Robot interface · repose-robot-interface
Robot interface
Every robot speaks a different protocol. repose-robot-interface defines what a Repose bridge must look like from the Copper side, so the rest of the graph never knows which robot it is driving. Swapping an igus ReBeL for a UR5e, URSim or MuJoCo is one bridge entry in RON.
The standard channels
Rx joint_state | repose_kinematics::CuJointStatePayload<N>: measured positions, velocities and CuRobotStatus. Always present. |
Tx joint_command | repose_controller::CuJointCommandPayload<N>: the controller's command. On bridges that move the robot. |
Tx session | CuSessionCommand. On bridges with a control session. |
Rx session_state | CuSessionState. On bridges with a control session. |
Directions are from the bridge's point of view in Copper: Rx flows from the robot into the graph, Tx from the graph to the robot.
Vendor channels
A bridge may add channels for things only its robot has, under a vendor-prefixed name: cri_status on the igus bridge, ur_status on the UR bridge. Nothing in Repose depends on them. Use them for diagnostics and dashboards, not for control logic you want to keep portable.
Command modes
CuJointCommandPayload carries a mode: position, velocity or effort (see Command modes). A bridge supports a subset and refuses the rest. The igus and UR bridges take velocity streams and single position moves and refuse effort; the MuJoCo bridge takes positions. Check the bridge's README before switching modes.
Pages
- Session lifecycle: acquiring control, enabling drives, and the tracker that enforces the rules.
- Available bridges: igus ReBeL, Universal Robots, MuJoCo, and how each is configured.
- Write a bridge: the structure and rules for adding a new robot.