Is everyone finding great success with the GPS in their autonomous skills program, or are you using the inertial sensor more?
I have never heard of a successful team using the GPS sensor.
1 Like
The best thing you can ever do when evaluating the efficacy of two different sensors is to test them yourself in your own use case. However, I understand that the sensor has a pretty steep price, so here is my advice and experience:
The inertial sensor is practically a necessity in autonomous. It is very good at its job, and with some good methods it will keep your robot on track quite well. The GPS is a good alternative to odometry for a quick and easy absolute positioning system, but you sacrifice accuracy and time, as the GPS largely is only useful when the robot is at rest. When given 1-2s to take a snapshot, the GPS can be very helpful in determining your position on the field, but if your goal is real-time updating on a consistent basis, the GPS will provide very little help.
4 Likes
the GPS sensor is honestly not good. Needs tape (which most fields donât even have), really big and clunky (and needs a camera), updates pos pretty slowly⌠using the inertial sensor + odometry is wayy more accurate + not field dependent.
Not sure why you think this, the GPS updates somewhere around 25 times per second.
4 Likes
While that may be the technical spec for the data rate, the accuracy of the data from the device while moving does seem inferior to odometry-based position tracking, at least based on what my graduated teamâs experiences with the device were. From what I recall, they put the GPS device (and a second) on a robot in the hopes of using the sensor to feed their pure-pursuit movement to less than satisfactory results. Swapping the GPS for odometry led to better results. Itâs been a couple years, but from what I recall, I think the GPSâs reported heading data was particularly unreliable. I think they started to try to use an EWMA to smooth the heading reading over time, but I think they still wound up coming to the conclusion that the sensor wasnât worth the effort.
I think they also then went so far as to try to use the GPS device to assist with ânext-movementâ planning, akin to:
// Pseudocode
chassis.setPosition(0_ft,0_ft,0_degrees);
chassis.moveTo(1_ft, 2_ft, 90_degrees);
gps_actual = gps.getPosition();
chassis.setPosition(gps_actual.x, gps_actual.y, gps_actual.heading);
chassis.moveTo(2_ft, 2_ft, 180_degrees);
// ... etc.
Which wound up turning into:
// Pseudocode
chassis.setPosition(0_ft,0_ft,0_degrees);
chassis.moveTo(1_ft, 2_ft, 90_degrees);
wait(GPS_STABILIZATION_DELAY, ms);
gps_actual1 = gps.getPosition();
wait(GPS_STABILIZATION_DELAY, ms);
gps_actual2 = gps.getPosition();
wait(GPS_STABILIZATION_DELAY, ms);
gps_actual3 = gps.getPosition();
gps_actual = EWMA_Position(gps_actual1, gps_actual2_gps_actual3);
chassis.setPosition(gps_actual.x, gps_actual.y, gps_actual.heading);
chassis.moveTo(2_ft, 2_ft, 180_degrees);
// ... etc.
Which improved the accuracy, but not to a point that was superior to tradition tracking-wheel based odometry, and had the detriment of the delays in movement (I think GPS_STABILIZATION_DELAY was greater than 50 and possibly 100).
Perhaps @2775Josh or @6210K can give more detailed experiences with the device. With this topic up, I might be motivated to build a test rig at the end of the season and re-evaluate the device and share the experience here.
15 Likes
an odom system is still going to update faster, I believe (and much MUCH more accurately and consistently).
My experience is as follows:
Our team ordered a GPS and very naively believed it would solve all of our programming positional struggles (sophomores, am I rightâŚ). We began to try to use it in a sensor fusion algorithm with the inertial and encoders, but since our drive base was 600rpm direct drive, it seemed unable to keep up with the speed at which we were moving. I forget the exact details of our further experimentation as to why this was, but I distinctly remember my team being convinced that the GPS could really only take a snapshot every 500ms or so, so @jpearman 's comment interests me greatly.
After this experience, my team began solely using the GPS in situations where the robot comes to rest. We would average the values returned across a 1s or so period, and use that to reset our global position. It has been about 2 years I believe since I attempted to use it in any other case but this one, but I agree that this thread suggests I should do some more experimentation.
5 Likes
Yeah, pretty sure my guys were running a 600RPM drive w/ the GPS too. We speculated that maybe the camera would start to blur. I think there was also something with the confidence score that the sensor reported, and they found any positions with a score less than maybe 97 werenât useful even with EWMA, etc.
One undocumented caveat we discovered around that time as well, is that the sensor MUST be mounted as close to parallel to the ground as possible. Theyâd initially mounted the device on an angled intake because it was convenient and at the right height. That was several days worth of âfunâ figuring out, from what I remember.
3 Likes
On itâs own, yes, the GPS sensor sucks. But, with a little bit of knowledge, it can be the most powerful sensor for your odometry.
First, letâs talk about the strengths and weaknesses of odometry using tracking wheels and an inertial sensor:
Pros:
- Accurate over short distances
Cons: - Drifts significantly over time
Now, the GPS sensor:
Pros:
- Does not drift over time
- Imprecise
If only there was the some way to combine the 2. But there is! Itâs called sensor fusion, and you have a couple of ways to go about implementing it. The 2 most common methods is a Particle Filter, and a Kalman Filter. You need a background in statistics (AP stats should be sufficient with a little bit of self-study) and know the very basics of linear algebra (how to add/subtract matrices, how to multiply matrices, etc). The filter knows what values to âtrustâ more based on a mathematical model you create.
tldr; the GPS sensor is the best sensor for odometry, but it needs a filter.
Further reading:
6 Likes
I strongly recommend going with a 2-wheel odometry for position tracking any time over a GPS sensor. Itâs what my team uses, and it works phenomenally. As for the GPS sensorâŚ
This comes from a sister team of mine last year. The black line is the path the robot was following, and the red line is where it thought it was⌠fun times.
8 Likes
My team is a rookie team and the team decided to use GPS over odometry mainly due to lack of time and experience on odometry. GPS just seemed quite easy to use. We used GPS on the autons and skills and the experience was subpar. The team adapted PID code using GPS heading and coordinates information. However, the results were not very consistent. The robot would drive to unexpected locations sometimes. I think this is caused by the GPS sometimes gave wrong readings. Also initially the team wanted to use GPS to figure out near side or far side, red alliance or blue alliance based on the coordinates of starting tile so the program can select correct auton routines. Even when the robot is stationary, there is 1 out of 10 chances of the GPS gave wrong information which mess up the auton selection. And the team had to abandon the auton selection approach due to the randomness of the errors.
Of course, we did not use any filtering algorithms. @LemFromTheLib, would you please elaborate a little more on potentially using kalman filter for example to get more accurate information of the GPS. Are you suggesting just passing the GPS coordinates and heading into kalman filter to smooth it out? I think okapi lib has some implementation of kalman filter and I could probably get the team to try it out. Or are you suggesting creating something much more advanced like âExample 9 - Vehicle Location Estimationâ on the website you recommended?
You would pass in GPS coordinates and heading to the filter, and it would output coordinates and heading. But the thing about the Kalman filter is that it becomes more accurate the more sources of data you have.
You should implement encoder odometry first before you attempt at implementing the Kalman Filter. Lets say you do this though, what next? Well, example 9 is pretty close to what you would use, except that you have multiple input sources and you track heading as well.
I havenât looked at OkapiLibâs implementation in detail, but it seems that its not used for odometry, but rather just a tool that can be used by the user. I would not recommend using it until you have successfully implemented a Kalman filter on your own.
1 Like
One important thing I would like to add to @LemFromTheLib and @Mentor_355U explanations is that GPS sensor seems to be very sensitive to the minor irregularities in the dimensions and angles of the particular field setup as well as to the exact location and orientation of where sensor is mounted on the robot.
So, it would be necessary to calibrate it for every individual field setup to get good accuracy.
I donât think the GPS sensor itself has that feature, therefore teams would have to figure out pre-calibrated biases / corrections for their robot on each individual field and pass them as initial setup parameters for the filter run on that field.
Another question for the sensor firmware developers (@jpearman ?) would be if the image snapshots taken by the sensor and used for position calculation are strictly simultaneous or sequential taken over some period of time?
In the latter case, I would assume accuracy of the results will degrade if the robot was moving (translating and rotating) and itâs velocity was not accounted while calculating GPS solution.
Finally, if you are using Kalman Filter and predicting trajectory of a moving object, it is not as important to have high frequency / low latency measurements, as it is to know exact time of when that measurement was taken.
For example, you could get much accurate results if you know exact time of a measurement (+/- 1 msec) taken once every 300 msec arriving up to 100 msec after it was completed, rather than if you have sensor returning a measurement every 50 msec with up to 10 msec delay, but you have no idea when this measurement was actually taken within the last 60 msec. The final position estimation error will be proportional to the robot speed.
4 Likes
Regarding this:
Our designing/testing field is black metal with the add on strips. Competition is white plastic with embedded strips.
What are your experiences on either type field?
Maybe we should take some clear packing tape and really stretch/flatten our add on strips to make them perfectâŚ
Our practice field is the white plastic with embedded strips. One event we went to had embedded strips and another event we went to had add on strips for the metal field. We did not really see much difference in how GPS performed. Both cases are a bit disappointing and worse than how it performed on our practice field. I donât know if the lighting condition has anything to do with the performance. It definitely felt brighter in our practice field than in the tournament fields.
1 Like
We used to use 20ms for GPS sampling frequency but changed to 50ms. I think @jpearman said GPS updates around 25 times per second so 50ms should be fine. But it did not seem to change the performance of GPS as we still saw similar behavior.
@tehcnik3k and @LemFromTheLib, thanks for your comments. The team is going to implement odometry with 2 tracking wheel and inertial sensor. Maybe use GPS as supplemental information to correct drift etc. But I feel there could be more testing/experiments done with GPS so suggestions are welcome.
1 Like
I know this is a âstaleâ thread, but has anyone played around with running 2 gps sensors and/or
- averaging the readings
- filtering the readings to decide which one is more accurate (X% change in values⌠if over a threshold, switch the the sensor reporting less change)
Our experience is that itâs great and distances <4-5 feet. If 2 were mounted, 1 fore and 1 aft⌠maybe we could get some good readings.
I am wondering, have you tried combining these two sensors before? If so is it really worth the extra weight and time for the drift correction with the one minute auto skills?
Might we perhaps see a lemlib integration in the future 