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.

Exercise 3

Date: 18-9-2008

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.

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...

Embedded systems week 1

Date: 4-9-2008
Duration of activity: 3 hours
Group members participating: Peter, Thomas, Rasmus

The Goal of the session...:
Familiarizied ourselves with the nxj and the contents of the lego boxes.

Experiments...:
We built the car suggested in the schedule for week 1 and played around with the LineFollower class, in an attempt to make the car go faster. These attempts were mostly futile seeing as they generally resulted in the car going of the track. In general our strategy was to try and make the turns more gradual, in order to make the . Unfortunately this resulted in the car turning too slowly and therefore going over the track.

LightSensor experiments:
Measuring on a white surface with the floodlight on yielded readings around 53-54%
Measuring on a Black surface with the floodlight on yielded readings around 34-35%

Since a white surface reflects more light than a black surface, these readings make sense.

We also experimented with moving the sensor, which resulted in the following:
Measuring on a white surface with the floodlight on yielded readings around 53-54%
Measuring on a Black surface with the floodlight on yielded readings around 24-25%

These readings might be usefull, because they make it easier to distinguish black from white, and might even make it possible to move away from the bang-bang model used in the LineFollower program.

The program we ended up with can be found at http://www.daimi.au.dk/~heath/EmbeddedSystems/LineFollower.java