SO-ARM101 host PC — build spec & Ubuntu runbook

1. What changes with SO-ARM101

Earlier generic “MCU + ROS” advice assumed a programmable real-time controller on the arm. SO-ARM101 does not work that way. Official LeRobot hardware docs treat the arm as Feetech bus servos behind a USB MotorBus adapter, with all algorithms on the host.

2. What the host machine must do

For remote SO-ARM101 work (teleop, data collection, then learned policies), the host loop is roughly:

1. Open USB serial to follower (and leader, if present) via BusLinker / Waveshare.
2. Capture 1–2 RGB camera streams (wrist and/or scene).
3. Teleop mode: map leader joint positions → follower commands and record a LeRobot dataset.
4. Autonomy mode: run a policy (ACT, diffusion, SmolVLA, etc.) → joint targets → Feetech bus.
5. Expose SSH / logs / optional camera preview over Tailscale for remote monitoring.

3. Architecture (host vs BusLinker)

4. Processing levels by LeRobot workload

Size the host for the heaviest job you will run at the robot site. Teleop recording and policy inference have very different GPU needs.

Graphics / GPU requirements (plain English)

• Display GPU: irrelevant. Headless is fine once setup is done.
• CUDA GPU: required for comfortable policy inference. LeRobot is PyTorch-first.
• VRAM floor: 6–8 GB for typical ACT-class inference; more for larger VLAs; training is a separate machine class.
• CPU: 6+ cores fine; camera decode + dataset I/O matter more than single-thread speed.
• RAM: 16 GB minimum; 32 GB recommended when recording video datasets + running desktop tools.
• Storage: 1 TB NVMe preferred — LeRobot episode video fills disks quickly.
• USB: enough ports for 2 MotorBus adapters + 2 cameras without a flaky hub (powered hub OK if quality is good).
• Network: Ethernet preferred at site for remote SSH/Tailscale reliability.

5. Recommended minimal feasible build

Two equal “minimum viable” hosts for SO-ARM101 autonomy. Teleop-only can go cheaper (Path C).

Path C — teleop / data collection only

I/O you must plan for

• MotorBus: 1× USB for follower; 2× if using leader+follower teleop.
• Cameras: 1–2× USB3 UVC webcams (common LeRobot setup); mount rigidly.
• Servo power: kit PSUs (e.g. 5 V/4 A standard, 12 V for Pro follower) — do not power servos from the PC USB port.
• Kill switch: switched power strip or inline switch on servo supply at the site.
• UPS (optional): protects host disk and avoids ugly mid-episode power loss.

6. Bill of materials (host + SO-ARM101 side)

7. What you do not need (yet)

• A separate Arduino/STM32 “brain” board in addition to BusLinker (unless you redesign the stack)
• ROS 2 as a prerequisite (LeRobot can stand alone; add ROS later if you want)
• RTX 4090 on the robot desk for first ACT-style policies
• Cloud inference in the control loop
• Kubernetes on the robot host

8. Ubuntu install runbook

Assume Ubuntu 24.04 LTS is already installed on the host next to the arm (Desktop or Server). Run as a user with sudo. Commands are copy-pasteable.

8.1 System baseline

# Update OS
sudo apt update && sudo apt -y full-upgrade
sudo apt -y install curl wget git build-essential \
  ca-certificates gnupg lsb-release software-properties-common \
  htop tmux vim net-tools usbutils v4l-utils \
  python3-pip python3-venv python3-dev \
  openssh-server

# Optional: reboot after kernel upgrade
sudo reboot

8.2 Identity, locale, and unattended upgrades

# Set a clear hostname (shows up in Tailscale / mDNS)
sudo hostnamectl set-hostname robot-pc
echo "10.0.0.1 robot-pc" | sudo tee -a /etc/hosts  # adjust if needed

# Time sync (critical for logs + certs)
timedatectl
sudo timedatectl set-ntp true

# Security updates
sudo apt -y install unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades

8.3 NVIDIA GPU drivers (Path A)

# Recommended: Ubuntu’s proprietary driver meta-package
ubuntu-drivers devices
sudo ubuntu-drivers autoinstall
# or pin a known-good series, e.g.:
# sudo apt -y install nvidia-driver-550

