-
Notifications
You must be signed in to change notification settings - Fork 27
Home
Alexis DUBURCQ edited this page Nov 4, 2019
·
23 revisions
-
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.
- Note that the result of the simulation slightly differs on different computer even using
-
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
andlogviewer
--gepetto_walk
is broken becauseStateMachine.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 *
- No real-time logging on hard drive (only in CPU cache then RAM)
-
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
- 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 *
- 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. *
-
- Only "perfect" sensor data with noise/delay/jitter is available
- Error handling must be improved
-
- Old-fashioned message + return code
-