Training Pi0.5 on a LeKiwi

What changes when the arm can drive away

Everything you know from a fixed SO-100 still applies, plus three new problems. The policy now outputs base commands as well as joint commands. The scene camera moves, because it is mounted on a robot that translates and rotates. And a mistake no longer stops at the edge of the workspace, because the workspace is wherever the robot ends up.

LeKiwi is listed as compatible rather than fully supported. The training backend handles the wider action vector without special configuration, but the hardware loop gets less first-pass testing than the Feetech arms on a bench, so plan to verify things yourself rather than assume them.

The action vector is wider, and it will not tell you if it is not

Five joints plus a gripper give six actuator commands. The three-wheel holonomic base adds its own commands on top, so a properly recorded LeKiwi episode carries a wider action vector than any fixed-arm dataset. Check that in the dataset metadata before you spend GPU hours, because a dataset recorded without the base logged is a perfectly valid LeRobot dataset that trains into an arm-only policy on a robot that can drive.

{
  "robot_type": "lekiwi",
  "fps": 30,
  "features": {
    "action": {
      "dtype": "float32",
      "shape": [9],
      "names": [
        "shoulder_pan", "shoulder_lift", "elbow_flex",
        "wrist_flex", "wrist_roll", "gripper",
        "base_wheel_1", "base_wheel_2", "base_wheel_3"
      ]
    }
  }
}

The practical rule: open the dataset preview, read the action shape, and confirm it accounts for the base. This is a ten-second check that prevents the most expensive silent failure on this platform.

Recording demonstrations that include the base

Teleoperating a mobile manipulator is a two-handed skill, and the data quality problem is different from a fixed arm. On an SO-100 the risk is inconsistent grasp strategy. Here the risk is inconsistent division of labor: sometimes you drive close and barely extend the arm, sometimes you park further out and reach. Both work for you. Together they teach the policy that the boundary between driving and reaching is arbitrary.

1. Decide a convention before episode one: drive first and then reach, or drive and reach together. Then hold it for the entire dataset.
2. Keep base speed low and even. What you record is what the policy attempts, and a fast recorded turn becomes a fast commanded turn on a robot with momentum.
3. Vary the starting pose of the robot, not just the object, so the policy learns to approach rather than to replay one path.
4. Watch what the moving camera sees. A view that is stable while stationary can motion-blur while driving, and blurred frames during the approach are training data teaching confusion.
5. Stop the episode when the task is done, not when the robot has drifted to a stop.

Why Pi0.5, and what 485 ms means on wheels

Pi0.5 predicts action chunks through flow matching, following a continuous path to the next set of actions instead of choosing from discretized alternatives. On a mobile manipulator that continuity is worth more than it is on a fixed arm, because base and arm commands come out of the same head: a smooth output keeps the drive and the reach coordinated instead of producing a lurch every time the policy changes its mind.

The latency cuts the other way. About 485 ms per action step means just over two commands per second, and a wheeled base acts on the last command it was given until the next one arrives. On a fixed arm a stale command means the joint sits still. On a base it means the robot is still moving. That is the single most important sentence on this page: plan your speeds, your clearances and your stopping distances around a control loop that updates roughly twice a second.

Prerequisites

• A LeKiwi with the arm calibrated and all six arm servos responding, plus a base that drives predictably under teleoperation
• Correct supplies on both rails, 7.4 V to the arm and 12 V to the base
• A floor area you can clear and keep clear, not a desk
• A reliable link between the base and whatever machine runs the client, since a dropout mid-episode is a corrupt episode and mid-deployment it is a runaway
• At least 50 kept episodes as a LeRobot v2.1 dataset with the base included in the action vector

Training the policy

1. 1
   Choose the dataset and check its shape

   In Training, select the uploaded LeKiwi dataset and open the preview. Confirm the action dimensions cover arm and base, and confirm the camera streams are the ones you recorded with. Everything else in this flow assumes that check passed.

2. 2
   Pick Pi0.5

   It sits in the model list against the A100 80 GB tier at about 485 ms per action step. The backend identifier is pi0 while the trained artifact is a pi05 policy, which is only visible if you go through the API or MCP rather than the form.

3. 3
   Set the parameters and the seed

   Batch size 1, learning rate 5e-5, 30000 steps, gradient accumulation 16, plus the seed and log frequency fields this trainer family exposes. On a mobile robot, where evaluation is noisier than on a bench arm, a fixed seed is the only way to keep two runs comparable.

4. 4
   Queue it on an 80 GB card

   The pool takes an 80 GB card from the spot market by VRAM, so availability rather than choice decides which card you get. You are not billed while the job waits in the queue.

5. 5
   Follow loss and GPU telemetry

   The run page carries loss, learning rate and gradient norm next to utilization, VRAM, temperature and power. Neither the curve nor the telemetry knows anything about your floor, so treat both as evidence the job is healthy and nothing more.

6. 6
   Save more than one checkpoint

   Candidates from late in the schedule differ from each other more than the loss curve suggests. Put each one through the identical physical protocol in the identical cleared area, because a comparison spread across two rooms measures the rooms.

Defaults for a LeKiwi run

Cost and duration

The same 3 to 6 hours at 1.20 to 2.00 USD per hour, about 4 to 12 USD, as every other A100-tier run here. The wider action vector adds a negligible amount of work; what fills the hours is 30000 steps with 16 accumulation passes each at batch size 1. Memory is not the constraint on an 80 GB card, time is, and time is what the bill is measuring.

Given that a mobile dataset usually needs more iterations than a fixed-arm one to become reliable, budget for several runs rather than one. Proving the recording chain on a 24 GB card first, 2 to 5 hours at 0.30 to 0.60 USD per hour and about 1 to 3 USD, is a sensible habit on this platform.

Deployment and evaluation safety

This is the part that differs most from every other guide in this set. A fixed arm fails inside a volume you can reach around. A LeKiwi fails by leaving.

1. Run on the floor in an area you have physically bounded, with nothing fragile and no cables in the path.
2. Keep a person on the power for every attempt, standing, not sitting, and not the person also holding the notebook.
3. Assume stopping is not instant. At roughly two action steps per second the robot completes whatever it was last told to do before it hears anything new.
4. Do not evaluate near stairs, thresholds, pets or a table edge. The first policy will drive somewhere you did not predict, and the honest response to that is a cleared floor, not faster reflexes.
5. Cap the attempt. Decide up front how long one attempt may run and cut the power at that mark rather than watching to see what happens next.

With that in place, evaluate the way you would anywhere else: twenty attempts, varied robot start poses and object positions, written down honestly, then the same twenty for the next checkpoint. Separate failures into the ones where the base went to the wrong place and the ones where the base was right and the arm missed. Those two need different data to fix, and lumping them together is how people end up recording two hundred episodes that address neither.

Troubleshooting

Frequently asked questions