Closed s-bl closed 4 years ago
Thanks for reporting this. Recreating the objects in the stage are needed to ensure a deterministic and reproducible trajectories after resetting the environment and also because we have some interventions which potentially can change the env structure (having more objects or deleting objects and so on). If you are trying to save the state of the environment without changing the environment structure, then this should be supported using get_state and set_state under causal_world. This is not entirely deterministic functions because a potential bug in pybullet (see https://github.com/bulletphysics/bullet3/issues/2982 ). Are you trying to get and set the state across different instances for planning using the true model?
The deviations come from the fact that pybullet saves the previous n contact points to calculate the next state, so even if you set everything to be the same it wont yield the same next state since the cached contact points are not the same. We addressed this as a pybullet issue in general since its a limitation we couldn't work around at the moment.
Hey,
thanks for the quick reply.
Are you trying to get and set the state across different instances for planning using the true model?
Exactly, that's why we can't use the in-memory save and load functionality of pybullet.
We addressed this as a pybullet issue in general since its a limitation we couldn't work around at the moment.
I see, good. We could reduce the deviations already quite a bit with the aforementioned changed. For the moment, we can live with the remaining small deviations.
We noticed that set_full_env_state of the stage is recreating the objects in the scene which will create a different physical state, so running the simulation from a reloaded state yields different results than reloading.
In case interventions should be applied on the fly it might be good to only change properties and not recreate objects all the time.
For our use case we only want to store and set states without changing the structure of the envs (no new objects, etc.). For that reason we tried to use stage.set_full_state/get_full_state pair of function instead of the full_env_state functions. These didn't worked out of the box but we fixed some errors, see the diffs below.
With this changes we getting already smaller deviations between the original environment and a reseted copy. But we still get some deviations for the object and we don't know where they come from.
(In general, the list version of the state should be removed for clarity/bugs reasons)