diff --git a/dev/api.html b/dev/api.html index bbe430ea..bc7876de 100644 --- a/dev/api.html +++ b/dev/api.html @@ -14,105 +14,105 @@ timestep: time discretization input_scaling: input scaling for internal use of impulses (default: timestep) gravity: force vector resulting from gravitational potential -μ: complementarity violation (contact softness)source
Dojo.get_node — Function
get_node(mechanism, name) 
+μ: complementarity violation (contact softness)
source
Dojo.get_node — Function
get_node(mechanism, name) 
 
 return Node from Mechanism 
 
 mechanism: Mechanism 
-name: unique identifier for node
source
Dojo.get_body — Function
get_body(mechanism, name) 
+name: unique identifier for node
source
Dojo.get_body — Function
get_body(mechanism, name) 
 
 returns Body from Mechanism
 
 mechanism: Mechanism 
-name: unique identifier for body
source
Dojo.get_joint — Function
get_joint(mechanism, name) 
+name: unique identifier for body
source
Dojo.get_joint — Function
get_joint(mechanism, name) 
 
 return JointConstraint from Mechanism 
 
 mechanism: Mechanism 
-name: unique identifier for joint
source
Dojo.get_contact — Function
get_contact(mechanism, name) 
+name: unique identifier for joint
source
Dojo.get_contact — Function
get_contact(mechanism, name) 
 
 returns ContactConstraint from Mechanism 
 
 mechanism: Mechanism 
-name: unique identifier for contact
source
Dojo.get_maximal_state — Function
get_maximal_state(mechanism) 
+name: unique identifier for contact
source
Dojo.get_maximal_state — Function
get_maximal_state(mechanism) 
 
 return the current maximal state of mechanism 
 
-mechanism: Mechanism
source
Dojo.get_next_state — Function
get_next_state(mechanism) 
+mechanism: Mechanism
source
Dojo.get_next_state — Function
get_next_state(mechanism) 
 
 return the maximal state of mechanism after one simulation step
 
-mechanism: Mechanism
source
Dojo.get_minimal_state — Function
get_minimal_state(mechanism) 
+mechanism: Mechanism
source
Dojo.get_minimal_state — Function
get_minimal_state(mechanism) 
 
 return minimal state for mechanism 
 
-mechanism: Mechanism
source
Dojo.set_maximal_state! — Function
set_maximal_state(mechanism, z) 
+mechanism: Mechanism
source
Dojo.set_maximal_state! — Function
set_maximal_state(mechanism, z) 
 
 set the maximal state of a mechanism 
 
 mechanism: Mechanism 
-z: state
source
Dojo.set_minimal_state! — Function
set_minimal_state(mechanism, y) 
+z: state
source
Dojo.set_minimal_state! — Function
set_minimal_state(mechanism, y) 
 
 set the minimal state of a mechanism 
 
 mechanism: Mechanism 
-y: state
source
Dojo.set_input! — Function
set_input(mechanism, u) 
+y: state
source
Dojo.set_input! — Function
set_input(mechanism, u) 
 
 set input for each joint in mechanism 
 
 mechanism: Mechanism 
-u: input
source
Dojo.maximal_dimension — Function
maximal_dimension(mechanism)
+u: input
source
Dojo.maximal_dimension — Function
maximal_dimension(mechanism)
 
 dimension of a mechanism's maximal representation
 
-mechanism: Mechanism
source
Dojo.minimal_dimension — Function
minimal_dimension(mechanism)
+mechanism: Mechanism
source
Dojo.minimal_dimension — Function
minimal_dimension(mechanism)
 
 dimension of a mechanism's minimal representation
 
-mechanism: Mechanism
source
Dojo.input_dimension — Function
input_dimension(mechanism)
+mechanism: Mechanism
source
Dojo.input_dimension — Function
input_dimension(mechanism)
 
 return the number of inputs for mechanism
 
-mechanism: Mechanism
source
Dojo.input_dimensions — Function
input_dimensions(mechanism)
+mechanism: Mechanism
source
Dojo.input_dimensions — Function
input_dimensions(mechanism)
 
 return an array with the input dimensions of all joints
 
-mechanism: Mechanism
source
Dojo.zero_coordinates! — Function
zero_coordinates!(mechanism) 
+mechanism: Mechanism
source
Dojo.zero_coordinates! — Function
zero_coordinates!(mechanism) 
 
 set all mechanism body coordinates to zero 
 
-mechanism: Mechanism
source
Dojo.zero_velocities! — Function
zero_velocities!(mechanism) 
+mechanism: Mechanism
source
Dojo.zero_velocities! — Function
zero_velocities!(mechanism) 
 
 set all mechanism body velocities to zero 
 
-mechanism: Mechanism
source
Dojo.root_to_leaves_ordering — Function
root_to_leaves_ordering(mechanism; exclude_origin, exclude_loop_joints)
+mechanism: Mechanism
source
Dojo.root_to_leaves_ordering — Function
root_to_leaves_ordering(mechanism; exclude_origin, exclude_loop_joints)
 
 ordered list of ids from root to leaves, all nodes are visited a single time
     excluding: origin, joints forming a loop which are not visited
 
 mechanism: Mechanism 
 exclude_origin: flag to exclude origin from traversal 
-exclude_loop_joints: flag to exclude loop joints from traversal
source
Dojo.set_floating_base — Function
set_floating_base(mechanism, name)
+exclude_loop_joints: flag to exclude loop joints from traversal
source
Dojo.set_floating_base — Function
set_floating_base(mechanism, name)
 
 returns a mechanism with modified joints having body identified with 'name' as the floating base
 
 mechanism: Mechanism
-name: Symbol, identifier for floating-base body
source
Dojo.set_external_force! — Function
set_external_force!(body; force, torque, vertex)
+name: Symbol, identifier for floating-base body
source
Dojo.set_external_force! — Function
set_external_force!(body; force, torque, vertex)
 
 applies an external force on a body
 
 body: Body 
 force: force in body frame
 torque: torque in local frame
-vertex: point where force is applied in local frame
source
Dojo.add_external_force! — Function
add_external_force!(body; force, torque, vertex)
+vertex: point where force is applied in local frame
source
Dojo.add_external_force! — Function
add_external_force!(body; force, torque, vertex)
 
 adds an additional external force on a body
 
 body: Body 
 force: force in body frame
-torque: torque in local frame
source

Nodes

Dojo.Node — Type
Node{T}
+torque: torque in local frame
source

Nodes

Dojo.Node — Type
Node{T}
 
-Abstract type for graph node object
source
Dojo.Body — Type
Body{T} <: Node{T}
+Abstract type for graph node object
source
Dojo.Body — Type
Body{T} <: Node{T}
 
 A rigid body object
 
@@ -121,22 +121,22 @@
 mass: inertial property (kilograms)
 inertia: inertia matrix (kilograms meter^2)
 state: State; representation of the system's: position, linear velocity, orientation, and angular velocity 
-shape: Shape; geometry information about the Body
source
Dojo.Origin — Type
Origin{T} <: Node{T}
+shape: Shape; geometry information about the Body
source
Dojo.Origin — Type
Origin{T} <: Node{T}
 
 Global reference frame
 
 id: always 0 
 name: always :origin 
 state: State; defaults to zero values
-shape: Shape; defaults to EmptyShape
source
Dojo.Constraint — Type
Constraint{T}
+shape: Shape; defaults to EmptyShape
source
Dojo.Constraint — Type
Constraint{T}
 
-Abstract type for graph edge object
source
Dojo.Shape — Type
Shape{T} 
+Abstract type for graph edge object
source
Dojo.Shape — Type
Shape{T} 
 
-Abstract type; Subtypes contain geometric and visual information for a Body.
source
Dojo.EmptyShape — Type
EmptyShape{T} <: Shape{T}
+Abstract type; Subtypes contain geometric and visual information for a Body.
source
Dojo.EmptyShape — Type
EmptyShape{T} <: Shape{T}
 
-Contains no geometric or visual information
source
Dojo.Mesh — Type
Mesh{T} <: Shape{T}
+Contains no geometric or visual information
source
Dojo.Mesh — Type
Mesh{T} <: Shape{T}
 
-Contains geometric and visual information based on .obj file
source
Dojo.Box — Type
Box{T} <: Shape{T}
+Contains geometric and visual information based on .obj file
source
Dojo.Box — Type
Box{T} <: Shape{T}
 
 Cuboid geometry 
 
@@ -144,7 +144,7 @@
 orientation_offset: orientation offset from body frame
 xyz: dimensions (meters)
 scale: scaling
-color: RGBA
source
Dojo.Cylinder — Type
Cylinder{T} <: Shape{T}
+color: RGBA
source
Dojo.Cylinder — Type
Cylinder{T} <: Shape{T}
 
 cylinder geometry 
 
@@ -152,13 +152,13 @@
 orientation_offset: orientation offset from body frame
 rh: radius and height dimensions (meters)
 scale: scaling
-color: RGBA
source
Dojo.Capsule — Function
Capsule geometry created as a CombinedShapes
+color: RGBA
source
Dojo.Capsule — Function
Capsule geometry created as a CombinedShapes
 
 position_offset: geometry origin offset from center of mass
 orientation_offset: orientation offset from body frame
 rh: radius and height dimensions (meters)
 scale: scaling
-color: RGBA
source
Dojo.Sphere — Type
Sphere{T} <: Shape{T}
+color: RGBA
source
Dojo.Sphere — Type
Sphere{T} <: Shape{T}
 
 sphere geometry 
 
@@ -166,7 +166,7 @@
 orientation_offset: orientation offset from body frame
 r: radius (meters)
 scale: scaling
-color: RGBA
source
Dojo.Pyramid — Type
Pyramid{T} <: Shape{T}
+color: RGBA
source
Dojo.Pyramid — Type
Pyramid{T} <: Shape{T}
 
 pyramid geometry 
 
@@ -174,19 +174,19 @@
 orientation_offset: orientation offset from body frame
 wh: width and height dimensions (meters)
 scale: scaling
-color: RGBA
source
Dojo.FrameShape — Type
FrameShape{T} <: Shape{T}
+color: RGBA
source
Dojo.FrameShape — Type
FrameShape{T} <: Shape{T}
 
 coordinate frame geometry 
 
 position_offset: geometry origin offset from center of mass
 orientation_offset: orientation offset from body frame
 scale: scaling
-color: not used
source
Dojo.CombinedShapes — Type

CombinedShapes{T} <: Shape{T}

composite geometry
+color: not used
source
Dojo.CombinedShapes — Type

