my drones

yuneec - Edison, Simulink

Yuneec H and Intel Intellisense sensors

Overview

Typhoon H Hexacopter

Autonomous flight modes allow you to recall pre-programmed tracking shots while focusing on the camera:

Orbit Me: Typhoon H flies a circular path around you, keeping the camera trained on you the whole time. Point of Interest (POI): Select a subject and Typhoon H will orbit that subject autonomously. Journey Mode: Typhoon H will automatically go up and out, as far as 90 m, and capture the perfect aerial selfie. Follow Me / Watch Me: Follow Me ensures Typhoon H moves along with you. Watch Me tells Typhoon H to follow you while always pointing the camera at you wherever you go.

Curve Cable Cam: Easily program an invisible route for Typhoon H to fly along. Typhoon H will fly between pre-set coordinates while independently controlling camera position.
Return Home: Simply switch to Home Mode and Typhoon H will return and land within 8 m of you.

Vtol - APM, vtol

Vtol with single prop

Follow up work from this post , we decided to go for another flight to get a better tuned pitch controller, rectify airspeed sensor problems and collect more flight data before we push for TECS tuning.

A few hypotheses that we have been thinking about:

1. Vibrations from the DLE61 gas engine got to the Cube’s pitch estimation, causing the dive
   • Looking at the attitude graphs, the system knew that pitch was going down. It was also desiring more and more pitch as the aircraft dove downwards.
   • error_RP data from NKF4 seem to indicate small errors.
   • Plane pitch controllers (set of PIDP data) also seem to indicate that PID loops are actively kicking in to bring aircraft back to level
   • One thing we did notice is that there was a lot of clipping of accelerometers while aircraft is still on the ground. However, the clipping events stopped when aircraft is in the air.
   • Given that we were able to do a QLOITER with an engine in idle @ 2700 RPM, we aren’t sure if sensors and estimation are the cause of the problem.
     

Racing Skyhero - APM, skyhero

Skyhero

FC

Spacing f3 6dot

camera

Aomway

DJI s900 - DJI, Assistant, Spreadwings

DJI S900 Wookong

overview

checklist and indicator status

• Servo power will shut off 3 seconds after the landing gear has reached its target position.
• When powering on the system, if the transmitter switch is in the [Upper] position, the LED will flash red quickly as a warning. Toggle the switch to the [Lower] position to continue.
• If there is an abnormal signal or no signal input into the “IN” port, the LED will slowly flash red. Check receiver and connections for problems.
• If servo power consumption is too high, the LED will light up red. If this lasts more than 4 seconds, the landing gear will lower and the LED will flash green slowly. Re-calibration is needed beforeflying.
• A2 flight control system users can use the A2 Assistant to set intelligent gear on the “Advanced” page. Refer to the “A2 user manual” for details

DJI s1000 - DJI, Assistant 2, Spreadwings

DJI S1000 A2

overview

DJI s900 - DJI, Assistant, Spreadwings

DJI S1000 Wookong

overview

checklist and indicator status

• Servo power will shut off 3 seconds after the landing gear has reached its target position.
• When powering on the system, if the transmitter switch is in the [Upper] position, the LED will flash red quickly as a warning. Toggle the switch to the [Lower] position to continue.
• If there is an abnormal signal or no signal input into the “IN” port, the LED will slowly flash red. Check receiver and connections for problems.
• If servo power consumption is too high, the LED will light up red. If this lasts more than 4 seconds, the landing gear will lower and the LED will flash green slowly. Re-calibration is needed beforeflying.
• A2 flight control system users can use the A2 Assistant to set intelligent gear on the “Advanced” page. Refer to the “A2 user manual” for details

DJI Quad - DJI, quad

dji quad custom frame

dji wookong with gimball

overview

pixhawk4 vision - APM, Mission-planner, autonomy

Pixhawk vision

nazam - DJI, Assistant

DJI Naza m Lite

FC

Naza M Lite

_mydrone-readme - ros, apm, lora

overview

jetbot - nVidia, jetbot

Jetbot Nvidia Nano RAPA project

Follow me - APM, Mission-planner

Follow-Me Mode

- APM, Mission-planner

vibration isolation - APM, Mission-planner

Vibration Isolation

This topic shows how to determine whether vibration levels are too high, and lists some simple steps to improve vibration characteristics.

Overview

Flight Control boards with in-built accelerometers or gyros are sensitive to vibrations. High vibration levels can cause a range of problems, including reduced flight efficiency/performance, shorter flight times and increased vehicle wear-and-tear. In extreme cases vibration may lead to sensor clipping/failures, possibly resulting in estimation failures and fly-aways.

Well-designed airframes damp/reduce the amplitude of specific structural resonances at the autopilot mounting location. Further isolation may be needed in order to reduce vibration to the level that sensitive components can handle (e.g. some flight controllers must be attached to the airframe using some form of anti-vibration foam/mount - while others are internally isolated).

Vibration Analysis

Log Analysis using Flight Review > Vibration explains how to use logs to confirm whether vibration is a probable cause of flight problems.

Basic Vibration Fixes

A few of simple steps that may reduce vibrations are:

• Make sure everything is firmly attached on the vehicle (landing gear, GPS mast, etc.).
• Use balanced propellers.
• Make sure to use high-quality components for the propellers, motors, ESC and airframe. Each of these components can make a big difference.
• Use a vibration-isolation method to mount the autopilot. Many flight controllers come with mounting foam that you can use for this purpose, while others have inbuilt vibration-isolation mechanisms.
• As a last measure, adjust the software filters. It is better to reduce the source of vibrations, rather than filtering them out in software.

References

Some references that you may find useful are:

• An Introduction to Shock & Vibration Response Spectra, Tom Irvine (free paper)
• Structural Dynamics and Vibration in Practice - An Engineering Handbook, Douglas Thorby (preview).

quick start pixracer - APM, Mission-planner

Pixracer Wiring Quick Start

:::warning PX4 does not manufacture this (or any) autopilot. Contact the manufacturer for hardware support or compliance issues. :::

:::warning Under construction :::

This quick start guide shows how to power the Pixracer flight controller and connect its most important peripherals.

Wiring Guides

Main Setup

Radio/Remote Control

A remote control (RC) radio system is required if you want to manually control your vehicle (PX4 does not require a radio system for autonomous flight modes).

You will need to select a compatible transmitter/receiver and then bind them so that they communicate (read the instructions that come with your specific transmitter/receiver).

The instructions below show how to connect the different types of receivers:

• FrSky receivers connect via the port shown, and can use the provided I/O Connector.

  

  

• PPM-SUM and S.BUS receivers connect to the RCIN port.

  

• PPM and PWM receivers that have an individual wire for each channel must connect to the RCIN port via a PPM encoder like this one (PPM-Sum receivers use a single signal wire for all channels).

Power Module (ACSP4)

quick start pixhawk4 mini - APM, Mission-planner

Pixhawk 4 Mini Wiring Quick Start

:::warning PX4 does not manufacture this (or any) autopilot. Contact the manufacturer for hardware support or compliance issues. :::

This quick start guide shows how to power the Pixhawk^® 4 Mini flight controller and connect its most important peripherals.

Wiring Chart Overview

The image below shows where to connect the most important sensors and peripherals (except for motors and servos).

:::tip More information about available ports can be found here: Pixhawk 4 Mini > Interfaces. :::

Mount and Orient Controller

Pixhawk 4 Mini should be mounted on your frame using vibration-damping foam pads (included in the kit). It should be positioned as close to your vehicle’s center of gravity as possible, oriented top-side up with the arrow pointing towards the front of the vehicle.

:::note If the controller cannot be mounted in the recommended/default orientation (e.g. due to space constraints) you will need to configure the autopilot software with the orientation that you actually used: Flight Controller Orientation. :::

GPS + Compass + Buzzer + Safety Switch + LED

Attach the provided GPS with integrated compass, safety switch, buzzer, and LED to the GPS MODULE port. The GPS/Compass should be mounted on the frame as far away from other electronics as possible, with the direction marker towards the front of the vehicle (separating the compass from other electronics will reduce interference).

:::note The GPS module’s integrated safety switch is enabled by default (when enabled, PX4 will not let you arm the vehicle). To disable the safety press and hold the safety switch for 1 second. You can press the safety switch again to enable safety and disarm the vehicle (this can be useful if, for whatever reason, you are unable to disarm the vehicle from your remote control or ground station). :::

Power

The Power Management Board (PMB) serves the purpose of a power module as well as a power distribution board. In addition to providing regulated power to Pixhawk 4 Mini and the ESCs, it sends information to the autopilot about the battery’s voltage and current draw.

Connect the output of the PMB that comes with the kit to the POWER port of the Pixhawk 4 Mini using a 6-wire cable. The connections of the PMB, including power supply and signal connections to the ESCs and servos, are explained in the image below.

:::note The image above only shows the connection of a single ESC and a single servo. Connect the remaining ESCs and servos similarly. :::

The pinout of the Pixhawk 4 Mini POWER port is shown below. The CURRENT signal should carry an analog voltage from 0-3.3V for 0-120A as default. The VOLTAGE signal should carry an analog voltage from 0-3.3V for 0-60V as default. The VCC lines have to offer at least 3A continuous and should default to 5.1V. A lower voltage of 5V is still acceptable, but discouraged.

:::note If using a plane or rover, the 8 pin power (+) rail of MAIN OUT will need to be separately powered in order to drive servos for rudders, elevons, etc. To do this, the power rail needs to be connected to a BEC equipped ESC, a standalone 5V BEC, or a 2S LiPo battery. Be careful with the voltage of servo you are going to use here. :::

:::note Using the Power Module that comes with the kit you will need to configure the Number of Cells in the Power Settings but you won’t need to calibrate the voltage divider. You will have to update the voltage divider if you are using any other power module (e.g. the one from the Pixracer). :::

Radio Control

A remote control (RC) radio system is required if you want to manually control your vehicle (PX4 does not require a radio system for autonomous flight modes).

You will need to select a compatible transmitter/receiver and then bind them so that they communicate (read the instructions that come with your specific transmitter/receiver).

The instructions below show how to connect the different types of receivers to Pixhawk 4 Mini:

• Spektrum/DSM or S.BUS receivers connect to the DSM/SBUS RC input.

  

• PPM receivers connect to the PPM RC input port.

  

• PPM and PWM receivers that have an individual wire for each channel must connect to the PPM RC port via a PPM encoder like this one (PPM-Sum receivers use a single signal wire for all channels).

For more information about selecting a radio system, receiver compatibility, and binding your transmitter/receiver pair, see: Remote Control Transmitters & Receivers.

Telemetry Radio (Optional)

Telemetry radios may be used to communicate and control a vehicle in flight from a ground station (for example, you can direct the UAV to a particular position, or upload a new mission).

The vehicle-based radio should be connected to the TELEM1 port as shown below (if connected to this port, no further configuration is required). The other radio is connected to your ground station computer or mobile device (usually by USB).

microSD Card (Optional)

SD cards are highly recommended as they are needed to log and analyse flight details, to run missions, and to use UAVCAN-bus hardware. Insert the card (included in the kit) into Pixhawk 4 Mini as shown below.

:::tip For more information see Basic Concepts > SD Cards (Removable Memory). :::

Motors

Motors/servos are connected to the MAIN OUT ports in the order specified for your vehicle in the Airframe Reference. See Pixhawk 4 Mini > Supported Platforms for more information.

:::note This reference lists the output port to motor/servo mapping for all supported air and ground frames (if your frame is not listed in the reference then use a “generic” airframe of the correct type). :::

:::caution The mapping is not consistent across frames (e.g. you can’t rely on the throttle being on the same output for all plane frames). Make sure to use the correct mapping for your vehicle. :::

Other Peripherals

The wiring and configuration of optional/less common components is covered within the topics for individual peripherals.

Configuration

General configuration information is covered in: Autopilot Configuration.

QuadPlane specific configuration is covered here: QuadPlane VTOL Configuration

Further information

• Pixhawk 4 Mini

quick start pixhawk4 - APM, Mission-planner

Pixhawk 4 Wiring Quick Start

:::warning PX4 does not manufacture this (or any) autopilot. Contact the manufacturer for hardware support or compliance issues. :::

This quick start guide shows how to power the Pixhawk 4^® flight controller and connect its most important peripherals.

Wiring Chart Overview

The image below shows how to connect the most important sensors and peripherals (except the motor and servo outputs). We’ll go through each of these in detail in the following sections.

:::tip More information about available ports can be found here: Pixhawk 4 > Connections. :::

Mount and Orient Controller

Pixhawk 4 should be mounted on the frame using vibration-damping foam pads (included in the kit). It should be positioned as close to your vehicle’s center of gravity as possible, oriented top-side up with the arrow pointing towards the front of the vehicle.

:::note If the controller cannot be mounted in the recommended/default orientation (e.g. due to space constraints) you will need to configure the autopilot software with the orientation that you actually used: Flight Controller Orientation. :::

GPS + Compass + Buzzer + Safety Switch + LED

Attach the provided GPS with integrated compass, safety switch, buzzer and LED to the GPS MODULE port.

The GPS/Compass should be mounted on the frame as far away from other electronics as possible, with the direction marker towards the front of the vehicle (separating the compass from other electronics will reduce interference).

:::note The GPS module’s integrated safety switch is enabled by default (when enabled, PX4 will not let you arm the vehicle). To disable the safety press and hold the safety switch for 1 second. You can press the safety switch again to enable safety and disarm the vehicle (this can be useful if, for whatever reason, you are unable to disarm the vehicle from your remote control or ground station). :::

Power

Connect the output of the Power Management Board (PM board) that comes with the kit to one of the POWER bricks of Pixhawk 4 using a 6-wire cable. The PM input 2~12S will be connected to your LiPo battery. The connections of Power Management Board, including power supply and signal connections to the ESCs and servos, are explained in the table below. Note that the PM board does not supply power to the servos via + and - pins of FMU PWM-OUT.

The image below shows the power management board provided with Pixhawk 4.

:::note If using a plane or rover, the 8 pin power (+) rail of FMU PWM-OUT will need to be separately powered in order to drive servos for rudders, elevons etc. To do this, the power rail needs to be connected to a BEC equipped ESC or a standalone 5V BEC or a 2S LiPo battery. Be careful with the voltage of servo you are going to use here. :::

:::note Depending on your airframe type, refer to Airframe Reference to connect I/O PWM OUT and FMU PWM OUT ports of Pixhawk 4 to PM board. MAIN outputs in PX4 firmware map to I/O PWM OUT port of Pixhawk 4 whereas AUX outputs map to FMU PWM OUT of Pixhawk 4. For example, MAIN1 maps to IO_CH1 pin of I/O PWM OUT and AUX1 maps to FMU_CH1 pin of FMU PWM OUT. FMU PWM-IN of PM board is internally connected to FMU PWM-OUT, which is used to drive servos (e.g. aileron, elevator, rudder, elevon, gear, flaps, gimbal, steering). I/O PWM-IN of PM board is internally connected to M1-8, which is used to drive motors (e.g. throttle in Plane, VTOL and Rover). :::

The following table summarizes how to connect Pixhawk 4’s PWM OUT ports to PM board’s PWM-IN ports, depending on the Airframe Reference.

The pinout of Pixhawk 4’s power ports is shown below. The CURRENT signal should carry an analog voltage from 0-3.3V for 0-120A as default. The VOLTAGE signal should carry an analog voltage from 0-3.3V for 0-60V as default. The VCC lines have to offer at least 3A continuous and should default to 5.1V. A lower voltage of 5V is still acceptable, but discouraged.

:::note Using the Power Module that comes with the kit you will need to configure the Number of Cells in the Power Settings but you won’t need to calibrate the voltage divider. You will have to update the voltage divider if you are using any other power module (e.g. the one from the Pixracer). :::

Radio Control

A remote control (RC) radio system is required if you want to manually control your vehicle (PX4 does not require a radio system for autonomous flight modes).

You will need to select a compatible transmitter/receiver and then bind them so that they communicate (read the instructions that come with your specific transmitter/receiver).

The instructions below show how to connect the different types of receivers to Pixhawk 4:

• Spektrum/DSM or S.BUS receivers connect to the DSM/SBUS RC input.

  

• PPM receivers connect to the PPM RC input port.

  

• PPM and PWM receivers that have an individual wire for each channel must connect to the PPM RC port via a PPM encoder like this one (PPM-Sum receivers use a single signal wire for all channels).

For more information about selecting a radio system, receiver compatibility, and binding your transmitter/receiver pair, see: Remote Control Transmitters & Receivers.

Telemetry Radios (Optional)

Telemetry radios may be used to communicate and control a vehicle in flight from a ground station (for example, you can direct the UAV to a particular position, or upload a new mission).

The vehicle-based radio should be connected to the TELEM1 port as shown below (if connected to this port, no further configuration is required). The other radio is connected to your ground station computer or mobile device (usually by USB).

SD Card (Optional)

SD cards are highly recommended as they are needed to log and analyse flight details, to run missions, and to use UAVCAN-bus hardware. Insert the card (included in Pixhawk 4 kit) into Pixhawk 4 as shown below.

:::tip For more information see Basic Concepts > SD Cards (Removable Memory). :::

Motors

Motors/servos are connected to the I/O PWM OUT (MAIN) and FMU PWM OUT (AUX) ports in the order specified for your vehicle in the Airframe Reference.

:::note This reference lists the output port to motor/servo mapping for all supported air and ground frames (if your frame is not listed in the reference then use a “generic” airframe of the correct type). :::

:::caution The mapping is not consistent across frames (e.g. you can’t rely on the throttle being on the same output for all plane frames). Make sure to use the correct mapping for your vehicle. :::

