LeKiwi: an SO-100 arm on a base that drives

What LeKiwi is

LeKiwi is what happens when the SO-100 arm stops being furniture. The LeRobot community put the same five joint arm with a gripper on a three wheel holonomic base, so the robot can drive to the thing it is about to pick up. A build comes in around 400 to 500 euro, which is an arm plus a chassis, wheels, base motors and a second power supply.

Holonomic is the word carrying the weight. Three omni wheels spaced around the base let it translate forward, translate sideways and rotate on the spot, independently and simultaneously. There is no steering angle and no turning circle. From a data point of view that is the friendly case: the base has no hidden configuration you have to track, only velocities you command.

The arm half is unchanged from an SO-100, down to the servo part number. Everything on this page that sounds like a complication is the base, and everything that sounds familiar is the arm.

Specifications

The wheels are part of the policy

On an SO-100 the client records six numbers per control step, one per actuator. On a LeKiwi it records those six and then one velocity per wheel. Nine numbers go into the dataset row, nine numbers come out of the policy head, and the model is never told which of them belong to an arm and which to a floor.

# SO-100, one control step
action = [j1, j2, j3, j4, j5, gripper]        # 6 values

# LeKiwi, one control step
action = [j1, j2, j3, j4, j5, gripper,        # the same arm
          w1, w2, w3]                          # one velocity per wheel

That is the whole trick and it is also the whole difficulty. It is a trick because mobile manipulation needs no special architecture here. The same SmolVLA, ACT, GR00T N1.7 and Pi0.5 that fine-tune on a fixed arm fine-tune on this one, because the action width is declared in the dataset rather than inferred from a description of the robot. /glossary/lerobot-dataset shows where that shape lives, and /glossary/imitation-learning covers why the model treats all nine outputs alike.

It is a difficulty because every dimension you add is a dimension that needs demonstrations. If you drove the base in ten of forty episodes and left it parked for the other thirty, the wheel columns are mostly zeros, and the policy will conclude, quite correctly given the evidence, that the right thing to do with a wheel is nothing. Underdriving the base is the LeKiwi version of recording forty episodes with the object in one position.

It is a difficulty for a second reason too: the base moves the cameras. A fixed arm sees one scene from one viewpoint, and the only thing changing within an episode is the arm itself. A driving robot changes the entire image, so the visual distribution the policy has to cover is far wider for the same nominal task. Expect to need more episodes than the per model floors suggest, and expect /fix/policy-only-works-in-one-setup to be the page you reach for the first time the robot fails in a room you never recorded in.

What a mobile base does to recording

Teleoperation acquires a second control surface. The arm is driven the way it always is and the base is driven at the same time, by the same person, inside the same episode. That is a genuine motor skill and the first handful of episodes are usually not worth keeping. The general recording discipline in /so-100/data-collection still applies in full, with these additions.

• Drive and manipulate inside one episode. A recording where you park first and only then reach teaches the policy that driving and picking are separate phases, which is right only if that is genuinely the task.
• Vary where the robot starts on the floor, not only where the object sits on the table. The reset procedure now includes the position of the whole machine, and floor resets are much harder to repeat than table resets. Put tape on the floor.
• Give the robot a camera that sees where it is going, not only what the gripper holds. A wrist camera alone leaves the base blind, and a blind base is a policy that drives into furniture with great confidence.
• Expect longer episodes. Driving consumes seconds a fixed arm never spends, and every one of those seconds is a frame the trainer pays for in wall clock time.
• Keep the task string byte for byte identical across episodes, exactly as on a fixed arm. Language conditioned policies split a dataset on a reworded sentence whether or not there is a base underneath.

Two supplies on one robot

Because the arm is a Feetech chain, the Feetech scoped fix pages apply to it unchanged: /fix/arm-twitches-then-sags, /fix/joint-stops-early and /fix/gripper-does-not-close are all written for this hardware. So are the bus agnostic ones, /fix/arm-not-detected and /fix/servo-not-responding, and cameras behave as they do everywhere in /fix/camera-not-detected.

