LeKiwi Mobile Base Explained: Action Vector, Recording, Training

LeKiwi is an SO-100 class arm bolted onto a three-wheel omnidirectional base with a Raspberry Pi 5 in between. The arm half you know: six Feetech STS3215 servos driving five joints and a gripper, the same degrees of freedom and the same calibration dance as any SO-100. The other half changes the shape of the problem. The robot stops being six servo positions and becomes nine dimensions, three of them velocities in different units, measured rather than commanded, with no position feedback anywhere in the loop.

This is about that vector: where it comes from, what the kiwi drive matrix computes, which numbers are hard limits, and what changes when you record episodes and fine-tune a policy. Everything below was read out of lerobot main in August 2026 (pyproject on main reads version 0.6.2; the newest tagged release is v0.6.1, published 3 August 2026) and the LeKiwi build repository. Where docs and code disagree, and twice they do, the code wins.

What LeKiwi actually is

LeKiwi v1 is maintained by SIG Robotics at the University of Illinois with the Hugging Face LeRobot team. It is a build repository, not a product: bill of materials, STLs, assembly guide, Fusion 360 model, exported URDF. The arm on top is an SO-ARM101, sharing servo family and code paths with the SO-100. Here it is a compatible arm rather than the reference one; the side-by-side is at SO-100 vs LeKiwi.

The upstream bill of materials quotes three builds. Full totals include two arms, because leader-follower teleoperation needs a leader as well as the follower on the base.

Those exclude 3D printing. The parts cost listed here for a LeKiwi is about 400 to 500 EUR, the same territory. Either way it lands at roughly three times the parts cost of an SO-101 (about 130 to 170 EUR), and the difference is base, battery and Pi.

The kiwi drive is one 3x3 matrix

A kiwi drive is three omni wheels 120 degrees apart. Free rollers across each axis let a wheel be dragged sideways while it drives, so the three constraints together leave the chassis all three planar freedoms at once: forward, sideways, yaw. A differential-drive robot has to turn before it moves sideways. LeKiwi does not. The forward model is four lines.

# src/lerobot/robots/lekiwi/lekiwi.py, _body_to_wheel_raw defaults: wheel_radius=0.05, base_radius=0.125
angles = np.radians(np.array([240, 0, 120]) - 90)      # -> 150, -90, 30 degrees
m = np.array([[np.cos(a), np.sin(a), base_radius] for a in angles])

wheel_linear_speeds  = m.dot(np.array([x, y, theta_rad]))   # m/s at the rim
wheel_angular_speeds = wheel_linear_speeds / wheel_radius   # rad/s

The determinant is 0.325, so the matrix inverts cleanly and runs backwards to turn measured wheel speeds into a body velocity. That inverse is how x.vel, y.vel and theta.vel reach the observation. It also says forward speed comes only from the left and right wheels, and yaw is a third of the wheel sum over the base radius.

Then the part nobody documents. Wheel commands become raw ticks at 4096 per revolution, and if any wheel exceeds max_raw = 3000 all three scale down proportionally. 3000 ticks is 263.7 deg/s, or 0.230 m/s at a 0.05 m rim. Push that back through the matrix and you get the real envelope.

That matters when reading a recorded LeRobot dataset. The stored action is the requested velocity before scaling; the state is decoded from what the wheels reported. Wherever the request exceeded the cap, action and state disagree by construction, and no tuning closes that gap.

Six positions, three velocities, one vector

Both observation_features and action_features on the LeKiwi class return the same dictionary. That one decision drives most of what follows.

# both the observation state and the action are this, in this order
(
    "arm_shoulder_pan.pos",
    "arm_shoulder_lift.pos",
    "arm_elbow_flex.pos",
    "arm_wrist_flex.pos",
    "arm_wrist_roll.pos",
    "arm_gripper.pos",
    "x.vel",
    "y.vel",
    "theta.vel",
)

