Swarm Robotics

Posted by: @robotbuilder

↑

Aloha protocol

So here I imagine each bot has an accurate clock that is synchronized with the clocks in the other bots. Each bot can only send a message at a particular time during which the other robots are in receive mode.

No synchronization with clocks.  I pulled this off of the Internet.

ALOHA facts

• Developed early 70s at University of Hawaii
• Basic idea is very simple, but many modifications exist
• Any terminal is allowed to transmit without considering whether channel is idle or busy
• If packet is received correctly, the base station transmits an acknowledgement.
• If no acknowledgement is received by the mobile,
  • it assumes the packet to be lost
  • it retransmits the packet after waiting a random time
• Unslotted ALOHA: transmission may start anytime
• Slotted ALOHA: packets are transmitted in time slots

and a couple of graphics

Simple is good, I should be able to figure something out when I get to that point in my to-do list.

Tom

@thrandell 

I assume the graphic shows frames (packets) of groups of on/off binary states making up one message.

So the blue and green packages conflict and are randomly sent again (shaded).

How does user 2 and user 3 know that there was a conflict to send again?

And how is it determined that there was a conflict and by which users?

I wonder if remote IR remote controls can conflict if pointed at the same device. Maybe they have different carrier frequencies for each device.

Probably it would be easier to follow if a remote control protocol was used in the explanations rather than the complex wrap business of the RPi pico?

To enlarge image, right click image and select Open link in new window.

@thrandell 

Just some thoughts off topic on the IR transmissions but relevant to swarm robots.

The difficult step will surely be the writing of algorithms to make use of the bots current input and internal state to select a behaviour that brings about some useful swarming outcome.

What does each robot need to know about the other robots?

As far as I know individuals in most swarms only react to the closest neighbours.

The most common recognition in nature would be by touch and mostly vision.

Nature seems to have selected for easy to recognize visual targets to detect other members in a swarm.

With vision only those in sight need to be considered in choosing a behaviour.

I see an example on the internet of swarm robot fish that use two pi cameras and blue LEDs.

Posted by: @robotbuilder

↑

What does each robot need to know about the other robots?

That's a good question and one I’ve been thinking about. 

Since I now have two robots that minimally interfere with each other I thought that I should start working on robot pair behaviors.  Like followRobot, avoidRobot, orbitRobot.  To do that I need to have each robot gather range and bearing information about the other robot and then exchange that information with a message.  I think that I’ve got a handle on the range, but bearing is killing me because my receivers are 90 degrees apart and there’s a pretty big blind spot between them.  Here’s a picture of what I want to implement.

The active robot is on the left and I want it to orient itself to the other robot as it moves in an arc.  The active robot could transmit a message like: robot 1 to robot 2 my number 1 sensor picked you up at 20 cm at a bearing of 90 degrees.  The other robot would then respond with robot 2 to robot 1 my number 3 sensor picked up up at 20 cm at a bearing of 270 degrees.  It would then be up to the active robot to orient itself to have the same heading as the other robot while it moves in an arc.  Clear as mud?

Tom

@thrandell 

Not sure how much communication is really needed. Swarm bots simple react to a stimulus and there is a resultant "emergent" behaviour.

Nor do they usually know where they are on a global map to communicate,  they only know their positions (distance and direction) relative to each other.  This direction is not an absolute global direction it is just a certain number of degrees from the direction the robot is moving. "Keep that other fellow on my left."

So I imagine if one robot wants to orbit another robot it would simply rotate until a direction sensor (like a IR LED with a narrow view out say the left side of the robot) received say a pulsating LED light of a certain frequency. It would then "move forward" while continually turning left just enough to keep the robot at 90 degrees to itself.

As for a fixed distance then I imagine you do need to know the distance apart to again modify the degree of turning required to bring the orbit closer or further away.  Maybe some kind of TOF circuit.  Or an exchange of ultrasonic sound signals by timing how long before you get a reply as a measure of distance between the two robots. Another option might simply be the intensity of a light which would vary according to distance.

@thrandell 

Clear as mud?

Sort of. The exact workings are unclear to me. I have reread your posts a number of times but there is so much detail that would need clarifying before I would have any real idea if I knew what you had done, let alone what you wanted to do.

I guess the question is: What kind of feedback do you want, if any?

Posted by: @robotbuilder

↑

What kind of feedback do you want, if any?

I guess that I’m just ’thinking out loud’.

Posted by: @robotbuilder

↑

Not sure how much communication is really needed.

I believe that I could implement the BEECLUST algorithm with what I’ve come up with.  These robots won’t necessarily need to communicate with each other for that.  I’m just wondering if I should try to add more sensor functionality before committing to building a half dozen more robots?

It would be fun to try some of the things that I mentioned in my original post for this topic, like flocking and coordinated motion.  But to do that I would need to come up with a way to communicate range and bearing.

Tom

@thrandell 

I’m just wondering if I should try to add more sensor functionality before committing to building a half dozen more robots?

I don't see why you cant just add sensors to already built robots just as you can keep changing the code.

I think the basic requirement is they know if they have hit something including maybe another bot vs not another bot.

They know their own bearing - "I am going this way". No need to know what direction the other bots are going only how close those bots are relative to itself.

So one sensor I think you need is a recognition of another bot and a measure of distance to a bot near them.

The other sensors can be for all sorts of things like light intensity, temperature, touch and so on.

