Hello Pololu community,
In a previous build, I coordinated four Pololu robots to perform a computer-directed sweep of a small grid. We had some Crazyflies around the lab, so I decided to integrate them into the system I’ve been designing. The long-term goal is a low-cost testbed with both air and ground assets, but for this project I focused on coordinating Crazyflie drones and Pololu robots to move to a series of grid waypoints together. Instead of the old design with hard-coded “legs” for the Pololus, this version uses go_to functions for both the Pololu and the Crazyflie, establishing true grid-awareness on the ground robots. The 3D Crazyflie grid and 2D Pololu grid have aligned x and y axes (with a .2m offset that I didnt have time to fix but will in a later project), enabling the use of the same waypoints. This work was done as part of a research team under Dr. Honary at the University of San Diego.
The system has three pieces: The ground robot (Pololu 3pi+ 2040 running MicroPython) follows a taped grid, counts intersections, and reports status and coordinates. The bridge (an ESP32) relays MQTT ↔ UART so the ground robot and the computer can talk reliably. The hub (a computer script) commands the Pololu over MQTT and flies the Crazyflie via cflib (takeoff/waypoints/land).
On the Crazyflie side, I first tried to control the drone over the BLE protocol, but that would have cut off access to classes like high_level_commander (and key functions like takeoff and go_to). That route would have meant a ton of extra work to re-implement controls. To avoid that, I stuck with the Crazyflie PA radio system and used the hub (a jetson nano in this case) as a translator between the PA link and the MQTT-based Pololu messaging system.
On the Pololu side, I moved away from “turn and drive N intersections” commands sent from the computer. The robot now accepts waypoints in meters, converts them to an intersection count using the configured grid cell size, and then drives itself to that intersection. I also reorganized messaging: instead of a single status topic per robot, each robot now publishes on a small set of topics that separate out the information I’ll need in later editions.
Overall flow is simple: after the Pololu calibration and the Crazyflie’s initial takeoff, the hub sends the first waypoint. The next waypoint isn’t issued until the Pololu confirms it has reached the current location. There’s a lot of room to improve this, but it worked well for the demo since the Crazyflie is much faster than the ground robot.
Takeaways: the big improvement was pushing navigation down onto the robots themselves—moving the “brain” from the hub to the agents. In this setup the hub behaves more like a router than a brain. I also now have a reliable protocol for dual operation of Crazyflie drones and Pololu robots that I can build on. Next steps are to finish a fully autonomous ground system and then fold the drones into it using the basic program I established here.
Hardware:
Crazyflie loco positioning package
Pololu 3pi+ 2040 Robot
Wifi setup
Computer with cflib and MQTT (mosquitto broker)
Link to previous project: Computer-Driven Grid Sweep with 3pi+ and MQTT