From the same run as the last two posts, I’ve been analysing the stats.
First the integrated gyro showing the yaw it detected:
This shows the unintentional clockwise (negative) yaw of about -10° shortly after take-off followed by the intentional anticlockwise yaw of +90° as Hermione headed off left. I still need to have a play with the yaw rate PID to try to kill that initial -10° yaw.
More interesting, to me at least, is the motion processing:
The graph shows how often the FIFO was emptied. In an unhindered world, the FIFO is emptied every 10ms (0.01s) and the PWM to the ESCs update. Peaks above that means something else was taking up the spare time. The FIFO overflows at just above 84ms (512 bytes total FIFO size / 12 bytes per IMU sample / 500Hz IMU sampling rate = 85.333ms), and the highest shown here is 38ms, well within safety limits. I’m particularly delighted that the majority of the spikes are within the 10 to 20ms range – that strongly suggests the split phases of macro-block processing is working like a dream.
The 20ms norm means the PWM is updated at 50Hz. Were the PWM consistently updated at less than 50Hz, it would really start to show in the stability of the flight. But luckily it isn’t, meaning there’s probably just enough room to finally squeeze in compass and GPS processing.
In passing, it’s worth saying that such levels of stats would be impossible if I was using a microcontroller (Arduino etc) – this 11s flight logged 1.46MB of data to shared memory, and ultimately to SD card. It logs both initial hard coded constants, and every dynamic variable for every cycle of motion processing – that means nothing is missing and it’s possible to diagnose any problem as long as the reader knows the code intimately. Without these logs, it would have made it nigh on impossible for the ignorant me 4+ years ago to achieve what I have now.
* I rate myself as experienced having spent over 4 years on this.