5 ms·
As a flight pilot engineer you have to find a sweet spot and balance logging too much and too little. Writing logs to an SD card has huge costs that come with i
by dayjaby 3y ago
As a flight pilot engineer you have to find a sweet spot and balance logging too much and too little. Writing logs to an SD card has huge costs that come with it, that's why you don't want to log too much. Logging too little and you can't debug issues later on properly.
PX4 also has lots of "topics" logged at around 1/10, e.g. hover thrust estimate every 100ms:
https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/logger/logged_topics.cpp https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/l...
- LeifCarrotson 3y agoThis has a lot to do with the performance of your processor. Running on a single-board computer with an applications processor like a Raspberry Pi or BeagleBone, with multiple cores at 1 GHz+, gigabytes of DDR3, with on-chip SDXC drivers? Logging loads are irrelevant. The only thing to watch out for is that if you want to use the logs to figure out why you had a catastrophic crash, the OS may have write-buffered a lot of data in RAM. If you're running on a crossover MCU, like a Cortex M7, with a core or maybe two at a couple hundred MHz? Think about it what you log. Running on a Cortex M3 with a few dozen MHz and a few dozen kB of RAM? Yeah, appending to and rolling over a whole 512-byte page in RAM and finding the time to push it over the SPI peripheral is going to be tough, you may want to use a binary protocol so you're not burning unnecessary cycles in itoa() and you get more data per byte of buffer. The DJI drones discussed here have big Cortex-A53 SOCs that are already logging 4k video at 30 FPS to that SD card; the log file is only noticeable as a distraction from that task. I think the crossovers are the sweet spot, though, because a 'fast' clock or interrupt on that Linux board is slow in comparison to the more tightly integrated RTOSes.