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.
I don't like saying "oh this is AI generated" because of exactly this scenario, where maybe there is care behind it and you just used AI to help you write. The problem is that as a reader I have no way to tell, and aillI have a lot of experience reading AI generated writing where it's subtly incorrect or misleading.
I would really suggest you rewrite the README, to remove the cliches and make it clear how much effort you put in. You clearly are able to communicate well about this project on your own.
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.
Why would it matter that it’s AI generated? Are you allergic?
It has almost 200 commits since mid March. It’s AI generated. Determining that took me 2 minutes. The high order bit here is actually whether it is of high quality.
If it is high quality (I didn’t check) and it’s honest about its provenance, the way it was made is immaterial.
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.
Built a ROS 2 cycling helmet. IMU + GPS, but we didn't fuse them, on purpose.
Speed is just haversine between GPS fixes. IMU only does turn detection and crash/fall. No EKF. Under bridges or urban canyons I'd rather have speed go stale and drop to zero after a few seconds than have a filter keep extrapolating from IMU bias and tell the rider they're still doing 20 km/h.
Other thing: safety stays below ROS. Crash/fall runs on the MCU next to the IMU; ROS just subscribes to /safety/event. Pi reboots, helmet still alarms.
How does FusionCore handle long GPS outages: gate the output, or keep predicting?
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?
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. :)
I looked into open source sensor fusion libraries for open mower, it seemed like the WOLF framework was very promising as a pluggable sensor fusion system. http://mobile_robotics.pages.iri.upc-csic.es/wolf_projects/w.... I only used it briefly though.
I hate to say this, but this submissions readme seems obviously AI generated.
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.
I don't like saying "oh this is AI generated" because of exactly this scenario, where maybe there is care behind it and you just used AI to help you write. The problem is that as a reader I have no way to tell, and aillI have a lot of experience reading AI generated writing where it's subtly incorrect or misleading.
I would really suggest you rewrite the README, to remove the cliches and make it clear how much effort you put in. You clearly are able to communicate well about this project on your own.
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.
Why would it matter that it’s AI generated? Are you allergic?
It has almost 200 commits since mid March. It’s AI generated. Determining that took me 2 minutes. The high order bit here is actually whether it is of high quality.
If it is high quality (I didn’t check) and it’s honest about its provenance, the way it was made is immaterial.
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.
Built a ROS 2 cycling helmet. IMU + GPS, but we didn't fuse them, on purpose.
Speed is just haversine between GPS fixes. IMU only does turn detection and crash/fall. No EKF. Under bridges or urban canyons I'd rather have speed go stale and drop to zero after a few seconds than have a filter keep extrapolating from IMU bias and tell the rider they're still doing 20 km/h.
Other thing: safety stays below ROS. Crash/fall runs on the MCU next to the IMU; ROS just subscribes to /safety/event. Pi reboots, helmet still alarms.
How does FusionCore handle long GPS outages: gate the output, or keep predicting?
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?
[dead]
It looks interesting, but I hate ROS so most likely won’t try it.
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. :)
[dead]