Investigate what default should be used for SBAS - NONE or AUTO

[iforce2d]

Attempting to use ground assistance in regions with poor SBAS coverage can cause many satellites to be ignored (all GLONASS sats and even many GPS sats too). In the worst cases, this can cause GPS fix to be abandoned completely.

http://www.rcgroups.com/forums/showthread.php?t=2495732&page=384#post34725614

Currently there is no option in the configurator to disable the ground assistance type used by the GPS receiver. It's either auto, or a specific SBAS region.

By doing set gps_auto_config=OFF in the CLI, it is possible to skip all GPS module settings, but this is not ideal for two reasons:

1. Skipping GPS config does not disable SBAS, it just does not enable it (ie. if it was already enabled it will remain enabled)
2. Skipping GPS config also skips all the setup necessary to use UBX protocol for most modules which use NMEA by default.

I think it would be great to have a 'Disable' option in the 'Ground assistance type' combobox in the configurator.

[digitalentity]

Shame on me! I forgot about SBAS! The recent complaints about sat loss might in fact be related to ground assistance - since this is the only thing that does not get enabled when doing manual config and is enabled in auto.

[digitalentity]

0037380fc0e09ef2600eb82626cd4dee79867953 allows to disable SBAS. Settings changed - those who had it set to AUTO will now get DISABLED.

[iforce2d]

Thanks! From a backwards compatibility point of view I would be more inclined to add the new option at the end of the enum so that existing installs are not affected.

[theArchLadder]

I think disabling SBAS is the wrong approach and here's why:

After reading the wiki this is my understanding of SBAS: A few ground stations with known locations receives the GPS satellites and measures/figures out a few different errors in the GPS signal/position etc, then this information is sent to a SBAS satellite that then broadcasts this correction information that our multirotors can receive to get a more accurate position reading. Sounds like a good thing to have.

I have been playing around in u-center, i have plenty of both gps and glonass sats used, but when i get a lock to a SBAS sat, all my GLONASS sats becomes unused, so this is the "gps dropout" problem we'll been having.

But, i think i found a solution that lets us have the cake and eat it too! :)

In u-center, there is a setting for SBAS called "apply integrity information", with inav default this is enabled, but it's disabled with ublox defaults. When i disabled this, i no longer lost my GLONASS sats! I have been bench testing for more than an hour and i have around 15 sats all the time while having SBAS lock, even though my gps unit is close to my house. Yay!

I think the code here https://github.com/iNavFlight/inav/blob/master/src/main/io/gps_ublox.c#L143 Should be changed to this, please confirm this though since i had some issues with hex stuff in u-center

EDIT: Checksums are wrong here, do not use these lines!

    { SBAS_AUTO,  { 0xB5, 0x62, 0x06, 0x16, 0x08, 0x00, 0x03, 0x03, 0x03, 0x00, 0x00, 0x00, 0x00, 0x00, 0x31, 0xE5}},
    { SBAS_EGNOS, { 0xB5, 0x62, 0x06, 0x16, 0x08, 0x00, 0x03, 0x03, 0x03, 0x00, 0x51, 0x08, 0x00, 0x00, 0x8A, 0x41}},
    { SBAS_WAAS,  { 0xB5, 0x62, 0x06, 0x16, 0x08, 0x00, 0x03, 0x03, 0x03, 0x00, 0x04, 0xE0, 0x04, 0x00, 0x19, 0x9D}},
    { SBAS_MSAS,  { 0xB5, 0x62, 0x06, 0x16, 0x08, 0x00, 0x03, 0x03, 0x03, 0x00, 0x00, 0x02, 0x02, 0x00, 0x35, 0xEF}},
    { SBAS_GAGAN, { 0xB5, 0x62, 0x06, 0x16, 0x08, 0x00, 0x03, 0x03, 0x03, 0x00, 0x80, 0x01, 0x00, 0x00, 0xB2, 0xE8}}

the 8th number should be 0x03 instead of 0x07 as long as i got everything right... I guess the last two are some error checking

[theArchLadder]

To clarify: I think it would be wrong to have "SBAS disabled" as the default, I'm not against a "disabled" option even though i don't see any use for it with my fix...

[stronnag]