Degrees for the arm is a default aligned with the SO-100 in May 2026 (use_degrees = True). Older LeKiwi datasets used a normalised -100 to 100 range, so check units before trusting a recording from the public directory.

Three ways the base dimensions are not joints

1. They are velocities, so there is nothing to integrate. No pose, no odometry, no map is stored. Integrating x.vel drifts, because omni rollers slip and nothing corrects it. The policy locates itself from pixels alone.
2. State and action are the same quantity. On the arm, state is a measured position and action a target, separated by a real tracking error. On the base they are the decoded and the commanded body velocity, one step apart. A policy that copies state into action scores well on those columns while learning nothing, and the loss curve looks healthy. See loss falls, policy does nothing.
3. They are zero most of the time. The base drives for a second, then holds still while the arm works. Every normaliser has to cope with a spike at zero and thin tails, the shape min-max and mean-std both handle badly.

What changes when you record

Recording is a two-machine affair. A host on the Pi owns the serial bus and the cameras; a client on your laptop owns the leader arm, the keyboard and the dataset writer. ZeroMQ carries commands on 5555 with CONFLATE set, so only the newest survives a backlog, and multipart observations on 5556 with a two-deep queue that sheds stale frames. The host loop is capped at 30 Hz.

1. 1
   Install the lekiwi extra on both machines

   It pulls in the Feetech SDK and pyzmq. Needed on the Pi and the laptop.

   bash

   pip install -e ".[lekiwi]"

2. 2
   Set all nine motor ids

   One control board serves the whole robot, so ids must be unique across arm and base. The helper walks the arm down from 6 to 1, then the wheels from 9 to 7.

   bash

   lerobot-find-port
   
   lerobot-setup-motors \
       --robot.type=lekiwi \
       --robot.port=/dev/ttyACM0

3. 3
   Calibrate the arm. The wheels do not need it

   Wheels and wrist roll count as full-turn motors: offset 0, range 0 to 4095, no interaction. Run it over SSH on the Pi.

   bash

   lerobot-calibrate \
       --robot.type=lekiwi \
       --robot.id=my_awesome_kiwi

4. 4
   Start the host, and give it more than 30 seconds

   connection_time_s defaults to 30 and the loop exits when it elapses.

   bash

   python -m lerobot.robots.lekiwi.lekiwi_host \
       --robot.id=my_awesome_kiwi \
       --host.connection_time_s=3600

5. 5
   Teleoperate from the laptop

   Edit remote_ip first. The leader arm drives the six joints; w, a, s, d drive the base, z and x spin it, r and f step the speed preset.

   bash

   python examples/lekiwi/teleoperate.py

6. 6
   Record episodes

   Set remote_ip, HF_REPO_ID, TASK_DESCRIPTION, NUM_EPISODES (default 2), EPISODE_TIME_SEC (30) and RESET_TIME_SEC (10) at the top. FPS is 30.

   bash

   python examples/lekiwi/record.py

One detail that surprises people later: the default cameras have different shapes. Front is 640 by 480 rotated 180; wrist is declared 480 wide by 640 tall and rotated 90, so LeRobot captures landscape and hands you a portrait frame. In the dataset that is (480, 640, 3) for front and (640, 480, 3) for wrist. Policies resize, but a portrait wrist view crops differently than you expect, and depth cameras are rejected outright: the transport carries colour only. See camera not detected when one never appears.

What changes when you train

Less than you would think for four of the five policies. Nine dimensions are small enough that the modern stacks absorb them silently, and only GR00T N1.7 asks you to describe the vector.

For ACT and SmolVLA you point lerobot-train at the dataset and the shapes follow. A nine-dimensional LeKiwi recording trains with the same command line as a six-dimensional SO-100 one.

lerobot-train \
  --dataset.repo_id=${HF_USER}/lekiwi_pick_and_carry \
  --policy.type=act \
  --output_dir=outputs/train/act_lekiwi \
  --job_name=act_lekiwi \
  --policy.device=cuda \
  --policy.repo_id=${HF_USER}/act_lekiwi

