| Drake Terminology and Notation | |
| Accuracy, Tolerance, and Precision | Most numerical methods are approximate, and many can trade speed for quality under user control |
| Multibody Terminology and Notation | Translating from the mathematics of multibody mechanics to correct code is a difficult process and requires careful discipline to ensure that the resulting code is correct |
| Notation Basics | We are interested in representing physical quantities like position, orientation, inertia, and spatial velocity |
| Frames and Bodies | The frame and body are fundamental to multibody mechanics |
| Multibody Quantities | Quantities of interest in multibody dynamics have distinct types |
| Units of Multibody Quantities | Drake uses SI units (also known as MKS – meters, kilograms, and seconds) |
| Time Derivatives of Multibody Quantities | Scalar quantities: The ordinary first time-derivative of the scalar x is denoted xdot or xDt whereas the ordinary second time-derivative of x is denoted xddot or xDDt |
| Spatial Algebra | Multibody dynamics involves both rotational and translational quantities, for motion, forces, and mass properties |
| Spatial Pose and Transform | A spatial pose, more commonly just pose, provides the location and orientation of a frame B with respect to another frame A |
| Spatial Vectors | Spatial vectors are 6-element quantities that are pairs of ordinary 3-vectors |
| Spatial Mass Matrix (Spatial Inertia) | A Spatial Mass Matrix (also called Spatial Inertia) M represents the mass, center of mass location, and inertia in a single 6×6 symmetric, mass-weighted positive definite matrix that logically consists of four 3×3 submatrices |
| Formulating and Solving Optimization Problems | Drake's MathematicalProgram class is used to solve the mathematical optimization problem in the following form |
| Costs and Constraints | Most simple costs and constraints can be added directly to a MathematicalProgram through the MathematicalProgram::AddCost() and MathematicalProgram::AddConstraint() interfaces and their specializations |
| Geometry Optimization | Provides an abstraction for reasoning about geometry in optimization problems, and using optimization problems to solve geometry problems |
| Geodesic Convexity | A robot that has revolute joints without any limits has an inherently non-Euclidean configuration space, but one can still consider "geodesically-convex" sets, akin to convex sets in Euclidean space |
| Modeling Dynamical Systems | |
| System Events | This page describes how Drake Systems can respond (through an Event) to changes ("triggers") in time, state, and inputs |
| Primitives | General-purpose Systems such as Gain, Multiplexer, Integrator, and LinearSystem |
| Controllers | Implementations of controllers that operate as Systems in a block diagram |
| Estimators | Implementations of estimators that operate as Systems in a block diagram |
| Sensors | Drake provides a variety of capabilities for sensor modeling |
| Manipulation | Systems implementations and related functions that specifically support dexterous manipulation capabilities in robotics |
| Message Passing | Systems for publishing/subscribing to popular message passing ecosystems |
| Multibody Systems | Systems that relate to, or add functionality to, MultibodyPlant |
| Perception | Systems for dealing with perception data and/or wrapping basic perception algorithms |
| Discrete Systems | This page describes discrete systems modeled by difference equations (contrast to continuous systems modeled by ordinary differential equations) as well as considerations for implementing these systems in Drake |
| Stochastic Systems | This page describes the implementation details of modeling a stochastic system in Drake and writing algorithms that explicitly leverage the stochastic modeling framework |
| Configuring distributions | This page describes how to use classes such as schema::Distribution to denote stochastic quantities, as a bridge between loading a scenario specification and populating the corresponding symbolic::Expression quantities into a systems::System |
| Configuring transforms | This page describes how to use classes such as schema::Rotation and schema::Transform to denote stochastic quantities, as a bridge between loading a scenario specification and populating the corresponding math::RigidTransform quantities |
| Visualization | Systems for connecting to external visualization tools/GUIs |
| Examples | The examples contain a number of useful System implementations |
| Acrobot | Systems related to the Acrobot example |
| Multibody Kinematics and Dynamics | |
| Contact Modeling in Drake | |
| Modeling Compliant Contact | |
| Modeling of Dry Friction | |
| Margin for Hydroelastic Contact | |
| Estimation of Hydroelastic Parameters | |
| Default Contact Parameters | |
| Simulation of Multibody Systems | |
| Discrete Models for Simulation | |
| Continuous Models for Simulation | |
| Parsing Models for Multibody Dynamics | Drake's drake::multibody::Parser accepts model files written in a variety of input formats |
| Hydroelastic Contact User Guide | A guide to using hydroelastic contact in practice |
| Algorithms | |
| Simulation | |
| Integrators | Apart from solving initial value problems, for which the integrator is a key component of a simulator, integrators can also be used to solve boundary value problems (via numerical methods like the Multiple Shooting Method) and trajectory optimization problems (via numerical methods like direct transcription) |
| Simulator configuration | Configuration helpers to control Simulator and IntegratorBase settings |
| Analysis | |
| Planning | A collection of algorithms for finding configurations and/or trajectories of dynamical systems |
| Inverse kinematics | These algorithms help define configurations of dynamical systems based on inverse kinematics (IK) |
| Trajectories | These algorithms compute trajectories based on various criteria |
| Collision checking | The CollisionChecker interface provides a basis for performing distance queries on robots in environments for various planning problems (e.g., sampling planning) |
| Convenience classes | Simplifications for managing Diagrams containing MultibodyPlant and SceneGraph systems in planning tasks |
| Iris | These algorithms help construct regions of configuration space that are collision free |
| Feedback Control Design | A collection of algorithms for synthesizing feedback control |
| State Estimation | |
| System Identification | |
| Geometric Representations | |
| SceneGraph, SceneGraphInspector, QueryObject | SceneGraph serves as the nexus for all geometry (and geometry-based operations) in a Diagram |
| Geometry Queries and Roles | Geometry roles help define how a real-world object is modeled in Drake |
| Proximity Queries | Proximity queries span a range of types, including: |
| Penetration Queries | Penetration queries report all pairs of intersecting geometries and differ in how they characterize the penetration |
| Contact Surface | |
| Rendering Engines | Rendering engines are used to enable simulation of the perception stack |
| Render Benchmarks | Benchmarks for assessing rendering performance and comparing implementations |
| Render Engine Benchmarks | The benchmark consists of a scene with one or more spheres and one or more cameras above the spheres, looking down at the spheres |
| glTF Render Client-Server API | |
| Supported file formats | Drake offers a number of primitive types for representing objects' extents in space |
| Geometry Optimization | Provides an abstraction for reasoning about geometry in optimization problems, and using optimization problems to solve geometry problems |
| Geodesic Convexity | A robot that has revolute joints without any limits has an inherently non-Euclidean configuration space, but one can still consider "geodesically-convex" sets, akin to convex sets in Euclidean space |
| Technical Notes | |
| Python Bindings | Details on implementing python bindings for the C++ code |
| C++ support features | |
| hash_append generic hashing | Drake uses the hash_append pattern as described by N3980 |
| Default Scalars | Similar to the Eigen library, many classes in Drake use a template argument to specify the numeric scalar type to use for computation |
| Deprecation Severity Controls | Drake provides mechanisms to control the severity of deprecated API usage at both compile time and at runtime |
| Code Generation | Provides CodeGen functions which generate C99 code to evaluate symbolic expressions and matrices |
| YAML Serialization | |
| Template MetaProgramming | |
| Environment Variables | This section provides an inventory of environment variables relevant to Drake |
| DRAKE_PYTHON_LOGGING | By default, pydrake will redirect spdlog logging (from C++) to Python's logging module |
| DRAKE_DISABLE_CPU_FEATURES | Certain low-level code in Drake will scan for available CPU features at runtime and dispatch to CPU-optimized implementations |
| DRAKE_ALLOW_NETWORK | Users can set the environment variable DRAKE_ALLOW_NETWORK to a colon-separated list to limit which components are permitted network access |
| System Cache Design and Implementation Notes | |
| System Compatibility | System compatibility refers to the correspondence between a System and data structures used to hold the results of computation |
| System Scalar Conversion | System scalar conversion refers to cloning a System templatized by one scalar type into an identical System that is templatized by a different scalar type |
| Drake Version | Drake exposes its version to downstream C++ as preprocessor macros, so that code can adapt to the Drake version at compile time, e.g., to handle API changes across releases |
