Forgive me if I'm asking to cheat a bit and take some of the DIY out of DIY drones.
You need to be a member of diydrones to add comments!
Forgive me if I'm asking to cheat a bit and take some of the DIY out of DIY drones.
This reply was deleted.
Discussions
Forgive me if I'm asking to cheat a bit and take some of the DIY out of DIY drones.
Replies
I am using the 6dm unit with an Arduino UNO, just wondering if the code would be the same or much changes? Im hoping to just retreive the data from the unit once per second rather than continuously let the data flow since all I am doing is logging the data rather than using it for a drone situation. My SD card will get full rather quickly if I let it get every ounce of data from the 6dm.
Thanks
You are, of course, correct... an AHRS does not need to output lat/lon. My comment was for the purpose of demonstrating that there's no dead-reckoning of errors (to GPS) in these products, stand-alone. As a result, errors are inevitable over a cumulative period of time. Though, I must say, some of the products out there do an amazing job (for the money).
In particular, the 6dm represents state-of-the-art hardware and design as well as exceptional value. The fact that it uses a cortex-m3 micro (with plenty of left-over program space) means it won't be obsolete tomorrow. I'd love to port over William Premerlani's implementation onto it, as well as enable direct GPS support (via the available USART). I didn't look up the specs of your MEMS, but if they had built-in temperature sensors, I'd use those (each one) to compensate the individual MEMS. I might also add a "tilt" sensor (actually, a planar sensor) to detect L/R/U/D/N/I (normal/inverted) via some of the spare I/O pins you have. Yes, I'm aware that by seeing if one of the co-products is negative, I can detect an upside-down state without the need for another sensor. But there are some other neat things you can do with a planar sensor, to compensate for centripetal forces via interpolation (and imposition) of recent roll/pitch values.
1) When the aircraft makes longer turns, in which case the pitch and roll estimates will tend to zero, due to the lack of centripetal compensation.
2) Unpredictable magnetic field distortions from outside sources (which, in all fairness, also applies to any magnetometer).
There's a third condition which causes the device to yield meaningless measurements, and that's when you reach a pitch angle of +/- 90 degrees. This is a firmware limitation resulting from the use of Euler angles as opposed to quaternions. Add to that the fact that, ideally, the EKF (extended Kalman filter) should be tuned so that convergence takes place reasonably fast and without oscillation, and you end up with the realization that this is an IMU, not an AHRS. Ever see an AHRS tell you that your pitch and roll is zero during an extended turn, or give you some invalid figure for your pitch angle when you reach +/- 90 degrees? I haven't.
The fact that the unit currently does not incorporate a GPS in its solution should be enough of a clue to let you realize that it's not an AHRS. If you were to turn it on and read its outputs, it certainly would not know your lat/lon. Some would argue that the same holds true for other IMU's out there... and though they would be right, they'd also be missing the point (and not addressing your actual question). I suggest you take a look at MatrixPilot, which overcomes some of the limitations stated.
ArduIMU will give you three axis of absolute angles (roll, pitch, yaw). However, there is a limitation. GPS is used for centripetal acceleration correction. This approach is valid if the IMU always is moving more or less in the direction of one of its axis (in this case the x axis). This works great in airplanes where the movement is always more or less in the direction of the fuselage and where the IMU is always in motion (at least when you care about attitude estimation). It does not work in helicopters which may be hovering and yawing without linear motion along a known axis.
ArduIMU is stand alone.
Your original question included "the main micro controller wouldn't have to continuously integrate the gyros and crunch through Kalman filters". You can do attitude estimation with just accelerometers, but they are super noisy. They are useful for averages, but not for instantaneous values. If you are using gyros you have to use some method of integrating and filtering. Kalman and DCM are two competing approaches. There are others as well. In any case you do have to have a processor continually "crunching the numbers".
It says it runs a DCM algorithm. Its that a direction cosine matrix code to fuse the accelerometer-gyro data? Do you need the audrino autopilot board to go along with this, or can you use it as a stand alone IMU?