Lab session 2 : Experimenting with the ultrasonic sensor

Date: 9. September 2010

Duration of activity: 3,5 hours (11:00 - 14:30)

Group members participating : all group members, that is Anders Dyhrberg, Guillaume Depoyant, Michaël Ludmann and Michal Owsinski.

I. Objectives and summary

I. 1. Objectives

Build a robot with an ultrasonic sensor

Experiment with the ultrasonic sensor

Experimenting with the "Tracker Beam" example

Build and program a wall follower robot

I. 2. Summary

During this lab session, we managed to :

• Create a repository for our code using Google code and Subversion. You can browse it freely at this link.
• Build the LEGO robot with ultrasonic sensor and test it to see how the sensor measures the distance. We used for this purpose the file SonicSensorTest.java.
• Have the robot react simply according to what it senses with the ultrasonic sensor. We have tried the files Car.java and Tracker.java.
• Program something a bit more sophisticated, that enables our robot to follow a wall on his right. It was nessessary to change the position of the sensor and do many experiments with it to find the best place, in order to minimize the efforts in the programming part.

II. Results

II. 1. Test of the Ultrasonic Sensor

At the last lab session one of our task was to test the Lego Ultrasonic Sensor. The ultrasonic sensor detects objets in front of the sensor by sending a short high frequency sound and then listen to echoes. If an echo comes back there is an object in front. The sensor can measure distance up to 254 cm, it returns value of 255 when there is no object within range. Our task was to measure if the sensor is returning correct values with different distances and different objects. To our measurements we used the Lego car 9797 with on-top mounted ultrasonic sensor.

We started with the distance of 9 cm and increased it by 5 cm until the distance of 74 cm. What we observed was that the sensor was not accurate with very short distances, fx. with distance of 9 cm the sensor returned 11 cm. From the distance of 24 cm the sensor started to return correct values. Then we took 2 control measurements from the middle distance (109 and 134 cm). Last 4 measurements were 204, 214, 224, 234 cm on which we saw that the sensor is loosing the distance again.

Second experiment was to see how the sensor will react with different materials. We used fixed distance of 59 cm for all materials.

What we can see on the chart is cloths don't reflect ultra sonic sounds very well.

"Try to use the sensor with an object at a distance of up to 254 cm, can the sensor measure such a distance and under what conditions is it possible ? What is the time limit for the measurement - remember the speed of sound is 340.29 m/sec ? Does this limit usage of the sensor ?"

The sensor can measure the distance of 254 cm only with large objects (fx. wall) but it will loose accuracy.

Since the speed of sound is 340 m/sec the sensor shouldn't wait longer for the signal to return for more than 15 ms (sound travels 2,54m within 7,47 ms x 2 = 14,94 ms) but after putting that value in the SonicSensorTest.java program the sensor was returning correct values untill the distance of 161 cm.

II. 2. Experimenting with the "Tracker Beam" example

The functionallity of this program is very basic.

When the program is started it continously reads the distance to any object in front of it.

If there is no object within the range of the sensor it drives forward until it has something in range.

When an object is in range of the sensor. The program calculates the difference in the measured distance to the desiredDistance value. The system respond this calculation by driving in the required direction with a speed that gets smaller or larger depending on the distance to the object in order to continously achieve the desiredDistance value.

This type of system is what control theory term a feedback control system, more specifically in this case a proportional feedback control system. This dictates that the output is proportional to the error signal, and it is just a multiplication product of the error and the gain. It is normally mathematically expressed as:

where

• P_out: Output of the proportional controller. In our case our direct input to the motors.
• K_p: Proportional gain. In our case 50%
• e(t): Instantaneous process error at time 't'. e(t) = SP − PV. In our case the difference between value form sensor and desiredDistance.
• SP: Set point. In our case desiredDistance.
• PV: Process variable. In our case the value read form the Sonar Sensor

The tracker beam example is functional. But using a proportional feedback system will only bring you to a certain performance level, no matter how much you tweek the variables. In order to achieve a better performing system more advanced regulation is required.

II. 3. Wall Follower

Using a NQC programm

For this last part of this lab session, we had to first read and understand the code of Philippe Hurbain [1], who has once programmed a wall follower using the old LEGO Mindstorms RCX, a homebrew distance sensor and the NQC language (Not Quite C [2]).

His code is quite messy because of some arbitrary constant names and the peculiar way it uses the homebrew sensor (initialization of it and raw values that don't mean anything for our own sensor). For instance, smaller values mean that the sensor is further from the wall, as opposed to our sensor which returns the distance in centimeters. Still, appart from that, if you know C, it is quite easy to understand the logic beneath the whole program and its algorithm.

The program go through differents steps depending on the distance of the sensor to the wall. That is, depending on pre-established tresholds, it corrects the moves of the robot by changing the type of rotation each motor has to make. For example, if the robot is too close to wall (i.e. the distance measured is lower than a given threshold), then the program will make the robot turn, by having one motor turning at full speed, while the other floats.

Our own program in leJOS

Implementing this program in leJOS provided us easily with quite the same algorithm. However, first tests were not so conclusive, that is why we had to make some finishing touches.

We ended with the code you can check at this adress. We regulate the motors, that is the controlled variable, through the distance to the wall, that is the measured variable.

In our loop, we use one more interval to have a proper reaction when facing the wall a bit to close. In such a case, our robot moves backward until the distance is a bit higher. It therefore prevents it from being stuck in a corner.

Furthermore, we have chosen to have it taking turns by changing the power applied to the motors, so we have a smoother movement.

The importance of the physical world - Testing our algorithm

At first, we just translated the program from C into Java, trying to be as faithful as possible with the code of Philippe Hurbain. In order to have a functional system, the sensor had to be in a different orientation; indeed, it couldn't be oriented towards the front (looking at the wheels) that's why we just turned it to 45° to the right but we kept the original spot, that's to say just above the screen of the NXT brick. After that, we injected the code into the robot, and observed that it had different behaviors from what we could have expected.

Netherthelss, we managed to improve the behavior of the robot, changing the values that Philippe Hurbain qualified as "Too far", "too close" or "right distance", but still, the results weren't that satisfactory.

So at this moment, we tried to think into the physical world and try to understand how we could find an optimal configuration for the sensor. Because for the top of the NXT brick, we found out that for a same distance, the robot could be stuck in front of a wall or in a good position for the wall follower program (and for a little movement of one of the motor, the value that the sensor recorded could change in huge proportions). That's why we tried to keep the orientation of the sensor, but change the spot.

That's why we put the sensor above the right wheel and by sampling the distance values, we came out with a great result. We had still a few oscillations, but the robot was programmed to have some good trajectories to avoid the obstacles and not to be stuck (as we can see on the video around 00:26)

III. References

[1], Philippe Hurbain, WallFollower

[2], Not Quite C, a language with a C-like syntax, made for programming RCX LEGO bricks. It has since evolved into NXC (Not Exactly C) to work with the NXT brick.