EXPECT THE UNEXPECTED
THE RIDDLE OF EMERGENT BEHAVIOR
First Contact, The Swarm Interacts!
Turn on a lot of robots in a confined space and fun is on the menu! I have embraced a love of swarms since the earliest days of robotics but, I am excited about this less structured kind of swarm. I’ll bet a chaos mathematician would have a ball in my little arena. Of course, as much as you want it to be, life is not always fun. Sometimes bad things happen to well-intentioned writers and I am no exception.
I suffered a major setback in the last month. A virus destroyed my hard drive and though I had the emergent behavior files in a certain (backed up) location, I didn’t remember that the operational code was in a different spot. When the drive was reformatted, I lost the source code for the Boe-Bots.
Here is a little bonus FYI for those who don’t know; there is no way to get your code back from your Basic Stamp. Once it is com- piled, it loses all the labels, names and comments. Reverse engineering a Basic Stamp 2 program from the chip’s memory is a waste of time, if you wrote the code, it is faster to just take a deep breath, get a coffee and re- write the program.
There is a good side though; disaster often paves the way for renewal. The effect of this event was to force me to do what we should all eventually do, when we are going through the cycle of programming and then testing and programming (repeat). Once in a while, we should wipe the slate clean and write a fresh program. That way we can keep all the best features and drop any leftover junk. It also allows some new thinking to come into play and new features come to mind. Less junk means less program and that means more room in memory for cool features.
One of the new things I wrote into the code that had not previously been there was some- thing that began to come out of the testing. Something that ‘emerged’. My basic collision avoidance rules resulted in the bots spending a lot of time doing what I will call ‘dancing’.
As you may recall, the collision avoidance algorithm is a simple rule. First turn left, then move forward six inches, then turn right and continue forward. This is a good basic idea, but the way I implemented it was to store the last turn direction and then sim- ply turn the opposite way the next time. But, if there is another obstacle immediately to the left of the robot, the collision avoidance stops the robot and since the last turn was left, this time it turns right.
Immediately, it sees the first obstacle (which it has not yet cleared) and it turns again. This time left. Of course, the obstacle that caused it to turn back in the first place is still there, so it turns again.
Of course if there are lots of robots, there are lots of conflicts and lots of dances. The dancing would always resolve the conflict, eventually, but all this activity was eating up batteries like crazy! I decided to turn off the music to make it stop.
So, based on a rough count of time, if the repetitions came too quickly together, it is decided that a dance has developed and I wrote in a full stop for five seconds to pause the bot. This way, any nearby bots which the dancing bot was not communicating with would have enough time to move on and clear the area.
Of course, the obstacle could be a wall. In which case it would not be moving on. So I made a variable to count the repeats and if the pause was repeated more than twice, the obstacle would be considered immobile. Either it is a dead robot or a wall. Then I wrote a little subroutine to look for a way out. Basically, I made the robot turn 90 degrees four times and check the obstacle distance at each turn.
Once the clear route is discovered, the robot travels it for one foot and then resumes on course (which it hopefully hasn’t lost track of yet). It was getting pretty complex at this point, but I hoped that it would control the behavior.
Truthfully, I felt a little unsure about this change. “Dancing” was the first behavior that I observed that could have been considered emergent. It was a little underwhelming, but it was truly emergent.
There was no intent to write code that would make the robots dance. The basic rules the robots followed to avoid collisions resulted in a repetitive action that was not included in the original design. So, I am forced into wondering (a bit philosophical- ly?), that if I change the rules to eliminate the behavior, am I eliminating an outcome? Eliminating an emergence?
I reasoned that the code that caused the behavior was not one of the rules of the original experiment, so it was more of a technical glitch. That said, I like the way it looks when they dance, so I might change it back.
Back to business. If the robot determines the obstacle is a wall, then it is necessary only to figure out which way to go to get away from it. The criteria for determining if it is a wall is quite straightforward. It doesn’t move. It should be a simple matter of waiting a little while and testing again. If the obstacle is still there, then it is a dead robot or a wall.
With the new code checked and uploaded, testing could now begin. I set up an arena in my garage using an old ping pong table and some lumber for the ends. Some long light fixtures I had lying around looked good to be the sides and with the nests in the center of each end, I thought it looked pretty good.
First, I tested the newly completed arena with just a single robot and discovered right away that the makeshift walls were a little bit low. As the robot got close, if the PING))) was angled just a little bit too high, the echo was getting missed. I angled the PING))) down and that solved the problem for the moment, but I would need a more permanent fix.
I began a list of necessary improvements. 1×3 lumber would be needed for walls and my makeshift walls need to go. Ok, next test; add more robots. At this point in the testing, the end nests are not on and the robots are being turned at the ends by my trusty assistant, Shannon.
Two robots worked fine, but I expected it to be fine because I had been using two robots for all my tabletop tests. Three also worked well, but four began to expose a few problems with the code. The robots began to become seen as stationary obstacles, if there were two robots in close proximity. It seemed they would both dance a couple times and then both would stop. This was not what I wanted to achieve.
If the angle of the robots was not perfect, the communications between robots would not take place and the code dropped to the failsafe to prevent the robot being trapped. The robot would then turn and proceed on course, but when the timing meant the other robot would then move and suddenly robots started whacking into each other.
I am not a big fan of damaging the robots, so the whacking has to stop. I got a little bogged down in the details here and burned quite a few hours in trial and error. Quite a lot of experimenting in this area has led to finding a lot of ways that don’t work. I still don’t have a completely working solution, but I am confident that it will come. Much more trial and error is required. There is some improvement, but one fix causes other problems and so it goes on.
I believe that, though it is still chaotic, next issue will be the time to turn on the nests. This is the part of the code that gives the robots purpose. Before now, most of the code has been infrastructure. With the nests on, the robots will start tracking the beams. This code was developed early and parked; and of course it was lost, but the code was not complex. It is a simple matter of ‘on beam’ or ‘off beam’.
The real interesting stuff should start from this point on because this is where I program what the robot is carrying (food or refuse) and take the communications to the next level. This is where the robots will begin to exchange the food (and/or refuse) between each other and eventually the nest.
After which, they will reverse course and search for the other nest to begin again.
It is at this point that I expect something truly remarkable will happen. It is at this point that I am expecting something to emerge. I don’t know exactly what will happen, but I think a pattern will develop. I think the robots will begin to form relationships with each other. I hope it will be clear enough to observe and there won’t be too much error.
The only things that actually orient the robots are the beams. This makes me think that the robots will form lines leading to the nests. I think some robots will never make it to the nests, but will still carry food and refuse from robots they encounter, while trying.
It is important to note that I am not programming the robots to work collaboratively. The only rules are to get food, remove refuse and exchange that with any robot they encounter along the way.
Whatever extra comes from those simple rules, is emergent!