[Proposal] Extend FrameTransformer to report relative velocity and acceleration

[bikcrum]

Proposal

Extend FrameTransformer so it can optionally report linear and angular velocity, and optionally linear and angular acceleration, for the source and target frames, not only pose. Data would be exposed in both world and source frames (mirroring existing *_w / *_source pose fields), using the same rigid-body view as today (get_transforms()), supplemented by get_velocities() and get_accelerations() from PhysX, with COM-to-frame corrections when source/target offsets are non-identity.

Motivation

Users who drive policies, rewards, or observers from end-effector or body-relative motion (e.g. approach velocity, relative twist, acceleration limits) currently must duplicate logic: read poses from FrameTransformer, pull velocities from articulation/rigid-object APIs elsewhere, and manually align frames and offsets.

This feature would centralize pose + first/second-order kinematics for the same named frames, matching how teams already rely on FrameTransformer for relative pose.

Alternatives

• Users combine FrameTransformer with separate Articulation / RigidObject data and implement relative velocity/acceleration themselves. More work and prone to mismatch with FrameTransformer offsets.
• Use IMU to report velocity and acceleration with offset; however, it is limited to the world frame.

Build Info

Describe the versions where you are observing the missing feature in:

• Isaac Lab Version: 2.3.2
• Isaac Sim Version: 5.1

Checklist

• I have checked that there is no similar issue in the repo (required)

Acceptance Criteria

Add the criteria for which this task is considered done. If not known at issue creation time, you can add this once the issue is assigned.

• FrameTransformerData (and config) define opt-in fields for linear/angular velocity and acceleration in world and source frames, with documented shapes and conventions (including relative motion definitions).
• Unit or sensor check coverage validates at least one non-trivial case (e.g. rotating source frame, non-identity offset) against expected kinematics within tolerance.
• Documentation updated (sensor overview or FrameTransformer docstring) describing flags, semantics, and any PhysX/sim prerequisites for accelerations.

[RandomOakForest]

Thank you for posting this. The team will review it.