PAPER DEEP DIVE
MABEL: An Open Anthropomorphic Mobile Bimanual Platform for Teleoperation and Learning
As robot learning moves beyond the tabletop, many tasks require mobility, adjustable reach, active perception, and bimanual dexterity. Commercial platforms combining these capabilities are costly, while affordable open-source alternatives cover only a subset and require software integration. We present MABEL, an open-source anthropomorphic mobile bimanual robot with 56 degrees of freedom (DOF) and a US$8.1k parts cost. It combines two 7-DOF arms with 17-DOF hands, a pitching torso, a lift, a 3-DOF neck, and a holonomic base. Back-drivable arms and torso support compliant interaction, with fingertip reach from floor level to 2.23 m. The head and torso roughly triple modeled camera coverage relative to a torso-fixed camera. Apple Vision Pro head and hand tracking enables whole-body teleoperation without handheld controllers, with 137 ms mean glass-to-glass stereo video latency over the robot's Wi-Fi hotspot. We demonstrate an end-to-end imitation learning pipeline, from teleoperated data collection to policy deployment, using a shared command interface and whole-body controller.
One-Sentence Summary
MABEL is a 56-degree-of-freedom open mobile bimanual robot that combines a three-module holonomic base, adjustable torso and lift, two back-drivable arms, dexterous hands, active stereo gaze, Vision Pro teleoperation, simulation, data collection, and an ACT deployment path for a parts subtotal of USD 8,056.
1. Why a New Embodiment Is the Bottleneck
Robot learning has made steady progress on tabletop manipulation, but the tasks implied by a home, laboratory, or workshop extend far beyond a fixed-height table. An agent may need to kneel toward a cabinet, rise above a shelf, turn its head before entering a doorway, carry an object while changing direction, and use two hands without bringing its entire base to a stop. Each requirement is individually familiar. The engineering difficulty appears when they must coexist on one affordable body and when demonstration collection, simulation, control, and learned policy execution must all use the same interface.
The paper starts from a capability argument rather than an algorithm argument. Mobile ALOHA demonstrated that a wheeled platform can collect bimanual household data, but its position-controlled arms, one-DOF grippers, and nonholonomic base leave out compliant torque control, finger articulation, and lateral mobility. XLeRobot reduces cost dramatically, yet its five-DOF arms and fixed upper-body geometry occupy a different capability regime. YOR and TidyBot++ add holonomic mobile bases and lift axes, while OpenPyRo-A1 emphasizes torque-capable arms and a waist, but these systems still differ from MABEL in hand dexterity, active gaze, mobility, or openness of the complete control stack.
The commercial comparison is sharper. The paper lists platforms such as Rainbow RB-Y1, Galaxea R1 Pro, Astribot S1, and DexMate Vega at USD 69,000 to more than USD 120,000. These systems show that the capability combination is technically possible, but the cost and closed integration model make reproduction, repair, and modification difficult for university laboratories. A replacement component may be proprietary, and a research group cannot freely redesign the controller around an undocumented electrical or software boundary.
MABEL therefore treats affordability as an integration problem. Lowering the bill of materials is not enough if the resulting robot lacks back-drivability, enough reach, dexterous end effectors, or a maintainable software path. The authors target a complete loop: a laboratory obtains the design files and bill of materials, builds the robot, commands it with an immersive interface, records demonstrations through the deployed controller, trains a policy, and executes that policy through the same body-facing interface.
The headline result is not a new benchmark record. It is a full-stack embodiment with measured mechanical repeatability, odometry disagreement, video latency, a teleoperated task suite, and one end-to-end ACT experiment. That evidence matters because a platform paper must establish not only that the parts fit together, but that a researcher can characterize the assembled machine and reproduce an experimental workflow.
2. Design Contract and Coordinate Frames
The operator side uses a world frame $\mathcal{F}_w$, a tracked head frame $\mathcal{F}_h$, left and right wrist frames $\mathcal{F}_i$, and an estimated body-heading frame $\mathcal{F}_b$. The robot side uses a torso frame $\mathcal{F}_r$, head-camera frame $\mathcal{F}_g$, palm frames $\mathcal{F}_{e_i}$, and odometry frame $\mathcal{F}_o$. A notation such as ${}^{x}\mathbf{R}_{y}$ describes the orientation of frame $y$ in frame $x$, while ${}^{x}\mathbf{p}_{y}$ is a position. This is more than formalism: the retargeter must repeatedly convert human head and wrist observations into a robot whose torso, lift, neck, and base are moving at the same time.
The robot has 56 functional degrees of freedom but 59 actuators. The extra coordinates arise from the drivetrain and coupled lift representation. Two arms contribute 14 joints, the hands contribute 34 finger and wrist coordinates, the neck contributes three, the torso one, the lift one effective height, and the three swerve modules contribute six steering and drive coordinates. The learning pipeline uses one 59-dimensional measured and commanded vector, while the whole-body controller recognizes that not every coordinate has the same control law.
The control stack separates three rates and three semantic layers. Operator poses are streamed at 60 Hz, current robot joints and commands are represented at a nominal 50 Hz control cadence, and camera data for the learning experiment are curated onto a 30 Hz grid. The high-level retargeter turns sparse tracking into body, arm, and hand goals; the motion model constrains base motion; the whole-body controller converts references into safe joint targets and torques. Teleoperation, a scripted policy, and simulation all enter through the same command boundary.
3. Hardware: Making Reach, Compliance, and Mobility Coexist
The base is deliberately unusual. Instead of four swerve modules, MABEL uses three non-collinear REV MAXSwerve modules. Three contact points define a statically stable support polygon under nominal loading, avoid the wheel-lift ambiguity of a four-wheel overconstrained chassis, and reduce drivetrain cost by about USD 700. The trade-off is equally explicit: the support triangle is smaller than a comparable four-wheel rectangle, so rapid translation and turning can move the center of mass toward an edge.
The authors do not solve that mechanical trade-off by derating the base everywhere. They fit center-of-mass height as a function of lift height and impose a height-aware motion envelope using a ZMP approximation. When the lift is high, allowable acceleration is reduced; when the body is low, the robot can use a larger part of its speed envelope. This connection between a hardware choice and a controller constraint is one of the strongest parts of the design.
Each arm has seven degrees of freedom and derives from OpenArm. The project changes housings and wiring, sources actuators directly, and reports approximately USD 3,000 for both arms. The arms and the quasi-direct-drive torso are back-drivable. That property enables low-stiffness impedance control and physical contact, but it also raises the importance of gravity compensation. If the model is wrong or feedforward is absent, a compliant arm visibly sags instead of yielding only when an external force is applied.
The torso pitch range is $-60^\circ$ to $15^\circ$. A FlexiSpot E7 standing-desk column supplies an additional 0.635 m of vertical travel. Combined with arm geometry, the kinematic fingertip workspace extends from floor level to 2.23 m. The upper-body dimensions are chosen to resemble an adult: shoulder width and arm length follow anthropometric references, the stereo camera baseline is 63 mm, and the neck range is intended to cover common human head motion. These choices reduce the mismatch between operator movement and robot kinematics.
The end effectors are modular. The evaluation uses two 17-DOF tendon-driven ORCA hands, but the wrist interface can accept other hands or the OpenArm gripper. This flexibility matters for replication because a laboratory can choose a lower-cost or simpler manipulator without redesigning the arm. It also means the platform's dexterity claim is configuration-dependent: the 56-DOF figure describes the hand-equipped version, not every possible build.
Sensor and compute packaging are part of the open design. A synchronized ZED Mini head camera provides stereo perception, while each wrist carries a global-shutter Intel RealSense D405. The paper reports horizontal fields of view of $102^\circ$ and $87^\circ$, respectively, and notes that wider USB cameras with $120^\circ$ head and $170^\circ$ wrist coverage have also been tested. An optional base RGB-D camera and LiDAR support localization and navigation.
A custom Teensy-based board distributes power and bridges Ethernet to CAN and TTL interfaces. The base and upper body use separate CAN networks, limiting shared bandwidth and preserving subsystem modularity. Host software has been validated on a MacBook Pro with M1, Raspberry Pi 5, Jetson Orin, and Jetson Thor. Power comes from a 24 V pack with roughly four hours of operation or swappable 40 V tool batteries through a regulated bus with roughly two hours; an external supply can be used for continuous bench operation.
The reported USD 8,056 subtotal is specifically for the Raspberry Pi 5 configuration and excludes optional sensors. The authors also assembled a second robot from the released design and bill of materials in approximately two weeks. The cost is therefore a reproducible parts subtotal, not a claim that a turnkey robot, engineering labor, tools, and every optional navigation sensor cost eight thousand dollars.
| Property | MABEL specification | Why it matters |
|---|---|---|
| Functional DOF / actuators | 56 / 59 | Hands, active gaze, torso, lift, and holonomic base are represented in one command model |
| Mass and chassis | 61.8 kg; 0.49 x 0.49 m | Laboratory-portable scale with a support polygon of 0.34 x 0.35 m |
| Height and reach | Overall body 1.16-1.80 m; fingertip reach to 2.23 m | Floor-level and overhead tasks without changing the base hardware |
| Arms and hands | 2 x 7-DOF back-drivable arms; 2 x 17-DOF ORCA hands | Compliant contact plus articulated finger and pinch control |
| Torso and lift | -60 to 15 degree pitch; 0.635 m lift travel | Low, deep, and overhead workspaces |
| Mobility | Three-module holonomic swerve base | Translation and rotation can be commanded independently |
| Parts subtotal | USD 8,056 with Raspberry Pi 5 | Excludes optional sensors; software is Apache-2.0 and hardware is open |
4. Teleoperation: Sparse Tracking, Whole-Body Motion
The Apple Vision Pro supplies head orientation, wrist poses, and 27 tracked keypoints per hand. MABEL has 56 DOF, so the mapping is underdetermined. The system does not attempt full-body biomechanical reconstruction. It estimates a smaller operator state during an approximately ten-second calibration and allocates that state to body parts. Calibration measures each arm's reach, head-to-shoulder offsets, and hand scale.
A comfort box defines the portion of head translation that should be expressed as leaning rather than walking. Let the transformed head displacement in the estimated body frame be
$$ \begin{bmatrix}\Delta\mathbf{r}\\ \Delta z\end{bmatrix} ={}^{w}\mathbf{R}_{b}^{\top}\left({}^{w}\mathbf{p}_{h}-{}^{w}\mathbf{p}_{h,a}\right), \qquad \Delta\mathbf{r}_{\mathrm{lean}}=\operatorname{clip}_{\mathcal{B}}(\Delta\mathbf{r}), \qquad \Delta\mathbf{r}_{\mathrm{walk}}=\Delta\mathbf{r}-\Delta\mathbf{r}_{\mathrm{lean}}. $$
Here $\mathcal{B}=[-0.02,0.18]\times[-0.12,0.12]$ meters in the paper. The bounded component becomes a torso-lean intent and the residual becomes walking intent. Without this split, a small operator movement could immediately move the base. With it, leaning has a locally expressive range while larger displacement commands locomotion. Anchors reset on recentering, clutch release, and tracking loss.
The body mapping converts the retained state into torso pitch, lift height, and base-position references:
$$ q_{\mathrm{torso}}^{*}=q_{\mathrm{torso},0}-\gamma\Delta x_{\mathrm{lean}}, \qquad z_{\mathrm{lift}}^{*}=z_{\mathrm{lift},a}+\Delta z, \qquad {}^{o}\mathbf{r}_{\mathrm{base}}^{*} ={}^{o}\mathbf{r}_{\mathrm{base},a} +\mathbf{R}_{z}(\psi_{o,a})\Delta\mathbf{r}_{\mathrm{walk}}. $$
The neck has to compensate both for the operator's head rotation relative to their estimated body and for robot torso pitch. The paper writes
$$ \mathbf{q}_{\mathrm{neck}}^{*} =\operatorname{ypr}\left({}^{w}\mathbf{R}_{b}^{\top}{}^{w}\mathbf{R}_{h}\right) -\begin{bmatrix}0&q_{\mathrm{torso}}^{*}&0\end{bmatrix}^{\top}. $$
This coordinate choice keeps gaze tied to the operator's intent. When the robot leans forward, the neck can remain on the same visual target instead of inheriting the torso rotation as an unintended head-down command. The camera baseline and angular scale are preserved so the headset shows a human-scale stereo view.
Arm targets preserve the wrist displacement from the shoulder but scale it by robot-to-human reach:
$$ {}^{r}\mathbf{p}_{e_i}^{*} ={}^{r}\mathbf{o}_{r,i} +s_i\,{}^{w}\mathbf{R}_{b}^{\top} \left({}^{w}\mathbf{p}_{i}-{}^{w}\mathbf{o}_{h,i}\right), \qquad s_i=\frac{L_i^{r}}{L_i^{h}}. $$
The seven arm joints plus the hand's wrist joint form an eight-dimensional inverse-kinematics problem. The implementation solves a nonlinear least-squares objective with a position term, direction terms for palm normal, finger axis, and elbow, and a rest posture regularizer:
$$ \begin{aligned} \mathbf{q}_{\mathrm{IK}}=\arg\min_{\mathbf{q}}\quad &\left\|{}^{r}\mathbf{p}_{e_i}(\mathbf{q})-{}^{r}\mathbf{p}_{e_i}^{*}\right\|^2\\ &+w_{\mathrm{dir}}\sum_{j\in\mathcal{U}} \left(1-\mathbf{u}_j(\mathbf{q})^{\top}\mathbf{u}_j^{*}\right) +w_{\mathrm{rest}}\left\|\mathbf{q}-\mathbf{q}_{\mathrm{rest}}\right\|^2\\ \mathrm{s.t.}\quad &\mathbf{q}_{\min}\le\mathbf{q}\le\mathbf{q}_{\max}. \end{aligned} $$
The repository shows the same decomposition in arm_cosine.py. The wrist/contact error receives the largest coefficient, elbow and palm directions are cosine costs, and smoothness prevents the redundant seven-DOF arm from snapping between equivalent solutions. The optimizer is SLSQP with bounded joints and warm starts.
loss = C.ARM_W_WRIST * float(np.sum((rc - hk["contact"]) ** 2))
loss += C.ARM_W_ELBOW * (1.0 - float(np.dot(ed, hed)))
loss += C.ARM_W_ORIENT * ((1.0 - float(np.dot(rfwd, hk["fwd"])))
+ (1.0 - float(np.dot(rup, hk["up"]))))
loss += C.ARM_W_SMOOTH * float(np.sum((q - q_prev) ** 2))
loss += float(np.sum(self.reg_w * (q - self.q_nom) ** 2))Each ORCA hand has 16 finger joints. The retargeter matches full fingertip positions and deliberately emphasizes thumb-to-fingertip vectors when the operator pinches. If $\mathbf{P}$ stacks robot fingertip positions and $\boldsymbol{\delta}_m$ is the vector from thumb to fingertip $m$, the objective is
$$ \mathbf{q}_{f}^{*}= \arg\min_{\mathbf{q}_{f}} \left\|\mathbf{P}(\mathbf{q}_{f})-\bar{\mathbf{P}}\right\|_{F}^{2} +w_{\mathrm{pinch}}\sum_m \left\|\boldsymbol{\delta}_m(\mathbf{q}_{f})-\bar{\boldsymbol{\delta}}_m\right\|^{2}, \quad \mathbf{q}_{f,\min}\le\mathbf{q}_{f}\le\mathbf{q}_{f,\max}. $$
The public retargeter exposes a detail absent from most architecture diagrams: pinch weighting is conditional. A normalized thumb-tip distance below 0.55 activates the pinch term, while a grasp involving several fingers is treated as a power grasp and the pinch rows are relaxed. This keeps a closed fist from being pulled into an accidental pincer shape.
W_SHAPE = 15.0
W_DIR = 30.0
W_PINCH_LOW = 0.0
W_PINCH_HIGH = 50.0
PINCH_DIST_THRESH = 0.55
POWER_GRASP_PAIRS = 3The network path is designed for interaction rather than file transfer. Commands use newest-only delivery over WebSocket: if the operator produces a newer pose before an older one is consumed, the stale command is dropped. Video uses latest-frame UDP queues, so a lost packet costs one frame instead of building delay. The system can connect through the robot's own hotspot, a LAN, or Tailscale.
5. Motion Safety and Confidence-Aware Control
Three swerve modules make the mobile base mechanically simple and holonomic, but the controller must reason about the triangular support region. For a commanded planar twist $(\mathbf{v},\omega)$, module $j$ at position $\mathbf{r}_j$ from the center of rotation must realize
$$ \mathbf{v}_j=\mathbf{v}+\omega\mathbf{S}\mathbf{r}_j, \qquad \mathbf{S}=\begin{bmatrix}0&-1\\1&0\end{bmatrix}. $$
The direction of $\mathbf{v}_j$ sets steering, its norm sets wheel speed, and a saturation factor preserves the direction of the commanded twist when one module reaches a speed limit. The public module_velocities function reproduces the same planar relation as a two-column vector per module.
def module_velocities(vx, vy, w, r):
"""(3,2) ground-velocity vectors the rigid twist asks of each module."""
return np.stack([vx - w * r[:, 1], vy + w * r[:, 0]], axis=1)For tip-over assessment, the paper approximates horizontal center-of-mass acceleration while retaining translational, Coriolis, tangential, and centripetal terms:
$$ \mathbf{a}_{c}\approx \underbrace{\dot{\mathbf{v}}+\omega\mathbf{S}\mathbf{v}}_{\mathrm{base}} +\underbrace{\dot{\omega}\mathbf{S}\mathbf{r}_{c}}_{\mathrm{tangential}} -\underbrace{\omega^{2}\mathbf{r}_{c}}_{\mathrm{centripetal}}, \qquad h_{c}(z_{\mathrm{lift}})=h_{0}+k_{h}z_{\mathrm{lift}}. $$
For each support edge $k$, let $\mathbf{n}_k$ be the outward normal, $\ell_k$ the distance from the center-of-mass projection to the edge, $\sigma_k$ a safety factor, and $g$ gravity. The approximate maximum acceleration and utilization are
$$ a_k^{\max}=\frac{g\ell_k}{\sigma_k h_c(z_{\mathrm{lift}})}, \qquad u=\max_k\frac{-\mathbf{n}_k^{\top}\mathbf{a}_c}{a_k^{\max}}. $$
The controller scales commands to maintain $u\le 1$. The implementation is more conservative for the front edge than for lateral and rearward motion, and it checks the transient combination of acceleration and turning rather than testing each axis independently. This is essential for a three-point support polygon: a translation and yaw command that are individually acceptable can combine into an unsafe center-of-mass acceleration.
Arm inverse kinematics produces a desired configuration, not necessarily a collision-free path. The whole-body controller therefore projects a desired joint velocity onto a safe velocity through a quadratic program:
$$ \begin{aligned} \dot{\mathbf{q}}^{*}=\arg\min_{\dot{\mathbf{q}}}\quad &\frac{1}{2}\left\|\dot{\mathbf{q}}-\dot{\mathbf{q}}_{\mathrm{des}}\right\|^2\\ \mathrm{s.t.}\quad &\dot{\mathbf{q}}_{\min}\le\dot{\mathbf{q}}\le\dot{\mathbf{q}}_{\max},\\ &-\mathbf{J}_{c}\dot{\mathbf{q}}\le\kappa(d_c-d_s), \quad\forall c\in\mathcal{C}. \end{aligned} $$
Each pair of protected links is wrapped in capsules. For a pair $c$, $d_c$ is the surface clearance, $\mathbf{J}_c=\partial d_c/\partial\mathbf{q}$, $d_s$ is the desired safety margin, and $\kappa$ sets how quickly a violation must be repaired. The code's derivation is a discrete control-barrier constraint: as the gap approaches the safety distance, its rate of decrease is limited, and any already-inside violation must be corrected.
d(q) = ||c_a - c_b|| - r_a - r_b
d_dot = n.T @ (J_a - J_b) @ q_dot
constraint: d_dot >= -alpha * (d - d_s) for d < d_influence
Q form: -n.T @ (J_a - J_b) @ q_dot <= alpha * (d - d_s)The final tracking layer uses joint-space impedance:
$$ \boldsymbol{\tau} =\boldsymbol{\tau}_{g}(\mathbf{q}) +\boldsymbol{\tau}_{f}(\dot{\mathbf{q}}) +\mathbf{K}(\mathbf{q}^{*}-\mathbf{q}) +\mathbf{D}(\dot{\mathbf{q}}^{*}-\dot{\mathbf{q}}). $$
The gravity and friction terms determine whether low stiffness feels like deliberate compliance or like a loose mechanism. MABEL identifies the model closely enough to lower $\mathbf{K}$ and $\mathbf{D}$ for contact-rich interaction. The controller also caps damping against the discrete-time inertia of very light wrist joints, preventing a stiff gain from ringing or becoming unstable.
The repository's control engine has an explicit distinction between pure PD, impedance, and compliance. In compliance mode the stiffness is zero and gravity compensation plus damping make the arm back-drivable. In impedance mode a smoothed joint reference feeds the spring. Gravity feedforward is also applied to mechanism coordinates not owned by the torque law, including wrists, neck, lift, and torso outside the selected control group; otherwise those links sag when switching from position to torque control.
pure_pd = self.control_type == "pd"
K = self.stiffness if self.control_type == "impedance" else 0.0
D0 = self.damping + (self._damp_ratio * np.sqrt(K) if K > 0.0 else 0.0)
...
tau = b[dof] + K * (qdes - q) - D * qdThis agreement between the paper's equation and the public implementation is useful for replication. The exact gains remain configuration and hardware dependent, but the stiffness semantics, feedforward structure, and safety boundaries are inspectable.
6. Simulation, Data, and the ACT Path
The digital twin is not a separate demonstration environment with a different control API. MuJoCo and Isaac Lab models include all 59 actuated coordinates, 35 prebuilt scenes, and simulated camera and LiDAR streams. A simulation bridge uses the same command and observation shapes as hardware, so teleoperation setup, retargeting, recording, and learned policy inference can move between simulation and the real robot.
For the policy experiment, the authors collect 80 Vision Pro takes and segment them into 117 episodes, totaling 38.0 minutes and 68,364 frames at 30 Hz. Each episode retains stereo head RGB, both wrist RGB streams, available depth, joint feedback, commanded references, base twist, and lift-jog commands. Raw records preserve timestamps and validity information; curated data choose the latest available sample from each stream on a common 30 Hz grid.
The state and action representation has 59 coordinates even though the policy experiment is mostly upper-body. It includes 14 arm joints, 34 hand coordinates, three neck joints, the torso, one coupled lift height, and six swerve coordinates. Keeping the full representation means the interface does not change when a future policy begins to use the base or lift. For the current task, however, those coordinates stay near their initial configuration.
The demonstrated task is a small-object grasp and placement on a plate with both ORCA hands. ACT receives the left head image and both wrist images at $320\times240$, plus the previous second of joint positions sampled at 5 Hz. It predicts 120 future joint-reference steps, or four seconds at 30 Hz, and executes the first second before planning again. No temporal ensembling is used. Training lasts 8,000 steps with batch size 24 on an Apple M1 Max and takes about six hours.
The policy's output is not sent directly to motors. Each predicted joint reference enters the same whole-body controller used during teleoperation. This is the central systems claim: the learned model predicts a body-level command trajectory, while the controller continues to provide impedance, collision constraints, and hardware-specific conversion. Data collection and deployment share the meaning of an action.
flowchart LR
V[Vision Pro head and hand tracking] --> R[Whole-body retargeter]
R --> B[Comfort-box body split]
B --> T[Torso pitch and lift height]
B --> M[Swerve base reference]
R --> A[8-DOF arm IK]
R --> H[16-joint finger IK]
A --> C[Self-collision velocity QP]
H --> C
M --> Z[Height-aware ZMP scaling]
T --> C
Z --> C
C --> I[Joint impedance and position control]
I --> P[Physical MABEL or MuJoCo twin]
P --> D[Head, wrist, depth, and joint records]
D --> L[Curate on 30 Hz grid and export to LeRobot]
L --> ACT[Train ACT to predict 120-step joint-reference chunks]
ACT --> C
7. Experimental Characterization
The evaluation does not attempt to prove general manipulation competence. It measures whether the platform is mechanically repeatable enough for research, whether its odometry is adequate for local teleoperation, whether visual feedback is responsive enough for an operator, and whether the software path can train and deploy a policy. The mix is appropriate for a platform paper because each experiment tests a different layer that must remain stable when the others are combined.
7.1 Upper-body repeatability and path following
In the repeatability test, each palm visits four checkpoints from a common home pose over ten cycles while the upper body runs PD control with gravity compensation. The median repeatability is 1.65 mm, and the best checkpoint reaches 0.46 mm. The torso contributes the largest joint-induced error at 0.56 mm RMS per palm. These numbers are not a statement of absolute end-effector accuracy against an external metrology system; they characterize return variation within this mechanism and controller.
For path following, both palms trace mirrored spirals with 10 cm radius and squares with 20 cm sides across three trials, at torso pitches of 0 degrees and -10 degrees. Geometric path RMS error is 3.7-6.7 mm. Time-aligned error is 15-19 mm because the palm lags the commanded reference. When that lag is compensated, RMS error falls to 5-9 mm. The separation is informative: a large part of the apparent tracking error is timing, not spatial distortion.
Gravity feedforward has the largest single effect. Under compliant gains, palm error drops from 194 mm to 45 mm. This result explains why the software emphasizes model-based feedforward rather than simply increasing stiffness. Raising gains could suppress sag, but it would also remove the back-drivable behavior that the hardware was designed to provide.
| Test | Condition | Reported result | Interpretation |
|---|---|---|---|
| Palm repeatability | Four checkpoints, ten cycles, four visits each | Median 1.65 mm; best 0.46 mm | Suitable for repeatable laboratory manipulation experiments |
| Largest joint contribution | Scatter decomposition by joint | Torso 0.56 mm RMS per palm | Torso calibration and control dominate return variation |
| Geometric path error | Mirrored spirals and squares, two torso pitches | 3.7-6.7 mm RMS | Spatial shape is tracked more accurately than time |
| Time-aligned error | Same trajectories, direct comparison | 15-19 mm RMS | Controller lag is the main contributor |
| Lag-compensated error | Shifted timing comparison | 5-9 mm RMS | Most residual error disappears after accounting for delay |
| Compliant palm error | With versus without gravity feedforward | 194 mm to 45 mm | Model compensation is essential for low-stiffness control |
7.2 Odometry
Wheel odometry integrates drive-encoder motion and steering angles from the three swerve modules. It is compared with visual-inertial position from the ZED camera and IMU heading. On a repeated local path of 5.72 m completed in 121 s, RMS disagreement is 13.5 mm in position and $1.63^\circ$ in yaw. On a turn-and-square trial of 1.55 m in 35 s, disagreement is 17.7 mm and $1.47^\circ$.
These values support the use claimed by the authors: the body reference from the comfort-box split is tracked in the odometry frame during a teleoperation session. They do not establish long-horizon localization, map consistency, or drift over an entire building. The paper explicitly points future work toward onboard localization and mapping, so the result should be read as local command tracking rather than navigation-grade state estimation.
7.3 Glass-to-glass latency
Latency is measured with a Gray-coded clock shown on the operator's screen, filmed by the robot head camera, and then observed when the image returns to the same display. This creates a shared start and end clock and captures camera exposure, encoding, transport, decoding, and display. Across three 20-second trials for hotspot and LAN and four for direct Tailscale, mean per-trial medians are:
| Connection path | Mean glass-to-glass latency | Variation | Main observation |
|---|---|---|---|
| Robot Wi-Fi hotspot | 137 ms | +/- 5 ms | Fastest measured route |
| Local area network | 150 ms | +/- 0.2 ms | Very stable but slightly slower than direct hotspot |
| Direct Tailscale peer-to-peer | 161 ms | +/- 16 ms | Usable, with more route-dependent variation |
| Public relay | about 260 ms | Partly derived | Relay transport adds roughly 145 ms |
The camera accounts for 101-108 ms on every path, while encode, decode, and display add about 12 ms. Transport is the route-dependent term: 25 ms on the hotspot, 31 ms on the LAN, and 145 ms through the public relay. This decomposition is valuable because it identifies where a future system should optimize. Replacing the transport cannot remove the camera's share, even if network delay becomes negligible.
7.4 Policy result and teleoperated task breadth
The ACT policy succeeds in 8 of 10 autonomous trials. Objects are placed randomly inside a 20 x 20 cm region, and each trial has a 60-second limit. The split is by take, with 64 training takes, eight validation takes, and eight test takes, which reduces leakage between nearly identical segments of the same demonstration session.
Eight successes are evidence that the collection, curation, training, and deployment layers are connected. They are not evidence of robust mobile manipulation. The object set, placement region, and task are narrow; the base and lift remain near their initial configuration; and the policy is tested with one end-effector configuration. The paper states this limitation directly. The teleoperated household sequence is broader and shows table wiping, fridge opening, high-shelf reaching, basket carrying, dishwasher opening, and compliance, but those trials demonstrate the interface and embodiment rather than a learned autonomy benchmark.
Across the six teleoperation rows, the robot alternates which subsystem carries the task. Wiping uses dexterous hands and coordinated arms. Fridge opening combines base approach, arm force, head gaze, and torso. High-shelf reaching uses lift, neck, arm, and hand. Basket carrying requires both arms plus base motion. Dishwasher interaction uses torso pitch and arm reach. The final row applies external forces to the arm and torso to expose compliance. This matrix is more informative than a single success count because it shows why the platform cannot be reduced to a mobile base with two fixed manipulators.
| Compared system | Base | Arms and hands | Neck / body | Reported cost (USD) |
|---|---|---|---|---|
| Mobile ALOHA | Nonholonomic | 2 x 6-DOF; 1-DOF hands | No neck; fixed body | 32,000 |
| AhaRobot | Nonholonomic | 2 x 6-DOF; 1-DOF hands | 2-DOF neck; lift | 1,000 plus compute |
| XLeRobot | Holonomic | 2 x 5-DOF; 1-DOF hands | No neck or body travel | 660 |
| OpenPyRo-A1 | Fixed | 2 x 7-DOF; 1-DOF hands | No neck; waist | 14,000 |
| Reachy 2 | Holonomic | 2 x 7-DOF; 1-DOF hands | 3-DOF neck; no lift | 70,000 |
| Commercial range cited | Mostly holonomic | 2 x 7-DOF; 0-6 DOF hands | Neck and lift/torso variants | 69,000-120,000 |
| MABEL | Holonomic, 3 modules | 2 x 7-DOF; 2 x 17-DOF | 3-DOF neck; lift and pitching torso | 8,056 parts subtotal |
8. Limitations and What the Evidence Does Not Show
The first limitation is the lift. It buys a large vertical workspace at low cost, but it is slow compared with a purpose-built articulated body. This affects the fluency of whole-body teleoperation and would become more visible in long-horizon tasks that repeatedly change height. The authors propose a future folding body with waist, knee, and ankle joints as a faster alternative.
The second author-identified limitation is anthropometric mismatch. The OpenArm link proportions differ from human anatomy even though the overall reach and shoulder geometry are scaled. That mismatch complicates retargeting and can make some configurations feel less natural than the operator's movement. A future arm design with more human-like segment lengths could improve both embodied correspondence and workspace use.
The ACT experiment is intentionally narrow. It validates the pipeline rather than mobile behavior: the object placement is limited to 20 x 20 cm, the task is upper-body pick-and-place, and the base and lift remain near their initial values. The network predicts the full 59-coordinate representation, but prediction of a coordinate is not the same as demonstrated competence with that coordinate. Claims about mobile whole-body autonomy would require tasks that change base pose and lift height while manipulating.
The mechanical results are also bounded. Repeatability is measured within one robot and one setup, and odometry is compared over short local paths. There is no long-duration drift study, no repeated build-to-build characterization, and no comprehensive payload or thermal endurance test. The second unit demonstrates manufacture and assembly, not statistical reproducibility across many labs.
The cost should be interpreted with the same care. USD 8,056 is a parts subtotal for one compute configuration and excludes optional sensors. Labor, machining access, failed prints, tools, and integration time are not included. The robot's use of sourced OpenArm and ORCA components improves practicality, but dependence on specific vendors can still affect replication when parts or prices change.
Finally, safety is addressed at the command and joint levels but not as a complete certification story. The ZMP envelope, capsule collision constraints, velocity limits, and compliant control reduce risk, yet a 61.8 kg robot with a moving lift and dexterous hands still requires supervised operation, emergency stopping, workspace rules, and validation for each site. The paper demonstrates research safety mechanisms, not a consumer or industrial safety case.
9. Why the Shared Command Interface Matters
The most reusable idea in MABEL is not a single equation. It is the decision to make the representation of an action stable across teleoperation, simulation, data collection, and policy execution. A policy predicts joint references, but the deployed controller still owns impedance, self-collision, base limits, and device conversion. The learned model therefore does not need to absorb low-level hardware safety in the same training sample, and a controller improvement can apply to both human and autonomous control.
That design also exposes where learning stops. The ACT model does not choose a safe grasp force from first principles, infer a collision-free path, or understand that a higher lift changes tip-over limits. It predicts a trajectory within an interface whose surrounding controller handles those functions. For the current narrow task, that separation is enough. For longer autonomy, the authors point toward onboard mapping, longer-horizon whole-body policies, and foundation-model task planning over learned skills.
The open release extends the contribution beyond the eight-page paper. A team can inspect the CAD, firmware, ROS 2 stack, retargeter, controller, digital twin, and learning pipeline. The repository contains direct evidence for several paper equations, including the arm and hand objectives, swerve velocity relation, ZMP utilization, collision-barrier rows, and impedance law. This makes the platform unusually auditable for a hardware paper, even though reproducing it still requires substantial engineering work.
10. Conclusion
MABEL combines a low parts subtotal with a capability set that is normally reserved for expensive mobile bimanual robots. The three-module holonomic base provides mobility; the lift, torso, neck, arms, and hands cover floor-to-overhead interaction; back-drivable joints support compliant contact; and Vision Pro tracking turns sparse operator observations into whole-body commands. The reported 137 ms hotspot latency, millimeter-scale repeatability, centimeter-scale local odometry, and eight-of-ten ACT success rate establish that the integrated system works under controlled experimental conditions.
The limitations are equally concrete. The lift is slow, the arm proportions are not fully human, the policy experiment does not validate mobile autonomy, and the cost excludes labor and optional sensing. These constraints do not erase the platform contribution. They define the next engineering questions: a faster anthropomorphic body, longer-horizon whole-body learning, onboard localization and mapping, and task planning that can compose learned skills.
The paper's strongest claim is therefore institutional as well as technical. A university laboratory should not have to reconstruct teleoperation, simulation, controllers, data formats, and learning infrastructure from unrelated components before studying mobile manipulation. MABEL offers one shared open embodiment and one shared command path so that experiments can accumulate on a common base.
Golden quote: The platform's value is not that 56 degrees of freedom are impressive in isolation, but that the same body-level command can be produced by a person, a simulation, or a learned policy and still pass through one inspectable safety and compliance layer.
Traceability: This analysis is based on the full arXiv HTML and the public code at commit 2f9229f822b78877ed554d80649e2b7c41a0cbda. Original paper: https://arxiv.org/abs/2611.04083. Project site: https://robotmabel.github.io/website/. Code: https://github.com/robotmabel/open_mabel.
