Attitude message

[dpkoch]

Question: Do we want to include angular rates in the attitude message? These will be very similar to what's already being passed in the IMU message, so may be a waste of bandwidth. On the other hand, they may potentially be filtered, or you may simply want to get them in the same message and at the same time as the attitude. But they would make the message bigger.

I don't have a clear idea on whether we want to include them or not. If we do include them, we're very similar to the existing ATTITUDE message, except that they use floats. Thoughts?

[superjax]

I think the only reason we would add the rates to the message was if we were doing gyro filtering on the naze. I honestly don't know what to do about that. On one hand, it makes sense because the naze could receive 2-5 gyro messages each time it sends a mavlink message, so filtering all 5 into 1 makes sense. However, adding filters on top of filters seems like a way to introduce a lot of lag.

Cleanflight filters the gyro and the accel, then performs a complementary filter. I think that's weird, and we should instead just do complementary filtering from the raw sensor data. However, perhaps it makes sense to filter the gyro for sending the ATTITUDE message on mavlink, and take the filtered gyro measurements as the estimate of the angular rates.

What do you think about that. Add rate measurments to the mavlink Attitude message, and filter the gyro as an estimate of the rates?

[dpkoch]

Yeah that might make sense. So we would use the filtered gyro as the onboard rate estimate too?

Although there can be some low-pass filtering of gyros onboard the MPU-6050; do you know if that's turned on and already happening?

[superjax]

It looks like it is on, Apparently it's set to 42 Hz in drv_mpu6050.c

88|   static uint8_t mpuLowPassFilter = INV_FILTER_42HZ;

So the "raw" data we get from the gyro is already filtered. Would we get any benefit from filtering that data down to rate that we can process it?

[dpkoch]

Well what kind of filter were you thinking? Some type of averaging on all of the measurements since the last time we ran the estimator? Or an alpha-filter LPF on the most recent measurement like the one in the UAV book? For the latter I'm not sure it'd be much different than the built-in LPF, but may introduce additional delay. I'm not sure what the benefit of the former would be, or if it might even detrimental at too large of dt?

[superjax]

I don't know. I think we can run the onboard estimator on the IMU heartbeat so we don't need to filter it pre-estimator. I guess the only difference would be on the computer's EKF. I might have to ask Dr. McLain or Dr. Beard about the effect of a LPF on the IMU measurements pre-EKF.

[dpkoch]

@superjax so we're just using the existing attitude message then, right? So can we close this issue?

[superjax]

Yep!