CombinedShapes{T} <: Shape{T}

composite geometry
 
 position_offset: geometry origin offset from center of mass
 orientation_offset: orientation offset from body frame
 shape: list of Shape objects
-xyz: dimensions (meters)
source

Joints

Dojo.Joint — Type

Joint{T}

Abstract type for 3-dimensional constraint between two Body objects

source
Dojo.Rotational — Type
Rotational{T} <: Joint{T}
+xyz: dimensions (meters)
source

Joints

Dojo.Joint — Type

Joint{T}

Abstract type for 3-dimensional constraint between two Body objects

source
Dojo.Rotational — Type
Rotational{T} <: Joint{T}
 
 constraint limiting rotational degrees of freedom
 
@@ -200,7 +200,7 @@
 spring_offset: nominal joint configuration
 joint_limits: lower and upper limits on the joint configuration
 spring_type: can be :linear or :sinusoidal (currently not implemented), if linear then we need joint_limits to avoid the 360° singularity.
-input: external impulse torque
source
Dojo.Translational — Type
Translational{T} <: Joint{T}
+input: external impulse torque
source
Dojo.Translational — Type
Translational{T} <: Joint{T}
 
 constraint limiting translational degrees of freedom
 
@@ -214,7 +214,7 @@
 spring_offset: nominal joint configuration
 joint_limits: lower and upper limits on the joint configuration
 spring_type: can be :linear or :sinusoidal (currently not implemented), if linear then we need joint_limits to avoid the 360° singularity.
-input: external impulse force
source
Dojo.JointConstraint — Type
JointConstraint{T} <: Constraint{T}
+input: external impulse force
source
Dojo.JointConstraint — Type
JointConstraint{T} <: Constraint{T}
 
 constraint restricting translational and rotational degrees of freedom between two Body objects.
 
@@ -227,50 +227,50 @@
 parent_id: identifying number for parent Body{T}
 child_id: identifying number for child Body{T}
 minimal_index: indices for minimal coordinates
-impulses: joint impulses that maintain constraint between two Body{T} objects
source
Dojo.Floating — Function
Floating{T} <: JointConstraint{T} 
+impulses: joint impulses that maintain constraint between two Body{T} objects
source
Dojo.Floating — Function
Floating{T} <: JointConstraint{T} 
 
-no restricted degrees of freedom between two bodies
source
Dojo.Fixed — Function
Fixed{T} <: JointConstraint{T}
+no restricted degrees of freedom between two bodies
source
Dojo.Fixed — Function
Fixed{T} <: JointConstraint{T}
 
-fixed connection between two bodies
source
Dojo.Prismatic — Function
Prismatic{T} <: JointConstraint{T}
+fixed connection between two bodies
source
Dojo.Prismatic — Function
Prismatic{T} <: JointConstraint{T}
 
-one translational degree of freedom between two bodies
source
Dojo.Planar — Function
Planar{T} <: JointConstraint{T} 
+one translational degree of freedom between two bodies
source
Dojo.Planar — Function
Planar{T} <: JointConstraint{T} 
 
-two translational degree of freedom between two bodies
source
Dojo.FixedOrientation — Function
FixedOrientation{T} <: JointConstraint{T} 
+two translational degree of freedom between two bodies
source
Dojo.FixedOrientation — Function
FixedOrientation{T} <: JointConstraint{T} 
 
-three translational degree of freedom between two bodies
source
Dojo.Revolute — Function
Revolute{T} <: JointConstraint{T} 
+three translational degree of freedom between two bodies
source
Dojo.Revolute — Function
Revolute{T} <: JointConstraint{T} 
 
-one rotational degree of freedom between two bodies
source
Dojo.Cylindrical — Function
Cylindrical{T} <: JointConstraint{T} 
+one rotational degree of freedom between two bodies
source
Dojo.Cylindrical — Function
Cylindrical{T} <: JointConstraint{T} 
 
-one translational and one rotational degree of freedom between two bodies
source
Dojo.PlanarAxis — Function
PlanarAxis{T} <: JointConstraint{T} 
+one translational and one rotational degree of freedom between two bodies
source
Dojo.PlanarAxis — Function
PlanarAxis{T} <: JointConstraint{T} 
 
-two translational and one rotational degree of freedom between two bodies
source
Dojo.FreeRevolute — Function
FreeRevolute{T} <: JointConstraint{T} 
+two translational and one rotational degree of freedom between two bodies
source
Dojo.FreeRevolute — Function
FreeRevolute{T} <: JointConstraint{T} 
 
-free translation with rotation along one axis
source
Dojo.Orbital — Function
Orbital{T} <: JointConstraint{T} 
+free translation with rotation along one axis
source
Dojo.Orbital — Function
Orbital{T} <: JointConstraint{T} 
 
-two rotational degrees of freedom between two bodies
source
Dojo.PrismaticOrbital — Function
PrismaticOrbital{T} <: JointConstraint{T} 
+two rotational degrees of freedom between two bodies
source
Dojo.PrismaticOrbital — Function
PrismaticOrbital{T} <: JointConstraint{T} 
 
-one translational and two rotational degrees of freedom between two bodies
source
Dojo.PlanarOrbital — Function
PlanarOrbital{T} <: JointConstraint{T} 
+one translational and two rotational degrees of freedom between two bodies
source
Dojo.PlanarOrbital — Function
PlanarOrbital{T} <: JointConstraint{T} 
 
-two translational and two rotational degrees of freedom between two bodies
source
Dojo.FreeOrbital — Function
FreeOrbital{T} <: JointConstraint{T} 
+two translational and two rotational degrees of freedom between two bodies
source
Dojo.FreeOrbital — Function
FreeOrbital{T} <: JointConstraint{T} 
 
-three translational and two rotational degrees of freedom between two bodies
source
Dojo.Spherical — Function
Spherical{T} <: JointConstraint{T} 
+three translational and two rotational degrees of freedom between two bodies
source
Dojo.Spherical — Function
Spherical{T} <: JointConstraint{T} 
 
-three rotational degrees of freedom between two bodies
source
Dojo.CylindricalFree — Function
CylindricalFree{T} <: JointConstraint{T} 
+three rotational degrees of freedom between two bodies
source
Dojo.CylindricalFree — Function
CylindricalFree{T} <: JointConstraint{T} 
 
-one translational and three rotational degrees of freedom between two bodies
source
Dojo.PlanarFree — Function
PlanarFree{T} <: JointConstraint{T} 
+one translational and three rotational degrees of freedom between two bodies
source
Dojo.PlanarFree — Function
PlanarFree{T} <: JointConstraint{T} 
 
-two translational and three rotational degrees of freedom between two bodies
source

Contacts

Dojo.Contact — Type
Contact{T,N} 
+two translational and three rotational degrees of freedom between two bodies
source

Contacts

Dojo.Contact — Type
Contact{T,N} 
 
-Abstract type containing contact information associated with Body objects.
source
Dojo.ImpactContact — Type
ImpactContact{T,N} <: Contact{T,N}
+Abstract type containing contact information associated with Body objects.
source
Dojo.ImpactContact — Type
ImpactContact{T,N} <: Contact{T,N}
 
 contact object for impact (i.e., no friction)
 
-collision: Collision
source
Dojo.LinearContact — Type
LinearContact{T,N} <: Contact{T,N}
+collision: Collision
source
Dojo.LinearContact — Type
LinearContact{T,N} <: Contact{T,N}
 
 contact object for impact and friction with a linearized friction cone
 
 friction_coefficient: value of friction coefficient
-collision: Collision
source
Dojo.NonlinearContact — Type
NonlinearContact{T,N} <: Contact{T,N}
+collision: Collision
source
Dojo.NonlinearContact — Type
NonlinearContact{T,N} <: Contact{T,N}
 
 contact object for impact and friction with a nonlinear friction cone
 
@@ -278,7 +278,7 @@
 contact_tangent: mapping from world frame to surface tangent frame 
 contact_normal: inverse/complement of contact_tangent
 contact_origin: position of contact on Body relative to center of mass 
-contact radius: radius of contact
source
Dojo.ContactConstraint — Type
ContactConstraint{T} <: Constraint{T}
+contact radius: radius of contact
source
Dojo.ContactConstraint — Type
ContactConstraint{T} <: Constraint{T}
 
 constraint containing information for contact node.
 
@@ -288,7 +288,7 @@
 parent_id: identifying number of Body experiencing contact 
 child_id: always 0
 impulses: contact impulses applied to Body 
-impulses_dual: dual contact impulses, used by solver to enforce correct contact behaviors
source
Dojo.contact_constraint — Function
contact_constraint(bodies::Vector{Body}) 
+impulses_dual: dual contact impulses, used by solver to enforce correct contact behaviors
source
Dojo.contact_constraint — Function
contact_constraint(bodies::Vector{Body}) 
 
 generate ContactConstraints for each Body in list
 
@@ -296,35 +296,35 @@
 friction_coefficients: value of coefficient of friction for each contact point (optional for ImpactContact)
 contact_origins: the offset with respect to the center of Body for each contact point (optional)
 contact_radius: radius for each contact (optional)
-contact_type: :nonlinear, :linear, :impact
source
Dojo.contact_location — Function
contact_location(contact, x, q)
+contact_type: :nonlinear, :linear, :impact
source
Dojo.contact_location — Function
contact_location(contact, x, q)
 
 location of contact point in world coordinates
 
 contact: ContactConstraint
 x: body position
-q: body orientation
source
Dojo.get_sdf — Function
get_sdf(contact, x, q)
+q: body orientation
source
Dojo.get_sdf — Function
get_sdf(contact, x, q)
 
 returns the signed distance for a contact
 
 contact: ContactConstraint
 x: body position
-q: body orientation
source
Dojo.Collision — Type
Collision
+q: body orientation
source
Dojo.Collision — Type
Collision
 
-abstract type defining interaction between two bodies
source
Dojo.SphereHalfSpaceCollision — Type
SphereHalfSpaceCollision 
+abstract type defining interaction between two bodies
source
Dojo.SphereHalfSpaceCollision — Type
SphereHalfSpaceCollision 
 
 collision between a spherical contact and a flat surface
 
 contact_tangent: mapping from world frame to surface tangent frame 
 contact_normal: inverse/complement of contact_tangent
 contact_origin: position of contact on Body relative to center of mass 
-contact_radius: radius of contact
source
Dojo.SphereSphereCollision — Type
SphereSphereCollision 
+contact_radius: radius of contact
source
Dojo.SphereSphereCollision — Type
SphereSphereCollision 
 
 collision between two spheres
 
 origin_parent: position of contact on parent body relative to center of mass 
 origin_child: position of contact on parent body relative to center of mass 
 radius_parent: radius of contact for parent body 
