[Bug Report] Commit c984604 (optimization of getters) broke functionality with manager based RL workflow

[ozhanozen]

Describe the bug

The recent commit c984604 (#2118), which optimises data getters inside asset classes, appears to break functionality in my custom training workflows. Learning outcomes now differ significantly (and mostly degrade). After investigation I traced the issue to articulation_data.py: reverting only the changes introduced by c984604 in this file restores the previous training-workflow performance.

Are the changes in c984604 intended to affect anything beyond efficiency? If not, those modifications may introduce problems for other users as well.

While it’s hard to isolate a single culprit—my setup uses numerous custom MDP elements for events, observations, and curriculum—the likely pattern is that certain data buffers receive new timestamps before their underlying data are fresh, feeding stale values into the learning pipeline.

Example: body_state_w depends on body_link_pose_w and body_com_vel_w. If any function directly modifies the buffers of _body_link_pose_w.data or _body_com_vel_w.data after body_state_w has already been accessed, body_state_w will not capture this fresh information when it is called a second time. Any MDP element relying on body_state_w then might use out-of-date data for that timestep. I suspect such a case can slip through unnoticed, especially in event elements that randomise object or robot poses. In my environment I randomise the robot pose so that its end-effector starts near an object, whose pose is also randomized. With the recent changes, the function that randomises the end-effector may now read the object’s old pose, leading to incorrect initialisation.

To mitigate this in my own elements I invalidate the timestamp whenever stale data is possible (e.g. robot.data._body_link_pose_w.timestamp = -1). This alters the learning curve slightly but still fails to recover the performance seen before c984604. Do any built-in IsaacLab components (e.g. FrameTransformers, standard MDP elements, etc.) call these getters in a way that could also surface stale values?

Steps to reproduce

Revert the changes from c984604 (at least in articulation_data.py), then re-run a training workflow that previously converged correctly. You might observe markedly different learning behaviour between the reverted and current versions.

System Info

• Commit: ba2a7dc
• Isaac Sim Version: 4.5
• OS: Ubuntu 22.04
• GPU: 4090 RTX
• CUDA: 12.2
• GPU Driver: 535.129.03

Additional context

The issue might still relate to how I use the getters in my custom scripts, but ideally the data flow should be robust to such usage patterns.

Checklist

• I have checked that there is no similar issue in the repo (required)
• I have checked that the issue is not in running Isaac Sim itself and is related to the repo

Acceptance Criteria

• All data pathways remain free of stale values.

[ozhanozen]

I have debugged this further, my suspicion is that, here:

IsaacLab/source/isaaclab/isaaclab/assets/articulation/articulation.py

Lines 519 to 522 in 33e6865

	# Need to invalidate the buffer to trigger the update with the new root pose.
	self._data._body_state_w.timestamp = -1.0
	self._data._body_link_state_w.timestamp = -1.0
	self._data._body_com_state_w.timestamp = -1.0

not enough timestamps are invalidated. For example, I would say the following should be invalidated as well:

self._data._body_link_pose_w.timestamp = -1.0
self._data._body_com_vel_w.timestamp = -1.0
self._data._body_link_vel_w.timestamp = -1.0
self._data._body_com_pose_b.timestamp = -1.0
self._data._body_com_pose_w.timestamp = -1.0

because, e.g., calling body_state_w will now call body_link_pose_w, which carries the old value (and recent timestamp). Any code that body_state_w would, in turn, have the old value.

There could be other places where such an issue happens as well.

[ozhanozen]

Ok, after some testing, I could confirm that adding:

self._data._body_link_pose_w.timestamp = -1.0
self._data._body_com_vel_w.timestamp = -1.0
self._data._body_link_vel_w.timestamp = -1.0
self._data._body_com_pose_b.timestamp = -1.0
self._data._body_com_pose_w.timestamp = -1.0

to write_joint_position_to_sim(), alone, solves my aforementioned issue, and I am able to retrieve the previous learning dynamics.

I would suggest:

1. As a quick fix, updating write_joint_position_to_sim() accordingly.
2. Simplifying the chaining buffers, maybe we should remove timestamps from the ones that do not call Physx directly, e.g., body_state_w. They mostly operate on existing buffers, which should not be that costly.
3. Writing helper functions that reset the timestamps of all relevant buffers, for each family (e.g., body positions). It would be easy to keep track of the timestamps logic if they are in dedicated functions. It is also an option to use setters, such that setting one enforces timestamp reset for all that family.
4. Writing test conditions for circular buffer setter/getters such that any future change does not create issues.

[ooctipus]

Hi @ozhanozen
Thank you for finding the issue and provide the solution
I am aware of this data-reading consistency issue, and I can also attest that the same issue not only exist in articulation as you point but also in also exists in RigidObject.
I created below pull request and wrote test conditions to make sure write_*_to_sim will ensure all relevant data get updated directly, you can find it here, and feel free to add comment

#2736

[RandomOakForest]

Thank you for posting this, and for submitting a PR. The team will review.

[kellyguo11]

Fixed in #2736