msg/vehicle_odometry.msg: simplify covariance handling and update all usage

[dagar]

• replace float32[21] URT covariances with smaller dedicated position/velocity/orientation covariances
• these are easier to casually inspect and more representative of what's actually being used currently and reduces the size of vehicle_odometry_s quite a bit
• ekf2: add new helper to get roll/pitch/yaw covariances
• mavlink: delete unused ATT_POS_MOCAP stream (this is just a passthrough)
• mavlink: ODOMETRY receiver
  • handle trivial frame conversions in place (MAV_FRAME_LOCAL_ENU, MAV_FRAME_LOCAL_FLU, etc)
  • ODOMETRY velocity support more than just MAV_FRAME_BODY_FRD

pxh> listener vehicle_odometry

TOPIC: vehicle_odometry
 vehicle_odometry
    timestamp: 45748000 (0.004000 seconds ago)
    timestamp_sample: 45748000 (0 us before timestamp)
    position: [2.0012, -0.0012, 0.4814]
    q: [0.7066, 0.0020, -0.0115, 0.7075] (Roll: -0.8 deg, Pitch: -1.1 deg, Yaw: 90.1 deg)
    position_covariance: [0.0000, -0.0000, 0.0000, 0.0000, 0.0000, 0.0162]
    orientation_covariance: [0.0007, 0.0004, -0.0000, 0.0004, -0.0000, 0.0000]
    velocity: [0.0030, -0.0008, -0.0006]
    angular_velocity: [-0.0004, 0.0026, -0.0027]
    velocity_covariance: [0.0000, -0.0000, -0.0000, 0.0000, -0.0000, 0.0000]
    local_frame: 1
    velocity_frame: 1
    reset_counter: 6
    quality: 0

PR is stacked on top of #19965.

[mhkabir]

I propose dropping all crossterms and only keeping the variances for each direct measurement (pos, orientation, vel). I'm yet to come across any real system where the crossterms are used/useful.

For real systems, generating actually correct (co)variance estimates is also really challenging in the first place

[dagar]

@james-modalai any opinion?

[dagar]

Covariances dropped as suggested, but it's in a separate commit we can revert if someone disagrees.

[mhkabir]

This is probably unnecessary?

[dagar]

Perhaps mildly useful for comparison, but otherwise we're not even using it.

[mhkabir]

Most systems don't even estimate that in my experience, hence suggestion to drop

[mengchaoheng]

why NaN is better than 0 ? @dagar

for (auto &pc : msg.pose_covariance) {
  pc = NAN;
}