-radius_child: radius of contact for child body
source
Dojo.SphereCapsuleCollision — Type
SphereCapsuleCollision 
+radius_child: radius of contact for child body
source
Dojo.SphereCapsuleCollision — Type
SphereCapsuleCollision 
 
 collision between sphere and capsule 
 
@@ -332,14 +332,14 @@
 origin_capsule_a: position of capsule contact a relative to body center of mass
 origin_capsule_b: position of capsule contact b relative to body center of mass
 radius_sphere:    radius of sphere contact
-radius_capsule:   radius of capsule contact
source
Dojo.SphereBoxCollision — Type
SphereBoxCollision 
+radius_capsule:   radius of capsule contact
source
Dojo.SphereBoxCollision — Type
SphereBoxCollision 
 
 collision between sphere and box 
 
 origin_sphere:    position of sphere contact relative to body center of mass
 origin_box_a:     position of box corner contact a relative to body center of mass
 origin_box_b:     position of box corner contact b relative to body center of mass
-radius_sphere:    radius of sphere contact
source
Dojo.contact_normal — Function
contact_normal(collision, xp, qp, xc, qc)
+radius_sphere:    radius of sphere contact
source
Dojo.contact_normal — Function
contact_normal(collision, xp, qp, xc, qc)
 
 the contact normal (from child to parent) between two contact points
 
@@ -347,7 +347,7 @@
 xp: parent body position
 qp: parent body orientation
 xc: child body position
-qc: child body orientation
source
Dojo.contact_tangent — Function
contact_tangent(collision, xp, qp, xc, qc)
+qc: child body orientation
source
Dojo.contact_tangent — Function
contact_tangent(collision, xp, qp, xc, qc)
 
 contact tangents between two contact points
 
@@ -355,7 +355,7 @@
 xp: parent body position
 qp: parent body orientation
 xc: child body position
-qc: child body orientation
source

Representations

Dojo.State — Type
State{T} 
+qc: child body orientation
source

Representations

Dojo.State — Type
State{T} 
 
 state information in maximal coordinates for Body at time steps: 1, 2, 3. 
 information at time step 3 is recovered using configurations at time step 2 and velocities at time step 2.5.
@@ -376,37 +376,37 @@
 ωsol: angular velocity at time step 2.5 (midpoint); contains current value (index 1) and candidate value (index 2)
 
 d: implicit dynamics evaluator (zero vector indicates physics are satisfied)
-D: Jacobian of implicit dynamics
source
Dojo.minimal_to_maximal — Function
minimal_to_maximal(mechanism, y)
+D: Jacobian of implicit dynamics
source
Dojo.minimal_to_maximal — Function
minimal_to_maximal(mechanism, y)
 
 convert minimal to maximal representation
 
 mechanism: Mechanism
-y: minimal state
source
Dojo.maximal_to_minimal — Function
maximal_to_minimal(mechanism, z)
+y: minimal state
source
Dojo.maximal_to_minimal — Function
maximal_to_minimal(mechanism, z)
 
 convert maximal to minimal representation
 
 mechanism: Mechanism
-z: maximal state
source

Mechanics

Dojo.mechanical_energy — Function
mechanical_energy(mechanism, storage)
+z: maximal state
source

Mechanics

Dojo.mechanical_energy — Function
mechanical_energy(mechanism, storage)
 
 mechanism's total mechanical energy
 
 mechanism: Mechanism 
-storage: Storage
source
Dojo.kinetic_energy — Function
kinetic_energy(mechanism, storage)
+storage: Storage
source
Dojo.kinetic_energy — Function
kinetic_energy(mechanism, storage)
 
 mechanism's kinetic energy from linear and angular velocity
 
 mechanism: Mechanism 
-storage: Storage
source
Dojo.potential_energy — Function
potential_energy(mechanism, storage)
+storage: Storage
source
Dojo.potential_energy — Function
potential_energy(mechanism, storage)
 
 mechanism's potential energy from gravity and springs
 
 mechanism: Mechanism 
-storage: Storage
source
Dojo.momentum — Function
momentum(mechanism, storage)
+storage: Storage
source
Dojo.momentum — Function
momentum(mechanism, storage)
 
 mechanism's linear and angular momentum
 
 mechanism: Mechanism
-storage: Storage
source

Simulate

Dojo.Storage — Type
Storage{T,N}
+storage: Storage
source

Simulate

Dojo.Storage — Type
Storage{T,N}
 
 contains maximal-representation trajectories
 
@@ -417,21 +417,21 @@
 px: linear momentum
 pq: angular momentum 
 vl: linear velocity
-ωl: angular velocity
source
Dojo.step! — Function
step!(mechanism::Mechanism{T}, z::Vector{T}, u::Vector{T}; opts)
+ωl: angular velocity
source
Dojo.step! — Function
step!(mechanism::Mechanism{T}, z::Vector{T}, u::Vector{T}; opts)
 
 simulate mechanism for one time step provided maximal coordinates
 
 mechanism: Mechanism
 z: maximal state 
 u: inputs
-opts: SolverOptions
source
Dojo.step_minimal_coordinates! — Function
step_minimal_coordinates!(mechanism::Mechanism{T}, x::Vector{T}, u::Vector{T}; opts)
+opts: SolverOptions
source
Dojo.step_minimal_coordinates! — Function
step_minimal_coordinates!(mechanism::Mechanism{T}, x::Vector{T}, u::Vector{T}; opts)
 
 simulate mechanism for one time step provided minimal coordinates
 
 mechanism: Mechanism
 x: minimal state 
 u: inputs
