[Docs] GNSS-Denied Configuration #25955
Conversation
hamishwillee
force-pushed
the
gnss_denied_config
branch
2 times, most recently
from
4844e0e to
efcc893
Compare
hamishwillee
force-pushed
the
gnss_denied_config
branch
from
efcc893 to
e09f2ca
Compare
|
@ryanjAA @dirksavage88 After much thought I have made this particular PR and document purely cover the dead-reckoning mode (and by extension a little on the automatic mode, because it is hard to explain without contrast). This has the benefit that I can make it very clear that this is an experimental feature (as per your feedback). The docs borrow extremely heavily from your original notes @ryanjAA - thank you. I'll add a few questions in line (and I plan to come back to the pure no-GPS case) |
| MC vehicles benefits more because it can hover when transitioning between sensor regimes. | ||
| FW needs continuous accurate velocity/position during the entire mission arc, making sensor transitions trickier. |
There was a problem hiding this comment.
I'm not sure what you are saying here.
- Are you saying that an MC that loses or gains GNSS will hover for a bit while it fuses or stops fusing data? How does that help if you're in a position controlled mode - you'll still jump when the position updates because the system suddenly realizes you're not where you are supposed to be.
- Ditto for FW. You always want accurate position estimate. I think you might be saying that an FW doesn't adjust so well to position estimate changes because it can't, for example, fly sideways?
There was a problem hiding this comment.
Only comment would be if we want clarity here:
Dead-reckoning mode helps both Fixed-Wing and Multicopter vehicles.
Multicopters can stop or hover while the estimator transitions between GNSS and non-GNSS sensors, which makes these transitions easier to manage.
Fixed-Wing aircraft must maintain continuous forward flight, and require continuously accurate velocity and position estimates throughout the entire mission arc. Because of this, any drift that accumulates during GNSS outages has more pronounced consequences when GNSS recovers or sensor fusion modes change.
| - You have **redundant sensors** (optical flow, VIO, rangefinder, quality baro) that can maintain position estimation. | ||
| - Flying **missions that cross GPS-denied areas** where you want continuous operation rather than failsafe. | ||
| - **Urban environments** or other areas with intermittent GNSS quality. | ||
| - You want to **avoid EKF resets and jumps** when GNSS recovers (smoother transitions). |
There was a problem hiding this comment.
My understanding is that
- in the normal automatic mode you get a reset on fault for losing GNSS - EKF resets and fuses whatever data it has, and will drop out of any automatic mode and failsafe into some other mode. When GNSS is recovered I think it resets again and starts fusing the data - which allows you to go into a position controlled mode. There is no jump here though, because you aren't in a position mode, when you recover GNSS, so the vehicle never thinks you need to be moving anywhere.
- in the dead reckoning mode you don't reset when you lose GNSS and you don't failsafe. YOu keep flying along using your IMU/vision/optical flow estimated position. When you regain GNSS what happens? I have been assuming that you'd start fusing the GNSS, get a new position, NOT reset, but you would have a big jump.
Upshot, I thought you got more jumps in the dead-reckoning case. What am I missing on the lose/gain GNSS in each case.
There was a problem hiding this comment.
Yes, according to Marco in this talk yes in normal non dead reckon mode ekf2 resets if we lose GNSS, but with dead reckoning enabled EKF2 does not reset.
For the second bullet point, this is a good question. I would imagine that you don't failsafe for a timeframe -at least until some flag invalidates local position if optical flow is problematic at high altitude and/or error accumulates (IMU drift is a function of time). I am not sure what the vehicle behavior will be when GNSS starts being fused again (especially if we are in position mode with stick input). This implied "jump" is what we probably need to do more IRL tests to see.
Dead-reckoning mode: If estimated position/altitude is close enough to measurements, fusion resumes; if too far apart, data gets labeled as faulty.
ryanjAA
left a comment
ryanjAA
left a comment
There was a problem hiding this comment.
Everything looked good on my end. Whether you want to change that one part is here nor there. It looks great.
| MC vehicles benefits more because it can hover when transitioning between sensor regimes. | ||
| FW needs continuous accurate velocity/position during the entire mission arc, making sensor transitions trickier. |
There was a problem hiding this comment.
Only comment would be if we want clarity here:
Dead-reckoning mode helps both Fixed-Wing and Multicopter vehicles.
Multicopters can stop or hover while the estimator transitions between GNSS and non-GNSS sensors, which makes these transitions easier to manage.
Fixed-Wing aircraft must maintain continuous forward flight, and require continuously accurate velocity and position estimates throughout the entire mission arc. Because of this, any drift that accumulates during GNSS outages has more pronounced consequences when GNSS recovers or sensor fusion modes change.
|
No flaws found |
PX4 now has quite a bit of support coming for flight in GNSS denied environment, and also some existing support. Following discussion in #25664 (comment) this will add a base for that information.