The end course project

Starting up:

Participants: Johan & Jakob

Date: 24/11-2010

Duration: 4 Hours

Goal: Determine which project will be made for the end course project, describe that and two alternatives.

Plan: Discuss and agree upon three overarching themes for projects, then brainstorm within each area.

Consider the possibilities and problem areas within each project and describe them according to NXT programming excercise 11.

The three themes

We decided upon choosing between a predator/prey system inspired by [1], a set of music robots inspired in part by The Trons [2] and some sort of scenario involving sexrobots and the exchange of genes, inspired by [3].


Music bots:
A flock of robots synchronized in such a way that they can agree on a global time, tempo or beat and act accordingly. This encompasses that an external observer should get the sense that the robots are aware of each other and playing music together. 


Sex bots:
A flock of robots that when they meet exchange genomes representing different behaviours or parts of behaviours.
Whether they exchange parts of behaviour or complete patterns would be determined at a later point.

Music Robots:
As describe above the robots need to agree on a global clock, disregarding order of activation and time of activation. Different methodologies have been aired as to how we could go about this. Using the microphone seemed the most difficult as we would then need to detect beats. Different time synchronization algorithms for distributed systems exists and one of these could be employed after having established the NXTs in a network over bluetooth. We have also discussed having a central NXT dictate the beat and use motor output wired via the converters to the sensor ports of the performing robots.


Hardware needed:
A bunch of NXT's possibly with microphones for synchronizing, if this approach is chosen. Convertercables between NXTs and RCXs might also be needed.

Softwareplatform:

Each NXT must have the same base software component developed in LeJOS, there might also need to be developed a seperate central controller for tempo dictating purposes should that approach be chosen.

Expected Difficulties:

There are several challenges in this project, the first being the part of actually  getting them synchronized on a level where the fine tuned human ear does not get annoyed at the system being a bit out of sync. Furthermore the challenge of dynamically adding or removing robots from of the system without disrupting the state of the system might not be a trivial task.

The system might also employ some sort of leader election algorithm to determine which robot is allowed to play a solo. 

On another level the purely artistic value of the system is going to be extremely challenging to bring forth.

Possible presentation:
At the end course presentation the robots sould be able to perform a piece of rythmic music, after being started seperately and deciding on a common beat. 
Possibly this could include internal communication to determine a soloist and so on.




Sex bots
The overarching theme in this project is to observe emergent behaviour in a flock of robots that exchange different behaviour genomes. A bunch of robots wander around on a map of some sort and each time they bump into each other they exchange part of their genome with the other robot.


Hardware requirements:
A bunch of NXTs with sensors enabling navigation and a bunch of motors, enable movement on the field.


Softwareplatform:
Each NXT needs to have a common framework, that controls the robot.
This framework can then contain an assortment of different genomes all implementing the same "genome" interface.
This way each robot can exchange genomes and use them very similar to behaviourbased architectures.


Expected difficulties:
One of the great challenges in this project is to express the behaviour of the individual robots in such a way that it is obvious when the different genomes are switched around. Also defining meaningful genomes and the whole exchange protocol could pose difficult.


Possible Presentation:
If all ends well, the flock of robots will at the end of the project be able to exchange behaviours in a way that manifests itself clearly in the environment.
Then it would be interesting to test out different algorithms for genome exchange as well as framework function and how this influences any convergence on specific behaviours if those are experienced.


Predator/Prey:
The general idea of this project is to have robots of two different kinds, predators and prey. Within this system there would be different conditions that resulted in death - hunger, age and so on. When a robot is dead there would need to be different conditions in which they can revived to create a more persistent world. Within this system we would like to have the robots seem like they're acting in a flock, even though they're all having individual behaviour patterns.


Hardware requirements:
A bunch of NXTs along with sensors and actuators from the standard kit.


Software requirements:
Two different controllers one for predators and one for prey. There might also be a need for a central controller operating the environment.


