Main Content

Exchange Data for MAVLink Microservices like Mission Protocol and Parameter Protocol Using Simulink

This example shows how to implement MAVLink microservices like Mission protocol and Parameter protocol using the MAVLink Serializer and MAVLink Deserializer blocks in Simulink®.

This example uses:


  • Simulink®

  • UAV Toolbox™

  • Stateflow™

  • Instrument Control Toolbox™

  • DSP System Toolbox™

The Mission protocol microservice in MAVLink allows a Ground Control Station (GCS) to communicate with a drone to send and receive mission information needed to execute a mission. The Mission protocol microservice allows you to:

  • Upload a mission from the GCS to the drone

  • Download a mission from the drone

  • Set the current mission item

The Parameter protocol microservice in MAVLink allows you to exchange parameters representing important configuration information between the drone and the GCS. The parameters are represented as key-value pairs.

This example explains how to:

  • Upload a mission consisting of 10 waypoints from the GCS to a drone emulated in Simulink. Use QGroundControl (QGC) as the GCS. If you do not have the QGC installed on the host computer, downnload it from here.

  • Read and write data to a list of 28 parameters from the QGC and the drone.

Design Model

To get started, follow these steps:

1. Open the exampleHelperMAVLinkMissionAndParamProtocol file in MATLAB and click Run. This creates the workspace variables required to initialize the data in Simulink and upload the autopilot parameters to the QGC.

2. Launch the example model in Simulink by clicking Open Model at the top of this page. You can also use the following command to launch the model anytime after you clicked the Open Model button once:


The Simulink model consists of:

1. Model Setup: This area in the model consists of two subsystem blocks - Initialize Function and Global Data Stores. These blocks are used to initialize the data that will be used in the model from the signals generated in the base workspace.

2. Protocol Rx: This area in the model consists of the receive_udp subsystem block that is used to receive UDP data from QGC. The subsystem contains a Simulink function that reads the MAVLink data over UDP from the QGC, at each simulation step. The received MAVLink data is passed to a Stateflow chart for decoding and parsing.

3. Mission Protocol: This area in the model consists of two subsystem blocks that send mission requests and mission acknowledgements to the QGC. These functions are called from the Stateflow chart that implements the mission microservice.

4. Mission and Parameter Protocol: The Stateflow chart that implements the mission and parameter logic in the model.

The received MAVLink data is deserialized in the process_udp Simulink function and then passed to the Stateflow logic that performs four tasks:

a. ReceivingMission: This Stateflow subchart receives a mission from the QGC and decodes the waypoints in the mission. It implements the protocol of Mission microservice that uploads a mission from QGC to drone, as described in Upload a Mission to the Vehicle.

b. SendingParams: This Stateflow subchart uploads the parameters created in the base workspace to the QGC by following the parameter protocol, as described in Read All Parameters.

c. SendSingleParams: This Stateflow subchart defines how to send a single parameter form the drone to the QGC, as described in Read Single Parameter.

d. WriteSingleParam: This Stateflow subchart defines how to update the parameter values from the QGC and see them on the drone, as described in Write Parameters.

5. Logic to read received waypoints and parameters: Stateflow implements the two protocols and outputs the received waypoints and uploaded parameter values.

The next section explains how to upload a mission from the QGC to the drone.

Upload a Mission from QGC to Drone and Run the Simulink Model

1. Launch the QGC and navigate to the Plan View.

2. A preplanned mission, MissionProtocol.plan, is available with this example. Click Open Model at the top of this page to save the plan file to your computer. After you save the .plan file, launch QGC, and click File > Open to upload the plan to the QGC.

After you upload the plan, the mission is visible in QGC.

3. Run the Simulink model. The Simulink model sends HEARTBEAT message over MAVLink to QGC and thus establish connection with QGC.

4. Click Upload at the top right of QGC interface to upload the mission from QGroundControl.

5. Observe that the latitude and longitude values from the first two waypoints of the uploaded mission are being displayed in Simulink.

6. Change the waypoint1 and waypoint2 in the QGC by dragging the waypoints to a different location in the plan. Upload the modified mission by clicking Upload Required.

7. Observe the modified Latitude/Longitude values for waypoint 1 and 2 in Simulink.

Modify Parameters in QGC and Send Them to Simulink

When you run the exampleHelperMAVLinkMissionAndParamProtocol file in the MATLAB Command Window, a workspace variable apParams is created, which is an array of 28 flight parameters.

When you run the Simulink model, it connects to the QGC, and the QGC reads the parameters from Simulink.

The parameters can be visualized and modified in the QGC:

1. Navigate to the Vehicle Setup pane in the QGC. Select the Parameters tab.

2. In the Parameters tab, select Other to list all the parameters that the QGC read from Simulink.

3. The model displays the values for GDNC_TSTAR and GDNC_TURN_LEAD parameters. Click the GDNC_TSTAR and GDNC_TURN_LEAD parameters and modify their corresponding values in the QGC.

4. The QGC writes the values of these modified parameters using the parameter protocol microservice to Simulink. Observe the parameter values being modified in Simulink.

Other Things to try

The Stateflow charts explained in this example do not implement the following scenario:

  • If the communication between the drone and the QGC breaks off at some point and reconnects, the mission protocol upload should resume after the waypoint from which the drone had transmitted data before disconnecting.

You can modify the Stateflow charts, so that even when the communication snaps, Stateflow remembers the last waypoint transmitted.