manankharwar/fusioncore

tools/spike_injector.py takes a recorded bag and injects a GNSS spike into it, which is how the outlier gates get tested against something other than a hand-built unit test. It has no test, and more importantly it has no stated contract. The questions a user cannot answer from the script today: is the injected spike added to the existing fix, or does it replace it is the magnitude in metres on the ground, or in degrees of latitude and longitude does it alter the covariance that comes with the fix, or leave it claiming the original accuracy, which is what makes a spike adversarial rather than obvious are the surrounding fixes left untouched, so the injected one is detectable as a single outlier rather than a shifted segment That third one is the interesting case. A spike that honestly reports a huge covariance is easy for any filter to discount. A spike that keeps a small covariance is the one that defeats a chi-squared gate, and that distinction is the whole point of the tool. What a

Six of the eight update_* entry points on FusionCore take a timestamp, and none of the public documentation states what happens when that timestamp goes backwards. It matters because it has crashed before. From the changelog: the filter used to SIGABRT on a backward time jump, fixed by having predict_to re-sync the clock and the UKF floor eigenvalues rather than throw. On real NCLT data a run that used to die in two minutes now survives. That is good behaviour and nobody reading the header would know it exists, or that they can rely on it. The same gap covers a few neighbouring questions a user hits on day one: what happens if two sensors disagree about the clock, which is common with a separate IMU board, and what max_measurement_delay does about it whether measurements must arrive in timestamp order across different sensors, or only within one sensor what min_dt and max_dt actually gate, and what the filter does with a step outside them whether a repeated identical timestamp is a no

tools/rl_to_fusioncore.py converts a robot_localization config into a FusionCore one. For a lot of people it is the first FusionCore code they ever run, since the realistic path into this project is migrating off the thing they already have. It has no test. It is also not a trivial script. It refuses to guess, emits TODO markers for anything it will not infer, writes a summary to stderr so the refusals are visible even when stdout is redirected, and prints a header saying the output is not a finished config. That is careful design, and none of it is verified. What a fix looks like tools/test_rl_to_fusioncore.py with small robot_localization YAML inputs written inline: a minimal ekf_node config converts, and every key in the output is one the node actually declares. You can reuse the declared-parameter parsing in tools/check_config_params.py rather than hardcoding a list, which also means the test keeps working as parameters change a config using a feature FusionCore does not map produ

The benchmark table in the README is a May 2026 snapshot, and the only thing saying so is a sentence a reader has to notice: Read the caveat in the section above before quoting these. They are a May 2026 snapshot and have not been re-verified end to end on current main. One is known to have moved: 2013-04-05 has regressed from 12.1 m to about 19.4 m, still a 93% win. That caveat is honest and it is in the right place. The problem is that it is prose, so nothing enforces it, and the table beside it reads as current. It has already drifted once by an admitted factor of 1.6 on one sequence. Meanwhile tools/benchmark_baseline.json carries measured per-sequence numbers with the commit and date they were taken on, and benchmarks/nclt/golden_20260928/ carries a second set with full provenance. The data to keep the README honest exists. Nothing connects it to the README. What a fix looks like Something small, in roughly increasing order of usefulness: Put the measurement date and commit ins

ADOPTERS.md lists nine deployments with GitHub profile links, and nothing checks that any of them still resolve. It is the first file a prospective user reads to decide whether this is real, so a dead link there costs more than a dead link in a doc page. Same class of problem across the docs: mkdocs.yml builds the site in CI, but a 404 on an outbound link is not a build failure. What a fix looks like A link check in CI. There are two reasonable shapes and either is fine: lychee-action or an equivalent, run on **/*.md, with a short ignore list for the things that legitimately rate-limit or require auth. A small Python script in tools/, consistent with the five checkers already there, doing a HEAD request per link with a timeout and a cache. Prefer whichever you would rather maintain. If you write the Python one, follow the shape of tools/check_docs_params.py and give it a test. Two things worth getting right: Do not fail CI on a transient network error. A flaky external host failing