What robot or hardware are you running FusionCore on?

[manankharwar]

Trying to build a picture of what platforms people are actually using FusionCore on: helps prioritize hardware configs and know where to focus testing.

If you have it running (or are trying to get it running), drop a comment with:

• Robot platform (Husky, custom differential drive, mecanum, etc.)
• IMU model
• GPS receiver (u-blox, Emlid, Septentrio, etc.)
• ROS 2 distro
• Any gotchas you hit getting it set up

If your setup is not in the config folder yet and you get it working, a PR for the YAML is very welcome: it helps the next person with the same hardware skip the tuning entirely.

[samuk]

I'm having a go at using it in https://github.com/Agroecology-Lab/feldfreund_devkit_ros

No real hardware (yet) but hopefully will have a robot moving in a month or two. More: https://sowbot.co.uk/

[manankharwar]

Solid hardware stack. A few things worth keeping in mind before you start integrating everything:

First, with the BNO085, make sure you’re using raw mode instead of fusion/NDOF mode. The sensor can output either its own fused quaternion + “linear acceleration,” or the raw gyro/accelerometer data. FusionCore really wants the raw gyro and raw accel data, not the onboard fused output. A lot of ROS drivers default to NDOF because the data looks cleaner at first glance, but it can cause weird filter behavior later. Definitely double-check that the driver is publishing sensor_msgs/Imu with angular_velocity from the raw gyro and linear_acceleration from the raw accelerometer. That’s probably the most common BNO085 gotcha.

Also curious about the dual F9P setup: are you planning to run them as a moving baseline pair for heading, or just as two independent RTK receivers? If you do moving baseline (two antennas mounted on the frame, usually spaced ~0.5 m apart), FusionCore can fuse the GPS heading directly through compass_msgs/Heading. On tracked platforms that’s actually pretty valuable since skid-steer motion introduces lateral slip, so wheel-based heading tends to drift over longer runs.

Speaking of tracks, you’ll probably want to relax the lateral non-holonomic constraint a bit. FusionCore normally assumes near-zero lateral body-frame velocity, which works great for wheeled differential drive. But tracked robots do slide sideways during turns, so the filter can end up fighting real motion. Setting: encoder.nhc_vy_sigma: 5.0 usually helps a lot.

For the ODrive side, standard setup is just publishing wheel velocities as nav_msgs/Odometry and remapping to /odom/wheels.

Once the hardware shows up and you start wiring everything together, happy to help troubleshoot the integration side too...

[samuk]

The MCU firmware we're reusing does come with BN085.cpp and imu_bno085.h

It's not (yet) published as a ROS topic, just looking at it now to see if that's worth keeping, or write something from scratch. Ticket here

Intention is to use both RTK and get a heading out of them the main launch is devkit_launch.py

And I have this first-pass at a fusioncore.yaml

I'll work on getting the BNO085 publishing in ROS. I'm sure I have the RTK stuff misconfigured in some way, or at least sub optimally configured. If you were interested in installing and having a look at current bringup that would be amazing.

[manankharwar]

Yes, absolutely. Share the repo link and the fusioncore.yaml you have so far and I'll go through it. Happy to look at the BNO085 driver setup and the F9P config together.... the dual RTK heading setup especially has a few gotchas worth catching early.

[samuk]

Amazing thanks for having a look, if you have 9Gb of hardrive spare probably running the quickstart would be the way to go https://github.com/Agroecology-Lab/feldfreund_devkit_ros/tree/caatinga-dev#quick-start

Key files:

fusioncore.yaml
Is called in main launch: devkit_launch.py

Other key files are relposned_heading_shim.py and rtk_navsatfix_shim.py

It's all brought up by main manage.py script that keeps an .env storing what GNSS hardware is connected, so worth bringing it up using that.

I had a little hack at this with Claude between work meetings, it's probably made a worse mess than just doing nothing! This is what it said about it's efforts:

