Nice, funny timing. I've built a desktop UI around the same workflow, but for the RoArm-M3 (json over serial, so it needed RoArm-specific handling plus a VR teleop and an RSI tab). Is LeLab tied to SO-101 or can it take custom robots? I've got a native RoArm LeRobot port PR open, would be cool to plug it in.
No RadioShack in Switzerland, so I never had the Armatron as a kid. The thing did 6 degrees of freedom on a single motor and a clever gearbox. I now need a Blackwell to teach two arms to stack a cube. Draw your own conclusions ๐ค
@nurvai_ai@SHOW_ROBOTICS It's a leader arm, you backdrive it by hand to puppet the follower, so it carries no payload. That's why koch uses uniform xl330s, no per-joint sizing needed.
Just finished building a Koch v1.1 leader arm on the @SHOW_ROBOTICS workbench.
The Dynamixel XL330 servos feel noticeably smoother to backdrive than the RoArm / SO101 ones, whose gearboxes need a bit of force to get going.
Still can't tell if I'll prefer this new leader over VR teleop. But I won't lie, VR set up right feels really good.
@LeRobotHF Actually that post is RoArm-M3, which isn't in lerobot yet, the b601 is a different arm. I ported the RoArm to native 0.5.2, happy to upstream it.
That was a long weekend ๐
When we picked our hardware we'd just spent a year on 3d printing and wanted something off the shelf, so we got a pair of Waveshare RoArm-M3 AI kits, sold as "@LeRobotHF integrated."
Turns out the Waveshare LeRobot support is a fork that hasn't moved since mid-2025. being locked to it meant we couldn't record native LeRobot v3 datasets, plus a few things we didn't see coming:
- Native v3 lands in lerobot 0.4.0+. the fork is stuck on 0.1.0, so every recording had to go through a fragile v2.1 to v3 conversion.
- The fork uses the old lerobot.common API that upstream has since removed, so none of the modern train/eval tooling worked for us.
- The RoArm isn't an SO-101. it talks JSON over serial through an ESP32, not the clean Feetech binary bus. that gave us a feedback flood causing stale state reads, a 115200 baud usb ceiling while the servos run at 1Mbps internally, a firmware quirk forcing a double write on the gripper, and a singularity when driving it in cartesian over VR.
So we did the boring but necessary thing and ported it properly.
- Wrote the RoArm-M3 as a native lerobot 0.5.2 robot plugin, recording native v3 (no more conversion step)
- Reflashed the firmware 115200 to 1Mbps, state reads went 23Hz to 42Hz, teleop is smooth at 30fps now
- Studied the native SO-101 stack to see what we were doing wrong, then fixed fps mismatches, loop overrun blind spots, undistort cost and inference handling
- cut ~1400 lines of dead 0.1.0 code from the UI
We should probably upstream the RoArm 0.5.2 LeRobot so other RoArm owners don't hit the same wall, till then hit me with a DM if you need it.
Bonus: Small tour of the @SHOW_ROBOTICS workshop
The RoArm's VR teleop kept swinging the whole arm when we turned the wrist.
What threw us off: we leaned on the arm's native firmware IK. It couples position and orientation across all 6 axes, and you can't decouple it. So we drifted off the approach @aurel_arnold had laid out.
Went back to it: our own IK in MuJoCo, decoupled Pieper-style, audited before touching hardware. Now the wrist turns, elbow at 0ยฐ, arm tracks my hand to the mm over WebXR.
Still chasing one IK singularity that shows up at a certain height. Next.
@SHOW_ROBOTICS
Burning Claude tokens like there is no tomorrow:
- refactor of the entire stack
- transfer memory palace knowledge to skills
- port WaveShare RoArm M3 to LeRobot 0.5.2
- tweaking record-eval parity and teleop smoothness
@DominiqueCAPaul Interesting that the hard parts overlap. Planning a DAgger step at the end of our stacking pipeline too, how do you trigger interventions, button on the controller?
@DJiafei thank you, that would genuinely help ๐ setup changed since that dataset so i'll record fresh VR teleop demos. two Qs so it's right for you: how many demos, and ideal cam placement? i've got two RGB + a realsense (depth optional). i'll push to the hub in v3 and send the repo-id.
Refined the stacking path.
Out: MuJoCo sim, synthetic data, scripted policies. In: real-world RL only.
1. ACT on VR teleop demos, target 30-50% on 2-cube (matches SmolVLA paper baseline for ACT)
2. TOPReward for automated reward via VLM logits (Chen et al, Feb 2026)
3. ZPRL bottleneck latent online RL on frozen ACT to push 70%+ (Yu et al, May 2026)
4. Then 3-cube stacking, territory not yet published in the modern imitation learning corpus
Pivot from yesterday's plan. Sometimes the right call is to drop the wrong path before shipping.
PS: behind the scenes clip is in french, that's how Iris and I talk. also yes that's me pinching my finger in the gripper, occupational hazard ๐
@DJiafei Awesome! I keep hitting training collapse fine-tuning Molmo on our RoArm-M3, tried frozen then full FT per your earlier advice, still collapses. Given it's a low-cost arm way outside the pretraining distribution, what approach would you actually take for hardware like this?
Caveat I should add: ZPRL was demonstrated on flow-matching policies. ACT's transformer encoder-decoder is exactly the entangled cross-attention architecture the paper flags as an open question for latent steering. So Phase 3 either means switching base to flow-matching, or using an action-space RL method (EXPO-style edits) which is architecture-agnostic. Part of what I'll figure out.