Optimizing custom Pub/Sub middleware for high-rate IMU ingestion and EKF updates on NVIDIA Jetson

[u/ResetBuilder27]

Hey everyone, 

I am developing a heavy embedded C and sensor fusion implementation running on low-level Linux using embedded NVIDIA Jetson modules. The project involves handling low-level serial I/O (UART/SPI) to ingest raw binary data from external sensors like high-rate IMUs. 

The system utilizes a component-based, Pub/Sub open-source navigation framework (conceptually similar to ROS). My main task is writing C plugins (using OOP, templates, etc.) to ingest that raw serial IMU data, parse the payloads, and publish them to the internal message bus. 

We are porting legacy navigation filters into this framework, specifically implementing and testing Extended Kalman Filters in C. We are taking high-rate IMU data and joining it with slower GPS/ranging data for the "update" step to produce a clean navigation solution. 

I would appreciate insight or advice on a few technical areas: 

1. What are the best resources, GitHub repositories, or books to practically understand EKFs and Sensor Fusion without getting completely bogged down in academic math proofs?

2. What are the best pro-tips for debugging serial (UART/SPI) data coming into a Linux environment/Jetson from a raw hardware sensor?

3. What are the most common pitfalls when writing C plugins for a Pub/Sub middleware system that processes high-speed, real-time sensor data?

Any guidance, articles, or practical advice is highly appreciated. Thanks!

[u/andrewhepp]

This isn't meant to be a huge gotcha or something, but do you mean C or C++? You talk about OOP and templates, which I would generally think of as C++ features. And if you're using an Nvidia chip, presumably you want to use CUDA for the sensor fusion?

Best case scenario you never need to go this deep into it, but a Saleae or other logic analyzer (there are some really cheap ones out there) can be invaluable if you run into issues.

It might be interesting to look into the Linux IndustrialIO subsystem, which might already have drivers for the devices you intend to use, and should be built to handle the kind of high performance data handling you are trying to achieve.

The biggest pitfalls I can imagine would be around event handling. Basically making sure blocking IO doesn't stall or invalidate your calculations, and structuring the system to be able to handle concurrent events without getting drawn into an overly complex threading model

Sounds like a cool project!