I fear you have forgotten to update the checksums, and the hex strings should be (according to my tacky little ub_chk script):

0xb5, 0x62, 0x06, 0x16, 0x08, 0x00, 0x03, 0x03, 0x03, 0x00, 0x00, 0x00, 0x00, 0x00, 0x2d, 0xc9
0xb5, 0x62, 0x06, 0x16, 0x08, 0x00, 0x03, 0x03, 0x03, 0x00, 0x51, 0x08, 0x00, 0x00, 0x86, 0x25
0xb5, 0x62, 0x06, 0x16, 0x08, 0x00, 0x03, 0x03, 0x03, 0x00, 0x04, 0xe0, 0x04, 0x00, 0x15, 0x81
0xb5, 0x62, 0x06, 0x16, 0x08, 0x00, 0x03, 0x03, 0x03, 0x00, 0x00, 0x02, 0x02, 0x00, 0x31, 0xd3
0xb5, 0x62, 0x06, 0x16, 0x08, 0x00, 0x03, 0x03, 0x03, 0x00, 0x80, 0x01, 0x00, 0x00, 0xae, 0xcc

or in terms of the new branch settings:

 {{ /* SBAS_NONE */  0xb5, 0x62, 0x06, 0x16, 0x08, 0x00, 0x02, 0x03, 0x03, 0x00, 0x00, 0x00, 0x00, 0x00, 0x2c, 0xc1 }},
 {{ /* SBAS_EGNOS */  0xb5, 0x62, 0x06, 0x16, 0x08, 0x00, 0x03, 0x03, 0x03, 0x00, 0x51, 0x08, 0x00, 0x00, 0x86, 0x25 }},
 {{ /* SBAS_WAAS */  0xb5, 0x62, 0x06, 0x16, 0x08, 0x00, 0x03, 0x03, 0x03, 0x00, 0x04, 0xe0, 0x04, 0x00, 0x15, 0x81 }},
 {{ /* SBAS_MSAS */  0xb5, 0x62, 0x06, 0x16, 0x08, 0x00, 0x03, 0x03, 0x03, 0x00, 0x00, 0x02, 0x02, 0x00, 0x31, 0xd3 }},
 {{ /* SBAS_GAGAN */  0xb5, 0x62, 0x06, 0x16, 0x08, 0x00, 0x03, 0x03, 0x03, 0x00, 0x80, 0x01, 0x00, 0x00, 0xae, 0xcc }},
 {{ /* SBAS_AUTO */  0xb5, 0x62, 0x06, 0x16, 0x08, 0x00, 0x03, 0x03, 0x03, 0x00, 0x00, 0x00, 0x00, 0x00, 0x2d, 0xc9 }},

[DzikuVx]

Yay... no more broken landing gear on emergency landing? Cool! And by the way I also agree with @theArchLadder that disabling "integrity check" might be better than forcing SBAS disabled in AUTO configuration

[theArchLadder]

I just did a flight test, almost all my logs from before look similar to the first graph, thats a flight from yesterday, last two graphs are with the fixed setting i talked about here, looks great! I guess it's to early to call out victory from just one test flight, but this feels promising since i did the testing in u-center with the same result earlier today.

[digitalentity]

@theArchLadder, @stronnag thanks for figuring the new ubx sentences! I've also switched AUTO and NONE, existing setups won't be broken.

[iforce2d]

I noticed that the defaults for these settings are to disable the test satellites and integrity information: This is a good hint from the manufacturer that the best typical setting is to have these disabled. It might also explain why the dropping satellites behavior stopped for some users when they turned gps_auto_config off, because the Cleanflight config enables everything.

By the way, it's pretty easy to get the hex strings and checksums from u-center, no need to calculate them yourself. Here's the setting that Cleanflight has been applying until now - everything on hehehe... And here is the default setting according to the Ublox docs: This is what @theArchLadder has suggested above, but with test satellites disabled as well. I'm about to test this now, will update later.

Side note: isn't it great to be able to discuss a single topic in one thread without dozens of different conversations going on, across hundreds and hundreds of pages? I can't stand the way threads are done on RCGroups, which is why I hardly ever post there despite having an account for a long time. And the other suggestion I hear about asking on the IRC chat is even worse, don't get me started. I think a dedicated Cleanflight forum is long overdue... anybody else agree?

