How to train GR00T N1.7 on a LeKiwi

What the base changes, in one paragraph

A LeKiwi is an SO-100 arm bolted onto a three wheel holonomic base. The arm half behaves the way it does on a desk. The base half does three things: it adds commands to every frame of every episode, it moves the cameras while the policy is running, and it removes the table edge as a natural boundary on where the robot can end up. Only the first of those changes the dataset. All three change how you work.

The action vector gets wider

On an SO-100 the action column is six numbers. On a LeKiwi the base contributes its own commands, one per wheel in the usual LeRobot configuration, which makes nine numbers. Some builds expose the base as a body velocity instead of per wheel commands, which is still three extra values. Either way you should open your own meta/info.json and count rather than assuming, because that number determines what will and will not merge with your other datasets.

{
  "codebase_version": "v2.1",
  "robot_type": "lekiwi",
  "fps": 30,
  "total_episodes": 74,
  "features": {
    "observation.state": { "dtype": "float32", "shape": [9] },
    "action": {
      "dtype": "float32",
      "shape": [9],
      "names": [
        "shoulder_pan", "shoulder_lift", "elbow_flex", "wrist_flex", "wrist_roll", "gripper",
        "base_left_wheel", "base_back_wheel", "base_right_wheel"
      ]
    },
    "observation.images.front": { "dtype": "video", "shape": [480, 640, 3] },
    "observation.images.wrist": { "dtype": "video", "shape": [480, 640, 3] }
  }
}

Nine dimensions is not itself a difficulty for GR00T N1.7. The diffusion action head predicts whatever vector it was fine-tuned on, and three more columns cost nothing at training time. The difficulty is that three of those columns move the cameras. On a fixed arm, a change in the image means the world changed. On a LeKiwi, a change in the image usually means the robot moved, and the model has to learn that distinction from your demonstrations alone, because nothing in the data labels it.

Before you start

• A working LeKiwi: the SO-100 arm calibrated in place on the base, and the base drivable
• Both supplies correct, 7.4 V for the arm servos and 12 V for the base
• Cameras firmly mounted to the chassis, because everything is onboard and nothing is on a tripod
• A clear floor area large enough that the robot can be wrong without consequences
• The client installed and paired, with the robot showing online
• A LeRobot v2.1 dataset of at least 50 reviewed episodes

Recording demonstrations when the base moves too

The most useful decision you can make about a first LeKiwi dataset is to forbid simultaneous motion. Drive, stop, then manipulate. Back off only after the gripper has released. One convention, every episode, no exceptions.

Doing both at once is what everyone wants and it is why most first mobile policies do nothing useful. When driving and reaching overlap, the same camera image maps to two very different action vectors depending on what you happened to be thinking at the time. That is genuine ambiguity in the data rather than noise, and the model resolves it either by committing to one behavior or by blending them into a motion that neither drives nor reaches. Neither outcome is fixable with more steps.

• Vary the starting pose of the robot, not only the object. If you always begin a meter away and square on, that is the only approach the policy can produce
• Keep the floor consistent. A policy trained on a mat and evaluated on tiles is looking at a different world
• The rule about not moving the camera becomes a rule about not moving the mount. Check the front camera has not rotated in its bracket between sessions
• Drive at a speed you can repeat. The policy reproduces your velocity profile, and fast driving also motion blurs the frames it will later have to recognize
• Expect longer episodes and therefore a much larger dataset for the same episode count. Budget upload time accordingly

How many episodes, honestly

Fifty is the floor for GR00T N1.7 as a model, and it is the point where the fine-tune justifies an A100. It is not the number that makes a mobile task work. Fifty LeKiwi episodes will teach the manipulation reasonably and the navigation barely, because the space of where the robot was standing when the episode began is much larger than the space of where a cube was on a table.

The workable plan is to treat this as two data problems in sequence. First get the manipulation reliable from a small set of standing positions, with the base doing something trivial or nothing at all. Confirm that on the hardware. Then add episodes that widen the approach, keeping the manipulation demonstrations you already have. Extending a dataset that works beats starting again with an ambitious one that does not.

v2.1 is required and the rejection is expensive here

GR00T N1.7 accepts LeRobot v2.1 and rejects v3.0. The rule is the same as on every other arm, but the cost of hitting it is higher on a LeKiwi because your dataset is several times larger. You discover the problem after uploading all of it, and you discover it as a job that reaches RUNNING, produces no loss values at all, and turns FAILED inside a couple of minutes with a message about dataset metadata rather than about the version.

