We've had some reports of poor GPS accuracy in 2.9.1 as compared to 2.8.1. This discussion is to debate, test, conclude and if necessary fix issues related to GPS accuracy in 2.9.1.
You need to be a member of diydrones to add comments!
I bought a ublox neo (the $27 version) and connected it up to the APM2.5
at first everything seemed ok (connected to USB ) data was coming in from the GPS and the APM said ublox ok.
But then I disconnected the APM from usb and hooked it up to the battery.
GPS lost (NO GPS!) ...back to USB and there was the GPS again.
solution:
(kind of) ....my USB voltage is 4.5V the output data of the GPS has an amplitude of 2.5V . When on USB, the APM finds 2.5V worthy of a "1". When on 5 Volts (via lm7805 from battery) the APM DOESN'T find 2.5V a logical "1" voltage, so the GPS connection is lost......I am building a level converter for TX data out from GPS.
I mention in an earlier post that Australia where I fly does not have WAAS (US) or EGNOS (Europe) Satellite Based Ausgnentation System (SBAS). As both the MTK on v1.9 and Ublox LEA-6H use WAAS/EGNOS by default and APM is expenting this, how do I disable it to use GNSS only. The general concensus from folk in our area is the fact the two GPS options have WAAS/EGNOS on may contribute to the GPS erratic behaviour in our region. So we have the added issue both APM and the GPS from 3DR are only setup for either US or Europe operation in term of the GPS code and hardware? I hope I am wrong but I would at least like to no if I can disable the GPS trying to find WAAS or EGNOS feeds and also understand if there absent, what the impact would be on the APM flight mode functions?
Well I found another piece to the GPS accuracy puzzel today, somewhat by accident. I decided to risk my new rebuilt quad (second major build this month) on 2.9.1 with my MTK v1.9. Actually a ran out of time to build 2.8.1 again and try Crash's modified leadfilter. But I will get to it soon.
My first flight I diliberately left the GPS running for 15 minutes before arming and then after arming another 5 minutes before taking off. Loiter was fine and I did a few sucessful RTL's I have lowered the WP speed to 1m/s down from 5m/s which I figured would give the GPs more time to settle versus distance travelled. Another important data point is I disconnected the Telemetry prior to flying.
My second flight is where I have turned up something interesting. I followed the same routine as the first flight with long GPS warm ups pre and post arming. When I attempted the RTLs both failed with the quad heading in the wrong direction.
We already know that the leadfilter needs tweaking to compenstate for the changed data aquisition rate in v1.9 and the MTk is more suseptable to position accuracy issues than the ublox. However after analysing the logs today I found not only is the GPS data all ove rthe place the Home position without warning is moving to one of these extremme GPS position fluctuation points. So I would suggest we look to see why is the Home lock once the intial GPS position is locked in moving? This is not supposed to happen unless you disarm and rearm the APM or manually override. It explains the issue I encountered a few weeks ago. Maybe this is a possible bug.
Of course this still leaves us with the GPS expected erractic behaviour. I first thought the telemetry module could be interfering with the GPS. It would be good to know how far I can move the telemetry module from the APM serial port just to eliminate another veriable. Also it looks like the recent posts on the 2.9.1 forum have turned up a few good tips for eliminating GPS interference inlcuding special shaped and diameter aluminium plates.
Web Site hosted by iRepublics.com
Web Site hosted by iRepublics.com - the Bannerless Free Corporate Web Hosting Company
Just some thoughts on Google image overlay errors.
While I think the google earth aerial photographs are mostly quite accurately positioned I believe there are still some offset errors.
I use a garmin a lot for cycling and one of my usual routes shows my track 5m south of the road every time. There are a number of places where my track is consistently in error. Could it be satellite interference from something or a google error?
If you check ‘historical’ images, sometimes they are not exactly on top of the current ones. Also roads are sometimes in a slightly different place on openstreetmap or others.
I guess for things like RTL it is not that important as it will come back to where it started but if you have planned an auto mission to avoid masts/ trees etc it may put you closer than you think. It always happens with a tree in my field but have learned to offset a bit.
Well I ran a few simple ground tests this afternoon, to see how the MTK with v1.9 was performing with APM 2.9.1. I powered on my quad waited for a good lock and left it sitting on the ground for a few minutes before arming. With no props on I ran the motors for a while at low medium and maximum throttle, to check interference. No major issues here. Compass a tiny deviation at maximum throttle, but nothing to worry about, However, What suprised me the most was how bad the GPS accuracy is when moving the quad to a new location. with the system idle and a good GPS lock I picked up my quad and walked in a straight line for about 30m and placed is back down on the ground. The track jumped 90 degreees to the direction I was walking and by almost the same distance. The GPS Position bounced around for a good 2 minutes before gradually settling at the actual new location. So whilst the accuracy is reasonable the rate of correction after changing location is unusable at the moment. I suspect this is a combination of the APM corrected GPS data (filtering) and the performance level of the MTK (lag). Next test will be to repeat the above using the GPS direct using a PC program like TinyGPS. This should be an easy way to eliminate the filtering. Of course I will try the aluminium sheilding trick as well to elimnate this variable.
Thank you for the feedback and suggestion. I will try and schedule that test soon. However first I am going to check something with the current setup, weather permiting tomorrow. I want to set up a simple test where I establish a good home lock for a simple one waypoint mission, walk the quad to the correct WP 1 point placing it on the ground, wait for some good GPS data and then return the quad back to home. I will then set this up again and this time fly to the WP using the autopilot and compare the logged GPS readings.
There is another disturbing observation to add to my above report. If you look at the KML generated flight tracks the purple line which marks Start of RTL is on the other side of the dirt track towards the Dam. This is the same when you replay the TLOG in the mission planner. However if you look at the GPS position recorded at the exact time the mode change to RTL (also in the TLOG), the GPS coordinate corresponds to the first WP as shown with the yellow drop point labelled RTL (APM Log). Of course my Quad was physically at the Dam marked with a green drop point marker in my diagram. So there are three entirely different data points for the Start of RTL 1) MP / KML plot 2) GPS RTL recorded in the TLOG and 3) Actual position of the copter. Or if you like three different GPS positions for the same event = start of RTL.
Concerning the MTK 1.6/1.9 and apm 2.8.1/2.9.1 i would suggest a test. Test MTK1.9 with 2.9.1 than compile 2.8.1 with a replaced AP_GPS (2.9.1 library) so 2.8.1 understands the mtk1.9 binary protocol. Than redo the test. If the gps routine is basically the same (2.9.1/ 2.8.1) and the result is worse on 2.9.1 it must be a timing thing. There was a RC problem due to higher cycletime, perhaps something like that affects the gps PID controller as well? Perhaps a delta T problem with "I" ?
Randy I finally finished sifting though the logs from my recent crash with 2.9.1. The original discussion and data can be found here For those just reading this, I executed an auto mission which I had to abort from after my quad overshot the first waypoint by roughly twice the distance from home. I attempted RTL but the copter stopped well short of the first waypoint. The original cause was thought to be a momentary loss of GPS lock but as you will see from my analysis the issue seems to point to accuracy of the GPS formed data used by the APM. I choose my words carefully because I do not think this is an accuracy issue in the raw GPS data. The HDOP values were consistent and within the expected precision level. Here is a quick summary to not from the attached spreadsheets and diagrams:
1. There was a solid GPS lock for at least four minutes prior to an after arming, so the Home location was well established for RTL to work.
2. There was no delay in the raw GPS data updates which averaged between 0.8-1 sec during the 40 sec period AUTO was engaged. The original analysis of dropping from 10 to 8 sats a one point happened after the AUTO (which failed to stop at the first waypoint)
3. When comparing actual GPS position data taken after the crash at the location the Quad reached after mode was switched from AUTO to RTL and, there is a significant difference to the raw GPS data recorded in the telemetry log.
When considering the last point, there is no reasonable explanation I can find. Even though the quad was well past the first waypoint the raw GPS data (Lon and Lat) should have been correct. It should have also been correct for other stages of the flight and final resting past just prior to going in. I tested the MTK with 1.6 and 1.9 against two other portable GPS units and they at least giving a correct position. So this makes me ask if "mavlink_gps_raw_int_t" is a calculated / formatted version of the GPS position data coming from the MTK. If so the problem could be with the accuracy of these values over time or in certain conditions e.g delay in GPS data updates in version 2.9.1.
The above diagrams show the original mission and replay in the mission planer. I have marked the actual ground position when RTL was engaged and the final crash site. The next diagram shows the GPS error a little more clearly.
The yellow drop points show the "mavlink_gps_raw_int_t" positions recorded in the TLOG that correspond to the flight mode changes. The green drop points are physically where the quad was in the flying field. I captured this real GPS data after the flight, walking to each point and taking the Lat and LON readings. Clearly there is a significant difference.
Here is this data in table form:
I have attached the actual spreadsheets of this data and the full tlog in CSV format. I added two extra columns A and L to help m sort the filtered data and work out the delta T between GPS data updates.
Just for completeness here is a google earth plot of MTK v1.6 and v 1.9 and Global sat accuracy measurements I took from a fixed location. I used the TinyGPS app and cable direct to the MTK's I originally posted what I thought was a 7-8 meter difference between my MTK's with different firmware versions. I think the other portable GPS units I used are closer to MTK with v1.9 than MTK with v1.6 Its very subjective.
Replies
Hi guys,
Has anyone of you encountered the following?
I bought a ublox neo (the $27 version) and connected it up to the APM2.5
at first everything seemed ok (connected to USB ) data was coming in from the GPS and the APM said ublox ok.
But then I disconnected the APM from usb and hooked it up to the battery.
GPS lost (NO GPS!) ...back to USB and there was the GPS again.
solution:
(kind of) ....my USB voltage is 4.5V the output data of the GPS has an amplitude of 2.5V . When on USB, the APM finds 2.5V worthy of a "1". When on 5 Volts (via lm7805 from battery) the APM DOESN'T find 2.5V a logical "1" voltage, so the GPS connection is lost......I am building a level converter for TX data out from GPS.
My first flight I diliberately left the GPS running for 15 minutes before arming and then after arming another 5 minutes before taking off. Loiter was fine and I did a few sucessful RTL's I have lowered the WP speed to 1m/s down from 5m/s which I figured would give the GPs more time to settle versus distance travelled. Another important data point is I disconnected the Telemetry prior to flying.
My second flight is where I have turned up something interesting. I followed the same routine as the first flight with long GPS warm ups pre and post arming. When I attempted the RTLs both failed with the quad heading in the wrong direction.
We already know that the leadfilter needs tweaking to compenstate for the changed data aquisition rate in v1.9 and the MTk is more suseptable to position accuracy issues than the ublox. However after analysing the logs today I found not only is the GPS data all ove rthe place the Home position without warning is moving to one of these extremme GPS position fluctuation points. So I would suggest we look to see why is the Home lock once the intial GPS position is locked in moving? This is not supposed to happen unless you disarm and rearm the APM or manually override. It explains the issue I encountered a few weeks ago. Maybe this is a possible bug.
Of course this still leaves us with the GPS expected erractic behaviour. I first thought the telemetry module could be interfering with the GPS. It would be good to know how far I can move the telemetry module from the APM serial port just to eliminate another veriable. Also it looks like the recent posts on the 2.9.1 forum have turned up a few good tips for eliminating GPS interference inlcuding special shaped and diameter aluminium plates.
How is 2.9.2 coming along? When will it be out?
I am currently flying 2.8.1 as I could never get 2.9.1 to work as well as 2.8.1?
.
Just some thoughts on Google image overlay errors.
While I think the google earth aerial photographs are mostly quite accurately positioned I believe there are still some offset errors.
I use a garmin a lot for cycling and one of my usual routes shows my track 5m south of the road every time. There are a number of places where my track is consistently in error. Could it be satellite interference from something or a google error?
If you check ‘historical’ images, sometimes they are not exactly on top of the current ones. Also roads are sometimes in a slightly different place on openstreetmap or others.
I guess for things like RTL it is not that important as it will come back to where it started but if you have planned an auto mission to avoid masts/ trees etc it may put you closer than you think. It always happens with a tree in my field but have learned to offset a bit.
Hello Crashpilot,
"why didn't the leadfilter produce trouble in 2.8.1?"
Maybe is because of mtk 1.9 firmware refresh rate (not sure for now) as I'm disserting in the post below.
Regards,
Miguel
Thank you for the feedback and suggestion. I will try and schedule that test soon. However first I am going to check something with the current setup, weather permiting tomorrow. I want to set up a simple test where I establish a good home lock for a simple one waypoint mission, walk the quad to the correct WP 1 point placing it on the ground, wait for some good GPS data and then return the quad back to home. I will then set this up again and this time fly to the WP using the autopilot and compare the logged GPS readings.
There is another disturbing observation to add to my above report. If you look at the KML generated flight tracks the purple line which marks Start of RTL is on the other side of the dirt track towards the Dam. This is the same when you replay the TLOG in the mission planner. However if you look at the GPS position recorded at the exact time the mode change to RTL (also in the TLOG), the GPS coordinate corresponds to the first WP as shown with the yellow drop point labelled RTL (APM Log). Of course my Quad was physically at the Dam marked with a green drop point marker in my diagram. So there are three entirely different data points for the Start of RTL 1) MP / KML plot 2) GPS RTL recorded in the TLOG and 3) Actual position of the copter. Or if you like three different GPS positions for the same event = start of RTL.
Concerning the MTK 1.6/1.9 and apm 2.8.1/2.9.1 i would suggest a test. Test MTK1.9 with 2.9.1 than compile 2.8.1 with a replaced AP_GPS (2.9.1 library) so 2.8.1 understands the mtk1.9 binary protocol. Than redo the test. If the gps routine is basically the same (2.9.1/ 2.8.1) and the result is worse on 2.9.1 it must be a timing thing. There was a RC problem due to higher cycletime, perhaps something like that affects the gps PID controller as well? Perhaps a delta T problem with "I" ?
Just guessing.
Kraut Rob
Randy I finally finished sifting though the logs from my recent crash with 2.9.1. The original discussion and data can be found here For those just reading this, I executed an auto mission which I had to abort from after my quad overshot the first waypoint by roughly twice the distance from home. I attempted RTL but the copter stopped well short of the first waypoint. The original cause was thought to be a momentary loss of GPS lock but as you will see from my analysis the issue seems to point to accuracy of the GPS formed data used by the APM. I choose my words carefully because I do not think this is an accuracy issue in the raw GPS data. The HDOP values were consistent and within the expected precision level. Here is a quick summary to not from the attached spreadsheets and diagrams:
1. There was a solid GPS lock for at least four minutes prior to an after arming, so the Home location was well established for RTL to work.
2. There was no delay in the raw GPS data updates which averaged between 0.8-1 sec during the 40 sec period AUTO was engaged. The original analysis of dropping from 10 to 8 sats a one point happened after the AUTO (which failed to stop at the first waypoint)
3. When comparing actual GPS position data taken after the crash at the location the Quad reached after mode was switched from AUTO to RTL and, there is a significant difference to the raw GPS data recorded in the telemetry log.
When considering the last point, there is no reasonable explanation I can find. Even though the quad was well past the first waypoint the raw GPS data (Lon and Lat) should have been correct. It should have also been correct for other stages of the flight and final resting past just prior to going in. I tested the MTK with 1.6 and 1.9 against two other portable GPS units and they at least giving a correct position. So this makes me ask if "mavlink_gps_raw_int_t" is a calculated / formatted version of the GPS position data coming from the MTK. If so the problem could be with the accuracy of these values over time or in certain conditions e.g delay in GPS data updates in version 2.9.1.
The above diagrams show the original mission and replay in the mission planer. I have marked the actual ground position when RTL was engaged and the final crash site. The next diagram shows the GPS error a little more clearly.
The yellow drop points show the "mavlink_gps_raw_int_t" positions recorded in the TLOG that correspond to the flight mode changes. The green drop points are physically where the quad was in the flying field. I captured this real GPS data after the flight, walking to each point and taking the Lat and LON readings. Clearly there is a significant difference.
Here is this data in table form:
I have attached the actual spreadsheets of this data and the full tlog in CSV format. I added two extra columns A and L to help m sort the filtered data and work out the delta T between GPS data updates.
Just for completeness here is a google earth plot of MTK v1.6 and v 1.9 and Global sat accuracy measurements I took from a fixed location. I used the TinyGPS app and cable direct to the MTK's I originally posted what I thought was a 7-8 meter difference between my MTK's with different firmware versions. I think the other portable GPS units I used are closer to MTK with v1.9 than MTK with v1.6 Its very subjective.
2013-02-10 10-52-48ver2_GPS.csv
GPS_Failure_11Feb13b.xlsx
-
1
-
2
-
3
of 3 Next