[iforce2d]

I tested with settings as in the last screenshot of my post above, but I think for my geographical location this is not ideal either. The problem is that when SBAS kicks in the quad will suddenly re-position itself. It usually only moves about 2-3m in the cases that I saw, but the movement is very sudden and 2-3m is further than the 1.5m or so range that it stayed within when I had SBAS disabled completely. Position hold did seem slightly better, but not significantly.

I guess it will depend on how spotty the SBAS signal is in your location and what you're using your multi-rotor for, but I think for my situation I'll stick with the SBAS_NONE setting to be safe.

[digitalentity]

@iforce2d Yes, IIRC SBAS is used to improve absolute accuracy that is only relevant when doing autonomous flights (missions). For poshold and RTH we use relative positioning and SBAS probably won't greatly improve perfomance

[digitalentity]

I wonder if we can upgrade to 3 settings for GPS nav model: LOW_G = Pedestrian (better GPS reception, suitable for slower drones) MED_G = Airborne<1G (a balanced setting) HIGH_G = Airborne<4G (top-end performance at cost of higher sat quality requirement)

[oleost]

@digitalentity Good idea, but I would be very carefull with Pedestrian.

Atleast not default, and with warning that this is mostly for only flying in GPS assisted modes with limited speed.

There are multiple of us having fly aways with Pedestrian.

I know other flightcontroller have success with Pedestrian, maybe there is an issue with iNav how it uses the GPS data ?

[theArchLadder]

@iforce2d I use linux (archlinux) so i run u-center in wine and i have also tried it in virtualbox on window7. In the settings window there is a small button in the bottom row called "show hex toggle", but it's grayed out for me do i can't click it. So i can't get u-center to show me the hex codes... How do i get that to show?

@digitalentity Sounds good but IMHO LOW_G should not be the default because of the fly-away risk. I have not tried <1G yet...

@digitalentity Do you think we could bbox log the SBAS status?

I took a closer look at the log from the graphs i posted here before, and GPS height seems very accurate! I just happend to stand next to a lake that i know is 88 meters above sea level, and i was standing around 5 meter above that lake, and indeed, the GPS height shows 93 meters! It only logs at meter-precision, but it looks like GPS height follows baro height really well, i need to start logging GPS height at centimeter-precision... I'm curious if the GPS can be used for althold when it has a good HDOP/sat count and SBAS...

EDIT: Would be awesome if someone could tell me where i change from meter to centimeter for gps height logging... EDIT2: is it just here? https://github.com/iNavFlight/inav/blob/master/src/main/blackbox/blackbox.c#L992

[iforce2d]

@theArchLadder I'm using u-center via wine in Fedora linux and the hex toggle button just works, don't know how to help about that. I did notice though, that when the hex panel is hidden, you don't need the button to show it, you can just drag the divider upwards from the bottom of the window. I also noticed that if I drag the divider all the way down when the hex view is showing, it sets the hex view size as zero so that subsequently the button appears to have no effect - perhaps you did this earlier?

[theArchLadder]

@iforce2d The divider works as you say for "full form toggle" (left side panel), and i can just drag that back, but there is no divider at the bottom... Same thing in both wine and windows7. What version of u-center are you running? I use v8.20

As for your side-note from before: Yes i agree, this is much better than RCGroups. I like how we all helped in our own ways to solve this together, even though you made most of the work... This really show the beauty of open-source development :) I think this issue tracker should be used more, and with wider topics for discussing possible solutions/improvements... Not just "Solve this specific bug with this solution".

[digitalentity]

@theArchLadder LOW_G (Pedestrian) won't be a default, it would be a user-selectable option. I also think we need better names for these LOW_G, MEG_D, HIGH_G. Ideas, anyone?

We don't collect SBAS or SV data from GPS unit for the sake of minimizing the jitter of GPS data - that's why we have detailed satellite information removed.

GPS altitude is used for AltHold in airplanes and it works rather well.

[theArchLadder]

Has anyone been able to find any information on how big the improvement in accuracy usually is with SBAS? How can i tell in u-center if my GPS is using SBAS or not...?

[iforce2d]