Other Peripherals

The wiring and configuration of optional/less common components is covered within the topics for individual peripherals.

Pinouts

Pixhawk 4 Pinouts (Holybro)

Configuration

General configuration information is covered in: Autopilot Configuration.

QuadPlane specific configuration is covered here: QuadPlane VTOL Configuration

Further information

• Pixhawk 4 (Overview page)
• Pixhawk 4 Technical Data Sheet
• Pixhawk 4 Pinouts (Holybro)
• Pixhawk 4 Quick Start Guide (Holybro)

quick start pixhawk - APM, Mission-planner

Pixhawk Wiring Quick Start

:::warning PX4 does not manufacture this (or any) autopilot. Contact the manufacturer for hardware support or compliance issues. :::

This quick start guide shows how to power the 3DR Pixhawk flight controller and connect its most important peripherals.

:::note The 3DR Pixhawk is no longer available from 3DR. Other flight controllers based on the Pixhawk FMUv2 architecture are available from other companies (these share the same connections, outputs, functions, etc. and are wired in a similar way). :::

Wiring Chart Overview

The image below shows standard Pixhawk connections (excepting the motor and servo outputs). We’ll go through each main part in the following sections.

:::note More detailed wiring information is shown below. :::

Mount and Orient Controller

The Pixhawk should be mounted on the frame using vibration-damping foam pads (included in the kit). It should be positioned as close to your vehicle’s center of gravity as possible, oriented top-side up with the arrow points towards the front of the vehicle.

:::note If the controller cannot be mounted in the recommended/default orientation (e.g. due to space constraints) you will need to configure the autopilot software with the orientation that you actually used: Flight Controller Orientation. :::

Buzzer and Safety Switch

Connect the included buzzer and safety switch as shown below (these are mandatory).

GPS + Compass

Attach a GPS (required) to the GPS port using the 6-wire cable supplied in the kit. Optionally attach a compass to the I2C port using a 4-wire cable (the Pixhawk has an internal compass, which can be used if necessary).

:::note The diagram shows a combined GPS and Compass. The GPS/Compass should be mounted on the frame as far away from other electronics as possible, with the direction marker towards the front of the vehicle (separating the compass from other electronics will reduce interference). :::

Power

Connect the output of a Power module (PM) to the POWER port using a 6-wire cable as shown. The PM input will be connected to your LiPo battery, while the main output will supply vehicle ESCs/motors (possibly via a power distribution board).

The power module supplies the flight controller with power from the battery and also sends information about the analog current and voltage supplied via the module (including both power to the flight controller and to motors etc).

:::warning The power module supplies the flight controller itself, but cannot power servos and other hardware connected to the controller’s output ports (rail). For copter this does not matter because the motors are separately powered. :::

For planes and VTOL the output rail will need to be separately powered in order to drive servos for rudders, elevons etc. Often the main pusher/puller motor uses an ESC with an integrated BEC that can be connected to the Pixhawk output rail. If not, you will need to setup a 5V BEC to connect to one of the free Pixhawk ports (without power, the servos will not work).

Radio Control

A remote control (RC) radio system is required if you want to manually control your vehicle (PX4 does not require a radio system for autonomous flight modes).

You will need to select a compatible transmitter/receiver and then bind them so that they communicate (read the instructions that come with your specific transmitter/receiver).

The instructions below show how to connect the different types of receivers to Pixhawk:

• Spektrum and DSM receivers connect to the SPKT/DSM input.

• PPM-SUM and S.BUS receivers connect to the RC ground, power and signal pins as shown.

• PPM and PWM receivers that have an individual wire for each channel must connect to the RC port via a PPM encoder like this one (PPM-Sum receivers use a single signal wire for all channels).

For more information about selecting a radio system, receiver compatibility, and binding your transmitter/receiver pair, see: Remote Control Transmitters & Receivers.

Telemetry Radios (Optional)

Telemetry radios may be used to communicate and control a vehicle in flight from a ground station (for example, you can direct the UAV to a particular position, or upload a new mission). One radio must be connected to your vehicle as shown below. The other is connected to your ground station computer or mobile device (usually by USB).

Motors

The mappings between MAIN/AUX output ports and motor/servos for all supported air and ground frames are listed in the Airframe Reference.

:::caution The mapping is not consistent across frames (e.g. you can’t rely on the throttle being on the same output for all plane frames). Make sure to use the correct mapping for your vehicle. :::

:::tip If your frame is not listed in the reference then use a “generic” airframe of the correct type. :::

:::note The output rail must be separately powered, as discussed in the Power section above. :::

Other Peripherals

The wiring and configuration of other components is covered within the topics for individual peripherals.

Configuration

General configuration information is covered in: Autopilot Configuration.

QuadPlane specific configuration is covered here: QuadPlane VTOL Configuration

Detailed Wiring Infographic (Copter)

Further information

• Pixhawk Series
• 3DR Pixhawk

quick start holybro pix32 v5 - APM, Mission-planner

Pix32 v5 Wiring Quick Start

:::warning PX4 does not manufacture this (or any) autopilot. Contact the manufacturer for hardware support or compliance issues. :::

This quick start guide shows how to power the Holybro Pix32v5^® flight controller and connect its most important peripherals.

Unboxing

Pix32 v5 is sold bundled with a number of different combinations of accessories, including the pix32 v5 Base board, power module PM02 V3, and the Pixhawk 4 GPS/Compass (UBLOX NEO-M8N).

The content of the box with the PM02 V3 power module and Pixhawk 4 GPS/Compass is shown below. The box also includes a pinout guide and power module instructions, and Base board (not shown on the schematic below).

Wiring Chart Overview

The image below shows how to connect the most important sensors and peripherals (except the motor and servo outputs). We’ll go through each of these in detail in the following sections.

:::tip More information about available ports can be found here. :::

Mount and Orient Controller

Pix32 v5 should be mounted on the frame positioned as close to your vehicle’s center of gravity as possible, oriented top-side up with the arrow pointing towards the front of the vehicle.

:::note If the controller cannot be mounted in the recommended/default orientation (e.g. due to space constraints) you will need to configure the autopilot software with the orientation that you actually used: Flight Controller Orientation. :::

:::tip The board has internal vibration-isolation. Do not use vibration-isolation foam to mount the controller (double sided tape is normally sufficient). :::

GPS + Compass + Buzzer + Safety Switch + LED

Pix32 v5 is designed to work well with the Pixhawk 4 GPS module, which has an integrated compass, safety switch, buzzer and LED. It connects directly to the GPS port using the 10 pin cable.

The GPS/Compass should be mounted on the frame as far away from other electronics as possible, with the direction marker towards the front of the vehicle (separating the compass from other electronics will reduce interference).

:::note The GPS module’s integrated safety switch is enabled by default (when enabled, PX4 will not let you arm the vehicle). To disable the safety press and hold the safety switch for 1 second. You can press the safety switch again to enable safety and disarm the vehicle (this can be useful if, for whatever reason, you are unable to disarm the vehicle from your remote control or ground station). :::

Power

You can use a power module or power distribution board to power motors/servos and measure power consumption. The recommended power modules are shown below.

PM02 v3 Power Module

The Power Module (PM02 v3) can be bundled with pix32 v5. It provides regulated power to flight controller and sends battery voltage/current to the flight controller.

Connect the output of the Power Module as shown.

• PM voltage/current port: connect to POWER1 port (or POWER2) using the 6-wire GH cable supplied.
• PM input (XT60 male connector): connect to the LiPo battery (2~12S).
• PM power output (XT60 female connector): wire out to any motor ESCs.

:::note As this power module does not include power distribution wiring, you would normally just connect all the ESCs in parallel to the power module output (the ESC must be appropriate for the supplied voltage level). :::

:::note The 8 pin power (+) rail of MAIN/AUX is not powered by the power module supply to the flight controller. If it will need to be separately powered in order to drive servos for rudders, elevons etc., the power rail needs to be connected to a BEC equipped ESC or a standalone 5V BEC or a 2S LiPo battery. Ensure the voltage of servo you are going to use is appropriate. :::

The power module has the following characteristics/limits:

• Max input voltage: 60V
• Max current sensing: 120A Voltage
• Current measurement configured for SV ADC Switching regulator outputs 5.2V and 3A max
• Weight: 20g
• Package includes:
  • PM02 board
  • 6pin MLX cable (1)
  • 6pin GH cable (1)

:::note See also PM02v3 Power Module Manual (Holybro). :::

Battery Configuration

The battery/power setup must be configured in Power Settings. For either Power Module you will need to configure the Number of Cells.

You will not need to update the voltage divider unless you are using some other power module (e.g. the one from the Pixracer).

Radio Control

A remote control (RC) radio system is required if you want to manually control your vehicle (PX4 does not require a radio system for autonomous flight modes).

You will need to select a compatible transmitter/receiver and then bind them so that they communicate (read the instructions that come with your specific transmitter/receiver).

The instructions below show how to connect the different types of receivers to Pix32 v5 with Baseboard:

• Spektrum/DSM receivers connect to the DSM RC input shown below.

  

• PPM and S.Bus receivers connect to the SBUS_IN/PPM_IN input port (marked as RC IN):

  

• PPM and PWM receivers that have an individual wire for each channel must connect to the PPM RC port via a PPM encoder like this one (PPM-Sum receivers use a single signal wire for all channels).

For more information about selecting a radio system, receiver compatibility, and binding your transmitter/receiver pair, see: Remote Control Transmitters & Receivers.

Telemetry Radios (Optional)

Telemetry radios may be used to communicate and control a vehicle in flight from a ground station (for example, you can direct the UAV to a particular position, or upload a new mission).

The vehicle-based radio should be connected to the TELEM1 port as shown below (if connected to this port, no further configuration is required). The other radio is connected to your ground station computer or mobile device (usually by USB).

SD Card (Optional)

SD cards are most commonly used to log and analyse flight details. A micro SD card should come preinstalled on the pix32 v5, if you have your own micro SD card, insert the card into pix32 v5 as shown below.

:::tip The SanDisk Extreme U3 32GB is highly recommended. :::

Motors

Motors/servos control signals are connected to the I/O PWM OUT (MAIN) and FMU PWM OUT (AUX) ports in the order specified for your vehicle in the Airframe Reference.

The motors must be separately powered.

:::note If your frame is not listed in the airframe reference then use a “generic” airframe of the correct type. :::

Other Peripherals

The wiring and configuration of optional/less common components is covered within the topics for individual peripherals.

Pinouts

Pix32 v5 Pinouts (Holybro)

Configuration

General configuration information is covered in: Autopilot Configuration.

QuadPlane specific configuration is covered here: QuadPlane VTOL Configuration

Further information

• Pix32 v5 Overview (Overview page)
• Pix32 v5 Technical Data Sheet
• Pix32 v5 Pinouts
• Pix32 v5 Base Schematic Diagram
• Pix32 v5 Base Components Layout
• FMUv5 reference design pinout.

quick start durandal - APM, Mission-planner

Durandal Wiring Quick Start

:::warning PX4 does not manufacture this (or any) autopilot. Contact the manufacturer for hardware support or compliance issues. :::

This quick start guide shows how to power the Holybro Durandal^® flight controller and connect its most important peripherals.

Unboxing

Durandal is sold bundled with a number of different combinations of accessories, including power modules: PM02 V3 and PM07, and the Pixhawk 4 GPS/Compass ( u-blox NEO-M8N).

The content of the box with the PM02 V3 power module is shown below (the box also includes a pinout guide and power module instructions).

Wiring Chart Overview

The image below shows how to connect the most important sensors and peripherals (except the motor and servo outputs). We’ll go through each of these in detail in the following sections.

:::tip More information about available ports can be found here: Durandal > Pinouts. :::

Mount and Orient Controller

Durandal should be mounted on the frame positioned as close to your vehicle’s center of gravity as possible, oriented top-side up with the arrow pointing towards the front of the vehicle.

If the controller cannot be mounted in the recommended/default orientation (e.g. due to space constraints) you will need to configure the autopilot software with the orientation that you actually used: Flight Controller Orientation.

:::tip The board has internal vibration-isolation. Do not use vibration-isolation foam to mount the controller (double sided tape is normally sufficient). :::

GPS + Compass + Buzzer + Safety Switch + LED

Durandal is designed to work well with the Pixhawk 4 GPS module, which has an integrated compass, safety switch, buzzer and LED. It connects directly to the GPS port using the 10 pin cable.

The GPS/Compass should be mounted on the frame as far away from other electronics as possible, with the direction marker towards the front of the vehicle (separating the compass from other electronics will reduce interference).

:::note The GPS module’s integrated safety switch is enabled by default (when enabled, PX4 will not let you arm the vehicle). To disable the safety press and hold the safety switch for 1 second. You can press the safety switch again to enable safety and disarm the vehicle (this can be useful if, for whatever reason, you are unable to disarm the vehicle from your remote control or ground station). :::

Power

You can use a power module or power distribution board to power motors/servos and measure power consumption. The recommended power modules are shown below.

PM02 v3 Power Module

The Power Module (PM02 v3) can be bundled with Durandal. It provides regulated power to flight controller and sends battery voltage/current to the flight controller.

Connect the output of the Power Module as shown.

• PM voltage/current port: connect to POWER1 port (or POWER2) using the 6-wire GH cable supplied.
• PM input (XT60 male connector): connect to the LiPo battery (2~12S).
• PM power output (XT60 female connector): wire out to any motor ESCs.

:::tip As this power module does not include power distribution wiring, you would normally just connect all the ESCs in parallel to the power module output (the ESC must be appropriate for the supplied voltage level). :::

:::tip The 8 pin power (+) rail of MAIN/AUX is not powered by the power module supply to the flight controller. If it will need to be separately powered in order to drive servos for rudders, elevons etc., the power rail needs to be connected to a BEC equipped ESC or a standalone 5V BEC or a 2S LiPo battery. Ensure the voltage of servo you are going to use is appropriate. :::

The power module has the following characteristics/limits:

• Max input voltage: 60V
• Max current sensing: 120A Voltage
• Current measurement configured for SV ADC Switching regulator outputs 5.2V and 3A max
• Weight: 20g
• Package includes:
  • PM02 board
  • 6pin MLX cable (1)
  • 6pin GH cable (1)

:::note See also PM02v3 Power Module Manual (Holybro). :::

Pixhawk 4 Power Module (PM07)

The Pixhawk 4 Power Module (PM07) can be bundled/used with Durandal. It acts as both a power module and power distribution board, providing regulated power to flight controller and the ESCs, and sending battery voltage/current to the flight controller.

This is wired up in the same way as described in the Pixhawk 4 Quick Start > Power documentation.

It has the following characteristics/limits:

• PCB Current: total 120A outputs (MAX)
• UBEC 5V output current: 3A
• UBEC input voltage : 7~51v (2~12s LiPo)
• Dimensions: 68508 mm
• Mounting Holes: 45*45mm
• Weight: 36g
• Package includes:
  • PM07 board (1)
  • 80mm XT60 connector wire (1)

:::note See also PM07 Quick Start Guide (Holybro). :::

Battery Configuration

The battery/power setup must be configured in Power Settings. For either Power Module you will need to configure the Number of Cells.

You will not need to update the voltage divider unless you are using some other power module (e.g. the one from the Pixracer).

Radio Control

A remote control (RC) radio system is required if you want to manually control your vehicle (PX4 does not require a radio system for autonomous flight modes).

You will need to select a compatible transmitter/receiver and then bind them so that they communicate (read the instructions that come with your specific transmitter/receiver).

The instructions below show how to connect the different types of receivers to Durandal:

• Spektrum/DSM receivers connect to the DSM RC input.

  

• PPM and S.Bus receivers connect to the SBUS_IN/PPM_IN input port (marked as RC IN, next to the MAIN/AUX inputs).

  

• PPM and PWM receivers that have an individual wire for each channel must connect to the PPM RC port via a PPM encoder like this one (PPM-Sum receivers use a single signal wire for all channels).

For more information about selecting a radio system, receiver compatibility, and binding your transmitter/receiver pair, see: Remote Control Transmitters & Receivers.

Telemetry Radios (Optional)

Telemetry radios may be used to communicate and control a vehicle in flight from a ground station (for example, you can direct the UAV to a particular position, or upload a new mission).

The vehicle-based radio should be connected to the TELEM1 port as shown below using one of the 6-pos connectors (if connected to this port, no further configuration is required). The other radio is connected to your ground station computer or mobile device (usually by USB).

SD Card (Optional)

SD cards are highly recommended as they are needed to log and analyse flight details, to run missions, and to use UAVCAN-bus hardware. Insert an SD card into the Durandal where indicated below.

:::tip For more information see Basic Concepts > SD Cards (Removable Memory). :::

Motors

Motors/servos control signals are connected to the I/O PWM OUT (MAIN OUT) and FMU PWM OUT (AUX) ports in the order specified for your vehicle in the Airframe Reference.

The motors must be separately powered.

:::note If your frame is not listed in the airframe reference then use a “generic” airframe of the correct type. :::

:::tip Durandal has 5 AUX ports, so cannot be used with airframes that map AUX6, AUX7, AUX8 to motors or other critical flight controls. :::

Other Peripherals

The wiring and configuration of optional/less common components is covered within the topics for individual peripherals.

Pinouts

Durandal > Pinouts

PX4 Configuration

First you will need to install PX4 “Master” Firmware onto the controller using QGroundControl.

:::note Durandal support will be in the stable PX4 release that follows PX4 v1.10. :::

Further general configuration information is covered in: Autopilot Configuration.

QuadPlane specific configuration is covered here: QuadPlane VTOL Configuration

Further information

