This is part of TigerBug, a robot design I am working on for use at RIT for swarm research and as a fundraising/education tool . Take a look at the project hub for more progress on different components of this project.
I (and quite a few other people in the robotics field ) am amazed by Honeybee colonies. Honeybees can live( and in many climates, are only able to survive) together in colonies that grow to the 10s of thousands, and through a complex process manufacture food to feed both themselves and the pesky humans who keep taking from it. The average foraging honey bee may only live for 6 weeks, and while it may be very clever at orienting itself and perceiving color , it isn’t capable of recording information for future bees to follow, or managing the many steps in the process of taking nectar from flowering plants and producing honey, wax, and the various products that comprise a bee hive. This process is maintained by a large population constantly refreshing and passing the information to the next-of-kin, one bee at a time.
Though I’m no expert on the subject, I could talk about this for a while. I’ve been trying to help out RIT’s beekeeping club when I have time, and these amazing creatures were on my mind as I was thinking about potential applications for Tigerbug. This seemed like a reasonable simulation to undergo, and might be a unique project for the class. Alright then, Bee hive simulation. How am I going to do this?

Bee colonies are complex and chaotic, with many mechanical and chemical processes happening at the same time. Simulating something this complex would be impossible for the time/budget I had available for the project. So to start, I first laid out some assumptions I would make about the bees and their work-space (these are from my original notes):
- Bee bots travel in 2 dimensions, on a flat, enclosed plane.
- Bee bots can travel in straight lines of X length, and turn 𝚹 degrees.
- Bee bots start their simulation in the “hive”, a 2D circle on the plane.
- Bee bots can perform (outputs):
- Linear or rotation movement using two Geared DC motors
- Communication using Infra-red LEDs operating at atl. 1 frequency
- Bee bots can sense (inputs):
- how long it takes to travel X , and rotate 𝚹. They don’t have outright position feedback (meaning they don’t know which way they are moving, just by how much)
- Which way is north, using an internal compass
- whether or not they are impacting an object on any of their four corners (or, four quarter-circles if they are round).
- If they have found “nectar”
- Light in at least 1 color/frequency (past me: can we get low-cost sensors that do multiple colors? future me: yes we can)
- Bee bots are always powered, and don’t have to actually re-charge themselves.
- The Nectar is located in at least 1 fixed position, and is replenished when a bee takes from it, at least for a few times.
- Nectar is returned to the hive, where it is stored in a “honeycomb” – some sort of thing that they can dump it into.
Typically swarm robots are unintelligent, and are “commanded” by an omniscient source, such as an overhead camera and PC, communicating directions wirelessly to each robot. This allows the robots to perform very advanced tasks (such as these cool “zooids” from the Shape Lab at Stanford University).

I don’t have the expertise to make this sort of system unfortunately (that, and I also want these robots to be useful in other situations, such as teaching about robotics and programming using a single robot). which means that each bee robot will contain all the knowledge it needs to perform its part of the simulation from the start.
A Scout Bee will be designated as the first bee to make a move, travelling from the hive to search for a flower, detected as a change in color of the floor. it records the distance traveled to each obstacle it detects, and records how far it has to turn in order to keep going. these values can be used to generate a series of vectors corresponding to its motion around the x-y plane used in the simulation. once it finds a flower, these vectors are summed to produce a single path vector, defining a path from the hive to the resource. the bee then returns, modifying the path vector (s?) as necessary to avoid any obstacles it encounters. This part of the simulation is a bit abstract right now, but I would imagine the bee would attempt to deviate slightly from the path, and repeat if that does not work until it clears the obstacle. I’m sure there are smarter ways to do this.
source: brittanica.com
Worker Bees, meanwhile, are waiting in the Hive. When the scout returns to the hive, it drives around until it impacts one of the workers. The bee detects the bump from the scout, and turns to face it with an Infra-red transmitter-receiver. The scout then performs an electronic version of the “bee dance” (see above), describing to the worker the magnitude and direction of the path vector(s). these workers acknowledge they know where to go, and attempt to follow the path.
The process after the first communication will probably start to become chaotic. Workers may collide with themselves or other obstacles, and will attempt to correct the path vectors in order to reach the same point. This will likely not work perfectly in real life, but that is the point of swarm robotics! Once you get enough players trying to do the same thing, one is bound to accomplish it. if that one successful worker communicates back to the other workers, then the path is improved and more can reach the resource. The simulation may include multiple resources, and depleting resources that go dry after a certain number of worker bees have reached it, requiring the process to start over again.
much of this needs to be tested, and to do so I will be attempting to learn V-rep, a multi-agent robot simulation software. I hope that I can create a model of the robot we intend to build, and start perfecting the algorithms that will allow the colony to operate as intended.
However, enough of this theoretical stuff, it’s never been my strongest suit. lets make some actual robots!