I can feel a Eureka moment coming soon!
I can see at least two more problems to be fixed, but I can also see that unless my drone breaks the laws of physics, the number of problems really has to be nearing 0.
So the latest problem to be solved is how to avoid the junk / garbage data read from the MPU6050 sensors shown in the previous post. That’s an answer for another day, as I need to understand and fix it first. The problem is due to bad I2C interface reads, meaning the sensors appear to return values of -1, leading to the spikes you can see on the previous post.
Today’s fixed problem (I think) is how to ensure you only read data from the sensors when you can get your grubby mits on it safely?
- the MPU6050 has two sets of sensor registers – ones that it fills in, and ones that are read by software
- The software registers are updated periodically from the internal registers based upon a timer, and when that happens, the data ready interrupt gets triggered
- The sample rate for the readable register updates depends on both the DLPF (1kHz if enabled, 8kHz if not used), and the configured sample rate divisor allowing user configuration of how often the sensor samples are updated.
So to read a full set of sensors, they need to be read in less time than the next sample gets pushed to the register. This means I need to change my readSensorRaw code as follows
- read the interrupt status register to clear any outstanding interrupts
- spin waiting for a fresh interrupt
- start a timer
- read the sensors
- stop the timer
And finally reconfigure the sample rate divider (in code) so that the elapsed time measured above is less than the sampling period.
In the quick tests I did, the reading of the sensors took ~6ms, so with the DLPF on, the internal sample rate is 1kHz, so I’ve set the sample divider to 10 so that the external registers change every 10ms which should be more than enough time to read the sensors.