On Gyroscope input ordering about fusion

[xioTechnologies]

You need to stop conflating Euler angles with gyroscope axes. The gyroscope axes are X, Y, and Z. The terms roll, pitch, and yaw cannot not be used to describe the gyroscope axes. You said in #16 that this is "a convention I've been using". You need to abandon this convention. It is incorrect and causing you confusion.

[David-OConnor]

Thanks for getting back to me! I think we're on the same page. Gyroscope input is currently a struct with X, Y, and Z fields. In the code base, there's no indication of which Euler angle matches to which struct field.

I think this could be solved with one or more of these approaches:

1. Adding to the FusionAhrsUpdate doc comment the order to pass gyroscope measurements. (https://github.com/xioTechnologies/Fusion/blob/main/Fusion/FusionAhrs.c#L92)

2. Modifying one of the examples to be more explicit. For example, replace this:

const FusionVector gyroscope = {0.0f, 0.0f, 0.0f}; // replace this with actual gyroscope data in degrees/s

with this:

// Replace `roll`, `pitch`, and `yaw` with actual gyroscope data in degrees/s.
const FusionVector gyroscope = {roll, pitch, yaw};

3. Accept a FusionEuler struct instead of FusionVector for gyroscope inputs to FusionAhrsUpdate.

[xioTechnologies]

You believe there is a problem because you have a fundamental misunderstanding of Euler angles. The solution is for you to correct this misunderstanding, not modify the library.

To repeat, "Pitch, roll, and yaw are Euler angles. These terms are not applicable to gyroscope measurements of angular velocity.", and "The terms roll, pitch, and yaw cannot not be used to describe the gyroscope axes.".

[David-OConnor]

I understand that.

The order matters in terms of fusing the accel and gyro measurements. The API and docs are ambiguous about which order you pass gyro measurements into the vector struct thats fields are named X, Y, and Z

Thought experiment: Let's say I store my gyro reading euler angles as variables pitch, roll, and yaw:

I run this to perform an attitude update:

        const FusionVector gyroscope = {yaw, pitch, roll};
      
        FusionAhrsUpdateNoMagnetometer(&ahrs, gyroscope, accelerometer, SAMPLE_PERIOD);

Should I expect accurate results?

What if I substitute this line:

const FusionVector gyroscope = {pitch, pitch, pitch};

This

const FusionVector gyroscope = {pitch, roll yaw};

Re your last line, in an attempt to clarify:
Pitch, roll, and yaw are Euler angles... The API uses the Vec {x, y, z} type, not the EulerAngle type for updating the algorithm, and gives no indication of in which order to pass the measurements. These must be consistent, or they will fuse incorrectly with the other terms.

[xioTechnologies]

Your diagram labels the gyroscope axes: X, Y, and Z. The gyroscope struct fields are: X, Y, and Z. There is no ambiguity.

I have said that Euler angles cannot be used to describe gyroscope measurements four times now, and you respond by using Euler angles to describe gyroscope measurements. I suggest that we end this discussion. You are welcome to open a new issue on a different topic if needed.

[David-OConnor]

If you compare the diagram I posted and what you enter in the algorithm, I think you'll find the first 2 terms (X and Y) are not consistent with the code and examples here.

Order of gyro measurements mapping The FusionVector type as used as a parameter to the update fns:

Per that diagram: X, Y, Z
Per how this algorithm is coded, as defined in the quaternion x vector operation: Y, X, Z. This is how it behaves upstream in the update functions.

I understand you are done with this discussion; I'm posting this for the benefit of others who might run into the same ambiguity.

[WelinLee]

Hi, the discussion makes more confusion. I would like to explain more simplified.
The measurement from gyroscope is regarding to the sensor frame, whilst Euler angles indicate the rotation from current sensor frame regarding to the reference frame. That's why x-io always emphasizes "Pitch, roll, and yaw are terms not applicable to gyroscope measurements of angular velocity".
In the Fusion algorithms, the reference frame is Earth frame by NWU convention.
If sensor frame setting by manufacture is not matched with NWU convention, see FusionAxesSwap functions in detail.

[David-OConnor]

Fixed by #9

This was caused by mixing JPL and Hamilton conventions, which is a classic quaternion trap.