-opts: SolverOptions
source
Dojo.simulate! — Function
simulate!(mechanism, steps, storage, control!;
+opts: SolverOptions
source
Dojo.simulate! — Function
simulate!(mechanism, steps, storage, control!;
     record, verbose, abort_upon_failure, opts)
 
 simulate a mechanism
@@ -443,7 +443,7 @@
 record: flag for recording simulation to storage
 verbose: flag for printing during simulation 
 abort_upon_failure: flag for terminating simulation is solver fails to meet tolerances
-opts: SolverOptions
source

Gradients

Dojo.get_maximal_gradients! — Function
get_maximal_gradients!(mechanism, z, u; opts)
+opts: SolverOptions
source

Gradients

Dojo.get_maximal_gradients! — Function
get_maximal_gradients!(mechanism, z, u; opts)
 
 return maximal gradients for mechanism
 note: this requires simulating the mechanism for one time step
@@ -451,7 +451,7 @@
 mechanism: Mechanism
 z: state
 u: input
-opts: SolverOptions
source
Dojo.get_minimal_gradients! — Function
get_minimal_gradients!(mechanism, y, u; opts)
+opts: SolverOptions
source
Dojo.get_minimal_gradients! — Function
get_minimal_gradients!(mechanism, y, u; opts)
 
 return minimal gradients for mechanism
 note: this requires simulating the mechanism for one time step
@@ -459,17 +459,17 @@
 mechanism: Mechanism
 y: state
 u: input
-opts: SolverOptions
source
Dojo.maximal_to_minimal_jacobian — Function
maximal_to_minimal_jacobian(mechanism, z)
+opts: SolverOptions
source
Dojo.maximal_to_minimal_jacobian — Function
maximal_to_minimal_jacobian(mechanism, z)
 
 Jacobian of mapping from maximal to minimal representation
 
 mechanism: Mechanism
-z: maximal state
source
Dojo.minimal_to_maximal_jacobian — Function
minimal_to_maximal_jacobian(mechanism, x)
+z: maximal state
source
Dojo.minimal_to_maximal_jacobian — Function
minimal_to_maximal_jacobian(mechanism, x)
 
 Jacobian of mapping from minimal to maximal representation
 
 mechanism: Mechanism
-y: minimal state
source

Solver

Dojo.SolverOptions — Type
SolverOptions{T}
+y: minimal state
source

Solver

Dojo.SolverOptions — Type
SolverOptions{T}
 
 Options and tolerances of primal-dual interior point solver.
 
@@ -481,12 +481,12 @@
 undercut: complementarity slackness target; solver will aim at reaching complementarity violation = btol / undercut; defaults to Inf
 no_progress_max: number of Newton's iterations without progress trigerring the rescaling of the target complementarity violation; defaults to 3
 no_progress_undercut: undercut scaling factor (target_new ← target_current / no_progress_undercut); defaults to 10
-verbose: flag for printing the status of the solver during the solve; defaults to false
source
Dojo.mehrotra! — Function
mehrotra!(mechanism; opts)
+verbose: flag for printing the status of the solver during the solve; defaults to false
source
Dojo.mehrotra! — Function
mehrotra!(mechanism; opts)
 
 interior-point solver for simulation-step feasibility problem
 
 mechanism: Mechanism
-opts: SolverOptions
source

Visualization

Dojo.visualize — Function
visualize(mechanism, storage; vis, build, show_contact, animation, color, name)
+opts: SolverOptions
source

Visualization

Dojo.visualize — Function
visualize(mechanism, storage; vis, build, show_contact, animation, color, name)
 
 visualize mechanism using trajectory from storage 
 
@@ -496,7 +496,7 @@
 build: flag to construct mechanism visuals (only needs to be built once)
 show_contact: flag to show contact locations on system 
 color: RGBA 
-name: unique identifier for mechanism
source
Dojo.build_robot — Function
build_robot(mechanism; vis, show_contact, name, color)
+name: unique identifier for mechanism
source
Dojo.build_robot — Function
build_robot(mechanism; vis, show_contact, name, color)
 
 construct visuals for mechanism 
 
@@ -504,19 +504,19 @@
 vis: Visualizer 
 show_contact: flag to show contact locations on mechanism 
 name: unique identifier 
-color: RGBA
source
Dojo.set_camera! — Function
set_camera!(vis; zoom, cam_pos)
+color: RGBA
source
Dojo.set_camera! — Function
set_camera!(vis; zoom, cam_pos)
 
 position and zoom for camera in visualization
 
 vis: Visualizer
 zoom: value for zoom
-cam_pos: position of camera
source
Dojo.set_light! — Function
set_light!(vis; ambient, fill, pointX, pointXshadow, direction)
+cam_pos: position of camera
source
Dojo.set_light! — Function
set_light!(vis; ambient, fill, pointX, pointXshadow, direction)
 
 lighting conditions for visualization
 
 vis: Visualizer
 ambient: value for ambient lighting
-direction: positive or negative direction for light
source
Dojo.set_surface! — Function
set_surface!(vis; f, xlims, ylims, color, n)
+direction: positive or negative direction for light
source
Dojo.set_surface! — Function
set_surface!(vis; f, xlims, ylims, color, n)
 
 adds surface to visualization
 
@@ -525,7 +525,7 @@
 xlims: lateral domain for surface
 ylims: longitudinal domain for surface
 color: RGBA
-n: number of discretization points along each domain
source
Dojo.set_floor! — Function
set_floor!(vis; x, y, z, origin, normal, color, tilepermeter, imagename, axis, grid)
+n: number of discretization points along each domain
source
Dojo.set_floor! — Function
set_floor!(vis; x, y, z, origin, normal, color, tilepermeter, imagename, axis, grid)
 
 adds floor to visualization
 
@@ -539,7 +539,7 @@
 tilepermeter: scaling
 imagename: path to image
 axis: flag to turn on visualizer axis
-grid: flag to turn on visualizer grid
source
Dojo.set_arrow! — Function
set_arrow!(vis, origin, direction; color, shaft_radius, max_head_radius, scaling, name)
+grid: flag to turn on visualizer grid
source
Dojo.set_arrow! — Function
set_arrow!(vis, origin, direction; color, shaft_radius, max_head_radius, scaling, name)
 
 adds an arrow object to scene 
 
@@ -550,4 +550,4 @@
 shaft_radius: dimension of arrow shaft 
 max_head_radius: dimension of arrow head base 
 scaling: parameter that scales the entire arrow 
-name: Symbol
source
+name: Symbolsource diff --git a/dev/background_contact/collisions.html b/dev/background_contact/collisions.html index 1d7f05d9..15921a97 100644 --- a/dev/background_contact/collisions.html +++ b/dev/background_contact/collisions.html @@ -1,2 +1,2 @@ -Collisions · Dojo
Edit on GitHub
+Collisions · Dojo
Edit on GitHub
diff --git a/dev/background_contact/contact_models.html b/dev/background_contact/contact_models.html index 5f24b665..d6d4b674 100644 --- a/dev/background_contact/contact_models.html +++ b/dev/background_contact/contact_models.html @@ -1,2 +1,2 @@ -Overview · Dojo
Edit on GitHub

Overview

Impact and friction behaviors are modeled, along with the system’s dynamics, as a nonlinear complementarity problem (NCP). This model simulates hard contact without requiring system-specific solver tuning. Additionally, contacts between a system and the environment are treated as a single graph node connected to a rigid body (see below). As a result, the simulator retains efficient linear-time complexity for open-chain mechanical systems.

graph

Three contact models are implemented in Dojo:

nonlinear_cone

  • LinearContact enforces contact with a linearized cone of friction (pyramidal cone).

linearized_cone

All 3 of these contact models implement hard contact i.e., no interpenetration. This means that for both the nonlinear and linearized cones, we concatenate the constraints resulting from friction with the impact constraints.

Implementation

Dojo currently supports contact constraints occurring between a sphere and the ground i.e., a horizontal half-space of altitude 0.0. Each spherical contact is attached to a single Body.

To create a new point of contact, we need to define:

  • the Body to which the contact constraint is attached
  • radius of the sphere defining the spherical contact
  • coefficient of friction (except for ImpactContact)

Example

For the Quadruped model shown in the picture below, we defined 12 contacts spheres show in red:

  • 4 for the feet,
  • 4 for the knees,
  • 4 for for the hips.

quadruped_contact

+Overview · Dojo
Edit on GitHub

Overview

Impact and friction behaviors are modeled, along with the system’s dynamics, as a nonlinear complementarity problem (NCP). This model simulates hard contact without requiring system-specific solver tuning. Additionally, contacts between a system and the environment are treated as a single graph node connected to a rigid body (see below). As a result, the simulator retains efficient linear-time complexity for open-chain mechanical systems.

graph

Three contact models are implemented in Dojo:

nonlinear_cone

  • LinearContact enforces contact with a linearized cone of friction (pyramidal cone).

linearized_cone

All 3 of these contact models implement hard contact i.e., no interpenetration. This means that for both the nonlinear and linearized cones, we concatenate the constraints resulting from friction with the impact constraints.

Implementation

Dojo currently supports contact constraints occurring between a sphere and the ground i.e., a horizontal half-space of altitude 0.0. Each spherical contact is attached to a single Body.

To create a new point of contact, we need to define:

  • the Body to which the contact constraint is attached
  • radius of the sphere defining the spherical contact
  • coefficient of friction (except for ImpactContact)

Example

For the Quadruped model shown in the picture below, we defined 12 contacts spheres show in red:

  • 4 for the feet,
  • 4 for the knees,
  • 4 for for the hips.

quadruped_contact

diff --git a/dev/background_contact/impact.html b/dev/background_contact/impact.html index d062faee..f0c2d629 100644 --- a/dev/background_contact/impact.html +++ b/dev/background_contact/impact.html @@ -1,2 +1,2 @@ -Impact · Dojo
Edit on GitHub

Impact

Mathematical Model

We model hard contact via constraints on the system’s configuration and the applied contact forces. For a system with $P$ contact points, we define a signed-distance function,

\[\phi : \mathbf{Z} \rightarrow \mathbf{R}^P\]

subject to the following element-wise constraint:

\[ϕ(z) > 0,\]

Impact forces with magnitude $\gamma \in \mathbf{R}^P$ are applied to the bodies’ contact points in the direction of their surface normals in order to enforce (5) and prevent interpenetration. A non-negative constraint,

\[\gamma \geq 0,\]

enforces physical behavior that impulses are repulsive (e.g., the floor does not attract bodies), and the complementarity condition,

\[\gamma \circ \phi(z) = 0,\]

where $\circ$ is an element-wise product operator, enforces zero force if the body is not in contact and allows non-zero force during contact.

+Impact · Dojo
Edit on GitHub

Impact

Mathematical Model

We model hard contact via constraints on the system’s configuration and the applied contact forces. For a system with $P$ contact points, we define a signed-distance function,

\[\phi : \mathbf{Z} \rightarrow \mathbf{R}^P\]

subject to the following element-wise constraint:

\[ϕ(z) > 0,\]

Impact forces with magnitude $\gamma \in \mathbf{R}^P$ are applied to the bodies’ contact points in the direction of their surface normals in order to enforce (5) and prevent interpenetration. A non-negative constraint,

\[\gamma \geq 0,\]

enforces physical behavior that impulses are repulsive (e.g., the floor does not attract bodies), and the complementarity condition,

\[\gamma \circ \phi(z) = 0,\]

where $\circ$ is an element-wise product operator, enforces zero force if the body is not in contact and allows non-zero force during contact.

diff --git a/dev/background_contact/linearized_friction.html b/dev/background_contact/linearized_friction.html index 39591aa1..8bc8bc8e 100644 --- a/dev/background_contact/linearized_friction.html +++ b/dev/background_contact/linearized_friction.html @@ -12,4 +12,4 @@ \psi \cdot (\mu \gamma - \beta^T \textbf{1}) &= 0, \\ \beta \circ \eta &= 0, \\ \beta, \psi, \eta &\geq 0, -\end{align*}\]

where $\psi \in \mathbf{R}$ and $\eta \in \mathbf{R}^{4}$ are the dual variables associated with the friction cone and positivity constraints, respectively, and $\textbf{1}$ is a vector of ones.

+\end{align*}\]

where $\psi \in \mathbf{R}$ and $\eta \in \mathbf{R}^{4}$ are the dual variables associated with the friction cone and positivity constraints, respectively, and $\textbf{1}$ is a vector of ones.

diff --git a/dev/background_contact/nonlinear_friction.html b/dev/background_contact/nonlinear_friction.html index 641e935f..aca579a7 100644 --- a/dev/background_contact/nonlinear_friction.html +++ b/dev/background_contact/nonlinear_friction.html @@ -18,4 +18,4 @@ & \quad \beta^{(i)}_{(1)} - \mu^{(i)} \gamma^{(i)} = 0, && \quad i = 1, \dots, P,\\ & \quad \gamma, s \geq 0,\\ & \quad \beta^{(i)}, \eta^{(i)} \in \mathcal{Q}^3, && \quad i = 1, \dots, P, -\end{align*}\]

where $u \in \mathbf{R}^m$ is the control input at the current time step, $\lambda = (\beta^{(1)}_{(2:3)}, \gamma^{(1)}, \dots, \beta^{(P)}_{(2:3)}, \gamma^{(P)}) \in \mathbf{\Lambda}$ is the concatenation of impact and friction impulses, $B : \mathbf{Z} \rightarrow \mathbf{R}^{6N \times m}$ is the input Jacobian mapping control inputs into maximal coordinates, $C : \mathbf{Z} \rightarrow \mathbf{R}^{\text{dim}(\mathbf{\Lambda}) \times 6N}$ is a contact Jacobian mapping between maximal coordinates and contact surfaces, $s \in \mathbf{R}^P$ is a slack variable introduced for convenience, and $v^{(i)} : \mathbf{Z} \times \mathbf{Z} \rightarrow \mathbf{R}^2$ is the tangential velocity at contact point $i$. Joint limits and internal friction are readily incorporated into this problem formulation.

+\end{align*}\]

where $u \in \mathbf{R}^m$ is the control input at the current time step, $\lambda = (\beta^{(1)}_{(2:3)}, \gamma^{(1)}, \dots, \beta^{(P)}_{(2:3)}, \gamma^{(P)}) \in \mathbf{\Lambda}$ is the concatenation of impact and friction impulses, $B : \mathbf{Z} \rightarrow \mathbf{R}^{6N \times m}$ is the input Jacobian mapping control inputs into maximal coordinates, $C : \mathbf{Z} \rightarrow \mathbf{R}^{\text{dim}(\mathbf{\Lambda}) \times 6N}$ is a contact Jacobian mapping between maximal coordinates and contact surfaces, $s \in \mathbf{R}^P$ is a slack variable introduced for convenience, and $v^{(i)} : \mathbf{Z} \times \mathbf{Z} \rightarrow \mathbf{R}^2$ is the tangential velocity at contact point $i$. Joint limits and internal friction are readily incorporated into this problem formulation.

diff --git a/dev/background_representations/gradients.html b/dev/background_representations/gradients.html index 976aaeae..cf73c753 100644 --- a/dev/background_representations/gradients.html +++ b/dev/background_representations/gradients.html @@ -1,2 +1,2 @@ -Background on Gradients · Dojo
Edit on GitHub

