Team setup · from Prandium/docker/README.md

A Dockerfile that recreates the OpenArm v1.0 bimanual setup tested on zeus: ROS 2 Jazzy, the OpenArm stack at pinned commits, the local fixes, and the helper scripts. Full documentation: Documents/OpenArm Docs/OpenArm_ROS2_and_teleop_Guide_V3.1.md (the guide). Test history: Documents/Logs/.

What’s inside

Baseosrf/ros:jazzy-desktop-full (Ubuntu 24.04, ROS 2 Jazzy, RViz)
openarm_ros2b9d7a67
openarm_descriptionc103041
openarm_canf340d4b (v1.4.0), incl. openarm-can-cli
Local changestrajectory controllers use interpolation_method: splines (upstream none makes goals jump to the target); openarm_hardware patched with openarm_patches/0001 + 0002: start-up moves to zero in 10 s with no kick, and refuses to start if a motor doesn’t reply or a joint is more than 0.5 rad from zero (guide §4)
Scriptsrobot_scripts/ copied to /root/scripts (also /ws/scripts): launch wrapper, safe stop, single-joint move, joint sweep, demo (guide §8.7)
Shellevery shell sources ROS and the workspace; shells start in /ws

Check the local changes inside a container: git -C /root/ros2_ws/src/openarm_ros2 diff --stat (3 files).

Files you need

From the Prandium folder: docker/, openarm_patches/, robot_scripts/. Keep them side by side, as in Prandium.

Build (once, ~10–20 min, several GB to download)

cd Prandium
docker build -f docker/openarm-jazzy.Dockerfile -t openarm-jazzy:team .

Only openarm_patches/ and robot_scripts/ are sent to the build (see openarm-jazzy.Dockerfile.dockerignore). The build stops if a patch doesn’t apply.

Create the container (once)

On the host, first: Docker, your user in the docker group, and for an NVIDIA GPU the NVIDIA Container Toolkit.

xhost +SI:localuser:root            # once per login: lets the container open windows
docker run -it --name openarm --network host --ipc host --gpus all \
  -e NVIDIA_DRIVER_CAPABILITIES=all -e __NV_PRIME_RENDER_OFFLOAD=1 -e __GLX_VENDOR_LIBRARY_NAME=nvidia \
  -e DISPLAY=$DISPLAY -v /tmp/.X11-unix:/tmp/.X11-unix \
  --cap-add SYS_NICE --ulimit rtprio=99 --ulimit memlock=-1 \
  -v "$PWD/robot_scripts:/root/scripts" \
  openarm-jazzy:team
FlagWhy
--network hostROS discovery, and the CAN interfaces (can0, can1) are only visible with host networking
--ipc hostfast shared-memory transport
--gpus all + the three -e …NV…/NVIDIA…RViz on the NVIDIA GPU. __NV_PRIME_RENDER_OFFLOAD and __GLX_VENDOR_LIBRARY_NAME are for hybrid-graphics laptops; without an NVIDIA GPU, drop --gpus all and those variables
-e DISPLAY + X11 socketGUI (RViz)
--cap-add SYS_NICE --ulimit rtprio=99 --ulimit memlock=-1real-time priority for the 750 Hz control loop; the launch log should say Successful set up FIFO RT scheduling policy with priority 50. (guide §5)
-v "$PWD/robot_scripts:/root/scripts"optional: your live robot_scripts folder instead of the copy baked into the image (run the command from Prandium)

Daily: docker start openarm, then docker exec -it openarm bash for each terminal.

Simulation first

bash scripts/openarm_launch.sh sim        # in the container, from /ws
python3 scripts/openarm_demo.py           # in a second shell: the demo, in RViz

Real robot: read this before powering anything

  1. Check your CAN cabling. openarm_launch.sh real has zeus’s mapping built in: robot’s left arm = can0, right arm = can1, the reverse of the ROS defaults. If your robot is cabled differently, edit the args= line in robot_scripts/openarm_launch.sh first. After every real launch, python3 scripts/openarm_jmove.py left 7 0.1 must move the robot’s own left wrist (stand behind the robot: the arm on your left). On zeus, a launch with the wrong mapping once sent the right arm’s motions to the left arm.
  2. CAN on the host (after every reboot or re-plug): sudo ip link set can0 type can bitrate 1000000 dbitrate 5000000 fd on && sudo ip link set can0 up, same for can1 (guide §10.4).
  3. Check the motor zero with the arms hanging: openarm-can-cli -i can0 monitor (guide §11). A wrong zero is the classic cause of violent start-ups. Note: monitor enables the motors, and set_zero without --id re-zeroes all 8 motors of a bus.
  4. Power both arms before launching, arms hanging, base clamped or weighted, power switch within reach.
  5. Stop with bash scripts/openarm_stop.sh, arms at zero, never a plain Ctrl+C (it can crash ros2_control_node before the motors are switched off, guide §12.4).
  6. The per-arm joint limits and which way ”+” moves each joint are in guide §3: joint2 has only 10° of room toward the body.

The full routine and checklist: guide §12 and robot_scripts/README.md.

Alternative: share the built image instead

Rebuilding needs internet and time; the built image can be passed around as a file instead (several GB):

docker save openarm-jazzy:team | gzip > openarm-jazzy-team.tar.gz     # on the machine that built it
docker load < openarm-jazzy-team.tar.gz                              # on the teammate's machine