- Trainer key
- smolvla
- GPU tier
- RTX 4090 or any card with 24 GB
- Inference
- about 245 ms per action step
- Batch size
- 2, gradient accumulation 8
- Learning rate
- 1e-4
- Steps
- 20,000
- Dataset format
- LeRobot v2.1
- Typical run
- 2 to 5 hours, about 1 to 3 USD
- Servos
- Feetech STS3215 bus servos
- Servo voltage
- 7.4 V for the arm, 12 V for the base
SmolVLA trains on LeKiwi recordings with the same defaults as any other arm, batch size 2, learning rate 1e-4, 20 000 steps and gradient accumulation 8 on a 24 GB card, because the trainer simply learns whatever action dimensions your dataset contains. The work is in the data: the holonomic base adds dimensions on a different scale from the joints, the onboard camera moves within every episode, and at roughly 245 ms per action step a rolling base travels between decisions.
What a mobile base changes about the problem
A LeKiwi is an SO-100 arm, five joints plus a gripper on Feetech STS3215 servos, bolted to a three-wheel holonomic base. From the trainer point of view this is unremarkable: a LeRobot v2.1 dataset has whatever action dimensions it has, and SmolVLA learns to predict all of them. You will not change a single hyperparameter because of the base.
From the data point of view it is a different task category. The policy now decides, at every step, both where to put the gripper and where to put the robot. Those two decisions are coupled, because driving changes what the camera sees, and what the camera sees is the entire input.
| Assumption that holds on a static SO-100 | What it becomes on LeKiwi |
|---|---|
| Never move the camera between recording and inference | The camera moves constantly by design. The invariant is the mount and the environment, not the viewpoint. |
| Vary the object position across episodes | Vary the object position and the robot start pose. The second one is now the larger source of variation. |
| The action vector is six joint values | Six joint values plus base commands, on a different scale and describing a different kind of quantity. |
| An episode is ten to twenty seconds of arm motion | An episode is a drive phase followed by a manipulation phase, and it is longer. |
| One 7.4 V supply | A 7.4 V arm and a 12 V base on the same machine. |
LeKiwi carries 7.4 V for the STS3215 arm servos and 12 V for the base. Those are the two numbers you must never swap, because 12 V into an STS3215 destroys it in seconds. Use physically different connectors if your build allows it, and label both anyway. This is one of the few mistakes on this platform with no software recovery.
Demonstrating with a base in the loop
The standing advice for a static arm is to fix the camera and never touch it again. On LeKiwi the camera rides the robot, so that advice needs rewriting rather than repeating. What has to stay constant is the mount, the lens and the environment. The viewpoint is supposed to move, and the policy has to learn what a good approach looks like from the inside.
- Split every episode into a drive phase and a manipulation phase, and demonstrate them that way every time. Consistency between episodes matters more here than on a static arm, because there are more ways to be inconsistent.
- Stop the base before you grasp. At roughly 245 ms per action step, a base that is still coasting when the close command lands has moved between the decision and the action, and near misses become systematic rather than occasional.
- Vary the robot start pose across episodes, not just the object. Approaching the same target from three different directions is what teaches the policy that the target is a thing in the world rather than a region of the image.
- Drive slowly and evenly. The policy learns your velocity profile along with everything else, and a jerky demonstration produces a robot that lurches toward the table.
- Keep the drive phase short enough that manipulation is not a rounding error in the episode. If eighty percent of your frames are hallway, eighty percent of the training signal is driving.
Thirty episodes is the point where SmolVLA becomes useful, and that is genuinely lower than ACT, GR00T N1.7 or Pi0.5, all of which want 50 or more. On LeKiwi each episode carries more world in it, so thirty covers proportionally less of the variation you care about. Treat thirty as the number that gets you a verdict, and plan for the upper end before you expect reliability.
Task strings for a robot that has to go somewhere first
SmolVLA is language conditioned, so every episode carries a sentence and every inference call passes one. On a mobile robot the temptation is to put the navigation goal in the sentence. Keep it to something the robot can actually see: "drive to the table and pick up the red cube" is a reasonable single string for a task where the table is visible from the start pose. "Go to the kitchen" is not learnable from thirty episodes, because nothing in the observation distinguishes a kitchen instruction from any other.
Where language earns its place on this hardware is destination selection. Thirty episodes of bringing the cube to the bin and thirty of bringing it to the box, recorded in the same room, give one policy two behaviors you pick between with a sentence. On a static arm that is convenient. On a mobile robot it is close to the whole point, since the alternative is a separate policy per destination.
# meta/episodes.jsonl from a two-destination LeKiwi dataset
{"episode_index": 0, "tasks": ["drive to the table and put the cube in the bin"], "length": 1140}
{"episode_index": 1, "tasks": ["drive to the table and put the cube in the bin"], "length": 1207}
{"episode_index": 30, "tasks": ["drive to the table and put the cube in the box"], "length": 1183}
{"episode_index": 31, "tasks": ["drive to the table and put the cube in the box"], "length": 1096}Recording and starting the run
- 1Register the robot and calibrate the arm
Add the LeKiwi on /robots, pair the client, and calibrate. Calibration covers the arm joints. The base is commanded rather than posed, so what you verify there is that driving responds correctly in every direction the holonomic base supports.
- 2Record three episodes and inspect the action channels
Before committing to thirty, upload three and open the dataset preview. You are confirming that the base commands are present in the recorded actions and that they change during the drive phase. A dataset that captured only the arm will train perfectly well and produce a policy that cannot move the robot.
- 3Record the real set with varied start poses
One task string per task, robot start pose varied across the reachable area, base stopped before every grasp, and failures discarded during review rather than kept for completeness.
- 4Open Training, pick the dataset, pick SmolVLA
The parameter form redraws per model, and the six fields it offers for SmolVLA are the ones described in the table below. Nothing on that form is base-aware, and nothing needs to be.
- 5Fix the seed and start it
Mobile datasets change more between revisions than static ones, because you are still working out how to demonstrate. A fixed seed is what lets the next run be a comparison instead of an anecdote.
- 6Check the first log lines before walking away
Spot capacity on the 24 GB tier means a wait before the first metrics. Once loss prints, confirm it is falling. A LeKiwi dataset is larger than a static one, so a loading problem is more likely and more expensive to sleep through.
Defaults, and the two rows that are different here
| Setting | Default | Change this when |
|---|---|---|
| Batch size | 2 | Leave it. The limit is 24 GB of VRAM and the vision tower, and longer episodes do not change what one sample costs. |
| Learning rate | 1e-4 | Loss spikes and does not settle after one halving. On mobile data, also suspect episodes where the base was driven hard enough to blur the camera. |
| Steps | 20 000 | LeKiwi episodes carry many more frames each, so 20 000 steps makes fewer passes over your demonstrations than the same run on a static arm. If loss is still clearly falling at the end, extend the schedule before you add episodes. |
| Gradient accumulation | 8 | Never on a first run. Two times eight is the effective batch of 16 that the default learning rate assumes. |
| Seed | yours to set | Every time. Mobile demonstrations vary more between sessions than static ones, so you need the run-to-run variance held still to see whether a technique change helped. |
| Log frequency | as shipped | You are running a short probe and the curve is too sparse to judge. Logging only, no effect on the result. |
Seed and log frequency belong to the lerobot family: ACT, SmolVLA and Pi0.5. GR00T has no seed field at either entry point, which is worth knowing before you build a comparison workflow around one.
Cost is the same 24 GB tier as every other SmolVLA run, 0.30 to 0.60 USD per hour across 2 to 5 hours, so roughly 1 to 3 USD. Expect the upper half of that range, since a LeKiwi dataset holds substantially more frames per episode than a tabletop one. The A100 tier the 3 billion parameter models require is 1.20 to 2.00 USD per hour over 3 to 6 hours, about 4 to 12 USD.
The probe run, which matters more on a mobile base
Using a cheap SmolVLA run to judge a dataset is good practice everywhere and close to mandatory here. Mobile datasets are expensive to record, easy to get subtly wrong, and slow to re-record. A run that costs one to three dollars and answers whether the data is learnable is the cheapest instrument you have.
The verdict is more informative than on a static arm, because the two halves fail separately. If the robot drives roughly toward the target and then flails at the object, the drive data is fine and the manipulation data is thin. If it manipulates competently but only when it happens to start in the right place, the opposite. Either reading tells you which half of the next recording session to spend your time on, and neither requires an A100 to obtain.
A single success rate on a mobile manipulation task hides which half is broken. Record two columns from your very first evaluation: did it get to the object, and did it pick the object up. The combined number is the one you report, the split is the one you act on.
Deploying and evaluating a mobile policy
Deployment is the same mechanism as any other policy, with more ways for the first attempt to go badly. A static arm that misbehaves waves at the air. A mobile robot that misbehaves drives into furniture with an arm extended.
- First run with the wheels off the floor, on a block or a box. You see the full intent of the policy, both drive commands and arm motion, with no distance covered. This costs two minutes and catches the policies that would have crossed the room sideways.
- Then clear the floor properly. Nothing fragile, nothing at ankle height, and a person within reach of the power the whole time.
- Twenty attempts from varied start poses, scored in two columns, approach and grasp, written down as they happen.
- Compare two or three checkpoints from the back half of the run under the same protocol before concluding anything about the dataset.
- Watch for the base creeping during manipulation. A base that drifts while the gripper closes is the most common way a policy that learned both halves still fails at the join between them.
At roughly 245 ms per action step, the practical speed limit for driving is set by how far the robot travels in a quarter of a second. That is a comfortable walk for a slow base and a real problem for a fast one, and it is a further reason to demonstrate at a modest speed. The policy will drive at roughly the speed you showed it.
Troubleshooting mobile manipulation
| Symptom | What it usually means on a base | What to change |
|---|---|---|
| Loss falls cleanly but nothing useful happens | The action vector mixes base commands with joint positions on different scales, and one group dominated the training signal. Usually the base wins, because it moves in most frames. | Look at how many frames per episode are driving versus manipulating. Shorten the drive phase in future recordings, or record a second dataset with the robot already parked and train the manipulation half on its own. |
| Changing the instruction changes nothing about the behavior | On a mobile robot this is almost always a single-string dataset. With one destination, the sentence carried no information during training and the model learned to disregard the text entirely. | Add a second destination as its own block of thirty or more episodes in the same room, then retrain. One string plus one string is a language task. One string alone never was. |
| Works in the lighting it was recorded in, fails otherwise | Harder to avoid here, because the robot drives through several lighting conditions inside a single episode and your thirty episodes probably drove through the same ones in the same order. | Record a block at a different time of day over the same route. Varying the light along the path is worth more than varying anything else you could add at that cost. |
| The grasp is mistimed at the end of the approach | Three effects stack: the base is still settling, the camera is still moving, and the close command was committed about a quarter of a second earlier at 245 ms per step. | Demonstrate a deliberate stop before every grasp. Arrive, pause with the base at rest, then approach and close. The pause is what gives the policy a stable observation to trigger on. |
| The robot drives well but never commits to the approach | The observation at the decision point is outside anything in the training set, typically because you always started from the same side of the room. | Record ten episodes starting from the poses where it stalls. Targeted episodes at the failure point beat a general increase in dataset size, and on a mobile robot they are also much cheaper to collect. |
When the bigger model is worth it
Extra action dimensions and long episodes are exactly the conditions where model capacity starts to matter, so LeKiwi hits the SmolVLA ceiling sooner than a tabletop task does. The signal is the same as everywhere: a success rate that stops responding to more data. GR00T N1.7 takes the same LeRobot v2.1 dataset, wants 50 or more episodes, runs at about 152 ms per action step, and costs 4 to 12 USD per run on an 80 GB card. /train/groot-n1-7-on-lekiwi covers that step.
Before spending it, make sure the failure you are escalating is a capacity failure and not a data failure. /policies/smolvla describes where this model genuinely runs out, and /compare/act-vs-smolvla covers the other option on the cheap tier, which for a mobile robot mostly comes down to whether you need language at all.
Does the trainer need to be told about the mobile base?▾
No. SmolVLA learns whatever action dimensions the dataset contains, so the base is simply more columns. There is no base setting on the training form and none is needed. What the base changes is the data you feed it and the way you evaluate the result.
Should I train one policy for driving and one for manipulating?▾
It is a legitimate engineering answer and often the pragmatic one. If your approach is reliable enough to script, script it and learn only the manipulation, which shortens episodes and concentrates the training signal where the difficulty actually is. A single end-to-end policy is the more interesting result, not automatically the more useful one.
Can I bootstrap from an SO-100 dataset since LeKiwi uses the same arm?▾
Not into one dataset. The action spaces differ, so SO-100 episodes have no base columns and cannot be merged with LeKiwi episodes. The arm hardware being identical helps you with mounting and calibration, not with data reuse.
How many episodes do I actually need?▾
Thirty gets you a verdict on the data, which is lower than the 50 that ACT, GR00T N1.7 and Pi0.5 all want. Reliability on a mobile task takes more than a static one does, because each episode covers more variation and therefore samples it more thinly. Plan to record in blocks and let the probe runs tell you when more data has stopped helping.
Is 245 ms per action step a problem for driving?▾
It sets your speed limit. The robot travels for roughly a quarter of a second between decisions, so a fast base outruns the policy and overshoots. Drive slowly during demonstrations, since the policy reproduces the velocity profile you showed it, and stop the base entirely before any grasp.
What supplies does a LeKiwi need?▾
7.4 V for the STS3215 arm servos and 12 V for the base. Never cross them. Twelve volts into an arm servo destroys it in seconds, and it is the single most expensive mistake available on this hardware.
The full tutorial chain lives under /learn.