Starting up:
Participants: Johan & Jakob
Date: 6/10-2010
Duration: 4 Hours
Goal: Solve the Alishan Train Track as fast as possible
Different Strategies
As the track is well-defined, the robot has no need to actually reads the course and react to the sensor inputs.
Considering this and the fact that the score is only determined by the best track, and not the robots ability to perform at any given time, the best approach is probably to just hardcode the track and optimise for speed.
This strategy seems to be tedious and not a very interesting approach.
Another category of strategies are those that try to read the black line with the lightsensors and navigate the course based on this. We chose to pick this "inferior" approach due to seeing another team run the track much faster than we ever expect to be able to, and if we can't be best, we can possible make a more clever solution.
Staying on course
This particular track presents the robot with two specific challenges other that the more or less trivial linefollowing issue. First the track is different from normal line following track by having a spike that goes to the edge of the track on each of the two plateaus, this means that the standard procedure for following the line with two sensor cannot be used as the sensors would also detect this spike, which is not desirable when we want to follow the line, and not the spike. As if this is not complicating the matter enough the field is also no longer just a flat plane, but rather a three dimensional course. Due to the placement of the light sensors, every time the robot climbs onto one of the plateaus the robot tilts and thusly exposes the light sensors to less reflected light, and this complicates the process further.
One is better than two?
The way we approached these challenges was to build a standard 5-minute bot from nxtprograms.com and mounted two lightsensors on this chassis. Our strategy was then to use only one of the sensors at any given time for following the line, using the other only to keep track of where we are by counting the number of times we have seen something dark ( either the spike or the tilt of the robot ). Then after we have passed the spikes we can switch which sensor follows the line and which keeps track of where we are. This way we avoid the problem with following the line with two sensors. This leaves us with a quite inefficient bang-bang line follower, which time allowing could be substituted with a better PID line-follower.
We said we wouldn't hardcode it, but..
Instead of hardcoding the whole process we hardcoded a sequence of behaviours. Thus start in state 1 where we have not seen anything yet, count up until we switch, and so on. This approach was simple and worked in most cases, albeit slowly. The trouble with this is that the sensor sometimes registered dark while following the line in a non-tricky area, this of course might sabotage the clever partition of the track into distinct parts, thus switching sensor behaviour too early or not being ready to detect the endzones when entering them.
We were able to complete the track most times and are as such content with the result.
Some might say we got the best of both worlds, the simplicity and effectiveness of the hardcoded approach combined with the resiliency of the algorithmic approach.
We still had to tinker with the tedious count values and were not able to complete the track everytime, so evil tongues might say we got the drawbacks of both worlds, the tediousness of hardcoding it and the complexity of solving the problem algorithmically.
Thursday, 28 October 2010
Thursday, 7 October 2010
The first steps
Starting up:
Participants: Johan & Jakob
Date: 30/9-2010
Duration: 3 Hours
Goal: Construct a segway and make it balance.
The Inner Ear
As the standard Lego kits does not contain a gyroscope sensor to monitor the robots tilt, we took the inspiration from the exercise sheet and used the light sensor to determine in which direction the robot is currently falling.
This brings all the usual trials and tribulations of using the light sensor, susceptibility to the environment, both external lightsources as well as the texture and color of the surface on which we tried to make the Failbot balance.
Knowing which way is up
Similarly to the code handed out we start with an initial calibration, where we obtain the light sensor value representing the desired state, the robot in balance. When the robot tilts the light sensor moves closer or further away from the surface, and we can thusly use this value to compute which way we want the motors to turn.
Heavily inspired by the handout we used a similar PID scheme to avoid overshooting too much.
Standing Tall
After a bunch of failures of epic proportions, mostly the Failbot seemed to make an exhaustive search through the space of possible ways to fall, tilt and run off tables, we finally got the Failbot to keep balancing a few seconds, there was much rejoicing. One very pratical issue is that it has been very hard to set a prober initial state due to the fact that poorly constructed lego robots might not be very well balanced. The robot is programmed such that it cannot balance better than the initial state it is supplied with. An improvement could be using the gyroscope sensor that can be obtained, beyond being a better sensor for the task, it also gives the possibility of a decent calibration. If the robot is placed lying down, one could use this value to obtain a initial state ( perpendicular to this state ) and balance with that in mind. If one used another light sensor on the opposite side of the robot, one might also be able to better balance.
Participants: Johan & Jakob
Date: 30/9-2010
Duration: 3 Hours
Goal: Construct a segway and make it balance.
The Inner Ear
As the standard Lego kits does not contain a gyroscope sensor to monitor the robots tilt, we took the inspiration from the exercise sheet and used the light sensor to determine in which direction the robot is currently falling.
This brings all the usual trials and tribulations of using the light sensor, susceptibility to the environment, both external lightsources as well as the texture and color of the surface on which we tried to make the Failbot balance.
Knowing which way is up
Similarly to the code handed out we start with an initial calibration, where we obtain the light sensor value representing the desired state, the robot in balance. When the robot tilts the light sensor moves closer or further away from the surface, and we can thusly use this value to compute which way we want the motors to turn.
Heavily inspired by the handout we used a similar PID scheme to avoid overshooting too much.
Standing Tall
After a bunch of failures of epic proportions, mostly the Failbot seemed to make an exhaustive search through the space of possible ways to fall, tilt and run off tables, we finally got the Failbot to keep balancing a few seconds, there was much rejoicing. One very pratical issue is that it has been very hard to set a prober initial state due to the fact that poorly constructed lego robots might not be very well balanced. The robot is programmed such that it cannot balance better than the initial state it is supplied with. An improvement could be using the gyroscope sensor that can be obtained, beyond being a better sensor for the task, it also gives the possibility of a decent calibration. If the robot is placed lying down, one could use this value to obtain a initial state ( perpendicular to this state ) and balance with that in mind. If one used another light sensor on the opposite side of the robot, one might also be able to better balance.
Friday, 17 September 2010
Working with Sound
Starting up:
Participants: Johan & Jakob
Date: 16/9-2010
Duration: 3 Hours
Goal: Attach the Sound sensor to Failbot 9797 and test the sensor as described in the given exercise.
Building the robot was not a challenge, other than locating the correct blocks in the box.
Analyzing the input
After creating a basic program similar to SonicSensorTest.java, but with respect to the sound picked up by the sound sensor, we tested the sensor by producing various noises at different distances and angles.
Increasing the distances did lower the readings as one would expect, the farther away the lower the readings, however the angle from which the sound was coming from had a much bigger impact. A sound produced for behind the sensor was much lower than a sound produced right in front of the sensor.
Afterwards we tested the DataLogger, which worked as expected.
Sound Controlled Car
We uploaded the program to the Failbot 9797 and ran it. It started to drive as expected and responded to various sounds by driving turning each way and then stopping. Clapping was the least effective means of controlling it. Claps had to be very loud and preferably in front of the car for it to register. Johan tried making a high pitched yelping sound, which was very effective and worked almost every time, this appeared to be the best way of controlling it.
Turning it off was a challenge until we read the code and realized why. We fixed this by using a ButtonListener which calls System.exit() if the escape button is pushed. Very effective.
Clap Controlled Car
We discussed ways of analyzing the input from the sensor to determine whether a clap had been made. In the end we decided just to try to implement it by three if-sentences to determine whether the data corresponded to the pattern described in the exercises. This technique proved to be very effective - more effective than we both expected - and it was able to detect claps almost perfectly, while also filtering out other sounds such as the yelping sound which was so effective earlier.
Conclusions
The clap pattern described in the exercises proved to be very accurate and the simplistic algorithm implemented was very effective. By experiments and data logging it would probably be possible to tweak the constants to get less thread sleeping thereby enabling the Failbot to register more claps per minute, however we didn't find time for this.
Participants: Johan & Jakob
Date: 16/9-2010
Duration: 3 Hours
Goal: Attach the Sound sensor to Failbot 9797 and test the sensor as described in the given exercise.
Building the robot was not a challenge, other than locating the correct blocks in the box.
Analyzing the input
After creating a basic program similar to SonicSensorTest.java, but with respect to the sound picked up by the sound sensor, we tested the sensor by producing various noises at different distances and angles.
Increasing the distances did lower the readings as one would expect, the farther away the lower the readings, however the angle from which the sound was coming from had a much bigger impact. A sound produced for behind the sensor was much lower than a sound produced right in front of the sensor.
Afterwards we tested the DataLogger, which worked as expected.
Sound Controlled Car
We uploaded the program to the Failbot 9797 and ran it. It started to drive as expected and responded to various sounds by driving turning each way and then stopping. Clapping was the least effective means of controlling it. Claps had to be very loud and preferably in front of the car for it to register. Johan tried making a high pitched yelping sound, which was very effective and worked almost every time, this appeared to be the best way of controlling it.
Turning it off was a challenge until we read the code and realized why. We fixed this by using a ButtonListener which calls System.exit() if the escape button is pushed. Very effective.
Clap Controlled Car
We discussed ways of analyzing the input from the sensor to determine whether a clap had been made. In the end we decided just to try to implement it by three if-sentences to determine whether the data corresponded to the pattern described in the exercises. This technique proved to be very effective - more effective than we both expected - and it was able to detect claps almost perfectly, while also filtering out other sounds such as the yelping sound which was so effective earlier.
Conclusions
The clap pattern described in the exercises proved to be very accurate and the simplistic algorithm implemented was very effective. By experiments and data logging it would probably be possible to tweak the constants to get less thread sleeping thereby enabling the Failbot to register more claps per minute, however we didn't find time for this.
Friday, 10 September 2010
Depth Perception
Starting up:
Participants: Johan & Jakob
Date: 9/9-2010
Duration: 2 Hours
Goal: Attach the UltraSonic sensor to the Failbot 9797, then test the UltraSonic sensor with regard to the exercise problems.
Bodily Enhancement
The sensor rig was assembled with care and without problems much larger than not being able to easily locate the required blocks. The Failbot was provided with the program SonicSensorTest.java and placed at different distances.
We noticed a peculiar behaviour with regards to the measurements reported by the UltraSonic Sensor.
First of all, even though both object and rig remained stationary the measurements did not remain a stable value.
This might be attributed to the fact that the sensor reports the distance in centimeters and the distance might be close to the threshold between the values being reported.
Snappy Response
For the current exercise the sample rate for the UltraSonic sensor is increased to test whether the fact that a 300 ms minimum delay between samplings has been removed from the current release of LeJos.
We lowered the sample interval gradually, but did not notice any dramatic increase in the performance of the sensor.
Softcore Issues
The sensor performed very differently depending on which material we tried to bounce the ultrasonic signal off.
Clothes and other materials with sound absorbing properties gave the sensor very hard times.
Also the angle between the sensor and the objects surface ( e.g the surface of a wall ) exerted heavy influence on the results as the echoes did not return to the sensor. The sensors error also seemed very high 5-10 centimeters, which leads to the sensor being very demanding to use.
Tractor Beam ... Eh. Tracker Beam
The Failbot was gifted with the program Tracker.java and tried when running to keep a certain distance to any object in front. When no object was detected it sped full speed forward. This had the unintended effect of having it run into objects being introduced so close in front of it that the sensor reports the maximum distance.
Conclusions
The days conclusions are mostly centered around the unreliability of the ultrasonic sensor.
So far we have seen no pattern in the error of the sensor, and this could be examined further.
Participants: Johan & Jakob
Date: 9/9-2010
Duration: 2 Hours
Goal: Attach the UltraSonic sensor to the Failbot 9797, then test the UltraSonic sensor with regard to the exercise problems.
Bodily Enhancement
The sensor rig was assembled with care and without problems much larger than not being able to easily locate the required blocks. The Failbot was provided with the program SonicSensorTest.java and placed at different distances.
We noticed a peculiar behaviour with regards to the measurements reported by the UltraSonic Sensor.
First of all, even though both object and rig remained stationary the measurements did not remain a stable value.
This might be attributed to the fact that the sensor reports the distance in centimeters and the distance might be close to the threshold between the values being reported.
Snappy Response
For the current exercise the sample rate for the UltraSonic sensor is increased to test whether the fact that a 300 ms minimum delay between samplings has been removed from the current release of LeJos.
We lowered the sample interval gradually, but did not notice any dramatic increase in the performance of the sensor.
Softcore Issues
The sensor performed very differently depending on which material we tried to bounce the ultrasonic signal off.
Clothes and other materials with sound absorbing properties gave the sensor very hard times.
Also the angle between the sensor and the objects surface ( e.g the surface of a wall ) exerted heavy influence on the results as the echoes did not return to the sensor. The sensors error also seemed very high 5-10 centimeters, which leads to the sensor being very demanding to use.
Tractor Beam ... Eh. Tracker Beam
The Failbot was gifted with the program Tracker.java and tried when running to keep a certain distance to any object in front. When no object was detected it sped full speed forward. This had the unintended effect of having it run into objects being introduced so close in front of it that the sensor reports the maximum distance.
Conclusions
The days conclusions are mostly centered around the unreliability of the ultrasonic sensor.
So far we have seen no pattern in the error of the sensor, and this could be examined further.
Thursday, 2 September 2010
Report from labsession 1
Starting up
Participants:
Johan & Jacob
2 hours, 2nd september 2010
task: http://legolab.daimi.au.dk/DigitalControl.dir/NXT/Lesson1.dir/Lesson.html
Without any huge problems "The Failbot 9797" was built.
LeJOS was downloaded, and after having downloaded the stand-alone NXT driver from lego.com, nxjflashg, handled the firmware flashing expertly.
The first basic intelligence
Our robot started with no means of interacting with or interpreting the world, so we set out to empower it.
We downloaded the java code posted on the exercise sheet, compiled it and transferred it via bluetooth to the failbot.
The first test run on the black line was a succes. The failbot climbed steadily up the ramp, following the line nicely.
Now with our senses enable we generated the following table of light reflected by surfaces with and without the floodlight turned on:
This table clearly shows that a decent threshold value can be obtained from the average of the black and white values. It also shows that the reflected light is almost necessary to get enough variation between light and dark areas allowing us to consistently determine which type of surface we are sampling from.
Reaction times:
Having established a bunch of values and a base robot actually capable of doing something we went forward meddling with the sample frequency to determine what effect it has.
Starting with a sample interval of ~10 ms ( determined by Thread.sleep(10)),
The Failbot climbed up along the black line, without ever being close to crossing it.
Lowering the interval to 5 and 1 ms, respectively did not yield any visible alteration in the performance of The Failbot. Perhaps multiple runs should be timed to see whether the sample frequency has a negative effect when lowered.
Increasing the sample interval to 50 ms led to bigger arcs in the movement of The Failbot when following the line. The Failbot did still perform nicely with regards to stay near the line.
At 100 ms sample intervals The Failbot starts to fail. It crosses the black line without detecting it quite often, if put close to the line and quite parallel to it, it stays with the line for quite a long time though.
For a sample interval of 500 and 1000 miliseconds the robot mostly spins around, and sometimes change direction momentarily when crossing the black line coincidentally with a sample happening, this is not happening that often though.
Cluttered Minds
Now we toyed a bit with the memory part of the brain. Specifically we passed string literals to the LCD.drawString() method, and compared how much clutter this introduced to the memory to the amount of clutter when using predeclared constant strings. When the constant strings were used the amount of free memory did not change while the program was running, quite contrary to this, when string literals were used, the memory available dwindled away at quite a fast rate. This proceeded until the garbage collector ran and freed a bunch of memory, that then again started dwindling away.
This could lead to problems when working with a robot requiring real-time performance.
On such a small computer as the NXT the act of running the garbage collector might have a notable effect on the performance of the unit.
Conclusions
Perhaps more diverse results would come from testing the robot with varying sample times on both the straight line and the more winding road. As this might lead to different conditions emphasizing the strengths and weaknesses of the different sample frequencies.
Also a further experiment would be to time the runs for different sample times, and also motor speeds to find the optimum sample time to solve a given problem.
Participants:
Johan & Jacob
2 hours, 2nd september 2010
task: http://legolab.daimi.au.dk/DigitalControl.dir/NXT/Lesson1.dir/Lesson.html
Without any huge problems "The Failbot 9797" was built.
LeJOS was downloaded, and after having downloaded the stand-alone NXT driver from lego.com, nxjflashg, handled the firmware flashing expertly.
The first basic intelligence
Our robot started with no means of interacting with or interpreting the world, so we set out to empower it.
We downloaded the java code posted on the exercise sheet, compiled it and transferred it via bluetooth to the failbot.
The first test run on the black line was a succes. The failbot climbed steadily up the ramp, following the line nicely.
Now with our senses enable we generated the following table of light reflected by surfaces with and without the floodlight turned on:
| Place: | Floodlight on: | Floodlight off |
| Wooden table | 53 | 23 |
| Bordeux chair | 37 | 20 |
| Grey laminate floor | 46 | 16 |
| Whiteboard | 54 | 29 |
| Black cabinet | 32 | 15 |
| Blue laminate floor | 38 | 28 |
| Blue carpet | 34 | 27 |
| Green end zone | 35 | 26 |
This table clearly shows that a decent threshold value can be obtained from the average of the black and white values. It also shows that the reflected light is almost necessary to get enough variation between light and dark areas allowing us to consistently determine which type of surface we are sampling from.
Reaction times:
Having established a bunch of values and a base robot actually capable of doing something we went forward meddling with the sample frequency to determine what effect it has.
Starting with a sample interval of ~10 ms ( determined by Thread.sleep(10)),
The Failbot climbed up along the black line, without ever being close to crossing it.
Lowering the interval to 5 and 1 ms, respectively did not yield any visible alteration in the performance of The Failbot. Perhaps multiple runs should be timed to see whether the sample frequency has a negative effect when lowered.
Increasing the sample interval to 50 ms led to bigger arcs in the movement of The Failbot when following the line. The Failbot did still perform nicely with regards to stay near the line.
At 100 ms sample intervals The Failbot starts to fail. It crosses the black line without detecting it quite often, if put close to the line and quite parallel to it, it stays with the line for quite a long time though.
For a sample interval of 500 and 1000 miliseconds the robot mostly spins around, and sometimes change direction momentarily when crossing the black line coincidentally with a sample happening, this is not happening that often though.
Cluttered Minds
Now we toyed a bit with the memory part of the brain. Specifically we passed string literals to the LCD.drawString() method, and compared how much clutter this introduced to the memory to the amount of clutter when using predeclared constant strings. When the constant strings were used the amount of free memory did not change while the program was running, quite contrary to this, when string literals were used, the memory available dwindled away at quite a fast rate. This proceeded until the garbage collector ran and freed a bunch of memory, that then again started dwindling away.
This could lead to problems when working with a robot requiring real-time performance.
On such a small computer as the NXT the act of running the garbage collector might have a notable effect on the performance of the unit.
Conclusions
Perhaps more diverse results would come from testing the robot with varying sample times on both the straight line and the more winding road. As this might lead to different conditions emphasizing the strengths and weaknesses of the different sample frequencies.
Also a further experiment would be to time the runs for different sample times, and also motor speeds to find the optimum sample time to solve a given problem.
Welcome
Welcome to the blog of the failbot.
Here the experiences, successes and failures of our victim in the Embeded Systems course at the computer science department of Aarhus Universtity, will be shared.
What will our innocent LEGO Mindstorms NXT be put through? Only time will tell.
Follow its adventures here!
Here the experiences, successes and failures of our victim in the Embeded Systems course at the computer science department of Aarhus Universtity, will be shared.
What will our innocent LEGO Mindstorms NXT be put through? Only time will tell.
Follow its adventures here!
Subscribe to:
Posts (Atom)