Prandium Docs

13. Safety notes specific to this code

2 min read

Part I: The ROS 2 stack · §13 of 43

  1. Activation moves the robot: arms go from the current pose to all-zero with full gains (return_to_zero() in on_activate): upstream in ~2 s after a kick toward 0; on zeus (patched) in 10 s, eased, refusing if a motor doesn’t reply or a joint is >0.5 rad away (§4). Re-activating a hardware component does it again.
  2. Torque off = arms fall: on_deactivate, openarm-can-cli disable, Ctrl+C in the calibration scripts, and power loss all drop the arms. And the opposite: a plain Ctrl+C on the ROS launch may leave the torque on (crash before deactivation, §12.4).
  3. No tracking-error abort: JTC tolerances are all 0 (disabled), so a blocked or colliding arm doesn’t make the controller give up. The motor keeps pushing up to what kp × error allows.
  4. No self-collision checking outside MoveIt. Raw trajectory commands can drive the arm into the torso or the other arm.
  5. Forward position controller steps instantly (§8.5).
  6. Velocity “controller” isn’t velocity control (§4, §16).
  7. Mixed-up can0/can1 sends the right arm’s commands to the left arm (§10.3). On zeus the ROS defaults are the mixed-up mapping; it happened once (2026-10-10). Launch with openarm_launch.sh real and do the identification step (§12.2). The arms are mirrored, so the wrong arm also moves the other way, and the scripts’ limit checks apply to the arm the command was meant for.
  8. Wrong arm_type (default v2.0) loads the wrong kinematics. Always pass arm_type:=v10.
  9. Wrong zero makes “0 rad” a different physical pose. That’s dangerous at activation (§11).
  10. joint_limits.yaml isn’t the real limit set for joints 1–2 (§3): joint2 has only 10° inward on each arm.
  11. An arm powered after the launch stays limp while ROS thinks it’s in control (§4).
  12. openarm-can-cli monitor/diagnose enable the motors, and set_zero without --id re-zeroes all 8 (§10.5).

Graph View

Backlinks