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?
Hi there, the set_joint_positions API will also call set_joint_position_targets as it’s required to set both when setting the positions of joints. Therefore, you do not need an additional call to set_joint_position_targets.
Thank you for letting me know @kellyg , I have removed the unnessary function call.
Unfortunately, that does not solve the issue with the contacts. I was previously told that Nvidia is planning to release a new version in June. Do you know what the current status on that is? Would be super helpful for our planning.
The next release is currently planned for August. Sounds like the issue may be a bug with the GPU pipeline. In order for us to repro this, do we require 2 articulations in the scene, then setting the root and joint states for both simultaneously?
Regarding the issue, I find it hard to produce a simple setting to reproduce it. In general it seems to happen with:
two different articulations in a cloned scene, using ArticulationViews
resetting them simultaneously
But it does not always happen and not with all robots / articulations. It may indeed be the GPU pipeline, though I cannot confirm for certain.
Trying to find a reproducible, simple case, things start to behave weirdly before I even get to this point. In the attached file I use assets from nvidia. If device = "cpu", everything behaves fine (robot standing still, correct joint values being set). If you change it to device = "cuda", the robot starts moving without getting any commands - this also happens without a second articulated object. If at the same time we spawn a cabinet, the robot starts to fly around - no idea why,
While this is not the exact same issue, it seems very related. If I spawn a different articulated object, that I did not include as it’s based on much more files, the robot does not start flying, but the object doors always open after resets etc. - while on CPU the joints get set to the correct state and then do not move any further.
All these issues seem somewhat related to me. The python files are attached in the zip file below. testcase.tar.xz (5.2 KB)
Your help would be greatly appreciated! I am really, really struggling to use the simulator at this point and have run out of ideas on how to make the physics behave in a stable manner.
Thanks for providing the repro scripts. I tested the scripts on our latest internal version of Isaac Sim and I did not observe any issues. The behaviour was the the same with device set to “cpu” and “cuda”, and I didn’t get any undesired movement of the robot with the GPU pipeline. It’s likely that the issue has already been fixed and will be made available in the next Isaac Sim release.
Hey there, it sounds suspicious. It’s strange that it worked before, but not in the newer versions. Maybe there were some changes in the physics simulation. Have you tried reaching out to their support or community forums? They might have some insights or solutions. Alternatively, you could try this telepresence robot. Good luck with your training!
