35. Your first run on zeus, step by step

Part III: Running a trained policy · §35 of 43

The first run is broken into small steps so that each new thing is tested on its own: first the files, then the hardware without the policy moving, then a 10-second run, then longer runs. Don’t skip ahead. If a step doesn’t give the expected result, stop, look it up in §41, and note it in the day’s log.

35.1 Step 1: open a terminal and activate the environment

conda activate lerobot
cd ~/Documents/lerobot
lerobot-info | head -5          # shows the LeRobot version (0.6.2)
python -c "import torch; print('CUDA:', torch.cuda.is_available())"

Expected: CUDA: True. If False, see §27 (last row).

35.2 Step 2: check the trained model

Run the two snippets of §31.2 and §31.3. Note down:

• the full pretrained_model path,
• the camera names and resolutions the policy expects,
• the dataset’s fps,
• the start pose (mean per joint).

35.3 Step 3: hardware setup

bash ~/Documents/openarm_lerobot/setup_openarm_lerobot.sh

Expected: it ends with the sanity table, 16/16 follower motors. It also checks the Minis, which is harmless even if you won’t use them.

35.4 Step 4: make sure nothing else is driving the arms

pgrep -af "lerobot-|safe_teleop|ros2_control_node" || echo "nothing running"
candump -n 20 -T 500 can0; candump -n 20 -T 500 can1     # no output = nobody is commanding the arms

ros2_control_node runs inside the container, but the container shares the host’s process list only partly. If you’ve used ROS today, also check inside it (§25).

35.5 Step 5: check the cameras

lerobot-find-cameras opencv

It lists every camera and saves one test image per camera to outputs/captured_images/. Open them:

• Find which /dev/video… (or better, /dev/v4l/by-id/…) is which physical camera, and make sure it matches the name used in recording (e.g. the overhead camera must be top).
• Compare each image with a frame from the training data: lerobot-dataset-viz --repo-id <hf_user>/openarm_pick_cube --episode-index 0. Same framing, same angle? A camera that moved by a few centimetres can be enough to break the policy.

Camera numbers (/dev/video0, /dev/video2) can change when cameras are re-plugged. If you recorded with /dev/v4l/by-id/… paths, they don’t.

35.6 Step 6: put the arms in the start pose

Torque is off (setup leaves it off). By hand, move both arms to the start pose you noted in step 2, usually hanging straight down, grippers closed. Check:

python ~/Documents/openarm_lerobot/compare_mini_follower.py --once

Look only at the follower columns. Every joint should be within a few degrees of the start pose (or inside the min–max range from §31.3). Then put the objects of the task in a typical start position.

35.7 Step 7: dry run, everything loads but nothing moves (interactive mode)

This tests the policy files, the CAN connection, the cameras and the feature matching, without the policy ever moving the arms:

bash ~/Documents/openarm_lerobot/run_policy.sh --interactive=true

(or the full command of §32.1 with --interactive=true added.)

What happens:

1. The log of §33.1 up to step 4. Torque comes on at connect: the arms are energised from here.
2. A banner: “Interactive rollout session — the robot will NOT move until you type /start.”, followed by the command list:

Command	Effect
/start	Start (or restart) the policy. --duration then limits this segment.
/reset	Stop the policy, move back to the start pose, keep torque on, wait.
/stop	End the session: back to the start pose, torque off, exit.
/help	List the commands.
/subtask <text>, /vqa <text>, /autosteer <goal>	Only for language/VLA policies with a text head. Not used with ACT.

3. Type /stop and Enter. The arms “return” to where they already are, then go limp. Support them as torque goes off.

Expected: no error, and the arms didn’t move. You have now proven that the policy loads, both buses and all cameras open, and the camera names match. Note that routine log messages are muted during an interactive session: only errors and the cadence summaries are shown.

35.8 Step 8: the first 10 seconds of policy control

Re-check step 6 (arms at the start pose). The second person has a hand on the power switch. Then:

bash ~/Documents/openarm_lerobot/run_policy.sh --interactive=true --duration=10

At the banner, type /start. Watch the arms, not the screen.

• The arms should start moving smoothly, roughly like the beginning of a demonstration.
• Abort with the power switch if: an arm jumps fast at the very start, moves toward the torso or the other arm, hits the table hard, or a joint shakes.
• After 10 s the segment ends by itself: “Rollout run ended on its own (duration reached). Robot is holding position.” The arms hold their last pose.
• Type /reset to bring them back to the start pose, reset the scene, and /start again for another 10 s. Repeat a few times.
• /stop when done (support the arms).

Write down what you saw (did it go for the object? how smooth? any snap?) in the day’s log.

35.9 Step 9: longer runs

Once 10 s segments look sane:

• Raise --duration to the length of a typical demonstration plus some margin (e.g. 30–60 s).
• Drop --interactive=true when you don’t need the pause between attempts. Ctrl+C once stops early.
• To measure how often it succeeds, switch to evaluation episodes (§37).
• Read the cadence summary printed at the end of each run (§36.6): effective cadence should be close to 30 Hz.

35.10 After the run

• The arms are limp at the start pose. If you’re done for the day, lower them fully and switch the motor power off.
• Nothing is saved by the base strategy: no dataset, no video. If you want a record, use episodic (§37) or film it.
• Note in the log: which checkpoint, the command, how many attempts, what worked, what didn’t.

Previous34. Pre-flight checklist (every policy run)Next36. Tuning how the policy moves