My code has been running at about 450 loops per second, and it seemed that whatever I tried to speed it up was having little effect. The data from the MPU6050 was being updated 1000 times per seconds, so surely I could do better than 450?
Eventually, I started to suspect my customized GPIO python library was the cause – it waits for a hardware interrupt signalling fresh data is available – it calls epoll_wait() twice – could this explain why? Is it only catching every other interrupt and hence reducing the speed to a maximum of 500 loops per second? It seemed plausible so I changed the code, and sure enough, processing speed has gone up to 760 loops per second. The missing 240 loops are due to python motion processing, so now I can fine tune these and expect to get even better results.
Why does this matter? By nearly doubling the amount of data received in a fixed period, I can get better averaging over that period, which means I can increase dlpf to a higher frequency, and so reduce the risk of filtering out good data.
I’ve updated the code on GitHub – you’ll need to remove the current GPIO code first before unpacking the GPIO.tgz and running the install thus.
sudo apt-get remove python-rpi.gpio tar xvf GPIO.tgz cd GPIO sudo python setup.py install
Next step was to see what refinements I can make to the python code to speed the sensor data processing further. I moved the calibration and units checking from the main loop to the motion processing, and that upped the speed to 812 loops per seconds.
Now all I need to do is test it live!