I do not have bots or drones but I’d like to program for groups.
I’ve done a little bit of C++. 6 years of JavaScript though.
If anyone has 30+ same-type bots I’d be interesting in doing some programming exercises.
Getting run-time on 30+ of the same robot could be tough. As a general recommendation, I’d suggest writing a simulator on your computer, treating the robots as points in the plane. This would allow you to develop and debug your code before tying up a bunch of physical robots.
I just got this sent to me from my You Tube subscription this morning… Very timely! You can see some good ideas for swarms of quad copters as well as swarms of land based robots.
I am not sure if having one be the leader for all of the rest to follow is the most practical thing in the real world. If the leader gets in trouble away from the plan, the rest will all follow him over the cliff. (But staying the proper distance away until they crash!)
You’d have to have some sensors in the leader to say you’re still good to be the leader and have #2 take over if no communication form #1 is failed.
I am also unsure of the communication protocols to use from robot to robot. Broadcast messages for all to receive are probably best. But each member should be on a different frequency I’d think.
When we toured the UPenn GRASP lab last year, their quad copters all went back to a central server for figuring out what to do. So maybe the central (Borg/Cylon) server will see who should be the grounded leader for all else to emulate from.
So many things to think about!
Personally, I prefer distributed-intelligence setups - look up “emergence” or a flocking system simulation and you will see what I mean. Even a simple, low-level AI, when distributed across a large group can have significant effects. I would suggest avoiding a central hub if at all possible, or at least having some resiliency in the system so that, regardless of how many individual units fail, the swarm itself maintains its integrity. As you said, you don’t want to have your swarm crash and burn like a bunch of lemmings if the one designated “leader” unit decides to take a trip down a flight of stairs or smashes into a wall.
An idea that might work to the best of both worlds - have a control system that does not actually physically exist. Have your individual swarmbots feeding strategic and positioning data into a network. That network then will know the locations of all the units in the swarm, as well as strategically relevant information for delegating tasks to each individual member. Each individual unit should have the ability to sustain the whole network (though relaying info between bots to increase communication range is acceptable) so that the actual “leader” status can be transferred from bot to bot based on the risk of each robot being taken out. So, regardless of what the swarm is doing, the central computing hub can be moved somewhere sheltered without actually having to physically move. Code weighs nothing and can be activated, deactivated, or moved very quickly, so having the leader status being merely code allows for a lot more flexibility. Parallel computing would be an even better solution, but I don’t know how to pull that off, unfortunately.