@theArchLadder I'm using u-center v8.13. In one of the docking panels with status display of lat/lon, HDOP, 3D Acc etc there is a 'Fix mode' which should display 'DGPS' when the fix is currently using differential GPS.

I would be surprised if the SBAS improvement is any more than a few meters. I think to be sure about that you need a location for which you know the absolute real lat/lon, not as easy as you might think :)

[theArchLadder]

https://en.wikipedia.org/wiki/Global_Positioning_System#Accuracy_enhancement_and_surveying This claims that accuracy can go from 15 meters to 3 meters with SBAS-WAAS.

https://en.wikipedia.org/wiki/Wide_Area_Augmentation_System#Accuracy This claims that "Actual performance measurements" show better than 1 meter accuracy.

I watched some youtube videos and got the impression that SBAS is very important for aviation when doing landing approach in fog etc.

So it seems to provide a big benefit, but the question still remains if it's only absolute accuracy, witch is not that important to us, or if it also improves relative accuracy... I guess i will have to try and do some test myself...

[theArchLadder]

I just did a test flight with GPS enabled for althold with these settings: inav_w_z_baro_p = 0.00 inav_w_z_gps_p = 0.500 inav_w_z_gps_v = 0.200 And it sort of works, it's more stable compared to baro, non of those jumping up and down, but it did drift very slowly 2-3 meters up.

I then tried these settings: inav_w_z_baro_p = 0.100 inav_w_z_gps_p = 0.000 inav_w_z_gps_v = 0.200 And it did look smoother than just baro. Perhaps using both gps and baro could be a good thing for althold, more testing and tuning will tell i guess.

Blackbox got full so no logs :(

[iforce2d]

Absolute accuracy implies relative accuracy, doesn't it? It's relative to 0,0 :) When I lived in Japan with good SBAS coverage I did many tests where I matched the results of two separate modules (a 'follow-me' RC car) and it worked very well, often to the meter. I'm planning to do this with a quad now in NZ without SBAS, so I really hope the uncorrected position error of the two modules is the same.

[digitalentity]

@theArchLadder your settings didn't make AltHold use GPS. Multicopter: BARO only even if GPS is avaliable Airplane: BARO + GPS fused together per inavw* settings.

[theArchLadder]

Well, if the absolute position on average has a 10 meter error to east, it would be possible to just offset the position with 10 meters towards west, but this would not improve relative position, right?

[iforce2d]

Relative to what?

[digitalentity]

@iforce2d relative to point of launch.

[theArchLadder]

@digitalentity I removed STATE(FIXED_WING) from here: https://github.com/iNavFlight/inav/blob/master/src/main/flight/navigation_rewrite_pos_estimator.c#L519 I think this should be enough to use gps, right? I doubt it would hold altitude that well without any position sensor...?

[DzikuVx]

Relative to previous readout/point of launch. PosHold needs to know diff between current and target position that was also recorder by current readout. So it does not matter if acquired position is 10m to East or even 100km to south. As long as each acquired position has low error comparing to target, everything is OK. But if you plan WAYPOINT to move to x/y and UAV thinks x/y is somewhere else, there will be a problem. This is absolute

[iforce2d]

I see. Maybe repeatability is a better word. No, I don't think SBAS will help with that.

[digitalentity]

@theArchLadder @DzikuVx @iforce2d I think "Disabled" is a safer default. SBAS kicks in significantly later than initial fix is acquired. This may happen when the quad is already in flight and will introduce some unknown shift to absolute positioning. This will cause PosHold to change position rapidly but what's even worse - it will change the launch point position! RTH will return the quad to a different point!

[theArchLadder]

@digitalentity Have you seen this shift in testing?

I have done multiple flights now and i have not seen any shifts in either poshold or home-location. But i guess safety and consistency is more important than peak performance, so perhaps "disabled" is a better default.

I think the real question that needs to be answered is if SBAS does improve relative position accuracy or not...

[digitalentity]

I have seen a sudden single occurance of position drift a few times (2-3m usually). Suspected bad sat coverage (it was 6-7 sats), but now I figure it might actually be SBAS kicking in.

[iforce2d]

