Skip to content
Alexis DUBURCQ edited this page Nov 4, 2019 · 23 revisions

Features

  • Highly and easily configurable:

    • Mechanical flexibility modelling
    • Sensor noise, jitter and delay modelling
    • Support external forces on frames (both impulse or via time-continuous callback)
    • Support user-defined internal dynamics
    • Support both finite time and time-continuous update period for each sensor and the controller independently
    • Model uncertainties regarding the kinematics and dynamics properties
  • Deterministic or non deterministic on demand but still PERFECTLY REPEATABLE

    • Note that the result of the simulation slightly differs on different computer even using dbash, as the version of Python libraries such as Numpy is host-dependent.
  • Designed for fast R&D prototyping of biped locomotion at Wandercraft :

    • Support step-by-step (optimized for performance) or one-shot simulation
    • Fully wrapped in Python. Designed for (almost) never have to recompile C++.
    • Add variables to the logger on-the-fly without compiling
      • Useful to debugging and dynamic plots updated over time (not implemented so far)
    • Can generated log data fully compatible with tsv and logviewer
      • --gepetto_walk is broken because StateMachine.State is undefined in Jiminy Engine
  • Fast Python Interface:

    • C++ / Python shared pointer to avoid boost converts back-and-forth
  • Very fast:

    • No real-time logging on hard drive (only in CPU cache then RAM)
      • The log can be exported in CSV or binary on demand afterwards
    • No real-time display by default
      • A Python class offering this functionality is available
      • Exo: 100ms for 1000 integration steps, corresponding to about 2s of flat foot walking *
      • Cartpole: 20ms for 1000 integration steps, corresponding to about 3s of simulation *
  • Highly parallelizable:

    • Thread safe (single process - single core)
    • Synchronous by default (a Python class offering asynchronous controller update is available)
    • No shared memory
    • NO WANDERBRAIN
  • Well-suited for Reinforcement Learning:

    • Fully compatible with Gym OpenAI and any libraries built on top of it

Drawbacks

  • Support only multiple point contact with the ground applied on frame
    • The ground is flat
    • No modelling of internal collisions contrary to Gazebo, ie for rotary joints
    • No collision between links
      • It should be enough for walking (both flat foot and foot rolling), turnaround ...etc *

Development status

  • Open-source Jiminy core: (mostly) stable
      • Few bugs still to fix regarding the flexibilities and joint limits constraints *
  • Open-source Gym/Jiminy interface: stable
  • Mock of a High-Level Controller: doing
  • Modelling must be improved:
    • Only "perfect" sensor data with noise/delay/jitter is available
        • No complementary filter for IMUs, no voltage to force converter for Force sensors... *
    • Only "perfect" Low-level controller:
        • No voltage-current to torque-velocity conversion. No response time. *
  • Error handling must be improved
      • Old-fashioned message + return code
Clone this wiki locally