Drake
Modules
Here is a list of all modules:
[detail level 12345]
 Formulating and Solving Optimization Problems Drake 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 Systems Drake uses a Simulink-inspired description of dynamical systems 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 Models of sensors that operate as Systems in a block diagram ▼Automotive Systems The drake/automotive folder collects automotive-specific System models and related software Automotive Plants Actuated System models related to automotive software Automotive Planners and Controllers System planners and controllers related to automotive software Manipulation Systems implementations that specifically support dexterous manipulation capabilities in robotics Message Passing Systems for publishing/subscribing to popular message passing ecosystems 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 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 (Attic) Rigid-Body Systems These systems are being replaced with drake::multibody::multibody_plant::MultibodyPlant and drake::geometry::SceneGraph ▼Algorithms ▼Multibody Dynamics ▼Multibody Dynamics Concepts 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 ▼Terminology and Notation Drake uses consistent terminology and notation for multibody mechanics Notation Basics We are interested in representing physical quantities like position, orientation, inertia, and spatial velocity Frames and Bodies The most fundamental object in multibody mechanics is the coordinate frame, or just frame Multibody Quantities Quantities of interest in multibody dynamics have distinct types 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 ▼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) References Sources 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 Concepts Collision filters are a purely non-physical concept Collision Cliques Collision Filter Groups ▼Compliant Contact 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 Computing Contact Forces Consider the definition of a contact with interpenetrating collision elements A and B Working with Contacts in Drake The behavior of a simulation with contact will depend on three factors: The Details of Computing Contact Forces Drake includes a compliant contact model Drake Contact Implementation Drake'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 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 Template MetaProgramming System Cache Design and Implementation Notes 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 Geometry Roles Geometry roles help define how a real-world object is modeled in Drake