Build & Calibration Guide

1. Build Overview

This guide walks you through building the platform with 2× SO-101 follower arms, a neck/head assembly, an omni-wheel base on an IKEA RÅSKOG cart, and an NVIDIA Jetson compute node mounted near the neck/base region.

The 2-Bus Separation

All 17 motors run on two independent buses, each carrying two daisy chains. Splitting the buses this way keeps the high-torque wheel and neck motors off the same power budget as the arms, so an arm stall cannot brown out the drive base.

Recommended Build Order

1. Print all parts (files & print settings on Components)
2. Assemble both SO-101 arms
3. Install wrist camera mounts and grippers
4. Assemble cart and wheel base
5. Assemble neck / top base / head
6. Configure motor IDs — one motor at a time, before final assembly
7. Mount Jetson and route wiring
8. Final mechanical assembly and cable management
9. Bus verification and calibration
10. Software setup — install the stack and run the robot

2. Assembly

Overall Assembly

A complete walkthrough of the build process. Use the chapter links in the sections below to jump this video straight to that step.

A) Cart

Assemble the IKEA RÅSKOG cart first to establish the rolling structure.

• Do not finalize cable routing through the cart yet
• Leave access for motor extensions, USB data, power, and camera cable routes

B) Arms (Joints 1–5)

Assemble both SO-101 follower arms using the step-by-step build video below.

Crucial wrist/gripper order:

1. Before attaching the gripper to joint 5, install the wrist-camera attachment to the gripper
2. Install the gripper claw/fingers
3. Use the follower gripper approach on both arms

This order avoids reopening the wrist stack later.

C) Neck (Top Base & Head)

• Assemble the Top Base and Head.
• The head follows the same motor style and is derived from early SO-101 link patterns.
• The hollow neck doubles as a cable channel.

Jump to the neck assembly in the video above (0:00–18:51).

D) Wheels & Wheel Base

Assemble the wheels and wheel base.

Jump to the wheel assembly in the video above (18:52–32:30).

• Keep omni-wheel orientation/order exactly as documented
• Use two nuts per wheel bolt. Thread the first nut on and tighten it, then run a second nut down against it. The two jam together and cannot back off — a single nut works loose from the constant vibration of driving and the wheel eventually comes off.
• Use motor cable extensions — do not rely on short direct runs
• Leave slack until top-plate routing is finalized
• Mount the top plate and connectors only after route checks

E) Integrating Components onto the Cart

Bring the arms, neck, and wheel base together on the cart for the full platform.

• Secure each main shoulder to the cart with a screw and two nuts: pass a screw down through the arm base and the cart shelf, then thread two nuts onto it from the underside — sandwich the cart shelf between the arm base and the nuts, tighten the first, then jam the second down against it. The shoulder carries the whole arm's leverage every time it sweeps, and a single nut will not stay put under that load.

Jump to the full cart integration in the video above (32:35–39:52).

3. Motor Configuration & IDs

Configure motors before final cable management and hard mounting — verifying IDs on an assembled chain is far slower. Many servos ship with default ID 1, so each ID must be unique per bus and the baudrate must match the board and motors.

Before you start

You need the software stack installed to run these tools, but nothing beyond the base install — steps 3–5 of software setup is enough. Grant serial access first, or every command below fails with Permission denied:

ID Planning

Step 1 — Scan what is actually on the bus

This sweeps every supported baud rate and pings every address, so it finds motors even at the wrong baud or the wrong ID. Model 777 is the STS3215.

A brand-new motor answers as ID 1. That is why they must be configured one at a time — a bag of factory servos is seventeen motors all claiming the same address.

Step 2 — Write one ID at a time

The tool scans every baudrate to find the motor, so it works even on a servo that is at an unexpected ID or baud. It reprograms it to your chosen ID at the default 1 Mbps. --model defaults to sts3215, which is what this build uses throughout.

Isolate each motor, confirm its current ID with a scan, then write the correct one. Add motors back and re-scan as you go — a complete chain should list every ID with no gaps.

4. NVIDIA Jetson Placement

Mount the Jetson in the center rack of the cart, between the wheel base and the top plate.

• Keep mass low for stability
• Keep USB ports accessible
• Minimize cable length to the two motor control boards, two wrist cameras, one head camera, and power distribution

5. Wiring (2-Bus)

Seventeen motors, four daisy chains, two bus hubs, five USB cables. The diagram below is the complete reference — chain order per limb, which chain lands on which hub, and how the hubs and cameras reach the Jetson. Motor positions are taken straight from the robot's URDF.

A) Motor Wiring

