kharwarm

Umm.. I'm sorry but i'd ask you to go check the table again. lol

the wins aren't that marginal with numbers: 2.3x, 2.0x, 12.9x, 3.2x, 2.7x on the five sequences.

the loss on one specific sequence is genuinely bad though: 28.6m vs 9.6m, so 3x worse. That's because that sequence has extended degraded GPS over a long stretch and FusionCore's adaptive noise estimator seems to overcorrect in that condition. I haven't figured out exactly why yet and I said so in the benchmark notes.

on the spike: which one are you referring to? if it's 2012-01-08 there's a GPS jump early in the run that FusionCore's outlier gate catches and RL doesn't, which produces a visible discontinuity in the RL trajectory but not FusionCore's. happy to be corrected if you're seeing something different in the plots.

Fair, and I appreciate you saying that. I'll rewrite the intro section.... you're right that I can describe it better myself. The technical docs I'll keep as-is (parameter tables, migration steps), but the "what it is and why I built it" part should be mine.

It keeps predicting. During a GPS outage, FusionCore just dead-reckons off the IMU and wheel encoders, so the output stream stays continuous.

Covariance inflates over time as uncertainty builds... there’s no output gating. The Mahalanobis gate is only used on incoming measurements, so it’ll reject bad GPS fixes (like multipath spikes), but it doesn’t suppress the state estimate itself.

If the robot is stationary during an outage, ZUPT kicks in and drift stays close to zero. If it’s moving without GPS, then drift is entirely a function of IMU and encoder quality.... which, for something like a helmet, is probably going to degrade pretty quickly after ~30 seconds.

Your architecture is interesting to me. Letting speed go stale as an intentional safety signal (with the MCU handling crash logic below ROS) makes sense when “wrong but confident” is worse than no signal at all. FusionCore takes the opposite stance: never stop publishing, and let covariance communicate uncertainty to downstream consumers. For a cycling helmet... where false confidence could be dangerous... your approach is probably the safer call. For a robot that needs to keep navigating through something like a tunnel, FusionCore’s approach makes more sense.

Out of curiosity... what does your system do if GPS is lost for more than ~10 seconds while the device is moving? Does the MCU fall back to accelerometer-only crash detection, or does it just wait for GPS to come back?

Appreciate it. If you get a chance to take a look, the benchmark methodology and the RL comparison configs are all in the benchmarks/ folder, so you should be able to reproduce the results pretty easily.

I’ve already had six testers validate things across a range of environments—agricultural fields, open spaces, tunnels, underpasses, and even urban canyons with brief GPS dropouts. In those kinds of scenarios, FusionCore’s gating really stands out as a strength.

Fair point about the README... yeah, I did use Claude to help with the docs. But just to be clear, I’m not using OpenClaw or any other automated tools. FusionCore is a legit package: it’s available via apt, and the code’s up on GitHub. The filter and benchmarking work are my own. If you want to dig into the implementation, the core math is in ukf.cpp and fusioncore.cpp.

As for WOLF... it’s actually a really interesting framework, so credit where it’s due. That said, it’s built around a different philosophy. It’s a general-purpose factor graph system, while FusionCore is more opinionated and tuned specifically for GPS/IMU/wheel-based outdoor robotics.

If you’ve got a dataset you’d like me to run FusionCore on, send it over... I’m happy to share results. That might be a more useful way to compare them.

Fair haha... if you ever want the filter without the middleware, fusioncore_core is pure C++17 with zero ROS dependency. The ROS wrapper is thin on purpose. And if you're ever dealing with sensor fusion headaches on a project, feel free to reach out... happy to help regardless of stack. :)

robot_localization was the standard sensor fusion package for ROS. It was officially deprecated in September 2023. The designated replacement (fuse) still has no working GPS support two years later. FusionCore fills that gap: IMU, wheel encoders, and GPS fused via UKF at 100Hz on ROS 2 Jazzy. Automatic IMU bias estimation, Mahalanobis outlier rejection, adaptive noise covariance, TF validation at startup. Apache 2.0. Currently: 42 unit tests passing, Gazebo simulation working, 4 hardware testers running it this weekend including a farm robotics company doing RTK GPS fusion between corn rows with 3 inches of clearance, and a community contributor already submitted a PR adding PROJ-based coordinate system support. Happy to answer any technical questions.