GR00T is the exception, and in two ways. It loads LeRobot v2.0 or v2.1 only, so a v3.0 recording has to be converted down before the loader will touch it (dataset rejected as v3). And it looks up named slices in meta/modality.json and transforms each separately, so a custom robot gets registered under the NEW_EMBODIMENT tag with its config path passed to the fine-tuning entry point.

{
  "state": {
    "single_arm": {"start": 0, "end": 5},
    "gripper":    {"start": 5, "end": 6},
    "base":       {"start": 6, "end": 9}
  },
  "action": {
    "single_arm": {"start": 0, "end": 5},
    "gripper":    {"start": 5, "end": 6},
    "base":       {"start": 6, "end": 9}
  },
  "video": {
    "front": {"original_key": "observation.images.front"},
    "wrist": {"original_key": "observation.images.wrist"}
  },
  "annotation": {
    "human.task_description": {"original_key": "task_index"}
  }
}

"action": ModalityConfig(
    delta_indices=list(range(0, 16)),
    modality_keys=["single_arm", "gripper", "base"],
    action_configs=[
        ActionConfig(rep=ActionRepresentation.RELATIVE, type=ActionType.NON_EEF,
                     format=ActionFormat.DEFAULT),   # arm: delta from current state
        ActionConfig(rep=ActionRepresentation.ABSOLUTE, type=ActionType.NON_EEF,
                     format=ActionFormat.DEFAULT),   # gripper: target position
        ActionConfig(rep=ActionRepresentation.ABSOLUTE, type=ActionType.NON_EEF,
                     format=ActionFormat.DEFAULT),   # base: already a velocity
    ],
)

Normalisation is where mixed units bite

ACT and SmolVLA normalise state and action with mean and standard deviation, Pi0.5 uses quantiles, GR00T defaults to min-max per slice. All of them rescale each dimension independently, which is why nobody has to think about degrees sitting beside metres per second. It works, with one side effect worth naming.

After z-scoring, all nine dimensions contribute roughly equally to the loss. The base dimensions claim a third of the gradient budget even when the base moves in a minority of frames, and their small standard deviation amplifies wheel-feedback noise into large normalised targets. Not a reason to drop the base, but a reason to record episodes where it earns its place and to check generalisation across setups before trusting the result.

Two routes from a LeKiwi to a trained policy

Is the base worth it?

Where the base does not help

The base makes the data problem harder faster than it makes the robot more capable. Manipulation from 50 episodes works because the task is short, the camera fixed and the start state nearly identical each time. Add a base and you have added navigation, with a much larger state space, no pose observation and the same 50 episodes. Expect a policy that manipulates well once it is in the right place and cannot get itself there.

Then latency, where the arithmetic is concrete. The base stops if no command arrives for 500 ms. One policy step costs 20 ms for ACT, 152 ms for GR00T N1.7, 165 ms for GR00T N1.5, 245 ms for SmolVLA and 485 ms for Pi0.5 (inference latency). Send one command per inference and Pi0.5 lands within 15 ms of the watchdog before the network does anything.

The platform limit applies with extra force here. Remote inference over the public internet is viable for slow pick-and-place and not for fast reactive motion. On a mobile base the round trip that makes a grasp hesitant also makes the base overshoot, because a late velocity command keeps executing until the next replaces it. For anything past a demo, put inference on the same LAN as the Pi.

A scope note to close. The desktop client and browser teleoperation here are built around the arm; the LeKiwi base loop, keyboard mapping and ZeroMQ host stay upstream code you run yourself. This side gives you the part after the dataset: a guide per model and arm, rented GPUs by VRAM, and a served checkpoint. If somebody else drives while you build the dataset, the operator side is its own job. Background: the SO-100 hub, the SO-100 complete guide and collecting high-quality VLA data.