▼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 |
▼Modeling Dynamical Systems | Drake uses a Simulink-inspired description of 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 |
Manipulation Station | Systems related to the "manipulation station" used in the MIT Intelligent Robot Manipulation class |
▼Multibody Kinematics and Dynamics | |
▼Multibody Dynamics Constraints | This documentation describes the types of multibody constraints supported in Drake, including specialized constraint types- namely point-based contact constraints that allow Drake's constraint solver to readily incorporate the Coulomb friction model |
Variable definitions | |
Constraint types | Constraints can be categorized as either bilateral ("two-sided" constraints, e.g., g(q) = 0) or unilateral ("one-sided" constraints, e.g., g(q) ≥ 0) |
Constraint stabilization | Both truncation and rounding errors can prevent constraints from being exactly satisfied |
Constraint Jacobian matrices | Much of the problem data necessary to account for constraints in dynamical systems refers to particular Jacobian matrices |
Contact surface constraints | Consider two points pᵢ and pⱼ on rigid bodies i and j, respectively, and assume that at a certain configuration of the two bodies, ᶜq, the two points are coincident at a single location in space, p(ᶜq) |
A stable discretization strategy | To be written |
References | Sources referenced within the multibody constraint documentation |
Hydroelastic Contact User Guide | |
Parsing Models for Multibody Dynamics | Drake's drake::multibody::Parser accepts model files written in a variety of input formats |
▼Contact Modeling in Drake | Drake is concerned with the simulation of physical phenomena, including contact between simulated objects |
Detecting Contact | Given two posed geometric shapes in a common frame, the collision detection system is responsible for determining if those shapes are penetrating and characterizing that penetration |
Working with Contacts in Drake | The behavior of a simulation with contact will depend on three factors: |
Continuous Approximation of Coulomb Friction | Static friction (or stiction) arises due to surface characteristics at the microscopic level (e.g., mechanical interference of surface imperfections, electrostatic, and/or Van der Waals forces) |
▼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 |
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 |
▼Technical Notes | |
Python Bindings | Details on implementing python bindings for the C++ code |
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 |
▼C++ support features | |
hash_append generic hashing | Drake uses the hash_append pattern as described by N3980 |
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_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 |