The future of the Borg

Today the group members (Elvar, Ebbe and Henrik) met up in Suze at 9.00. Today we are supposed to discuss and decide our end course project.

We looked at the list of possible projects and all the ones with communications between robots did not interest us. However the project from last year's First Lego League did interest us. In that project the robot has to navigate between different points and perform various missions at these points. The most difficult problem in this project is getting the robot to learn the various locations on the map and navigate to them. A standard robot will be sufficient to complete this project, meaning all the standard actuators and sensors included in the Lego kit. A link to a more detailed description of the project is included here

We will be using Behaviour based architecture to perform the missions with one behaviour for each action that the robot does.

In the end we should able to present a robot that successfully finishes all the missions and can navigate to all locations on the map.

We plan on looking at the description in more depth and design our software architecture. After that we build the Borg and code the implementation. Finally we test our Borg on the actual map. We will first start on the project on the friday the 7th.

Lesson 10:

Idag 23/11-2007 mødtes vi alle i gruppe, Elvar, Henrik og Ebbe fra kl 9:00-12:00

Indledning:
Idag skal vi, igennem en række forsøg, undersøge hvordan en behaviour-based architecture er blevet implementeret med subsumption API'et leJOS NXJ.

BumperCar:
Vi skal her eksperimentere med et behaviour-based system, hvor en legobil med en touch sensor kører udgør kernen i eksperimentet. Legobilen indeholder to behaviours som hver især aktiveres på bestemte stimuli. De to behaviour er DriveForward og HitWall.
I første del eksperiment skal vi beskrive hvad der sker når vi trykker touch sensoren ned og holder den nede. Vi observerede at så snart touch sensoren trykkes ned, så begynder legobilen at bakke, indtil den til sidst helt stopper. Det der sker internt i legobilen er at når touch sensoren aktiveres så starter den HitWall, som så er aktiveret et vidst antal sekunder, hvorefter den så stopper. HitWall han derefter aktiveres igen ved at slippe touch sensoren, for så derefter at trykke på den igen, men den aktiveres ikke sekventielt ved at holde touch sensoren nede. Det vil sige at takeControl metoden i DriveForward ikke bliver aktiveret så længe at HitWall er aktiveret da DriveForward er i sleep-mode så længe HitWall er aktiv.

Efter at vi havde implementeret en PlaySound behaviour og givet den højest prioritet skulle vi derefter observere HitWall og se hvordan den ville reagere når den blev suppressed. Når HitWall bliver suppressed stopper begge motorere, men det kan alligevel godt ske at HitWall stadig har kontrol over motorene da programmet HitWall sover mellem at den kørere tilbage og drever legobilen og hvis tråden sover kan den ikke umiddelbart suppresses, så derfor kan HitWall godt stadig have kontrol over bilen selvom den bliver suppressed.

Another Arbitrator:
Her skal vi undersøge hvorledes vi kan undersøge en triggering condition ved mellem et konstant interval. Hvis vi kort kigger tilbage på den forrige opgave, hvor vi skulle se hvad der skete når når touch sensoren holdes nede, så observerede vi at der ikke skete noget efter den havde reageret første gang. Det ville være smart hvis legobilen reagerede på at touch sensoren blev holdt ned ved at den blev ved med at køre baglæns, og dette vil måske være muligt med undersøgelse at triggering conditions mellem et fast interval.
Efter vi tog de beskrevne skridt i opgaven opserverede vi nu at, hvis f.eks touch sensoren blev holdt nede, så gentog den HitWall behaviour sekvensen flere gange efter hinanden, som vi havde antaget.

Motivation Funktions:
Denne opgave går ud på at bruge motivation som faktor i beslutnings processen, når legobilen finder ud af hvilken behaviour den skal udføre. Her kan takeControl eventuelt bruges hvor den returnere en motivation variable mellem 0-1, som hentyder hvor motiveret legobilen er for at udføre en bestemt behaviour, hvor 1 er max motiveret. HitWall kunne sættes til at bruge denne metode sådan at når legobilen rammer en mur, så er den max motiveret til at bakke tilbage og dreje væk fra muren. Bilen ville derimod være mindre motiveret til at gentage sekvensen når den drejer da det ikke er mulig at køre ind i noget forfra når man bakker. Legobilen kunne derimod godt ramme en forhinding når den drejer i den dens forsøg på at komme væk fra muren, så her skulle den så igen være max motiveret til at undvige væggen endnu engang. Dermed kunne HitWall aktiveres når den forsøger at dreje væk fra muren.

References:
ReferencesBrian Bagnall, The leJOS Tutorial, Behavior
Thiemo Krink (in prep.). Motivation Networks - A Biological Model for Autonomous Agent Control.

Lesson 9: The living GPS Borg.

Today we all met in Zuse to do the exercises for Lesson 9.

The goal is to perform some experiments with the tacho navigator in order to explore the accuracy and potential uses.
The codebase in this experiment and the ideas and inspiration for this lesson comes from chapter 12 of the book: "Maximum Lego NXTBuilding Robots with Java Brains" by Brian Bagnall.
The robot used for this experiment is similar to the one seen on the exercise page. In fact we just used our "default" Lego robot, with some minute changes. The main one of these being, that we changed which end of the robot was 'forward' so that the turn wheel in the center is now the front of the robot.