Four daisy chains. One cable carries both power and the control signal, which is why each motor needs only the single wire to its neighbour. The free socket on the last motor of each chain goes to its bus hub.

• Bus 1 — Left arm (1→2→3→4→5→6): start at the shoulder, end at the gripper; chain head plugs into the Bus 1 hub
• Bus 1 — Right arm (7→8→9→10→11→12): exactly the same order on the other arm; also into the Bus 1 hub
• Bus 2 — Head (1→2): ID 1 is tilt (up/down), ID 2 is pan (left/right)
• Bus 2 — Wheels (3→4→5): run the cable around the rim of the wheel plate; use extensions for clean routing up to the middle shelf

Cable Routing

A daisy chain breaks at any point and everything downstream goes silent. Two rules prevent most of the grief:

• Service loop at every rotating joint. Shoulder pan sweeps the whole arm; without slack the cable pulls its own connector at the travel extremes and drops the bus mid-motion. This surfaces during calibration, where a single dropped packet aborts the run.
• The first link carries every transaction. The adapter-to-first-motor cable is the highest-value thing to re-seat when a bus misbehaves.

Also: avoid tight bends near connectors, keep motion cables away from pinch points, and label both ends of every extension.

B) Power Wiring

There are three separate things here and confusing them costs hours: servo power, Jetson power, and USB. USB carries data only.

• 12 V battery mounted low and upright in the cart, with strain relief at the battery and distribution points
• Main power line routed to a distribution point on the middle shelf
• Separate fused outputs for the Bus 1 hub (arms), the Bus 2 hub (head + wheels), and the Jetson power path — the repo's firmware limits assume 5 A on the arm bus and 10 A on the head/wheel bus, so keep the fuses and the torque ceilings in firmware_limits.py consistent with each other

Grounding

If the adapter board and the motor chain are fed from different supplies, they must still share a common ground — otherwise the data line has no valid voltage reference. The symptom is distinctive: every motor powered and drawing current, and zero communication.

Watch for load asymmetry when diagnosing. A marginal supply often carries three wheels fine and cannot carry twelve arm joints, which presents as "the arm bus is broken."

C) Camera Wiring

The cameras do not touch the motor buses at all — each one runs its own cable into its own USB port on the Jetson, never through a bus hub.

• Wrist cameras (×2): route each cable along its arm with full-motion slack; secure at intervals; keep compute-end connectors accessible
• Head camera (RealSense): route through the hollow neck into a USB 3.0 port; leave pan/tilt slack at the head joint

That accounts for all five USB cables: two bus adapters and three cameras.

6. Final Assembly

Complete final assembly, substituting the Jetson where older instructions reference a Raspberry Pi.

• Complete wiring and cable management before clamping the top base into the cart
• Clamp arms onto the cart corners after route verification

Final Checklist

7. Hardware Calibration & Validation

One whole-robot calibration serves both the robot class and the vision stack. Run it first, verify it, then work through the sanity checks below.

A) Run the Calibration

The run has four prompts: centre both arms, sweep every arm joint through its full range, centre the head, and then the wheels are handled automatically as full-turn motors.

B) Verify the Calibration — Do Not Skip This

Calibration can complete successfully and still be wrong. There are two failure modes and both are silent:

• Range reads 0–4095 on a limited joint. The homing offset landed inside the travel range, so the raw count wrapped and min/max pinned to the encoder extremes. This is legitimate only for wrist roll and the wheels — a shoulder or elbow cannot travel 360°. Consequence: IK commands positions that do not exist and the arm drives into its hard stop.
• Range far narrower than its mirror. That joint was not swept fully. Consequence: the arm is artificially limited and IK fails to reach valid targets.

The strongest check is left/right symmetry. Mirrored joints should agree within a few percent — here is a known-good run:

Two independently-swept arms landing within a few percent of each other is not something you get by accident — it is the best available evidence the calibration is sound.

C) Read Back What the Robot Thinks It Is

These print calibrated positions, so a joint reporting a wild angle at a pose you can see means the calibration did not take. Nothing is commanded to move — but read the warning first.

D) First Commanded Motion

Start with the base — it is the only subsystem where a mistake cannot drop an arm on your hand. Then move the arms.

E) Mechanical IK Accuracy

Once the arm takes end-effector commands, check that the gripper actually arrives where it was told. Expect 1–2 cm; worse than that is mechanical, not software — look for loose servo horns, a stripped gear, or a bent bracket. The First Reach tutorial walks through this end to end.

measure_ee.py hardcodes PORT = "/dev/ttyACM0" near the top of the file — change it to /dev/xle_arms for this build.

F) Camera Bring-up