A First Week With a Robot Arm: An Honest Day-by-Day Plan

What a first week actually looks like

Most first-week guides for a low-cost arm are written backwards. They start from the finished demo, walk you through the commands that produced it, and quietly leave out the three evenings that went nowhere. This one is written forwards. It follows the same order you will actually hit it in: parts, print, motor ids, assembly, calibration, teleoperation, recording, training, and the first rollout that does not work. For each day there is a point where a predictable number of people stop, and naming that point in advance is most of what makes the difference.

The hardware is the SO-100 and its successor the SO-101, both built around Feetech STS3215 bus servos. The software is LeRobot. Everything below is checked against LeRobot v0.6.1, released 3 August 2026, and against the SO-ARM100 repository as it stood in August 2026. Upstream moves fast enough that command names change between releases, so if a flag does not exist for you, check which version you installed before assuming the article is wrong.

Before day one: the order that decides the week

The single most common way to lose a week is to order the wrong servos, and which servos are wrong depends on which arm you are building. The bill of materials on the front page of the SO-ARM100 repository is the SO-101 one, and it is not twelve identical motors: it lists seven STS3215 units with 1/345 gearing, two with 1/191 and three with 1/147, because the SO-101 leader has to be back-drivable by a human hand while the follower needs holding torque. That list totals $229.88 in the US and EUR 226.30 in the EU, with a single follower arm at $121.94. The older SO-100 list, which the repository now marks as deprecated, has the simpler shape: twelve identical STS3215 servos for the pair at $232 and EUR 244, or six at $123 and EUR 128 for a single follower, with the leader made back-drivable by removing its gears rather than by buying different ones. AY-Robots quotes the SO-100 at roughly 110 to 150 EUR in parts and the SO-101 at 130 to 170 EUR, which lands in the same place once you add local shipping.

If you are choosing between the two arms, read SO-100 against SO-101 before ordering rather than after. The SO-ARM100 repository now marks its own SO-100 documentation as deprecated and points new builders at the SO-101, which the same README describes as having improved wiring, updated motors for the leader arm and no gear removal. AY-Robots still treats the SO-100 as its reference arm because so many of them exist, but if you are buying parts today there is very little reason to build the older one.

Day 1: print, and check the print before you trust it

The STL files ship pre-oriented so that a whole arm prints from a single file, with variants for a 220 x 220 mm bed and a 205 x 250 mm bed. The tested settings are PLA+, a 0.4 mm nozzle at 0.2 mm layer height (or 0.6 mm at 0.4 mm), and 15 percent infill. The repository does not publish an estimated print time, which is the honest answer: it depends entirely on your printer, and the printer is busy rather than you.

Do the boring inventory on day one too. Lay out the motors and confirm the gear ratios are what you ordered, count the M2x6 and M3x6 screws, and confirm you have a Phillips #0 and #1. The upstream parts list recommends exactly those two sizes, and a stripped M2 head in a motor holder is a far worse afternoon than a trip to a hardware shop.

Day 2: motor ids, the step that eats an evening

Every servo on the bus needs a unique id, and every brand-new STS3215 arrives with the same default id of 1. Setting those ids is a physical, one-at-a-time ritual: connect exactly one motor to the controller board, press Enter, let the script write the id and baudrate into the motor's EEPROM, then move the cable to the next motor. Twelve motors across two arms means twelve rounds of that. There is no batch mode, because the bus cannot address two motors that share an id.

1. 1
   Install LeRobot and the Feetech SDK

   LeRobot needs Python 3.12 or newer. The base package is deliberately lightweight, so the robot workflow extras and the Feetech motor support are separate installs.

   bash

   conda create -y -n lerobot python=3.12
   conda activate lerobot
   conda install ffmpeg -c conda-forge
   
   git clone https://github.com/huggingface/lerobot.git
   cd lerobot
   pip install -e ".[core_scripts]"   # record, replay, calibrate
   pip install -e ".[feetech]"        # STS3215 bus servos

