A little addition:
I've re-read all the Introduction to DCM doc (draft 2).
The scheme provided as figure 1 does not provide any details, which is what I'm seeking and the reason why I asked for another scheme.
The general approach is quite clear to me, but still I fail to understand how white-noise gaussian processes are removed (or at least an attempt is made to) from the sampled signals.
And there is no detail on how the actual merging of acceleration and rotation information is done.
The document itself is a very clear explanation of the geometry of different reference frames and related interconnections, but I miss a more technical analisys of the innards on the algorithm.
I hope not to sound too pretentious.
I'm using the DCM code as provided with the CK devices "mongoose" as the starting basis for an opens-source wifi AHRS for real aircraft. (That means some of the difficulties of UAVs don't occur: no continuous high-speed rotations for a Cessna 182, or else you've got other problems...)
Comparing the Mayhony algorithm with the Madgwick algorithm they're very similar except in the function for the error vector.
One uses a linear combination of the magnetic and gravitational cross products, and the other uses the first iteration of a steepest descent estimation, based on the Jacobian of an error function yada yada yada.
Is there any significant difference in the performance?
I also think there are two simplifications that can be made in the algorithm:
Don't compute the Z (third) row of the R matrix in Eqn. 17 - just set it to the cross product of the X and Y rows. That removes any requirement ever to renormalize the third row.
I don't know if you've looked into the maths but you either need to stabilize the magnetic information so you can use the whole magnetic vector (magnetic heading + angle of dip) as a reference vector during a turn, and/or differentiate the GPS velocity to give you a frame acceleration to correct the measured acceleration.
There's no reliable and easy way as far as I can see yet.
Send me a message on this site and we can compare notes.
Doug, et. al.
I've written up the project (so far) here:
In the implementation of MatrixPilot, we do take advantage of the fact that the third row of the R matrix is the cross product of the first two rows. Glad to see that you noticed that.
I’m confused with the effectiveness and accuracy of the proposed direction cosine matrix method.
Without doubt, if the UAV is not aclinic(level), the forward acceleration is measured by accelerometer, together with the gravity component. Unless the UAV is stationary, The horizontal attitude angle determined by the output of accelerometer is not believable. Of course, the azimuth angle obtained by GPS is also not believable. You known, the frequency of GPS signal is low, the azimuth will be vibrated, and the accuracy is too low to use.
I guess the core of this method is using the attitude reference to compute the gyro errors. So, I think it is better to equip a magnetometer.
The IMU computed attitude is limited by IMU errors(Gyro errors bias and Accelerometer bias errors). During motion, these errors can be estimated and compensated by EKF. I’d like to know the accuracy of the proposed method with attitude reference obtained by GPS and accelerometer. Of course, the accuracy equipped a magnetometer.
Since the first introduction of this idea, I have made many refinements to improve effectiveness and accuracy. There are links to the discussions on the UDB page. You might want to read a few of them, including the discussions on removing magnetometer offsets, self-aligning magnetometer, self-calibrating gyros, for example. And recently, I have made a major advance in the area of accounting for acceleration. At this point, the direction cosine matrix method is highly accurate and effective, if you incorporate the various improvements that I have published.
In the DCM, the accelerometers used for the pitch-roll compensator, and the GPS used for the roll compensator. Does anyone know why the GPS did not use for the pitch-roll compensator?
There have been several improvements to the basic algorithm since the original discussion. For more information, take a look at the blogs and discussions listed here.
The latest version of MatrixPilot uses the following approaches for gyro drift compensation, depending on whether or not a magnetometer is used.
A. No magnetometer. Accelerometers are used for roll-pitch compensation. GPS velocity is used for yaw compensation.
B. With magnetometer. Accelerometers are used for roll-pitch compensation. Magnetometer is used for yaw compensation.
In either case, in the latest version of MatrixPilot, change in GPS velocity is used to adjust the roll-pitch compensation to take into account acceleration. This is a new method that is particularly well suited for multicopters and VTOLS.
Typically, gravity is used as a reference vector for the "down" direction, that is why accelerometers are used for roll-pitch compensation. However, gravity does not tell you which way is north, so you need something else for for yaw compensation.
In fixed-wing aircraft, the air velocity vector is approximately parallel with the fuselage, so if you can somehow figure out the wind vector, you can use GPS velocity plus wind to determine the direction the plane is pointing and do yaw compensation.
For aircraft that hover, you need a magnetometer for yaw.
Regarding using the GPS for roll-pitch for fixed-wing, it cannot help you with roll, because the roll axis is approximately parallel with the air velocity. In principle you might use air velocity vector to help with pitch, but that requires that you know both the angle of attack and the vertical wind accurately. Typically, for pitch, you get better accuracy from accelerometer information.
I REALLY thank you very much. I hope to not disturb you much.