These two show the motion tracking results, and the motion processing loop intervals.
Each spike in the dt (time interval) graph happens at about 10Hz (the frame rate for the video) and shows the camera data processing; this is only triggered when there is camera motion data available, not simply based on a 10Hz timer. As you can see this is there from the start. The horizontal units here are the number of motion processing loops i.e. the spikes start right from the word go, not after 4 seconds as suggested by the top graph.
The silence in the top graph’s first 4 second thus suggests the camera motion-blocks simply are not detecting motion at this point.. The flight plan is a 2 seconds take-off, 12 second hover and 2 second descent, but I’ve had to abort it after 5 seconds due to instability: Zoe is flapping both around pitch (blue) and roll (orange). The instability grows during the flight, so the 4 second point is likely to be where the low resolution camera macro-blocks actually start to see the instability.
Currently, the camera motion processing is still not fed into the PIDs, so the flapping is not caused by the camera motion. Certainly, the next step is to include this in the PIDs and see if this actually works.
Finally, there’s one fly in the ointment: the IMU FIFO overflow triggers every other flight; this is almost certainly not due directly to the camera itself, but to how I’m managing the FIFO and it’s overflow interrupt; first couple of attempts to control this have failed, so I’ll have to keep stabbing in the dark.