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.

Views: 23832

Reply to This

Replies to This Discussion

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

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

 

Eddie,

     You're absolutely right (like many of us on the dev team found out) that the UBLOX is well worth the extra $50 it costs over the mediatek especially when compared with the original built-in mediatek which has a very small antenna.  Below is the path my mediatek bounced around during my testing yesterday (using the AC 2.8.1 as "master").  It's actual location is shown by the arrow - it's on my balcony.  It's moving at least 100m at times.

William (Bill?),

     Yes, that's how it works.  So ArduCopter/ArduPlane/ArduRover just take the 2D Lock and 3D Lock from the GPS itself.  The data that appears in the dataflash logs and tlogs (i.e. where we've seen jumps) is the data directly from the GPS ("directly" = we parse the incoming stream from the GPS, put the values into global variables and dump them into the logs).

     Re the distance to a waypoint, we do that all internally to AC/AP/AR instead of relying on the GPS.  These calculations are pretty straight forward and as you say shouldn't lead to the complaints that people are talking about related to missing points or points in the wrong place.

     I like the suggestion for using a threshold based on HDOP to ensure a good home location.  I had been thinking about making sure that the position hadn't changed by more than x cm but your method sounds much more straight forward and again it puts all the pressure on the gps to do it's job which I like! :-).

     The only thing that I disagree with you about that we definitely see the GPSs reporting bad positions...but actually we always have even on 2.8.1.

     ..anyway, I'm continuing my investigations.  Next I will be comparing the position accuracy of two mediatek GPSs running side-by-side with one attached to an AC 2.8.1 and the other an AC 2.9.1 APM.  The only thing that I can see that has changed re the Mediatek between 2.8.1 and 2.9.1 is

      1. WAAS_ON message was changed from:

#define WAAS_ON             "$PMTK301,2*2E\r\n"

#define WAAS_ON_281            "$PSRF151,1*3F\r\n"

     2. NAV_THRESHOLD config is sent on startup.  I don't know what this is for yet.

#define MTK_NAVTHRES_OFF     "$PMTK397,0*23\r\n"

#define WAAS_ON_281            "$PSRF151,1*3F\r\n"

was for the original Sparkfun SiRF.  It is the wrong command for the Medatek and was erroneously copied from the old driver when the switch was made between SiRF to MediaTek.

#define WAAS_ON             "$PMTK301,2*2E\r\n"

is the correct one for Mtek.

#define MTK_NAVTHRES_OFF     "$PMTK397,0*23\r\n" sets the minimum speed the GPS must be moving to update the position to 0 m/s

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.

@ 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

 

Michael,

     Just for the benefit of other reads of this thread, I'll just clarify that the concerns for 2.9.1 & GPS position are all related to the Mediatek which doesn't have this setting.

     ...that said, I'm sure I've read or heard from Tridge (and perhaps others) that we should consider doing exactly what you are proposing.  It's very possible.  For people who would like to experiment with changing this setting, in the 2.9.1 code, this is set in system.pde around line 240.

// GPS Initialization
g_gps->init(GPS::GPS_ENGINE_AIRBORNE_1G);

     The GPS_ENGINE_AIRBORNE_1G part can be replaced with any of the following:

        GPS_ENGINE_NONE
        GPS_ENGINE_PORTABLE
        GPS_ENGINE_STATIONARY
        GPS_ENGINE_PEDESTRIAN
        GPS_ENGINE_AUTOMOTIVE
        GPS_ENGINE_SEA
        GPS_ENGINE_AIRBORNE_1G
        GPS_ENGINE_AIRBORNE_2G
        GPS_ENGINE_AIRBORNE_4G

     Changing it dynamically depending upon the navigation mode (i.e. waypoints or loiter) is a little tougher but very do-able.    I can't make any promises when I will get to trying this out but I'd be interested in other's giving it a go!

so i will do some test´s. i just received my u-bolx 2h ago.

 

@Randy,

I tested both the MediaTek v1.9 and v1.6 firmware yesterday and I found the v1.6 had much less drift than the v1.9 when just sitting in a static position. I was recording 8 - 9 sats and a HDOP around 1 sitting in the middle of my house. I let the GPS run for about 3 hours.

Regards,

TCIII

Thomas,

    That's interesting.  thanks for doing this comparison.  I guess I'd like to see the tlogs or kmz files if you have 'em.  The only thing is that slightly worries about this method of testing is that it's in your house.  We always tell people not to trust the GPS signals in their house because of the multipath (see previous page of this discussion).  Two ways to look at it...(1) better accuracy is always better even when in your house OR (2) the test isn't representative of real flying conditions so we shouldn't aim to achieve better performance in this environment.

Randy,

You said:

"The only thing that I disagree with you about that we definitely see the GPSs reporting bad positions...but actually we always have even on 2.8.1."

Questions:

Did this only happen on the mediatek or with the ublox as well?

Would the GPS reporting wrong positions explain why I have seen the following with 2.8.1?

(Haven't gotten to fly 2.9.1 yet I'm rebuilding my vehicle to push some of the wiring count down and move some components around.

I experienced the following 10-20 times with 2.8.1:

RTL - Runs off wrong way

Stab - works

RTL - Comes home

There was 1 time where I was safe enough to let RTL run for a while in the wrong direction and it seemed after 10-12 seconds it turned and came nearly home but stopped like 20m short and hovered.

Reply to Discussion

RSS

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service