SO-100 vs LeKiwi: the same arm, plus a base you have to teach

The short answer

This is not two arms, it is one arm and the same arm on wheels. The manipulator on a LeKiwi is the SO-100 manipulator: five joints plus gripper, Feetech STS3215 servos, 7.4 V. So the comparison is not about which one picks things up better. It is about whether you want the base, what it adds to your dataset, and whether you are ready to pay for it in demonstrations rather than in euros. The euros are the smaller number: roughly 400 to 500 against 110 to 150.

Side by side

What the base adds to every episode

The action vector recorded on an SO-100 has six entries, one per actuator. On a LeKiwi the base contributes its own commanded dimensions on top of those: three wheels, driven independently, which is what holonomic means in this build. Read the exact width off your recorded dataset rather than off this page, because the dataset is the authority on its own schema. What is not in doubt is the direction: the vector is wider, and the extra entries are ones no fixed arm ever had to predict.

A policy has to produce every dimension it was trained on, at every step. It does not get to leave the wheels blank because the interesting part of the task happens at the gripper. So the base is not an extra you can ignore until later. From the first episode you record on a LeKiwi, driving is part of the demonstration and part of what the model is asked to imitate.

That changes what your episode budget has to cover. On a fixed arm the object sits in a handful of places on the table and the camera never moves. On a mobile base the robot approaches from somewhere, and where it approaches from is now a variable you are teaching. The fifty episodes GR00T N1.7 wants become fifty episodes of driving and manipulating, not fifty of manipulating. Fifty runs that all start from the same tile on the floor teach a policy one approach path and nothing about the room.

What the wheels do to teleoperation and recording

The recorder starts and stops the recording, it does not drive the robot for you. You teleoperate while it runs, through the desktop client or the web cockpit, and on a LeKiwi that means driving the base and the arm inside the same episode. That is a coordination skill and your early attempts will show it. Clumsy driving is written into the dataset as ground truth just as faithfully as clean driving.

Two rules follow. First, keep an episode only when it was actually good: press Enter to end a clean one, Ctrl-C to discard the one you fumbled, because a half-driven approach in the data is worse than one fewer episode. Second, make the camera decision before the recording decision. A wrist camera moves with the arm on both robots, but on a LeKiwi a base or top camera moves with the whole machine, so the background shifts inside a single episode in a way a fixed setup never produces.

What does not change

Which model copes best with a mobile base

There is no base specific policy on this platform, so the real question is which of the five behaves well with a wider action space and longer episodes. Three facts in the catalog decide it. ACT has no pretraining and no language conditioning, so it learns your demonstrations and nothing past them, which on a mobile base means it learns your approach paths literally; its inference at about 20 ms is the compensation, and a driving robot benefits from a loop that closes quickly. Pi0.5 at about 485 ms per action step is the one to be careful with, because a base in motion makes a stale observation more expensive than a fixed arm ever does. SmolVLA sits in between at about 245 ms and becomes useful from about thirty episodes, which makes it the cheapest way to find out whether your LeKiwi data is worth scaling before you rent an 80 GB card.

A sane first week on a LeKiwi

1. 1
   Park the base and treat the thing as an SO-100

   Bring the arm up on its own rail, find the port, set the zero point and send it home. Everything you know about a fixed arm is valid at this stage, and it is the last stage where that is true for free.

   bash

   ay-robots devices
   ay-robots calibrate
   ay-robots home

2. 2
   Record a manipulation only baseline

   With the base stationary, record the task the way you would on a fixed arm. This gives you a reference for later: if the mobile policy fails, you will want to know whether the arm half was ever working.

   bash

   ay-robots record --task "pick up the red cube and put it in the bin" \
     --dataset lekiwi-static --episodes 10 --cameras wrist,top

3. 3
   Add driving, and vary one thing at a time

   Now record with the base moving, changing the starting position deliberately rather than randomly. Cover the approach directions you expect to need at deployment, and do not let all your episodes start from the same tile.

4. 4
   Upload and train the cheap model first

   Upload the dataset, then open Training in the dashboard, pick it, choose SmolVLA and press Start. There is no ay-robots train command: training runs on a rented cloud GPU, and an agent starts it with the start_training tool instead.

   bash

   ay-robots datasets upload lekiwi-mobile --name "lekiwi cube pick"

5. 5
   Evaluate from fixed starting positions

   Mark the floor. Run the same set of start positions in the same order every time, and write down where the failure happened: wrong approach, right approach with a bad grasp, or an arm that never got near the object. Those three go to different fixes.

   bash

   ay-robots run --model smolvla \
     --checkpoint s3://ay-robots-runs/lekiwi-cube-pick/step-20000 \
     --task "pick up the red cube and put it in the bin"
   ay-robots stop

Full against compatible, and how to debug across the line

The SO-100 carries the full support level: it is the reference unit, and a hardware symptom is reproduced on one before the page describing it goes up. The LeKiwi carries compatible. The arm half of it is that same reference hardware, which is why the servo advice, the calibration procedure and the Feetech failure modes apply directly. The base half is not: it is another rail and a set of dimensions the reference arm does not have, and the reproductions documented here were done on a fixed arm.

So split the problem before you debug it. Park the base and run the task by hand. If the arm misbehaves standing still, it is an arm problem and every fix page applies as written. If the arm is fine and the approach is wrong, it is a data problem in exactly the dimensions a fixed arm never had, and no change of model will fix a dataset that only ever drove one route.

Buy the LeKiwi if

• The task genuinely requires the robot to move: fetching from a second surface, following a person, working a bench longer than the arm reach.
• You already have a working fixed-arm workflow and your failures are about reach rather than about grasping.
• You are prepared to record demonstrations that cover several approach directions, not one.

Stay on the SO-100 if

• You are learning the pipeline. Every hour spent on driving is an hour not spent on the part that decides whether a policy grasps anything.
• Your task fits on a table. A mobile base adds dimensions, failure modes and a second power rail, and buys nothing back if the object is always within reach.
• Budget matters. Roughly 400 to 500 euro is three SO-100 arms, and three arms means a leader and follower pair with a spare.

Where to go next

• /robots/lekiwi for the LeKiwi fact sheet, rails and base layout
• /robots/so-100 for the arm that sits on top of it
• /train/smolvla-on-lekiwi for the cheapest first run on mobile data
• /train/groot-n1-7-on-lekiwi once you have fifty clean episodes and want generalization
• /fix/policy-only-works-in-one-setup when the robot succeeds from one start position and nowhere else
• /fix/camera-not-detected when a base mounted camera drops out mid session
• /glossary/degrees-of-freedom for how the base widens the action vector
• /glossary/episode for what one recorded demonstration contains
• /compare/so-100-vs-so-101 if you are still choosing the arm itself

Frequently asked questions