I am using RL to train on a robotic task. For this I set the robot to the center of a small room and spawn obstacles in random positions around it. At reset, the object positions are changed with
where dof_pos are default joint values and 0s for the base joints. Both these calls are issued, then a physics step is taken. The new robot position is guaranteed to be free of any obstacle.
This worked well in 2022.1.1, but sometimes fails in 2022.2.0 and 2022.2.1. It seems to fail in two cases:
a) the robot is in contact with an obstacle when resetting - see image 1 before reset, 2 after reset. The robot position is set to the center of the room, but instead the robot seems to fly off somewhere (outside the images)
b) an obstacle is being reset to the last position of the robot before the reset - see image 3 before reset, 4 after reset
My guess is that something changed in the physics, such that simultaneously resetting these objects no longer works. Could this be the case? As I mentioned, the exact same code worked well before.
This reset logic follows the OmniIsaacGymEnvs repository. Do you have any tipps how to remedy this? Are there any settings or object properties I could change to make this work? Or how / in what order should I do a reset in this scenario?
No, I’m not touching the root transform, i.e. never calling self._robots.set_world_poses(), this should remain unchanged at the original position (set by the gridcloner)
Can you try explicitly resetting the world poses to its original values at reset time to see if that helps? We’ve recently discovered that not resetting root transforms may cause large errors in the joints pre and post reset in the physics solver, it’s possible that this may be related.
Thanks for the suggestion. unfortunately resetting the robot root (self._robots.set_world_poses(*self._robots.get_world_poses())) leads the simulator to fail. I think for some reason this moves the robot into some invalid position. So I can’t quite test this hypothesis
What I did find is that the initial problem disappears if I add the obstacles as a RigidPrimView instead of an XFormPrimView. The downside of this is that now the obstacles also collide with each other, meaning I either have to put a lot of work into ensuring that they do not collide or write my own custom collision filter. I’m also not sure if this comes with additional computational overhead. My aim was to just have some static obstacles with minimal simulation dynamics, which the XFormPrimView seemed to fulfill (until the update to the latest version)
Lastly, trying the version with RigidPrimView and custom collision filter, most of the time it works fine, except for some rare cases in which the robot is suddenly able to drive through some of the obstacles
Unfortunately this for some reason also leads the simulation to crash. Though also from the description it sounds like that would disable all physical collisions? We would still like to have it collide with the robot
But otherwise I can also live with using the RigidPrimView with my custom collision filter. Seems to work alright for our current purposes.
Hi, there seems to be a larger issue with collisions when setting multiple object poses in the same step
I am now running a different task setup with a robot and a single articulated object. During reset I (i) set the robot position and robot joint values and (ii) set the articulated object positions and joint values with articulation.set_joint_positions() and articulation.set_joint_velocities(). Both the old and the new positions of robot and articulated object are far apart and cannot be in collision. I have also checked the collision boxes for both and they match the visuals of the objects pretty much perfectly.
Sometimes (not everytime) this leads to the following:
in the very next physics step after the reset, the PhysxSchema.PhysxContactReportAPI reports a contact between a robot link and the articulated object
over the next few steps the articulated object shakes or even falls over. This can be seen in the appended video at 0 and 22 seconds
This does not happen with e.g. a DynamicCuboid instead of the articulated object. But it happens as soon as I add a second Articulation & ArticulationView such as the articulated object above or the franka robot (omniisaacgymenvs.robots.articulations.franka). I have also tested it with a different robot than the PR2, the result is the same, making me confident that it is not related to the collision meshes of any of these objects.
Furthermore, it also still happens if I do not set any state of the articulated object in the reset, but only call
In particular it seems to be related to self._robots.set_joint_positions(dof_pos.clone(), indices=indices) (tested by commenting out each of the commands above)
Lastly, this only happens on the GPU. If I set use_gpu_pipeline: False and use_flatcache: False (as defined by OmniIsaacGymEnvs) this does not occur.
@kellyg Are you aware of this happening in other cases? Is there something in the order of the calls that I can change to circumvent this?
