Building a GELLO Leader Arm for Franka FR3: Hardware Assembly, Wiring, and Pitfalls

01 · Introduction

What this guide is for

My hardware setup

• Follower robot: Franka Research 3 (7-DoF), with a Robotiq 2F-85 / Franka Hand gripper.
• Leader: GELLO arm built from the gello_mechanical/franka_fr3 design.
• Actuators: 7× DYNAMIXEL XL330-M288-T (joints) + 1× XL330-M077-T (gripper trigger).
• Controller: ROBOTIS OpenRB-150, daisy-chaining the bus to the PC over USB-C.
• Software: gello_software (driver) + RLinf gello-teleop (FK + agent).

02 · Bill of Materials

What you need to buy and print

03 · Mechanical Assembly

Putting the arm together

Cable routing & base mounting

Route each lead along its link with enough slack to survive the joint's full range — a cable that's taut at one extreme will unseat its connector or cap the motion. Finally, fix the base so the leader can't tip during teleop and its reach maps comfortably onto the robot's workspace.

04 · Wiring

From servos to the PC

The XL330s share a single 3-wire TTL bus: each servo has two ports, so you chain them servo-to-servo from the base out to the gripper. The first servo plugs into the OpenRB-150's white Dynamixel port; the board is the bus master and talks to the PC over a single USB-C cable that carries both power and data.

It enumerates as a USB CDC-ACM serial device — on my machine /dev/ttyACM0(note: ACM, not the FTDI ttyUSB* some docs assume). Confirm it before going further:

ls -l /dev/serial/by-id/      # stable name for the OpenRB-150
ls -l /dev/ttyACM0            # what gello_software expects

Set each servo's ID before you chain them

This is the step that bites everyone: every Dynamixel ships with the same factory ID (1). Put them all on one bus and they answer at once and collide, so a scan flickers between seeing one device and none. Before building the daisy-chain, connect one motor at a time and use ROBOTIS's software (Dynamixel Wizard 2.0, through the OpenRB-150) to write a unique ID to each — 1→7 for the joints from base to tip, and 8 for the gripper. Only one servo may be on the bus while you write, or the new ID gets broadcast to every ID-1 servo at once.

When external 5V is needed

For passive teleoperation — how GELLO is used here, with servo torque off — the OpenRB-150's USB-C power is enough; the arm only reads joint angles. An external supply (5V, ≥3A — 5A preferred, never 12V on XL330) only matters if you actually drive the servos: torque, damping, or virtual-spring mode. I first thought it was required and it wasn't — a misread of a torque-enable warning.

05 · Common Hardware Pitfalls

What actually cost me time

06 · First Power-On Checklist

Confirm it works before the robot moves

• ✓Board power LED on after USB-C connect.
• ✓Device appears under /dev/serial/by-id (and as /dev/ttyACM0).
• ✓All 8 motors detected on a bus scan (IDs 1–7 joints, 8 gripper) at 57600 baud.
• ✓Joint signs correct — validated by end-effector tracking, not single-joint motion (§7).
• ✓Joint offsets calibrated against a known reference pose.

Reference: my calibrated config

After ID assignment and calibration, the per-port config GELLO reads from looked like this — the offsets and signs are build-specific, so yours will differ:

# gello_agent.py  PORT_CONFIG_MAP entry
"/dev/ttyACM0": DynamixelRobotConfig(
    joint_ids     = (1, 2, 3, 4, 5, 6, 7),
    joint_offsets = (3.142, 6.283, 6.283, 1.571, 9.425, 4.712, 3.142),
    joint_signs   = (1, 1, 1, -1, 1, -1, 1),
    gripper_config= (8, 184, 142),   # (id, open, close)
)

07 · Notes for FR3 Teleoperation

How it behaves once it's live

Passive GELLO has no force feedback

The leader's motors are torque-off; it senses your motion and never pushes back. You feel the spring and the arm's own inertia — nothing from the robot or its contacts — so move deliberately, especially near objects.

The FR3 syncs to the GELLO pose, not its joints

One subtlety reframes all the calibration: RLinf's GELLO path is not a joint-to-joint leader/follower. It runs forward kinematics on GELLO's joints to get an end-effector pose, takes the Cartesian delta against the robot's current tool pose, and lets inverse kinematics redistribute it across the real joints.

GELLO joints ──(offset, sign)──▶ joint angles
        └─▶ FrankaFK ─▶ end-effector pose
              └─▶ Cartesian delta vs current TCP
                    └─▶ IK ─▶ robot joint commands

So moving one GELLO joint does not move the matching robot joint — the robot tracks the end-effector, and IK can hide a wrong joint sign entirely. Validate with whole-arm EE tracking instead. It also means the action space is an EE delta — the same space the policy I was evaluating (π₀.₅-DROID) uses, so leader, dataset, and model all agree.

Always align before enabling the controller

Before each session, pose GELLO to match the robot's home, then enable teleop. Enabling with a large mismatch commands a big instantaneous EE jump — align first, every time.

08 · Teleoperation in action

Driving the FR3 to collect demonstrations

How the data-collection pipeline is wired — RLinf's real-world env, the Polymetis controller backend, and the LeRobot dataset it produces — is documented on the FR3 cell page →