Running a Robot Lab on a Small Budget: What It Really Costs

A manipulation lab is three budgets pretending to be one. There is the hardware budget, which people obsess over. There is the data budget, which is mostly your own hours and which nobody costs. And there is the compute budget, which is the one that is genuinely cheap now and that people still overpay for by buying a graphics card. This article puts real numbers on all three, taken from published bills of materials, vendor price pages and papers that were fetched while writing it, and it says where the money leaks first.

The short version: a working single-arm setup that can record a LeRobot dataset and run a trained policy costs a few hundred euros in parts and single-digit dollars per training run. The SO-100 class of arm is what made that true. Everything above that number is a choice you should be able to justify, not a default.

The three budgets, separated

Before any shopping, split the spend. The reason is that the three budgets scale completely differently. Hardware is a one-off with a long tail of breakage. Data is a recurring cost measured in hours of teleoperation. Compute is metered by the minute and is the only one you can turn off entirely between projects.

It helps to anchor against what a funded lab spends. The ALOHA paper states the whole bimanual system costs under $20k, with the ViperX 6-DoF follower arm at around $5600 off the shelf and the smaller WidowX leader at $3300. Mobile ALOHA puts the mobile version at $32k including onboard power and compute. The DROID platform, which 13 institutions used to collect 76k trajectories over 350 hours across 564 scenes, is built on a Franka Panda 7-DoF arm with two Zed 2 stereo cameras, a wrist-mounted Zed Mini and an Oculus Quest 2 for teleop. Those are the numbers you are not paying.

A 3D-printed SO-101 pair replaces the $8900 of ALOHA arm hardware with a bill of materials of $229.88. It is a worse arm. It is also under 3 percent of the price, and for learning imitation learning on tabletop pick-and-place it is enough. That trade is the whole premise of a small-budget lab.

The arm: what 230 dollars actually buys

The SO-ARM100 repository publishes a per-region bill of materials. Below is the US column for the two-arm leader-follower setup, which is the configuration you want if you plan to record data rather than just wiggle a servo. Prices are as published in that README on 2026-08-23; the repo is maintained and the numbers move.

Twelve servos at $13.89 is $166.68 of that $229.88. The arm is essentially a pile of Feetech bus servos with plastic between them, and that is also its failure mode: when something breaks, it is a servo, and a servo is 14 dollars plus a disassembly evening. Budget for two spares from day one. That is the cheapest insurance in the build.

The four arms AY-Robots supports sit at different points on that curve. The parts costs below are the platform's own figures; you can put any two side by side on the arm comparison pages.

Cross-check those against upstream and you get a useful lesson about BOM totals. The Koch v1.1 repository lists $199 for the leader and $278 for the follower in US pricing, so $477 for the pair, against the platform's 250 to 350 EUR for the same arm. The LeKiwi BOM lists $482 US for the 12 V build and $499 for the 5 V build, and states explicitly that it excludes the cost of 3D printing. Region, vendor and what is counted move these totals by a third or more. Treat any published BOM as an order of magnitude, not a quote.

If you have no printer, that is not a blocker and it is also not free. The SO-ARM100 README lists tested printers including the Prusa MINI+, Creality Ender 3 and Bambu Lab machines, with PLA+ at a 0.4 mm nozzle, 0.2 mm layer height and 15 percent infill. It also ships print gauges you check against a real STS3215 servo or a standard Lego brick before committing to a full plate. Vendors selling pre-printed frame kits and fully assembled arms are listed in the same README. Paying to skip a week of tolerance chasing is a defensible line item on a small budget; buying a printer to make one arm usually is not.

Cameras: the line item where money leaks first

This is where small budgets die. Cameras look cheap individually, they are the part people over-buy, and the failure is not financial at first. It is a recording session that silently drops frames and produces a dataset that trains a policy that does not work.

LeRobot's camera layer is deliberately boring. Per the camera documentation, OpenCVCamera covers phones, built-in laptop cameras and USB webcams, RealSenseCamera adds Intel RealSense with depth, and there are ZMQCamera and Reachy2Camera for networked and robot-native streams. Auto-discovery works for the first two:

lerobot-find-cameras opencv   # or: lerobot-find-cameras realsense

