AP_ADSB: add OPTION bit to Prefer_ARHS_for_Location instead of GPS #19054
Conversation
|
@nicholas-inocencio what do you think about this? |
|
Better to preserve the current behaviour as default rather than having the current behaviour opt-in. ADSB is in people's safety cases and we shouldn't change it from underneath them. Thanks for he explanation in the comments - WikiNeeded? - but don't you find it a little odd that you're happy to navigate the aircraft with bodgy positioning but reporting from the GPS?! i.e. you are not reporting where you think you actually are! Wouldn't it be better to configure the AHRS to use GPS altitude? It can be pretty good now-adays. Snazzy use of scripting and EKF3 sources would allow you to switch sources depending on estimated altitude if you're finding GPS is a problem down low. |
|
We had experimental ADS-B firmware builds that would switch over to GEO altitude above 60k because, as @magicrub described, its more accurate at high altitudes. Unfortunately, FAA requested we do NOT do this, so we've since reverted that in subsequent experimental firmware releases. Another reason they wanted transponders to continue transmitting baro altitude is DO-260B only allows for 3 message types for geometric altitude NIC=11, NIC=10 and NIC=0 (TYPE 20,21,22 below) where as baro altitude as a full range of NIC values (TYPE 9-18). In other words, if using geometric altitude and if the GPS source doesn't have current ionospheric correction data to get the position integrity above a NIC of 9, the position is essentially thrown away since it has to be set to TYPE 22/NIC 0. Regulators would rather have consistent position information despite poor baro performance if the aircraft doesn't have an adequate barometer for the altitudes it's flying. It's a shortcoming in DO-260B which is being address in DO-260C.
|
|
@peterbarker the problem is that the current implementation is wrong and the new option bit allows for the corner cases, not the other way around. |
Right but if implemented to DO-260C, the Version 3 bit must be set otherwise other fields can be mis-interpreted by receivers. |
|
To be clear, this PR is addressing what populates the "GPS altitude" position in the transponders. In the case of Ping 200X, the transponder is already using it's own integrated Baro with a static ground-pressure reference of 29.92-ish? For the GPS fields, the existing code feeds it whatever the AHRS/EKF thinks the position/altitude is and that diverges badly from reality when using pure Baro above a few thousand feet. The only reason I'm even considering keeping AHRS in there at all is because the ADSB library has been known to be used by non-ADSB applications for object avoidance. |
| // With the ADSB_OPTION bit set, we'll never use GPS direct. Always prefer AHRS which could be GPS, beacons, VICON ect | ||
| // The benefit of using GPS is it uses GPS Pos+Alt where AHRS is a mixture of sources. AHRS default is position = GPS and Alt = baro | ||
| if ((AP::gps().status() >= AP_GPS::GPS_OK_FIX_3D) && ((_options & uint32_t(AP_ADSB::AdsbOption::Prefer_ARHS_for_Location)) == 0)) { | ||
| _my_loc = AP::gps().location(); |
There was a problem hiding this comment.
do we need to cope with dead-reckoning when we lose GPS? should we give AHRS solution at that point?
we may need option bits to separate horizontal pos source and vertical |
|
#17179 is relevant |
Add ADSB_OPTION bit to Prefer_ARHS_for_Location instead of GPS. Current behavior always uses AHRS but ADSB-Out expects gps position and gps altitude. The AHRS default is GPS position and Baro altitude and that causes a lot of error at higher altitudes, especially because of reasons #17984 is trying to address.
I pulled this out of #19049 as a separate PR.