EKF2: EV vel/pos only use EV q if enabled and valid

[dagar]

No description provided.

[haumarco]

When we have GNSS fusion enabled and yaw bit of ev_ctrl is 0, we still want to fuse the EV measurements right?
It would be ev_q_available=false, yaw_align=true

So right now the continuing_conditions_passing would be false.

In the current implementation, it would rotate the EV measurement using ev_q_error_filt

[dagar]

When we have GNSS fusion enabled and yaw bit of ev_ctrl is 0, we still want to fuse the EV measurements right? It would be ev_q_available=false, yaw_align=true

So right now the continuing_conditions_passing would be false.

In the current implementation, it would rotate the EV measurement using ev_q_error_filt

My approach with the EKF2_x_CTRL bits has been that we should strictly respect them for whether or not you're allowed to use the data. So if anything EKF2_EV_CTRL Yaw bit should actually be Orientation. Then the way it works now in ev_yaw control is that it only activates conditionally wrt GNSS/mag (in addition to the bit being set).

Then in the case you mention if we want to use GNSS (position) with EV position it either needs to be actual NED or if FRD we also require EV q (both valid data and bit enabled).

Thoughts?

[bresch]

What if you want to use the ev_q to rotate and fuse the position data but actually not fuse the ev yaw? I think this is a common use case when GNSS and ev_pos are both enabled (yaw is already observable and we don't want to use the somewhat arbitrary "yaw" from a vision system).
Should we then restore the old "rotate frame" bit?

[dagar]

What if you want to use the ev_q to rotate and fuse the position data but actually not fuse the ev yaw? I think this is a common use case when GNSS and ev_pos are both enabled (yaw is already observable and we don't want to use the somewhat arbitrary "yaw" from a vision system). Should we then restore the old "rotate frame" bit?

I agree it's a common use case and this is actually why I'm suggesting we do it automatically based on what's available (and enabled) so that we're in a better position to do whichever is needed contextually.

For example if you have vision + GNSS, but at takeoff you don't have a good fix (maybe you're inside) we fully use the EV frame (ev_pos + ev_yaw) and ignore mag (!yaw_align). Later if GNSS becomes good we reset yaw and start (cs_yaw_align=true, cs_gps=true) and ev_yaw stops (if enabled mag is also allowed to start at this point).

Does that make sense? In the case of EV_CTRL the bits set which data we say we want to use, but beyond that what we actually do with it depends on broader context.

[bresch]

For example if you have vision + GNSS, but at takeoff you don't have a good fix (maybe you're inside) we fully use the EV frame (ev_pos + ev_yaw) and ignore mag (!yaw_align). Later if GNSS becomes good we reset yaw and start (cs_yaw_align=true, cs_gps=true) and ev_yaw stops (if enabled mag is also allowed to start at this point).
Does that make sense? In the case of EV_CTRL the bits set which data we say we want to use, but beyond that what we actually do with it depends on broader context.

Ok, yes, that makes sense to me.
What do you think @haumarco ?

[haumarco]

Ah ok.
Maybe as a new feature:
I'm just thinking what if we have EV but only with xyz velocity data where the orientation offset is unknown (FRD). We should then be able to update _ev_q_error_filt based on the rotational delta of the velocity vectors (delta(v_local, v_frd) with a small alpha so its not only affecting the velocity magnitude.