From the carton to the first movement

1. 1
   Build the arm first and prove it on its own

   A LeKiwi is an SO-100 with a chassis underneath. Assemble and calibrate the arm as a standalone arm before the base exists, because a fault is far easier to isolate in a system with six servos than in one with nine. /learn/so-100-getting-started is the build for that half and every word of it applies.

2. 2
   Label both supplies before the base goes on

   One 7.4 V lead for the arm, one 12 V lead for the base, marked at the plug end. Do it while the two are still visually distinct in your memory rather than after they have been coiled together in a box.

3. 3
   Install the client and pair the machine

   The installer from /download carries the CLI, the desktop client and the driver. Pair once with the code from the Robots page.

   bash

   curl -fsSL https://www.ay-robots.com/install.sh | sh
   ay-robots pair 4QD2-8HRM-1XV6
   ay-robots status

4. 4
   Read the device list and count

   The arm and its serial port, plus every camera. Confirm the arm chain is complete here, because a servo that drops out intermittently is much harder to diagnose once the robot is also moving.

   bash

   ay-robots devices

5. 5
   Calibrate the arm and home it

   The zero reference is captured for the joints. Wheel velocities have no equivalent zero pose, since a velocity is a rate rather than a position, so calibration concerns the arm half only.

   bash

   ay-robots calibrate
   ay-robots home

6. 6
   Drive it before you record anything

   Spend twenty minutes teleoperating the base and the arm together with nothing recording. The point is to find out how the machine behaves when both halves move at once, on your floor, before that behaviour is baked into a dataset.

What the platform trains and runs on a LeKiwi

All four policy families have a guide for LeKiwi. The GPU tiers and inference figures are properties of the model and do not change with the base, but the latency column deserves a second look on a machine that drives: hesitation between action steps is far more visible when the whole robot is in motion than when only a gripper is.

Treat the episode column as a floor measured on fixed arms. Nothing in the catalog states what a mobile base adds to it, and this page will not invent a multiplier, but the reasoning above about camera motion points in one direction only. If the robot stalls partway through a motion rather than failing outright, /fix/policy-freezes-mid-motion separates the latency case from the mechanical one. Model detail sits on /policies/smolvla, /policies/act, /policies/groot-n1-7 and /policies/pi0-5.

# Drive base and arm together while this records
ay-robots record --task "bring the mug from the side table to the desk" --episodes 60 --cameras wrist,front

ay-robots datasets list --local
ay-robots datasets upload mug-fetch --name mug-fetch-lekiwi

# Training runs on a rented cloud GPU. Start it under Training in the dashboard
# or through the start_training tool on the MCP server.

ay-robots run --model smolvla --checkpoint s3://runs/mug-fetch-lekiwi/step-20000 --task "bring the mug from the side table to the desk"
ay-robots stop

Against the other three arms

• SO-100 and SO-101: the same Feetech servos at the same 7.4 V, six values per action, roughly 110 to 170 euro in parts, full support. A LeKiwi is one of these arms plus a base, so the arm knowledge transfers completely and the data knowledge does not.
• Koch v1.1: a Dynamixel arm on 5 V and 12 V rails at roughly 250 to 350 euro. It is the other compatible machine on the list, but its difference lives below the serial port while the LeKiwi difference lives above it, in the shape of the data.
• LeKiwi: the only supported robot whose action vector is wider than its arm, the only one where the reset procedure includes a position on the floor, and at roughly 400 to 500 euro the most expensive build here.

One thing worth saying without hedging: if the task does not require the robot to move across a room, a fixed arm is the better instrument. Every extra dimension has to be paid for in demonstrations, and paying for three wheels you never meaningfully use is the most common way a LeKiwi underperforms an SO-100 that cost a quarter as much. /glossary/end-effector is a useful reminder of where the task actually happens.

Frequently asked questions