2. 2
   Find the serial port for each controller board

   Run it once per arm. The script asks you to unplug the USB cable and press Enter, then prints the port that disappeared. On Linux you may need to open permissions on the device node first.

   bash

   lerobot-find-port
   
   # Linux only, if the port is present but not writable:
   sudo chmod 666 /dev/ttyACM0
   sudo chmod 666 /dev/ttyACM1

3. 3
   Write ids and baudrates, one motor at a time

   The script prompts for the gripper first and walks backwards down the arm. Connect only the named motor, and make sure it is not yet daisy-chained to any other. Repeat the whole procedure for the leader with the teleop flags.

   bash

   lerobot-setup-motors \
       --robot.type=so100_follower \
       --robot.port=/dev/ttyACM0
   
   # expected prompts, in order:
   #   Connect the controller board to the 'gripper' motor only and press enter.
   #   'gripper' motor id set to 6
   #   Connect the controller board to the 'wrist_roll' motor only and press enter.
   
   lerobot-setup-motors \
       --teleop.type=so100_leader \
       --teleop.port=/dev/ttyACM1

Day 3: assembly, and the wires you forgot to route

The upstream guidance is that a first arm takes a bit more than an hour, and a second arm somewhat less once the sequence is familiar. That is accurate for the screwing. It is not accurate for a first build, because the assembly videos show the mechanical steps without showing when the cables go in, and the documentation says so directly: inserting the cables beforehand is much easier than afterwards. Every joint has a cable that has to be routed through the part before the part is closed, and every time you get that wrong you undo four M3 screws.

Two specific fits are tight by design and worth knowing about in advance. The shoulder motor holder on the SO-100 usually needs a workbench or a similar hard surface to press the part around the motor, and the fourth motor holder is the same story. If a part will not go on with hand pressure, that is expected, not a print failure. Force applied to a printed part in the right direction is fine; force applied to a motor horn is how you lose the position you just set.

Day 4: calibration, then the first minute of teleoperation

Calibration is two gestures. Move every joint to the middle of its range and press Enter, then move every joint through its full range of motion. That is it. What it produces is a mapping between raw encoder counts and normalised joint values, stored under the id you passed on the command line. Use the same id later during recording and rollout, because that is how LeRobot finds the calibration file. The upstream docs make the point that matters: calibration is what lets a network trained on one arm work on another.

lerobot-calibrate \
    --robot.type=so100_follower \
    --robot.port=/dev/ttyACM0 \
    --robot.id=my_follower_arm

lerobot-calibrate \
    --teleop.type=so100_leader \
    --teleop.port=/dev/ttyACM1 \
    --teleop.id=my_leader_arm

Then teleoperate. This is the first moment the project feels real, and it is also the first moment a mechanical problem becomes visible. If the follower shakes and then droops, you are usually looking at a power or torque problem rather than a software one, and arm twitches then sags lists the usual causes. If one joint stops well short of where the leader is, the range of motion sweep did not cover that joint properly and joint stops early applies. The leader-follower scheme itself is simple: the leader publishes joint positions, the follower is commanded to match them.

lerobot-teleoperate \
    --robot.type=so100_follower \
    --robot.port=/dev/ttyACM0 \
    --robot.id=my_follower_arm \
    --teleop.type=so100_leader \
    --teleop.port=/dev/ttyACM1 \
    --teleop.id=my_leader_arm \
    --display_data=true

If your parts have not arrived yet, you do not have to wait to learn what teleoperation feels like. The live arm on AY-Robots is a physical SO-100 streaming in the browser with no signup, handed out through a queue. Ten minutes of driving a real arm teaches you more about why demonstrations are hard than an hour of reading, and it costs nothing. The try page collects the other things you can do without hardware.

Day 5: cameras, then the long recording session

