|
|
# Lab Notebook 10
|
|
|
# **Lab Notebook 10**
|
|
|
|
|
|
**Date:** 20th of May 2016
|
|
|
|
|
|
**Group number:** Group 14
|
|
|
**Group number:** Group 14
|
|
|
|
|
|
**Group members participating:**
|
|
|
Camilla M. V. Frederiksen, Ida Larsen-Ledet, Nicolai Nibe and Emil Platz
|
|
|
**Group members participating:** Camilla M. V. Frederiksen, Ida Larsen-Ledet, Nicolai Nibe and Emil Platz
|
|
|
|
|
|
**Activity duration:** TODO hours
|
|
|
**Activity duration:** 5.5 hours
|
|
|
|
|
|
## Goal
|
|
|
... [lesson plan 10](http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson10.dir/Lesson.html).
|
|
|
## **Goal**
|
|
|
|
|
|
## Plan
|
|
|
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].
|
|
|
|
|
|
## Results
|
|
|
### Rebuilding the robot
|
|
|
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**
|
|
|
|
|
|
![TEMPLATE](LINK)
|
|
|
*Figure 1: TODO
|
|
|
Ida will be in charge of programming, Camilla and Emil will be in charge of performing the experiments, and Nicolai will be taking notes. Aside from performing the experiments, Camilla will also be in charge of documenting them by taking pictures and filming, labeling with post-it notes.
|
|
|
|
|
|
### TODO SUBHEADING
|
|
|
We plan to complete the work on Friday the 20th of May and so will continue working until we have completed all of the tasks specified in lesson plan 10.
|
|
|
|
|
|
[![TODO](LINK)](LINK)
|
|
|
*Video 1: TODO*
|
|
|
## **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.
|
|
|
|
|
|
#### TODO SUBSUBHEADING
|
|
|
![rebuilt robot build](https://gitlab.au.dk/LEGO/lego-kode/blob/master/week13/img/rebuild_robot_build.PNG)
|
|
|
|
|
|
*Figure 1: Rebuilt robot for precise tracking during the following exercises.*
|
|
|
|
|
|
## Conclusion
|
|
|
### Observing the accuracy of PilotSquare.java
|
|
|
|
|
|
## References
|
|
|
[1] Rodney Brooks, [A robust layered control system for a mobile robot](http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=1087032), IEEE Journal of Robotics and Automation, RA-2(1):14-23, 1986
|
|
|
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.
|
|
|
|
|
|
[2] Jones, Flynn, and Seiger, ["Mobile Robots, Inspiration to Implementation"](http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson7.dir/11128_Mobile_Robots_Inspiration_to_Implementation-Flynn_and_Jones.pdf), Second Edition, 1999.
|
|
|
![Robot on precision paper](https://gitlab.au.dk/LEGO/lego-kode/blob/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.
|
|
|
|
|
|
![Changed position of orange pointer](https://gitlab.au.dk/LEGO/lego-kode/blob/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.
|
|
|
|
|
|
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).
|
|
|
|
|
|
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: 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
|
|
|
|
|
|
![Screenshots of pose provider’s info on PilotSquare before calibration](https://gitlab.au.dk/LEGO/lego-kode/blob/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.*
|
|
|
|
|
|
### Calibration of wheel diameter and track width
|
|
|
|
|
|
#### 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.
|
|
|
|
|
|
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.
|
|
|
|
|
|
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.
|
|
|
|
|
|
[![First wheelCalibrate run](http://img.youtube.com/vi/DYoANyNwRMQ/0.jpg)](https://www.youtube.com/watch?v=DYoANyNwRMQ)
|
|
|
|
|
|
*Video 1: The robot running the wheelCalibrate program with 6.3 cm as wheel diameter*
|
|
|
|
|
|
We figured that since the robot wasn’t driving far enough, the program must have been treating the wheels as being larger than they actually were, whereby they were not performing enough revolutions to make the robot drive 50 cm. In order to calibrate the wheel diameter to get the robot to drive the correct distance, we would therefore have to lower the values supplied for *wheelDiameter*. Since the deviation was so big - more than 10 % from the specified distance - we decided to measure the wheels again, to see if we had made an error.
|
|
|
|
|
|
After re-measuring the wheels, we realised that we messed up our initial measurements because the person reading the value misread it: The wheels were actually both 5.6 cm. We reran the program with the updated diameter values.
|
|
|
|
|
|
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.
|
|
|
|
|
|
[![Third run of wheel calibration](http://img.youtube.com/vi/kab8L6PIzBM/0.jpg)](https://www.youtube.com/watch?v=kab8L6PIzBM)
|
|
|
|
|
|
*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.
|
|
|
|
|
|
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.
|
|
|
|
|
|
[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.
|
|
|
|
|
|
[![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.
|
|
|
|
|
|
![Screenshots of pose provider’s info on WheelCalibration](https://gitlab.au.dk/LEGO/lego-kode/blob/master/week13/img/wheel_calibration.PNG)
|
|
|
|
|
|
*Figure TODO: 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.
|
|
|
|
|
|
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 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.
|
|
|
|
|
|
![Position before track calibration](https://gitlab.au.dk/LEGO/lego-kode/blob/master/week13/img/IMG_2399.JPG)
|
|
|
|
|
|
*Figure 4: 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 https://gitlab.au.dk/LEGO/lego-kode/blob/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]
|
|
|
|
|
|
#### 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 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.
|
|
|
|
|
|
![Screenshots of the OdometryPoseProvider’s info on PilotSquare after calibration](https://gitlab.au.dk/LEGO/lego-kode/blob/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.*
|
|
|
|
|
|
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.
|
|
|
|
|
|
![Plotting the OdometryPoseProvider’s info on PilotSquare after calibration](https://gitlab.au.dk/LEGO/lego-kode/blob/master/week13/img/calibratedsquare_ends.PNG)
|
|
|
|
|
|
*Figure TODO: Plot of the OdometryPoseProvider’s readings.*
|
|
|
|
|
|
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.
|
|
|
|
|
|
### Working with particle filters
|
|
|
|
|
|
#### 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.
|
|
|
|
|
|
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.
|
|
|
|
|
|
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.
|
|
|
|
|
|
<table>
|
|
|
<tr>
|
|
|
<td>Distance error</td>
|
|
|
<td>0 mm</td>
|
|
|
<td>1 mm</td>
|
|
|
<td>1.5 mm</td>
|
|
|
<td>2.5 mm</td>
|
|
|
<td>0 mm</td>
|
|
|
</tr>
|
|
|
</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>
|
|
|
<tr>
|
|
|
<td>Angle error</td>
|
|
|
<td>3.5°</td>
|
|
|
<td>2°</td>
|
|
|
<td>2.5°</td>
|
|
|
<td>2°</td>
|
|
|
<td>0°</td>
|
|
|
</tr>
|
|
|
</table>
|
|
|
|
|
|
|
|
|
*Table 2: Angle error measured from the intended point to the actual point.*
|
|
|
|
|
|
[Note: All angles too far over 180]
|
|
|
|
|
|
![Screenshots of pose providers info on WheelCalibration after calibration](https://gitlab.au.dk/LEGO/lego-kode/blob/master/week13/img/calibrated_line.PNG)
|
|
|
|
|
|
*Figure TODO*: [blabla]
|
|
|
|
|
|
![Screenshots of pose providers info on TrackCalibration after calibration](https://gitlab.au.dk/LEGO/lego-kode/blob/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).
|
|
|
|
|
|
### 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, 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)
|
|
|
|
|
|
## **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.
|
|
|
|
|
|
[TODO konklusion for non-systematiske fejl og partikelfiltre]
|
|
|
|
|
|
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")
|
|
|
|
|
|
## **References**
|
|
|
|
|
|
[1] Borenstein, Everett and Feng, [*Where am I? Sensors and Methods for Mobile Robot Positioning*](http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson10.dir/pos96rep.pdf), University of Michigan, 1996
|
|
|
|
|
|
[2] [Monte Carlo localization](https://en.wikipedia.org/wiki/Monte_Carlo_localization) (Wikipedia)
|
|
|
|
|
|
[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)
|
|
|
|
|
|
[5] 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))
|
|
|
|
|
|
[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 track width calibration, [TrackCalibration.java]([https://gitlab.au.dk/LEGO/lego-kode/blob/master/src/Lesson10programs/NXT/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]
|
|
|
|
|
|
[?] [Video 1]([https://www.youtube.com/watch?v=](https://www.youtube.com/watch?v=lLlhimXuy6I)DYoANyNwRMQ)
|
|
|
|
|
|
[?] [Video 2]([https://www.youtube.com/watch?v=](https://www.youtube.com/watch?v=lLlhimXuy6I)kab8L6PIzBM)
|
|
|
|
|
|
[?] [Video 3]([https://www.youtube.com/watch?v=](https://www.youtube.com/watch?v=lLlhimXuy6I)dCpuXGpKxfQ)
|
|
|
|
|
|
[?] [Video 4](https://www.youtube.com/watch?v=7UQpdAVc95k)
|
|
|
|
|
|
[3] Fred G. Martin, Robotic Explorations: A Hands-on Introduction to Engineering, Prentice Hall, 2001. |