I hope this message finds you well. I recently encountered an issue while attempting to run a robot motion implementation with a ‘gpu’ pipeline. The implementation works perfectly fine when using the CPU, but when I switch the pipeline to ‘gpu’, the robot does not move. I’m writing to seek clarification regarding the potential differences between these two approaches.
Could you please help me understand why this discrepancy might occur? I would greatly appreciate any insights or suggestions you can provide to help me resolve this issue. Below is the implementation I have been using:
The previous issue has been resolved. It was simply due to calling the set_joint_positions function multiple times within a single loop, which resulted in overwriting the values.
However, I have encountered another issue related to the behavior difference between the CPU pipeline and the GPU pipeline.
I am trying to recreate the Factory environment using the reference of the OmniIsaacGymEnvs Factory with a different robot. In the process of resetting the environment, when I use set_joint_positions to move the robot to its initial pose in the ArticulationView, the robot disappears inexplicably.
This issue does not occur when the pipeline is set to CPU, and the robot is properly initialized. However, using the CPU pipeline prevents me from simulating the SDF, which is necessary for replicating the Factory environment.
After executing the following code, the robot disappears somewhere:
In this image, the robot and the table appear to overlap, so I initially thought that the robot might be getting displaced to an unintended location due to contact. However, even after removing the table, the same issue continues to occur.
And here is the image when running with the CPU pipeline.
Before calling it.
Hi there, thanks for reporting the issue. Could you validate that the joint positions being set are within the dof limit constraints? Sometimes, undesired behaviours can occur when the states being set are beyond the limits. Otherwise, if it’s possible to provide a repro case, we can look into it. If it’s a similar issue as the referenced post, hopefully it was also fixed and will be available with the new release coming up.