Unity Reachy Digital Twin joint mapping

Hi everyone,

I’m using Reachy2-UnityDigitalTwin and Unity already mirrors Reachy (sim + physical) in real time.

goal: implement an intent preview: show the future motion on a ghost model in Unity, then execute the same motion on the robot/sim after ~1s delay (should look continuous, not a jump).

I need help with:

  1. Joint mapping: Is there an official mapping between Unity prefab joint names (ArticulationBodies like r_shoulder_first_link, r_elbow_first_link, etc.) and the joint order used in Python SDK reachy.r_arm.goto([7 values]) / ROS2 controller arrays?

  2. Teleop “intent” signal: During VR teleop, where can I read the commanded targets (not measured state)?
    I heard the chain is: VR → WebRTC → ROS /joint_commands/{part_name}/ik_target_pose/{part}_forward_position_controller/commands.
    Which topic/point is best to tap for intent?

  3. Where to insert delay safely: What’s the cleanest/safest place to add a fixed ~1s delay (e.g., delay /joint_commands vs ik_target_pose vs controller commands)? Any pitfalls?

I can attach a short Unity joint dump (names + joint types) and/or ros2 topic list outputs if helpful.

Hello @HabilH,

  1. In the Reachy2-UnityDigitalTwin project, you can find the mapping between the Unity prefab joints and the robot joint orders in the Motors list of Reachy2Controller (script attached to the Reachy2 GameObject in the hierarchy). The hand is handled a bit differently, but for the arm there is one Unity joint per controlled robot joint. The GameObjects used as joints have a JointController script attached.
  2. Topics/{part_name}/ik_target_pose and /{part}_forward_position_controller/commandsdo not contain the same kind of information:
    • /{part_name}/ik_target_pose is still an end-effector pose goal (desired position and orientation),
    • /{part}_forward_position_controller/commands contains the joints positions after IK has been computed.
  3. If you introduce a delay before publishing /{part_name}/ik_target_pose, the IK has not been processed yet, so you won’t have the values of each joint target to update the UnityDigitalTwin. If you want to delay the movement while still using the joint targets produced by the IK, you should delay before publishing the controller commands. You could publish the IK result (the computed joint goals) to another topic so you can retrieve the joint targets before sending the commands to the robot.