Clarification on CF coordinates and states

[xkhainguyen]

Hi,

I looked at the state estimator of the CF2.1 quadcopter and saw some confusing information. I also looked at this https://www.bitcraze.io/documentation/system/platform/cf2-coordinate-system/ but some are not consistent to me.

I assume that kalman_core.c uses standard coordinates (correct pitch) and only modify the final output to obey the legacy code (in CF coordinate with reverse pitch). Below are my insights, please correct me if I am wrong.

1. The final estimates of position, velocity, and acceleration are all in the world frame.
2. The final acceleration z is said to be without gravity; but with upward z, shouldn't it be plus 1 to remove gravity instead of minus 1?
3. The gyro angular rate is in the body frame and CF coordinate.
4. I see the quaternion estimate remains in the standard coordinate. So if my quaternion-based controller uses standard coordinates, the only thing I need to do is to negate sensors->gyro.y
5. If I use MoCap and default crazyswarm configurations, the CF will have a world-frame as the MoCap and receive position + quaternion measurements in standard coordinates (reason as in 4.)

A side thing in Brescianini controller that I found: this should use omega_yaw_max
And it seems like this controller is using the wrong pitch rate direction (omega[1]), considering its powerDistributionForceTorque as well.

Thank you very much!

[krichardsson]

Hi,
there is unfortunately a bit of a mix, we hope to clean it up at some point. Different parts of the system use different definitions.

The final estimates of position, velocity, and acceleration are all in the world frame.

yes

The final acceleration z is said to be without gravity; but with upward z, shouldn't it be plus 1 to remove gravity instead of minus 1?

Looking at the log values for the accelerometer, it looks like z acc is reversed. Steady state value for z acc is +1. x and y defined as in cf2 coordinate system

Log data from the estimator are according to the cf2 coordinate system with a steady state z acc of 0.

The gyro angular rate is in the body frame and CF coordinate.

Body frame: yes
Looking at gyro log values
Angular rate is positive clock wise for all axes as they are defined in cf2 coordinate system

Roll, pitch, yaw in the stabilizer and state estimator defined as in cf2 coordinate system, that is pitch is y-axis CCW.

I see the quaternion estimate remains in the standard coordinate. So if my quaternion-based controller uses standard coordinates, the only thing I need to do is to negate sensors->gyro.y

See gyro above

If I use MoCap and default crazyswarm configurations, the CF will have a world-frame as the MoCap and receive position + quaternion measurements in standard coordinates (reason as in 4.)

I'm not sure how crazyswarm has defined the system

A side thing in Brescianini controller that I found: this should use omega_yaw_max
And it seems like this controller is using the wrong pitch rate direction (omega[1]), considering its powerDistributionForceTorque as well.

Interesting, I mainly copy/pasted the code from an old implementation and did not look too much at the details. I will add an issue to investigate the problem.

[xkhainguyen]

Thanks for the answers, let's reiterate

Body frame: yes
Looking at gyro log values
Angular rate is positive clock wise for all axes as they are defined in cf2 coordinate system

So pitch rate (from gyro) is CW, not as in cf2 coordinate system. Then the Breschianini controller should be correct.

Roll, pitch, yaw in the stabilizer and state estimator defined as in cf2 coordinate system, that is pitch is y-axis CCW.

The only thing in CCW is pitch angle. Quaternion estimate is CW as well.

=> So if my controller uses CW coordinate and quaternion instead of Euler angles, everything should be natively fine.

[krichardsson]

The easiest way to verify this is to connect a client, set up logging of the variable you are interested in and check the behavior by moving the Crazyflie around. This way you will see what actually is happening.

[xkhainguyen]

@krichardsson Thank you very much!