Cameras first, because they are the part of the setup most likely to change under you. LeRobot discovers OpenCV and RealSense devices for you, and the documentation warns that the identifiers can change after a reboot or after re-plugging, depending on the operating system. That is not a small caveat. A dataset recorded with wrist and top swapped is a dataset that trains a policy to reach in the wrong direction, and nothing about the loss curve will tell you.

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 Id field is what you pass as index_or_path.

The Hugging Face guidance on what makes a good dataset is short and specific: two camera views, steady framing, neutral and stable lighting, sharp focus, and at least 480x640. The leader arm must not appear in frame, and the only things moving should be the follower and the object. Name your features by what they see rather than by the device, so images.top and images.wrist rather than images.laptop. Write the task description as a real sentence of roughly 25 to 50 characters, because a vision-language model will actually read it.

Now the number that surprises people. LeRobot dataset recording defaults, straight out of the config dataclass, are 50 episodes at 30 fps, 60 seconds per episode and 60 seconds of reset between episodes. Multiply it: 50 times 120 seconds is 6000 seconds, or 1 hour 40 minutes of unbroken clock time, assuming you never retake anything and never need a break. In practice you will retake, because the guidance is to keep grasping behaviour consistent, and inconsistent takes are worth deleting rather than keeping.

lerobot-record \
    --robot.type=so100_follower \
    --robot.port=/dev/ttyACM0 \
    --robot.id=my_follower_arm \
    --robot.cameras="{ top: {type: opencv, index_or_path: 1, width: 640, height: 480, fps: 30}, wrist: {type: opencv, index_or_path: 0, width: 640, height: 480, fps: 30} }" \
    --teleop.type=so100_leader \
    --teleop.port=/dev/ttyACM1 \
    --teleop.id=my_leader_arm \
    --dataset.repo_id=${HF_USER}/so100_pick_place \
    --dataset.num_episodes=50 \
    --dataset.single_task="Put the red brick in the bowl" \
    --dataset.episode_time_s=20 \
    --dataset.reset_time_s=10 \
    --dataset.streaming_encoding=true \
    --display_data=true

This is the day where people give up quietly. Not with an error message, just with boredom around episode 28. The counter-measure is scheduling: record in two blocks with a real break, decide the object positions in advance so you are not improvising, and keep the task narrow. Record your first dataset walks the same ground with the AY-Robots client, and our guide to collecting high-quality VLA training data goes deeper on what to vary and what to hold fixed.

Two routes through the same week

The manual route and the platform route are not different workflows, they are the same workflow with different amounts of infrastructure work attached. Here is the same goal, from recorded episodes to a policy running on the arm, done both ways.

# 1. train, locally or on a rented box
lerobot-train \
  --dataset.repo_id=${HF_USER}/so100_pick_place \
  --policy.type=act \
  --output_dir=outputs/train/act_so100 \
  --job_name=act_so100 \
  --policy.device=cuda \
  --steps=20000 \
  --policy.scheduler_decay_steps=20000

# 2. run it back on the arm
lerobot-rollout \
  --strategy.type=base \
  --policy.path=outputs/train/act_so100/checkpoints/last/pretrained_model \
  --robot.type=so100_follower \
  --robot.port=/dev/ttyACM0 \
  --robot.id=my_follower_arm \
  --robot.cameras="{ top: {type: opencv, index_or_path: 1, width: 640, height: 480, fps: 30}, wrist: {type: opencv, index_or_path: 0, width: 640, height: 480, fps: 30} }" \
  --task="Put the red brick in the bowl" \
  --duration=60

Day 6: training, which is mostly waiting

Pick ACT for the first run. It is the smallest of the five trainable policies at roughly 80 M parameters, it trains from scratch rather than fine-tuning a foundation model, it runs on any 24 GB card, and it has the lowest inference cost of the group at 20 ms per action step. It is also the policy the LeRobot imitation-learning tutorial uses in its own worked training example. The trade is that ACT has no base model at all: it only exists after training on your task, so it will never generalise beyond what you recorded.

