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 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?
That's brilliant. I was toying with an alternative test (since I haven't got two Mediatek units available), of attaching a little hardware data logger unit, to the data coming out of the GPS itself, and recording this in parallel with the logged data. However finding suitable wires and plugs was getting a bit complex, and the weather here in the UK, (currently snowing), makes testing improbable, even for ground tests in the near future.
The odd thing about this, is I had 'loiter' working competently with 2.8.1, and never saw a 'I'm going to go dashing miles away' with this, but since switching to 2.9.1, it seems to happen just about every flight if using the loiter. This 'sudden appearance, simultaneous with switching versions', is what suggests something 'odd' is happening.
What (of course) is needed, is to average the GPS readings more, slowing the response to it, and reject any readings that show movement of more than some predetermined speed, then use the inertial data to provide the biggest input for 'short term hold'. This way momentary spikes (whatever the cause), won't give this sort of behaviour. If the position suddenly says 'move 50 feet', but the inertial is saying 'the copter is only slowly moving, and in the right direction', it'll provide the ability to reject the motion spike. I suspect this is how the Naza achieves such a good hold.
Left copter on long USB over ethernet connection in the middle of my lawn. Ran static location tests on the flight data screen, watching HDOP, and the position. Used the Ublox, and the Mediatek, via the arducopter.
Typical 5 minute test on the Mediatek, hdop maximum 1.3, most of the time sitting at 1, and dropping on a couple of occasions to 0.9. Minimum satellites 9, max 12. Distance from 'home' however reached 52m max!....
Plot went right across three houses and the sports field behind me. 99% of the data was happily in the immediate vicinity, there were just a couple of points that were completely 'wayward'.
With the Ublox, distance from home reached 2m max.
With the Mediatek connected using NMEA, directly to Google Earth, largest distance recorded was 3m.
What is interesting is the huge movement recorded, is not happening using the NMEA interface.
It is as if one byte in the data stream, possibly is getting corrupted, and not getting picked up by the checksum handling, or the bad checksum is being ignored. I notice the Ublox data has a 'number of bytes' value, so a lost byte for instance would be detected.
Hey Randy, is it possible to see the GPS location accuracy somewhere? I know you can see the number of sats, but what about accuracy? As in, 2.6m for example?
I just took the time to setup my copter in the back garden, stationary in the centre of the lawn, and log the position reported by it, versus the position from my radio control telemetry.
Let the system go 'locked' then waited a couple more minutes before starting.
The position reported by the radio control moved by a total of just under 8' for the entire test. It reported between 5 and 8 satellites.
The position reported by the arducopter logs had me over half a mile away from the start point at one time. Position was like a random 'drunkards walk', running to the north west and to the south east over quite a narrow diagonal line. The logs also showed 3dfix all the time, and reported between 5 and 9 satellites visible. The altitude only varied by 2m over the entire time. The linear nature, and the fact the altitude remained good (which is normally the first thing to decay), suggests something very odd is going on. Does this receiver use WAAS?. Is it possible it is somehow getting an incorrect offset from this, that is drifting badly?.
Motors were not running, so no RF interference from this, only the radio telemetry (Spektrum DX8, placed on the opposite side of the model).
The motion was jerky, but steadily moved to the north west, then after about 90 seconds reversed, came back across the starting point, and went to the south east. Then reversed again, and had nearly got back to the start when I finished the test. It was almost like perhaps a 6 minute cycle.
Had also changed the GPS cable and added spike filters to this before starting.
Ouch. No wonder position hold/loiter is not working!.....
It'll hold position sometimes for minutes without problems, and then suddenly decide it is a huge distance from where it wants to be, and head off at full speed. If one is lucky and nothing is in it's path, after a few seconds, it comes back (but the return always at relatively slow speed compared to the initial jump).
Why?. No idea. Sudden 'one sample' jumps in GPS positions can always happen. I have logs showing my Land Rover doing over Mach1, for a couple of seconds, when there was an update to the GPS clocks, but this was an 'announced' event late at night a while ago. When this doesn't happen, I have seen smaller jumps when (for instance) a mainline railway train passed close by. Sudden change in signal paths and reflections. However my separate telemetry GPS, recorded no jumps when the shifts occur, but was sampling at a much lower interval.
The obvious suggestions are:
1) An Olympic filter instead of any basic averaging.
2) A 'limit' value on movement speed, and rejecting values if the copter is detected to be moving out of position by more than (say) 30mph.
3) The one being worked on of including inertial data into the verification of movement required.
On my last such glitch, my brother was flying a Naza alongside my model, and this didn't shift more than a few inches, while on the Arducopter it was a test of reflexes to reselect stabilise mode before it hit a line of trees.
One of the reasons for my going the Arducopter route, was to have the goto waypoint options lacking in the Naza, but currently these appear to be potentially dangerous.
It does appear that for some reason this code is seeing momentary glitches in the data. Since it wasn't apparent on older versions, one wonders about something like an error in parsing values as a possibility. This is one that affects my telemetry, since I'm almost on the Greenwitch meridian, and the program to display the logs from my Spektrum system, suddenly jumps massively east when the position passes the meridian, taking the 'minute' value as degrees. So I jump to 59degrees east.....
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.
Replies
That's brilliant. I was toying with an alternative test (since I haven't got two Mediatek units available), of attaching a little hardware data logger unit, to the data coming out of the GPS itself, and recording this in parallel with the logged data. However finding suitable wires and plugs was getting a bit complex, and the weather here in the UK, (currently snowing), makes testing improbable, even for ground tests in the near future.
The odd thing about this, is I had 'loiter' working competently with 2.8.1, and never saw a 'I'm going to go dashing miles away' with this, but since switching to 2.9.1, it seems to happen just about every flight if using the loiter. This 'sudden appearance, simultaneous with switching versions', is what suggests something 'odd' is happening.
What (of course) is needed, is to average the GPS readings more, slowing the response to it, and reject any readings that show movement of more than some predetermined speed, then use the inertial data to provide the biggest input for 'short term hold'. This way momentary spikes (whatever the cause), won't give this sort of behaviour. If the position suddenly says 'move 50 feet', but the inertial is saying 'the copter is only slowly moving, and in the right direction', it'll provide the ability to reject the motion spike. I suspect this is how the Naza achieves such a good hold.
Best Wishes
Ok.
Have been playing more with the static tests.
Left copter on long USB over ethernet connection in the middle of my lawn. Ran static location tests on the flight data screen, watching HDOP, and the position. Used the Ublox, and the Mediatek, via the arducopter.
Typical 5 minute test on the Mediatek, hdop maximum 1.3, most of the time sitting at 1, and dropping on a couple of occasions to 0.9. Minimum satellites 9, max 12. Distance from 'home' however reached 52m max!....
Plot went right across three houses and the sports field behind me. 99% of the data was happily in the immediate vicinity, there were just a couple of points that were completely 'wayward'.
With the Ublox, distance from home reached 2m max.
With the Mediatek connected using NMEA, directly to Google Earth, largest distance recorded was 3m.
What is interesting is the huge movement recorded, is not happening using the NMEA interface.
It is as if one byte in the data stream, possibly is getting corrupted, and not getting picked up by the checksum handling, or the bad checksum is being ignored. I notice the Ublox data has a 'number of bytes' value, so a lost byte for instance would be detected.
Best Wishes
Hey Randy, is it possible to see the GPS location accuracy somewhere? I know you can see the number of sats, but what about accuracy? As in, 2.6m for example?
I've ordered a second different GPS module. An LEA-6H, and going to repeat the test (assuming it is not pouring with rain/snow tomorrow).
I might try also reading the data from the Mediatek unit directly with a PC, instead of using the Arducopter. Will update once I have some data.
In fact looking at the data, the position error in longitude is also almost nothing. A couple of metres. Almost the entire movement is lattitude.
The silly thing is it seemed about 100* better in 2.8.1.
Best Wishes
Let the system go 'locked' then waited a couple more minutes before starting.
The position reported by the radio control moved by a total of just under 8' for the entire test. It reported between 5 and 8 satellites.
The position reported by the arducopter logs had me over half a mile away from the start point at one time. Position was like a random 'drunkards walk', running to the north west and to the south east over quite a narrow diagonal line. The logs also showed 3dfix all the time, and reported between 5 and 9 satellites visible. The altitude only varied by 2m over the entire time. The linear nature, and the fact the altitude remained good (which is normally the first thing to decay), suggests something very odd is going on. Does this receiver use WAAS?. Is it possible it is somehow getting an incorrect offset from this, that is drifting badly?.
Motors were not running, so no RF interference from this, only the radio telemetry (Spektrum DX8, placed on the opposite side of the model).
The motion was jerky, but steadily moved to the north west, then after about 90 seconds reversed, came back across the starting point, and went to the south east. Then reversed again, and had nearly got back to the start when I finished the test. It was almost like perhaps a 6 minute cycle.
Had also changed the GPS cable and added spike filters to this before starting.
Ouch. No wonder position hold/loiter is not working!.....
Best Wishes
I'm seeing sudden movement glitches in 2.9.1.
It'll hold position sometimes for minutes without problems, and then suddenly decide it is a huge distance from where it wants to be, and head off at full speed. If one is lucky and nothing is in it's path, after a few seconds, it comes back (but the return always at relatively slow speed compared to the initial jump).
Why?. No idea. Sudden 'one sample' jumps in GPS positions can always happen. I have logs showing my Land Rover doing over Mach1, for a couple of seconds, when there was an update to the GPS clocks, but this was an 'announced' event late at night a while ago. When this doesn't happen, I have seen smaller jumps when (for instance) a mainline railway train passed close by. Sudden change in signal paths and reflections. However my separate telemetry GPS, recorded no jumps when the shifts occur, but was sampling at a much lower interval.
The obvious suggestions are:
1) An Olympic filter instead of any basic averaging.
2) A 'limit' value on movement speed, and rejecting values if the copter is detected to be moving out of position by more than (say) 30mph.
3) The one being worked on of including inertial data into the verification of movement required.
On my last such glitch, my brother was flying a Naza alongside my model, and this didn't shift more than a few inches, while on the Arducopter it was a test of reflexes to reselect stabilise mode before it hit a line of trees.
One of the reasons for my going the Arducopter route, was to have the goto waypoint options lacking in the Naza, but currently these appear to be potentially dangerous.
It does appear that for some reason this code is seeing momentary glitches in the data. Since it wasn't apparent on older versions, one wonders about something like an error in parsing values as a possibility. This is one that affects my telemetry, since I'm almost on the Greenwitch meridian, and the program to display the logs from my Spektrum system, suddenly jumps massively east when the position passes the meridian, taking the 'minute' value as degrees. So I jump to 59degrees east.....
Best Wishes
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.
-
1
-
2
-
3
-
4
-
5
of 5 Next