The datasheet for the MPU6050 mentions a programmable interrupt that can be used for several things, including letting the user (in this case the Drone Pi python code) know there is data to be read from the sensors. I’d paid this no heed, and had seen occasional errors, and duff readings, but never too many to worry about. But now I’m at the last stages of fine tuning, and these hesitations, repetitions and deviations of sensor data have the dominant factor destabilizing the system.
So I had a quick nosey at the specs this morning, and it proved easy to rework my circuit to feed the MPU6050 interupt pin into a GPIO port of the Drone, and then change the code to spin, waiting for this GPIO pin to go high before reading the data registers. It worked a dream. Best results yet. OK so this is a simulation, but still it looks lovely!
You can see the hover is horizontal – that’s due to only using the vertical speed integration for takeoff – as soon as it’s hovering, then that spin speed is used leaving this very stable power out during simulated over, with only slight power decrease on descent.
Time for yet another hand-held live test, and if that works, then I think I’m ready for an untethered flight outdoors – still only take-off, hover, and land, but if it works, I’ll be over the moon given I’ve been working on this 6 months now!