fix(tracker): exclude Lost tracks from bridge output (#420, ADR-082) (#426)

`tracker_bridge::tracker_to_person_detections` documented itself as filtering
to `is_alive()` but never actually filtered — it forwarded every non-Terminated
track to the WebSocket stream. With 3 ESP32-S3 nodes × ~10 Hz CSI, transient
detections that fell outside the Mahalanobis gate created a steady stream of
new Tentative tracks that aged through Active and into Lost. Lost tracks are
kept in the tracker for `reid_window` (~3 s) so re-identification can match
them when a similar detection reappears, but they are NOT currently observed
and must not render as live skeletons. Up to ~90 ghost skeletons could
accumulate at any moment, hence the 22-24 phantoms users saw while
`estimated_persons` correctly reported 1.

Add `PoseTracker::confirmed_tracks()` that returns only `Tentative ∪ Active`
and rewire the bridge to use it. `Lost` tracks remain in the tracker for
re-ID; they just no longer ship to the UI. `active_tracks()` is left
unchanged for the AETHER re-ID consumers (ADR-024).

Regression test `test_lost_tracks_excluded_from_bridge_output` drives a
track to Active, lapses for `loss_misses + 1` ticks to push it to Lost,
and asserts `tracker_update` returns an empty Vec while the Lost track
is still present in `all_tracks()` (re-ID still works).

Validated:
- cargo test --workspace --no-default-features → 1,539 passed, 0 failed
- ESP32-S3 on COM7 still streaming live CSI (cb #32800)
This commit is contained in:
rUv
2026-04-25 20:03:03 -04:00
committed by GitHub
parent 58a63d6bdf
commit 7f201bdf6f
5 changed files with 289 additions and 4 deletions
+11
View File
@@ -8,6 +8,17 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
## [Unreleased]
### Fixed
- **Ghost skeletons in live UI with multi-node ESP32 setups** (#420, ADR-082) —
`tracker_bridge::tracker_to_person_detections` documented itself as filtering
to `is_alive()` tracks but in fact passed every non-Terminated track to the
WebSocket stream. `Lost` tracks — kept inside `reid_window` for
re-identification but not currently observed — were rendering as phantom
skeletons, accumulating to 22-24 with 3 nodes × 10 Hz CSI while
`estimated_persons` correctly reported 1. Added
`PoseTracker::confirmed_tracks()` (Tentative + Active only) and rewired the
bridge to use it. Lost tracks remain in the tracker for re-ID; they just
no longer ship to the UI. Regression test:
`test_lost_tracks_excluded_from_bridge_output`.
- **Rust workspace build with `--no-default-features` on Windows** (#366, #415) —
`wifi-densepose-mat`, `wifi-densepose-sensing-server`, and `wifi-densepose-train`
all depended on `wifi-densepose-signal` with default features enabled, which