Back from DisneyLand where it was 35°C in the shade. It actually turned out to be fun, even cool at times, and gave me plenty of thinking time, the net result of which is I’ve changed the main scheduling loop which now
- polls the IMU FIFO to check how many batches of sensor data are queued up there; the motion processing runs every 10 batches
- if the IMU FIFO has less than 10 batches, select.select() is called, listening on the OS FIFO of the camera macro-block collection process; the timeout for the select.select() is based upon the IMU sampling rate, and the number of IMU FIFO batches required to reach 10.
- The select.select() wakes either because
- there are now >=10 batches of IMU FIFO data present, triggering motion processing
- there are macro-block data on the OS FIFO, which updates the lateral PID distance and velocity input.
Even without the camera in use, this improves the scheduling because now the motion processing happens every 10 batches of IMU data, and it doesn’t use time.sleep() whose timing resulted in significant variation in the number of IMU FIFO batches triggering motion processing.
I’m taking this integration carefully step by step because an error could lead to disastrous, hard to diagnose behaviour. Currently the camera FIFO results are not integrated with the motion processing, but instead are just logged. I hope during the next few days I can get this all integrated.
Note that due to some delivery problems, this is all being carried out on Zoe with her version 2 PiZero.
Update: Initial testing suggests a priority problem: motion processing is now taking nearly 10ms means the code doesn’t reach the select.select() call, but instead simply loops on motion processing. This means that when finally the OS FIFO of macro-blocks gets read, there are possibly several sets, and they are backed up and out-of-date. I’ll change the scheduling to prioritize reading OS FIFO and allow the IMU FIFO to accumulate more samples.