... | @@ -28,7 +28,7 @@ We started by stripping the robot of all the gear from the sumo wrestling tourna |
... | @@ -28,7 +28,7 @@ We started by stripping the robot of all the gear from the sumo wrestling tourna |
|
|
|
|
|
*Figure 1: Rebuilt robot for precise tracking during the following exercises.*
|
|
*Figure 1: Rebuilt robot for precise tracking during the following exercises.*
|
|
|
|
|
|
We have made use of the provided **PilotGUI.java** to display the *OdometryPoseProvider*’s estimates of the robot’s position. The *OdometryPoseProvider* treats 0 degrees as lying along the x-axis and therefore reports straight movement as changes in the x-axis (this can be inferred from the fact that *OdometryPoseProvider.java* uses cosine to calculate the x-coordinate and sine to calculate the y-coordinate [9]). Thus, in this reports, deviations on the x-axis are deviations along the straight course of the robot, and deviations on the y-axis are deviations on a course perpendicular to this.
|
|
We have made use of the provided **PilotGUI.java** to display the *OdometryPoseProvider*’s estimates of the robot’s position. The *OdometryPoseProvider* treats 0 degrees as lying along the x-axis and therefore reports straight movement as changes in the x-axis (this can be inferred from the fact that *OdometryPoseProvider.java* uses cosine to calculate the x-coordinate and sine to calculate the y-coordinate [9]). Thus, in this report, deviations on the x-axis are deviations along the straight course of the robot, and deviations on the y-axis are deviations on a course perpendicular to this.
|
|
|
|
|
|
### Observing the accuracy of PilotSquare.java
|
|
### Observing the accuracy of PilotSquare.java
|
|
|
|
|
... | @@ -46,9 +46,7 @@ Our initial run failed miserably because we had positioned the orange pointer to |
... | @@ -46,9 +46,7 @@ Our initial run failed miserably because we had positioned the orange pointer to |
|
|
|
|
|
*Figure 3: Reposition of the orange pointer (3a) and the effect on start position placement (3b)*
|
|
*Figure 3: Reposition of the orange pointer (3a) and the effect on start position placement (3b)*
|
|
|
|
|
|
On the second run our robot managed to do the full trip, but the final position was quite far off the center point - about 4 cm. However, we noticed that the robot was moving the paper around on the table when it was turning or accelerating, which defeated that paper’s purpose of allowing us to judge the end position compared to the start position. Failing to procure any duct tape, we did a third run where we kept the paper steady by having two people press down on the paper’s sides. After this run, the final position was however still rather far away from the center; we measured a 0.75 cm difference along the y-axis and a 3 cm difference along the x-axis (we decided to switch to logging distance along the two axes, instead of a direct total distance). Note that all length measurements were performed simply judging by eye using the grid on the paper, both here and in all following distance measurements.
|
|
On the second run our robot managed to do the full trip, but the final position was quite far off the center point - about 4 cm. However, we noticed that the robot was moving the paper around on the table when it was turning or accelerating, which defeated that paper’s purpose of allowing us to judge the end position compared to the start position. Failing to procure any duct tape, we did a third run where we kept the paper steady by having two people press down on the paper’s sides. After this run, the final position was however still rather far away from the center; we measured a 0.75 cm difference along the y-axis and a 3 cm difference along the x-axis (we decided to switch to logging distance along the two axes, instead of a direct total distance). Note that all length measurements were performed simply judging by eye using the grid on the paper, both here and in all following distance measurements. However, the difference in measuring by sight and with an actual ruler should be insignificant in regards to our results, since the grid functioned as a ruler.
|
|
|
|
|
|
[TODO EMIL:- skriv hvordan vi målte. Camilla mener, at det bare var med øjemål på det ternede papir, ikke med lineal (men at vinkler var med vinkelmåler). Vi tænker, at du kan be- /afkræfte og rette ovenstående kommentar sidst i afsnittet til ift. det :) /Ida]
|
|
|
|
|
|
|
|
We did another fourth and fifth run and saw that the robot ended incredibly accurately in the same position as in the other runs - that is, each run was very similar to the rest, but the end point was far off center. The end position in the fifth run deviated by only about 2-3 mm at most. In Figure 4, screenshots of the *OdometryPoseProvider*’s readings are shown. They also show deviations, although not nearly as evident as those recorded from visual observation. This makes sense, seeing as we performed no modifications of the parameter values to fit *PilotSquare* to our robot - wrong parameter values will cause the program to, for instance, perform an incorrect number of wheel revolutions to travel a distance of e.g. 50 cm, as we describe further in the next section, where we describe our attempt to improve the robot’s performance through calibration of the variables *wheelDiameter* and *trackWidth*.
|
|
We did another fourth and fifth run and saw that the robot ended incredibly accurately in the same position as in the other runs - that is, each run was very similar to the rest, but the end point was far off center. The end position in the fifth run deviated by only about 2-3 mm at most. In Figure 4, screenshots of the *OdometryPoseProvider*’s readings are shown. They also show deviations, although not nearly as evident as those recorded from visual observation. This makes sense, seeing as we performed no modifications of the parameter values to fit *PilotSquare* to our robot - wrong parameter values will cause the program to, for instance, perform an incorrect number of wheel revolutions to travel a distance of e.g. 50 cm, as we describe further in the next section, where we describe our attempt to improve the robot’s performance through calibration of the variables *wheelDiameter* and *trackWidth*.
|
|
|
|
|
... | @@ -60,7 +58,7 @@ We did another fourth and fifth run and saw that the robot ended incredibly accu |
... | @@ -60,7 +58,7 @@ We did another fourth and fifth run and saw that the robot ended incredibly accu |
|
|
|
|
|
#### Wheel diameter
|
|
#### Wheel diameter
|
|
|
|
|
|
The leJOS *DifferentialPilot* constructor requires values for the the wheel diameter and the distance between the wheels (track width) to be specified. We thought it best to focus on one parameter at a time, which is also according to the structure of the lesson plan. We therefore started out by ignoring the track width completely and simply used the value provided in the supplied code. We measured the wheel diameter of both wheels, by taking them off the robot, placing them vertically on a table and measuring them with a ruler, using a straight piece of LEGO to align the ruler. We recorded the diameter for both of our wheels to be 6.3 cm.
|
|
The leJOS *DifferentialPilot* constructor requires values for the wheel diameter and the distance between the wheels (track width) to be specified. We thought it best to focus on one parameter at a time, which is also according to the structure of the lesson plan. We therefore started out by ignoring the track width completely and simply used the value provided in the supplied code. We measured the wheel diameter of both wheels, by taking them off the robot, placing them vertically on a table and measuring them with a ruler, using a straight piece of LEGO to align the ruler. We recorded the diameter for both of our wheels to be 6.3 cm.
|
|
|
|
|
|
We then needed to calibrate these diameter values to account for possible sources of inconsistencies, such as the wheels not being completely aligned [3] or unequal weight distribution on the robot. An incorrect wheel diameter would affect the program’s ability to correctly move the robot specific distances and to move the robot at different speeds (as speed is determined by the number of wheel revolutions per time unit and thus tightly related to the circumference of the wheels).
|
|
We then needed to calibrate these diameter values to account for possible sources of inconsistencies, such as the wheels not being completely aligned [3] or unequal weight distribution on the robot. An incorrect wheel diameter would affect the program’s ability to correctly move the robot specific distances and to move the robot at different speeds (as speed is determined by the number of wheel revolutions per time unit and thus tightly related to the circumference of the wheels).
|
|
|
|
|
... | @@ -84,20 +82,17 @@ As we prepared this third run, we made sure to fix the back wheel to be properly |
... | @@ -84,20 +82,17 @@ As we prepared this third run, we made sure to fix the back wheel to be properly |
|
|
|
|
|
*Video 2: The robot running wheelCalibration with 5.6 cm as wheel diameter.*
|
|
*Video 2: The robot running wheelCalibration with 5.6 cm as wheel diameter.*
|
|
|
|
|
|
The errors seen in Video 2 could either have been caused by the the missing calibration of the *trackWidth* parameter or the fact that we were relying on mere visual precision to ensure that the robot was positioned perpendicular to the line, which was naturally not optimal. Seen in retrospect we probably should have measured the track width to begin with, even though we would save the calibration for later, just to have a value that somewhat fit our robot.
|
|
The errors seen in Video 2 could either have been caused by the missing calibration of the *trackWidth* parameter or the fact that we were relying on mere visual precision to ensure that the robot was positioned perpendicular to the line, which was naturally not optimal. Seen in retrospect we probably should have measured the track width to begin with, even though we would save the calibration for later, just to have a value that somewhat fit our robot. Logically though, the track width shouldn’t affect straight driving, but having a more precise value wouldn’t hurt.
|
|
|
|
|
|
It is worth noting that following these runs, we measured the line on the paper that was used to judge our runs, and found it to have a length of only 49.5 cm according to our ruler. We choose to base our runs on the line (as opposed to our ruler) using that as our measure for 50 cm, as this makes our experiments with calibration easier. We will however consider to re-calibrate the wheel diameter with an actual distance of 50 cm in lesson 11, if we need to drive a longer route only depending on the tacho counter.
|
|
It is worth noting that following these runs, we measured the line on the paper that was used to judge our runs, and found it to have a length of only 49.5 cm according to our ruler. We choose to base our runs on the line (as opposed to our ruler) using that as our measure for 50 cm, as this makes our experiments with calibration easier. We will however consider to re-calibrate the wheel diameter with an actual distance of 50 cm in lesson 11, if we need to drive a longer route only depending on the tacho counter.
|
|
|
|
|
|
As the car was steering a bit towards the left of the line, we adjusted *leftWheelDiameter* from 5.6 to 5.5, while keeping the value for the right wheel at 5.6. The idea was to let the program treat the left wheel as being smaller, thus giving it more power and thereby fixing the error. Running the program with these values, however, caused the robot to end up 1.5 cm off to the *right* of the line, as can be seen in Video 3, causing a total difference of 2.5 cm on the y-axis from our previous run.
|
|
As the car was steering a bit towards the left of the line, we adjusted *leftWheelDiameter* from 5.6 to 5.5, while keeping the value for the right wheel at 5.6. The idea was to let the program treat the left wheel as being smaller, thus giving it more power and thereby fixing the error. Running the program with these values, however, caused the robot to end up 1.5 cm off to the *right* of the line, as can be seen in Video 3, causing a total difference of 2.5 cm on the y-axis from our previous run.
|
|
|
|
|
|
[TODO: Hvad menes med ‘causing a total difference of 2.5 cm’? Det er svært at forstå /Camilla.
|
|
|
|
Jeg tror, at der menes, at før var vi på venstre side 1 cm fra (gætter jeg på, ud fra værdierne), og nu er vi 1,5 cm fra på højre side, så i alt har vi rykket os 2,5 cm. Men jeg kan ikke se pointen med at skrive det /Ida]
|
|
|
|
|
|
|
|
[![Fourth run of wheel calibration](http://img.youtube.com/vi/dCpuXGpKxfQ/0.jpg)](https://www.youtube.com/watch?v=dCpuXGpKxfQ)
|
|
[![Fourth run of wheel calibration](http://img.youtube.com/vi/dCpuXGpKxfQ/0.jpg)](https://www.youtube.com/watch?v=dCpuXGpKxfQ)
|
|
|
|
|
|
*Video 3: The robot running wheelCalibration with left - and right wheel diameter of 5.5 cm and 5.6 cm respectively.*
|
|
*Video 3: The robot running wheelCalibration with left - and right wheel diameter of 5.5 cm and 5.6 cm respectively.*
|
|
|
|
|
|
We changed *leftWheelDiameter* back to 5.6 and ran the program again. This time the robot ended up 0.5 cm to the left of the line, which is far better than the 1.5 cm on the right side from the previous run. We decided to move on at this point, as the robot seemed too inconsistent in its shift on the y-axis for it to make sense to calibrate further. We could possibly have gotten a better result by specifying the wheel diameters using more than one decimal point, but for the exercise in this lesson, we did not feel that the gain was large enough. In lesson 11, however, we might desire a more precise calibration in which case we could make use of more decimal points in the parameters.
|
|
We changed *leftWheelDiameter* back to 5.6 and ran the program again. This time the robot ended up 0.5 cm to the left of the line, which is far better than the 1.5 cm on the right side from the previous run. We decided to move on at this point, as the robot seemed too inconsistent in its shift on the y-axis for it to make sense to calibrate further. We could possibly have gotten a better result by specifying the wheel diameters using more than one decimal point. Considering the 2-2.5 cm difference between the 5.5 and 5.6 cm runs, to account for the 0.5-1 cm skew, we should subtract <0.5 mm from the leftWheelDiameter. For the exercise in this lesson, we did not feel that the gain was large enough to experiment with calibrations of this precision. In lesson 11, however, we might desire a more precise calibration in which case we could make use of more decimal points in the parameters.
|
|
|
|
|
|
[![Fifth run of wheel calibration](http://img.youtube.com/vi/7UQpdAVc95k/0.jpg)](https://www.youtube.com/watch?v=7UQpdAVc95k)
|
|
[![Fifth run of wheel calibration](http://img.youtube.com/vi/7UQpdAVc95k/0.jpg)](https://www.youtube.com/watch?v=7UQpdAVc95k)
|
|
|
|
|
... | @@ -111,12 +106,6 @@ Despite basing our decisions on visual observations, we also noted the *Odometry |
... | @@ -111,12 +106,6 @@ Despite basing our decisions on visual observations, we also noted the *Odometry |
|
|
|
|
|
#### Track width
|
|
#### Track width
|
|
|
|
|
|
We started by fastening the wheels so they would not shift around and cause the track width to change over time. We then measured the track width to be 15.7 cm.
|
|
|
|
|
|
|
|
We wrote a program, **_trackCalibration.java_** [8], to calibrate the track width. It makes the robot perform a 180-degree turn and then stop. This allows us to measure how far off target we end up with relative ease, as the robot should, if perfectly calibrated, end up on the same line as it starts its turn from.
|
|
|
|
|
|
|
|
When trying to run the program it became apparent that we had put the wheels too close to the motor in our attempt to fasten them - they were scraping against the motor while turning. We moved them a slight bit out, and remeasured the track width to be **16.2 cm**.
|
|
|
|
|
|
|
|
We started by fastening the wheels so they would not shift around and cause the track width to change over time. We then measured the track width to be 16.2 cm.
|
|
We started by fastening the wheels so they would not shift around and cause the track width to change over time. We then measured the track width to be 16.2 cm.
|
|
|
|
|
|
We wrote a program, **_trackCalibration.java_** [8], to calibrate the track width. It makes the robot perform a 180-degree turn and then stop. This allows us to measure, with relative ease, how far off target we end up as the robot should, if perfectly calibrated, end up on the same line as it starts its turn from.
|
|
We wrote a program, **_trackCalibration.java_** [8], to calibrate the track width. It makes the robot perform a 180-degree turn and then stop. This allows us to measure, with relative ease, how far off target we end up as the robot should, if perfectly calibrated, end up on the same line as it starts its turn from.
|
... | @@ -133,7 +122,9 @@ We do not have a video showing the track width run, due to issues with our recor |
... | @@ -133,7 +122,9 @@ We do not have a video showing the track width run, due to issues with our recor |
|
|
|
|
|
#### Re-running PilotSquare
|
|
#### Re-running PilotSquare
|
|
|
|
|
|
We changed *PilotSquare* to use the calibrated values, i.e. *wheelDiameter* = 5.6 and *trackWidth* = 16.2 instead of the original 5.5 and 16.0 [6], and re-ran it on the paper track. We judged the final position this time to be approximately 2.5 mm to the right of the x-axis on the paper, and 6 mm up on the y-axis on the paper, a significant improvement to our previous run.
|
|
We changed *PilotSquare* to use the calibrated values, i.e. *wheelDiameter* = 5.6 and *trackWidth* = 16.2 instead of the original 5.5 and 16.0 [6], and re-ran it on the paper track.
|
|
|
|
|
|
|
|
We measured a 2.5 mm difference along the y-axis and a 6 mm difference along the x-axis, a significant improvement to our previous run.
|
|
|
|
|
|
We ran *PilotSquare* a total of five times. The *OdometryPoseProvider* provided end coordinates deviating by an average of 0.057 cm on the x-axis and 0.054 cm on the y-axis. Thus, we see no remarkable improvement compared to the pre-calibration runs (0.059 on the x-axis and 0.061 on the y-axis) - considering that we only performed five runs, the small difference may very well be due to non-systematic errors and variations. The average deviation of the angle, 0.469, is nearly twice that obtained before the calibration, but the magnitude of these deviations is so small that they could still be random.
|
|
We ran *PilotSquare* a total of five times. The *OdometryPoseProvider* provided end coordinates deviating by an average of 0.057 cm on the x-axis and 0.054 cm on the y-axis. Thus, we see no remarkable improvement compared to the pre-calibration runs (0.059 on the x-axis and 0.061 on the y-axis) - considering that we only performed five runs, the small difference may very well be due to non-systematic errors and variations. The average deviation of the angle, 0.469, is nearly twice that obtained before the calibration, but the magnitude of these deviations is so small that they could still be random.
|
|
|
|
|
... | @@ -145,7 +136,7 @@ During the five runs, we found our ending position to be randomly distributed ar |
... | @@ -145,7 +136,7 @@ During the five runs, we found our ending position to be randomly distributed ar |
|
|
|
|
|
![Plotting the OdometryPoseProvider’s info on PilotSquare after calibration](https://gitlab.au.dk/LEGO/lego-kode/raw/master/week13/img/calibratedsquare_ends.png)
|
|
![Plotting the OdometryPoseProvider’s info on PilotSquare after calibration](https://gitlab.au.dk/LEGO/lego-kode/raw/master/week13/img/calibratedsquare_ends.png)
|
|
|
|
|
|
*Figure 8: Plot of the OdometryPoseProvider’s readings.*
|
|
*Figure 8: Plot of the OdometryPoseProvider’s readings. The red dot marks (0,0), i.e. the desired end point.*
|
|
|
|
|
|
The offset center for the distribution might be caused by the accumulation of small errors in travels and turns. A way to investigate this could be to see how making right turns instead of left turns would affect the position of the end point.
|
|
The offset center for the distribution might be caused by the accumulation of small errors in travels and turns. A way to investigate this could be to see how making right turns instead of left turns would affect the position of the end point.
|
|
|
|
|
... | @@ -159,7 +150,7 @@ In determining the non-systematic error, we discussed the fact that we still hav |
... | @@ -159,7 +150,7 @@ In determining the non-systematic error, we discussed the fact that we still hav |
|
|
|
|
|
Additionally, we felt that the instructions were unclear as to whether the distance and angle noise variables are supposed to be the average of the noise distribution, or the maximum deviation in distance/angle. We made a gut feeling decision that the average made the most sense and went with that.
|
|
Additionally, we felt that the instructions were unclear as to whether the distance and angle noise variables are supposed to be the average of the noise distribution, or the maximum deviation in distance/angle. We made a gut feeling decision that the average made the most sense and went with that.
|
|
|
|
|
|
We first ran *WheelCalibration* which drives the robot 50 cm forward, repeating it five times. We then ran *TrackCalibration* which turns the robot 180 degrees, again repeating it five times. Table 1 and 2 contains the results of all ten runs. These measurements were all made with a ruler and a protractor but they are certainly influenced by human errors.
|
|
We first ran *WheelCalibration* which drives the robot 50 cm forward, repeating it five times. We then ran *TrackCalibration* which turns the robot 180 degrees, again repeating it five times. Table 1 and 2 contains the results of all ten runs. These measurements were all made with a ruler and a protractor but they are certainly influenced by human errors.
|
|
|
|
|
|
<table>
|
|
<table>
|
|
<tr>
|
|
<tr>
|
... | @@ -189,7 +180,7 @@ We first ran *WheelCalibration* which drives the robot 50 cm forward, repeating |
... | @@ -189,7 +180,7 @@ We first ran *WheelCalibration* which drives the robot 50 cm forward, repeating |
|
|
|
|
|
*Table 2: Angle error measured from the intended point to the actual point. In all runs the robot’s end position were at an angle larger than 180 degrees.*
|
|
*Table 2: Angle error measured from the intended point to the actual point. In all runs the robot’s end position were at an angle larger than 180 degrees.*
|
|
|
|
|
|
Running these tests, we once again noticed the effect of not quite correcting the systematic errors, as all of our distance and angle measurements are all slightly larger than desired. The average distance deviation is 1 cm and the average angle deviation is 2 degrees. This seems consistent with the systematic errors we noticed in our second iteration of *PilotSquare* runs, as all ending points were in the upper right quadrant of our paper (too far on the x-axis and with a slight turn). In the plot in Figure 8 we also see all points being located (almost) in the same quadrant - we note that the y-values in this plot are negative, but the sign difference from our own measurements might simply be due to us viewing the coordinate system of the paper track differently from the view of the *OdometryPoseProvider*.
|
|
Running these tests, we once again noticed the effect of not quite correcting the systematic errors, as all of our distance and angle measurements are all slightly larger than desired. The average distance deviation is 1 mm and the average angle deviation is 2 degrees. This seems consistent with the systematic errors we noticed in our second iteration of *PilotSquare* runs, as all ending points were in the upper right quadrant of our paper (too far on the x-axis and with a slight turn). In the plot in Figure 8 we also see all points being located (almost) in the same quadrant - we note that the y-values in this plot are negative, but the sign difference from our own measurements might simply be due to us viewing the coordinate system of the paper track differently from the view of the *OdometryPoseProvider*.
|
|
|
|
|
|
Readings from the ten runs described in this section are shown in the screenshots in Figure 9 and 10 below. The average angle error is 0.07 degrees, and the average deviation on distance is 0.023 cm (some values were negative - the average magnitude of the deviation is 0.025). As in all other cases, the differences are much smaller than what we observed visually, but the implications are still similar to those of our visual observations.
|
|
Readings from the ten runs described in this section are shown in the screenshots in Figure 9 and 10 below. The average angle error is 0.07 degrees, and the average deviation on distance is 0.023 cm (some values were negative - the average magnitude of the deviation is 0.025). As in all other cases, the differences are much smaller than what we observed visually, but the implications are still similar to those of our visual observations.
|
|
|
|
|
... | @@ -203,13 +194,15 @@ Readings from the ten runs described in this section are shown in the screenshot |
... | @@ -203,13 +194,15 @@ Readings from the ten runs described in this section are shown in the screenshot |
|
|
|
|
|
### Combining position tracking with avoiding objects
|
|
### Combining position tracking with avoiding objects
|
|
|
|
|
|
By utilizing the *OdometryPoseProvider*, it would possible for us to drive according to a fixed path using *DifferentialPilot* , and then stop the robot once it senses an object in front of it with the ultrasonic sensor. This should work provided that we let all our movement commands return immediately. Once the robot has stopped, we can then request our current estimated position by the pose provider and use this combined with our known desired destination to plan a new path towards the destination that avoids the encountered object. This process of encountering an object in our path, getting our current position and replanning a new path, can be repeated for as many randomly appearing/disappearing or moving objects as needed, until we reach our destination, provided that our pose provider is providing us with solid estimates of position. That is, provided that we have minimal errors, both systematic and non-systematic, we should be able to reach our destination fairly accurately.
|
|
By utilizing the *OdometryPoseProvider*, it would possible for us to drive according to a fixed path using *DifferentialPilot*, and then stop the robot once it senses an object in front of it with the ultrasonic sensor. This should work provided that we let all our movement commands return immediately. Once the robot has stopped, we can then request our current estimated position by the pose provider and use this combined with our known desired destination to plan a new path towards the destination that avoids the encountered object. This process of encountering an object in our path, getting our current position and replanning a new path, can be repeated for as many randomly appearing/disappearing or moving objects as needed, until we reach our destination, provided that our pose provider is providing us with solid estimates of position. That is, provided that we have minimal errors, both systematic and non-systematic, we should be able to reach our destination fairly accurately.
|
|
|
|
|
|
|
|
A very simple algorithm would be to approach your desired destination by moving along either the x-axis or the y-axis and if you encounter an object, you turn 90 degrees and move ‘along’ the object until you want to try to go towards your desired destination again. There would of course be some specific cases to handle such as corners, but this somewhat shows how position tracking by dead reckoning can be used to avoid objects and still stay enroute.
|
|
|
|
|
|
Additional considerations might include two ultrasonic sensors - aside from the one in the front, a sensor placed on the side could be used to detect when the robot has passed a blocking object.
|
|
Additional considerations might include two ultrasonic sensors - aside from the one in the front, a sensor placed on the side could be used to detect when the robot has passed a blocking object.
|
|
|
|
|
|
## **Conclusion**
|
|
## **Conclusion**
|
|
|
|
|
|
During these experiments we calibrated the wheel diameter and track width of our robot in an attempt to get rid of systematic errors, which in the case of wheel diameter largely improved the performance of our robot. We however observed that there wew still systematic errors remaining, but we would have to spend significant time fine-tuning the calibrations to get rid of them. At the same time, we conclude that on the two examples (driving 50 cm and turning 180 degrees) the robot performed almost perfectly, with the only note that we have calibrated for 49,5 cm instead of 50 cm as the lines on the paper track was 0.5 cm too short, wherefore we might have to perform a small recalibration next time.
|
|
During these experiments we calibrated the wheel diameter and track width of our robot in an attempt to get rid of systematic errors, which in the case of wheel diameter largely improved the performance of our robot. We however observed that there was still systematic errors remaining, but we would have to spend significant time fine-tuning the calibrations to get rid of them. At the same time, we conclude that on the two examples (driving 50 cm and turning 180 degrees) the robot performed almost perfectly, with the only note that we have calibrated for 49,5 cm instead of 50 cm as the lines on the paper track was 0.5 cm too short, wherefore we might have to perform a small recalibration next time.
|
|
|
|
|
|
Comparing observations performed by eye to values calculated by the *OdometryPoseProvider* has supported some of our observations, while being more or less inconclusive in other cases. A vital point that it helped support was the fact that when using calibrated values for the *PilotSquare*, the robot seems to always end up in the same quadrant. We have briefly discussed how the reason for this might be investigated further.
|
|
Comparing observations performed by eye to values calculated by the *OdometryPoseProvider* has supported some of our observations, while being more or less inconclusive in other cases. A vital point that it helped support was the fact that when using calibrated values for the *PilotSquare*, the robot seems to always end up in the same quadrant. We have briefly discussed how the reason for this might be investigated further.
|
|
|
|
|
... | | ... | |