# --- Detected Cameras ---
# Camera #0:
#   Name: OpenCV Camera @ 0
#   Type: OpenCV
#   Id: 0
#   Backend api: AVFOUNDATION
#   Default stream profile:
#     Format: 16.0
#     Width: 1920
#     Height: 1080
#     Fps: 15.0

The practical consequence for a budget: two 640x480 webcams at 30 fps on separate controllers beat one 1080p camera, and beat three cameras that fight. Note that the real-robot tutorial does not start you there. Its teleoperation example runs a single camera named front at 640x480 and 30 fps, its record example raises that same single camera to 1920x1080, and only the rollout example drives two streams at once, an OpenCV camera and a RealSense at 640x480. One 1080p stream is precisely the configuration that stops working the moment you add a second camera to the same controller. Two angles is the standard configuration for tabletop manipulation because the end effector needs a close view and the scene needs a wide one.

The host machine, and why it is not a GPU

The computer next to the arm has one job during recording: pull two camera streams and a serial bus at a steady 30 Hz and write them to disk without stalling. That is an I/O problem, not a compute problem. A laptop you already own is the correct answer for most people, and the honest advice is to spend nothing here until something actually stalls.

The Jetson number is worth stating precisely because it is the honest ceiling for local inference. NVIDIA's Orin Nano Super announcement puts the dev kit at $249, down from $499, with 67 sparse TOPS, 33 dense TOPS, 8 GB of LPDDR5 at 102 GB/s in a 7 to 25 W envelope. Meanwhile the Isaac-GR00T repository lists inference as needing one GPU with 16 GB or more of VRAM and fine-tuning as wanting 40 GB or more, recommending H100 or L40 nodes. An 8 GB Orin Nano is under the inference floor for a 3 B vision-language-action model. It is a fine host for ACT, which is about 80 M parameters at 20 ms per action step.

Compute: rent it, and do not round up

This is the part of the budget that got cheap while everyone was not looking. Fine-tuning a VLA on your own data is a few hours of one GPU. Buying that GPU costs more than the arm, the cameras, the host and every spare servo combined, and it will idle 95 percent of the time.

Here are per-hour prices fetched on 2026-08-24 from two vendors that publish them. Runpod's pricing page carries a Community Cloud / Secure Cloud toggle and a per-second view; the rates below are the ones it serves by default. Both marketplaces move, so treat these as an order of magnitude and not a quote.

Two structural details matter more than the headline rate. First, billing granularity: Hugging Face Jobs bills by the minute and only while a job is Starting or Running, with no charge during build, and its default job timeout is 30 minutes unless you raise it. Vast.ai bills per second and offers an interruptible tier it describes as 50 percent or more cheaper, preemptible, and suited to checkpointed batch training. Second, idle time: an instance you forget about is the real budget risk, not the hourly rate.

For scale on what you are not paying: the SmolVLA paper reports that the project consumed approximately 30,000 GPU hours, pretraining for 200,000 steps at a global batch size of 256 across 4 GPUs, on 481 community datasets totalling 22.9K episodes and 10.6M frames. At the 4090 rate above that pretraining bill alone would run into five figures. You are renting the last sliver of that curve, the fine-tuning on your own 30 to 50 episodes.

Costing one real project, end to end

Here is the actual sequence for a first pick-and-place project on an SO-101, with the money and the hours marked. Commands are from the LeRobot SO-101 guide and the imitation learning tutorial as read on 2026-08-23.

1. 1
   1. Parts and printing: about 230 USD, one week

   Order the two-arm BOM, print the frames or buy a printed kit. Install LeRobot and the Feetech SDK. The install is the only software cost in the whole project.

   bash

   pip install -e ".[feetech]"

2. 2
   2. Ports, motor ids and calibration: 0 USD, one evening

   Motors usually ship with a default id of 1, so ids and baudrate are written to EEPROM one motor at a time. Then calibrate both arms so leader and follower agree on joint positions. Skipping calibration is the classic way to burn a whole dataset.

   bash

   lerobot-find-port
   
   lerobot-setup-motors \
       --robot.type=so101_follower \
       --robot.port=/dev/tty.usbmodem585A0076841
   
   lerobot-calibrate \
       --robot.type=so101_follower \
       --robot.port=/dev/tty.usbmodem58760431551 \
       --robot.id=my_awesome_follower_arm

