Warehouse Picking With Cheap Arms: The Throughput You Get

A published pick-and-place cycle on an SO-100 takes 9.7 seconds. That figure comes from the SmolVLA paper, measured over ten trials with the cube starting in five different positions, with the model running in asynchronous mode. Synchronous mode took 13.75 seconds for the same task. Those two numbers are the honest starting point for any conversation about warehouse picking on cheap hardware, because everything else people say about low-cost arms is either a demo video or a press release.

9.7 seconds per cycle is about 371 attempts per hour if the arm never stops moving. A human order picker runs 400 to 600 picks per hour. A production piece-picking cell quotes a three second cycle. A packaging delta robot does a 25/305/25 mm cycle in 0.36 seconds with a 1 kg payload. So the low-cost arm is not off the chart. It is on the chart, at the bottom of it, on a much easier task than any of the others were measured on. This article works through where exactly it lands and what the gap is made of.

Everyone publishes a different picks-per-hour

Picks per hour is the metric warehouses use, and it is close to useless without the conditions attached. Mean picks per hour (MPPH) as Berkeley uses it counts successful grasps per hour over a bin-clearing run, so failures already cost you throughput. A vendor machine rate counts the arm cycling between two totes with nothing going wrong. A challenge score counts items moved inside a fixed time window. Here are the figures I could verify, each with what it actually measured.

Read the fourth column before the second. The delta robot is fast because the item arrives in a known pose and the arm never has to decide anything. Dex-Net 4.0 and the challenge entries are slow because they are solving perception in clutter. The SO-100 number sits near the challenge entries while doing far less work, which tells you the bottleneck on cheap hardware is not the same bottleneck as in a warehouse.

What an SO-100 class arm actually is, next to the alternatives

The interesting thing about the SO-100 spec sheet is that there is no spec sheet. The build repository lists servos, gear ratios and prices. It does not publish a payload, a reach, a repeatability figure, a duty cycle or an ingress rating, because the arm was designed as a research and teaching platform, not as a machine you buy against a requirement. Compare that to what the two industrial reference points publish.

The row that ends the conversation for most warehouse deployments is the safety row, not the payload row. A UR5e ships 21 configurable safety functions certified to EN ISO 13849-1 PLd Category 3. An SO-100 ships none, because it is six hobby servos on a serial bus. You cannot put it next to a picker without a risk assessment that concludes it cannot hurt anyone, and the honest way to reach that conclusion is a fence or a cell.

There is no payload figure, so do the arithmetic yourself

The build repository does give you one number to work from: the 7.4 V STS3215 has a stall torque of 16.5 kg.cm measured at 6 V, while the 12 V version is rated 30 kg.cm. Stall torque is not usable torque. A servo held near stall heats up and either derates or dies, so plan on a fraction of it. Reach is not published either, so measure your own arm.

# Static payload budget for the shoulder servo of a 7.4 V SO-100.
# Only input taken from a published source:
#   SO-ARM100 README: 7.4 V STS3215 stall torque 16.5 kg.cm (measured at 6 V).
stall_kgcm = 16.5

# Everything below is an assumption you should replace with your own measurement.
duty_fraction = 0.30          # what you dare hold continuously without cooking the servo
lever_cm      = 25.0          # horizontal shoulder-axis to gripper distance, arm extended

usable_kgcm = stall_kgcm * duty_fraction        # 4.95 kg.cm
payload_kg  = usable_kgcm / lever_cm            # 0.198 kg

print(f"{payload_kg*1000:.0f} g at full extension, BEFORE subtracting the mass")
print("of the forearm, wrist, gripper and cable that hang off the same joint.")

Under 200 g at full extension, before the arm carries its own forearm and gripper. In practice that means small parts, empty boxes, blister packs, cable ties and lab samples. It does not mean a 500 g shampoo bottle, and it certainly does not mean a case. If your pick list has a mass distribution, plot it before you plan anything else. The SO-100 against SO-101 comparison goes through where the newer arm helps, and it is mostly assembly and smoothness rather than load.

Cycle time is set by your demonstrations, not by your GPU

This is the part people get backwards. A policy trained by imitation learning moves at the speed of the data it was shown. If you teleoperated the demonstrations at a comfortable human pace, the policy reproduces that pace. Buying a faster card does not make the arm move faster; it only shortens the pause between action chunks.

