The boring sensor fusion papers that will actually make your robot work

The second paper is more ambitious and, frankly, more interesting to me. FusionCore is an open-source ROS 2 package that fuses IMU, wheel encoders, GPS, and visual SLAM into a single 100 Hz odometry stream. That's not new. What's new is how they handle the failure modes.

The clever bit is their 23rd state (yes, they're tracking 23 different variables). It's an online estimate of the wheel encoder's systematic yaw rate bias. In plain English: wheel encoders slowly lie to you about how much you're turning, and this lie compounds over time. FusionCore figures out how much the wheels are lying by comparing to GPS heading, then uses that correction during GPS blackouts. The result is less heading drift when you lose satellite signal.

They also do proper outlier rejection (throwing out measurements that are obviously wrong rather than letting them corrupt your estimate), automatic noise covariance adaptation (the filter learns how much to trust each sensor), and native GPS handling in ECEF coordinates without needing a separate projection node. Call me old-fashioned, but I appreciate when someone actually thinks through the implementation details instead of just publishing a paper and leaving the engineering to "future work."

The benchmark results are brutal

Here's where it gets interesting. They compared FusionCore against robot_localization, which is basically the standard ROS package everyone uses for this stuff. Tested on twelve sequences from the NCLT dataset, each 55 to 92 minutes long.

FusionCore won on ten of twelve sequences. Improvements ranged from 1.2x to 22.2x better trajectory error on the winning sequences. But the really damning number: the robot_localization UKF diverged numerically on all twelve sequences. Diverged! Meaning it completely failed to produce usable output.

Now, I should note that robot_localization is a general-purpose tool and FusionCore is specifically tuned for this problem, so it's not entirely a fair comparison. But if you're building a product and your navigation stack diverges during an hour-long test run, you've got problems.

So what

Look, I know sensor fusion isn't sexy. Nobody's going to raise a $400 million Series B by promising better Kalman filtering. The kids running these humanoid companies want to talk about foundation models and end-to-end learning and emergent behaviors.

But here's what I've learned covering tech since the 90s: the unsexy infrastructure work is usually what separates products that ship from products that demo well. Every autonomous vehicle company that's actually deployed at scale (and there aren't many) has a team of people obsessing over exactly this kind of problem. How do you maintain localization when GPS drops? How do you detect and reject bad sensor data? How do you handle the wheel encoder drift that accumulates over an eight-hour shift?

The fact that FusionCore is open source under Apache 2.0 matters. The fact that it's built for ROS 2 matters. The fact that it handles visual SLAM fusion with automatic recovery from map reinitialization matters, because that's what enables GPS-denied operation in real environments.

Will either of these papers change the world? No. But they might help your robot know where it is when it drives under that bridge. And honestly, that's more valuable than another humanoid doing parkour in a warehouse.

If you want to argue with me about this, my email's on the about page.

Mark Kowalski · 2 hours ago · 5 min