NXT Programming, Lesson 3

Test of the Sound Sensor
We wanted to test the sound sensor at different distances and sound levels. We found the clapping was not a very good sound, since it is a short sound, and therefor the reading might not be at the max sound level of the clap.

A continuous sound made from a phone was better suited for this experiment. A small video of the experiment can be found here.

Pictures:

The robot. A sound sensor i fittet to the side of the robot.

Allan with the phone.

The program used to make the sound.

The robot and the table where the the distance is measured.

The some what soundproof room, where we did our experiment.


The results from the experiment can bee seen in the table below.

sound level\cm	0cm	40cm	80cm	120cm	160cm	200cm
low	36	7*	-	-	-	-
medium	93	32	24	16	13	11
high	93	64	46	30	36	19

*result might be influenced by background noise

The maximum dB the sensor can measure is 90 dB[Lego], and the value the sensor returns is the percentage hereof.

At 0 cm the medium and high gave the same result while low got a significant lower result. At 40 cm high dropped a quarter while medium dropped two quarters. At 200 cm both the medium and high gave results higher than the background noise, but we decided to stop at this marker, cause the difference was very small.

The high dropped about a quater at every measurement marker, although we had a reading at 160 cm that did not fit in with the rest of the readings. We suspect that our soundproof room was not that soundproof...

Data logger

The above table is generated using the given datalogger, from which the highest db amount from the logged file is noted. Another way to look at this data would be as a graph, e.g. like the bellow mentioned graph over the data "high, 40 cm.":

The graph shows how the first couple of seconds of sound should be ignored, since this is the sound of the NXT when starting up.

Sound Controlled Car

The sound controlled car program is given in the assignment, and is a simple program which reacts on claps, by blocking until a clap (a loud sound) is registered. Furthermore the value of the escape-button is polled in such a way that the robot does not react to an escape button push if it is blocked.

The solution to do the polling in a new thread (read event listener):

Button.ESCAPE.addButtonListener(new ButtonListener() {

public void buttonPressed(Button b) {

isRunning = false;

System.exit(0);

}

public void buttonReleased(Button b) {

}

});

Clap Controlled Car

We modified the program to be able to register four types of commands, executed by clapping the right amount of times, with a predefined amount of maximum time between them:

1. Drive forward
2. Drive right
3. Drive left
4. Stop

The robot is build around our SoundCarListerner, which waits for a clap. When the first clap is registered, the method driveForward is called:

private void driveForward(long time) {
     LCD.drawString("driveForward",0,7);
        boolean right = waitForClapSoundTimed(time);
        LCD.drawString("driveForward",0,7);
        if (right) driveRight(getTime());
        else {
            car.driveForward();
            try {
  waitForClapSound();
     } catch (Exception e) {
       // TODO Auto-generated catch block
       //e.printStackTrace();
     }
        }
    }

The method waits for the timed method waitForClapSoundTimed(), which returns true if a clap is heard within 300 ms, or false if no clap was heard. driveForward(), will either call the method driveRight(), if true is returned, or make the robot start driving forward if no clap was heard. This recursive cycle moved between the methods: driveForward -> driveRight -> driveLeft -> stop.

The problems we had with this implementation, was that we did not have any wait time between our sound.readValue(), which meant that it would jump to stop every time we made a sound. By making the thread sleep for 100 ms between readings, we could now distinguish between claps. But this also means that the robot will not register faster claps.