... | ... | @@ -12,7 +12,7 @@ |
|
|
|
|
|
The purpose of this lesson is to obtain an understanding of position tracking using odometry, and our work will constitute preliminary work for lesson 11, in which the goal will be to create a robot that is able to stay within a certain area at Aarhus Central Station using Monte Carlo localization [2].
|
|
|
|
|
|
As specified in the [lesson plan](http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson10.dir/Lesson.html), in this lesson we will investigate how the use of odometry [1, Chapter 1, page 19] and the NXT motor’s tacho counter can aid in keeping track of the position of a LEGO car using a differential drive. To perform the exercises, we will also need to investigate how the leJOS classes *DifferentialPilot* and *OdometryPoseProvider* make use of odometry to keep track of the car’s position. Additionally, we will determine the accuracy of the odometry estimates of the position provided by these two classes.
|
|
|
As specified in the [lesson plan](http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson10.dir/Lesson.html), in this lesson we will investigate how the use of odometry [1, Chapter 1, page 19] and the NXT motor’s tacho counter can aid in keeping track of the position of a LEGO car using a differential drive. To perform the exercises, we will also need to investigate how the leJOS classes **DifferentialPilot** and **OdometryPoseProvider** make use of odometry to keep track of the car’s position. Additionally, we will determine the accuracy of the odometry estimates of the position provided by these two classes.
|
|
|
|
|
|
## **Plan**
|
|
|
|
... | ... | @@ -22,39 +22,39 @@ We plan to complete the work on Friday the 20th of May and so will continue work |
|
|
|
|
|
## **Result****s**
|
|
|
|
|
|
We started by stripping the robot of all the gear from the sumo wrestling tournament, and rebuilt it to the base ExpressBot. Then we attached the tiny orange pointer in the front, to use for measuring movement precision as seen in Figure 1.
|
|
|
We started by stripping the robot of all the gear from the sumo wrestling tournament and rebuilt it to the Express-Bot base [4, page 2]. Then we attached the tiny orange pointer in the front, to use for measuring movement precision. The rebuilt robot can be seen in Figure 1.
|
|
|
|
|
|
![rebuilt robot build](https://gitlab.au.dk/LEGO/lego-kode/raw/master/week13/img/rebuild_robot_build.PNG)
|
|
|
|
|
|
*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.
|
|
|
|
|
|
### Observing the accuracy of PilotSquare.java
|
|
|
|
|
|
We ran the **_PilotSquare.java_** [5] on the NXT that would cause the robot to drive in a simple square using the *DifferentialPilot*, by starting the robot on the 0.5 cm divisioned piece of paper, and positioning it such that the pointer was at the center, as seen in Figure 2.
|
|
|
We ran **_PilotSquare.java_** [6] which makes the robot drive in a square using the *DifferentialPilot*, starting the robot on a piece of paper divisioned into a 0.5 cm x 0.5 cm grid, positioning it such that the pointer was at the center of the grid, as shown in Figure 2.
|
|
|
|
|
|
The *DifferentialPilot* used in [6] is initialized with a wheel diameter of 5.5 (cm) and a track width of 16.0 (cm). These parameters will be described and discussed further in the next section.
|
|
|
|
|
|
![Robot on precision paper](https://gitlab.au.dk/LEGO/lego-kode/raw/master/week13/img/IMG_2378.JPG)
|
|
|
|
|
|
*Figure 2: Robot placed on paper prior to PilotSquare run*
|
|
|
|
|
|
Our initial run failed miserably because we had positioned the orange pointer too low so it was scraping along the table and interrupting the robot’s movements. We repositioned it as seen in Figure 3.a, which made it a bit harder to position the robot precisely as seen in Figure 3.b.
|
|
|
Our initial run failed miserably because we had positioned the orange pointer too low so it was scraping the table and interrupting the robot’s movements. We repositioned it as shown in Figure 3a, which made it a bit harder to position the robot precisely - shown in Figure 3b.
|
|
|
|
|
|
![Changed position of orange pointer](https://gitlab.au.dk/LEGO/lego-kode/raw/master/week13/img/orange_pointer_reposition.PNG)
|
|
|
|
|
|
*Figure 3: Reposition of the orange pointer and the effect on start position placement*
|
|
|
|
|
|
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 centimeters. However, we noticed that the robot was actively moving the paper around on the table when it was turning/accelerating, which appeared to be a major problem, so we wanted to rerun again while keeping the paper steady.
|
|
|
*Figure 3: Reposition of the orange pointer (3a) and the effect on start position placement (3b)*
|
|
|
|
|
|
Third run, after failing to find any duct tape to fasten the paper, we ran it the program while having two people press down on the paper during side to prevent it slipping. The final position off the center was however still fairly large, at 7.5 mm along the x-axis, and 30 mm up the y-axis (we decided to switch to logging distance in the two axes, instead of a direct total distance).
|
|
|
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.
|
|
|
|
|
|
We did another fourth and fifth run and saw that the robot moved to the same final position incredibly accurately, even though it was far off center. The final position deviated by only about 2-3 mm at most. We figured this indicated that given some calibration of some of our variables, such as *wheelDiameter* and *trackWidth*, we’d be able to get a consistently accurate run, which lead us to the next exercise.
|
|
|
[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]
|
|
|
|
|
|
[TODO: Should this be somewhere else?] (Lyder fint her, hvis der menes det ovenstående. Måske skal følgende pose-provider info flettes ind ovenfor, så sidste sætning i dette afsnit ender med ‘which lead us to the next exercise.’ /Camilla)
|
|
|
|
|
|
IDATODO: INDARBEJD I OVENSTÅENDE
|
|
|
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*.
|
|
|
|
|
|
![Screenshots of pose provider’s info on PilotSquare before calibration](https://gitlab.au.dk/LEGO/lego-kode/raw/master/week13/img/square.PNG)
|
|
|
|
|
|
*Figure TODO: Screenshots of the end location info computed by the OdometryPoseProvider on four runs of PilotSquare before calibration. The values shown on the screenshot are differences on the x-axis (Pose x) and the y-axis (Pose y), and the difference in angle (Pose v). The average size of the deviation is 0.059 on the x-axis, 0.061 on the y-axis, and 0.247 on the angle.*
|
|
|
*Figure 4: Screenshots of the end location info computed by the OdometryPoseProvider on four runs of PilotSquare before calibration. The values shown on the screenshot are differences on the x-axis (Pose x) and the y-axis (Pose y), and the difference in angle (Pose v). The average size of the deviation is 0.059 on the x-axis, 0.061 on the y-axis, and 0.247 on the angle. Due to a mistake, the order of the displayed readings does not match the order that the runs were performed in.*
|
|
|
|
|
|
### Calibration of wheel diameter and track width
|
|
|
|
... | ... | @@ -64,7 +64,7 @@ The leJOS *DifferentialPilot* constructor requires values for the the wheel diam |
|
|
|
|
|
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 wrote a program, **_wheelCalibration.java_** [6], for this. It uses a *DifferentialPilot* instance taking both **leftWheelDiameter** and **rightWheelDiameter** as arguments to simply drive 50 cm forward and then stop the robot. Supplied with the newly measured diameter values, it would allow us to check that the robot did in fact move 50 cm when using these values.
|
|
|
We wrote a program, **_wheelCalibration.java_** [7], for this. It uses a *DifferentialPilot* instance taking both **leftWheelDiameter** and **rightWheelDiameter** as arguments to simply drive 50 cm forward and then stop the robot. Supplied with the newly measured diameter values, it would allow us to check that the robot did in fact move 50 cm when using these values.
|
|
|
|
|
|
On the first run, the robot only drove about 44.5 cm along the line. It did, however, also appear to drive a little skewed from the proper direct course, but nowhere near enough to account for the missing 5.5 centimeters. This run can be seen in Video 1.
|
|
|
|
... | ... | @@ -78,7 +78,7 @@ After re-measuring the wheels, we realised that we messed up our initial measure |
|
|
|
|
|
The second run got much closer to the specified distance. However, we realised as we started the run that the back wheel was not properly positioned, causing the robot to shift slightly in the beginning as the wheel got aligned with the course. We therefore redid the run.
|
|
|
|
|
|
As we prepared this third run, we made sure to fix the back wheel to be properly positioned to prevent any initial skew like the one described before. In this run, the robot ended up almost perfectly on the 50 cm mark on the papers handed out at the lab session, and about 1 cm off to the left of the y-axis marked by a line. This can be seen in Video 2.
|
|
|
As we prepared this third run, we made sure to fix the back wheel to be properly positioned to prevent any initial skew like the one described before. In this run, the robot ended up almost perfectly on the 50 cm mark on the papers handed out at the lab session, and about 1 cm off to the left of the x-axis marked by a line. This can be seen in Video 2.
|
|
|
|
|
|
[![Third run of wheel calibration](http://img.youtube.com/vi/kab8L6PIzBM/0.jpg)](https://www.youtube.com/watch?v=kab8L6PIzBM)
|
|
|
|
... | ... | @@ -93,71 +93,61 @@ As the car was steering a bit towards the left of the line, we adjusted *leftWhe |
|
|
[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]
|
|
|
|
|
|
[TODO: det er ikke klart, hvad vi mener med y-direction, men vil ikke bare slette. Jeg synes vi skal skrive fremover eller til siden, da det er mere klart. /Camilla
|
|
|
|
|
|
Jeg fikser det /Ida]
|
|
|
|
|
|
[TODO: Har tilføjet lidt til "difference" delen så den del er mere klart. Jeg synes umiddelbart at forklaringerne i x og y-akser giver god mening, men hvis i er uenige må i gerne omformulere, jeg har bare ingen bedre måde at skrive det på -Nicolai]
|
|
|
|
|
|
[![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.*
|
|
|
|
|
|
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, 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.
|
|
|
|
|
|
[![Fifth run of wheel calibration](http://img.youtube.com/vi/7UQpdAVc95k/0.jpg)](https://www.youtube.com/watch?v=7UQpdAVc95k)
|
|
|
|
|
|
*Video 4: The robot running wheelCalibration with a wheel diameter of 5.6 cm.*
|
|
|
|
|
|
Despite basing our decisions on visual observations, we also noted the *OdometryPoseProvider*’s calculated end positions. These are shown in Figure TODO below. The deviations calculated by the *OdometryPoseProvider* are a lot smaller than the ones we observed. We weigh our visual observations higher than these, as the *OdometryPoseProvider* only reports values calculated based on tacho count and might miss some physical influences. Additionally, the deviations in the values reported by the *OdometryPoseProvider* are so small that it is hard to judge whether there are any improvements, which we have seen was indeed very feasible using our visual judgements.
|
|
|
Despite basing our decisions on visual observations, we also noted the *OdometryPoseProvider*’s calculated end positions. These are shown in Figure 5 below. The deviations calculated by the *OdometryPoseProvider* are a lot smaller than the ones we observed. We weigh our visual observations higher than these, as the *OdometryPoseProvider* only reports values calculated based on tacho count and might miss some physical influences. Additionally, the deviations in the values reported by the *OdometryPoseProvider* are so small that it is hard to judge whether there are any improvements, which we have seen was indeed very feasible using our visual judgements.
|
|
|
|
|
|
![Screenshots of pose provider’s info on WheelCalibration](https://gitlab.au.dk/LEGO/lego-kode/raw/master/week13/img/wheel_calibration.PNG)
|
|
|
|
|
|
*Figure TODO: Screenshots of the end location info computed by the OdometryPoseProvider on runs 2-5 of WheelCalibration.*
|
|
|
*Figure 5: Screenshots of the end location info computed by the OdometryPoseProvider on runs 2-5 of WheelCalibration.*
|
|
|
|
|
|
#### 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_** [7], 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.
|
|
|
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 wrote a program, **_trackCalibration.java_** [7], 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.
|
|
|
|
|
|
We placed the robot on the paper track, positioning the wheels on the same line and the orange pointer on another line perpendicular to the line that the wheels were placed on, as shown in Figure 4.
|
|
|
We placed the robot on the paper track, positioning the wheels on the same line and the orange pointer on another line perpendicular to the line that the wheels were placed on, as shown in Figure 6.
|
|
|
|
|
|
![Position before track calibration](https://gitlab.au.dk/LEGO/lego-kode/raw/master/week13/img/IMG_2399.JPG)
|
|
|
|
|
|
*Figure 4: Position of robot before running trackCalibration program.*
|
|
|
*Figure 6: Position of robot before running trackCalibration program.*
|
|
|
|
|
|
We then ran the program and found it to miraculously rotate a perfect 180 degrees (judging by eye) with our measured 16.2 cm set as the track width. The *OdometryPoseProvider* reported an angle of -179,9012 degrees, confirming our observation (see [the screenshots](https://gitlab.au.dk/LEGO/lego-kode/raw/master/week13/img/trackcal.JPG)). As this by far lived up to the precision obtained during our wheel calibration, we did not try to do any calibration on the track width.
|
|
|
|
|
|
[Har valgt at udelade en video af track-caliebration, fordi videoen virkelig er dårlig! /Camilla
|
|
|
|
|
|
TODO: Vi kunne eventuelt skrive det - "We do not have a video showing the track width run, due to issues with our recording of it" /Ida]
|
|
|
We do not have a video showing the track width run, due to issues with our recording of it.
|
|
|
|
|
|
#### Re-running PilotSquare
|
|
|
|
|
|
We changed *PilotSquare* to use the calibrated values, i.e. *wheelDiameter* = 5.6 and *trackWidth* = 16.2 [TODO: har vi skrevet, hvad værdierne oprindeligt var?], and re-ran it on the paper track. We judged the final position this time to be approximately 2.5 mm to the right on the y-axis on the paper, and 6 mm up on the x-axis on the paper, a significant improvement to our previous run.
|
|
|
|
|
|
However, on the GUI display, the *OdometryPoseProvider* showed that it believed the robot to be much further off from the center than we were in our original run of *PilotSquare*. We believe this to be a result of…[TODO]
|
|
|
|
|
|
[TODO: insert fancy explanation of why the pose provider thinks we are at a different place because of calibrated values not being our real values.. THIS IS PROBLEM!?? Pose provider thinks we’re way the fuck off from real position, cause we calibrated based on real world]
|
|
|
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 ran *PilotSquare* a total of five times. The *OdometryPoseProvider* provided end coordinates deviating by an average of 0.057 cm on its x-axis and 0.054 cm on its 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.
|
|
|
|
|
|
![Screenshots of the OdometryPoseProvider’s info on PilotSquare after calibration](https://gitlab.au.dk/LEGO/lego-kode/raw/master/week13/img/calibrated_square.PNG)
|
|
|
|
|
|
*Figure TODO: Screenshots of the end location info computed by the OdometryPoseProvider on four runs of PilotSquare **after** calibration. The average size of the deviation is 0.057 on the x-axis, 0.054 on the y-axis, and 0.469 on the angle.*
|
|
|
*Figure 7: Screenshots of the end location info computed by the OdometryPoseProvider on four runs of PilotSquare **after** calibration. The average size of the deviation is 0.057 on the x-axis, 0.054 on the y-axis, and 0.469 on the angle. Due to a mistake, the order of the displayed readings does not match the order that the runs were performed in.*
|
|
|
|
|
|
During the five runs, we found our ending position to be randomly distributed around a point that was not exactly our origin point, but around 0.5 cm away from it - again, judging by eye. Plotting the readings shown in Figure TODO above, we obtain a pattern that supports this observation - see Figure TODO below.
|
|
|
During the five runs, we found our ending position to be randomly distributed around a point that was not exactly our origin point, but around 0.5 cm away from it - again, judging by eye. Plotting the readings shown in Figure 7, we obtain a pattern that supports this observation - see Figure 8.
|
|
|
|
|
|
![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 TODO: Plot of the OdometryPoseProvider’s readings.*
|
|
|
*Figure 8: Plot of the OdometryPoseProvider’s readings.*
|
|
|
|
|
|
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.
|
|
|
|
|
|
We decided not to attempt tweaking the calibration further to approach the exact origin point, as this would probably take a long time and we felt that we had achieved a calibration good enough for the purpose of the task, giving us a solid feeling for the effect of calibrating the wheel diameter and the track width.
|
|
|
|
... | ... | @@ -165,11 +155,11 @@ We decided not to attempt tweaking the calibration further to approach the exact |
|
|
|
|
|
#### Non-systematic errors
|
|
|
|
|
|
In determining our non-systematic error, a problem we discussed was that we still have some systematic error unresolved. However, we decided that we could still reasonably well test distance noise and angle noise by testing the random distribution using the previous two singular runs of driving forward 50 cm and turning 180 degrees, respectively, as we calibrated around these, they should have a random distribution around our actual desired final location, as opposed to our combination of drives and turns, which in our *PilotSquare* tests appeared to have a random distribution around a point slightly off our desired final destination.
|
|
|
In determining the non-systematic error, we discussed the fact that we still have some systematic error unresolved, which might prove problematic. However, we decided that we could still test distance noise and angle noise reasonably well by testing the random distribution using *WheelCalibration.java* and *TrackCalibration.java*. Since we performed calibration using these, they should have a random distribution around our desired final location, as opposed to the combination of drives and turns in *PilotSquare.java* which appeared to have a random distribution around a point slightly off our desired final destination.
|
|
|
|
|
|
Additionally, we felt it unclear in the instructions whether the distance and angle noise variables are supposed to be the average of the noise distribution, or the worst-case maximum difference 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* that drives 50 cm forward, repeating it 5 times. Then we ran *trackCalibration* that turns the robot 180 degrees, again repeating it 5 times. Table 1 and 2 contains the results of all ten runs. Worth noting is that these were all done with rulers and angle measurers, but is 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>
|
|
|
<tr>
|
... | ... | @@ -183,9 +173,7 @@ We first ran *wheelCalibration* that drives 50 cm forward, repeating it 5 times. |
|
|
</table>
|
|
|
|
|
|
|
|
|
*Table 1: Distance error measured from the intended point to the actual point.*
|
|
|
|
|
|
[Note: All distances were on the same end, too far forward]
|
|
|
*Table 1: Distance error measured from the intended point to the actual point. In all runs the robot went further than 50 cm.*
|
|
|
|
|
|
<table>
|
|
|
<tr>
|
... | ... | @@ -199,83 +187,33 @@ We first ran *wheelCalibration* that drives 50 cm forward, repeating it 5 times. |
|
|
</table>
|
|
|
|
|
|
|
|
|
*Table 2: Angle error measured from the intended point to the actual point.*
|
|
|
*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*.
|
|
|
|
|
|
[Note: All angles too far over 180]
|
|
|
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.
|
|
|
|
|
|
![Screenshots of pose providers info on WheelCalibration after calibration](https://gitlab.au.dk/LEGO/lego-kode/raw/master/week13/img/calibrated_line.PNG)
|
|
|
|
|
|
*Figure TODO*: [blabla]
|
|
|
*Figure 9: The OdometryPoseProvider’s reportings on the five runs of WheelCalibration. Due to a mistake, the order of the displayed readings does not match the order that the runs were performed in.*
|
|
|
|
|
|
![Screenshots of pose providers info on TrackCalibration after calibration](https://gitlab.au.dk/LEGO/lego-kode/raw/master/week13/img/calibrated_180.PNG)
|
|
|
|
|
|
*Figure TODO*: [blabla]
|
|
|
|
|
|
[Har efterladt resten af dette afsnit til Ida, da hun ville tilføje beregninger, og jeg ikke vil binde hende til specifikke formuleringer /Camilla - Cool. Jeg får først skrevet på det mandag /Ida]
|
|
|
|
|
|
[OBS: Beregningerne er i et Sheets-dokument - skriver om det mandag, eller måske i morgen aften - skal fejre fødselsdag med min far og ved ikke helt, hvad vi skal, så det kommer an på det :)]
|
|
|
|
|
|
After running these tests again, we can once again seem to notice our remaining systematic errors, as all our distance and angle errors are all slightly above our intended destination. As such, it seems our errors are distributed in an area around roughly [TODO: Complete estimation] 1.5 cm higher, and 2° higher than intended. This also 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 along both axes).
|
|
|
|
|
|
#### (Odometry Pose Provider considerations)
|
|
|
|
|
|
[TODO inkludér i resten af teksten]
|
|
|
|
|
|
[Jeg føler ikke, at jeg kan før resten er skrevet /Camilla]
|
|
|
|
|
|
If we wanted to test if the larger deviation on PilotSquare compared to the calibration tests were due to an accumulation of small errors from travels and turns, we could for instance try to let PilotSquare turn right instead of left, so see if the deviation would then be skewed in a different direction (TODO: omformulér og inkludér i samlet tekst).
|
|
|
*Figure 10*: *The OdometryPoseProvider’s reportings on the five runs of TrackCalibration. Due to a mistake, the order of the displayed readings does not match the order that the runs were performed in.*
|
|
|
|
|
|
### Combining position tracking with avoiding objects
|
|
|
|
|
|
[TODO: Nedenunder er alt hvad jeg føler der er at sige, men efterlader noterne og denne TODO in-case nogen føler de har noget klogt at tilføje, specielt Ida da jeg tror hun har bedre styr på PoseProvider -Nicolai]
|
|
|
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, provided we do all our movement commands with immediate returns. Once 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 it 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, and provided that our pose provider is providing us with solid estimates of position, that is to mean we have minimal errors both systematic and non-systematic, then we should still be able to reach our destination fairly accurately.
|
|
|
|
|
|
Discussion:
|
|
|
|
|
|
* Use 2 Ultrasonic sensors, front and right side
|
|
|
|
|
|
* On object in front: turn 90° left, drive till right side is free, then turn 90° right
|
|
|
|
|
|
* Continue till right side is free. Once free of object, try to drive back to destination based on current pose from PoseProvider (x, y) and desired destination
|
|
|
|
|
|
Note: Above is shitty concrete example.
|
|
|
|
|
|
**Primary point**:
|
|
|
|
|
|
On see object - Dodge until free (Attempting to avoid while driving in direction of desired x, y destination)
|
|
|
|
|
|
On free of object - Drive towards desired x, y destination, based on current ‘known’ x, y position from Pose Provider (Which uses Dead Reckoning to decide our position)
|
|
|
|
|
|
Important Note: Pose doesn’t update continuously during driving, but when we do immediate return and then stop the robot, we can get the current pose.
|
|
|
|
|
|
Alpha-omega: We can, using the Pose Provider, always ‘know’ where we are (x, y, theta). And we know where we should go, so when knowing objects location, with ultrasonic sensors, we can use this data to plan new path
|
|
|
|
|
|
Idas noter:
|
|
|
|
|
|
* DifferentialPilot implementerer MoveProvider
|
|
|
(jf. [http://www.lejos.org/nxt/nxj/api/lejos/robotics/navigation/MoveProvider.html](http://www.lejos.org/nxt/nxj/api/lejos/robotics/navigation/MoveProvider.html))
|
|
|
→ OdometryPoseProvider skal have vores DifferentialPilot-instans som argument
|
|
|
|
|
|
* Det er muligt at genbruge Move-objekter, jf. setValues() i [http://www.lejos.org/nxt/nxj/api/lejos/robotics/navigation/Move.html](http://www.lejos.org/nxt/nxj/api/lejos/robotics/navigation/Move.html)
|
|
|
|
|
|
* Hvis ting repræsenteres vha. punkter, vil robotten ramme ind i deres kanter, jf. [http://www.lejos.org/nxt/nxj/tutorial/WheeledVehicles/WheeledVehicles.htm](http://www.lejos.org/nxt/nxj/tutorial/WheeledVehicles/WheeledVehicles.htm)
|
|
|
|
|
|
## Thoughts on lesson 11
|
|
|
|
|
|
TODO: Hvis vi når at snakke om det det, kunne vi skrive noget her om, hvordan vi vil bruge det, som vi har lært i lesson 10, i lesson 11 /Ida
|
|
|
|
|
|
* re-calibrate robot to fit our ruler, not the testing paper (as we will be using the ruler to measure the world that we will act in)
|
|
|
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**
|
|
|
|
|
|
During these experiments we calibrated the wheel diameter and track width of our specific robot in an attempt to get rid of systematic errors which in case of wheel diameter largely increased performance. We however observed that we still had some systematic errors that we would have to spend significant time fine tuning the calibrations to get rid of. 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 measurement papir seemed to bit 0,5 cm too short, why 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 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.
|
|
|
|
|
|
[TODO konklusion for non-systematiske fejl og partikelfiltre]
|
|
|
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.
|
|
|
|
|
|
Lastly we discussed how it would be possible to use the pose provider to drive a desired fixed route while simultaneously pathing around unknown blocking objects.
|
|
|
|
|
|
TODO: Kort konklusion på, hvordan det, vi har lært her, kan bruges i Lesson 11 (i.e. evt. opsummering af "Thoughts on lesson 11")
|
|
|
Lastly we discussed how it would be possible to use the pose provider to drive a desired fixed route while simultaneously pathing around unknown blocking objects, which is the task for lesson 11. As mentioned earlier in this report, in lesson 11 we will probably also be able to benefit from re-calibrating our wheel diameters and track width to fit our ruler or a tape measure, and not the paper track, as we will want the values to be fitted against the real world that our robot will be acting in, which we will most likely not measure using the paper track. The use of additional decimal points in the values provided to the constructor of *DifferentialPilot* might also help us increase precision.
|
|
|
|
|
|
## **References**
|
|
|
|
... | ... | @@ -285,23 +223,25 @@ TODO: Kort konklusion på, hvordan det, vi har lært her, kan bruges i Lesson 11 |
|
|
|
|
|
[3] Borenstein and Feng, (Measurement and correction of systematic odometry errors in mobile robots)[http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson10.dir/paper58.pdf], Robotics and Automation, IEEE Transactions on (Volume:12 , Issue: 6 ), 1995
|
|
|
|
|
|
[4] [A leJOS tutorial on controlling wheeled vehicles](http://www.lejos.org/nxt/nxj/tutorial/WheeledVehicles/WheeledVehicles.htm)
|
|
|
[4] [The Express-Bot](http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson6.dir/ExpressBot.pdf)
|
|
|
|
|
|
[5] [A leJOS tutorial on controlling wheeled vehicles](http://www.lejos.org/nxt/nxj/tutorial/WheeledVehicles/WheeledVehicles.htm)
|
|
|
|
|
|
[5] Ole Caprani’s implementation of [PilotSquare
|
|
|
[6] Ole Caprani’s implementation of [PilotSquare
|
|
|
|
|
|
.java]([http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson10.dir/LessonPrograms/NXT/PilotSquare.java](http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson10.dir/LessonPrograms/NXT/PilotSquare.java))
|
|
|
.java](http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson10.dir/LessonPrograms/NXT/PilotSquare.java)
|
|
|
|
|
|
[6] Our program for wheel calibration, [WheelCalibration.java](https://gitlab.au.dk/LEGO/lego-kode/blob/master/src/Lesson10programs/NXT/WheelCalibration.java)
|
|
|
[7] Our program for wheel calibration, [WheelCalibration.java](https://gitlab.au.dk/LEGO/lego-kode/blob/master/src/Lesson10programs/NXT/WheelCalibration.java)
|
|
|
|
|
|
[7] Our program for track width calibration, [TrackCalibration.java]([https://gitlab.au.dk/LEGO/lego-kode/](https://gitlab.au.dk/LEGO/lego-kode/blob/master/src/Lesson10programs/NXT/TrackCalibration.java)[blob](https://gitlab.au.dk/LEGO/lego-kode/blob/master/src/Lesson10programs/NXT/TrackCalibration.java)[/master/src/Lesson10programs/NXT/TrackCalibration.java](https://gitlab.au.dk/LEGO/lego-kode/blob/master/src/Lesson10programs/NXT/TrackCalibration.java))
|
|
|
[8] Our program for track width calibration, [TrackCalibration.java](https://gitlab.au.dk/LEGO/lego-kode/blob/master/src/Lesson10programs/NXT/TrackCalibration.java)
|
|
|
|
|
|
[TODO: fix nr. når vi er færdige]
|
|
|
[9] lejos.robotics.location.odometryposeprovider
|
|
|
|
|
|
[?] [Video 1]([https://www.youtube.com/watch?v=](https://www.youtube.com/watch?v=lLlhimXuy6I)DYoANyNwRMQ)
|
|
|
[10] [Video 1](https://www.youtube.com/watch?v=DYoANyNwRMQ)
|
|
|
|
|
|
[?] [Video 2]([https://www.youtube.com/watch?v=](https://www.youtube.com/watch?v=lLlhimXuy6I)kab8L6PIzBM)
|
|
|
[11] [Video 2](https://www.youtube.com/watch?v=kab8L6PIzBM)
|
|
|
|
|
|
[?] [Video 3]([https://www.youtube.com/watch?v=](https://www.youtube.com/watch?v=lLlhimXuy6I)dCpuXGpKxfQ)
|
|
|
[12] [Video 3](https://www.youtube.com/watch?v=dCpuXGpKxfQ)
|
|
|
|
|
|
[?] [Video 4](https://www.youtube.com/watch?v=7UQpdAVc95k)
|
|
|
[13] [Video 4](https://www.youtube.com/watch?v=7UQpdAVc95k)
|
|
|
|