Background on Gradients

Implicit Function Theorem

An implicit function, $r : \mathbf{R}^{n_w} \times \mathbf{R}^{n_\theta} \rightarrow \mathbf{R}^{n_w}$, is defined as

\[r(w^*; \theta) = 0,\]

for solution $w^* \in \mathbf{R}^{n_w}$ and problem data $\theta \in \mathbf{R}^{n_\theta}$. At a solution point of the above equation the sensitivities of the solution with respect to the problem data, i.e., $\partial w^* / \partial \theta$, can be computed under certain conditions. First, we approximate the above equation to first order:

\[ \frac{\partial r}{\partial w} \delta w + \frac{\partial r}{\partial \theta} \delta \theta = 0,\]

and then solve for the relationship:

\[\frac{\partial w^*}{\partial \theta} = -\Big(\frac{\partial r}{\partial w}\Big)^{-1} \frac{\partial r}{\partial \theta}. \quad \quad(1)\]

In case $(\partial r / \partial w)^{-1}$ is not well defined, (e.g., not full rank) we can either apply regularization or approximately solve (1) with, for example, a least-squares approach.

Often, Newton's method is employed to find solutions to the implicit equation and custom linear-system solvers can efficiently compute search directions for this purpose. Importantly, the factorization of $\partial r / \partial w$ used to find a solution can be reused to compute (1) at very low computational cost using only back-substitution. Additionally, each element of the problem-data sensitivity can be computed in parallel.

Dojo's Gradient

At a solution point, $w^*(\theta, \kappa)$, the sensitivity of the solution with respect to the problem data, i.e., $\partial w^* / \partial \theta$, is efficiently computed using the implicit-function theorem (1) to differentiate through the solver's residual.

The efficient linear-system solver used for the simulator, as well as the computation and factorization of $\partial r / \partial w$, is used to compute the sensitivities for each element of the problem data. Calculations over the individual columns of $\partial r / \partial \theta$ can be performed in parallel.

The problem data for each simulation step include: the previous and current configurations, control input, and additional terms like the time step, friction coefficients, and parameters of each body. The chain rule is utilized to compute gradients with respect to the finite-difference velocities as well as transformations between minimal- and maximal-coordinate representations.

In many robotics scenarios, we are interested in gradient information through contact events. Instead of computing gradients for hard contact with zero or very small central-path parameters, we use a relaxed value from intermediate solutions $w^*(\theta, \kappa > 0)$ corresponding to a soft contact model. In practice, we find that these smooth gradients greatly improve the performance of gradient-based optimization methods.

Gradient Comparison

Gradient comparison between randomized smoothing and Dojo's smooth gradients. The dynamics for a box in the $XY$ plane that is resting on a flat surface and displaced an amount $\Delta$ by an input $F$ (top left). Its corresponding exact gradients are shown in black. Gradient bundles (right column) are computed using sampling schemes with varying covariances $\Sigma$ and $500$ samples. Dojo's gradients (middle column) are computed for different values of $\kappa$, corresponding to the smoothness of the contact model. Compared to the 500-sample gradient bundle, Dojo's gradients are not noisy and are a 100 times faster to compute with a single worker.

+Background on Gradients · Dojo
Edit on GitHub

Background on Gradients

Implicit Function Theorem

An implicit function, $r : \mathbf{R}^{n_w} \times \mathbf{R}^{n_\theta} \rightarrow \mathbf{R}^{n_w}$, is defined as

\[r(w^*; \theta) = 0,\]

for solution $w^* \in \mathbf{R}^{n_w}$ and problem data $\theta \in \mathbf{R}^{n_\theta}$. At a solution point of the above equation the sensitivities of the solution with respect to the problem data, i.e., $\partial w^* / \partial \theta$, can be computed under certain conditions. First, we approximate the above equation to first order:

\[ \frac{\partial r}{\partial w} \delta w + \frac{\partial r}{\partial \theta} \delta \theta = 0,\]

and then solve for the relationship:

\[\frac{\partial w^*}{\partial \theta} = -\Big(\frac{\partial r}{\partial w}\Big)^{-1} \frac{\partial r}{\partial \theta}. \quad \quad(1)\]

In case $(\partial r / \partial w)^{-1}$ is not well defined, (e.g., not full rank) we can either apply regularization or approximately solve (1) with, for example, a least-squares approach.

Often, Newton's method is employed to find solutions to the implicit equation and custom linear-system solvers can efficiently compute search directions for this purpose. Importantly, the factorization of $\partial r / \partial w$ used to find a solution can be reused to compute (1) at very low computational cost using only back-substitution. Additionally, each element of the problem-data sensitivity can be computed in parallel.

Dojo's Gradient

At a solution point, $w^*(\theta, \kappa)$, the sensitivity of the solution with respect to the problem data, i.e., $\partial w^* / \partial \theta$, is efficiently computed using the implicit-function theorem (1) to differentiate through the solver's residual.

The efficient linear-system solver used for the simulator, as well as the computation and factorization of $\partial r / \partial w$, is used to compute the sensitivities for each element of the problem data. Calculations over the individual columns of $\partial r / \partial \theta$ can be performed in parallel.

The problem data for each simulation step include: the previous and current configurations, control input, and additional terms like the time step, friction coefficients, and parameters of each body. The chain rule is utilized to compute gradients with respect to the finite-difference velocities as well as transformations between minimal- and maximal-coordinate representations.

In many robotics scenarios, we are interested in gradient information through contact events. Instead of computing gradients for hard contact with zero or very small central-path parameters, we use a relaxed value from intermediate solutions $w^*(\theta, \kappa > 0)$ corresponding to a soft contact model. In practice, we find that these smooth gradients greatly improve the performance of gradient-based optimization methods.

Gradient Comparison

Gradient comparison between randomized smoothing and Dojo's smooth gradients. The dynamics for a box in the $XY$ plane that is resting on a flat surface and displaced an amount $\Delta$ by an input $F$ (top left). Its corresponding exact gradients are shown in black. Gradient bundles (right column) are computed using sampling schemes with varying covariances $\Sigma$ and $500$ samples. Dojo's gradients (middle column) are computed for different values of $\kappa$, corresponding to the smoothness of the contact model. Compared to the 500-sample gradient bundle, Dojo's gradients are not noisy and are a 100 times faster to compute with a single worker.

diff --git a/dev/background_representations/maximal_representation.html b/dev/background_representations/maximal_representation.html index 305fed29..8ac591a8 100644 --- a/dev/background_representations/maximal_representation.html +++ b/dev/background_representations/maximal_representation.html @@ -1,2 +1,2 @@ -Maximal Coordinates · Dojo
Edit on GitHub

Maximal Coordinates

The $i$-th body in a mechanism with $N$ bodies has state:

\[z^{(i)} = (x^{(i)}, v^{(i)}, q^{(i)}, \omega^{(i)}) \in \mathbf{R}^3 \times \mathbf{R}^3 \times \mathbf{H} \times \mathbf{R}^3,\]

represented in maximal coordinates, where $\mathbf{H}$ is the space of unit quaternions.

  • $x$: position in world frame
  • $v$: linear velocity in the world frame
  • $q$: orientation represented as a unit quaternion
  • $\omega$: angular velocity in the body frame

The mechanism state:

\[z = (z^{(1)}, \dots, z^{(N)}).\]

is the concatentation of all body states.

+Maximal Coordinates · Dojo
Edit on GitHub

Maximal Coordinates

The $i$-th body in a mechanism with $N$ bodies has state:

\[z^{(i)} = (x^{(i)}, v^{(i)}, q^{(i)}, \omega^{(i)}) \in \mathbf{R}^3 \times \mathbf{R}^3 \times \mathbf{H} \times \mathbf{R}^3,\]

represented in maximal coordinates, where $\mathbf{H}$ is the space of unit quaternions.

  • $x$: position in world frame
  • $v$: linear velocity in the world frame
  • $q$: orientation represented as a unit quaternion
  • $\omega$: angular velocity in the body frame

The mechanism state:

\[z = (z^{(1)}, \dots, z^{(N)}).\]

is the concatentation of all body states.

diff --git a/dev/background_representations/minimal_representation.html b/dev/background_representations/minimal_representation.html index 637e1e7a..dd739b9c 100644 --- a/dev/background_representations/minimal_representation.html +++ b/dev/background_representations/minimal_representation.html @@ -1,2 +1,2 @@ -Minimal Coordinates · Dojo
Edit on GitHub

Minimal Coordinates

Dojo simulates systems in maximal coordinates.

For a mechanism with $M$ joints and $N$ bodies, the maximal representation $z$ can be efficiently converted to minimal coordinates:

\[y = (y^{(1)}, \dots, y^{(M)}) \leftarrow z = (z^{(1)}, \dots, z^{(N)}),\]

where $y^{(j)}$ depends on the degree and type of joint. Note: this minimal representation does not stack coordinates followed by velocities, which is a common convention; instead, coordinates and velocities are grouped by joint.

Each minimal state comprises:

\[y = (p_{\text{translational}}, p_{\text{rotational}}, w_{\text{translational}}, w_{\text{rotational}})\]

coordinates $p$ and velocities $w$ for both translational and rotational degrees of freedom.

In the case of a floating-base joint, the minimal-representation orientation is converted to modified Rodrigues parameters from a unit quaternion.

+Minimal Coordinates · Dojo
Edit on GitHub

Minimal Coordinates

Dojo simulates systems in maximal coordinates.

For a mechanism with $M$ joints and $N$ bodies, the maximal representation $z$ can be efficiently converted to minimal coordinates:

\[y = (y^{(1)}, \dots, y^{(M)}) \leftarrow z = (z^{(1)}, \dots, z^{(N)}),\]

where $y^{(j)}$ depends on the degree and type of joint. Note: this minimal representation does not stack coordinates followed by velocities, which is a common convention; instead, coordinates and velocities are grouped by joint.

Each minimal state comprises:

\[y = (p_{\text{translational}}, p_{\text{rotational}}, w_{\text{translational}}, w_{\text{rotational}})\]

coordinates $p$ and velocities $w$ for both translational and rotational degrees of freedom.

In the case of a floating-base joint, the minimal-representation orientation is converted to modified Rodrigues parameters from a unit quaternion.

diff --git a/dev/background_solver/interior_point.html b/dev/background_solver/interior_point.html index 5038d6d1..213fbe5c 100644 --- a/dev/background_solver/interior_point.html +++ b/dev/background_solver/interior_point.html @@ -4,4 +4,4 @@ \text{subject to} & \quad c(x, y, z; \theta) = 0, \\ & \quad y^{(i)} \circ z^{(i)} = \kappa \mathbf{e}, && \quad i = 1,\dots,n, \\ & \quad y^{(i)}, z^{(i)} \in \mathcal{K}, && \quad i = 1,\dots, n, -\end{align*}\]

