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!
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.
I'm not quite sure, but the accuracy maybe is because of the antenna of the GPS and not a software issue. I had an broken USB GPS laying around with a huge antenna, as the UBLOX one... I did a bold move, and i removed the Mediatek antenna and replaced it with the other! Now, instead of 5 satelites i used to get, i get 9 (in my house with only one west facing window)! The accuracy is also very improved and the traveling is between 1-2 meters! All this in my house, i havent tested it outside yet. Maybe in a while, as it is night here and late. What do you think? anyone else tried it?
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.
Yesterday I was checking settings on my apm in the house and suddenly noticed that the gps position on the MP was going in circles around the actual location. It did this for maybe a minute and then it stopped on my exact position in the house. I don't know if this is related to the discussion, but I hadn't noticed this behavior with 2.8.1. I have updated the firmware in the gps yet. I will watch to see when this happens as it may have been on initial gps lock.
Hi all! Randy, there's substantial difference in the code about the gps accuracy from 2.8.x to 2.9.1? I noticed a pronunced "circle effect" during Loiter, not present in 2.8.1, or at least thequadmovesoften randomlyover 5 meters during Loiter. It's possible thattheinertialcanadversely affect theperformance of thepositionhold? I mean "INAV Z". In the first video the Loiter with 2.9.1 (I do notmovewhile shooting), in the second with 2.8.2.
Randy sorry for thr delay in posting results. I will hoepfully get my findings up tonight after work. Meanwhile I have checked a static reading with MTK v1.6 versus v1.9 away from buildings in the countryside and found there is a 7-8 metre difference. I need the check the reading against the Globalsat potable device I also had runing but its postion data closely matches the MTK unit I have with v1.6. Of course this amount of difference is probbaly allowable in terms of GPS precision I am not sure.
Personally, I think Loiter has improved, but I am getting random cut outs. In other words, I will be in loiter behaving fine, then it will start to drift (lose GPS). It didn't seem to do this with V2.8.1+ older GPS FW (whatever came on it last year). When Loiter works, it's good. I have to review the logs, but it sounds like what you are describing.
I have a APM2 with Mediatek and 1.9 FW. I updated in conjunction with going to v2.9.1. So, I am not sure if this randomness is caused by 1.9 or v2.9.1 or a combo.
Replies
Greetings again guys!
I'm not quite sure, but the accuracy maybe is because of the antenna of the GPS and not a software issue. I had an broken USB GPS laying around with a huge antenna, as the UBLOX one... I did a bold move, and i removed the Mediatek antenna and replaced it with the other! Now, instead of 5 satelites i used to get, i get 9 (in my house with only one west facing window)! The accuracy is also very improved and the traveling is between 1-2 meters! All this in my house, i havent tested it outside yet. Maybe in a while, as it is night here and late. What do you think? anyone else tried it?
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
Yesterday I was checking settings on my apm in the house and suddenly noticed that the gps position on the MP was going in circles around the actual location. It did this for maybe a minute and then it stopped on my exact position in the house. I don't know if this is related to the discussion, but I hadn't noticed this behavior with 2.8.1. I have updated the firmware in the gps yet. I will watch to see when this happens as it may have been on initial gps lock.
Hi all! Randy, there's substantial difference in the code about the gps accuracy from 2.8.x to 2.9.1?
I noticed a pronunced "circle effect" during Loiter, not present in 2.8.1, or at least the quad moves often randomly over 5 meters during Loiter.
It's possible that the inertial can adversely affect the performance of the position hold? I mean "INAV Z".
In the first video the Loiter with 2.9.1 (I do not move while shooting), in the second with 2.8.2.
Bests, Marco
Personally, I think Loiter has improved, but I am getting random cut outs. In other words, I will be in loiter behaving fine, then it will start to drift (lose GPS). It didn't seem to do this with V2.8.1+ older GPS FW (whatever came on it last year). When Loiter works, it's good. I have to review the logs, but it sounds like what you are describing.
I have a APM2 with Mediatek and 1.9 FW. I updated in conjunction with going to v2.9.1. So, I am not sure if this randomness is caused by 1.9 or v2.9.1 or a combo.
I will try to post log files tonight if I can
-
1
-
2
-
3
-
4
-
5
of 5 Next