Feature requests

[duburcqa]

• Backup visual and collision models in log files for standalone replay/plot and guaranteed persistence

  • Adapt the viewer here and there to check if mesh path exists and fallback to geometry loading if not.
  • Adapt log loader the create jiminy::Robot from pinocchio models instead of urdf path and mesh dirs here. Then remove irrelevant log constant here.
  • Add flag to log preloaded visual meshes for standalone replay

• Use discrete height map for the ground profile instead of symbolic function

  • Rely on the new capability of hpp-fcl to define heightmap geometries (it only supports regular grid) ([core] Take advantage of newly introduced HeightField in hppfcl #489). The discretization step should be an option for the user to play with. Simulation and rendering performance should be benchmark. Then rename in HeightField for consistency with hpp-fcl.
  • Wheel and sphere constraints should support uneven ground ([core] Modify wheel and sphere constraint to support ground profile #450)
  • Replace contact points by sphere of small radius (1mm) since FCL does not support points. Then add these spheres as proper collision geometries and completely remove the dedicated handling of contact points.
  • Modify display contact point method of the viewer to display all geometries that can possibly collide with something.
  • Ground profile should be not an option but rather a EngineMultiRobot method at this point, including discretization if symbolic, along with area (min/max x/y) and assertion check to stop the simulation is going out of bounds.
  • Allow to add static primitive shapes in the scene that can collide with the robots.
  • It would make it possible to backup it automatically with pinocchio model.

• Detect contact points instead of hard-coded candidate list

  • The 4 points in contact and further apart should be computed instead of only the deepest one, otherwise the contact would be unstable and physically wrong (wrong pressure force distribution and thereby friction). Mujoco proposes to apply small rotations of +/-1e-3 to the collision shapes in the directions orthogonal to the normal of contact. It provides up to 5 contact points that better span the intersection between shapes and also works with non-convex shapes (although the cost may be prohibitive).
  • Remove the capability to choose the number of contacts in options. It should be fixed to 5 for bodies, 1 for contact points.

• Enable generic collision between bodies

  • As for mujoco, exclude collision between successive parents and childs to prevent permanent collision.
  • Update HPP-FCL to v2 to enable Broad phase computation and thereby avoid checking all possible collision pairs manually.
  • Use pre-allocated distance / collision detection functors for better efficiency (see example)
  • Only display active contact points for bodies since the others make no sense. Use grey color for non active contact points.
  • Benchmark and speed-up update of markers (sending to backend), which is currently very slow.

• Add advanced transmission support ([core] Add support of motors to joints transmissions #428)

  • Including associated kinematic constraint

• (Optional) Improve efficiency of the contact solver by implementing space computation of (sDUiJt).T * (sDUiJt)

  • It requires adding a function that return the sparsity pattern of a abstract constraint, namely a std vector of segments (pairs [start, length]).

[duburcqa]

gym_jiminy profiling:

• 44%/TOT simulation (compute next state)
  • 5%/TOT computeExternalForces (python bindings)
  • 6%/TOT computeCommand
  • 2%/TOT "Project external forces from local cartesian space to joint space"
  • 4%/TOT C++ telemetry
  • 5%/TOT compute constraints
  • 9%/TOT compte force solving
• 33%/TOT python stuff (compute observation, reward, done)

Timing in bold could be reduced to zero. Speeding up the whole learning environment by about x2.

[duburcqa]

Up-to-date benchmark:

• 33% SolveBoxedForwardDynamics
  • 14% computeJMinvJt
• 20% computeCommand (python)
• 9% rnea
• 4% nonLinearEffects
• 4% computeAllExtraTerms
• 4% C++ telemetry
• 4% setSensorsData
• 3% computeForwardDynamics
• 3% basic python stuff
• 2% computeAllTerms

The maximum speed-up that can be expected is about 10%. To go further, it may be interesting to JIT rnea, nonLinearEffects, computeForwardDynamics, which may reduce their computation time by a factor 2.