Custom dead-reckoning script (not the stock one) — convergence-then-divergence question
I’m running a custom version of the dead-reckoning concept, not the stock copter-deadreckon-home.lua. Instead of freezing the bearing to home once and flying a fixed heading, mine continuously re-reads the EKF’s live position estimate and re-solves a wind triangle every ~100ms, so it keeps re-aiming toward home instead of committing to one snapshot.
ANY SUGGESTION HOW CAN I IMPROVE MY SCRIPT?
My doubt: with a short timeout it lands close to home, but with a longer timeout it converges nicely early on, then drifts away again before landing — ending up further out than where it already got to. Anyone seen this with EKF3 dead-reckoning, or know a better way to detect “this is as good as it’ll get, land now”?
That’s not dead reckoning, and you will encounter major issues attempting to converge on a drifting MEMS IMU. Don’t. The script, as provided, is about as good as it gets. Maybe it could be improved, but I have no interest in open source non-GPS applications.
Thanks for the clarification. I understand the limitations of MEMS IMUs, and I’m not trying to achieve long-duration GPS-denied navigation. My goal is simply to maximize the chance of getting close to home after a sudden GPS loss.
My script continuously uses the EKF’s updated position estimate and re-aims toward home every ~100 ms. The only issue is that with longer timeouts, the EKF estimate initially improves but later starts drifting again.
If you could suggest any better approach or any EKF metric that would help determine when it’s best to stop and land, it would be highly appreciated. Thanks!
Again, this is exactly the opposite of dead reckoning and defeats the entire purpose of using the script. You might as well not even use it if you intend to continue to rely on the EKF position.
I tested both the original ArduPilot dead-reckoning script and a slightly modified version, but I’m seeing the same issue in both.
When GPS is lost, the drone does not yaw toward the home direction. Instead, it keeps flying in a fixed direction rather than pointing toward home. I’m also using the correct drag model for my drone (EK3_DRAG_BCOEF_X/Y and EK3_DRAG_MCOEF are configured correctly).
I’ve also followed the recommended setup steps, including setting SCR_HEAP_SIZE, FS_DR_ENABLE = 0, and FS_EKF_ACTION = 0.
beacuse otherwise ekf failsafe get priority over lua
Has anyone encountered this issue or have any suggestions on what might be causing it?
What you are trying to do is fundamental wrong. Dead reckoning failsafe performs GPS denied zone escape maneuver, it cannot navigate as with regular IMUs unaided EKF loses position estimate very quickly.
You either have good position estimate (by virtue of having a ridiculously expensive IMU or having other source of position or at least velocity (less accurate)) and you can use position controller or you don’t and your copter will bugger off in a random direction when EKF diverges.
@LupusTheCanine Thanks for the explanation. I understand that dead reckoning cannot provide accurate long-term navigation like GPS because of IMU drift. However, my issue seems to occur immediately after GPS loss. The drone doesn’t even attempt to yaw toward the estimated home direction—it simply continues flying in a fixed direction.
I’m using the original ArduPilot dead-reckoning Lua script
wasn’t expecting perfect navigation back home, but I did expect the drone to at least turn toward the estimated home direction based on the last valid EKF estimate. Is this behavior expected, or does it indicate that something else is not working correctly?
That’s a good point. I was assuming it would yaw toward home, but I understand a multirotor can translate without changing its heading. My actual observation is that after GPS loss, the drone doesn’t appear to move toward the estimated home position at all. Instead, it continues flying in a fixed direction. I’m using the original ArduPilot dead-reckoning Lua script with the recommended parameters and drag model configured. Is this the expected behavior, or should it at least attempt to fly toward the last estimated home position
It will attempt to fly directly toward the last known home location via time/heading/distance. If you do not have a compass installed, it will not be able to discern heading.