MABEL
MABEL
From an empty bench to a robot that powers on — in order: the materials, the bill of materials, the mechanical build, and the wiring. Firmware and calibration live with the software →
Any desktop printer — every part fits a standard bed. Budget 7 spools (≈2.1 kg printed): PLA/PETG white for covers and mounts, black for the high-wear ORCA hand structure.
Hex drivers, a crimper, a soldering iron, a multimeter — and a current-limited bench supply for every first energization. No machine shop: sheet parts are ordered from any fab service (drawings in the BOM).
A Mac or Linux laptop runs the full simulation twin and every desktop tool. Ubuntu on the Jetson runs the robot — ROS 2 is only needed there.
Basic 3D printing, a terminal, light electronics. Prove every motion in the twin before it ever runs on hardware.
Eight subsystems make up the core bill. Hover a slice — or a row — and the actual components inside it appear below.
| Subsystem | Share | Cost |
|---|---|---|
| Mobile base | 28% | $2,272 |
| Body / torso | 11% | $889 |
| Arms - both | 33% | $2,622 |
| Hands - both | 15% | $1,195 |
| Neck / head | 3% | $235 |
| Structural hardware | 2% | $184 |
| Electronics, power & cabling | 6% | $500 |
| 3D printed material | 2% | $161 |
| Core total | $8,058 |
Prices move. NVIDIA raised every Jetson price 33–101% on 22 July 2026 — the identical robot went from $12,969 to $14,968 overnight. Compute is a choice here, not a component: the bill treats it that way.
The shells take about 36 hours on one printer — start them before the actuator kits arrive, and build the electrical kits while they run.
≈ 2.1 kg of PETG or ABS. Every mesh is generated from the MuJoCo model mabel_full.xml — never hand-edit a printed part, regenerate it.
Bottom-up. Never mount a module onto one you haven't range-tested — a base with a twisted swerve module is invisible once the body is on it.
Assign every CAN and serial ID before the part goes into the chain, one device powered at a time. A wrong ID buried mid-arm means taking the arm apart.
Every actuator stays limp until its module is mechanically complete and its limits are set. Bring the whole robot up with torque disabled.
What these drawings are. The exploded views below are the authority for which parts exist and in what order they stack. A fully itemized fastener and torque schedule has not been published yet — use the hardware that ships with each actuator, and match the drawing. Published drawings today: body and head; the remaining five modules are documented as build sequences here and in the build guide.
Three independently steered modules in a delta layout — the rolling foundation everything else stacks onto.
A cascaded Z-column that adds 0.635 m of vertical travel — counter height to over a table.
The lift changes the base's limits. Raising the column raises the centre of mass, so the tip-safe speed and braking envelope tightens with height. That coupling is modelled in whole-body control — it is not something you tune out mechanically.
The torso that leans, and the frame that carries the arms, the neck, and the body electronics.
Two 7-DOF OpenArm-derived arms on quasi-direct-drive motors — low gearing, real torque control, back-drivable by hand.
can0, right on can1. Do not merge them onto one chain.Two open-source ORCA hands — five tendon-routed fingers each, 17 actuated DOF per hand on a single serial chain.
A 3-DOF neck and the stereo eyes it aims. Yaw runs on the body CAN bus; roll and pitch are a pair of Dynamixel servos on TTL.
Bring the neck up limp. The X-series servos latch torque-enable across a host reconnect — a previous session that energised the neck leaves it stiff at the next bring-up. The driver asserts the safe limp state on connect; do not defeat it while assembling.
Custom base and body boards tie every actuator onto one low-latency local network — CAN for the motor buses, Ethernet and USB 3 for the bandwidth.
can0 / can1. Terminate each chain at both ends.Mechanically complete is not commissioned. Bring the robot up limp, one bus at a time, then hand over to the build guide for firmware and calibration.
No — and you shouldn't start with it. The entire stack runs against the
MuJoCo twin on a laptop: cd server && ./run.sh boots physics, cameras,
the teleop gateway and a browser control studio. Phones, headsets and browsers
connect to the twin exactly as they later connect to the robot — same
ports, same wire contract, and the clients can't tell which is live.
Prove every motion in the twin first, then order parts. The golden rule of the whole build. Replication wiki · 05 Software →
Work the bus, not the motor:
① Bus up? ./can_up.sh then ./can_scan.sh — 1 Mbit everywhere.
② Termination: ~60 Ω measured across CAN-H/L (two 120 Ω ends in parallel).
③ ID clash: assign IDs one device powered at a time — expect 6 on the base,
7 per arm, 17 per hand chain.
④ First unreachable ID in a chain = check that connector; everything
downstream vanishes with it.
The two wrist boards are identical, so USB enumerates them in arrival
order — left becomes right after a reboot. Pin each camera by its hub
port (udev rules ship in hardware_bridge/install/) and keep
both on one powered USB-3 hub.
Slow or stuttering? Drop to 640×480 — teleop wants latency, not pixels; the measured glass-to-glass budget is dominated by encode, not resolution.
The MJCF (mabel_full.xml) is the single source of truth —
the URDF, the web GLB, the phone/headset rigs and the tip-over constants are all
generated from it. Edit the model and skip the regeneration, and every
viewer silently keeps showing the old body.
Re-run the §8 pipeline in order (MJCF → URDF → GLB → rigs → mirror), then re-check the CoM constants. Never hand-edit a derived file.