[Bug Report] [bug] Mobile Base yaw not updating xy translation

[exaFLOPs26]

Describe the bug

Mobile bases with no distinct wheels (e.g., ridgeback Franka) have a hierarchical joint setup: world -> dummy_joint_x -> dummy_joint_y -> mobile_base. So even if I rotate the yaw, xy is not affected. So it goes like this.

anubis_v2.mov

Steps to reproduce

1. First I change the x_joint and it went forward and backward direction.
2. As I rotate the yaw for around 90 degree x,y should have changed.
3. Last I change the y_joint that the direction should have been forward and backwards but still sideways, which means that the yaw rotation is not updating the xy translation. And it is obvice by the hierarchical joint structure.

What I did first

Change it to yaw-x-y joint hierarchical structure. But now it rotates in a circle. This is obvice even I change the xy translation, again in the opposite way, xy translation is not updating yaw rotation. So the center of yaw rotation is fixed at the first time.

What I am doing

I use simple linear algebra to calculate the xy translation with yaw rotation. But I can't move and rotate at the same time. And this is a big bottleneck on Imitation Learning and RL for mobile ones.

System Info

Describe the characteristic of your environment:

• Isaac Sim Version: 4.5.0
• OS: Ubuntu 22.04
• GPU: Nvidia L40S

Additional context

• To do Sim2Real Real2Sim is important. How can we tune the simulation to make it stablized? Tried gain tuner, but at the end of the day, I did it manually.

• I remember a speech by Eric in office hour session, that what we need to do is not make the simulation same as the real world, but make it cover it. Are there any tips on this also?

[RandomOakForest]

Thank you for posting this. Interesting catch, the team will review this. It would be great if you can start new discussions on each of your questions in "additional context", adding more details or elaborating on a specific task of interest.

[exaFLOPs26]

Thanks! One more thing is that if I do ik absolute control for these kind of mobile manipulator(without distinct wheel like ridgeback_franka) it occurs a problem.

I fixed the 'source/isaaclab/isaaclab/envs/mdp/task_space_actions.py' to make it work! If interested, I can share it.

[RandomOakForest]

That would be great. Please add a PR for the team to review.

[RandomOakForest]

Following up, it seems the video is showing the expected behavior as you update parameters. In particular, we don't think this is expected: "yaw for around 90 degree x,y should have changed."

[exaFLOPs26]

First I control the x joint and next I controled the Y joint. As I rotate 90 degree, wouldn't the x and y head the same direction?

I think my demo is quite overcomplicated, but the problem I am having is that the robot is not going forward toward the heading direction but just goint along the fixed world x axis even the yaw is rotated.

[exaFLOPs26]

https://forums.developer.nvidia.com/t/moving-ridgebackfranka-robot-with-articulations-does-not-change-the-pose-of-the-robot/242112/8

[exaFLOPs26]

I found out that others are having the same issue. How can we handle this?

[exaFLOPs26]

@RandomOakForest Not to rush you, but this is still a bug to fix right?

[RandomOakForest]

Following up, I'll move this post to our Discussions section. Here is a summary that may help with possible next steps to try. To achieve proper movement in local x/y directions after rotating the mobile base, you need to transform control inputs from the local frame to world frame using the robot's current orientation. Here's the technical breakdown:

Core Requirements

1. Frame Transformation
   • After a 90° yaw rotation, the mobile base's local axes no longer align with world axes
   • Movement commands must be rotated using current orientation data
   • Use quat_apply() ¹ or transform_points() ² for coordinate transformation:

# Local forward direction (x-axis)
local_vec = torch.tensor([1.0, 0.0, 0.0])  

# Get current orientation quaternion (w,x,y,z format)
quat = mobile_base.get_orientation()  

# Transform to world frame
world_vec = quat_apply(quat, local_vec) [^3][^5]

2. Hierarchical Joint Control
   • Dummy joints operate in parent frame space ³
   • After transformation, apply calculated world vectors to joints:

# For velocity control
dummy_joint_x.set_velocity(world_vec[^0] * speed)
dummy_joint_y.set_velocity(world_vec[^1] * speed)

Implementation Checklist

1. Orientation Tracking

• Continuously monitor mobile base orientation using get_orientation()

2. Command Transformation

• Convert desired local movement vectors using current quaternion

3. Joint Actuation

• Apply transformed vectors to dummy prismatic joints ³
• For position control, use cumulative offsets:

current_x = dummy_joint_x.get_position()
current_y = dummy_joint_y.get_position()
new_x = current_x + world_vec[^0] * step_size
new_y = current_y + world_vec[^1] * step_size
dummy_joint_x.set_position(new_x)
dummy_joint_y.set_position(new_y)

Common Pitfalls

• Frame Stacking: Ensure joint hierarchy matches your coordinate transformation order (world→X→Y→base) ³
• Quaternion Convention: Verify quaternion storage format (w,x,y,z vs x,y,z,w) in your USD setup ²

The critical insight is that dummy joints don't automatically account for child rotations - you must manually transform control vectors using the mobile base's current orientation before applying them to the X/Y joints³²¹.

References

Footnotes

1. https://isaac-sim.github.io/IsaacLab/main/source/api/lab/isaaclab.utils.html ↩ ↩²

2. https://isaac-sim.github.io/IsaacLab/v2.0.2/source/api/lab/isaaclab.utils.html ↩ ↩² ↩³

3. https://forums.developer.nvidia.com/t/moving-ridgebackfranka-robot-with-articulations-does-not-change-the-pose-of-the-robot/242112 ↩ ↩² ↩³ ↩⁴

[exaFLOPs26]

I see! Thanks for the detailed reply.
Sadly, I just made an omniwheel inside and made it work but when I need to do this I will definitely refer to your suggestions. Thanks again!