• Durandal Overview
• Durandal Technical Data Sheet (Holybro)
• Durandal Pinouts (Holybro)
• Durandal_MB_H743sch.pdf (Durandal Schematics)
• STM32H743IIK_pinout.pdf (Durandal Pinmap)

quick start cube - APM, Mission-planner

Cube Wiring Quick Start

:::warning PX4 does not manufacture this (or any) autopilot. Contact the manufacturer for hardware support or compliance issues.

Note also that while Cube Black is fully supported by PX4, support for Cube Yellow and Cube Orange is Experimental. :::

This quick start guide shows how to power the Cube^® flight controllers and connect their most important peripherals.

:::tip The instructions apply to all Cube variants, including Cube Black, Cube Yellow and Cube Orange. Further/updated information may be available in the Cube User Manual (Cube Docs). :::

Accessories

Cube comes with most (or all) of the accessories you will need when purchased.

The exception is that some kits do not include a GPS, which will have to be purchased separately (see below).

Wiring Overview

The image below shows how to connect the most important sensors and peripherals. We’ll go through each of these in detail in the following sections.

1. Telemetry System — Allows you to plan/run missions, and control and monitor the vehicle in real time. Typically includes telemetry radios, tablet/PC and ground station software.
2. Buzzer — Provides audio signals that indicate what the UAV is doing
3. Remote Control Receiver System — Connects to a hand-held transmitter that an operator can use to manually fly the vehicle (shown is a PWM receiver with PWM->PPM converter).
4. (Dedicated) Safety switch — Press and hold to lock and unlock motors. Only required if you are not using the recommended GPS with inbuilt safety switch.
5. GPS, Compass, LED, Safety Switch — The recommended GPS module contains GPS, Compass, LED and Safety Switch.
6. Power System — Powers Cube and the motor ESCs. Consists of LiPo battery, power module, and optional battery warning system (audio warning if battery power goes below a predefined level).

:::note The port labeled GPS2 maps to TEL4 in PX4 (i.e. if connecting to the port labeled GPS2, assign the serial port configuration parameter for the connected hardware to TEL4). :::

:::tip More information about available ports can be found here: Cube > Ports. :::

Mount and Orient Controller

Mount the Cube as close as possible to your vehicle’s center of gravity, ideally oriented top-side up and with the arrow pointing towards the front of the vehicle (note the subtle arrow marker on top of the cube)

:::note If the controller cannot be mounted in the recommended/default orientation (e.g. due to space constraints) you will need to configure the autopilot software with the orientation that you actually used: Flight Controller Orientation. :::

The Cube can be mounted using either vibration-damping foam pads (included in the kit) or mounting screws. The mounting screws in the Cube accessories are designed for a 1.8mm thick frameboard. Customized screws are supposed to be M2.5 with thread length inside Cube in range 6mm~7.55mm.

GPS + Compass + Safety Switch + LED

The recommended GPS modules are the Here and Here+, both of which incorporate a GPS module, Compass, Safety Switch and LEDs. The difference between the modules is that Here+ supports centimeter level positioning via RTK. Otherwise they are used/connected in the same way.

:::warning The Here+ has been superseded by the Here3 a UAVCAN RTK-GNSS that incorporate a compass and LEDs (but no safety switch). See UAVCAN for documentation on how it should be connected. :::

The module should be mounted on the frame as far away from other electronics as possible, with the direction marker towards the front of the vehicle (separating the compass from other electronics will reduce interference). It must be connected to the GPS1 port using the supplied 8-pin cable.

The diagram below shows a schematic view of the module and its connections.

:::note The GPS module’s integrated safety switch is enabled by default (when enabled, PX4 will not let you arm the vehicle). To disable the safety press and hold the safety switch for 1 second. You can press the safety switch again to enable safety and disarm the vehicle (this can be useful if, for whatever reason, you are unable to disarm the vehicle from your remote control or ground station). :::

:::tip If you want to use an old-style 6-pin GPS module, the kit comes with a cable that you can use to connect both the GPS and Safety Switch. :::

Safety Switch

The dedicated safety switch that comes with the Cube is only required if you are not using the recommended GPS (which has an inbuilt safety switch).

If you are flying without the GPS you must attach the switch directly to the GPS1 port in order to be able to arm the vehicle and fly (or via a supplied cable if using an old-style 6-pin GPS).

Buzzer

The buzzer plays tones and tunes that provide audible notification of vehicle status (including tones that are helpful for debugging startup issues, and that notify of conditions that might affect safe operation of the vehicle).

The buzzer should be connected to the USB port as shown (no further configuration is required).

Radio Control

A remote control (RC) radio system is required if you want to manually control your vehicle (PX4 does not require a radio system for autonomous flight modes).

You will need to select a compatible transmitter/receiver and then bind them so that they communicate (read the instructions that come with your specific transmitter/receiver).

The instructions below show how to connect the different types of receivers.

PPM-SUM / Futaba S.Bus receivers

Connect the ground(-),power(+),and signal(S) wires to the RC pins using the provided 3-wire servo cable.

Spektrum Satellite Receivers

Spektrum DSM, DSM2, and DSM-X Satellite RC receivers connect to the SPKT/DSM port.

PWM Receivers

The Cube cannot directly connect to PPM or PWM receivers that have an individual wire for each channel. PWM receivers must therefore connect to the RCIN port via a PPM encoder module, which may be purchased from hex.aero or proficnc.com.

Power

Cube is typically powered from a Lithium Ion Polymer (LiPo) Battery via a Power Module (supplied with the kit) that is connected to the POWER1 port. The power module provides reliable supply and voltage/current indication to the board, and may separately supply power to ESCs that are used to drive motors on a multicopter vehicle.

A typical power setup for a Multicopter vehicle is shown below.

:::Note The power (+) rail of MAIN/AUX is not powered by the power module supply to the flight controller. In order to drive servos for rudders, elevons, etc., it will need to be separately powered.

This can be done by connecting the power rail to a BEC equipped ESC, a standalone 5V BEC, or a 2S LiPo battery. Ensure the voltage of servo you are going to use is appropriate! :::

Telemetry System (Optional)

A telemetry system allows you to communicate with, monitor, and control a vehicle in flight from a ground station (for example, you can direct the UAV to a particular position, or upload a new mission).

The communication channel is via Telemetry Radios. The vehicle-based radio should be connected to the TELEM1 port (if connected to this port, no further configuration is required). The other radio is connected to your ground station computer or mobile device (usually via USB).

SD Card (Optional)

SD cards are highly recommended as they are needed to log and analyse flight details, to run missions, and to use UAVCAN-bus hardware. Insert the Micro-SD card into Cube as shown (if not already present).

:::tip For more information see Basic Concepts > SD Cards (Removable Memory). :::

Motors

Motors/servos are connected to the MAIN and AUX ports in the order specified for your vehicle in the Airframe Reference.

:::note This reference lists the output port to motor/servo mapping for all supported air and ground frames (if your frame is not listed in the reference then use a “generic” airframe of the correct type). :::

:::caution The mapping is not consistent across frames (e.g. you can’t rely on the throttle being on the same output for all plane frames). Make sure to use the correct mapping for your vehicle. :::

Other Peripherals

The wiring and configuration of optional/less common components is covered within the topics for individual peripherals.

:::note If connecting peripherals to the port labeled GPS2, assign the PX4 serial port configuration parameter for the hardware to TEL4 (not GPS2). :::

Configuration

Configuration is performed using QGroundContro.

After downloading, installing and running QGroundControl, connect the board to your computer as shown.

Basic/common configuration information is covered in: Autopilot Configuration.

QuadPlane specific configuration is covered here: QuadPlane VTOL Configuration

Bootloader Updates

