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!
maybe it is a bit off topic here but i have spoken to the U-Blox company regarding the setup for the Dynamic Model Filter.
For the Copter code we are using Airborne1g with a Large Position Deviation. If we change to Pedestrian the deviation will be small. The disadvantage is that the output of heading and speed will be delayed. In the actual setting we are using, the output of speed and heading will be very fast and the output of the position is delayed according the answer from u-Blox.
How important is the heading and speed output for the control of the copter? Would it be better to change the mode to Portable or even to pedestrian? Or switche the mode during runtime when we are go into loiter mode ( this is possible according u-Blox).
This is a graphic of comparing the various GPS options. All three units were mounted on one frame and all the data was gathered simultaneously with a pre-release version of 2.9 when I was testing the Mtek V1.9 firmware.
Maybe it is the wrong place here but i did a good working ACC/GPS fusion on the NAZE32. The GPS code is based on 2.8.1 pimped with acc data. In the result i get a very good Pos Hold with my mtk3329 (FW1.9) (it is the same model that's on my apm 2.0). I didn't expect that from my mtk :). Here is the link to the sourcecode, maybe it is of some use for the arducopter project as well. http://www.multiwii.com/forum/viewtopic.php?f=23&t=1947&sta...
Today I performed two GPS related tests of the ArduCopter 2.8.1 vs 2.9.1 code.
The first test was to investigate if there was any difference between the parsing of messages from the GPS between 2.8.1 and 2.9.1. So there was some mention that perhaps the 2.9.1. code was becoming too busy to parse the messages - I couldn't find any indication of that.
I connected two APMs (one running AC2.8.1, the other 2.9.1) to the same Mediatek GPS running firmware 1.6. In the first test the AC 2.8.1 was the "master" in that it was responsible for sending the start-up info to the mediatek. I then repeated the test but with the 2.9.1 as the "master". During both tests, the two APMs received 3d lock at exactly the same time and from reviewing the dataflash logs, they both produced exactly the same google earth tracks. There was no lost data on either.
In the 2nd set of tests, I just performed GPS lock speed tests. So I connected up APM2 and APM2.5 with either AC2.8.1 or 2.9.1, connected them to the Mediatek and timed how long it took to get 2D and 3D lock. The results are in the table below. The results were quite variable and it's pretty hard to draw any conclusions from this small set of samples.
I've found that there are two differences in the configuration sent to the Mediatek between 2.8.1 and 2.9.1. I'll investigate those more tomorrow.
By the way - these tests were performed in a very urban environment (downtown tokyo) which leads to a lot of multipathing. Some comments above talk about the accuracy of the GPS in your house but that's not really a good test. Below is a picture which shows why you really can't trust your GPS near buildings:
I had a crash last weekend which Randy has already analysed for me in the 2.9.1 Forum. I decided to do some more checking becuase the GPS accuracy seems to have played a factor in the sequence of events. I cannot point to any conclusive evidence yet but, there are several events in the flight log which show delays (usec timing field on raw GPS data) which equate to delays in the range 1.8 to 2 seconds and in one case a 5 second delay when the system arms even though the GPS lock status (blue light on MTK) is solid and the LAT and LON coordinates are precsuely the same. I suspect there is some interaction with APM code and GPS in version 2.9.1 which is at fault here. It could be simply the processor under heavy load or interrupt priorities delay the GPS data update. I do not see any failure in GPS lock in these delay cases.
Of cause what is extermely troubling to me is I was under the misunderstanding if you had a solid GPS lock when arming and prior to take off and say you had a a minor (1-2) second delay in GPS data to the APM during the flight the system would still be able to work out its position and correct accordingly.
I have stopped using RTL and AUTO modes now becuase this is a huge risk. You could easily have a delay in GPS data say on one leg of your auto flight further from the home location and as seen in my video and logs the copter will fly on past the waypoint forcing an abort.
RTL seems non effective in these cases becuase the copter APM no longer knows its position and the code is not correcting against the real GPS data after these events.
I hope there is some work fix or short term work around so the APM can use the live GPS data to re- validate position. As I understand the calculation to waypoint is off the initial home position so if say APM is fooled in to thinking it has only reached point X when infact it is at point Y due to a GOS data delay It sees not reason to accept the change in real GSP position after the lock or GSP data delayed has past.
I do think there is definitely some accuracy difference in the MTK with v1.9 perhaps more apprent on APM 2.9.1 versus the earlier GPS. Yesterday I compared GPS position data with the MTK 1.6 and 1.9 and also used a portable GlobalSAT GOS device. The MTK on 1.6 correlated with the portable device I used but there was always a slight difference in LON value on the MTK with v1.9. I will post the data up later.
I am heading out to my flying field now to measure the actual crash site and RTL enagement positions to compare this with the data APM recorded last weekend. I will upload this soon
i had a problem with my arducopter and i believe that was the reason, please see and comment if you agree that this was a GPS problem! At 1:01 i put the copter at Loiter mode, and at 1:11 starts flying away without any input from me! At 1:13 its is visible that i go back at Stabilise mode, in order to keep it from fly away and it stops drifting away! I crash landed it by turning down the throttle slowly as i couldn't see very clearly its orientation! No damage at all was taken... The exact same has happened once more!
From checking with Tridge, who knows a lot more about the GPS code than I do, there are some other changes that came with the new Mediatek 1.9 firmware code:
The old 1.6 firmware had a lot more filtering internally and would actually lie about it's GPS lock status. Even after losing lock it would carry on reporting that it had lock but extrapolate it's position based on the gps's last recorded ground speed and direction. In one test with the old 1.6 firmware a team member walked from his front yard into his house which has a metal roof and doesn't allow him to get a gps lock. Instead of the gps reporting that it had lost lock, it instead reported that he'd walked out the other side of his house, across his neighbour's yard and kept going. After about 1 minute it finally lost lock and reported that he was about 500m away from his real position.
The new APM side of the gps library turns on SBAS. This only matters if you're using the 1.9 firmware on the GPS and generally should improve the position estimate but in some places in australia it's rumored to make things worse because you might accidentally pick up the japanese SBAS information (Australia apparently doesn't have it's own SBAS set-up).
Still investigating but that's a little bit of extra info on this topic.
Replies
@ Randy
maybe it is a bit off topic here but i have spoken to the U-Blox company regarding the setup for the Dynamic Model Filter.
For the Copter code we are using Airborne1g with a Large Position Deviation. If we change to Pedestrian the deviation will be small. The disadvantage is that the output of heading and speed will be delayed. In the actual setting we are using, the output of speed and heading will be very fast and the output of the position is delayed according the answer from u-Blox.
How important is the heading and speed output for the control of the copter? Would it be better to change the mode to Portable or even to pedestrian? Or switche the mode during runtime when we are go into loiter mode ( this is possible according u-Blox).
Mode
Description
Velocity m/s
Vertical Velocity m/s
Altitude m
Position Deviation
0
Portable
310
50
12000
Medium
2
Stationary
10
6
9000
Small
3
Pedestrian
30
20
9000
Small
4
Automotive
84
15
6000
Medium
5
At Sea
25
5
500
Medium
6
Airborne1g
100
100
50000
Large
7
Airborne2g
250
100
50000
Large
8
Airborne4g
500
100
50000
Large
This is a graphic of comparing the various GPS options. All three units were mounted on one frame and all the data was gathered simultaneously with a pre-release version of 2.9 when I was testing the Mtek V1.9 firmware.
Don't know if this adds to this thread...
Been flying APM 2.0 2.8.1 with built in GPS... works ok.... take a while for GPS fix.... drifts around 20 feet.....
Now flying new APM 2.5 with UBlox..... Factor of 10 times better.... 3D fix in seconds inside the shop...
Super smooth Loiter.. ect..... copter is no longer jumping around like its haveing a wank.. !!!
Eddie Weeks
Maybe it is the wrong place here but i did a good working ACC/GPS fusion on the NAZE32. The GPS code is based on 2.8.1 pimped with acc data. In the result i get a very good Pos Hold with my mtk3329 (FW1.9) (it is the same model that's on my apm 2.0). I didn't expect that from my mtk :). Here is the link to the sourcecode, maybe it is of some use for the arducopter project as well. http://www.multiwii.com/forum/viewtopic.php?f=23&t=1947&sta...
Cheers
Kraut Rob
Today I performed two GPS related tests of the ArduCopter 2.8.1 vs 2.9.1 code.
The first test was to investigate if there was any difference between the parsing of messages from the GPS between 2.8.1 and 2.9.1. So there was some mention that perhaps the 2.9.1. code was becoming too busy to parse the messages - I couldn't find any indication of that.
I connected two APMs (one running AC2.8.1, the other 2.9.1) to the same Mediatek GPS running firmware 1.6. In the first test the AC 2.8.1 was the "master" in that it was responsible for sending the start-up info to the mediatek. I then repeated the test but with the 2.9.1 as the "master". During both tests, the two APMs received 3d lock at exactly the same time and from reviewing the dataflash logs, they both produced exactly the same google earth tracks. There was no lost data on either.
In the 2nd set of tests, I just performed GPS lock speed tests. So I connected up APM2 and APM2.5 with either AC2.8.1 or 2.9.1, connected them to the Mediatek and timed how long it took to get 2D and 3D lock. The results are in the table below. The results were quite variable and it's pretty hard to draw any conclusions from this small set of samples.
By the way - these tests were performed in a very urban environment (downtown tokyo) which leads to a lot of multipathing. Some comments above talk about the accuracy of the GPS in your house but that's not really a good test. Below is a picture which shows why you really can't trust your GPS near buildings:
It is not clear to me if Gps problems with 2.9.1 arises only with Mediatek GPS while with uBlox Gps behavior is like with 2.8.1.
Of cause what is extermely troubling to me is I was under the misunderstanding if you had a solid GPS lock when arming and prior to take off and say you had a a minor (1-2) second delay in GPS data to the APM during the flight the system would still be able to work out its position and correct accordingly.
I have stopped using RTL and AUTO modes now becuase this is a huge risk. You could easily have a delay in GPS data say on one leg of your auto flight further from the home location and as seen in my video and logs the copter will fly on past the waypoint forcing an abort.
RTL seems non effective in these cases becuase the copter APM no longer knows its position and the code is not correcting against the real GPS data after these events.
I hope there is some work fix or short term work around so the APM can use the live GPS data to re- validate position. As I understand the calculation to waypoint is off the initial home position so if say APM is fooled in to thinking it has only reached point X when infact it is at point Y due to a GOS data delay It sees not reason to accept the change in real GSP position after the lock or GSP data delayed has past.
I do think there is definitely some accuracy difference in the MTK with v1.9 perhaps more apprent on APM 2.9.1 versus the earlier GPS. Yesterday I compared GPS position data with the MTK 1.6 and 1.9 and also used a portable GlobalSAT GOS device. The MTK on 1.6 correlated with the portable device I used but there was always a slight difference in LON value on the MTK with v1.9. I will post the data up later.
I am heading out to my flying field now to measure the actual crash site and RTL enagement positions to compare this with the data APM recorded last weekend. I will upload this soon
https://www.youtube.com/watch?v=5ns5OdKvQ7U
i had a problem with my arducopter and i believe that was the reason, please see and comment if you agree that this was a GPS problem! At 1:01 i put the copter at Loiter mode, and at 1:11 starts flying away without any input from me! At 1:13 its is visible that i go back at Stabilise mode, in order to keep it from fly away and it stops drifting away! I crash landed it by turning down the throttle slowly as i couldn't see very clearly its orientation! No damage at all was taken... The exact same has happened once more!
APM 2.5 with 2.9.1
From checking with Tridge, who knows a lot more about the GPS code than I do, there are some other changes that came with the new Mediatek 1.9 firmware code:
Still investigating but that's a little bit of extra info on this topic.
@Randy,
If I test my MediaTek V2 GPS in the Terminal CLI, it always starts the first line with MTK19. What is the significance of the "19"?
Regards,
TCIII
-
1
-
2
-
3
-
4
-
5
of 5 Next