One of the most common user complaints about QGC is the lack of feedback to the user when planning a mission (in the top 3 user complaints for us).
PX4 has an onboard "mission feasibility checker" that checks the mission AFTER it has been uploaded. This is a nice safety feature for the vehicle, but is very frustrating to users who spent a bunch of time planning a mission only to have it rejected with cryptic warning messages back from the autopilot as to why.
It seems to me that QGC has a lot of information in the downloaded parameters about if the vehicle will reject the mission or not. This list may not be complete, but here are a the most common/problematic PX4 parameters that could be checked against the mission live while planning:
GF_MAX_HOR_DIST
GF_MAX_VER_DIST
MIS_DIST_1WP
MIS_DIST_WPS
FW_LND_ANG
MIS_TAKEOFF_REQ
RTL_TYPE (to see if a landing sequence is required)
Proposed approach:
turn the mission item and partial line segment RED if they are placed with invalid settings (e.g. location, altitude, etc) based on a local version of the mission feasibility checker running in QGC in real time.
The red coloring would be consistent with the red terrain altitude bars.
There could also be a checklist summary somewhere that showed all mission checks green or showed which items where invalid/missing in red.
A toggle in application settings could optionally block upload of a QGC invalid mission.
What should happen if planning a mission when you're not connected to any vehicles? Just allow the plan and then re-evaluate the mission after you connect?
What if the user modifies the above parameters? Does the ground station have to watch them and recalculate?
Suggest add GF_ACTION to list since if geofence action is only a warning I presume a mission is still valid.
RTL_TYPE is not a blocker for mission acceptance, though I can see that it would be a useful hint to the end user. Especially on fixed wing (and again, when you create a mission you don't know what vehicle you'll be running on).
@Antiheavy - is there also a PR in place in PX4 to provide less cryptic upload fail messages. Working the problem at both ends makes sense.
One of the most common user complaints about QGC is the lack of feedback to the user when planning a mission (in the top 3 user complaints for us).
PX4 has an onboard "mission feasibility checker" that checks the mission AFTER it has been uploaded. This is a nice safety feature for the vehicle, but is very frustrating to users who spent a bunch of time planning a mission only to have it rejected with cryptic warning messages back from the autopilot as to why.
It seems to me that QGC has a lot of information in the downloaded parameters about if the vehicle will reject the mission or not. This list may not be complete, but here are a the most common/problematic PX4 parameters that could be checked against the mission live while planning: GF_MAX_HOR_DIST GF_MAX_VER_DIST MIS_DIST_1WP MIS_DIST_WPS FW_LND_ANG MIS_TAKEOFF_REQ RTL_TYPE (to see if a landing sequence is required)
Proposed approach:
PX4 feasibility checker: https://github.com/PX4/Firmware/blob/master/src/modules/navigator/mission_feasibility_checker.cpp