The five policies you can train differ a lot in inference latency per action step, but action chunking amortises that cost. One forward pass produces a whole sequence of actions, which the arm then plays out at the recording frame rate. The table below shows what each model's latency costs as a share of a 50-action chunk played at 30 fps, which is the LeRobot async default.

Two readings follow from that column. First, none of these models is latency-bound for a slow pick cycle: even Pi0.5 finishes the next chunk with 70 percent of the current chunk still queued. Second, Pi0.5 is the one where a network hop starts to matter. Add 100 ms of public-internet round trip and it is using 35 percent of the window. The side-by-side policy comparison has the rest of the numbers.

So if you want a shorter cycle, the lever is the data. Record demonstrations faster, at the edge of what you can teleoperate cleanly. The cost is that fast motion produces motion blur and fewer frames per unit of travel, which makes the task harder to learn. There is a real trade-off there, and the data collection guide covers how to find the edge without falling off it.

Measure your own cycle before you trust anyone's number

Everything above is somebody else's cell, gripper and object. The only number that matters for your pick list is the one you measure. This is the shortest honest path from a bare arm to a cycle time, using the current LeRobot command-line tools as they exist in the repository's docs today.

1. 1
   Find the port and set the servo IDs

   Every STS3215 leaves the factory with the same bus ID, so you write IDs once, per arm. Run the port finder with the arm unplugged, then plugged in, and it tells you which device appeared.

   bash

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

2. 2
   Calibrate both arms

   Calibration writes the joint limits and zero offsets to a file keyed by --robot.id. Skip it and the policy will learn your offsets as part of the task, which is one of the classic reasons a policy only works in one setup.

   bash

   lerobot-calibrate \
       --robot.type=so101_follower \
       --robot.port=/dev/tty.usbmodem58760431551 \
       --robot.id=picker_follower
   
   lerobot-calibrate \
       --teleop.type=so101_leader \
       --teleop.port=/dev/tty.usbmodem575E0031751 \
       --teleop.id=picker_leader

3. 3
   Record the pick, timed to your actual cycle

   The defaults are --dataset.episode_time_s=60, --dataset.reset_time_s=60 and --dataset.num_episodes=50, which is 100 minutes of wall clock. If your pick takes 12 seconds, cut the episode to 20 s and the reset to 10 s and you record the same 50 episodes in 25 minutes.

   bash

   lerobot-record \
       --robot.type=so101_follower \
       --robot.port=/dev/tty.usbmodem585A0076841 \
       --robot.id=picker_follower \
       --robot.cameras="{ top: {type: opencv, index_or_path: 0, width: 640, height: 480, fps: 30}, wrist: {type: opencv, index_or_path: 1, width: 640, height: 480, fps: 30} }" \
       --teleop.type=so101_leader \
       --teleop.port=/dev/tty.usbmodem575E0031751 \
       --teleop.id=picker_leader \
       --dataset.repo_id=${HF_USER}/tote-transfer \
       --dataset.single_task="Pick the part from the left tote and drop it in the right tote" \
       --dataset.num_episodes=50 \
       --dataset.episode_time_s=20 \
       --dataset.reset_time_s=10 \
       --dataset.fps=30

4. 4
   Check the cadence report before you train

   lerobot-record paces the loop at --dataset.fps and prints what it actually achieved, per episode and for the session. If your effective cadence is well under target, the dataset already encodes stalls that the policy will learn to imitate.

   text

   Cadence (episode 0): 29.88 Hz vs 30 Hz target - 600 ticks, 20.0 s measured
     8/599 ticks over the 33.3 ms budget (work mean 18.4 ms, worst 45.1 ms)

5. 5
   Train, then roll out for a fixed duration and count

   lerobot-rollout takes a --duration in seconds. Run it for 600 s, count the successful transfers, and multiply by six. That is your picks per hour, measured the same way the benchmarks above measure theirs.

   bash

   lerobot-train \
     --dataset.repo_id=${HF_USER}/tote-transfer \
     --policy.type=smolvla \
     --policy.device=cuda \
     --policy.repo_id=${HF_USER}/tote-policy
   
   lerobot-rollout \
     --strategy.type=base \
     --policy.path=${HF_USER}/tote-policy \
     --robot.type=so101_follower \
     --robot.port=/dev/tty.usbmodem585A0076841 \
     --task="Pick the part from the left tote and drop it in the right tote" \
     --duration=600

