Is it possible to auto-recover when lighthouses are back in sight?

[sssecs]

Using one tracker and two lighthouses, I notice that when the tracker moves out of both lighthouses’ sight, the position data freezes, even after the tracker sees the lighthouse again. In this situation, I have to restart the program. Is there any approach to recover?

Thanks for your help in advance!

[rocketmark]

The root cause is that libsurvive's Kalman filter accumulates uncertainty during the blackout but doesn't reset when tracking resumes. Incoming hits get rejected because they're too far from the (now stale) predicted state.

A few things that help without recompiling:

Reduce how aggressively stale state is trusted:

--filter-threshold-ang-per-sec 30
--light-max-error 0.01

If you're running the global scene solver, limit it to 1 solve so a bad re-solve after the blackout doesn't corrupt your lighthouse positions:

--globalscenesolver 1

If you control the application loop, calling survive_simple_close() + reinit on loss-of-tracking is the nuclear option but guarantees a clean state.

The deeper fix is capping the Kalman process noise growth during long gaps (the uncertainty matrix scales as t⁷ under the jerk model, so a few hundred milliseconds of dropout causes the filter to reject valid observations on resume). There's an open patch for this in the rocketmark/libsurvive fork (survive_kalman_tracker_process_noise dt cap) if you want to apply it yourself. It prevents the NaN/rejection cascade without changing normal tracking behavior.

[fredinfinite23]

The deeper fix is capping the Kalman process noise growth during long gaps (the uncertainty matrix scales as t⁷ under the jerk model, so a few hundred milliseconds of dropout causes the filter to reject valid observations on resume). There's an open patch for this in the rocketmark/libsurvive fork (survive_kalman_tracker_process_noise dt cap) if you want to apply it yourself. It prevents the NaN/rejection cascade without changing normal tracking behavior.

Thanks @rocketmark , I too am aware of this, but I honestly didn't know that patch existed.
Any reason why we couldn't start the upstreaming process for it ? draft ? other caveats ?
@bl4ckb0ne FYI ^

[rocketmark]

I'm happy to submit the patch :) I've got a handful in my fork. I'll submit PRs for the ones that are broadly applicable and not just for my specific use case.

[rocketmark]

I also only just recently created the patch. I've been heads down trying to get my project up and running that I've not stopped to think about what patches I should submit back.

[rocketmark]

Pull request submitted: #352