Duration of activity: 2.75 hours
Group members participating: Thomas, Rasmus, Peter
The Goal of the session...: Find end course project.
Proposal 1:
LegWay
Try to build a LEGO car that can balance on two wheels. Inspiration can be found in LegWay.
We have found a movie which presents this concept: http://www.youtube.com/watch?v=b3vDnwwBmgQ
Materials:
Only one nxt is needed, along with a couple of wheels...
Challenge:
Trying out different approaches to see which ones work (Bang-Bang, PID...). Possibly getting the LegWay to follow a line while balancing.
Expected progress:
A linefollowing LegWay.
Proposal 2:
Light Follower
Try to build a 2 LEGO cars. One of them will follow second one with source of light. Second could have a predefined route, or it could just be driving around at random. Possibly the light carrying robot, could be remote controlled by bluetooth.
We have found a movie which presents this concept: http://www.youtube.com/watch?v=4jLxJuel9EQ
Materials:
Two nxt's needed.
Light source.
Challenge:
Behaviour of the robot following the light. Breitenberg? Other...?
Possibly following bluetooth beacon instead of light.
Expected progress:
A robot following another robot, that carries a light/a beacon.
Proposal 3:
LEGO Boids
Build a flock of robots, that display emergent flock behaviour.
Materials:
A lot (at least ten) nxt's.
Something to transmit/receive position information (possibly bluetooth).
Challenge:
Getting enough nxt's. Triangulation/navigation.
Expected progress:
Diffucult to say. Depends on the capabilities of bluetooth triangulation.
Proposal 4:
Evolutionary robots
Build a flock of robots, that will learn to drive towards a light source by an evolutionary model inspired by this work on embodied evolution. Experimenting with different fitness models.
Materials:
quite a few nxt's. a strong light source.
Challenge:
Communication between robots, getting enough nxts.
Expected progress:
Reaching behavoir that is better that randomly driving around.
Proposal 5 (this is the one we are going to do):
Reasons for choosing this:
We think the project is funny, and we like the fact that it is interactive. A lot of the other projects, seem too large to complete, or it seems to us that LEGO is not a good medium for building fine mechanics.
Musical robots
Build a robot that plays music. The robot should be interactive, in the sense that a user should be able to tap out rythms, set the tempo and change the pitch of the music, by means of various sensors. Possibly a second robot could be built, that can react to the music played by the first robot.
One might imagine using a touch sensor to tap a rythm. Using the actuators to set tempo (reading the number of ticks pr. second, when the user manually spins the actuator). And setting the pitch of a melody, by using a distance sensor.
Materials:
One - three nxt's:
One or two for grabbing input/playing sounds.
One for reacting on the music produced.
Challenges:
Using the sound class in the nxt. Simulating many tracks playing at once. Analyzing sound (detecting bpm).
Architecture:
We are going to use the lejos platform to program the software, and build the actual robots using LEGO.
We have considered using some external loudspeakers, but we might try to play the music using analog instruments instead (beat by banging on the table, flute by pumping hydralic piston, etc...).
Expected progress:
Playing user-defined music with up to three tracks. Possibly we will build some instruments and try too get the robot to play them.
Thursday, 27 November 2008
Thursday, 6 November 2008
Lesson 8
Date: 06-11-2008
Duration of activity: 2.75 hours
Group members participating: Thomas, Rasmus, Peter
The Goal of the session...: Experiment with LEGO car that exhibits several behaviors
Plan:
The car has 3 different states:
In the java program each state is represented as a daemon thread. It is handy to have these threads as daemon threads because then they die when the main thread dies. Upon creation each thread instance is passed a reference to the behaviour objects, that it must be able to suppress. A behaviour is then suppressed by setting the suppression bool to true. Whenever a behaviour accesses the engines, a check is made to ensure that the behaviour is not suppressed. If it is suppressed, the request for some engine action is ignored.
Drive toward light:
We implemented the drive-toward-light behavior from lesson 7 by using a BreitenbergLightSensor class we made last week. We were discussing how this behavior should interact with the other behaviours. It could either suppress the other behaviors when driving towards light, or it could just drive towards light whenever possible. We opted for the second possibility, because it seems fair that an avoidance behaviour (AvoidFront), should take precedence over the lightseeking behavior. DriveTowardsLight.java and the breitenberg class can be found here along with the rest of the files needed for the SoundCar. We briefly experimented with the car, by holding a flashlight in front of it to make it drive forwards (toward the light) and then waving a hand in front of the sonic sensor. The car did as expected, and fled from the hand, suppressing the drive-toward-light behavior.
Duration of activity: 2.75 hours
Group members participating: Thomas, Rasmus, Peter
The Goal of the session...: Experiment with LEGO car that exhibits several behaviors
Plan:
- We built a car from page 28-30 (with sonic sensor)
- We built program using SoundCar.java, and files available here
- We wrote a report
The car has 3 different states:
- Randomly driving around
- Detecting an obstacle and backing away
- Making sounds
In the java program each state is represented as a daemon thread. It is handy to have these threads as daemon threads because then they die when the main thread dies. Upon creation each thread instance is passed a reference to the behaviour objects, that it must be able to suppress. A behaviour is then suppressed by setting the suppression bool to true. Whenever a behaviour accesses the engines, a check is made to ensure that the behaviour is not suppressed. If it is suppressed, the request for some engine action is ignored.
Drive toward light:
We implemented the drive-toward-light behavior from lesson 7 by using a BreitenbergLightSensor class we made last week. We were discussing how this behavior should interact with the other behaviours. It could either suppress the other behaviors when driving towards light, or it could just drive towards light whenever possible. We opted for the second possibility, because it seems fair that an avoidance behaviour (AvoidFront), should take precedence over the lightseeking behavior. DriveTowardsLight.java and the breitenberg class can be found here along with the rest of the files needed for the SoundCar. We briefly experimented with the car, by holding a flashlight in front of it to make it drive forwards (toward the light) and then waving a hand in front of the sonic sensor. The car did as expected, and fled from the hand, suppressing the drive-toward-light behavior.
Thursday, 30 October 2008
Breitenburg Bots
Date: 30-10-2008
Duration of activity: 2.75 hours
Group members participating: Thomas, Rasmus, Peter
The Goal of the session...: Experiment with Breitenburg robots.
Setup: We built a small car with 3 wheels and 2 light sensors attached at the front. (Reminiscent of the 2 wheeled cars in the picture below).
Experiment:
We connected the sensors as in case 2a above, and just fed the output from the lightsensors directly to the motors.
Purpose:
Test the effects of just forwarding the output, without any form of normalization.
Result:
The values produced by the lightsensors, were barely high enough to get the car moving, let alone show any sort of consistent behaviour.
Experiment:
We tried normalizing the values, before feeding them into the engines. This was done by averaging the max/min values of the sensors and using them in a normalization process ala the one presented during the lecture:
int result = ((t - MIN_LIGHT)* 100) / (MAX_LIGHT - MIN_LIGHT) ;
Purpose:
Stabilize/magnify he bahaviour exhibited, by tailoring the interpretation of the input to some values relevant for the environment we were in.
Result:
The sensors had different sensitivity, which resulted in the car either driving hard left, or hard right and only when subjected to a strong light source.
Experiment:
When normalizing the values, we took in to account the values already seen:
private int MAX_LIGHT = 0;
public int readValue()
{
int t = super.readValue();
if(MIN_LIGHT > t)
MIN_LIGHT = t;
if(MAX_LIGHT < t)
MAX_LIGHT = t;
if(MAX_LIGHT == MIN_LIGHT)
MAX_LIGHT++;
int result = ((t - MIN_LIGHT)* 100) / (MAX_LIGHT - MIN_LIGHT) ;
return result;
}
Purpose:
Enable the sensors to calibrate themselves over time, so that the output values actually hit the entire range betweem 0 and 100 depending on the input.
Result:
The car exhibited the desired behaviour, meaning that it steered toward light sources, but turned away before hitting them.
Experiment:
To try out vehicle 2b.
Purpose:
To get at different behaviour by just changing the wiring of the motors and the sensors.
Result:
As expected the car drove towards the light source when the light source was at a certain distance form the car. And when it got closer the car steared towards the light, instead of away from the light.
Final versions:
http://www.daimi.au.dk/~rusmus/Breitenberg/
Duration of activity: 2.75 hours
Group members participating: Thomas, Rasmus, Peter
The Goal of the session...: Experiment with Breitenburg robots.
Setup: We built a small car with 3 wheels and 2 light sensors attached at the front. (Reminiscent of the 2 wheeled cars in the picture below).
Experiment:
We connected the sensors as in case 2a above, and just fed the output from the lightsensors directly to the motors.
Purpose:
Test the effects of just forwarding the output, without any form of normalization.
Result:
The values produced by the lightsensors, were barely high enough to get the car moving, let alone show any sort of consistent behaviour.
Experiment:
We tried normalizing the values, before feeding them into the engines. This was done by averaging the max/min values of the sensors and using them in a normalization process ala the one presented during the lecture:
int result = ((t - MIN_LIGHT)* 100) / (MAX_LIGHT - MIN_LIGHT) ;
Purpose:
Stabilize/magnify he bahaviour exhibited, by tailoring the interpretation of the input to some values relevant for the environment we were in.
Result:
The sensors had different sensitivity, which resulted in the car either driving hard left, or hard right and only when subjected to a strong light source.
Experiment:
When normalizing the values, we took in to account the values already seen:
private int MIN_LIGHT = 100;
private int MAX_LIGHT = 0;
public int readValue()
{
int t = super.readValue();
if(MIN_LIGHT > t)
MIN_LIGHT = t;
if(MAX_LIGHT < t)
MAX_LIGHT = t;
if(MAX_LIGHT == MIN_LIGHT)
MAX_LIGHT++;
int result = ((t - MIN_LIGHT)* 100) / (MAX_LIGHT - MIN_LIGHT) ;
return result;
}
Purpose:
Enable the sensors to calibrate themselves over time, so that the output values actually hit the entire range betweem 0 and 100 depending on the input.
Result:
The car exhibited the desired behaviour, meaning that it steered toward light sources, but turned away before hitting them.
Experiment:
To try out vehicle 2b.
Purpose:
To get at different behaviour by just changing the wiring of the motors and the sensors.
Result:
As expected the car drove towards the light source when the light source was at a certain distance form the car. And when it got closer the car steared towards the light, instead of away from the light.
Final versions:
http://www.daimi.au.dk/~rusmus/Breitenberg/
Thursday, 2 October 2008
Date: 25-9-2008
Duration of activity: 2.5 hours
Group members participating: Thomas, Rasmus, Peter
The Goal of the session...: Building a Linefollower.
Setup:
We built the 9797 car once again, and loaded Linefollower onto the nxj. (Linefollower uses BlackWhiteSensor).
Experiments:
Duration of activity: 2.5 hours
Group members participating: Thomas, Rasmus, Peter
The Goal of the session...: Building a Linefollower.
Setup:
We built the 9797 car once again, and loaded Linefollower onto the nxj. (Linefollower uses BlackWhiteSensor).
Experiments:
BlackWhiteSensor:
Because we already tested the lightsensor (week 1) we decided to skip straight to consturcting the ColorSensorClass.
ColorSensor:
Our first attempt at a colorsensor just sampled values for black, white and blue, and when asked which color it was on, it calculated the difference between a reading and these values, returning the color that had the least difference. The problem with this approach, was that whenever a blue was reported, the car stopped, because it thought it had reached the goalzone.
We modified the colorsensor, so you had to ask for a boolean on each color and we modified the car, so it counted the number of times a blue was reported. The car did not stop until 10 blues had been reported in a row. (A false reset the count).
Here are the final versions of
Thursday, 25 September 2008
Excercise 4
Date: 25-9-2008
Duration of activity: 3 hours
Group members participating: Thomas, Rasmus
The Goal of the session...: Building a two-wheel car/robot that can keep its balance.
Setup:
We built the NXTWay robot suggested in the excercise notes (http://www.philohome.com/nxtway/nxtway.htm)
Experiments:
Getting to know the hardware:
We started out by loading a Bang-Bang controller onto the NXTWay and running it. The results were not very impressive. The problem was the way the power to the motors were controlled. Either they were full on or off, which resulted in highly erratic behaviour and, ultimately (but quickly), the NXTWay falling over. Because this was expected, we didn't spend a lot of time analysing this. Instead we moved on to a more feasible control mechanism. (The Bang-Bang Controller ced can be found here: http://www.daimi.au.dk/~rusmus/SejwayBad.java).
Moving on:
We now loaded a PID controller onto the NXTWay, and tried it out. We ran into a problem with the sensor being able to move, which gave some rather unstable readings, resulting in the NXTWay falling down. It turned out, that this was due to a design error, so we moved the sensor higher up and made sure it was fixed properly.
Getting scientific...:
Purpose:
Analysing the readouts from the lightsensor, in order to better tweak the software parameters.
What we did:
Started up the program, and tilted the NXTWay as far forward as possible. We then read the sensorreading of the display and tilted it a back a bit. We continued in this way until the readings no longer changed perceptibly.
On the table:
- Forward position: 559
- Upright position: 513
- Slightly backward position: 472
- Backward position: 458
On the floor (blue):
- Forward position: 417
- Upright position: 397
- Slightly backward position: 369
- Backward position: 363
On white floor:
- Forward position: 573
- Upright position: 535
- Slightly backward position: 499
- Backward position: 489
We plotted this:
The three most important points on each of the series, are the first three. This is because the NXTWay uses these readings to determine which way it is tilting, and consequently they are used to control the motors. On the table and the white surface, the readings are fairly similar. There is a nice difference between the three most significant points, making them well suited for balancing on.
The floor on the other hand the curve is flatter. Beacause of this the NXTWay should in theory have a harder time balancing on this surface.
We tested this hypothesis and indeed the balancing capabilities of the car on the blue floor were clearly poorer.
Further experiments:
We would have liked to conduct a number of other experiments, but we ran out of time. We briefly tried adding a "tower" on top of the NXTWay, in order to move the center of gravity, but from the little we tried, we could not detect any significant improvement.
We would also have liked to tweak the code in some way, in order to adjust the NXTWay to the environment we were testing in. It is our firm belief, that with some parameter tweaking and on the right surface, the NXTWay can balance quite effieciently.
Duration of activity: 3 hours
Group members participating: Thomas, Rasmus
The Goal of the session...: Building a two-wheel car/robot that can keep its balance.
Setup:
We built the NXTWay robot suggested in the excercise notes (http://www.philohome.com/nxtway/nxtway.htm)
Experiments:
Getting to know the hardware:
We started out by loading a Bang-Bang controller onto the NXTWay and running it. The results were not very impressive. The problem was the way the power to the motors were controlled. Either they were full on or off, which resulted in highly erratic behaviour and, ultimately (but quickly), the NXTWay falling over. Because this was expected, we didn't spend a lot of time analysing this. Instead we moved on to a more feasible control mechanism. (The Bang-Bang Controller ced can be found here: http://www.daimi.au.dk/~rusmus/SejwayBad.java).
Moving on:
We now loaded a PID controller onto the NXTWay, and tried it out. We ran into a problem with the sensor being able to move, which gave some rather unstable readings, resulting in the NXTWay falling down. It turned out, that this was due to a design error, so we moved the sensor higher up and made sure it was fixed properly.
Getting scientific...:
Purpose:
Analysing the readouts from the lightsensor, in order to better tweak the software parameters.
What we did:
Started up the program, and tilted the NXTWay as far forward as possible. We then read the sensorreading of the display and tilted it a back a bit. We continued in this way until the readings no longer changed perceptibly.
On the table:
- Forward position: 559
- Upright position: 513
- Slightly backward position: 472
- Backward position: 458
On the floor (blue):
- Forward position: 417
- Upright position: 397
- Slightly backward position: 369
- Backward position: 363
On white floor:
- Forward position: 573
- Upright position: 535
- Slightly backward position: 499
- Backward position: 489
We plotted this:
The three most important points on each of the series, are the first three. This is because the NXTWay uses these readings to determine which way it is tilting, and consequently they are used to control the motors. On the table and the white surface, the readings are fairly similar. There is a nice difference between the three most significant points, making them well suited for balancing on.
The floor on the other hand the curve is flatter. Beacause of this the NXTWay should in theory have a harder time balancing on this surface.
We tested this hypothesis and indeed the balancing capabilities of the car on the blue floor were clearly poorer.
Further experiments:
We would have liked to conduct a number of other experiments, but we ran out of time. We briefly tried adding a "tower" on top of the NXTWay, in order to move the center of gravity, but from the little we tried, we could not detect any significant improvement.
We would also have liked to tweak the code in some way, in order to adjust the NXTWay to the environment we were testing in. It is our firm belief, that with some parameter tweaking and on the right surface, the NXTWay can balance quite effieciently.
Thursday, 18 September 2008
Exercise 3
Date: 18-9-2008
The Goal of the session...: Experimenting with the microphone sensor and making it detect claps.
Test of the sound sensor
We wrote a program similiar to SonicSensorTest, which just writes the intensity of the sound (in percentage) measured on the NXT display. Clapping very close to the microphone gives a reading of almost 100 as expected. A clap made several meters away from the device will yield a clear reading as well. Speaking at normal conversation level about 30cm away from the sensor will give readings at about 20%. We checked the ambient sound level as well and it was at 3-5%.
Sound controlled car
Behaviour of the car when running SoundCrtCar.java: The car can run in four different states: forward, right, left and stop. The transistion between the states is triggered by a loud noise. So at first the car drives forward, after detecting the first loud noise it goes right, after the next it goes left, etc.
Plot of our claps
The graph shows the data collected for one clap. We've changed the sampling rate from 5 to 1 msec to get a more accurate sample. Our "signature" of a clap is a signal going from 0% to almost 100% percent in less than 10 msecs. During the next 200 msecs it fades back to the base value of 3-5%. So this description of a clap more or less fits Toledo's. The SoundCtrCar program uses a threshold of 90%, so this program would detect a clap like the opne above. But it would also detect any other loud sound. So the challenge is to write a program that can detect this specific signature of the clap.
Based on our measured clap data we've made a small program called ClapDetecter.java. It tries to detect a clap signal based on the simple three-phase characteristic described above. It does not work every time. But we expect that further fiddling with the border values could fix that.
Duration of activity: 3 hours
Group members participating: Peter, Thomas, Rasmus
The Goal of the session...: Experimenting with the microphone sensor and making it detect claps.
Test of the sound sensor
We wrote a program similiar to SonicSensorTest, which just writes the intensity of the sound (in percentage) measured on the NXT display. Clapping very close to the microphone gives a reading of almost 100 as expected. A clap made several meters away from the device will yield a clear reading as well. Speaking at normal conversation level about 30cm away from the sensor will give readings at about 20%. We checked the ambient sound level as well and it was at 3-5%.
Sound controlled car
Behaviour of the car when running SoundCrtCar.java: The car can run in four different states: forward, right, left and stop. The transistion between the states is triggered by a loud noise. So at first the car drives forward, after detecting the first loud noise it goes right, after the next it goes left, etc.
Plot of our claps
The graph shows the data collected for one clap. We've changed the sampling rate from 5 to 1 msec to get a more accurate sample. Our "signature" of a clap is a signal going from 0% to almost 100% percent in less than 10 msecs. During the next 200 msecs it fades back to the base value of 3-5%. So this description of a clap more or less fits Toledo's. The SoundCtrCar program uses a threshold of 90%, so this program would detect a clap like the opne above. But it would also detect any other loud sound. So the challenge is to write a program that can detect this specific signature of the clap.
Based on our measured clap data we've made a small program called ClapDetecter.java. It tries to detect a clap signal based on the simple three-phase characteristic described above. It does not work every time. But we expect that further fiddling with the border values could fix that.
Thursday, 11 September 2008
Embedded systems week 2
Date: 11-9-2008
Duration of activity: 3 hours
Group members participating: Peter, Thomas, Rasmus
The Goal of the session...: Playing with sensors. In particular the UltraSonic Sensor.
Experiments...:
SensorTest:
We uploaded the SonicSensorTest program and moved the car around a bit.
Result:
The sensor seemed to measure pretty accurately, but when the distance exceded 2m, the sensor just read 255... It seems that with the simple program, the sensor operates best within a range from 10cm to 180cm. The fact that the readings become unstable around 2m would indicate that if the microphone does not hear the ping within 5ms it just reads 255. ((340,29 m/s )/ 1000 ms/s) = 0,34 m/ms; 5 ms *0,34 m/ms = 1,8m (approx)). This might be because the sound loses speed from being reflected. One might investigate this manually, by setting the sensor in ping mode, and printing the time betwen the ping and the echo (We tried doing this, but it seems that the hardware can't keep up). The measurements in the graph below were made on the floor, which seems to have had a detrimental effect on the range (echoes of the floor most probably).
TrackerBeam:
Playing around with the Tracker program.
Behaviour:
The car drives forward, until it senses an obstacle, at which point it will reverse, until it senses that the obstacle is no longer in the way. Sometimes it got stuck going back and forth at the edge of the allowed distance and it banged into a wall because the angle was too steep, so it didn't sense the obstacle. We fiddled with the constants a bit, but we mostly made the car unstable and choppy in the stops.
This type of controller is called a closed-loop-controller (Wikipedia: "A closed-loop controller uses feedback to control states or outputs of a dynamical system. Its name comes from the information path in the system: process inputs (e.g. voltage applied to an electric motor) have an effect on the process outputs (e.g. velocity or torque of the motor), which is measured with sensors and processed by the controller; the result (the control signal) is used as input to the process, closing the loop.").
WallFollower:
Sadly we didn't have time to try out the wallfollower. We looked over the code and tried to find out what it was doing, but we didn't have the time to translate it into java...
Subscribe to:
Posts (Atom)