How to get information about the update Frequencies between the flight controlling uC and the sensors/actors?
Hi there! I am having a hard time to find any documentation about how frequently px4 requests information from its sensors.
I also cloned the repository GitHub - PX4/PX4-Autopilot: PX4 Autopilot Software and tried to understand the firmware enough to ‘grep’ through the source to find the update rates. I always end up in a dead end after passing some macros leading to an _IOC instruction with a hard-coded memory address without any comment about what’s behind the address.
I can not believe, I am the only person who is interested in this very important part of PX4s system design, what information did I overlook?
Can anybody give me a hint that helps me to find the update rates? I am especially interested in:
GPS update rate?
IMU(s) update rate?
ESC signal update rate? (I have often read that it is configurable 50-400Hz and default is 400Hz)
Magnetometer update rate?
Barometer update rate?
Briefly, the flight control software stack is based on a publish-and-subscribe mechanism called uORB. Sensor drivers such as GPS and airspeed publish their measurement updates at whatever rate they can, and independent tasks such as “commander” and “Mavlink” subscribe to those updates, processing them periodically when these tasks run.
There are numerous sensors supported by the software stack. If you want an accurate answer to how often specific sensors publish updates, you could look at the source code for the relevant sensor drivers, such as the ublox gps driver.
Thank You so much!
So each update rate is defined by a bottleneck. This bottleneck can be the commander task if it is executed less often than new information is published via uORB. Or the bottleneck is the sensor itself (or its data link SPI, I2C…) when the commander task is called more often than new information is published.
It depends on who is the slowest: producer (sensor) or consumer (evaluating task)
Did I get it right?
Now I went into the src/drivers/ directory and I found some helpfull sensor sample rates
Hi @UtH_HAW
The sequence is correct, but it’s actually not a bottleneck. A producer typically publishes at a fixed frequency (eg. GPS with 5Hz, gyro ~240Hz), and each consumer waits for new data and runs at the same frequency as the input changes. It only becomes a bottleneck once a resource is exhausted (like CPU or SD card speed), then the subscriber misses some updates. We try to make sure the CPU load is not too high, so that under normal conditions no updates are missed.
