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?
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.
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.
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. :)
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?
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.
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.
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]