RemoteID/PositionManager: fix GCS Live GNSS position - #14587
Conversation
|
|
||
| static constexpr qreal kMinHorizonalAccuracyMeters = 100.; | ||
| static constexpr qreal kMinVerticalAccuracyMeters = 10.; | ||
| static constexpr qreal kMinVerticalAccuracyMeters = 100.; |
There was a problem hiding this comment.
This might need discussion. It solved the problem for me with Herelink but might not be generic.
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #14587 +/- ##
==========================================
+ Coverage 25.47% 32.65% +7.18%
==========================================
Files 769 784 +15
Lines 65912 67556 +1644
Branches 30495 31289 +794
==========================================
+ Hits 16788 22059 +5271
+ Misses 37285 30634 -6651
- Partials 11839 14863 +3024
Flags with carried forward coverage won't be shown. Click here to find out more.
... and 473 files with indirect coverage changes Continue to review full report in Codecov by Harness.
🚀 New features to boost your workflow:
|
Build ResultsPlatform Status
All builds passed. Pre-commit
Pre-commit hooks: 0 passed, 0 failed, 0 skipped. Test Resultslinux-coverage-integration: 37 passed, 0 skipped Code Coverage
Artifact Sizes
Updated: 2026-07-30 01:20:10 UTC • Commit: 847f415 • Triggered by: Android |
There was a problem hiding this comment.
Pull request overview
This PR improves the reliability of the Remote ID “Live GNSS” GCS position pipeline, primarily for Android and FAA-region requirements, by addressing timestamp freshness handling and altitude retention for 3D coordinates.
Changes:
- Stamp GCS GNSS “last update” using local arrival time (UTC) instead of the source-provided timestamp to prevent freshness flapping on platforms with offset provider clocks (e.g. Android).
- Increase the vertical accuracy gate from 10 m → 100 m and accept altitude when vertical accuracy is acceptable or not reported, to avoid dropping altitude and failing FAA 3D coordinate requirements.
- Adjust altitude-setting logic in
QGCPositionManagerto use the new vertical-accuracy behavior.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| src/Vehicle/RemoteIDManager.cc | Changes freshness timestamping for Live GNSS updates to use local arrival time. |
| src/PositionManager/PositionManager.h | Raises the vertical accuracy threshold constant to 100 m. |
| src/PositionManager/PositionManager.cpp | Updates altitude acceptance logic to retain altitude under broader (and Android-compatible) conditions. |
| if ((update.coordinate().type() == QGeoCoordinate::Coordinate3D) && verticalAccuracyOk) { | ||
| newGCSPosition.setAltitude(update.coordinate().altitude()); | ||
| } |
| if (update.isValid()) { | ||
| _lastGeoPositionTimeStamp = update.timestamp().toUTC(); | ||
| // Stamp the local arrival time rather than update.timestamp(). The freshness | ||
| // check in _sendSystem() compares this against the local wall clock, and on some | ||
| // platforms (e.g. Android) the position source's own timestamp is offset from the | ||
| // system clock, which made gcsGPSGood flap green/red even with a healthy fix. | ||
| _lastGeoPositionTimeStamp = QDateTime::currentDateTimeUtc(); |
|
@julianoes Can you look at the review? |
PR #14587 — Implications of the
|
|
2 and 3 are the main problems. 3 was already a bit whacky, but 2 will lead to real problems. |
|
Sorry, missed this. I'll revisit it. |
fced979 to
b8fa876
Compare
|
Reworked: the vertical accuracy gate in
|
Consumers which need to know how fresh gcsPosition is had to fall back on the timestamp of the raw QGeoPositionInfo, which comes from the position source's own clock (on Android offset from the system clock) and is stamped even for updates the accuracy gate rejected. Record the local arrival time of the updates which actually make it into gcsPosition and expose it as gcsPositionTimestamp().
Two problems made Live GNSS unusable on Android in FAA regions: Altitude: QGCPositionManager only copies the altitude into gcsPosition when the fix reports a vertical accuracy within 10m, which the Android position source almost never meets. That left a 2D coordinate, so the FAA check in _sendSystem() hard-failed. Take the altitude straight from the fix for the Remote ID message rather than loosening the gate for everyone: OPEN_DRONE_ID_SYSTEM has no accuracy field for the operator altitude, so a loosely known altitude beats none, whereas the other consumers of gcsPosition act on it (Follow Me sends it as FOLLOW_TARGET altMetersAMSL, update-home-position as MAV_CMD_DO_SET_HOME) and keep the strict gate. Freshness: the check compared the position source's own timestamp against the local wall clock. On Android the two clocks are offset, and an offset near the 5s ALLOWED_GPS_DELAY threshold made gcsPositionUsable flap at 1 Hz despite a healthy fix. It also stamped updates which the accuracy gate rejected, so a fresh-looking status could accompany stale coordinates. Use QGCPositionManager::gcsPositionTimestamp() instead, which measures the true time since the last position that gcsPosition was actually updated from.
b8fa876 to
847f415
Compare
|
Thanks @julianoes |
Two fixes so the Live GNSS Remote ID GCS position works on Android / in FAA regions.
_updateLastGCSPositionInfo()storedupdate.timestamp()(the source's clock), which on Android is offset from the system clock the freshness check compares against — makinggcsGPSGoodflap at 1 Hz near the 5 s threshold. Now stamps local arrival time.