Lab 11

At the end of the labsession you have chosen a project and you have discussed at least two alternative projects. The lab report from this labsession should include:

list of projects considered with a short description of each, e.g. a description could be:"robot that can dry wet spots on the floor during a handball match".

- Navigation spin off
Robots could look for each other using only sound sensors. When all are found they should position them selves in a row and synchronize their sounds to be able to play a short symphony together.

- Legway spin off
build a two-legged walking robot with a custom build gyro

- Interactive Robot Games
Pacman



for each project describe the hardware/software platform and software architecture of each component.
- Symphony
Software
PC bluetooth monitor software for us to be able to see what the hell the robots are doing - especially when synchronizing. This will help us debug

Awesome lejos software

Hardware
Four NXT's
Four Ultra sounds sensors
Four microphones

- Legway

Hardware
Three to five motors
One NXT
Lots of lego

- Interactive Robot Games
Software
Control software for pacman which communicates via bluetooth


Hardware
Cameras for positioning
Five NXT (four enemies and one pacman)
Computers for sending
Four Ultra sounds sensors


try to point out the most difficult problems to be solved in each project, e.g. for the floorcleaner robot it is difficult to figure out when to stop cleaning.
- Symphony
Synchronizing
Finding each other using only sound in a noisy environment

- Legway
Ballancing
Turning
Construction

- Robot games
Positioning and movement
AI for enemies
Bluetooth communication


for each project describe what you would expect to be able to present at the end of the project period.

- Symphony
At the end of the project four robots should be able to be positioned randomly in a room (it might have to be a quiet environment). Thereafter they should be able to find each other and group. Position them selves in a row and synchronize with each other for thereafter to be able to play a short symphony

- Legway
At the presentation we should have a robot which can walk using only two legs and balance. We might have a robot which can turn corners.

- Pacman
We will be able to play pacman using a computer as a controller and the floor as a playing field.

Lab 10

Er der en der gider uploade lab 10 rapporten?

Lab 9

Here's a link to our Lab9 report: lab9_report_fourembeddednerds.pdf

Lab 8

Here's a link to our Lab8 report: lab8_report_fourembeddednerds.pdf

Lesson 4

Self-balancing robot

In this session we tried to build a self-balancing LEGO robot, using the original Steve Hassenplug's Legway, Philippe Hurbain's NXTway, and Brian Bagnall's balancing robot as inspirations.

The robot is standing on two wheels as a Segway, and must try to reach a stable position, by measuring the distance from the light sensor (see the picture) to the floor.

To perform this we used the PID-controller 'Sejway' written by Brian Bagnall, which computes the power to inject into the motors by a combination of a proportional error, an integrative error and a derivative error. As the code was already written, the most difficult part was to find the good settings for the offset and the P-, I- and D-coefficients.

Interactive menu.

In order to make the experiments easier, we made all those settings interactively configurable, using the NXT's buttons and screen. Then we could modify the settings while experimenting, without reloading the program each time. For a smooth usage, a long push on the left or right button makes the values change continuously. As this interactive menu is managed by a class listening all the buttons of the NXT, the program was first not stoppable anymore. We fixed this by making a long push (>1s) on the grey button stop the program.

After many trials, we managed to keep the robot standing 5s... impressive!

Lesson 3

Data Logger

Data was logged from the microphone and plotted in a chart using Excel:

Chart showing noise

Sound Controlled Car

The car moves based on sound meaning that when a noise is made the car switches between the following driving modes:

• Forward
• Right
• Left
• Stop

This results in a car moving a bit odd. The way the program makes sure that random background noise doesn't result in change of direction is by having a minimum thresshold. Only if the dB level of the sound is above 90 a change will occur. 

Clap Controlled Car

In the last part of the Lesson, we experimented with implementing the SIvan Toledo algorithm for detecting a "clap". He described a clap as a sequence of key characteristics that must be met within a certain timeframe of each other. Specifically a clap is instantiated with a "low-amplitude" sample of below 50, followed by a very-high amplitude sample of at least 85 within 25 ms of the instantiation and followed by a low-sample below 50 within another 250 ms of the high amplitude. In order to filter out noise from potential instantiations of a clap, we used the data collected from the second part to determine a noise level threshold, which we determined to be 30 or below. Using this knowledge, we ignore all samples below this value when listening for a clap instantiation, i.e. to instantiate a clap we listen for a sample between ]30,50]. Because this algorithm is very time sensitive, we maxed out the sampling rate at 3ms interval sampling. One thing we experienced with this alternate way of detecting a clap, is that it is a bit more sensitive to the actual sound of the clap, we needed to clap in a certain way for it to detect it as a clap. It actually seemed more sensitive to snapping your fingers than the common clap, we experienced that our claps needed to be very high pitched, short and loud. We expect that we would have been able to work out the quirks and inaccuracies given more time to tweak the individual thresholds, timeouts etc. But all in all, it seems to be more picky about the exact sound of the clap, but also more resistant against other loud noises.

Lesson 2

For our second lesson we were to learn how to use the ultrasonic sensor for the NXT.

To that end the first part consisted of uploading a testing program for the sensor, which verified that the sensor was actually operational.

Tracker

Thereafter we uploaded a Tracker program demonstrating the use of said sensor. It is a reactive program, that causes the car to approach an object in range of the ultrasonic sensor until the distance to it is reduced to 35cm. Seeing no object in range it will drive forwards. If the object is closer than 35cm the car will back up. The car will however not at any point stand still.

Wall follower

The core of our second lesson was to program the car to follow a wall. We achieved this by using the tracker program as a basis. We ended up trying two different methods of implementation.

Both implementations work on the principle of letting the car constantly move forward while adjusting the power to the left and right wheels, depending on the correction (if any) to be made.

The first implementation involved adding a threshold (error margin) constant which let the car travel straight for a while before making a correction to the error that has been accumulating by not travelling parallel to the wall.

We did this after learning from lesson 1 and the results of other students efforts during the lesson, that correcting an error instantly results in a jagged and inefficient movement pattern.

Besides this and tweaking (mostly via trial and error) some other constants like the desired distance to the wall and the extent of the force with which an error was corrected, no other significant changes were made to the tracker program.

We were pleased to see that this implementation actually worked quite well and moved very efficiently along the wall.

In an effort to make the wall following routine more concise and allowing the car to correct different magnitudes of errors with an appropriate response, we implemented another solution based on a different principle.

This time the car would constantly correct its distance to the wall by adjusting the power to the wheels based on the square root of the error from the desired distance to the wall. After some erratic results and obtaining the insight that a form of threshold was still necessary we managed to make this solution work as well.

The primary objective behind our second attempt was to try a different and more implicit approach to allow the car to turn around corners, since implementing that behavior in the former approach would mean a lot of tweaking or the implementation of a new subroutine just for that purpose.

Unfortunately we did not manage to make either of these programs capable of turning around neither inside nor outside corners.

We found that our first solution worked better than the second one, although we suspect that we might have chosen the wrong function for correcting the error in the second one.

Comparison of NCQ implementation

Philippe Hurbains NCQ implementation of the wall follower uses the three state algorithm, which turns hard (read: in place), when it is too close to the wall and shallow when only a minor correction is needed.