Queue 0: cut integration suite from 241s to 22s, add the v1.0 work queue - #269
Conversation
The 14 open v1.0 issues are not independent: #254 and #255 both break the NavigationFilter trait, #253 would deny the very unwraps that #254 removes, and #262's InsEngine cannot exist until that trait is object-safe. Records the execution order as a spine of stacked branches carrying the breaking changes plus additive branches off main, along with the four issues that are deliberately split across two PRs and why. Mirrors the project board at https://github.com/users/jbrodovsky/projects/7 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
11 of the 13 running integration tests finish in 0.78 s combined. The other two are RBPF tests configured at num_particles: 5000, ten times RbpfConfig::default(), and they account for 434 of the suite's 241 s of wall clock (they overlap). The build profile was not the problem: [profile.test] inherits = "release" already propagates opt-level=3 to nalgebra, strapdown and the test harness alike, and a clean compile is only 12 s. Sweeping num_particles on test_data.csv at seed 42: particles full-GNSS median wall degraded median wall 250 23.86 m 12 s 11,457.70 m 10 s 500 23.67 m 23 s 6,955.45 m 21 s 1000 23.58 m 45 s 2,607.08 m 42 s 2000 23.60 m 90 s 5,195.30 m 83 s 5000 23.50 m 226 s 204.42 m 210 s test_rbpf_closed_loop_on_real_data is flat in particle count -- 0.4% between 250 and 5000 -- and clears its thresholds by roughly 9x either way, so it now runs at RbpfConfig::default() of 500. test_rbpf_with_degraded_gnss is a different story. Its error is not monotonic in N (2000 particles is worse than 1000) and it passes only at exactly 5000/seed 42, clearing median < 250 m at 204 m on a metric that swings 50x between neighbouring counts. That is the #266 pattern again: a knob cranked until the test went green. Lowering the count would hide it, so the count stays and the test is #[ignore]d with a pointer to #267, which tracks the underlying divergence. Run it with -- --ignored. Also corrects three assertion messages that named thresholds they did not enforce (e.g. "should be less than 150m" guarding < 2200.0). Refs #267, #268 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
There was a problem hiding this comment.
🟢 Approval recommended
The changes are limited to test configuration and documentation, and the updated assertions/ignore rationale are consistent with the stated acceptance criteria and verified thresholds.
Pull request overview
This PR improves the strapdown-core integration test suite runtime by reducing RBPF particle count for the stable/undegraded-GNSS scenario and quarantining a non-robust degraded-GNSS RBPF test, while also adding v1.0 queue documentation to coordinate upcoming milestone work.
Changes:
- Reduced RBPF integration-test particle count for the nominal GNSS case (5000 → 500) by parameterizing
run_rbpf_with_cfg. - Quarantined the degraded-GNSS RBPF integration test with
#[ignore]and clarified how to run it while investigating #267. - Added durable v1.0 work-queue documentation (queue topology and Queue 0 rationale/results).
File summaries
| File | Description |
|---|---|
| docs/V1_QUEUE.md | Adds a durable v1.0 “spine + parallel” work queue plan and merge/rebase workflow notes. |
| docs/queue/00-test-speed.md | Documents Queue 0 motivation, particle sweep results, and acceptance criteria for the test runtime reduction. |
| core/tests/integration_tests.rs | Speeds up integration tests by lowering nominal RBPF particles and ignoring the degraded-GNSS RBPF test; fixes assertion messages to match enforced thresholds. |
Review details
- Files reviewed: 3/3 changed files
- Comments generated: 0
- Review effort level: Lite
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
CI note:
|
| job | main @ 3259edb |
|---|---|
| ubuntu-latest, no-default-features | pass |
| macos-latest, no-default-features | fail |
| windows-latest, no-default-features | fail |
| Workspace (all features) | fail |
Three tests fail on macOS/Windows:
| test | message | owner |
|---|---|---|
test_eskf_stability_high_dynamics |
bounded with high dynamics, expected < 1905.00m, got 2121.97m | #266 |
test_filter_comparison |
ESKF RMS horizontal error should be reasonable | #266 |
test_rbpf_with_degraded_gnss |
should be less than 250m, got 2534.98m | #267 |
This PR fixes one of the three — test_rbpf_with_degraded_gnss is quarantined here with a
pointer to #267, so it stops failing on macOS and Windows. The two ESKF failures are queue position
1 (#270).
That cross-platform split is itself the argument for the change in this PR: same source, same seed,
same data, and the RBPF horizontal error moves from 204 m to 2,535 m purely on floating-point code
generation. A test that swings 12x across platforms and 50x across neighbouring particle counts is
asserting a coincidence, not a bound.
Follow-up: the unit-test failure here is also pre-existingThe earlier comment covered the three integration failures. This run also shows
A docs-only diff reproduces it, so it is runner scheduling, not the code under test. Tracked as #284 Against the honest baseline (#279, same CI conditions, no code change), this PR:
No test that was passing under equivalent conditions now fails. |
v1/00-test-speedmainWhy
cargo testtakes ~241 s. 11 of 13 integration tests finish in 0.78 s; the two RBPF tests take 224 s and 210 s because they run atnum_particles: 5000, 10x theRbpfConfig::default()of 500. The build profile is already fully optimised (opt-level=3for nalgebra,strapdownand the test harness alike), so this is a test-configuration problem, not a Cargo profile problem.Outcome
cargo test -p strapdown-core --test integration_tests: 241.15 s -> 22.37 s (10.8x).Measured particle sweep on
test_data.csv, seed 42, that drove the decision:The full-GNSS test is flat in particle count, so it drops to 500 with a ~9x threshold margin.
The degraded test is not monotonic and passes only at exactly 5000 -- filed as #267 and
#[ignore]d rather than tuned around. #268 covers the redundant per-particle covariancerecursion that makes both tests linear in N when they should be O(1).
Acceptance criteria
Branches off
main; independent of the spine.Queue:
docs/V1_QUEUE.md| Board: https://github.com/users/jbrodovsky/projects/7