mission feasibility fundamental problem (mavlink mission sync architecture)

[dagar]

WIP placeholder, more detail coming.

https://github.com/PX4/Firmware/pull/12464#issuecomment-511137439

Before accepting a mission navigator requires that the feasibility checker accepts it. The problem is that the mission is already synced to the vehicle with the previous mission discarded before the feasibility is accessed. For example a plane with a valid mission (and planned landing sequence) could have an infeasible mission uploaded during operation, resulting in the vehicle no longer having a safe planned landing.

We need to structure things such that the valid mission is kept and only replaced by a new feasible mission.

[Antiheavy]

resulting in the vehicle no longer having a safe planned landing.

This is the crux of the problem from a fixed wing perspective. Unfortunately we have airplanes loitering around home until the battery runs out and it "lands" randomly into trees/crops/buildings around the Home location. Counting on the user (especially a new user) to properly upload a "feasible" mission isn't enough.

We need to structure things such that the valid mission is kept and only replaced by a new feasible mission.

Some sort of double buffer or two memory (SDcard) slots for mission storage may be needed?

[Antiheavy]

This issue applies to VTOLs that wish to use a mission landing as well: https://github.com/PX4/Firmware/issues/10669#issuecomment-511384590 https://github.com/PX4/Firmware/pull/12464

[RomanBapst]

@Antiheavy Was just looking into this. Either we create two mission files and only allow the actual mission file to be updated if the feasibility checks on the temporary ones pass. The other option is to write both mission into one file and clear the old mission from the files as soon as checks on the new mission pass.

[RomanBapst]

@dagar FYI

[RomanBapst]

@dagar From what I see mavlink_mission.cpp writes the mission directly to the SD card via dataman API. We could write those items into a separate dataman file in order to first evaluate it in the navigator. If the navigator is happy he can then copy the mission items into the primary dataman storage. What do you think?

[Antiheavy]

If the navigator is happy he can then copy the mission items into the primary dataman storage.

do you need to actually copy it? or can you have 2 mission slots and just declare which one is "active" and let the non-active one be open for overwriting? ... I'm no software architect so maybe i'm way off base... Either way, I'm supper excited to see this issue getting some attention!

[Antiheavy]

Another important point to consider: If RTL_TYPE=1 is selected and the user purposefully "clears the vehicle mission" via QGC or other, the RTL landing will be deleted. I wonder if completely clearing all valid missions during "flying" should be prevented somehow if certain RTL_TYPEs are selected? edit: clearing vehicle mission while in launch detection, but not yet flying, should also be prevented, or should cause an immediate disarm. (fyi @kjkinney)

[Antiheavy]

@RomanBapst any further thoughts on this?

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions.

[Antiheavy]

Still highly relevant.

[hamishwillee]

@RomanBapst What has to happen for this to move forward.

Is it that you expect @Antiheavy to contribute the solution? If so, shouldn't it still be you who defines here the expected architectural change?

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions.