Lesson 2 – Max N00b, max distance
Feb 13, 2014 • lego_course
Todays goals:
Are as described in the lesson 2 exercises notes:
Mount ultrasonic sensor to Max
Additional "Optional" Goals
No additional goals this week
Because of the thorough guide described in the lesson 2 exercises notes, no further planning was necessary.
We followed the goals as described earlier, and started off with attaching the ultrasonic sensor.
Max N00b with newly attached ultrasonic sensor
Then we did the exercises as explained.
By marking distances on a table in 5cm intervals to a total of 140cm, we could then use the values displayed on Max and the measured distance on the table to make a chart displaying the accuracy of the ultrasonic sensor in a controlled environment, using different objects.
We placed Max at the 10 centimeters marker using the wheel base as a point of measure, and deducting an offset from the wheel base to the ultrasonic sensor of 4 centimeters. This basically means that there will be +4 centimeters from the sensor to the different objects from the beginning point.
Then we started with an even surfaced cardboard box placed directly in front of Max and perpendicular to the table.
Measurement using cardboard box as target object
The measurements only fluctuated about 1-3 centimeters (see Table 1) , which could be caused by environmental factors. We know that humidity and temperature has an impact on ultrasonic devices, however in our tests it was constant and therefore had no direct impact on our readings. However, something that could interfere with out readings could be other devices doing similar tests next to us. Next, we used the lid of our Lego kit, which is a semi transparent plastic with a straight surface with small difference in surface height, also placed directly in front of Max and perpendicular to the table
Measurement using semi transparent plastic lid as target
The fluctuations varied a bit more than the cardboard box (See table 1), which could be caused by the slight variations in the target surface. Also at 130 centimeters the sensor was not able to register the target anymore – possibly because of timey wimey stuff.
After that we tried with a coffee pot, having a complex shape and no straight surfaces for the ultrasonic sensor to bounce sound directly off, should give some interesting results.
Measurement using a coffee pot as target
Surprisingly enough, the measurements did not fluctuate as much as we had expected, only differing 4-8 centimeters (See table 1) which could be caused by the sensor reading the top of the pot and us measuring from the larger base, reducing the difference to ~1-4 centimeters. But the sensor – as with the plastic lid – lost sight of the coffee pot already at 65 centimeters.
Last, we tried with the edge of an open book, placed with the edge facing the sensor, to see if the sharp sides would have an effect on the measurements.
Measurement using an open book as target
The results from this last experiment, turned up some very interesting results. The sensor was only able to sense the book at the distance of 30 to 60 centimeters with a difference between target distance and actual distance of 11-16 centimeters (See table 1) The larger difference would be correctable with an offset limiting the differences to ~1-5 centimeters.
We were handed the programming section for measuring the distance using the ultrasonic sensor through this link. No alterations to the code was needed for this exercise.
The table below shows the different sensor readings at the different distances, 255 being the sensor not being able to register the target object. To the right, the differences between measured and actual distance is displayed left to right as follows: Cardboard box, Semi transparent plastic, Coffee pot & Edge of open book.
Table 1 – Measurements from exercise 1
If you look close at the distance of 10 centimeters and 135 centimeters, we got a large difference. We are not sure why this happens, however, we do speculate that the faulty readings at the 10 centimeter mark could be caused by the fact that the sensor itself is with a transmitter and a receiver, positioned with a small gap between. As such, we speculate that perhaps because of the short distance, the echoes do not bounce off correctly or wide enough from the transmitter to hit the receiver.
To better illustrate and compare the different results, we made the following chart depicting the different measurements.
Ultrasonic readings at different distances
As described in the lesson notes, we want to see what happens when changing the sample interval for reading the distance.
We changed the sample interval value from 300 milliseconds to 30 milliseconds, 20 milliseconds, 10 milliseconds, 5 milliseconds and 1 millisecond and tested each of them. For testing the different interval values we chose to continuously move a plastic lid in distances of 10 centimeters to 140 centimeters from the sensor to see if there were any difference in measurement of distance, spikes in the change of measurements and maximum measured distance, between the sample interval.
By modifying the code section from exercise 1:
We would be able to test the program at different sample rates.
The distances displayed on Max at the different distances compared to the results from the 300 milliseconds sample tests, were very similar, confirming our suspicion that the rate in which we ask for the distance doesn´t affect the hardware's ability to measure correctly. The only differences that we observed was that the distance value display changed faster.
We want to find out what might affect Max' ability to measure distances when using an ultrasonic sensor.
We placed Max 250 centimeters and 255 centimeters from a wall to see if it could measure the distance. Further, we tried standing between Max and the wall to see if the distance measured would change.
No further programming was needed. This was mainly calculation and speculation.
From our experiment it would seem that only large, flat surfaces can be measured at distances of 250 centimeters to 255 centimeters. We observed in the earlier exercises that the measurement depends on the different shapes of the objects, and in this exercise we tried standing in front of Max N00b which could only register our presence until we were about 77 centimeters away. However, if we placed Max N00b 250 centimeters from a wall, we got clear measurements.
Since the ultrasonic ping sensor is using ultrasound for measurement, an echo is required in order to know the distance. If the objects have e.g. a rounded shape, the echoes can be reflected away from the receiving part of the sensor causing no measurements at all – which the program gives the value 255.
Working with ultrasonics, we are using sound and it is there relevant to see if the speed of sound has any relevance to Max' sensoring capabilites. This means we want to calculate the minimum time it will take for the ultrasonic sound to travel. We know that the distance was between 250 and 255, so these are our two examples. Also, the sound has to travel from Max and to the wall, and back again to Max. This means we have this equation for calculating time needed for measurements:
As we want the results to be easier to relate to, we change the speed of sound so we get the end result in miliseconds. This is illustrated in the following example of time need to successfully measure at 250cm
An example of time need to successfully measure at 255cm
This means that the lower bounds for when using the ultrasonic sensor is almost 15 milliseconds. What does this mean? It means that no matter what we do there is a physical hardware limitation for how quickly we can get the measurement updates at certain ranges. So what we must do in these two examples is to set our sample rate to a minimum of 15 milliseconds. To put this into perspective, we have calculated the lower bounds for the different distances we used in the previous exercises. The actual distance is in centimeters and the lower bounds is in milliseconds:
Table 2 – Lower time bounds
We want to understand and describe the behavior of the Tracker.java program, and determine which type of control it is.
We first observed the robots behavior by placing and facing it 130 centimeters from a wall and let it run the Tracker.java program and thereafter looked through the code. Afterwards, we made multiple tests of the Tracker.java program with increasing and decreasing the variables: desired distance, minPower and gain. A video of Max running Tracker.java with standard values can be found here.
Using the sample code provided in the lesson notes and modifying the following variables we are able to examine the program and how it works.
int distance,
desiredDistance = 35, // cm
minPower = 60;
float error, gain = 0.1f;
Through the observation and looking at the code the behavior of the robot is: First, the program checks that the sensor's distance value is different from 255. This value is the maximum value in centimeters that the I2C sensor can measure and also the given value from the I2C sensor if an object is further than 255 centimeters from the sensor. If the distance value is 255, the program will execute the motors to move in a specified speed. If the distance values are different from 255, the program will compare the differences of the measured distance and the desired distance between the robot and an object, which is called the error . The error is then multiplied with a variable, named gain, which results in a variable called power. If the error is above 0, the robot will move forward with a speed being the lowest of either: (1) the variable power+minPower or (2) the fixed value 100. Otherwise, the robot moves backwards with a speed being the lowest of either: (1) the variable power+minPower or (2) the fixed value 100.
There are three variables that can be increased og decreased to change the behavior of the robot:
desired distance determines how close to an object Max is allowed to be before either stopping or moving backwards.
minPower is used in calculation to determine a minimum power applied to the motor. minPower makes sure that there is a least amount of power to overcome the inertia to make sure the motors can move. By lowering the minPower value, the motors can not overcome the inertia. Increasing minPower will not only make the power overcome the inertia, but it will also increase the speed in which the robot will be moving in. This is important when Max is close to a desired distance from an object in front of him, because if the minPower is too large, he might jump forwards (or backwards) too much, which can result in a constant oscillating around the desired distance. A video of what happens when increasing minPower can be found here.
gain is used for multiplying the error variable to give a new power value. Gain is also a factor that is used to determine which speed the robot should move in. Furthermore, gain determines the deceleration of the speed according to the robot's distance to an object. A video of what happens when decreasing gain can be found here.
To sum up: The program runs in a proportional controlled loop, where the measured distance is compared with the desired distance, which calculates two outputs: (1) the direction of movement and (2) the movement speed.
We want to make the car oscillate by adjusting the constants in the controller and then create a differential controller for Max so he stops oscillating.
Same experiment procedure as before. First, Max will oscillate when at a desired distance. Then – with the differential controller – Max will stop oscillating at the desired distance.
Our working Tracker code can be downloaded here. Note that the assignment states that we are only allowed to change the variables to make the oscillating start and stop. To create a differential controller, we added a new variable, dgain which is used like this:
power = (int)((gain*error)-(dgain*Math.abs(distance-previousDistance)));
dgain is a variable we set, which is used for correcting the distance measured and desired distance, so that we get a gradual deacceleration based on the distances.
We made Max oscillate from using the code provided as seen here.
By adding a new variable dgain, it as possible to create a differential controller that can make Max decelerate slowly and stop at a desired distance e.g. 35 centimeters. If Max e.g. is placed closer to the wall than the 35 centimeters, he will drive backwards – decelerating gradually as he comes closer to the desired distance, stopping at 35 centimeters.
We want to create a wall-following robot, as described by Philippe Hurbain. First, we have to move the ultrasound sensor to a 45 degrees angle and then we will create a program, based on the code used by Hurbain.
We put the sensor in a 45-degrees angle, as shown here:
Max N00b, staring 45 degrees into the horizon.
We then programmed Max N00b so he could follow a wall. This was based on the code used in the previous Exercise (Tracker.java) to make him drive around a group of cardboard boxes, with a minimum amount of oscillation when correcting. The small box-trip can be seen in this video.
This had two issues:
It was not able to follow inner sharp corners, as seen in the video. Instead, it smoothes out it's driving path to "cut the corner".
When tested on the wall-following track, it couldn't quite manage the drive – having a problem with the last corner of the last cardboard box.
Wall-following track
This lead os into trying the same method Hurbain did which will be described in the next section.
We looked at the principle behind Hurbian's code, which was a series of thresholds that defined whether it was a:
Sharp turn outwards
Sharp turn inwards
Smooth turn outwards
Smooth turn inwards
As such, we created a program which can be found here.
We made Max N00b become a wall-following robot, driving around whatever obstacles he might face as seen in this video.
We realized that some of the hardest obstacles to pass was sharp corners which was also shown in Exercise 1, where the ultrasound had issues sensing the edge of an open book. However, there are also differences in the sensing of the different sharp corners themselves:
Uneven sharp corner
Rounded sharp corner
Max had no problems passing the uneven sharp corner of the cardboard box, however he had serious issues passing the rounded sharp corner. This can be caused by the fact that the ultrasonic soundwave got deflected away causing the sensor to read 255 instead of the actual distance.
This made us realize that our first attempt when using Tracker.java actually might have worked, creating a more smooth drive for Max Noob.
The ultrasonic sensor's reactions to different targets proved to be quite a problem for us, which was in particular visible in Exercise 6.
Also, Max was running out of power which had a significant effect on the output of the two motors.
The ultrasound sensor has a hard time coping with different materials and also sensing at an angle of a target, meaning it is less suited for this kind of task than e.g. an IR or Laser distance sensor. However, it proved quite reliable when facing obstacles perpendicularly. Some good things about using an ultrasonic sensor is that it isn't affected by e.g. light conditions – making it work in complete dark. Furthermore, it is able to sense transparent materials, like glass or transparent paper, which IR or Laser distance sensors would have a particular hard time sensing.