sudo reboot

# Verify
nvidia-smi
# Expect GPU name, driver version, CUDA version listed

8.4 Docker (optional)

curl -fsSL https://get.docker.com | sudo sh
sudo usermod -aG docker "$USER"
# log out/in for group membership

# NVIDIA Container Toolkit (GPU in containers)
distribution=$(. /etc/os-release;echo $ID$VERSION_ID)
curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | \
  sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg
curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | \
  sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | \
  sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list
sudo apt update
sudo apt -y install nvidia-container-toolkit
sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

# Smoke test
docker run --rm --gpus all nvidia/cuda:12.4.1-base-ubuntu22.04 nvidia-smi

8.5 Camera smoke test

sudo apt -y install v4l-utils python3-opencv
v4l2-ctl --list-devices
python3 - <<'PY'
import cv2
cap = cv2.VideoCapture(0)
ok, frame = cap.read()
print("camera_ok=", ok, "shape=", None if frame is None else frame.shape)
cap.release()
PY

8.6 USB permissions for BusLinker / cameras

# Serial access for Feetech MotorBus adapters
sudo usermod -aG dialout "$USER"
sudo usermod -aG video "$USER"
sudo usermod -aG plugdev "$USER"

# CRITICAL on many Ubuntu installs: brltty claims CH340/CH341 USB-serial IDs
# used by some bus servo boards and blocks /dev/ttyUSB* or ttyACM*
sudo apt -y remove brltty
# reboot or replug adapters after removal

# Temporary access (until groups apply / udev rules land)
# sudo chmod 666 /dev/ttyACM0 /dev/ttyACM1

# Stable symlinks — replace vendor/product from `lsusb` after plugging adapters
sudo tee /etc/udev/rules.d/99-so101-motorbus.rules <<'EOF'
# Example: adjust idVendor/idProduct per `lsusb` for each adapter
SUBSYSTEM=="tty", ATTRS{idVendor}=="1a86", ATTRS{idProduct}=="7523", SYMLINK+="so101_follower", MODE="0666"
# Second adapter example — different serial or physical port mapping as needed
# SUBSYSTEM=="tty", ATTRS{idVendor}=="1a86", ATTRS{idProduct}=="7523", ATTRS{serial}=="XXXX", SYMLINK+="so101_leader", MODE="0666"
EOF
sudo udevadm control --reload-rules
sudo udevadm trigger

# Re-login, then: ls -l /dev/ttyACM* /dev/ttyUSB* /dev/video*

9. Remote access & security

You are not on site. The host owns USB to the arm — treat it as a hardened jump host. Remember: there is no independent MCU application brain to “fail safe” for you.

9.1 SSH hardening

sudo systemctl enable --now ssh

# On your laptop: ssh-copy-id user@robot-pc-local-ip
# Then on robot PC, prefer keys only:
sudo sed -i 's/^#\?PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
sudo sed -i 's/^#\?PermitRootLogin.*/PermitRootLogin no/' /etc/ssh/sshd_config
sudo systemctl restart ssh

9.2 Tailscale (recommended VPN)

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up --ssh
# authenticate via the printed URL from a browser on any device
tailscale status
tailscale ip -4

9.3 Firewall

sudo apt -y install ufw
sudo ufw default deny incoming
sudo ufw default allow outgoing
# If Tailscale handles SSH, you can skip public 22 entirely.
# Allow SSH only if needed on LAN:
sudo ufw allow from 192.168.0.0/16 to any port 22 proto tcp
sudo ufw allow in on tailscale0
sudo ufw enable
sudo ufw status verbose

9.4 Fail-safe behavior (required for SO-ARM101)

• Physical kill: switched power to servo PSU(s) reachable by anyone on site.
• Host process: if LeRobot/teleop dies, do not auto-restart motion blindly via systemd without review.
• USB disconnect: practice what the arm does when the adapter is unplugged mid-move (expect freezes / limp depending on servo state — verify on your kit).
• Remote soft stop: document a command that disables torque / stops the policy process over SSH.
• Local supervision: first remote sessions should have a person who can cut power within arm’s reach radius.

