Silent failure in GPU mode: getRootPose() and velocity getters return stale initial data

[fffffq00]

Description:
I was using the maniskill3 framework today and tried to access the robot's root pose via env.agent.robot._objs[i].root_pose. I noticed that the returned values remained completely static throughout the simulation.

After digging into the SAPIEN source code, I realized this happens because the environment is running in GPU mode, and the native C++ handles lose synchronization with the GPU tensor buffers.

However, the core issue is that the std::runtime_error originally designed to prevent this exact scenario has been explicitly commented out in the source code:
https://github.com/haosulab/SAPIEN/blob/master/src/physx/articulation.cpp#L362-L364
The same applies to the velocity getters below it.

Suggestion:
Why was this exception-throwing code commented out? Is it really appropriate to provide no warnings or exceptions at all for an unsupported API call in GPU mode? (Even though few people might call these native single-fetch APIs in GPU mode, we should still ensure all features are robust.)

[StoneT2000]

What robot are you using? Root pose not changing can be indicative of a fixed robot base and or a fake link centered at the origin

[fffffq00]

Hi, I don't think it's a robot configuration issue. I've verified that the robot's root is not fixed. env.agent.robot.root_pose and env.agent.robot._objs[i].root.pose are updating correctly as expected. However, env.agent.robot._objs[i].root_pose remains static, even when the robot is moving. I think the issue lies in the code I just posted.

[StoneT2000]

Ah I understand now. You aren't meant to retrieve data from the CPU buffers during GPU simulation, which is saved in _objs[i].root_pose (the original SAPIEN articulation object). When running GPU simulation all sim state data such as poses and velocities are in GPU buffers only. We give you access to the GPU buffers via env.agent.robot.root_pose

[fffffq00]

Yes, But when I retrieve data the wrong way, there are no warnings or errors at all. I think these functions should definitely throw an exception or at least give some kind of warning.

[StoneT2000]

Ok a question for @fbxiang then.

I do recall there are some properties that are meant to be left exposed, we may not have double checked we handled all of them correctly.

[fbxiang]

The situation was that in some places, it is convenient to keep these properties available. Afterall, these are perfectly valid before GPU initialization. A better design is probably to throw an error when you access these after GPU init, but that may still break some existing code. Considering PhysX itself also had such desync issue, and the problem probably exists elsewhere, the best thing is probably trying to detect misuse and print a warning. I will look into that later.