with decision variables $x \in \mathbf{R}^k$ and $y, z \in \mathbf{R}^m$, equality-constraint set $c : \mathbf{R}^k \times \mathbf{R}^m \times \mathbf{R}^m \times \mathbf{R}^l \rightarrow \mathbf{R}^h$, problem data $\theta \in \mathbf{R}^l$; and where $\mathcal{K}$ is the Cartesian product of $n$ total positive-orthant and second-order cones. The variables are partitioned: $x = (x^{(1)}, \dots, x^{(p)})$, where $i = 1$ are Euclidean variables and $i = 2, \dots, p$ are each quaternion variables; and $y = (y^{(1)}, \dots, y^{(n)})$, $z = (z^{(1)}, \dots, z^{(n)})$, where $j = 1$ is the positive-orthant and the remaining $j = 2, \dots, n$ are second-order cones. For convenience, we denote $w = (x, y, z)$.

The algorithm aims to satisfy a sequence of relaxed problems with $\kappa > 0$ and $\kappa \rightarrow 0$ in order to reliably converge to a solution of the original problem (i.e., $\kappa = 0$). This continuation approach helps avoid premature ill-conditioning and is the basis for numerous convex and non-convex general-purpose interior-point solvers.

Violation metrics:

Two metrics are used to measure progress: The constraint violation,

\[r_{\text{vio}} = \| c(w; \theta) \|_{\infty},\]

and complementarity violation,

\[b_{\text{vio}} = {\text{max}}_i \{\| y^{(i)} \circ z^{(i)} \|_{\infty}\}.\]

The NCP is considered solved when $r_{\text{vio}} < r_{\text{tol}}$ and $b_{\text{vio}} < b_{\text{tol}}$.

solver options

Both r_tol and b_tol are options that can easily be accessed and modified via SolverOptions.

Newton Steps

The main loop of the solver performs Newton's method on the equality-constraint set $c$ and the bilinear constraints. The solver typically converges in about 10 iterations.

solver options

The maximal number of Newton's iterations max_iter can be set via SolverOptions.

Newton's method provides a search direction, then we perform a line search along this direction to determine the step length $\alpha$. We use a backtracking line search that accepts the step whenever it decreases $c_{\text{vio}}$ or $b_{\text{vio}}$. The line search starts with a step $\alpha=1$, if the step acceptance conditions are not met the step is decreased geometrically: $\alpha \leftarrow s \cdot \alpha$. The line search takes at most max_ls backtracking steps.

solver options

The scaling parameter $s$ is called ls_scale and the maximum number of line search iteration max_ls can be set via SolverOptions.

+\end{align*}\]

with decision variables $x \in \mathbf{R}^k$ and $y, z \in \mathbf{R}^m$, equality-constraint set $c : \mathbf{R}^k \times \mathbf{R}^m \times \mathbf{R}^m \times \mathbf{R}^l \rightarrow \mathbf{R}^h$, problem data $\theta \in \mathbf{R}^l$; and where $\mathcal{K}$ is the Cartesian product of $n$ total positive-orthant and second-order cones. The variables are partitioned: $x = (x^{(1)}, \dots, x^{(p)})$, where $i = 1$ are Euclidean variables and $i = 2, \dots, p$ are each quaternion variables; and $y = (y^{(1)}, \dots, y^{(n)})$, $z = (z^{(1)}, \dots, z^{(n)})$, where $j = 1$ is the positive-orthant and the remaining $j = 2, \dots, n$ are second-order cones. For convenience, we denote $w = (x, y, z)$.

The algorithm aims to satisfy a sequence of relaxed problems with $\kappa > 0$ and $\kappa \rightarrow 0$ in order to reliably converge to a solution of the original problem (i.e., $\kappa = 0$). This continuation approach helps avoid premature ill-conditioning and is the basis for numerous convex and non-convex general-purpose interior-point solvers.

Violation metrics:

Two metrics are used to measure progress: The constraint violation,

\[r_{\text{vio}} = \| c(w; \theta) \|_{\infty},\]

and complementarity violation,

\[b_{\text{vio}} = {\text{max}}_i \{\| y^{(i)} \circ z^{(i)} \|_{\infty}\}.\]

The NCP is considered solved when $r_{\text{vio}} < r_{\text{tol}}$ and $b_{\text{vio}} < b_{\text{tol}}$.

solver options

Both r_tol and b_tol are options that can easily be accessed and modified via SolverOptions.

Newton Steps

The main loop of the solver performs Newton's method on the equality-constraint set $c$ and the bilinear constraints. The solver typically converges in about 10 iterations.

solver options

The maximal number of Newton's iterations max_iter can be set via SolverOptions.

Newton's method provides a search direction, then we perform a line search along this direction to determine the step length $\alpha$. We use a backtracking line search that accepts the step whenever it decreases $c_{\text{vio}}$ or $b_{\text{vio}}$. The line search starts with a step $\alpha=1$, if the step acceptance conditions are not met the step is decreased geometrically: $\alpha \leftarrow s \cdot \alpha$. The line search takes at most max_ls backtracking steps.

solver options

The scaling parameter $s$ is called ls_scale and the maximum number of line search iteration max_ls can be set via SolverOptions.

diff --git a/dev/background_solver/solver_options.html b/dev/background_solver/solver_options.html index ed2d0636..97a7b3a4 100644 --- a/dev/background_solver/solver_options.html +++ b/dev/background_solver/solver_options.html @@ -1,2 +1,2 @@ -Solver Options · Dojo
Edit on GitHub

Solver Options

The solver has several options accessible via SolverOptions. Below is a list describing their effect on the solver's behavior, typical values, and if they need to be tuned by the user.

optiondefaultrangeeffecttuning
rtol$10^{-4}$$[10^{-6}, 10^{-2}]$larger leads to faster solve (usually takes the same value as btol)rarely
btol$10^{-4}$$[10^{-6}, 10^{-2}]$larger results in smoothed contact dynamics and faster solverarely
ls_scale$0.5$$[0.3, 0.8]$larger potentially increase step size at the cost of more residual evaluationsnever
max_ls$10$$[1, 25]$larger allows for taking smaller stepsnever
undercut$+\infty$$[2, +\infty]$larger is more robust but can generate stiffer gradientsrarely
no_progress_max$3$$[3, 5]$smaller will increase the undercut fasternever
no_progress_undercut$10$$[3, 100]$larger will increase the undercut fasternever
verbose$\text{false}$$\{\text{true}, \text{false}\}$printing the status of the solveroften
+Solver Options · Dojo
Edit on GitHub

Solver Options

The solver has several options accessible via SolverOptions. Below is a list describing their effect on the solver's behavior, typical values, and if they need to be tuned by the user.

optiondefaultrangeeffecttuning
rtol$10^{-4}$$[10^{-6}, 10^{-2}]$larger leads to faster solve (usually takes the same value as btol)rarely
btol$10^{-4}$$[10^{-6}, 10^{-2}]$larger results in smoothed contact dynamics and faster solverarely
ls_scale$0.5$$[0.3, 0.8]$larger potentially increase step size at the cost of more residual evaluationsnever
max_ls$10$$[1, 25]$larger allows for taking smaller stepsnever
undercut$+\infty$$[2, +\infty]$larger is more robust but can generate stiffer gradientsrarely
no_progress_max$3$$[3, 5]$smaller will increase the undercut fasternever
no_progress_undercut$10$$[3, 100]$larger will increase the undercut fasternever
verbose$\text{false}$$\{\text{true}, \text{false}\}$printing the status of the solveroften
diff --git a/dev/citing.html b/dev/citing.html index 77048a4f..3a2e6ff9 100644 --- a/dev/citing.html +++ b/dev/citing.html @@ -3,4 +3,4 @@ title={Dojo: {A} {D}ifferentiable {S}imulator for {R}obotics}, author={Howell, Taylor A. and Le Cleac'h, Simon and Bruedigam, Jan and Kolter, J. Zico and Schwager, Mac and Manchester, Zachary}, year={2022} -}

A preprint can be downloaded from arXiv.

+}

A preprint can be downloaded from arXiv.

diff --git a/dev/contributing.html b/dev/contributing.html index 3c8d1870..1266b1f2 100644 --- a/dev/contributing.html +++ b/dev/contributing.html @@ -1,2 +1,2 @@ -Contributing · Dojo
Edit on GitHub

Contributing

Contributions are always welcome!

  • If you want to contribute features, bug fixes, etc, please take a look at our Code Style Guide below
  • Please report any issues and bugs that you encounter in Issues
  • As an open source project we are also interested in any projects and applications that use Dojo. Please let us know via email to: thowell@stanford.edu or simonlc@stanford.edu

Potentially Useful Contributions

Here are a list of current to-do's that would make awesome contributions:

  • reduce allocations by using StaticArrays and https://docs.julialang.org/en/v1/manual/profile/#Line-by-Line-Allocation-Tracking
  • improved parsing of URDF files
    • joint limits, friction coefficients
  • improved collision detection
    • body-to-body contact
    • general convex shapes
    • curved surfaces
  • GPU support
  • nice REPL interface
  • interactive GUI

Code Style Guide

The code in this repository follows the naming and style conventions of Julia Base with a few modifications. This style guide is heavily "inspired" by the guides of John Myles White, JuMP, and COSMO

Formatting

  • Use one tab when indenting a new block (except module)

  • Use spaces between operators, except for ^, ', and :

  • Use single space after commas and semicolons

  • Don't use spaces around parentheses, or braces

Bad: f(x,y) = [5*sin(x+y);y'] Good: f(x, y) = [5 * sin(x + y); y']

  • Use spacing with keyword arguments

Bad: foo(x::Float; y::Integer = 1) Good: foo(x::Float; y::Integer=1)

  • Don't parenthesize conditions

Bad: if (a == b) Good: if a == b

Naming

  • Modules and Type names use capitalization and camel case, e.g. module LinearAlgebra, struct ConvexSets.
  • Functions are lowercase and use underscores to separate words, e.g. has_key(x), is_valid(y).
  • Normal variables are lowercase and use underscores like functions, e.g. convex_set
  • Constants are uppercase, e.g. const MY_CONSTANT
  • Always append ! to names of functions that modify their arguments.
  • Function arguments that are mutated come first. Otherwise follow the rules layed out in Julia Base Argument ordering
  • Files are named like functions, e.g. my_new_file.jl

