Hello again. Last month was about getting the foundations in shape; this month was about wheels turning and maps building. June was a hardware month — the kind where you spend an evening with a multimeter and a servo that’s spinning the wrong way, and then suddenly a robot does the thing.

The wheelchair robot (built from scratch)

This one ran away from me in the best way. The plan was modest — “mount the Pi, do one RC-driven test run.” Instead, I built the whole robot.

It’s an electric wheelchair turned into a tank-drive robot. Arduino running a DBH-12V dual motor driver (with a verified pin map, which took a couple of goes), RC tank-drive on the sticks, and — the part I’m most pleased with — a latching e-stop with a 300 ms watchdog. If the control link drops, it stops. If you hit the e-stop, it stays stopped until you deliberately reset it. When you’re building something that weighs as much as a person and can pull away from you, that’s not a nice-to-have.

All of it runs through one control daemon: e-stop, RC drive, and onboard journey recording (LiDAR, IMU, GPS, camera) in a single process. The recording side reuses the pipeline I built for the G-Wiz telemetry rig last month — record a run, upload it, replay it in the browser on a map ready for some AI processing.

TurtleBot2 / Kobuki — SLAM on a Jetson, driven through the platform

This one was a resurrection. The Kobuki TurtleBot2 had been sitting unused for years — an ancient NVIDIA Jetson TK1 for a brain, Ubuntu 14, ROS1, the whole lot frozen in time. This month I dragged it into the present: a newer Jetson, and ROS2 Humble running in a Docker container — which is the neatest way to get a modern ROS2 onto older Jetson hardware without reflashing the whole board and fighting its ancient OS. From there, it’s wired into the same control stack as everything else, so I can drive it and watch its map from the browser. Xtion depth camera for the laser scan, slam_toolbox for mapping and multi-waypoint navigation. Driving it to a series of waypoints and watching the map fill in is genuinely satisfying.

Reviving it wasn’t free, though — and the camera is where it bit me. Depth-camera SLAM on the Jetson is right at the edge of what the hardware can do. A real LiDAR gives you a clean 360° scan; a depth camera gives you a narrow forward cone faked into a laser scan, and on a Nano, the whole pipeline is fighting for CPU. You lose the map the moment you turn too fast, and loop closure is fragile because the robot can’t see enough of the world at once. I got it mapping and navigating — but I also got a concrete feel for why people put a proper LiDAR on anything they’re serious about, and why a beefier compute brain (the Jetson Orin on my bench is the obvious upgrade) changes the game. That’s the kind of lesson you can’t read in a tutorial. You have to drive the thing into a wall a few times.

PiBob — ROS2 driver, hardware-verified end-to-end

PiBob (my Pi-brained humanoid) crossed the finish line in ROS2 this month. I went from a URDF that frankly didn’t look like the actual robot — arm meshes floating in the wrong places — to every part correctly seated and mirrored per side, and then I drove the real servos from the RViz sliders.

The hardware test more than earned its keep. It caught a driver bug where the bridge had never actually loaded the joints — so it was cheerfully POSTing nothing to the servos — plus three servos wired to turn the wrong way. None of that shows up in simulation. You only find it when a real arm moves and goes, “That’s not right.”

https://github.com/burf2000/PiBob/tree/main/ros2

The Sanbot turned out to be holonomic — and the SDK never said so

The biggest surprise of the month came from a robot I’ve owned for ages: the Sanbot Elf. I’m building a proper ROS2 driver for it — putting a vendor-locked Android humanoid onto the ROS2 graph with standard topics, so normal robotics tooling can drive it like anything else — and while reverse-engineering its OpenSDK I started poking at the wheel commands one at a time.

It has three omni wheels, and it turns out it can strafe sideways and spin on the spot — full holonomic motion — none of which is in any documentation I could find. The SDK just exposes a pile of motion codes with vague names, and the only way to learn what each actually did was to fire it at the real robot and watch. So I did: send code 3, it spins left on the spot; code 10, it slides sideways a metre and a half without rotating. Watching a service humanoid crab across the room when you had no idea it could is a proper “wait, it can do that?” moment.

I wrote the whole thing down — which code does what, plus the gotchas (the “turn” codes are actually orbits, not on-the-spot spins, and read reversed) — so the next person, probably future me, doesn’t have to rediscover it. The driver itself is still in development, but the hard part — knowing what the robot can actually do — is mapped. A robot is often far more capable than its own manual admits.

Honest scorecard

• Sanbot ROS2 driver + holonomic discovery — ✅ driver built; omni motion (strafe/spin) mapped and documented.
• Wheelchair robot — ✅ built and hardware-verified, way past plan.
• TurtleBot2 SLAM + nav — ✅ mapping and navigating, with a clear-eyed view of the depth-cam limits.
• PiBob ROS2 — ✅ done, real servos driven from RViz.
• Heterogeneous fleet driver — safety-hardened, getting more solid each month.
• Meta Quest teleop for PiBob / Inmoov — ❌ built but could be better, not fully tested with the Inmoov
• Burf Platform improvements — Security fixes and simple SLAM / A* navigation added to Burf Platform

What’s next

First job is getting the wheelchair onto ROS2: sensors properly mounted, a URDF built from the real mounting positions, laser-odometry and slam_toolbox, so a driven journey turns into a live 2-D map in the browser. Drive it around a room, watch the map appear — that’s the satisfying full-circle moment. Then the fun part: run all that recorded trip data through some AI — every run captures LiDAR, IMU, GPS, and camera, and all that data is begging to be learned from rather than just replayed.

Alongside that, two longer threads. Keep building out the platform that ties these very different robots together — more of the control, telemetry, and fleet features that make a pile of one-off robots behave like one system. And keep levelling up my ROS2, which every one of these builds quietly pushes a bit further.

For a part-time evenings-and-weekends operation, June was a good month: four very different robots, all moving, all talking through the same stack. That’s exactly the direction I wanted this to go. More next month.