Lesson 8: The structured Borg!

For lesson 8 we all met in Zuse from 12-15.

The main goal for today is to do the exercises described in lesson 8. The purpose of this lesson, is to examine layered control systems as described by Rodney Brooks in e.g. his MIT AI Memo 864. The main idea is to build specific behavior for the robot in different modules, which will be combined and run concurrently in order to achieve some overall behavior. In this manner the sample code provides us with 3 modules: Avoid front, random drive and play sounds.
During this lesson we will extend the program with a new module "Go towards light" which we will run together with the other modules. By adding more modules, the robot will (hopefully) exhibit a more complex behavior, or seem to have more goals it wishes to achieve.
But first things first:

Experiment 1 - Observing a Borg's behavior
In this experiment we will run the BehaviourTest1.java program (support classes found here) in order to observe the behavior. The goal is to learn how the modules running in different threads affect the overall behavior of the Borg.
After observing the robot, it is clear that the behavior varies between the 3 modules. But, as expected the "Play sound" module inhibits both the other modules, such that when playing sounds, it will stand still.
In the same manner the "Avoid front" module inhibits the "random drive", such that it will take over when close to an obstacle, and try to steer away from it.
Reflecting on this it is clear that when writing our own module, we must have some sort of inhibiting mechanism, such that the robot does not always just drive towards the light. Specifically it will probably be clever to have the "Avoid Front" module inhibit our module, so that it is able to avoid obstacles, even though they are bright and shiny.
In a similar manner it will be hard to both drive randomly, while still being attracted to light, so we will have to strike a balance as to which module gets command.


Experiment 2 - Teaching the Borg some manners of light
This experiment includes the coding of our module(s) which will exhibit behavior such that the robot will drive towards light. Last week we built a similar module, so it is mostly a matter of incorporating it into the framework. Our code can be found here.
The first attempt was more successful than we could have hoped. It actually followed light, while still playing sounds and occasionally taking a peek around the floor (meaning driving random every 1-3 seconds).
Instead of actually suppressing the randomdrive module, we just made that module only activate from time to time in order to get a small random deviation, in our quest for light sources.
It should be mentioned that we implemented the "drive towards light" in two different threads as suggested from last lessons exercises.
Our main problem after the first run, was that the "suppress" mechanism did not work. Meaning that when it hit a wall, it kept on going forward. This came down to a bug in the way we used the motors, as we had used motor instances instead of motorports, meaning we avoided the locomotion entirely, overruling the suppressing mechanisms somehow. We were able to fix this rather easily and the successive runs were actually surprisingly good.

In conclusion we were surprised to see that this simple form of layered concurrent behavior model was actually able to get some "fun" but still goal oriented behavior from the robot. It would probably be possible to implement more modules and string them together with the existing ones to make the robot e.g. want to follow lines, or play sounds when driving over specific colors.
That being said it will quickly become hard to manage the suppressing mechanisms, and getting more than 5-7 modules running concurrently will be a technical nightmare in forms of what should run when, and trying to determine the main goals that the robot will aim to please at any given time.