Syntax

  • Use 1.0 instead of 1.
+Contributing · Dojo
Edit on GitHub

Contributing

Contributions are always welcome!

  • If you want to contribute features, bug fixes, etc, please take a look at our Code Style Guide below
  • Please report any issues and bugs that you encounter in Issues
  • As an open source project we are also interested in any projects and applications that use Dojo. Please let us know via email to: thowell@stanford.edu or simonlc@stanford.edu

Potentially Useful Contributions

Here are a list of current to-do's that would make awesome contributions:

  • reduce allocations by using StaticArrays and https://docs.julialang.org/en/v1/manual/profile/#Line-by-Line-Allocation-Tracking
  • improved parsing of URDF files
    • joint limits, friction coefficients
  • improved collision detection
    • body-to-body contact
    • general convex shapes
    • curved surfaces
  • GPU support
  • nice REPL interface
  • interactive GUI

Code Style Guide

The code in this repository follows the naming and style conventions of Julia Base with a few modifications. This style guide is heavily "inspired" by the guides of John Myles White, JuMP, and COSMO

Formatting

  • Use one tab when indenting a new block (except module)

  • Use spaces between operators, except for ^, ', and :

  • Use single space after commas and semicolons

  • Don't use spaces around parentheses, or braces

Bad: f(x,y) = [5*sin(x+y);y'] Good: f(x, y) = [5 * sin(x + y); y']

  • Use spacing with keyword arguments

Bad: foo(x::Float; y::Integer = 1) Good: foo(x::Float; y::Integer=1)

  • Don't parenthesize conditions

Bad: if (a == b) Good: if a == b

Naming

  • Modules and Type names use capitalization and camel case, e.g. module LinearAlgebra, struct ConvexSets.
  • Functions are lowercase and use underscores to separate words, e.g. has_key(x), is_valid(y).
  • Normal variables are lowercase and use underscores like functions, e.g. convex_set
  • Constants are uppercase, e.g. const MY_CONSTANT
  • Always append ! to names of functions that modify their arguments.
  • Function arguments that are mutated come first. Otherwise follow the rules layed out in Julia Base Argument ordering
  • Files are named like functions, e.g. my_new_file.jl

Syntax

  • Use 1.0 instead of 1.
diff --git a/dev/creating_mechanism/environment_existing.html b/dev/creating_mechanism/environment_existing.html index 7c2b6dab..df66afce 100644 --- a/dev/creating_mechanism/environment_existing.html +++ b/dev/creating_mechanism/environment_existing.html @@ -4,4 +4,4 @@ using DojoEnvironments # ### Get environment (check DojoEnvironment/environments files for kwargs) -environment = get_environment(:pendulum; timestep=0.01, horizon=200) +environment = get_environment(:pendulum; timestep=0.01, horizon=200) diff --git a/dev/creating_mechanism/mechanism_directly.html b/dev/creating_mechanism/mechanism_directly.html index 7393e75e..84f464ce 100644 --- a/dev/creating_mechanism/mechanism_directly.html +++ b/dev/creating_mechanism/mechanism_directly.html @@ -15,4 +15,4 @@ joint = JointConstraint(Revolute(origin, body, rotation_axis; child_vertex=connection)) # ### Construct Mechanism -mechanism = Mechanism(origin, [body], [joint]) +mechanism = Mechanism(origin, [body], [joint]) diff --git a/dev/creating_mechanism/mechanism_existing.html b/dev/creating_mechanism/mechanism_existing.html index c750bbfd..d0d3cbfb 100644 --- a/dev/creating_mechanism/mechanism_existing.html +++ b/dev/creating_mechanism/mechanism_existing.html @@ -4,4 +4,4 @@ using DojoEnvironments # ### Get mechanism (check DojoEnvironment/mechanisms files for kwargs) -mechanism = get_mechanism(:pendulum; timestep=0.02, length=0.75) +mechanism = get_mechanism(:pendulum; timestep=0.02, length=0.75) diff --git a/dev/creating_mechanism/overview.html b/dev/creating_mechanism/overview.html index a0c32622..024a1440 100644 --- a/dev/creating_mechanism/overview.html +++ b/dev/creating_mechanism/overview.html @@ -1,2 +1,2 @@ -Overview · Dojo
Edit on GitHub

Overview

There are three ways to to build and use mechanical systems in Dojo: Build it directly, use an existing mechanism, or use an existing environment. Directly-built and existing mechanism both result in a Mechanism, and using an existing mechanism is just for convenience. Creating an Environment can be useful for more advanced applications like reinforcement learning. We use the pendulum as a simple example for these three methods and later give two more detailed examples.

+Overview · Dojo
Edit on GitHub

Overview

There are three ways to to build and use mechanical systems in Dojo: Build it directly, use an existing mechanism, or use an existing environment. Directly-built and existing mechanism both result in a Mechanism, and using an existing mechanism is just for convenience. Creating an Environment can be useful for more advanced applications like reinforcement learning. We use the pendulum as a simple example for these three methods and later give two more detailed examples.

diff --git a/dev/creating_mechanism/quadruped.html b/dev/creating_mechanism/quadruped.html index 6e9988e7..1503ff2c 100644 --- a/dev/creating_mechanism/quadruped.html +++ b/dev/creating_mechanism/quadruped.html @@ -108,4 +108,4 @@ return end - + diff --git a/dev/creating_mechanism/tippetop.html b/dev/creating_mechanism/tippetop.html index 679b7a8e..c95f7788 100644 --- a/dev/creating_mechanism/tippetop.html +++ b/dev/creating_mechanism/tippetop.html @@ -80,4 +80,4 @@ [body_position; Dojo.rotation_vector(body_orientation)]) set_minimal_velocities!(mechanism, floating_joint, [body_linear_velocity; body_angular_velocity]) -end +end diff --git a/dev/creating_simulation/define_controller.html b/dev/creating_simulation/define_controller.html index 1ab37c0a..9fb2b138 100644 --- a/dev/creating_simulation/define_controller.html +++ b/dev/creating_simulation/define_controller.html @@ -42,4 +42,4 @@ # ### Visualize vis = visualize(mechanism, storage) -render(vis) +render(vis) diff --git a/dev/creating_simulation/define_simulation.html b/dev/creating_simulation/define_simulation.html index bb16f5a7..d80b0e64 100644 --- a/dev/creating_simulation/define_simulation.html +++ b/dev/creating_simulation/define_simulation.html @@ -14,4 +14,4 @@ # ### Visualize mechanism vis = visualize(mechanism, storage) -render(vis)

And voila! You should see something like this;

+render(vis)

And voila! You should see something like this;

diff --git a/dev/creating_simulation/simulation_with_gradients.html b/dev/creating_simulation/simulation_with_gradients.html index e37130e9..72a1ee77 100644 --- a/dev/creating_simulation/simulation_with_gradients.html +++ b/dev/creating_simulation/simulation_with_gradients.html @@ -36,4 +36,4 @@ # ### Visualize vis = visualize(mechanism, storage) -render(vis) +render(vis) diff --git a/dev/environments/overview.html b/dev/environments/overview.html index 22366baf..a3bf1caf 100644 --- a/dev/environments/overview.html +++ b/dev/environments/overview.html @@ -1,2 +1,2 @@ -Overview · Dojo
Edit on GitHub

Overview

You can use Environments to interface Dojo to other packages, such as ReinforcementLearning. Due to current changes in the ReinforcementLearning package, we will provide an updated documentation once the changes are done. However, an experimental implementation of training the cartpole with ReinforcementLearning is provided in the examples.

+Overview · Dojo
Edit on GitHub

Overview

You can use Environments to interface Dojo to other packages, such as ReinforcementLearning. Due to current changes in the ReinforcementLearning package, we will provide an updated documentation once the changes are done. However, an experimental implementation of training the cartpole with ReinforcementLearning is provided in the examples.

diff --git a/dev/examples/reinforcement_learning.html b/dev/examples/reinforcement_learning.html index 7d68f02f..369d604e 100644 --- a/dev/examples/reinforcement_learning.html +++ b/dev/examples/reinforcement_learning.html @@ -1,2 +1,2 @@ -Reinforcement Learning · Dojo
Edit on GitHub

Reinforcement Learning

We have implemented a few learning examples.

Ant

Policy optimization is performed using the reinforcement-learning algorithm augmented random search (ARS) to optimize static linear policies for locomotion. The insect-like robot has rewards on forward velocity and survival and costs on control usage and contact forces.

Quadruped

A very basic random-sampling algorithm is used to find parameters for the periodic gait of a quadruped.

Cartpole

We have modified the cartpole example in the ReinforcementLearning package to use Dojo's dynamics. This allows us to combine advanced learning algorithms with accurate dynamics simulation.

+Reinforcement Learning · Dojo
Edit on GitHub

Reinforcement Learning

We have implemented a few learning examples.

Ant

Policy optimization is performed using the reinforcement-learning algorithm augmented random search (ARS) to optimize static linear policies for locomotion. The insect-like robot has rewards on forward velocity and survival and costs on control usage and contact forces.

Quadruped

A very basic random-sampling algorithm is used to find parameters for the periodic gait of a quadruped.

Cartpole

We have modified the cartpole example in the ReinforcementLearning package to use Dojo's dynamics. This allows us to combine advanced learning algorithms with accurate dynamics simulation.

diff --git a/dev/examples/simulation.html b/dev/examples/simulation.html index e61b9cc0..4c69d380 100644 --- a/dev/examples/simulation.html +++ b/dev/examples/simulation.html @@ -1,2 +1,2 @@ -Simulation · Dojo
Edit on GitHub

Simulation

Dojo can simulate a number of interesting physical behaviors. We include notebooks (generated upon installation) for the examples below.

Atlas Drop

The humanoid Atlas is dropped onto a flat surface. Dojo is able to simulate hard contact and prevent interpenetration of the robot's feet with the floor. In comparison, when the same system is simulated in MuJoCo, centimeters of interpenetration occur.

Friction Cone Comparison

Blocks are simulated with initial velocity before impacting and sliding along a flat surface. We compare Dojo's nonlinear cone (blue) with a linearized approximation (orange) and MuJoCo's default linear cone (magenta). The linearized cones exhibit drift due to the approximation, whereas Dojo's nonlinear cone produces the expected sliding behavior.

Dzhanibekov Effect

Dojo simulates the unstable rotational motion of a rigid body about its second primary moment of inertia. Using non-Euclidean optimization for quaternions enables continuous simulation of rotating objects without singularity issues.