Check codebase_version in meta/info.json before the upload starts. On a mobile dataset that five second check can save an hour of re-uploading over a home connection.

Start the run

1. 1
   Confirm the action width in the dataset preview

   Before selecting anything, open the dataset and look at the feature schema. Nine columns where you expect nine, and wheel columns that actually vary across episodes. Wheel columns stuck at zero mean the base was never commanded during recording, which turns your mobile dataset into an expensive stationary one.

2. 2
   Select the dataset in the Training page

   It appears once processing finishes, which takes longer for LeKiwi datasets than for tabletop ones simply because there is more video. The card shows the episode count you should be checking against your own notes.

3. 3
   Pick GR00T N1.7

   The model list shows it with the A100 80 GB tier. Nothing about the extra action dimensions changes the tier or the model choice, and N1.5 remains only a reproduction tool for older projects.

4. 4
   Review the hyperparameters

   Batch size 32, learning rate 1e-4, 20 000 steps, gradient accumulation 1, plus the save steps field. GR00T offers no seed. A wider action vector is not a reason to change any of these, since none of them scales with action dimensionality.

5. 5
   Start the run and expect the upper half of the time range

   Larger video files mean more data loading per step, so LeKiwi runs tend toward the longer end of the estimate rather than the shorter one. That shows up as GPU utilization that is not pinned at full, and there is nothing to fix about it.

6. 6
   Watch loss and GPU telemetry

   A clear early drop means the data loaded. Flat from the start means it did not. Utilization, VRAM, temperature and power on the same page tell you whether the card is working or waiting on the data pipeline.

7. 7
   Take several checkpoints into evaluation

   Mobile policies vary more between checkpoints than tabletop ones, because there is more to get subtly wrong. Save steps controls how many candidates you have, and having three to test is worth the storage.

Hyperparameter defaults

What it costs and how long it holds the card

The A100 80 GB tier costs 1.20 to 2.00 USD per hour on the pool, and a default 20 000 step run lands between 3 and 6 hours, so about 4 to 12 USD in total. On a LeKiwi, expect to sit in the upper part of that band: the video volume per episode is higher and data loading, not the model, is what sets the pace.

Against a robot that costs roughly 400 to 500 euro to build, a run is negligible in money and significant in calendar time. The scarce resource is floor space and your patience for resetting a mobile robot between episodes, so make each dataset revision deliberate.

Evaluating a policy that can drive away

Everything about evaluating a mobile policy is more hazardous than the tabletop case for the obvious reason. The first attempts should happen with the robot up on a block, wheels free and touching nothing. You see the wheel commands the policy produces without the robot acting on them, and you catch a base that wants to drive backwards into your foot for free.

1. First attempts on a block, wheels spinning in the air, arm folded
2. Then on the floor in a bounded area with no cables to run over and nothing breakable in reach
3. Never on a table. A holonomic base has no notion of an edge and no reason to stop at one
4. Hand on the power for every attempt until the success rate is one you would bet on
5. Keep people out of the run out area, including the part of it the robot only reaches when the policy is wrong

Then run the twenty attempt protocol, and score three things separately rather than one: did it arrive at the object, did it grasp, did it complete the task. A policy that navigates well and never grasps and a policy that grasps well and never arrives both score zero in a single success column, and they need completely different additional data. Physical success rate is still the only metric that counts, but on a mobile robot it is worth three columns instead of one.

Troubleshooting

• Loss plateaus and the policy is weak: check whether your demonstrations were consistent about the order of driving and manipulating. Inconsistent ordering is the most common cause on this robot, and it cannot be trained away.
• Policy freezes mid-motion: the observation is outside the training set, and on a mobile robot the usual reason is a standing position you never demonstrated from. Note where it stopped and record from there.
• Works in one lighting condition only: onboard cameras see more of the room than a tabletop rig does, so the illumination varies across the floor area as well as across the day. Record a second block in the other condition and train on the union.
• Gripper never closes: check that the base actually stops before the arm reaches. A policy that grasps while still creeping forward misses consistently, and the fix is in the demonstrations rather than in the gripper.
• Dataset rejected within minutes: codebase_version says v3.0. Convert to v2.1 and re-upload, and check before the upload next time given the file sizes involved.
• The robot drives past the object and keeps going: your episodes never contain a clean stop. If you always began manipulating while still rolling slightly, there is no example of the base coming to rest, so the policy has nothing to imitate.
• The base drifts sideways over a long episode: a wheel that slips or a mount that has loosened. This is mechanical, it shows up in the data as commanded motions that did not happen, and it will teach the policy to over-correct.

Frequently asked questions