If you get the [Program PX4IO(../getting_started/tunes.md#program-px4io) warning tone after flashing PX4 firmware, you may need to update the bootloader.

The safety switch can be used to force bootloader updates. To use this feature de-power the Cube, hold down the safety switch, then power the Cube over USB.

Further information

• Cube Black
• Cube Yellow
• Cube Orange
• Cube Docs (Manufacturer):
  • Cube Module Overview
  • Cube User Manual
  • Mini Carrier Board

quick start cuav v5 plus - APM, Mission-planner

CUAV V5+ Wiring Quick Start

:::warning PX4 does not manufacture this (or any) autopilot. Contact the manufacturer for hardware support or compliance issues. :::

This quick start guide shows how to power the CUAV V5+ flight controller and connect its most important peripherals.

Wiring Chart Overview

The image below shows how to connect the most important sensors and peripherals (except the motor and servo outputs). We’ll go through each of these in detail in the following sections.

:::note For more interface information, please read V5+ Manual. :::

:::note If the controller cannot be mounted in the recommended/default orientation (e.g. due to space constraints) you will need to configure the autopilot software with the orientation that you actually used: Flight Controller Orientation. :::

GPS + Compass + Safety Switch + LED

The recommended GPS module is the Neo v2 GPS, which contains GPS, compass, safety switch, buzzer, LED status light.

:::note Other GPS modules may not work (see this compatibility issue)). :::

The GPS/Compass module should be mounted on the frame as far away from other electronics as possible, with the direction marker towards the front of the vehicle (Neo v2 GPS arrow is in the same direction as the flight control arrow). Connect to the flight control GPS interface using a cable.

:::note If you use the NEO V2 PRO GNSS (CAN GPS), please use the cable to connect to the flight control CAN interface. :::

Safety Switch

The dedicated safety switch that comes with the V5+ is only required if you are not using the recommended Neo V2 GPS (which has an inbuilt safety switch).

If you are flying without the GPS you must attach the switch directly to the GPS1 port in order to be able to arm the vehicle and fly (if you use the old 6-pin GPS, please read the definition of the bottom interface to change the line).

Buzzer

If you do not use the recommended GPS, the buzzer may not work.

Radio Control

A remote control (RC) radio system is required if you want to manually control your vehicle (PX4 does not require a radio system for autonomous flight modes). You will need to select a compatible transmitter/receiver and then bind them so that they communicate (read the instructions that come with your specific transmitter/receiver).

The figure below shows how you can access your remote receiver (please find the SBUS cable in the kit).

Spektrum Satellite Receivers

The V5+ has a dedicated DSM cable. If using a Spektrum satellite receiver, this should be connected to the flight controller DSM/SBUS/RSSI interface.

Power

The V5+ kit includes the HV_PM module, which supports 2~14S LiPo batteries. Connect the 6pin connector of the HW_PM module to the flight control Power1 interface.

:::warning The supplied power module is unfused. Power must be turned off while connecting peripherals. :::

:::note The power module is not a power source for peripherals connected to the PWM outputs. If you’re connecting servos/actuators you will need to separately power them using a BEC. :::

Telemetry System (Optional)

A telemetry system allows you to communicate with, monitor, and control a vehicle in flight from a ground station (for example, you can direct the UAV to a particular position, or upload a new mission).

The communication channel is via Telemetry Radios. The vehicle-based radio should be connected to either the TELEM1 or TELEM2 port (if connected to these ports, no further configuration is required). The other radio is connected to your ground station computer or mobile device (usually via USB).

SD Card (Optional)

An SD card is inserted in the factory (you do not need to do anything).

Motors

Motors/servos are connected to the MAIN and AUX ports in the order specified for your vehicle in the Airframes Reference.

Pinouts

Download V5+ pinouts from here.

Further Information

• Airframe build-log using CUAV v5+ on a DJI FlameWheel450
• CUAV V5+ Manual (CUAV)
• CUAV V5+ docs (CUAV)
• FMUv5 reference design pinout (CUAV)
• CUAV Github (CUAV)
• Base board design reference (CUAV)

quick start cuav v5 nano - APM, Mission-planner

CUAV V5 nano Wiring Quick Start

:::warning PX4 does not manufacture this (or any) autopilot. Contact the manufacturer for hardware support or compliance issues. :::

This quick start guide shows how to power the CUAV V5 nano flight controller and connect its most important peripherals.

Wiring Chart Overview

The image below shows how to connect the most important sensors and peripherals (except the motor and servo outputs). We’ll go through each of these in detail in the following sections.

:::note For more interface information, please read V5 nano Manual. :::

:::note If the controller cannot be mounted in the recommended/default orientation (e.g. due to space constraints) you will need to configure the autopilot software with the orientation that you actually used: Flight Controller Orientation. :::

GPS + Compass + Safety Switch + LED

The recommended GPS module is the Neo v2 GPS, which contains GPS, compass, safety switch, buzzer, LED status light.

:::note Other GPS modules may not work (see this compatibility issue). :::

The GPS/Compass module should be mounted on the frame as far away from other electronics as possible, with the direction marker towards the front of the vehicle (Neo GPS arrow is in the same direction as the flight control arrow). Connect to the flight control GPS interface using a cable.

:::note If you use CAN GPS, please use the cable to connect to the flight control CAN interface. :::

Safety Switch

The dedicated safety switch that comes with the V5+ is only required if you are not using the recommended Neo v2 GPS (which has an inbuilt safety switch).

If you are flying without the GPS you must attach the switch directly to the GPS1 port in order to be able to arm the vehicle and fly (If you use the old 6-pin GPS, please read the definition of the bottom interface to change the line).

Buzzer

If you do not use the recommended Neo v2 GPS the buzzer may not work.

Radio Control

A remote control (RC) radio system is required if you want to manually control your vehicle (PX4 does not require a radio system for autonomous flight modes). You will need to select a compatible transmitter/receiver and then bind them so that they communicate (read the instructions that come with your specific transmitter/receiver).

The figure below shows how you can access your remote receiver (please find the S.Bus cable in the kit)

Spektrum Satellite Receivers

The V5 nano has a dedicated DSM cable. If using a Spektrum satellite receiver, this should be connected to the flight controller DSM/SBUS/RSSI interface.

Power

The v5 nano kit includes the HV_PM module, which supports 2~14S LiPo batteries. Connect the 6pin connector of the HW_PM module to the flight control Power interface.

:::warning The supplied power module is unfused. Power must be turned off while connecting peripherals. :::

:::note The power module is not a power source for peripherals connected to the PWM outputs. If you’re connecting servos/actuators you will need to separately power them using a BEC. :::

Telemetry System (Optional)

A telemetry system allows you to communicate with, monitor, and control a vehicle in flight from a ground station (for example, you can direct the UAV to a particular position, or upload a new mission).

The communication channel is via Telemetry Radios. The vehicle-based radio should be connected to the TELEM1 or TELEM2 port (if connected to these ports, no further configuration is required). The other radio is connected to your ground station computer or mobile device (usually via USB).

SD Card (Optional)

An SD card is inserted in the factory (you do not need to do anything).

Motors

Motors/servos are connected to the MAIN ports in the order specified for your vehicle in the Airframes Reference.

Pinouts

Further Information

• Airframe buildlog using CUAV v5 nano on a DJI FlameWheel450
• CUAV V5 nano
• V5 nano manual (CUAV)
• FMUv5 reference design pinout (CUAV)
• CUAV Github (CUAV)

mount and orient controller - APM, Mission-planner

Mounting the Flight Controller

Orientation

Almost all Flight Controllers have a heading mark arrow (shown below). The controller should be placed on the frame top-side up, oriented so that the arrow points towards the front of the vehicle (on all aircraft frames - airplane, multirotor, VTOL, ground vehicles etc.).

:::note If the controller cannot be mounted in the recommended/default orientation (e.g. due to physical constraints) you will need to configure the autopilot software with the orientation that you actually used: Flight Controller Orientation. :::

Vibration Isolation

Flight Control boards with in-built accelerometers or gyros are sensitive to vibrations. Some boards include in-built vibration-isolation, while others come with mounting foam that you can use to isolate the controller from the vehicle.

Vibration damping foam

You should use the mounting strategy recommended in your flight controller documentation.

:::tip Log Analysis using Flight Review > Vibration explains how to test whether vibration levels are acceptable, and Vibration Isolation suggests a number of possible solutions if there is a problem. :::

- APM, Mission-planner

Basic Assembly

A typical autopilot “minimal” system running PX4 consists of a flight controller connected to a power system, GPS, external compass (optional), radio control system (optional) and/or telemetry radio system (optional).

This section contains topics that explain how to assemble such a system for different flight controllers.

:::tip Quickstart guides are only provided for a few controllers. Other controllers will have similar connections. Additional information may be available in flight controllers pages or in manufacturer documentation. :::

• See Peripherals for information about connecting sensors and other peripherals (e.g. airspeed sensor for planes).
• See Airframe Builds for complete assembly examples on different vehicle frames.
• See Multicopter Racer Setup for racer-specific assembly and configuration information.

airframe reference - APM, Mission-planner

Airframes Reference

:::note This list is auto-generated from the source code using the build command: make airframe_metadata. :::

This page lists all supported airframes and types including the motor assignment and numbering. The motors in green rotate clockwise, the ones in blue counterclockwise.

AUX channels may not be present on some flight controllers. If present, PWM AUX channels are commonly labelled AUX OUT.

Airship

Airship

Common Outputs
MAIN1: starboard thruster MAIN2: port thruster MAIN3: thrust tilt MAIN4: tail thruster

Autogyro

Autogyro

Common Outputs
AUX1: feed-through of RC AUX1 channel for prerotator (optional) AUX2: feed-through of RC AUX2 channel for release device (optional)

Balloon

Balloon

Copter

Coaxial Helicopter

Common Outputs
MAIN1: Left swashplate servomotor, pitch axis MAIN2: Right swashplate servomotor, roll axis MAIN3: Upper rotor (CCW) MAIN4: Lower rotor (CW)

Dodecarotor cox

Common Outputs
MAIN1: motor 1 MAIN2: motor 2 MAIN3: motor 3 MAIN4: motor 4 MAIN5: motor 5 MAIN6: motor 6 AUX1: motor 7 AUX2: motor 8 AUX3: motor 9 AUX4: motor 10 AUX5: motor 11 AUX6: motor 12

Helicopter

Common Outputs
MAIN1: main motor MAIN2: front swashplate servo MAIN3: right swashplate servo MAIN4: left swashplate servo MAIN5: tail-rotor servo

Hexarotor +

Common Outputs
MAIN1: motor1 MAIN2: motor2 MAIN3: motor3 MAIN4: motor4 MAIN5: motor5 MAIN6: motor6 AUX1: feed-through of RC AUX1 channel AUX2: feed-through of RC AUX2 channel AUX3: feed-through of RC AUX3 channel

Hexarotor Coaxial

Common Outputs

MAIN1: front right top, CW; angle:60; direction:CW MAIN2: front right bottom, CCW; angle:60; direction:CCW MAIN3: back top, CW; angle:180; direction:CW MAIN4: back bottom, CCW; angle:180; direction:CCW MAIN5: front left top, CW; angle:-60; direction:CW MAIN6: front left bottom, CCW;angle:-60; direction:CCW AUX1: feed-through of RC AUX1 channel AUX2: feed-through of RC AUX2 channel AUX3: feed-through of RC AUX3 channel

Hexarotor x

Common Outputs
MAIN1: motor 1 MAIN2: motor 2 MAIN3: motor 3 MAIN4: motor 4 MAIN5: motor 5 MAIN6: motor 6

Octo Coax Wide

Common Outputs
MAIN1: motor 1 MAIN2: motor 2 MAIN3: motor 3 MAIN4: motor 4 MAIN5: motor 5 MAIN6: motor 6 MAIN7: motor 7 MAIN8: motor 8

Octorotor +

Common Outputs
MAIN1: motor 1 MAIN2: motor 2 MAIN3: motor 3 MAIN4: motor 4 MAIN5: motor 5 MAIN6: motor 6 MAIN7: motor 7 MAIN8: motor 8 AUX1: feed-through of RC AUX1 channel AUX2: feed-through of RC AUX2 channel AUX3: feed-through of RC AUX3 channel

Octorotor Coaxial

Common Outputs
MAIN1: motor 1 MAIN2: motor 2 MAIN3: motor 3 MAIN4: motor 4 MAIN5: motor 5 MAIN6: motor 6 MAIN7: motor 7 MAIN8: motor 8

Octorotor x

Common Outputs
MAIN1: motor 1 MAIN2: motor 2 MAIN3: motor 3 MAIN4: motor 4 MAIN5: motor 5 MAIN6: motor 6 MAIN7: motor 7 MAIN8: motor 8 AUX1: feed-through of RC AUX1 channel AUX2: feed-through of RC AUX2 channel AUX3: feed-through of RC AUX3 channel

Quadrotor +

Common Outputs
MAIN1: motor 1 MAIN2: motor 2 MAIN3: motor 3 MAIN4: motor 4 MAIN5: feed-through of RC AUX1 channel MAIN6: feed-through of RC AUX2 channel AUX1: feed-through of RC AUX1 channel AUX2: feed-through of RC AUX2 channel AUX3: feed-through of RC AUX3 channel AUX4: feed-through of RC FLAPS channel

Quadrotor H

Quadrotor Wide

Common Outputs
AUX1: feed-through of RC AUX1 channel AUX2: feed-through of RC AUX2 channel AUX3: feed-through of RC AUX3 channel AUX4: feed-through of RC FLAPS channel

Quadrotor asymmetric

Common Outputs
MAIN1: motor1 (front right: CCW) MAIN2: motor2 (back left: CCW) MAIN3: motor3 (front left: CW) MAIN4: motor4 (back right: CW) MAIN5: feed-through of RC AUX1 channel MAIN6: feed-through of RC AUX2 channel

Quadrotor x

Common Outputs
AUX1: feed-through of RC AUX1 channel AUX2: feed-through of RC AUX2 channel AUX3: feed-through of RC AUX3 channel AUX4: feed-through of RC FLAPS channel

Simulation (Copter)

Tilt-Quad

Common Outputs
MAIN1: motor 1 MAIN2: motor 2 MAIN3: motor 3 MAIN4: motor 4 AUX1: Outer servo motor for rotor 2 arm AUX2: Outer servo motor for rotor 4 arm AUX3: Inner servo motor for rotor 2 arm AUX4: Inner servo motor for rotor 4 arm

Tricopter Y+

Common Outputs
MAIN1: motor 1 MAIN2: motor 2 MAIN3: motor 3 MAIN4: yaw servo

Tricopter Y-

Common Outputs
MAIN1: motor 1 MAIN2: motor 2 MAIN3: motor 3 MAIN4: yaw servo

Plane

Flying Wing

Common Outputs
AUX1: feed-through of RC AUX1 channel AUX2: feed-through of RC AUX2 channel AUX3: feed-through of RC AUX3 channel

Plane A-Tail

Common Outputs
MAIN1: aileron right MAIN2: aileron left MAIN3: v-tail right MAIN4: v-tail left MAIN5: throttle MAIN6: wheel MAIN7: flaps right MAIN8: flaps left AUX1: feed-through of RC AUX1 channel AUX2: feed-through of RC AUX2 channel AUX3: feed-through of RC AUX3 channel

Plane V-Tail

Common Outputs
MAIN1: aileron right MAIN2: aileron left MAIN3: v-tail right MAIN4: v-tail left MAIN5: throttle MAIN6: wheel MAIN7: flaps right MAIN8: flaps left AUX1: feed-through of RC AUX1 channel AUX2: feed-through of RC AUX2 channel AUX3: feed-through of RC AUX3 channel

Simulation (Plane)

Common Outputs
MAIN1: aileron MAIN2: elevator MAIN3: rudder MAIN4: throttle MAIN5: flaps MAIN6: gear

Standard Plane

Common Outputs
AUX1: feed-through of RC AUX1 channel AUX2: feed-through of RC AUX2 channel AUX3: feed-through of RC AUX3 channel

Rover

Rover

Underwater Robot

Underwater Robot

Vectored 6 DOF UUV

Common Outputs

MAIN1: motor 1 CCW, bow starboard horizontal, , propeller CCW MAIN2: motor 2 CCW, bow port horizontal, propeller CCW MAIN3: motor 3 CCW, stern starboard horizontal, propeller CW MAIN4: motor 4 CCW, stern port horizontal, propeller CW MAIN5: motor 5 CCW, bow starboard vertical, propeller CCW MAIN6: motor 6 CCW, bow port vertical, propeller CW MAIN7: motor 7 CCW, stern starboard vertical, propeller CW MAIN8: motor 8 CCW, stern port vertical, propeller CCW

VTOL

Standard VTOL

VTOL Duo Tailsitter

Common Outputs
MAIN1: motor right MAIN2: motor left MAIN5: elevon right MAIN6: elevon left

VTOL Octoplane

Common Outputs
MAIN1: motor 1 MAIN2: motor 2 MAIN3: motor 3 MAIN4: motor 4 MAIN5: motor 5 MAIN6: motor 6 MAIN7: motor 7 MAIN8: motor 8 AUX1: Aileron 1 AUX2: Aileron 2 AUX3: Elevator AUX4: Rudder AUX5: Throttle

VTOL Quad Tailsitter

Common Outputs
MAIN1: motor 1 MAIN2: motor 2 MAIN3: motor 4 MAIN4: motor 5 MAIN5: elevon left MAIN6: elevon right MAIN7: canard surface MAIN8: rudder

VTOL Tiltrotor

airframe readme - APM, Mission-planner

Airframe/Vehicle Builds

PX4 supports numerous types of vehicles, including different configurations of multicopters, planes, VTOL vehicles, ground vehicles, etc. The complete set of supported configurations can be seen in the Airframes Reference.

This section contains instructions for how to install several different flight controllers on a number of common frames.

traffic_avoidance_utm - APM, Mission-planner

Air Traffic Avoidance: UAS Traffic Management (UTM)

PX4 can use MAVLink UTM_GLOBAL_POSITION messages to support simple air traffic avoidance in missions. If a potential collision is detected, PX4 can warn, immediately land, or return (depending on the value of NAV_TRAFF_AVOID).

:::note This implementation is exactly the same as for ADS-B traffic avoidance (except for the source of other-vehicle data). For more information see implementation below. :::

Configure Traffic Avoidance

Configure the trigger distance and action when there is a potential collision using the parameters below:

Implementation

PX4 listens for UTM_GLOBAL_POSITION MAVLink messages during missions. When a valid message is received, its validity flags, position and heading are mapped into the same transponder_report UORB topic used for ADS-B traffic avoidance.

The implementation is otherwise exactly as described in: ADS-B traffic avoidance > Implementation.

:::note UTM_GLOBAL_POSITION contains additional fields that are not provided by an ADSB transponder (see ADSB_VEHICLE). The current implementation simply drops the additional fields (including information about the vehicle’s planned next waypoint). :::

Further Information

• ADS-B Traffic Avoidance

traffic avoidance adsb - APM, Mission-planner

Air Traffic Avoidance: ADS-B/FLARM

PX4 can use ADS-B or FLARM transponders to support simple air traffic avoidance in missions. If a potential collision is detected, PX4 can warn, immediately land, or return (depending on the value of NAV_TRAFF_AVOID).

Supported Hardware

PX4 traffic avoidance works with ADS-B or FLARM products that supply transponder data using the MAVLink ADSB_VEHICLE message.

It has been tested with the following devices:

• PingRX ADS-B Receiver (uAvionix)
• FLARM

Hardware Setup

Either device can be connected to any free/unused serial port on the flight controller. Most commonly it they are connected to TELEM2 (if this is not being use for some other purpose).

PingRX

The PingRX MAVLink port uses a JST ZHR-4 mating connector with pinout as shown below.

The PingRX comes with connector cable that can be attached directly to the TELEM2 port (DF13-6P) on an mRo Pixhawk. For other ports or boards, you will need to obtain your own cable.

FLARM

FLARM has an on-board DF-13 6 Pin connector that has an identical pinout to the mRo Pixhawk.

:::note The TX and RX on the flight controller must be connected to the RX and TX on the FLARM, respectively. :::

official

Software Configuration

Port Configuration

Flarm/PingRX are configured in the same way as any other MAVLink Peripheral. The only specific setup is that the port baud rate must be set to 57600 and the a low-bandwidth profile (MAV_X_MODE).

Assuming you have connected the device to the TELEM2 port, set the parameters as shown:

• MAV_1_CONFIG = TELEM 2
• MAV_1_MODE = Normal
• MAV_1_RATE = 0 (default sending rate for port).
• MAV_1_FORWARD = Enabled

Then reboot the vehicle.

You will now find a new parameter called SER_TEL2_BAUD, which must be set to 57600.

Configure Traffic Avoidance

Configure the action when there is a potential collision using the parameter below:

Implementation

PX4 listens for valid transponder reports during missions.

If a valid transponder report is received, PX4 first uses the transponder position and heading information to estimate whether the vehicles will share a similar altitude before they pass each other. If they may then PX4 it estimates how the closest distance between the path to the next waypoint and the other vehicles predicted path. If the crossing point is less than the configured distance for altitude and path, the Traffic Avoidance Failsafe action is started, and the vehicle will either warn, land, or return. The detection distance can be configured separately for manned and unmanned aviation.

The code can be found in Navigator::check_traffic (/src/modules/navigator/navigator_main.cpp).

PX4 will also forward the transponder data to a GCS if this has been configured for the MAVLink instance (this is recommended). The last 10 Digits of the GUID is displayed as Drone identification.

Further Information

• MAVLink Peripherals
• Serial Port Configuration

- APM, Mission-planner

satcom_roadblock - APM, Mission-planner

Iridium/RockBlock Satellite Communication System

A satellite communication system can be used to provide long range high latency link between a ground station and a vehicle.

This topic describes how to set up a system that uses RockBlock as the service provider for the Iridium SBD Satellite Communication System. Given good signal quality, users can expect a latency between 10 to 15 seconds.

Overview

The following components are needed for the satellite communication link:

• A RockBlock 9603 module connected to a Pixhawk flashed with the PX4 Autopilot.
• A message relay server running Ubuntu Linux.
• A ground station computer running QGroundControl on Ubuntu Linux

The full system architecture is shown below:

:::note The setup was tested with the current release of QGroundControl running on Ubuntu 14.04 and 16.04.

• It may be possible to run the system on other ground stations and operating systems, but this has not been tested (and is not guaranteed to work).
• The RockBlock MK2 module can also be used. The RockBlock 9603 module is recommended because it is smaller and lighter, while providing the same functionality. :::

Costs

The UK link running cost consists of a line rental and per message cost:

• Each module needs to be activated which costs £10.00 per month
• Each message transmitted over the system costs one credit per 50 bytes. Bundles of credits can be bought from RockBlock for £0.04-£0.11 per credit, depending on the bundle size.

Refer to the RockBlock Documentation for a detailed explanation of the modules, running costs and RockBlock in general.

Vehicle Setup

Wiring

Connect the RockBlock module to a serial port of the Pixhawk. Due to the power requirements of the module it can only be powered over a high-power serial port as a maximum of 0.5 A at 5 V are required. If none is available/free then another power source which has the same ground level as the Pixhawk and can provide required power has to be setup. The details of the connectors and the power requirements can be found in the RockBlock documentation.

Module

The module can either use the internal antenna or an external one connected to the SMA connector. To switch between the two antennas modes the position of a small RF link cable needs to changed. If an external antenna is used always make sure that the antenna is connected to the module before powering it up to avoid damage to the module.

The default baud rate of the module is 19200. However, the PX4 iridiumsbd driver requires a baud rate of 115200 so it needs to be changed using the AT commands.

1. Connect to the module with using a 19200/8-N-1 setting and check if the communication is working using the command: AT. The response should be: OK.
2. Change the baud rate:

   AT+IPR=9
   

3. Reconnect to the model now with a 115200/8-N-1 setting and save the configuration using:

   AT&W0
   

The module is now ready to be used with PX4.

Software

Configure the serial port on which the RockBlock module will run using ISBD_CONFIG. There is no need to set the baud rate for the port, as this is configured by the driver.

:::note If the configuration parameter is not available in QGroundControl then you may need to add the driver to the firmware:

drivers/telemetry/iridiumsbd

:::

RockBlock Setup

When buying the first module on RockBlock an user account needs to be created in a first step.

Log in to the account and register the RockBlock module under the My RockBLOCKs. Activate the line rental for the module and make sure that enough credits for the expected flight duration are available on the account. When using the default settings one message per minute is sent from the vehicle to the ground station.

Set up a delivery group for the message relay server and add the module to that delivery group:

Relay Server Setup

The relay server should be run on either Ubuntu 16.04 or 14.04 OS.

1. The server working as a message relay should have a static IP address and two publicly accessible, open, TCP ports:

   • 5672 for the RabbitMQ message broker (can be changed in the rabbitmq settings)
   • 45679 for the HTTP POST interface (can be changed in the relay.cfg file)
2. Install the required python modules:

   sudo pip install pika tornado future
   

3. Install the rabbitmq message broker:

   sudo apt install rabbitmq-server
   

4. Configure the broker’s credentials (change PWD to your preferred password):

   sudo rabbitmqctl add_user iridiumsbd PWD
   sudo rabbitmqctl set_permissions iridiumsbd ".*" ".*" ".*"
   

5. Clone the SatComInfrastructure repository:

   git clone https://github.com/acfloria/SatComInfrastructure.git
   

6. Go to the location of the SatComInfrastructure repo and configure the broker’s queues:

   ./setup_rabbit.py localhost iridiumsbd PWD
   

7. Verify the setup:

   sudo rabbitmqctl list_queues
   

   This should give you a list of 4 queues: MO, MO_LOG, MT, MT_LOG

8. Edit the relay.cfg configuration file to reflect your settings.
9. Start the relay script in the detached mode:

   screen -dm bash -c 'cd SatcomInfrastructure/; ./relay.py
   

Other instructions include:

• Detach from the screen:

  ctrl+a d
  

• Kill execution of the script:

  ctrl+a :quit
  

• Reattach to the screen::

  screen -dr
  

Ground Station Computer

To setup the ground station:

1. Install the required python modules:

   sudo pip install pika tornado future
   

2. Clone the SatComInfrastructure repository:

   git clone https://github.com/acfloria/SatComInfrastructure.git
   

3. Edit the udp2rabbit.cfg configuration file to reflect your settings.
4. Install QGroundControl (daily build).

5. Add a UDP connection in QGC with the parameters:

   • Listening port: 10000
   • Target hosts: 127.0.0.1:10001
   • High Latency: checked

   

Verification

1. Open a terminal on the ground station computer and change to the location of the SatComInfrastructure repository. Then start the udp2rabbit.py script:

   ./udp2rabbit.py
   

2. Send a test message from RockBlock Account to the created delivery group in the Test Delivery Groups tab.

If in the terminal where the udp2rabbit.py script is running within a couple of seconds the acknowledge for a message can be observed, then the RockBlock delivery group, the relay server and the udp2rabbit script are set up correctly:

Running the System

1. Start QGroundControl. Manually connect the high latency link first, then the regular telemetry link:

   

2. Open a terminal on the ground station computer and change to the location of the SatComInfrastructure repository. Then start the udp2rabbit.py script:

   ./udp2rabbit.py
   

3. Power up the vehicle.

4. Wait until the first HIGH_LATENCY2 message is received on QGC. This can be checked either using the MAVLink Inspector widget or on the toolbar with the LinkIndicator. If more than one link is connected to the active vehicle the LinkIndicator shows all of them by clicking on the name of the shown link:

   

   The link indicator always shows the name of the priority link.

5. The satellite communication system is now ready to use. The priority link, which is the link over which commands are send, is determined the following ways:
   • If no link is commanded by the user a regular radio telemetry link is preferred over the high latency link.
   • The autopilot and QGC will fall back from the regular radio telemetry to the high latency link if the vehicle is armed and the radio telemetry link is lost (no MAVLink messages received for a certain time). As soon as the radio telemetry link is regained QGC and the autopilot will switch back to it.

   • The user can select a priority link over the LinkIndicator on the toolbar. This link is kept as the priority link as long as this link is active or the user selects another priority link:

     

Troubleshooting

• Satellite communication messages from the airplane are received but no commands can be transmitted (the vehicle does not react)
  • Check the settings of the relay server and make sure that they are correct, especially the IMEI.
• No satellite communication messages from the airplane arrive on the ground station:
  • Check using the system console if the iridiumsbd driver started and if it did that a signal from any satellite is received by the module:

    iridiumsbd status
    

  • Make sure using the verification steps from above that the relay server, the delivery group and the udp2rabbit.py script are set up correctly.
  • Check if the link is connected and that its settings are correct.
• The IridiumSBD driver does not start:
  • Reboot the vehicle. If that helps increase the sleep time in the extras.txt before the driver is started. If that does not help make sure that the Pixhawk and the module have the same ground level. Confirm also that the baudrate of the module is set to 115200.
• A first message is received on the ground but as soon as the vehicle is flying no message can be transmitted or the latency is significantly larger (in the order of minutes)
  • Check the signal quality after the flight. If it is decreasing during the flight and you are using the internal antenna consider using an external antenna. If you are already using the external antenna try moving the antenna as far away as possible from any electronics or anything which might disturb the signal. Also make sure that the antenna is not damaged.

rtk-gps - APM, Mission-planner

RTK GPS

Real Time Kinematic (RTK) GNSS/GPS systems provide centimeter-level accuracy, allowing PX4 to be used in applications like precision surveying (where pinpoint accuracy is essential). This feature requires QGroundControl running on a laptop/PC and a vehicle with a WiFi or Telemetry radio link to the ground station laptop.

In addition, some RTK setups can provide heading from GPS, which can be used as an alternative to the compass.

Information about supported devices and setup can be found in the section: Peripheral Hardware > RTK GPS.

precision landing - APM, Mission-planner

Precision Landing

PX4 supports precision landing for multicopters on either stationary or moving targets. The target may be provided by an onboard IR sensor and a landing beacon, or by an offboard positioning system.

Precision landing can be started/initiated as part of a mission, in a Return mode landing, or by entering the Precision Land flight mode.

:::note Precision landing is only possible with a valid global position (due to a limitation in the current implementation of the position controller). :::

Overview

Land Modes

A precision landing can be configured to either be “required” or “opportunistic”. The choice of mode affects how a precision landing is performed.

Required Mode

In Required Mode the vehicle will search for a target if none is visible when landing is initiated. The vehicle will perform a precision landing if a target is located.

The search procedure consists of climbing to the search altitude (PLD_SRCH_ALT). If the target is still not visible at the search altitude and after a search timeout (PLD_SRCH_TOUT), a normal landing is initiated at the current position.

:::note If using an offboard positioning system PX4 assumes that the target is visible when it is recieving MAVLink LANDING_TARGET messages. :::

Opportunistic Mode

In Opportunistic Mode the vehicle will use precision landing if (and only if) the target is visible when landing is initiated. If it is not visible the vehicle immediately performs a normal landing at the current position.

Landing Phases

A precision landing has three phases:

1. Horizontal approach: The vehicle approaches the target horizontally while keeping its current altitude. Once the position of the target relative to the vehicle is below a threshold (PLD_HACC_RAD), the next phase is entered. If the target is lost during this phase (not visible for longer than PLD_BTOUT), a search procedure is initiated (during a required precision landing) or the vehicle does a normal landing (during an opportunistic precision landing).

2. Descent over target: The vehicle descends, while remaining centered over the target. If the target is lost during this phase (not visible for longer than PLD_BTOUT), a search procedure is initiated (during a required precision landing) or the vehicle does a normal landing (during an opportunistic precision landing).

3. Final approach: When the vehicle is close to the ground (closer than PLD_FAPPR_ALT), it descends while remaining centered over the target. If the target is lost during this phase, the descent is continued independent of the kind of precision landing.

Search procedures are initiated in the first and second steps, and will run at most PLD_MAX_SRCH times. Landing Phases Flow Diagram

A flow diagram showing the phases can be found in landing phases flow Diagram below.

Initiating a Precision Landing

Precision landing can be used in missions, during the landing phase in Return mode, or by entering the Precision Land mode.

Mission Precision Landing

Precision landing can be initiated as part of a mission using MAV_CMD_NAV_LAND with param2 set appropriately:

• 0: Normal landing without using the target.
• 1: Opportunistic precision landing.
• 2: Required precision landing.

Return Mode Precision Landing

Precision landing can be used in the Return mode landing phase.

This is enabled using the parameter RTL_PLD_MD, which takes the following values:

• 0: Precision landing disabled (land as normal).
• 1: Opportunistic precision landing.
• 2: Required precision landing.

Precision Landing Flight Mode

Precision landing can be enabled by switching to the Precision Landing flight mode.

You can verify this using the QGroundControl MAVLink Console to enter the following command:

commander mode auto:precland

:::note When switching to the mode in this way, the precision landing is always “required”; there is no way to specify the type of landing. :::

:::note At time of writing is no convenient way to directly invoke precision landing (other than commanding return mode):

• QGroundControl does not provide it as a UI option.
• MAV_CMD_NAV_LAND only works in missions.
• MAV_CMD_SET_MODE should work, but you will need to determine the appropriate base and custom modes used by PX4 to represent the precision landing mode. :::

Hardware Setup

IR Sensor/Beacon Setup

The IR sensor/landing beacon solution requires an IR-LOCK Sensor and downward facing distance sensor connected to the flight controller, and an IR beacon as a target (e.g. IR-LOCK MarkOne). This enables landing with a precision of roughly 10 cm (GPS precision, by contrast, may be as large as several meters).

Install the IR-LOCK sensor by following the official guide. Ensure that the sensor’s x axis is aligned with the vehicle’s y axis and the sensor’s y axis aligned with the vehicle’s -x direction (this is the case if the camera is pitched down 90 degrees from facing forward).

Install a range/distance sensor (the LidarLite v3 has been found to work well).

:::note Many infrared based range sensors do not perform well in the presence of the IR-LOCK beacon. Refer to the IR-LOCK guide for other compatible sensors. :::

Offboard Positioning

The offboard solution requires a positioning system that implements the MAVLink Landing Target Protocol. This can use any positioning mechanism to determine the landing target, for example computer vision and a visual marker.

The system must publish the coordinates of the target in the LANDING_TARGET message. Note that PX4 requires LANDING_TARGET.frame to be MAV_FRAME_LOCAL_NED and only populates the fields x, y, and z. The origin of the local NED frame [0,0] is the home position (you can map this home position to global coordinates using GPS_GLOBAL_ORIGIN).

PX4 does not explicitly require a distance sensor or other sensors, but will perform better if it can more precisely determine its own position.

Firmware Configuration

Precision landing requires the modules irlock and landing_target_estimator, which are not included in the PX4 firmware by default. They can be included by adding (or uncommenting) the following lines in the relevant configuration file for your flight controller (e.g. PX4-Autopilot/boards/px4/fmu-v5/default.cmake):

drivers/irlock
modules/landing_target_estimator

The two modules should also be started on system boot. For instructions see: customizing the system startup.

PX4 Configuration (Parameters)

LTEST_MODE determines if the target is assumed to be stationary or moving. If LTEST_MODE is set to moving (e.g. it is installed on a vehicle on which the multicopter is to land), target measurements are only used to generate position setpoints in the precision landing controller. If LTEST_MODE is set to stationary, the target measurements are also used by the vehicle position estimator (EKF2 or LPE).

Other relevant parameters are listed in the parameter reference under Landing_target estimator and Precision land parameters. Some of the most useful ones are listed below.

IR Beacon Scaling

Measurement scaling may be necessary due to lens distortions of the IR-LOCK sensor.

LTEST_SCALE_X and LTEST_SCALE_Y can be used to scale beacon measurements before they are used to estimate the beacon’s position and velocity relative to the vehicle. Note that LTEST_SCALE_X and LTEST_SCALE_Y are considered in the sensor frame, not the vehicle frame.

To calibrate these scale parameters, set LTEST_MODE to moving, fly your multicopter above the beacon and perform forward-backward and left-right motions with the vehicle, while logging landing_target_pose and vehicle_local_position. Then, compare landing_target_pose.vx_rel and landing_target_pose.vy_rel to vehicle_local_position.vx and vehicle_local_position.vy, respectively (both measurements are in NED frame). If the estimated beacon velocities are consistently smaller or larger than the vehicle velocities, adjust the scale parameters to compensate.

If you observe slow sideways oscillations of the vehicle while doing a precision landing with LTEST_MODE set to stationary, the beacon measurements are likely scaled too high and you should reduce the scale parameter in the relevant direction.

Simulation

Precision landing with the IR-LOCK sensor and beacon can be simulated in SITL Gazebo.

To start the simulation with the world that contains a IR-LOCK beacon and a vehicle with a range sensor and IR-LOCK camera, run:

make px4_sitl gazebo_iris_irlock

You can change the location of the beacon either by moving it in the Gazebo GUI or by changing its location in the Gazebo world.

Operating Principles

Landing Target Estimator

The landing_target_estimator takes measurements from the irlock driver as well as the estimated terrain height to estimate the beacon’s position relative to the vehicle.

The measurements in irlock_report contain the tangent of the angles from the image center to the beacon. In other words, the measurements are the x and y components of the vector pointing towards the beacon, where the z component has length “1”. This means that scaling the measurement by the distance from the camera to the beacon results in the vector from the camera to the beacon. This relative position is then rotated into the north-aligned, level body frame using the vehicle’s attitude estimate. Both x and y components of the relative position measurement are filtered in separate Kalman Filters, which act as simple low-pass filters that also produce a velocity estimate and allow for outlier rejection.

The landing_target_estimator publishes the estimated relative position and velocity whenever a new irlock_report is fused into the estimate. Nothing is published if the beacon is not seen or beacon measurements are rejected. The landing target estimate is published in the landing_target_pose uORB message.

Enhanced Vehicle Position Estimation

If the target is specified to be stationary using the parameter LTEST_MODE, the vehicle’s position/velocity estimate can be improved with the help of the target measurements. This is done by fusing the target’s velocity as a measurement of the negative velocity of the vehicle.

Landing Phases Flow Diagram

This image shows the landing phases as a flow diagram.

readme, advanced features - APM, Mission-planner

Advanced Features

This section contains topics related to some of the more advanced features of the PX4 autopilot:

• Air Traffic Avoidance: ADS-B/FLARM
• Air Traffic Avoidance: UTM
• Computer Vision
  • Obstacle Avoidance (needs companion computer)
  • Safe Landing (needs companion computer)
  • Collision Prevention (can use companion computer or sensors on flight controller)
  • Path Planning Interface (Developer Interface)
  • Motion Capture (MoCap)
  • Visual Inertial Odometry (VIO)
• Iridium/RockBlock Satellite Communication System
• Precision Landing
• RTK GPS

tuning_the_ecl_ekf - APM, Mission-planner

Using the ECL EKF

This tutorial answers common questions about use of the ECL EKF algorithm.

:::tip The PX4 State Estimation Overview video from the PX4 Developer Summit 2019 (Dr. Paul Riseborough) provides an overview of the estimator, and additionally describes both the major changes from 2018/2019, and the expected improvements through 2020. :::

What is the ECL EKF?

The Estimation and Control Library (ECL) uses an Extended Kalman Filter (EKF) algorithm to process sensor measurements and provide an estimate of the following states:

• Quaternion defining the rotation from North, East, Down local earth frame to X, Y, Z body frame
• Velocity at the IMU - North, East, Down (m/s)
• Position at the IMU - North, East, Down (m)
• IMU delta angle bias estimates - X, Y, Z (rad)
• IMU delta velocity bias estimates - X, Y, Z (m/s)
• Earth Magnetic field components - North, East, Down (gauss)
• Vehicle body frame magnetic field bias - X, Y, Z (gauss)
• Wind velocity - North, East (m/s)

The EKF runs on a delayed ‘fusion time horizon’ to allow for different time delays on each measurement relative to the IMU. Data for each sensor is FIFO buffered and retrieved from the buffer by the EKF to be used at the correct time. The delay compensation for each sensor is controlled by the EKF2_*_DELAY parameters.

A complementary filter is used to propagate the states forward from the ‘fusion time horizon’ to current time using the buffered IMU data. The time constant for this filter is controlled by the EKF2_TAU_VEL and EKF2_TAU_POS parameters.

:::note The ‘fusion time horizon’ delay and length of the buffers is determined by the largest of the EKF2_*_DELAY parameters. If a sensor is not being used, it is recommended to set its time delay to zero. Reducing the ‘fusion time horizon’ delay reduces errors in the complementary filter used to propagate states forward to current time. :::

The position and velocity states are adjusted to account for the offset between the IMU and the body frame before they are output to the control loops. The position of the IMU relative to the body frame is set by the EKF2_IMU_POS_X,Y,Z parameters.

The EKF uses the IMU data for state prediction only. IMU data is not used as an observation in the EKF derivation. The algebraic equations for the covariance prediction, state update and covariance update were derived using the Matlab symbolic toolbox and can be found here: Matlab Symbolic Derivation.

Running a Single EKF Instance

The default behaviour is to run a single instance of the EKF. In this case sensor selection and failover is performed before data is received by the EKF. This provides protection against a limited number of sensor faults, such as loss of data, but does not protect against the sensor providing inaccurate data that exceeds the ability of the EKF and control loops to compensate.

The parameter settings for running a single EKF instance are:

• EKF2_MULTI_IMU = 0
• EKF2_MULTI_MAG = 0
• SENS_IMU_MODE = 1
• SENS_MAG_MODE = 1

Running Multiple EKF Instances

Depending on the number of IMUs and magnetometers and the autopilot’s CPU capacity, multiple instances of the EKF can be run. This provides protection against a wider range of sensor errors and is achieved by each EKF instance using a different sensor combination. By comparing the internal consistency of each EKF instance, the EKF selector is able to determine the EKF and sensor combination with the best data consistency. This enables faults such as sudden changes in IMU bias, saturation or stuck data to be detected and isolated.

The total number of EKF instances is the product of the number of IMU’s and number of magnetometers selected by EKF2_MULTI_IMU and EKF2_MULTI_MAG and is given by the following formula:

N_instances = MAX(EKF2_MULTI_IMU , 1) x MAX(EKF2_MULTI_MAG , 1)

For example an autopilot with 2 IMUs and 2 magnetometers could run with EKF2_MULTI_IMU = 2 and EKF2_MULTI_MAG = 2 for a total of 4 EKF instances where each instance uses the following combination of sensors:

• EKF instance 1 : IMU 1, magnetometer 1
• EKF instance 2 : IMU 1, magnetometer 2
• EKF instance 3 : IMU 2, magnetometer 1
• EKF instance 4 : IMU 2, magnetometer 2

The maximum number of IMU or magnetometer sensors that can be handled is 4 of each for a theoretical maximum of 4 x 4 = 16 EKF instances. In practice this is limited by available computing resources. During development of this feature, testing with STM32F7 CPU based HW demonstrated 4 EKF instances with acceptable processing load and memory utilisation margin.

:::warning Ground based testing to check CPU and memory utilisation should be performed before flying. :::

If EKF2_MULTI_IMU >= 3, then the failover time for large rate gyro errors is further reduced because the EKF selector is able to apply a median select strategy for faster isolation of the faulty IMU.

The setup for multiple EKF instances is controlled by the following parameters:

• SENS_IMU_MODE: Set to 0 if running multiple EKF instances with IMU sensor diversity, ie EKF2_MULTI_IMU > 1.

  When set to 1 (default for single EKF operation) the sensor module selects IMU data used by the EKF. This provides protection against loss of data from the sensor but does not protect against bad sensor data. When set to 0, the sensor module does not make a selection.

• SENS_MAG_MODE: Set to 0 if running multiple EKF instances with magnetometer sensor diversity, ie EKF2_MULTI_MAG > 1.

  When set to 1 (default for single EKF operation) the sensor module selects Magnetometer data used by the EKF. This provides protection against loss of data from the sensor but does not protect against bad sensor data. When set to 0, the sensor module does not make a selection.

• EKF2_MULTI_IMU: This parameter specifies the number of IMU sensors used by the multiple EKF’s. If EKF2_MULTI_IMU <= 1, then only the first IMU sensor will be used. When SENS_IMU_MODE = 1, this will be the sensor selected by the sensor module. If EKF2_MULTI_IMU >= 2, then a separate EKF instance will run for the specified number of IMU sensors up to the lesser of 4 or the number of IMU’s present.

• EKF2_MULTI_MAG: This parameter specifies the number of magnetometer sensors used by the multiple EKF’s. If EKF2_MULTI_MAG <= 1, then only the first magnetometer sensor will be used. When SENS_MAG_MODE = 1, this will be the sensor selected by the sensor module. If EKF2_MULTI_MAG >= 2, then a separate EKF instance will run for the specified number of magnetometer sensors up to the lesser of 4 or the number of magnetometers present.

:::note The recording and EKF2 replay of flight logs with multiple EKF instances is not supported. To enable recording for EKF replay you must set the parameters to enable a single EKF instance. :::

What sensor measurements does it use?

The EKF has different modes of operation that allow for different combinations of sensor measurements. On start-up the filter checks for a minimum viable combination of sensors and after initial tilt, yaw and height alignment is completed, enters a mode that provides rotation, vertical velocity, vertical position, IMU delta angle bias and IMU delta velocity bias estimates.

This mode requires IMU data, a source of yaw (magnetometer or external vision) and a source of height data. This minimum data set is required for all EKF modes of operation. Other sensor data can then be used to estimate additional states.

IMU

• Three axis body fixed Inertial Measurement unit delta angle and delta velocity data at a minimum rate of 100Hz. Note: Coning corrections should be applied to the IMU delta angle data before it is used by the EKF.

Magnetometer

Three axis body fixed magnetometer data (or external vision system pose data) at a minimum rate of 5Hz is required. Magnetometer data can be used in two ways:

• Magnetometer measurements are converted to a yaw angle using the tilt estimate and magnetic declination. This yaw angle is then used as an observation by the EKF. This method is less accurate and does not allow for learning of body frame field offsets, however it is more robust to magnetic anomalies and large start-up gyro biases. It is the default method used during start-up and on ground.
• The XYZ magnetometer readings are used as separate observations. This method is more accurate and allows body frame offsets to be learned, but assumes the earth magnetic field environment only changes slowly and performs less well when there are significant external magnetic anomalies.

The logic used to select these modes is set by the EKF2_MAG_TYPE parameter.

The option is available to operate without a magnetometer, either by replacing it using yaw from a dual antenna GPS or using the IMU measurements and GPS velocity data to estimate yaw from vehicle movement.

Height

A source of height data - either GPS, barometric pressure, range finder or external vision at a minimum rate of 5Hz is required.

:::note The primary source of height data is controlled by the EKF2_HGT_MODE parameter. :::

If these measurements are not present, the EKF will not start. When these measurements have been detected, the EKF will initialise the states and complete the tilt and yaw alignment. When tilt and yaw alignment is complete, the EKF can then transition to other modes of operation enabling use of additional sensor data:

Correction for Static Pressure Position Error

Barometric pressure altitude is subject to errors generated by aerodynamic disturbances caused by vehicle wind relative velocity and orientation. This is known in aeronautics as static pressure position error. The EKF2 module that uses the ECL/EKF2 estimator library provides a method of compensating for these errors, provided wind speed state estimation is active.

For platforms operating in a fixed wing mode, wind speed state estimation requires either Airspeed and/or Synthetic Sideslip fusion to be enabled.

For multi-rotors, fusion of Drag Specific Forces can be enabled and tuned to provide the required wind velocity state estimates.

The EKF2 module models the error as a body fixed ellipsoid that specifies the fraction of dynamic pressure that is added to/subtracted from the barometric pressure - before it is converted to a height estimate. See the following parameter documentation for information on how to use this feature:

• EKF2_PCOEF_XP
• EKF2_PCOEF_XN
• EKF2_PCOEF_YP
• EKF2_PCOEF_YN
• EKF2_PCOEF_Z

GPS

Position and Velocity Measurements

GPS measurements will be used for position and velocity if the following conditions are met:

• GPS use is enabled via setting of the EKF2_AID_MASK parameter.
• GPS quality checks have passed. These checks are controlled by the EKF2_GPS_CHECK and EKF2_REQ_* parameters.
• GPS height can be used directly by the EKF via setting of the EKF2_HGT_MODE parameter.

Yaw Measurements

Some GPS receivers such as the Trimble MB-Two RTK GPS receiver can be used to provide a heading measurement that replaces the use of magnetometer data. This can be a significant advantage when operating in an environment where large magnetic anomalies are present, or at latitudes here the earth’s magnetic field has a high inclination. Use of GPS yaw measurements is enabled by setting bit position 7 to 1 (adding 128) in the EKF2_AID_MASK parameter.

Yaw From GPS Velocity

The EKF runs an additional multi-hypothesis filter internally that uses multiple 3-state Extended Kalman Filters (EKF’s) whose states are NE velocity and yaw angle. These individual yaw angle estimates are then combined using a Gaussian Sum Filter (GSF). The individual 3-state EKF’s use IMU and GPS horizontal velocity data (plus optional airspeed data) and do not rely on any prior knowledge of the yaw angle or magnetometer measurements. This provides a backup to the yaw from the main filter and is used to reset the yaw for the main 24-state EKF when a post-takeoff loss of navigation indicates that the yaw estimate from the magnetometer is bad. This will result in an Emergency yaw reset - magnetometer use stopped message information message at the GCS.

Data from this estimator is logged when ekf2 replay logging is enabled and can be viewed in the yaw_estimator_status message. The individual yaw estimates from the individual 3-state EKF yaw estimators are in the yaw fields. The GSF combined yaw estimate is in the yaw_composite field. The variance for the GSF yaw estimate is in the yaw_variance field. All angles are in radians. Weightings applied by the GSF to the individual 3-state EKF outputs are in theweight fields.

This also makes it possible to operate without any magnetometer data or dual antenna GPS receiver for yaw provided some horizontal movement after takeoff can be performed to enable the yaw to become observable. To use this feature, set EKF2_MAG_TYPE to none (5) to disable magnetometer use. Once the vehicle has performed sufficient horizontal movement to make the yaw observable, the main 24-state EKF will align it’s yaw to the GSF estimate and commence use of GPS.

Dual Receivers

Data from GPS receivers can be blended using an algorithm that weights data based on reported accuracy (this works best if both receivers output data at the same rate and use the same accuracy). The mechanism also provides automatic failover if data from a receiver is lost (it allows, for example, a standard GPS to be used as a backup to a more accurate RTK receiver). This is controlled by the SENS_GPS_MASK parameter.

The SENS_GPS_MASK parameter is set by default to disable blending and always use the first receiver, so it will have to be set to select which receiver accuracy metrics are used to decide how much each receiver output contributes to the blended solution. Where different receiver models are used, it is important that the SENS_GPS_MASK parameter is set to a value that uses accuracy metrics that are supported by both receivers. For example do not set bit position 0 to true unless the drivers for both receivers publish values in the s_variance_m_s field of the vehicle_gps_position message that are comparable. This can be difficult with receivers from different manufacturers due to the different way that accuracy is defined, e.g. CEP vs 1-sigma, etc.

The following items should be checked during setup:

• Verify that data for the second receiver is present. This will be logged as vehicle_gps_position_1 and can also be checked when connected via the nsh console using the command listener vehicle_gps_position -i 1. The GPS_2_CONFIG parameter will need to be set correctly.
• Check the s_variance_m_s, eph and epv data from each receiver and decide which accuracy metrics can be used. If both receivers output sensible s_variance_m_s and eph data, and GPS vertical position is not being used directly for navigation, then setting SENS_GPS_MASK to 3 is recommended. Where only eph data is available and both receivers do not output s_variance_m_s data, set SENS_GPS_MASK to 2. Bit position 2 would only be set if the GPS had been selected as a primary height source with the EKF2_HGT_MODE parameter and both receivers output sensible epv data.
• The output from the blended receiver data is logged as ekf_gps_position, and can be checked whilst connect via the nsh terminal using the command listener ekf_gps_position.
• Where receivers output at different rates, the blended output will be at the rate of slower receiver. Where possible receivers should be configured to output at the same rate.

GNSS Performance Requirements

For the ECL to accept GNSS data for navigation, certain minimum requirements need to be satisfied over a period of time, defined by EKF2_REQ_GPS_H (10 seconds by default).

Minima are defined in the EKF2REQ* parameters and each check can be en-/disabled using the EKF2_GPS_CHECK parameter.

The table below shows the different metrics directly reported or calculated from the GNSS data, and the minimum required values for the data to be used by ECL. In addition, the Average Value column shows typical values that might reasonably be obtained from a standard GNSS module (e.g. u-blox M8 series) - i.e. values that are considered good/acceptable.

:::note The hpos_drift_rate, vpos_drift_rate and hspd are calculated over a period of 10 seconds and published in the ekf2_gps_drift topic. Note that ekf2_gps_drift is not logged! :::

Range Finder

Range finder distance to ground is used by a single state filter to estimate the vertical position of the terrain relative to the height datum.

If operating over a flat surface that can be used as a zero height datum, the range finder data can also be used directly by the EKF to estimate height by setting the EKF2_HGT_MODE parameter to 2.

Airspeed

Equivalent Airspeed (EAS) data can be used to estimate wind velocity and reduce drift when GPS is lost by setting EKF2_ARSP_THR to a positive value. Airspeed data will be used when it exceeds the threshold set by a positive value for EKF2_ARSP_THR and the vehicle type is not rotary wing.

Synthetic Sideslip

Fixed wing platforms can take advantage of an assumed sideslip observation of zero to improve wind speed estimation and also enable wind speed estimation without an airspeed sensor. This is enabled by setting the EKF2_FUSE_BETA parameter to 1.

Multicopter Wind Estimation using Drag Specific Forces

Multi-rotor platforms can take advantage of the relationship between airspeed and drag force along the X and Y body axes to estimate North/East components of wind velocity. This is enabled by setting bit position 5 in the EKF2_AID_MASK parameter to true. The relationship between airspeed and specific force (IMU acceleration) along the X and Y body axes is controlled by the EKF2_BCOEF_X and EKF2_BCOEF_Y parameters which set the ballistic coefficients for flight in the X and Y directions respectively. The amount of specific force observation noise is set by the EKF2_DRAG_NOISE parameter.

These can be tuned by flying the vehicle in Position mode repeatedly forwards/backwards between rest and maximum speed, adjusting EKF2_BCOEF_X so that the corresponding innovation sequence in the ekf2_innovations_0.drag_innov[0] log message is minimised. This is then repeated for right/left movement with adjustment of EKF2_BCOEF_Y to minimise the ekf2_innovations_0.drag_innov[1] innovation sequence. Tuning is easier if this testing is conducted in still conditions.

If you are able to log data without dropouts from boot using SDLOG_MODE = 1 and SDLOG_PROFILE = 2, have access to the development environment, and are able to build code, then we recommended you fly once and perform the tuning via EKF2 Replay of the flight log.

:::note The recording and EKF2 replay of flight logs with multiple EKF instances is not supported. To enable recording for EKF replay you must set the parameters to enable a single EKF instance. :::

Optical Flow

Optical flow data will be used if the following conditions are met:

• Valid range finder data is available.
• Bit position 1 in the EKF2_AID_MASK parameter is true.
• The quality metric returned by the flow sensor is greater than the minimum requirement set by the EKF2_OF_QMIN parameter.

External Vision System

Position, velocity or orientation measurements from an external vision system, e.g. Vicon, can be used:

• External vision system horizontal position data will be used if bit position 3 in the EKF2_AID_MASK parameter is true.
• External vision system vertical position data will be used if the EKF2_HGT_MODE parameter is set to 3.
• External vision system velocity data will be used if bit position 8 in the EKF2_AID_MASK parameter is true.
• External vision system orientation data will be used for yaw estimation if bit position 4 in the EKF2_AID_MASK parameter is true.
• External vision reference frame offset will be estimated and used to rotate the external vision system data if bit position 6 in the EKF2_AID_MASK parameter is true.

Either bit 4 (EV_YAW) or bit 6 (EV_ROTATE) should be set to true, but not both together. Following EKF2_AID_MASK values are supported when using with an external vision system.

The EKF considers uncertainty in the visual pose estimate. This uncertainty information can be sent via the covariance fields in the MAVLink ODOMETRY message or it can be set through the parameters EKF2_EVP_NOISE, EKF2_EVV_NOISE and EKF2_EVA_NOISE. You can choose the source of the uncertainty with EKF2_EV_NOISE_MD.

How do I use the ‘ecl’ library EKF?

Set the SYS_MC_EST_GROUP parameter to 2 to use the ecl EKF.

What are the advantages and disadvantages of the ecl EKF over other estimators?

Like all estimators, much of the performance comes from the tuning to match sensor characteristics. Tuning is a compromise between accuracy and robustness and although we have attempted to provide a tune that meets the needs of most users, there will be applications where tuning changes are required.

For this reason, no claims for accuracy relative to the legacy combination of attitude_estimator_q + local_position_estimator have been made and the best choice of estimator will depend on the application and tuning.

Disadvantages

• The ecl EKF is a complex algorithm that requires a good understanding of extended Kalman filter theory and its application to navigation problems to tune successfully. It is therefore more difficult for users that are not achieving good results to know what to change.
• The ecl EKF uses more RAM and flash space.
• The ecl EKF uses more logging space.

Advantages

• The ecl EKF is able to fuse data from sensors with different time delays and data rates in a mathematically consistent way which improves accuracy during dynamic maneuvers once time delay parameters are set correctly.
• The ecl EKF is capable of fusing a large range of different sensor types.
• The ecl EKF detects and reports statistically significant inconsistencies in sensor data, assisting with diagnosis of sensor errors.
• For fixed wing operation, the ecl EKF estimates wind speed with or without an airspeed sensor and is able to use the estimated wind in combination with airspeed measurements and sideslip assumptions to extend the dead-reckoning time available if GPS is lost in flight.
• The ecl EKF estimates 3-axis accelerometer bias which improves accuracy for tailsitters and other vehicles that experience large attitude changes between flight phases.
• The federated architecture (combined attitude and position/velocity estimation) means that attitude estimation benefits from all sensor measurements. This should provide the potential for improved attitude estimation if tuned correctly.

How do I check the EKF performance?

EKF outputs, states and status data are published to a number of uORB topics which are logged to the SD card during flight. The following guide assumes that data has been logged using the .ulog file format. The .ulog format data can be parsed in python by using the PX4 pyulog library.

Most of the EKF data is found in the estimator_innovations and estimator_status uORB messages that are logged to the .ulog file.

A python script that automatically generates analysis plots and metadata can be found here. To use this script file, cd to the Tools/ecl_ekf directory and enter python process_logdata_ekf.py <log_file.ulg>. This saves performance metadata in a csv file named **.mdat.csv** and plots in a pdf file named `.pdf`.

Multiple log files in a directory can be analysed using the batch_process_logdata_ekf.py script. When this has been done, the performance metadata files can be processed to provide a statistical assessment of the estimator performance across the population of logs using the batch_process_metadata_ekf.py script.

Output Data

• Attitude output data is found in the vehicle_attitude message.
• Local position output data is found in the vehicle_local_position message.
• Global (WGS-84) output data is found in the vehicle_global_position message.
• Wind velocity output data is found in the wind_estimate message.

States

Refer to states[32] in estimator_status. The index map for states[32] is as follows:

• [0 … 3] Quaternions
• [4 … 6] Velocity NED (m/s)
• [7 … 9] Position NED (m)
• [10 … 12] IMU delta angle bias XYZ (rad)
• [13 … 15] IMU delta velocity bias XYZ (m/s)
• [16 … 18] Earth magnetic field NED (gauss)
• [19 … 21] Body magnetic field XYZ (gauss)
• [22 … 23] Wind velocity NE (m/s)
• [24 … 32] Not Used

State Variances

Refer to covariances[28] in estimator_status. The index map for covariances[28] is as follows:

• [0 … 3] Quaternions
• [4 … 6] Velocity NED (m/s)^2
• [7 … 9] Position NED (m^2)
• [10 … 12] IMU delta angle bias XYZ (rad^2)
• [13 … 15] IMU delta velocity bias XYZ (m/s)^2
• [16 … 18] Earth magnetic field NED (gauss^2)
• [19 … 21] Body magnetic field XYZ (gauss^2)
• [22 … 23] Wind velocity NE (m/s)^2
• [24 … 28] Not Used

Observation Innovations & Innovation Variances

The observation estimator_innovations, estimator_innovation_variances, and estimator_innovation_test_ratios message fields are defined in estimator_innovations.msg. The messages all have the same field names/types (but different units).

:::note The messages have the same fields because they are generated from the same field definition. The # TOPICS line (at the end of the file) lists the names of the set of messages to be created):

# TOPICS estimator_innovations estimator_innovation_variances estimator_innovation_test_ratios

:::

Some of the observations are:

• Magnetometer XYZ (gauss, gauss^2) : mag_field[3]
• Yaw angle (rad, rad^2) : heading
• True Airspeed (m/s, (m/s)^2) : airspeed
• Synthetic sideslip (rad, rad^2) : beta
• Optical flow XY (rad/sec, (rad/s)^2) : flow
• Height above ground (m, m^2) : hagl
• Drag specific force ((m/s)^2): drag
• Velocity and position innovations : per sensor

In addition, each sensor has its own fields for horizontal and vertical position and/or velocity values (where appropriate). These are largely self documenting, and are reproduced below:

# GPS
float32[2] gps_hvel	# horizontal GPS velocity innovation (m/sec) and innovation variance ((m/sec)**2)
float32    gps_vvel	# vertical GPS velocity innovation (m/sec) and innovation variance ((m/sec)**2)
float32[2] gps_hpos	# horizontal GPS position innovation (m) and innovation variance (m**2)
float32    gps_vpos	# vertical GPS position innovation (m) and innovation variance (m**2)

# External Vision
float32[2] ev_hvel	# horizontal external vision velocity innovation (m/sec) and innovation variance ((m/sec)**2)
float32    ev_vvel	# vertical external vision velocity innovation (m/sec) and innovation variance ((m/sec)**2)
float32[2] ev_hpos	# horizontal external vision position innovation (m) and innovation variance (m**2)
float32    ev_vpos	# vertical external vision position innovation (m) and innovation variance (m**2)

# Fake Position and Velocity
float32[2] fake_hvel	# fake horizontal velocity innovation (m/s) and innovation variance ((m/s)**2)
float32    fake_vvel	# fake vertical velocity innovation (m/s) and innovation variance ((m/s)**2)
float32[2] fake_hpos	# fake horizontal position innovation (m) and innovation variance (m**2)
float32    fake_vpos	# fake vertical position innovation (m) and innovation variance (m**2)

# Height sensors
float32 rng_vpos	# range sensor height innovation (m) and innovation variance (m**2)
float32 baro_vpos	# barometer height innovation (m) and innovation variance (m**2)

# Auxiliary velocity
float32[2] aux_hvel	# horizontal auxiliar velocity innovation from landing target measurement (m/sec) and innovation variance ((m/sec)**2)
float32    aux_vvel	# vertical auxiliar velocity innovation from landing target measurement (m/sec) and innovation variance ((m/sec)**2)

Output Complementary Filter

The output complementary filter is used to propagate states forward from the fusion time horizon to current time. To check the magnitude of the angular, velocity and position tracking errors measured at the fusion time horizon, refer to output_tracking_error[3] in the ekf2_innovations message.

The index map is as follows:

• [0] Angular tracking error magnitude (rad)
• [1] Velocity tracking error magnitude (m/s). The velocity tracking time constant can be adjusted using the EKF2_TAU_VEL parameter. Reducing this parameter reduces steady state errors but increases the amount of observation noise on the NED velocity outputs.
• [2] Position tracking error magnitude (m). The position tracking time constant can be adjusted using the EKF2_TAU_POS parameter. Reducing this parameter reduces steady state errors but increases the amount of observation noise on the NED position outputs.

EKF Errors

The EKF contains internal error checking for badly conditioned state and covariance updates. Refer to the filter_fault_flags in estimator_status.

Observation Errors

There are two categories of observation faults:

• Loss of data. An example of this is a range finder failing to provide a return.
• The innovation, which is the difference between the state prediction and sensor observation is excessive. An example of this is excessive vibration causing a large vertical position error, resulting in the barometer height measurement being rejected.

Both of these can result in observation data being rejected for long enough to cause the EKF to attempt a reset of the states using the sensor observations. All observations have a statistical confidence checks applied to the innovations. The number of standard deviations for the check are controlled by the EKF2_*_GATE parameter for each observation type.

Test levels are available in estimator_status as follows:

• mag_test_ratio: ratio of the largest magnetometer innovation component to the innovation test limit
• vel_test_ratio: ratio of the largest velocity innovation component to the innovation test limit
• pos_test_ratio: ratio of the largest horizontal position innovation component to the innovation test limit
• hgt_test_ratio: ratio of the vertical position innovation to the innovation test limit
• tas_test_ratio: ratio of the true airspeed innovation to the innovation test limit
• hagl_test_ratio: ratio of the height above ground innovation to the innovation test limit

For a binary pass/fail summary for each sensor, refer to innovation_check_flags in estimator_status.

GPS Quality Checks

The EKF applies a number of GPS quality checks before commencing GPS aiding. These checks are controlled by the EKF2_GPS_CHECK and EKF2_REQ_* parameters. The pass/fail status for these checks is logged in the estimator_status.gps_check_fail_flags message. This integer will be zero when all required GPS checks have passed. If the EKF is not commencing GPS alignment, check the value of the integer against the bitmask definition gps_check_fail_flags in estimator_status.

EKF Numerical Errors

The EKF uses single precision floating point operations for all of its computations and first order approximations for derivation of the covariance prediction and update equations in order to reduce processing requirements. This means that it is possible when re-tuning the EKF to encounter conditions where the covariance matrix operations become badly conditioned enough to cause divergence or significant errors in the state estimates.

To prevent this, every covariance and state update step contains the following error detection and correction steps:

• If the innovation variance is less than the observation variance (this requires a negative state variance which is impossible) or the covariance update will produce a negative variance for any of the states, then:
  • The state and covariance update is skipped
  • The corresponding rows and columns in the covariance matrix are reset
  • The failure is recorded in the estimator_status filter_fault_flags message
• State variances (diagonals in the covariance matrix) are constrained to be non-negative.
• An upper limit is applied to state variances.
• Symmetry is forced on the covariance matrix.

After re-tuning the filter, particularly re-tuning that involve reducing the noise variables, the value of estimator_status.gps_check_fail_flags should be checked to ensure that it remains zero.

What should I do if the height estimate is diverging?

The most common cause of EKF height diverging away from GPS and altimeter measurements during flight is clipping and/or aliasing of the IMU measurements caused by vibration. If this is occurring, then the following signs should be evident in the data

• estimator_innovations.vel_pos_innov[2] and estimator_innovations.vel_pos_innov[5] will both have the same sign.
• estimator_status.hgt_test_ratio will be greater than 1.0

The recommended first step is to ensure that the autopilot is isolated from the airframe using an effective isolation mounting system. An isolation mount has 6 degrees of freedom, and therefore 6 resonant frequencies. As a general rule, the 6 resonant frequencies of the autopilot on the isolation mount should be above 25Hz to avoid interaction with the autopilot dynamics and below the frequency of the motors.

An isolation mount can make vibration worse if the resonant frequencies coincide with motor or propeller blade passage frequencies.

The EKF can be made more resistant to vibration induced height divergence by making the following parameter changes:

• Double the value of the innovation gate for the primary height sensor. If using barometric height this is EKF2_BARO_GATE.
• Increase the value of EKF2_ACC_NOISE to 0.5 initially. If divergence is still occurring, increase in further increments of 0.1 but do not go above 1.0

Note that the effect of these changes will make the EKF more sensitive to errors in GPS vertical velocity and barometric pressure.

What should I do if the position estimate is diverging?

The most common causes of position divergence are:

• High vibration levels.
  • Fix by improving mechanical isolation of the autopilot.
  • Increasing the value of EKF2_ACC_NOISE and EKF2_GYR_NOISE can help, but does make the EKF more vulnerable to GPS glitches.
• Large gyro bias offsets.
  • Fix by re-calibrating the gyro. Check for excessive temperature sensitivity (> 3 deg/sec bias change during warm-up from a cold start and replace the sensor if affected of insulate to slow the rate of temperature change.
• Bad yaw alignment
  • Check the magnetometer calibration and alignment.
  • Check the heading shown QGC is within 15 deg truth
• Poor GPS accuracy
  • Check for interference
  • Improve separation and shielding
  • Check flying location for GPS signal obstructions and reflectors (nearby tall buildings)
• Loss of GPS

Determining which of these is the primary cause requires a methodical approach to analysis of the EKF log data:

• Plot the velocity innovation test ratio - estimator_status.vel_test_ratio
• Plot the horizontal position innovation test ratio - estimator_status.pos_test_ratio
• Plot the height innovation test ratio - estimator_status.hgt_test_ratio
• Plot the magnetometer innovation test ratio - estimator_status.mag_test_ratio
• Plot the GPS receiver reported speed accuracy - vehicle_gps_position.s_variance_m_s
• Plot the IMU delta angle state estimates - estimator_status.states[10], states[11] and states[12]
• Plot the EKF internal high frequency vibration metrics:
  • Delta angle coning vibration - estimator_status.vibe[0]
  • High frequency delta angle vibration - estimator_status.vibe[1]
  • High frequency delta velocity vibration - estimator_status.vibe[2]

During normal operation, all the test ratios should remain below 0.5 with only occasional spikes above this as shown in the example below from a successful flight:

The following plot shows the EKF vibration metrics for a multirotor with good isolation. The landing shock and the increased vibration during takeoff and landing can be seen. Insufficient data has been gathered with these metrics to provide specific advice on maximum thresholds.

The above vibration metrics are of limited value as the presence of vibration at a frequency close to the IMU sampling frequency (1 kHz for most boards) will cause offsets to appear in the data that do not show up in the high frequency vibration metrics. The only way to detect aliasing errors is in their effect on inertial navigation accuracy and the rise in innovation levels.

In addition to generating large position and velocity test ratios of > 1.0, the different error mechanisms affect the other test ratios in different ways:

Determination of Excessive Vibration

High vibration levels normally affect vertical position and velocity innovations as well as the horizontal components. Magnetometer test levels are only affected to a small extent.

(insert example plots showing bad vibration here)

Determination of Excessive Gyro Bias

Large gyro bias offsets are normally characterised by a change in the value of delta angle bias greater than 5E-4 during flight (equivalent to ~3 deg/sec) and can also cause a large increase in the magnetometer test ratio if the yaw axis is affected. Height is normally unaffected other than extreme cases. Switch on bias value of up to 5 deg/sec can be tolerated provided the filter is given time settle before flying. Pre-flight checks performed by the commander should prevent arming if the position is diverging.

(insert example plots showing bad gyro bias here)

Determination of Poor Yaw Accuracy

Bad yaw alignment causes a velocity test ratio that increases rapidly when the vehicle starts moving due inconsistency in the direction of velocity calculated by the inertial nav and the GPS measurement. Magnetometer innovations are slightly affected. Height is normally unaffected.

(insert example plots showing bad yaw alignment here)

Determination of Poor GPS Accuracy

Poor GPS accuracy is normally accompanied by a rise in the reported velocity error of the receiver in conjunction with a rise in innovations. Transient errors due to multipath, obscuration and interference are more common causes. Here is an example of a temporary loss of GPS accuracy where the multi-rotor started drifting away from its loiter location and had to be corrected using the sticks. The rise in estimator_status.vel_test_ratio to greater than 1 indicates the GPs velocity was inconsistent with other measurements and has been rejected.

This is accompanied with rise in the GPS receivers reported velocity accuracy which indicates that it was likely a GPS error.

If we also look at the GPS horizontal velocity innovations and innovation variances, we can see the large spike in North velocity innovation that accompanies this GPS ‘glitch’ event.

Determination of GPS Data Loss

Loss of GPS data will be shown by the velocity and position innovation test ratios ‘flat-lining’. If this occurs, check the other GPS status data in vehicle_gps_position for further information.

The following plot shows the NED GPS velocity innovations ekf2_innovations_0.vel_pos_innov[0 ... 2], the GPS NE position innovations ekf2_innovations_0.vel_pos_innov[3 ... 4] and the Baro vertical position innovation ekf2_innovations_0.vel_pos_innov[5] generated from a simulated VTOL flight using SITL Gazebo.

The simulated GPS was made to lose lock at 73 seconds. Note the NED velocity innovations and NE position innovations ‘flat-line’ after GPS is lost. Note that after 10 seconds without GPS data, the EKF reverts back to a static position mode using the last known position and the NE position innovations start to change again.

Barometer Ground Effect Compensation

If the vehicle has the tendency during landing to climb back into the air when close to the ground, the most likely cause is barometer ground effect.

This is caused when air pushed down by the propellers hits the ground and creates a high pressure zone below the drone. The result is a lower reading of pressure altitude, leading to an unwanted climb being commanded. The figure below shows a typical situation where the ground effect is present. Note how the barometer signal dips at the beginning and end of the flight.

You can enable ground effect compensation to fix this problem:

• From the plot estimate the magnitude of the barometer dip during takeoff or landing. In the plot above one can read a barometer dip of about 6 meters during landing.
• Then set the parameter EKF2_GND_EFF_DZ to that value and add a 10 percent margin. Therefore, in this case a value of 6.6 meters would be a good starting point.

If a terrain estimate is available (e.g. the vehicle is equipped with a range finder) then you can additionally specify EKF2_GND_MAX_HGT, the above ground-level altitude below which ground effect compensation should be activated. If no terrain estimate is available this parameter will have no effect and the system will use heuristics to determine if ground effect compensation should be activated.

Further Information

• PX4 State Estimation Overview, PX4 Developer Summit 2019, Dr. Paul Riseborough): Overview of the estimator, and major changes from 2018/19, and the expected improvements through 2019/20.

static_pressure_buildup - APM, Mission-planner

Static Pressure Buildup

Air flowing over an enclosed vehicle can cause the static pressure to change within the canopy/hull. Depending on the location of holes/leaks in the hull, you can end up with under or overpressure (similar to a wing).

The change in pressure can affect barometer measurements, leading to an inaccurate altitude estimate. This might manifest as the vehicle losing altitude when it stops moving in Altitude, Position or Mission modes (when the vehicle stops moving the static pressure drops, the sensor reports a higher altitude, and the vehicle compensates by descending).

One solution is to use foam-filled venting holes to reduce the buildup (as much as possible) and then attempt dynamic calibration to remove any remaining effects.

:::tip Before “fixing” the problem you should first check that the Z setpoint tracks the estimated altitude (to verify that there are no controller issues). :::

:::note While it is possible to remove the barometer from the altitude estimate (i.e. only use altitude from the GPS), this is not recommended. GPS is inaccurate in many environments, and particularly in urban environments where you have signal reflections off buildings. :::

Airflow Analysis

You can modify the hull by drilling holes or filling them with foam.

One way to analyse the effects of these changes is to mount the drone on a car and drive around (on a relatively level surface) with the hull exposed to air/wind. By looking at the ground station you can review the effects of movement-induced static pressure changes on the measured altitude (using the road as “ground truth).

This process allows rapid iteration without draining batteries: modify drone, drive/review, repeat!

:::tip Aim for a barometer altitude drop of less than 2 metres at maximum horizontal speed before attempting software-based calibration below. :::

Dynamic Calibration

After modifying the hardware, you can then use the EKF2_PCOEF_* parameters to tune for expected barometer variation based on relative air velocity. For more information see ECL/EKF Overview & Tuning > Correction for Static Pressure Position Error.

:::note The approach works well if the relationship between the error due to static pressure and the velocity varies linearly. If the vehicle has a more complex aerodynamic model it will be less effective. :::

sensor_thermal_calibration - APM, Mission-planner

Thermal Calibration and Compensation

PX4 contains functionality to calibrate and compensate rate gyro, accelerometer and barometric pressure sensors for the effect of changing sensor temperature on sensor bias.

This topic details the test environment and calibration procedures. At the end there is a description of the implementation.

:::note After thermal calibration the thermal calibration parameters (TC_*) are used for all calibration/compensation of the respective sensors. Any subsequent standard calibration will therefore update TC_* parameters and not the “normal” SYS_CAL_* calibration parameters (and in some cases these parameters may be reset). :::

:::note At time of writing (PX4 v1.11) thermal calibration of the magnetometer is not yet supported. :::

Test Setup/Best Practice

The calibration procedures described in the following sections are ideally run in an environment chamber (a temperature and humidity controlled environment) as the board is heated from the lowest to the highest operating/calibration temperature. Before starting the calibration, the board is first cold soaked (cooled to the minimum temperature and allowed to reach equilibrium).

For the cold soak you can use a regular home freezer to achieve -20C, and commercial freezers can achieve of the order of -40C. The board should be placed in a ziplock/anti-static bag containing a silica packet, with a power lead coming out through a sealed hole. After the cold soak the bag can be moved to the test environment and the test continued in the same bag.

:::note The bag/silica is to prevent condensation from forming on the board. :::

It possible to perform the calibration without a commercial-grade environment chamber. A simple environment container can be created using a styrofoam box with a very small internal volume of air. This allows the autopilot to self-heat the air relatively quickly (be sure that the box has a small hole to equalize to ambient room pressure, but still be able to heat up inside).

Using this sort of setup it is possible to heat a board to ~70C. Anecdotal evidence suggests that many common boards can be heated to this temperature without adverse side effects. If in doubt, check the safe operating range with your manufacturer.

:::tip To check the status of the onboard thermal calibration use the MAVlink console (or NuttX console) to check the reported internal temp from the sensor. :::

Calibration Procedures

PX4 supports two calibration procedures:

• onboard - calibration is run on the board itself. This method requires knowledge of the amount of temperature rise that is achievable with the test setup.
• offboard - compensation parameters are calculated on a development computer based on log information collected during the calibration procedure. This method allows users to visually check the quality of the data and curve-fit.

The offboard approach is more complex and slower, but requires less knowledge of the test setup and is easier to validate.

Onboard Calibration Procedure

Onboard calibration is run entirely on the device. It require knowledge of the amount of temperature rise that is achievable with the test setup.

To perform and onboard calibration:

1. Ensure the frame type is set before calibration, otherwise calibration parameters will be lost when the board is setup.
2. Power the board and set the SYS_CAL_* parameters to 1 to enable calibration of the required sensors at the next startup. ¹
3. Set the SYS_CAL_TDEL parameter to the number of degrees of temperature rise required for the onboard calibrator to complete. If this parameter is too small, then the calibration will complete early and the temperature range for the calibration will not be sufficient to compensate when the board is fully warmed up. If this parameter is set too large, then the onboard calibrator will never complete. allowance should be made for the rise in temperature due to the boards self heating when setting this parameter. If the amount of temperature rise at the sensors is unknown, then the off-board method should be used.
4. Set the SYS_CAL_TMIN parameter to the lowest temperature data that you want the calibrator to use. This enables a lower cold soak ambient temperature to be used to reduce the cold soak time whilst maintaining control over the calibration minimum temperature. The data for a sensor will not be used by the calibrator if it is below the value set by this parameter.
5. Set the SYS_CAL_TMAX parameter to the highest starting sensor temperature that should be accepted by the calibrator. If the starting temperature is higher than the value set by this parameter, the calibration will exit with an error. Note that if the variation in measured temperature between different sensors exceeds the gap between SYS_CAL_TMAX and SYS_CAL_TMIN, then it will be impossible for the calibration to start.
6. Remove power and cold soak the board to below the starting temperature specified by the SYS_CAL_TMIN parameter. Note that there is a 10 second delay on startup before calibration starts to allow any sensors to stabilise and the sensors will warm internally during this period.
7. Keeping the board stationary², apply power and warm to a temperature high enough to achieve the temperature rise specified by the SYS_CAL_TDEL parameter. The completion percentage is printed to the system console during calibration. ³
8. When the calibration completes, remove power, allow the board to cool to a temperature that is within the calibration range before performing the next step.
9. Perform a 6-point accel calibration via the system console using commander calibrate accel or via QGroundControl. If the board is being set-up for the first time, the gyro and magnetometer calibration will also need to be performed.
10. The board should always be re-powered before flying after any sensor calibration, because sudden offset changes from calibration can upset the navigation estimator and some parameters are not loaded by the algorithms that use them until the next startup.

Offboard Calibration Procedure

Offboard calibration is run on a development computer using data collected during the calibration test. This method provides a way to visually check the quality of data and curve fit.

To perform an offboard calibration:

1. Ensure the frame type is set before calibration, otherwise calibration parameters will be lost when the board is setup.
2. Power up the board and set the TC_A_ENABLE, TC_B_ENABLE and TC_G_ENABLE parameters to 1.
3. Set all CAL_GYRO](../advanced_config/parameter_reference.md#CAL_GYRO0_ID) and [CAL_ACC parameters to defaults.
4. Set the SDLOG_MODE parameter to 2 to enable logging of data from boot.
5. Set the SDLOG_PROFILE checkbox for thermal calibration (bit 2) to log the raw sensor data required for calibration.
6. Cold soak the board to the minimum temperature it will be required to operate in.
7. Apply power and keeping the board still ², warm it slowly to the maximum required operating temperature. ³
8. Remove power and extract the .ulog file.
9. Open a terminal window in the Firmware/Tools directory and run the python calibration script:

   python process_sensor_caldata.py <full path name to .ulog file>
   

   This will generate a .pdf file showing the measured data and curve fits for each sensor, and a .params file containing the calibration parameters.

10. Power the board, connect QGroundControl and load the parameter from the generated .params file onto the board using QGroundControl. Due to the number of parameters, loading them may take some time.
11. After parameters have finished loading, set SDLOG_MODE to 1 to re-enable normal logging and remove power.
12. Power the board and perform a normal accelerometer sensor calibration using QGroundControl. It is important that this step is performed when board is within the calibration temperature range. The board must be repowered after this step before flying as the sudden offset changes can upset the navigation estimator and some parameters are not loaded by the algorithms that use them until the next startup.

Implementation Detail

Calibration refers to the process of measuring the change in sensor value across a range of internal temperatures, and performing a polynomial fit on the data to calculate a set of coefficients (stored as parameters) that can be used to correct the sensor data. Compensation refers to the process of using the internal temperature to calculate an offset that is subtracted from the sensor reading to correct for changing offset with temperature

The inertial rate gyro and accelerometer sensor offsets are calculated using a 3rd order polynomial, whereas the barometric pressure sensor offset is calculated using a 5th order polynomial. Example fits are show below:

Calibration Parameter Storage

With the existing parameter system implementation we are limited to storing each value in the struct as a separate entry. To work around this limitation the following logical naming convention is used for the thermal compensation parameters:

TC_[type][instance]_[cal_name]_[axis]

Where:

• type: is a single character indicating the type of sensor where G = rate gyroscope, A = accelerometer and B = barometer.
• instance: is an integer 0,1 or 2 allowing for calibration of up to three sensors of the same type.

• cal_name: is a string identifying the calibration value. It has the following possible values:

  • Xn: Polynomial coefficient where n is the order of the coefficient, e.g. X3 * (temperature - reference temperature)**3.
  • SCL: scale factor.
  • TREF: reference temperature (deg C).
  • TMIN: minimum valid temperature (deg C).
  • TMAX: maximum valid temperature (deg C).
• axis: is an integer 0,1 or 2 indicating that the calibration data is for X,Y or Z axis in the board frame of reference. For the barometric pressure sensor, the axis suffix is omitted.

Examples:

• TC_G0_X3_0 is the ^3 coefficient for the first gyro x-axis.
• TC_A1_TREF is the reference temperature for the second accelerometer.

Calibration Parameter Usage

The correction for thermal offsets (using the calibration parameters) is performed in the sensors module. The reference temperature is subtracted from the measured temperature to obtain a delta temperature where:

delta = measured_temperature - reference_temperature

The delta temperature is then used to calculate a offset, where:

offset = X0 + X1*delta + X2*delta**2 + ... + Xn*delta**n

The offset and temperature scale factor are then used to correct the sensor measurement where:

corrected_measurement = (raw_measurement - offset) * scale_factor

If the temperature is above the test range set by the *_TMIN and *_TMAX parameters, then the measured temperature will be clipped to remain within the limits.

Correction of the accelerometer, barometers or rate gyroscope data is enabled by setting TC_A_ENABLE, TC_B_ENABLE or TC_G_ENABLE parameters to 1 respectively.

Compatibility with legacy CAL_* parameters and commander controlled calibration

The legacy temperature-agnostic PX4 rate gyro and accelerometer sensor calibration is performed by the commander module and involves adjusting offset, and in the case of accelerometer calibration, scale factor calibration parameters. The offset and scale factor parameters are applied within the driver for each sensor. These parameters are found in the CAL parameter group.

Onboard temperature calibration is controlled by the events module and the corrections are applied within the sensors module before the sensor combined uORB topic is published. This means that if thermal compensation is being used, all of the corresponding legacy offset and scale factor parameters must be set to defaults of zero and unity before a thermal calibration is performed. If an on-board temperature calibration is performed, this will be done automatically, however if an offboard calibration is being performed it is important that the legacy CAL*OFF and CAL*SCALE parameters be reset before calibration data is logged.

If gyro thermal compensation has been enabled by setting the TC_G_ENABLE parameter to 1, then the commander controlled gyro calibration can still be performed, however it will be used to shift the compensation curve up or down by the amount required to zero the angular rate offset. It achieves this by adjusting the X0 coefficients.

If accel thermal compensation has been enabled by setting the TC_A_ENABLE parameter to 1, then the commander controlled 6-point accel calibration can still be performed, however instead of adjusting the *OFF and *SCALE parameters in the CAL parameter group, these parameters are set to defaults and the thermal compensation X0 and SCL parameters are adjusted instead.

Limitations

Scale factors are assumed to be temperature invariant due to the difficulty associated with measuring these at different temperatures. This limits the usefulness of the accelerometer calibration to those sensor models with stable scale factors. In theory with a thermal chamber or IMU heater capable of controlling IMU internal temperature to within a degree, it would be possible to perform a series of 6 sided accelerometer calibrations and correct the accelerometers for both offset and scale factor. Due to the complexity of integrating the required board movement with the calibration algorithm, this capability has not been included.

prearm_arm_disarm - APM, Mission-planner

Prearm, Arm, Disarm Configuration

Vehicles may have moving parts, some of which are potentially dangerous when powered (in particular motors and propellers)!

To reduce the chance of accidents, PX4 has explicit state(s) for powering the vehicle components:

• Disarmed: There is no power to motors or actuators.
• Pre-armed: Motors/propellers are locked but actuators for non-dangerous electronics are powered (e.g. ailerons, flaps etc.).
• Armed: Vehicle is fully powered. Motors/propellers may be turning (dangerous!)

:::note Ground stations may display disarmed for pre-armed vehicles. While not technically correct for pre-armed vehicles, it is “safe”. :::

Users can control progression though these states using a safety switch on the vehicle (optional) and an arming switch/button, arming gesture, or MAVLink command on the ground controller:

• A safety switch is a control on the vehicle that must be engaged before the vehicle can be armed, and which may also prevent prearming (depending on the configuration). Commonly the safety switch is integrated into a GPS unit, but it may also be a separate physical component.

  :::warning A vehicle that is armed is potentially dangerous. The safety switch is an additional mechanism that prevents arming from happening by accident. :::

• An arming switch is a switch or button on an RC controller that can be used to arm the vehicle and start motors (provided arming is not prevented by a safety switch).
• An arming gesture is a stick movement on an RC controller that can be used as an alternative to an arming switch.
• MAVLink commands can also be sent by a ground control station to arm/disarm a vehicle.

PX4 will also automatically disarm the vehicle if it does not takeoff within a certain amount of time after arming, and if it is not manually disarmed after landing. This reduces the amount of time where an armed (and therefore dangerous) vehicle is on the ground.

PX4 allows you to configure how pre-arming, arming and disarming work using parameters (which can be edited in QGroundControl via the parameter editor), as described in the following sections.

:::tip Arming/disarming parameters can be found in Parameter Reference > Commander (search for COM_ARM_* and COM_DISARM_*). :::

Arming Gesture

By default, the vehicle is armed and disarmed by moving RC throttle/yaw sticks to particular extremes and holding them for 1 second.

• Arming: Throttle minimum, yaw maximum
• Disarming: Throttle minimum, yaw minimum

RC controllers will have different gestures based on their mode (as controller mode affects the sticks used for throttle and yaw):

• Mode 2:
  • Arm: Left stick to bottom right.
  • Disarm: Left stick to the bottom left.
• Mode 1:
  • Arm: Left-stick to right, right-stick to bottom.
  • Disarm: Left-stick to left, right-stick to the bottom.

The required hold time can be configured using COM_RC_ARM_HYST.

Arming Button/Switch

An arming button or “momentary switch” can be configured to trigger arm/disarm instead of gesture-based arming (setting an arming switch disables arming gestures). The button should be held down for (nominally) one second to arm (when disarmed) or disarm (when armed).

A two-position switch can also be used for arming/disarming, where the respective arm/disarm commands are sent on switch transitions.

:::tip Two-position arming switches are primarily used in/recommended for racing drones. :::

The switch or button is assigned (and enabled) using RC_MAP_ARM_SW, and the switch “type” is configured using COM_ARM_SWISBTN.

:::note The switch can also be set as part of QGroundControl Flight Mode configuration. :::

Auto-Disarming

By default vehicles will automatically disarm on landing, or if you take too long to take off after arming. The feature is configured using the following timeouts.

Arming Sequence: Pre Arm Mode & Safety Button

The arming sequence depends on whether or not there is a safety switch, and is controlled by the parameters COM_PREARM_MODE (Prearm mode) and CBRK_IO_SAFETY (I/O safety circuit breaker).

The COM_PREARM_MODE parameter defines when/if pre-arm mode is enabled (“safe”/non-throttling actuators are able to move):

• Disabled: Pre-arm mode disabled (there is no stage where only “safe”/non-throttling actuators are enabled).
• Safety Switch (Default): The pre-arm mode is enabled by the safety switch. If there is no safety switch then pre-arm mode will not be enabled.
• Always: Prearm mode is enabled from power up.

If there is a safety switch then this will be a precondition for arming. If there is no safety switch the I/O safety circuit breaker must be engaged (CBRK_IO_SAFETY), and arming will depend only on the arm command.

The sections below detail the startup sequences for the different configurations

Default: COM_PREARM_MODE=Safety and Safety Switch

The default configuration uses safety switch to prearm. From prearm you can then arm to engage all motors/actuators. It corresponds to: COM_PREARM_MODE=1 (safety switch) and CBRK_IO_SAFETY=0 (I/O safety circuit breaker disabled).

The default startup sequence is:

1. Power-up.
   • All actuators locked into disarmed position
   • Not possible to arm.
2. Safety switch is pressed.
   • System now prearmed: non-throttling actuators can move (e.g. ailerons).
   • System safety is off: Arming possible.
3. Arm command is issued.
   • The system is armed.
   • All motors and actuators can move.

COM_PREARM_MODE=Disabled and Safety Switch

When prearm mode is Disabled, engaging the safety switch does not unlock the “safe” actuators, though it does allow you to then arm the vehicle. This corresponds to COM_PREARM_MODE=0 (Disabled) and CBRK_IO_SAFETY=0 (I/O safety circuit breaker disabled).

The startup sequence is:

1. Power-up.
   • All actuators locked into disarmed position
   • Not possible to arm.
2. Safety switch is pressed.
   • All actuators stay locked into disarmed position (same as disarmed).
   • System safety is off: Arming possible.
3. Arm command is issued.
   • The system is armed.
   • All motors and actuators can move.

COM_PREARM_MODE=Always and Safety Switch

When prearm mode is Always, prearm mode is enabled from power up. To arm, you still need the safety switch. This corresponds to COM_PREARM_MODE=2 (Always) and CBRK_IO_SAFETY=0 (I/O safety circuit breaker disabled).

The startup sequence is:

1. Power-up.
   • System now prearmed: non-throttling actuators can move (e.g. ailerons).
   • Not possible to arm.
2. Safety switch is pressed.
   • System safety is off: Arming possible.
3. Arm command is issued.
   • The system is armed.
   • All motors and actuators can move.

COM_PREARM_MODE=Safety or Disabled and No Safety Switch

With no safety switch, when COM_PREARM_MODE is set to Safety or Disabled prearm mode cannot be enabled (same as disarmed). This corresponds to COM_PREARM_MODE=0 or 1 (Disabled/Safety Switch) and CBRK_IO_SAFETY=22027 (I/O safety circuit breaker engaged).

The startup sequence is:

1. Power-up.
   • All actuators locked into disarmed position
   • System safety is off: Arming possible.
2. Arm command is issued.
   • The system is armed.
   • All motors and actuators can move.

COM_PREARM_MODE=Always and No Safety Switch

When prearm mode is Always, prearm mode is enabled from power up. This corresponds to COM_PREARM_MODE=2 (Always) and CBRK_IO_SAFETY=22027 (I/O safety circuit breaker engaged).

The startup sequence is:

1. Power-up.
   • System now prearmed: non-throttling actuators can move (e.g. ailerons).
   • System safety is off: Arming possible.
2. Arm command is issued.
   • The system is armed.
   • All motors and actuators can move.

Parameters

parameters - APM, Mission-planner

Finding/Updating Parameters

PX4 behaviour can be configured/tuned using parameters (e.g. Multicopter PID gains, calibration information, etc.).

The QGroundControl Parameters screen allows you to find and modify any of the parameters associated with the vehicle. The screen is accessed by clicking the top menu Gear icon and then Parameters in the sidebar.

:::note Most of the more commonly used parameters are more conveniently set using the dedicated setup screens described in the Basic Configuration section. The Parameters screen is needed when modifying less commonly modified parameters - for example while tuning a new vehicle. :::

:::warning While some parameters can be changed in flight, this is not recommended (except where explicitly stated in the guide). :::

Finding a Parameter

You can search for a parameter by entering a term in the Search field. This will show you a list of all parameter names and descriptions that contain the entered substring (press Clear to reset the search).

You can also browse the parameters by group by clicking on the buttons to the left (in the image below the Battery Calibration group is selected).

:::tip If you can’t find an expected parameter, see the next section. :::

Missing Parameters

Parameters are usually not visible because either they are conditional on other parameters, or they are not present in the firmware (see below).

Conditional Parameters

A parameter may not be displayed if it is conditional on another parameter that is not enabled.

You can usually find out what parameters are conditional by searching the full parameter reference and other documentation. In particular serial port configuration parameters depend on what service is assigned to a serial port.

Parameter Not In Firmware

A parameter may not be present in the firmware because you’re using a different version of PX4 or because you’re using a build in which the associated module is not included.

New parameters are added in each PX4 version, and existing parameters are sometimes removed or renamed. You can check whether a parameter should be present by reviewing the full parameter reference for the version you’re targeting. You can also search for the parameter in the source tree and in the release notes.

The other reason that a parameter might not be in firmware is if its associated module has not been included. This is a problem (in particular) for FMUv2 firmware, which omits many modules so that PX4 can fit into the 1MB of available flash. There are two options to solve this problem:

• Check if you can update your board to run FMUv3 firmware, which includes all modules: Firmware > FMUv2 Bootloader Update
• If your board can only run FMUv2 firmware you will need to rebuild PX4 with the missing modules enabled. You can see these commented out in boards/px4/fmu-v2/default.cmake:

  	DRIVERS
        adc
        #barometer # all available barometer drivers
        barometer/ms5611
        #batt_smbus
        #camera_capture
  

  :::note You may also need to disable other modules in order to fit the rebuilt firmware into 1MB flash. Finding modules to remove requires some trial/error and depends on what use cases you need the vehicle to meet. :::

Changing a Parameter

To change the value of a parameter click on the parameter row in a group or search list. This will open a side dialog in which you can update the value (this dialog also provides additional detailed information about the parameter - including whether a reboot is required for the change to take effect).

:::note When you click Save the parameter is automatically and silently uploaded to the connected vehicle. Depending on the parameter, you may then need to reboot the flight controller for the change to take effect. :::

Tools

You can select additional options from the Tools menu on the top right hand side of the screen.

Refresh
Refresh the parameter values by re-requesting all of them from the vehicle.

Reset all to defaults
Reset all parameters to their original default values.

Load from file / Save to file
Load parameters from an existing file or save your current parameter settings to a file.

Clear RC to Param
This clears all associations between RC transmitter controls and parameters. For more information see: Radio Setup > Param Tuning Channels.

Reboot Vehicle
Reboot the vehicle (required after changing some parameters).

parameter_reference - APM, Mission-planner

Parameter Reference

:::note This documentation was auto-generated from the source code for this PX4 version (using make parameters_metadata). :::

:::tip If a listed parameter is missing from the Firmware see: Finding/Updating Parameters. :::

UAVCAN Motor Parameters

UAVCAN GNSS

Airspeed Validator

Angular Velocity Control

Attitude Q estimator

Battery Calibration

Camera Capture

Camera Control

Camera trigger

Circuit Breaker

Commander