Tuesday, May 11, 2021
Home » Emergent Behavior » Emergent Behavior – Part 4

Emergent Behavior – Part 4



Programming The Swarm: Applications In Emergent Behavior

Emergent Behavior 4-5Swarms are a fascinating aspect of robotics that gets more prevalent every day. Basically, swarms are a group of robots working together. A lot of possibilities open up when robots work in teams. One of the earliest ideas was forwarded by Rodney Brooks from MIT when designs were being sought for the Mars rovers.

The design forwarded by the MIT team was a swarm of terrain adaptive semi-autonomous hexapod robots. This design offered many advantages. No single robot failure would cripple the project. In fact, you could lose many robots in the swarm and still have an effective science package.

The swarm gathers information along the entire physical distance of the swarm, which could be many miles wide. Communication allows for computing resources to be shared. The same communication can equip the swarm with early detection of threats at one end that could enable robots at the other end to protect themselves against things like weather events.

Any kind of information available at any point of the swarm is available to the entire swarm.

The swarm is also protected from all kinds of failures. Robots that are no longer functioning are simply dropped from the group and the gap is closed. The coverage shrinks slightly, but the work of the swarm continues.

Emergent Behavior 4-16There are countless applications for swarms: search and rescue, exploration, cleaning, inspection, intrusion detection and security to name a few. A little imagination and swarms of quadcopters could be attacking fires in problematic locations like nuclear reactors or applying paint to high buildings or bridges.

I am exploring a kind of limited integration. There will be no dividing of resources or sophisticated communications. In fact, the point is to simplify. In the emergent behavior experiment I am exploring to see what happens when the swarm is limited to brief exchanges of data and collision avoidance.

Collision avoidance will be achieved by the use of PING ))) modules and whiskers. Communication has proven to be a challenge, but when the best method is chosen, it will all have to be programmed.

Programming the Boe-Bots Basic Stamp 2 processors has its own challenges. The biggest challenge in a larger project is the memory on the Stamp. The memory available for the program is limited to 2K or 2,000 bytes. That isn’t very much. In my Khan project, I used 1994 bytes of memory.

Another challenge is the lack of interrupts. This is not uncommon; however, small processing platforms and PICs often lack interrupts.

These kinds of limitations mean the programmer needs to be vigilant and plan care- fully. The most important aspect of the programming design is the use of subroutines. Subroutines are like little boxes of code that the processor can go and use whenever you tell it to. The big advantage here is that you do not need to repeat the code and therefore you take up less of the precious 2k of memory for the program. An example of a subroutine in pBasic code looks like this example taken from the code from last issue’s IR beam tracking code:


DO irdetect = IN3 ‘ look for IR signal

IF (irdetect = 0) THEN

GOSUB Fwd_pulse ‘ if found, move forward



‘ —–{ Subroutine – Single forward pulse ]—- ——————–


PULSOUT 13, 850 ‘ move left servo forward

PULSOUT 12, 650 ‘ move right servo forward


wait 20ms


Here, the subroutine is called Fwd_pulse: and it is called from inside the “IF” statement in the main code. The other code is removed for clarity so you can see that if port 3 on the Basic detects and IR pulse, then the unit moves forward in response.

This subroutine can be called over and over from anywhere in the program and will never use any more code than the first time it was written.

Keeping subroutines organized is some- times a good reason to use a flowchart. When I studied programming in the early ‘80s, we flowcharted everything from start to finish. That is no longer necessary, but it is a helpful tool when you are visualizing how you want to call a subroutine.

An interrupt is an electrical or soft- ware connection directly into the processing core that alerts the processor to a condition that requires immediate attention, like a whisker contact. The processor stops working on the instructions in the stack and processes an Interrupt Request (IRQ) or runs the code in an Interrupt Handler. Without interrupts, you must poll your sensors one at a time for their individual condition and that takes time. The time spent in polling sensors can mean a sensor that gets a momentary contact can get missed. That information is lost and if that lost information is a warning to an imminent collision, the result will probably be a crash.

Comments are the last thing I am going to mention and they are very important. Commenting your code not only helps the next person who reads it to understand what you are up to, but also serves as notes for yourself.

It is not uncommon for me to completely forget why I wrote code a certain way or what I was planning to do next, especially if I have taken a break from a particular piece of code to work on something else.

So you can clearly see the advantages of modular code. As I step through programming the swarm, I am finished with my motor control routines. That module is done and if I need to move the robot, I need only to call the subroutine.

Also complete are the codes that send and receive signals on the IR chip. The only thing that will change slightly there is the protocol and there is a subroutine for that. By the way, calling a subroutine from within another subroutine is called Nested Subroutines.

Programming and testing the programming of the swarm is complicated and time consuming. Some of it has been done, but there is much still to do. Don’t be afraid to just jump in an d try things too. There are a huge number of forums and the Parallax site has a marvelous discussion thread on any number of Stamp topics.

I hope this helps you to write your basic programs in smaller, more efficient memory spaces. Happy coding!

Parallax, Inc., www.parallax.com