Date:
14/3-2014 (round 1), 17/3-2014 (round 2)
Duration of activity:9.30-13.00 (round 1), 9.30 - 17.00 (round 2)
Group members participating:,
Benjamin, Christina, Levi
Goal for the lab session:
Complete all the exercises for this weeks lab session [1].
Plan for the activities:Go through the exercises one by one, completing them to the extent possible.
Results obtained during lab session:
Vehicle 1
We tried different approaches to map the raw values to the motors. First we tried our own custom approach, where we used the raw value to measure the percentage of the maximum possible value( (value/1023)*100 ). Then we simply added a minPower to this percentage, so the car would drive a little even though there were no noise.
We mounted two light sensors on the front of the car to experiment with the vehicles 2a and 2b, where vehicle 2a has an exibitory connection and 2b has an inhibitory connection.
With the exhibitory connection the car is to follow the light, as it should follow the mantra ‘the more light, the more motor power’. The code for this can be found here [3].
The normalize function used in the program defines the mapping between sensor range and motor power, and in our case, this is from the read raw values of 0 - 1023 from the sensor mapped to the motor power from 0 - 100.
The way of normalizing this is as follows, and can be found here [4].
A video that shows the behavior of the exhibitory connection can be seen below. It shows how the car will turn towards the side where the light is.
A video that shows the behavior of the inhibitory connection can be seen below. It shows the car driving on a white surface, slowly turning left towards a box with a dark cavity. The car continues to drive deeper into the box as it gets darker further into the box. When the car reaches the bottom wall of the box it drives more slowly, but doesn’t stop driving. This is because the motors will always run with at least the ‘minPower’ value.
Vehicle 3
We mounted two ultrasonic sensors and two light sensors on the car, as the picture below shows.
Then we tried a bit more complicated thing, where we let the values from the light sensor start from 100 and going up to 0, and then let the ultrasonic sensor start from 0 and go down to 100. We then deducted values from the first pair of sensors from the second pair of sensors, and appended the results to the motors. This turned out to be more useful since the car avoided most obstacles, as shown in the video below:
It is worth noting however that most obstacles in our testing area was thin and glossy table legs, which can be difficult to measure properly for the sensors.
Conclusion We have gone through all the exercises and experimented with different sensors and set-ups.
References
We tried different approaches to map the raw values to the motors. First we tried our own custom approach, where we used the raw value to measure the percentage of the maximum possible value( (value/1023)*100 ). Then we simply added a minPower to this percentage, so the car would drive a little even though there were no noise.
A video that shows the car driving forward, and slowing down as it reaches a loud sound source (and eventually stopping) is seen below.
Furthermore we tried this: instead of going from -100 to 100 in motorpower, we instead asked if the value was below or above 50, and then the further it was above or below 50, the faster it would drive forward or backward. So if there were no noise, it would calmly drive forward, however if there were loud noises it would drive backwards (like a little scared girl).
We then switched to Breitenbergs[2] approach and tried to use his code. It went fine when mapping values between 0 and 100 to the motors, however when we tried to go to -100, and thus the car should go backwards, we noticed that the engines would simply make too much noise for the value to be low enough to make the motor drive backward.
Vehicle 2
Light sensorsWe mounted two light sensors on the front of the car to experiment with the vehicles 2a and 2b, where vehicle 2a has an exibitory connection and 2b has an inhibitory connection.
With the exhibitory connection the car is to follow the light, as it should follow the mantra ‘the more light, the more motor power’. The code for this can be found here [3].
The normalize function used in the program defines the mapping between sensor range and motor power, and in our case, this is from the read raw values of 0 - 1023 from the sensor mapped to the motor power from 0 - 100.
The way of normalizing this is as follows, and can be found here [4].
A video that shows the behavior of the exhibitory connection can be seen below. It shows how the car will turn towards the side where the light is.
Moving light source
We didn’t have more than one vehicle to test the the program ‘LightFollower’ on, but as the video (fig.5 in the lab session notes) shows, vehicles with exhibitory connections will follow the light and if these lights are placed on other vehicles that move, the light-following vehicle will follow the light source, and therefore the other vehicle which has the lamp placed on it.
Light condition samples
As we could not understand Deans approach [2] (MAX_LIGHT and MIN_LIGHT will always be the same value according to his code, and if we try to normalize using those two values using his previous code, we will end up dividing with 0, and we can’t have that), we decided to make our own approach.
In our approach we take a sample size of 100 on each sensor. In each sample set we find the min and max value, and then we take the lesser and the greater of the two min and max values, and make that our respectively MAX_LIGHT and MIN_LIGHT. That way our algorithm will take the lighting context into consideration.
This however means that sometimes the MAX_LIGHT and MIN_LIGHT would be very close to each other, which meant that small variations in the sensors raw values could make a large difference in the power, making the car drive in odd directions.
We did not make any attempt to optimize this.
By making the min and max values change depending on the measured light, we make the robot take its lighting context into consideration. It may not be important to this project, but if we wish a more precise movement no matter if it’s dark or bright, and movement between darkness and brightness, this is a way to do it.
Below is a video in darkness, where we open the door to a bright room, and the robot has to take the new context into consideration. We do not know why the robot actually stops again after it has measured its new, brighter context, however we chose not to pursue this further.
By making the min and max values change depending on the measured light, we make the robot take its lighting context into consideration. It may not be important to this project, but if we wish a more precise movement no matter if it’s dark or bright, and movement between darkness and brightness, this is a way to do it.
Below is a video in darkness, where we open the door to a bright room, and the robot has to take the new context into consideration. We do not know why the robot actually stops again after it has measured its new, brighter context, however we chose not to pursue this further.
Ultrasonic sensors
In the video [5] a car with two ultrasonic sensors mounted in the front, with some distance in between them, is driving around on a floor, avoiding objects as the car comes closer to them. It seems to work by driving to the left when the sensor on the right senses an obstacle, and vice versa. At a point it drives into an object as it seems that the car doesn’t turn enough to avoid hitting the object with the mounted sensor. When it hits something it keeps on driving. At another point it drives towards a wall and doesn’t correct itself by turning, and it therefore drives into the wall.It could seem that the reason it bumps into things and doesn’t stop driving when it runs into something, is that the sensors aren’t correctly registering at all times, the distance to objects for each of the sensors. Another reason could simply be that the robot is taking both sensors into consideration when measuring distance, and when one of the sensors does not detect any obstacles, it would still drive forward somehow. A possible way of improving this could be to improve upon the distance between the sensors, placing them closer together, and see how this affects the behavior. We have built the car from the video, and implementing code by the mantra of the inhibitory connection; ‘less distance to object from one sensor means more power to the motor (right sensor connected to the left motor)’. First we start with approximately the same distance between the sensors as in the video. A picture of our construction is seen here:
In the video [5] a car with two ultrasonic sensors mounted in the front, with some distance in between them, is driving around on a floor, avoiding objects as the car comes closer to them. It seems to work by driving to the left when the sensor on the right senses an obstacle, and vice versa. At a point it drives into an object as it seems that the car doesn’t turn enough to avoid hitting the object with the mounted sensor. When it hits something it keeps on driving. At another point it drives towards a wall and doesn’t correct itself by turning, and it therefore drives into the wall.It could seem that the reason it bumps into things and doesn’t stop driving when it runs into something, is that the sensors aren’t correctly registering at all times, the distance to objects for each of the sensors. Another reason could simply be that the robot is taking both sensors into consideration when measuring distance, and when one of the sensors does not detect any obstacles, it would still drive forward somehow. A possible way of improving this could be to improve upon the distance between the sensors, placing them closer together, and see how this affects the behavior. We have built the car from the video, and implementing code by the mantra of the inhibitory connection; ‘less distance to object from one sensor means more power to the motor (right sensor connected to the left motor)’. First we start with approximately the same distance between the sensors as in the video. A picture of our construction is seen here:
The code for the program that the car runs using two ultrasonic sensors can be found here [6].
A video that shows the behaviour of the car is shown below.
A video that shows the behaviour of the car is shown below.
We tried placing the sensors more towards the middle/towards each other (so they were approximately 5 cm closer together) but that didn’t seem to affect the car much.
From the video it can be seen that the car stops at some places, were we suspect the distance for both of the sensors to the obstacle the ultrasonic signal reflects on, is so low that the motor doesn’t run. However if there is just a slight difference in the readings for the two sensors, adjusting the minPower variable så that it just have enough power to turn around will make the car go away from the obstacle and drive in another direction. This behaviour (with minPower set up from 30 to 50), can be seen in the video below:
From the video it can be seen that the car stops at some places, were we suspect the distance for both of the sensors to the obstacle the ultrasonic signal reflects on, is so low that the motor doesn’t run. However if there is just a slight difference in the readings for the two sensors, adjusting the minPower variable så that it just have enough power to turn around will make the car go away from the obstacle and drive in another direction. This behaviour (with minPower set up from 30 to 50), can be seen in the video below:
At this stage we already feel our program on the car runs better than that from the video, and we won’t improve further on it.
We mounted two ultrasonic sensors and two light sensors on the car, as the picture below shows.
In order to be able to compare the two very different value ranges, we calculated their percentages rather than their “raw” values. The reason we write “raw” with quotes is that we were unsuccessful in getting the raw data from the ultrasonic sensor, so we had to use the getDistance() method instead, which returns a distance from 0 to 255 cm. In order to get the percentage we simply divided the value with the maximum possible value (which was either 255 or 1023). In this way the value output would always be somewhere between 0 and 100 (as it is percentage).
Then we toyed a bit around with the values to see what would make the car avoid obstacles at best.
We tried to append the higher value of the light sensor and the ultrasound sensor to the motor. However that turned out bad, as the car kept driving into things, as you can see in the video below:
Then we tried a bit more complicated thing, where we let the values from the light sensor start from 100 and going up to 0, and then let the ultrasonic sensor start from 0 and go down to 100. We then deducted values from the first pair of sensors from the second pair of sensors, and appended the results to the motors. This turned out to be more useful since the car avoided most obstacles, as shown in the video below:
Conclusion We have gone through all the exercises and experimented with different sensors and set-ups.
References
[1] Lab session
[2] Tom Dean
[3] LightFollower.java
[4] Lecture slide, p. 41
[5] Ultrasonic sensors
[6] UltraSonic_avoid.java
Ingen kommentarer:
Send en kommentar