For wall-clock expectations, the LeRobot compute guide gives indicative figures for 5 epochs over a 50-episode dataset of about 45,000 frames at 640x480. ACT on a single RTX 4090 or 3090 lands at roughly 30 to 60 minutes. The same job on an L4 or A10G is 1 to 2 hours. SmolVLA on an A100 40 GB at batch 16 is 1 to 2 hours. Apple Silicon with MPS runs ACT in 6 to 14 hours, which is technically possible and practically a way to lose day six. The guide is explicit that these are order-of-magnitude figures and real runs deviate by plus or minus 50 percent.

The failure mode on this day is not a crash. It is a training curve that looks perfect while the policy does nothing useful, which is common enough that it has its own page at loss falls, policy does nothing. Behaviour-cloning loss measures how well the network predicts the action you recorded, not whether the resulting trajectory picks anything up, and while LeRobot v0.6 can compute a held-out loss on an evaluation split, that is off by default (eval_steps is 0) and a lower behaviour-cloning loss still does not rank checkpoints by task success. The only honest evaluation is running it on the arm. If the run itself dies, out of memory during training and training job stuck queued cover the two most common stops.

Day 7: the rollout, and the disappointment that follows it

Deployment is one command, and it needs to match the recording setup exactly. Same camera names, same resolutions, same robot id so the calibration file is found, same task string. LeRobot v0.6 exposes five rollout strategies: base for a plain autonomous run with no recording, sentry for continuous recording with auto-upload, highlight for ring-buffer recording saved by a keystroke, dagger for human-in-the-loop collection, and episodic for episode-oriented runs with reset phases. Every strategy also accepts --inference.type=rtc, real-time chunking for the slow VLA models; the default backend is sync, one policy call per control tick. Start with base and sync.

lerobot-rollout \
  --strategy.type=base \
  --policy.path=${HF_USER}/act_so100_pick_place \
  --robot.type=so100_follower \
  --robot.port=/dev/ttyACM0 \
  --robot.id=my_follower_arm \
  --robot.cameras="{ top: {type: opencv, index_or_path: 1, width: 640, height: 480, fps: 30}, wrist: {type: opencv, index_or_path: 0, width: 640, height: 480, fps: 30} }" \
  --task="Put the red brick in the bowl" \
  --duration=60

What usually happens on a first attempt: the arm moves confidently towards roughly the right place, closes the gripper slightly early or slightly late, and either succeeds or nudges the object out of reach. Then you move the object 15 cm and it fails completely. This is normal and it is not a bug in your setup. ACT predicts a chunk of 100 actions at a time by default and executes all 100 of them, so once a chunk commits to the wrong approach there is no correction until the next one. Action chunking is what makes these policies smooth and it is also why they look stubborn.

What week two is for

The week-one goal is not a good policy. It is a closed loop: hardware that answers, a dataset that loads, a run that finishes, and a checkpoint that moves the arm. Once that loop exists, every improvement is cheap, because you are changing one variable against a known baseline instead of debugging four things at once.

1. Measure before you change anything. Twenty attempts from the same start positions gives you a success rate, and without one you cannot tell an improvement from a good afternoon.
2. Add the variation you actually need, one axis at a time. The upstream advice is explicit that adding too much variation too quickly hurts results.
3. Record 20 more episodes covering exactly the failures you saw, rather than 200 more of what already works.
4. Only then try a larger model. SmolVLA needs 30 episodes minimum on this platform and adds language conditioning at 245 ms per action step; GR00T N1.7 needs 50 and an A100-class card.
5. Compare before you commit. The arena holds 85 VLA models with 332 benchmark results, each value linked to its paper or model card.

If you want the longer form of any single day, the SO-100 getting-started track covers hardware and calibration, train your first policy covers day six, and run your first policy covers day seven. The complete SO-100 guide is the single longest reference we have on the arm itself, and the VLA overview explains what the larger models buy you once ACT stops being enough.