Week 5 lab

We were all here this week (Zoi, Carsten and Dan). We worked from
11:15 to 13:30.

** light values:

We used the program from last time that read the normalized light
value (which is the raw light value? (range is 0-1024 according to
API)). The light conditions are just the Zuse building. For
the dark conditions we wrapped a black bag around the sensor.

- in light conditions: white=555, black=370, green=460
- in dark conditions: white=540, black=312, green=415

** carfollower using dark-white:

*** initial program

- on hill: lost track when going over edge. Light sensor gets too
far away from the floor and thinks black and white.
- on track: goes off-track in sharp turns.

*** with proportional

We made it turn less if the light value was close to the average
between the black and white light values. The robot would more easily
stray from the black line in corners and sometimes just on straight
lines.

For next week we could implement a smarter solution that, when the
error gets high enough we could make the other wheel turn in reverse
making the robot turn on its own axis.

*** Finding green

Our experiments with reading light values, we know that green is
between black and white. But in our proportional line follower, that
is the optimal line. We try to overcome this by adding a check to our
main loop that stops the car if a light values close to the green
calibrated value.

Through experiments we ended up with green being defined as the
calibrated value +- 1. And our robot would very often stop on the
black line. Next week we can use a more precise light-value (by using
different API function) to get a more accurate detection.

Week 4

This week we had to experiment with a balancing robot utilizing the
light sensor.

Using the light measure of calibration phase of the program we
determined the light values varies from around 540 when tilting
forward (closer to the ground) to 530 when tilted backwards.

The program uses the three error values (P,I,D) to determine a course
of action.

We tried changing to effect of the D value to decrease the jerking
motions that caused the robot to overcompensate and fall over. But out
changes either didn't noticeable affect the robot, or it had too great
an affect and the robot would fall over by not compensating enough.

In the end we had the most sucess by spending a very long time in the
calibration phase finding a very accurate balance value.

week 3

Test of sound sensor:

Clapping seems to make it go up to 50%, whistling made it go up to 98%.

Clapping at 1-5m away reads a value of about 20%.

Behind it also works.

sample:

we recorded a single clap about 1 meter away. (PLOT)

sound control car:

We implemented buttonlistener as described in the API. The program
works as expected. It only accepts very loud sounds. which meant we
had to get very close to whistle at it to make it switch settings.

Sound identification.

We tried distinguishing between a clap and a general loud noise.

we implemented the sound storage as an array of 60 integers. which was
updated as a circular array. We a circular array as this is very fast
and every ms it takes to add the integer is added to the update-time
(2ms processing time + 5 ms thread.sleep time = 7ms update-time). If
our update-time becomes too big our clap detection analysis would fail.

We implemented the clap-detection by having 3 integers. 1st contains
the average volume of the last 25ms. 2nd has the average of 25ms in
the pat to 225ms in the past. And 3rd has the average of 225ms to 250
ms in the past. A clap is then when the 1st and 3rd integers are
between 30 and 50. and the 2nd is above 85.

Our program worked about every 5th to 10th clap.

Week 2

The sensor had a very narrow cone. So we needed a big target the
farther we wanted to measure.

It takes sound approximately 15 ms to travel 2 * 255cm. The NXJ is
capable of updating faster than this, so the speed of sound can
interfere with programs using fast update-rate.

The tracker program is a linear control system as the speed slows the
closer to the preferred distance the robot gets.

We tried 3 settings for the minPower for the tracker program.

Default (60%): It would oscillate back and forth around three 35cm
mark.

At 255cm, it's power is max(60, (255-35) * 0.5) = 110%

At 0cm, it's power is - min(60, |0-35| * 0.5) = - min(60, 16) = 60%,

At 35cm, it's power is max(60, (35-35)*0.5) = 60%

Change 1 (0%): It would stop at around 138cm away from the wall, with
a power of 51%. So 51% is the least amount of power needed to make the
wheels turn. So this could be a good minPower.

Change 2 (51%): It wasn't. Engine power needed to make the wheel turn
is variable. and 51% isn't always enough. when it backing up it would
stop at 35cm though. So we need a higher minPower. But then we're back to 60%.

We implemented a simple program the turned into the wall on high
distance, and turn away from the wall on lower distance. This worked
somewhat well. When the robot was placed at the correct distance it
would keep the correct distance untill the oscillations eventually
became too big and it would turn 180% degrees.

02-09-2010

Well... We had most the lego blocks and we actually managed to build the car. Further more we got this block created!