Experiment 1:
The goal of this experiment is to determine the accuracy of the tacho navigator. We will be driving the route displayed on page 298 in chapter 12 of Bagnall's book 5 times. Each time measuring how far from the starting point the robot stops. (closer is of course better). This will give us an initial idea of the accuracy of this form of navigation.

The dark coin is the starting point and the light coin is the point were it stopped.

These are our initial results:
Run no. Deviation from start point - Direction from start point to endpoint
1: 11,5cm - W
2: 6,8cm - W
3: 10,0cm - SW
4: 7,3cm - W
5 8,7cm - NW

We observe, that the deviation is somewhat 'stable' in that it always ends behind the starting point (west of it). What this tells us is, that the accuracy of our own measurements on wheelbase might be off a bit, but also that the robot can not be considered 100% accurate in this form of navigation. Things like 'slippage' of the wheels and the inaccuracy of the mechanics that is Lego, plays a big part when driving a robot like this. For example, if the Borg drove over a coin then that was sometimes enough to introduce errors in the angles of the Borg. And once an angle error has been introduced into the driving then there is no way to take it back. At least not in the code we are using.

One thing we noticed when writing the code to test turn behavior is that when we wanted the Borg to rotate 360 degrees then nothing happened. It might be that the compiler optimizes that away since that is basically the same as doing nothing, we are not sure. We did manage to force it to turn by making a for loop that rotates the Borg 90 degrees 4 times. Even then did it not end up facing the same direction as it started in.

As a follow up to this experiment we observed that changing the wheel base to be more robust (e.g. we locked the wheels in place to be sure that they did not vary at all in between experiments) produced more stable results and therefore more accurate made the Borg get closer still to the starting point. However, the exact stopping point still varied between each run in a similar matter as before.

Thought experiment:
The last problem we will consider in todays lessons, is how it would be possible to make the robot move from one place to another using the TachoNavigator class, while avoiding any obstacles on the way.
The general problem in doing this, is keeping the TachoNavigator up-to-date with the current position while avoiding obstacles. One way to do this was to implement behaviors as we have seen last time. Having a "move to point" behavior, that utilizes the TachoNavigator running as the default behavior, but either
a) stopping every X units to detect any obstacles in its way and then starting the "avoid" behavior, or
b) having the avoidance behavior being able to inhibit the "move to point" behavior, while it avoids an obstacle.

option b) would probably be preferred, as it makes more sense to talk about "behaving" in some manner in this way.
The main thing here is then that the avoidance behavior should take over, but not just avoid randomly. It could be a "wall follower" behavior that tries to follow the obstacle outline in the general direction of the point we want to go to. The last part of this sentence is important, since we do not want the robot to be sidetracked to a dead end, or an entirely different location. So it should always try to have some "desired" direction that goes toward the final point it wants to reach. After avoiding the obstacle (in one way or another), the UpdatePosition method should be called in the TachoNavigator class, and the "move to point" behavior should take over again.

The code used in this experiment can be found here.

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.

Light! The Borgs first love and worst enemy

In lesson 7 we have to study some examples vehicles proposed by Valentino Braitenberg in the early 1980's. Braitenburg proposed several reactive vehicles that have seemingly complex behaviours although they only consist of very simple internal structures.

Our primary interest in this lesson will be 2 vehicles, which react to light. Specificly, one will seemingly appreciate any lightsource, and try to drive closer to it, while the other will "fear" the light and drive away from it.
Theese behaviours will be accomplished by having two lightsensors at the front of our bot, that are "directly coupled" to the two motors, such that when the lightsensor experiences an increased amount of light, it will generate more power for its corresponding motor.
The trick is, that in order to get the "attraction" effect, we will crosswire the sensor and motor, such that when the right sensor senses light, it will increase the power to the left motor, hence making it go right. To Achieve the opposite effect, we will just switch the sensor/motor connection. This is a very simple matter, even though one has to remember that the input from the sensors actually has to go through our program which wil interpret the value, normalize and adapt it before the power to the motor will be set. Hence it is kind of a simulation of Braitenburg's intended vehicles.

Based on code based on the simple examples in the article from lesson 7, we build our Borg as explained. But even though it is a simple system it was not quite such an easy matter to get it to work.
One of the major problems was that the sensors reacts very poorly on light from the environment and hence it was hard to get it to do anything at all. Another problem we encountered was with the multithreading capabilities of the java framework for lego. It was not easy to actually get both sensors and motors to react in a concurrent fashion.
Theese problems resulted in the fact that we had to actually point a lightsource at one of the light sensors to get it to do anything. A lightsource on the top of the vehicle simple did not do anything for the sensors.

All this goes to show, that even though you are actually building something fundementally very simple, there are still lots of technical issues that inhibits the expected behaviour. We believe that if we had used the never NXT sensors instead of the old sensor versions we could have obtained some better results, but unfortunately theese where not available.