Hi all,
I recently took a college class in robotics. I apologize for the poorly organized code and the following messy synopsis. The project was done over a period of 4-5 weeks and still needs to be polished. However, I hope to share my results at this point. (Please forgive a recently graduated student’s ignorance as well!)
Goal
I was particularly inspired by this paper: From Fireflies to Fault-Tolerant Swarms of Robots | IEEE Journals & Magazine | IEEE Xplore.
So, I worked on the firefly synchronization mechanism stated in the paper. In particular, I used a makeshift turtlebot model for each swarm member. Each robot has its own ROS node to build up “activation” over time. And once the activation crosses a threshold, it flashes. Each robot is equipped with 2 180-degree cameras. Whenever a robot detects a nearby flash, its activation is increased by a fixed amount (thereby making the robot flash faster.
The swarm is able to synchronize:
Challenges
-
Although, as you can see in the video, the swarm often falls out of sync. I identified that there is a significant network latency coming from the ROS middleware, and it is likely the main culprit. The second, but less pronounced, issue is clock drifts. In the video, you can see that while robots would change to green at the same time, they do not change back to blue at the same time.
-
I used a multithreaded executor to reduce much of the overhead. However, I could not replicate the paper’s results fully! The paper uses a coupling constant (effect of each flash upon nearby robots) at 0.10-0.30. My swarm was only able to synchronize with a coupling constant of 0.5-0.75. The conjecture was that the high coupling constant would mask the latency. In particular, as soon as the swarm falls out of sync, it will immediately get back in sync. The chosen coupling constant depends on the swarm size as well as the environment of the swarm. This adjustment is not consistent with the IEEE paper. However, it is effective at overcoming the limits of the simulation.
-
I used Gazebo Garden for the simulation. It seems like the Material states of models do not get propagated to the Gazebo Rendering Engine. Hence, I could not simply change the states of the model in a Gazebo System Plugin. Instead, I had to create a Rendering Plugin (running on Gazebo Server) to manually override the Material before each rendering cycle.
-
The implementation does not scale with swarm size! As highlighted above, there is a significant cost to each additional ROS node. I observed that a swarm of 30 would have a delay of up to 2s.
All 4 points above pertain only to simulations. There is no central network orchestration in a decentralized swarm (as far as a brief survey of the current literature on swarm robotics is concerned). Hence, the results in the paper should be easily replicated in a real robotic swarm. However, it does not seem like swarm robotics can utilize the ROS middleware in the same capacity as a single robot with only nodes for sensing and actuating. The network overheads for loopback routing are too significant to ignore as the number of nodes increases.
Tools used
ROS2 - Humble
Gazebo Garden
ros_gz_bridge package
OpenCV 4
GitHub repo for the implementation: [ROS2 & GZ] Synchronization, at last! - YouTube