Can a mission be created in a basic script form?

Using Mission Planner and QGC to make scripts, it seems as those these tools are simply a GUI to construction of a script that’s followed when in Auto flight mode.

When I was learning how to use a Loiter waypoint in a mission, I was referred to a MavLink doc about a MavLink command that controlled the mission’s loiter waypoint. Perhaps a mission is a script of MavLink commands.

No doubt, using a GUI front end to building a mission script has the advantage of controlling syntax errors. But if it’s possible construct a mission in raw format, perhaps there are some cases where it might be advantageous to do so.

I’d appreciate any suggestions or discussion anyone may have about this. Thank you!


Looking a the contents of a waypoint file from a mission saved to a file, it seems the mission is indeed sequence of simple coded statements - just guessing but I suspect one column represents a mission command and the subsequent columns are the command’s parameters.

In a recent video by Andrew Tridgell about a mission where a vehicle lands, disarms, waits, re-arms and then flies more of the mission, he describes how to use mission options that are “hidden.” And that LUA scripts are necessary to create even more complexity in missions.

This suggests to me that ArduPilot contains some sort of mission “interpreter” that has a substantial syntax vocabulary - and perhaps the role of LUA is that it can feed statements to the “interpreter” on the basis of an algorithm.

I’d welcome direction on how to become better informed on these topics.

amilcarlucas - Sure, that’s exactly how I do it now. I was just wondering about the options of creating the mission directly, instead of with the GUI table in Mission Planner or the Waypoint oriented method in QGC.

From the table shown from the waypoint file I posted - it seems one could simply use a spreadsheet to create such a table as long as you knew the numeric codes for the types of waypoints and their parameters.

It’s interesting to note the difference in how Mission Planner and QGC allows creation of a mission. QGC incorporates attributes such as speed and altitude in the waypoint entry - and Mission Planner has these entries on separate lines. This can cause depiction irregularities when moving a mission from one platform to the other - as it’s QGC I believe that expects a Lat/Long on entries - and Mission Planner has these positions on separate lines. This can cause the depiction of the course to be off to a “0, 0” coordinate. I’ve never tried to fly a mission that depicts this - not worth the risk.

Anyway - thanks for volunteering the links. My questions remain unanswered.

Mission planner and QGC use their own file format to store the missions. And that is probably not what you want, that file format has to be loaded in the respective GCS software to be translated to proper mavlink commands.
At the end of the day, all the drones do (PX4 based or ArduPilot based, they are similar in this respect) is execute mavlink mission commands

And sure, as long as you follow the mavlink mission protocol described above you can script missions as you like without needing neither mission planner nor QGroundControl. I would advise though to not try to reinvent the wheel and use either pymavlink or mavros to do this.

Now once the mission reaches the vehicle it does get stored in ArduPilots file format, that is again different from all other above, it contains less fields and is optimized for space. The Lua scripting can and should work with this file format.

So it really depends on what you want to do, where you want to do it, and how often you want to do it. If it is simple enough but very long, I guess your best bet will be Lua scripting.

It is exceedingly easy to write code in any number of programming or scripting languages that outputs the correct format. As well, onboard Lua provides mechanisms to create, load, and modify missions. You really haven’t asked a question specific enough to answer.

You’ve already alluded to understanding the file format. Other than digging into the source code, I’m not aware of a well documented source for the command indices and their associated parameters. If I want to use a specific mission command via a script (like the one I wrote for this topic), I use Mission Planner to create a mission with that command and use unique values for each required parameter. Then I simply reverse engineer the command by reading the output file. I recognize that’s not ideal, but I’m neither a developer nor a stickler for documentation - I’m just a user who’s interested in exploring the architecture and exploiting its features to the max extent possible.

Apologies - I am aware of this documentation, which is helpful and contains information that elaborates on the “reverse engineering” that I mentioned in the previous paragraph:
Messages (common) · MAVLink Developer Guide

Amilcarlucas - That’s helpful information - thank you.

My position is I’m an apprentice trying to learn the trade well enough to become a journeyman. I feel that the best way to know how to use the tool well, is to know how the tool works. I don’t want to re-engineer anything - I just don’t want to be needlessly uninformed. It’s tricky from my vantage to know where “needlessly” begins and ends.

When I was sorting out how to use the Loiter waypoint in a mission, I was referred to the Mavlink website reference that explained that command and it’s parameters. That’s when I got the idea that a mission is perhaps just a sequence of Mavlink commands - perhaps viewed as a script of them.

It was interesting that QGC didn’t have all the Mavlink Loiter command parameters available to the user to input.

The only way I’ve moved mission files from Mission Planner to or from QGC is by uploading it from one platform onto my copters, and downloading it to the other. I hadn’t considered a common format of a saved file. Yet both QGC and Mission Planner has to upload mission files in a format acceptable to ArduPilot. I just wanted to know more about the format of what gets loaded to ArduPilot.

Anyway - thank you to you and all your fellow journymen for helping this apprentice.

Yuri -

Thank you for your helpful input.

As in many (if not most) aspects of information technology, the software environment of ArduPilot is a layer cake. Lots of layers. I’m just trying to understand the layers that will help me the most.

@Yuri_Rage I posted above some links to the documentation. Do you know them?

Yes - but unless I’m missing something, nothing there addresses my questions.

Yes, such as for a MP .waypoints file, calculate coordinates in a spreadsheet and paste them, and use a text editor with column selection capability for modifying the .waypoints file directly.

1 Like

A mission is a sequence of mission items, have a look here.

These items are encapsulated into MAVLINK messages for transferring to an autopilot, the general MAVLINK spec is here (look for MAV_CMD_whatever such as the most obvious MAV_CMD_NAV_WAYPOINT) and the Ardupilot specific subset is here.

Commands are sent from a GCS to an autopilot by implementing the mission protocol, here is the spec for uploading. The various GCSes like MP and QGC implement this protocol. It doesn’t matter how they internally handle the mission or how they save it to file (this is for their own use after all), all that matters is that they nudge the autopilot into a mission upload transaction by sending a MISSION_COUNT MAVLINK message and then do the MISSION_REQUEST_INT, MISSION_ITEM_INT tango until the final MISSION_ACK as shown in the diagram.

You can script your own mission by using anything that can spit out MAVLINK (dronekit, pymavlink, MAVROS spring to mind) and you can also implement your own upload protocol, though I am sure there’s a bunch of implementations for this.
A much simpler solution might be to spit out a file readable by MP and then let MP do the uploading transaction. Each row in the .waypoints file is a MAV_CMD_whatever command, you can tell which one by the 4th column. So, in the file you link, I see 16, 22, 178, 16, 82…

16 is an easy one, it’s a waypoint and the first line must always be a waypoint that is taken to be HOME for the mission (even though it won’t actually be used since HOME is set to wherever the vehicle happens to be when it arms).

22 is a takeoff.

178 sets the speed.

16 we have already, it’s yet another a waypoint.

82 is a spline waypoint.


So, if you keep the documentation handy, you can simply write out a text file that is readable by MP (or a different one for QGC) and then just leave all the interfacing work to MP (or QGC).