common: add not feasible mission results

[julianoes]

It came up that it should be possible for the flight controller to communicate with the ground station if an uploaded mission is not actually feasible.

Hence I'm adding two cases for where the upload is not feasible. This is probably not the full list. And I'm wondering if we should have only one NOT_FEASIBLE result and then communicate the exact reason via statustext/event.

[hamishwillee]

This means you can't fly the distance because the frame with a full battery would crash before the end? Does it take account of partial battery?

[julianoes]

I guess the question is if a mission should have battery stops programmed in or not. To this day I have not seen multi battery missions being executed correctly, so that's a bigger problem to solve, in my opinion.

[hamishwillee]

Mission is not feasible because it will cause a geofence violation - essentially catering for exclusion and inclusion geofences

[hamishwillee]

If we include not feasible at all then I think having individual reasons at this point is better than status messages.

My concern about feasibility is that some of these things only work with atomic upload of the whole plan. i.e I upload a mission then a geofence then a rally points (say). When I upload my new mission it will be compared against the existing geofence and can potentially fail.

I sit on the fence a bit for this one. Consider the too long test -

• should be able to upload a mission when my battery has low battery - I could just add more batteries.
• What if my mission allows landing for battery recharge.
• It is not "certain" changing vehicle airframe and reboot clears a mission. So you've rejected the mission that might be valid if I just had my vehicle type set wrong?

My "gut" feeling is that we are always going to have to a pre-flight or pre-mission validity check anyway, and getting that right and informing the user is actually more important than failing here. Just my 2 bits.

[julianoes]

When I upload my new mission it will be compared against the existing geofence and can potentially fail.

Yes, that's a good point.

My "gut" feeling is that we are always going to have to a pre-flight or pre-mission validity check anyway, and getting that right and informing the user is actually more important than failing here. Just my 2 bits.

Yes, agreed.

[hamishwillee]

Yeah, the whole thing is a bit messy. You might for example upload a new geofence that invalidates the current mission. Should that fail because the mission is no longer valid? What if you just wanted to fly manually and you're using the geofence to do that safely?

I don't think you can do a reliable test of a mission against valid geofence or rally points unless plan upload is atomic.

• Even if you recommend upload order as rally point, geofence, mission, to ensure the mission works with the geofence - if the mission upload fails, you now have a potentially incompatible geofence and rally points for the old mission.
• A GCS might somewhat fake the required behaviour in a hacky way. It can store the current geofence and rally points, and then do upload in order geofence, rally point, mission. If the mission upload fails it could restore the potentially invalid rally point and geofence. Ugly, an only works because geofence and rally points, unlike missions, can round trip.

Further you can feasibility check before a mission, but what if you upload the mission while you're flying?

It is probably worth discussing in the dev call whether/how we might support atomic upload of the plan.

In the meantime how are you reporting that a mission is infeasible at runtime? What I'm wondering is whether we could ask the GCS to command a feasibility check after uploading the last part of the plan. If it fails then the vehicle will still have an infeasible plan, but we could invalidate the version on the GCS and put it in a state where it requires upload before the mission would be started. Not ideal since the GCS is the interlock and you might still start the mission via a companion that doesn't check validity but better that nothing.

[julianoes]

Ok, let's discuss it in the dev call. I'll leave this open until then but we can probably close it after.

[hamishwillee]

OK. Sounds like a plan - added to agenda.

[julianoes]

Takway: needs more thought, and is probably not so easy. Closing for now. We can easily pick that back up once it comes up.