rd record_calibration_poses starts but leader arms cannot be moved because teleoperation is not started

[tron-ann]

I ran into an issue after cloning and running the repository.

When running rd record_calibration_poses, the command starts normally, cameras open correctly, and CAN interfaces are detected. However, both leader arms become stiff / unresponsive in the calibration pose recording mode, so I cannot move the leaders to record calibration poses as described in the instructions.
In contrast, rd teleop works normally, and regular teleoperation is possible.

Cause:
After tracing the code, it looks like setup_for_teleop_recording() in raiden/robot/controller.py initializes the robots, moves them home, and puts the leaders into gravity compensation mode, but it does not actually call start_teleoperation().
As a result, the leaders enter gravity compensation, but the leader-follower teleoperation loop is never started.

Workaround / fix:
I was able to fix this locally by adding:

self.start_teleoperation()
at the end of setup_for_teleop_recording() in:

raiden/robot/controller.py

So the function becomes:

def setup_for_teleop_recording(self):
    """Complete setup for teleoperation-based recording: init -> home -> grav comp"""
    # Check CAN interfaces
    print("Checking CAN interfaces...")
    self.check_can_interfaces()

    # Initialize robots
    self.initialize_robots(gravity_comp_mode=False)

    # Move to home positions
    self.move_to_home_positions(simultaneous=True)

    # Enable gravity compensation mode for leaders only
    print(
        "  - Disabling position control on leaders for gravity compensation mode..."
    )
    if self.leader_r:
        self.leader_r.update_kp_kd(kp=np.zeros(6), kd=np.zeros(6))
    if self.leader_l:
        self.leader_l.update_kp_kd(kp=np.zeros(6), kd=np.zeros(6))
    print("✓ Leaders in gravity compensation mode")

    # Gripper ready signal
    self.signal_ready_with_grippers()

    # Footpedal soft e-stop (optional)
    print("Initializing footpedal...")
    self.attach_footpedal()

    self.start_teleoperation()

After this change, the leaders can be moved and the followers follow as expected during calibration pose recording.

I’m sharing this here in case it helps others.

[sh8]

Thank you for reporting the issue! start_teleoperation() is invoked in raiden/calibration/recorder.py via:

self.interface.start(self.robot_controller)

I’ll take a closer look at this bug tomorrow morning.

[sh8]

Unfortunately, I couldn't reproduce this error. Could you share the stacktrace so I can do further debugging?

[tron-ann]

Thanks for looking into this.

In my case, the terminal does not show any traceback or explicit error when I run rd record_calibration_poses. The program starts normally, and I can use the keyboard shortcuts such as r, d, and q without any issue. However, I cannot move either of the two leader arms while this command is running. Both leaders feel stiff / locked, so I am unable to record different calibration poses.

For additional context, I had also previously tried to reproduce the I2RT MuJoCo visualizer with:

python examples/minimum_gello/minimum_gello.py --mode visualizer_local

That path was also unstable on my side. I saw errors such as:

RuntimeError: Motor error detected: motor id: 6, error: loss communication
RuntimeError: MotorChainRobot(...): motor_chain_robot's motor chain is not running, exiting the robot server

In addition, when running teleoperation earlier using i2rt or Raiden, I previously hit an issue related to a missing channel attribute.
AttributeError: 'DMSingleMotorCanInterface' object has no attribute 'channel'
To work around that, I modifieddm_driver.py class DMSingleMotorCanInterface(CanInterface) by adding the following line in init, right after super().init(...):
self.channel = channel

So to summarize: rd teleop works on my side, but rd record_calibration_poses starts without any visible error while still leaving both leader arms immovable.

[sh8]

Thank you so much for all the details? Apparently, i2rt's SDK had some breaking changes, and I got a similar error before. I think the latest commit at least fixed the DM driver issue so could you try to pull the latest changes and try again? Thanks!

[tron-ann]

Hi @sh8, thanks for the response — apologies for the late reply. Let me clarify the scope of the original report first:

The motor errors and the DMSingleMotorCanInterface channel issue both came from the i2rt SDK path (examples/minimum_gello/minimum_gello.py --mode visualizer_local), not from Raiden.

The actual Raiden-internal issue is just one: rd record_calibration_poses leaves the leader arms stiff.

We had another person on our team try the same setup on a separate machine using the same branch (bcb277d, details below). The calibration leader-lock reproduces there as well, so the issue is not environment-specific. Applying the same workaround — adding self.start_teleoperation() at the end of setup_for_teleop_recording() in raiden/robot/controller.py — resolves the calibration lock. One side effect: with that line added, rd teleop itself stops working, likely because start_teleoperation() ends up being invoked twice in the teleop path. Reverting controller.py to the original restores rd teleop.

The branch with calibration problem for reference:

• HEAD: bcb277d (2026-04-05, Added --use_depth option to the shardify command)
• Local diff: a single line self.start_teleoperation() added immediately after attach_footpedal() in raiden/robot/controller.py

---

On a separate note: the Recording docs state that follower gripper position is mapped from the leader trigger as 0 → open, 1 → closed, but in the recorded robot_data.npz we appear to observe the opposite — gripper_pos near 1 when the gripper is open and near 0 when closed. Could be a documentation wording issue.