I am trying to input a custom xgyro, ygyro and zgyro live value to the px4 algorithm. I have done research inside the PX4 Firmware github files but I can’t figure it out. I am trying to get to the root of where does the px4 uses the original values coming from the IMU, to tell the px4 to use a live value that I am calculating and willing to feed to the Pixhawk 4 from a RPi, for it to be used instead of the original IMU gyro values. Is there any option to do this as simple as possible? I am trying to build something in where I can switch in between original values and custom calculated gyro values, and be able to change with my RC, like a flight-mode or just a switch.
From a control and estimation point of view that sounds quite tricky because for good performance we try to read gyro data at a high rate and low latency.
Also, make sure to read about how multiple EKFs are used:
You will have to learn quite a bit about the inner workings of PX4 and find out which uorb topics are published and consumed. And you probably want to have one EKF running on the default/first IMU, and then a second one based on your gyro data.
Out of interest, can you explain more about what you’re trying to achieve, or what sort of gyro data you have?
@JulianOes Hi I’m trying to work on a similar problem - I want to PX4’s EKF2 use AI-corrected IMU data instead of the raw sensor stream.
My intended flow is: /mavros/imu/data → AI model (denoising/filtering) → UDP port 14560 → vehicle_imu_ai (uORB) → EKF2
Issue
From a structural point of view, publishing data through the vehicle_imu_ai topic is correct — the message format and timing fields match vehicle_imu.
However, once EKF2’s IMU source is switched to vehicle_imu_ai, two major problems occur.
EKF2 logs poll timeout 0, 22
After setting EKF2_IMU_SRC=1, EKF2 stops receiving IMU updates at the expected rate.
The AI IMU feed currently runs at about 35 Hz, which is much slower and less regular than the default IMU rate (~200 Hz).
PX4’s scheduler waits for IMU updates that don’t arrive on time, so it logs poll timeouts.
As a result, EKF2 stops updating because the AI data is too slow or inconsistent.
/mavros/imu/data drops to ~1 Hz after switching to AI
Immediately after switching EKF2 to use vehicle_imu_ai, the /mavros/imu/data topic slows to ~1 Hz ~ only heartbeat messages remain.
This likely happens because EKF2 unsubscribes from the raw vehicle_imu topic once it switches to the AI feed.
In SITL, if no one is subscribed, the simulator stops publishing IMU data.
Consequences:
MAVROS loses high-rate IMU data and pose updates stop.
The AI inference script stops receiving IMU input and therefore stops sending corrected data.
EKF2 then times out waiting for new vehicle_imu_ai samples, and the entire estimation pipeline halts.
Hi, I think you can follow the flow of raw sensor IMU from driver to module/sensor in firmware px4. An other way, you can modify the VehicleImu.cpp/.h file in px4 source code so this topic will not publish data from internal imus and publish your AI data instead
Hi, I tried a TCP-based approach where I broadcast the raw simulator data to my AI model, which then passes it back to my EKF2.
The key point for this task is that the AI model consumes IMU data from the simulator, since its a noise correcting model, so I cannot stop subscribing to it.
Sure, EKF2 at any given point can only subscribe to one uORB topic for IMU data, in this case its vehicle_imu coming from the Gazebo Simulator.
For SITL Testing, my goal was to use this simulator data, pass it to an AI model, get the corrected IMU readings and send them back to the EKF2.
But I still needed this original data source as that’s my input to the AI model. So in a way I can’t kill that while still not wanting to send that data to EKF2.
I tried sending my corrected data as a new uORB topic which the EKF can subscribe to, but as soon as we were making this switch, EKF de-registers from the original vehicle_imu data and the whole pipeline stops, cause now I’ve killed my original data source.
If you de-register from the vehicle_imu uORB, you’d notice that your MAVROS updates also stops (both /mavros/imu/data and mavros/local_position/pose etc)
My final conclusion after this ordeal was, EKF needed a constant subscription to an IMU data source which automatically polls and consumes the data.
Actually, data from topic vehicle_imu is not raw data. PX4 compenstate some offset and bias before publish data to vehicle_imu. So, I think you need to check imu from gazebo come to which topic (sensor_accel ?).
Yeah that’s correct, the EKF2 performs the bias corrections once it gets the data from vehicle_imu. We export out the data before this stage. Our goal is to pass the data coming from vehicle_imu before it reaches EKF2
If you use AI to correct bias instability and RRW from imu, I think you should do it with raw imu from sensor drivers. I think the 2nd block in your pipeline should move to before EKF (so you dont need to create new topic). The Sensor Drivers block connects directly to imu_sample_new.
I think when you put data through vehicle_imu, your raw data is preprocessed by turn on, thermal and scale factor compenstation, so your AI model will not show full strength on debiasing noise from IMU. And in vehicle_imu data still has the effect from vibration.
