EXPECT THE UNEXPECTED
THE RIDDLE OF EMERGENT BEHAVIOR
The swarm is built, the experiment is designed, and now it is time for the nitty-gritty.
In the January/ February Issue of Robot we kicked this experiment off and now it’s time to get down to work and make some actual circuits and software that works. To recap, the intent of the experiment is to develop a robot swarm that demonstrates an emergent behavior. An Emergent Behavior is anything that wasn’t originally intended in the program, but results from the interaction of the robots and usually proceeds from a simple set of rules.
First Things First
The swarm needs to communicate. This is the most important thing and, conveniently, there are many code examples that demonstrate various methods of communication. Most communication code out there provides for communication between the human and the Boe Bot, but if you dig deep enough, you can find subroutines that deal with BS2 to BS2 communications using Infrared (IR).
There are a few great reasons to use IR. First and foremost is that all of the required parts exist in the Boe-Bot kit. Nothing extra is necessary. Also, the other forms of communication tend to lack a certain intimacy. I could use RF, but with RF, all the robots can talk at once. I would need to manage communication traffic and the communications themselves would contain no proximity information. If I use IR, the fact that the other robots would be able to see their counterpart’s IR signal provides a type of information that, by nature, contains some basic proximity data.
The IR signal has a limit to its range and a limit on the angles in which the robot can ‘see’ the signal. This provides enough proximity data to tell us that one robot is near another robot, but it doesn’t tell us anything about the other robots that may be nearby, but pointed in another direction.
To make IR communications work, we need a protocol. Thankfully, a basic IR communication protocol for Boe-to-Boe communication exists in the Boe-Bot Documentation, so I don’t need to reinvent the wheel. I just need to ‘cookbook’ the subroutines into a program that does what I want it to. Basically, the Parallax documentation talks about 1 Boe-Bot talking to another, but I need each Boe-Bot to both talk and listen to others.
So the code examples are a starting point, but they do provide useful information, like some of the constant and variable values, which takes a lot of trial and error out of the work. At this point, I just want the robots to be able to exchange basic handshakes with each other and the proof (test) that the signal is received will be to stop the motors.
I set the program’s main loop up to watch for IR traffic and IF it sees none, THEN broadcast a blast of IR. IF, during the watching phase, the robot sees IR, THEN the robot stops in place and illuminates an LED.
There is no collision detection yet, but this was done on purpose. I am hoping to avoid collisions by using dead reckoning. What the heck is Dead Reckoning, you ask? Used by sailors and pilots for as long as people have sailed ships, it is a simple speed-time-distance calculation. If you move at a certain speed for a certain time, you should travel a calculable distance. For example: The Captain knows that if the helmsman of the sailing ship can hold a steady compass heading for a certain number of hours, the vessel will arrive at a certain point on the map. Assuming nothing changes, like wind speed or direction.
The same holds true for land based robots. In cases where there are no beacons, borders or any other frame of reference, you must calculate how far your robot will travel at what speed and determine position in relation to the starting point. For instance, I know that if my robot travels perfectly straight at a rate of 6 inches per second, I can reasonably predict that in 6 seconds, the robot will have travelled three feet. If the robot ran true enough, I could put an “X” on the ground and the robot would stop on top of it, every time.
After the robots are stopped and knowing the length of the Boe-Bot (5 ½ inches, so round up to six inches), we then just program a 90-degree turn, run straight for 12 inches and turn 90 degrees back to the starting angle. Now the robots can each run straight and there is no chance of hit- ting each other.
Knowing the distance allows the programmer to cover a certain amount of ground with a fixed length of time. The hitch in this plan is the errors introduced by the surfaces and the imperfections in the components. These are cumulative and result in a deflection from the intended path. At some point, a frame of reference is required to correct the errors.
In the case of this experiment the frame of reference will be the “Feeding Stations” at each end of the arena which are beacons.
Now that I had some of the basics down, it was time to start playing with the robots. I wanted to get them to see each other and just stop. After downloading my program, I turned on the first robot and it ran forward in a stutter step; starting and stopping! It would jerk ahead at ¼ second intervals pausing between each lunge. Completely useless!
The problems were the result of my understanding of the commands. My first attempt was to have the robot move until a valid start byte was read from another robot. This lead to the robot moving ahead one inch, stopping and then repeating that action. The problem was in the FREQIN command. If no value is specified, it will read for the entire maximum time a pulse could take before moving to the next command. The resulting starting and stopping simply wouldn’t do. Back to the drawing board.
Luckily, the solution was to simply check the pin to see if any IR signal was present at all, before trying to read the signal. This check is very fast and is achieved by simply reading a logical 1 or 0 on the port. If there is a signal, the conversation can start. Reading the port takes no time at all and after the code change, the robot ran at a steady speed.
I set the loop up to run forward at full speed, checking to see if there was a signal, then stop the motors when an IR signal is detected and just wait. I decided to leave the conversation part out for this test. Placing the robots across the room from each other, my daughter starting one and me starting the other, we hit the ‘on’ switches. Each robot moved about four or five inches and then stopped.
“Wow, Dad. That was great. Can we do it again?” Came the sarcastic observation of my oldest teen.
The robots were still more than six feet apart! We did try it again and the behavior repeated. It was definitely not planned, but it was also not emergent! After some investigation, I discovered that this was happening because the IR LEDs in the Parallax kits have a very good range! The Boe-Bots can see each other all the way across a room!
Of course, this is a disaster! The plan was for the robots to get fairly close, before “seeing” each other. With a range of over six feet, in order to use dead reckoning, I would need a large gymnasium to conduct the experiment! The IR pollution in the room would be thick. Each Boe-Bot would be seeing IR from the other bots scattered all over the room and miscommunication would be rampant.
So, it is back to the drawing board for a new solution to the communication problem. I have a few ideas to try. Possibly using proximity feelers to get really, really close, then maybe using sound? Maybe ultra- sound? What about longer shrouds on the IR? Or placing the LED lower on the bot?
So, faithful reader, do you have any ideas to help me solve this issue? If you do, feel free to send them to me at: emergentbehavior@ botmag.com and I will try out your best ideas and report on them in the next issue. Maybe they will make good YouTube videos.