PolyMap & Minone: First Test Results (#4)

Simple SLAM Robot: Initial Tests with PolyMap and Minone

Both the PolyMap mapping platform and the Minone robot have reached a level of functionality sufficient for their initial tests together. The early results are exciting, though clearly revealing room for improvement—exactly as anticipated!

Here's a video capturing these very first tests. Having this visual documentation will greatly help us track the robot's progression as we refine and improve the SLAM capabilities.

Overview of the First SLAM Tests

These initial tests show how well the mapping system, PolyMap, works together with Minone, a very minimal robot platform that is built around an ESP32 microcontroller. Minone, equipped with only a single ultrasonic sensor, navigated a confined hallway environment. All communication between the robot and the mapping software was successfully managed via MQTT, demonstrating effective real-time integration.

Minone, alone in the hallway.

In this test setup, Minone was in a hallway out of my vision. My phone was recording its movement. I sat in an adjacent room behind the door and was instructing the robot through the visualization. Commands were sent using MQTT to the robot and telemetry and map data was returned as previously discussed. In this test, I did have the reassurance that it was working, as I could hear the motor movement down the hallway.

Mapping Process and Key Observations

The PolyMap visualization provided live feedback during the tests with telemetry and maps. On the map you can see:

• Robot position was clearly indicated in orange.

• Obstacles detected by the ultrasonic sensor appeared in red.

• Unexplored areas remained marked in black.

• Telemetry shows the Pose (X, Y, Θ) and state: Manual

PolyMap Viz April 2025 (Totally Not Evil Robot Army)

The visualization effectively demonstrated the system's ability to build a cohesive map from successive sensor readings. However, the tests quickly highlighted significant limitations associated with relying on a single ultrasonic sensor:

• False negatives: The sensor occasionally failed to detect obstacles, particularly when encountering oblique angles. The pulsed ultrasonic signal reflects off the surface and does not return to the sensor, the device times out waiting, and returns a long distance (in this case greater than 170cm)

• False positives: There were numerous instances of the sensor incorrectly registering obstacles due to noise and sensor inaccuracies. This could be due to echos, but otherwise indeterminate (for me at this time).

Minone, False Neg due to Reflection in corner.

These limitations underscore a common challenge when using ultrasonic distance sensors. In simple SLAM test, there were no special filter applied or sensor data management used. This is a clear direction for improvement in the next code iteration.

Initial Conclusions and Immediate Next Steps

The primary next step is addressing the significant number of false positive and negative readings produced by the ultrasonic sensor. To tackle this challenge, the mapping algorithm will transition from a basic binary representation (occupied/free) to a probabilistic occupancy grid, employing the log-odds methodology. This approach should significantly reduce the influence of sensor inaccuracies by statistically weighting sensor readings over time.

Looking Ahead: Introducing Mintwo and Exploring Swarms

Future development plans include building an upgraded version of Minone: the Mintwo robot (?!?). This iteration will be enhanced by incorporating multiple IR time-of-flight sensors, dramatically enriching the data quality and robustness. The improved sensory capability of Mintwo will not only enhance individual robot performance but also lay the foundational work for exploring coordinated behaviors and swarm robotics, leveraging PolyMap’s scalable and distributed architecture.

Stay tuned as we continue to iterate and enhance both the PolyMap platform and our expanding army, ehr.. family of robots!

Minone – Getting the MV#Robot to Stable (#3)

Minone – Getting the MV#Robot to Stable (#3)

It's been a busy stretch since the last update! Many improvements, refactoring, debugging, and learning sessions have pushed the Minone MV#Robot toward a more stable and robust platform.

Code: Structure and States

Most of the recent effort has been dedicated to fleshing out software needed for remote operation. The robot's codebase has significantly expanded, particularly around the command structure. I've implemented a state model to handle essential high-level states:

• Standby: Robot awaits commands—especially useful after a reboot, allowing manual verification before resuming tasks.

• Manual: Direct control, crucial for immediate testing and remote operations.

• Autonomous: Fully independent operation. Future enhancements will include advanced exploration strategies, frontier search, and swarm coordination.

• Pause: Temporary halt; currently, the robot resumes directly into Autonomous mode.

• Error: Safety state activated by unexpected issues.

High-level state changes are now managed via an MQTT subscriber, enabling remote state-level commands. In Manual mode, the MQTT listener also accepts individual task commands for immediate execution.

To efficiently handle robot actions ("tasks"), I developed wrapper code that allows manual triggering for debugging flexibility. Additionally, during Autonomous mode, the Robot's Agent autonomously generates tasks, utilizing the same task infrastructure.

Precise Movement Challenges

One aspect differentiating a true robot from a toy or simple remote-controlled device is the ability to move precisely. For mapping and SLAM purposes, it is crucial to know exactly where the robot is and its pose. To understand how much a motor has turned, an encoder is used to 'count' the amount of rotation. Minone uses encoders that are built into recycled Roomba wheel modules I am using. Knowing the number of pulses per rotation and wheel dimensions allows precise odometry calculations—determining how far the robot moves or rotates.

Initially, Minone exhibited incorrect odometry during turns. Calculations seemed accurate—asking to move 10cm resulted in software reports of 10cm—but the physical movement was actually 20cm. This discrepancy first appeared in rotation measurements, which were exactly half the physical result. At first, I assumed calculation errors were related to the complexity of the turn calcuation. The wheels are rotating in opposite directions and you must factor in wheelbase dimensions. A quick patch improved turn precision slightly, but the underlying movement issues remained.

Digging deeper revealed encoder pulse counts were half the expected values. Although the very specific 508.5 pulses per rotation was correct, I initially misunderstood that this value included both rising and falling edges of the encoder's square-wave pulse. A small adjustment resolved this completely:

// --- Encoder Setup ---
void setupEncoders() {
  pinMode(LEFT_ENCODER_PIN, INPUT_PULLUP);
  pinMode(RIGHT_ENCODER_PIN, INPUT_PULLUP);
  attachInterrupt(digitalPinToInterrupt(LEFT_ENCODER_PIN), leftEncoderISR, CHANGE);
  attachInterrupt(digitalPinToInterrupt(RIGHT_ENCODER_PIN), rightEncoderISR, CHANGE);
}

Switching the interrupt trigger from 'RISE' to 'CHANGE' allowed counting both edges. Problem solved! Recognizing this resolved earlier incorrect adjustments, making robot turns and movements significantly more accurate—not perfect yet, but sufficient for this prototype stage.

A cautionary note on AI-assisted coding: Unfortunately, my AI coding companion missed this nuance, underscoring the continued need to have some knowledge of what you are working with, both in code and hardware. The AI repeatedly suggested using 'RISE,' which cost significant debugging time. Only through examining code from other experienced developers—a big shout out to Bill at DroneBot Workshop—did I discover the proper approach.

Coordinate Systems & Rotational Model

Choosing a coordinate system for your robot is critical, impacting navigation, mapping, and visualization. Coordinate systems aren't always the simple math we learned in high school (traditional X/Y axes). You must consider the Z-axis for rotation and eventually 3D mapping, plus how your robot’s "frame of reference" relates to mapping standards reference. Surprisingly, industry standards differ significantly from basic Cartesian assumptions.

I selected a right-handed system (X-forward, Y-left, Z-up) for the robot frame, aligning with robotics conventions used in platforms like ROS. Positive yaw indicates counterclockwise (left) rotation, while negative yaw indicates clockwise (right) rotation. Though initially counter-intuitive, maintaining consistency across code and system interfaces is very important.

Downstream, the Map Manager and visualization components must translate these standards, especially when interfacing with game engines like Godot, which often uses a different convention.

Minone 11 APR 2025 - MV#Robot

Hardware Improvements

The prototype hardware has also been improved in this iteration. Adding a level shifter stabilized communication between components with different voltage domains. To safely power the ESP32 independently, I now directly use a clean 5V source from a power bank rather than the L298N's regulator.

Currently, the robot remains on a breadboard— a big messy rats nest of jumper wires. Future builds will transition to a safer proto-board with robust connectors for stability and better cable management, reducing risk of havoc from loose connections.

Demos: Seeing the Progress!

Here are short videos captured during the build process. The first demonstrates basic movement and scanning routines without intelligent decision-making:

The second video shows progress after foundational movements were implemented but before odometry corrections—movements rely on timing rather than accurate angle calculations. Since filming, accuracy has significantly improved!

Thanks for following along! The Minone MV#Robot journey continues—iterate, iterate, iterate!

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

SWARM - A conversation with ChatGPT

The following is a conversation with OpenAI's ChatGPT about Swarm robotic systems.  I will be updating the transcript with links as well as verifying ChatGPTs response.

Prompt:

Act as an expert in robotics on the topic of swarm robotics, and an expert blog writer. The audience for this blog is technical professionals who are interested in learning about the latest advancements in swarm robotics. Provide a comprehensive overview of the most popular swarm management processes and software packages, including their strengths and weaknesses. Include real-life examples and case studies to illustrate how these processes have been successfully used in various industries.

[NOTE:  OpenAI's ChatGPT3 is trained on data up to Sept 2021. At the time of this conversation it was almost 18months out of date.]

Introduction to Swarm Robotics

Swarm robotics is a rapidly growing field that involves the coordination of multiple robots to achieve a common goal. The approach is inspired by the collective behavior of social animals such as ants, bees, and termites. Swarm robotics offers several advantages over traditional robotics, including increased flexibility, adaptability, and fault tolerance.

Swarm robotics has found applications in various fields, including agriculture, construction, search and rescue, and surveillance. In this blog, we will discuss the most popular swarm management processes and software packages used in swarm robotics and their strengths and weaknesses.

Particle Swarm Optimization (PSO)

Particle swarm optimization is a popular algorithm used in swarm robotics for optimization problems. The algorithm is based on the behavior of bird flocks and fish schools. PSO is used to optimize a function by iteratively adjusting a population of particles or agents. The algorithm's strength lies in its ability to converge to the optimal solution quickly, but it may get stuck in local optima.

PSO has been applied in various industries, such as in the energy industry, to optimize the placement and sizing of renewable energy systems. A real-life example of PSO in action is the optimization of wind turbines in offshore wind farms.

Ant Colony Optimization (ACO)

Ant colony optimization is another popular algorithm used in swarm robotics. The algorithm is based on the foraging behavior of ants. ACO is used to solve combinatorial optimization problems. The algorithm's strength lies in its ability to find the optimal solution by exploring the search space thoroughly. However, ACO may take longer to converge to the optimal solution.

ACO has been applied in various industries, such as in the logistics industry, to optimize transportation routes. A real-life example of ACO in action is the optimization of delivery routes for a package delivery company.

Artificial Bee Colony (ABC)

Artificial bee colony is a metaheuristic algorithm inspired by the behavior of honeybees. ABC is used to solve optimization problems by iteratively adjusting a population of candidate solutions. The algorithm's strength lies in its simplicity and ability to explore the search space effectively. However, ABC may converge slowly to the optimal solution.

ABC has been applied in various industries, such as in the manufacturing industry, to optimize the production process. A real-life example of ABC in action is the optimization of a manufacturing process to minimize the production cost.

Robotic Operating System (ROS)

The Robotic Operating System (ROS) is a popular software package used in swarm robotics. ROS provides a set of tools and libraries for developing and managing robotic systems. The system's strength lies in its modularity, flexibility, and compatibility with a wide range of sensors and hardware. However, ROS may have a steep learning curve for new users.

ROS has been applied in various industries, such as in the healthcare industry, to develop robotic systems for assisting with surgical procedures. A real-life example of ROS in action is the development of the da Vinci surgical system, which is used in minimally invasive surgeries.

Multi-Agent Platform (MAP)

The Multi-Agent Platform (MAP) is a software package designed for developing and managing multi-agent systems. MAP provides a set of tools and libraries for developing and managing swarm robotics systems. The platform's strength lies in its ability to manage large-scale multi-agent systems and its support for fault tolerance. However, MAP may have limited compatibility with certain sensors and hardware.

MAP has been applied in various industries, such as in the defense industry, to develop swarm robotics systems for surveillance and reconnaissance missions. A real-life example of MAP in action is the development of a swarm of autonomous drones for border surveillance.

Conclusion

Swarm robotics is a rapidly growing field that offers several advantages over traditional robotics. In this blog, we discussed the most popular swarm management processes

About ROS?

Me: what packages are used for Swarm management in ROS?

ROS (Robot Operating System) is a widely used software framework for developing robotic systems, including swarm robotics systems. There are several ROS packages that are specifically designed for swarm management in ROS.

Here are some popular ROS packages for swarm management:

swarm_behaviors: This package provides high-level swarm behaviors for robots in a swarm, such as maintaining a formation, exploring a space, and coordinating tasks. The package is designed to be used with other ROS packages to build more complex swarm behaviors.

swarm_msgs: This package provides message types for swarm robotics systems, such as swarm commands, swarm state information, and swarm sensor data. These message types enable communication and coordination between robots in a swarm.

swarm_simulator: This package provides a simulator for swarm robotics systems in ROS. The simulator allows users to test and validate swarm behaviors and algorithms in a simulated environment before deploying them on real robots.

swarm_navigation: This package provides navigation algorithms for robots in a swarm, such as swarm path planning and obstacle avoidance. The package is designed to work with other ROS packages to provide more complex swarm navigation behaviors.

swarm_control: This package provides low-level control algorithms for robots in a swarm, such as formation control and synchronization. The package is designed to be used with other ROS packages to build more complex swarm control behaviors.

These packages are just a few examples of the many ROS packages available for swarm management. Depending on the specific application, different combinations of packages may be used to build a complete swarm robotics system in ROS.

Communications for Swarms:

ME:  what technology and methods are used for swarm communications in areas of 100s of meters? what protocols of communication are used?

Swarm communications in areas of 100s of meters require a robust and reliable communication system that can support a large number of robots in a swarm. There are several technologies and methods that can be used for swarm communications, including wireless mesh networks, ad-hoc networks, and satellite communications.

Wireless mesh networks are a popular technology for swarm communications. In this approach, each robot in the swarm acts as a node in a wireless network, and communication is facilitated through peer-to-peer links between nodes. Mesh networks are highly scalable and can support a large number of nodes, making them ideal for swarm robotics applications.

Ad-hoc networks are another technology that can be used for swarm communications. In this approach, robots in the swarm establish direct communication links with nearby robots to create a decentralized communication network. Ad-hoc networks are highly flexible and can adapt to changes in the swarm's structure, making them ideal for dynamic swarm robotics applications.

Satellite communications are a technology that can be used for swarm communications in remote areas where other communication technologies are not available. In this approach, robots in the swarm communicate with a satellite to transmit data and commands to other robots in the swarm. Satellite communications are highly reliable but may have high latency due to the long distance between the swarm and the satellite.

In terms of communication protocols, several protocols are used in swarm robotics, including Bluetooth, Zigbee, and IEEE 802.11. Bluetooth is a short-range wireless protocol that can be used for communication between nearby robots in a swarm. Zigbee is a low-power wireless protocol that can be used for communication between robots in a swarm over longer distances. IEEE 802.11 is a high-speed wireless protocol that can be used for communication between robots in a swarm over long distances.

In summary, the choice of communication technology and protocols for swarm robotics applications depends on several factors, including the size and structure of the swarm, the range of communication required, and the environmental conditions in which the swarm operates.

Swarm with Mesh networks

ME: what swarm robot management systems support mesh networks?

There are several swarm robot management systems that support mesh networks for communication between swarm robots. Here are a few examples:

Kilobot: Kilobot is a low-cost robot designed for swarm robotics research. The Kilobot system includes a custom wireless mesh network protocol that allows the robots to communicate with each other and coordinate their behaviors.

DroNet: DroNet is a swarm robotics platform designed for monitoring and surveillance applications. The system includes a wireless mesh network protocol that enables communication between the robots in the swarm.

Buzz: Buzz is a programming language and runtime system for swarm robotics applications. The Buzz system includes a wireless mesh network protocol that allows the robots to communicate with each other and share information.

Aseba: Aseba is a programming language and runtime system for swarm robotics applications. The Aseba system includes a wireless mesh network protocol that allows the robots to communicate with each other and coordinate their behaviors.

MORSE: MORSE is a simulation platform for swarm robotics research. The MORSE system includes a wireless mesh network protocol that simulates the communication between the robots in the swarm.

These are just a few examples of swarm robot management systems that support mesh networks for communication between swarm robots. Depending on the specific application, different swarm robot management systems may be more appropriate.

Swarm in Industry:

ME: what industries has swarm robotics been applied to?

Swarm robotics has been applied to a wide range of industries, from manufacturing and logistics to agriculture and environmental monitoring. Here are some examples of industries where swarm robotics has been successfully applied:

Manufacturing: In manufacturing, swarm robotics has been used to optimize production processes and improve product quality. For example, swarm robots can work together to assemble complex products, such as electronic devices or automobiles, with high precision and efficiency.

Logistics: In logistics, swarm robotics has been used to automate warehouse operations and improve supply chain management. For example, swarm robots can work together to pick and pack items in a warehouse, reducing the need for human labor and improving efficiency.

Agriculture: In agriculture, swarm robotics has been used to monitor and manage crops, as well as perform tasks such as planting and harvesting. For example, swarm robots can work together to map and monitor fields, identify areas where crops are struggling, and apply targeted treatments to improve crop health.

Environmental monitoring: In environmental monitoring, swarm robotics has been used to collect data and monitor sensitive environments, such as forests, oceans, and wetlands. For example, swarm robots can work together to collect water or soil samples, monitor air quality, and track wildlife populations.

Search and rescue: In search and rescue operations, swarm robotics has been used to locate and rescue people in emergency situations. For example, swarm robots can work together to search for survivors in the rubble of a collapsed building or to locate people stranded in a remote wilderness area.

These are just a few examples of the many industries where swarm robotics has been applied. As swarm robotics technology continues to advance, we can expect to see even more applications in the future.

Swarm and SLAM

ME: what systems combine swarm robotics management with larger mapping (SLAM)?

Simultaneous Localization and Mapping (SLAM) is an important technology for mobile robotics that allows robots to build a map of their environment while simultaneously localizing themselves within that map. Combining SLAM with swarm robotics can be particularly useful in applications where a large number of robots need to navigate and map an environment. Here are some examples of swarm robotics systems that combine SLAM with swarm management:

ARGoS: ARGoS is a multi-robot simulation framework that supports swarm robotics research. The ARGoS system includes a SLAM module that allows the robots to build a map of their environment and localize themselves within that map. The system also includes a swarm management module that allows the robots to communicate and coordinate their behaviors.

Robot Operating System (ROS): ROS is a popular platform for mobile robotics research that includes many modules and tools for building complex robotic systems. ROS includes several SLAM packages, such as GMapping and Hector SLAM, that can be used in conjunction with swarm robotics management packages, such as Swarm Robotics Tool Kit (SRTK), to build large-scale robotic systems.

Robotic Operating System for Everyone (ROS2): ROS2 is a newer version of ROS that includes many improvements and updates. ROS2 also includes several SLAM packages, such as Navigation2 and Cartographer, that can be used in conjunction with swarm robotics management packages, such as Swarm Intelligence in Cellular Systems (SWARMS), to build complex robotic systems.

Distributed Autonomous Robotic Systems (DARS): DARS is a research program that aims to develop decentralized, self-organizing robotic systems. The DARS program includes several projects that combine SLAM with swarm robotics management to create large-scale robotic systems that can operate autonomously.

These are just a few examples of swarm robotics systems that combine SLAM with swarm management. There are many other systems and research projects that are exploring this area, and as the technology continues to advance, we can expect to see even more sophisticated swarm robotics systems that can operate in complex and dynamic environments.

SWARM software that is commercially available

ME: what commercially available software systems provide swam management?

There are several commercially available software systems that provide swarm management capabilities. Here are some examples:

Robot Operating System (ROS): ROS is a popular open-source platform for building robotic systems. ROS includes several packages for swarm robotics, such as the Swarm Robotics Tool Kit (SRTK) and the ARGoS simulator. ROS can be used for a wide range of robotic applications, including swarm robotics, and is supported by a large community of developers.

Blue River Technology: Blue River Technology is a company that develops precision agriculture technologies, including a swarm management system called See & Spray. See & Spray uses computer vision and machine learning to identify and target weeds in agricultural fields, and uses a swarm of robots to apply targeted herbicide to the weeds. The system is designed to reduce the amount of herbicide used in agriculture and improve crop yields.

Aerialtronics: Aerialtronics is a company that develops drone technologies for a wide range of applications, including inspection, surveillance, and security. Aerialtronics' Altura Zenith drone system includes a swarm management module that allows multiple drones to be controlled and coordinated by a single operator. The system can be used for applications such as search and rescue, disaster response, and infrastructure inspection.

Auterion: Auterion is a company that develops open-source software for drone and robotics applications. Auterion's Dronecode platform includes a swarm management module that allows multiple drones to be controlled and coordinated. The platform is designed to be flexible and customizable, and can be used for a wide range of applications, including agriculture, inspection, and search and rescue.

These are just a few examples of commercially available software systems that provide swarm management capabilities. There are many other companies and platforms that are developing swarm robotics technologies, and as the field continues to evolve, we can expect to see even more advanced and sophisticated systems become available.

Swarm systems in unstructured environments

Me: which swarm systems operate best in unstructured and non-static environments?

Swarm systems that operate best in unstructured and non-static environments are those that are designed to be adaptive and resilient. Here are some examples of swarm systems that are well-suited for such environments:

Kilobot: Kilobot is a low-cost swarm robot developed by researchers at Harvard University. The Kilobots are designed to operate in large groups and are capable of self-organizing and adapting to changes in their environment. The robots use a simple communication protocol to coordinate their behaviors, and can perform a variety of tasks, such as pattern formation and aggregation.

[Note: Kilobot is not suitable for unstructured environments. (-1 Chat GPT!)]

SWARMS: SWARMS (Swarm Intelligence in Cellular Systems) is a software platform developed by researchers at the University of Sheffield that allows robots to self-organize and adapt to changing environments. The platform includes a swarm management module that allows the robots to communicate and coordinate their behaviors. The SWARMS platform has been used in a variety of applications, such as environmental monitoring and search and rescue.

RoboBees: RoboBees are a type of micro-robot developed by researchers at Harvard University that are designed to mimic the behavior of bees. The robots are capable of flying and can be used for a variety of applications, such as environmental monitoring and crop pollination. The RoboBees are designed to operate in large swarms and can adapt to changes in their environment.

AMR Swarm: The AMR Swarm is a swarm robotics platform developed by researchers at the University of Lincoln that is designed for use in industrial environments. The platform includes a swarm management module that allows the robots to communicate and coordinate their behaviors, and is designed to be adaptable to changes in the environment. The AMR Swarm has been used in a variety of applications, such as warehouse logistics and manufacturing.

These are just a few examples of swarm systems that are well-suited for unstructured and non-static environments. In general, swarm systems that are designed to be adaptive, resilient, and capable of self-organization are likely to perform well in such environments. Additionally, systems that use sensors and machine learning algorithms to perceive and interpret their environment can further enhance their adaptability and resilience.