Quick update — had a proper read through the bring-up, the Lizard firmware, and the FusionCore source. Four things worth flagging. Patches applied locally; not yet on hardware (still sorting the chassis).

1. Heading covariance. Both heading shims set orientation_covariance[0] = -1 to mean "roll/pitch unknown, only yaw valid". gnss_heading_callback reads cov[0] < 0 as "invalid orientation" and returns before update_gnss_heading is called — so the dual-antenna heading never reaches the filter at all. Set [0] and [4] to a large positive value instead and it goes through.

2. /gnss/fix QoS mismatch. rtk_navsatfix_shim publishes BEST_EFFORT, FusionCore subscribes RELIABLE. DDS won't pair them, no error shown, position fixes silently dropped. Switched the publisher to RELIABLE.

3. Duplicate odom → base_link. Both odom_handler and FusionCore were broadcasting it, so the TF flickered between the wheel pose and the fused pose. Disabled the wheel-side broadcast (publish_tf: False in devkit.yaml).

4. dual_antenna parameter silently ignored in course_over_ground — passed by the launch but never declared by the node, so both heading shims would have raced on /gnss/heading in dual-F9P mode. Declared it properly and gated the CoG shim on it.

A few questions if you've a moment:

• validate_transforms() is called at line 498 (in on_activate) but its return value is discarded. The launch comments claim missing imu_link → base_link blocks activation; the code doesn't enforce that. Deliberate?
• Worth a note somewhere about the /gnss/heading covariance contract? It's a sharp edge — anyone using the standard sensor_msgs/Imu -1 sentinel will silently lose all heading updates.
• Any reason /gnss/fix is subscribed RELIABLE rather than SensorDataQoS? Means the publisher side has to match exactly.

Cheers.

[manankharwar]

Your patches are correct... read through the current caatinga-dev branch. The heading shim covariance fix is right (1e6 for roll/pitch, actual variance for yaw[8]), and the RELIABLE publisher QoS on rtk_navsatfix_shim is correct. Good catches.

Three quick answers to your questions:

validate_transforms(): yes, deliberate. It prints [OK]/[MISSING] warnings and gives the exact static_transform_publisher fix command, but doesn't block activation. The real TF lookup happens per-message in the IMU callback, so the filter still starts even if the transform is temporarily unavailable.

Heading covariance contract: you're right, it's a sharp edge. I'll add a note to the docs. The contract is: cov[0] must be >= 0 (not the -1 sentinel), and cov[8] carries the yaw variance. Your shim is the correct pattern. I'll also fix the callback to handle the yaw-only case more gracefully (reject only if both cov[0] < 0 AND cov[8] <= 0).

RELIABLE on /gnss/fix: default ROS 2 QoS, no deliberate choice. SensorDataQoS would be more correct for 10 Hz GPS but changing it breaks existing users. Will document it.

One thing in your fusioncore.yaml: gnss.mahalanobis_threshold: 5.0 is not a recognized parameter... it's silently ignored. The real parameter is outlier_threshold_gnss. Default is 16.27. For RTK FIXED with real covariance from the HP fix, something like outlier_threshold_gnss: 9.49 is tighter and more appropriate.

Once you have hardware, the tracked platform will need encoder.nhc_vy_sigma: 3.0 (or higher) to relax the lateral velocity constraint... tracks slide sideways during turns. Let me know when you're getting data and we can tune from there.

[Russ76]

Fusioncore helped my indoor tracked robot. It uses the Andino repo for motor control and has an Oak-D camera and Velodyne VLP16 lidar. It uses two Raspberry Pi Fives for computing. I used Rtabmap for mapping but I was having trouble getting the odometry right. Sometimes Slam Toolbox showed two places where it thought the robot was operating! The visual odometry in Rtabmap wasn't precise enough for good mapping. Manan worked with me to develop the proper yaml and launch files to straighten out the robot operation, integrate the IMU output and ICP_odom to help odometry become more stable. Now the robot is mapping well and driving autonomously! It uses Ros2 Jazzy on Ubuntu 24.04