9.5 Optional camera preview

# Simple low-latency path for debugging (LAN/VPN only):
# MediaMTX / go2rtc / WebRTC stacks are preferable to raw open RTSP on the internet.
# Example placeholder: use your chosen streamer bound to Tailscale IP only.
ip -4 addr show tailscale0

10. LeRobot + Feetech stack install

Follow the official guides for exact flags as versions move: LeRobot install, SO-101 assembly / motors / calibrate. Below is a practical host-side sequence after Ubuntu/JetPack basics.

10.1 Clone and install with Feetech extra

# Prefer a fresh conda/mamba or venv per LeRobot docs for your platform
cd ~
git clone https://github.com/huggingface/lerobot.git
cd lerobot

# Install package + Feetech motors support (required for SO-ARM101)
pip install -e ".[feetech]"

# On x86_64 Ubuntu with NVIDIA GPU, ensure torch sees CUDA:
python -c "import torch; print(torch.__version__, torch.cuda.is_available())"

10.2 Find MotorBus ports

# Power the adapter(s) with the kit PSU, then:
lerobot-find-port

# On Linux you will often see /dev/ttyACM0, /dev/ttyACM1
# Use chmod or dialout group if permission denied:
# sudo chmod 666 /dev/ttyACM0

10.3 Motor IDs, calibration, first motion

# One motor at a time per official SO-101 guide — example shapes:
lerobot-setup-motors \
  --robot.type=so101_follower \
  --robot.port=/dev/ttyACM0

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

# Leader (if present) uses --teleop.type=so101_leader and its own port/id
# Then follow the imitation-learning real-robot tutorial for teleop + record + train + eval

10.4 Optional: YOLO still useful?

Classic YOLO pick-and-place is not the primary SO-ARM101 path. LeRobot policies usually consume raw camera frames + joint state end-to-end. You can still add OpenCV/YOLO for debugging or hybrid stacks, but size the GPU for the policy first.

11. BusLinker / Waveshare bring-up

1. Power correctly. Connect kit PSU to the servo board; USB alone is not the motor supply. Standard vs Pro kits differ (e.g. 5 V vs 12 V follower) — match the listing.
2. USB to host only. Plug BusLinker/Waveshare into the robot-site host (the machine that will run LeRobot). For Waveshare, set jumpers to channel B (USB) when controlling from PC.
3. Identify ports. lsusb, dmesg -w, lerobot-find-port. Remove brltty if the device never appears.
4. Program servo IDs once. Use lerobot-setup-motors one motor at a time (official sequence). Optional Windows Feetech GUI for debug only.
5. Daisy-chain and calibrate. Full bus chain, then lerobot-calibrate for follower and leader so joint zeros match.
6. Cameras last. Mount scene (± wrist) cameras, confirm indices, then record short teleop episodes before long datasets.
7. Remote only after local success. Teleop and a recorded replay must work with you standing there before Tailscale-only operation.

12. Verification checklist

13. Day-2 operations

# Prefer manual start for motion-capable processes.
# If you must daemonize inference, gate on a
# hardware enable or explicit env flag.

[Service]
Type=simple
User=YOUR_USER
WorkingDirectory=/home/YOUR_USER/lerobot
# ExecStart=... only after dry-run validation
Restart=no

Performance tuning notes

• Record at the camera resolution you will evaluate with (domain gap hurts policies).
• Keep USB cameras on the host’s native controllers when possible.
• For inference latency, profile the policy step time; upgrade GPU only when model eval is the bottleneck.
• Train heavy jobs elsewhere; ship checkpoints to the robot host.

Decision guide (one paragraph)

SO-ARM101 makes the host PC the entire brain and the BusLinker a USB/power bridge to STS3215 servos under Hugging Face LeRobot. For remote object manipulation, place an RTX 3050-class or Jetson Orin Nano next to the arm, install Ubuntu/JetPack, Feetech-enabled LeRobot, cameras, and Tailscale. Use a light machine only for teleop/data collection. Train big models off-site. Compensate for the missing independent MCU with a physical servo power kill and local supervision on first remote runs.