Hello. I’m trying to upload a mission created using python to a SITL fixed wing aircraft. If I try the mission defined in the example, with airspeeds, GPS coords and altitudes adjusted to appropriate values for my particular aircraft, I receive the following message in QGroundControl:
“[15:56:36.299] Critical: Mission rejected: landing pattern required.”
And in the python terminal:
“mavsdk.mission.MissionError: ERROR: ‘Error’; origin: start_mission(); params: ()”. It does, however state that the vehicle is armed and that the mission is starting before throwing the message.
If I shut QGroundControl and again try to run the script, I receive the same python terminal error message, but I do find that the mission waypoints have been uploaded to the vehicle upon re-opening QGroundControl.
I suspect I need to include a takeoff and/or a landing in the mission I’m trying to upload to stop this error? If so how do I pre-program such a mission item in MAVSDK (I cannot find an appropriate mission item to facilitate this)?
I think that’s a PX4 question: I don’t understand why a mission would not be valid without a landing pattern; it seems perfectly reasonable to me to fly a mission that ends in loiter mode somewhere.
Isn’t it possible to plan such a mission (i.e. without a landing pattern) from QGC?
Hi Jonas, thank you for your reply. I have just now tried to upload a mission without the landing pattern, and I do receive the same message “Mission rejected: landing pattern required.”
I originally thought there may be a vehicle parameter I could set to not require the landing for a mission, but I cannot find one - all I can find is “MIS_TAKEOFF_REQ” for the takeoff (nothing for the landing)…maybe I can turn off completely the mission feasibility checker somehow (probably dangerous)?
I appreciate any advice. If I cannot upload a landing using MAVSDK do you think another option like pymavlink or DroneKit would be more suitable? I’m really just trying to upload waypoints (in the form of a mission) on the fly to the aircraft.
If it doesn’t work when you upload a mission from QGC then it won’t work anywhere unless you either provide a mission landing (one solution!) or disable whatever is requiring it.
What value do you have for the parameter RTL_TYPE? If it is 2 see if the problem goes away when you set 0. My guess here being that if you have a mission landing required for return path, then you have to define one.
@sfuhrer Is there a plane trigger that forces a mission landing to be present (I am wondering if the thunderfly vehicle is a fixed wing frame)
Hello @hamishwillee! Yes that indeed works if I set the parameter “RTL_TYPE” = 0. Thank you - this solves the problem of being able to upload the mission, arm and fly waypoints calculated off-board.
My remaining related problem however is that at some point, ultimately, I need to land. So I still need to somehow define a fixed wing landing item. From what I can work out, MAVSDK’s “mission” class does not currently support such a landing mission item (please correct me if I’m wrong here).
I have therefore been trialing compilation of a QGroundControl “.plan” file that contains a landing mission item, however I’m having trouble finding a good reference as to what format this item should be (please tell me if you know of a good reference here). I did think I could reverse engineer the format from a working “.plan” file saved directly out of QGroundControl, but when I try to upload this file (without any change) to the aircraft using the mavsdk mission_RAW class (import_qgroundcontrol_mission) I receive a file parse error “mavsdk.mission_raw.MissionRawError: FAILED_TO_PARSE_QGC_PLAN: 'Failed To Parse Qgc Plan…”, so I’m not having much success. I suspect there could be a miss-match between the latest QGroundControl “.plan” format and the MAVSDK parse requirements but I could be wrong. Note that if I remove the landing mission item then this plan imports fine. Do you have any suggestions for me here?
@sfuhrer Can you advise me on other things that might cause mission feasibility checks, or point me to the code where messages are defined.
Further, are there any other key critical messages that you might think need to be recorded other than these checks and the EKF errors?
Hi @hamishwillee. Yes as soon as I include a MAV_CMD_DO_LAND_START mission item it throws an error “mavsdk.mission_raw.MissionRawError: UNSUPPORTED: ‘Unsupported’;…”. I figure I am either off the mark with the format of my file, or this mission item is indeed unsupported - most likely the former due to the fact that I’m guessing on the required format. If you do ever track down any documentation here (even just an un-commented example) it would really be appreciated.
Thanks very much again for your help with my issues!
I have worked through the problem some more and come to the following conclusions:
The latest QGroundControl (QGC) version (I’m currently running v4.2.3) has a fixed wing landing “sequence” or “syntax” that is not recognized by the MAVSDK parsing routine (I believe MAVSDK is not up to date on the latest QGC landing “syntax”). This is evidenced by the fact that an unedited working QGC mission exported to “.plan” format will not re-import using the MAVSDK “mission_import.py” script in the MAVSDK examples due to a parsing error. I can, however, get around this by manually creating MAV_CMD_DO_LAND_START & MAV_CMD_NAV_LAND mission items (essentially defining a landing as per older versions of QGC) - thank you Hamish!
RTL_TYPE for fixed wing when set to 0, 1, or 3 does not fly to the MAV_CMD_DO_LAND_START marker, but rather directly to the MAV_CMD_NAV_LAND marker. The result of this is no alignment with runway heading on approach and landing. This might be just my system / setup but I figure it is worth mentioning as someone else may want to check it. I have the same problem with these RTL_TYPE settings when a mission landing is setup via the latest QGC landing syntax as well. I suspect the intent is to fly to the MAV_CMD_DO_LAND_START so the entire fixed wing landing sequence (runway alignment, descent rate, airspeeds etc.) is followed and a safe landing can occur.
In any case, I have a path forward for my immediate problem (I can now calculate a mission in code, and upload directly to the aircraft). Thank you both again very much for your help!