6. 6
   Repeat with the async stack and compare

   Start the policy server, point the robot client at it, and run the same 600 s window. The delta between the two runs is your version of the 13.75 s to 9.7 s result.

   bash

   # terminal 1, on the machine with the GPU
   python -m lerobot.async_inference.policy_server \
        --host=127.0.0.1 \
        --port=8080
   
   # terminal 2, on the machine holding the arm
   python -m lerobot.async_inference.robot_client \
       --server_address=127.0.0.1:8080 \
       --robot.type=so101_follower \
       --robot.port=/dev/tty.usbmodem585A0076841 \
       --robot.id=picker_follower \
       --policy_type=smolvla \
       --pretrained_name_or_path=${HF_USER}/tote-policy \
       --policy_device=cuda \
       --actions_per_chunk=50 \
       --chunk_size_threshold=0.7 \
       --task="Pick the part from the left tote and drop it in the right tote"

If the arm sags between cycles or a joint stops short of where the demonstration went, stop and fix the hardware before you blame the policy. The failure-mode pages for an arm that twitches then sags and for a gripper that will not close cover the two that eat the most time on a picking task, because both look exactly like a bad policy from the outside.

Two routes to the same measured number

Where the gap actually is

Notice which of those are hardware and which are evidence. The payload, the brakes and the safety functions are physics and certification, and no amount of training fixes them. The cluttered-bin gap is an evidence gap: it may well close, and the model arena, which tracks 85 VLA models across 332 benchmark results with every value linked to its paper or model card, is where you would see it close first.

The picking work a cheap arm does fit

Rather than asking whether a 130 EUR arm can replace a picker, ask which jobs have the shape it is good at: light parts, a fixed station, a slow rate, a human nearby anyway, and no consequence if a cycle fails. There are more of those in a real building than people expect.

• Kitting light components into a tray. Fixed geometry, one SKU per run, parts under 200 g. This is the shape the published results actually match.
• Feeding a test rig or an inspection station. The rate is set by the instrument, not the arm, and it is usually one item every 20 to 60 seconds.
• Sample handling in a lab. Small, light, repetitive, already inside a fume hood or an enclosure, so the safety question is answered by the room.
• Proving a task is learnable before buying a cell. Record 50 episodes, train, roll out for ten minutes, count. That answers the feasibility question for the price of a weekend.
• Collecting demonstration data for a policy you intend to run on better hardware later. The cross-embodiment argument is that the data has value beyond the arm that recorded it.
• Training and evaluating operators. A bench arm is a cheap way to find out who can teleoperate cleanly before you put them on real equipment.

What all six have in common is that they do not need the arm to be reliable in the industrial sense. They need it to be cheap enough that a 20 percent failure rate is an annoyance rather than a line stoppage. A vision-language-action model on a 130 EUR arm is a good answer to a feasibility question and a bad answer to a throughput question.

What the experiment costs

The arm is not the expensive part, and neither is the training. Both are rounding errors against the cost of a single day of somebody's time integrating anything.

Five runs to find hyperparameters that work is 15 USD on the small tier. That budget is the actual argument for cheap arms in picking research: not that they will run your warehouse, but that finding out costs less than the meeting where you discuss whether to find out. The training documentation covers what the form sends, and the three ways to start without a robot covers the case where you do not have an arm on the bench yet.

What would have to change

If you want to know whether this gets better, watch four things rather than the demo videos. First, payload: a 12 V servo variant already exists at 30 kg.cm stall against 16.5, and a redesign around it moves the ceiling without changing the software. Second, cluttered-bin results on low-cost hardware, which is where the published evidence stops today. Third, whether async inference plus faster demonstrations pushes the measured cycle below about 6 seconds, which would put a single station near 600 attempts per hour. Fourth, safety, which is the one that cannot be solved by better models and will decide whether any of it ever leaves a fenced cell.

None of that is close. It is also not the reason to ignore the hardware. The reason to keep an SO-100 on the bench is that it turns an argument about feasibility into a measurement, for the price of a takeaway meal. If you want to see one move before you buy anything, there is a physical arm streaming with no signup, and the full SO-100 setup guide covers the build end to end.

Questions people actually ask