Tippetop

A spinning object oscillates between up and down configurations as a result of its mass distribution.

+Simulation · Dojo
Edit on GitHub

Simulation

Dojo can simulate a number of interesting physical behaviors. We include notebooks (generated upon installation) for the examples below.

Atlas Drop

The humanoid Atlas is dropped onto a flat surface. Dojo is able to simulate hard contact and prevent interpenetration of the robot's feet with the floor. In comparison, when the same system is simulated in MuJoCo, centimeters of interpenetration occur.

Friction Cone Comparison

Blocks are simulated with initial velocity before impacting and sliding along a flat surface. We compare Dojo's nonlinear cone (blue) with a linearized approximation (orange) and MuJoCo's default linear cone (magenta). The linearized cones exhibit drift due to the approximation, whereas Dojo's nonlinear cone produces the expected sliding behavior.

Dzhanibekov Effect

Dojo simulates the unstable rotational motion of a rigid body about its second primary moment of inertia. Using non-Euclidean optimization for quaternions enables continuous simulation of rotating objects without singularity issues.

Tippetop

A spinning object oscillates between up and down configurations as a result of its mass distribution.

diff --git a/dev/examples/system_identification.html b/dev/examples/system_identification.html index 8a5ab6c6..11d45387 100644 --- a/dev/examples/system_identification.html +++ b/dev/examples/system_identification.html @@ -1,2 +1,2 @@ -System Identification · Dojo
Edit on GitHub

System Identification

A real-world dataset is used to learn the geometric and friction properties of a block being tossed onto a flat surface. Gradient-based optimization is employed to regress parameters and real-to-sim validation is performed. The ground truth system is shown in orange and the learned system in blue.

Geometry

The eight locations of the block's corners relative to its center of mass are learned.

Friction

A friction coefficient, describing a friction cone, is learned for all of the contact points.

Real-To-Sim

The system parameters are learned to within a $\pm 5 \%$ error from their ground-truth values. These parameters are then compared to the ground-truth system in simulation.

Learning

The cost function:

$\mathcal{L}(\mathcal{D}, \theta) = \sum_{Z \in \mathcal{D}} L(Z, \theta) = \sum_{Z \in \mathcal{D}} \frac{1}{2} ||s(z_{-}, z, \theta) - z_{+}||_W^2$,

is used where $\mathcal{D}$ is a dataset of trajectories containing tuples $(z_{-}, z, z_{+})$ of state sequences, with system parameters $\theta \in \mathbf{R}^p$, and where $s : \mathbf{Z} \times \mathbf{Z} \times \mathbf{R}^p \rightarrow \mathbf{Z}$ represents the simulator.

A quasi-Newton method is employed to optimize the cost function and uses gradients:

$\frac{\partial L}{\partial \theta} = {\frac{\partial s}{\partial \theta}}^T W \Big(s(z_{-}, z, \theta) - z_{+} \Big)$,

and the following Gauss-Newton approximation:

$\frac{\partial^2 L}{\partial \theta^2} \approx {\frac{\partial s}{\partial \theta}}^T W \frac{\partial s}{\partial \theta}$,

of the cost function Hessian, which only relies on Jacobians from Dojo.

+System Identification · Dojo
Edit on GitHub

System Identification

A real-world dataset is used to learn the geometric and friction properties of a block being tossed onto a flat surface. Gradient-based optimization is employed to regress parameters and real-to-sim validation is performed. The ground truth system is shown in orange and the learned system in blue.

Geometry

The eight locations of the block's corners relative to its center of mass are learned.

Friction

A friction coefficient, describing a friction cone, is learned for all of the contact points.

Real-To-Sim

The system parameters are learned to within a $\pm 5 \%$ error from their ground-truth values. These parameters are then compared to the ground-truth system in simulation.

Learning

The cost function:

$\mathcal{L}(\mathcal{D}, \theta) = \sum_{Z \in \mathcal{D}} L(Z, \theta) = \sum_{Z \in \mathcal{D}} \frac{1}{2} ||s(z_{-}, z, \theta) - z_{+}||_W^2$,

is used where $\mathcal{D}$ is a dataset of trajectories containing tuples $(z_{-}, z, z_{+})$ of state sequences, with system parameters $\theta \in \mathbf{R}^p$, and where $s : \mathbf{Z} \times \mathbf{Z} \times \mathbf{R}^p \rightarrow \mathbf{Z}$ represents the simulator.

A quasi-Newton method is employed to optimize the cost function and uses gradients:

$\frac{\partial L}{\partial \theta} = {\frac{\partial s}{\partial \theta}}^T W \Big(s(z_{-}, z, \theta) - z_{+} \Big)$,

and the following Gauss-Newton approximation:

$\frac{\partial^2 L}{\partial \theta^2} \approx {\frac{\partial s}{\partial \theta}}^T W \frac{\partial s}{\partial \theta}$,

of the cost function Hessian, which only relies on Jacobians from Dojo.

diff --git a/dev/examples/trajectory_optimization.html b/dev/examples/trajectory_optimization.html index 07536634..3b9f1c31 100644 --- a/dev/examples/trajectory_optimization.html +++ b/dev/examples/trajectory_optimization.html @@ -1,2 +1,2 @@ -Trajectory Optimization · Dojo
Edit on GitHub

Trajectory Optimization

Info

The trajectory optimization examples are outdated and currently not available.

Dojo provides dynamics constraints and Jacobians in order to perform trajectory optimization using iterative LQR.

Quadruped

A Unitree A1 takes a number of forward steps. There are costs on a kinematic gait and control usage, as well as an augmented Lagrangian (i.e., soft) constraint on the the robot's final pose. The maximal representation is converted to a minimal one for optimization. Additionally, slack controls are utilized early on to aid the optimizer before being driven to zero by a constraint to achieve a dynamically feasible trajectory.

Atlas

The Atlas v5 humanoid (sans arms) takes a number of forward steps. Similar to the quadruped example, there are costs on control effort and deviations from a kinematic plan, a minimal representation is utilized, and the optimizer is aided by slack controls.

Block

A block is moved to a goal location by applying forces to its center of mass. The optimizer is initialized with zero control and utilizes smooth gradients from Dojo to find a motion that overcomes friction to slide towards the goal.

Raibert Hopper

A hopping robot, inspired by the Raibert Hopper, is tasked with moving to a goal location. The optimizer finds a single hop trajectory to reach its goal pose.

Cartpole

This classic system is tasked with performing a swing-up. Examples are provided performing optimization with both maximal and minimal representations.

+Trajectory Optimization · Dojo
Edit on GitHub

Trajectory Optimization

Info

The trajectory optimization examples are outdated and currently not available.

Dojo provides dynamics constraints and Jacobians in order to perform trajectory optimization using iterative LQR.

Quadruped

A Unitree A1 takes a number of forward steps. There are costs on a kinematic gait and control usage, as well as an augmented Lagrangian (i.e., soft) constraint on the the robot's final pose. The maximal representation is converted to a minimal one for optimization. Additionally, slack controls are utilized early on to aid the optimizer before being driven to zero by a constraint to achieve a dynamically feasible trajectory.

Atlas

The Atlas v5 humanoid (sans arms) takes a number of forward steps. Similar to the quadruped example, there are costs on control effort and deviations from a kinematic plan, a minimal representation is utilized, and the optimizer is aided by slack controls.

Block

A block is moved to a goal location by applying forces to its center of mass. The optimizer is initialized with zero control and utilizes smooth gradients from Dojo to find a motion that overcomes friction to slide towards the goal.

Raibert Hopper

A hopping robot, inspired by the Raibert Hopper, is tasked with moving to a goal location. The optimizer finds a single hop trajectory to reach its goal pose.

Cartpole

This classic system is tasked with performing a swing-up. Examples are provided performing optimization with both maximal and minimal representations.

diff --git a/dev/index.html b/dev/index.html index 1d62e6e4..15700b35 100644 --- a/dev/index.html +++ b/dev/index.html @@ -1,2 +1,2 @@ -Get Started · Dojo
Edit on GitHub

Get Started

Dojo is a differentiable simulator for robotics, prioritizing accurate physics and useful gradients. The simulator is written in pure Julia in order to be both performant and easy to use.

Features

  • Maximal-Coordinates Representation: Fast and efficient conversion between maximal and minimal representations
  • Smooth Gradients: Simulation with hard contact and useful gradients through contact events
  • Open Source: Code is available on GitHub and distributed under the MIT License
  • Python Interface: dojopy

Installation

Dojo can be installed using the Julia package manager for Julia v1.6 and higher. Inside the Julia REPL, type ] to enter the Pkg REPL mode then run

pkg> add Dojo

Credits

The following people are involved in the development of Dojo:

Primary Development

  • Simon Le Cleac'h (main development, contact modeling, interior-point solver, gradients)
  • Taylor Howell (main development, contact modeling, interior-point solver, gradients)
  • Jan Bruedigam (main development, maximal representation and graph-based solver)

Additional Contributions

Development by the Robotic Exploration Lab.

If this project is useful for your work please consider

Licence

Dojo.jl is licensed under the MIT License. For more details click here.

+Get Started · Dojo
Edit on GitHub

Get Started

Dojo is a differentiable simulator for robotics, prioritizing accurate physics and useful gradients. The simulator is written in pure Julia in order to be both performant and easy to use.

Features

  • Maximal-Coordinates Representation: Fast and efficient conversion between maximal and minimal representations
  • Smooth Gradients: Simulation with hard contact and useful gradients through contact events
  • Open Source: Code is available on GitHub and distributed under the MIT License
  • Python Interface: dojopy

Installation

Dojo can be installed using the Julia package manager for Julia v1.6 and higher. Inside the Julia REPL, type ] to enter the Pkg REPL mode then run

pkg> add Dojo

Credits

The following people are involved in the development of Dojo:

Primary Development

  • Simon Le Cleac'h (main development, contact modeling, interior-point solver, gradients)
  • Taylor Howell (main development, contact modeling, interior-point solver, gradients)
  • Jan Bruedigam (main development, maximal representation and graph-based solver)

Additional Contributions

Development by the Robotic Exploration Lab.

If this project is useful for your work please consider

Licence

Dojo.jl is licensed under the MIT License. For more details click here.

diff --git a/dev/search.html b/dev/search.html index 4f60acfb..a75a3d54 100644 --- a/dev/search.html +++ b/dev/search.html @@ -1,2 +1,2 @@ -Search · Dojo

Loading search...

    +Search · Dojo

    Loading search...