Swarm Robotics

@thrandell 

Notice the sim bots do not detect other bots (except on contact) they only react to the IR light intensity which comes from all the other bots to control their behavior. I set their behavior to move toward the most intense light and stop if got to some maximum level. The result is they all ended up at an equal distance from each other and stopped.

When I was working on my Hide and Seek robots I had the idea of using an omni-directional IED but I could never source one. Have you ever seen them for sale?

Maybe a ring of ir leds? Isn't a LED light normally omini directional? Using IR proximity detection involves shielding or focusing that light into one directon.

Have you given much thought to what swarm behavior you want to emerge?

Communication:

I thought maybe the bots need to take turns in talking.

Bot1 goes first sending out its ID and data. Only bot2 is allowed to respond although all other bots can listen. Then it is bot2 that sends out its ID and data but only bot3 is allowed to respond. Then bot3 sends out its ID and data and only bot1 can respond.

When bot1 sends and bot2 does not respond for some reason bot1 can try bot3. If bot3 does not respond it can try bot4 or in your three bot example just try bot2 again.

The idea is the bots have to take turns and not talk over each other and have some protocol for doing this. This would be fast as you could ever get and not have to untangle clashing messages.

Object detection would have to use some other means than the IR from a transmitter. Maybe the communication can use a different pulse rate.

Posted by: @robotbuilder

↑

Notice the sim bots do not detect other bots (except on contact)

Yeah, I figured as much.  I've read about other swarm robots that use that approach.

Posted by: @robotbuilder

↑

The idea is the bots have to take turns and not talk over each other and have some protocol for doing this. This would be fast as you could ever get and not have to untangle clashing messages.

I’m working on some ideas to help with the coordination of when to send and when to receive data.

Also there might be something to be gained from the directionality of received messages.  If a robot receives a message on sensor x, then it can response on sensors x-1, x and x+1 and contain the message traffic to a specific direction.  This might minimize ‘clashing messages’.  Currently, I’m using short 10 bit messages for obstacle detection and as a kind of “message in a bottle”.  For example, if the front sensors emit and receive their robot ID then there is an obstacle in the way.  While when the other sensors emit their robot ID it’s more of a broadcast of its location to the robot neighborhood.  Once received a nearby robot confirms the message by emitting range and bearing in the direction of the received message.  I  can emit the 10 bit message on all eight sensors and read the results in about 0.04 seconds.  All that sounds great, but I need a second robot to try all this stuff out and see if it’s going to work fast enough.

Posted by: @robotbuilder

↑

Object detection would have to use some other means than the IR from a transmitter.

So, I think I have a handle on obstacle detection using IR sensors.  I’ve had good results with multiple robots finding obstacles and not interfering with each other by having each robot emit its unique robot ID.  If it’s received then an obstacle is near by and if not then it’s clear sailing. The format of the message is a 2 bit header ’11’, a 3 bit robot ID, a 3 bit sensor ID and a two bit trailer ’11’  For example, 11 001 100 11 would represent robot 1 sending a message via its sensor #4.  So its small, quick and has no CRC. 

Here is an example of two robots exchanging 10 bit messages, i.e. not transmitting on top of each other.

Robot A (id=1) is the active robot and after the exchange would know that robot B (id=2) has an orientation of 180 degrees and has a bearing of 45 degrees.  All that’s left is the range which robot A can get by varying the duty cycle on sensor #1 until it gets a reflection.

Anyway, that’s my current approach.  I need to work out the longer messages and when to send them.  Also things like data structures, a FIFO queue, how to age and when to delete neighboring robot information, how to format the data for the i2c master to read, …

Tom

@thrandell 

Robot A (id=1) is the active robot and after the exchange would know that robot B (id=2) has an orientation of 180 degrees and has a bearing of 45 degrees. All that’s left is the range which robot A can get by varying the duty cycle on sensor #1 until it gets a reflection.

I assume that is an approximate direction. If two adjacent sensors receive the same message than I guess you could assume the direction of the sender was in between the sensors thus giving you up to 16 directions?

I don't remember how you compute the distance by varying the "duty cycle"? How precise is that?

Given this information what does the robot actually do with it?

In other words what swarm behaviors are you hoping to implement?

The swarm behaviors of cells can be complex but they don't have IDs or distance measurements instead their behaviors are controlled by light, chemical (from other cells or the environment) or physical contact. They can work together to make a multicellular organism which in turn can display swarm behavior such as we see in ants or birds (which may have distance and direction information) and so on.

Swarm behaviour needs a goal which is best achieved by working together.

I can easily test algorithms to see what kind of behavior would result if each bot knows where the other bots are relative to themselves which is the information I assume you are trying to share between the robots.

Once I played around with writing soccer bot simulations. In the example below the bots knew where they were on the field and they knew where the ball was however they didn't have information about the other players and only reacted on contact with each other. This resulted in a mad scramble for the ball. First one there had to get the ball between itself and the goal and give it a good kick. A less than optimal way to play soccer 🙂

To enlarge an image, right click image and choose Open link in new Window.

Bearing & Obstacle Avoidance

As with so many things in Robotics there are always compromises. At least with my robots there are.  The way I’m determining the bearing to another robot is by reading that robot’s obstacle avoidance signal instead of trying to bounce a location signal off of it.  By embedding a robot’s ID and the transmitting sensor ID into a message and using that for obstacle avoidance I can solve a lot of inter-robot communication issues, but it’s been a bumpy road.  

Trying to determine a kin robot’s bearing using their obstacle avoidance message has been problematic because as the robots get closer together the beam from the IED gets so wide that multiple sensors on the receiving robot are getting the same message.  If they were analog sensors then maybe it might work, but they’re digital so they all report the same thing. They either got the message or they didn’t.

Recently I’ve started using the Vishay TSSP94056 and TSAL6100 together as my main sensor on the swarm robots.  The TSAL6100 has a very narrow beam at 20 degrees and the TSSP94056 is their fastest receiver and operates at 56kHz.  I have also started using a U shaped piece of plastic as a ‘blinder’ to shield out stray IR radiation.  

Now for the compromise.  To get the best bearing separation from the sensors when a kin robot is close by, say <7” I need all the stuff I mentioned above plus a low power IR emitter.  Very low.  The emitter is driven by a PWM signal that the Pico generates so I can control the emitter’s strength with the duty cycle, but the obstacle avoidance range with that low power is now about 5”.  So these swarmers aren’t going to be moving very fast, but I’ve finally got a decent bearing measurement.

If anyone is interested in using IR receivers as robot sensors Vishay has a nice application note on the topic. https://www.vishay.com/docs/82904/irreceiversprecencesensorapps.pdf

Tom