EKF2 doesn't publish any state with vision + vision yaw aiding before vision data received

[okalachev]

This is reproduced on a real drone and in SITL on any version, e .g. 1.8.1 (the latest).

When using Q + LPE setup, you can aid vision position, but you still can fly without it in STABILIZED mode. It's pretty useful, because you can use one setup for autonomous flying and for normal manual flying.

On EKF2, the state is not getting initialised before any vision position messages published. Despite the lack of the state, you still can arm the copter in STABILIZED mode, which, in fact, acts more like ACRO mode.

Also, this makes flying with floor markers or with visual odometry (with the camera facing downwards) much harder, because you should take off to see markers or floor features, but you can't do it normally without the state.

To Reproduce

Clone 1.8.1 version, change EKF2_AID_MASK to 24 in ekf2/iris. Run SITL.

Then, in shell:

pxh> listener vehicle_attitude
never published
pxh> listener vehicle_local_position
never published

@mhkabir

[dagar]

The first thing we could do is lock it down. Something like requiring a valid attitude for arming if you're in a mode requiring attitude. The stricter option would be to reject entering stabilized mode, which might be more annoying for the typical use case.

@priseborough @mhkabir any suggestions for the desired solution of having usable attitude estimate with EKF2 prior to providing vision input?

Perhaps as an incremental step towards fully supporting multiple estimators we could make it possible for ATTQ and EKF2 to coexist, with a simple priority switch to the EKF2 attitude estimate once it's available and valid.

[okalachev]

Maybe just make EKF2 to estimate the attitude even without the vision position/yaw? The initial yaw can be taken from the magnetometer or (indoors, where magnetometer works poorly) just set to zero.

For me, the most useful behaviour would be like this:

EKF2 estimates everything even without any vision input. Yaw is set to 0 (OR to magnetometer yaw), local position is set to (0, 0, 0). As I understand, when the drone is landed, the velocities also should be set to zero, so the drone should stay at zero position until it's taken off. When it's taken off, Z can be corrected from barometer or rangefinder.

Then, when the vision data is coming, the drone should instantly believe to it (without any offsets and delays), and continue estimation with the vision data.

[mhkabir]

@dagar

any suggestions for the desired solution of having usable attitude estimate with EKF2 prior to providing vision input?

Yes this should already be working. I'm not sure why this isn't happening. I'll investigate.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale[bot]]

Closing as stale.

[fabianschilling]

I can confirm this is still an issue in 1.8.2 (latest stable). This is a serious bug since the vehicle reports to be in STABILIZED mode but behaves as in ACRO (as okalachev already said above).