EXPECT THE UNEXPECTED
THE RIDDLE OF EMERGENT BEHAVIOR
The build has been going well. Even with some setbacks, I am nearing the end of the building phase and finally approaching the start of the actual experiment. Will I see an emergent behavior? Have I already seen all the emergence I am to see? It is time to bring all the modules to their final state and start observing the motion of the swarm. I am getting excited about the possibilities.
But, all this thought to the experiment and suddenly realize that I have missed a fundamental step. What, in fact, is the “start”. Very basically, I had not asked the question: What is the physical starting position of the swarm? Should they all have food? Should some have food and some have waste? Should all of the robots be carrying nothing? What is the right state?
My first thought was to start the experiment based on the beginning of a typical day. No food for anybody; all robots must forage. If I start all the bots with nothing, that is a pretty good first state. Then they would all start out in search of food. But is it an appropriate first state?
One could argue that yes, the insect would awake from a night of rest and proceed out to begin its day, but the reality is that we are dealing with mechanics, not organics. Therefore, day and night has no meaning. Operations would be continuous. The only interruption would be depleted batteries, which would expire at a variable rate, eventually causing different robots to require a recharge or replacement (in the case of Boe-Bots) in a random fashion.
I know of a robotic factory in Japan that operates with no lights on in the building. There is no need because there are no people working; only robots. The sensors on the robots do not require light to function, so unless a human technician is conducting maintenance, all the operations are carried out in complete darkness. Day and night have no meaning.
The result of continuous operations means that over time, all the robots would be starting and stopping at different times of day. In order to simulate this, I have decided to start the robots in pairs, some with food, some with waste and some with nothing, from both ends. First one group and then the other, until all the robots were on the field.
The first step in accomplishing this task is to get the robots talking to the beacons. With that done, the next and last programming task is to have the robots talking to each other and exchanging food and waste in the process.
As you may know from the last article, the beacon code, though destroyed by the virus, would be easy to re-create and I was right. Within the first hour, working from the excellent texts about IR communications that are on the Parallax website, I had messages going from beacon to robot. The Bug-Bots made their first conversations with the nest.
All that was left was to integrate the new IR code into the main loop of what I have started to call The Bug-Bots. That sounded easy and it was! Well, it was easy to integrate the code. What happened next came as a big surprise.
Turning on the beacons caused some interesting and unintended effects. The first robot went so completely crazy that I assumed there was something mis-wired on the robot and I selected another but, the repeat of the chaotic swirling dance resulted in my making a fast jab at the reset button to calm things down.
I know that it was very important to have the shields on the IR receivers and LEDs to ensure that the beams were truly beams. For a little while I had forgotten to add the shield to one of the beacons. As a result, I spent a lot of wasted time trying to eliminate the errant signals. IR is light. It scatters and bounces and reflects. One must think about the invisible as visible and consider it just like any other kind of light.
But it wasn’t just the light. It was the sound, as well. Ultrasonic sound is also still sound. Our ability to register those frequencies in our ears has nothing to do with the fact that they remain vibrating waves in the atmosphere. It caused me to ponder while, at one point, I was trying to make sense of the chaos, what would it look like if I could see all the interference patterns of the ping sensors as they rattled out their sonic waves, which would then bounce around in the environment?
What would the infrared light look like as it was being fired from the front of each robot and from the beacons? As I stood imagining how that riotous vision would appear, I realized I had created a monster. I was going to need to step back and really look at the timing of elements in the code.
The ping modules were working pretty well, but I had integrated the IR side sensors into the collision avoidance module in order to watch for robots on the right and left and kept all the front IR LEDs flashing continuously. This seemed to be causing the side sensors to keep going off and the robot would turn to face the ‘robot’ on the side and if there was one, immediately go into collision avoidance and start spinning and flailing.
I would like to have called it emergent, but the result (even with only a few robots in the arena) was a pretty good representation of nuclear fission. A lot of energy output from a very small input.
For days, I struggled with the code, sectioning out what I thought was causing the trouble and trying again. And again. And again. At the time of this writing, I still have not completely debugged the code. Dejected, I decided to work on what I hoped would be the easier of the two remaining tasks: robot to robot exchange.
This piece requires what I believe is the last piece of hardware to get mounted on the Boe-Bot (Bug-Bot?). A second LED. The first one was red in color and really was only there to assist with debugging code, to this point, but now it must be used for its real purpose: to indicate which cargo the Boe-Bot is carrying: food or waste. The red LED is used to indicate waste.
The second LED, green, will indicate food. Both LEDs off will indicate an empty bot. The third possible state. Both on is not possible because I decided that the Bug-Bots won’t be allowed to carry both food and waste at the same time. At this point, the electronics package should be complete.
Once I am sure that the electronics are all on board, I will take the time to clean up the breadboard by shortening all the leads and rearranging and routing all the wires, so that everything is neat and tidy. This is for more than just aesthetics. The resistors standing tall on their leads actually represent a hazard to the Boe-Bot. If an errant hand should press the leads together a short circuit could occur that could not only result in damage to the processor and its support electronics but in a worst case cause fire.
Careful handling now will need to be replaced with solid engineering later. I have considered building a circuit board to solder all the components down and ensure that they will stay put as the robots interact in the swarm environment. You may see this in an upcoming issue. Stay tuned.
With the LEDs in place, the communications test between two robots worked fairly well, but is not without its own issues. With the LED and IR detectors wide open, the signals work well. But with the shrouds necessary to contain the signals within a narrow beam, the conversation becomes a bit sketchy. So, I turned everything off except the exchange code between two robots. This worked.
They talk. They send food back and forth between two Bug-Bots and the LEDs alternate nicely. It seems a very civil exchange. Will this conversation remain civil? Or when I turn the rest on, is the chaos I saw earlier a battle the robots engage in to wrest food from one another and get to the nest first?
What am I seeing? What is the conversation? Perhaps the emergence will be not be as I expected. Perhaps the rules I have settled on are resulting in violent conquest instead of cooperative collaboration. Is the system a breeding ground for the “robotic bully”?
Right now, it is hard to tell. If you don’t see an article in the next issue, then I am still wrestling with the code, trying to settle it down and bring harmony to the electronic universe inside the Parallax Basic Stamp processor. I’ll be back with the answer soon enough.
Wish me luck.
Parallax, Inc., www.parallax.com