3. 3
   3. Cameras: about 25 to 60 USD, one hour, or one lost afternoon

   Two webcams at 640x480 and 30 fps, on separate USB controllers. Verify with a teleop session before recording anything, because a stream that fails here fails silently later.

   bash

   lerobot-find-cameras opencv
   
   lerobot-teleoperate \
       --robot.type=so101_follower \
       --robot.port=/dev/tty.usbmodem5AB90687491 \
       --robot.id=my_follower_arm \
       --robot.cameras="{front: {type: opencv, index_or_path: 0, width: 640, height: 480, fps: 30}, wrist: {type: opencv, index_or_path: 2, width: 640, height: 480, fps: 30}}" \
       --teleop.type=so101_leader \
       --teleop.port=/dev/tty.usbmodem5AB90689011 \
       --teleop.id=my_leader_arm \
       --display_data=true

4. 4
   4. Record the dataset: 0 USD, two to four hours of your life

   This is the real cost. LeRobot defaults are 50 episodes at episode_time_s=60 with reset_time_s=60, which is 100 minutes of wall clock before any re-records. The tutorial's own advice is at least 50 episodes with 10 per grasp location, cameras fixed, behaviour consistent.

   bash

   lerobot-record \
       --robot.type=so101_follower \
       --robot.port=/dev/tty.usbmodem585A0076841 \
       --robot.id=my_awesome_follower_arm \
       --robot.cameras="{ front: {type: opencv, index_or_path: 0, width: 640, height: 480, fps: 30}, wrist: {type: opencv, index_or_path: 2, width: 640, height: 480, fps: 30}}" \
       --teleop.type=so101_leader \
       --teleop.port=/dev/tty.usbmodem58760431551 \
       --teleop.id=my_awesome_leader_arm \
       --dataset.repo_id=${HF_USER}/record-test \
       --dataset.num_episodes=50 \
       --dataset.single_task="Grab the black cube"

5. 5
   5. Train: 1 to 12 USD, 2 to 6 hours, unattended

   Locally on a card you own, on Hugging Face Jobs by adding --job.target, or on AY-Robots by picking model and dataset in a form. All three run the same trainers.

   bash

   # local
   lerobot-train \
     --dataset.repo_id=${HF_USER}/so101_test \
     --policy.type=act \
     --output_dir=outputs/train/act_so101_test \
     --policy.device=cuda
   
   # same command, rented hardware, billed by the minute
   lerobot-train \
     --dataset.repo_id=${HF_USER}/so101_test \
     --policy.type=act \
     --policy.repo_id=${HF_USER}/my_policy \
     --job.target=a10g-small
   
   hf jobs hardware      # list flavors and prices
   hf jobs cancel <job-id>

6. 6
   6. Run it back: cents, or a pod hour

   Roll the policy out on the arm. On AY-Robots an inference pod is auto-provisioned and destroys itself when idle. Note that ACT has no base model, so this checkpoint only exists because you trained it.

   bash

   lerobot-rollout \
     --strategy.type=base \
     --policy.path=${HF_USER}/my_policy \
     --robot.type=so100_follower \
     --robot.port=/dev/ttyACM1 \
     --task="Put lego brick into the transparent box" \
     --duration=60

Add it up: roughly 230 to 320 USD of hardware, about 12 hours of your time, and under 15 USD of compute for several training runs. The hardware is a one-off. The 12 hours is not, and that is the number people get wrong.

Two ways to get there

# datasets land here by default
ls ~/.cache/huggingface/lerobot/${HF_USER}/record-test

# LeRobot video encoding defaults, worth knowing before you blame the codec:
#   vcodec  = libsvtav1
#   pix_fmt = yuv420p
#   crf     = 30
#   g       = 2    (keyframe every 2 frames)
#   preset  = 12

Where the money is wasted first

Ranked by how often it happens, not by size. Every item here is a thing that looks like an investment and behaves like a tax.

