Drake
Modules
Here is a list of all modules:
[detail level 12345]
 Formulating and Solving Optimization ProblemsDrake wraps a number of commercial solvers (+ a few custom solvers) to provide a common interface for convex optimization, mixed-integer convex optimization, and other non-convex mathematical programs
 Modeling Dynamical SystemsDrake uses a Simulink-inspired description of dynamical systems
 PrimitivesGeneral-purpose Systems such as Gain, Multiplexer, Integrator, and LinearSystem
 ControllersImplementations of controllers that operate as Systems in a block diagram
 EstimatorsImplementations of estimators that operate as Systems in a block diagram
 SensorsModels of sensors that operate as Systems in a block diagram
 Automotive SystemsThe drake/automotive folder collects automotive-specific System models and related software
 Automotive PlantsActuated System models related to automotive software
 Automotive Planners and ControllersSystem planners and controllers related to automotive software
 ManipulationSystems implementations that specifically support dexterous manipulation capabilities in robotics
 Message PassingSystems for publishing/subscribing to popular message passing ecosystems
 Stochastic SystemsThis page describes the implementation details of modeling a stochastic system in Drake and writing algorithms that explicitly leverage the stochastic modeling framework
 VisualizationSystems for connecting to external visualization tools/GUIs
 ExamplesThe examples contain a number of useful System implementations
 AcrobotSystems related to the Acrobot example
 Manipulation StationSystems related to the "manipulation station" used in the MIT Intelligent Robot Manipulation class
 (Attic) Rigid-Body SystemsThese systems are being replaced with drake::multibody::multibody_plant::MultibodyPlant and drake::geometry::SceneGraph
 Algorithms
 Multibody Dynamics
 Multibody Dynamics ConceptsTranslating 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
 Terminology and NotationDrake uses consistent terminology and notation for multibody mechanics
 Notation BasicsWe are interested in representing physical quantities like position, orientation, inertia, and spatial velocity
 Frames and BodiesThe most fundamental object in multibody mechanics is the coordinate frame, or just frame
 Multibody QuantitiesQuantities of interest in multibody dynamics have distinct types
 Time Derivatives of Multibody QuantitiesScalar 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 AlgebraMultibody dynamics involves both rotational and translational quantities, for motion, forces, and mass properties
 Spatial Pose and TransformA spatial pose, more commonly just pose, provides the location and orientation of a frame B with respect to another frame A
 Spatial VectorsSpatial 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
 Multibody dynamics constraintsThis 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 typesConstraints 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 stabilizationBoth truncation and rounding errors can prevent constraints from being exactly satisfied
 Constraint Jacobian matricesMuch of the problem data necessary to account for constraints in dynamical systems refers to particular Jacobian matrices
 Contact surface constraintsConsider 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)
 ReferencesSources referenced within the multibody constraint documentation
 Collision Concepts (RigidBodyPlant only)In the real world, we can rely on the axiom that no two objects can occupy the same space at the same time; the universe provides this constraint for free
 Collision Filter ConceptsCollision filters are a purely non-physical concept
 Collision Cliques
 Collision Filter Groups
 Compliant Contact in DrakeDrake is concerned with the simulation of physical phenomena, including contact between simulated objects
 Detecting ContactGiven 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
 Computing Contact ForcesConsider the definition of a contact with interpenetrating collision elements A and B
 Working with Contacts in DrakeThe behavior of a simulation with contact will depend on three factors:
 The Details of Computing Contact ForcesDrake includes a compliant contact model
 Drake Contact ImplementationDrake's compliant point contact model is a coarse approximation of the previous discussion
 Simulation
 Analysis
 Planning
 Feedback Control Design
 State Estimation
 System Identification
 Technical Notes
 Python BindingsDetails on implementing python bindings for the C++ code
 C++ support features
 hash_append generic hashingDrake uses the hash_append pattern as described by N3980
 Template MetaProgramming
 System Cache Design and Implementation Notes
 System Scalar ConversionSystem scalar conversion refers to cloning a System templatized by one scalar type into an identical System that is templatized by a different scalar type
 Geometry RolesGeometry roles help define how a real-world object is modeled in Drake