wpumacay / loco-bullet Goto Github PK

This might be related to #2 . There are some cases in which some bodies that are connected just get into a configuration that they cannot escape, meaning that one got into a out-of-range value for its constraint limit.

For example, for revolute joints with a range of [-100,100], if one body passes this limit, the constraint solver will try to send it back to the actual range, but if penetration was just right, then the object gets stuck. This usually happens when #2 happens, but in some other cases it also happens, when speeds are too high.

Possible-solution: use tip from the Bullet-user-manual, regarding the addition of collision margins to stabilize the collision detection.

The current implementation is buggy. If constraints are disabled all bodies should behave like free bodies, but they behave weirdly (floating like their collision shapes were not computed correctly)

Related to #6 : When the spherical-joints reset, the model just crashes (not the application) by making some of the bodies go away entirely (quite weird 🤔 ). Perhaps it's just a silly issue, as I've just given support for single-dof joints and free joints, but not spherical 🤦‍♂️ .

There's this key feature missing. Similar to the implementation done in the MuJoCo-based repo, we should be able to reset agents as we please (setting generalized coordinates to some initial values from a start distribution).

There are still some issues with some models, like humanoid. The non-stable simulation problems occur when some controls are applied to some specific joints, which makes the humanoid just fly away with huge velocities. For testing, run the test_agent_bt sample with the humanoid_symmetric.xml model (mjcf) and just swing back and forth the hip_y control (either right or left, both seem to give the same behavior).

We should have a way to kind of compare our usage of the btMultibody to the one provided in the examples/importers from the bullet repo, as theirs is more stable for some models like humanoid. This should be also extended to another implementation like the one in MuJoCo and other engines, such that we can ensure that we're using their articulated-body dynamic algorithms correctly.

Similar to the MuJoCo counterpart, we should have support to grab the required low-level information for proprioceptive sensor readings, like joint angles, velocities, relative positions, forces, etc.

Similar to the tests done for MuJoCo, we should have similar functionality that exposes the contacts from the bullet internal contact manifolds to the user. This is a key feature as early termination is required for most RL-tasks in locomotion, and we will need to check whether or not a body has touched the ground in order to terminate an episode.

Possible-solution: For an example of the low-level calls needed in Bullet, check the btCollisionWorld::debugDrawWorld method, in which they grab the manifolds and then the contacts. Still, we might need to wrap this for each agent such that when multiple agents are in the scenario, each one of them has the required information.