Well, I've been struggling with how best (most efficiently) to read the mag data and on this iteration (I guess I should have posted the entire sketch) I removed the data ready test from the mag data read function (I still check for overlfow) and I am relying only on the data ready read in the main loop. I am trying to minimize reads of mag registers while getting the proper data when ready. This would be so much easier with a proper AK8963C interrupt exposed.
I thought about having a counter and reading the mag data automatically every other MPU6500 data ready interrupt. But probably the best way and the way Invensense intended is to treat the AK8963C as a slave 0 device, have the MPU9250 ASIC read all of the data into the FIFO and then when the mag data is ready read all of the sensors in a single burst read. This is what their DMP does, but this is also why the DMP is limited to 100 Hz quaternion update rates. So there is no perfect solution (except a mag interrupt!).
The other thing I used to do and probably still should is burst read the accel and gyro (and temperature, tucked between them) data and parse the single array into accelerations and rotations. This would save a fair amount of time in I2C transactions for both MCUs and is the righter way to do it without the 100 Hz limitation on the data rate a la Invensense.
Thanks for the link, I'll give it a try.
I realized yesterday I am also doing something else not quite right. I am setting the internal sensor rate at 1 kHz, and then setting the DLPF to 41/42 Hz for the accel/gyro. This is all fine. But then I have used a sample rate divider (1 + sampledivider = 1 + 4) to bring the output sample rate to the host to 200 Hz for both accel and gyro, and I think this is wrong. The DLPF of 41/42 Hz requires 5.9 ms delay time for the ASIC to do the averaging. The maximum host read rate therefore should be 170 Hz, so a smaple divide of 1 + 5 would be more appropriate to read the data at 167 Hz. If I use a 91/92 Hz DLPF filter bandwidth instead this brings the delay time down to 3.9 ms which will support a sampledivide of 1 + 3 and a corresponding 250 Hz host sample read rate. The downside to the flexible configurability of the MPU9250 accel/gyro is the complication of it all.
Missed this.
Units of deltat are seconds.
Generally 4 -5x the sample data rate should be sufficient. It depends somewhat on the application. Best is to try it at 5x and 10x for your application. There is a point of diminishing returns, since the algorithm will eventually asymptote to a solution for a given set of data.
>> I tested 5 to 10 times the sampling rate - could not see a big difference. But I did not test with collecting data and analysis.
About every second read, it's not exact and syncing can be a problem. Usually I ignore rigorous timestamping in these simple sketches but the MPU9250 allows such if you treat the AK8963 as a SLV0 device, read its data using the internal I2C bus into the FIFO, and then read the time aligned data from the FIFO to the host. But if you do, the data rate is somehow clamped at 100 Hz, so there is a tradeoff. Generally I would recommend running the gyro and accel at 400 Hz, the mag at 100 Hz, and running the fusion rate at 2 kHz. This should be adequate for most human and flying robot applications.
>> I have some doubts whether syncing of incoming data is at the end that important. Just for fun I put acc gyro and mag values somewhat out of sync and the system at least did not flip over. No question - good syncing is nice to have.
The DPLF doesn't affect the sample rates or introduce time delays per se. The accel data is available to the internal ASIC at 1 kHz and the gyro data at 8 kHz. The DPLF simply determines how these data are averaged internally. They are still provided to the host at 200 Hz or 400 Hz or whatever is specified. But is a constraint, of course. There are certain combinations of data rate and LPF allowed and others not. Consult the data sheet.
>>The DPLF has a the delay of up to 66ms, the refresh rate stays al the time at 1khz. Something does not add up. Data out of DPLF might be "old". The AK8963 can deliver data at 100 hz - my conclusion was, that mag data might be fresher than filtered acc/gyro data. From here came my question. I read out all 9250 data interrupt driven at around 100hz at once.
It is unlikely (I won't say impossible) that the mag data is fresher than the accel/gyro data.Of course, if you set the accel/gyro sample rates at 10 Hz and the mag at 100 Hz this is exactly what you would get. The orientation solution is dominated by the gyro and the fusion filter rate needs to be sized according to the gyro rate. The accel and mag are helper functions to correct for gyro drift. So if you run the gyro at 1 kHz and the accel and mag at 100 Hz, you are likely to get a very reasonable orientation solution provided you run the Madgwick/Mahony fusion at 2 kHz or higher.
Best is to test out the parameters in your particular application. It might be surprising to some, but this is more art than science. While the basic principles are fairly well understood, the applications vary widely and there is no one-size-fits-all solutions that I am aware of.
I think you are right about being able to ignore this generally (I have so far). However, for flying robots respecting the DLPF delay limits is probably the wiser course.
I took a look at your repository and the functions are straightforward. One thing I don't like about having the MPU6500 manage the AK8963C is that the data is either limited to 100 Hz output rate (like the MPU6500 DMP) or mag data is read multiple times before refreshing. I'll stick to the polling I am doing now. It is simpler and seems to me to be no less efficient than making use of the SLV0 register. I would still prefer a dedicated mag sensor interrupt.
Is there also a Madwick for accel/gyro fusion only ?
I just take all the data out at 100hz and I am quite happy about it
I was simple saying that if I read all data at 200 Hz I am by definition reading 100 Hz mag data twice anyway. But this is a good idea, to run the mag in single shot mode and then I could run at 200 Hz. Haven't tried this yet.
We are running our flight control loop at 1 kHz (yes, 1 ms loop time!) and this provides a much more stable flight for very small UAVs.