It’s hard to believe that I started this topic over a year ago.  Time flies.  I had this lofty goal of coming up with something to submit to this year’s Reddit Robotics Showcase but I guess it’ll have to wait for next year. https://www.reddit.com/r/robotics/

I came up with a third version of my swarm robot and I think that it’s a good enough design to crank out a few more.  So far I’ve written behaviors to avoid obstacles, recover from collisions, report battery strength and give audio and visual clues to help with debugging.  Here’s a feature list of sorts:

• Mechanical front bumper
• DRV8835 motor driver
• 75:1 Low Power 6V micro metal gear motors
• Quadrature motor encoders
• Plastic ball caster
• Lithium Ion 3.7V 1.25Ah battery
• Lithium Ion battery charger
• Panel mounted rocker power switch
• RPi Pico main controller
• Voltage checking circuit (a voltage divider connected to an analog pin)
• Piezo buzzer
• 3mm colored LEDs
• RPi Pico subsystem controller (connected via i2c to main controller)
• 8 TSSP94056 IR receivers
• 8 TSAL6400 Infrared emitting diodes
• Loads of un-used GPIO pins

You can see in this picture that I’ve made a few improvements over the previous version.  The wheels are now centered in the chassis so it makes great pivot turns.  I added a mini snap-action switch bumper with an analog circuit (another voltage divider).  I also doubled the number of IR sensors and added a Pico to control them.

It’s bigger to hold all those IR sensors and battery life is shorter but I think that the area coverage provided by the 8 IR sensors is much better than the previous version.  No blind spots although bearing measurements are pretty coarse (it’s no calibrated video imaging system).  These new IR receivers operate at 56kHz and from experiments I found that I can get good binary performance from 25 pulses of an emitter at 56kHz, which gives me around 2,240 bps.

Family photo. 

Next up is to put some thought into what I want the subsystem controller to do and nail it down so that I don’t have to be writing code for both controllers at the same time.  It has now turned into a software project. :-/

Tom

@thrandell 

Looking good.

Are you going to have any wifi connections?

Although I have two picos in the electronic collection I haven't played with them yet.

"In all cases, there’s also a choice of which programming language to use with a pico. By default, all of the Picos lean towards using Python, and the software support for wireless is a bit more complete and robust if you take this route."

https://all3dp.com/2/raspberry-pi-pico-w-h-wh-wifi/

Posted by: @robotbuilder

↑

Are you going to have any wifi connections?

No wi-fi at this point because I want to try some of the swarm robot implementation techniques that I’ve been reading about.  Bandwidth is my biggest constraint so I’m trying out a couple of tuning parameters for the sensor subsystem, namely neighbor refresh rate and the maximum number of neighbors to track.  

Eg of 4Hz neighbor refresh rate

Emit       Listen                            Emit    Listen

———|———————|———|——————-|

               250ms                       |             250ms ...

Eg of 3Hz neighbor refresh rate

Emit       Listen                                          Emit    Listen                                   

———|——————————|———|——————————|

                      333ms                               |                 333ms ...

The period of transmitting messages is fixed in these different example rates but in practice as the number of neighbors increases the emit time will cut into the listen time…

The neighbor data that I want to track initially will be:

• neighbor.sourceID (the robot that is the source of this info)
• neighbor.ID (the neighbor identified by the source)
• neighbor.type (can be robot, beacon, food, obstacle,…)
• neighbor.range (distance from source robot to neighbor)
• neighbor.bearing (bearing from source robot to neighbor)

So far I’m trying out the neighbor refresh rate as well as different duty cycles for emitters and different groupings of sensors.  As I get these robots on the mat to test out position and communication all these tuning parameters to tweak makes for a slow process.:/

Tom

@thrandell 

Forgive me for this is not really on your actual problem just a thought bubble.

The method seems complicated?

I was wondering what data you would get if each robot had an IR light on its head and you read in the analog values from the eight IR sensors? The bots would be in a landscape of illumination values. A behavior could be based on those sensor numbers?

Does it really need to know the ID of another robot if all it is doing is adjusting its position relative to that robot? Is the actual bearing of a particular robot required if you can generate behaviors based on the combined illumination of the other robots? It appears to me that an accurate relative bearing to other robots isn't really possible with a setup of only eight directions.

In the example below, which assumes the robot sensors are not getting any direct light from their own omnidirectional IR light transmitter, I tried to simulate 3 robots with eight sensors. The robots are all pointing in the same direction (as the sensor arrangement shows).

The brighter the light that sensor detects the closer it must be to another robot or to an obstacle that is reflecting the robots own light back at it.

Of course this is all in my head and the simulation. Not sure if it is practical.

To enlarge an image, right click image and select Open link in new window.

@robotbuilder

Well, that’s an interesting robot design, although I’m a little hazy on the implementation details.  

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?

Tom

@robotbuilder 

I found something I thought you might enjoy.  It’s a simulator.  

While experimenting with the robots running at the same neighbor refresh rate I noticed that they would periodically fall in and out of sync.  I’m thinking that they were both transmitting and receiving at the same time and lost their “connection”.  It reminded me of those fireflies that can synchronize their flashes with each other to impress the lady fireflies.  So I did a search and found that the way they synchronize is surprisingly simple.  Check out this simulator.

https://ncase.me/fireflies/

Tom

@thrandell Beautiful, and so easy to implement with a MPU/MCU.