Documentation

Quadcopter Project

This example shows how to use Simulink® to model a toy quadcopter and its cameras to help estimate the snow levels on the MathWorks Apple Hill campus roof.

  • To manage the model and source files, it uses Simulink® Projects.

  • To show the quadcopter in a three-dimensional environment, it uses Simulink® 3D Animation.

  • For the collaborative development of a flight simulation application, it provides an implementation of the Flight Simulation application template.

Note: To successfully run this example you must have a C/C++ compiler installed.

Open the quadcopter project

Run the following command to create and open a working copy of the project files for this example:

asbQuadcopterStart

Quadcopter physical characteristics

The following schematic shows the quadcopter physical characteristics:

  • Axis

  • Mass and Inertia

  • Rotors

Axis

The quadcopter body axis is centered in the center of gravity (represented by the red sphere in the schematic). The x-axis aligns with the arm that supports rotor #1. The rotors are numbered in a counterclockwise direction from rotor #1 to rotor #4 which is aligned with the quadcopter y-axis. The z-axis obeys the right hand rule.

Mass and Inertia

We assume that the whole body works as a particle (represented in this case by the red sphere with center in the center of gravity). The startVars file contains the values for the inertia and mass. This file also defines initialization variables such as initial velocity and position.

Rotors

  • Rotor #1 rotates positively with respect to the z-axis.

  • Rotor #2, which is aligned with the negative portion of the y-axis, rotates negatively with respect to the body's z-axis.

  • Rotor #3, which has the same color and rotation direction as rotor #1, is located along the negative portion of the x-axis.

  • Rotor #4, which has the same color and rotation direction as rotor #2, is located along the positive portion of the y-axis.

This rotor set-up for a quadcopter is often called a diamond pattern.

This example simplifies the rotors forces and moments as a table lookup that returns the forces and moments depending on the rotor revolutions per minute (RPMs). It uses a first order system to model the dynamics of the compound electric motor and rotor blade assembly. You can change the dynamics to a second order linear and nonlinear response by changing the Variants.Actuators structure in the workspace. For more information on subsystem variants see Model Variants).

The startVars file defines the arm length (measured as the distance between the quadcopter center of gravity and the rotors axis of rotation).

Note: Although there is a small difference between the plane that contains the rotors, and the center of gravity of the quadcopter, the mathematical model assumes that they are in the same plane.

Control

For control, the quadcopter uses a mixing technique to translate input changes in pitch, roll, yaw, and throttle. This technique uses differential thrust in rotor pairs to obtain the desired aircraft motion. For example, to obtain a positive pitching moment, the model amplifies the input from the pitch by a gain that is both:

  • Added to the rotor #1 RPM.

  • Removed by the same amount from rotor #3. The model similarly obtains the roll by affecting rotors #2 and #4. To obtain a positive yaw motion, the model amplifies the input by a gain that is both:

  • Added to the RPM of rotors #1 and #3.

  • Decreased by the same amount from rotors #2 and #4. The model also passes the throttle through a gain that adds or removes RPMs to all rotors at the same time. For simplicity, the model adds the throttle input to and subtracts it from the RPM required for the quadcopter to hover.

The controllerVars file contains the gains for each differential thrust bias.

You can provide inputs to the quadcopter (in pitch, roll, yaw, and throttle) by using one of the following and changing the Variants.Command structure in the workspace:

  • A Signal Builder block

  • A joystick

  • Previously saved data

  • Spreadsheet data

Sensors

The model uses a set of sensors to determine its states. It uses an Inertial Measurement Unit (IMU) to measure the angular rates and translational accelerations. To include sensor dynamics with these measurements, you can change the Variants.Sensors structure in the workspace.

Environment

The models implement several Aerospace Blockset™ environment blocks, including those for atmosphere and gravity models. To include these models, you can change the Variants.Environment structure in the workspace to toggle between variable and fixed environment models.

Linearization

The model uses the trimLinearizeOpPoint file to linearize the nonlinear model of the quadcopter for hovering. This file uses Simulink Control Design® to find a linear system for which the angular rates and the translational states are equal to zero. You can edit this file to find linear models for different flying conditions. For more information on how to do this, see the Simulink Control Design documentation).

Testing

To make sure that the linear and nonlinear models are equivalent under a set of conditions, the model adds a file, linearTest to the project. This test adds a doublet maneuver to all the rotors (actuators) and compares the outputs for the linear and nonlinear models. linearTest uses the MATLAB® Unit Testing Framework.

Visualization

You can visualize the variables for the quadcopter in one of the following ways:

  • Using Simulation Data Inspector.

  • Using the flight instrument blocks.

  • Toggling between the different visualization variant subsystems. You can toggle between the different variant subsystems by changing the Variants.Visualization structure. Note that one of these variants is a FlightGear animation. To use this animation, you must add a FlightGear compatible model of the quadcopter to the project. The software does not include this model.

Trajectory Generation

A trajectory generation tool, using the Dubin method, creates a set of navigational waypoints. To create a trajectory with a set of waypoints this method uses a set of poses defined by position, heading, turn curvature, and turn direction.

To start the tool, open the project and run:

asbTrajectoryTool

The following interface displays:

The interface has several panels:

Waypoints

This panel describes the poses the trajectory tool requires. To define these poses, the panel uses text boxes:

  • North and East (position in meters)

  • Heading (degrees from North)

  • Curvature (turning curvature in meters^-1)

  • Turn (direction clockwise or counter-clockwise)

A list of poses appears in the waypoint list to the right of the text boxes.

To add a waypoint, enter pose values in the edit boxes and click Add. The new waypoint appears in the waypoint list in the same panel.

To edit the characteristics of a waypoint, select the waypoint in the list and click Edit. The characteristics of the waypoints display in the edit boxes. Edit the characteristics as desired, then click OK. To cancel the changes click Cancel.

To delete a waypoint, in the waypoint list, select the waypoint and click Delete.

No-Fly Zone

The panel defines the location and characteristics of the no-fly zones. To define the no-fly zone, the panel uses text boxes:

  • North and East (position in meters)

  • Radius (distance in meters)

  • Margin (safety margin in meters)

Use the Add, Delete, Edit, OK, and Cancel buttons in the same way as for the Waypoints panel.

Mapped Trajectory

This panel plots the trajectory over the Apple Hill campus aerial schematic based on the waypoints and no-fly zone characteristics.

To generate the trajectory, add the waypoint and no-fly zone characteristics to the respective panels, then click Generate Trajectory .

To save the trajectory that is currently in your panel, click the Save button. This button only saves your last trajectory.

To load the last saved trajectory, click Load.

To load the default trajectory, press the Load Default button.

To clear the values in the waypoint and no-fly zone panel, click Clear.

The default data contains poses for specific locations at which the toy quadcopter uses its cameras so the pilot on the ground can estimate the height of the snow on the roof. Three no-fly zones were defined for each of the auxiliary power generators, so in case there is a failure in the quadcopter, it does not cause any damage to the campus infrastructure.

When the example generates the trajectory for the default data, the plot should appear as follows:

The red line represents the trajectory, black x markers determine either a change in the trajectory or a specific pose. Blue lines that represent the heading for that specific waypoint accompany specific poses. No-fly zones are represented as green circles.

If you have a Simulink 3D Animation license, you can also view the trajectory in a 3-D representation of the Apple Hill campus:

Note: For visualization reasons the 3D representation of the quadcopter is not at the same scale as the environment.

Was this topic helpful?