Other requirements:
A mat or other material representing the environment, this might actually take quite some time to fabricate as we need to create representations of safezones, foodzones, and homes. And in such a way that the robots are able to navigate it.


Expected difficulties:
The hardest part of this project is probably going to be creation behavioural patterns that are easy for the audience to interpret. Other than that navigating the environment in a meaningful way might also pose a challenge.

References:

1. http://www.imm.dtu.dk/upload/institutter/imm/cse%20laboratories/wurtz.pdf  - project from iMars lab
2. http://www.youtube.com/watch?v=c2JChnwv2Ws - The Trons
3. http://hackaday.com/2005/03/25/sex-bots/ - Sex bots

Color Recognition

Starting up:
Participants: Johan & Jakob
Date: 2/12-2010
Duration: 3 Hours
Goal: Investigate the light sensor and determine whether the sensor can be used to detect more colors than merely black and white.
Plan: First we will try and determine how precise the sensor can differentiate between black, white and green. Next we will try to utilize this to create a program which can detect which of the three colors the surface is.

Experiments:
Our initial experiments were designed to give us a better insight into the sensitivity of the light sensor. We placed the sensor over the different colored surfaces (black, white and green) and took readings from the sensor using the BlackWhiteSensor class. The sensor readings were fairly consistent with an error margin of approximately +/- 2-3. This error margin is mainly due to the sensor vibrating, thereby making the sensor get closer and farther away from the surface.
The sensor reading also gave us an impression of what the different colors' value were and it was evident that the readings from black and green were very close to each other, however we still believed that by choosing a small enough error margin we would be able to interpret the reading correctly and choose the correct color.

Line follower:
We tried the LineFollower class and it worked as expected. Next we looked at the code to try and come up with a method to extend the BlackWhiteSensor class to incorporate the color green. We decided that a simple addition of the color green in the calibration routine and a method for returning whether the current color is green would be sufficient to be able to use all three colors. The method green (to determine whether the surface is green) is implemented in a way so that it has an error margin of +/- 2. Meaning that if the sensor reading is within +/- 2 of the reading from the calibration routine, the surface would be interpreted as being green. A fairly basic approach which we believed would be sufficient for the job.

We the implemented a test program called ColorTest based on the LineFollower class. The only significant alteration is the behaviour when confronted with a color. The robot moves forward continuously and analyzes the color of the surface. If the color is green the robot makes a buzzing noise and writes green on the LCD, if the color is white it beeps twice and writes white on the LCD and if the color is black the robot beeps once and writes black on the LCD.
Since the sensor reading of green is within the threshold of black it is important to start out checking if the color is green, otherwise it would default to black each time. This is because we didn't want to make major changes to the class and we felt this approach would be sufficient.

Tests and results:
The test program was run several times and while there were a few anomalies it worked fairly well. The biggest anomaly was the fact that the transition from a black surface to a white surface and vice versa was often interrupted with a reading of green in between. We concluded that this was due to the sensor reading half white half black and thereby triggering a green interpretation because it is between black and white in the light spectrum. Another small anomaly was the occasional black reading while on a green surface. This was concluded to be caused by the vibrations in the robot making the sensor get closer to the surface and thereby reading a darker color than in the calibration. We attempted to fix this with the green error margin, but found that increasing it only caused the problem to migrate to the black surface.
All in all the tests were successful besides the few anomalies. the robot was able to interpret the surface correctly the majority of the time.

Conclusion:
The experiments showed that it was possible with a low probability of error to detect other colors than merely black and white. By making further experiments it might also be possible to add another color closer to the white spectrum and identifying this color as well. This, however, remains untested.

References:
1. http://www.daimi.au.dk/~bubbi/lego/ColorSensor.java - ColorSensor class for detecting black, white and green.
2. http://www.daimi.au.dk/~bubbi/lego/ColorTest.java - Test program for detecting surface colors.