... | @@ -63,12 +63,12 @@ This time the robot ended 1 mm to the right and 1.5 mm in front of the initial p |
... | @@ -63,12 +63,12 @@ This time the robot ended 1 mm to the right and 1.5 mm in front of the initial p |
|
![Skærmbillede 2015-06-01 kl. 09.32.02](http://gitlab.au.dk/uploads/group-22/lego/1283b932a5/Sk%C3%A6rmbillede_2015-06-01_kl._09.32.02.png)
|
|
![Skærmbillede 2015-06-01 kl. 09.32.02](http://gitlab.au.dk/uploads/group-22/lego/1283b932a5/Sk%C3%A6rmbillede_2015-06-01_kl._09.32.02.png)
|
|
##### Fig. 6 - Screendump of the robot screen with values.
|
|
##### Fig. 6 - Screendump of the robot screen with values.
|
|
|
|
|
|
These values are very close to the ones we noted on the paper grid layout.
|
|
These values are very close to the ones we noted on the paper grid layout. The small difference in values can have several possible causes.
|
|
|
|
|
|
Compared to the previous experiment the error of 0.225 % is significantly smaller than 1.075 % from test 1 meaning that the slim wheels where more accurate for precision driving. However the same result may also be achieved with the wide wheels if the trackWidth and wheelDiameter values are properly adjusted.
|
|
Compared to the previous experiment the error of 0.225 % is significantly smaller than 1.075 % from test 1 meaning that the slim wheels were more accurate for precision driving. However the same result may also be achieved with the wide wheels if the trackWidth and wheelDiameter values are further adjusted.
|
|
|
|
|
|
### Measurement and Correction of Systematic Odometry Errors in Mobile Robots
|
|
### Measurement and Correction of Systematic Odometry Errors in Mobile Robots
|
|
There is two dominant errors [1] which can occur within the differential-drive mobile robots: Uncertainty about the wheelbase and unequal wheel diameters.
|
|
There is two dominant types of errors [1] which can occur within the differential-drive mobile robots: Uncertainty about the wheelbase and unequal wheel diameters.
|
|
|
|
|
|
### Measuring the accurate wheel diameter and track width
|
|
### Measuring the accurate wheel diameter and track width
|
|
As our Test 2 revealed the importance of a precisely measured wheelDiameter we decided to use a caliper to get these values as accurate as possible. Doing these measurements would also reveal any possible deviations for the same type of wheels.
|
|
As our Test 2 revealed the importance of a precisely measured wheelDiameter we decided to use a caliper to get these values as accurate as possible. Doing these measurements would also reveal any possible deviations for the same type of wheels.
|
... | @@ -76,9 +76,9 @@ As our Test 2 revealed the importance of a precisely measured wheelDiameter we d |
... | @@ -76,9 +76,9 @@ As our Test 2 revealed the importance of a precisely measured wheelDiameter we d |
|
![IMG_8677](http://gitlab.au.dk/uploads/group-22/lego/e449d916ab/IMG_8677.JPG)
|
|
![IMG_8677](http://gitlab.au.dk/uploads/group-22/lego/e449d916ab/IMG_8677.JPG)
|
|
##### Fig. 7 - With the use of a caliper, we got the accurate measuring of the wheel diameter.
|
|
##### Fig. 7 - With the use of a caliper, we got the accurate measuring of the wheel diameter.
|
|
|
|
|
|
The fat off road wheels were measured to be 5,6 + (1/10)*0,1 = 5,61 centimetres, but were likely to compress slightly under the weight of the robot, something that could not be measured using a standard caliper with the wheels mounted to the robot.
|
|
The wide off road wheels were measured to be 5,6 + (1/10)*0,1 = 5,61 centimetres, but were likely to compress slightly under the weight of the robot, something that could not be measured using a standard caliper with the wheels mounted to the robot.
|
|
|
|
|
|
The slim wheels we measured to 3 + (2/10) * 0,1 = 3,02 centimetres.
|
|
The slim wheels were measured to 3 + (2/10) * 0,1 = 3,02 centimetres.
|
|
While fitting the caliper to the slim wheels, we noticed that the right wheel was a couple of micrometres larger than the left, but that this wasn’t enough to actually make the caliper move.
|
|
While fitting the caliper to the slim wheels, we noticed that the right wheel was a couple of micrometres larger than the left, but that this wasn’t enough to actually make the caliper move.
|
|
|
|
|
|
### Calculation of the true track width
|
|
### Calculation of the true track width
|
... | @@ -110,7 +110,11 @@ By attaching an extended pointer the change in orientation should be easier to d |
... | @@ -110,7 +110,11 @@ By attaching an extended pointer the change in orientation should be easier to d |
|
The extended arm with two pointers made it easier to align the robot to the line on the ground.
|
|
The extended arm with two pointers made it easier to align the robot to the line on the ground.
|
|
|
|
|
|
### Conclusion to first experiment
|
|
### Conclusion to first experiment
|
|
Play in the wheels is a non-systematic error, as it is determined by chance and not a consistent recurring inaccuracy. An example of a systematic error, would be if one wheel had a slightly larger diameter than the other, or that one of the electrical motors
|
|
By changing the wheels from big to small tires, we could make the robot more accurate as we were able to better measure the tire size.
|
|
|
|
|
|
|
|
The small difference in diameter in the slim wheels caused the robot to drive slightly to one side. To fix this we tried switching the wheels to opposite sides and this fixed the problem.
|
|
|
|
|
|
|
|
Play in the wheels is a non-systematic error, as it is determined by chance and not a consistent recurring inaccuracy. An example of a systematic error, would be if one wheel had a slightly larger diameter than the other, or differences in the electrical motors.
|
|
|
|
|
|
## Calibrate the wheel diameter and the track width
|
|
## Calibrate the wheel diameter and the track width
|
|
To calibrate the robots travel distance according to the wheel diameter we modified the code from PilotSquare.java as follows:
|
|
To calibrate the robots travel distance according to the wheel diameter we modified the code from PilotSquare.java as follows:
|
... | @@ -122,20 +126,20 @@ To calibrate the robots travel distance according to the wheel diameter we modif |
... | @@ -122,20 +126,20 @@ To calibrate the robots travel distance according to the wheel diameter we modif |
|
##### Fig. 12 - Codesnippet from PilotSquare.java
|
|
##### Fig. 12 - Codesnippet from PilotSquare.java
|
|
|
|
|
|
|
|
|
|
This code should drive the robot forward 50 cm’s. In order to get accurate results the robot was placed on a paper with a grid layout and markers for each 25 cm’s. By doing this we know that if the robot is calibrated correctly it will stop after two lines corresponding to 50 cm.
|
|
This code should drive the robot forward 50 cm. In order to get accurate results the robot was placed on a paper with a grid layout and markers for each 25 cm. By doing this we know that if the robot is calibrated correctly it will stop after two lines corresponding to 50 cm.
|
|
|
|
|
|
|
|
|
|
![IMG_0677](http://gitlab.au.dk/uploads/group-22/lego/c6c2a8e30e/IMG_0677.JPG)
|
|
![IMG_0677](http://gitlab.au.dk/uploads/group-22/lego/c6c2a8e30e/IMG_0677.JPG)
|
|
##### Fig. 13 - The robot starting position.
|
|
##### Fig. 13 - The robot starting position.
|
|
|
|
|
|
### Initial drive (diameter 3.0):
|
|
### Initial drive (Wheel diameter 3.0):
|
|
The initial drive revealed a traveled distance of 51 cm which is 1 cm more than targeted. This result is also proved by the pose() values showed below which indicates a value larger than 50.
|
|
The initial drive revealed a traveled distance of 51 cm which is 1 cm more than targeted. Looking at the pose() values (showed below) we know that the program thinks it has travelled the targeted 50 cm which means that the wheel diameter value is not properly adjusted.
|
|
|
|
|
|
![IMG_0679](http://gitlab.au.dk/uploads/group-22/lego/299f6cf5de/IMG_0679.JPG)
|
|
![IMG_0679](http://gitlab.au.dk/uploads/group-22/lego/299f6cf5de/IMG_0679.JPG)
|
|
##### Fig. 14 - Ending position of the robot after test run.
|
|
##### Fig. 14 - Ending position of the robot after test run.
|
|
|
|
|
|
![Skærmbillede 2015-06-01 kl. 09.59.50](http://gitlab.au.dk/uploads/group-22/lego/08b4fb0c39/Sk%C3%A6rmbillede_2015-06-01_kl._09.59.50.png)
|
|
![Skærmbillede 2015-06-01 kl. 09.59.50](http://gitlab.au.dk/uploads/group-22/lego/08b4fb0c39/Sk%C3%A6rmbillede_2015-06-01_kl._09.59.50.png)
|
|
##### Fig. 15 - Screendump of the robot after test run.
|
|
##### Fig. 15 - The console view shows that the robot has covered the desired distance of 50 cm though the paper layout proved it had not. This means that the wheelDiameter is not properly adjusted.
|
|
|
|
|
|
As the robot drove too far, we modified the wheelDiameter value from 3.0 to 3.1 (cm) and observed the change in travelled distance.
|
|
As the robot drove too far, we modified the wheelDiameter value from 3.0 to 3.1 (cm) and observed the change in travelled distance.
|
|
|
|
|
... | @@ -152,12 +156,6 @@ After some fine tuning we discovered that a wheelDiameter value of 3.025 reveale |
... | @@ -152,12 +156,6 @@ After some fine tuning we discovered that a wheelDiameter value of 3.025 reveale |
|
![IMG_0681](http://gitlab.au.dk/uploads/group-22/lego/ca29af600f/IMG_0681.JPG)
|
|
![IMG_0681](http://gitlab.au.dk/uploads/group-22/lego/ca29af600f/IMG_0681.JPG)
|
|
##### Fig. 18 - Ending position with wheel diameter at 3.025.
|
|
##### Fig. 18 - Ending position with wheel diameter at 3.025.
|
|
|
|
|
|
### Causes for different Odometry
|
|
|
|
|
|
|
|
In [4] causes for different odometry errors are described, both systematic errors e.g. caused by unequal wheel diameters and non-systematic errors e.g. caused by wheel-slippage due to irregularities of the surface or over-acceleration. According to [4] the non-systematic errors can be reduced significantly by adjusting the wheel diameters and track width used in the software. In [4] a method is given that reduces the systematic odometry errors. We will, however, in the following use a more ad hoc method.
|
|
|
|
|
|
|
|
Lastly we observed a systematic error where the robot shifted slightly to one side. To fix this we tried switching the wheels to opposite sides and this fixed the problem.
|
|
|
|
|
|
|
|
### Adjusting trackWidth through rotation
|
|
### Adjusting trackWidth through rotation
|
|
|
|
|
|
* After having adjusted the wheel diameters then make the vehicle rotate a given angle e.g. 180 degrees and adjust the trackWidth until the vehicle rotates as close to the given angle as possible.
|
|
* After having adjusted the wheel diameters then make the vehicle rotate a given angle e.g. 180 degrees and adjust the trackWidth until the vehicle rotates as close to the given angle as possible.
|
... | @@ -173,20 +171,23 @@ show(poseProvider.getPose()); |
... | @@ -173,20 +171,23 @@ show(poseProvider.getPose()); |
|
With the value trackWidth correctly calibrated we expect the robot to turn exactly 180 degrees.
|
|
With the value trackWidth correctly calibrated we expect the robot to turn exactly 180 degrees.
|
|
|
|
|
|
### Results
|
|
### Results
|
|
The results showed the robot turn 180 degrees and stop with the pointer touching the line. When looking at the pose result V we see that it is practically as close to 180 degrees as itcan be, meaning that the trackWidth value is calibrated properly from the start.
|
|
The results showed the robot turn 180 degrees and stop with the pointer touching the line. When looking at the pose result V we see that it is practically as close to 180 degrees as it can be, meaning that the trackWidth value is calibrated properly from the start.
|
|
|
|
|
|
![Skærmbillede 2015-06-01 kl. 10.15.35](http://gitlab.au.dk/uploads/group-22/lego/53ebbb1e9d/Sk%C3%A6rmbillede_2015-06-01_kl._10.15.35.png)
|
|
![Skærmbillede 2015-06-01 kl. 10.15.35](http://gitlab.au.dk/uploads/group-22/lego/53ebbb1e9d/Sk%C3%A6rmbillede_2015-06-01_kl._10.15.35.png)
|
|
##### Fig. 20 - Screendump from the robot screen with values.
|
|
##### Fig. 20 - Screendump from the robot screen with values.
|
|
|
|
|
|
![90 turn start](http://gitlab.au.dk/uploads/group-22/lego/88f4af5140/90_turn_start.JPG)
|
|
![90 turn start](http://gitlab.au.dk/uploads/group-22/lego/88f4af5140/90_turn_start.JPG)
|
|
Fig. 21 - Starting position of the robot before 90 degree turn.
|
|
##### Fig. 21 - Starting position of the robot before 90 degree turn.
|
|
|
|
|
|
![90 turn finished](http://gitlab.au.dk/uploads/group-22/lego/2f3dfa8f34/90_turn_finished.JPG)
|
|
![90 turn finished](http://gitlab.au.dk/uploads/group-22/lego/2f3dfa8f34/90_turn_finished.JPG)
|
|
Fig. 22 - Finish position of the robot after 90 degree turn.
|
|
##### Fig. 22 - Finish position of the robot after 90 degree turn.
|
|
|
|
|
|
|
|
[![image alt text](http://img.youtube.com/vi/eNhb2zsw7ao/0.jpg)](http://www.youtube.com/watch?v=eNhb2zsw7ao)
|
|
|
|
##### Fig. 23 - Showing the robot turning and stopping at almost exactly 180 degree.
|
|
|
|
|
|
In [4] it is described that "With proper adjustment of these parameters, errors in distance traveled and angle of rotation can be held to 2% or perhaps less". See if this can be achieved.
|
|
In [4] it is described that "With proper adjustment of these parameters, errors in distance traveled and angle of rotation can be held to 2% or perhaps less". See if this can be achieved.
|
|
|
|
|
|
Our values and test drives reveals an error of less than…. (50.8 cm / 50 cm * 100 ) - 100 = 1.8 % error.
|
|
Our values and test drives reveals an error of 1.8%, (50.8 cm / 50 cm * 100 )- 100 = 1.8 % error.
|
|
|
|
|
|
## Square experiment with increased distance
|
|
## Square experiment with increased distance
|
|
With this experiment we aim to expose erros by increasing the robots travel distance. By doing this we should be able to make minor adjustments to the wheelDiameter and get a more accurate calibration.
|
|
With this experiment we aim to expose erros by increasing the robots travel distance. By doing this we should be able to make minor adjustments to the wheelDiameter and get a more accurate calibration.
|
... | @@ -195,21 +196,21 @@ To obtain an increased travel distance we made the following changes to the for- |
... | @@ -195,21 +196,21 @@ To obtain an increased travel distance we made the following changes to the for- |
|
```
|
|
```
|
|
pilot.travel(50); //instead of 25
|
|
pilot.travel(50); //instead of 25
|
|
```
|
|
```
|
|
##### Fig. 23 - Codesnippet of the for-loop in the PilotSquare.java
|
|
##### Fig. 24 - Codesnippet of the for-loop in the PilotSquare.java
|
|
|
|
|
|
## Results
|
|
## Results
|
|
The experiments showed the robot stopping within 3 mm of the line after driving in a square with side = 50 cm.
|
|
The experiments showed (see fig. 25) the robot stopping within 1-2 mm of the line after driving in a square with side = 50 cm.
|
|
|
|
|
|
The robot travelled a total distance of 200 cm. The pose values show that the robot have travelled 0.4 cm too far. This reveals an error of (200.4/200*100)-100 = 0.205 % which is very low and acceptable.
|
|
![after 50cm square drive (1)](http://gitlab.au.dk/uploads/group-22/lego/d5952e0d32/after_50cm_square_drive__1_.JPG)
|
|
|
|
##### Fig. 25 - The robot position after 50cm square drive.
|
|
|
|
|
|
![Skærmbillede 2015-06-01 kl. 10.40.37](http://gitlab.au.dk/uploads/group-22/lego/ed32d850c4/Sk%C3%A6rmbillede_2015-06-01_kl._10.40.37.png)
|
|
The robot travelled a total distance of 200 cm. The pose values show that the robot have travelled 0.4 cm too far. This reveals an error of (200.4/200*100)-100 = 0.205 % which is very low and acceptable.
|
|
##### Fig. 24 - Screendump of the robot screen after run.
|
|
|
|
|
|
|
|
## Position tracking by means of particle filters
|
|
## Position tracking by means of particle filters
|
|
To estimate the influence of non-systematic errors on the position of the vehicle obtained by odometry we will use the method of Monte Carlo localization or particle filter localization, [2]: "The algorithm uses a particle filter to represent the distribution of likely states, with each particle representing a possible state, i.e. a hypothesis of where the robot is". We will use use the algorithm in the special case where only the movements of the vehicle will be modelled in the motion update step of the algorithm, [2] and all particles are initially set to the known starting position. An example of the resulting particle set after each move of a non-sensing vehicle can be seen in Fig. 25. The details of the stochastic motion model used in Fig. 25 can be found in [2].
|
|
To estimate the influence of non-systematic errors on the position of the vehicle obtained by odometry we will use the method of Monte Carlo localization or particle filter localization, [2]: "The algorithm uses a particle filter to represent the distribution of likely states, with each particle representing a possible state, i.e. a hypothesis of where the robot is". We will use use the algorithm in the special case where only the movements of the vehicle will be modelled in the motion update step of the algorithm, [2] and all particles are initially set to the known starting position. An example of the resulting particle set after each move of a non-sensing vehicle can be seen in Fig. 26. The details of the stochastic motion model used in Fig. 26 can be found in [2].
|
|
|
|
|
|
![Skærmbillede 2015-06-01 kl. 10.42.53](http://gitlab.au.dk/uploads/group-22/lego/51f222e026/Sk%C3%A6rmbillede_2015-06-01_kl._10.42.53.png)
|
|
![Skærmbillede 2015-06-01 kl. 10.42.53](http://gitlab.au.dk/uploads/group-22/lego/51f222e026/Sk%C3%A6rmbillede_2015-06-01_kl._10.42.53.png)
|
|
##### Fig. 25: The distribution of likely positions for a non-sensing vehicle after moving for several steps.
|
|
##### Fig. 26: The distribution of likely positions for a non-sensing vehicle after moving for several steps.
|
|
|
|
|
|
## Task
|
|
## Task
|
|
Investigate if the model of non-systematic random odometry errors also model the errors of the base vehicle driving a sequence of travel and rotation steps.
|
|
Investigate if the model of non-systematic random odometry errors also model the errors of the base vehicle driving a sequence of travel and rotation steps.
|
... | @@ -219,20 +220,20 @@ By repeating a square-driving sequence we will measure the extent of the randoml |
... | @@ -219,20 +220,20 @@ By repeating a square-driving sequence we will measure the extent of the randoml |
|
|
|
|
|
### Changing the distance noise
|
|
### Changing the distance noise
|
|
![Skærmbillede 2015-06-01 kl. 10.44.54](http://gitlab.au.dk/uploads/group-22/lego/6fb5274750/Sk%C3%A6rmbillede_2015-06-01_kl._10.44.54.png)
|
|
![Skærmbillede 2015-06-01 kl. 10.44.54](http://gitlab.au.dk/uploads/group-22/lego/6fb5274750/Sk%C3%A6rmbillede_2015-06-01_kl._10.44.54.png)
|
|
##### Fig. 26: The four experiments with changing the distance noise.
|
|
##### Fig. 27: The four experiments with changing the distance noise.
|
|
|
|
|
|
The four experiments show that when the noise factor is increased the spread increases as well. Each point represents a possible outcome position of the robot after driving the square. However the noise value may be fine tuned according to the robot’s accuracy as our previous experiments revealed that the robot was able to travel a square with 50 cm sides within mm’s of accuracy. With this in mind a distance noise factor above 0.2 may be inappropriate.
|
|
The four experiments show that when the noise factor is increased the spread increases as well. Each point represents a possible outcome position of the robot after driving the square. However the noise value may be fine tuned according to the robot’s accuracy as our previous experiments revealed that the robot was able to travel a square with 50 cm sides within mm’s of accuracy. With this in mind a distance noise factor above 0.2 may be inappropriate.
|
|
|
|
|
|
### Changing the angular noise
|
|
### Changing the angular noise
|
|
![Skærmbillede 2015-06-01 kl. 10.46.12](http://gitlab.au.dk/uploads/group-22/lego/600af11772/Sk%C3%A6rmbillede_2015-06-01_kl._10.46.12.png)
|
|
![Skærmbillede 2015-06-01 kl. 10.46.12](http://gitlab.au.dk/uploads/group-22/lego/600af11772/Sk%C3%A6rmbillede_2015-06-01_kl._10.46.12.png)
|
|
##### Fig. 27: The four experiments with changing the angular noise
|
|
##### Fig. 28: The four experiments with changing the angular noise
|
|
|
|
|
|
This experiments reveals similar results to the experiment with distance noise above. It shows that once the noise factor increases the spread will increase equally. What is worth noting is that the angle noise factor is significantly higher than the distance noise factor. This is due to the fact that if the robot only has to drive forward, it will have less trouble staying on track. Whenever the robot turns more factors comes into play eg. accuracy in turning angles, friction when turning and so on resulting in a larger spread in points. However an angle noise factor of 32 seems way too much compared to how the robot acts on a track. As mentioned earlier the robot can complete a square route with high accuracy which makes an angle noise factor of less than 4 more appropriate.
|
|
This experiments reveals similar results to the experiment with distance noise above. It shows that once the noise factor increases the spread will increase equally. What is worth noting is that the angle noise factor is significantly higher than the distance noise factor. This is due to the fact that if the robot only has to drive forward, it will have less trouble staying on track. Whenever the robot turns more factors comes into play eg. accuracy in turning angles, friction when turning and so on resulting in a larger spread in points. However an angle noise factor of 32 seems way too much compared to how the robot acts on a track. As mentioned earlier the robot can complete a square route with high accuracy which makes an angle noise factor of less than 4 more appropriate.
|
|
|
|
|
|
### Sub Task
|
|
### Sub Task
|
|
Look into the motion model used in [2] to get inspiration for experimenting with the model used in applyMove.
|
|
Look into the motion model used in [2] to get inspiration for experimenting with the model used in applyMove.
|
|
|
|
|
|
The motion model from [2] uses theta to calculate the heading of the robot at its starting position. In our applyMove model from Particle.java we don’t use the theta parameter. This means we don’t get any noise on the angle of the robot when it is driving in a straight line. This can be seen in the figure below (see fig. 29). Only when turning we get noise on the heading of the robot and thus the particles spread out as seen in the previous table (see fig. 27).
|
|
The motion model from [2] uses theta to calculate the heading of the robot at its starting position. In our applyMove model from Particle.java we don’t use the theta parameter. This means we don’t get any noise on the angle of the robot when it is driving in a straight line. This can be seen in the figure below (see fig. 30). Only when turning we get noise on the heading of the robot and thus the particles spread out as seen in the previous table (see fig. 28).
|
|
|
|
|
|
```
|
|
```
|
|
|
|
|
... | @@ -240,10 +241,10 @@ float ym = (move.getDistanceTraveled()*((float)Math.sin(Math.toRadians(pose.getH |
... | @@ -240,10 +241,10 @@ float ym = (move.getDistanceTraveled()*((float)Math.sin(Math.toRadians(pose.getH |
|
float xm = (move.getDistanceTraveled()*((float)Math.cos(Math.toRadians(pose.getHeading()))));
|
|
float xm = (move.getDistanceTraveled()*((float)Math.cos(Math.toRadians(pose.getHeading()))));
|
|
|
|
|
|
```
|
|
```
|
|
##### Fig. 28 - Codesnippet from where?
|
|
##### Fig. 29 - Codesnippet from where?
|
|
|
|
|
|
![Skærmbillede 2015-06-01 kl. 10.50.47](http://gitlab.au.dk/uploads/group-22/lego/8c7ecb627b/Sk%C3%A6rmbillede_2015-06-01_kl._10.50.47.png)
|
|
![Skærmbillede 2015-06-01 kl. 10.50.47](http://gitlab.au.dk/uploads/group-22/lego/8c7ecb627b/Sk%C3%A6rmbillede_2015-06-01_kl._10.50.47.png)
|
|
##### Fig. 29 - As long the robot drives straight, the points will stay on the line with no angle.
|
|
##### Fig. 30 - As long the robot drives straight, the points will stay on the line with no angle.
|
|
|
|
|
|
### Particle filter experiments conclusion
|
|
### Particle filter experiments conclusion
|
|
Our two experiments revealed that once the noise factors increase the spread of particles will increase equally. When comparing these results to how our robot acts when travelling in a square we can conclude that a noise factor above the default values of distanceNoise=0.2 and angleNoise=4 is inappropriate as once values like wheelDiameter and trackWidth are adjusted properly the robot will drive and turn with high accuracy. We can also conclude that the angular noise should be larger than the distance noise as the robot is influenced by more factors once it turns than if it drives straight.
|
|
Our two experiments revealed that once the noise factors increase the spread of particles will increase equally. When comparing these results to how our robot acts when travelling in a square we can conclude that a noise factor above the default values of distanceNoise=0.2 and angleNoise=4 is inappropriate as once values like wheelDiameter and trackWidth are adjusted properly the robot will drive and turn with high accuracy. We can also conclude that the angular noise should be larger than the distance noise as the robot is influenced by more factors once it turns than if it drives straight.
|
... | @@ -257,14 +258,14 @@ To make a robot that travels along a fixed route using dead reckoning [3], while |
... | @@ -257,14 +258,14 @@ To make a robot that travels along a fixed route using dead reckoning [3], while |
|
The logic behind the task is to imagine a public space in which the robot has to navigate a predefined route. In such situation the robot should be able to detect and avoid people on its path and navigate to a fixed point without crashing into people.
|
|
The logic behind the task is to imagine a public space in which the robot has to navigate a predefined route. In such situation the robot should be able to detect and avoid people on its path and navigate to a fixed point without crashing into people.
|
|
|
|
|
|
![banegaard](http://gitlab.au.dk/uploads/group-22/lego/17eb9ec552/banegaard.jpg)
|
|
![banegaard](http://gitlab.au.dk/uploads/group-22/lego/17eb9ec552/banegaard.jpg)
|
|
##### Fig. 30 - Picture of Aarhus Main Station.
|
|
##### Fig. 31 - Picture of Aarhus Main Station.
|
|
|
|
|
|
Our strategy is to make the robot drive from point A towards point B in a straight line (see fig. 30).
|
|
Our strategy is to make the robot drive from point A towards point B in a straight line (see fig. 31).
|
|
If the robot encounters an object it will save its pose value in forward direction, turn 90 degrees, drive a short predetermined distance, turn 90 degrees in opposite direction, and then return to the path. When it has passed the object it will compare the current pose value with the ones saved before encountering the object. From this comparison it knows how much distance it needs to cover in order to get to point B.
|
|
If the robot encounters an object it will save its pose value in forward direction, turn 90 degrees, drive a short predetermined distance, turn 90 degrees in opposite direction, and then return to the path. When it has passed the object it will compare the current pose value with the ones saved before encountering the object. From this comparison it knows how much distance it needs to cover in order to get to point B.
|
|
It is worth noting that this is just an example of a solution to the problem with navigation along dynamic objects. We will only drive in a straight line and in order to keep things simple we will only handle one predefined object on the path.
|
|
It is worth noting that this is just an example of a solution to the problem with navigation along dynamic objects. We will only drive in a straight line and in order to keep things simple we will only handle one predefined object on the path.
|
|
|
|
|
|
![plan](http://gitlab.au.dk/uploads/group-22/lego/f151686264/plan.png)
|
|
![plan](http://gitlab.au.dk/uploads/group-22/lego/f151686264/plan.png)
|
|
##### Fig. 31 - Our plan to make the robot drive from A to B in a straight line.
|
|
##### Fig. 32 - Our plan to make the robot drive from A to B in a straight line.
|
|
|
|
|
|
In comparison to a real life scenario you could argue that most people occupies a certain amount of space in a room and thus use a predefined hardcoded avoidance sequence. However it seems more reasonable if the robot used it sensors while avoiding an object to compensate for unknown factors. For example it would be crucial to detect if it has to avoid just one person or a large group of persons or a person pushing a stroller.
|
|
In comparison to a real life scenario you could argue that most people occupies a certain amount of space in a room and thus use a predefined hardcoded avoidance sequence. However it seems more reasonable if the robot used it sensors while avoiding an object to compensate for unknown factors. For example it would be crucial to detect if it has to avoid just one person or a large group of persons or a person pushing a stroller.
|
|
|
|
|
... | @@ -298,22 +299,29 @@ oldPoseX = poseProvider.getPose().getX(); |
... | @@ -298,22 +299,29 @@ oldPoseX = poseProvider.getPose().getX(); |
|
show(poseProvider.getPose());
|
|
show(poseProvider.getPose());
|
|
}
|
|
}
|
|
```
|
|
```
|
|
##### Fig. 32 - Code from PilotSquare.java shows how an ulrasonic sensor is used along with the poseProvider to get the robot to avoid objects when it encounters an object while still being able to get to its desired destination.
|
|
##### Fig. 33 - Code from PilotSquare.java shows how an ulrasonic sensor is used along with the poseProvider to get the robot to avoid objects when it encounters an object while still being able to get to its desired destination.
|
|
|
|
|
|
The code shows that as long the x value from the current pose is less than the predefined travelDistance, the robot will drive forward towards its destination. While driving forward the ultrasonic sensor conducts readings in order to detect upcoming objects. If an object is detected it will trigger the if statement containing the code to avoid the object. After completing a series of avoidance steps the oldPoseX value will be updated with the current pose’s x value. Then loop starts over and the robot will travel the remaining distance towards the destination.
|
|
The code shows that as long the x value from the current pose is less than the predefined travelDistance, the robot will drive forward towards its destination. While driving forward the ultrasonic sensor conducts readings in order to detect upcoming objects. If an object is detected it will trigger the if statement containing the code to avoid the object. After completing a series of avoidance steps the oldPoseX value will be updated with the current pose’s x value. Then loop starts over and the robot will travel the remaining distance towards the destination.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## Result
|
|
## Result
|
|
The robot was able to drive along a path with a fixed length and avoid the object encountered in various positions.
|
|
The robot was able to drive along a path with a fixed length and avoid the object encountered in various positions (See fig. 34).
|
|
|
|
|
|
[![image alt text](http://img.youtube.com/vi/aCHZVuBc0l0/0.jpg)](http://www.youtube.com/watch?v=aCHZVuBc0l0)
|
|
[![image alt text](http://img.youtube.com/vi/aCHZVuBc0l0/0.jpg)](http://www.youtube.com/watch?v=aCHZVuBc0l0)
|
|
##### Fig. 33 - Video showing how the robot car is avoiding a bucket on the route.
|
|
##### Fig. 34 - An object is placed at a random spot on the straight line and the robot avoids it and stops at the 100 cm mark, covering a total of 75 cm. When turning the robot does not rotate the full 90 degrees, but still manages to get around the object.
|
|
|
|
|
|
This proves that a robot can navigate between dynamically placed objects while following a predefined route. In spite of the successful result, the experiment showed some concerns which should be handled through further experimentation:
|
|
This proves that a robot can navigate between dynamically placed objects while following a predefined route. In spite of the successful result, the experiment showed some concerns which should be handled through further experimentation:
|
|
|
|
|
|
While testing this implementation, we encountered a systematic error that we had a hard time determining the cause of. The issue was, that the robot did not travel the exact distances determined in the code and did not turn exactly 90 degrees. To solve this we tried changing the trackWidth and wheelDiameter as in the previous exercise. This quickly resulted in the trackWidth and wheelDiameter differing a lot from the actual measurements of the robot. The problem with systematic errors is that their impact cannot be determined until they are actually found and removed [5]. We suppose that this systematic error could have been cause by ourselves, simply by calibrating the robot too much to drive a specific route with the best possible results.
|
|
While testing this implementation, we encountered a systematic error that we had a hard time determining the cause of. The issue was that the robot did not travel the exact distance determined in the code and did not turn exactly 90 degrees. To solve this we tried changing the trackWidth and wheelDiameter as in the previous exercise. This quickly resulted in the trackWidth and wheelDiameter differing a lot from the actual measurements of the robot. The problem with systematic errors is that their impact cannot be determined until they are actually found and removed [5]. We suppose that this systematic error could have been caused by ourselves, simply by calibrating the robot too much to drive a specific route with the best possible results.
|
|
|
|
|
|
|
|
Instead of using a simple if statement, we could have approached this last task differently, by implementing a behaviour model like in previous assignments. The advantages of this would have been that the model would be easier to build upon in the next assignment, as our current approach is quite specific to the problem.
|
|
|
|
|
|
|
|
## Conclusion
|
|
|
|
* Through this lab session we have gained experience with odometry and how it can be used along with a tacho counter to keep track of a position.
|
|
|
|
* In order to perform precision driving the values of the robot’s track width and wheel diameter are crucial. If these values are slightly off, the error will accumulate over distance.
|
|
|
|
* A particle filter can be used to determine possible outcomes of a robot’s position. Through calibration of distance and angular noise the spread of the possible points will change. The extent of spread in points will be greater if the robot turns compared to driving straight.
|
|
|
|
* In order to follow a predetermined route from A to B along dynamically placed objects an ultrasonic sensor can be used. By detecting upcoming objects using the sensor and interpreting pose values, the robot is able to go from A to B while avoiding randomly placed objects with a fixed size.
|
|
|
|
|
|
|
|
|
|
## References
|
|
## References
|
... | | ... | |