Minone - Starting the build (#2)

Early minone - TNERA MVP Robot

Minone Build Log #2: The Grind Begins

Minone is a Minimal Viable Robot, built as a prototype for my development of PolyMap, a multi-agent mapping system. It’s a bare-bones junkyard robot—scrapped components, an ESP32-S, and some basic electronics. And let me tell you—it’s fantastic for learning how the real physical world and the virtual one collide. And boy, does it grind.

Core Components:

• ESP32-S dev board
• L298N - motor driver
• Scraped Roomba Motor Modules (with encoders)
• HC-SR04 Ultrasonic Sensor
• MG90 servo
• and a 12V/5V power bank

Here is a highlevel schematic of how they are connected together:

Everything’s wired up pretty simply—and that’s where the real problems start. 😄

Voltage in and out: 3.3V vs 5V

The ESP32 runs at 3.3V logic, but nearly all my sensors are 5V devices. That means input signals need to be stepped down, which I’ve handled using voltage dividers. No big deal.

The trickier part? Outputs. The PWM signals that drive the servo, trigger the ultrasonic sensor, and control the motor driver are all a bit underpowered at 3.3V. Some devices tolerate this. The L298N? Not so much.

That means it’s time to level shift those outputs. A voltage divider doesn’t cut it here. I’ll be testing a proper level shifter soon to ensure robust 5V signaling.

PWM Resource Conflicts on the ESP32

One of the most valuable lessons so far: PWM timers and channels are limited and easily conflicted.

At first, I had a nice ultrasonic sweep working via the servo—classic radar style. But after I added the motor drivers and encoder logic, the servo went haywire. High-pitched whining, jittering, and eventually… nothing.

What happened?

Turns out, the servo and motor driver were fighting over the same PWM channels. The servo took channel 0 by default. The motor driver was hardcoded to use channels 0 and 1. This conflicted both the frequency (servo at 50Hz, motor at 5kHz) and the timer allocations.

My first fix: reorder the initializations to let the servo grab a channel first. This helped, but wasn’t enough.

The real fix: manually assign a separate timer and channel to the servo. I dedicated timer 1 / channel 2 for the servo just before attaching its pin. That separated its timing cleanly from the motors—and everything started playing nicely again.

It cost me a bit of time, but the lesson was well worth it: don’t assume PWM resources will sort themselves out.

The Mysterious Unbootable EPS32

When shifting to local (robot power), Minone just… refused to boot. No errors, no logs—just silence. After way too much head-scratching, I finally pulled out the multimeter and discovered the culprit: the L298N motor driver was holding GPIO 12 and 15 high on startup. Turns out, those pins are a bit picky—they must be low for the ESP32 to boot.

No amount of code, pull-downs, or wishful thinking could override the voltage being held by the motor driver’s enable pins. The only fix? Move those signals to different GPIOs. I ended up switching to GPIO 19 and 22, and just like that—boot restored.

Sometimes, it’s not a bug—it’s physics.

A note about "Vibe Coding"

Throughout the development of Minone (and PolyMap), I’ve leaned heavily on LLM-based AI to guide the process—something the industry is starting to call Vibe Coding. As many have noted, Vibe Coding is a fast way to build software that might otherwise be just out of reach. And honestly? I recommend it, but not for beginners to coding.  [Update: Vibe Coding now has negative connotations. What I recommend is using it as a tool, not over dependence on it.]

AI has helped me rapidly prototype, implement features, and solve specific technical challenges. But beware—it’s not all smooth sailing.

Where AI shines is in writing clean, functional code based on known patterns. It’s excellent at pulling in details, explaining APIs, and even suggesting optimizations. But it often struggles with the human side of development—especially incremental development, integrating features, and aligning with the developer’s mental model.

A big part of my time is still spent going back through generated code line-by-line, trying to understand what it’s doing and whether it matches what I need it to do.

There are also assumptions—sometimes wrong ones. For example, in my code, the AI assumed the encoders were infrared-based, when in reality they’re Hall effect sensors. It’s up to the developer to catch those mismatches and feed corrections back into the conversation. Once pointed out, the AI adjusts quickly, but it doesn’t ask enough questions up front to avoid such errors.

Another example: determining the number of pulses per revolution from these old Roomba motors. This spec isn’t widely documented, and the AI couldn’t give a definitive answer. I had to dig through old boards and obscure web forums to figure it out.

The takeaway? AI is an incredible tool—but the human still needs vision, intuition, and a working understanding of how systems should behave. We’re closer than ever, but not quite at full autopilot.

Incremental Robot Development: ✅ Turning left 

Here’s a quick one: I connected one of the motors directly to the battery—pure chaos, purely intentional. 😄

Sure, it was just to confirm the motor worked. But from a test-first, incremental development perspective? We can officially check off:

✅ Turning left.

Progress!

State of the Platform

Minone is now stable. The essentials—WiFi, MQTT, sensor reads, sweeps, motor movement, and encoder feedback—are all working together smoothly.

The platform’s ready for the next steps:

• Fully Integrated into the Godot visualization
• A much much more curious Robot Agent
• Mapping the basement hallway - the Testing Goal

PolyMap: Leveraging Godot for Visualization (#3)

 

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 Godot?

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!

Polymap: Mulit-Agent SLAM Simple Simulator (#2)

Multi-Agent SLAM! with Distributed Data Fusion and Frontier Searching

PolyMap is an experimental platform designed to explore Robotic Swarm–based Simultaneous Localization and Mapping (SLAM) strategies across both simulated and real-world environments. The mission is to harness distributed robotic sensor data, real-time MQTT communications, and advanced data fusion to develop robust, collaborative mapping environments that bridge virtual (systems) and the physical (machine) world.

---

Recent Work

Robust MQTT Communications & Security
The MQTT infrastructure now enables secure, real-time data exchange between robot agents and the Map Manager. With brokers, subscribers, and publishers designed to run on distributed platforms, the system is designed to scale smoothly to multiple robot agents. Integrating data from distributed sources has enhanced the completeness of the global maps.

PolyMap MQTT pipeline

Frontier Searching Implementation
I have integrated frontier searching techniques—drawing inspiration from Yamauci, 1997—to systematically prioritize and explore unknown regions of the map. This approach is central to refining our mapping strategy by dynamically guiding the system to areas that require further investigation.

Enhanced Visualization
The python visualization is now somewhat fully functional, offering a clear and dynamic representation of the evolving global map. Real-time updates provide immediate robot telemetry and map fusion data, ensuring that the state of the environment is always accurately reflected.

YouTube Video Demo
Here is a YouTube video showing PolyMap in action. You can see the simulated robots navigate in a virtual environment, exchange data via MQTT, and merge their local maps into a dynamic global view—all in real time. 

---

Current Challenges

Robot Agent Behavior
While our simulation demonstrates significant progress, the robot agents exhibit limited exploratory behavior and are challenging to fine-tune. They often get stuck in corners, a behavior likely influenced by the coarse resolution of the current scanning technology. This is a complete topic that I will expand on more in the future.

Polymap: going long on Frontiers

PolyMap: Robot Agent Exploration

Operational Mode Transitions

In the system, robots cycle through distinct operational states that define their behavior during navigation. These include:

• Scan Mode: Actively gathering sensor data.
• Idle Mode: Maintaining a standby state when no immediate action is required.
• Obstruction Mode: Responding to detected obstacles.
• Frontier Mode: Venturing into uncharted areas for further exploration.

While these states provide a structured approach to managing robot behavior, the transitions between them need further review and refinement. Enhancing these transitions is critical to achieving smoother performance and greater responsiveness during navigation.

---

Upcoming Developments

Enhanced Sensing
We are set to incorporate a 'radar-like scan' into both our simulation and physical platforms. This upgrade will augment the capabilities of our single ultrasonic sensor, providing richer, more detailed environmental data.

Physical Implementation – Meet MinOne
The physical build of “MinOne” is now underway. This robot will serve as the real-world counterpart to our simulation, enabling us to bridge virtual testing with tangible, hands-on experiments.

Next-Generation Visualization
In our continuous effort to improve user experience and performance, we are evaluating the Godot engine as a potential upgrade for our visualization tool, aiming to deliver a more immersive and high-performance display.

Further Enhancements
Moving forward, we will focus on fine-tuning robot behaviors and sensor parameters, as well as exploring additional sensor integrations to boost mapping fidelity. The goal remains to develop a scalable and robust platform for multi-agent SLAM exploration and discovery.

---

PolyMap's evolution is driven by a relentless passion for iterative improvement and DIY robotics innovation. This project is about building something tangible—each challenge overcome and every feature refined brings PolyMap closer to bridging the gap between simulation and reality and expanding the boundaries of collaborative robotic mapping.

Minone - Introduction of my MVP Robot for SLAM Exploration

Exploring Robots are cool. Robots that map their surroundings? Even cooler. But there’s a massive difference between slapping together a chassis and motors and actually building a robot that can autonomously explore and create a map of its environment. That’s the problem I’m setting out to tackle with Minone, my MVP (Minimum Viable Prototype) for an exploration-focused robot.

Minone - MVP for SLAM

Why Start Simple?

Most SLAM (Simultaneous Localization and Mapping) discussions dive straight into complex sensor suites—LiDAR, stereo cameras, high-end IMUs—but I’m deliberately taking the opposite approach. Instead of relying on fancy hardware, Minone is built to push the limits of simple sensors, starting with nothing more than an ultrasonic distance sensor (HC-SR04).

Why? Because understanding SLAM at its core—filtering noisy sensor data, estimating position, and reconstructing an environment—is much more valuable than just plugging in a high-end sensor and hoping for magic. I want to see how much useful data I can extract from the bare minimum before moving on to more advanced solutions.

A Scrap Yard Robot

In true MVP fashion, I built Minone from whatever I had lying around:

• Chassis: The top of an old wine box. (Recycling counts as engineering, right?)
• Motors: Two Roomba drive motors salvaged from an old unit.
• Caster Wheel: From a trashed suitcase. (Turns out, old luggage makes for decent robot parts.)

It’s the ultimate scrap yard robot, which makes it easy to modify as I iterate. That’s already proving useful, since I’m starting to regret my choice of a trailing caster wheel—turning is fine, but the bot has a tendency to tip forward. A problem for Future Me to solve.

Electronics & Control

For brains and motion control, I’m using:

• Microcontroller: ESP-32S
• Motor Driver: L298N H-Bridge

This will be my first time working with an ESP-32S, so I’m looking forward to seeing how it handles real-time sensor inputs and motor control. The L298N should manage the Roomba motors' voltage needs just fine (in theory, at least).

The Underpowered Sensor Challenge

The HC-SR04 ultrasonic sensor is laughably weak for proper SLAM. It’s low-resolution, has a narrow field of view, and struggles with certain surfaces. But that’s exactly why I’m using it—I want to figure out how to make the most of bad data.

If I can extract meaningful spatial information from this absolute potato of a sensor, then adding better sensors later (IR, TOF, LiDAR) will only make the system stronger.

What’s Next?

With the basic hardware in place, the next steps will be:

1. Getting Minone moving – Setting up basic motor control with the ESP-32S and L298N.
2. Reading sensor data – Making sure the HC-SR04 is providing usable distance measurements.
3. Starting simple SLAM tests – Even basic dead reckoning will be a good first step.

As I build and test, I’ll be refining Minone’s design—possibly rethinking that caster wheel before it faceplants one too many times.

Stay tuned for the next update! 🚀

PolyMap: Introduction

PolyMap:
PolyMap is an experimental platform designed to explore Robotic Swarm–based Simultaneous Localization and Mapping (SLAM) strategies across both simulated and real-world environments. By combining lightweight simulation, MQTT-based communications, and emerging visualization techniques, PolyMap aims to offer an accessible yet robust toolkit in multi-robot collaboration and global mapping challenges.

Recent Progress: Building a Simple SLAM Simulator
I am pleased to share the latest milestones in developing a simple SLAM simulator under PolyMap. Over the past few weeks, I have laid the foundation for simulating robot behavior, visualizing real-time maps, and merging local maps into a unified global view. This work is an important step toward creating a versatile environment where multiple robots can collaboratively build and refine shared maps.

An early achievement in this release has been leveraging MQTT for robot-to-visualization communication. Each simulated robot transmits map updates through MQTT, which our visualization layer consolidates into a cohesive global map. I have also made headway on a basic search feature, an early step toward more sophisticated swarm coordination. Concurrently, I have improved the simulation architecture to ensure that incoming data and visualization processes run smoothly without blocking each other.

On the infrastructure side, I have established a basic development structure—not full CI/CD yet, but enough to keep things organized and maintain momentum. I have also incorporated early concurrency and event-handling mechanisms so that data flow and visual updates can occur in parallel. While there’s still much, much more to do, these accomplishments underline PolyMap’s potential to evolve into a compelling cooperative robotics exploration platform.

Next Steps and Future Directions
Looking ahead, I plan to explore using gaming engines to enhance our visualization capabilities, offering a more immersive and high-performance environment for simulating robot movements and interactions. Additionally, as the simulated framework matures, we’re setting our sights on integrating physical robots into the pipeline—bridging the gap between virtual testing and real-world application. By supporting both simulated and physical robot platforms, we hope to make PolyMap a flexible tool for multi-robot SLAM challenges. Stay tuned for more updates as the platform continues to evolve!

Here is a much more realistic screen capture of the actual 'early' simple simulation. ;)

Simple SLAM simulation