Leveraging Godot for PolyMap Visualization
Introduction to PolyMap and Visualization Goals
PolyMap is my experimental platform exploring multi-agent, robotic swarm-based Simultaneous Localization and Mapping (SLAM) strategies for mapping real-world environments. Development has been incremental: starting with a simulation, robot agents, a mapping manager, and basic visualization. One key goal was to leverage existing technologies like game engines to rapidly create an operable system. Game engines also offer a natural interface to visualize the spatial data generated by the robots as they explore physical space—and it’s just really cool!
Why use a game engine instead of existing tools like RViz? There’s no single answer. RViz and others are developed for the ROS environment and are reportedly easy to integrate with ROS, but I haven’t explored ROS yet. Possibly due to hardware constraints or concerns about getting locked into a specific architecture, I’ve chosen instead to learn the fundamentals of the (robot) science before adopting fully developed solutions. This is also exactly why I’m starting with a single ultrasonic sensor rather than a Lidar for spatial sensing. There is a vast amount of unbuilt software needed in this space, and I want to understand the basics before being embedded in one ecosystem. (A related question: is ROS becoming a walled garden?)
I chose Godot because it’s open source, has no license fees, and has a large community. It can render immersive 3D environments with advanced graphics and interactivity—features that would take far longer to build from scratch. This makes enhancements like zooming, panning, robot tracking, and detailed exploration straightforward. Overall, it’s a friendly platform for any maker stepping into games or 3D visualization. Plus, Thor from Pirate Software thinks "Godot is the Blender of game engines". 😉
Transitioning from Python to Godot
The original Python-based visualization tool was a solid proof-of-concept for displaying the global map and robot telemetry. As the project matured, I planned to try a game engine to overcome Python’s limitations in interactivity and feature expansion—where everything had to be built from scratch.
Transitioning to Godot 4.4 opened new possibilities for a more fluid UI. Because PolyMap uses MQTT for distributed communication, multiple visualization clients can consume the same data. This architecture also means each component can be developed in the best language for its function: the simulation and map manager will stay in Python, while the robot agent code (currently Python) will move to C++ for real hardware deployment. 🤖
Here is a video showing the transition and new version:
Integrating MQTT Communications in Godot
A critical aspect of PolyMap is using MQTT for data exchange. Fortunately, people like Goatchurch paved the way by porting MQTT code into Godot. It was showcased at a Godot convention, and most importantly, their open-source work on GitHub allowed me to clone it. Within a short time, messages from my existing Python version appeared in Godot. Once the MQTT connections and message handling were in place, communications were solid, letting me focus on features and functionality.
In the prototype, there’s a connectivity dialog box where the user enters the server URL, port, user ID, and password. It also allows topic subscriptions and message publishing. In this setup, the visualization subscribes to global_map and telemetry topics. Currently, the entire 100×100 integer map is broadcast every second, alongside telemetry data from the robot agents.
Using Godot
One of the most exciting aspects of Godot is how easily you can configure screens and add new features. Godot is heavily object-oriented; everything is a Node with attributes and methods. It reminds me of early “thick client” GUI development (pre-Web, like Acius 4D). This is my first Godot project, so I’m still learning and deciding how much to configure in the editor versus coding in scripts. Right now, screen elements are configured in the editor, while global map rendering is done in code.
There is a learning curve to working with Godot, but I understand it is very similar to other game engines like Unity and Unreal engines. For me, it was natural to code with an AI (or two, or three) to help me quickly learn how Godot works. There are also good videos on YouTube as well such as this video. One issue I ran into was that many of the AIs did not know how Godot 4.4 had changed from earlier versions, there was a constant effort required to correct the AI when it was off hallucinating. 🙂
Building the first prototype had its challenges: positioning the camera to view the map, deciding where to place MQTT functions, and balancing performance between rendering each grid point individually or using a grid mesh. Once I got the hang of Godot, it was surprisingly simple to get the visualization working. Adding a mouse-wheel zoom took only five minutes. I’m excited to add more capabilities quickly!
Future Features
With the first iteration working, here’s what I’m planning next:
- Persistent Map: I can choose between redrawing the global map each time, or making it more persistent and only updating changed elements as the are discovered by the robot.
- Free Fly - Camera: I will change the primary camera and give the user the ability to 'free fly' over the map moving around the landscape discovered by the robots.
- Robot FPV: It should be possible to put a camera in each of the virtual robots, allowing the user to select the robot and view the 3D space from its perspective.
Looking ahead, I’m breaking out the map manager and robot agent code from the simulation, moving toward a distributed computing platform. This is a key step for migrating from simulation to real hardware. Stay tuned for more updates!
