Fix wrong axis alignment #370
Conversation
|
I can confirm this is a problem, passing the inverted value of |
|
Glad this works for you.
Which direction of the board (or Ax typically) points toward true north is
up to the user and is arbitrary. Once this is chosen, the sensor data needs
to be fed into the fusion algorithms conforming to either NED or ENU RHS
convention. So this will depend on the sensor suite. But yes, for the
MPU9250, if DOWN is Az then DOWN has to be -Mz.
…On Sun, May 12, 2019 at 3:53 AM Robert Oostenveld ***@***.***> wrote:
I can confirm this is a problem, passing the inverted value of mz solves
it.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#370 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABTDLKS3STQXKTILVCTX47DPU7ZJ7ANCNFSM4HMI2VEQ>
.
|
|
hmm, I am currently not totally sure about my prior conformation. I noticed that - after making the change - the AHRS worked fine (from the top of my head it was NWU, which is a right-handed system just like NED and ENU), but that convergence was very slow. I now wonder whether that might be due to a remaining axis misalignment. The MPU9250 is according to figure 4 and 5 in http://www.invensense.com/wp-content/uploads/2015/02/PS-MPU-9250A-01-v1.1.pdf
which for the break-out-board version from e.g. Ebay means
So keeping (x,y,z) for accelerometer and gyro as they are, and for the magnetometer taking (y,x,-z) seems correct. It also maintains the magnetometer axes in a right-handed coordinate system, whereas the original code changes from a right-handed to a left-handed coordinate system. I will check it further and report back. |
|
Hi @robertoostenveld ! The slow convergence is because Kp, Beta is not suitable for your sensor, I had to hand-changing them to find the best fit. After all that, I've got fast response, correct value. Hope this help! |
|
@robertoostenveld Thinking about slow convergence, try setting gyro scale to highest (2000 deg/sec), because when you set it low (eg: 250deg/sec), it cannot measure fast rotation. |
|
Of course, this is all nonsense. The slow convergence is due to one of two
things. Either your MCU isn't running fast enough to maintain 5 - 10 x
fusion rate versus gyro sample rate or you are not feeding the sensor data
into the fusion filter properly (i.e., NED or ENU). Convergence has nothing
to do with beta. Or the gyro rate, unless you are using this on an
automobile wheel or something...
…On Mon, May 13, 2019 at 11:30 AM maisonsmd ***@***.***> wrote:
@robertoostenveld <https://github.com/robertoostenveld> Thinking about
slow convergence, try setting gyro scale to highest (2000 deg/sec), because
when you set it low (eg: 250deg/sec), it cannot measure fast rotation.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#370?email_source=notifications&email_token=ABTDLKQD4YD4OYEFKXHCYDDPVGXTTA5CNFSM4HMI2VE2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODVJFLXA#issuecomment-491935196>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABTDLKWHOIUUT6OYFGFTT4DPVGXTTANCNFSM4HMI2VEQ>
.
|
|
@kriswiner Update: I had to multiply gyro because I didn't calculate the resolution properly. Now I checked and it doesn't need to multiply anymore. |
|
I have tested some variants of the sketch more. If I change in my code the line that corresponds to this into then the yaw, roll and pitch behave as I would expect them. Also they converge smoothly. The problematic convergence that I reported at the start of this comment was not a problem any more when I reverted to the default |
|
This is not arbitrary nor subject to trial and error. The sensor data need
to be sent to the fusion function in NED or ENU (consistent right-handed
coordinate system) order. The choice of which axis is to be North is
arbitrary. But once the user makes this choice, the sensor axes determine
which axes point North, East, and Down.
So having Az and Mz as third inputs to the accel and mag sensor data,
respectively, cannot possibly be right for the MPU9250 since these are
oriented opposite to each other in the sensors. You need to check whether
the other sensor data are fed in properly.
…On Tue, May 14, 2019 at 1:02 PM Robert Oostenveld ***@***.***> wrote:
I have tested some variants of the sketch more.
If I change in my code the line that corresponds to this
<https://github.com/kriswiner/MPU9250/blob/72038b040bef3cf072612cd8a8ee8f26e3c87158/MPU9250BasicAHRS.ino#L433>
MahonyQuaternionUpdate(ax, ay, az, gx*PI/180.0f, gy*PI/180.0f, gz*PI/180.0f, my, mx, mz);
into
MahonyQuaternionUpdate(ax, ay, az, gx*PI/180.0f, gy*PI/180.0f, gz*PI/180.0f, my, mx, -mz);
then the yaw, roll and pitch behave as I would expect them. Also they
converge smoothly. The problematic convergence that I reported at the start
of this comment
<#370 (comment)>
was not a problem any more when I reverted to the default GScale, Ascale
and Mmode values. So in summary, in my previous experimenting, I changed
the scales and the minus-mz in one go, solving one, but introducing an
unrelated issue. The suggested -mz still seems a good idea to me.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#370?email_source=notifications&email_token=ABTDLKUZIJONTPJLHNFALOTPVMLGHA5CNFSM4HMI2VE2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODVMT7AQ#issuecomment-492388226>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABTDLKS473ZXHLLYEAWJMD3PVMLGHANCNFSM4HMI2VEQ>
.
|
|
with testing sketches I mean checking with some additional serial console output that the orientations and signs of values for each of the nine axes is consistent with those specified in the invensense data sheet, prior to feeding them into the sensor fusion algorithm. I confirmed that they are consistent. And it is indeed as you describe, the magnetometer values should be represented in a right-hand coordinate system which is consistent with that of the accelerometer and gyroscope. The code in this line feeds the magnetometer values in the order (my, mx, mz) to the MahonyQuaternionUpdate function. Flipping mx and my in the input values, but keeping mz as it is, results in a left handed coordinate system. The proposed input arguments (my, mx, -mz) are in a right handed system and aligned with (ax, ay, az) and (gx, gy, gz). Do with it what you wish. |
|
If you've checked this for NED consistency then it should work well and not
display large latency nor odd cross axis effects as is often reported when
this RHS requirement is not met. As long as you have also calibrated the
sensors well you should be able to achieve absolute orientation accuracy of
<4 degrees rms in heading and 1 degree rms in pitch and roll using these
relatively simple fusion methods.
…On Tue, May 14, 2019 at 1:49 PM Robert Oostenveld ***@***.***> wrote:
with *testing sketches* I mean checking with some additional serial
console output that the orientations and signs of values for each of the
nine axes is consistent with those specified in the invensense data sheet,
prior to feeding them into the sensor fusion algorithm. I confirmed that
they are consistent.
And it is indeed as you describe, the magnetometer values should be
represented in a right-hand coordinate system which is consistent with that
of the accelerometer and gyroscope.
The code in this line
<https://github.com/kriswiner/MPU9250/blob/72038b040bef3cf072612cd8a8ee8f26e3c87158/MPU9250BasicAHRS.ino#L433>
feeds the magnetometer values in the order (my, mx, mz) to the
MahonyQuaternionUpdate
<https://github.com/kriswiner/MPU9250/blob/72038b040bef3cf072612cd8a8ee8f26e3c87158/quaternionFilters.ino#L104>
function. Flipping mx and my in the input values, but keeping mz as it is,
results in a left handed coordinate system. The proposed input arguments
(my, mx, -mz) are in a right handed system and aligned with (ax, ay, az)
and (gx, gy, gz).
Do with it what you wish.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#370?email_source=notifications&email_token=ABTDLKTAUQAGGWK4BROKZ6LPVMQU7A5CNFSM4HMI2VE2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODVMX4CI#issuecomment-492404233>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABTDLKSX7TTSRMTPU5DNOSTPVMQU7ANCNFSM4HMI2VEQ>
.
|
|
Closing due to no update for the past 5 years. |
magnetic sensor has Z axis inverted