I saw shifts a few times within about ten minutes, I must be in a pretty bad location for this :) For me it was also about 2-3m, and along the same direction each time. This was with SBAS enabled and the integrity information disabled. I often test hovering just off the ground, in those cases I rarely see it until I go higher.

Yes, I think disabled being the default is safer and might avoid some "what's going on?!" moments for newer users. If possible a 'what is SBAS?' link to info in the configurator might help people to decide in a more educated way than just thinking "uhh... auto is good right?" like I have been doing all this time :) It would be a pity not to use it if you live in a region with good coverage, which is probably the majority of users.

[theArchLadder]

@iforce2d Are those shifts gone when you disable SBAS though?

[iforce2d]

@theArchLadder so far, yes. https://www.youtube.com/watch?v=odConQAhMsY I'll do some more testing this week.

[theArchLadder]

@iforce2d Good to know, i will also investigate this, my plan right now is to leave my quad sitting in a field while the blackbox is recording and do this for like 15 minutes with SBAS off, then SBAS on, and calculate the average RMS error to the average position... And i guess max/min error could also be interesting. And graphs... Well this escalated quickly!

If anyone has a better idea on how to measure the relative position accuracy, let me know!

EDIT: Would be nice to have a way to confirm that SBAS is active, i don't have a laptop so using u-center will be difficult...

[digitalentity]

Guys, what do you think about 1f49891? Now 3 dynamic modes for Ublox autoconfig - conservative PEDESTRIAN, somewhat optimal AIR_1G and extreme AIR_4G. I've also renamed the setting to avoid confusion.

[digitalentity]

@theArchLadder we can subscribe to an SBAS message, but do we have any use for this info?

[theArchLadder]

@digitalentity Looks fine to me, naming is more clear but harder to remember, is there a way to list possible alternatives for an setting in cli?

As for SBAS: I think this would be useful for debugging and investigating the benefit of SBAS.

[digitalentity]

Something like set parameter_name=? could list min/max or alternatives. Good idea. Opening an issue for this - #198

[stronnag]

Tested 1f49891, never seen the sat count so stable. Great fix.

[digitalentity]

@stronnag thanks for testing. I'll merge this after testing on a not-so-good Ublox7 module today that seem to work acceptable only with Pedestrian setting.

[theArchLadder]

Please merge ASAP, it's a big improvement over current code... And i keep forgetting to merge sbas-none branch into my own custom build branch :wink:

IMHO we should keep this issue open to investigate if NONE or AUTO should be the default.

[iforce2d]

Tested 1f49891, behavior seems the same (not sure what I'm looking for exactly) except that this time it showed 18 satellites, first time I have seen that many since disabling SBAS. Of course this might just be dependent on their current position in orbit...

[digitalentity]

Ok, SBAS code merged as well as new gps_dyn_model code. Issue renamed to conclude default settings.

[theArchLadder]

I did a very basic test today. I started with sbas=NONE. I powered up my quad and waited a few minutes until i had 19 sats or so, i then armed and let it sit there for 15 minutes, i then changed to sbas=EGNOS, powercycled and did the same thing again.

In both test the error radius was around 3 meters from the average position and it looks like the position difference between the two tests was less than a meter.

There are a few problems with this though

1. I have no way to tell if SBAS was actually used.
2. I have yet to come up with a accurate way to calculate the average of 10000+ floats to high precision, ideas? I'm using processing now and it behaves a bit weird with floats and doubles.
3. Only two tests are to few to really draw any conclusions.

IMHO, the only take-away is that i did not see a massive improvement (or any for that matter) in relative accuracy when using SBAS.

I also checked position with my android devices, one galaxy S4 (uses gps+glonass, but no sbas AFAIK), and an old galaxy S2 (only gps). S4 was 1.5-2 meters away from both tests, i have seen up to 5 meters when trying follow-me though, sbas=EGNOS on the quad. S2 was 11 meters wrong.

[theArchLadder]

Did some flying with sbas=NONE and it felt like home position moved more than usual. Could just be a coincidence though, so as always, more testing needed.

[digitalentity]

I didn't notice any difference between auto and none neither in position hold accuracy nor rth accuracy. Not sure if my crappy Ublox7 is using sbas at all.

[theArchLadder]

I think we need to log sbas status if we should be able to investigate this, but adding that feature is sadly beyond my skills.