Why ,the quaternion values from sensor fusion toolbox are switched ?

Hello everyone,

I am using the Sensor Fusion and Tracking Toolbox. I have raw data from accelerometer and gyroscope.. I imported them to matlab and logged them to imufilter in order to estimate the orientation. ( i want to compare the results of matlab with my own algorithm for gettting the orientation)

However, The quaternions estimated from the toolbox have an unexpected behavior.

the i (x-axis) values are switched with the w values (the real part). So for example , the initial quaternions are someting like 0.0023 + 0.99i -0.001k + 0.001j.

and going along the data set .. it seems they are so similar to my orientation output except that the values of i and w components are switched. I wanted to know why ? or what i am doing wrong. Thank you

Update: I have now transformed the quaternions to normal vectors using (compact) and I noticed the following when I compared the results from the toolbox and results from my alogrithm (assuming Q = [w,x,y,z]) :

1. The scalar w component is at i (x) and has an inversed sign
2. The x compnent is at w position with the same sign
3. The y component is at the z position with an inversed sign
4. The z component is at the y position with the same sign

[James Tursa]

See this link for a discussion of the MATLAB quaternion convention:

https://www.mathworks.com/matlabcentral/answers/465053-rotation-order-of-quatrotate

Answer 1

[Jim Riggs]

There are two different ways that are commonly used to represent quaternions.

Q = [a,b,c,d] with d being the scalar part, and a,b,c being the vector part.

or

Q = [a,b,c,d] where a is the scalar part and b,c,d represent the vector part.

Matlab currently uses the latter representation; a is the scalar, and b,c,d are the vector coponents. Make sure that your code is the same.

[Hesham Safyeldin]

@Jim, Thank you for the answer.

as I have stated in the question, the output is a quaternion vector that is defined in matlab

for example: 0.0023 + 0.99i -0.001k + 0.001j.

The whole weight here is on the "i" component relating to the x axis not to the scalar no matter which representation is used, or so I understand.

The results I have are from totally a different program. but stil no matter.

I plugged to the imu filter raw data from accelerometer and gyroscope , i expected quaternion values where the scalar component is almost 1 in the beginning and other values are too small. That does not happen, the i component is taking the 1.

Update: I have now transformed the quaternions to normal vectors using (compact) and I noticed the following when I compared the results from the toolbox and results from my alogrithm (assuming Q = [w,x,y,z]) :

1. The scalar w component is at i (x) and has an inversed sign
2. The x compnent is at w position with the same sign
3. The y component is at the z position with an inversed sign
4. The z component is at the y position with the same sign

any explanation for this weird behavior ?

[James Tursa]

I don't understand what you mean with a lot of your descriptions. Can you give us a small example of the IMU inputs used, the quaternions used, the code for your algorithms, and how you are comparing to MATLAB function output? In particular, since MATLAB does not model the i, j, and k quaternion imaginary numbers explicitly, it is important that you give us the algorithms/code for how you are creating and using the quaternions for comparison (e.g., as 4-tuple quaternions or 4-element vectors). Then I think we might be able to help you.

E.g., you seem to be implying that the scalar part is appearing as the 2nd element of the quaternion, which should never be the case regardless of the convention being used, but I can't be sure of this because I don't fully understand your descriptions. It also doesn't make sense that two elements have inversed signs ... I might have expected one or three elements due to convention mismatches, but not two.

[Hesham Safyeldin]

@james, thanks for answering

input data are attached with some figures of the problem. However ,it is now solved. It was a reference frame problem.

But maybe I can ask you something else if you may.

Why always the quaternion results coming out from the toolbox are not initalized to [1,0,0,0] .. they are pretty close but not equal.

Answer 2

[Hesham Safyeldin]

It turned out to be a 'Reference Frame' problem.

I think my sensor gives data in 'ENU' while the default in Matlab is NED. Honestly I do not understand too much the impact of the difference from these 2 reference frames. but when I changed the reference frame, problem seemed to be solved.

Answer 3

[Brian Fanous]

Hensham

There are a few issues that might be going on. First, if you are using the NED convention of the imufilter, then you have to make sure that your input sensor data is also using that convention (i.e. on a flat surface your accelerometer z-axis gives a positive value, clockwise rotations give positive values from the gyroscope, etc). There’s a demo to illustrate that here:

https://www.mathworks.com/help/fusion/examples/logged-sensor-data-alignment-for-orientation-estimation.html

The other thing to be aware of is what the quaternion output of imufilter means. The imufilter gives a quaternion q that will take a quantity in the parent (global) frame to the child (sensor) frame, when used with a frame rotation. That is

x_sensor = framerotate(q, x_global).

Ensure the library you are using is doing that as well.