Hello! I am working on a TVC model rocket, specifically the part where I am getting the sensor's orientation. I plan on using the Madgwick AHRS algorithm, and for that, I need to discover my MPU6050's sample frequency (or my Nano's).
I'm not entirely sure what that even is, so it would be awesome if someone could explain what it is to me, and how I would find it? Also, does anyone know what units Madgwick AHRS algo expects it in?
Thanks!
The basic data sampling frequency is set by issuing commands to the MPU6050. See the data sheet for the details. It must be faster than the sample loop time.
The actual sample loop time is what is needed for any AHRS calculation, and depends on the MCU, MCU clock frequency, time to read out the sensor and apply corrections, etc. Use the micros() function to determine the time taken by the sample loop.
@jremington Thanks for the reply. Here is how I calculate the time between each loop, dt. Is this what I can use for the value? Although, it is a very very small number obviously.
#include <Arduino.h>
unsigned long prevTime = 0; // For calculating dt
double dt; // Time difference between loops
void setup() {
prevTime = micros(); // Initial Start Time
}
void loop() {
unsigned long currentTime = micros();
dt = (double)(currentTime - prevTime) / 1000000.0; // Convert microseconds to seconds
prevTime = currentTime; // Update prevTime for the next iteration
}
What would the updated code look like? Should I remove the / 1000000.0? And then can I use the dt value as the sampling rate? But I may need dt to be in seconds at certain points like computing PID values.
@Delta_G
AHRS algorithms require the loop time in seconds, in order to correctly integrate the gyro readings in radians/second.
How about the sampling frequency? And also, I see from looking at the MPU6050 datasheet, it outputs degrees per second by default, even when using the Adafruit_MPU6050 library, like I am. This is correct, right? I want to make sure I have all the right units being passed in.
@jremington
Most, if not all AHRS algorithms require the gyro data to be measured in radians per second. Some implementations may make that conversion internally.
It is up to you to make sure that you meet all the requirements of whatever algorithm and implementation you use. Make sure to test your final implementation very carefully to determine if the resulting orientations are accurate.
If you are serious about this project, keep in mind that the MPU-6050 is obsolete and was discontinued many years ago, so what you have is some sort of clone. Modern IMUs perform much better.
@jremington I have been working with the MPU6050 for a year now, never even noticed, and I am getting close to flight. What IMU do you recommend? Also, I have still been looking at the datasheet, and can't figure out the sampling frequency of it, or how the AHRS expects it. Any advice?
The manufacturer called it the Output Data Rate (ODR) and was programmable: 4 - 8000 Hz for the gyro, 4-1000 Hz for acc.
However, with a clone or imitation, you have absolutely no guarantee that the device will behave according to the original MPU-6050 data sheet.
I recommend the ISM330DHCX.
@jremington How does this look? Also, if I purchased this, I see that it outputs degrees per second, and has 12.5 Hz to 6.7 KHz sampling rate. The library also lets you set the sampling rate through the library, which looks amazing to me. Does this sound good?
Also, I was hoping you could help me understand the AHRS algorithm a bit more by confirming if I am correct or not:
Expects the sampling rate in HZ
Expects gyro readings in Radians Per Second
The Adafruit sensor outputs sensor readings in Degrees Per Second (atleast for the gyro).
AHRS is a generic term, and there are at least a dozen different AHRS algorithms and implementations in wide use.
The Mahony and Madgwick algorithms are simple and fast, and the Arduino implementations generally expect loop time in seconds and gyro data in radians/sec.
How does this look?
That is an example breakout for the sensor I recommended, and Adafruit is a highly reputable seller.
@jremington Yes, I am talking about the Madgwick algorithm, sorry for the confusion. Is there any more information you can give about it on a high-level in terms of how it works? Not in the math details, but in the overall concepts. I know a bit, but can't seem to find out information about the Madgwick filter besides his cryptic paper.
Thanks!
There are many summaries on line of various AHRS algorithms.
This one is probably the most complete.
Madgwick section.
@jremington I have seen this before, and will look more closely, thanks.
Last thing, I have heard that I should set the accelerometer measurements inputted to the Madgwick AHRS filter to zero while in flight, as the accelerometer is affected by the thrust. If I use the updateIMU() method, that expects the gyro and accel readings, is it OK to set the accel to 0 in terms of still getting an accurate estimation of orientation?
Correct. The accuracy of the gyro-only orientation estimates depends on how well you correct for gyro drift, amount of gyro noise, and the accuracy of the angular rate integration.
@jremington And how would one go about accounting for these things? I know of things like complementary filters, but these also need accelerometer readings I have heard. Do you know of anything used to account for these?
Sorry, I don't understand the question. Preliminary ground tests that you conduct on the filter will quickly reveal whether it is working at all, the accuracy of the orientation estimates, and the rate of gyro drift.
@jremington Sorry for the confusion.
I am asking if there was anything I can implement in code to account for gyro drift, without using the accelerometer. I was under the impression that the Madgwick AHRS algorithm would do that for me. Is there anything I can implement in code to account for gyro drift?
Also, how would I be able to check if the orientation estimates are accurate? Would I just use my eyes to test it and see if it looks right? Thanks.
For gyro-only integration and orientation estimates, the best you can do is subtract the previously measured static offsets, and optionally, measure and take into account the temperature dependent drifts in those offsets.
@jremington Got it. That is what I do with my current algorithm as well. I read in 1000 gyro measurements, sum them up, divide them by 1000, then subtract them from all the next readings. That sounds fine, right?
Also, do you know of anything that can reliably test if orientation readings are correct?