1. A training GPU. At 1 to 3 USD a run on the 24 GB tier, which is the tier a consumer card actually competes with, buying one only pays off after hundreds of runs, and it still cannot hold a 3 B model comfortably. Buy the card for inference next to the robot if you buy it at all.
2. Too many cameras. Three streams contending for USB bandwidth produce worse data than two that do not, and the failure is silent. Two viewpoints is the working default.
3. A depth camera before you need depth. None of the five trainable policies here requires a depth stream. Buy it when RGB is provably ambiguous for your task, not before.
4. 1080p everything. The LeRobot record example does use 1920x1080, but on a single camera, and that is the catch: the resolution the tutorial gets away with on one stream is the one that breaks you on two. Higher resolution costs USB bandwidth, disk, encode CPU and training throughput, and buys very little for tabletop manipulation.
5. A second arm before the first task works. A leader-follower pair is not two robots, it is one recording rig. A second follower is a scaling decision, not a starting one.
6. A 3D printer for one build. Printed frame kits and assembled arms are sold by the vendors listed in the SO-ARM100 README. A printer plus its learning curve is not cheaper for a single arm.
7. Re-recording a dataset because calibration drifted. Free to avoid, expensive to fix. Calibrate, verify with lerobot-replay, then record.
8. Idle cloud instances. The one genuinely unbounded cost in this list. Set a timeout, or use a platform whose pods kill themselves.

There is a matching list of things worth paying for: two spare servos, decent table clamps, a second USB controller (a PCIe card or a different port group, not a hub), and enough light on the workspace that the cameras are not fighting your ceiling lamp. All four together are a small fraction of the arm, and all four prevent a class of failure. If a policy is misbehaving and you cannot tell why, a policy that only works in one setup and loss falls but the policy does nothing are the two pages that usually explain it.

The parts that cost nothing

A surprising amount of a manipulation project can be done for zero. Not as a marketing claim, but because the expensive parts are the ones you can defer.

• Drive a real arm before buying one. The live page streams a physical SO-100 with no signup, queue-based. It answers 'do I actually want to do this' for free.
• Read other people's data. The dataset directory lists public datasets, and datasets can also come straight from a Hugging Face repo id or from your own machine.
• Compare models with published numbers rather than vibes. The arena holds 85 VLA models with 332 benchmark results, each value linked to its paper or model card.
• Learn the pipeline on data you did not record: train your first policy walks the whole flow, and a dataset can come straight from a Hugging Face repo id.
• Get paid instead of paying. The operator page is teleoperation work for people who want the hours without the hardware.

Where a small budget genuinely does not work

Being honest about this is more useful than another table. There are three places where the cheap setup is not a smaller version of the expensive one, it is a different thing.

The first is precision. The ALOHA paper specs its ViperX follower at 5 to 8 mm accuracy with 1 mm repeatability, on an arm that costs around $5600. A printed arm on plastic gearing with position-controlled hobby servos is looser than that, and it drifts with temperature and wear. Tasks that need repeatable sub-millimetre placement are out, and no amount of training data fixes a mechanical tolerance.

The second is throughput. One arm and one operator is about 50 episodes an evening at the documented 60 second episode and 60 second reset. DROID needed 13 institutions and 50 collectors over 12 months for its 76k trajectories. If your research question needs that scale, the bottleneck is people, and no hardware saving addresses it. The third is that a cheap arm makes debugging harder, not easier: when a policy fails you now have to rule out a slipping horn and a drifting calibration before you look at the model. That is a real tax on your time, paid to save several thousand euros, and for most people it is still worth it. Action chunking helps hide some of the jitter, but it does not add mechanical repeatability that the arm never had.

Where to go next

If you are buying hardware, start with the complete SO-100 setup guide and the SO-100 versus SO-101 comparison, since the newer arm is the better build for a few euros more. If you are about to record, read how to collect high-quality VLA training data first; the hours you save there are worth more than anything in this article. And if scale is what you are actually asking about, the DROID dataset writeup shows what 13 institutions and 12 months buys that one arm on a desk cannot.

For the mechanical side, SO-100 getting started and record your first dataset are the two pages that turn a BOM into a working rig. The training docs cover what the trainer actually sends, the policies page compares the five models side by side, and the failure-mode index is the page to bookmark, because on a small budget most of your losses are hours, not euros.