From Pygame Script to Robot Operating System

The original mDetect robot could already do something impressive: find its own position in a tunnel with no GPS, using just wheel encoders, an IMU, and a LiDAR. But the software behind it was a single Python script with a Pygame window — press a key, send one command down a serial cable, and that was the whole system. It proved the localisation idea worked, but it had no map, no path planning, and no way to add a sensor without rewriting everything. So for this next stage, called AutonomousRobot, I kept the exact same physical robot and gave it a proper robotics stack underneath: ROS 2 Humble, split across two machines the way TurtleBot3 does it — a Raspberry Pi running the low-level driver stack, and a workstation running RViz2, SLAM Toolbox, and Nav2.

What Actually Changed

The old system was a remote control: one script, one computer, one input source, no map. The new system can look at a map and figure out how to get somewhere on its own — click a point in RViz, or now type an exact x_mm, y_mm, heading_deg into a custom Goto panel docked right next to Nav2's own, and it plans the route and drives it, watching the LiDAR the whole way. A custom Teleop panel sits next to it for manual driving, so nudging the robot clear of an obstacle no longer means a separate SSH session. Teleop, manual test commands, and autonomous navigation all pass through a single arbitration node (cmd_mux) before reaching the motors, with a dedicated safety layer that stops the robot near obstacles no matter which of the three is currently driving.

Watch it in action:

None of the test runs were clean, obstacle-free demos, either — Nav2's local planner had to trigger recovery behaviours mid-route to work around clutter in the room before closing the last few centimetres to the goal, which is exactly the kind of real-world messiness the old Pygame script had no way to handle.

The Hard Parts

Getting there took more than installing ROS 2 and hoping for the best. The Raspberry Pi and the workstation had to agree on network settings before they could even see each other's data, which meant real troubleshooting on Wi-Fi. Nav2 also doesn't ask permission — it always publishes its final drive command on the same topic name no matter what, so cmd_mux had to be built around that fact instead of fighting it. On the hardware side, the Arduino and the LiDAR share the same USB chip, so the Pi couldn't reliably tell them apart until the udev rules were rewritten around which physical port each device was plugged into. Some of the trickiest bugs weren't in the robotics code at all. Early on, the robot's ROS 2 package could quietly turn into a disconnected copy instead of a live link back to the source, so edits stopped taking effect and nobody noticed until behaviour didn't match the code — that had to be caught and automated away. The Arduino firmware also needed a full rewrite: a cleaner command format, a watchdog that stops the robot if the network link drops, and an emergency stop that has to be cleared on purpose rather than releasing itself.

What I Achieved

By the end of this stage, the same physical robot that once needed someone at a keyboard could be pointed at a location on a map and drive there itself — planning its own path, watching for obstacles with the LiDAR, and stopping safely if anything went wrong. Just as importantly, the whole install process for a new machine collapsed into a single script, which matters more than it sounds like: it means the project can now actually be repeated and handed off, instead of only living in one person's head.

What's Next

The next milestone is fusing all three sensors — encoders, IMU, and LiDAR — into a single, better position estimate instead of relying on them separately, then testing the whole stack in a real tunnel rather than a lab. Read the full technical writeup