my drones I work with and at my disposal.
Edit me

my drones

yuneec - Edison, Simulink

Yuneec H and Intel Intellisense sensors

     
cgoet-manual mainteanance pilot-manual
     

Overview

Typhoon H Hexacopter

 
yuneecth
 

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

Type Details Type Details
frame   FC  
motor   ESC  
RC   mode  
weight   class  
battery   air-time  
configurator   last updated  
airframe      

FC

Spacing f3 6dot

camera

Aomway

DJI s900 - DJI, Assistant, Spreadwings

DJI S900 Wookong

overview

Type Details Type Details
frame   FC  
motor   ESC  
RC   mode  
weight   class  
battery   air-time  
configurator   last updated  
airframe      

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

 
s100A2
 

overview

   
manual training

DJI s900 - DJI, Assistant, Spreadwings

DJI S1000 Wookong

overview

Type Details Type Details
frame   FC  
motor   ESC  
RC   mode  
weight   class  
battery   air-time  
configurator   last updated  
airframe spreadwings from Gwangmyung    

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

 
xugong
 

overview

pixhawk4 vision - APM, Mission-planner, autonomy

Pixhawk vision

nazam - DJI, Assistant

DJI Naza m Lite

     
nazam nazam nazam
     
Type Details Type Details
frame   FC  
motor   ESC  
RC   mode  
weight   class  
battery   air-time  
configurator   last updated  
airframe      

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:

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

Grau pixracer double

Main Setup

Grau setup pixracer top

Grau setup pixracer bottom

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.

    Grau b Pixracer FrSkyS.Port Connection

    Pixracer FrSkyS.Port Connection

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

    Radio Connection

  • 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)

Grau ACSP4 2 roh

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.

Pixhawk4 mini

Wiring Chart Overview

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

*Pixhawk 4 Mini* Wiring Overview

:::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.

*Pixhawk 4 Mini* Orientation

:::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).

Connect compass/GPS to Pixhawk 4

:::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.

Pixhawk 4 - Power Management Board

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

Pin(s) or Connector Function
B+ Connect to ESC B+ to power the ESC
GND Connect to ESC Ground
PWR JST-GH 6-pin Connector, 5V 3A output
connect to Pixhawk 4 Mini POWER
BAT Power Input, connect to 2~12s LiPo Battery

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.

Pin Signal Volt
1(red) VCC +5V
2(black) VCC +5V
3(black) CURRENT +3.3V
4(black) VOLTAGE +3.3V
5(black) GND GND
6(black) GND GND

:::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.

    Pixhawk 4 Mini - Radio port for Spektrum receivers

  • PPM receivers connect to the PPM RC input port.

    Pixhawk 4 Mini - Radio port for PPM receivers

  • 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).

Pixhawk 4 Mini Telemetry

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.

Pixhawk 4 Mini SD Card

:::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

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.

Pixhawk 4 Wiring Overview

:::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).

Connect compass/GPS to Pixhawk 4

:::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.

Pixhawk 4 - Power Management Board

:::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. :::

PIN&Connector Function
I/O PWM-IN See note below for connection to Pixhawk 4
M1 I/O PWM OUT 1: connect signal wire to ESC of motor 1 here
M2 I/O PWM OUT 2: connect signal wire to ESC of motor 2 here
M3 I/O PWM OUT 3: connect signal wire to ESC of motor 3 here
M4 I/O PWM OUT 4: connect signal wire to ESC of motor 4 here
M5 I/O PWM OUT 5: connect signal wire to ESC of motor 5 here
M6 I/O PWM OUT 6: connect signal wire to ESC of motor 6 here
M7 I/O PWM OUT 7: connect signal wire to ESC of motor 7 here
M8 I/O PWM OUT 8: connect signal wire to ESC of motor 8 here
FMU PWM-IN See note below for connection to Pixhawk 4
FMU PWM-OUT If FMU PWM-IN is connected to Pixhawk 4, connect signal wires to ESC or signal, +, - wires to servos here
CAP&ADC-OUT connect to CAP & ADC IN port of Pixhawk 4
CAP&ADC-IN CAP&ADC input: Pinouts are printed on the back side of the board
B+ connect to ESC B+ to power the ESC
GND connect to ESC Ground
PWR1 5v output 3A, connect to Pixhawk 4 POWER 1
PWR2 5v output 3A, connect to Pixhawk 4 POWER 2
2~12S Power Input, connect to 12S LiPo Battery

:::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.

Airframe Reference Connection between Pixhawk 4 –> PM board
MAIN: motor I/O PWM OUT –> I/O PWM IN
MAIN: servo I/O PWM OUT –> FMU PWM IN
AUX: motor FMU PWM OUT –> I/O PWM IN
AUX: servo FMU PWM OUT –> FMU PWM IN

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.

Pin Signal Volt
1(red) VCC +5V
2(black) VCC +5V
3(black) CURRENT +3.3V
4(black) VOLTAGE +3.3V
5(black) GND GND
6(black) GND GND

:::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.

    Pixhawk 4 - Radio port for Spektrum receivers

  • PPM receivers connect to the PPM RC input port.

    Pixhawk 4 - Radio port for PPM receivers

  • 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).

Pixhawk 4/Telemetry Radio

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.

Pixhawk 4/SD Card

:::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

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.

Pixhawk Image

:::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.

Pixhawk Wiring Overview

:::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.

Pixhawk mounting and orientation

:::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).

Pixhawk mounting and orientation

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). :::

Connect compass/GPS to Pixhawk

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).

Pixhawk - Power Module

:::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. Pixhawk - Radio port for Spektrum receivers

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

  • 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).

Pixhawk/Telemetry Radio

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)

QuadCopter Pixhawk Wiring Infographic

Further information

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.

Pix32 v5 With Base

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).

Pix32 v5 Box

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.

Pix32 v5 Wiring Overview

:::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.

Pix32 v5 With Orientation

:::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.

Pix32 v5 with GPS

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.

Pix32 v5 With Power Module

  • 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.

    Pix32v5 rc receivers

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

    Pinouts

  • 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).

Pix32 v5 With Telemetry Radios

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.

Pix32 v5 With SD Card

:::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.

Pix32 v5 - Back Pinouts (Schematic)

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

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.

Durandal

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).

Durandal Box

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.

Durandal Wiring Overview

:::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.

Mounting/Orientation

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).

Connect compass/GPS to Durandal

:::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.

Durandal PM02v3 Power connections

  • 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.

    Durandal - DSM

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

    Durandal - Back Pinouts (Schematic)

  • 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).

Durandal/Telemetry Radio

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.

Durandal SD Card

:::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.

Durandal - Back Pinouts (Schematic)

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

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.

Cube Accessories

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.

Cube - Wiring Overview

  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)

Cube Mount - Direction of Front

:::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.

Cube Mount - Mounting Plate

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.

Here+ Connector Diagram

:::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).

Cube Buzzer

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.

Cube - RCIN

Spektrum Satellite Receivers

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

Cube - Spektrum

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.

Power Setup - MC

:::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).

Telemetry Radio

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).

Cube - Mount SDCard

:::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.

Cube - Motor Connections

:::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.

Cube - USB Connection to Computer

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

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.

V5+ AutoPilot - Hero Image

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.

V5+ AutoPilot

Main interface Function
Power1 Connect power module. Power input with analog voltage and current detection. Do not use a Digital PM on this connector!
Power2 Connect i2c smart battery.
TF CARD SD card for log storage (card pre-inserted in factory).
M1~M8 PWM outputs. Can be used to control motors or servos.
A1~A6 PWM outputs. Can be used to control motors or servos.
DSU7 Used for FMU debug, reading debug information.
I2C1/I2C2 Connect an I2C device such as an external compass.
CAN1/CAN2 Connect UAVCAN devices such as CAN GPS.
TYPE-C(USB) Connect to a computer for communication between the flight controller and the computer, such as loading firmware.
SBUS OUT Connect SBUS devices (e.g. camera gimbals).
GPS&SAFETY Connect to Neo GPS, which includes GPS, safety switch, buzzer interface.
TELEM1/TELEM2 Connect to the Telemetry System.
DSM/SBUS/RSSI Includes DSM, SBUS, RSSI signal input interface, DSM interface can be connected to DSM satellite receiver, SBUS interface to SBUS remote control receiver, RSSI for signal strength return module.

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

V5+ AutoPilot

:::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. :::

V5+ AutoPilot

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).

V5+ AutoPilot

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. :::

V5+ AutoPilot

:::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).

V5+ AutoPilot

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.

V5+ AutoPilot

Pinouts

Download V5+ pinouts from here.

Further Information

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.

Nano Hero Image

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.

quickstart

Main interface Function
Power Connect Power module; Provides Power and ANALOG voltage and current measurements.
PM2 Do not use with PX4
TF CARD SD card for log storage (comes with card)
M1~M8 PWM outputs. Can be used to control motors or servos.
A1~A3 Capture pins (not currently supported on PX4).
nARMED Indicates the FMU armed state. It is active low (low when armed).
DSU7 Used for FMU debug, reading debug information.
I2C2/I2C3/I2C4 Connect an I2C device such as an external compass.
CAN1/CAN2 Connect UAVCAN devices such as CAN GPS.
TYPE-C(USB) Connect to a computer for communication between the flight controller and the computer, such as loading firmware
GPS&SAFETY Connect to Neo GPS, which includes GPS, safety switch, buzzer interface.
TELEM1/TELEM2 Connect to the Telemetry System.
DSM/SBUS/RSSI Includes DSM, SBUS, RSSI signal input interface, DSM interface can be connected to DSM satellite receiver, SBUS interface to SBUS remote control receiver, RSSI for signal strength return module.

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

quickstart

:::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. :::

quickstart

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)

quickstart

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. :::

quickstart

:::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).

quickstart

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.

quickstart

Pinouts

V5 nano pinouts

Further Information

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.).

FC Heading Mark

FC Orientation

:::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.

Pixhawk Mounting foam 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
Name
Cloudship Maintainer: John Doe <john@example.com>

SYS_AUTOSTART = 2507

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)
Name
ThunderFly Auto-G2 Maintainer: ThunderFly s.r.o., Roman Dvorak <dvorakroman@thunderfly.cz>

SYS_AUTOSTART = 17002

Specific Outputs:

  • MAIN1: rotor_head_L
  • MAIN2: rotor_head_R
  • MAIN3: elevator
  • MAIN4: rudder
  • MAIN5: rudder (second, optional)
  • MAIN6: throttle
  • MAIN7: wheel

ThunderFly TF-G2 Maintainer: ThunderFly s.r.o., Roman Dvorak <dvorakroman@thunderfly.cz>

SYS_AUTOSTART = 17003

Specific Outputs:

  • MAIN2: rotor_head_L
  • MAIN3: rotor_head_R
  • MAIN4: rudder
  • MAIN5: throttle

Balloon

Balloon

Name
ThunderFly balloon TF-B1 Maintainer: ThunderFly s.r.o.

SYS_AUTOSTART = 18001

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)
Name
Esky (Big) Lama v4 Maintainer: Emmanuel Roussel

SYS_AUTOSTART = 15001

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
Name
Generic Dodecarotor cox geometry Maintainer: William Peale <develop707@gmail.com>

SYS_AUTOSTART = 24001

Helicopter

Common Outputs
  • MAIN1: main motor
  • MAIN2: front swashplate servo
  • MAIN3: right swashplate servo
  • MAIN4: left swashplate servo
  • MAIN5: tail-rotor servo
Name
Blade 130X Maintainer: Bart Slinger <bartslinger@gmail.com>

SYS_AUTOSTART = 16001

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
Name
Generic Hexarotor + geometry Maintainer: Lorenz Meier <lorenz@px4.io>

SYS_AUTOSTART = 7001

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
Name
Generic Hexarotor coaxial geometry Maintainer: Lorenz Meier <lorenz@px4.io>

SYS_AUTOSTART = 11001

Hexarotor x

Common Outputs
  • MAIN1: motor 1
  • MAIN2: motor 2
  • MAIN3: motor 3
  • MAIN4: motor 4
  • MAIN5: motor 5
  • MAIN6: motor 6
Name
Generic Hexarotor x geometry Maintainer: Lorenz Meier <lorenz@px4.io>

SYS_AUTOSTART = 6001

Specific Outputs:

  • AUX1: feed-through of RC AUX1 channel
  • AUX2: feed-through of RC AUX2 channel
  • AUX3: feed-through of RC AUX3 channel

UVify Draco-R Maintainer: Hyon Lim <lim@uvify.com>

SYS_AUTOSTART = 6002

Specific Outputs:

  • AUX1: feed-through of RC AUX1 channel
  • AUX2: feed-through of RC AUX2 channel

Hex X with control allocation Maintainer: Silvan Fuhrer

SYS_AUTOSTART = 6003

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
Name
Steadidrone MAVRIK Maintainer: Simon Wilks <simon@uaventure.com>

SYS_AUTOSTART = 12002

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
Name
Generic Octocopter + geometry Maintainer: Lorenz Meier <lorenz@px4.io>

SYS_AUTOSTART = 9001

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
Name
Generic 10" Octo coaxial geometry Maintainer: Lorenz Meier <lorenz@px4.io>

SYS_AUTOSTART = 12001

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
Name
Generic Octocopter X geometry Maintainer: Lorenz Meier <lorenz@px4.io>

SYS_AUTOSTART = 8001

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
Name
Generic 10" Quad + geometry Maintainer: Lorenz Meier <lorenz@px4.io>

SYS_AUTOSTART = 5001

Quadrotor H

Name
Reaper 500 Quad Maintainer: Blankered

SYS_AUTOSTART = 4040

Specific 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

BetaFPV Beta75X 2S Brushless Whoop Maintainer: Beat Kueng <beat-kueng@gmx.net>

SYS_AUTOSTART = 4041

Specific Outputs:

  • MAIN1: motor 1
  • MAIN2: motor 2
  • MAIN3: motor 3
  • MAIN4: motor 4

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
Name
Team Blacksheep Discovery Maintainer: Lorenz Meier <lorenz@px4.io>

SYS_AUTOSTART = 10015

Specific 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

3DR Iris Quadrotor Maintainer: Lorenz Meier <lorenz@px4.io>

SYS_AUTOSTART = 10016

Specific Outputs:

  • MAIN1: motor 1
  • MAIN2: motor 2
  • MAIN3: motor 3
  • MAIN4: motor 4

Steadidrone QU4D Maintainer: Lorenz Meier <lorenz@px4.io>

SYS_AUTOSTART = 10017

Specific 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

Team Blacksheep Discovery Endurance Maintainer: Simon Wilks <simon@uaventure.com>

SYS_AUTOSTART = 10018

Specific 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

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
Name
Spedix S250AQ Maintainer: Lorenz Meier <lorenz@px4.io>

SYS_AUTOSTART = 4051

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
Name
Generic Quadcopter Maintainer: Lorenz Meier <lorenz@px4.io>

SYS_AUTOSTART = 4001

Specific 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

Lumenier QAV-R (raceblade) 5" arms Maintainer: James Goppert <james.goppert@gmail.com>

SYS_AUTOSTART = 4003

Lumenier QAV250 Maintainer: Lorenz Meier <lorenz@px4.io>

SYS_AUTOSTART = 4009

DJI F330 w/ DJI ESCs Maintainer: Lorenz Meier <lorenz@px4.io>

SYS_AUTOSTART = 4010

DJI F450 w/ DJI ESCs Maintainer: Lorenz Meier <lorenz@px4.io>

SYS_AUTOSTART = 4011

S500 Generic Maintainer: Lorenz Meier <lorenz@px4.io>

SYS_AUTOSTART = 4014

Holybro S500 Maintainer: Lorenz Meier <lorenz@px4.io>

SYS_AUTOSTART = 4015

PX4 Vision DevKit Platform Maintainer: John Doe <john@example.com>

SYS_AUTOSTART = 4016

Specific Outputs:

  • MAIN1: motor 1
  • MAIN2: motor 2
  • MAIN3: motor 3
  • MAIN4: motor 4

NXP HoverGames Maintainer: Iain Galloway <iain.galloway@nxp.com>

SYS_AUTOSTART = 4017

Specific Outputs:

  • MAIN1: motor 1
  • MAIN2: motor 2
  • MAIN3: motor 3
  • MAIN4: motor 4

S500 with control allocation Maintainer: Silvan Fuhrer

SYS_AUTOSTART = 4018

3DR Solo Maintainer: Andreas Antener <andreas@uaventure.com>

SYS_AUTOSTART = 4030

3DR DIY Quad Maintainer: Lorenz Meier <lorenz@px4.io>

SYS_AUTOSTART = 4031

Generic 250 Racer Maintainer: Lorenz Meier <lorenz@px4.io>

SYS_AUTOSTART = 4050

HolyBro QAV250 Maintainer: Beat Kueng <beat-kueng@gmx.net>

SYS_AUTOSTART = 4052

Holybro Kopis 2 Maintainer: Beat Kueng <beat@px4.io>

SYS_AUTOSTART = 4053

DJI Matrice 100 Maintainer: James Goppert <james.goppert@gmail.com>

SYS_AUTOSTART = 4060

Advanced Technology Labs (ATL) Mantis EDU

SYS_AUTOSTART = 4061

Specific Outputs:

  • MAIN1: motor 1
  • MAIN2: motor 2
  • MAIN3: motor 3
  • MAIN4: motor 4

UVify IFO Maintainer: Hyon Lim <lim@uvify.com>

SYS_AUTOSTART = 4071

Specific Outputs:

  • MAIN1: motor 1
  • MAIN2: motor 2
  • MAIN3: motor 3
  • MAIN4: motor 4

UVify Draco Maintainer: Hyon Lim <lim@uvify.com>

SYS_AUTOSTART = 4072

Specific Outputs:

  • MAIN1: motor 1
  • MAIN2: motor 2
  • MAIN3: motor 3
  • MAIN4: motor 4

UVify IFO Maintainer: Hyon Lim <lim@uvify.com>

SYS_AUTOSTART = 4073

Specific Outputs:

  • MAIN1: motor 1
  • MAIN2: motor 2
  • MAIN3: motor 3
  • MAIN4: motor 4

ZMR250 Racer Maintainer: Anton Matosov <anton.matosov@gmail.com>

SYS_AUTOSTART = 4080

NanoMind 110 Quad Maintainer: Henry Zhang <zhanghui629@gmail.com>

SYS_AUTOSTART = 4090

Teal One Maintainer: Matt McFadden <matt.mcfadden@tealdrones.com>

SYS_AUTOSTART = 4250

Specific Outputs:

  • MAIN1: motor 1
  • MAIN2: motor 2
  • MAIN3: motor 3
  • MAIN4: motor 4

COEX Clover 4 Maintainer: Oleg Kalachev <okalachev@gmail.com>

SYS_AUTOSTART = 4500

Crazyflie 2 Maintainer: Dennis Shtatov <densht@gmail.com>

SYS_AUTOSTART = 4900

Crazyflie 2.1 Maintainer: Dennis Shtatov <densht@gmail.com>

SYS_AUTOSTART = 4901

Simulation (Copter)

Name
HIL Quadcopter X Maintainer: Lorenz Meier <lorenz@px4.io>

SYS_AUTOSTART = 1001

SIH Quadcopter X Maintainer: Romain Chiappinelli <romain.chiap@gmail.com>

SYS_AUTOSTART = 1100

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
Name
Tilt-Quadrotor Maintainer: Ricardo Marques <marques.ricardo17@gmail.com>

SYS_AUTOSTART = 4100

Tricopter Y+

Common Outputs
  • MAIN1: motor 1
  • MAIN2: motor 2
  • MAIN3: motor 3
  • MAIN4: yaw servo
Name
Generic Tricopter Y+ Geometry Maintainer: Trent Lukaczyk <aerialhedgehog@gmail.com>

SYS_AUTOSTART = 14001

Tricopter Y-

Common Outputs
  • MAIN1: motor 1
  • MAIN2: motor 2
  • MAIN3: motor 3
  • MAIN4: yaw servo
Name
Generic Tricopter Y- Geometry Maintainer: Trent Lukaczyk <aerialhedgehog@gmail.com>

SYS_AUTOSTART = 14002

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
Name
Generic Flying Wing

SYS_AUTOSTART = 3000

Specific Outputs:

  • MAIN1: left aileron
  • MAIN2: right aileron
  • MAIN4: throttle

IO Camflyer Maintainer: Simon Wilks <simon@uaventure.com>

SYS_AUTOSTART = 3030

Specific Outputs:

  • MAIN1: left aileron
  • MAIN2: right aileron
  • MAIN4: throttle

Phantom FPV Flying Wing Maintainer: Simon Wilks <simon@uaventure.com>

SYS_AUTOSTART = 3031

Specific Outputs:

  • MAIN1: left aileron
  • MAIN2: right aileron
  • MAIN4: throttle

Skywalker X5 Flying Wing Maintainer: Julian Oes <julian@px4.io>

SYS_AUTOSTART = 3032

Specific Outputs:

  • MAIN1: left aileron
  • MAIN2: right aileron
  • MAIN4: throttle

Wing Wing (aka Z-84) Flying Wing Maintainer: Lorenz Meier <lorenz@px4.io>

SYS_AUTOSTART = 3033

Specific Outputs:

  • MAIN1: left aileron
  • MAIN2: right aileron
  • MAIN4: throttle

FX-79 Buffalo Flying Wing Maintainer: Simon Wilks <simon@uaventure.com>

SYS_AUTOSTART = 3034

Specific Outputs:

  • MAIN1: right aileron
  • MAIN2: left aileron
  • MAIN4: throttle

Viper Maintainer: Simon Wilks <simon@uaventure.com>

SYS_AUTOSTART = 3035

Specific Outputs:

  • MAIN1: left aileron
  • MAIN2: right aileron
  • MAIN4: throttle

Sparkle Tech Pigeon Maintainer: Simon Wilks <simon@uaventure.com>

SYS_AUTOSTART = 3036

Specific Outputs:

  • MAIN1: left aileron
  • MAIN2: right aileron
  • MAIN4: throttle

Modified Parrot Disco Maintainer: Jan Liphardt <JTLiphardt@gmail.com>

SYS_AUTOSTART = 3037

Specific Outputs:

  • MAIN1: left aileron
  • MAIN2: right aileron
  • MAIN4: throttle

TBS Caipirinha Maintainer: Lorenz Meier <lorenz@px4.io>

SYS_AUTOSTART = 3100

Specific Outputs:

  • MAIN1: left aileron
  • MAIN2: right aileron
  • MAIN4: throttle

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
Name
Applied Aeronautics Albatross Maintainer: Andreas Antener <andreas@uaventure.com>

SYS_AUTOSTART = 2106

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
Name
X-UAV Mini Talon Maintainer: Friedrich Beckmann <friedrich.beckmann@hs-augsburg.de>

SYS_AUTOSTART = 2200

Simulation (Plane)

Common Outputs
  • MAIN1: aileron
  • MAIN2: elevator
  • MAIN3: rudder
  • MAIN4: throttle
  • MAIN5: flaps
  • MAIN6: gear
Name
HILStar (XPlane) Maintainer: Lorenz Meier <lorenz@px4.io>

SYS_AUTOSTART = 1000

SIH plane AERT Maintainer: Romain Chiappinelli <romain.chiap@gmail.com>

SYS_AUTOSTART = 1101

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
Name
Standard Plane Maintainer: Lorenz Meier <lorenz@px4.io>

SYS_AUTOSTART = 2100

Specific Outputs:

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

Bormatec Maja Maintainer: Andreas Antener <andreas@uaventure.com>

SYS_AUTOSTART = 2105

Specific Outputs:

  • MAIN1: aileron
  • MAIN2: aileron
  • MAIN3: elevator
  • MAIN4: rudder
  • MAIN5: throttle
  • MAIN6: wheel
  • MAIN7: flaps

Rover

Rover

Name
Generic Ground Vehicle

SYS_AUTOSTART = 50000

Specific Outputs:

  • MAIN2: steering
  • MAIN4: throttle

Aion Robotics R1 UGV Maintainer: Timothy Scott

SYS_AUTOSTART = 50003

Specific Outputs:

  • MAIN0: Speed of left wheels
  • MAIN1: Speed of right wheels

NXP Cup car: DF Robot GPX Maintainer: Katrin Moritz

SYS_AUTOSTART = 50004

Specific Outputs:

  • MAIN2: Steering servo
  • MAIN3: Speed of left wheels
  • MAIN4: Speed of right wheels

Underwater Robot

Underwater Robot

Name
Generic Underwater Robot

SYS_AUTOSTART = 60000

HippoCampus UUV (Unmanned Underwater Vehicle) Maintainer: Daniel Duecker <daniel.duecker@tuhh.de>

SYS_AUTOSTART = 60001

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
Name
BlueROV2 (Heavy Configuration) Maintainer: Thies Lennart Alff <thies.lennart.alff@tuhh.de>

SYS_AUTOSTART = 60002

VTOL

Standard VTOL

Name
HIL Standard VTOL QuadPlane Maintainer: Roman Bapst <roman@auterion.com>

SYS_AUTOSTART = 1002

Generic Quadplane VTOL

SYS_AUTOSTART = 13000

Specific Outputs:

  • MAIN1: motor 1
  • MAIN2: motor 2
  • MAIN3: motor 3
  • MAIN4: motor 4
  • AUX1: Aileron 1
  • AUX2: Aileron 2
  • AUX3: Elevator
  • AUX4: Rudder
  • AUX5: Throttle

Fun Cub Quad VTOL Maintainer: Simon Wilks <simon@uaventure.com>

SYS_AUTOSTART = 13005

Specific Outputs:

  • MAIN1: motor 1
  • MAIN2: motor 2
  • MAIN3: motor 3
  • MAIN4: motor 4
  • AUX1: Aileron 1
  • AUX2: Aileron 2
  • AUX3: Elevator
  • AUX4: Rudder
  • AUX5: Throttle

Generic quad delta VTOL Maintainer: Simon Wilks <simon@uaventure.com>

SYS_AUTOSTART = 13006

Specific Outputs:

  • MAIN1: motor 1
  • MAIN2: motor 2
  • MAIN3: motor 3
  • MAIN4: motor 4
  • AUX1: Right elevon
  • AUX2: Left elevon
  • AUX3: Motor

Generic AAVVT v-tail plane airframe with Quad VTOL. Maintainer: Sander Smeets <sander@droneslab.com>

SYS_AUTOSTART = 13007

QuadRanger Maintainer: Sander Smeets <sander@droneslab.com>

SYS_AUTOSTART = 13008

Sparkle Tech Ranger VTOL Maintainer: Andreas Antener <andreas@uaventure.com>

SYS_AUTOSTART = 13009

Vertical Technologies DeltaQuad Maintainer: Sander Smeets <sander@droneslab.com>

SYS_AUTOSTART = 13013

Specific Outputs:

  • MAIN1: motor 1
  • MAIN2: motor 2
  • MAIN3: motor 3
  • MAIN4: motor 4
  • MAIN5: Right elevon
  • MAIN6: Left elevon
  • MAIN7: Pusher motor
  • MAIN8: Pusher reverse channel

BabyShark VTOL Maintainer: Silvan Fuhrer <silvan@auterion.com>

SYS_AUTOSTART = 13014

Specific Outputs:

  • MAIN1: Ailerons
  • MAIN2: A-tail left
  • MAIN3: Pusher motor
  • MAIN4: A-tail right
  • MAIN5: motor 1
  • MAIN6: motor 2
  • MAIN7: motor 3
  • MAIN8: motor 4

VTOL Duo Tailsitter

Common Outputs
  • MAIN1: motor right
  • MAIN2: motor left
  • MAIN5: elevon right
  • MAIN6: elevon left
Name
Caipiroshka Duo Tailsitter Maintainer: Roman Bapst <roman@px4.io>

SYS_AUTOSTART = 13001

Generic Tailsitter Maintainer: Roman Bapst <roman@px4.io>

SYS_AUTOSTART = 13200

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
Name
Generic Octoplane VTOL Maintainer: John Doe <john@example.com>

SYS_AUTOSTART = 13050

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
Name
Quadrotor X Tailsitter Maintainer: Roman Bapst <roman@px4.io>

SYS_AUTOSTART = 13003

Quadrotor + Tailsitter Maintainer: Roman Bapst <roman@px4.io>

SYS_AUTOSTART = 13004

VTOL Tiltrotor

Name
BirdsEyeView Aerobotics FireFly6 Maintainer: Roman Bapst <roman@uaventure.com>

SYS_AUTOSTART = 13002

Specific Outputs:

  • MAIN1: Front right motor bottom
  • MAIN2: Front right motor top
  • MAIN3: Back motor bottom
  • MAIN4: Back motor top
  • MAIN5: Front left motor bottom
  • MAIN6: Front left motor top
  • AUX1: Tilt servo
  • AUX2: Elevon 1
  • AUX3: Elevon 2
  • AUX4: Gear

CruiseAder Claire Maintainer: Samay Siga <samay_s@icloud.com>

SYS_AUTOSTART = 13010

E-flite Convergence Maintainer: Andreas Antener <andreas@uaventure.com>

SYS_AUTOSTART = 13012

Specific Outputs:

  • MAIN1: Motor right
  • MAIN2: Motor left
  • MAIN3: Motor back
  • MAIN4: empty
  • MAIN5: Tilt servo right
  • MAIN6: Tilt servo left
  • MAIN7: Elevon right
  • MAIN8: Elevon left

Generic Quadplane VTOL Tiltrotor

SYS_AUTOSTART = 13030

Specific Outputs:

  • MAIN1: motor 1
  • MAIN2: motor 2
  • MAIN3: motor 3
  • MAIN4: motor 4
  • AUX1: Motor tilt front left
  • AUX2: Motor tilt front right
  • AUX3: Motor tilt rear left
  • AUX4: Motor tilt rear right
  • AUX5: Aileron left
  • AUX6: Aileron right
  • AUX7: Elevator
  • AUX8: Rudder

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:

Parameter Description
NAV_TRAFF_AVOID Enable traffic avoidance mode specify avoidance response. 0: Disable, 1: Warn only, 2: Return mode, 3: Land mode.
NAV_TRAFF_A_RADM Set traffic avoidance trigger distance for manned aviation.
NAV_TRAFF_A_RADU Set traffic avoidance trigger distance for unmanned aviation.

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

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:

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.

Pin Signal Volt
1 (red) RX (IN) +5V tolerant
2 (blk) TX (OUT)  
3 (blk) Power +4 to 6V
4 (blk) GND GND

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.

Pin Signal Volt
1 (red) VCC +4V to +36V
2 (blk) TX (OUT) +3.3V
3 (blk) RX (IN) +3.3V
4 (blk) - +3.3V
5 (blk) - +3.3V
6 (blk) GND GND

:::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:

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:

Parameter Description
NAV_TRAFF_AVOID Enable traffic avoidance mode specify avoidance response. 0: Disable, 1: Warn only, 2: Return mode, 3: Land mode.
NAV_TRAFF_A_RADM Set traffic avoidance distance for manned aviation
NAV_TRAFF_A_RADU Set traffic avoidance distance for unmanned aviation

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

- 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:

Architecture

:::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:

Delivery Groups

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

    High Latency Link Settings

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:

udp2rabbit message acknowledge

Running the System

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

    Connect the High Latency 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:

    Link Toolbar

    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:

      Prioritylink Selection

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.

Parameter Description
LTEST_MODE Landing target is moving (0) or stationary (1). Default is moving.
PLD_HACC_RAD Horizontal acceptance radius, within which the vehicle will start descending. Default is 0.2m.
PLD_BTOUT Landing Target Timeout, after which the target is assumed lost. Default is 5 seconds.
PLD_FAPPR_ALT Final approach altitude. Default is 0.1 metres.
PLD_MAX_SRCH Maximum number of search attempts in an required landing.
RTL_PLD_MD RTL precision land mode. 0: disabled, 1: Opportunistic, 2: Required.

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.

Precision Landing 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:

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:

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:

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.

Metric Minimum required Average Value Units Notes
eph < 3 (EKF2_REQ_EPH) 0.8 m Standard deviation of horizontal position error
epv < 5 (EKF2_REQ_EPV) 1.5 m Standard deviation of vertical position error
Number of satellites ≥6 (EKF2_REQ_NSATS) 14 -  
sacc < 0.5 (EKF2_REQ_SACC) 0.2 m/s Standard deviation of horizontal speed error
fix type ≥ 3 4 - 0-1: no fix, 2: 2D fix, 3: 3D fix, 4: RTCM code differential, 5: Real-Time Kinematic, float, 6: Real-Time Kinematic, fixed, 8: Extrapolated
PDOP < 2.5 (EKF2_REQ_PDOP) 1.0 - Position dilution of precision
hpos drift rate < 0.1 (EKF2_REQ_HDRIFT) 0.01 m/s Drift rate calculated from reported GNSS position (when stationary).
vpos drift rate < 0.2 (EKF2_REQ_VDRIFT) 0.02 m/s Drift rate calculated from reported GNSS altitude (when stationary).
hspd < 0.1 (EKF2_REQ_HDRIFT) 0.01 m/s Filtered magnitude of reported GNSS horizontal velocity.
vspd < 0.2 (EKF2_REQ_VDRIFT) 0.02 m/s Filtered magnitude of reported GNSS vertical velocity.

:::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.

EKF_AID_MASK value Set bits Description
321 GPS + EV_VEL + ROTATE_EV Heading w.r.t. North (Recommended)
73 GPS + EV_POS + ROTATE_EV Heading w.r.t. North (Not recommended, use EV_VEL instead)
24 EV_POS + EV_YAW Heading w.r.t. external vision frame
72 EV_POS + ROTATE_EV Heading w.r.t. North
272 EV_VEL + EV_YAW Heading w.r.t. external vision frame
320 EV_VEL + ROTATE_EV Heading w.r.t. North
280 EV_POS + EV_VEL + EV_YAW Heading w.r.t. external vision frame
328 EV_POS + EV_VEL + ROTATE_EV Heading w.r.t. North

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

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

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:

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:

Position, Velocity, Height and Magnetometer Test Ratios

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.

Vibration metrics - successful

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.

GPS glitch - test ratios

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

GPS Glitch - reported receiver accuracy

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.

GPS Glitch - velocity innovations

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.

GPS Data Loss - in SITL

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.

Barometer ground effect

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. 1
  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 stationary2, 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. 3
  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 2, warm it slowly to the maximum required operating temperature. 3
  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:

Thermal calibration gyro

Thermal calibration accel

Thermal calibration barometer

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.


  1. The SYS_CAL_ACCEL, SYS_CAL_BARO and SYS_CAL_GYRO parameters are reset to 0 when the calibration is started. 

  2. Calibration of the barometric pressure sensor offsets requires a stable air pressure environment. The air pressure will change slowly due to weather and inside buildings can change rapidly due to external wind fluctuations and HVAC system operation.  2

  3. Care must be taken when warming a cold soaked board to avoid formation of condensation on the board that can cause board damage under some circumstances.  2

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.

Parameter Description
COM_RC_ARM_HYST Time that RC stick must be held in arm/disarm position before arming/disarming occurs (default: 1 second).

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.

Parameter Description
RC_MAP_ARM_SW RC arm switch channel (default: 0 - unassigned). If defined, the specified RC channel (button/switch) is used for arming instead of a stick gesture.
Note:
- This setting disables the stick gesture!
- This setting applies to RC controllers. It does not apply to Joystick controllers that are connected via QGroundControl.
COM_ARM_SWISBTN Arm switch is a momentary button.
- 0: Arm switch is a 2-position switch where arm/disarm commands are sent on switch transitions.
-1: Arm switch is a button or momentary button where the arm/disarm command ae sent after holding down button for set time (COM_RC_ARM_HYST).

:::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.

Parameter Description
COM_DISARM_LAND Time-out for auto disarm after landing. Default: 2s (-1 to disable).
COM_DISARM_PRFLT Time-out for auto disarm if too slow to takeoff. Default: 10s (<=0 to disable).

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

Parameter Description
COM_PREARM_MODE Condition to enter prearmed mode. 0: Disabled, 1: Safety switch (prearm mode enabled by safety switch; if no switch present cannot be enabled), 2: Always (prearm mode enabled from power up). Default: 1 (safety button).
CBRK_IO_SAFETY Circuit breaker for IO safety.

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).

Parameters 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).

Parameters Screen

:::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).

Changing a parameter value

:::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.

Tools menu

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

NameDescriptionMin > Max (Incr.)DefaultUnits
ctl_bw (INT32) Speed controller bandwidth

Comment: Speed controller bandwidth, in Hz. Higher values result in faster speed and current rise times, but may result in overshoot and higher current consumption. For fixed-wing aircraft, this value should be less than 50 Hz; for multirotors, values up to 100 Hz may provide improvements in responsiveness.

10 > 250 75 Hz
ctl_dir (INT32) Reverse direction

Comment: Motor spin direction as detected during initial enumeration. Use 0 or 1 to reverse direction.

0 > 1 1
ctl_gain (FLOAT) Speed (RPM) controller gain

Comment: Speed (RPM) controller gain. Determines controller aggressiveness; units are amp-seconds per radian. Systems with higher rotational inertia (large props) will need gain increased; systems with low rotational inertia (small props) may need gain decreased. Higher values result in faster response, but may result in oscillation and excessive overshoot. Lower values result in a slower, smoother response.

0.00 > 1.00 1 C/rad
ctl_hz_idle (FLOAT) Idle speed (e Hz)

Comment: Idle speed (e Hz)

0.0 > 100.0 3.5 Hz
ctl_start_rate (INT32) Spin-up rate (e Hz/s)

Comment: Spin-up rate (e Hz/s)

5 > 1000 25 1/s^2
esc_index (INT32) Index of this ESC in throttle command messages.

Comment: Index of this ESC in throttle command messages.

0 > 15 0
id_ext_status (INT32) Extended status ID

Comment: Extended status ID

1 > 1000000 20034
int_ext_status (INT32) Extended status interval (µs)

Comment: Extended status interval (µs)

0 > 1000000 50000 us
int_status (INT32) ESC status interval (µs)

Comment: ESC status interval (µs)

? > 1000000 50000 us
mot_i_max (FLOAT) Motor current limit in amps

Comment: Motor current limit in amps. This determines the maximum current controller setpoint, as well as the maximum allowable current setpoint slew rate. This value should generally be set to the continuous current rating listed in the motor’s specification sheet, or set equal to the motor’s specified continuous power divided by the motor voltage limit.

1 > 80 12 A
mot_kv (INT32) Motor Kv in RPM per volt

Comment: Motor Kv in RPM per volt. This can be taken from the motor’s specification sheet; accuracy will help control performance but some deviation from the specified value is acceptable.

0 > 4000 2300 rpm/V
mot_ls (FLOAT) READ ONLY: Motor inductance in henries.

Comment: READ ONLY: Motor inductance in henries. This is measured on start-up.

0.0 H
mot_num_poles (INT32) Number of motor poles.

Comment: Number of motor poles. Used to convert mechanical speeds to electrical speeds. This number should be taken from the motor’s specification sheet.

2 > 40 14
mot_rs (FLOAT) READ ONLY: Motor resistance in ohms

Comment: READ ONLY: Motor resistance in ohms. This is measured on start-up. When tuning a new motor, check that this value is approximately equal to the value shown in the motor’s specification sheet.

0.0 Ohm
mot_v_accel (FLOAT) Acceleration limit (V)

Comment: Acceleration limit (V)

0.01 > 1.00 0.5 V
mot_v_max (FLOAT) Motor voltage limit in volts

Comment: Motor voltage limit in volts. The current controller’s commanded voltage will never exceed this value. Note that this may safely be above the nominal voltage of the motor; to determine the actual motor voltage limit, divide the motor’s rated power by the motor current limit.

0 > ? 14.8 V

UAVCAN GNSS

NameDescriptionMin > Max (Incr.)DefaultUnits
gnss.dyn_model (INT32) GNSS dynamic model

Comment: Dynamic model used in the GNSS positioning engine. 0 – Automotive, 1 – Sea, 2 – Airborne.

Values:
  • 0: Automotive
  • 1: Sea
  • 2: Airborne
0 > 2 2
gnss.old_fix_msg (INT32) Broadcast old GNSS fix message

Comment: Broadcast the old (deprecated) GNSS fix message uavcan.equipment.gnss.Fix alongside the new alternative uavcan.equipment.gnss.Fix2. It is recommended to disable this feature to reduce the CAN bus traffic.

Values:
  • 0: Fix2
  • 1: Fix and Fix2
0 > 1 1
gnss.warn_dimens (INT32) device health warning

Comment: Set the device health to Warning if the dimensionality of the GNSS solution is less than this value. 3 for the full (3D) solution, 2 for planar (2D) solution, 1 for time-only solution, 0 disables the feature.

Values:
  • 0: disables the feature
  • 1: time-only solution
  • 2: planar (2D) solution
  • 3: full (3D) solution
0 > 3 0
gnss.warn_sats (INT32)

Comment: Set the device health to Warning if the number of satellites used in the GNSS solution is below this threshold. Zero disables the feature

0
uavcan.pubp-pres (INT32)

Comment: Set the device health to Warning if the number of satellites used in the GNSS solution is below this threshold. Zero disables the feature

0 > 1000000 0 us

Airspeed Validator

NameDescriptionMin > Max (Incr.)DefaultUnits
ASPD_BETA_GATE (INT32) Airspeed Selector: Gate size for sideslip angle fusion

Comment: Sets the number of standard deviations used by the innovation consistency test.

1 > 5 1 SD
ASPD_BETA_NOISE (FLOAT) Airspeed Selector: Wind estimator sideslip measurement noise

Comment: Sideslip measurement noise of the internal wind estimator(s) of the airspeed selector.

0 > 1 0.3 rad
ASPD_DO_CHECKS (INT32) Enable checks on airspeed sensors

Comment: If set to true then the data comming from the airspeed sensors is checked for validity. Only applied if ASPD_PRIMARY > 0.

Enabled (1)
ASPD_FALLBACK_GW (INT32) Enable fallback to sensor-less airspeed estimation

Comment: If set to true and airspeed checks are enabled, it will use a sensor-less airspeed estimation based on groundspeed minus windspeed if no other airspeed sensor available to fall back to.

Values:
  • 0: Disable fallback to sensor-less estimation
  • 1: Enable fallback to sensor-less estimation
Disabled (0)
ASPD_FS_INNOV (FLOAT) Airspeed failsafe consistency threshold

Comment: This specifies the minimum airspeed test ratio required to trigger a failsafe. Larger values make the check less sensitive, smaller values make it more sensitive. Start with a value of 1.0 when tuning. When tas_test_ratio is > 1.0 it indicates the inconsistency between predicted and measured airspeed is large enough to cause the wind EKF to reject airspeed measurements. The time required to detect a fault when the threshold is exceeded depends on the size of the exceedance and is controlled by the ASPD_FS_INTEG parameter.

0.5 > 3.0 1.0
ASPD_FS_INTEG (FLOAT) Airspeed failsafe consistency delay

Comment: This sets the time integral of airspeed test ratio exceedance above ASPD_FS_INNOV required to trigger a failsafe. For example if ASPD_FS_INNOV is 1 and estimator_status.tas_test_ratio is 2.0, then the exceedance is 1.0 and the integral will rise at a rate of 1.0/second. A negative value disables the check. Larger positive values make the check less sensitive, smaller positive values make it more sensitive.

? > 30.0 5.0 s
ASPD_FS_T_START (INT32) Airspeed failsafe start delay

Comment: Delay before switching back to using airspeed sensor if checks indicate sensor is good. Set to a negative value to disable the re-enabling in flight.

-1 > 1000 -1 s
ASPD_FS_T_STOP (INT32) Airspeed failsafe stop delay

Comment: Delay before stopping use of airspeed sensor if checks indicate sensor is bad.

1 > 10 2 s
ASPD_PRIMARY (INT32) Index or primary airspeed measurement source Values:
  • -1: Disabled
  • 0: Groundspeed minus windspeed
  • 1: First airspeed sensor
  • 2: Second airspeed sensor
  • 3: Third airspeed sensor

Reboot required: true

1
ASPD_SCALE (FLOAT) Airspeed scale (scale from IAS to CAS)

Comment: Scale can either be entered manually, or estimated in-flight by setting ASPD_SCALE_EST to 1.

0.5 > 1.5 1.0
ASPD_SCALE_EST (INT32) Automatic airspeed scale estimation on

Comment: Turns the automatic airspeed scale (scale from IAS to CAS) on or off. It is recommended to fly level altitude while performing the estimation. Set to 1 to start estimation (best when already flying). Set to 0 to end scale estimation. The estimated scale is then saved using the ASPD_SCALE parameter.

Disabled (0)
ASPD_SC_P_NOISE (FLOAT) Airspeed Selector: Wind estimator true airspeed scale process noise

Comment: Airspeed scale process noise of the internal wind estimator(s) of the airspeed selector.

0 > 0.1 0.0001 Hz
ASPD_TAS_GATE (INT32) Airspeed Selector: Gate size for true airspeed fusion

Comment: Sets the number of standard deviations used by the innovation consistency test.

1 > 5 3 SD
ASPD_TAS_NOISE (FLOAT) Airspeed Selector: Wind estimator true airspeed measurement noise

Comment: True airspeed measurement noise of the internal wind estimator(s) of the airspeed selector.

0 > 4 1.4 m/s
ASPD_W_P_NOISE (FLOAT) Airspeed Selector: Wind estimator wind process noise

Comment: Wind process noise of the internal wind estimator(s) of the airspeed selector.

0 > 1 0.1 m/s^2

Angular Velocity Control

NameDescriptionMin > Max (Incr.)DefaultUnits
AVC_X_D (FLOAT) Body X axis angular velocity D gain

Comment: Body X axis angular velocity differential gain. Small values help reduce fast oscillations. If value is too big oscillations will appear again.

0.0 > 2.0 (0.01) 0.36
AVC_X_FF (FLOAT) Body X axis angular velocity feedforward gain

Comment: Improves tracking performance.

0.0 > ? 0.0 Nm/(rad/s)
AVC_X_I (FLOAT) Body X axis angular velocity I gain

Comment: Body X axis angular velocity integral gain. Can be set to compensate static thrust difference or gravity center offset.

0.0 > ? (0.01) 0.2 Nm/rad
AVC_X_I_LIM (FLOAT) Body X axis angular velocity integrator limit

Comment: Body X axis angular velocity integrator limit. Can be set to increase the amount of integrator available to counteract disturbances or reduced to improve settling time after large roll moment trim changes.

0.0 > ? (0.01) 0.3 Nm
AVC_X_K (FLOAT) Body X axis angular velocity controller gain

Comment: Global gain of the controller. This gain scales the P, I and D terms of the controller: output = AVC_X_K * (AVC_X_P * error + AVC_X_I * error_integral + AVC_X_D * error_derivative) Set AVC_X_P=1 to implement a PID in the ideal form. Set AVC_X_K=1 to implement a PID in the parallel form.

0.0 > 5.0 (0.0005) 1.0
AVC_X_P (FLOAT) Body X axis angular velocity P gain

Comment: Body X axis angular velocity proportional gain, i.e. control output for angular speed error 1 rad/s.

0.0 > 20.0 (0.01) 18. 1/s
AVC_Y_D (FLOAT) Body Y axis angular velocity D gain

Comment: Body Y axis angular velocity differential gain. Small values help reduce fast oscillations. If value is too big oscillations will appear again.

0.0 > 2.0 (0.01) 0.36
AVC_Y_FF (FLOAT) Body Y axis angular velocity feedforward

Comment: Improves tracking performance.

0.0 > ? 0.0 Nm/(rad/s)
AVC_Y_I (FLOAT) Body Y axis angular velocity I gain

Comment: Body Y axis angular velocity integral gain. Can be set to compensate static thrust difference or gravity center offset.

0.0 > ? (0.01) 0.2 Nm/rad
AVC_Y_I_LIM (FLOAT) Body Y axis angular velocity integrator limit

Comment: Body Y axis angular velocity integrator limit. Can be set to increase the amount of integrator available to counteract disturbances or reduced to improve settling time after large pitch moment trim changes.

0.0 > ? (0.01) 0.3 Nm
AVC_Y_K (FLOAT) Body Y axis angular velocity controller gain

Comment: Global gain of the controller. This gain scales the P, I and D terms of the controller: output = AVC_Y_K * (AVC_Y_P * error + AVC_Y_I * error_integral + AVC_Y_D * error_derivative) Set AVC_Y_P=1 to implement a PID in the ideal form. Set AVC_Y_K=1 to implement a PID in the parallel form.

0.0 > 20.0 (0.0005) 1.0
AVC_Y_P (FLOAT) Body Y axis angular velocity P gain

Comment: Body Y axis angular velocity proportional gain, i.e. control output for angular speed error 1 rad/s.

0.0 > 20.0 (0.01) 18. 1/s
AVC_Z_D (FLOAT) Body Z axis angular velocity D gain

Comment: Body Z axis angular velocity differential gain. Small values help reduce fast oscillations. If value is too big oscillations will appear again.

0.0 > 2.0 (0.01) 0.0
AVC_Z_FF (FLOAT) Body Z axis angular velocity feedforward

Comment: Improves tracking performance.

0.0 > ? (0.01) 0.0 Nm/(rad/s)
AVC_Z_I (FLOAT) Body Z axis angular velocity I gain

Comment: Body Z axis angular velocity integral gain. Can be set to compensate static thrust difference or gravity center offset.

0.0 > ? (0.01) 0.1 Nm/rad
AVC_Z_I_LIM (FLOAT) Body Z axis angular velocity integrator limit

Comment: Body Z axis angular velocity integrator limit. Can be set to increase the amount of integrator available to counteract disturbances or reduced to improve settling time after large yaw moment trim changes.

0.0 > ? (0.01) 0.30 Nm
AVC_Z_K (FLOAT) Body Z axis angular velocity controller gain

Comment: Global gain of the controller. This gain scales the P, I and D terms of the controller: output = AVC_Z_K * (AVC_Z_P * error + AVC_Z_I * error_integral + AVC_Z_D * error_derivative) Set AVC_Z_P=1 to implement a PID in the ideal form. Set AVC_Z_K=1 to implement a PID in the parallel form.

0.0 > 5.0 (0.0005) 1.0
AVC_Z_P (FLOAT) Body Z axis angular velocity P gain

Comment: Body Z axis angular velocity proportional gain, i.e. control output for angular speed error 1 rad/s.

0.0 > 20.0 (0.01) 7. 1/s

Attitude Q estimator

NameDescriptionMin > Max (Incr.)DefaultUnits
ATT_ACC_COMP (INT32) Acceleration compensation based on GPS velocity Enabled (1)
ATT_BIAS_MAX (FLOAT) Gyro bias limit 0 > 2 0.05 rad/s
ATT_EXT_HDG_M (INT32) External heading usage mode (from Motion capture/Vision)

Comment: Set to 1 to use heading estimate from vision. Set to 2 to use heading from motion capture.

Values:
  • 0: None
  • 1: Vision
  • 2: Motion Capture
0 > 2 0
ATT_MAG_DECL (FLOAT) Magnetic declination, in degrees

Comment: This parameter is not used in normal operation, as the declination is looked up based on the GPS coordinates of the vehicle.

0.0 deg
ATT_MAG_DECL_A (INT32) Automatic GPS based declination compensation Enabled (1)
ATT_W_ACC (FLOAT) Complimentary filter accelerometer weight 0 > 1 0.2
ATT_W_EXT_HDG (FLOAT) Complimentary filter external heading weight 0 > 1 0.1
ATT_W_GYRO_BIAS (FLOAT) Complimentary filter gyroscope bias weight 0 > 1 0.1
ATT_W_MAG (FLOAT) Complimentary filter magnetometer weight

Comment: Set to 0 to avoid using the magnetometer.

0 > 1 0.1

Battery Calibration

NameDescriptionMin > Max (Incr.)DefaultUnits
BAT1_A_PER_V (FLOAT) Battery 1 current per volt (A/V)

Comment: The voltage seen by the ADC multiplied by this factor will determine the battery current. A value of -1 means to use the board default.

Reboot required: True

-1.0
BAT1_CAPACITY (FLOAT) Battery 1 capacity

Comment: Defines the capacity of battery 1 in mAh.

Reboot required: True

-1.0 > 100000 (50) -1.0 mAh
BAT1_I_CHANNEL (INT32) Battery 1 Current ADC Channel

Comment: This parameter specifies the ADC channel used to monitor current of main power battery. A value of -1 means to use the board default.

Reboot required: True

-1
BAT1_N_CELLS (INT32) Number of cells for battery 1

Comment: Defines the number of cells the attached battery consists of.

Values:
  • 2: 2S Battery
  • 3: 3S Battery
  • 4: 4S Battery
  • 5: 5S Battery
  • 6: 6S Battery
  • 7: 7S Battery
  • 8: 8S Battery
  • 9: 9S Battery
  • 10: 10S Battery
  • 11: 11S Battery
  • 12: 12S Battery
  • 13: 13S Battery
  • 14: 14S Battery
  • 15: 15S Battery
  • 16: 16S Battery

Reboot required: True

0
BAT1_R_INTERNAL (FLOAT) Explicitly defines the per cell internal resistance for battery 1

Comment: If non-negative, then this will be used in place of BAT1_V_LOAD_DROP for all calculations.

Reboot required: True

-1.0 > 0.2 (0.01) -1.0 Ohm
BAT1_SOURCE (INT32) Battery 1 monitoring source

Comment: This parameter controls the source of battery data. The value 'Power Module' means that measurements are expected to come from a power module. If the value is set to 'External' then the system expects to receive mavlink battery status messages. If the value is set to 'ESCs', the battery information are taken from the esc_status message. This requires the ESC to provide both voltage as well as current.

Values:
  • -1: Disabled
  • 0: Power Module
  • 1: External
  • 2: ESCs

Reboot required: True

0
BAT1_V_CHANNEL (INT32) Battery 1 Voltage ADC Channel

Comment: This parameter specifies the ADC channel used to monitor voltage of main power battery. A value of -1 means to use the board default.

Reboot required: True

-1
BAT1_V_CHARGED (FLOAT) Full cell voltage (5C load)

Comment: Defines the voltage where a single cell of battery 1 is considered full under a mild load. This will never be the nominal voltage of 4.2V

Reboot required: True

(0.01) 4.05 V
BAT1_V_DIV (FLOAT) Battery 1 voltage divider (V divider)

Comment: This is the divider from battery 1 voltage to ADC voltage. If using e.g. Mauch power modules the value from the datasheet can be applied straight here. A value of -1 means to use the board default.

Reboot required: True

-1.0
BAT1_V_EMPTY (FLOAT) Empty cell voltage (5C load)

Comment: Defines the voltage where a single cell of battery 1 is considered empty. The voltage should be chosen before the steep dropoff to 2.8V. A typical lithium battery can only be discharged down to 10% before it drops off to a voltage level damaging the cells.

Reboot required: True

(0.01) 3.5 V
BAT1_V_LOAD_DROP (FLOAT) Voltage drop per cell on full throttle

Comment: This implicitely defines the internal resistance to maximum current ratio for battery 1 and assumes linearity. A good value to use is the difference between the 5C and 20-25C load. Not used if BAT1_R_INTERNAL is set.

Reboot required: True

0.07 > 0.5 (0.01) 0.3 V
BAT2_A_PER_V (FLOAT) Battery 2 current per volt (A/V)

Comment: The voltage seen by the ADC multiplied by this factor will determine the battery current. A value of -1 means to use the board default.

Reboot required: True

-1.0
BAT2_CAPACITY (FLOAT) Battery 2 capacity

Comment: Defines the capacity of battery 2 in mAh.

Reboot required: True

-1.0 > 100000 (50) -1.0 mAh
BAT2_I_CHANNEL (INT32) Battery 2 Current ADC Channel

Comment: This parameter specifies the ADC channel used to monitor current of main power battery. A value of -1 means to use the board default.

Reboot required: True

-1
BAT2_N_CELLS (INT32) Number of cells for battery 2

Comment: Defines the number of cells the attached battery consists of.

Values:
  • 2: 2S Battery
  • 3: 3S Battery
  • 4: 4S Battery
  • 5: 5S Battery
  • 6: 6S Battery
  • 7: 7S Battery
  • 8: 8S Battery
  • 9: 9S Battery
  • 10: 10S Battery
  • 11: 11S Battery
  • 12: 12S Battery
  • 13: 13S Battery
  • 14: 14S Battery
  • 15: 15S Battery
  • 16: 16S Battery

Reboot required: True

0
BAT2_R_INTERNAL (FLOAT) Explicitly defines the per cell internal resistance for battery 2

Comment: If non-negative, then this will be used in place of BAT2_V_LOAD_DROP for all calculations.

Reboot required: True

-1.0 > 0.2 (0.01) -1.0 Ohm
BAT2_SOURCE (INT32) Battery 2 monitoring source

Comment: This parameter controls the source of battery data. The value 'Power Module' means that measurements are expected to come from a power module. If the value is set to 'External' then the system expects to receive mavlink battery status messages. If the value is set to 'ESCs', the battery information are taken from the esc_status message. This requires the ESC to provide both voltage as well as current.

Values:
  • -1: Disabled
  • 0: Power Module
  • 1: External
  • 2: ESCs

Reboot required: True

-1
BAT2_V_CHANNEL (INT32) Battery 2 Voltage ADC Channel

Comment: This parameter specifies the ADC channel used to monitor voltage of main power battery. A value of -1 means to use the board default.

Reboot required: True

-1
BAT2_V_CHARGED (FLOAT) Full cell voltage (5C load)

Comment: Defines the voltage where a single cell of battery 1 is considered full under a mild load. This will never be the nominal voltage of 4.2V

Reboot required: True

(0.01) 4.05 V
BAT2_V_DIV (FLOAT) Battery 2 voltage divider (V divider)

Comment: This is the divider from battery 2 voltage to ADC voltage. If using e.g. Mauch power modules the value from the datasheet can be applied straight here. A value of -1 means to use the board default.

Reboot required: True

-1.0
BAT2_V_EMPTY (FLOAT) Empty cell voltage (5C load)

Comment: Defines the voltage where a single cell of battery 1 is considered empty. The voltage should be chosen before the steep dropoff to 2.8V. A typical lithium battery can only be discharged down to 10% before it drops off to a voltage level damaging the cells.

Reboot required: True

(0.01) 3.5 V
BAT2_V_LOAD_DROP (FLOAT) Voltage drop per cell on full throttle

Comment: This implicitely defines the internal resistance to maximum current ratio for battery 1 and assumes linearity. A good value to use is the difference between the 5C and 20-25C load. Not used if BAT2_R_INTERNAL is set.

Reboot required: True

0.07 > 0.5 (0.01) 0.3 V
BAT_ADC_CHANNEL (INT32) This parameter is deprecated. Please use BAT1_I_CHANNEL -1
BAT_CRIT_THR (FLOAT) Critical threshold

Comment: Sets the threshold when the battery will be reported as critically low. This has to be lower than the low threshold. This threshold commonly will trigger RTL.

0.05 > 0.25 (0.01) 0.07 norm
BAT_EMERGEN_THR (FLOAT) Emergency threshold

Comment: Sets the threshold when the battery will be reported as dangerously low. This has to be lower than the critical threshold. This threshold commonly will trigger landing.

0.03 > 0.1 (0.01) 0.05 norm
BAT_LOW_THR (FLOAT) Low threshold

Comment: Sets the threshold when the battery will be reported as low. This has to be higher than the critical threshold.

0.12 > 0.5 (0.01) 0.15 norm
BAT_N_CELLS (INT32) This parameter is deprecated. Please use BAT1_N_CELLS instead 3
BAT_V_CHARGED (FLOAT) This parameter is deprecated. Please use BAT1_V_CHARGED instead 4.05
BAT_V_EMPTY (FLOAT) This parameter is deprecated. Please use BAT1_V_EMPTY instead 3.5
BAT_V_LOAD_DROP (FLOAT) This parameter is deprecated. Please use BAT1_V_LOAD_DROP instead 0.3
BAT_V_OFFS_CURR (FLOAT) Offset in volt as seen by the ADC input of the current sensor

Comment: This offset will be subtracted before calculating the battery current based on the voltage.

0.0

Camera Capture

NameDescriptionMin > Max (Incr.)DefaultUnits
CAM_CAP_DELAY (FLOAT) Camera strobe delay

Comment: This parameter sets the delay between image integration start and strobe firing

0.0 > 100.0 0.0 ms

Camera Control

NameDescriptionMin > Max (Incr.)DefaultUnits
CAM_CAP_EDGE (INT32) Camera capture edge Values:
  • 0: Falling edge
  • 1: Rising edge

Reboot required: true

0
CAM_CAP_FBACK (INT32) Camera capture feedback

Comment: Enables camera capture feedback

Reboot required: true

Disabled (0)
CAM_CAP_MODE (INT32) Camera capture timestamping mode

Comment: Change time measurement

Values:
  • 0: Get absolute timestamp
  • 1: Get timestamp of mid exposure (active high)
  • 2: Get timestamp of mid exposure (active low)

Reboot required: true

0

Camera trigger

NameDescriptionMin > Max (Incr.)DefaultUnits
TRIG_ACT_TIME (FLOAT) Camera trigger activation time

Comment: This parameter sets the time the trigger needs to pulled high or low.

Reboot required: true

0.1 > 3000 40.0 ms
TRIG_DISTANCE (FLOAT) Camera trigger distance

Comment: Sets the distance at which to trigger the camera.

Reboot required: true

0 > ? (1) 25.0 m
TRIG_INTERFACE (INT32) Camera trigger Interface

Comment: Selects the trigger interface

Values:
  • 1: GPIO
  • 2: Seagull MAP2 (over PWM)
  • 3: MAVLink (forward via MAV_CMD_IMAGE_START_CAPTURE)
  • 4: Generic PWM (IR trigger, servo)

Reboot required: true

4
TRIG_INTERVAL (FLOAT) Camera trigger interval

Comment: This parameter sets the time between two consecutive trigger events

Reboot required: true

4.0 > 10000.0 40.0 ms
TRIG_MIN_INTERVA (FLOAT) Minimum camera trigger interval

Comment: This parameter sets the minimum time between two consecutive trigger events the specific camera setup is supporting.

Reboot required: true

1.0 > 10000.0 1.0 ms
TRIG_MODE (INT32) Camera trigger mode Values:
  • 0: Disable
  • 1: Time based, on command
  • 2: Time based, always on
  • 3: Distance based, always on
  • 4: Distance based, on command (Survey mode)

Reboot required: true

0 > 4 0
TRIG_PINS (INT32) Camera trigger pin

Comment: Selects which FMU pin is used (range: AUX1-AUX8 on Pixhawk controllers with an I/O board, MAIN1-MAIN8 on controllers without an I/O board). The PWM interface takes two pins per camera, while relay triggers on every pin individually. Example: Value 56 would trigger on pins 5 and 6. For GPIO mode Pin 6 will be triggered followed by 5. With a value of 65 pin 5 will be triggered followed by 6. Pins may be non contiguous. I.E. 16 or 61. In GPIO mode the delay pin to pin is < .2 uS.

Reboot required: true

1 > 12345678 56
TRIG_PINS_EX (INT32) Camera trigger pin extended

Comment: This Bit mask selects which FMU pin is used (range: AUX9-AUX32) If the value is not 0 it takes precedence over TRIG_PINS. If bits above 8 are set that value is used as the selector for trigger pins. greater then 8. 0x00000300 Would be Pins 9,10. If the value is

Reboot required: true

0 > 2147483647 0
TRIG_POLARITY (INT32) Camera trigger polarity

Comment: This parameter sets the polarity of the trigger (0 = active low, 1 = active high )

Values:
  • 0: Active low
  • 1: Active high

Reboot required: true

0 > 1 0
TRIG_PWM_NEUTRAL (INT32) PWM neutral output on trigger pin

Reboot required: true

1000 > 2000 1500 us
TRIG_PWM_SHOOT (INT32) PWM output to trigger shot

Reboot required: true

1000 > 2000 1900 us

Circuit Breaker

NameDescriptionMin > Max (Incr.)DefaultUnits
CBRK_AIRSPD_CHK (INT32) Circuit breaker for airspeed sensor

Comment: Setting this parameter to 162128 will disable the check for an airspeed sensor. The sensor driver will not be started and it cannot be calibrated. WARNING: ENABLING THIS CIRCUIT BREAKER IS AT OWN RISK

Reboot required: true

0 > 162128 0
CBRK_BUZZER (INT32) Circuit breaker for disabling buzzer

Comment: Setting this parameter to 782097 will disable the buzzer audio notification. Setting this parameter to 782090 will disable the startup tune, while keeping all others enabled.

Reboot required: true

0 > 782097 0
CBRK_ENGINEFAIL (INT32) Circuit breaker for engine failure detection

Comment: Setting this parameter to 284953 will disable the engine failure detection. If the aircraft is in engine failure mode the engine failure flag will be set to healthy WARNING: ENABLING THIS CIRCUIT BREAKER IS AT OWN RISK

Reboot required: true

0 > 284953 284953
CBRK_FLIGHTTERM (INT32) Circuit breaker for flight termination

Comment: Setting this parameter to 121212 will disable the flight termination action if triggered by the FailureDetector logic or if FMU is lost. This circuit breaker does not affect the RC loss, data link loss, geofence, and takeoff failure detection safety logic.

Reboot required: true

0 > 121212 121212
CBRK_IO_SAFETY (INT32) Circuit breaker for IO safety

Comment: Setting this parameter to 22027 will disable IO safety. WARNING: ENABLING THIS CIRCUIT BREAKER IS AT OWN RISK

0 > 22027 22027
CBRK_RATE_CTRL (INT32) Circuit breaker for rate controller output

Comment: Setting this parameter to 140253 will disable the rate controller uORB publication. WARNING: ENABLING THIS CIRCUIT BREAKER IS AT OWN RISK

Reboot required: true

0 > 140253 0
CBRK_SUPPLY_CHK (INT32) Circuit breaker for power supply check

Comment: Setting this parameter to 894281 will disable the power valid checks in the commander. WARNING: ENABLING THIS CIRCUIT BREAKER IS AT OWN RISK

0 > 894281 0
CBRK_USB_CHK (INT32) Circuit breaker for USB link check

Comment: Setting this parameter to 197848 will disable the USB connected checks in the commander, setting it to 0 keeps them enabled (recommended). We are generally recommending to not fly with the USB link connected and production vehicles should set this parameter to zero to prevent users from flying USB powered. However, for R&D purposes it has proven over the years to work just fine.

0 > 197848 197848
CBRK_VELPOSERR (INT32) Circuit breaker for position error check

Comment: Setting this parameter to 201607 will disable the position and velocity accuracy checks in the commander. WARNING: ENABLING THIS CIRCUIT BREAKER IS AT OWN RISK

0 > 201607 0
CBRK_VTOLARMING (INT32) Circuit breaker for arming in fixed-wing mode check

Comment: Setting this parameter to 159753 will enable arming in fixed-wing mode for VTOLs. WARNING: ENABLING THIS CIRCUIT BREAKER IS AT OWN RISK

0 > 159753 0

Commander

NameDescriptionMin > Max (Incr.)DefaultUnits
COM_ARM_ARSP_EN (INT32) Enable preflight check for maximal allowed airspeed when arming

Comment: Deny arming if the current airspeed measurement is greater than half the cruise airspeed (FW_AIRSPD_TRIM). Excessive airspeed measurements on ground are either caused by wind or bad airspeed calibration.

Values:
  • 0: Disabled
  • 1: Enabled
1
COM_ARM_AUTH_ID (INT32) Arm authorizer system id

Comment: Used if arm authorization is requested by COM_ARM_AUTH_REQ.

10
COM_ARM_AUTH_MET (INT32) Arm authorization method

Comment: Methods: - one arm: request authorization and arm when authorization is received - two step arm: 1st arm command request an authorization and 2nd arm command arm the drone if authorized Used if arm authorization is requested by COM_ARM_AUTH_REQ.

Values:
  • 0: one arm
  • 1: two step arm
0
COM_ARM_AUTH_REQ (INT32) Require arm authorization to arm

Comment: By default off. The default allows to arm the vehicle without a arm authorization.

Disabled (0)
COM_ARM_AUTH_TO (FLOAT) Arm authorization timeout

Comment: Timeout for authorizer answer. Used if arm authorization is requested by COM_ARM_AUTH_REQ.

(0.1) 1 s
COM_ARM_CHK_ESCS (INT32) Enable checks on ESCs that report telemetry

Comment: If this parameter is set, the system will check ESC's online status and failures. This param is specific for ESCs reporting status. It shall be used only if ESCs support telemetry.

Disabled (0)
COM_ARM_EKF_HGT (FLOAT) Maximum EKF height innovation test ratio that will allow arming 0.1 > 1.0 (0.05) 1.0
COM_ARM_EKF_POS (FLOAT) Maximum EKF position innovation test ratio that will allow arming 0.1 > 1.0 (0.05) 0.5
COM_ARM_EKF_VEL (FLOAT) Maximum EKF velocity innovation test ratio that will allow arming 0.1 > 1.0 (0.05) 0.5
COM_ARM_EKF_YAW (FLOAT) Maximum EKF yaw innovation test ratio that will allow arming 0.1 > 1.0 (0.05) 0.5
COM_ARM_IMU_ACC (FLOAT) Maximum accelerometer inconsistency between IMU units that will allow arming 0.1 > 1.0 (0.05) 0.7 m/s^2
COM_ARM_IMU_GYR (FLOAT) Maximum rate gyro inconsistency between IMU units that will allow arming 0.02 > 0.3 (0.01) 0.25 rad/s
COM_ARM_MAG_ANG (INT32) Maximum magnetic field inconsistency between units that will allow arming

Comment: Set -1 to disable the check.

3 > 180 45 deg
COM_ARM_MAG_STR (INT32) Enable mag strength preflight check

Comment: Deny arming if the estimator detects a strong magnetic disturbance (check enabled by EKF2_MAG_CHECK)

Enabled (1)
COM_ARM_MIS_REQ (INT32) Require valid mission to arm

Comment: The default allows to arm the vehicle without a valid mission.

Disabled (0)
COM_ARM_SDCARD (INT32) Enable FMU SD card detection check

Comment: This check detects if the FMU SD card is missing. Depending on the value of the parameter, the check can be disabled, warn only or deny arming.

Values:
  • 0: Disabled
  • 1: Warning only
  • 2: Enforce SD card presence
1
COM_ARM_SWISBTN (INT32) Arm switch is a momentary button

Comment: 0: Arming/disarming triggers on switch transition. 1: Arming/disarming triggers when holding the momentary button down for COM_RC_ARM_HYST like the stick gesture.

Disabled (0)
COM_ARM_WO_GPS (INT32) Allow arming without GPS

Comment: The default allows the vehicle to arm without GPS signal.

Values:
  • 0: Require GPS lock to arm
  • 1: Allow arming without GPS
1
COM_CPU_MAX (FLOAT) Maximum allowed CPU load to still arm

Comment: A negative value disables the check.

-1 > 100 (1) 90.0 %
COM_DISARM_LAND (FLOAT) Time-out for auto disarm after landing

Comment: A non-zero, positive value specifies the time-out period in seconds after which the vehicle will be automatically disarmed in case a landing situation has been detected during this period. A zero or negative value means that automatic disarming triggered by landing detection is disabled.

2.0 s
COM_DISARM_PRFLT (FLOAT) Time-out for auto disarm if not taking off

Comment: A non-zero, positive value specifies the time in seconds, within which the vehicle is expected to take off after arming. In case the vehicle didn't takeoff within the timeout it disarms again. A negative value disables autmoatic disarming triggered by a pre-takeoff timeout.

10.0 s
COM_DL_LOSS_T (INT32) Datalink loss time threshold

Comment: After this amount of seconds without datalink the data link lost mode triggers

5 > 300 (1) 10 s
COM_EF_C2T (FLOAT) Engine Failure Current/Throttle Threshold

Comment: Engine failure triggers only below this current value

0.0 > 50.0 (1) 5.0 A/%
COM_EF_THROT (FLOAT) Engine Failure Throttle Threshold

Comment: Engine failure triggers only above this throttle value

0.0 > 1.0 (0.01) 0.5 norm
COM_EF_TIME (FLOAT) Engine Failure Time Threshold

Comment: Engine failure triggers only if the throttle threshold and the current to throttle threshold are violated for this time

0.0 > 60.0 (1) 10.0 s
COM_FLIGHT_UUID (INT32) Next flight UUID

Comment: This number is incremented automatically after every flight on disarming in order to remember the next flight UUID. The first flight is 0.

0 > ? 0
COM_FLTMODE1 (INT32) First flightmode slot (1000-1160)

Comment: If the main switch channel is in this range the selected flight mode will be applied.

Values:
  • -1: Unassigned
  • 0: Manual
  • 1: Altitude
  • 2: Position
  • 3: Mission
  • 4: Hold
  • 5: Return
  • 6: Acro
  • 7: Offboard
  • 8: Stabilized
  • 10: Takeoff
  • 11: Land
  • 12: Follow Me
-1
COM_FLTMODE2 (INT32) Second flightmode slot (1160-1320)

Comment: If the main switch channel is in this range the selected flight mode will be applied.

Values:
  • -1: Unassigned
  • 0: Manual
  • 1: Altitude
  • 2: Position
  • 3: Mission
  • 4: Hold
  • 5: Return
  • 6: Acro
  • 7: Offboard
  • 8: Stabilized
  • 10: Takeoff
  • 11: Land
  • 12: Follow Me
-1
COM_FLTMODE3 (INT32) Third flightmode slot (1320-1480)

Comment: If the main switch channel is in this range the selected flight mode will be applied.

Values:
  • -1: Unassigned
  • 0: Manual
  • 1: Altitude
  • 2: Position
  • 3: Mission
  • 4: Hold
  • 5: Return
  • 6: Acro
  • 7: Offboard
  • 8: Stabilized
  • 10: Takeoff
  • 11: Land
  • 12: Follow Me
-1
COM_FLTMODE4 (INT32) Fourth flightmode slot (1480-1640)

Comment: If the main switch channel is in this range the selected flight mode will be applied.

Values:
  • -1: Unassigned
  • 0: Manual
  • 1: Altitude
  • 2: Position
  • 3: Mission
  • 4: Hold
  • 5: Return
  • 6: Acro
  • 7: Offboard
  • 8: Stabilized
  • 10: Takeoff
  • 11: Land
  • 12: Follow Me
-1
COM_FLTMODE5 (INT32) Fifth flightmode slot (1640-1800)

Comment: If the main switch channel is in this range the selected flight mode will be applied.

Values:
  • -1: Unassigned
  • 0: Manual
  • 1: Altitude
  • 2: Position
  • 3: Mission
  • 4: Hold
  • 5: Return
  • 6: Acro
  • 7: Offboard
  • 8: Stabilized
  • 10: Takeoff
  • 11: Land
  • 12: Follow Me
-1
COM_FLTMODE6 (INT32) Sixth flightmode slot (1800-2000)

Comment: If the main switch channel is in this range the selected flight mode will be applied.

Values:
  • -1: Unassigned
  • 0: Manual
  • 1: Altitude
  • 2: Position
  • 3: Mission
  • 4: Hold
  • 5: Return
  • 6: Acro
  • 7: Offboard
  • 8: Stabilized
  • 10: Takeoff
  • 11: Land
  • 12: Follow Me
-1
COM_FLT_PROFILE (INT32) User Flight Profile

Comment: Describes the intended use of the vehicle. Can be used by ground control software or log post processing. This param does not influence the behavior within the firmware. This means for example the control logic is independent of the setting of this param (but depends on other params).

Values:
  • 0: Default
  • 100: Pro User
  • 200: Flight Tester
  • 300: Developer
0
COM_HLDL_LOSS_T (INT32) High Latency Datalink loss time threshold

Comment: After this amount of seconds without datalink the data link lost mode triggers

60 > 3600 120 s
COM_HLDL_REG_T (INT32) High Latency Datalink regain time threshold

Comment: After a data link loss: after this number of seconds with a healthy datalink the 'datalink loss' flag is set back to false

0 > 60 0 s
COM_HOME_H_T (FLOAT) Home set horizontal threshold

Comment: The home position will be set if the estimated positioning accuracy is below the threshold.

2 > 15 (0.5) 5.0 m
COM_HOME_IN_AIR (INT32) Allows setting the home position after takeoff

Comment: If set to true, the autopilot is allowed to set its home position after takeoff The true home position is back-computed if a local position is estimate if available. If no local position is available, home is set to the current position.

Disabled (0)
COM_HOME_V_T (FLOAT) Home set vertical threshold

Comment: The home position will be set if the estimated positioning accuracy is below the threshold.

5 > 25 (0.5) 10.0 m
COM_KILL_DISARM (FLOAT) Timeout value for disarming when kill switch is engaged 0.0 > 30.0 (0.1) 5.0 s
COM_LKDOWN_TKO (FLOAT) Timeout for detecting a failure after takeoff

Comment: A non-zero, positive value specifies the timeframe in seconds within failure detector is allowed to put the vehicle into a lockdown state if attitude exceeds the limits defined in FD_FAIL_P and FD_FAIL_R. The check is not executed for flight modes that do support acrobatic maneuvers, e.g: Acro (MC/FW) and Manual (FW). A zero or negative value means that the check is disabled.

-1.0 > 5.0 3.0 s
COM_LOW_BAT_ACT (INT32) Battery failsafe mode

Comment: Action the system takes at critical battery. See also BAT_CRIT_THR and BAT_EMERGEN_THR for definition of battery states.

Values:
  • 0: Warning
  • 2: Land mode
  • 3: Return at critical level, land at emergency level
(1) 0
COM_MOT_TEST_EN (INT32) Enable Motor Testing

Comment: If set, enables the motor test interface via MAVLink (DO_MOTOR_TEST), that allows spinning the motors for testing purposes.

Enabled (1)
COM_OBC_LOSS_T (FLOAT) Time-out to wait when onboard computer connection is lost before warning about loss connection 0 > 60 (0.01) 5.0 s
COM_OBL_ACT (INT32) Set offboard loss failsafe mode

Comment: The offboard loss failsafe will only be entered after a timeout, set by COM_OF_LOSS_T in seconds.

Values:
  • -1: Disabled
  • 0: Land mode
  • 1: Hold mode
  • 2: Return mode
  • 3: Terminate
  • 4: Lockdown
0
COM_OBL_RC_ACT (INT32) Set offboard loss failsafe mode when RC is available

Comment: The offboard loss failsafe will only be entered after a timeout, set by COM_OF_LOSS_T in seconds.

Values:
  • -1: Disabled
  • 0: Position mode
  • 1: Altitude mode
  • 2: Manual
  • 3: Return mode
  • 4: Land mode
  • 5: Hold mode
  • 6: Terminate
  • 7: Lockdown
0
COM_OBS_AVOID (INT32) Flag to enable obstacle avoidance Disabled (0)
COM_OF_LOSS_T (FLOAT) Time-out to wait when offboard connection is lost before triggering offboard lost action

Comment: See COM_OBL_ACT and COM_OBL_RC_ACT to configure action.

0 > 60 (0.01) 1.0 s
COM_POSCTL_NAVL (INT32) Position control navigation loss response

Comment: This sets the flight mode that will be used if navigation accuracy is no longer adequate for position control. Navigation accuracy checks can be disabled using the CBRK_VELPOSERR parameter, but doing so will remove protection for all flight modes.

Values:
  • 0: Altitude/Manual. Assume use of remote control after fallback. Switch to Altitude mode if a height estimate is available, else switch to MANUAL.
  • 1: Land/Terminate. Assume no use of remote control after fallback. Switch to Land mode if a height estimate is available, else switch to TERMINATION.
0
COM_POS_FS_DELAY (INT32) Loss of position failsafe activation delay

Comment: This sets number of seconds that the position checks need to be failed before the failsafe will activate. The default value has been optimised for rotary wing applications. For fixed wing applications, a larger value between 5 and 10 should be used.

1 > 100 1 s
COM_POS_FS_EPH (FLOAT) Horizontal position error threshold

Comment: This is the horizontal position error (EPH) threshold that will trigger a failsafe. The default is appropriate for a multicopter. Can be increased for a fixed-wing.

5 m
COM_POS_FS_EPV (FLOAT) Vertical position error threshold

Comment: This is the vertical position error (EPV) threshold that will trigger a failsafe. The default is appropriate for a multicopter. Can be increased for a fixed-wing.

10 m
COM_POS_FS_GAIN (INT32) Loss of position probation gain factor

Comment: This sets the rate that the loss of position probation time grows when position checks are failing. The default value has been optimised for rotary wing applications. For fixed wing applications a value of 0 should be used.

Reboot required: true

10
COM_POS_FS_PROB (INT32) Loss of position probation delay at takeoff

Comment: The probation delay is the number of seconds that the EKF innovation checks need to pass for the position to be declared good after it has been declared bad. The probation delay will be reset to this parameter value when takeoff is detected. After takeoff, if position checks are passing, the probation delay will reduce by one second for every lapsed second of valid position down to a minimum of 1 second. If position checks are failing, the probation delay will increase by COM_POS_FS_GAIN seconds for every lapsed second up to a maximum of 100 seconds. The default value has been optimised for rotary wing applications. For fixed wing applications, a value of 1 should be used.

1 > 100 30 s
COM_POWER_COUNT (INT32) Required number of redundant power modules

Comment: This configures a check to verify the expected number of 5V rail power supplies are present. By default only one is expected. Note: CBRK_SUPPLY_CHK disables all power checks including this one.

0 > 4 1
COM_PREARM_MODE (INT32) Condition to enter prearmed mode

Comment: Condition to enter the prearmed state, an intermediate state between disarmed and armed in which non-throttling actuators are active.

Values:
  • 0: Disabled
  • 1: Safety button
  • 2: Always
0
COM_RCL_ACT_T (FLOAT) Delay between RC loss and configured reaction

Comment: RC signal not updated -> still use data for COM_RC_LOSS_T seconds Consider RC signal lost -> wait COM_RCL_ACT_T seconds on the spot waiting to regain signal React with failsafe action NAV_RCL_ACT A zero value disables the delay.

0.0 > 25.0 15.0 s
COM_RCL_EXCEPT (INT32) RC loss exceptions

Comment: Specify modes in which RC loss is ignored and the failsafe action not triggered.

Bitmask:
  • 0: Mission
  • 1: Hold
  • 2: Offboard
0 > 31 0
COM_RC_ARM_HYST (INT32) RC input arm/disarm command duration

Comment: The default value of 1000 requires the stick to be held in the arm or disarm position for 1 second.

100 > 1500 1000 ms
COM_RC_IN_MODE (INT32) RC control input mode

Comment: The default value of 0 requires a valid RC transmitter setup. Setting this to 1 allows joystick control and disables RC input handling and the associated checks. A value of 2 will generate RC control data from manual input received via MAVLink instead of directly forwarding the manual input data.

Values:
  • 0: RC Transmitter
  • 1: Joystick/No RC Checks
  • 2: Virtual RC by Joystick
0 > 2 0
COM_RC_LOSS_T (FLOAT) RC loss time threshold

Comment: After this amount of seconds without RC connection it's considered lost and not used anymore

0 > 35 (0.1) 0.5 s
COM_RC_OVERRIDE (INT32) Enable RC stick override of auto and/or offboard modes

Comment: When RC stick override is enabled, moving the RC sticks more than COM_RC_STICK_OV from their center position immediately gives control back to the pilot by switching to Position mode. Note: Only has an effect on multicopters, and VTOLs in multicopter mode.

Bitmask:
  • 0: Enable override during auto modes (except for in critical battery reaction)
  • 1: Enable override during offboard mode
  • 2: Ignore throttle stick
0 > 7 1
COM_RC_STICK_OV (FLOAT) RC stick override threshold

Comment: If COM_RC_OVERRIDE is enabled and the joystick input is moved more than this threshold the autopilot the pilot takes over control.

5 > 80 (0.05) 30.0 %
COM_REARM_GRACE (INT32) Rearming grace period

Comment: Re-arming grace allows to rearm the drone with manual command without running prearmcheck during 5 s after disarming.

Enabled (1)
COM_TAKEOFF_ACT (INT32) Action after TAKEOFF has been accepted

Comment: The mode transition after TAKEOFF has completed successfully.

Values:
  • 0: Hold
  • 1: Mission (if valid)
0
COM_VEL_FS_EVH (FLOAT) Horizontal velocity error threshold

Comment: This is the horizontal velocity error (EVH) threshold that will trigger a failsafe. The default is appropriate for a multicopter. Can be increased for a fixed-wing.

1 m/s
NAV_DLL_ACT (INT32) Set data link loss failsafe mode

Comment: The data link loss failsafe will only be entered after a timeout, set by COM_DL_LOSS_T in seconds. Once the timeout occurs the selected action will be executed.

Values:
  • 0: Disabled
  • 1: Hold mode
  • 2: Return mode
  • 3: Land mode
  • 5: Terminate
  • 6: Lockdown
0 > 6 0
NAV_RCL_ACT (INT32) Set RC loss failsafe mode

Comment: The RC loss failsafe will only be entered after a timeout, set by COM_RC_LOSS_T in seconds. If RC input checks have been disabled by setting the COM_RC_IN_MODE param it will not be triggered.

Values:
  • 1: Hold mode
  • 2: Return mode
  • 3: Land mode
  • 5: Terminate
  • 6: Lockdown
1 > 6 2
RTL_FLT_TIME (FLOAT) Maximum allowed RTL flight in minutes

Comment: This is used to determine when the vehicle should be switched to RTL due to low battery. Note, particularly for multirotors this should reflect flight time at cruise speed, not while stationary

15 min

Control Allocation

NameDescriptionMin > Max (Incr.)DefaultUnits
CA_ACT0_MAX (FLOAT) Maximum value for actuator 0 0.0
CA_ACT0_MIN (FLOAT) Minimum value for actuator 0 0.0
CA_ACT10_MAX (FLOAT) Maximum value for actuator 10 0.0
CA_ACT10_MIN (FLOAT) Minimum value for actuator 10 0.0
CA_ACT11_MAX (FLOAT) Maximum value for actuator 11 0.0
CA_ACT11_MIN (FLOAT) Minimum value for actuator 11 0.0
CA_ACT12_MAX (FLOAT) Maximum value for actuator 12 0.0
CA_ACT12_MIN (FLOAT) Minimum value for actuator 12 0.0
CA_ACT13_MAX (FLOAT) Maximum value for actuator 13 0.0
CA_ACT13_MIN (FLOAT) Minimum value for actuator 13 0.0
CA_ACT14_MAX (FLOAT) Maximum value for actuator 14 0.0
CA_ACT14_MIN (FLOAT) Minimum value for actuator 14 0.0
CA_ACT15_MAX (FLOAT) Maximum value for actuator 15 0.0
CA_ACT15_MIN (FLOAT) Minimum value for actuator 15 0.0
CA_ACT1_MAX (FLOAT) Maximum value for actuator 1 0.0
CA_ACT1_MIN (FLOAT) Minimum value for actuator 1 0.0
CA_ACT2_MAX (FLOAT) Maximum value for actuator 2 0.0
CA_ACT2_MIN (FLOAT) Minimum value for actuator 2 0.0
CA_ACT3_MAX (FLOAT) Maximum value for actuator 3 0.0
CA_ACT3_MIN (FLOAT) Minimum value for actuator 3 0.0
CA_ACT4_MAX (FLOAT) Maximum value for actuator 4 0.0
CA_ACT4_MIN (FLOAT) Minimum value for actuator 4 0.0
CA_ACT5_MAX (FLOAT) Maximum value for actuator 5 0.0
CA_ACT5_MIN (FLOAT) Minimum value for actuator 5 0.0
CA_ACT6_MAX (FLOAT) Maximum value for actuator 6 0.0
CA_ACT6_MIN (FLOAT) Minimum value for actuator 6 0.0
CA_ACT7_MAX (FLOAT) Maximum value for actuator 7 0.0
CA_ACT7_MIN (FLOAT) Minimum value for actuator 7 0.0
CA_ACT8_MAX (FLOAT) Maximum value for actuator 8 0.0
CA_ACT8_MIN (FLOAT) Minimum value for actuator 8 0.0
CA_ACT9_MAX (FLOAT) Maximum value for actuator 9 0.0
CA_ACT9_MIN (FLOAT) Minimum value for actuator 9 0.0
CA_AIRFRAME (INT32) Airframe ID

Comment: This is used to retrieve pre-computed control effectiveness matrix

Values:
  • 0: Multirotor
  • 1: Standard VTOL (WIP)
  • 2: Tiltrotor VTOL (WIP)
0 > 2 0
CA_AIR_SCALE_EN (INT32) Airspeed scaler

Comment: This compensates for the variation of flap effectiveness with airspeed.

Disabled (0)
CA_BAT_SCALE_EN (INT32) Battery power level scaler

Comment: This compensates for voltage drop of the battery over time by attempting to normalize performance across the operating range of the battery. The copter should constantly behave as if it was fully charged with reduced max acceleration at lower battery percentages. i.e. if hover is at 0.5 throttle at 100% battery, it will still be 0.5 at 60% battery.

Disabled (0)
CA_MC_R0_AX (FLOAT) Axis of rotor 0 thrust vector, X body axis component 0.0
CA_MC_R0_AY (FLOAT) Axis of rotor 0 thrust vector, Y body axis component 0.0
CA_MC_R0_AZ (FLOAT) Axis of rotor 0 thrust vector, Z body axis component -1.0
CA_MC_R0_CT (FLOAT) Thrust coefficient of rotor 0

Comment: The thrust coefficient if defined as Thrust = CT * u^2, where u (with value between CA_ACT0_MIN and CA_ACT0_MAX) is the output signal sent to the motor controller.

0.0
CA_MC_R0_KM (FLOAT) Moment coefficient of rotor 0

Comment: The moment coefficient if defined as Torque = KM * Thrust Use a positive value for a rotor with CCW rotation. Use a negative value for a rotor with CW rotation.

0.05
CA_MC_R0_PX (FLOAT) Position of rotor 0 along X body axis 0.0
CA_MC_R0_PY (FLOAT) Position of rotor 0 along Y body axis 0.0
CA_MC_R0_PZ (FLOAT) Position of rotor 0 along Z body axis 0.0
CA_MC_R1_AX (FLOAT) Axis of rotor 1 thrust vector, X body axis component 0.0
CA_MC_R1_AY (FLOAT) Axis of rotor 1 thrust vector, Y body axis component 0.0
CA_MC_R1_AZ (FLOAT) Axis of rotor 1 thrust vector, Z body axis component -1.0
CA_MC_R1_CT (FLOAT) Thrust coefficient of rotor 1

Comment: The thrust coefficient if defined as Thrust = CT * u^2, where u (with value between CA_ACT1_MIN and CA_ACT1_MAX) is the output signal sent to the motor controller.

0.0
CA_MC_R1_KM (FLOAT) Moment coefficient of rotor 1

Comment: The moment coefficient if defined as Torque = KM * Thrust, Use a positive value for a rotor with CCW rotation. Use a negative value for a rotor with CW rotation.

0.05
CA_MC_R1_PX (FLOAT) Position of rotor 1 along X body axis 0.0
CA_MC_R1_PY (FLOAT) Position of rotor 1 along Y body axis 0.0
CA_MC_R1_PZ (FLOAT) Position of rotor 1 along Z body axis 0.0
CA_MC_R2_AX (FLOAT) Axis of rotor 2 thrust vector, X body axis component 0.0
CA_MC_R2_AY (FLOAT) Axis of rotor 2 thrust vector, Y body axis component 0.0
CA_MC_R2_AZ (FLOAT) Axis of rotor 2 thrust vector, Z body axis component -1.0
CA_MC_R2_CT (FLOAT) Thrust coefficient of rotor 2

Comment: The thrust coefficient if defined as Thrust = CT * u^2, where u (with value between CA_ACT2_MIN and CA_ACT2_MAX) is the output signal sent to the motor controller.

0.0
CA_MC_R2_KM (FLOAT) Moment coefficient of rotor 2

Comment: The moment coefficient if defined as Torque = KM * Thrust Use a positive value for a rotor with CCW rotation. Use a negative value for a rotor with CW rotation.

0.05
CA_MC_R2_PX (FLOAT) Position of rotor 2 along X body axis 0.0
CA_MC_R2_PY (FLOAT) Position of rotor 2 along Y body axis 0.0
CA_MC_R2_PZ (FLOAT) Position of rotor 2 along Z body axis 0.0
CA_MC_R3_AX (FLOAT) Axis of rotor 3 thrust vector, X body axis component 0.0
CA_MC_R3_AY (FLOAT) Axis of rotor 3 thrust vector, Y body axis component 0.0
CA_MC_R3_AZ (FLOAT) Axis of rotor 3 thrust vector, Z body axis component -1.0
CA_MC_R3_CT (FLOAT) Thrust coefficient of rotor 3

Comment: The thrust coefficient if defined as Thrust = CT * u^2, where u (with value between CA_ACT3_MIN and CA_ACT3_MAX) is the output signal sent to the motor controller.

0.0
CA_MC_R3_KM (FLOAT) Moment coefficient of rotor 3

Comment: The moment coefficient if defined as Torque = KM * Thrust Use a positive value for a rotor with CCW rotation. Use a negative value for a rotor with CW rotation.

0.05
CA_MC_R3_PX (FLOAT) Position of rotor 3 along X body axis 0.0
CA_MC_R3_PY (FLOAT) Position of rotor 3 along Y body axis 0.0
CA_MC_R3_PZ (FLOAT) Position of rotor 3 along Z body axis 0.0
CA_MC_R4_AX (FLOAT) Axis of rotor 4 thrust vector, X body axis component 0.0
CA_MC_R4_AY (FLOAT) Axis of rotor 4 thrust vector, Y body axis component 0.0
CA_MC_R4_AZ (FLOAT) Axis of rotor 4 thrust vector, Z body axis component -1.0
CA_MC_R4_CT (FLOAT) Thrust coefficient of rotor 4

Comment: The thrust coefficient if defined as Thrust = CT * u^2, where u (with value between CA_ACT4_MIN and CA_ACT4_MAX) is the output signal sent to the motor controller.

0.0
CA_MC_R4_KM (FLOAT) Moment coefficient of rotor 4

Comment: The moment coefficient if defined as Torque = KM * Thrust Use a positive value for a rotor with CCW rotation. Use a negative value for a rotor with CW rotation.

0.05
CA_MC_R4_PX (FLOAT) Position of rotor 4 along X body axis 0.0
CA_MC_R4_PY (FLOAT) Position of rotor 4 along Y body axis 0.0
CA_MC_R4_PZ (FLOAT) Position of rotor 4 along Z body axis 0.0
CA_MC_R5_AX (FLOAT) Axis of rotor 5 thrust vector, X body axis component 0.0
CA_MC_R5_AY (FLOAT) Axis of rotor 5 thrust vector, Y body axis component 0.0
CA_MC_R5_AZ (FLOAT) Axis of rotor 5 thrust vector, Z body axis component -1.0
CA_MC_R5_CT (FLOAT) Thrust coefficient of rotor 5

Comment: The thrust coefficient if defined as Thrust = CT * u^2, where u (with value between CA_ACT5_MIN and CA_ACT5_MAX) is the output signal sent to the motor controller.

0.0
CA_MC_R5_KM (FLOAT) Moment coefficient of rotor 5

Comment: The moment coefficient if defined as Torque = KM * Thrust Use a positive value for a rotor with CCW rotation. Use a negative value for a rotor with CW rotation.

0.05
CA_MC_R5_PX (FLOAT) Position of rotor 5 along X body axis 0.0
CA_MC_R5_PY (FLOAT) Position of rotor 5 along Y body axis 0.0
CA_MC_R5_PZ (FLOAT) Position of rotor 5 along Z body axis 0.0
CA_MC_R6_AX (FLOAT) Axis of rotor 6 thrust vector, X body axis component 0.0
CA_MC_R6_AY (FLOAT) Axis of rotor 6 thrust vector, Y body axis component 0.0
CA_MC_R6_AZ (FLOAT) Axis of rotor 6 thrust vector, Z body axis component -1.0
CA_MC_R6_CT (FLOAT) Thrust coefficient of rotor 6

Comment: The thrust coefficient if defined as Thrust = CT * u^2, where u (with value between CA_ACT6_MIN and CA_ACT6_MAX) is the output signal sent to the motor controller.

0.0
CA_MC_R6_KM (FLOAT) Moment coefficient of rotor 6

Comment: The moment coefficient if defined as Torque = KM * Thrust Use a positive value for a rotor with CCW rotation. Use a negative value for a rotor with CW rotation.

0.05
CA_MC_R6_PX (FLOAT) Position of rotor 6 along X body axis 0.0
CA_MC_R6_PY (FLOAT) Position of rotor 6 along Y body axis 0.0
CA_MC_R6_PZ (FLOAT) Position of rotor 6 along Z body axis 0.0
CA_MC_R7_AX (FLOAT) Axis of rotor 7 thrust vector, X body axis component 0.0
CA_MC_R7_AY (FLOAT) Axis of rotor 7 thrust vector, Y body axis component 0.0
CA_MC_R7_AZ (FLOAT) Axis of rotor 7 thrust vector, Z body axis component -1.0
CA_MC_R7_CT (FLOAT) Thrust coefficient of rotor 7

Comment: The thrust coefficient if defined as Thrust = CT * u^2, where u (with value between CA_ACT7_MIN and CA_ACT7_MAX) is the output signal sent to the motor controller.

0.0
CA_MC_R7_KM (FLOAT) Moment coefficient of rotor 7

Comment: The moment coefficient if defined as Torque = KM * Thrust Use a positive value for a rotor with CCW rotation. Use a negative value for a rotor with CW rotation.

0.05
CA_MC_R7_PX (FLOAT) Position of rotor 7 along X body axis 0.0
CA_MC_R7_PY (FLOAT) Position of rotor 7 along Y body axis 0.0
CA_MC_R7_PZ (FLOAT) Position of rotor 7 along Z body axis 0.0
CA_METHOD (INT32) Control allocation method Values:
  • 0: Pseudo-inverse with output clipping (default)
  • 1: Pseudo-inverse with sequential desaturation technique
0 > 1 0

DShot

NameDescriptionMin > Max (Incr.)DefaultUnits
DSHOT_3D_DEAD_H (INT32) DSHOT 3D deadband high

Comment: When the actuator_output is between DSHOT_3D_DEAD_L and DSHOT_3D_DEAD_H, motor will not spin. This value is with respect to the mixer_module range (0-1999), not the DSHOT values.

1000 > 1999 1000
DSHOT_3D_DEAD_L (INT32) DSHOT 3D deadband low

Comment: When the actuator_output is between DSHOT_3D_DEAD_L and DSHOT_3D_DEAD_H, motor will not spin. This value is with respect to the mixer_module range (0-1999), not the DSHOT values.

0 > 1000 1000
DSHOT_3D_ENABLE (INT32) Allows for 3d mode when using DShot and suitable mixer

Comment: WARNING: ESC must be configured for 3D mode, and DSHOT_MIN set to 0. This splits the throttle ranges in two. Direction 1) 48 is the slowest, 1047 is the fastest. Direction 2) 1049 is the slowest, 2047 is the fastest. When mixer outputs 1000 or value inside DSHOT 3D deadband, DShot 0 is sent.

Disabled (0)
DSHOT_CONFIG (INT32) Configure DShot

Comment: This enables/disables DShot. The different modes define different speeds, for example DShot150 = 150kb/s. Not all ESCs support all modes. Note: this enables DShot on the FMU outputs. For boards with an IO it is the AUX outputs.

Values:
  • 0: Disable (use PWM/Oneshot)
  • 150: DShot150
  • 300: DShot300
  • 600: DShot600
  • 1200: DShot1200

Reboot required: True

0
DSHOT_MIN (FLOAT) Minimum DShot Motor Output

Comment: Minimum Output Value for DShot in percent. The value depends on the ESC. Make sure to set this high enough so that the motors are always spinning while armed.

0 > 1 (0.01) 0.055 %
DSHOT_TEL_CFG (INT32) Serial Configuration for DShot Driver

Comment: Configure on which serial port to run DShot Driver.

Values:
  • 0: Disabled
  • 6: UART 6
  • 101: TELEM 1
  • 102: TELEM 2
  • 103: TELEM 3
  • 104: TELEM/SERIAL 4
  • 201: GPS 1
  • 202: GPS 2
  • 203: GPS 3
  • 300: Radio Controller
  • 301: Wifi Port

Reboot required: true

0
MOT_POLE_COUNT (INT32) Number of magnetic poles of the motors

Comment: Specify the number of magnetic poles of the motors. It is required to compute the RPM value from the eRPM returned with the ESC telemetry. Either get the number from the motor spec sheet or count the magnets on the bell of the motor (not the stator magnets). Typical motors for 5 inch props have 14 poles.

14
NameDescriptionMin > Max (Incr.)DefaultUnits
NAV_AH_ALT (FLOAT) Airfield home alt

Comment: Altitude of airfield home waypoint

-50 > ? (0.5) 600.0 m
NAV_AH_LAT (INT32) Airfield home Lat

Comment: Latitude of airfield home waypoint

-900000000 > 900000000 -265847810 deg*1e7
NAV_AH_LON (INT32) Airfield home Lon

Comment: Longitude of airfield home waypoint

-1800000000 > 1800000000 1518423250 deg*1e7

EKF2

NameDescriptionMin > Max (Incr.)DefaultUnits
EKF2_ABIAS_INIT (FLOAT) 1-sigma IMU accelerometer switch-on bias

Reboot required: true

0.0 > 0.5 0.2 m/s^2
EKF2_ABL_ACCLIM (FLOAT) Maximum IMU accel magnitude that allows IMU bias learning

Comment: If the magnitude of the IMU accelerometer vector exceeds this value, the EKF delta velocity state estimation will be inhibited. This reduces the adverse effect of high manoeuvre accelerations and IMU nonlinerity and scale factor errors on the delta velocity bias estimates.

20.0 > 200.0 25.0 m/s^2
EKF2_ABL_GYRLIM (FLOAT) Maximum IMU gyro angular rate magnitude that allows IMU bias learning

Comment: If the magnitude of the IMU angular rate vector exceeds this value, the EKF delta velocity state estimation will be inhibited. This reduces the adverse effect of rapid rotation rates and associated errors on the delta velocity bias estimates.

2.0 > 20.0 3.0 rad/s
EKF2_ABL_LIM (FLOAT) Accelerometer bias learning limit

Comment: The ekf delta velocity bias states will be limited to within a range equivalent to +- of this value.

0.0 > 0.8 0.4 m/s^2
EKF2_ABL_TAU (FLOAT) Time constant used by acceleration and angular rate magnitude checks used to inhibit delta velocity bias learning

Comment: The vector magnitude of angular rate and acceleration used to check if learning should be inhibited has a peak hold filter applied to it with an exponential decay. This parameter controls the time constant of the decay.

0.1 > 1.0 0.5 s
EKF2_ACC_B_NOISE (FLOAT) Process noise for IMU accelerometer bias prediction 0.0 > 0.01 3.0e-3 m/s^3
EKF2_ACC_NOISE (FLOAT) Accelerometer noise for covariance prediction 0.01 > 1.0 3.5e-1 m/s^2
EKF2_AID_MASK (INT32) Integer bitmask controlling data fusion and aiding methods

Comment: Set bits in the following positions to enable: 0 : Set to true to use GPS data if available 1 : Set to true to use optical flow data if available 2 : Set to true to inhibit IMU delta velocity bias estimation 3 : Set to true to enable vision position fusion 4 : Set to true to enable vision yaw fusion. Cannot be used if bit position 7 is true. 5 : Set to true to enable multi-rotor drag specific force fusion 6 : set to true if the EV observations are in a non NED reference frame and need to be rotated before being used 7 : Set to true to enable GPS yaw fusion. Cannot be used if bit position 4 is true.

Bitmask:
  • 0: use GPS
  • 1: use optical flow
  • 2: inhibit IMU bias estimation
  • 3: vision position fusion
  • 4: vision yaw fusion
  • 5: multi-rotor drag fusion
  • 6: rotate external vision
  • 7: GPS yaw fusion
  • 8: vision velocity fusion

Reboot required: true

0 > 511 1
EKF2_ANGERR_INIT (FLOAT) 1-sigma tilt angle uncertainty after gravity vector alignment

Reboot required: true

0.0 > 0.5 0.1 rad
EKF2_ARSP_THR (FLOAT) Airspeed fusion threshold

Comment: A value of zero will deactivate airspeed fusion. Any other positive value will determine the minimum airspeed which will still be fused. Set to about 90% of the vehicles stall speed. Both airspeed fusion and sideslip fusion must be active for the EKF to continue navigating after loss of GPS. Use EKF2_FUSE_BETA to activate sideslip fusion.

0.0 > ? 0.0 m/s
EKF2_ASPD_MAX (FLOAT) Upper limit on airspeed along individual axes used to correct baro for position error effects 5.0 > 50.0 20.0 m/s
EKF2_ASP_DELAY (FLOAT) Airspeed measurement delay relative to IMU measurements

Reboot required: true

0 > 300 100 ms
EKF2_AVEL_DELAY (FLOAT) Auxillary Velocity Estimate (e.g from a landing target) delay relative to IMU measurements

Reboot required: true

0 > 300 5 ms
EKF2_BARO_DELAY (FLOAT) Barometer measurement delay relative to IMU measurements

Reboot required: true

0 > 300 0 ms
EKF2_BARO_GATE (FLOAT) Gate size for barometric and GPS height fusion

Comment: Sets the number of standard deviations used by the innovation consistency test.

1.0 > ? 5.0 SD
EKF2_BARO_NOISE (FLOAT) Measurement noise for barometric altitude 0.01 > 15.0 3.5 m
EKF2_BCOEF_X (FLOAT) X-axis ballistic coefficient used for multi-rotor wind estimation

Comment: This parameter controls the prediction of drag produced by bluff body drag along the forward/reverse axis when flying a multi-copter which enables estimation of wind drift when enabled by the EKF2_AID_MASK parameter. The EKF2_BCOEF_X paraemter should be set initially to the ratio of mass / projected frontal area and adjusted together with EKF2_MCOEF to minimise variance of the X-axis drag specific force innovation sequence. The drag produced by this effect scales with speed squared. Set this parameter to zero to turn off the bluff body drag model for this axis. The predicted drag from the rotors is specified separately by the EKF2_MCOEF parameter.

0.0 > 200.0 100.0 kg/m^2
EKF2_BCOEF_Y (FLOAT) Y-axis ballistic coefficient used for multi-rotor wind estimation

Comment: This parameter controls the prediction of drag produced by bluff body drag along the right/left axis when flying a multi-copter, which enables estimation of wind drift when enabled by the EKF2_AID_MASK parameter. The EKF2_BCOEF_Y paraemter should be set initially to the ratio of mass / projected side area and adjusted together with EKF2_MCOEF to minimise variance of the Y-axis drag specific force innovation sequence. The drag produced by this effect scales with speed squared. et this parameter to zero to turn off the bluff body drag model for this axis. The predicted drag from the rotors is specified separately by the EKF2_MCOEF parameter.

0.0 > 200.0 100.0 kg/m^2
EKF2_BETA_GATE (FLOAT) Gate size for synthetic sideslip fusion

Comment: Sets the number of standard deviations used by the innovation consistency test.

1.0 > ? 5.0 SD
EKF2_BETA_NOISE (FLOAT) Noise for synthetic sideslip fusion 0.1 > 1.0 0.3 m/s
EKF2_DECL_TYPE (INT32) Integer bitmask controlling handling of magnetic declination

Comment: Set bits in the following positions to enable functions. 0 : Set to true to use the declination from the geo_lookup library when the GPS position becomes available, set to false to always use the EKF2_MAG_DECL value. 1 : Set to true to save the EKF2_MAG_DECL parameter to the value returned by the EKF when the vehicle disarms. 2 : Set to true to always use the declination as an observation when 3-axis magnetometer fusion is being used.

Bitmask:
  • 0: use geo_lookup declination
  • 1: save EKF2_MAG_DECL on disarm
  • 2: use declination as an observation

Reboot required: true

0 > 7 7
EKF2_DRAG_NOISE (FLOAT) Specific drag force observation noise variance used by the multi-rotor specific drag force model

Comment: Increasing this makes the multi-rotor wind estimates adjust more slowly.

0.5 > 10.0 2.5 (m/s^2)^2
EKF2_EAS_NOISE (FLOAT) Measurement noise for airspeed fusion 0.5 > 5.0 1.4 m/s
EKF2_EVA_NOISE (FLOAT) Measurement noise for vision angle observations used to lower bound or replace the uncertainty included in the message 0.05 > ? 0.05 rad
EKF2_EVP_GATE (FLOAT) Gate size for vision position fusion

Comment: Sets the number of standard deviations used by the innovation consistency test.

1.0 > ? 5.0 SD
EKF2_EVP_NOISE (FLOAT) Measurement noise for vision position observations used to lower bound or replace the uncertainty included in the message 0.01 > ? 0.1 m
EKF2_EVV_GATE (FLOAT) Gate size for vision velocity estimate fusion

Comment: Sets the number of standard deviations used by the innovation consistency test.

1.0 > ? 3.0 SD
EKF2_EVV_NOISE (FLOAT) Measurement noise for vision velocity observations used to lower bound or replace the uncertainty included in the message 0.01 > ? 0.1 m/s
EKF2_EV_DELAY (FLOAT) Vision Position Estimator delay relative to IMU measurements

Reboot required: true

0 > 300 175 ms
EKF2_EV_NOISE_MD (INT32) Whether to set the external vision observation noise from the parameter or from vision message

Comment: If set to true the observation noise is set from the parameters directly, if set to false the measurement noise is taken from the vision message and the parameter are used as a lower bound.

Disabled (0)
EKF2_EV_POS_X (FLOAT) X position of VI sensor focal point in body frame (forward axis with origin relative to vehicle centre of gravity) 0.0 m
EKF2_EV_POS_Y (FLOAT) Y position of VI sensor focal point in body frame (right axis with origin relative to vehicle centre of gravity) 0.0 m
EKF2_EV_POS_Z (FLOAT) Z position of VI sensor focal point in body frame (down axis with origin relative to vehicle centre of gravity) 0.0 m
EKF2_FUSE_BETA (INT32) Boolean determining if synthetic sideslip measurements should fused

Comment: A value of 1 indicates that fusion is active Both sideslip fusion and airspeed fusion must be active for the EKF to continue navigating after loss of GPS. Use EKF2_ARSP_THR to activate airspeed fusion.

Disabled (0)
EKF2_GBIAS_INIT (FLOAT) 1-sigma IMU gyro switch-on bias

Reboot required: true

0.0 > 0.2 0.1 rad/s
EKF2_GND_EFF_DZ (FLOAT) Baro deadzone range for height fusion

Comment: Sets the value of deadzone applied to negative baro innovations. Deadzone is enabled when EKF2_GND_EFF_DZ > 0.

0.0 > 10.0 4.0 m
EKF2_GND_MAX_HGT (FLOAT) Height above ground level for ground effect zone

Comment: Sets the maximum distance to the ground level where negative baro innovations are expected.

0.0 > 5.0 0.5 m
EKF2_GPS_CHECK (INT32) Integer bitmask controlling GPS checks

Comment: Set bits to 1 to enable checks. Checks enabled by the following bit positions 0 : Minimum required sat count set by EKF2_REQ_NSATS 1 : Maximum allowed PDOP set by EKF2_REQ_PDOP 2 : Maximum allowed horizontal position error set by EKF2_REQ_EPH 3 : Maximum allowed vertical position error set by EKF2_REQ_EPV 4 : Maximum allowed speed error set by EKF2_REQ_SACC 5 : Maximum allowed horizontal position rate set by EKF2_REQ_HDRIFT. This check will only run when the vehicle is on ground and stationary. Detecton of the stationary condition is controlled by the EKF2_MOVE_TEST parameter. 6 : Maximum allowed vertical position rate set by EKF2_REQ_VDRIFT. This check will only run when the vehicle is on ground and stationary. Detecton of the stationary condition is controlled by the EKF2_MOVE_TEST parameter. 7 : Maximum allowed horizontal speed set by EKF2_REQ_HDRIFT. This check will only run when the vehicle is on ground and stationary. Detecton of the stationary condition is controlled by the EKF2_MOVE_TEST parameter. 8 : Maximum allowed vertical velocity discrepancy set by EKF2_REQ_VDRIFT

Bitmask:
  • 0: Min sat count (EKF2_REQ_NSATS)
  • 1: Max PDOP (EKF2_REQ_PDOP)
  • 2: Max horizontal position error (EKF2_REQ_EPH)
  • 3: Max vertical position error (EKF2_REQ_EPV)
  • 4: Max speed error (EKF2_REQ_SACC)
  • 5: Max horizontal position rate (EKF2_REQ_HDRIFT)
  • 6: Max vertical position rate (EKF2_REQ_VDRIFT)
  • 7: Max horizontal speed (EKF2_REQ_HDRIFT)
  • 8: Max vertical velocity discrepancy (EKF2_REQ_VDRIFT)
0 > 511 245
EKF2_GPS_DELAY (FLOAT) GPS measurement delay relative to IMU measurements

Reboot required: true

0 > 300 110 ms
EKF2_GPS_POS_X (FLOAT) X position of GPS antenna in body frame (forward axis with origin relative to vehicle centre of gravity) 0.0 m
EKF2_GPS_POS_Y (FLOAT) Y position of GPS antenna in body frame (right axis with origin relative to vehicle centre of gravity) 0.0 m
EKF2_GPS_POS_Z (FLOAT) Z position of GPS antenna in body frame (down axis with origin relative to vehicle centre of gravity) 0.0 m
EKF2_GPS_P_GATE (FLOAT) Gate size for GPS horizontal position fusion

Comment: Sets the number of standard deviations used by the innovation consistency test.

1.0 > ? 5.0 SD
EKF2_GPS_P_NOISE (FLOAT) Measurement noise for gps position 0.01 > 10.0 0.5 m
EKF2_GPS_V_GATE (FLOAT) Gate size for GPS velocity fusion

Comment: Sets the number of standard deviations used by the innovation consistency test.

1.0 > ? 5.0 SD
EKF2_GPS_V_NOISE (FLOAT) Measurement noise for gps horizontal velocity 0.01 > 5.0 0.3 m/s
EKF2_GSF_TAS (FLOAT) Default value of true airspeed used in EKF-GSF AHRS calculation

Comment: If no airspeed measurements are avalable, the EKF-GSF AHRS calculation will assume this value of true airspeed when compensating for centripetal acceleration during turns. Set to zero to disable centripetal acceleration compensation during fixed wing flight modes.

0.0 > 100.0 15.0 m/s
EKF2_GYR_B_NOISE (FLOAT) Process noise for IMU rate gyro bias prediction 0.0 > 0.01 1.0e-3 rad/s^2
EKF2_GYR_NOISE (FLOAT) Rate gyro noise for covariance prediction 0.0001 > 0.1 1.5e-2 rad/s
EKF2_HDG_GATE (FLOAT) Gate size for magnetic heading fusion

Comment: Sets the number of standard deviations used by the innovation consistency test.

1.0 > ? 2.6 SD
EKF2_HEAD_NOISE (FLOAT) Measurement noise for magnetic heading fusion 0.01 > 1.0 0.3 rad
EKF2_HGT_MODE (INT32) Determines the primary source of height data used by the EKF

Comment: The range sensor option should only be used when for operation over a flat surface as the local NED origin will move up and down with ground level.

Values:
  • 0: Barometric pressure
  • 1: GPS
  • 2: Range sensor
  • 3: Vision

Reboot required: true

0
EKF2_IMU_POS_X (FLOAT) X position of IMU in body frame (forward axis with origin relative to vehicle centre of gravity) 0.0 m
EKF2_IMU_POS_Y (FLOAT) Y position of IMU in body frame (right axis with origin relative to vehicle centre of gravity) 0.0 m
EKF2_IMU_POS_Z (FLOAT) Z position of IMU in body frame (down axis with origin relative to vehicle centre of gravity) 0.0 m
EKF2_MAG_ACCLIM (FLOAT) Horizontal acceleration threshold used by automatic selection of magnetometer fusion method

Comment: This parameter is used when the magnetometer fusion method is set automatically (EKF2_MAG_TYPE = 0). If the filtered horizontal acceleration is greater than this parameter value, then the EKF will use 3-axis magnetomer fusion.

0.0 > 5.0 0.5 m/s^2
EKF2_MAG_B_NOISE (FLOAT) Process noise for body magnetic field prediction 0.0 > 0.1 1.0e-4 gauss/s
EKF2_MAG_CHECK (INT32) Magnetic field strength test selection

Comment: When set, the EKF checks the strength of the magnetic field to decide whether the magnetometer data is valid. If GPS data is received, the magnetic field is compared to a World Magnetic Model (WMM), otherwise an average value is used. This check is useful to reject occasional hard iron disturbance.

Disabled (0)
EKF2_MAG_DECL (FLOAT) Magnetic declination 0 deg
EKF2_MAG_DELAY (FLOAT) Magnetometer measurement delay relative to IMU measurements

Reboot required: true

0 > 300 0 ms
EKF2_MAG_E_NOISE (FLOAT) Process noise for earth magnetic field prediction 0.0 > 0.1 1.0e-3 gauss/s
EKF2_MAG_GATE (FLOAT) Gate size for magnetometer XYZ component fusion

Comment: Sets the number of standard deviations used by the innovation consistency test.

1.0 > ? 3.0 SD
EKF2_MAG_NOISE (FLOAT) Measurement noise for magnetometer 3-axis fusion 0.001 > 1.0 5.0e-2 gauss
EKF2_MAG_TYPE (INT32) Type of magnetometer fusion

Comment: Integer controlling the type of magnetometer fusion used - magnetic heading or 3-component vector. The fuson of magnetomer data as a three component vector enables vehicle body fixed hard iron errors to be learned, but requires a stable earth field. If set to 'Automatic' magnetic heading fusion is used when on-ground and 3-axis magnetic field fusion in-flight with fallback to magnetic heading fusion if there is insufficient motion to make yaw or magnetic field states observable. If set to 'Magnetic heading' magnetic heading fusion is used at all times If set to '3-axis' 3-axis field fusion is used at all times. If set to 'VTOL custom' the behaviour is the same as 'Automatic', but if fusing airspeed, magnetometer fusion is only allowed to modify the magnetic field states. This can be used by VTOL platforms with large magnetic field disturbances to prevent incorrect bias states being learned during forward flight operation which can adversely affect estimation accuracy after transition to hovering flight. If set to 'MC custom' the behaviour is the same as 'Automatic, but if there are no earth frame position or velocity observations being used, the magnetometer will not be used. This enables vehicles to operate with no GPS in environments where the magnetic field cannot be used to provide a heading reference. Prior to flight, the yaw angle is assumed to be constant if movement tests controlled by the EKF2_MOVE_TEST parameter indicate that the vehicle is static. This allows the vehicle to be placed on the ground to learn the yaw gyro bias prior to flight. If set to 'None' the magnetometer will not be used under any circumstance. If no external source of yaw is available, it is possible to use post-takeoff horizontal movement combined with GPS velocity measurements to align the yaw angle with the timer required (depending on the amount of movement and GPS data quality). Other external sources of yaw may be used if selected via the EKF2_AID_MASK parameter.

Values:
  • 0: Automatic
  • 1: Magnetic heading
  • 2: 3-axis
  • 3: VTOL custom
  • 4: MC custom
  • 5: None

Reboot required: true

0
EKF2_MAG_YAWLIM (FLOAT) Yaw rate threshold used by automatic selection of magnetometer fusion method

Comment: This parameter is used when the magnetometer fusion method is set automatically (EKF2_MAG_TYPE = 0). If the filtered yaw rate is greater than this parameter value, then the EKF will use 3-axis magnetomer fusion.

0.0 > 1.0 0.25 rad/s
EKF2_MCOEF (FLOAT) propeller momentum drag coefficient used for multi-rotor wind estimation

Comment: This parameter controls the prediction of drag produced by the propellers when flying a multi-copter, which enables estimation of wind drift when enabled by the EKF2_AID_MASK parameter. The drag produced by this effect scales with speed not speed squared and is produced because some of the air velocity normal to the propeller axis of rotation is lost when passing through the rotor disc. This changes the momentum of the flow which creates a drag reaction force. When comparing un-ducted propellers of the same diameter, the effect is roughly proportional to the area of the propeller blades when viewed side on and changes with propeller selection. Momentum drag is significantly higher for ducted rotors. For example, if flying at 10 m/s at sea level conditions produces a rotor induced drag deceleration of 1.5 m/s/s when the multi-copter levelled to zero roll/pitch, then EKF2_MCOEF would be set to 0.15 = (1.5/10.0). Set EKF2_MCOEF to a positive value to enable wind estimation using this drag effect. To account for the drag produced by the body which scales with speed squared, see documentation for the EKF2_BCOEF_X and EKF2_BCOEF_Y parameters. The EKF2_MCOEF parameter should be adjusted together with EKF2_BCOEF_X and EKF2_BCOEF_Y to minimise variance of the X and y axis drag specific force innovation sequences.

0 > 1.0 0.15 1/s
EKF2_MIN_OBS_DT (INT32) Minimum time of arrival delta between non-IMU observations before data is downsampled

Comment: Baro and Magnetometer data will be averaged before downsampling, other data will be point sampled resulting in loss of information.

Reboot required: true

10 > 50 20 ms
EKF2_MIN_RNG (FLOAT) Expected range finder reading when on ground

Comment: If the vehicle is on ground, is not moving as determined by the motion test controlled by EKF2_MOVE_TEST and the range finder is returning invalid or no data, then an assumed range value of EKF2_MIN_RNG will be used by the terrain estimator so that a terrain height estimate is avilable at the start of flight in situations where the range finder may be inside its minimum measurements distance when on ground.

0.01 > ? 0.1 m
EKF2_MOVE_TEST (FLOAT) Vehicle movement test threshold

Comment: Scales the threshold tests applied to IMU data used to determine if the vehicle is static or moving. See parameter descriptions for EKF2_GPS_CHECK and EKF2_MAG_TYPE for further information on the functionality affected by this parameter.

0.1 > 10.0 1.0
EKF2_MULTI_IMU (INT32) Multi-EKF IMUs

Comment: Maximum number of IMUs to use for Multi-EKF. Set 0 to disable. Requires SENS_IMU_MODE 0.

Reboot required: true

0 > 4 0
EKF2_MULTI_MAG (INT32) Multi-EKF Magnetometers

Comment: Maximum number of magnetometers to use for Multi-EKF. Set 0 to disable. Requires SENS_MAG_MODE 0.

Reboot required: true

0 > 4 0
EKF2_NOAID_NOISE (FLOAT) Measurement noise for non-aiding position hold 0.5 > 50.0 10.0 m
EKF2_NOAID_TOUT (INT32) Maximum lapsed time from last fusion of measurements that constrain velocity drift before the EKF will report the horizontal nav solution as invalid 500000 > 10000000 5000000 us
EKF2_OF_DELAY (FLOAT) Optical flow measurement delay relative to IMU measurements

Comment: Assumes measurement is timestamped at trailing edge of integration period

Reboot required: true

0 > 300 20 ms
EKF2_OF_GATE (FLOAT) Gate size for optical flow fusion

Comment: Sets the number of standard deviations used by the innovation consistency test.

1.0 > ? 3.0 SD
EKF2_OF_N_MAX (FLOAT) Measurement noise for the optical flow sensor

Comment: (when it's reported quality metric is at the minimum set by EKF2_OF_QMIN). The following condition must be met: EKF2_OF_N_MAXN >= EKF2_OF_N_MIN

0.05 > ? 0.5 rad/s
EKF2_OF_N_MIN (FLOAT) Measurement noise for the optical flow sensor when it's reported quality metric is at the maximum 0.05 > ? 0.15 rad/s
EKF2_OF_POS_X (FLOAT) X position of optical flow focal point in body frame (forward axis with origin relative to vehicle centre of gravity) 0.0 m
EKF2_OF_POS_Y (FLOAT) Y position of optical flow focal point in body frame (right axis with origin relative to vehicle centre of gravity) 0.0 m
EKF2_OF_POS_Z (FLOAT) Z position of optical flow focal point in body frame (down axis with origin relative to vehicle centre of gravity) 0.0 m
EKF2_OF_QMIN (INT32) Optical Flow data will only be used if the sensor reports a quality metric >= EKF2_OF_QMIN 0 > 255 1
EKF2_PCOEF_XN (FLOAT) Static pressure position error coefficient for the negative X axis

Comment: This is the ratio of static pressure error to dynamic pressure generated by a negative wind relative velocity along the X body axis. If the baro height estimate rises during backwards flight, then this will be a negative number.

-0.5 > 0.5 0.0
EKF2_PCOEF_XP (FLOAT) Static pressure position error coefficient for the positive X axis

Comment: This is the ratio of static pressure error to dynamic pressure generated by a positive wind relative velocity along the X body axis. If the baro height estimate rises during forward flight, then this will be a negative number.

-0.5 > 0.5 0.0
EKF2_PCOEF_YN (FLOAT) Pressure position error coefficient for the negative Y axis

Comment: This is the ratio of static pressure error to dynamic pressure generated by a wind relative velocity along the negative Y (LH) body axis. If the baro height estimate rises during sideways flight to the left, then this will be a negative number.

-0.5 > 0.5 0.0
EKF2_PCOEF_YP (FLOAT) Pressure position error coefficient for the positive Y axis

Comment: This is the ratio of static pressure error to dynamic pressure generated by a wind relative velocity along the positive Y (RH) body axis. If the baro height estimate rises during sideways flight to the right, then this will be a negative number.

-0.5 > 0.5 0.0
EKF2_PCOEF_Z (FLOAT) Static pressure position error coefficient for the Z axis

Comment: This is the ratio of static pressure error to dynamic pressure generated by a wind relative velocity along the Z body axis.

-0.5 > 0.5 0.0
EKF2_REQ_EPH (FLOAT) Required EPH to use GPS 2 > 100 3.0 m
EKF2_REQ_EPV (FLOAT) Required EPV to use GPS 2 > 100 5.0 m
EKF2_REQ_GPS_H (FLOAT) Required GPS health time on startup

Comment: Minimum continuous period without GPS failure required to mark a healthy GPS status. It can be reduced to speed up initialization, but it's recommended to keep this unchanged for a vehicle.

Reboot required: true

0.1 > ? 10.0 s
EKF2_REQ_HDRIFT (FLOAT) Maximum horizontal drift speed to use GPS 0.1 > 1.0 0.1 m/s
EKF2_REQ_NSATS (INT32) Required satellite count to use GPS 4 > 12 6
EKF2_REQ_PDOP (FLOAT) Maximum PDOP to use GPS 1.5 > 5.0 2.5
EKF2_REQ_SACC (FLOAT) Required speed accuracy to use GPS 0.5 > 5.0 0.5 m/s
EKF2_REQ_VDRIFT (FLOAT) Maximum vertical drift speed to use GPS 0.1 > 1.5 0.2 m/s
EKF2_RNG_AID (INT32) Range sensor aid

Comment: If this parameter is enabled then the estimator will make use of the range finder measurements to estimate it's height even if range sensor is not the primary height source. It will only do so if conditions for range measurement fusion are met. This enables the range finder to be used during low speed and low altitude operation, eg takeoff and landing, where baro interference from rotor wash is excessive and can corrupt EKF state estimates. It is intended to be used where a vertical takeoff and landing is performed, and horizontal flight does not occur until above EKF2_RNG_A_HMAX. If vehicle motion causes repeated switching between the primary height sensor and range finder, an offset in the local position origin can accumulate. Also range finder measurements are less reliable and can experience unexpected errors. For these reasons, if accurate control of height relative to ground is required, it is recommended to use the MPC_ALT_MODE parameter instead, unless baro errors are severe enough to cause problems with landing and takeoff.

Values:
  • 0: Range aid disabled
  • 1: Range aid enabled
1
EKF2_RNG_A_HMAX (FLOAT) Maximum absolute altitude (height above ground level) allowed for range aid mode

Comment: If the vehicle absolute altitude exceeds this value then the estimator will not fuse range measurements to estimate it's height. This only applies when range aid mode is activated (EKF2_RNG_AID = enabled).

1.0 > 10.0 5.0 m
EKF2_RNG_A_IGATE (FLOAT) Gate size used for innovation consistency checks for range aid fusion

Comment: A lower value means HAGL needs to be more stable in order to use range finder for height estimation in range aid mode

0.1 > 5.0 1.0 SD
EKF2_RNG_A_VMAX (FLOAT) Maximum horizontal velocity allowed for range aid mode

Comment: If the vehicle horizontal speed exceeds this value then the estimator will not fuse range measurements to estimate it's height. This only applies when range aid mode is activated (EKF2_RNG_AID = enabled).

0.1 > 2 1.0 m/s
EKF2_RNG_DELAY (FLOAT) Range finder measurement delay relative to IMU measurements

Reboot required: true

0 > 300 5 ms
EKF2_RNG_GATE (FLOAT) Gate size for range finder fusion

Comment: Sets the number of standard deviations used by the innovation consistency test.

1.0 > ? 5.0 SD
EKF2_RNG_NOISE (FLOAT) Measurement noise for range finder fusion 0.01 > ? 0.1 m
EKF2_RNG_PITCH (FLOAT) Range sensor pitch offset -0.75 > 0.75 0.0 rad
EKF2_RNG_POS_X (FLOAT) X position of range finder origin in body frame (forward axis with origin relative to vehicle centre of gravity) 0.0 m
EKF2_RNG_POS_Y (FLOAT) Y position of range finder origin in body frame (right axis with origin relative to vehicle centre of gravity) 0.0 m
EKF2_RNG_POS_Z (FLOAT) Z position of range finder origin in body frame (down axis with origin relative to vehicle centre of gravity) 0.0 m
EKF2_RNG_QLTY_T (FLOAT) Minimum duration during which the reported range finder signal quality needs to be non-zero in order to be declared valid (s) 0.1 > 5 1.0 s
EKF2_RNG_SFE (FLOAT) Range finder range dependant noise scaler

Comment: Specifies the increase in range finder noise with range.

0.0 > 0.2 0.05 m/m
EKF2_SEL_ERR_RED (FLOAT) Selector error reduce threshold

Comment: EKF2 instances have to be better than the selected by at least this amount before their relative score can be reduced.

0.2
EKF2_SEL_IMU_ACC (FLOAT) Selector acceleration threshold

Comment: EKF2 selector acceleration error threshold for comparing accelerometers. Acceleration vector differences larger than this will result in accumulated velocity error.

1.0 m/s^2
EKF2_SEL_IMU_ANG (FLOAT) Selector angular threshold

Comment: EKF2 selector maximum accumulated angular error threshold for comparing gyros. Accumulated angular error larger than this will result in the sensor being declared faulty.

15.0 deg
EKF2_SEL_IMU_RAT (FLOAT) Selector angular rate threshold

Comment: EKF2 selector angular rate error threshold for comparing gyros. Angular rate vector differences larger than this will result in accumulated angular error.

7.0 deg/s
EKF2_SEL_IMU_VEL (FLOAT) Selector angular threshold

Comment: EKF2 selector maximum accumulated velocity threshold for comparing accelerometers. Accumulated velocity error larger than this will result in the sensor being declared faulty.

2.0 m/s
EKF2_SYNT_MAG_Z (INT32) Enable synthetic magnetometer Z component measurement

Comment: Use for vehicles where the measured body Z magnetic field is subject to strong magnetic interference. For magnetic heading fusion the magnetometer Z measurement will be replaced by a synthetic value calculated using the knowledge of the 3D magnetic field vector at the location of the drone. Therefore, this parameter will only have an effect if the global position of the drone is known. For 3D mag fusion the magnetometer Z measurement will simply be ingored instead of fusing the synthetic value.

Disabled (0)
EKF2_TAS_GATE (FLOAT) Gate size for TAS fusion

Comment: Sets the number of standard deviations used by the innovation consistency test.

1.0 > ? 3.0 SD
EKF2_TAU_POS (FLOAT) Time constant of the position output prediction and smoothing filter. Controls how tightly the output track the EKF states 0.1 > 1.0 0.25 s
EKF2_TAU_VEL (FLOAT) Time constant of the velocity output prediction and smoothing filter ? > 1.0 0.25 s
EKF2_TERR_GRAD (FLOAT) Magnitude of terrain gradient 0.0 > ? 0.5 m/m
EKF2_TERR_MASK (INT32) Integer bitmask controlling fusion sources of the terrain estimator

Comment: Set bits in the following positions to enable: 0 : Set to true to use range finder data if available 1 : Set to true to use optical flow data if available

Bitmask:
  • 0: use range finder
  • 1: use optical flow
0 > 3 3
EKF2_TERR_NOISE (FLOAT) Terrain altitude process noise - accounts for instability in vehicle height estimate 0.5 > ? 5.0 m/s
EKF2_WIND_NOISE (FLOAT) Process noise for wind velocity prediction 0.0 > 1.0 1.0e-1 m/s^2

ESC

NameDescriptionMin > Max (Incr.)DefaultUnits
ESC_BL_VER (INT32) Required esc bootloader version 0 > 65535 0
ESC_FW_VER (INT32) Required esc firmware version 0 > 65535 0
ESC_HW_VER (INT32) Required esc hardware version 0 > 65535 0

Events

NameDescriptionMin > Max (Incr.)DefaultUnits
EV_TSK_RC_LOSS (INT32) RC Loss Alarm

Comment: Enable/disable event task for RC Loss. When enabled, an alarm tune will be played via buzzer or ESCs, if supported. The alarm will sound after a disarm, if the vehicle was previously armed and only if the vehicle had RC signal at some point. Particularly useful for locating crashed drones without a GPS sensor.

Reboot required: true

Disabled (0)
EV_TSK_STAT_DIS (INT32) Status Display

Comment: Enable/disable event task for displaying the vehicle status using arm-mounted LEDs. When enabled and if the vehicle supports it, LEDs will flash indicating various vehicle status changes. Currently PX4 has not implemented any specific status events. -

Reboot required: true

Disabled (0)

FW Attitude Control

NameDescriptionMin > Max (Incr.)DefaultUnits
FW_ACRO_X_MAX (FLOAT) Acro body x max rate

Comment: This is the rate the controller is trying to achieve if the user applies full roll stick input in acro mode.

45 > 720 90 deg
FW_ACRO_Y_MAX (FLOAT) Acro body y max rate

Comment: This is the body y rate the controller is trying to achieve if the user applies full pitch stick input in acro mode.

45 > 720 90 deg
FW_ACRO_Z_MAX (FLOAT) Acro body z max rate

Comment: This is the body z rate the controller is trying to achieve if the user applies full yaw stick input in acro mode.

10 > 180 45 deg
FW_ARSP_MODE (INT32) Airspeed mode

Comment: For small wings or VTOL without airspeed sensor this parameter can be used to enable flying without an airspeed reading

Values:
  • 0: Normal (use airspeed if available)
  • 1: Airspeed disabled
0
FW_ARSP_SCALE_EN (INT32) Enable airspeed scaling

Comment: This enables a logic that automatically adjusts the output of the rate controller to take into account the real torque produced by an aerodynamic control surface given the current deviation from the trim airspeed (FW_AIRSPD_TRIM). Enable when using aerodynamic control surfaces (e.g.: plane) Disable when using rotor wings (e.g.: autogyro)

Enabled (1)
FW_BAT_SCALE_EN (INT32) Whether to scale throttle by battery power level

Comment: This compensates for voltage drop of the battery over time by attempting to normalize performance across the operating range of the battery. The fixed wing should constantly behave as if it was fully charged with reduced max thrust at lower battery percentages. i.e. if cruise speed is at 0.5 throttle at 100% battery, it will still be 0.5 at 60% battery.

Disabled (0)
FW_DTRIM_P_FLPS (FLOAT) Pitch trim increment for flaps configuration

Comment: This increment is added to the pitch trim whenever flaps are fully deployed.

-0.25 > 0.25 (0.01) 0.0
FW_DTRIM_P_VMAX (FLOAT) Pitch trim increment at maximum airspeed

Comment: This increment is added to TRIM_PITCH when airspeed is FW_AIRSPD_MAX.

-0.25 > 0.25 (0.01) 0.0
FW_DTRIM_P_VMIN (FLOAT) Pitch trim increment at minimum airspeed

Comment: This increment is added to TRIM_PITCH when airspeed is FW_AIRSPD_MIN.

-0.25 > 0.25 (0.01) 0.0
FW_DTRIM_R_FLPS (FLOAT) Roll trim increment for flaps configuration

Comment: This increment is added to TRIM_ROLL whenever flaps are fully deployed.

-0.25 > 0.25 (0.01) 0.0
FW_DTRIM_R_VMAX (FLOAT) Roll trim increment at maximum airspeed

Comment: This increment is added to TRIM_ROLL when airspeed is FW_AIRSPD_MAX.

-0.25 > 0.25 (0.01) 0.0
FW_DTRIM_R_VMIN (FLOAT) Roll trim increment at minimum airspeed

Comment: This increment is added to TRIM_ROLL when airspeed is FW_AIRSPD_MIN.

-0.25 > 0.25 (0.01) 0.0
FW_DTRIM_Y_VMAX (FLOAT) Yaw trim increment at maximum airspeed

Comment: This increment is added to TRIM_YAW when airspeed is FW_AIRSPD_MAX.

-0.25 > 0.25 (0.01) 0.0
FW_DTRIM_Y_VMIN (FLOAT) Yaw trim increment at minimum airspeed

Comment: This increment is added to TRIM_YAW when airspeed is FW_AIRSPD_MIN.

-0.25 > 0.25 (0.01) 0.0
FW_FLAPERON_SCL (FLOAT) Scale factor for flaperons 0.0 > 1.0 (0.01) 0.0 norm
FW_FLAPS_LND_SCL (FLOAT) Flaps setting during landing

Comment: Sets a fraction of full flaps (FW_FLAPS_SCL) during landing

0.0 > 1.0 (0.01) 1.0 norm
FW_FLAPS_SCL (FLOAT) Scale factor for flaps 0.0 > 1.0 (0.01) 1.0 norm
FW_FLAPS_TO_SCL (FLOAT) Flaps setting during take-off

Comment: Sets a fraction of full flaps (FW_FLAPS_SCL) during take-off

0.0 > 1.0 (0.01) 0.0 norm
FW_MAN_P_MAX (FLOAT) Max manual pitch

Comment: Max pitch for manual control in attitude stabilized mode

0.0 > 90.0 (0.5) 45.0 deg
FW_MAN_P_SC (FLOAT) Manual pitch scale

Comment: Scale factor applied to the desired pitch actuator command in full manual mode. This parameter allows to adjust the throws of the control surfaces.

0.0 > ? (0.01) 1.0 norm
FW_MAN_R_MAX (FLOAT) Max manual roll

Comment: Max roll for manual control in attitude stabilized mode

0.0 > 90.0 (0.5) 45.0 deg
FW_MAN_R_SC (FLOAT) Manual roll scale

Comment: Scale factor applied to the desired roll actuator command in full manual mode. This parameter allows to adjust the throws of the control surfaces.

0.0 > 1.0 (0.01) 1.0 norm
FW_MAN_Y_SC (FLOAT) Manual yaw scale

Comment: Scale factor applied to the desired yaw actuator command in full manual mode. This parameter allows to adjust the throws of the control surfaces.

0.0 > ? (0.01) 1.0 norm
FW_PR_FF (FLOAT) Pitch rate feed forward

Comment: Direct feed forward from rate setpoint to control surface output

0.0 > 10.0 (0.05) 0.5 %/rad/s
FW_PR_I (FLOAT) Pitch rate integrator gain

Comment: This gain defines how much control response will result out of a steady state error. It trims any constant error.

0.005 > 0.5 (0.005) 0.1 %/rad
FW_PR_IMAX (FLOAT) Pitch rate integrator limit

Comment: The portion of the integrator part in the control surface deflection is limited to this value

0.0 > 1.0 (0.05) 0.4
FW_PR_P (FLOAT) Pitch rate proportional gain

Comment: This defines how much the elevator input will be commanded depending on the current body angular rate error.

0.005 > 1.0 (0.005) 0.08 %/rad/s
FW_PSP_OFF (FLOAT) Pitch setpoint offset (pitch at level flight)

Comment: An airframe specific offset of the pitch setpoint in degrees, the value is added to the pitch setpoint and should correspond to the pitch at typical cruise speed of the airframe.

-90.0 > 90.0 (0.5) 0.0 deg
FW_P_RMAX_NEG (FLOAT) Maximum negative / down pitch rate

Comment: This limits the maximum pitch down up angular rate the controller will output (in degrees per second).

0.0 > 90.0 (0.5) 60.0 deg/s
FW_P_RMAX_POS (FLOAT) Maximum positive / up pitch rate

Comment: This limits the maximum pitch up angular rate the controller will output (in degrees per second).

0.0 > 90.0 (0.5) 60.0 deg/s
FW_P_TC (FLOAT) Attitude pitch time constant

Comment: This defines the latency between a pitch step input and the achieved setpoint (inverse to a P gain). Half a second is a good start value and fits for most average systems. Smaller systems may require smaller values, but as this will wear out servos faster, the value should only be decreased as needed.

0.2 > 1.0 (0.05) 0.4 s
FW_RLL_TO_YAW_FF (FLOAT) Roll control to yaw control feedforward gain

Comment: This gain can be used to counteract the "adverse yaw" effect for fixed wings. When the plane enters a roll it will tend to yaw the nose out of the turn. This gain enables the use of a yaw actuator (rudder, airbrakes, ...) to counteract this effect.

0.0 > ? (0.01) 0.0
FW_RR_FF (FLOAT) Roll rate feed forward

Comment: Direct feed forward from rate setpoint to control surface output. Use this to obtain a tigher response of the controller without introducing noise amplification.

0.0 > 10.0 (0.05) 0.5 %/rad/s
FW_RR_I (FLOAT) Roll rate integrator Gain

Comment: This gain defines how much control response will result out of a steady state error. It trims any constant error.

0.005 > 0.2 (0.005) 0.1 %/rad
FW_RR_IMAX (FLOAT) Roll integrator anti-windup

Comment: The portion of the integrator part in the control surface deflection is limited to this value.

0.0 > 1.0 (0.05) 0.2
FW_RR_P (FLOAT) Roll rate proportional Gain

Comment: This defines how much the aileron input will be commanded depending on the current body angular rate error.

0.005 > 1.0 (0.005) 0.05 %/rad/s
FW_R_RMAX (FLOAT) Maximum roll rate

Comment: This limits the maximum roll rate the controller will output (in degrees per second).

0.0 > 90.0 (0.5) 70.0 deg/s
FW_R_TC (FLOAT) Attitude Roll Time Constant

Comment: This defines the latency between a roll step input and the achieved setpoint (inverse to a P gain). Half a second is a good start value and fits for most average systems. Smaller systems may require smaller values, but as this will wear out servos faster, the value should only be decreased as needed.

0.4 > 1.0 (0.05) 0.4 s
FW_WR_FF (FLOAT) Wheel steering rate feed forward

Comment: Direct feed forward from rate setpoint to control surface output

0.0 > 10.0 (0.05) 0.2 %/rad/s
FW_WR_I (FLOAT) Wheel steering rate integrator gain

Comment: This gain defines how much control response will result out of a steady state error. It trims any constant error.

0.005 > 0.5 (0.005) 0.1 %/rad
FW_WR_IMAX (FLOAT) Wheel steering rate integrator limit

Comment: The portion of the integrator part in the control surface deflection is limited to this value

0.0 > 1.0 (0.05) 1.0
FW_WR_P (FLOAT) Wheel steering rate proportional gain

Comment: This defines how much the wheel steering input will be commanded depending on the current body angular rate error.

0.005 > 1.0 (0.005) 0.5 %/rad/s
FW_W_EN (INT32) Enable wheel steering controller Disabled (0)
FW_W_RMAX (FLOAT) Maximum wheel steering rate

Comment: This limits the maximum wheel steering rate the controller will output (in degrees per second).

0.0 > 90.0 (0.5) 30.0 deg/s
FW_YR_FF (FLOAT) Yaw rate feed forward

Comment: Direct feed forward from rate setpoint to control surface output

0.0 > 10.0 (0.05) 0.3 %/rad/s
FW_YR_I (FLOAT) Yaw rate integrator gain

Comment: This gain defines how much control response will result out of a steady state error. It trims any constant error.

0.0 > 50.0 (0.5) 0.1 %/rad
FW_YR_IMAX (FLOAT) Yaw rate integrator limit

Comment: The portion of the integrator part in the control surface deflection is limited to this value

0.0 > 1.0 (0.05) 0.2
FW_YR_P (FLOAT) Yaw rate proportional gain

Comment: This defines how much the rudder input will be commanded depending on the current body angular rate error.

0.005 > 1.0 (0.005) 0.05 %/rad/s
FW_Y_RMAX (FLOAT) Maximum yaw rate

Comment: This limits the maximum yaw rate the controller will output (in degrees per second).

0.0 > 90.0 (0.5) 50.0 deg/s

FW L1 Control

NameDescriptionMin > Max (Incr.)DefaultUnits
FW_CLMBOUT_DIFF (FLOAT) Climbout Altitude difference

Comment: If the altitude error exceeds this parameter, the system will climb out with maximum throttle and minimum airspeed until it is closer than this distance to the desired altitude. Mostly used for takeoff waypoints / modes. Set to 0 to disable climbout mode (not recommended).

0.0 > 150.0 (0.5) 10.0 m
FW_L1_DAMPING (FLOAT) L1 damping

Comment: Damping factor for L1 control.

0.6 > 0.9 (0.05) 0.75
FW_L1_PERIOD (FLOAT) L1 period

Comment: This is the L1 distance and defines the tracking point ahead of the aircraft its following. A value of 18-25 meters works for most aircraft. Shorten slowly during tuning until response is sharp without oscillation.

12.0 > 50.0 (0.5) 20.0 m
FW_L1_R_SLEW_MAX (FLOAT) L1 controller roll slew rate limit

Comment: The maxium change in roll angle setpoint per second.

0 > ? (1) 90.0 deg/s
FW_LND_AIRSPD_SC (FLOAT) Min. airspeed scaling factor for landing

Comment: Multiplying this factor with the minimum airspeed of the plane gives the target airspeed the landing approach. FW_AIRSPD_MIN * FW_LND_AIRSPD_SC

1.0 > 1.5 (0.01) 1.3 norm
FW_LND_ANG (FLOAT) Landing slope angle 1.0 > 15.0 (0.5) 5.0 deg
FW_LND_EARLYCFG (INT32) Early landing configuration deployment

Comment: When disabled, the landing configuration (flaps, landing airspeed, etc.) is only activated on the final approach to landing. When enabled, it is already activated when entering the final loiter-down (loiter-to-alt) waypoint before the landing approach. This shifts the (often large) altitude and airspeed errors caused by the configuration change away from the ground such that these are not so critical. It also gives the controller enough time to adapt to the new configuration such that the landing approach starts with a cleaner initial state.

Disabled (0)
FW_LND_FLALT (FLOAT) Landing flare altitude (relative to landing altitude) 0.0 > 25.0 (0.5) 3.0 m
FW_LND_FL_PMAX (FLOAT) Flare, maximum pitch

Comment: Maximum pitch during flare, a positive sign means nose up Applied once FW_LND_FLALT is reached

0 > 45.0 (0.5) 15.0 deg
FW_LND_FL_PMIN (FLOAT) Flare, minimum pitch

Comment: Minimum pitch during flare, a positive sign means nose up Applied once FW_LND_FLALT is reached

0 > 15.0 (0.5) 2.5 deg
FW_LND_HHDIST (FLOAT) Landing heading hold horizontal distance

Comment: Set to 0 to disable heading hold.

0 > 30.0 (0.5) 15.0 m
FW_LND_HVIRT (FLOAT) 1.0 > 15.0 (0.5) 10.0 m
FW_LND_THRTC_SC (FLOAT) Altitude time constant factor for landing

Comment: Set this parameter to less than 1.0 to make TECS react faster to altitude errors during landing than during normal flight (i.e. giving efficiency and low motor wear at high altitudes but control accuracy during landing). During landing, the TECS altitude time constant (FW_T_ALT_TC) is multiplied by this value.

0.2 > 1.0 (0.1) 1.0
FW_LND_TLALT (FLOAT) Landing throttle limit altitude (relative landing altitude)

Comment: Default of -1.0 lets the system default to applying throttle limiting at 2/3 of the flare altitude.

-1.0 > 30.0 (0.5) -1.0 m
FW_LND_USETER (INT32) Use terrain estimate during landing

Comment: This is turned off by default and a waypoint or return altitude is normally used (or sea level for an arbitrary land position).

Disabled (0)
FW_POSCTL_INV_ST (INT32) RC stick mapping fixed-wing

Comment: Set RC/joystick configuration for fixed-wing position and altitude controlled flight.

Values:
  • 0: Normal stick configuration (airspeed on throttle stick, altitude on pitch stick)
  • 1: Alternative stick configuration (altitude on throttle stick, airspeed on pitch stick)
0 > 1 0
FW_P_LIM_MAX (FLOAT) Positive pitch limit

Comment: The maximum positive pitch the controller will output.

0.0 > 60.0 (0.5) 45.0 deg
FW_P_LIM_MIN (FLOAT) Negative pitch limit

Comment: The minimum negative pitch the controller will output.

-60.0 > 0.0 (0.5) -45.0 deg
FW_R_LIM (FLOAT) Controller roll limit

Comment: The maximum roll the controller will output.

35.0 > 65.0 (0.5) 50.0 deg
FW_THR_ALT_SCL (FLOAT) Scale throttle by pressure change

Comment: Automatically adjust throttle to account for decreased air density at higher altitudes. Start with a scale factor of 1.0 and adjust for different propulsion systems. When flying without airspeed sensor this will help to keep a constant performance over large altitude ranges. The default value of 0 will disable scaling.

0.0 > 10.0 (0.1) 0.0
FW_THR_CRUISE (FLOAT) Cruise throttle

Comment: This is the throttle setting required to achieve the desired cruise speed. Most airframes have a value of 0.5-0.7.

0.0 > 1.0 (0.01) 0.6 norm
FW_THR_IDLE (FLOAT) Idle throttle

Comment: This is the minimum throttle while on the ground For aircraft with internal combustion engine this parameter should be set above desired idle rpm.

0.0 > 0.4 (0.01) 0.15 norm
FW_THR_LND_MAX (FLOAT) Throttle limit during landing below throttle limit altitude

Comment: During the flare of the autonomous landing process, this value will be set as throttle limit when the aircraft altitude is below FW_LND_TLALT.

0.0 > 1.0 (0.01) 1.0 norm
FW_THR_MAX (FLOAT) Throttle limit max

Comment: This is the maximum throttle % that can be used by the controller. For overpowered aircraft, this should be reduced to a value that provides sufficient thrust to climb at the maximum pitch angle PTCH_MAX.

0.0 > 1.0 (0.01) 1.0 norm
FW_THR_MIN (FLOAT) Throttle limit min

Comment: This is the minimum throttle % that can be used by the controller. For electric aircraft this will normally be set to zero, but can be set to a small non-zero value if a folding prop is fitted to prevent the prop from folding and unfolding repeatedly in-flight or to provide some aerodynamic drag from a turning prop to improve the descent rate. For aircraft with internal combustion engine this parameter should be set for desired idle rpm.

0.0 > 1.0 (0.01) 0.0 norm
FW_THR_SLEW_MAX (FLOAT) Throttle max slew rate

Comment: Maximum slew rate for the commanded throttle

0.0 > 1.0 0.0
FW_TKO_PITCH_MIN (FLOAT) Minimum pitch during takeoff -5.0 > 30.0 (0.5) 10.0 deg

FW Launch detection

NameDescriptionMin > Max (Incr.)DefaultUnits
LAUN_ALL_ON (INT32) Launch detection Disabled (0)
LAUN_CAT_A (FLOAT) Catapult accelerometer threshold

Comment: LAUN_CAT_A for LAUN_CAT_T serves as threshold to trigger launch detection.

0 > ? (0.5) 30.0 m/s^2
LAUN_CAT_MDEL (FLOAT) Motor delay

Comment: Delay between starting attitude control and powering up the throttle (giving throttle control to the controller) Before this timespan is up the throttle will be set to FW_THR_IDLE, set to 0 to deactivate

0.0 > 10.0 (0.5) 0.0 s
LAUN_CAT_PMAX (FLOAT) Maximum pitch before the throttle is powered up (during motor delay phase)

Comment: This is an extra limit for the maximum pitch which is imposed in the phase before the throttle turns on. This allows to limit the maximum pitch angle during a bungee launch (make the launch less steep).

0.0 > 45.0 (0.5) 30.0 deg
LAUN_CAT_T (FLOAT) Catapult time threshold

Comment: LAUN_CAT_A for LAUN_CAT_T serves as threshold to trigger launch detection.

0.0 > 5.0 (0.05) 0.05 s

FW TECS

NameDescriptionMin > Max (Incr.)DefaultUnits
FW_AIRSPD_MAX (FLOAT) Maximum Airspeed (CAS)

Comment: If the CAS (calibrated airspeed) is above this value, the TECS controller will try to decrease airspeed more aggressively.

0.5 > 40 (0.5) 20.0 m/s
FW_AIRSPD_MIN (FLOAT) Minimum Airspeed (CAS)

Comment: The minimal airspeed (calibrated airspeed) the user is able to command. Further, if the airspeed falls below this value, the TECS controller will try to increase airspeed more aggressively.

0.5 > 40 (0.5) 10.0 m/s
FW_AIRSPD_STALL (FLOAT) Stall Airspeed (CAS)

Comment: The stall airspeed (calibrated airspeed) of the vehicle. It is used for airspeed sensor failure detection and for the control surface scaling airspeed limits.

0.5 > 40 (0.5) 7.0 m/s
FW_AIRSPD_TRIM (FLOAT) Cruise Airspeed (CAS)

Comment: The trim CAS (calibrated airspeed) of the vehicle. If an airspeed controller is active, this is the default airspeed setpoint that the controller will try to achieve if no other airspeed setpoint sources are present (e.g. through non-centered RC sticks).

0.5 > 40 (0.5) 15.0 m/s
FW_GND_SPD_MIN (FLOAT) Minimum groundspeed

Comment: The controller will increase the commanded airspeed to maintain this minimum groundspeed to the next waypoint.

0.0 > 40 (0.5) 5.0 m/s
FW_T_ALT_TC (FLOAT) Altitude error time constant 2.0 > ? (0.5) 5.0
FW_T_CLMB_MAX (FLOAT) Maximum climb rate

Comment: This is the best climb rate that the aircraft can achieve with the throttle set to THR_MAX and the airspeed set to the default value. For electric aircraft make sure this number can be achieved towards the end of flight when the battery voltage has reduced. The setting of this parameter can be checked by commanding a positive altitude change of 100m in loiter, RTL or guided mode. If the throttle required to climb is close to THR_MAX and the aircraft is maintaining airspeed, then this parameter is set correctly. If the airspeed starts to reduce, then the parameter is set to high, and if the throttle demand required to climb and maintain speed is noticeably less than FW_THR_MAX, then either FW_T_CLMB_MAX should be increased or FW_THR_MAX reduced.

1.0 > 15.0 (0.5) 5.0 m/s
FW_T_CLMB_R_SP (FLOAT) Default target climbrate

Comment: The default rate at which the vehicle will climb in autonomous modes to achieve altitude setpoints. In manual modes this defines the maximum rate at which the altitude setpoint can be increased.

0.5 > 15 (0.01) 3.0 m/s
FW_T_HRATE_FF (FLOAT) Height rate feed forward 0.0 > 1.0 (0.05) 0.3
FW_T_I_GAIN_PIT (FLOAT) Integrator gain pitch

Comment: This is the integrator gain on the pitch part of the control loop. Increasing this gain increases the speed at which speed and height offsets are trimmed out, but reduces damping and increases overshoot. Set this value to zero to completely disable all integrator action.

0.0 > 2.0 (0.05) 0.1
FW_T_I_GAIN_THR (FLOAT) Integrator gain throttle

Comment: This is the integrator gain on the throttle part of the control loop. Increasing this gain increases the speed at which speed and height offsets are trimmed out, but reduces damping and increases overshoot. Set this value to zero to completely disable all integrator action.

0.0 > 2.0 (0.05) 0.3
FW_T_PTCH_DAMP (FLOAT) Pitch damping factor

Comment: This is the damping gain for the pitch demand loop. Increase to add damping to correct for oscillations in height. The default value of 0.0 will work well provided the pitch to servo controller has been tuned properly.

0.0 > 2.0 (0.1) 0.1
FW_T_RLL2THR (FLOAT) Roll -> Throttle feedforward

Comment: Increasing this gain turn increases the amount of throttle that will be used to compensate for the additional drag created by turning. Ideally this should be set to approximately 10 x the extra sink rate in m/s created by a 45 degree bank turn. Increase this gain if the aircraft initially loses energy in turns and reduce if the aircraft initially gains energy in turns. Efficient high aspect-ratio aircraft (eg powered sailplanes) can use a lower value, whereas inefficient low aspect-ratio models (eg delta wings) can use a higher value.

0.0 > 20.0 (0.5) 15.0
FW_T_SEB_R_FF (FLOAT) Specific total energy balance rate feedforward gain 0.5 > 3 (0.01) 1.0
FW_T_SINK_MAX (FLOAT) Maximum descent rate

Comment: This sets the maximum descent rate that the controller will use. If this value is too large, the aircraft can over-speed on descent. This should be set to a value that can be achieved without exceeding the lower pitch angle limit and without over-speeding the aircraft.

1.0 > 15.0 (0.5) 5.0 m/s
FW_T_SINK_MIN (FLOAT) Minimum descent rate

Comment: This is the sink rate of the aircraft with the throttle set to THR_MIN and flown at the same airspeed as used to measure FW_T_CLMB_MAX.

1.0 > 5.0 (0.5) 2.0 m/s
FW_T_SINK_R_SP (FLOAT) Default target sinkrate

Comment: The default rate at which the vehicle will sink in autonomous modes to achieve altitude setpoints. In manual modes this defines the maximum rate at which the altitude setpoint can be decreased.

0.5 > 15 (0.01) 2.0 m/s
FW_T_SPDWEIGHT (FLOAT) Speed <--> Altitude priority

Comment: This parameter adjusts the amount of weighting that the pitch control applies to speed vs height errors. Setting it to 0.0 will cause the pitch control to control height and ignore speed errors. This will normally improve height accuracy but give larger airspeed errors. Setting it to 2.0 will cause the pitch control loop to control speed and ignore height errors. This will normally reduce airspeed errors, but give larger height errors. The default value of 1.0 allows the pitch control to simultaneously control height and speed. Note to Glider Pilots - set this parameter to 2.0 (The glider will adjust its pitch angle to maintain airspeed, ignoring changes in height).

0.0 > 2.0 (1.0) 1.0
FW_T_SPD_OMEGA (FLOAT) Complementary filter "omega" parameter for speed

Comment: This is the cross-over frequency (in radians/second) of the complementary filter used to fuse longitudinal acceleration and airspeed to obtain an improved airspeed estimate. Increasing this frequency weights the solution more towards use of the airspeed sensor, whilst reducing it weights the solution more towards use of the accelerometer data.

1.0 > 10.0 (0.5) 2.0 rad/s
FW_T_STE_R_TC (FLOAT) Specific total energy rate first order filter time constant

Comment: This filter is applied to the specific total energy rate used for throttle damping.

0.0 > 2 (0.01) 0.4
FW_T_TAS_R_TC (FLOAT) True airspeed rate first order filter time constant

Comment: This filter is applied to the true airspeed rate.

0.0 > 2 (0.01) 0.2
FW_T_TAS_TC (FLOAT) True airspeed error time constant 2.0 > ? (0.5) 5.0
FW_T_THR_DAMP (FLOAT) Throttle damping factor

Comment: This is the damping gain for the throttle demand loop. Increase to add damping to correct for oscillations in speed and height.

0.0 > 2.0 (0.1) 0.1
FW_T_VERT_ACC (FLOAT) Maximum vertical acceleration

Comment: This is the maximum vertical acceleration (in m/s/s) either up or down that the controller will use to correct speed or height errors. The default value of 7 m/s/s (equivalent to +- 0.7 g) allows for reasonably aggressive pitch changes if required to recover from under-speed conditions.

1.0 > 10.0 (0.5) 7.0 m/s^2

Failure Detector

NameDescriptionMin > Max (Incr.)DefaultUnits
FD_ESCS_EN (INT32) Enable checks on ESCs that report their arming state

Comment: If enabled, failure detector will verify that all the ESCs have successfully armed when the vehicle has transitioned to the armed state. Timeout for receiving an acknowledgement from the ESCs is 0.3s, if no feedback is received the failure detector will auto disarm the vehicle.

Enabled (1)
FD_EXT_ATS_EN (INT32) Enable PWM input on for engaging failsafe from an external automatic trigger system (ATS)

Comment: Enabled on either AUX5 or MAIN5 depending on board. External ATS is required by ASTM F3322-18.

Reboot required: true

Disabled (0)
FD_EXT_ATS_TRIG (INT32) The PWM threshold from external automatic trigger system for engaging failsafe

Comment: External ATS is required by ASTM F3322-18.

1900 us
FD_FAIL_P (INT32) FailureDetector Max Pitch

Comment: Maximum pitch angle before FailureDetector triggers the attitude_failure flag. The flag triggers flight termination (if @CBRK_FLIGHTTERM = 0), which sets outputs to their failsafe values. On takeoff the flag triggers lockdown (irrespective of @CBRK_FLIGHTTERM), which disarms motors but does not set outputs to failsafe values. Setting this parameter to 0 disables the check

60 > 180 60 deg
FD_FAIL_P_TTRI (FLOAT) Pitch failure trigger time

Comment: Seconds (decimal) that pitch has to exceed FD_FAIL_P before being considered as a failure.

0.02 > 5 0.3 s
FD_FAIL_R (INT32) FailureDetector Max Roll

Comment: Maximum roll angle before FailureDetector triggers the attitude_failure flag. The flag triggers flight termination (if @CBRK_FLIGHTTERM = 0), which sets outputs to their failsafe values. On takeoff the flag triggers lockdown (irrespective of @CBRK_FLIGHTTERM), which disarms motors but does not set outputs to failsafe values. Setting this parameter to 0 disables the check

60 > 180 60 deg
FD_FAIL_R_TTRI (FLOAT) Roll failure trigger time

Comment: Seconds (decimal) that roll has to exceed FD_FAIL_R before being considered as a failure.

0.02 > 5 0.3 s

Follow target

NameDescriptionMin > Max (Incr.)DefaultUnits
NAV_FT_DST (FLOAT) Distance to follow target from

Comment: The distance in meters to follow the target at

1.0 > ? 8.0 m
NAV_FT_FS (INT32) Side to follow target from

Comment: The side to follow the target from (front right = 0, behind = 1, front = 2, front left = 3)

0 > 3 1
NAV_FT_RS (FLOAT) Dynamic filtering algorithm responsiveness to target movement

Comment: lower numbers increase the responsiveness to changing long lat but also ignore less noise

0.0 > 1.0 0.5
NAV_MIN_FT_HT (FLOAT) Minimum follow target altitude

Comment: The minimum height in meters relative to home for following a target

8.0 > ? 8.0 m

GPS

NameDescriptionMin > Max (Incr.)DefaultUnits
GPS_1_CONFIG (INT32) Serial Configuration for Main GPS

Comment: Configure on which serial port to run Main GPS.

Values:
  • 0: Disabled
  • 6: UART 6
  • 101: TELEM 1
  • 102: TELEM 2
  • 103: TELEM 3
  • 104: TELEM/SERIAL 4
  • 201: GPS 1
  • 202: GPS 2
  • 203: GPS 3
  • 300: Radio Controller
  • 301: Wifi Port

Reboot required: true

201
GPS_1_GNSS (INT32) GNSS Systems for Primary GPS (integer bitmask)

Comment: This integer bitmask controls the set of GNSS systems used by the receiver. Check your receiver's documentation on how many systems are supported to be used in parallel. Currently this functionality is just implemented for u-blox receivers. When no bits are set, the receiver's default configuration should be used. Set bits true to enable: 0 : Use GPS (with QZSS) 1 : Use SBAS (multiple GPS augmentation systems) 2 : Use Galileo 3 : Use BeiDou 4 : Use GLONASS

Bitmask:
  • 0: GPS (with QZSS)
  • 1: SBAS
  • 2: Galileo
  • 3: BeiDou
  • 4: GLONASS

Reboot required: true

0 > 31 0
GPS_1_PROTOCOL (INT32) Protocol for Main GPS

Comment: Select the GPS protocol over serial. Auto-detection will probe all protocols, and thus is a bit slower.

Values:
  • 0: Auto detect
  • 1: u-blox
  • 2: MTK
  • 3: Ashtech / Trimble
  • 4: Emlid Reach
  • 5: Femtomes
  • 6: NMEA (generic)

Reboot required: true

0 > 5 1
GPS_2_CONFIG (INT32) Serial Configuration for Secondary GPS

Comment: Configure on which serial port to run Secondary GPS.

Values:
  • 0: Disabled
  • 6: UART 6
  • 101: TELEM 1
  • 102: TELEM 2
  • 103: TELEM 3
  • 104: TELEM/SERIAL 4
  • 201: GPS 1
  • 202: GPS 2
  • 203: GPS 3
  • 300: Radio Controller
  • 301: Wifi Port

Reboot required: true

0
GPS_2_GNSS (INT32) GNSS Systems for Secondary GPS (integer bitmask)

Comment: This integer bitmask controls the set of GNSS systems used by the receiver. Check your receiver's documentation on how many systems are supported to be used in parallel. Currently this functionality is just implemented for u-blox receivers. When no bits are set, the receiver's default configuration should be used. Set bits true to enable: 0 : Use GPS (with QZSS) 1 : Use SBAS (multiple GPS augmentation systems) 2 : Use Galileo 3 : Use BeiDou 4 : Use GLONASS

Bitmask:
  • 0: GPS (with QZSS)
  • 1: SBAS
  • 2: Galileo
  • 3: BeiDou
  • 4: GLONASS

Reboot required: true

0 > 31 0
GPS_2_PROTOCOL (INT32) Protocol for Secondary GPS

Comment: Select the GPS protocol over serial. Auto-detection will probe all protocols, and thus is a bit slower.

Values:
  • 0: Auto detect
  • 1: u-blox
  • 2: MTK
  • 3: Ashtech / Trimble
  • 4: Emlid Reach
  • 5: Femtomes
  • 6: NMEA (generic)

Reboot required: true

0 > 5 1
GPS_DUMP_COMM (INT32) Log GPS communication data

Comment: If this is set to 1, all GPS communication data will be published via uORB, and written to the log file as gps_dump message. If this is set to 2, the main GPS is configured to output RTCM data, which is then logged as gps_dump and can be used for PPK.

Values:
  • 0: Disable
  • 1: Full communication
  • 2: RTCM output (PPK)
0 > 2 0
GPS_UBX_DYNMODEL (INT32) u-blox GPS dynamic platform model

Comment: u-blox receivers support different dynamic platform models to adjust the navigation engine to the expected application environment.

Values:
  • 2: stationary
  • 4: automotive
  • 6: airborne with <1g acceleration
  • 7: airborne with <2g acceleration
  • 8: airborne with <4g acceleration

Reboot required: true

0 > 9 7
GPS_UBX_MODE (INT32) u-blox GPS Mode

Comment: Select the u-blox configuration setup. Most setups will use the default, including RTK and dual GPS without heading. The Heading mode requires 2 F9P devices to be attached. The main GPS will act as rover and output heading information, whereas the secondary will act as moving base, sending RTCM on UART2 to the rover GPS. RTK is still possible with this setup.

Values:
  • 0: Default
  • 1: Heading

Reboot required: true

0 > 1 0
GPS_YAW_OFFSET (FLOAT) Heading/Yaw offset for dual antenna GPS

Comment: Heading offset angle for dual antenna GPS setups that support heading estimation. (currently only for the Trimble MB-Two). Set this to 0 if the antennas are parallel to the forward-facing direction of the vehicle and the first antenna is in front. The offset angle increases clockwise. Set this to 90 if the first antenna is placed on the right side and the second on the left side of the vehicle.

Reboot required: true

0 > 360 0. deg

GPS Failure Navigation

NameDescriptionMin > Max (Incr.)DefaultUnits
NAV_GPSF_LT (FLOAT) Loiter time

Comment: The time in seconds the system should do open loop loiter and wait for GPS recovery before it goes into flight termination. Set to 0 to disable.

0.0 > 3600.0 (1) 0.0 s
NAV_GPSF_P (FLOAT) Fixed pitch angle

Comment: Pitch in degrees during the open loop loiter

-30.0 > 30.0 (0.5) 0.0 deg
NAV_GPSF_R (FLOAT) Fixed bank angle

Comment: Roll in degrees during the loiter

0.0 > 30.0 (0.5) 15.0 deg
NAV_GPSF_TR (FLOAT) Thrust

Comment: Thrust value which is set during the open loop loiter

0.0 > 1.0 (0.05) 0.0 norm

Geofence

NameDescriptionMin > Max (Incr.)DefaultUnits
GF_ACTION (INT32) Geofence violation action

Comment: Note: Setting this value to 4 enables flight termination, which will kill the vehicle on violation of the fence. Due to the inherent danger of this, this function is disabled using a software circuit breaker, which needs to be reset to 0 to really shut down the system.

Values:
  • 0: None
  • 1: Warning
  • 2: Hold mode
  • 3: Return mode
  • 4: Terminate
  • 5: Land mode
0 > 5 2
GF_ALTMODE (INT32) Geofence altitude mode

Comment: Select which altitude (AMSL) source should be used for geofence calculations.

Values:
  • 0: Autopilot estimator global position altitude (GPS)
  • 1: Raw barometer altitude (assuming standard atmospheric pressure)
0 > 1 0
GF_COUNT (INT32) Geofence counter limit

Comment: Set how many subsequent position measurements outside of the fence are needed before geofence violation is triggered

-1 > 10 (1) -1
GF_MAX_HOR_DIST (FLOAT) Max horizontal distance in meters

Comment: Maximum horizontal distance in meters the vehicle can be from home before triggering a geofence action. Disabled if 0.

0 > 10000 (1) 0 m
GF_MAX_VER_DIST (FLOAT) Max vertical distance in meters

Comment: Maximum vertical distance in meters the vehicle can be from home before triggering a geofence action. Disabled if 0.

0 > 10000 (1) 0 m
GF_SOURCE (INT32) Geofence source

Comment: Select which position source should be used. Selecting GPS instead of global position makes sure that there is no dependence on the position estimator 0 = global position, 1 = GPS

Values:
  • 0: GPOS
  • 1: GPS
0 > 1 0

Hover Thrust Estimator

NameDescriptionMin > Max (Incr.)DefaultUnits
HTE_ACC_GATE (FLOAT) Gate size for acceleration fusion

Comment: Sets the number of standard deviations used by the innovation consistency test.

1.0 > 10.0 3.0 SD
HTE_HT_ERR_INIT (FLOAT) 1-sigma initial hover thrust uncertainty

Comment: Sets the number of standard deviations used by the innovation consistency test.

0.0 > 1.0 0.1 normalized_thrust
HTE_HT_NOISE (FLOAT) Hover thrust process noise

Comment: Reduce to make the hover thrust estimate more stable, increase if the real hover thrust is expected to change quickly over time.

0.0001 > 1.0 0.0036 normalized_thrust/s

Iridium SBD

NameDescriptionMin > Max (Incr.)DefaultUnits
ISBD_CONFIG (INT32) Serial Configuration for Iridium (with MAVLink)

Comment: Configure on which serial port to run Iridium (with MAVLink).

Values:
  • 0: Disabled
  • 6: UART 6
  • 101: TELEM 1
  • 102: TELEM 2
  • 103: TELEM 3
  • 104: TELEM/SERIAL 4
  • 201: GPS 1
  • 202: GPS 2
  • 203: GPS 3
  • 300: Radio Controller
  • 301: Wifi Port

Reboot required: true

0
ISBD_READ_INT (INT32) Satellite radio read interval. Only required to be nonzero if data is not sent using a ring call 0 > 5000 0 s
ISBD_SBD_TIMEOUT (INT32) Iridium SBD session timeout 0 > 300 60 s
ISBD_STACK_TIME (INT32) Time the Iridium driver will wait for additional mavlink messages to combine them into one SBD message

Comment: Value 0 turns the functionality off

0 > 500 0 ms

Land Detector

NameDescriptionMin > Max (Incr.)DefaultUnits
LNDFW_AIRSPD_MAX (FLOAT) Airspeed max

Comment: Maximum airspeed allowed in the landed state

4 > 20 6.00 m/s
LNDFW_VEL_XY_MAX (FLOAT) Fixedwing max horizontal velocity

Comment: Maximum horizontal velocity allowed in the landed state

0.5 > 10 5.0 m/s
LNDFW_VEL_Z_MAX (FLOAT) Fixedwing max climb rate

Comment: Maximum vertical velocity allowed in the landed state

0.1 > 20 3.0 m/s
LNDFW_XYACC_MAX (FLOAT) Fixedwing max horizontal acceleration

Comment: Maximum horizontal (x,y body axes) acceleration allowed in the landed state

2 > 15 8.0 m/s^2
LNDMC_ALT_GND (FLOAT) Ground effect altitude for multicopters

Comment: The height above ground below which ground effect creates barometric altitude errors. A negative value indicates no ground effect.

-1 > ? -1.0 m
LNDMC_ALT_MAX (FLOAT) Maximum altitude for multicopters

Comment: The system will obey this limit as a hard altitude limit. This setting will be consolidated with the GF_MAX_VER_DIST parameter. A negative value indicates no altitude limitation.

-1 > 10000 -1.0 m
LNDMC_ROT_MAX (FLOAT) Multicopter max rotation

Comment: Maximum allowed angular velocity around each axis allowed in the landed state.

20.0 deg/s
LNDMC_TRIG_TIME (FLOAT) Multicopter land detection trigger time

Comment: Total time it takes to go through all three land detection stages: ground contact, maybe landed, landed when all necessary conditions are constantly met.

0.1 > 10.0 1.0 s
LNDMC_XY_VEL_MAX (FLOAT) Multicopter max horizontal velocity

Comment: Maximum horizontal velocity allowed in the landed state

1.5 m/s
LNDMC_Z_VEL_MAX (FLOAT) Multicopter max climb rate

Comment: Maximum vertical velocity allowed in the landed state

0.50 m/s
LND_FLIGHT_T_HI (INT32) Total flight time in microseconds

Comment: Total flight time of this autopilot. Higher 32 bits of the value. Flight time in microseconds = (LND_FLIGHT_T_HI << 32) | LND_FLIGHT_T_LO.

0 > ? 0
LND_FLIGHT_T_LO (INT32) Total flight time in microseconds

Comment: Total flight time of this autopilot. Lower 32 bits of the value. Flight time in microseconds = (LND_FLIGHT_T_HI << 32) | LND_FLIGHT_T_LO.

0 > ? 0

Landing target Estimator

NameDescriptionMin > Max (Incr.)DefaultUnits
LTEST_ACC_UNC (FLOAT) Acceleration uncertainty

Comment: Variance of acceleration measurement used for landing target position prediction. Higher values results in tighter following of the measurements and more lenient outlier rejection

0.01 > ? 10.0 (m/s^2)^2
LTEST_MEAS_UNC (FLOAT) Landing target measurement uncertainty

Comment: Variance of the landing target measurement from the driver. Higher values result in less aggressive following of the measurement and a smoother output as well as fewer rejected measurements.

0.005 tan(rad)^2
LTEST_MODE (INT32) Landing target mode

Comment: Configure the mode of the landing target. Depending on the mode, the landing target observations are used differently to aid position estimation. Mode Moving: The landing target may be moving around while in the field of view of the vehicle. Landing target measurements are not used to aid positioning. Mode Stationary: The landing target is stationary. Measured velocity w.r.t. the landing target is used to aid velocity estimation.

Values:
  • 0: Moving
  • 1: Stationary
0 > 1 0
LTEST_POS_UNC_IN (FLOAT) Initial landing target position uncertainty

Comment: Initial variance of the relative landing target position in x and y direction

0.001 > ? 0.1 m^2
LTEST_SCALE_X (FLOAT) Scale factor for sensor measurements in sensor x axis

Comment: Landing target x measurements are scaled by this factor before being used

0.01 > ? 1.0
LTEST_SCALE_Y (FLOAT) Scale factor for sensor measurements in sensor y axis

Comment: Landing target y measurements are scaled by this factor before being used

0.01 > ? 1.0
LTEST_VEL_UNC_IN (FLOAT) Initial landing target velocity uncertainty

Comment: Initial variance of the relative landing target velocity in x and y directions

0.001 > ? 0.1 (m/s)^2

Local Position Estimator

NameDescriptionMin > Max (Incr.)DefaultUnits
LPE_ACC_XY (FLOAT) Accelerometer xy noise density

Comment: Data sheet noise density = 150ug/sqrt(Hz) = 0.0015 m/s^2/sqrt(Hz) Larger than data sheet to account for tilt error.

0.00001 > 2 0.012 m/s^2/sqrt(Hz)
LPE_ACC_Z (FLOAT) Accelerometer z noise density

Comment: Data sheet noise density = 150ug/sqrt(Hz) = 0.0015 m/s^2/sqrt(Hz)

0.00001 > 2 0.02 m/s^2/sqrt(Hz)
LPE_BAR_Z (FLOAT) Barometric presssure altitude z standard deviation 0.01 > 100 3.0 m
LPE_EPH_MAX (FLOAT) Max EPH allowed for GPS initialization 1.0 > 5.0 3.0 m
LPE_EPV_MAX (FLOAT) Max EPV allowed for GPS initialization 1.0 > 5.0 5.0 m
LPE_FAKE_ORIGIN (INT32) Enable publishing of a fake global position (e.g for AUTO missions using Optical Flow)

Comment: By initializing the estimator to the LPE_LAT/LON parameters when global information is unavailable

0 > 1 0
LPE_FGYRO_HP (FLOAT) Flow gyro high pass filter cut off frequency 0 > 2 0.001 Hz
LPE_FLW_OFF_Z (FLOAT) Optical flow z offset from center -1 > 1 0.0 m
LPE_FLW_QMIN (INT32) Optical flow minimum quality threshold 0 > 255 150
LPE_FLW_R (FLOAT) Optical flow rotation (roll/pitch) noise gain 0.1 > 10.0 7.0 m/s/rad
LPE_FLW_RR (FLOAT) Optical flow angular velocity noise gain 0.0 > 10.0 7.0 m/rad
LPE_FLW_SCALE (FLOAT) Optical flow scale 0.1 > 10.0 1.3 m
LPE_FUSION (INT32) Integer bitmask controlling data fusion

Comment: Set bits in the following positions to enable: 0 : Set to true to fuse GPS data if available, also requires GPS for altitude init 1 : Set to true to fuse optical flow data if available 2 : Set to true to fuse vision position 3 : Set to true to enable landing target 4 : Set to true to fuse land detector 5 : Set to true to publish AGL as local position down component 6 : Set to true to enable flow gyro compensation 7 : Set to true to enable baro fusion default (145 - GPS, baro, land detector)

Bitmask:
  • 0: fuse GPS, requires GPS for alt. init
  • 1: fuse optical flow
  • 2: fuse vision position
  • 3: fuse landing target
  • 4: fuse land detector
  • 5: pub agl as lpos down
  • 6: flow gyro compensation
  • 7: fuse baro
0 > 255 145
LPE_GPS_DELAY (FLOAT) GPS delay compensaton 0 > 0.4 0.29 s
LPE_GPS_VXY (FLOAT) GPS xy velocity standard deviation

Comment: EPV used if greater than this value.

0.01 > 2 0.25 m/s
LPE_GPS_VZ (FLOAT) GPS z velocity standard deviation 0.01 > 2 0.25 m/s
LPE_GPS_XY (FLOAT) Minimum GPS xy standard deviation, uses reported EPH if greater 0.01 > 5 1.0 m
LPE_GPS_Z (FLOAT) Minimum GPS z standard deviation, uses reported EPV if greater 0.01 > 200 3.0 m
LPE_LAND_VXY (FLOAT) Land detector xy velocity standard deviation 0.01 > 10.0 0.05 m/s
LPE_LAND_Z (FLOAT) Land detector z standard deviation 0.001 > 10.0 0.03 m
LPE_LAT (FLOAT) Local origin latitude for nav w/o GPS -90 > 90 47.397742 deg
LPE_LDR_OFF_Z (FLOAT) Lidar z offset from center of vehicle +down -1 > 1 0.00 m
LPE_LDR_Z (FLOAT) Lidar z standard deviation 0.01 > 1 0.03 m
LPE_LON (FLOAT) Local origin longitude for nav w/o GPS -180 > 180 8.545594 deg
LPE_LT_COV (FLOAT) Minimum landing target standard covariance, uses reported covariance if greater 0.0 > 10 0.0001 m^2
LPE_PN_B (FLOAT) Accel bias propagation noise density 0 > 1 1e-3 m/s^3/sqrt(Hz)
LPE_PN_P (FLOAT) Position propagation noise density

Comment: Increase to trust measurements more. Decrease to trust model more.

0 > 1 0.1 m/s/sqrt(Hz)
LPE_PN_T (FLOAT) Terrain random walk noise density, hilly/outdoor (0.1), flat/Indoor (0.001) 0 > 1 0.001 m/s/sqrt(Hz)
LPE_PN_V (FLOAT) Velocity propagation noise density

Comment: Increase to trust measurements more. Decrease to trust model more.

0 > 1 0.1 m/s^2/sqrt(Hz)
LPE_SNR_OFF_Z (FLOAT) Sonar z offset from center of vehicle +down -1 > 1 0.00 m
LPE_SNR_Z (FLOAT) Sonar z standard deviation 0.01 > 1 0.05 m
LPE_T_MAX_GRADE (FLOAT) Terrain maximum percent grade, hilly/outdoor (100 = 45 deg), flat/Indoor (0 = 0 deg)

Comment: Used to calculate increased terrain random walk nosie due to movement.

0 > 100 1.0 %
LPE_VIC_P (FLOAT) Vicon position standard deviation 0.0001 > 1 0.001 m
LPE_VIS_DELAY (FLOAT) Vision delay compensation

Comment: Set to zero to enable automatic compensation from measurement timestamps

0 > 0.1 0.1 s
LPE_VIS_XY (FLOAT) Vision xy standard deviation 0.01 > 1 0.1 m
LPE_VIS_Z (FLOAT) Vision z standard deviation 0.01 > 100 0.5 m
LPE_VXY_PUB (FLOAT) Required velocity xy standard deviation to publish position 0.01 > 1.0 0.3 m/s
LPE_X_LP (FLOAT) Cut frequency for state publication 5 > 1000 5.0 Hz
LPE_Z_PUB (FLOAT) Required z standard deviation to publish altitude/ terrain 0.3 > 5.0 1.0 m
NameDescriptionMin > Max (Incr.)DefaultUnits
MAV_0_BROADCAST (INT32) Broadcast heartbeats on local network for MAVLink instance 0

Comment: This allows a ground control station to automatically find the drone on the local network.

Values:
  • 0: Never broadcast
  • 1: Always broadcast
  • 2: Only multicast
1
MAV_0_CONFIG (INT32) Serial Configuration for MAVLink (instance 0)

Comment: Configure on which serial port to run MAVLink.

Values:
  • 0: Disabled
  • 6: UART 6
  • 101: TELEM 1
  • 102: TELEM 2
  • 103: TELEM 3
  • 104: TELEM/SERIAL 4
  • 201: GPS 1
  • 202: GPS 2
  • 203: GPS 3
  • 300: Radio Controller
  • 301: Wifi Port
  • 1000: Ethernet

Reboot required: true

101
MAV_0_FORWARD (INT32) Enable MAVLink Message forwarding for instance 0

Comment: If enabled, forward incoming MAVLink messages to other MAVLink ports if the message is either broadcast or the target is not the autopilot. This allows for example a GCS to talk to a camera that is connected to the autopilot via MAVLink (on a different link than the GCS).

Reboot required: True

Enabled (1)
MAV_0_MODE (INT32) MAVLink Mode for instance 0

Comment: The MAVLink Mode defines the set of streamed messages (for example the vehicle's attitude) and their sending rates.

Values:
  • 0: Normal
  • 1: Custom
  • 2: Onboard
  • 3: OSD
  • 4: Magic
  • 5: Config
  • 7: Minimal
  • 8: External Vision
  • 10: Gimbal
  • 11: Onboard Low Bandwidth

Reboot required: True

0
MAV_0_RADIO_CTL (INT32) Enable software throttling of mavlink on instance 0

Comment: If enabled, MAVLink messages will be throttled according to `txbuf` field reported by radio_status. Requires a radio to send the mavlink message RADIO_STATUS.

Reboot required: True

Enabled (1)
MAV_0_RATE (INT32) Maximum MAVLink sending rate for instance 0

Comment: Configure the maximum sending rate for the MAVLink streams in Bytes/sec. If the configured streams exceed the maximum rate, the sending rate of each stream is automatically decreased. If this is set to 0 a value of half of the theoretical maximum bandwidth is used. This corresponds to baudrate/20 Bytes/s (baudrate/10 = maximum data rate on 8N1-configured links).

Reboot required: True

0 > ? 1200 B/s
MAV_0_REMOTE_PRT (INT32) MAVLink Remote Port for instance 0

Comment: If ethernet enabled and selected as configuration for MAVLink instance 0, selected remote port will be set and used in MAVLink instance 0.

Reboot required: True

14550
MAV_0_UDP_PRT (INT32) MAVLink Network Port for instance 0

Comment: If ethernet enabled and selected as configuration for MAVLink instance 0, selected udp port will be set and used in MAVLink instance 0.

Reboot required: True

14556
MAV_1_BROADCAST (INT32) Broadcast heartbeats on local network for MAVLink instance 1

Comment: This allows a ground control station to automatically find the drone on the local network.

Values:
  • 0: Never broadcast
  • 1: Always broadcast
  • 2: Only multicast
0
MAV_1_CONFIG (INT32) Serial Configuration for MAVLink (instance 1)

Comment: Configure on which serial port to run MAVLink.

Values:
  • 0: Disabled
  • 6: UART 6
  • 101: TELEM 1
  • 102: TELEM 2
  • 103: TELEM 3
  • 104: TELEM/SERIAL 4
  • 201: GPS 1
  • 202: GPS 2
  • 203: GPS 3
  • 300: Radio Controller
  • 301: Wifi Port
  • 1000: Ethernet

Reboot required: true

0
MAV_1_FORWARD (INT32) Enable MAVLink Message forwarding for instance 1

Comment: If enabled, forward incoming MAVLink messages to other MAVLink ports if the message is either broadcast or the target is not the autopilot. This allows for example a GCS to talk to a camera that is connected to the autopilot via MAVLink (on a different link than the GCS).

Reboot required: True

Disabled (0)
MAV_1_MODE (INT32) MAVLink Mode for instance 1

Comment: The MAVLink Mode defines the set of streamed messages (for example the vehicle's attitude) and their sending rates.

Values:
  • 0: Normal
  • 1: Custom
  • 2: Onboard
  • 3: OSD
  • 4: Magic
  • 5: Config
  • 7: Minimal
  • 8: External Vision
  • 10: Gimbal
  • 11: Onboard Low Bandwidth

Reboot required: True

2
MAV_1_RADIO_CTL (INT32) Enable software throttling of mavlink on instance 1

Comment: If enabled, MAVLink messages will be throttled according to `txbuf` field reported by radio_status. Requires a radio to send the mavlink message RADIO_STATUS.

Reboot required: True

Enabled (1)
MAV_1_RATE (INT32) Maximum MAVLink sending rate for instance 1

Comment: Configure the maximum sending rate for the MAVLink streams in Bytes/sec. If the configured streams exceed the maximum rate, the sending rate of each stream is automatically decreased. If this is set to 0 a value of half of the theoretical maximum bandwidth is used. This corresponds to baudrate/20 Bytes/s (baudrate/10 = maximum data rate on 8N1-configured links).

Reboot required: True

0 > ? 0 B/s
MAV_1_REMOTE_PRT (INT32) MAVLink Remote Port for instance 1

Comment: If ethernet enabled and selected as configuration for MAVLink instance 1, selected remote port will be set and used in MAVLink instance 1.

Reboot required: True

0
MAV_1_UDP_PRT (INT32) MAVLink Network Port for instance 1

Comment: If ethernet enabled and selected as configuration for MAVLink instance 1, selected udp port will be set and used in MAVLink instance 1.

Reboot required: True

0
MAV_2_BROADCAST (INT32) Broadcast heartbeats on local network for MAVLink instance 2

Comment: This allows a ground control station to automatically find the drone on the local network.

Values:
  • 0: Never broadcast
  • 1: Always broadcast
  • 2: Only multicast
0
MAV_2_CONFIG (INT32) Serial Configuration for MAVLink (instance 2)

Comment: Configure on which serial port to run MAVLink.

Values:
  • 0: Disabled
  • 6: UART 6
  • 101: TELEM 1
  • 102: TELEM 2
  • 103: TELEM 3
  • 104: TELEM/SERIAL 4
  • 201: GPS 1
  • 202: GPS 2
  • 203: GPS 3
  • 300: Radio Controller
  • 301: Wifi Port
  • 1000: Ethernet

Reboot required: true

0
MAV_2_FORWARD (INT32) Enable MAVLink Message forwarding for instance 2

Comment: If enabled, forward incoming MAVLink messages to other MAVLink ports if the message is either broadcast or the target is not the autopilot. This allows for example a GCS to talk to a camera that is connected to the autopilot via MAVLink (on a different link than the GCS).

Reboot required: True

Disabled (0)
MAV_2_MODE (INT32) MAVLink Mode for instance 2

Comment: The MAVLink Mode defines the set of streamed messages (for example the vehicle's attitude) and their sending rates.

Values:
  • 0: Normal
  • 1: Custom
  • 2: Onboard
  • 3: OSD
  • 4: Magic
  • 5: Config
  • 7: Minimal
  • 8: External Vision
  • 10: Gimbal
  • 11: Onboard Low Bandwidth

Reboot required: True

0
MAV_2_RADIO_CTL (INT32) Enable software throttling of mavlink on instance 2

Comment: If enabled, MAVLink messages will be throttled according to `txbuf` field reported by radio_status. Requires a radio to send the mavlink message RADIO_STATUS.

Reboot required: True

Enabled (1)
MAV_2_RATE (INT32) Maximum MAVLink sending rate for instance 2

Comment: Configure the maximum sending rate for the MAVLink streams in Bytes/sec. If the configured streams exceed the maximum rate, the sending rate of each stream is automatically decreased. If this is set to 0 a value of half of the theoretical maximum bandwidth is used. This corresponds to baudrate/20 Bytes/s (baudrate/10 = maximum data rate on 8N1-configured links).

Reboot required: True

0 > ? 0 B/s
MAV_2_REMOTE_PRT (INT32) MAVLink Remote Port for instance 2

Comment: If ethernet enabled and selected as configuration for MAVLink instance 2, selected remote port will be set and used in MAVLink instance 2.

Reboot required: True

0
MAV_2_UDP_PRT (INT32) MAVLink Network Port for instance 2

Comment: If ethernet enabled and selected as configuration for MAVLink instance 2, selected udp port will be set and used in MAVLink instance 2.

Reboot required: True

0
MAV_COMP_ID (INT32) MAVLink component ID

Reboot required: true

1 > 250 1
MAV_FWDEXTSP (INT32) Forward external setpoint messages

Comment: If set to 1 incoming external setpoint messages will be directly forwarded to the controllers if in offboard control mode

Enabled (1)
MAV_HASH_CHK_EN (INT32) Parameter hash check

Comment: Disabling the parameter hash check functionality will make the mavlink instance stream parameters continuously.

Enabled (1)
MAV_HB_FORW_EN (INT32) Hearbeat message forwarding

Comment: The mavlink hearbeat message will not be forwarded if this parameter is set to 'disabled'. The main reason for disabling heartbeats to be forwarded is because they confuse dronekit.

Enabled (1)
MAV_ODOM_LP (INT32) Activate ODOMETRY loopback

Comment: If set, it gets the data from 'vehicle_visual_odometry' instead of 'vehicle_odometry' serving as a loopback of the received ODOMETRY messages on the Mavlink receiver.

Disabled (0)
MAV_PROTO_VER (INT32) MAVLink protocol version Values:
  • 0: Default to 1, switch to 2 if GCS sends version 2
  • 1: Always use version 1
  • 2: Always use version 2
0
MAV_RADIO_TOUT (INT32) Timeout in seconds for the RADIO_STATUS reports coming in

Comment: If the connected radio stops reporting RADIO_STATUS for a certain time, a warning is triggered and, if MAV_X_RADIO_CTL is enabled, the software-flow control is reset.

1 > 250 5 s
MAV_SIK_RADIO_ID (INT32) MAVLink SiK Radio ID

Comment: When non-zero the MAVLink app will attempt to configure the SiK radio to this ID and re-set the parameter to 0. If the value is negative it will reset the complete radio config to factory defaults. Only applies if this mavlink instance is going through a SiK radio

-1 > 240 0
MAV_SYS_ID (INT32) MAVLink system ID

Reboot required: true

1 > 250 1
MAV_TYPE (INT32) MAVLink airframe type Values:
  • 0: Generic micro air vehicle
  • 1: Fixed wing aircraft
  • 2: Quadrotor
  • 3: Coaxial helicopter
  • 4: Normal helicopter with tail rotor
  • 5: Ground installation
  • 6: Operator control unit / ground control station
  • 7: Airship, controlled
  • 8: Free balloon, uncontrolled
  • 9: Rocket
  • 10: Ground rover
  • 11: Surface vessel, boat, ship
  • 12: Submarine
  • 13: Hexarotor
  • 14: Octorotor
  • 15: Tricopter
  • 16: Flapping wing
  • 17: Kite
  • 18: Onboard companion controller
  • 19: Two-rotor VTOL using control surfaces in vertical operation in addition. Tailsitter.
  • 20: Quad-rotor VTOL using a V-shaped quad config in vertical operation. Tailsitter.
  • 21: Tiltrotor VTOL
  • 22: VTOL reserved 2
  • 23: VTOL reserved 3
  • 24: VTOL reserved 4
  • 25: VTOL reserved 5
  • 26: Onboard gimbal
  • 27: Onboard ADSB peripheral
1 > 27 2
MAV_USEHILGPS (INT32) Use/Accept HIL GPS message even if not in HIL mode

Comment: If set to 1 incoming HIL GPS messages are parsed.

Disabled (0)

Mission

NameDescriptionMin > Max (Incr.)DefaultUnits
MIS_DIST_1WP (FLOAT) Maximal horizontal distance from home to first waypoint

Comment: Failsafe check to prevent running mission stored from previous flight at a new takeoff location. Set a value of zero or less to disable. The mission will not be started if the current waypoint is more distant than MIS_DIST_1WP from the home position.

0 > 10000 (100) 900 m
MIS_DIST_WPS (FLOAT) Maximal horizontal distance between waypoint

Comment: Failsafe check to prevent running missions which are way too big. Set a value of zero or less to disable. The mission will not be started if any distance between two subsequent waypoints is greater than MIS_DIST_WPS.

0 > 10000 (100) 900 m
MIS_LTRMIN_ALT (FLOAT) Minimum Loiter altitude

Comment: This is the minimum altitude the system will always obey. The intent is to stay out of ground effect. set to -1, if there shouldn't be a minimum loiter altitude

-1 > 80 (0.5) -1.0 m
MIS_MNT_YAW_CTL (INT32) Enable yaw control of the mount. (Only affects multicopters and ROI mission items)

Comment: If enabled, yaw commands will be sent to the mount and the vehicle will follow its heading towards the flight direction. If disabled, the vehicle will yaw towards the ROI.

Values:
  • 0: Disable
  • 1: Enable
0 > 1 0
MIS_TAKEOFF_ALT (FLOAT) Take-off altitude

Comment: This is the minimum altitude the system will take off to.

0 > 80 (0.5) 2.5 m
MIS_TAKEOFF_REQ (INT32) Take-off waypoint required

Comment: If set, the mission feasibility checker will check for a takeoff waypoint on the mission.

Disabled (0)
MIS_YAW_ERR (FLOAT) Max yaw error in degrees needed for waypoint heading acceptance 0 > 90 (1) 12.0 deg
MIS_YAW_TMT (FLOAT) Time in seconds we wait on reaching target heading at a waypoint if it is forced

Comment: If set > 0 it will ignore the target heading for normal waypoint acceptance. If the waypoint forces the heading the timeout will matter. For example on VTOL forwards transition. Mainly useful for VTOLs that have less yaw authority and might not reach target yaw in wind. Disabled by default.

-1 > 20 (1) -1.0 s
MPC_YAW_MODE (INT32) Yaw mode

Comment: Specifies the heading in Auto.

Values:
  • 0: towards waypoint
  • 1: towards home
  • 2: away from home
  • 3: along trajectory
  • 4: towards waypoint (yaw first)
0 > 4 0
NAV_ACC_RAD (FLOAT) Acceptance Radius

Comment: Default acceptance radius, overridden by acceptance radius of waypoint if set. For fixed wing the L1 turning distance is used for horizontal acceptance.

0.05 > 200.0 (0.5) 10.0 m
NAV_FORCE_VT (INT32) Force VTOL mode takeoff and land Enabled (1)
NAV_FW_ALTL_RAD (FLOAT) FW Altitude Acceptance Radius before a landing

Comment: Altitude acceptance used for the last waypoint before a fixed-wing landing. This is usually smaller than the standard vertical acceptance because close to the ground higher accuracy is required.

0.05 > 200.0 5.0 m
NAV_FW_ALT_RAD (FLOAT) FW Altitude Acceptance Radius

Comment: Acceptance radius for fixedwing altitude.

0.05 > 200.0 (0.5) 10.0 m
NAV_LOITER_RAD (FLOAT) Loiter radius (FW only)

Comment: Default value of loiter radius for missions, Hold mode, Return mode, etc. (fixedwing only).

25 > 1000 (0.5) 50.0 m
NAV_MC_ALT_RAD (FLOAT) MC Altitude Acceptance Radius

Comment: Acceptance radius for multicopter altitude.

0.05 > 200.0 (0.5) 0.8 m
NAV_TRAFF_AVOID (INT32) Set traffic avoidance mode

Comment: Enabling this will allow the system to respond to transponder data from e.g. ADSB transponders

Values:
  • 0: Disabled
  • 1: Warn only
  • 2: Return mode
  • 3: Land mode
  • 4: Position Hold mode
1
NAV_TRAFF_A_RADM (FLOAT) Set NAV TRAFFIC AVOID RADIUS MANNED

Comment: Defines the Radius where NAV TRAFFIC AVOID is Called For Manned Aviation

500 > ? 500 m
NAV_TRAFF_A_RADU (FLOAT) Set NAV TRAFFIC AVOID RADIUS

Comment: Defines the Radius where NAV TRAFFIC AVOID is Called For Unmanned Aviation

10 > 500 10 m

Mixer Output

NameDescriptionMin > Max (Incr.)DefaultUnits
MC_AIRMODE (INT32) Multicopter air-mode

Comment: The air-mode enables the mixer to increase the total thrust of the multirotor in order to keep attitude and rate control even at low and high throttle. This function should be disabled during tuning as it will help the controller to diverge if the closed-loop is unstable (i.e. the vehicle is not tuned yet). Enabling air-mode for yaw requires the use of an arming switch.

Values:
  • 0: Disabled
  • 1: Roll/Pitch
  • 2: Roll/Pitch/Yaw
0
MOT_ORDERING (INT32) Motor Ordering

Comment: Determines the motor ordering. This can be used for example in combination with a 4-in-1 ESC that assumes a motor ordering which is different from PX4. ONLY supported for Quads. When changing this, make sure to test the motor response without props first.

Values:
  • 0: PX4
  • 1: Betaflight / Cleanflight
0

Mount

NameDescriptionMin > Max (Incr.)DefaultUnits
MNT_DO_STAB (INT32) Stabilize the mount

Comment: Set to true for servo gimbal, false for passthrough. This is required for a gimbal which is not capable of stabilizing itself and relies on the IMU's attitude estimation.

Values:
  • 0: Disable
  • 1: Stabilize all axis
  • 2: Stabilize yaw for absolute/lock mode.
0 > 2 0
MNT_MAN_PITCH (INT32) Auxiliary channel to control pitch (in AUX input or manual mode) Values:
  • 0: Disable
  • 1: AUX1
  • 2: AUX2
  • 3: AUX3
  • 4: AUX4
  • 5: AUX5
  • 6: AUX6
0 > 6 0
MNT_MAN_ROLL (INT32) Auxiliary channel to control roll (in AUX input or manual mode) Values:
  • 0: Disable
  • 1: AUX1
  • 2: AUX2
  • 3: AUX3
  • 4: AUX4
  • 5: AUX5
  • 6: AUX6
0 > 6 0
MNT_MAN_YAW (INT32) Auxiliary channel to control yaw (in AUX input or manual mode) Values:
  • 0: Disable
  • 1: AUX1
  • 2: AUX2
  • 3: AUX3
  • 4: AUX4
  • 5: AUX5
  • 6: AUX6
0 > 6 0
MNT_MAV_COMPID (INT32) Mavlink Component ID of the mount

Comment: If MNT_MODE_OUT is MAVLink protocol v2, mount configure/control commands will be sent with this component ID.

154
MNT_MAV_SYSID (INT32) Mavlink System ID of the mount

Comment: If MNT_MODE_OUT is MAVLink gimbal protocol v1, mount configure/control commands will be sent with this target ID.

1
MNT_MODE_IN (INT32) Mount input mode

Comment: RC uses the AUX input channels (see MNT_MAN_* parameters), MAVLINK_ROI uses the MAV_CMD_DO_SET_ROI Mavlink message, and MAVLINK_DO_MOUNT the MAV_CMD_DO_MOUNT_CONFIGURE and MAV_CMD_DO_MOUNT_CONTROL messages to control a mount.

Values:
  • -1: DISABLED
  • 0: AUTO
  • 1: RC
  • 2: MAVLINK_ROI (protocol v1)
  • 3: MAVLINK_DO_MOUNT (protocol v1)
  • 4: MAVlink gimbal protocol v2

Reboot required: true

-1 > 4 -1
MNT_MODE_OUT (INT32) Mount output mode

Comment: AUX uses the mixer output Control Group #2. MAVLINK uses the MAV_CMD_DO_MOUNT_CONFIGURE and MAV_CMD_DO_MOUNT_CONTROL MavLink messages to control a mount (set MNT_MAV_SYSID & MNT_MAV_COMPID)

Values:
  • 0: AUX
  • 1: MAVLink gimbal protocol v1
  • 2: MAVLink gimbal protocol v2
0 > 2 0
MNT_OB_LOCK_MODE (FLOAT) Mixer value for selecting a locking mode

Comment: if required for the gimbal (only in AUX output mode)

-1.0 > 1.0 0.0
MNT_OB_NORM_MODE (FLOAT) Mixer value for selecting normal mode

Comment: if required by the gimbal (only in AUX output mode)

-1.0 > 1.0 -1.0
MNT_OFF_PITCH (FLOAT) Offset for pitch channel output in degrees -360.0 > 360.0 0.0
MNT_OFF_ROLL (FLOAT) Offset for roll channel output in degrees -360.0 > 360.0 0.0
MNT_OFF_YAW (FLOAT) Offset for yaw channel output in degrees -360.0 > 360.0 0.0
MNT_RANGE_PITCH (FLOAT) Range of pitch channel output in degrees (only in AUX output mode) 1.0 > 720.0 360.0
MNT_RANGE_ROLL (FLOAT) Range of roll channel output in degrees (only in AUX output mode) 1.0 > 720.0 360.0
MNT_RANGE_YAW (FLOAT) Range of yaw channel output in degrees (only in AUX output mode) 1.0 > 720.0 360.0
MNT_RATE_PITCH (FLOAT) Angular pitch rate for manual input in degrees/second

Comment: Full stick input [-1..1] translats to [-pitch rate..pitch rate].

1.0 > 90.0 30.0
MNT_RATE_YAW (FLOAT) Angular yaw rate for manual input in degrees/second

Comment: Full stick input [-1..1] translats to [-yaw rate..yaw rate].

1.0 > 90.0 30.0

Multicopter Attitude Control

NameDescriptionMin > Max (Incr.)DefaultUnits
MC_PITCHRATE_MAX (FLOAT) Max pitch rate

Comment: Limit for pitch rate in manual and auto modes (except acro). Has effect for large rotations in autonomous mode, to avoid large control output and mixer saturation. This is not only limited by the vehicle's properties, but also by the maximum measurement rate of the gyro.

0.0 > 1800.0 (5) 220.0 deg/s
MC_PITCH_P (FLOAT) Pitch P gain

Comment: Pitch proportional gain, i.e. desired angular speed in rad/s for error 1 rad.

0.0 > 12 (0.1) 6.5
MC_ROLLRATE_MAX (FLOAT) Max roll rate

Comment: Limit for roll rate in manual and auto modes (except acro). Has effect for large rotations in autonomous mode, to avoid large control output and mixer saturation. This is not only limited by the vehicle's properties, but also by the maximum measurement rate of the gyro.

0.0 > 1800.0 (5) 220.0 deg/s
MC_ROLL_P (FLOAT) Roll P gain

Comment: Roll proportional gain, i.e. desired angular speed in rad/s for error 1 rad.

0.0 > 12 (0.1) 6.5
MC_YAWRATE_MAX (FLOAT) Max yaw rate 0.0 > 1800.0 (5) 200.0 deg/s
MC_YAW_P (FLOAT) Yaw P gain

Comment: Yaw proportional gain, i.e. desired angular speed in rad/s for error 1 rad.

0.0 > 5 (0.1) 2.8
MC_YAW_WEIGHT (FLOAT) Yaw weight

Comment: A fraction [0,1] deprioritizing yaw compared to roll and pitch in non-linear attitude control. Deprioritizing yaw is necessary because multicopters have much less control authority in yaw compared to the other axes and it makes sense because yaw is not critical for stable hovering or 3D navigation. For yaw control tuning use MC_YAW_P. This ratio has no inpact on the yaw gain.

0.0 > 1.0 (0.1) 0.4
MPC_YAWRAUTO_MAX (FLOAT) Max yaw rate in auto mode

Comment: Limit the rate of change of the yaw setpoint in autonomous mode to avoid large control output and mixer saturation.

0.0 > 360.0 (5) 45.0 deg/s

Multicopter Position Control

NameDescriptionMin > Max (Incr.)DefaultUnits
CP_DELAY (FLOAT) Average delay of the range sensor message plus the tracking delay of the position controller in seconds

Comment: Only used in Position mode.

0 > 1 0.4 s
CP_DIST (FLOAT) Minimum distance the vehicle should keep to all obstacles

Comment: Only used in Position mode. Collision avoidance is disabled by setting this parameter to a negative value

-1 > 15 -1.0 m
CP_GO_NO_DATA (INT32) Boolean to allow moving into directions where there is no sensor data (outside FOV)

Comment: Only used in Position mode.

Disabled (0)
CP_GUIDE_ANG (FLOAT) Angle left/right from the commanded setpoint by which the collision prevention algorithm can choose to change the setpoint direction

Comment: Only used in Position mode.

0 > 90 30. deg
MC_MAN_TILT_TAU (FLOAT) Manual tilt input filter time constant

Comment: Setting this parameter to 0 disables the filter

0.0 > 2.0 0.0 s
MPC_ACC_DOWN_MAX (FLOAT) Maximum vertical acceleration in velocity controlled modes down 2.0 > 15.0 (1) 3.0 m/s^2
MPC_ACC_HOR (FLOAT) Acceleration for auto and for manual

Comment: Note: In manual, this parameter is only used in MPC_POS_MODE 4.

2.0 > 15.0 (1) 3.0 m/s^2
MPC_ACC_HOR_MAX (FLOAT) Maximum horizontal acceleration for auto mode and for manual mode

Comment: MPC_POS_MODE 1 just deceleration 3 acceleration and deceleration 4 just acceleration

2.0 > 15.0 (1) 5.0 m/s^2
MPC_ACC_UP_MAX (FLOAT) Maximum vertical acceleration in velocity controlled modes upward 2.0 > 15.0 (1) 4.0 m/s^2
MPC_ALT_MODE (INT32) Altitude control mode

Comment: Set to 0 to control height relative to the earth frame origin. This origin may move up and down in flight due to sensor drift. Set to 1 to control height relative to estimated distance to ground. The vehicle will move up and down with terrain height variation. Requires a distance to ground sensor. The height controller will revert to using height above origin if the distance to ground estimate becomes invalid as indicated by the local_position.distance_bottom_valid message being false. Set to 2 to control height relative to ground (requires a distance sensor) when stationary and relative to earth frame origin when moving horizontally. The speed threshold is controlled by the MPC_HOLD_MAX_XY parameter.

Values:
  • 0: Altitude following
  • 1: Terrain following
  • 2: Terrain hold
0 > 2 0
MPC_HOLD_DZ (FLOAT) Deadzone of sticks where position hold is enabled 0.0 > 1.0 0.1
MPC_HOLD_MAX_XY (FLOAT) Maximum horizontal velocity for which position hold is enabled (use 0 to disable check) 0.0 > 3.0 0.8 m/s
MPC_HOLD_MAX_Z (FLOAT) Maximum vertical velocity for which position hold is enabled (use 0 to disable check) 0.0 > 3.0 0.6 m/s
MPC_JERK_AUTO (FLOAT) Jerk limit in auto mode

Comment: Limit the maximum jerk of the vehicle (how fast the acceleration can change). A lower value leads to smoother vehicle motions, but it also limits its agility.

1.0 > 80.0 (1) 4.0 m/s^3
MPC_JERK_MAX (FLOAT) Maximum jerk limit

Comment: Limit the maximum jerk of the vehicle (how fast the acceleration can change). A lower value leads to smoother vehicle motions, but it also limits its agility (how fast it can change directions or break). Setting this to the maximum value essentially disables the limit. Note: This is only used when MPC_POS_MODE is set to a smoothing mode 3 or 4.

0.5 > 500.0 (1) 8.0 m/s^3
MPC_LAND_ALT1 (FLOAT) Altitude for 1. step of slow landing (descend)

Comment: Below this altitude descending velocity gets limited to a value between "MPC_Z_VEL_MAX_DN" and "MPC_LAND_SPEED" Value needs to be higher than "MPC_LAND_ALT2"

0 > 122 10.0 m
MPC_LAND_ALT2 (FLOAT) Altitude for 2. step of slow landing (landing)

Comment: Below this altitude descending velocity gets limited to "MPC_LAND_SPEED". Value needs to be lower than "MPC_LAND_ALT1"

0 > 122 5.0 m
MPC_LAND_SPEED (FLOAT) Landing descend rate 0.6 > ? 0.7 m/s
MPC_MANTHR_MIN (FLOAT) Minimum manual thrust

Comment: Minimum vertical thrust. It's recommended to set it > 0 to avoid free fall with zero thrust. With MC_AIRMODE set to 1, this can safely be set to 0.

0.0 > 1.0 (0.01) 0.08 norm
MPC_MAN_TILT_MAX (FLOAT) Maximal tilt angle in manual or altitude mode 0.0 > 90.0 35.0 deg
MPC_MAN_Y_MAX (FLOAT) Max manual yaw rate 0.0 > 400 150.0 deg/s
MPC_MAN_Y_TAU (FLOAT) Manual yaw rate input filter time constant

Comment: Setting this parameter to 0 disables the filter

0.0 > 5.0 0.08 s
MPC_POS_MODE (INT32) Manual-Position control sub-mode

Comment: The supported sub-modes are: 0 Simple position control where sticks map directly to velocity setpoints without smoothing. Useful for velocity control tuning. 3 Smooth position control with maximum acceleration and jerk limits based on jerk optimized trajectory generator (different algorithm than 1). 4 Smooth position control where sticks map to acceleration and there's a virtual brake drag

Values:
  • 0: Simple position control
  • 3: Smooth position control (Jerk optimized)
  • 4: Acceleration based input
4
MPC_SPOOLUP_TIME (FLOAT) Enforced delay between arming and takeoff

Comment: For altitude controlled modes the time from arming the motors until a takeoff is possible gets forced to be at least MPC_SPOOLUP_TIME seconds to ensure the motors and propellers can sppol up and reach idle speed before getting commanded to spin faster. This delay is particularly useful for vehicles with slow motor spin-up e.g. because of large propellers.

0 > 10 1.0 s
MPC_THR_CURVE (INT32) Thrust curve in Manual Mode

Comment: This parameter defines how the throttle stick input is mapped to commanded thrust in Manual/Stabilized flight mode. In case the default is used ('Rescale to hover thrust'), the stick input is linearly rescaled, such that a centered stick corresponds to the hover throttle (see MPC_THR_HOVER). Select 'No Rescale' to directly map the stick 1:1 to the output. This can be useful in case the hover thrust is very low and the default would lead to too much distortion (e.g. if hover thrust is set to 20%, 80% of the upper thrust range is squeezed into the upper half of the stick range). Note: In case MPC_THR_HOVER is set to 50%, the modes 0 and 1 are the same.

Values:
  • 0: Rescale to hover thrust
  • 1: No Rescale
0
MPC_THR_HOVER (FLOAT) Hover thrust

Comment: Vertical thrust required to hover. This value is mapped to center stick for manual throttle control. With this value set to the thrust required to hover, transition from manual to Altitude or Position mode while hovering will occur with the throttle stick near center, which is then interpreted as (near) zero demand for vertical speed. This parameter is also important for the landing detection to work correctly.

0.1 > 0.8 (0.01) 0.5 norm
MPC_THR_MAX (FLOAT) Maximum thrust in auto thrust control

Comment: Limit max allowed thrust

0.0 > 1.0 (0.01) 1.0 norm
MPC_THR_MIN (FLOAT) Minimum collective thrust in auto thrust control

Comment: It's recommended to set it > 0 to avoid free fall with zero thrust. Note: Without airmode zero thrust leads to zero roll/pitch control authority. (see MC_AIRMODE)

0.05 > 1.0 (0.01) 0.12 norm
MPC_THR_XY_MARG (FLOAT) Horizontal thrust margin

Comment: Margin that is kept for horizontal control when prioritizing vertical thrust. To avoid completely starving horizontal control with high vertical error.

0.0 > 0.5 (0.01) 0.3 norm
MPC_TILTMAX_AIR (FLOAT) Maximum tilt angle in air

Comment: Limits maximum tilt in AUTO and POSCTRL modes during flight.

20.0 > 89.0 45.0 deg
MPC_TILTMAX_LND (FLOAT) Maximum tilt during landing

Comment: Limits maximum tilt angle on landing.

10.0 > 89.0 12.0 deg
MPC_TKO_RAMP_T (FLOAT) Position control smooth takeoff ramp time constant

Comment: Increasing this value will make automatic and manual takeoff slower. If it's too slow the drone might scratch the ground and tip over. A time constant of 0 disables the ramp

0 > 5 3.0
MPC_TKO_SPEED (FLOAT) Takeoff climb rate 1 > 5 1.5 m/s
MPC_USE_HTE (INT32) Hover thrust source selector

Comment: Set false to use the fixed parameter MPC_THR_HOVER Set true to use the value computed by the hover thrust estimator

Enabled (1)
MPC_VELD_LP (FLOAT) Low pass filter cut freq. for numerical velocity derivative 0.0 > 10 5.0 Hz
MPC_VEL_MANUAL (FLOAT) Maximum horizontal velocity setpoint for manual controlled mode

Comment: If velocity setpoint larger than MPC_XY_VEL_MAX is set, then the setpoint will be capped to MPC_XY_VEL_MAX

3.0 > 20.0 (1) 10.0 m/s
MPC_XY_CRUISE (FLOAT) Maximum horizontal velocity in mission

Comment: Horizontal velocity used when flying autonomously in e.g. Missions, RTL, Goto.

3.0 > 20.0 (1) 5.0 m/s
MPC_XY_ERR_MAX (FLOAT) Maximum horizontal error allowed by the trajectory generator

Comment: The integration speed of the trajectory setpoint is linearly reduced with the horizontal position tracking error. When the error is above this parameter, the integration of the trajectory is stopped to wait for the drone. This value can be adjusted depending on the tracking capabilities of the vehicle.

0.1 > 10.0 2.0
MPC_XY_MAN_EXPO (FLOAT) Manual position control stick exponential curve sensitivity

Comment: The higher the value the less sensitivity the stick has around zero while still reaching the maximum value with full stick deflection. 0 Purely linear input curve (default) 1 Purely cubic input curve

0 > 1 0.6
MPC_XY_P (FLOAT) Proportional gain for horizontal position error 0.0 > 2.0 0.95
MPC_XY_TRAJ_P (FLOAT) Proportional gain for horizontal trajectory position error 0.1 > 1.0 0.5
MPC_XY_VEL_ALL (FLOAT) Overall Horizonal Velocity Limit

Comment: If set to a value greater than zero, other parameters are automatically set (such as MPC_XY_VEL_MAX or MPC_VEL_MANUAL). If set to a negative value, the existing individual parameters are used.

-20 > 20 (1) -10.0
MPC_XY_VEL_D_ACC (FLOAT) Differential gain for horizontal velocity error. Small values help reduce fast oscillations. If value is too big oscillations will appear again

Comment: defined as correction acceleration in m/s^2 per m/s^2 velocity derivative

0.1 > 2.0 0.2
MPC_XY_VEL_I_ACC (FLOAT) Integral gain for horizontal velocity error

Comment: defined as correction acceleration in m/s^2 per m velocity integral Non-zero value allows to eliminate steady state errors in the presence of disturbances like wind.

0.0 > 60.0 0.4
MPC_XY_VEL_MAX (FLOAT) Maximum horizontal velocity

Comment: Maximum horizontal velocity in AUTO mode. If higher speeds are commanded in a mission they will be capped to this velocity.

0.0 > 20.0 (1) 12.0 m/s
MPC_XY_VEL_P_ACC (FLOAT) Proportional gain for horizontal velocity error

Comment: defined as correction acceleration in m/s^2 per m/s velocity error

1.2 > 5.0 1.8
MPC_YAW_EXPO (FLOAT) Manual control stick yaw rotation exponential curve

Comment: The higher the value the less sensitivity the stick has around zero while still reaching the maximum value with full stick deflection. 0 Purely linear input curve (default) 1 Purely cubic input curve

0 > 1 0.6
MPC_Z_MAN_EXPO (FLOAT) Manual control stick vertical exponential curve

Comment: The higher the value the less sensitivity the stick has around zero while still reaching the maximum value with full stick deflection. 0 Purely linear input curve (default) 1 Purely cubic input curve

0 > 1 0.6
MPC_Z_P (FLOAT) Proportional gain for vertical position error 0.0 > 1.5 1.0
MPC_Z_VEL_ALL (FLOAT) Overall Vertical Velocity Limit

Comment: If set to a value greater than zero, other parameters are automatically set (such as MPC_Z_VEL_MAX_UP or MPC_LAND_SPEED). If set to a negative value, the existing individual parameters are used.

-3 > 8 (0.5) -3.0
MPC_Z_VEL_D_ACC (FLOAT) Differential gain for vertical velocity error

Comment: defined as correction acceleration in m/s^2 per m/s^2 velocity derivative

0.0 > 2.0 0.0
MPC_Z_VEL_I_ACC (FLOAT) Integral gain for vertical velocity error

Comment: defined as correction acceleration in m/s^2 per m velocity integral Non zero value allows hovering thrust estimation on stabilized or autonomous takeoff.

0.2 > 3.0 2.0
MPC_Z_VEL_MAX_DN (FLOAT) Maximum vertical descent velocity

Comment: Maximum vertical velocity in AUTO mode and endpoint for stabilized modes (ALTCTRL, POSCTRL).

0.5 > 4.0 1.0 m/s
MPC_Z_VEL_MAX_UP (FLOAT) Maximum vertical ascent velocity

Comment: Maximum vertical velocity in AUTO mode and endpoint for stabilized modes (ALTCTRL, POSCTRL).

0.5 > 8.0 3.0 m/s
MPC_Z_VEL_P_ACC (FLOAT) Proportional gain for vertical velocity error

Comment: defined as correction acceleration in m/s^2 per m/s velocity error

2.0 > 15.0 4.0
SYS_VEHICLE_RESP (FLOAT) Responsiveness

Comment: Changes the overall responsiveness of the vehicle. The higher the value, the faster the vehicle will react. If set to a value greater than zero, other parameters are automatically set (such as the acceleration or jerk limits). If set to a negative value, the existing individual parameters are used.

-1 > 1 (0.05) -0.4
WV_EN (INT32) Enable weathervane Disabled (0)
WV_ROLL_MIN (FLOAT) Minimum roll angle setpoint for weathervane controller to demand a yaw-rate 0 > 5 1.0 deg
WV_YRATE_MAX (FLOAT) Maximum yawrate the weathervane controller is allowed to demand 0 > 120 90.0 deg/s

Multicopter Rate Control

NameDescriptionMin > Max (Incr.)DefaultUnits
MC_ACRO_EXPO (FLOAT) Acro mode Expo factor for Roll and Pitch

Comment: Exponential factor for tuning the input curve shape. 0 Purely linear input curve 1 Purely cubic input curve

0 > 1 0.69
MC_ACRO_EXPO_Y (FLOAT) Acro mode Expo factor for Yaw

Comment: Exponential factor for tuning the input curve shape. 0 Purely linear input curve 1 Purely cubic input curve

0 > 1 0.69
MC_ACRO_P_MAX (FLOAT) Max acro pitch rate

Comment: default: 2 turns per second

0.0 > 1800.0 (5) 720.0 deg/s
MC_ACRO_R_MAX (FLOAT) Max acro roll rate

Comment: default: 2 turns per second

0.0 > 1800.0 (5) 720.0 deg/s
MC_ACRO_SUPEXPO (FLOAT) Acro mode SuperExpo factor for Roll and Pitch

Comment: SuperExpo factor for refining the input curve shape tuned using MC_ACRO_EXPO. 0 Pure Expo function 0.7 resonable shape enhancement for intuitive stick feel 0.95 very strong bent input curve only near maxima have effect

0 > 0.95 0.7
MC_ACRO_SUPEXPOY (FLOAT) Acro mode SuperExpo factor for Yaw

Comment: SuperExpo factor for refining the input curve shape tuned using MC_ACRO_EXPO_Y. 0 Pure Expo function 0.7 resonable shape enhancement for intuitive stick feel 0.95 very strong bent input curve only near maxima have effect

0 > 0.95 0.7
MC_ACRO_Y_MAX (FLOAT) Max acro yaw rate

Comment: default 1.5 turns per second

0.0 > 1800.0 (5) 540.0 deg/s
MC_BAT_SCALE_EN (INT32) Battery power level scaler

Comment: This compensates for voltage drop of the battery over time by attempting to normalize performance across the operating range of the battery. The copter should constantly behave as if it was fully charged with reduced max acceleration at lower battery percentages. i.e. if hover is at 0.5 throttle at 100% battery, it will still be 0.5 at 60% battery.

Disabled (0)
MC_PITCHRATE_D (FLOAT) Pitch rate D gain

Comment: Pitch rate differential gain. Small values help reduce fast oscillations. If value is too big oscillations will appear again.

0.0 > ? (0.0005) 0.003
MC_PITCHRATE_FF (FLOAT) Pitch rate feedforward

Comment: Improves tracking performance.

0.0 > ? 0.0
MC_PITCHRATE_I (FLOAT) Pitch rate I gain

Comment: Pitch rate integral gain. Can be set to compensate static thrust difference or gravity center offset.

0.0 > ? (0.01) 0.2
MC_PITCHRATE_K (FLOAT) Pitch rate controller gain

Comment: Global gain of the controller. This gain scales the P, I and D terms of the controller: output = MC_PITCHRATE_K * (MC_PITCHRATE_P * error + MC_PITCHRATE_I * error_integral + MC_PITCHRATE_D * error_derivative) Set MC_PITCHRATE_P=1 to implement a PID in the ideal form. Set MC_PITCHRATE_K=1 to implement a PID in the parallel form.

0.01 > 5.0 (0.0005) 1.0
MC_PITCHRATE_P (FLOAT) Pitch rate P gain

Comment: Pitch rate proportional gain, i.e. control output for angular speed error 1 rad/s.

0.01 > 0.6 (0.01) 0.15
MC_PR_INT_LIM (FLOAT) Pitch rate integrator limit

Comment: Pitch rate integrator limit. Can be set to increase the amount of integrator available to counteract disturbances or reduced to improve settling time after large pitch moment trim changes.

0.0 > ? (0.01) 0.30
MC_ROLLRATE_D (FLOAT) Roll rate D gain

Comment: Roll rate differential gain. Small values help reduce fast oscillations. If value is too big oscillations will appear again.

0.0 > 0.01 (0.0005) 0.003
MC_ROLLRATE_FF (FLOAT) Roll rate feedforward

Comment: Improves tracking performance.

0.0 > ? 0.0
MC_ROLLRATE_I (FLOAT) Roll rate I gain

Comment: Roll rate integral gain. Can be set to compensate static thrust difference or gravity center offset.

0.0 > ? (0.01) 0.2
MC_ROLLRATE_K (FLOAT) Roll rate controller gain

Comment: Global gain of the controller. This gain scales the P, I and D terms of the controller: output = MC_ROLLRATE_K * (MC_ROLLRATE_P * error + MC_ROLLRATE_I * error_integral + MC_ROLLRATE_D * error_derivative) Set MC_ROLLRATE_P=1 to implement a PID in the ideal form. Set MC_ROLLRATE_K=1 to implement a PID in the parallel form.

0.01 > 5.0 (0.0005) 1.0
MC_ROLLRATE_P (FLOAT) Roll rate P gain

Comment: Roll rate proportional gain, i.e. control output for angular speed error 1 rad/s.

0.01 > 0.5 (0.01) 0.15
MC_RR_INT_LIM (FLOAT) Roll rate integrator limit

Comment: Roll rate integrator limit. Can be set to increase the amount of integrator available to counteract disturbances or reduced to improve settling time after large roll moment trim changes.

0.0 > ? (0.01) 0.30
MC_YAWRATE_D (FLOAT) Yaw rate D gain

Comment: Yaw rate differential gain. Small values help reduce fast oscillations. If value is too big oscillations will appear again.

0.0 > ? (0.01) 0.0
MC_YAWRATE_FF (FLOAT) Yaw rate feedforward

Comment: Improves tracking performance.

0.0 > ? (0.01) 0.0
MC_YAWRATE_I (FLOAT) Yaw rate I gain

Comment: Yaw rate integral gain. Can be set to compensate static thrust difference or gravity center offset.

0.0 > ? (0.01) 0.1
MC_YAWRATE_K (FLOAT) Yaw rate controller gain

Comment: Global gain of the controller. This gain scales the P, I and D terms of the controller: output = MC_YAWRATE_K * (MC_YAWRATE_P * error + MC_YAWRATE_I * error_integral + MC_YAWRATE_D * error_derivative) Set MC_YAWRATE_P=1 to implement a PID in the ideal form. Set MC_YAWRATE_K=1 to implement a PID in the parallel form.

0.0 > 5.0 (0.0005) 1.0
MC_YAWRATE_P (FLOAT) Yaw rate P gain

Comment: Yaw rate proportional gain, i.e. control output for angular speed error 1 rad/s.

0.0 > 0.6 (0.01) 0.2
MC_YR_INT_LIM (FLOAT) Yaw rate integrator limit

Comment: Yaw rate integrator limit. Can be set to increase the amount of integrator available to counteract disturbances or reduced to improve settling time after large yaw moment trim changes.

0.0 > ? (0.01) 0.30

OSD

NameDescriptionMin > Max (Incr.)DefaultUnits
OSD_ATXXXX_CFG (INT32) Enable/Disable the ATXXX OSD Chip

Comment: Configure the ATXXXX OSD Chip (mounted on the OmnibusF4SD board) and select the transmission standard.

Values:
  • 0: Disabled
  • 1: NTSC
  • 2: PAL

Reboot required: true

0

PWM Outputs

NameDescriptionMin > Max (Incr.)DefaultUnits
MOT_SLEW_MAX (FLOAT) Minimum motor rise time (slew rate limit)

Comment: Minimum time allowed for the motor input signal to pass through a range of 1000 PWM units. A value x means that the motor signal can only go from 1000 to 2000 PWM in maximum x seconds. Zero means that slew rate limiting is disabled.

0.0 > ? 0.0 s/(1000*PWM)
PWM_AUX_DIS1 (INT32) PWM aux 1 disarmed value

Comment: This is the PWM pulse the autopilot is outputting if not armed. When set to -1 the value for PWM_AUX_DISARM will be used

-1 > 2150 -1 us
PWM_AUX_DIS2 (INT32) PWM aux 2 disarmed value

Comment: This is the PWM pulse the autopilot is outputting if not armed. When set to -1 the value for PWM_AUX_DISARM will be used

-1 > 2150 -1 us
PWM_AUX_DIS3 (INT32) PWM aux 3 disarmed value

Comment: This is the PWM pulse the autopilot is outputting if not armed. When set to -1 the value for PWM_AUX_DISARM will be used

-1 > 2150 -1 us
PWM_AUX_DIS4 (INT32) PWM aux 4 disarmed value

Comment: This is the PWM pulse the autopilot is outputting if not armed. When set to -1 the value for PWM_AUX_DISARM will be used

-1 > 2150 -1 us
PWM_AUX_DIS5 (INT32) PWM aux 5 disarmed value

Comment: This is the PWM pulse the autopilot is outputting if not armed. When set to -1 the value for PWM_AUX_DISARM will be used

-1 > 2150 -1 us
PWM_AUX_DIS6 (INT32) PWM aux 6 disarmed value

Comment: This is the PWM pulse the autopilot is outputting if not armed. When set to -1 the value for PWM_AUX_DISARM will be used

-1 > 2150 -1 us
PWM_AUX_DIS7 (INT32) PWM aux 7 disarmed value

Comment: This is the PWM pulse the autopilot is outputting if not armed. When set to -1 the value for PWM_AUX_DISARM will be used

-1 > 2150 -1 us
PWM_AUX_DIS8 (INT32) PWM aux 8 disarmed value

Comment: This is the PWM pulse the autopilot is outputting if not armed. When set to -1 the value for PWM_AUX_DISARM will be used

-1 > 2150 -1 us
PWM_AUX_DISARM (INT32) PWM aux disarmed value

Comment: This is the PWM pulse the autopilot is outputting if not armed. The main use of this parameter is to silence ESCs when they are disarmed.

0 > 2200 1500 us
PWM_AUX_FAIL1 (INT32) PWM aux 1 failsafe value

Comment: This is the PWM pulse the autopilot is outputting if in failsafe mode. When set to -1 the value is set automatically depending if the actuator is a motor (900us) or a servo (1500us)

-1 > 2150 -1 us
PWM_AUX_FAIL2 (INT32) PWM aux 2 failsafe value

Comment: This is the PWM pulse the autopilot is outputting if in failsafe mode. When set to -1 the value is set automatically depending if the actuator is a motor (900us) or a servo (1500us)

-1 > 2150 -1 us
PWM_AUX_FAIL3 (INT32) PWM aux 3 failsafe value

Comment: This is the PWM pulse the autopilot is outputting if in failsafe mode. When set to -1 the value is set automatically depending if the actuator is a motor (900us) or a servo (1500us)

-1 > 2150 -1 us
PWM_AUX_FAIL4 (INT32) PWM aux 4 failsafe value

Comment: This is the PWM pulse the autopilot is outputting if in failsafe mode. When set to -1 the value is set automatically depending if the actuator is a motor (900us) or a servo (1500us)

-1 > 2150 -1 us
PWM_AUX_FAIL5 (INT32) PWM aux 5 failsafe value

Comment: This is the PWM pulse the autopilot is outputting if in failsafe mode. When set to -1 the value is set automatically depending if the actuator is a motor (900us) or a servo (1500us)

-1 > 2150 -1 us
PWM_AUX_FAIL6 (INT32) PWM aux 6 failsafe value

Comment: This is the PWM pulse the autopilot is outputting if in failsafe mode. When set to -1 the value is set automatically depending if the actuator is a motor (900us) or a servo (1500us)

-1 > 2150 -1 us
PWM_AUX_FAIL7 (INT32) PWM aux 7 failsafe value

Comment: This is the PWM pulse the autopilot is outputting if in failsafe mode. When set to -1 the value is set automatically depending if the actuator is a motor (900us) or a servo (1500us)

-1 > 2150 -1 us
PWM_AUX_FAIL8 (INT32) PWM aux 8 failsafe value

Comment: This is the PWM pulse the autopilot is outputting if in failsafe mode. When set to -1 the value is set automatically depending if the actuator is a motor (900us) or a servo (1500us)

-1 > 2150 -1 us
PWM_AUX_MAX (INT32) PWM aux maximum value

Comment: Set to 2000 for industry default or 2100 to increase servo travel.

1600 > 2200 2000 us
PWM_AUX_MAX1 (INT32) PWM aux 1 maximum value

Comment: This is the maximum PWM pulse the autopilot is allowed to output. When set to -1 the value for PWM_AUX_MAX will be used

-1 > 2150 -1 us
PWM_AUX_MAX2 (INT32) PWM aux 2 maximum value

Comment: This is the maximum PWM pulse the autopilot is allowed to output. When set to -1 the value for PWM_AUX_MAX will be used

-1 > 2150 -1 us
PWM_AUX_MAX3 (INT32) PWM aux 3 maximum value

Comment: This is the maximum PWM pulse the autopilot is allowed to output. When set to -1 the value for PWM_AUX_MAX will be used

-1 > 2150 -1 us
PWM_AUX_MAX4 (INT32) PWM aux 4 maximum value

Comment: This is the maximum PWM pulse the autopilot is allowed to output. When set to -1 the value for PWM_AUX_MAX will be used

-1 > 2150 -1 us
PWM_AUX_MAX5 (INT32) PWM aux 5 maximum value

Comment: This is the maximum PWM pulse the autopilot is allowed to output. When set to -1 the value for PWM_AUX_MAX will be used

-1 > 2150 -1 us
PWM_AUX_MAX6 (INT32) PWM aux 6 maximum value

Comment: This is the maximum PWM pulse the autopilot is allowed to output. When set to -1 the value for PWM_AUX_MAX will be used

-1 > 2150 -1 us
PWM_AUX_MAX7 (INT32) PWM aux 7 maximum value

Comment: This is the maximum PWM pulse the autopilot is allowed to output. When set to -1 the value for PWM_AUX_MAX will be used

-1 > 2150 -1 us
PWM_AUX_MAX8 (INT32) PWM aux 8 maximum value

Comment: This is the maximum PWM pulse the autopilot is allowed to output. When set to -1 the value for PWM_AUX_MAX will be used

-1 > 2150 -1 us
PWM_AUX_MIN (INT32) PWM aux minimum value

Comment: Set to 1000 for industry default or 900 to increase servo travel.

800 > 1400 1000 us
PWM_AUX_MIN1 (INT32) PWM aux 1 minimum value

Comment: This is the minimum PWM pulse the autopilot is allowed to output. When set to -1 the value for PWM_AUX_MIN will be used

-1 > 1600 -1 us
PWM_AUX_MIN2 (INT32) PWM aux 2 minimum value

Comment: This is the minimum PWM pulse the autopilot is allowed to output. When set to -1 the value for PWM_AUX_MIN will be used

-1 > 1600 -1 us
PWM_AUX_MIN3 (INT32) PWM aux 3 minimum value

Comment: This is the minimum PWM pulse the autopilot is allowed to output. When set to -1 the value for PWM_AUX_MIN will be used

-1 > 1600 -1 us
PWM_AUX_MIN4 (INT32) PWM aux 4 minimum value

Comment: This is the minimum PWM pulse the autopilot is allowed to output. When set to -1 the value for PWM_AUX_MIN will be used

-1 > 1600 -1 us
PWM_AUX_MIN5 (INT32) PWM aux 5 minimum value

Comment: This is the minimum PWM pulse the autopilot is allowed to output. When set to -1 the value for PWM_AUX_MIN will be used

-1 > 1600 -1 us
PWM_AUX_MIN6 (INT32) PWM aux 6 minimum value

Comment: This is the minimum PWM pulse the autopilot is allowed to output. When set to -1 the value for PWM_AUX_MIN will be used

-1 > 1600 -1 us
PWM_AUX_MIN7 (INT32) PWM aux 7 minimum value

Comment: This is the minimum PWM pulse the autopilot is allowed to output. When set to -1 the value for PWM_AUX_MIN will be used

-1 > 1600 -1 us
PWM_AUX_MIN8 (INT32) PWM aux 8 minimum value

Comment: This is the minimum PWM pulse the autopilot is allowed to output. When set to -1 the value for PWM_AUX_MIN will be used

-1 > 1600 -1 us
PWM_AUX_OUT (INT32) PWM channels used as ESC outputs

Comment: Number representing the channels e.g. 134 - Channel 1, 3 and 4. Global e.g. PWM_AUX_MIN/MAX/DISARM limits only apply to these channels.

0 > 123456789 0
PWM_AUX_RATE (INT32) PWM aux output frequency

Comment: Set to 400 for industry default or 1000 for high frequency ESCs. Set to 0 for Oneshot125.

-1 > 2000 50 Hz
PWM_AUX_RATE1 (INT32) PWM aux 1 rate

Comment: Set the default PWM output frequency for the aux outputs

0 > 400 50 Hz
PWM_AUX_REV1 (INT32) PWM aux 1 reverse value

Comment: Enable to invert the channel. Warning: Use this parameter when connected to a servo only. For a brushless motor, invert manually two phases to reverse the direction.

Disabled (0)
PWM_AUX_REV2 (INT32) PWM aux 2 reverse value

Comment: Enable to invert the channel. Warning: Use this parameter when connected to a servo only. For a brushless motor, invert manually two phases to reverse the direction.

Disabled (0)
PWM_AUX_REV3 (INT32) PWM aux 3 reverse value

Comment: Enable to invert the channel. Warning: Use this parameter when connected to a servo only. For a brushless motor, invert manually two phases to reverse the direction.

Disabled (0)
PWM_AUX_REV4 (INT32) PWM aux 4 reverse value

Comment: Enable to invert the channel. Warning: Use this parameter when connected to a servo only. For a brushless motor, invert manually two phases to reverse the direction.

Disabled (0)
PWM_AUX_REV5 (INT32) PWM aux 5 reverse value

Comment: Enable to invert the channel. Warning: Use this parameter when connected to a servo only. For a brushless motor, invert manually two phases to reverse the direction.

Disabled (0)
PWM_AUX_REV6 (INT32) PWM aux 6 reverse value

Comment: Enable to invert the channel. Warning: Use this parameter when connected to a servo only. For a brushless motor, invert manually two phases to reverse the direction.

Disabled (0)
PWM_AUX_REV7 (INT32) PWM aux 7 reverse value

Comment: Enable to invert the channel. Warning: Use this parameter when connected to a servo only. For a brushless motor, invert manually two phases to reverse the direction.

Disabled (0)
PWM_AUX_REV8 (INT32) PWM aux 8 reverse value

Comment: Enable to invert the channel. Warning: Use this parameter when connected to a servo only. For a brushless motor, invert manually two phases to reverse the direction.

Disabled (0)
PWM_AUX_TRIM1 (FLOAT) PWM aux 1 trim value

Comment: Set to normalized offset

-0.2 > 0.2 0
PWM_AUX_TRIM2 (FLOAT) PWM aux 2 trim value

Comment: Set to normalized offset

-0.2 > 0.2 0
PWM_AUX_TRIM3 (FLOAT) PWM aux 3 trim value

Comment: Set to normalized offset

-0.2 > 0.2 0
PWM_AUX_TRIM4 (FLOAT) PWM aux 4 trim value

Comment: Set to normalized offset

-0.2 > 0.2 0
PWM_AUX_TRIM5 (FLOAT) PWM aux 5 trim value

Comment: Set to normalized offset

-0.2 > 0.2 0
PWM_AUX_TRIM6 (FLOAT) PWM aux 6 trim value

Comment: Set to normalized offset

-0.2 > 0.2 0
PWM_AUX_TRIM7 (FLOAT) PWM aux 7 trim value

Comment: Set to normalized offset

-0.2 > 0.2 0
PWM_AUX_TRIM8 (FLOAT) PWM aux 8 trim value

Comment: Set to normalized offset

-0.2 > 0.2 0
PWM_EXTRA_DIS1 (INT32) PWM extra 1 disarmed value

Comment: This is the PWM pulse the autopilot is outputting if not armed. When set to -1 the value for PWM_EXTRA_DISARM will be used

-1 > 2150 -1 us
PWM_EXTRA_DIS2 (INT32) PWM extra 2 disarmed value

Comment: This is the PWM pulse the autopilot is outputting if not armed. When set to -1 the value for PWM_EXTRA_DISARM will be used

-1 > 2150 -1 us
PWM_EXTRA_DIS3 (INT32) PWM extra 3 disarmed value

Comment: This is the PWM pulse the autopilot is outputting if not armed. When set to -1 the value for PWM_EXTRA_DISARM will be used

-1 > 2150 -1 us
PWM_EXTRA_DIS4 (INT32) PWM extra 4 disarmed value

Comment: This is the PWM pulse the autopilot is outputting if not armed. When set to -1 the value for PWM_EXTRA_DISARM will be used

-1 > 2150 -1 us
PWM_EXTRA_DIS5 (INT32) PWM extra 5 disarmed value

Comment: This is the PWM pulse the autopilot is outputting if not armed. When set to -1 the value for PWM_EXTRA_DISARM will be used

-1 > 2150 -1 us
PWM_EXTRA_DIS6 (INT32) PWM extra 6 disarmed value

Comment: This is the PWM pulse the autopilot is outputting if not armed. When set to -1 the value for PWM_EXTRA_DISARM will be used

-1 > 2150 -1 us
PWM_EXTRA_DIS7 (INT32) PWM extra 7 disarmed value

Comment: This is the PWM pulse the autopilot is outputting if not armed. When set to -1 the value for PWM_EXTRA_DISARM will be used

-1 > 2150 -1 us
PWM_EXTRA_DIS8 (INT32) PWM extra 8 disarmed value

Comment: This is the PWM pulse the autopilot is outputting if not armed. When set to -1 the value for PWM_EXTRA_DISARM will be used

-1 > 2150 -1 us
PWM_EXTRA_DISARM (INT32) PWM extra disarmed value

Comment: This is the PWM pulse the autopilot is outputting if not armed. The main use of this parameter is to silence ESCs when they are disarmed.

0 > 2200 1500 us
PWM_EXTRA_FAIL1 (INT32) PWM extra 1 failsafe value

Comment: This is the PWM pulse the autopilot is outputting if in failsafe mode. When set to -1 the value is set automatically depending if the actuator is a motor (900us) or a servo (1500us)

0 > 2150 0 us
PWM_EXTRA_FAIL2 (INT32) PWM extra 2 failsafe value

Comment: This is the PWM pulse the autopilot is outputting if in failsafe mode. When set to -1 the value is set automatically depending if the actuator is a motor (900us) or a servo (1500us)

0 > 2150 0 us
PWM_EXTRA_FAIL3 (INT32) PWM extra 3 failsafe value

Comment: This is the PWM pulse the autopilot is outputting if in failsafe mode. When set to -1 the value is set automatically depending if the actuator is a motor (900us) or a servo (1500us)

0 > 2150 0 us
PWM_EXTRA_FAIL4 (INT32) PWM extra 4 failsafe value

Comment: This is the PWM pulse the autopilot is outputting if in failsafe mode. When set to -1 the value is set automatically depending if the actuator is a motor (900us) or a servo (1500us)

0 > 2150 0 us
PWM_EXTRA_FAIL5 (INT32) PWM extra 5 failsafe value

Comment: This is the PWM pulse the autopilot is outputting if in failsafe mode. When set to -1 the value is set automatically depending if the actuator is a motor (900us) or a servo (1500us)

0 > 2150 0 us
PWM_EXTRA_FAIL6 (INT32) PWM extra 6 failsafe value

Comment: This is the PWM pulse the autopilot is outputting if in failsafe mode. When set to -1 the value is set automatically depending if the actuator is a motor (900us) or a servo (1500us)

0 > 2150 0 us
PWM_EXTRA_FAIL7 (INT32) PWM extra 7 failsafe value

Comment: This is the PWM pulse the autopilot is outputting if in failsafe mode. When set to -1 the value is set automatically depending if the actuator is a motor (900us) or a servo (1500us)

0 > 2150 0 us
PWM_EXTRA_FAIL8 (INT32) PWM extra 8 failsafe value

Comment: This is the PWM pulse the autopilot is outputting if in failsafe mode. When set to -1 the value is set automatically depending if the actuator is a motor (900us) or a servo (1500us)

0 > 2150 0 us
PWM_EXTRA_MAX (INT32) PWM extra maximum value

Comment: Set to 2000 for industry default or 2100 to increase servo travel.

1600 > 2200 2000 us
PWM_EXTRA_MAX1 (INT32) PWM extra 1 maximum value

Comment: This is the maximum PWM pulse the autopilot is allowed to output. When set to -1 the value for PWM_EXTRA_MAX will be used

-1 > 2150 -1 us
PWM_EXTRA_MAX2 (INT32) PWM extra 2 maximum value

Comment: This is the maximum PWM pulse the autopilot is allowed to output. When set to -1 the value for PWM_EXTRA_MAX will be used

-1 > 2150 -1 us
PWM_EXTRA_MAX3 (INT32) PWM extra 3 maximum value

Comment: This is the maximum PWM pulse the autopilot is allowed to output. When set to -1 the value for PWM_EXTRA_MAX will be used

-1 > 2150 -1 us
PWM_EXTRA_MAX4 (INT32) PWM extra 4 maximum value

Comment: This is the maximum PWM pulse the autopilot is allowed to output. When set to -1 the value for PWM_EXTRA_MAX will be used

-1 > 2150 -1 us
PWM_EXTRA_MAX5 (INT32) PWM extra 5 maximum value

Comment: This is the maximum PWM pulse the autopilot is allowed to output. When set to -1 the value for PWM_EXTRA_MAX will be used

-1 > 2150 -1 us
PWM_EXTRA_MAX6 (INT32) PWM extra 6 maximum value

Comment: This is the maximum PWM pulse the autopilot is allowed to output. When set to -1 the value for PWM_EXTRA_MAX will be used

-1 > 2150 -1 us
PWM_EXTRA_MAX7 (INT32) PWM extra 7 maximum value

Comment: This is the maximum PWM pulse the autopilot is allowed to output. When set to -1 the value for PWM_EXTRA_MAX will be used

-1 > 2150 -1 us
PWM_EXTRA_MAX8 (INT32) PWM extra 8 maximum value

Comment: This is the maximum PWM pulse the autopilot is allowed to output. When set to -1 the value for PWM_EXTRA_MAX will be used

-1 > 2150 -1 us
PWM_EXTRA_MIN (INT32) PWM extra minimum value

Comment: Set to 1000 for industry default or 900 to increase servo travel.

800 > 1400 1000 us
PWM_EXTRA_MIN1 (INT32) PWM extra 1 minimum value

Comment: This is the minimum PWM pulse the autopilot is allowed to output. When set to -1 the value for PWM_EXTRA_MIN will be used

-1 > 1600 -1 us
PWM_EXTRA_MIN2 (INT32) PWM extra 2 minimum value

Comment: This is the minimum PWM pulse the autopilot is allowed to output. When set to -1 the value for PWM_EXTRA_MIN will be used

-1 > 1600 -1 us
PWM_EXTRA_MIN3 (INT32) PWM extra 3 minimum value

Comment: This is the minimum PWM pulse the autopilot is allowed to output. When set to -1 the value for PWM_EXTRA_MIN will be used

-1 > 1600 -1 us
PWM_EXTRA_MIN4 (INT32) PWM extra 4 minimum value

Comment: This is the minimum PWM pulse the autopilot is allowed to output. When set to -1 the value for PWM_EXTRA_MIN will be used

-1 > 1600 -1 us
PWM_EXTRA_MIN5 (INT32) PWM extra 5 minimum value

Comment: This is the minimum PWM pulse the autopilot is allowed to output. When set to -1 the value for PWM_EXTRA_MIN will be used

-1 > 1600 -1 us
PWM_EXTRA_MIN6 (INT32) PWM extra 6 minimum value

Comment: This is the minimum PWM pulse the autopilot is allowed to output. When set to -1 the value for PWM_EXTRA_MIN will be used

-1 > 1600 -1 us
PWM_EXTRA_MIN7 (INT32) PWM extra 7 minimum value

Comment: This is the minimum PWM pulse the autopilot is allowed to output. When set to -1 the value for PWM_EXTRA_MIN will be used

-1 > 1600 -1 us
PWM_EXTRA_MIN8 (INT32) PWM extra 8 minimum value

Comment: This is the minimum PWM pulse the autopilot is allowed to output. When set to -1 the value for PWM_EXTRA_MIN will be used

-1 > 1600 -1 us
PWM_EXTRA_RATE (INT32) PWM extra output frequency

Comment: Set to 400 for industry default or 1000 for high frequency ESCs. Set to 0 for Oneshot125.

-1 > 2000 50 Hz
PWM_EXTRA_RATE1 (INT32) PWM extra 1 rate

Comment: Set the default PWM output frequency for the main outputs

0 > 400 50 Hz
PWM_EXTRA_REV1 (INT32) PWM extra 1 reverse value

Comment: Enable to invert the channel. Warning: Use this parameter when connected to a servo only. For a brushless motor, invert manually two phases to reverse the direction.

Disabled (0)
PWM_EXTRA_REV2 (INT32) PWM extra 2 reverse value

Comment: Enable to invert the channel. Warning: Use this parameter when connected to a servo only. For a brushless motor, invert manually two phases to reverse the direction.

Disabled (0)
PWM_EXTRA_REV3 (INT32) PWM extra 3 reverse value

Comment: Enable to invert the channel. Warning: Use this parameter when connected to a servo only. For a brushless motor, invert manually two phases to reverse the direction.

Disabled (0)
PWM_EXTRA_REV4 (INT32) PWM extra 4 reverse value

Comment: Enable to invert the channel. Warning: Use this parameter when connected to a servo only. For a brushless motor, invert manually two phases to reverse the direction.

Disabled (0)
PWM_EXTRA_REV5 (INT32) PWM extra 5 reverse value

Comment: Enable to invert the channel. Warning: Use this parameter when connected to a servo only. For a brushless motor, invert manually two phases to reverse the direction.

Disabled (0)
PWM_EXTRA_REV6 (INT32) PWM extra 6 reverse value

Comment: Enable to invert the channel. Warning: Use this parameter when connected to a servo only. For a brushless motor, invert manually two phases to reverse the direction.

Disabled (0)
PWM_EXTRA_REV7 (INT32) PWM extra 7 reverse value

Comment: Enable to invert the channel. Warning: Use this parameter when connected to a servo only. For a brushless motor, invert manually two phases to reverse the direction.

Disabled (0)
PWM_EXTRA_REV8 (INT32) PWM extra 8 reverse value

Comment: Enable to invert the channel. Warning: Use this parameter when connected to a servo only. For a brushless motor, invert manually two phases to reverse the direction.

Disabled (0)
PWM_EXTRA_TRIM1 (FLOAT) PWM extra 1 trim value

Comment: Set to normalized offset

-0.2 > 0.2 0
PWM_EXTRA_TRIM2 (FLOAT) PWM extra 2 trim value

Comment: Set to normalized offset

-0.2 > 0.2 0
PWM_EXTRA_TRIM3 (FLOAT) PWM extra 3 trim value

Comment: Set to normalized offset

-0.2 > 0.2 0
PWM_EXTRA_TRIM4 (FLOAT) PWM extra 4 trim value

Comment: Set to normalized offset

-0.2 > 0.2 0
PWM_EXTRA_TRIM5 (FLOAT) PWM extra 5 trim value

Comment: Set to normalized offset

-0.2 > 0.2 0
PWM_EXTRA_TRIM6 (FLOAT) PWM extra 6 trim value

Comment: Set to normalized offset

-0.2 > 0.2 0
PWM_EXTRA_TRIM7 (FLOAT) PWM extra 7 trim value

Comment: Set to normalized offset

-0.2 > 0.2 0
PWM_EXTRA_TRIM8 (FLOAT) PWM extra 8 trim value

Comment: Set to normalized offset

-0.2 > 0.2 0
PWM_MAIN_DIS1 (INT32) PWM main 1 disarmed value

Comment: This is the PWM pulse the autopilot is outputting if not armed. When set to -1 the value for PWM_MAIN_DISARM will be used

-1 > 2150 -1 us
PWM_MAIN_DIS10 (INT32) PWM main 10 disarmed value

Comment: This is the PWM pulse the autopilot is outputting if not armed. When set to -1 the value for PWM_MAIN_DISARM will be used

-1 > 2150 -1 us
PWM_MAIN_DIS11 (INT32) PWM main 11 disarmed value

Comment: This is the PWM pulse the autopilot is outputting if not armed. When set to -1 the value for PWM_MAIN_DISARM will be used

-1 > 2150 -1 us
PWM_MAIN_DIS12 (INT32) PWM main 12 disarmed value

Comment: This is the PWM pulse the autopilot is outputting if not armed. When set to -1 the value for PWM_MAIN_DISARM will be used

-1 > 2150 -1 us
PWM_MAIN_DIS13 (INT32) PWM main 13 disarmed value

Comment: This is the PWM pulse the autopilot is outputting if not armed. When set to -1 the value for PWM_MAIN_DISARM will be used

-1 > 2150 -1 us
PWM_MAIN_DIS14 (INT32) PWM main 14 disarmed value

Comment: This is the PWM pulse the autopilot is outputting if not armed. When set to -1 the value for PWM_MAIN_DISARM will be used

-1 > 2150 -1 us
PWM_MAIN_DIS2 (INT32) PWM main 2 disarmed value

Comment: This is the PWM pulse the autopilot is outputting if not armed. When set to -1 the value for PWM_MAIN_DISARM will be used

-1 > 2150 -1 us
PWM_MAIN_DIS3 (INT32) PWM main 3 disarmed value

Comment: This is the PWM pulse the autopilot is outputting if not armed. When set to -1 the value for PWM_MAIN_DISARM will be used

-1 > 2150 -1 us
PWM_MAIN_DIS4 (INT32) PWM main 4 disarmed value

Comment: This is the PWM pulse the autopilot is outputting if not armed. When set to -1 the value for PWM_MAIN_DISARM will be used

-1 > 2150 -1 us
PWM_MAIN_DIS5 (INT32) PWM main 5 disarmed value

Comment: This is the PWM pulse the autopilot is outputting if not armed. When set to -1 the value for PWM_MAIN_DISARM will be used

-1 > 2150 -1 us
PWM_MAIN_DIS6 (INT32) PWM main 6 disarmed value

Comment: This is the PWM pulse the autopilot is outputting if not armed. When set to -1 the value for PWM_MAIN_DISARM will be used

-1 > 2150 -1 us
PWM_MAIN_DIS7 (INT32) PWM main 7 disarmed value

Comment: This is the PWM pulse the autopilot is outputting if not armed. When set to -1 the value for PWM_MAIN_DISARM will be used

-1 > 2150 -1 us
PWM_MAIN_DIS8 (INT32) PWM main 8 disarmed value

Comment: This is the PWM pulse the autopilot is outputting if not armed. When set to -1 the value for PWM_MAIN_DISARM will be used

-1 > 2150 -1 us
PWM_MAIN_DIS9 (INT32) PWM main 9 disarmed value

Comment: This is the PWM pulse the autopilot is outputting if not armed. When set to -1 the value for PWM_MAIN_DISARM will be used

-1 > 2150 -1 us
PWM_MAIN_DISARM (INT32) PWM main disarmed value

Comment: This is the PWM pulse the autopilot is outputting if not armed. The main use of this parameter is to silence ESCs when they are disarmed.

0 > 2200 900 us
PWM_MAIN_FAIL1 (INT32) PWM main 1 failsafe value

Comment: This is the PWM pulse the autopilot is outputting if in failsafe mode. When set to -1 the value is set automatically depending if the actuator is a motor (900us) or a servo (1500us)

-1 > 2150 -1 us
PWM_MAIN_FAIL10 (INT32) PWM main 10 failsafe value

Comment: This is the PWM pulse the autopilot is outputting if in failsafe mode. When set to -1 the value is set automatically depending if the actuator is a motor (900us) or a servo (1500us)

-1 > 2150 -1 us
PWM_MAIN_FAIL11 (INT32) PWM main 11 failsafe value

Comment: This is the PWM pulse the autopilot is outputting if in failsafe mode. When set to -1 the value is set automatically depending if the actuator is a motor (900us) or a servo (1500us)

-1 > 2150 -1 us
PWM_MAIN_FAIL12 (INT32) PWM main 12 failsafe value

Comment: This is the PWM pulse the autopilot is outputting if in failsafe mode. When set to -1 the value is set automatically depending if the actuator is a motor (900us) or a servo (1500us)

-1 > 2150 -1 us
PWM_MAIN_FAIL13 (INT32) PWM main 13 failsafe value

Comment: This is the PWM pulse the autopilot is outputting if in failsafe mode. When set to -1 the value is set automatically depending if the actuator is a motor (900us) or a servo (1500us)

-1 > 2150 -1 us
PWM_MAIN_FAIL14 (INT32) PWM main 14 failsafe value

Comment: This is the PWM pulse the autopilot is outputting if in failsafe mode. When set to -1 the value is set automatically depending if the actuator is a motor (900us) or a servo (1500us)

-1 > 2150 -1 us
PWM_MAIN_FAIL2 (INT32) PWM main 2 failsafe value

Comment: This is the PWM pulse the autopilot is outputting if in failsafe mode. When set to -1 the value is set automatically depending if the actuator is a motor (900us) or a servo (1500us)

-1 > 2150 -1 us
PWM_MAIN_FAIL3 (INT32) PWM main 3 failsafe value

Comment: This is the PWM pulse the autopilot is outputting if in failsafe mode. When set to -1 the value is set automatically depending if the actuator is a motor (900us) or a servo (1500us)

-1 > 2150 -1 us
PWM_MAIN_FAIL4 (INT32) PWM main 4 failsafe value

Comment: This is the PWM pulse the autopilot is outputting if in failsafe mode. When set to -1 the value is set automatically depending if the actuator is a motor (900us) or a servo (1500us)

-1 > 2150 -1 us
PWM_MAIN_FAIL5 (INT32) PWM main 5 failsafe value

Comment: This is the PWM pulse the autopilot is outputting if in failsafe mode. When set to -1 the value is set automatically depending if the actuator is a motor (900us) or a servo (1500us)

-1 > 2150 -1 us
PWM_MAIN_FAIL6 (INT32) PWM main 6 failsafe value

Comment: This is the PWM pulse the autopilot is outputting if in failsafe mode. When set to -1 the value is set automatically depending if the actuator is a motor (900us) or a servo (1500us)

-1 > 2150 -1 us
PWM_MAIN_FAIL7 (INT32) PWM main 7 failsafe value

Comment: This is the PWM pulse the autopilot is outputting if in failsafe mode. When set to -1 the value is set automatically depending if the actuator is a motor (900us) or a servo (1500us)

-1 > 2150 -1 us
PWM_MAIN_FAIL8 (INT32) PWM main 8 failsafe value

Comment: This is the PWM pulse the autopilot is outputting if in failsafe mode. When set to -1 the value is set automatically depending if the actuator is a motor (900us) or a servo (1500us)

-1 > 2150 -1 us
PWM_MAIN_FAIL9 (INT32) PWM main 9 failsafe value

Comment: This is the PWM pulse the autopilot is outputting if in failsafe mode. When set to -1 the value is set automatically depending if the actuator is a motor (900us) or a servo (1500us)

-1 > 2150 -1 us
PWM_MAIN_MAX (INT32) PWM main maximum value

Comment: Set to 2000 for industry default or 2100 to increase servo travel.

1600 > 2200 2000 us
PWM_MAIN_MAX1 (INT32) PWM main 1 maximum value

Comment: This is the maximum PWM pulse the autopilot is allowed to output. When set to -1 the value for PWM_MAIN_MAX will be used

-1 > 2150 -1 us
PWM_MAIN_MAX10 (INT32) PWM main 10 maximum value

Comment: This is the maximum PWM pulse the autopilot is allowed to output. When set to -1 the value for PWM_MAIN_MAX will be used

-1 > 2150 -1 us
PWM_MAIN_MAX11 (INT32) PWM main 11 maximum value

Comment: This is the maximum PWM pulse the autopilot is allowed to output. When set to -1 the value for PWM_MAIN_MAX will be used

-1 > 2150 -1 us
PWM_MAIN_MAX12 (INT32) PWM main 12 maximum value

Comment: This is the maximum PWM pulse the autopilot is allowed to output. When set to -1 the value for PWM_MAIN_MAX will be used

-1 > 2150 -1 us
PWM_MAIN_MAX13 (INT32) PWM main 13 maximum value

Comment: This is the maximum PWM pulse the autopilot is allowed to output. When set to -1 the value for PWM_MAIN_MAX will be used

-1 > 2150 -1 us
PWM_MAIN_MAX14 (INT32) PWM main 14 maximum value

Comment: This is the maximum PWM pulse the autopilot is allowed to output. When set to -1 the value for PWM_MAIN_MAX will be used

-1 > 2150 -1 us
PWM_MAIN_MAX2 (INT32) PWM main 2 maximum value

Comment: This is the maximum PWM pulse the autopilot is allowed to output. When set to -1 the value for PWM_MAIN_MAX will be used

-1 > 2150 -1 us
PWM_MAIN_MAX3 (INT32) PWM main 3 maximum value

Comment: This is the maximum PWM pulse the autopilot is allowed to output. When set to -1 the value for PWM_MAIN_MAX will be used

-1 > 2150 -1 us
PWM_MAIN_MAX4 (INT32) PWM main 4 maximum value

Comment: This is the maximum PWM pulse the autopilot is allowed to output. When set to -1 the value for PWM_MAIN_MAX will be used

-1 > 2150 -1 us
PWM_MAIN_MAX5 (INT32) PWM main 5 maximum value

Comment: This is the maximum PWM pulse the autopilot is allowed to output. When set to -1 the value for PWM_MAIN_MAX will be used

-1 > 2150 -1 us
PWM_MAIN_MAX6 (INT32) PWM main 6 maximum value

Comment: This is the maximum PWM pulse the autopilot is allowed to output. When set to -1 the value for PWM_MAIN_MAX will be used

-1 > 2150 -1 us
PWM_MAIN_MAX7 (INT32) PWM main 7 maximum value

Comment: This is the maximum PWM pulse the autopilot is allowed to output. When set to -1 the value for PWM_MAIN_MAX will be used

-1 > 2150 -1 us
PWM_MAIN_MAX8 (INT32) PWM main 8 maximum value

Comment: This is the maximum PWM pulse the autopilot is allowed to output. When set to -1 the value for PWM_MAIN_MAX will be used

-1 > 2150 -1 us
PWM_MAIN_MAX9 (INT32) PWM main 9 maximum value

Comment: This is the maximum PWM pulse the autopilot is allowed to output. When set to -1 the value for PWM_MAIN_MAX will be used

-1 > 2150 -1 us
PWM_MAIN_MIN (INT32) PWM main minimum value

Comment: Set to 1000 for industry default or 900 to increase servo travel.

800 > 1400 1000 us
PWM_MAIN_MIN1 (INT32) PWM main 1 minimum value

Comment: This is the minimum PWM pulse the autopilot is allowed to output. When set to -1 the value for PWM_MAIN_MIN will be used

-1 > 1600 -1 us
PWM_MAIN_MIN10 (INT32) PWM main 10 minimum value

Comment: This is the minimum PWM pulse the autopilot is allowed to output. When set to -1 the value for PWM_MAIN_MIN will be used

-1 > 1600 -1 us
PWM_MAIN_MIN11 (INT32) PWM main 11 minimum value

Comment: This is the minimum PWM pulse the autopilot is allowed to output. When set to -1 the value for PWM_MAIN_MIN will be used

-1 > 1600 -1 us
PWM_MAIN_MIN12 (INT32) PWM main 12 minimum value

Comment: This is the minimum PWM pulse the autopilot is allowed to output. When set to -1 the value for PWM_MAIN_MIN will be used

-1 > 1600 -1 us
PWM_MAIN_MIN13 (INT32) PWM main 13 minimum value

Comment: This is the minimum PWM pulse the autopilot is allowed to output. When set to -1 the value for PWM_MAIN_MIN will be used

-1 > 1600 -1 us
PWM_MAIN_MIN14 (INT32) PWM main 14 minimum value

Comment: This is the minimum PWM pulse the autopilot is allowed to output. When set to -1 the value for PWM_MAIN_MIN will be used

-1 > 1600 -1 us
PWM_MAIN_MIN2 (INT32) PWM main 2 minimum value

Comment: This is the minimum PWM pulse the autopilot is allowed to output. When set to -1 the value for PWM_MAIN_MIN will be used

-1 > 1600 -1 us
PWM_MAIN_MIN3 (INT32) PWM main 3 minimum value

Comment: This is the minimum PWM pulse the autopilot is allowed to output. When set to -1 the value for PWM_MAIN_MIN will be used

-1 > 1600 -1 us
PWM_MAIN_MIN4 (INT32) PWM main 4 minimum value

Comment: This is the minimum PWM pulse the autopilot is allowed to output. When set to -1 the value for PWM_MAIN_MIN will be used

-1 > 1600 -1 us
PWM_MAIN_MIN5 (INT32) PWM main 5 minimum value

Comment: This is the minimum PWM pulse the autopilot is allowed to output. When set to -1 the value for PWM_MAIN_MIN will be used

-1 > 1600 -1 us
PWM_MAIN_MIN6 (INT32) PWM main 6 minimum value

Comment: This is the minimum PWM pulse the autopilot is allowed to output. When set to -1 the value for PWM_MAIN_MIN will be used

-1 > 1600 -1 us
PWM_MAIN_MIN7 (INT32) PWM main 7 minimum value

Comment: This is the minimum PWM pulse the autopilot is allowed to output. When set to -1 the value for PWM_MAIN_MIN will be used

-1 > 1600 -1 us
PWM_MAIN_MIN8 (INT32) PWM main 8 minimum value

Comment: This is the minimum PWM pulse the autopilot is allowed to output. When set to -1 the value for PWM_MAIN_MIN will be used

-1 > 1600 -1 us
PWM_MAIN_MIN9 (INT32) PWM main 9 minimum value

Comment: This is the minimum PWM pulse the autopilot is allowed to output. When set to -1 the value for PWM_MAIN_MIN will be used

-1 > 1600 -1 us
PWM_MAIN_OUT (INT32) PWM channels used as ESC outputs

Comment: Number representing the channels e.g. 134 - Channel 1, 3 and 4. Global e.g. PWM_MAIN_MIN/MAX/DISARM limits only apply to these channels.

0 > 123456789 0
PWM_MAIN_RATE (INT32) PWM main output frequency

Comment: Set to 400 for industry default or 1000 for high frequency ESCs. Set to 0 for Oneshot125.

-1 > 2000 400 Hz
PWM_MAIN_RATE1 (INT32) PWM main 1 rate

Comment: Set the default PWM output frequency for the main outputs

0 > 400 50 Hz
PWM_MAIN_REV1 (INT32) PWM main 1 reverse value

Comment: Enable to invert the channel. Warning: Use this parameter when connected to a servo only. For a brushless motor, invert manually two phases to reverse the direction.

Disabled (0)
PWM_MAIN_REV10 (INT32) PWM main 10 reverse value

Comment: Enable to invert the channel. Warning: Use this parameter when connected to a servo only. For a brushless motor, invert manually two phases to reverse the direction.

Disabled (0)
PWM_MAIN_REV11 (INT32) PWM main 11 reverse value

Comment: Enable to invert the channel. Warning: Use this parameter when connected to a servo only. For a brushless motor, invert manually two phases to reverse the direction.

Disabled (0)
PWM_MAIN_REV12 (INT32) PWM main 12 reverse value

Comment: Enable to invert the channel. Warning: Use this parameter when connected to a servo only. For a brushless motor, invert manually two phases to reverse the direction.

Disabled (0)
PWM_MAIN_REV13 (INT32) PWM main 13 reverse value

Comment: Enable to invert the channel. Warning: Use this parameter when connected to a servo only. For a brushless motor, invert manually two phases to reverse the direction.

Disabled (0)
PWM_MAIN_REV14 (INT32) PWM main 14 reverse value

Comment: Enable to invert the channel. Warning: Use this parameter when connected to a servo only. For a brushless motor, invert manually two phases to reverse the direction.

Disabled (0)
PWM_MAIN_REV2 (INT32) PWM main 2 reverse value

Comment: Enable to invert the channel. Warning: Use this parameter when connected to a servo only. For a brushless motor, invert manually two phases to reverse the direction.

Disabled (0)
PWM_MAIN_REV3 (INT32) PWM main 3 reverse value

Comment: Enable to invert the channel. Warning: Use this parameter when connected to a servo only. For a brushless motor, invert manually two phases to reverse the direction.

Disabled (0)
PWM_MAIN_REV4 (INT32) PWM main 4 reverse value

Comment: Enable to invert the channel. Warning: Use this parameter when connected to a servo only. For a brushless motor, invert manually two phases to reverse the direction.

Disabled (0)
PWM_MAIN_REV5 (INT32) PWM main 5 reverse value

Comment: Enable to invert the channel. Warning: Use this parameter when connected to a servo only. For a brushless motor, invert manually two phases to reverse the direction.

Disabled (0)
PWM_MAIN_REV6 (INT32) PWM main 6 reverse value

Comment: Enable to invert the channel. Warning: Use this parameter when connected to a servo only. For a brushless motor, invert manually two phases to reverse the direction.

Disabled (0)
PWM_MAIN_REV7 (INT32) PWM main 7 reverse value

Comment: Enable to invert the channel. Warning: Use this parameter when connected to a servo only. For a brushless motor, invert manually two phases to reverse the direction.

Disabled (0)
PWM_MAIN_REV8 (INT32) PWM main 8 reverse value

Comment: Enable to invert the channel. Warning: Use this parameter when connected to a servo only. For a brushless motor, invert manually two phases to reverse the direction.

Disabled (0)
PWM_MAIN_REV9 (INT32) PWM main 9 reverse value

Comment: Enable to invert the channel. Warning: Use this parameter when connected to a servo only. For a brushless motor, invert manually two phases to reverse the direction.

Disabled (0)
PWM_MAIN_TRIM1 (FLOAT) PWM main 1 trim value

Comment: Set to normalized offset

-0.2 > 0.2 0
PWM_MAIN_TRIM10 (FLOAT) PWM main 10 trim value

Comment: Set to normalized offset

-0.2 > 0.2 0
PWM_MAIN_TRIM11 (FLOAT) PWM main 11 trim value

Comment: Set to normalized offset

-0.2 > 0.2 0
PWM_MAIN_TRIM12 (FLOAT) PWM main 12 trim value

Comment: Set to normalized offset

-0.2 > 0.2 0
PWM_MAIN_TRIM13 (FLOAT) PWM main 13 trim value

Comment: Set to normalized offset

-0.2 > 0.2 0
PWM_MAIN_TRIM14 (FLOAT) PWM main 14 trim value

Comment: Set to normalized offset

-0.2 > 0.2 0
PWM_MAIN_TRIM2 (FLOAT) PWM main 2 trim value

Comment: Set to normalized offset

-0.2 > 0.2 0
PWM_MAIN_TRIM3 (FLOAT) PWM main 3 trim value

Comment: Set to normalized offset

-0.2 > 0.2 0
PWM_MAIN_TRIM4 (FLOAT) PWM main 4 trim value

Comment: Set to normalized offset

-0.2 > 0.2 0
PWM_MAIN_TRIM5 (FLOAT) PWM main 5 trim value

Comment: Set to normalized offset

-0.2 > 0.2 0
PWM_MAIN_TRIM6 (FLOAT) PWM main 6 trim value

Comment: Set to normalized offset

-0.2 > 0.2 0
PWM_MAIN_TRIM7 (FLOAT) PWM main 7 trim value

Comment: Set to normalized offset

-0.2 > 0.2 0
PWM_MAIN_TRIM8 (FLOAT) PWM main 8 trim value

Comment: Set to normalized offset

-0.2 > 0.2 0
PWM_MAIN_TRIM9 (FLOAT) PWM main 9 trim value

Comment: Set to normalized offset

-0.2 > 0.2 0
PWM_SBUS_MODE (INT32) S.BUS out

Comment: Set to 1 to enable S.BUS version 1 output instead of RSSI.

Disabled (0)
THR_MDL_FAC (FLOAT) Thrust to motor control signal model parameter

Comment: Parameter used to model the nonlinear relationship between motor control signal (e.g. PWM) and static thrust. The model is: rel_thrust = factor * rel_signal^2 + (1-factor) * rel_signal, where rel_thrust is the normalized thrust between 0 and 1, and rel_signal is the relative motor control signal between 0 and 1.

0.0 > 1.0 0.0

Precision Land

NameDescriptionMin > Max (Incr.)DefaultUnits
PLD_BTOUT (FLOAT) Landing Target Timeout

Comment: Time after which the landing target is considered lost without any new measurements.

0.0 > 50 (0.5) 5.0 s
PLD_FAPPR_ALT (FLOAT) Final approach altitude

Comment: Allow final approach (without horizontal positioning) if losing landing target closer than this to the ground.

0.0 > 10 (0.1) 0.1 m
PLD_HACC_RAD (FLOAT) Horizontal acceptance radius

Comment: Start descending if closer above landing target than this.

0.0 > 10 (0.1) 0.2 m
PLD_MAX_SRCH (INT32) Maximum number of search attempts

Comment: Maximum number of times to search for the landing target if it is lost during the precision landing.

0 > 100 3
PLD_SRCH_ALT (FLOAT) Search altitude

Comment: Altitude above home to which to climb when searching for the landing target.

0.0 > 100 (0.1) 10.0 m
PLD_SRCH_TOUT (FLOAT) Search timeout

Comment: Time allowed to search for the landing target before falling back to normal landing.

0.0 > 100 (0.1) 10.0 s

RTPS

NameDescriptionMin > Max (Incr.)DefaultUnits
RTPS_CONFIG (INT32) Serial Configuration for FastRTPS

Comment: Configure on which serial port to run FastRTPS.

Values:
  • 0: Disabled
  • 6: UART 6
  • 101: TELEM 1
  • 102: TELEM 2
  • 103: TELEM 3
  • 104: TELEM/SERIAL 4
  • 201: GPS 1
  • 202: GPS 2
  • 203: GPS 3
  • 300: Radio Controller
  • 301: Wifi Port

Reboot required: true

0
RTPS_MAV_CONFIG (INT32) Serial Configuration for MAVLink + FastRTPS

Comment: Configure on which serial port to run MAVLink + FastRTPS.

Values:
  • 0: Disabled
  • 6: UART 6
  • 101: TELEM 1
  • 102: TELEM 2
  • 103: TELEM 3
  • 104: TELEM/SERIAL 4
  • 201: GPS 1
  • 202: GPS 2
  • 203: GPS 3
  • 300: Radio Controller
  • 301: Wifi Port

Reboot required: true

0

Radio Calibration

NameDescriptionMin > Max (Incr.)DefaultUnits
RC10_DZ (FLOAT) RC channel 10 dead zone

Comment: The +- range of this value around the trim value will be considered as zero.

0.0 > 100.0 0.0
RC10_MAX (FLOAT) RC channel 10 maximum

Comment: Maximum value for this channel.

1500.0 > 2200.0 2000 us
RC10_MIN (FLOAT) RC channel 10 minimum

Comment: Minimum value for this channel.

800.0 > 1500.0 1000 us
RC10_REV (FLOAT) RC channel 10 reverse

Comment: Set to -1 to reverse channel.

Values:
  • -1.0: Reverse
  • 1.0: Normal
-1.0 > 1.0 1.0
RC10_TRIM (FLOAT) RC channel 10 trim

Comment: Mid point value (has to be set to the same as min for throttle channel).

800.0 > 2200.0 1500 us
RC11_DZ (FLOAT) RC channel 11 dead zone

Comment: The +- range of this value around the trim value will be considered as zero.

0.0 > 100.0 0.0
RC11_MAX (FLOAT) RC channel 11 maximum

Comment: Maximum value for this channel.

1500.0 > 2200.0 2000 us
RC11_MIN (FLOAT) RC channel 11 minimum

Comment: Minimum value for this channel.

800.0 > 1500.0 1000 us
RC11_REV (FLOAT) RC channel 11 reverse

Comment: Set to -1 to reverse channel.

Values:
  • -1.0: Reverse
  • 1.0: Normal
-1.0 > 1.0 1.0
RC11_TRIM (FLOAT) RC channel 11 trim

Comment: Mid point value (has to be set to the same as min for throttle channel).

800.0 > 2200.0 1500 us
RC12_DZ (FLOAT) RC channel 12 dead zone

Comment: The +- range of this value around the trim value will be considered as zero.

0.0 > 100.0 0.0
RC12_MAX (FLOAT) RC channel 12 maximum

Comment: Maximum value for this channel.

1500.0 > 2200.0 2000 us
RC12_MIN (FLOAT) RC channel 12 minimum

Comment: Minimum value for this channel.

800.0 > 1500.0 1000 us
RC12_REV (FLOAT) RC channel 12 reverse

Comment: Set to -1 to reverse channel.

Values:
  • -1.0: Reverse
  • 1.0: Normal
-1.0 > 1.0 1.0
RC12_TRIM (FLOAT) RC channel 12 trim

Comment: Mid point value (has to be set to the same as min for throttle channel).

800.0 > 2200.0 1500 us
RC13_DZ (FLOAT) RC channel 13 dead zone

Comment: The +- range of this value around the trim value will be considered as zero.

0.0 > 100.0 0.0
RC13_MAX (FLOAT) RC channel 13 maximum

Comment: Maximum value for this channel.

1500.0 > 2200.0 2000 us
RC13_MIN (FLOAT) RC channel 13 minimum

Comment: Minimum value for this channel.

800.0 > 1500.0 1000 us
RC13_REV (FLOAT) RC channel 13 reverse

Comment: Set to -1 to reverse channel.

Values:
  • -1.0: Reverse
  • 1.0: Normal
-1.0 > 1.0 1.0
RC13_TRIM (FLOAT) RC channel 13 trim

Comment: Mid point value (has to be set to the same as min for throttle channel).

800.0 > 2200.0 1500 us
RC14_DZ (FLOAT) RC channel 14 dead zone

Comment: The +- range of this value around the trim value will be considered as zero.

0.0 > 100.0 0.0
RC14_MAX (FLOAT) RC channel 14 maximum

Comment: Maximum value for this channel.

1500.0 > 2200.0 2000 us
RC14_MIN (FLOAT) RC channel 14 minimum

Comment: Minimum value for this channel.

800.0 > 1500.0 1000 us
RC14_REV (FLOAT) RC channel 14 reverse

Comment: Set to -1 to reverse channel.

Values:
  • -1.0: Reverse
  • 1.0: Normal
-1.0 > 1.0 1.0
RC14_TRIM (FLOAT) RC channel 14 trim

Comment: Mid point value (has to be set to the same as min for throttle channel).

800.0 > 2200.0 1500 us
RC15_DZ (FLOAT) RC channel 15 dead zone

Comment: The +- range of this value around the trim value will be considered as zero.

0.0 > 100.0 0.0
RC15_MAX (FLOAT) RC channel 15 maximum

Comment: Maximum value for this channel.

1500.0 > 2200.0 2000 us
RC15_MIN (FLOAT) RC channel 15 minimum

Comment: Minimum value for this channel.

800.0 > 1500.0 1000 us
RC15_REV (FLOAT) RC channel 15 reverse

Comment: Set to -1 to reverse channel.

Values:
  • -1.0: Reverse
  • 1.0: Normal
-1.0 > 1.0 1.0
RC15_TRIM (FLOAT) RC channel 15 trim

Comment: Mid point value (has to be set to the same as min for throttle channel).

800.0 > 2200.0 1500 us
RC16_DZ (FLOAT) RC channel 16 dead zone

Comment: The +- range of this value around the trim value will be considered as zero.

0.0 > 100.0 0.0
RC16_MAX (FLOAT) RC channel 16 maximum

Comment: Maximum value for this channel.

1500.0 > 2200.0 2000 us
RC16_MIN (FLOAT) RC channel 16 minimum

Comment: Minimum value for this channel.

800.0 > 1500.0 1000 us
RC16_REV (FLOAT) RC channel 16 reverse

Comment: Set to -1 to reverse channel.

Values:
  • -1.0: Reverse
  • 1.0: Normal
-1.0 > 1.0 1.0
RC16_TRIM (FLOAT) RC channel 16 trim

Comment: Mid point value (has to be set to the same as min for throttle channel).

800.0 > 2200.0 1500 us
RC17_DZ (FLOAT) RC channel 17 dead zone

Comment: The +- range of this value around the trim value will be considered as zero.

0.0 > 100.0 0.0
RC17_MAX (FLOAT) RC channel 17 maximum

Comment: Maximum value for this channel.

1500.0 > 2200.0 2000 us
RC17_MIN (FLOAT) RC channel 17 minimum

Comment: Minimum value for this channel.

800.0 > 1500.0 1000 us
RC17_REV (FLOAT) RC channel 17 reverse

Comment: Set to -1 to reverse channel.

Values:
  • -1.0: Reverse
  • 1.0: Normal
-1.0 > 1.0 1.0
RC17_TRIM (FLOAT) RC channel 17 trim

Comment: Mid point value (has to be set to the same as min for throttle channel).

800.0 > 2200.0 1500 us
RC18_DZ (FLOAT) RC channel 18 dead zone

Comment: The +- range of this value around the trim value will be considered as zero.

0.0 > 100.0 0.0
RC18_MAX (FLOAT) RC channel 18 maximum

Comment: Maximum value for this channel.

1500.0 > 2200.0 2000 us
RC18_MIN (FLOAT) RC channel 18 minimum

Comment: Minimum value for this channel.

800.0 > 1500.0 1000 us
RC18_REV (FLOAT) RC channel 18 reverse

Comment: Set to -1 to reverse channel.

Values:
  • -1.0: Reverse
  • 1.0: Normal
-1.0 > 1.0 1.0
RC18_TRIM (FLOAT) RC channel 18 trim

Comment: Mid point value (has to be set to the same as min for throttle channel).

800.0 > 2200.0 1500 us
RC1_DZ (FLOAT) RC channel 1 dead zone

Comment: The +- range of this value around the trim value will be considered as zero.

0.0 > 100.0 10.0 us
RC1_MAX (FLOAT) RC channel 1 maximum

Comment: Maximum value for RC channel 1

1500.0 > 2200.0 2000.0 us
RC1_MIN (FLOAT) RC channel 1 minimum

Comment: Minimum value for RC channel 1

800.0 > 1500.0 1000.0 us
RC1_REV (FLOAT) RC channel 1 reverse

Comment: Set to -1 to reverse channel.

Values:
  • -1.0: Reverse
  • 1.0: Normal
-1.0 > 1.0 1.0
RC1_TRIM (FLOAT) RC channel 1 trim

Comment: Mid point value (same as min for throttle)

800.0 > 2200.0 1500.0 us
RC2_DZ (FLOAT) RC channel 2 dead zone

Comment: The +- range of this value around the trim value will be considered as zero.

0.0 > 100.0 10.0 us
RC2_MAX (FLOAT) RC channel 2 maximum

Comment: Maximum value for this channel.

1500.0 > 2200.0 2000.0 us
RC2_MIN (FLOAT) RC channel 2 minimum

Comment: Minimum value for this channel.

800.0 > 1500.0 1000.0 us
RC2_REV (FLOAT) RC channel 2 reverse

Comment: Set to -1 to reverse channel.

Values:
  • -1.0: Reverse
  • 1.0: Normal
-1.0 > 1.0 1.0
RC2_TRIM (FLOAT) RC channel 2 trim

Comment: Mid point value (has to be set to the same as min for throttle channel).

800.0 > 2200.0 1500.0 us
RC3_DZ (FLOAT) RC channel 3 dead zone

Comment: The +- range of this value around the trim value will be considered as zero.

0.0 > 100.0 10.0 us
RC3_MAX (FLOAT) RC channel 3 maximum

Comment: Maximum value for this channel.

1500.0 > 2200.0 2000 us
RC3_MIN (FLOAT) RC channel 3 minimum

Comment: Minimum value for this channel.

800.0 > 1500.0 1000 us
RC3_REV (FLOAT) RC channel 3 reverse

Comment: Set to -1 to reverse channel.

Values:
  • -1.0: Reverse
  • 1.0: Normal
-1.0 > 1.0 1.0
RC3_TRIM (FLOAT) RC channel 3 trim

Comment: Mid point value (has to be set to the same as min for throttle channel).

800.0 > 2200.0 1500 us
RC4_DZ (FLOAT) RC channel 4 dead zone

Comment: The +- range of this value around the trim value will be considered as zero.

0.0 > 100.0 10.0 us
RC4_MAX (FLOAT) RC channel 4 maximum

Comment: Maximum value for this channel.

1500.0 > 2200.0 2000 us
RC4_MIN (FLOAT) RC channel 4 minimum

Comment: Minimum value for this channel.

800.0 > 1500.0 1000 us
RC4_REV (FLOAT) RC channel 4 reverse

Comment: Set to -1 to reverse channel.

Values:
  • -1.0: Reverse
  • 1.0: Normal
-1.0 > 1.0 1.0
RC4_TRIM (FLOAT) RC channel 4 trim

Comment: Mid point value (has to be set to the same as min for throttle channel).

800.0 > 2200.0 1500 us
RC5_DZ (FLOAT) RC channel 5 dead zone

Comment: The +- range of this value around the trim value will be considered as zero.

0.0 > 100.0 10.0
RC5_MAX (FLOAT) RC channel 5 maximum

Comment: Maximum value for this channel.

1500.0 > 2200.0 2000 us
RC5_MIN (FLOAT) RC channel 5 minimum

Comment: Minimum value for this channel.

800.0 > 1500.0 1000 us
RC5_REV (FLOAT) RC channel 5 reverse

Comment: Set to -1 to reverse channel.

Values:
  • -1.0: Reverse
  • 1.0: Normal
-1.0 > 1.0 1.0
RC5_TRIM (FLOAT) RC channel 5 trim

Comment: Mid point value (has to be set to the same as min for throttle channel).

800.0 > 2200.0 1500 us
RC6_DZ (FLOAT) RC channel 6 dead zone

Comment: The +- range of this value around the trim value will be considered as zero.

0.0 > 100.0 10.0
RC6_MAX (FLOAT) RC channel 6 maximum

Comment: Maximum value for this channel.

1500.0 > 2200.0 2000 us
RC6_MIN (FLOAT) RC channel 6 minimum

Comment: Minimum value for this channel.

800.0 > 1500.0 1000 us
RC6_REV (FLOAT) RC channel 6 reverse

Comment: Set to -1 to reverse channel.

Values:
  • -1.0: Reverse
  • 1.0: Normal
-1.0 > 1.0 1.0
RC6_TRIM (FLOAT) RC channel 6 trim

Comment: Mid point value (has to be set to the same as min for throttle channel).

800.0 > 2200.0 1500 us
RC7_DZ (FLOAT) RC channel 7 dead zone

Comment: The +- range of this value around the trim value will be considered as zero.

0.0 > 100.0 10.0
RC7_MAX (FLOAT) RC channel 7 maximum

Comment: Maximum value for this channel.

1500.0 > 2200.0 2000 us
RC7_MIN (FLOAT) RC channel 7 minimum

Comment: Minimum value for this channel.

800.0 > 1500.0 1000 us
RC7_REV (FLOAT) RC channel 7 reverse

Comment: Set to -1 to reverse channel.

Values:
  • -1.0: Reverse
  • 1.0: Normal
-1.0 > 1.0 1.0
RC7_TRIM (FLOAT) RC channel 7 trim

Comment: Mid point value (has to be set to the same as min for throttle channel).

800.0 > 2200.0 1500 us
RC8_DZ (FLOAT) RC channel 8 dead zone

Comment: The +- range of this value around the trim value will be considered as zero.

0.0 > 100.0 10.0
RC8_MAX (FLOAT) RC channel 8 maximum

Comment: Maximum value for this channel.

1500.0 > 2200.0 2000 us
RC8_MIN (FLOAT) RC channel 8 minimum

Comment: Minimum value for this channel.

800.0 > 1500.0 1000 us
RC8_REV (FLOAT) RC channel 8 reverse

Comment: Set to -1 to reverse channel.

Values:
  • -1.0: Reverse
  • 1.0: Normal
-1.0 > 1.0 1.0
RC8_TRIM (FLOAT) RC channel 8 trim

Comment: Mid point value (has to be set to the same as min for throttle channel).

800.0 > 2200.0 1500 us
RC9_DZ (FLOAT) RC channel 9 dead zone

Comment: The +- range of this value around the trim value will be considered as zero.

0.0 > 100.0 0.0
RC9_MAX (FLOAT) RC channel 9 maximum

Comment: Maximum value for this channel.

1500.0 > 2200.0 2000 us
RC9_MIN (FLOAT) RC channel 9 minimum

Comment: Minimum value for this channel.

800.0 > 1500.0 1000 us
RC9_REV (FLOAT) RC channel 9 reverse

Comment: Set to -1 to reverse channel.

Values:
  • -1.0: Reverse
  • 1.0: Normal
-1.0 > 1.0 1.0
RC9_TRIM (FLOAT) RC channel 9 trim

Comment: Mid point value (has to be set to the same as min for throttle channel).

800.0 > 2200.0 1500 us
RC_CHAN_CNT (INT32) RC channel count

Comment: This parameter is used by Ground Station software to save the number of channels which were used during RC calibration. It is only meant for ground station use.

0 > 18 0
RC_FAILS_THR (INT32) Failsafe channel PWM threshold

Comment: Set to a value slightly above the PWM value assumed by throttle in a failsafe event, but ensure it is below the PWM value assumed by throttle during normal operation. Use RC_MAP_FAILSAFE to specify which channel is used to check. Note: The default value of 0 is below the epxed range and hence disables the feature.

0 > 2200 0 us
RC_MAP_AUX1 (INT32) AUX1 Passthrough RC channel

Comment: Default function: Camera pitch

Values:
  • 0: Unassigned
  • 1: Channel 1
  • 2: Channel 2
  • 3: Channel 3
  • 4: Channel 4
  • 5: Channel 5
  • 6: Channel 6
  • 7: Channel 7
  • 8: Channel 8
  • 9: Channel 9
  • 10: Channel 10
  • 11: Channel 11
  • 12: Channel 12
  • 13: Channel 13
  • 14: Channel 14
  • 15: Channel 15
  • 16: Channel 16
  • 17: Channel 17
  • 18: Channel 18
0 > 18 0
RC_MAP_AUX2 (INT32) AUX2 Passthrough RC channel

Comment: Default function: Camera roll

Values:
  • 0: Unassigned
  • 1: Channel 1
  • 2: Channel 2
  • 3: Channel 3
  • 4: Channel 4
  • 5: Channel 5
  • 6: Channel 6
  • 7: Channel 7
  • 8: Channel 8
  • 9: Channel 9
  • 10: Channel 10
  • 11: Channel 11
  • 12: Channel 12
  • 13: Channel 13
  • 14: Channel 14
  • 15: Channel 15
  • 16: Channel 16
  • 17: Channel 17
  • 18: Channel 18
0 > 18 0
RC_MAP_AUX3 (INT32) AUX3 Passthrough RC channel

Comment: Default function: Camera azimuth / yaw

Values:
  • 0: Unassigned
  • 1: Channel 1
  • 2: Channel 2
  • 3: Channel 3
  • 4: Channel 4
  • 5: Channel 5
  • 6: Channel 6
  • 7: Channel 7
  • 8: Channel 8
  • 9: Channel 9
  • 10: Channel 10
  • 11: Channel 11
  • 12: Channel 12
  • 13: Channel 13
  • 14: Channel 14
  • 15: Channel 15
  • 16: Channel 16
  • 17: Channel 17
  • 18: Channel 18
0 > 18 0
RC_MAP_AUX4 (INT32) AUX4 Passthrough RC channel Values:
  • 0: Unassigned
  • 1: Channel 1
  • 2: Channel 2
  • 3: Channel 3
  • 4: Channel 4
  • 5: Channel 5
  • 6: Channel 6
  • 7: Channel 7
  • 8: Channel 8
  • 9: Channel 9
  • 10: Channel 10
  • 11: Channel 11
  • 12: Channel 12
  • 13: Channel 13
  • 14: Channel 14
  • 15: Channel 15
  • 16: Channel 16
  • 17: Channel 17
  • 18: Channel 18
0 > 18 0
RC_MAP_AUX5 (INT32) AUX5 Passthrough RC channel Values:
  • 0: Unassigned
  • 1: Channel 1
  • 2: Channel 2
  • 3: Channel 3
  • 4: Channel 4
  • 5: Channel 5
  • 6: Channel 6
  • 7: Channel 7
  • 8: Channel 8
  • 9: Channel 9
  • 10: Channel 10
  • 11: Channel 11
  • 12: Channel 12
  • 13: Channel 13
  • 14: Channel 14
  • 15: Channel 15
  • 16: Channel 16
  • 17: Channel 17
  • 18: Channel 18
0 > 18 0
RC_MAP_AUX6 (INT32) AUX6 Passthrough RC channel Values:
  • 0: Unassigned
  • 1: Channel 1
  • 2: Channel 2
  • 3: Channel 3
  • 4: Channel 4
  • 5: Channel 5
  • 6: Channel 6
  • 7: Channel 7
  • 8: Channel 8
  • 9: Channel 9
  • 10: Channel 10
  • 11: Channel 11
  • 12: Channel 12
  • 13: Channel 13
  • 14: Channel 14
  • 15: Channel 15
  • 16: Channel 16
  • 17: Channel 17
  • 18: Channel 18
0 > 18 0
RC_MAP_FAILSAFE (INT32) Failsafe channel mapping

Comment: Configures which channel is used by the receiver to indicate the signal was lost. Futaba receivers do report that way. If 0, whichever channel is mapped to throttle is used otherwise the value indicates the specific RC channel to use Use RC_FAILS_THR to set the threshold indicating lost signal. By default it's below the expected range and hence diabled.

Values:
  • 0: Unassigned
  • 1: Channel 1
  • 2: Channel 2
  • 3: Channel 3
  • 4: Channel 4
  • 5: Channel 5
  • 6: Channel 6
  • 7: Channel 7
  • 8: Channel 8
  • 9: Channel 9
  • 10: Channel 10
  • 11: Channel 11
  • 12: Channel 12
  • 13: Channel 13
  • 14: Channel 14
  • 15: Channel 15
  • 16: Channel 16
  • 17: Channel 17
  • 18: Channel 18
0 > 18 0
RC_MAP_PARAM1 (INT32) PARAM1 tuning channel

Comment: Can be used for parameter tuning with the RC. This one is further referenced as the 1st parameter channel. Set to 0 to deactivate *

Values:
  • 0: Unassigned
  • 1: Channel 1
  • 2: Channel 2
  • 3: Channel 3
  • 4: Channel 4
  • 5: Channel 5
  • 6: Channel 6
  • 7: Channel 7
  • 8: Channel 8
  • 9: Channel 9
  • 10: Channel 10
  • 11: Channel 11
  • 12: Channel 12
  • 13: Channel 13
  • 14: Channel 14
  • 15: Channel 15
  • 16: Channel 16
  • 17: Channel 17
  • 18: Channel 18
0 > 18 0
RC_MAP_PARAM2 (INT32) PARAM2 tuning channel

Comment: Can be used for parameter tuning with the RC. This one is further referenced as the 2nd parameter channel. Set to 0 to deactivate *

Values:
  • 0: Unassigned
  • 1: Channel 1
  • 2: Channel 2
  • 3: Channel 3
  • 4: Channel 4
  • 5: Channel 5
  • 6: Channel 6
  • 7: Channel 7
  • 8: Channel 8
  • 9: Channel 9
  • 10: Channel 10
  • 11: Channel 11
  • 12: Channel 12
  • 13: Channel 13
  • 14: Channel 14
  • 15: Channel 15
  • 16: Channel 16
  • 17: Channel 17
  • 18: Channel 18
0 > 18 0
RC_MAP_PARAM3 (INT32) PARAM3 tuning channel

Comment: Can be used for parameter tuning with the RC. This one is further referenced as the 3th parameter channel. Set to 0 to deactivate *

Values:
  • 0: Unassigned
  • 1: Channel 1
  • 2: Channel 2
  • 3: Channel 3
  • 4: Channel 4
  • 5: Channel 5
  • 6: Channel 6
  • 7: Channel 7
  • 8: Channel 8
  • 9: Channel 9
  • 10: Channel 10
  • 11: Channel 11
  • 12: Channel 12
  • 13: Channel 13
  • 14: Channel 14
  • 15: Channel 15
  • 16: Channel 16
  • 17: Channel 17
  • 18: Channel 18
0 > 18 0
RC_MAP_PITCH (INT32) Pitch control channel mapping

Comment: The channel index (starting from 1 for channel 1) indicates which channel should be used for reading pitch inputs from. A value of zero indicates the switch is not assigned.

Values:
  • 0: Unassigned
  • 1: Channel 1
  • 2: Channel 2
  • 3: Channel 3
  • 4: Channel 4
  • 5: Channel 5
  • 6: Channel 6
  • 7: Channel 7
  • 8: Channel 8
  • 9: Channel 9
  • 10: Channel 10
  • 11: Channel 11
  • 12: Channel 12
  • 13: Channel 13
  • 14: Channel 14
  • 15: Channel 15
  • 16: Channel 16
  • 17: Channel 17
  • 18: Channel 18
0 > 18 0
RC_MAP_ROLL (INT32) Roll control channel mapping

Comment: The channel index (starting from 1 for channel 1) indicates which channel should be used for reading roll inputs from. A value of zero indicates the switch is not assigned.

Values:
  • 0: Unassigned
  • 1: Channel 1
  • 2: Channel 2
  • 3: Channel 3
  • 4: Channel 4
  • 5: Channel 5
  • 6: Channel 6
  • 7: Channel 7
  • 8: Channel 8
  • 9: Channel 9
  • 10: Channel 10
  • 11: Channel 11
  • 12: Channel 12
  • 13: Channel 13
  • 14: Channel 14
  • 15: Channel 15
  • 16: Channel 16
  • 17: Channel 17
  • 18: Channel 18
0 > 18 0
RC_MAP_THROTTLE (INT32) Throttle control channel mapping

Comment: The channel index (starting from 1 for channel 1) indicates which channel should be used for reading throttle inputs from. A value of zero indicates the switch is not assigned.

Values:
  • 0: Unassigned
  • 1: Channel 1
  • 2: Channel 2
  • 3: Channel 3
  • 4: Channel 4
  • 5: Channel 5
  • 6: Channel 6
  • 7: Channel 7
  • 8: Channel 8
  • 9: Channel 9
  • 10: Channel 10
  • 11: Channel 11
  • 12: Channel 12
  • 13: Channel 13
  • 14: Channel 14
  • 15: Channel 15
  • 16: Channel 16
  • 17: Channel 17
  • 18: Channel 18
0 > 18 0
RC_MAP_YAW (INT32) Yaw control channel mapping

Comment: The channel index (starting from 1 for channel 1) indicates which channel should be used for reading yaw inputs from. A value of zero indicates the switch is not assigned.

Values:
  • 0: Unassigned
  • 1: Channel 1
  • 2: Channel 2
  • 3: Channel 3
  • 4: Channel 4
  • 5: Channel 5
  • 6: Channel 6
  • 7: Channel 7
  • 8: Channel 8
  • 9: Channel 9
  • 10: Channel 10
  • 11: Channel 11
  • 12: Channel 12
  • 13: Channel 13
  • 14: Channel 14
  • 15: Channel 15
  • 16: Channel 16
  • 17: Channel 17
  • 18: Channel 18
0 > 18 0
RC_RSSI_PWM_CHAN (INT32) PWM input channel that provides RSSI

Comment: 0: do not read RSSI from input channel 1-18: read RSSI from specified input channel Specify the range for RSSI input with RC_RSSI_PWM_MIN and RC_RSSI_PWM_MAX parameters.

Values:
  • 0: Unassigned
  • 1: Channel 1
  • 2: Channel 2
  • 3: Channel 3
  • 4: Channel 4
  • 5: Channel 5
  • 6: Channel 6
  • 7: Channel 7
  • 8: Channel 8
  • 9: Channel 9
  • 10: Channel 10
  • 11: Channel 11
  • 12: Channel 12
  • 13: Channel 13
  • 14: Channel 14
  • 15: Channel 15
  • 16: Channel 16
  • 17: Channel 17
  • 18: Channel 18
0 > 18 0
RC_RSSI_PWM_MAX (INT32) Max input value for RSSI reading

Comment: Only used if RC_RSSI_PWM_CHAN > 0

0 > 2000 2000
RC_RSSI_PWM_MIN (INT32) Min input value for RSSI reading

Comment: Only used if RC_RSSI_PWM_CHAN > 0

0 > 2000 1000
TRIM_PITCH (FLOAT) Pitch trim

Comment: The trim value is the actuator control value the system needs for straight and level flight. It can be calibrated by flying manually straight and level using the RC trims and copying them using the GCS.

-0.25 > 0.25 (0.01) 0.0
TRIM_ROLL (FLOAT) Roll trim

Comment: The trim value is the actuator control value the system needs for straight and level flight. It can be calibrated by flying manually straight and level using the RC trims and copying them using the GCS.

-0.25 > 0.25 (0.01) 0.0
TRIM_YAW (FLOAT) Yaw trim

Comment: The trim value is the actuator control value the system needs for straight and level flight. It can be calibrated by flying manually straight and level using the RC trims and copying them using the GCS.

-0.25 > 0.25 (0.01) 0.0

Radio Switches

NameDescriptionMin > Max (Incr.)DefaultUnits
RC_ACRO_TH (FLOAT) Threshold for selecting acro mode

Comment: 0-1 indicate where in the full channel range the threshold sits 0 : min 1 : max sign indicates polarity of comparison positive : true when channel>th negative : true when channel<th

-1 > 1 0.75
RC_ARMSWITCH_TH (FLOAT) Threshold for the arm switch

Comment: 0-1 indicate where in the full channel range the threshold sits 0 : min 1 : max sign indicates polarity of comparison positive : true when channel>th negative : true when channel<th

-1 > 1 0.75
RC_ASSIST_TH (FLOAT) Threshold for selecting assist mode

Comment: 0-1 indicate where in the full channel range the threshold sits 0 : min 1 : max sign indicates polarity of comparison positive : true when channel>th negative : true when channel<th

-1 > 1 0.25
RC_AUTO_TH (FLOAT) Threshold for selecting auto mode

Comment: 0-1 indicate where in the full channel range the threshold sits 0 : min 1 : max sign indicates polarity of comparison positive : true when channel>th negative : true when channel<th

-1 > 1 0.75
RC_GEAR_TH (FLOAT) Threshold for the landing gear switch

Comment: 0-1 indicate where in the full channel range the threshold sits 0 : min 1 : max sign indicates polarity of comparison positive : true when channel>th negative : true when channel<th

-1 > 1 0.75
RC_KILLSWITCH_TH (FLOAT) Threshold for the kill switch

Comment: 0-1 indicate where in the full channel range the threshold sits 0 : min 1 : max sign indicates polarity of comparison positive : true when channel>th negative : true when channel<th

-1 > 1 0.75
RC_LOITER_TH (FLOAT) Threshold for selecting loiter mode

Comment: 0-1 indicate where in the full channel range the threshold sits 0 : min 1 : max sign indicates polarity of comparison positive : true when channel>th negative : true when channel<th

-1 > 1 0.75
RC_MAN_TH (FLOAT) Threshold for the manual switch

Comment: 0-1 indicate where in the full channel range the threshold sits 0 : min 1 : max sign indicates polarity of comparison positive : true when channel>th negative : true when channel<th

-1 > 1 0.75
RC_MAP_ACRO_SW (INT32) Acro switch channel Values:
  • 0: Unassigned
  • 1: Channel 1
  • 2: Channel 2
  • 3: Channel 3
  • 4: Channel 4
  • 5: Channel 5
  • 6: Channel 6
  • 7: Channel 7
  • 8: Channel 8
  • 9: Channel 9
  • 10: Channel 10
  • 11: Channel 11
  • 12: Channel 12
  • 13: Channel 13
  • 14: Channel 14
  • 15: Channel 15
  • 16: Channel 16
  • 17: Channel 17
  • 18: Channel 18
0 > 18 0
RC_MAP_ARM_SW (INT32) Arm switch channel

Comment: Use it to arm/disarm via switch instead of default throttle stick. If this is assigned, arming and disarming via stick is disabled.

Values:
  • 0: Unassigned
  • 1: Channel 1
  • 2: Channel 2
  • 3: Channel 3
  • 4: Channel 4
  • 5: Channel 5
  • 6: Channel 6
  • 7: Channel 7
  • 8: Channel 8
  • 9: Channel 9
  • 10: Channel 10
  • 11: Channel 11
  • 12: Channel 12
  • 13: Channel 13
  • 14: Channel 14
  • 15: Channel 15
  • 16: Channel 16
  • 17: Channel 17
  • 18: Channel 18
0 > 18 0
RC_MAP_FLAPS (INT32) Flaps channel Values:
  • 0: Unassigned
  • 1: Channel 1
  • 2: Channel 2
  • 3: Channel 3
  • 4: Channel 4
  • 5: Channel 5
  • 6: Channel 6
  • 7: Channel 7
  • 8: Channel 8
  • 9: Channel 9
  • 10: Channel 10
  • 11: Channel 11
  • 12: Channel 12
  • 13: Channel 13
  • 14: Channel 14
  • 15: Channel 15
  • 16: Channel 16
  • 17: Channel 17
  • 18: Channel 18
0 > 18 0
RC_MAP_FLTMODE (INT32) Single channel flight mode selection

Comment: If this parameter is non-zero, flight modes are only selected by this channel and are assigned to six slots.

Values:
  • 0: Unassigned
  • 1: Channel 1
  • 2: Channel 2
  • 3: Channel 3
  • 4: Channel 4
  • 5: Channel 5
  • 6: Channel 6
  • 7: Channel 7
  • 8: Channel 8
  • 9: Channel 9
  • 10: Channel 10
  • 11: Channel 11
  • 12: Channel 12
  • 13: Channel 13
  • 14: Channel 14
  • 15: Channel 15
  • 16: Channel 16
  • 17: Channel 17
  • 18: Channel 18
0 > 18 0
RC_MAP_GEAR_SW (INT32) Landing gear switch channel Values:
  • 0: Unassigned
  • 1: Channel 1
  • 2: Channel 2
  • 3: Channel 3
  • 4: Channel 4
  • 5: Channel 5
  • 6: Channel 6
  • 7: Channel 7
  • 8: Channel 8
  • 9: Channel 9
  • 10: Channel 10
  • 11: Channel 11
  • 12: Channel 12
  • 13: Channel 13
  • 14: Channel 14
  • 15: Channel 15
  • 16: Channel 16
  • 17: Channel 17
  • 18: Channel 18
0 > 18 0
RC_MAP_KILL_SW (INT32) Emergency Kill switch channel Values:
  • 0: Unassigned
  • 1: Channel 1
  • 2: Channel 2
  • 3: Channel 3
  • 4: Channel 4
  • 5: Channel 5
  • 6: Channel 6
  • 7: Channel 7
  • 8: Channel 8
  • 9: Channel 9
  • 10: Channel 10
  • 11: Channel 11
  • 12: Channel 12
  • 13: Channel 13
  • 14: Channel 14
  • 15: Channel 15
  • 16: Channel 16
  • 17: Channel 17
  • 18: Channel 18
0 > 18 0
RC_MAP_LOITER_SW (INT32) Loiter switch channel Values:
  • 0: Unassigned
  • 1: Channel 1
  • 2: Channel 2
  • 3: Channel 3
  • 4: Channel 4
  • 5: Channel 5
  • 6: Channel 6
  • 7: Channel 7
  • 8: Channel 8
  • 9: Channel 9
  • 10: Channel 10
  • 11: Channel 11
  • 12: Channel 12
  • 13: Channel 13
  • 14: Channel 14
  • 15: Channel 15
  • 16: Channel 16
  • 17: Channel 17
  • 18: Channel 18
0 > 18 0
RC_MAP_MAN_SW (INT32) Manual switch channel mapping Values:
  • 0: Unassigned
  • 1: Channel 1
  • 2: Channel 2
  • 3: Channel 3
  • 4: Channel 4
  • 5: Channel 5
  • 6: Channel 6
  • 7: Channel 7
  • 8: Channel 8
  • 9: Channel 9
  • 10: Channel 10
  • 11: Channel 11
  • 12: Channel 12
  • 13: Channel 13
  • 14: Channel 14
  • 15: Channel 15
  • 16: Channel 16
  • 17: Channel 17
  • 18: Channel 18
0 > 18 0
RC_MAP_MODE_SW (INT32) Mode switch channel mapping

Comment: This is the main flight mode selector. The channel index (starting from 1 for channel 1) indicates which channel should be used for deciding about the main mode. A value of zero indicates the switch is not assigned.

Values:
  • 0: Unassigned
  • 1: Channel 1
  • 2: Channel 2
  • 3: Channel 3
  • 4: Channel 4
  • 5: Channel 5
  • 6: Channel 6
  • 7: Channel 7
  • 8: Channel 8
  • 9: Channel 9
  • 10: Channel 10
  • 11: Channel 11
  • 12: Channel 12
  • 13: Channel 13
  • 14: Channel 14
  • 15: Channel 15
  • 16: Channel 16
  • 17: Channel 17
  • 18: Channel 18
0 > 18 0
RC_MAP_OFFB_SW (INT32) Offboard switch channel Values:
  • 0: Unassigned
  • 1: Channel 1
  • 2: Channel 2
  • 3: Channel 3
  • 4: Channel 4
  • 5: Channel 5
  • 6: Channel 6
  • 7: Channel 7
  • 8: Channel 8
  • 9: Channel 9
  • 10: Channel 10
  • 11: Channel 11
  • 12: Channel 12
  • 13: Channel 13
  • 14: Channel 14
  • 15: Channel 15
  • 16: Channel 16
  • 17: Channel 17
  • 18: Channel 18
0 > 18 0
RC_MAP_POSCTL_SW (INT32) Position Control switch channel Values:
  • 0: Unassigned
  • 1: Channel 1
  • 2: Channel 2
  • 3: Channel 3
  • 4: Channel 4
  • 5: Channel 5
  • 6: Channel 6
  • 7: Channel 7
  • 8: Channel 8
  • 9: Channel 9
  • 10: Channel 10
  • 11: Channel 11
  • 12: Channel 12
  • 13: Channel 13
  • 14: Channel 14
  • 15: Channel 15
  • 16: Channel 16
  • 17: Channel 17
  • 18: Channel 18
0 > 18 0
RC_MAP_RATT_SW (INT32) Rattitude switch channel (deprecated) Values:
  • 0: Unassigned
  • 1: Channel 1
  • 2: Channel 2
  • 3: Channel 3
  • 4: Channel 4
  • 5: Channel 5
  • 6: Channel 6
  • 7: Channel 7
  • 8: Channel 8
  • 9: Channel 9
  • 10: Channel 10
  • 11: Channel 11
  • 12: Channel 12
  • 13: Channel 13
  • 14: Channel 14
  • 15: Channel 15
  • 16: Channel 16
  • 17: Channel 17
  • 18: Channel 18
0 > 18 0
RC_MAP_RETURN_SW (INT32) Return switch channel Values:
  • 0: Unassigned
  • 1: Channel 1
  • 2: Channel 2
  • 3: Channel 3
  • 4: Channel 4
  • 5: Channel 5
  • 6: Channel 6
  • 7: Channel 7
  • 8: Channel 8
  • 9: Channel 9
  • 10: Channel 10
  • 11: Channel 11
  • 12: Channel 12
  • 13: Channel 13
  • 14: Channel 14
  • 15: Channel 15
  • 16: Channel 16
  • 17: Channel 17
  • 18: Channel 18
0 > 18 0
RC_MAP_STAB_SW (INT32) Stabilize switch channel mapping Values:
  • 0: Unassigned
  • 1: Channel 1
  • 2: Channel 2
  • 3: Channel 3
  • 4: Channel 4
  • 5: Channel 5
  • 6: Channel 6
  • 7: Channel 7
  • 8: Channel 8
  • 9: Channel 9
  • 10: Channel 10
  • 11: Channel 11
  • 12: Channel 12
  • 13: Channel 13
  • 14: Channel 14
  • 15: Channel 15
  • 16: Channel 16
  • 17: Channel 17
  • 18: Channel 18
0 > 18 0
RC_MAP_TRANS_SW (INT32) VTOL transition switch channel mapping Values:
  • 0: Unassigned
  • 1: Channel 1
  • 2: Channel 2
  • 3: Channel 3
  • 4: Channel 4
  • 5: Channel 5
  • 6: Channel 6
  • 7: Channel 7
  • 8: Channel 8
  • 9: Channel 9
  • 10: Channel 10
  • 11: Channel 11
  • 12: Channel 12
  • 13: Channel 13
  • 14: Channel 14
  • 15: Channel 15
  • 16: Channel 16
  • 17: Channel 17
  • 18: Channel 18
0 > 18 0
RC_OFFB_TH (FLOAT) Threshold for selecting offboard mode

Comment: 0-1 indicate where in the full channel range the threshold sits 0 : min 1 : max sign indicates polarity of comparison positive : true when channel>th negative : true when channel<th

-1 > 1 0.75
RC_POSCTL_TH (FLOAT) Threshold for selecting posctl mode

Comment: 0-1 indicate where in the full channel range the threshold sits 0 : min 1 : max sign indicates polarity of comparison positive : true when channel>th negative : true when channel<th

-1 > 1 0.75
RC_RETURN_TH (FLOAT) Threshold for selecting return to launch mode

Comment: 0-1 indicate where in the full channel range the threshold sits 0 : min 1 : max sign indicates polarity of comparison positive : true when channel>th negative : true when channel<th

-1 > 1 0.75
RC_STAB_TH (FLOAT) Threshold for the stabilize switch

Comment: 0-1 indicate where in the full channel range the threshold sits 0 : min 1 : max sign indicates polarity of comparison positive : true when channel>th negative : true when channel<th

-1 > 1 0.5
RC_TRANS_TH (FLOAT) Threshold for the VTOL transition switch

Comment: 0-1 indicate where in the full channel range the threshold sits 0 : min 1 : max sign indicates polarity of comparison positive : true when channel>th negative : true when channel<th

-1 > 1 0.75

Return Mode

NameDescriptionMin > Max (Incr.)DefaultUnits
RTL_CONE_ANG (INT32) Half-angle of the return mode altitude cone

Comment: Defines the half-angle of a cone centered around the destination position that affects the altitude at which the vehicle returns.

Values:
  • 0: No cone, always climb to RTL_RETURN_ALT above destination.
  • 25: 25 degrees half cone angle.
  • 45: 45 degrees half cone angle.
  • 65: 65 degrees half cone angle.
  • 80: 80 degrees half cone angle.
  • 90: Only climb to at least RTL_DESCEND_ALT above destination.
0 > 90 45 deg
RTL_DESCEND_ALT (FLOAT) Return mode loiter altitude

Comment: Descend to this altitude (above destination position) after return, and wait for time defined in RTL_LAND_DELAY. Land (i.e. slowly descend) from this altitude if autolanding allowed.

2 > 100 (0.5) 30 m
RTL_LAND_DELAY (FLOAT) Return mode delay

Comment: Delay before landing (after initial descent) in Return mode. If set to -1 the system will not land but loiter at RTL_DESCEND_ALT.

-1 > 300 (0.5) 0.0 s
RTL_LOITER_RAD (FLOAT) Loiter radius for rtl descend

Comment: Set the radius for loitering to a safe altitude for VTOL transition.

25 > 1000 (0.5) 50.0 m
RTL_MIN_DIST (FLOAT) Horizontal radius from return point within which special rules for return mode apply

Comment: The return altitude will be calculated based on RTL_CONE_ANG parameter. The yaw setpoint will switch to the one defined by corresponding waypoint.

0.5 > 100 (0.5) 10.0 m
RTL_RETURN_ALT (FLOAT) Return mode return altitude

Comment: Default minimum altitude above destination (e.g. home, safe point, landing pattern) for return flight. This is affected by RTL_MIN_DIST and RTL_CONE_ANG.

0 > 150 (0.5) 60 m
RTL_TYPE (INT32) Return type

Comment: Return mode destination and flight path (home location, rally point, mission landing pattern, reverse mission)

Values:
  • 0: Return to closest safe point (home or rally point) via direct path.
  • 1: Return to closest safe point other than home (mission landing pattern or rally point), via direct path. If no mission landing or rally points are defined return home via direct path.
  • 2: Return to a planned mission landing, if available, using the mission path, else return to home via the reverse mission path. Do not consider rally points.
  • 3: Return via direct path to closest destination: home, start of mission landing pattern or safe point. If the destination is a mission landing pattern, follow the pattern to land.
0

Return To Land

NameDescriptionMin > Max (Incr.)DefaultUnits
RTL_PLD_MD (INT32) RTL precision land mode

Comment: Use precision landing when doing an RTL landing phase.

Values:
  • 0: No precision landing
  • 1: Opportunistic precision landing
  • 2: Required precision landing
0

Roboclaw

NameDescriptionMin > Max (Incr.)DefaultUnits
RBCLW_SER_CFG (INT32) Serial Configuration for Roboclaw Driver

Comment: Configure on which serial port to run Roboclaw Driver.

Values:
  • 0: Disabled
  • 6: UART 6
  • 101: TELEM 1
  • 102: TELEM 2
  • 103: TELEM 3
  • 104: TELEM/SERIAL 4
  • 201: GPS 1
  • 202: GPS 2
  • 203: GPS 3
  • 300: Radio Controller
  • 301: Wifi Port

Reboot required: true

0

Roboclaw driver

NameDescriptionMin > Max (Incr.)DefaultUnits
RBCLW_ADDRESS (INT32) Address of the Roboclaw

Comment: The Roboclaw can be configured to have an address from 0x80 to 0x87, inclusive. It must be configured to match this parameter.

Values:
  • 128: 0x80
  • 129: 0x81
  • 130: 0x82
  • 131: 0x83
  • 132: 0x84
  • 133: 0x85
  • 134: 0x86
  • 135: 0x87
128 > 135 128
RBCLW_BAUD (INT32) Roboclaw serial baud rate

Comment: Baud rate of the serial communication with the Roboclaw. The Roboclaw must be configured to match this rate.

Values:
  • 2400: 2400 baud
  • 9600: 9600 baud
  • 19200: 19200 baud
  • 38400: 38400 baud
  • 57600: 57600 baud
  • 115200: 115200 baud
  • 230400: 230400 baud
  • 460800: 460800 baud

Reboot required: true

2400 > 460800 2400
RBCLW_COUNTS_REV (INT32) Encoder counts per revolution

Comment: Number of encoder counts for one revolution. The roboclaw treats analog encoders (potentiometers) as having 2047 counts per rev. The default value of 1200 corresponds to the default configuration of the Aion R1 rover.

1 > ? 1200
RBCLW_READ_PER (INT32) Encoder read period

Comment: How long to wait, in Milliseconds, between reading wheel encoder values over Uart from the Roboclaw

1 > 1000 10 ms
RBCLW_WRITE_PER (INT32) Uart write period

Comment: How long to wait, in Milliseconds, between writing actuator controls over Uart to the Roboclaw

1 > 1000 10 ms

Rover Position Control

NameDescriptionMin > Max (Incr.)DefaultUnits
GND_L1_DAMPING (FLOAT) L1 damping

Comment: Damping factor for L1 control.

0.6 > 0.9 (0.05) 0.75
GND_L1_DIST (FLOAT) L1 distance

Comment: This is the distance at which the next waypoint is activated. This should be set to about 2-4x of GND_WHEEL_BASE and not smaller than one meter (due to GPS accuracy).

1.0 > 50.0 (0.1) 1.0 m
GND_L1_PERIOD (FLOAT) L1 period

Comment: This is the L1 distance and defines the tracking point ahead of the rover it's following. Use values around 2-5m for a 0.3m wheel base. Tuning instructions: Shorten slowly during tuning until response is sharp without oscillation.

0.5 > 50.0 (0.5) 5.0 m
GND_MAN_Y_MAX (FLOAT) Max manual yaw rate 0.0 > 400 150.0 deg/s
GND_MAX_ANG (FLOAT) Maximum turn angle for Ackerman steering

Comment: At a control output of 0, the steering wheels are at 0 radians. At a control output of 1, the steering wheels are at GND_MAX_ANG radians.

0.0 > 3.14159 (0.01) 0.7854 rad
GND_SPEED_D (FLOAT) Speed proportional gain

Comment: This is the derivative gain for the speed closed loop controller

0.00 > 50.0 (0.005) 0.001 %m/s
GND_SPEED_I (FLOAT) Speed Integral gain

Comment: This is the integral gain for the speed closed loop controller

0.00 > 50.0 (0.005) 3.0 %m/s
GND_SPEED_IMAX (FLOAT) Speed integral maximum value

Comment: This is the maxim value the integral can reach to prevent wind-up.

0.005 > 50.0 (0.005) 1.0 %m/s
GND_SPEED_MAX (FLOAT) Maximum ground speed 0.0 > 40 (0.5) 10.0 m/s
GND_SPEED_P (FLOAT) Speed proportional gain

Comment: This is the proportional gain for the speed closed loop controller

0.005 > 50.0 (0.005) 2.0 %m/s
GND_SPEED_THR_SC (FLOAT) Speed to throttle scaler

Comment: This is a gain to map the speed control output to the throttle linearly.

0.005 > 50.0 (0.005) 1.0 %m/s
GND_SPEED_TRIM (FLOAT) Trim ground speed 0.0 > 40 (0.5) 3.0 m/s
GND_SP_CTRL_MODE (INT32) Control mode for speed

Comment: This allows the user to choose between closed loop gps speed or open loop cruise throttle speed

Values:
  • 0: open loop control
  • 1: close the loop with gps speed
0 > 1 1
GND_THR_CRUISE (FLOAT) Cruise throttle

Comment: This is the throttle setting required to achieve the desired cruise speed. 10% is ok for a traxxas stampede vxl with ESC set to training mode

0.0 > 1.0 (0.01) 0.1 norm
GND_THR_MAX (FLOAT) Throttle limit max

Comment: This is the maximum throttle % that can be used by the controller. For a Traxxas stampede vxl with the ESC set to training, 30 % is enough

0.0 > 1.0 (0.01) 0.3 norm
GND_THR_MIN (FLOAT) Throttle limit min

Comment: This is the minimum throttle % that can be used by the controller. Set to 0 for rover

0.0 > 1.0 (0.01) 0.0 norm
GND_WHEEL_BASE (FLOAT) Distance from front axle to rear axle

Comment: A value of 0.31 is typical for 1/10 RC cars.

0.0 > ? (0.01) 0.31 m

Runway Takeoff

NameDescriptionMin > Max (Incr.)DefaultUnits
RWTO_AIRSPD_SCL (FLOAT) Min airspeed scaling factor for takeoff

Comment: Pitch up will be commanded when the following airspeed is reached: FW_AIRSPD_MIN * RWTO_AIRSPD_SCL

0.0 > 2.0 (0.01) 1.3 norm
RWTO_HDG (INT32) Specifies which heading should be held during runnway takeoff

Comment: 0: airframe heading, 1: heading towards takeoff waypoint

Values:
  • 0: Airframe
  • 1: Waypoint
0 > 1 0
RWTO_MAX_PITCH (FLOAT) Max pitch during takeoff

Comment: Fixed-wing settings are used if set to 0. Note that there is also a minimum pitch of 10 degrees during takeoff, so this must be larger if set.

0.0 > 60.0 (0.5) 20.0 deg
RWTO_MAX_ROLL (FLOAT) Max roll during climbout

Comment: Roll is limited during climbout to ensure enough lift and prevents aggressive navigation before we're on a safe height.

0.0 > 60.0 (0.5) 25.0 deg
RWTO_MAX_THR (FLOAT) Max throttle during runway takeoff

Comment: Can be used to test taxi on runway

0.0 > 1.0 (0.01) 1.0 norm
RWTO_NAV_ALT (FLOAT) Altitude AGL at which we have enough ground clearance to allow some roll

Comment: Until RWTO_NAV_ALT is reached the plane is held level and only rudder is used to keep the heading (see RWTO_HDG). This should be below FW_CLMBOUT_DIFF if FW_CLMBOUT_DIFF > 0.

0.0 > 100.0 (1) 5.0 m
RWTO_PSP (FLOAT) Pitch setpoint during taxi / before takeoff airspeed is reached

Comment: A taildragger with steerable wheel might need to pitch up a little to keep its wheel on the ground before airspeed to takeoff is reached.

-10.0 > 20.0 (0.5) 0.0 deg
RWTO_RAMP_TIME (FLOAT) Throttle ramp up time for runway takeoff 1.0 > 15.0 (0.1) 2.0 s
RWTO_TKOFF (INT32) Runway takeoff with landing gear Disabled (0)

SD Logging

NameDescriptionMin > Max (Incr.)DefaultUnits
SDLOG_BOOT_BAT (INT32) Battery-only Logging

Comment: When enabled, logging will not start from boot if battery power is not detected (e.g. powered via USB on a test bench). This prevents extraneous flight logs from being created during bench testing. Note that this only applies to log-from-boot modes. This has no effect on arm-based modes.

Disabled (0)
SDLOG_DIRS_MAX (INT32) Maximum number of log directories to keep

Comment: If there are more log directories than this value, the system will delete the oldest directories during startup. In addition, the system will delete old logs if there is not enough free space left. The minimum amount is 300 MB. If this is set to 0, old directories will only be removed if the free space falls below the minimum. Note: this does not apply to mission log files.

Reboot required: true

0 > 1000 0
SDLOG_MISSION (INT32) Mission Log

Comment: If enabled, a small additional "mission" log file will be written to the SD card. The log contains just those messages that are useful for tasks like generating flight statistics and geotagging. The different modes can be used to further reduce the logged data (and thus the log file size). For example, choose geotagging mode to only log data required for geotagging. Note that the normal/full log is still created, and contains all the data in the mission log (and more).

Values:
  • 0: Disabled
  • 1: All mission messages
  • 2: Geotagging messages

Reboot required: true

0
SDLOG_MODE (INT32) Logging Mode

Comment: Determines when to start and stop logging. By default, logging is started when arming the system, and stopped when disarming.

Values:
  • -1: disabled
  • 0: when armed until disarm (default)
  • 1: from boot until disarm
  • 2: from boot until shutdown
  • 3: depending on AUX1 RC channel

Reboot required: true

0
SDLOG_PROFILE (INT32) Logging topic profile (integer bitmask)

Comment: This integer bitmask controls the set and rates of logged topics. The default allows for general log analysis while keeping the log file size reasonably small. Enabling multiple sets leads to higher bandwidth requirements and larger log files. Set bits true to enable: 0 : Default set (used for general log analysis) 1 : Full rate estimator (EKF2) replay topics 2 : Topics for thermal calibration (high rate raw IMU and Baro sensor data) 3 : Topics for system identification (high rate actuator control and IMU data) 4 : Full rates for analysis of fast maneuvers (RC, attitude, rates and actuators) 5 : Debugging topics (debug_*.msg topics, for custom code) 6 : Topics for sensor comparison (low rate raw IMU, Baro and Magnetomer data) 7 : Topics for computer vision and collision avoidance 8 : Raw FIFO high-rate IMU (Gyro) 9 : Raw FIFO high-rate IMU (Accel)

Bitmask:
  • 0: Default set (general log analysis)
  • 1: Estimator replay (EKF2)
  • 2: Thermal calibration
  • 3: System identification
  • 4: High rate
  • 5: Debug
  • 6: Sensor comparison
  • 7: Computer Vision and Avoidance
  • 8: Raw FIFO high-rate IMU (Gyro)
  • 9: Raw FIFO high-rate IMU (Accel)

Reboot required: true

0 > 1023 1
SDLOG_UTC_OFFSET (INT32) UTC offset (unit: min)

Comment: the difference in hours and minutes from Coordinated Universal Time (UTC) for a your place and date. for example, In case of South Korea(UTC+09:00), UTC offset is 540 min (9*60) refer to https://en.wikipedia.org/wiki/List_of_UTC_time_offsets

-1000 > 1000 0 min
SDLOG_UUID (INT32) Log UUID

Comment: If set to 1, add an ID to the log, which uniquely identifies the vehicle

Enabled (1)

SITL

NameDescriptionMin > Max (Incr.)DefaultUnits
SIM_BAT_DRAIN (FLOAT) Simulator Battery drain interval 1 > 86400 (1) 60 s
SIM_BAT_MIN_PCT (FLOAT) Simulator Battery minimal percentage

Comment: Can be used to alter the battery level during SITL- or HITL-simulation on the fly. Particularly useful for testing different low-battery behaviour.

0 > 100 (0.1) 50.0 %

Sensor Calibration

NameDescriptionMin > Max (Incr.)DefaultUnits
CAL_ACC0_ID (INT32) ID of the Accelerometer that the calibration is for 0
CAL_ACC0_PRIO (INT32) Accelerometer 0 priority Values:
  • -1: Uninitialized
  • 0: Disabled
  • 1: Min
  • 25: Low
  • 50: Medium (Default)
  • 75: High
  • 100: Max
-1
CAL_ACC0_ROT (INT32) Rotation of accelerometer 0 relative to airframe

Comment: An internal sensor will force a value of -1, so a GCS should only attempt to configure the rotation if the value is greater than or equal to zero.

Values:
  • -1: Internal
  • 0: No rotation
  • 1: Yaw 45°
  • 2: Yaw 90°
  • 3: Yaw 135°
  • 4: Yaw 180°
  • 5: Yaw 225°
  • 6: Yaw 270°
  • 7: Yaw 315°
  • 8: Roll 180°
  • 9: Roll 180°, Yaw 45°
  • 10: Roll 180°, Yaw 90°
  • 11: Roll 180°, Yaw 135°
  • 12: Pitch 180°
  • 13: Roll 180°, Yaw 225°
  • 14: Roll 180°, Yaw 270°
  • 15: Roll 180°, Yaw 315°
  • 16: Roll 90°
  • 17: Roll 90°, Yaw 45°
  • 18: Roll 90°, Yaw 90°
  • 19: Roll 90°, Yaw 135°
  • 20: Roll 270°
  • 21: Roll 270°, Yaw 45°
  • 22: Roll 270°, Yaw 90°
  • 23: Roll 270°, Yaw 135°
  • 24: Pitch 90°
  • 25: Pitch 270°
  • 26: Pitch 180°, Yaw 90°
  • 27: Pitch 180°, Yaw 270°
  • 28: Roll 90°, Pitch 90°
  • 29: Roll 180°, Pitch 90°
  • 30: Roll 270°, Pitch 90°
  • 31: Roll 90°, Pitch 180°
  • 32: Roll 270°, Pitch 180°
  • 33: Roll 90°, Pitch 270°
  • 34: Roll 180°, Pitch 270°
  • 35: Roll 270°, Pitch 270°
  • 36: Roll 90°, Pitch 180°, Yaw 90°
  • 37: Roll 90°, Yaw 270°
  • 38: Roll 90°, Pitch 68°, Yaw 293°
  • 39: Pitch 315°
  • 40: Roll 90°, Pitch 315°

Reboot required: true

-1 > 40 -1
CAL_ACC0_TEMP (FLOAT) Accelerometer calibration temperature

Comment: Temperature during last calibration.

-1000. celcius
CAL_ACC0_XOFF (FLOAT) Accelerometer X-axis offset 0.0
CAL_ACC0_XSCALE (FLOAT) Accelerometer X-axis scaling factor 1.0
CAL_ACC0_YOFF (FLOAT) Accelerometer Y-axis offset 0.0
CAL_ACC0_YSCALE (FLOAT) Accelerometer Y-axis scaling factor 1.0
CAL_ACC0_ZOFF (FLOAT) Accelerometer Z-axis offset 0.0
CAL_ACC0_ZSCALE (FLOAT) Accelerometer Z-axis scaling factor 1.0
CAL_ACC1_ID (INT32) ID of the Accelerometer that the calibration is for 0
CAL_ACC1_PRIO (INT32) Accelerometer 1 priority Values:
  • -1: Uninitialized
  • 0: Disabled
  • 1: Min
  • 25: Low
  • 50: Medium (Default)
  • 75: High
  • 100: Max
-1
CAL_ACC1_ROT (INT32) Rotation of accelerometer 1 relative to airframe

Comment: An internal sensor will force a value of -1, so a GCS should only attempt to configure the rotation if the value is greater than or equal to zero.

Values:
  • -1: Internal
  • 0: No rotation
  • 1: Yaw 45°
  • 2: Yaw 90°
  • 3: Yaw 135°
  • 4: Yaw 180°
  • 5: Yaw 225°
  • 6: Yaw 270°
  • 7: Yaw 315°
  • 8: Roll 180°
  • 9: Roll 180°, Yaw 45°
  • 10: Roll 180°, Yaw 90°
  • 11: Roll 180°, Yaw 135°
  • 12: Pitch 180°
  • 13: Roll 180°, Yaw 225°
  • 14: Roll 180°, Yaw 270°
  • 15: Roll 180°, Yaw 315°
  • 16: Roll 90°
  • 17: Roll 90°, Yaw 45°
  • 18: Roll 90°, Yaw 90°
  • 19: Roll 90°, Yaw 135°
  • 20: Roll 270°
  • 21: Roll 270°, Yaw 45°
  • 22: Roll 270°, Yaw 90°
  • 23: Roll 270°, Yaw 135°
  • 24: Pitch 90°
  • 25: Pitch 270°
  • 26: Pitch 180°, Yaw 90°
  • 27: Pitch 180°, Yaw 270°
  • 28: Roll 90°, Pitch 90°
  • 29: Roll 180°, Pitch 90°
  • 30: Roll 270°, Pitch 90°
  • 31: Roll 90°, Pitch 180°
  • 32: Roll 270°, Pitch 180°
  • 33: Roll 90°, Pitch 270°
  • 34: Roll 180°, Pitch 270°
  • 35: Roll 270°, Pitch 270°
  • 36: Roll 90°, Pitch 180°, Yaw 90°
  • 37: Roll 90°, Yaw 270°
  • 38: Roll 90°, Pitch 68°, Yaw 293°
  • 39: Pitch 315°
  • 40: Roll 90°, Pitch 315°

Reboot required: true

-1 > 40 -1
CAL_ACC1_TEMP (FLOAT) Accelerometer calibration temperature

Comment: Temperature during last calibration.

-1000. celcius
CAL_ACC1_XOFF (FLOAT) Accelerometer X-axis offset 0.0
CAL_ACC1_XSCALE (FLOAT) Accelerometer X-axis scaling factor 1.0
CAL_ACC1_YOFF (FLOAT) Accelerometer Y-axis offset 0.0
CAL_ACC1_YSCALE (FLOAT) Accelerometer Y-axis scaling factor 1.0
CAL_ACC1_ZOFF (FLOAT) Accelerometer Z-axis offset 0.0
CAL_ACC1_ZSCALE (FLOAT) Accelerometer Z-axis scaling factor 1.0
CAL_ACC2_ID (INT32) ID of the Accelerometer that the calibration is for 0
CAL_ACC2_PRIO (INT32) Accelerometer 2 priority Values:
  • -1: Uninitialized
  • 0: Disabled
  • 1: Min
  • 25: Low
  • 50: Medium (Default)
  • 75: High
  • 100: Max
-1
CAL_ACC2_ROT (INT32) Rotation of accelerometer 2 relative to airframe

Comment: An internal sensor will force a value of -1, so a GCS should only attempt to configure the rotation if the value is greater than or equal to zero.

Values:
  • -1: Internal
  • 0: No rotation
  • 1: Yaw 45°
  • 2: Yaw 90°
  • 3: Yaw 135°
  • 4: Yaw 180°
  • 5: Yaw 225°
  • 6: Yaw 270°
  • 7: Yaw 315°
  • 8: Roll 180°
  • 9: Roll 180°, Yaw 45°
  • 10: Roll 180°, Yaw 90°
  • 11: Roll 180°, Yaw 135°
  • 12: Pitch 180°
  • 13: Roll 180°, Yaw 225°
  • 14: Roll 180°, Yaw 270°
  • 15: Roll 180°, Yaw 315°
  • 16: Roll 90°
  • 17: Roll 90°, Yaw 45°
  • 18: Roll 90°, Yaw 90°
  • 19: Roll 90°, Yaw 135°
  • 20: Roll 270°
  • 21: Roll 270°, Yaw 45°
  • 22: Roll 270°, Yaw 90°
  • 23: Roll 270°, Yaw 135°
  • 24: Pitch 90°
  • 25: Pitch 270°
  • 26: Pitch 180°, Yaw 90°
  • 27: Pitch 180°, Yaw 270°
  • 28: Roll 90°, Pitch 90°
  • 29: Roll 180°, Pitch 90°
  • 30: Roll 270°, Pitch 90°
  • 31: Roll 90°, Pitch 180°
  • 32: Roll 270°, Pitch 180°
  • 33: Roll 90°, Pitch 270°
  • 34: Roll 180°, Pitch 270°
  • 35: Roll 270°, Pitch 270°
  • 36: Roll 90°, Pitch 180°, Yaw 90°
  • 37: Roll 90°, Yaw 270°
  • 38: Roll 90°, Pitch 68°, Yaw 293°
  • 39: Pitch 315°
  • 40: Roll 90°, Pitch 315°

Reboot required: true

-1 > 40 -1
CAL_ACC2_TEMP (FLOAT) Accelerometer calibration temperature

Comment: Temperature during last calibration.

-1000. celcius
CAL_ACC2_XOFF (FLOAT) Accelerometer X-axis offset 0.0
CAL_ACC2_XSCALE (FLOAT) Accelerometer X-axis scaling factor 1.0
CAL_ACC2_YOFF (FLOAT) Accelerometer Y-axis offset 0.0
CAL_ACC2_YSCALE (FLOAT) Accelerometer Y-axis scaling factor 1.0
CAL_ACC2_ZOFF (FLOAT) Accelerometer Z-axis offset 0.0
CAL_ACC2_ZSCALE (FLOAT) Accelerometer Z-axis scaling factor 1.0
CAL_ACC3_ID (INT32) ID of the Accelerometer that the calibration is for 0
CAL_ACC3_PRIO (INT32) Accelerometer 3 priority Values:
  • -1: Uninitialized
  • 0: Disabled
  • 1: Min
  • 25: Low
  • 50: Medium (Default)
  • 75: High
  • 100: Max
-1
CAL_ACC3_ROT (INT32) Rotation of accelerometer 3 relative to airframe

Comment: An internal sensor will force a value of -1, so a GCS should only attempt to configure the rotation if the value is greater than or equal to zero.

Values:
  • -1: Internal
  • 0: No rotation
  • 1: Yaw 45°
  • 2: Yaw 90°
  • 3: Yaw 135°
  • 4: Yaw 180°
  • 5: Yaw 225°
  • 6: Yaw 270°
  • 7: Yaw 315°
  • 8: Roll 180°
  • 9: Roll 180°, Yaw 45°
  • 10: Roll 180°, Yaw 90°
  • 11: Roll 180°, Yaw 135°
  • 12: Pitch 180°
  • 13: Roll 180°, Yaw 225°
  • 14: Roll 180°, Yaw 270°
  • 15: Roll 180°, Yaw 315°
  • 16: Roll 90°
  • 17: Roll 90°, Yaw 45°
  • 18: Roll 90°, Yaw 90°
  • 19: Roll 90°, Yaw 135°
  • 20: Roll 270°
  • 21: Roll 270°, Yaw 45°
  • 22: Roll 270°, Yaw 90°
  • 23: Roll 270°, Yaw 135°
  • 24: Pitch 90°
  • 25: Pitch 270°
  • 26: Pitch 180°, Yaw 90°
  • 27: Pitch 180°, Yaw 270°
  • 28: Roll 90°, Pitch 90°
  • 29: Roll 180°, Pitch 90°
  • 30: Roll 270°, Pitch 90°
  • 31: Roll 90°, Pitch 180°
  • 32: Roll 270°, Pitch 180°
  • 33: Roll 90°, Pitch 270°
  • 34: Roll 180°, Pitch 270°
  • 35: Roll 270°, Pitch 270°
  • 36: Roll 90°, Pitch 180°, Yaw 90°
  • 37: Roll 90°, Yaw 270°
  • 38: Roll 90°, Pitch 68°, Yaw 293°
  • 39: Pitch 315°
  • 40: Roll 90°, Pitch 315°

Reboot required: true

-1 > 40 -1
CAL_ACC3_TEMP (FLOAT) Accelerometer calibration temperature

Comment: Temperature during last calibration.

-1000. celcius
CAL_ACC3_XOFF (FLOAT) Accelerometer X-axis offset 0.0
CAL_ACC3_XSCALE (FLOAT) Accelerometer X-axis scaling factor 1.0
CAL_ACC3_YOFF (FLOAT) Accelerometer Y-axis offset 0.0
CAL_ACC3_YSCALE (FLOAT) Accelerometer Y-axis scaling factor 1.0
CAL_ACC3_ZOFF (FLOAT) Accelerometer Z-axis offset 0.0
CAL_ACC3_ZSCALE (FLOAT) Accelerometer Z-axis scaling factor 1.0
CAL_GYRO0_ID (INT32) ID of the Gyro that the calibration is for 0
CAL_GYRO0_PRIO (INT32) Gyro 0 priority Values:
  • -1: Uninitialized
  • 0: Disabled
  • 1: Min
  • 25: Low
  • 50: Medium (Default)
  • 75: High
  • 100: Max
-1
CAL_GYRO0_ROT (INT32) Rotation of gyro 0 relative to airframe

Comment: An internal sensor will force a value of -1, so a GCS should only attempt to configure the rotation if the value is greater than or equal to zero.

Values:
  • -1: Internal
  • 0: No rotation
  • 1: Yaw 45°
  • 2: Yaw 90°
  • 3: Yaw 135°
  • 4: Yaw 180°
  • 5: Yaw 225°
  • 6: Yaw 270°
  • 7: Yaw 315°
  • 8: Roll 180°
  • 9: Roll 180°, Yaw 45°
  • 10: Roll 180°, Yaw 90°
  • 11: Roll 180°, Yaw 135°
  • 12: Pitch 180°
  • 13: Roll 180°, Yaw 225°
  • 14: Roll 180°, Yaw 270°
  • 15: Roll 180°, Yaw 315°
  • 16: Roll 90°
  • 17: Roll 90°, Yaw 45°
  • 18: Roll 90°, Yaw 90°
  • 19: Roll 90°, Yaw 135°
  • 20: Roll 270°
  • 21: Roll 270°, Yaw 45°
  • 22: Roll 270°, Yaw 90°
  • 23: Roll 270°, Yaw 135°
  • 24: Pitch 90°
  • 25: Pitch 270°
  • 26: Pitch 180°, Yaw 90°
  • 27: Pitch 180°, Yaw 270°
  • 28: Roll 90°, Pitch 90°
  • 29: Roll 180°, Pitch 90°
  • 30: Roll 270°, Pitch 90°
  • 31: Roll 90°, Pitch 180°
  • 32: Roll 270°, Pitch 180°
  • 33: Roll 90°, Pitch 270°
  • 34: Roll 180°, Pitch 270°
  • 35: Roll 270°, Pitch 270°
  • 36: Roll 90°, Pitch 180°, Yaw 90°
  • 37: Roll 90°, Yaw 270°
  • 38: Roll 90°, Pitch 68°, Yaw 293°
  • 39: Pitch 315°
  • 40: Roll 90°, Pitch 315°

Reboot required: true

-1 > 40 -1
CAL_GYRO0_TEMP (FLOAT) Gyroscope calibration temperature

Comment: Temperature during last calibration.

-1000. celcius
CAL_GYRO0_XOFF (FLOAT) Gyro X-axis offset 0.0
CAL_GYRO0_YOFF (FLOAT) Gyro Y-axis offset 0.0
CAL_GYRO0_ZOFF (FLOAT) Gyro Z-axis offset 0.0
CAL_GYRO1_ID (INT32) ID of the Gyro that the calibration is for 0
CAL_GYRO1_PRIO (INT32) Gyro 1 priority Values:
  • -1: Uninitialized
  • 0: Disabled
  • 1: Min
  • 25: Low
  • 50: Medium (Default)
  • 75: High
  • 100: Max
-1
CAL_GYRO1_ROT (INT32) Rotation of gyro 1 relative to airframe

Comment: An internal sensor will force a value of -1, so a GCS should only attempt to configure the rotation if the value is greater than or equal to zero.

Values:
  • -1: Internal
  • 0: No rotation
  • 1: Yaw 45°
  • 2: Yaw 90°
  • 3: Yaw 135°
  • 4: Yaw 180°
  • 5: Yaw 225°
  • 6: Yaw 270°
  • 7: Yaw 315°
  • 8: Roll 180°
  • 9: Roll 180°, Yaw 45°
  • 10: Roll 180°, Yaw 90°
  • 11: Roll 180°, Yaw 135°
  • 12: Pitch 180°
  • 13: Roll 180°, Yaw 225°
  • 14: Roll 180°, Yaw 270°
  • 15: Roll 180°, Yaw 315°
  • 16: Roll 90°
  • 17: Roll 90°, Yaw 45°
  • 18: Roll 90°, Yaw 90°
  • 19: Roll 90°, Yaw 135°
  • 20: Roll 270°
  • 21: Roll 270°, Yaw 45°
  • 22: Roll 270°, Yaw 90°
  • 23: Roll 270°, Yaw 135°
  • 24: Pitch 90°
  • 25: Pitch 270°
  • 26: Pitch 180°, Yaw 90°
  • 27: Pitch 180°, Yaw 270°
  • 28: Roll 90°, Pitch 90°
  • 29: Roll 180°, Pitch 90°
  • 30: Roll 270°, Pitch 90°
  • 31: Roll 90°, Pitch 180°
  • 32: Roll 270°, Pitch 180°
  • 33: Roll 90°, Pitch 270°
  • 34: Roll 180°, Pitch 270°
  • 35: Roll 270°, Pitch 270°
  • 36: Roll 90°, Pitch 180°, Yaw 90°
  • 37: Roll 90°, Yaw 270°
  • 38: Roll 90°, Pitch 68°, Yaw 293°
  • 39: Pitch 315°
  • 40: Roll 90°, Pitch 315°

Reboot required: true

-1 > 40 -1
CAL_GYRO1_TEMP (FLOAT) Gyroscope calibration temperature

Comment: Temperature during last calibration.

-1000. celcius
CAL_GYRO1_XOFF (FLOAT) Gyro X-axis offset 0.0
CAL_GYRO1_YOFF (FLOAT) Gyro Y-axis offset 0.0
CAL_GYRO1_ZOFF (FLOAT) Gyro Z-axis offset 0.0
CAL_GYRO2_ID (INT32) ID of the Gyro that the calibration is for 0
CAL_GYRO2_PRIO (INT32) Gyro 2 priority Values:
  • -1: Uninitialized
  • 0: Disabled
  • 1: Min
  • 25: Low
  • 50: Medium (Default)
  • 75: High
  • 100: Max
-1
CAL_GYRO2_ROT (INT32) Rotation of gyro 2 relative to airframe

Comment: An internal sensor will force a value of -1, so a GCS should only attempt to configure the rotation if the value is greater than or equal to zero.

Values:
  • -1: Internal
  • 0: No rotation
  • 1: Yaw 45°
  • 2: Yaw 90°
  • 3: Yaw 135°
  • 4: Yaw 180°
  • 5: Yaw 225°
  • 6: Yaw 270°
  • 7: Yaw 315°
  • 8: Roll 180°
  • 9: Roll 180°, Yaw 45°
  • 10: Roll 180°, Yaw 90°
  • 11: Roll 180°, Yaw 135°
  • 12: Pitch 180°
  • 13: Roll 180°, Yaw 225°
  • 14: Roll 180°, Yaw 270°
  • 15: Roll 180°, Yaw 315°
  • 16: Roll 90°
  • 17: Roll 90°, Yaw 45°
  • 18: Roll 90°, Yaw 90°
  • 19: Roll 90°, Yaw 135°
  • 20: Roll 270°
  • 21: Roll 270°, Yaw 45°
  • 22: Roll 270°, Yaw 90°
  • 23: Roll 270°, Yaw 135°
  • 24: Pitch 90°
  • 25: Pitch 270°
  • 26: Pitch 180°, Yaw 90°
  • 27: Pitch 180°, Yaw 270°
  • 28: Roll 90°, Pitch 90°
  • 29: Roll 180°, Pitch 90°
  • 30: Roll 270°, Pitch 90°
  • 31: Roll 90°, Pitch 180°
  • 32: Roll 270°, Pitch 180°
  • 33: Roll 90°, Pitch 270°
  • 34: Roll 180°, Pitch 270°
  • 35: Roll 270°, Pitch 270°
  • 36: Roll 90°, Pitch 180°, Yaw 90°
  • 37: Roll 90°, Yaw 270°
  • 38: Roll 90°, Pitch 68°, Yaw 293°
  • 39: Pitch 315°
  • 40: Roll 90°, Pitch 315°

Reboot required: true

-1 > 40 -1
CAL_GYRO2_TEMP (FLOAT) Gyroscope calibration temperature

Comment: Temperature during last calibration.

-1000. celcius
CAL_GYRO2_XOFF (FLOAT) Gyro X-axis offset 0.0
CAL_GYRO2_YOFF (FLOAT) Gyro Y-axis offset 0.0
CAL_GYRO2_ZOFF (FLOAT) Gyro Z-axis offset 0.0
CAL_GYRO3_ID (INT32) ID of the Gyro that the calibration is for 0
CAL_GYRO3_PRIO (INT32) Gyro 3 priority Values:
  • -1: Uninitialized
  • 0: Disabled
  • 1: Min
  • 25: Low
  • 50: Medium (Default)
  • 75: High
  • 100: Max
-1
CAL_GYRO3_ROT (INT32) Rotation of gyro 3 relative to airframe

Comment: An internal sensor will force a value of -1, so a GCS should only attempt to configure the rotation if the value is greater than or equal to zero.

Values:
  • -1: Internal
  • 0: No rotation
  • 1: Yaw 45°
  • 2: Yaw 90°
  • 3: Yaw 135°
  • 4: Yaw 180°
  • 5: Yaw 225°
  • 6: Yaw 270°
  • 7: Yaw 315°
  • 8: Roll 180°
  • 9: Roll 180°, Yaw 45°
  • 10: Roll 180°, Yaw 90°
  • 11: Roll 180°, Yaw 135°
  • 12: Pitch 180°
  • 13: Roll 180°, Yaw 225°
  • 14: Roll 180°, Yaw 270°
  • 15: Roll 180°, Yaw 315°
  • 16: Roll 90°
  • 17: Roll 90°, Yaw 45°
  • 18: Roll 90°, Yaw 90°
  • 19: Roll 90°, Yaw 135°
  • 20: Roll 270°
  • 21: Roll 270°, Yaw 45°
  • 22: Roll 270°, Yaw 90°
  • 23: Roll 270°, Yaw 135°
  • 24: Pitch 90°
  • 25: Pitch 270°
  • 26: Pitch 180°, Yaw 90°
  • 27: Pitch 180°, Yaw 270°
  • 28: Roll 90°, Pitch 90°
  • 29: Roll 180°, Pitch 90°
  • 30: Roll 270°, Pitch 90°
  • 31: Roll 90°, Pitch 180°
  • 32: Roll 270°, Pitch 180°
  • 33: Roll 90°, Pitch 270°
  • 34: Roll 180°, Pitch 270°
  • 35: Roll 270°, Pitch 270°
  • 36: Roll 90°, Pitch 180°, Yaw 90°
  • 37: Roll 90°, Yaw 270°
  • 38: Roll 90°, Pitch 68°, Yaw 293°
  • 39: Pitch 315°
  • 40: Roll 90°, Pitch 315°

Reboot required: true

-1 > 40 -1
CAL_GYRO3_TEMP (FLOAT) Gyroscope calibration temperature

Comment: Temperature during last calibration.

-1000. celcius
CAL_GYRO3_XOFF (FLOAT) Gyro X-axis offset 0.0
CAL_GYRO3_YOFF (FLOAT) Gyro Y-axis offset 0.0
CAL_GYRO3_ZOFF (FLOAT) Gyro Z-axis offset 0.0
CAL_MAG0_ID (INT32) ID of Magnetometer the calibration is for 0
CAL_MAG0_PRIO (INT32) Mag 0 priority Values:
  • -1: Uninitialized
  • 0: Disabled
  • 1: Min
  • 25: Low
  • 50: Medium (Default)
  • 75: High
  • 100: Max
-1
CAL_MAG0_ROT (INT32) Rotation of magnetometer 0 relative to airframe

Comment: An internal sensor will force a value of -1, so a GCS should only attempt to configure the rotation if the value is greater than or equal to zero.

Values:
  • -1: Internal
  • 0: No rotation
  • 1: Yaw 45°
  • 2: Yaw 90°
  • 3: Yaw 135°
  • 4: Yaw 180°
  • 5: Yaw 225°
  • 6: Yaw 270°
  • 7: Yaw 315°
  • 8: Roll 180°
  • 9: Roll 180°, Yaw 45°
  • 10: Roll 180°, Yaw 90°
  • 11: Roll 180°, Yaw 135°
  • 12: Pitch 180°
  • 13: Roll 180°, Yaw 225°
  • 14: Roll 180°, Yaw 270°
  • 15: Roll 180°, Yaw 315°
  • 16: Roll 90°
  • 17: Roll 90°, Yaw 45°
  • 18: Roll 90°, Yaw 90°
  • 19: Roll 90°, Yaw 135°
  • 20: Roll 270°
  • 21: Roll 270°, Yaw 45°
  • 22: Roll 270°, Yaw 90°
  • 23: Roll 270°, Yaw 135°
  • 24: Pitch 90°
  • 25: Pitch 270°
  • 26: Pitch 180°, Yaw 90°
  • 27: Pitch 180°, Yaw 270°
  • 28: Roll 90°, Pitch 90°
  • 29: Roll 180°, Pitch 90°
  • 30: Roll 270°, Pitch 90°
  • 31: Roll 90°, Pitch 180°
  • 32: Roll 270°, Pitch 180°
  • 33: Roll 90°, Pitch 270°
  • 34: Roll 180°, Pitch 270°
  • 35: Roll 270°, Pitch 270°
  • 36: Roll 90°, Pitch 180°, Yaw 90°
  • 37: Roll 90°, Yaw 270°
  • 38: Roll 90°, Pitch 68°, Yaw 293°
  • 39: Pitch 315°
  • 40: Roll 90°, Pitch 315°

Reboot required: true

-1 > 40 -1
CAL_MAG0_TEMP (FLOAT) Magnetometer calibration temperature

Comment: Temperature during last calibration.

-1000. celcius
CAL_MAG0_XCOMP (FLOAT) X Axis throttle compensation for Mag 0

Comment: Coefficient describing linear relationship between X component of magnetometer in body frame axis and either current or throttle depending on value of CAL_MAG_COMP_TYP. Unit for throttle-based compensation is [G] and for current-based compensation [G/kA]

0.0
CAL_MAG0_XODIAG (FLOAT) Magnetometer X-axis off diagonal factor 0.0
CAL_MAG0_XOFF (FLOAT) Magnetometer X-axis offset 0.0
CAL_MAG0_XSCALE (FLOAT) Magnetometer X-axis scaling factor 1.0
CAL_MAG0_YCOMP (FLOAT) Y Axis throttle compensation for Mag 0

Comment: Coefficient describing linear relationship between Y component of magnetometer in body frame axis and either current or throttle depending on value of CAL_MAG_COMP_TYP. Unit for throttle-based compensation is [G] and for current-based compensation [G/kA]

0.0
CAL_MAG0_YODIAG (FLOAT) Magnetometer Y-axis off diagonal factor 0.0
CAL_MAG0_YOFF (FLOAT) Magnetometer Y-axis offset 0.0
CAL_MAG0_YSCALE (FLOAT) Magnetometer Y-axis scaling factor 1.0
CAL_MAG0_ZCOMP (FLOAT) Z Axis throttle compensation for Mag 0

Comment: Coefficient describing linear relationship between Z component of magnetometer in body frame axis and either current or throttle depending on value of CAL_MAG_COMP_TYP. Unit for throttle-based compensation is [G] and for current-based compensation [G/kA]

0.0
CAL_MAG0_ZODIAG (FLOAT) Magnetometer Z-axis off diagonal factor 0.0
CAL_MAG0_ZOFF (FLOAT) Magnetometer Z-axis offset 0.0
CAL_MAG0_ZSCALE (FLOAT) Magnetometer Z-axis scaling factor 1.0
CAL_MAG1_ID (INT32) ID of Magnetometer the calibration is for 0
CAL_MAG1_PRIO (INT32) Mag 1 priority Values:
  • -1: Uninitialized
  • 0: Disabled
  • 1: Min
  • 25: Low
  • 50: Medium (Default)
  • 75: High
  • 100: Max
-1
CAL_MAG1_ROT (INT32) Rotation of magnetometer 1 relative to airframe

Comment: An internal sensor will force a value of -1, so a GCS should only attempt to configure the rotation if the value is greater than or equal to zero.

Values:
  • -1: Internal
  • 0: No rotation
  • 1: Yaw 45°
  • 2: Yaw 90°
  • 3: Yaw 135°
  • 4: Yaw 180°
  • 5: Yaw 225°
  • 6: Yaw 270°
  • 7: Yaw 315°
  • 8: Roll 180°
  • 9: Roll 180°, Yaw 45°
  • 10: Roll 180°, Yaw 90°
  • 11: Roll 180°, Yaw 135°
  • 12: Pitch 180°
  • 13: Roll 180°, Yaw 225°
  • 14: Roll 180°, Yaw 270°
  • 15: Roll 180°, Yaw 315°
  • 16: Roll 90°
  • 17: Roll 90°, Yaw 45°
  • 18: Roll 90°, Yaw 90°
  • 19: Roll 90°, Yaw 135°
  • 20: Roll 270°
  • 21: Roll 270°, Yaw 45°
  • 22: Roll 270°, Yaw 90°
  • 23: Roll 270°, Yaw 135°
  • 24: Pitch 90°
  • 25: Pitch 270°
  • 26: Pitch 180°, Yaw 90°
  • 27: Pitch 180°, Yaw 270°
  • 28: Roll 90°, Pitch 90°
  • 29: Roll 180°, Pitch 90°
  • 30: Roll 270°, Pitch 90°
  • 31: Roll 90°, Pitch 180°
  • 32: Roll 270°, Pitch 180°
  • 33: Roll 90°, Pitch 270°
  • 34: Roll 180°, Pitch 270°
  • 35: Roll 270°, Pitch 270°
  • 36: Roll 90°, Pitch 180°, Yaw 90°
  • 37: Roll 90°, Yaw 270°
  • 38: Roll 90°, Pitch 68°, Yaw 293°
  • 39: Pitch 315°
  • 40: Roll 90°, Pitch 315°

Reboot required: true

-1 > 40 -1
CAL_MAG1_TEMP (FLOAT) Magnetometer calibration temperature

Comment: Temperature during last calibration.

-1000. celcius
CAL_MAG1_XCOMP (FLOAT) X Axis throttle compensation for Mag 1

Comment: Coefficient describing linear relationship between X component of magnetometer in body frame axis and either current or throttle depending on value of CAL_MAG_COMP_TYP. Unit for throttle-based compensation is [G] and for current-based compensation [G/kA]

0.0
CAL_MAG1_XODIAG (FLOAT) Magnetometer X-axis off diagonal factor 0.0
CAL_MAG1_XOFF (FLOAT) Magnetometer X-axis offset 0.0
CAL_MAG1_XSCALE (FLOAT) Magnetometer X-axis scaling factor 1.0
CAL_MAG1_YCOMP (FLOAT) Y Axis throttle compensation for Mag 1

Comment: Coefficient describing linear relationship between Y component of magnetometer in body frame axis and either current or throttle depending on value of CAL_MAG_COMP_TYP. Unit for throttle-based compensation is [G] and for current-based compensation [G/kA]

0.0
CAL_MAG1_YODIAG (FLOAT) Magnetometer Y-axis off diagonal factor 0.0
CAL_MAG1_YOFF (FLOAT) Magnetometer Y-axis offset 0.0
CAL_MAG1_YSCALE (FLOAT) Magnetometer Y-axis scaling factor 1.0
CAL_MAG1_ZCOMP (FLOAT) Z Axis throttle compensation for Mag 1

Comment: Coefficient describing linear relationship between Z component of magnetometer in body frame axis and either current or throttle depending on value of CAL_MAG_COMP_TYP. Unit for throttle-based compensation is [G] and for current-based compensation [G/kA]

0.0
CAL_MAG1_ZODIAG (FLOAT) Magnetometer Z-axis off diagonal factor 0.0
CAL_MAG1_ZOFF (FLOAT) Magnetometer Z-axis offset 0.0
CAL_MAG1_ZSCALE (FLOAT) Magnetometer Z-axis scaling factor 1.0
CAL_MAG2_ID (INT32) ID of Magnetometer the calibration is for 0
CAL_MAG2_PRIO (INT32) Mag 2 priority Values:
  • -1: Uninitialized
  • 0: Disabled
  • 1: Min
  • 25: Low
  • 50: Medium (Default)
  • 75: High
  • 100: Max
-1
CAL_MAG2_ROT (INT32) Rotation of magnetometer 2 relative to airframe

Comment: An internal sensor will force a value of -1, so a GCS should only attempt to configure the rotation if the value is greater than or equal to zero.

Values:
  • -1: Internal
  • 0: No rotation
  • 1: Yaw 45°
  • 2: Yaw 90°
  • 3: Yaw 135°
  • 4: Yaw 180°
  • 5: Yaw 225°
  • 6: Yaw 270°
  • 7: Yaw 315°
  • 8: Roll 180°
  • 9: Roll 180°, Yaw 45°
  • 10: Roll 180°, Yaw 90°
  • 11: Roll 180°, Yaw 135°
  • 12: Pitch 180°
  • 13: Roll 180°, Yaw 225°
  • 14: Roll 180°, Yaw 270°
  • 15: Roll 180°, Yaw 315°
  • 16: Roll 90°
  • 17: Roll 90°, Yaw 45°
  • 18: Roll 90°, Yaw 90°
  • 19: Roll 90°, Yaw 135°
  • 20: Roll 270°
  • 21: Roll 270°, Yaw 45°
  • 22: Roll 270°, Yaw 90°
  • 23: Roll 270°, Yaw 135°
  • 24: Pitch 90°
  • 25: Pitch 270°
  • 26: Pitch 180°, Yaw 90°
  • 27: Pitch 180°, Yaw 270°
  • 28: Roll 90°, Pitch 90°
  • 29: Roll 180°, Pitch 90°
  • 30: Roll 270°, Pitch 90°
  • 31: Roll 90°, Pitch 180°
  • 32: Roll 270°, Pitch 180°
  • 33: Roll 90°, Pitch 270°
  • 34: Roll 180°, Pitch 270°
  • 35: Roll 270°, Pitch 270°
  • 36: Roll 90°, Pitch 180°, Yaw 90°
  • 37: Roll 90°, Yaw 270°
  • 38: Roll 90°, Pitch 68°, Yaw 293°
  • 39: Pitch 315°
  • 40: Roll 90°, Pitch 315°

Reboot required: true

-1 > 40 -1
CAL_MAG2_TEMP (FLOAT) Magnetometer calibration temperature

Comment: Temperature during last calibration.

-1000. celcius
CAL_MAG2_XCOMP (FLOAT) X Axis throttle compensation for Mag 2

Comment: Coefficient describing linear relationship between X component of magnetometer in body frame axis and either current or throttle depending on value of CAL_MAG_COMP_TYP. Unit for throttle-based compensation is [G] and for current-based compensation [G/kA]

0.0
CAL_MAG2_XODIAG (FLOAT) Magnetometer X-axis off diagonal factor 0.0
CAL_MAG2_XOFF (FLOAT) Magnetometer X-axis offset 0.0
CAL_MAG2_XSCALE (FLOAT) Magnetometer X-axis scaling factor 1.0
CAL_MAG2_YCOMP (FLOAT) Y Axis throttle compensation for Mag 2

Comment: Coefficient describing linear relationship between Y component of magnetometer in body frame axis and either current or throttle depending on value of CAL_MAG_COMP_TYP. Unit for throttle-based compensation is [G] and for current-based compensation [G/kA]

0.0
CAL_MAG2_YODIAG (FLOAT) Magnetometer Y-axis off diagonal factor 0.0
CAL_MAG2_YOFF (FLOAT) Magnetometer Y-axis offset 0.0
CAL_MAG2_YSCALE (FLOAT) Magnetometer Y-axis scaling factor 1.0
CAL_MAG2_ZCOMP (FLOAT) Z Axis throttle compensation for Mag 2

Comment: Coefficient describing linear relationship between Z component of magnetometer in body frame axis and either current or throttle depending on value of CAL_MAG_COMP_TYP. Unit for throttle-based compensation is [G] and for current-based compensation [G/kA]

0.0
CAL_MAG2_ZODIAG (FLOAT) Magnetometer Z-axis off diagonal factor 0.0
CAL_MAG2_ZOFF (FLOAT) Magnetometer Z-axis offset 0.0
CAL_MAG2_ZSCALE (FLOAT) Magnetometer Z-axis scaling factor 1.0
CAL_MAG3_ID (INT32) ID of Magnetometer the calibration is for 0
CAL_MAG3_PRIO (INT32) Mag 3 priority Values:
  • -1: Uninitialized
  • 0: Disabled
  • 1: Min
  • 25: Low
  • 50: Medium (Default)
  • 75: High
  • 100: Max
-1
CAL_MAG3_ROT (INT32) Rotation of magnetometer 3 relative to airframe

Comment: An internal sensor will force a value of -1, so a GCS should only attempt to configure the rotation if the value is greater than or equal to zero.

Values:
  • -1: Internal
  • 0: No rotation
  • 1: Yaw 45°
  • 2: Yaw 90°
  • 3: Yaw 135°
  • 4: Yaw 180°
  • 5: Yaw 225°
  • 6: Yaw 270°
  • 7: Yaw 315°
  • 8: Roll 180°
  • 9: Roll 180°, Yaw 45°
  • 10: Roll 180°, Yaw 90°
  • 11: Roll 180°, Yaw 135°
  • 12: Pitch 180°
  • 13: Roll 180°, Yaw 225°
  • 14: Roll 180°, Yaw 270°
  • 15: Roll 180°, Yaw 315°
  • 16: Roll 90°
  • 17: Roll 90°, Yaw 45°
  • 18: Roll 90°, Yaw 90°
  • 19: Roll 90°, Yaw 135°
  • 20: Roll 270°
  • 21: Roll 270°, Yaw 45°
  • 22: Roll 270°, Yaw 90°
  • 23: Roll 270°, Yaw 135°
  • 24: Pitch 90°
  • 25: Pitch 270°
  • 26: Pitch 180°, Yaw 90°
  • 27: Pitch 180°, Yaw 270°
  • 28: Roll 90°, Pitch 90°
  • 29: Roll 180°, Pitch 90°
  • 30: Roll 270°, Pitch 90°
  • 31: Roll 90°, Pitch 180°
  • 32: Roll 270°, Pitch 180°
  • 33: Roll 90°, Pitch 270°
  • 34: Roll 180°, Pitch 270°
  • 35: Roll 270°, Pitch 270°
  • 36: Roll 90°, Pitch 180°, Yaw 90°
  • 37: Roll 90°, Yaw 270°
  • 38: Roll 90°, Pitch 68°, Yaw 293°
  • 39: Pitch 315°
  • 40: Roll 90°, Pitch 315°

Reboot required: true

-1 > 40 -1
CAL_MAG3_TEMP (FLOAT) Magnetometer calibration temperature

Comment: Temperature during last calibration.

-1000. celcius
CAL_MAG3_XCOMP (FLOAT) X Axis throttle compensation for Mag 3

Comment: Coefficient describing linear relationship between X component of magnetometer in body frame axis and either current or throttle depending on value of CAL_MAG_COMP_TYP. Unit for throttle-based compensation is [G] and for current-based compensation [G/kA]

0.0
CAL_MAG3_XODIAG (FLOAT) Magnetometer X-axis off diagonal factor 0.0
CAL_MAG3_XOFF (FLOAT) Magnetometer X-axis offset 0.0
CAL_MAG3_XSCALE (FLOAT) Magnetometer X-axis scaling factor 1.0
CAL_MAG3_YCOMP (FLOAT) Y Axis throttle compensation for Mag 3

Comment: Coefficient describing linear relationship between Y component of magnetometer in body frame axis and either current or throttle depending on value of CAL_MAG_COMP_TYP. Unit for throttle-based compensation is [G] and for current-based compensation [G/kA]

0.0
CAL_MAG3_YODIAG (FLOAT) Magnetometer Y-axis off diagonal factor 0.0
CAL_MAG3_YOFF (FLOAT) Magnetometer Y-axis offset 0.0
CAL_MAG3_YSCALE (FLOAT) Magnetometer Y-axis scaling factor 1.0
CAL_MAG3_ZCOMP (FLOAT) Z Axis throttle compensation for Mag 3

Comment: Coefficient describing linear relationship between Z component of magnetometer in body frame axis and either current or throttle depending on value of CAL_MAG_COMP_TYP. Unit for throttle-based compensation is [G] and for current-based compensation [G/kA]

0.0
CAL_MAG3_ZODIAG (FLOAT) Magnetometer Z-axis off diagonal factor 0.0
CAL_MAG3_ZOFF (FLOAT) Magnetometer Z-axis offset 0.0
CAL_MAG3_ZSCALE (FLOAT) Magnetometer Z-axis scaling factor 1.0
CAL_MAG_COMP_TYP (INT32) Type of magnetometer compensation Values:
  • 0: Disabled
  • 1: Throttle-based compensation
  • 2: Current-based compensation (battery_status instance 0)
  • 3: Current-based compensation (battery_status instance 1)
0
SENS_DPRES_ANSC (FLOAT) Differential pressure sensor analog scaling

Comment: Pick the appropriate scaling from the datasheet. this number defines the (linear) conversion from voltage to Pascal (pa). For the MPXV7002DP this is 1000. NOTE: If the sensor always registers zero, try switching the static and dynamic tubes.

0
SENS_DPRES_OFF (FLOAT) Differential pressure sensor offset

Comment: The offset (zero-reading) in Pascal

0.0
SENS_FLOW_MAXHGT (FLOAT) Maximum height above ground when reliant on optical flow

Comment: This parameter defines the maximum distance from ground at which the optical flow sensor operates reliably. The height setpoint will be limited to be no greater than this value when the navigation system is completely reliant on optical flow data and the height above ground estimate is valid. The sensor may be usable above this height, but accuracy will progressively degrade.

1.0 > 25.0 (0.1) 3.0 m
SENS_FLOW_MAXR (FLOAT) Magnitude of maximum angular flow rate reliably measurable by the optical flow sensor

Comment: Optical flow data will not fused by the estimators if the magnitude of the flow rate exceeds this value and control loops will be instructed to limit ground speed such that the flow rate produced by movement over ground is less than 50% of this value.

1.0 > ? 2.5 rad/s
SENS_FLOW_MINHGT (FLOAT) Minimum height above ground when reliant on optical flow

Comment: This parameter defines the minimum distance from ground at which the optical flow sensor operates reliably. The sensor may be usable below this height, but accuracy will progressively reduce to loss of focus.

0.0 > 1.0 (0.1) 0.7 m

Sensors

NameDescriptionMin > Max (Incr.)DefaultUnits
BAT1_C_MULT (FLOAT) Capacity/current multiplier for high-current capable SMBUS battery

Reboot required: true

1.0
BAT1_SMBUS_MODEL (INT32) Battery device model Values:
  • 0: AutoDetect
  • 1: BQ40Z50 based
  • 2: BQ40Z80 based

Reboot required: true

0 > 2 0
BATMON_ADDR_DFLT (INT32) I2C address for BatMon battery 1

Reboot required: true

11
BATMON_DRIVER_EN (INT32) Parameter to enable BatMon module Values:
  • 0: Disabled
  • 1: Start on default I2C addr(BATMON_ADDR_DFLT)
  • 2: Autodetect I2C address (TODO)

Reboot required: true

0 > 2 0
CAL_AIR_CMODEL (INT32) Airspeed sensor compensation model for the SDP3x

Comment: Model with Pitot CAL_AIR_TUBED_MM: Not used, 1.5 mm tubes assumed. CAL_AIR_TUBELEN: Length of the tubes connecting the pitot to the sensor. Model without Pitot (1.5 mm tubes) CAL_AIR_TUBED_MM: Not used, 1.5 mm tubes assumed. CAL_AIR_TUBELEN: Length of the tubes connecting the pitot to the sensor. Tube Pressure Drop CAL_AIR_TUBED_MM: Diameter in mm of the pitot and tubes, must have the same diameter. CAL_AIR_TUBELEN: Length of the tubes connecting the pitot to the sensor and the static + dynamic port length of the pitot.

Values:
  • 0: Model with Pitot
  • 1: Model without Pitot (1.5 mm tubes)
  • 2: Tube Pressure Drop
0
CAL_AIR_TUBED_MM (FLOAT) Airspeed sensor tube diameter. Only used for the Tube Pressure Drop Compensation 1.5 > 100 1.5 mm
CAL_AIR_TUBELEN (FLOAT) Airspeed sensor tube length

Comment: See the CAL_AIR_CMODEL explanation on how this parameter should be set.

0.01 > 2.00 0.2 m
CAL_MAG_ROT_AUTO (INT32) Automatically set external rotations

Comment: During calibration attempt to automatically determine the rotation of external magnetometers.

Enabled (1)
CAL_MAG_SIDES (INT32) Bitfield selecting mag sides for calibration

Comment: If set to two side calibration, only the offsets are estimated, the scale calibration is left unchanged. Thus an initial six side calibration is recommended. Bits: ORIENTATION_TAIL_DOWN = 1 ORIENTATION_NOSE_DOWN = 2 ORIENTATION_LEFT = 4 ORIENTATION_RIGHT = 8 ORIENTATION_UPSIDE_DOWN = 16 ORIENTATION_RIGHTSIDE_UP = 32

Values:
  • 34: Two side calibration
  • 38: Three side calibration
  • 63: Six side calibration
34 > 63 63
IMU_ACCEL_CUTOFF (FLOAT) Low pass filter cutoff frequency for accel

Comment: The cutoff frequency for the 2nd order butterworth filter on the primary accelerometer. This only affects the signal sent to the controllers, not the estimators. 0 disables the filter.

Reboot required: true

0 > 1000 30.0 Hz
IMU_DGYRO_CUTOFF (FLOAT) Cutoff frequency for angular acceleration (D-Term filter)

Comment: The cutoff frequency for the 2nd order butterworth filter used on the time derivative of the measured angular velocity, also known as the D-term filter in the rate controller. The D-term uses the derivative of the rate and thus is the most susceptible to noise. Therefore, using a D-term filter allows to increase IMU_GYRO_CUTOFF, which leads to reduced control latency and permits to increase the P gains. A value of 0 disables the filter.

Reboot required: true

0 > 1000 30.0 Hz
IMU_GYRO_CAL_EN (INT32) IMU gyro auto calibration enable

Reboot required: true

Enabled (1)
IMU_GYRO_CUTOFF (FLOAT) Low pass filter cutoff frequency for gyro

Comment: The cutoff frequency for the 2nd order butterworth filter on the primary gyro. This only affects the angular velocity sent to the controllers, not the estimators. It applies also to the angular acceleration (D-Term filter), see IMU_DGYRO_CUTOFF. A value of 0 disables the filter.

Reboot required: true

0 > 1000 40.0 Hz
IMU_GYRO_DYN_NF (INT32) IMU gyro dynamic notch filtering

Comment: Enable bank of dynamically updating notch filters. Requires ESC RPM feedback or onboard FFT (IMU_GYRO_FFT_EN).

Bitmask:
  • 0: ESC RPM
  • 1: FFT
0 > 3 0
IMU_GYRO_FFT_EN (INT32) IMU gyro FFT enable

Reboot required: true

Disabled (0)
IMU_GYRO_FFT_LEN (INT32) IMU gyro FFT length Values:
  • 256: 256
  • 512: 512
  • 1024: 1024
  • 4096: 4096

Reboot required: true

512 Hz
IMU_GYRO_FFT_MAX (FLOAT) IMU gyro FFT maximum frequency

Reboot required: true

1 > 1000 192. Hz
IMU_GYRO_FFT_MIN (FLOAT) IMU gyro FFT minimum frequency

Reboot required: true

1 > 1000 32. Hz
IMU_GYRO_NF_BW (FLOAT) Notch filter bandwidth for gyro

Comment: The frequency width of the stop band for the 2nd order notch filter on the primary gyro. See "IMU_GYRO_NF_FREQ" to activate the filter and to set the notch frequency. Applies to both angular velocity and angular acceleration sent to the controllers.

Reboot required: true

0 > 100 20.0 Hz
IMU_GYRO_NF_FREQ (FLOAT) Notch filter frequency for gyro

Comment: The center frequency for the 2nd order notch filter on the primary gyro. This filter can be enabled to avoid feedback amplification of structural resonances at a specific frequency. This only affects the signal sent to the controllers, not the estimators. Applies to both angular velocity and angular acceleration sent to the controllers. See "IMU_GYRO_NF_BW" to set the bandwidth of the filter. A value of 0 disables the filter.

Reboot required: true

0 > 1000 0.0 Hz
IMU_GYRO_RATEMAX (INT32) Gyro control data maximum publication rate (inner loop rate)

Comment: The maximum rate the gyro control data (vehicle_angular_velocity) will be allowed to publish at. This is the loop rate for the rate controller and outputs. Note: sensor data is always read and filtered at the full raw rate (eg commonly 8 kHz) regardless of this setting.

Values:
  • 100: 100 Hz
  • 250: 250 Hz
  • 400: 400 Hz
  • 800: 800 Hz
  • 1000: 1000 Hz
  • 2000: 2000 Hz

Reboot required: true

100 > 2000 400 Hz
IMU_INTEG_RATE (INT32) IMU integration rate

Comment: The rate at which raw IMU data is integrated to produce delta angles and delta velocities. Recommended to set this to a multiple of the estimator update period (currently 10 ms for ekf2).

Values:
  • 100: 100 Hz
  • 200: 200 Hz
  • 250: 250 Hz
  • 400: 400 Hz

Reboot required: true

100 > 1000 200 Hz
INA226_CONFIG (INT32) INA226 Power Monitor Config 0 > 65535 (1) 18139
INA226_CURRENT (FLOAT) INA226 Power Monitor Max Current 0.1 > 200.0 (0.1) 164.0
INA226_SHUNT (FLOAT) INA226 Power Monitor Shunt 0.000000001 > 0.1 (.000000001) 0.0005
INA228_CONFIG (INT32) INA228 Power Monitor Config 0 > 65535 (1) 63779
INA228_CURRENT (FLOAT) INA228 Power Monitor Max Current 0.1 > 327.68 (0.1) 327.68
INA228_SHUNT (FLOAT) INA228 Power Monitor Shunt 0.000000001 > 0.1 (.000000001) 0.0005
PCF8583_ADDR (INT32) PCF8583 rotorfreq (i2c) i2c address Values:
  • 80: Address 0x50 (80)
  • 81: Address 0x51 (81)

Reboot required: true

80
PCF8583_MAGNET (INT32) PCF8583 rotorfreq (i2c) pulse count

Comment: Nmumber of signals per rotation of actuator

Reboot required: true

1 > ? 2
PCF8583_POOL (INT32) PCF8583 rotorfreq (i2c) pool interval

Comment: Determines how often the sensor is read out.

Reboot required: true

1000000 us
PCF8583_RESET (INT32) PCF8583 rotorfreq (i2c) pulse reset value

Comment: Internal device counter is reset to 0 when overun this value, counter is able to store upto 6 digits reset of counter takes some time - measurement with reset has worse accurancy. 0 means reset counter after every measurement.

Reboot required: true

500000
SENS_BARO_QNH (FLOAT) QNH for barometer

Reboot required: true

500 > 1500 1013.25 hPa
SENS_BARO_RATE (FLOAT) Baro max rate

Comment: Barometric air data maximum publication rate. This is an upper bound, actual barometric data rate is still dependant on the sensor.

Reboot required: true

1 > 200 20.0 Hz
SENS_BOARD_ROT (INT32) Board rotation

Comment: This parameter defines the rotation of the FMU board relative to the platform.

Values:
  • 0: No rotation
  • 1: Yaw 45°
  • 2: Yaw 90°
  • 3: Yaw 135°
  • 4: Yaw 180°
  • 5: Yaw 225°
  • 6: Yaw 270°
  • 7: Yaw 315°
  • 8: Roll 180°
  • 9: Roll 180°, Yaw 45°
  • 10: Roll 180°, Yaw 90°
  • 11: Roll 180°, Yaw 135°
  • 12: Pitch 180°
  • 13: Roll 180°, Yaw 225°
  • 14: Roll 180°, Yaw 270°
  • 15: Roll 180°, Yaw 315°
  • 16: Roll 90°
  • 17: Roll 90°, Yaw 45°
  • 18: Roll 90°, Yaw 90°
  • 19: Roll 90°, Yaw 135°
  • 20: Roll 270°
  • 21: Roll 270°, Yaw 45°
  • 22: Roll 270°, Yaw 90°
  • 23: Roll 270°, Yaw 135°
  • 24: Pitch 90°
  • 25: Pitch 270°
  • 26: Pitch 180°, Yaw 90°
  • 27: Pitch 180°, Yaw 270°
  • 28: Roll 90°, Pitch 90°
  • 29: Roll 180°, Pitch 90°
  • 30: Roll 270°, Pitch 90°
  • 31: Roll 90°, Pitch 180°
  • 32: Roll 270°, Pitch 180°
  • 33: Roll 90°, Pitch 270°
  • 34: Roll 180°, Pitch 270°
  • 35: Roll 270°, Pitch 270°
  • 36: Roll 90°, Pitch 180°, Yaw 90°
  • 37: Roll 90°, Yaw 270°
  • 38: Roll 90°, Pitch 68°, Yaw 293°
  • 39: Pitch 315°
  • 40: Roll 90°, Pitch 315°

Reboot required: true

-1 > 40 0
SENS_BOARD_X_OFF (FLOAT) Board rotation X (Roll) offset

Comment: This parameter defines a rotational offset in degrees around the X (Roll) axis It allows the user to fine tune the board offset in the event of misalignment.

0.0 deg
SENS_BOARD_Y_OFF (FLOAT) Board rotation Y (Pitch) offset

Comment: This parameter defines a rotational offset in degrees around the Y (Pitch) axis. It allows the user to fine tune the board offset in the event of misalignment.

0.0 deg
SENS_BOARD_Z_OFF (FLOAT) Board rotation Z (YAW) offset

Comment: This parameter defines a rotational offset in degrees around the Z (Yaw) axis. It allows the user to fine tune the board offset in the event of misalignment.

0.0 deg
SENS_CM8JL65_CFG (INT32) Serial Configuration for Lanbao PSK-CM8JL65-CC5

Comment: Configure on which serial port to run Lanbao PSK-CM8JL65-CC5.

Values:
  • 0: Disabled
  • 6: UART 6
  • 101: TELEM 1
  • 102: TELEM 2
  • 103: TELEM 3
  • 104: TELEM/SERIAL 4
  • 201: GPS 1
  • 202: GPS 2
  • 203: GPS 3
  • 300: Radio Controller
  • 301: Wifi Port

Reboot required: true

0
SENS_CM8JL65_R_0 (INT32) Distance Sensor Rotation

Comment: Distance Sensor Rotation as MAV_SENSOR_ORIENTATION enum

Values:
  • 0: ROTATION_FORWARD_FACING
  • 2: ROTATION_RIGHT_FACING
  • 6: ROTATION_LEFT_FACING
  • 12: ROTATION_BACKWARD_FACING
  • 24: ROTATION_UPWARD_FACING
  • 25: ROTATION_DOWNWARD_FACING

Reboot required: True

25
SENS_EN_ADIS164X (INT32) Analog Devices ADIS16448 IMU (external SPI) Values:
  • 0: Disabled
  • 1: Enabled

Reboot required: true

0 > 1 0
SENS_EN_BATT (INT32) SMBUS Smart battery driver BQ40Z50 and BQ40Z80

Reboot required: true

Disabled (0)
SENS_EN_ETSASPD (INT32) Eagle Tree airspeed sensor (external I2C)

Reboot required: true

Disabled (0)
SENS_EN_INA226 (INT32) Enable INA226 Power Monitor

Comment: For systems a INA226 Power Monitor, this should be set to true

Reboot required: true

Disabled (0)
SENS_EN_INA228 (INT32) Enable INA228 Power Monitor

Comment: For systems a INA228 Power Monitor, this should be set to true

Reboot required: true

Disabled (0)
SENS_EN_LL40LS (INT32) Lidar-Lite (LL40LS) Values:
  • 0: Disabled
  • 1: PWM
  • 2: I2C

Reboot required: true

0 > 2 0
SENS_EN_MB12XX (INT32) Maxbotix Sonar (mb12xx)

Reboot required: true

Disabled (0)
SENS_EN_MPDT (INT32) Enable Mappydot rangefinder (i2c) Values:
  • 0: Disabled
  • 1: Autodetect

Reboot required: true

0 > 1 0
SENS_EN_MS4525 (INT32) TE MS4525 differential pressure sensor (external I2C)

Reboot required: true

Disabled (0)
SENS_EN_MS5525 (INT32) TE MS5525 differential pressure sensor (external I2C)

Reboot required: true

Disabled (0)
SENS_EN_PAW3902 (INT32) PAW3902 & PAW3903 Optical Flow

Reboot required: true

Disabled (0)
SENS_EN_PGA460 (INT32) PGA460 Ultrasonic driver (PGA460)

Reboot required: true

Disabled (0)
SENS_EN_PMW3901 (INT32) PMW3901 Optical Flow

Reboot required: true

Disabled (0)
SENS_EN_PX4FLOW (INT32) PX4 Flow Optical Flow

Reboot required: true

Disabled (0)
SENS_EN_SDP3X (INT32) Sensirion SDP3X differential pressure sensor (external I2C)

Reboot required: true

Disabled (0)
SENS_EN_SF0X (INT32) Lightware Laser Rangefinder hardware model (serial) Values:
  • 1: SF02
  • 2: SF10/a
  • 3: SF10/b
  • 4: SF10/c
  • 5: SF11/c

Reboot required: true

1
SENS_EN_SF1XX (INT32) Lightware SF1xx/SF20/LW20 laser rangefinder (i2c) Values:
  • 0: Disabled
  • 1: SF10/a
  • 2: SF10/b
  • 3: SF10/c
  • 4: SF11/c
  • 5: SF/LW20/b
  • 6: SF/LW20/c

Reboot required: true

0 > 6 0
SENS_EN_SR05 (INT32) HY-SRF05 / HC-SR05

Reboot required: true

Disabled (0)
SENS_EN_THERMAL (INT32) Thermal control of sensor temperature Values:
  • -1: Thermal control unavailable
  • 0: Thermal control off
  • 1: Thermal control enabled
-1
SENS_EN_TRANGER (INT32) TeraRanger Rangefinder (i2c) Values:
  • 0: Disabled
  • 1: Autodetect
  • 2: TROne
  • 3: TREvo60m
  • 4: TREvo600Hz
  • 5: TREvo3m

Reboot required: true

0 > 3 0
SENS_EN_VL53L1X (INT32) VL53L1X Distance Sensor

Reboot required: true

Disabled (0)
SENS_EXT_I2C_PRB (INT32) External I2C probe

Comment: Probe for optional external I2C devices.

Enabled (1)
SENS_FLOW_ROT (INT32) PX4Flow board rotation

Comment: This parameter defines the yaw rotation of the PX4FLOW board relative to the vehicle body frame. Zero rotation is defined as X on flow board pointing towards front of vehicle. The recommneded installation default for the PX4FLOW board is with the Y axis forward (270 deg yaw).

Values:
  • 0: No rotation
  • 1: Yaw 45°
  • 2: Yaw 90°
  • 3: Yaw 135°
  • 4: Yaw 180°
  • 5: Yaw 225°
  • 6: Yaw 270°
  • 7: Yaw 315°

Reboot required: true

6
SENS_GPS_MASK (INT32) Multi GPS Blending Control Mask

Comment: Set bits in the following positions to set which GPS accuracy metrics will be used to calculate the blending weight. Set to zero to disable and always used first GPS instance. 0 : Set to true to use speed accuracy 1 : Set to true to use horizontal position accuracy 2 : Set to true to use vertical position accuracy

Bitmask:
  • 0: use speed accuracy
  • 1: use hpos accuracy
  • 2: use vpos accuracy
0 > 7 0
SENS_GPS_PRIME (INT32) Multi GPS primary instance

Comment: When no blending is active, this defines the preferred GPS receiver instance. The GPS selection logic waits until the primary receiver is available to send data to the EKF even if a secondary instance is already available. The secondary instance is then only used if the primary one times out. To have an equal priority of all the instances, set this parameter to -1 and the best receiver will be used. This parameter has no effect if blending is active.

-1 > 1 0
SENS_GPS_TAU (FLOAT) Multi GPS Blending Time Constant

Comment: Sets the longest time constant that will be applied to the calculation of GPS position and height offsets used to correct data from multiple GPS data for steady state position differences.

1.0 > 100.0 10.0 s
SENS_IMU_MODE (INT32) Sensors hub IMU mode Values:
  • 0: Disabled
  • 1: Publish primary IMU selection

Reboot required: true

1
SENS_IMU_TEMP (FLOAT) Target IMU temperature 0 > 85.0 55.0 celcius
SENS_IMU_TEMP_FF (FLOAT) IMU heater controller feedforward value 0 > 1.0 0.05 %
SENS_IMU_TEMP_I (FLOAT) IMU heater controller integrator gain value 0 > 1.0 0.025 us/C
SENS_IMU_TEMP_P (FLOAT) IMU heater controller proportional gain value 0 > 2.0 1.0 us/C
SENS_INT_BARO_EN (INT32) Enable internal barometers

Comment: For systems with an external barometer, this should be set to false to make sure that the external is used.

Reboot required: true

Enabled (1)
SENS_LEDDAR1_CFG (INT32) Serial Configuration for LeddarOne Rangefinder

Comment: Configure on which serial port to run LeddarOne Rangefinder.

Values:
  • 0: Disabled
  • 6: UART 6
  • 101: TELEM 1
  • 102: TELEM 2
  • 103: TELEM 3
  • 104: TELEM/SERIAL 4
  • 201: GPS 1
  • 202: GPS 2
  • 203: GPS 3
  • 300: Radio Controller
  • 301: Wifi Port

Reboot required: true

0
SENS_MAG_MODE (INT32) Sensors hub mag mode Values:
  • 0: Publish all magnetometers
  • 1: Publish primary magnetometer

Reboot required: true

1
SENS_MAG_RATE (FLOAT) Magnetometer max rate

Comment: Magnetometer data maximum publication rate. This is an upper bound, actual magnetometer data rate is still dependant on the sensor.

Reboot required: true

1 > 200 50.0 Hz
SENS_MB12_0_ROT (INT32) MaxBotix MB12XX Sensor 0 Rotation

Comment: This parameter defines the rotation of the sensor relative to the platform.

Values:
  • 0: No rotation
  • 1: Yaw 45°
  • 2: Yaw 90°
  • 3: Yaw 135°
  • 4: Yaw 180°
  • 5: Yaw 225°
  • 6: Yaw 270°
  • 7: Yaw 315°

Reboot required: true

0 > 7 0
SENS_MB12_10_ROT (INT32) MaxBotix MB12XX Sensor 10 Rotation

Comment: This parameter defines the rotation of the sensor relative to the platform.

Values:
  • 0: No rotation
  • 1: Yaw 45°
  • 2: Yaw 90°
  • 3: Yaw 135°
  • 4: Yaw 180°
  • 5: Yaw 225°
  • 6: Yaw 270°
  • 7: Yaw 315°

Reboot required: true

0 > 7 0
SENS_MB12_11_ROT (INT32) MaxBotix MB12XX Sensor 12 Rotation

Comment: This parameter defines the rotation of the sensor relative to the platform.

Values:
  • 0: No rotation
  • 1: Yaw 45°
  • 2: Yaw 90°
  • 3: Yaw 135°
  • 4: Yaw 180°
  • 5: Yaw 225°
  • 6: Yaw 270°
  • 7: Yaw 315°

Reboot required: true

0 > 7 0
SENS_MB12_1_ROT (INT32) MaxBotix MB12XX Sensor 1 Rotation

Comment: This parameter defines the rotation of the sensor relative to the platform.

Values:
  • 0: No rotation
  • 1: Yaw 45°
  • 2: Yaw 90°
  • 3: Yaw 135°
  • 4: Yaw 180°
  • 5: Yaw 225°
  • 6: Yaw 270°
  • 7: Yaw 315°

Reboot required: true

0 > 7 0
SENS_MB12_2_ROT (INT32) MaxBotix MB12XX Sensor 2 Rotation

Comment: This parameter defines the rotation of the sensor relative to the platform.

Values:
  • 0: No rotation
  • 1: Yaw 45°
  • 2: Yaw 90°
  • 3: Yaw 135°
  • 4: Yaw 180°
  • 5: Yaw 225°
  • 6: Yaw 270°
  • 7: Yaw 315°

Reboot required: true

0 > 7 0
SENS_MB12_3_ROT (INT32) MaxBotix MB12XX Sensor 3 Rotation

Comment: This parameter defines the rotation of the sensor relative to the platform.

Values:
  • 0: No rotation
  • 1: Yaw 45°
  • 2: Yaw 90°
  • 3: Yaw 135°
  • 4: Yaw 180°
  • 5: Yaw 225°
  • 6: Yaw 270°
  • 7: Yaw 315°

Reboot required: true

0 > 7 0
SENS_MB12_4_ROT (INT32) MaxBotix MB12XX Sensor 4 Rotation

Comment: This parameter defines the rotation of the sensor relative to the platform.

Values:
  • 0: No rotation
  • 1: Yaw 45°
  • 2: Yaw 90°
  • 3: Yaw 135°
  • 4: Yaw 180°
  • 5: Yaw 225°
  • 6: Yaw 270°
  • 7: Yaw 315°

Reboot required: true

0 > 7 0
SENS_MB12_5_ROT (INT32) MaxBotix MB12XX Sensor 5 Rotation

Comment: This parameter defines the rotation of the sensor relative to the platform.

Values:
  • 0: No rotation
  • 1: Yaw 45°
  • 2: Yaw 90°
  • 3: Yaw 135°
  • 4: Yaw 180°
  • 5: Yaw 225°
  • 6: Yaw 270°
  • 7: Yaw 315°

Reboot required: true

0 > 7 0
SENS_MB12_6_ROT (INT32) MaxBotix MB12XX Sensor 6 Rotation

Comment: This parameter defines the rotation of the sensor relative to the platform.

Values:
  • 0: No rotation
  • 1: Yaw 45°
  • 2: Yaw 90°
  • 3: Yaw 135°
  • 4: Yaw 180°
  • 5: Yaw 225°
  • 6: Yaw 270°
  • 7: Yaw 315°

Reboot required: true

0 > 7 0
SENS_MB12_7_ROT (INT32) MaxBotix MB12XX Sensor 7 Rotation

Comment: This parameter defines the rotation of the sensor relative to the platform.

Values:
  • 0: No rotation
  • 1: Yaw 45°
  • 2: Yaw 90°
  • 3: Yaw 135°
  • 4: Yaw 180°
  • 5: Yaw 225°
  • 6: Yaw 270°
  • 7: Yaw 315°

Reboot required: true

0 > 7 0
SENS_MB12_8_ROT (INT32) MaxBotix MB12XX Sensor 8 Rotation

Comment: This parameter defines the rotation of the sensor relative to the platform.

Values:
  • 0: No rotation
  • 1: Yaw 45°
  • 2: Yaw 90°
  • 3: Yaw 135°
  • 4: Yaw 180°
  • 5: Yaw 225°
  • 6: Yaw 270°
  • 7: Yaw 315°

Reboot required: true

0 > 7 0
SENS_MB12_9_ROT (INT32) MaxBotix MB12XX Sensor 9 Rotation

Comment: This parameter defines the rotation of the sensor relative to the platform.

Values:
  • 0: No rotation
  • 1: Yaw 45°
  • 2: Yaw 90°
  • 3: Yaw 135°
  • 4: Yaw 180°
  • 5: Yaw 225°
  • 6: Yaw 270°
  • 7: Yaw 315°

Reboot required: true

0 > 7 0
SENS_MPDT0_ROT (INT32) MappyDot Sensor 0 Rotation

Comment: This parameter defines the rotation of the Mappydot sensor relative to the platform.

Values:
  • 0: No rotation
  • 1: Yaw 45°
  • 2: Yaw 90°
  • 3: Yaw 135°
  • 4: Yaw 180°
  • 5: Yaw 225°
  • 6: Yaw 270°
  • 7: Yaw 315°

Reboot required: true

0 > 7 0
SENS_MPDT10_ROT (INT32) MappyDot Sensor 10 Rotation

Comment: This parameter defines the rotation of the Mappydot sensor relative to the platform.

Values:
  • 0: No rotation
  • 1: Yaw 45°
  • 2: Yaw 90°
  • 3: Yaw 135°
  • 4: Yaw 180°
  • 5: Yaw 225°
  • 6: Yaw 270°
  • 7: Yaw 315°

Reboot required: true

0 > 7 0
SENS_MPDT11_ROT (INT32) MappyDot Sensor 12 Rotation

Comment: This parameter defines the rotation of the Mappydot sensor relative to the platform.

Values:
  • 0: No rotation
  • 1: Yaw 45°
  • 2: Yaw 90°
  • 3: Yaw 135°
  • 4: Yaw 180°
  • 5: Yaw 225°
  • 6: Yaw 270°
  • 7: Yaw 315°

Reboot required: true

0 > 7 0
SENS_MPDT1_ROT (INT32) MappyDot Sensor 1 Rotation

Comment: This parameter defines the rotation of the Mappydot sensor relative to the platform.

Values:
  • 0: No rotation
  • 1: Yaw 45°
  • 2: Yaw 90°
  • 3: Yaw 135°
  • 4: Yaw 180°
  • 5: Yaw 225°
  • 6: Yaw 270°
  • 7: Yaw 315°

Reboot required: true

0 > 7 0
SENS_MPDT2_ROT (INT32) MappyDot Sensor 2 Rotation

Comment: This parameter defines the rotation of the Mappydot sensor relative to the platform.

Values:
  • 0: No rotation
  • 1: Yaw 45°
  • 2: Yaw 90°
  • 3: Yaw 135°
  • 4: Yaw 180°
  • 5: Yaw 225°
  • 6: Yaw 270°
  • 7: Yaw 315°

Reboot required: true

0 > 7 0
SENS_MPDT3_ROT (INT32) MappyDot Sensor 3 Rotation

Comment: This parameter defines the rotation of the Mappydot sensor relative to the platform.

Values:
  • 0: No rotation
  • 1: Yaw 45°
  • 2: Yaw 90°
  • 3: Yaw 135°
  • 4: Yaw 180°
  • 5: Yaw 225°
  • 6: Yaw 270°
  • 7: Yaw 315°

Reboot required: true

0 > 7 0
SENS_MPDT4_ROT (INT32) MappyDot Sensor 4 Rotation

Comment: This parameter defines the rotation of the Mappydot sensor relative to the platform.

Values:
  • 0: No rotation
  • 1: Yaw 45°
  • 2: Yaw 90°
  • 3: Yaw 135°
  • 4: Yaw 180°
  • 5: Yaw 225°
  • 6: Yaw 270°
  • 7: Yaw 315°

Reboot required: true

0 > 7 0
SENS_MPDT5_ROT (INT32) MappyDot Sensor 5 Rotation

Comment: This parameter defines the rotation of the Mappydot sensor relative to the platform.

Values:
  • 0: No rotation
  • 1: Yaw 45°
  • 2: Yaw 90°
  • 3: Yaw 135°
  • 4: Yaw 180°
  • 5: Yaw 225°
  • 6: Yaw 270°
  • 7: Yaw 315°

Reboot required: true

0 > 7 0
SENS_MPDT6_ROT (INT32) MappyDot Sensor 6 Rotation

Comment: This parameter defines the rotation of the Mappydot sensor relative to the platform.

Values:
  • 0: No rotation
  • 1: Yaw 45°
  • 2: Yaw 90°
  • 3: Yaw 135°
  • 4: Yaw 180°
  • 5: Yaw 225°
  • 6: Yaw 270°
  • 7: Yaw 315°

Reboot required: true

0 > 7 0
SENS_MPDT7_ROT (INT32) MappyDot Sensor 7 Rotation

Comment: This parameter defines the rotation of the Mappydot sensor relative to the platform.

Values:
  • 0: No rotation
  • 1: Yaw 45°
  • 2: Yaw 90°
  • 3: Yaw 135°
  • 4: Yaw 180°
  • 5: Yaw 225°
  • 6: Yaw 270°
  • 7: Yaw 315°

Reboot required: true

0 > 7 0
SENS_MPDT8_ROT (INT32) MappyDot Sensor 8 Rotation

Comment: This parameter defines the rotation of the Mappydot sensor relative to the platform.

Values:
  • 0: No rotation
  • 1: Yaw 45°
  • 2: Yaw 90°
  • 3: Yaw 135°
  • 4: Yaw 180°
  • 5: Yaw 225°
  • 6: Yaw 270°
  • 7: Yaw 315°

Reboot required: true

0 > 7 0
SENS_MPDT9_ROT (INT32) MappyDot Sensor 9 Rotation

Comment: This parameter defines the rotation of the Mappydot sensor relative to the platform.

Values:
  • 0: No rotation
  • 1: Yaw 45°
  • 2: Yaw 90°
  • 3: Yaw 135°
  • 4: Yaw 180°
  • 5: Yaw 225°
  • 6: Yaw 270°
  • 7: Yaw 315°

Reboot required: true

0 > 7 0
SENS_OR_ADIS164X (INT32) Analog Devices ADIS16448 IMU Orientation(external SPI) Values:
  • 0: ROTATION_NONE
  • 4: ROTATION_YAW_180

Reboot required: true

0 > 101 0
SENS_SF0X_CFG (INT32) Serial Configuration for Lightware Laser Rangefinder (serial)

Comment: Configure on which serial port to run Lightware Laser Rangefinder (serial).

Values:
  • 0: Disabled
  • 6: UART 6
  • 101: TELEM 1
  • 102: TELEM 2
  • 103: TELEM 3
  • 104: TELEM/SERIAL 4
  • 201: GPS 1
  • 202: GPS 2
  • 203: GPS 3
  • 300: Radio Controller
  • 301: Wifi Port

Reboot required: true

0
SENS_TEMP_ID (INT32) Target IMU device ID to regulate temperature 0
SENS_TFLOW_CFG (INT32) Serial Configuration for ThoneFlow-3901U optical flow sensor

Comment: Configure on which serial port to run ThoneFlow-3901U optical flow sensor.

Values:
  • 0: Disabled
  • 6: UART 6
  • 101: TELEM 1
  • 102: TELEM 2
  • 103: TELEM 3
  • 104: TELEM/SERIAL 4
  • 201: GPS 1
  • 202: GPS 2
  • 203: GPS 3
  • 300: Radio Controller
  • 301: Wifi Port

Reboot required: true

0
SENS_TFMINI_CFG (INT32) Serial Configuration for Benewake TFmini Rangefinder

Comment: Configure on which serial port to run Benewake TFmini Rangefinder.

Values:
  • 0: Disabled
  • 6: UART 6
  • 101: TELEM 1
  • 102: TELEM 2
  • 103: TELEM 3
  • 104: TELEM/SERIAL 4
  • 201: GPS 1
  • 202: GPS 2
  • 203: GPS 3
  • 300: Radio Controller
  • 301: Wifi Port

Reboot required: true

0
SENS_ULAND_CFG (INT32) Serial Configuration for uLanding Radar

Comment: Configure on which serial port to run uLanding Radar.

Values:
  • 0: Disabled
  • 6: UART 6
  • 101: TELEM 1
  • 102: TELEM 2
  • 103: TELEM 3
  • 104: TELEM/SERIAL 4
  • 201: GPS 1
  • 202: GPS 2
  • 203: GPS 3
  • 300: Radio Controller
  • 301: Wifi Port

Reboot required: true

0
VOXLPM_SHUNT_BAT (FLOAT) VOXL Power Monitor Shunt, Battery

Reboot required: true

0.000000001 > 0.1 (.000000001) 0.00063
VOXLPM_SHUNT_REG (FLOAT) VOXL Power Monitor Shunt, Regulator

Reboot required: true

0.000000001 > 0.1 (.000000001) 0.0056

Serial

NameDescriptionMin > Max (Incr.)DefaultUnits
RC_PORT_CONFIG (INT32) Serial Configuration for RC Input Driver

Comment: Configure on which serial port to run RC Input Driver. Setting this to 'Disabled' will use a board-specific default port for RC input.

Values:
  • 0: Disabled
  • 6: UART 6
  • 101: TELEM 1
  • 102: TELEM 2
  • 103: TELEM 3
  • 104: TELEM/SERIAL 4
  • 201: GPS 1
  • 202: GPS 2
  • 203: GPS 3
  • 300: Radio Controller
  • 301: Wifi Port

Reboot required: true

300
SER_GPS1_BAUD (INT32) Baudrate for the GPS 1 Serial Port

Comment: Configure the Baudrate for the GPS 1 Serial Port. Note: certain drivers such as the GPS can determine the Baudrate automatically.

Values:
  • 0: Auto
  • 50: 50 8N1
  • 75: 75 8N1
  • 110: 110 8N1
  • 134: 134 8N1
  • 150: 150 8N1
  • 200: 200 8N1
  • 300: 300 8N1
  • 600: 600 8N1
  • 1200: 1200 8N1
  • 1800: 1800 8N1
  • 2400: 2400 8N1
  • 4800: 4800 8N1
  • 9600: 9600 8N1
  • 19200: 19200 8N1
  • 38400: 38400 8N1
  • 57600: 57600 8N1
  • 115200: 115200 8N1
  • 230400: 230400 8N1
  • 460800: 460800 8N1
  • 500000: 500000 8N1
  • 921600: 921600 8N1
  • 1000000: 1000000 8N1
  • 1500000: 1500000 8N1
  • 2000000: 2000000 8N1
  • 3000000: 3000000 8N1

Reboot required: true

0
SER_GPS2_BAUD (INT32) Baudrate for the GPS 2 Serial Port

Comment: Configure the Baudrate for the GPS 2 Serial Port. Note: certain drivers such as the GPS can determine the Baudrate automatically.

Values:
  • 0: Auto
  • 50: 50 8N1
  • 75: 75 8N1
  • 110: 110 8N1
  • 134: 134 8N1
  • 150: 150 8N1
  • 200: 200 8N1
  • 300: 300 8N1
  • 600: 600 8N1
  • 1200: 1200 8N1
  • 1800: 1800 8N1
  • 2400: 2400 8N1
  • 4800: 4800 8N1
  • 9600: 9600 8N1
  • 19200: 19200 8N1
  • 38400: 38400 8N1
  • 57600: 57600 8N1
  • 115200: 115200 8N1
  • 230400: 230400 8N1
  • 460800: 460800 8N1
  • 500000: 500000 8N1
  • 921600: 921600 8N1
  • 1000000: 1000000 8N1
  • 1500000: 1500000 8N1
  • 2000000: 2000000 8N1
  • 3000000: 3000000 8N1

Reboot required: true

0
SER_GPS3_BAUD (INT32) Baudrate for the GPS 3 Serial Port

Comment: Configure the Baudrate for the GPS 3 Serial Port. Note: certain drivers such as the GPS can determine the Baudrate automatically.

Values:
  • 0: Auto
  • 50: 50 8N1
  • 75: 75 8N1
  • 110: 110 8N1
  • 134: 134 8N1
  • 150: 150 8N1
  • 200: 200 8N1
  • 300: 300 8N1
  • 600: 600 8N1
  • 1200: 1200 8N1
  • 1800: 1800 8N1
  • 2400: 2400 8N1
  • 4800: 4800 8N1
  • 9600: 9600 8N1
  • 19200: 19200 8N1
  • 38400: 38400 8N1
  • 57600: 57600 8N1
  • 115200: 115200 8N1
  • 230400: 230400 8N1
  • 460800: 460800 8N1
  • 500000: 500000 8N1
  • 921600: 921600 8N1
  • 1000000: 1000000 8N1
  • 1500000: 1500000 8N1
  • 2000000: 2000000 8N1
  • 3000000: 3000000 8N1

Reboot required: true

0
SER_RC_BAUD (INT32) Baudrate for the Radio Controller Serial Port

Comment: Configure the Baudrate for the Radio Controller Serial Port. Note: certain drivers such as the GPS can determine the Baudrate automatically.

Values:
  • 0: Auto
  • 50: 50 8N1
  • 75: 75 8N1
  • 110: 110 8N1
  • 134: 134 8N1
  • 150: 150 8N1
  • 200: 200 8N1
  • 300: 300 8N1
  • 600: 600 8N1
  • 1200: 1200 8N1
  • 1800: 1800 8N1
  • 2400: 2400 8N1
  • 4800: 4800 8N1
  • 9600: 9600 8N1
  • 19200: 19200 8N1
  • 38400: 38400 8N1
  • 57600: 57600 8N1
  • 115200: 115200 8N1
  • 230400: 230400 8N1
  • 460800: 460800 8N1
  • 500000: 500000 8N1
  • 921600: 921600 8N1
  • 1000000: 1000000 8N1
  • 1500000: 1500000 8N1
  • 2000000: 2000000 8N1
  • 3000000: 3000000 8N1

Reboot required: true

0
SER_TEL1_BAUD (INT32) Baudrate for the TELEM 1 Serial Port

Comment: Configure the Baudrate for the TELEM 1 Serial Port. Note: certain drivers such as the GPS can determine the Baudrate automatically.

Values:
  • 0: Auto
  • 50: 50 8N1
  • 75: 75 8N1
  • 110: 110 8N1
  • 134: 134 8N1
  • 150: 150 8N1
  • 200: 200 8N1
  • 300: 300 8N1
  • 600: 600 8N1
  • 1200: 1200 8N1
  • 1800: 1800 8N1
  • 2400: 2400 8N1
  • 4800: 4800 8N1
  • 9600: 9600 8N1
  • 19200: 19200 8N1
  • 38400: 38400 8N1
  • 57600: 57600 8N1
  • 115200: 115200 8N1
  • 230400: 230400 8N1
  • 460800: 460800 8N1
  • 500000: 500000 8N1
  • 921600: 921600 8N1
  • 1000000: 1000000 8N1
  • 1500000: 1500000 8N1
  • 2000000: 2000000 8N1
  • 3000000: 3000000 8N1

Reboot required: true

57600
SER_TEL2_BAUD (INT32) Baudrate for the TELEM 2 Serial Port

Comment: Configure the Baudrate for the TELEM 2 Serial Port. Note: certain drivers such as the GPS can determine the Baudrate automatically.

Values:
  • 0: Auto
  • 50: 50 8N1
  • 75: 75 8N1
  • 110: 110 8N1
  • 134: 134 8N1
  • 150: 150 8N1
  • 200: 200 8N1
  • 300: 300 8N1
  • 600: 600 8N1
  • 1200: 1200 8N1
  • 1800: 1800 8N1
  • 2400: 2400 8N1
  • 4800: 4800 8N1
  • 9600: 9600 8N1
  • 19200: 19200 8N1
  • 38400: 38400 8N1
  • 57600: 57600 8N1
  • 115200: 115200 8N1
  • 230400: 230400 8N1
  • 460800: 460800 8N1
  • 500000: 500000 8N1
  • 921600: 921600 8N1
  • 1000000: 1000000 8N1
  • 1500000: 1500000 8N1
  • 2000000: 2000000 8N1
  • 3000000: 3000000 8N1

Reboot required: true

921600
SER_TEL3_BAUD (INT32) Baudrate for the TELEM 3 Serial Port

Comment: Configure the Baudrate for the TELEM 3 Serial Port. Note: certain drivers such as the GPS can determine the Baudrate automatically.

Values:
  • 0: Auto
  • 50: 50 8N1
  • 75: 75 8N1
  • 110: 110 8N1
  • 134: 134 8N1
  • 150: 150 8N1
  • 200: 200 8N1
  • 300: 300 8N1
  • 600: 600 8N1
  • 1200: 1200 8N1
  • 1800: 1800 8N1
  • 2400: 2400 8N1
  • 4800: 4800 8N1
  • 9600: 9600 8N1
  • 19200: 19200 8N1
  • 38400: 38400 8N1
  • 57600: 57600 8N1
  • 115200: 115200 8N1
  • 230400: 230400 8N1
  • 460800: 460800 8N1
  • 500000: 500000 8N1
  • 921600: 921600 8N1
  • 1000000: 1000000 8N1
  • 1500000: 1500000 8N1
  • 2000000: 2000000 8N1
  • 3000000: 3000000 8N1

Reboot required: true

57600
SER_TEL4_BAUD (INT32) Baudrate for the TELEM/SERIAL 4 Serial Port

Comment: Configure the Baudrate for the TELEM/SERIAL 4 Serial Port. Note: certain drivers such as the GPS can determine the Baudrate automatically.

Values:
  • 0: Auto
  • 50: 50 8N1
  • 75: 75 8N1
  • 110: 110 8N1
  • 134: 134 8N1
  • 150: 150 8N1
  • 200: 200 8N1
  • 300: 300 8N1
  • 600: 600 8N1
  • 1200: 1200 8N1
  • 1800: 1800 8N1
  • 2400: 2400 8N1
  • 4800: 4800 8N1
  • 9600: 9600 8N1
  • 19200: 19200 8N1
  • 38400: 38400 8N1
  • 57600: 57600 8N1
  • 115200: 115200 8N1
  • 230400: 230400 8N1
  • 460800: 460800 8N1
  • 500000: 500000 8N1
  • 921600: 921600 8N1
  • 1000000: 1000000 8N1
  • 1500000: 1500000 8N1
  • 2000000: 2000000 8N1
  • 3000000: 3000000 8N1

Reboot required: true

57600
SER_URT6_BAUD (INT32) Baudrate for the UART 6 Serial Port

Comment: Configure the Baudrate for the UART 6 Serial Port. Note: certain drivers such as the GPS can determine the Baudrate automatically.

Values:
  • 0: Auto
  • 50: 50 8N1
  • 75: 75 8N1
  • 110: 110 8N1
  • 134: 134 8N1
  • 150: 150 8N1
  • 200: 200 8N1
  • 300: 300 8N1
  • 600: 600 8N1
  • 1200: 1200 8N1
  • 1800: 1800 8N1
  • 2400: 2400 8N1
  • 4800: 4800 8N1
  • 9600: 9600 8N1
  • 19200: 19200 8N1
  • 38400: 38400 8N1
  • 57600: 57600 8N1
  • 115200: 115200 8N1
  • 230400: 230400 8N1
  • 460800: 460800 8N1
  • 500000: 500000 8N1
  • 921600: 921600 8N1
  • 1000000: 1000000 8N1
  • 1500000: 1500000 8N1
  • 2000000: 2000000 8N1
  • 3000000: 3000000 8N1

Reboot required: true

57600
SER_WIFI_BAUD (INT32) Baudrate for the Wifi Port Serial Port

Comment: Configure the Baudrate for the Wifi Port Serial Port. Note: certain drivers such as the GPS can determine the Baudrate automatically.

Values:
  • 0: Auto
  • 50: 50 8N1
  • 75: 75 8N1
  • 110: 110 8N1
  • 134: 134 8N1
  • 150: 150 8N1
  • 200: 200 8N1
  • 300: 300 8N1
  • 600: 600 8N1
  • 1200: 1200 8N1
  • 1800: 1800 8N1
  • 2400: 2400 8N1
  • 4800: 4800 8N1
  • 9600: 9600 8N1
  • 19200: 19200 8N1
  • 38400: 38400 8N1
  • 57600: 57600 8N1
  • 115200: 115200 8N1
  • 230400: 230400 8N1
  • 460800: 460800 8N1
  • 500000: 500000 8N1
  • 921600: 921600 8N1
  • 1000000: 1000000 8N1
  • 1500000: 1500000 8N1
  • 2000000: 2000000 8N1
  • 3000000: 3000000 8N1

Reboot required: true

1

Simulation In Hardware

NameDescriptionMin > Max (Incr.)DefaultUnits
SIH_BARO_OFFSET (FLOAT) Barometer offset in meters

Comment: Absolute value superior to 10000 will disable barometer

0.0 m
SIH_DISTSNSR_MAX (FLOAT) distance sensor maximun range 0.0 > 1000.0 (0.01) 100.0 m
SIH_DISTSNSR_MIN (FLOAT) distance sensor minimun range 0.0 > 10.0 (0.01) 0.0 m
SIH_DISTSNSR_OVR (FLOAT) if >= 0 the distance sensor measures will be overrided by this value

Comment: Absolute value superior to 10000 will disable distance sensor

-1.0 m
SIH_GPS_USED (INT32) Number of GPS satellites used 0 > 50 10
SIH_IXX (FLOAT) Vehicle inertia about X axis

Comment: The intertia is a 3 by 3 symmetric matrix. It represents the difficulty of the vehicle to modify its angular rate.

0.0 > ? (0.005) 0.025 kg m^2
SIH_IXY (FLOAT) Vehicle cross term inertia xy

Comment: The intertia is a 3 by 3 symmetric matrix. This value can be set to 0 for a quad symmetric about its center of mass.

(0.005) 0.0 kg m^2
SIH_IXZ (FLOAT) Vehicle cross term inertia xz

Comment: The intertia is a 3 by 3 symmetric matrix. This value can be set to 0 for a quad symmetric about its center of mass.

(0.005) 0.0 kg m^2
SIH_IYY (FLOAT) Vehicle inertia about Y axis

Comment: The intertia is a 3 by 3 symmetric matrix. It represents the difficulty of the vehicle to modify its angular rate.

0.0 > ? (0.005) 0.025 kg m^2
SIH_IYZ (FLOAT) Vehicle cross term inertia yz

Comment: The intertia is a 3 by 3 symmetric matrix. This value can be set to 0 for a quad symmetric about its center of mass.

(0.005) 0.0 kg m^2
SIH_IZZ (FLOAT) Vehicle inertia about Z axis

Comment: The intertia is a 3 by 3 symmetric matrix. It represents the difficulty of the vehicle to modify its angular rate.

0.0 > ? (0.005) 0.030 kg m^2
SIH_KDV (FLOAT) First order drag coefficient

Comment: Physical coefficient representing the friction with air particules. The greater this value, the slower the quad will move. Drag force function of velocity: D=-KDV*V. The maximum freefall velocity can be computed as V=10*MASS/KDV [m/s]

0.0 > ? (0.05) 1.0 N/(m/s)
SIH_KDW (FLOAT) First order angular damper coefficient

Comment: Physical coefficient representing the friction with air particules during rotations. The greater this value, the slower the quad will rotate. Aerodynamic moment function of body rate: Ma=-KDW*W_B. This value can be set to 0 if unknown.

0.0 > ? (0.005) 0.025 Nm/(rad/s)
SIH_LOC_H0 (FLOAT) Initial AMSL ground altitude

Comment: This value represents the Above Mean Sea Level (AMSL) altitude where the simulation begins. If using FlightGear as a visual animation, this value can be tweaked such that the vehicle lies on the ground at takeoff. LAT0, LON0, H0, MU_X, MU_Y, and MU_Z should ideally be consistent among each others to represent a physical ground location on Earth.

-420.0 > 8848.0 (0.01) 32.34 m
SIH_LOC_LAT0 (INT32) Initial geodetic latitude

Comment: This value represents the North-South location on Earth where the simulation begins. A value of 45 deg should be written 450000000. LAT0, LON0, H0, MU_X, MU_Y, and MU_Z should ideally be consistent among each others to represent a physical ground location on Earth.

-850000000 > 850000000 454671160 deg*1e7
SIH_LOC_LON0 (INT32) Initial geodetic longitude

Comment: This value represents the East-West location on Earth where the simulation begins. A value of 45 deg should be written 450000000. LAT0, LON0, H0, MU_X, MU_Y, and MU_Z should ideally be consistent among each others to represent a physical ground location on Earth.

-1800000000 > 1800000000 -737578370 deg*1e7
SIH_LOC_MU_X (FLOAT) North magnetic field at the initial location

Comment: This value represents the North magnetic field at the initial location. A magnetic field calculator can be found on the NOAA website Note, the values need to be converted from nano Tesla to Gauss LAT0, LON0, H0, MU_X, MU_Y, and MU_Z should ideally be consistent among each others to represent a physical ground location on Earth.

-1.0 > 1.0 (0.001) 0.179 gauss
SIH_LOC_MU_Y (FLOAT) East magnetic field at the initial location

Comment: This value represents the East magnetic field at the initial location. A magnetic field calculator can be found on the NOAA website Note, the values need to be converted from nano Tesla to Gauss LAT0, LON0, H0, MU_X, MU_Y, and MU_Z should ideally be consistent among each others to represent a physical ground location on Earth.

-1.0 > 1.0 (0.001) -0.045 gauss
SIH_LOC_MU_Z (FLOAT) Down magnetic field at the initial location

Comment: This value represents the Down magnetic field at the initial location. A magnetic field calculator can be found on the NOAA website Note, the values need to be converted from nano Tesla to Gauss LAT0, LON0, H0, MU_X, MU_Y, and MU_Z should ideally be consistent among each others to represent a physical ground location on Earth.

-1.0 > 1.0 (0.001) 0.504 gauss
SIH_L_PITCH (FLOAT) Pitch arm length

Comment: This is the arm length generating the pitching moment This value can be measured with a ruler. This corresponds to half the distance between the front and rear motors.

0.0 > ? (0.05) 0.2 m
SIH_L_ROLL (FLOAT) Roll arm length

Comment: This is the arm length generating the rolling moment This value can be measured with a ruler. This corresponds to half the distance between the left and right motors.

0.0 > ? (0.05) 0.2 m
SIH_MAG_OFFSET_X (FLOAT) magnetometer X offset in Gauss

Comment: Absolute value superior to 10000 will disable magnetometer

0.0 gauss
SIH_MAG_OFFSET_Y (FLOAT) magnetometer Y offset in Gauss

Comment: Absolute value superior to 10000 will disable magnetometer

0.0 gauss
SIH_MAG_OFFSET_Z (FLOAT) magnetometer Z offset in Gauss

Comment: Absolute value superior to 10000 will disable magnetometer

0.0 gauss
SIH_MASS (FLOAT) Vehicle mass

Comment: This value can be measured by weighting the quad on a scale.

0.0 > ? (0.1) 1.0 kg
SIH_Q_MAX (FLOAT) Max propeller torque

Comment: This is the maximum torque delivered by one propeller when the motor is running at full speed. This value is usually about few percent of the maximum thrust force.

0.0 > ? (0.05) 0.1 Nm
SIH_T_MAX (FLOAT) Max propeller thrust force

Comment: This is the maximum force delivered by one propeller when the motor is running at full speed. This value is usually about 5 times the mass of the quadrotor.

0.0 > ? (0.5) 5.0 N
SIH_T_TAU (FLOAT) thruster time constant tau

Comment: the time taken for the thruster to step from 0 to 100% should be about 4 times tau

0.05 s
SIH_VEHICLE_TYPE (INT32) Vehicle type Values:
  • 0: MC
  • 1: FW

Reboot required: true

0

System

NameDescriptionMin > Max (Incr.)DefaultUnits
LED_RGB1_MAXBRT (INT32) RGB Led brightness limit

Comment: Set to 0 to disable, 1 for minimum brightness up to 31 (max)

0 > 31 31
LED_RGB_MAXBRT (INT32) RGB Led brightness limit

Comment: Set to 0 to disable, 1 for minimum brightness up to 15 (max)

0 > 15 15
SYS_AUTOCONFIG (INT32) Automatically configure default values

Comment: Set to 1 to reset parameters on next system startup (setting defaults). Platform-specific values are used if available. RC* parameters are preserved.

Values:
  • 0: Keep parameters
  • 1: Reset parameters to airframe defaults
0
SYS_AUTOSTART (INT32) Auto-start script index

Comment: CHANGING THIS VALUE REQUIRES A RESTART. Defines the auto-start script used to bootstrap the system.

Reboot required: true

0 > 9999999 0
SYS_BL_UPDATE (INT32) Bootloader update

Comment: If enabled, update the bootloader on the next boot. WARNING: do not cut the power during an update process, otherwise you will have to recover using some alternative method (e.g. JTAG). Instructions: - Insert an SD card - Enable this parameter - Reboot the board (plug the power or send a reboot command) - Wait until the board comes back up (or at least 2 minutes) - If it does not come back, check the file bootlog.txt on the SD card

Reboot required: true

Disabled (0)
SYS_CAL_ACCEL (INT32) Enable auto start of accelerometer thermal calibration at the next power up

Comment: 0 : Set to 0 to do nothing 1 : Set to 1 to start a calibration at next boot This parameter is reset to zero when the temperature calibration starts. default (0, no calibration)

0 > 1 0
SYS_CAL_BARO (INT32) Enable auto start of barometer thermal calibration at the next power up

Comment: 0 : Set to 0 to do nothing 1 : Set to 1 to start a calibration at next boot This parameter is reset to zero when the temperature calibration starts. default (0, no calibration)

0 > 1 0
SYS_CAL_GYRO (INT32) Enable auto start of rate gyro thermal calibration at the next power up

Comment: 0 : Set to 0 to do nothing 1 : Set to 1 to start a calibration at next boot This parameter is reset to zero when the temperature calibration starts. default (0, no calibration)

0 > 1 0
SYS_CAL_TDEL (INT32) Required temperature rise during thermal calibration

Comment: A temperature increase greater than this value is required during calibration. Calibration will complete for each sensor when the temperature increase above the starting temeprature exceeds the value set by SYS_CAL_TDEL. If the temperature rise is insufficient, the calibration will continue indefinitely and the board will need to be repowered to exit.

10 > ? 24 celcius
SYS_CAL_TMAX (INT32) Maximum starting temperature for thermal calibration

Comment: Temperature calibration will not start if the temperature of any sensor is higher than the value set by SYS_CAL_TMAX.

10 celcius
SYS_CAL_TMIN (INT32) Minimum starting temperature for thermal calibration

Comment: Temperature calibration for each sensor will ignore data if the temperature is lower than the value set by SYS_CAL_TMIN.

5 celcius
SYS_FAC_CAL_MODE (INT32) Enable factory calibration mode

Comment: If enabled, future sensor calibrations will be stored to /fs/mtd_caldata. Note: this is only supported on boards with a separate calibration storage /fs/mtd_caldata.

Disabled (0)
SYS_FAILURE_EN (INT32) Enable failure injection

Comment: If enabled allows MAVLink INJECT_FAILURE commands. WARNING: the failures can easily cause crashes and are to be used with caution!

Disabled (0)
SYS_HAS_BARO (INT32) Control if the vehicle has a barometer

Comment: Disable this if the board has no barometer, such as some of the Omnibus F4 SD variants. If disabled, the preflight checks will not check for the presence of a barometer.

Reboot required: true

Enabled (1)
SYS_HAS_GPS (INT32) Control if the vehicle has a GPS

Comment: Disable this if the system has no GPS. If disabled, the sensors hub will not process sensor_gps, and GPS will not be available for the rest of the system.

Reboot required: true

Enabled (1)
SYS_HAS_MAG (INT32) Control if the vehicle has a magnetometer

Comment: Disable this if the board has no magnetometer, such as the Omnibus F4 SD. If disabled, the preflight checks will not check for the presence of a magnetometer.

Reboot required: true

Enabled (1)
SYS_HITL (INT32) Enable HITL/SIH mode on next boot

Comment: While enabled the system will boot in Hardware-In-The-Loop (HITL) or Simulation-In-Hardware (SIH) mode and not enable all sensors and checks. When disabled the same vehicle can be flown normally. Set to 'external HITL', if the system should perform as if it were a real vehicle (the only difference to a real system is then only the parameter value, which can be used for log analysis).

Values:
  • -1: external HITL
  • 0: HITL and SIH disabled
  • 1: HITL enabled
  • 2: SIH enabled

Reboot required: true

0
SYS_MC_EST_GROUP (INT32) Set multicopter estimator group

Comment: Set the group of estimators used for multicopters and VTOLs

Values:
  • 1: local_position_estimator, attitude_estimator_q (unsupported)
  • 2: ekf2 (recommended)
  • 3: Q attitude estimator (no position)

Reboot required: true

2
SYS_RESTART_TYPE (INT32) Set restart type

Comment: Set by px4io to indicate type of restart

Values:
  • 0: Data survives resets
  • 1: Data survives in-flight resets only
  • 2: Data does not survive reset
0 > 2 2
SYS_STCK_EN (INT32) Enable stack checking Enabled (1)
SYS_USE_IO (INT32) Set usage of IO board

Comment: Can be used to use a standard startup script but with a FMU only set-up. Set to 0 to force the FMU only set-up.

Reboot required: true

0 > 1 Enabled (1)

Telemetry

NameDescriptionMin > Max (Incr.)DefaultUnits
TEL_BST_EN (INT32) Blacksheep telemetry Enable

Comment: If true, the FMU will try to connect to Blacksheep telemetry on start up

Reboot required: true

Disabled (0)
TEL_FRSKY_CONFIG (INT32) Serial Configuration for FrSky Telemetry

Comment: Configure on which serial port to run FrSky Telemetry.

Values:
  • 0: Disabled
  • 6: UART 6
  • 101: TELEM 1
  • 102: TELEM 2
  • 103: TELEM 3
  • 104: TELEM/SERIAL 4
  • 201: GPS 1
  • 202: GPS 2
  • 203: GPS 3
  • 300: Radio Controller
  • 301: Wifi Port

Reboot required: true

0
TEL_HOTT_CONFIG (INT32) Serial Configuration for HoTT Telemetry

Comment: Configure on which serial port to run HoTT Telemetry.

Values:
  • 0: Disabled
  • 6: UART 6
  • 101: TELEM 1
  • 102: TELEM 2
  • 103: TELEM 3
  • 104: TELEM/SERIAL 4
  • 201: GPS 1
  • 202: GPS 2
  • 203: GPS 3
  • 300: Radio Controller
  • 301: Wifi Port

Reboot required: true

0

Testing

NameDescriptionMin > Max (Incr.)DefaultUnits
TEST_1 (INT32) 2
TEST_2 (INT32) 4
TEST_3 (FLOAT) 5.0
TEST_D (FLOAT) 0.01
TEST_DEV (FLOAT) 2.0
TEST_D_LP (FLOAT) 10.0
TEST_HP (FLOAT) 10.0
TEST_I (FLOAT) 0.1
TEST_I_MAX (FLOAT) 1.0
TEST_LP (FLOAT) 10.0
TEST_MAX (FLOAT) 1.0
TEST_MEAN (FLOAT) 1.0
TEST_MIN (FLOAT) -1.0
TEST_P (FLOAT) 0.2
TEST_PARAMS (INT32) 12345678
TEST_RC2_X (INT32) 16
TEST_RC_X (INT32) 8
TEST_TRIM (FLOAT) 0.5

Thermal Compensation

NameDescriptionMin > Max (Incr.)DefaultUnits
TC_A0_ID (INT32) ID of Accelerometer that the calibration is for 0
TC_A0_TMAX (FLOAT) Accelerometer calibration maximum temperature 100.0
TC_A0_TMIN (FLOAT) Accelerometer calibration minimum temperature 0.0
TC_A0_TREF (FLOAT) Accelerometer calibration reference temperature 25.0
TC_A0_X0_0 (FLOAT) Accelerometer offset temperature ^0 polynomial coefficient - X axis 0.0
TC_A0_X0_1 (FLOAT) Accelerometer offset temperature ^0 polynomial coefficient - Y axis 0.0
TC_A0_X0_2 (FLOAT) Accelerometer offset temperature ^0 polynomial coefficient - Z axis 0.0
TC_A0_X1_0 (FLOAT) Accelerometer offset temperature ^1 polynomial coefficient - X axis 0.0
TC_A0_X1_1 (FLOAT) Accelerometer offset temperature ^1 polynomial coefficient - Y axis 0.0
TC_A0_X1_2 (FLOAT) Accelerometer offset temperature ^1 polynomial coefficient - Z axis 0.0
TC_A0_X2_0 (FLOAT) Accelerometer offset temperature ^2 polynomial coefficient - X axis 0.0
TC_A0_X2_1 (FLOAT) Accelerometer offset temperature ^2 polynomial coefficient - Y axis 0.0
TC_A0_X2_2 (FLOAT) Accelerometer offset temperature ^2 polynomial coefficient - Z axis 0.0
TC_A0_X3_0 (FLOAT) Accelerometer offset temperature ^3 polynomial coefficient - X axis 0.0
TC_A0_X3_1 (FLOAT) Accelerometer offset temperature ^3 polynomial coefficient - Y axis 0.0
TC_A0_X3_2 (FLOAT) Accelerometer offset temperature ^3 polynomial coefficient - Z axis 0.0
TC_A1_ID (INT32) ID of Accelerometer that the calibration is for 0
TC_A1_TMAX (FLOAT) Accelerometer calibration maximum temperature 100.0
TC_A1_TMIN (FLOAT) Accelerometer calibration minimum temperature 0.0
TC_A1_TREF (FLOAT) Accelerometer calibration reference temperature 25.0
TC_A1_X0_0 (FLOAT) Accelerometer offset temperature ^0 polynomial coefficient - X axis 0.0
TC_A1_X0_1 (FLOAT) Accelerometer offset temperature ^0 polynomial coefficient - Y axis 0.0
TC_A1_X0_2 (FLOAT) Accelerometer offset temperature ^0 polynomial coefficient - Z axis 0.0
TC_A1_X1_0 (FLOAT) Accelerometer offset temperature ^1 polynomial coefficient - X axis 0.0
TC_A1_X1_1 (FLOAT) Accelerometer offset temperature ^1 polynomial coefficient - Y axis 0.0
TC_A1_X1_2 (FLOAT) Accelerometer offset temperature ^1 polynomial coefficient - Z axis 0.0
TC_A1_X2_0 (FLOAT) Accelerometer offset temperature ^2 polynomial coefficient - X axis 0.0
TC_A1_X2_1 (FLOAT) Accelerometer offset temperature ^2 polynomial coefficient - Y axis 0.0
TC_A1_X2_2 (FLOAT) Accelerometer offset temperature ^2 polynomial coefficient - Z axis 0.0
TC_A1_X3_0 (FLOAT) Accelerometer offset temperature ^3 polynomial coefficient - X axis 0.0
TC_A1_X3_1 (FLOAT) Accelerometer offset temperature ^3 polynomial coefficient - Y axis 0.0
TC_A1_X3_2 (FLOAT) Accelerometer offset temperature ^3 polynomial coefficient - Z axis 0.0
TC_A2_ID (INT32) ID of Accelerometer that the calibration is for 0
TC_A2_TMAX (FLOAT) Accelerometer calibration maximum temperature 100.0
TC_A2_TMIN (FLOAT) Accelerometer calibration minimum temperature 0.0
TC_A2_TREF (FLOAT) Accelerometer calibration reference temperature 25.0
TC_A2_X0_0 (FLOAT) Accelerometer offset temperature ^0 polynomial coefficient - X axis 0.0
TC_A2_X0_1 (FLOAT) Accelerometer offset temperature ^0 polynomial coefficient - Y axis 0.0
TC_A2_X0_2 (FLOAT) Accelerometer offset temperature ^0 polynomial coefficient - Z axis 0.0
TC_A2_X1_0 (FLOAT) Accelerometer offset temperature ^1 polynomial coefficient - X axis 0.0
TC_A2_X1_1 (FLOAT) Accelerometer offset temperature ^1 polynomial coefficient - Y axis 0.0
TC_A2_X1_2 (FLOAT) Accelerometer offset temperature ^1 polynomial coefficient - Z axis 0.0
TC_A2_X2_0 (FLOAT) Accelerometer offset temperature ^2 polynomial coefficient - X axis 0.0
TC_A2_X2_1 (FLOAT) Accelerometer offset temperature ^2 polynomial coefficient - Y axis 0.0
TC_A2_X2_2 (FLOAT) Accelerometer offset temperature ^2 polynomial coefficient - Z axis 0.0
TC_A2_X3_0 (FLOAT) Accelerometer offset temperature ^3 polynomial coefficient - X axis 0.0
TC_A2_X3_1 (FLOAT) Accelerometer offset temperature ^3 polynomial coefficient - Y axis 0.0
TC_A2_X3_2 (FLOAT) Accelerometer offset temperature ^3 polynomial coefficient - Z axis 0.0
TC_A3_ID (INT32) ID of Accelerometer that the calibration is for 0
TC_A3_TMAX (FLOAT) Accelerometer calibration maximum temperature 100.0
TC_A3_TMIN (FLOAT) Accelerometer calibration minimum temperature 0.0
TC_A3_TREF (FLOAT) Accelerometer calibration reference temperature 25.0
TC_A3_X0_0 (FLOAT) Accelerometer offset temperature ^0 polynomial coefficient - X axis 0.0
TC_A3_X0_1 (FLOAT) Accelerometer offset temperature ^0 polynomial coefficient - Y axis 0.0
TC_A3_X0_2 (FLOAT) Accelerometer offset temperature ^0 polynomial coefficient - Z axis 0.0
TC_A3_X1_0 (FLOAT) Accelerometer offset temperature ^1 polynomial coefficient - X axis 0.0
TC_A3_X1_1 (FLOAT) Accelerometer offset temperature ^1 polynomial coefficient - Y axis 0.0
TC_A3_X1_2 (FLOAT) Accelerometer offset temperature ^1 polynomial coefficient - Z axis 0.0
TC_A3_X2_0 (FLOAT) Accelerometer offset temperature ^2 polynomial coefficient - X axis 0.0
TC_A3_X2_1 (FLOAT) Accelerometer offset temperature ^2 polynomial coefficient - Y axis 0.0
TC_A3_X2_2 (FLOAT) Accelerometer offset temperature ^2 polynomial coefficient - Z axis 0.0
TC_A3_X3_0 (FLOAT) Accelerometer offset temperature ^3 polynomial coefficient - X axis 0.0
TC_A3_X3_1 (FLOAT) Accelerometer offset temperature ^3 polynomial coefficient - Y axis 0.0
TC_A3_X3_2 (FLOAT) Accelerometer offset temperature ^3 polynomial coefficient - Z axis 0.0
TC_A_ENABLE (INT32) Thermal compensation for accelerometer sensors

Reboot required: true

Disabled (0)
TC_B0_ID (INT32) ID of Barometer that the calibration is for 0
TC_B0_TMAX (FLOAT) Barometer calibration maximum temperature 75.0
TC_B0_TMIN (FLOAT) Barometer calibration minimum temperature 5.0
TC_B0_TREF (FLOAT) Barometer calibration reference temperature 40.0
TC_B0_X0 (FLOAT) Barometer offset temperature ^0 polynomial coefficient 0.0
TC_B0_X1 (FLOAT) Barometer offset temperature ^1 polynomial coefficients 0.0
TC_B0_X2 (FLOAT) Barometer offset temperature ^2 polynomial coefficient 0.0
TC_B0_X3 (FLOAT) Barometer offset temperature ^3 polynomial coefficient 0.0
TC_B0_X4 (FLOAT) Barometer offset temperature ^4 polynomial coefficient 0.0
TC_B0_X5 (FLOAT) Barometer offset temperature ^5 polynomial coefficient 0.0
TC_B1_ID (INT32) ID of Barometer that the calibration is for 0
TC_B1_TMAX (FLOAT) Barometer calibration maximum temperature 75.0
TC_B1_TMIN (FLOAT) Barometer calibration minimum temperature 5.0
TC_B1_TREF (FLOAT) Barometer calibration reference temperature 40.0
TC_B1_X0 (FLOAT) Barometer offset temperature ^0 polynomial coefficient 0.0
TC_B1_X1 (FLOAT) Barometer offset temperature ^1 polynomial coefficients 0.0
TC_B1_X2 (FLOAT) Barometer offset temperature ^2 polynomial coefficient 0.0
TC_B1_X3 (FLOAT) Barometer offset temperature ^3 polynomial coefficient 0.0
TC_B1_X4 (FLOAT) Barometer offset temperature ^4 polynomial coefficient 0.0
TC_B1_X5 (FLOAT) Barometer offset temperature ^5 polynomial coefficient 0.0
TC_B2_ID (INT32) ID of Barometer that the calibration is for 0
TC_B2_TMAX (FLOAT) Barometer calibration maximum temperature 75.0
TC_B2_TMIN (FLOAT) Barometer calibration minimum temperature 5.0
TC_B2_TREF (FLOAT) Barometer calibration reference temperature 40.0
TC_B2_X0 (FLOAT) Barometer offset temperature ^0 polynomial coefficient 0.0
TC_B2_X1 (FLOAT) Barometer offset temperature ^1 polynomial coefficients 0.0
TC_B2_X2 (FLOAT) Barometer offset temperature ^2 polynomial coefficient 0.0
TC_B2_X3 (FLOAT) Barometer offset temperature ^3 polynomial coefficient 0.0
TC_B2_X4 (FLOAT) Barometer offset temperature ^4 polynomial coefficient 0.0
TC_B2_X5 (FLOAT) Barometer offset temperature ^5 polynomial coefficient 0.0
TC_B3_ID (INT32) ID of Barometer that the calibration is for 0
TC_B3_TMAX (FLOAT) Barometer calibration maximum temperature 75.0
TC_B3_TMIN (FLOAT) Barometer calibration minimum temperature 5.0
TC_B3_TREF (FLOAT) Barometer calibration reference temperature 40.0
TC_B3_X0 (FLOAT) Barometer offset temperature ^0 polynomial coefficient 0.0
TC_B3_X1 (FLOAT) Barometer offset temperature ^1 polynomial coefficients 0.0
TC_B3_X2 (FLOAT) Barometer offset temperature ^2 polynomial coefficient 0.0
TC_B3_X3 (FLOAT) Barometer offset temperature ^3 polynomial coefficient 0.0
TC_B3_X4 (FLOAT) Barometer offset temperature ^4 polynomial coefficient 0.0
TC_B3_X5 (FLOAT) Barometer offset temperature ^5 polynomial coefficient 0.0
TC_B_ENABLE (INT32) Thermal compensation for barometric pressure sensors

Reboot required: true

Disabled (0)
TC_G0_ID (INT32) ID of Gyro that the calibration is for 0
TC_G0_TMAX (FLOAT) Gyro calibration maximum temperature 100.0
TC_G0_TMIN (FLOAT) Gyro calibration minimum temperature 0.0
TC_G0_TREF (FLOAT) Gyro calibration reference temperature 25.0
TC_G0_X0_0 (FLOAT) Gyro rate offset temperature ^0 polynomial coefficient - X axis 0.0
TC_G0_X0_1 (FLOAT) Gyro rate offset temperature ^0 polynomial coefficient - Y axis 0.0
TC_G0_X0_2 (FLOAT) Gyro rate offset temperature ^0 polynomial coefficient - Z axis 0.0
TC_G0_X1_0 (FLOAT) Gyro rate offset temperature ^1 polynomial coefficient - X axis 0.0
TC_G0_X1_1 (FLOAT) Gyro rate offset temperature ^1 polynomial coefficient - Y axis 0.0
TC_G0_X1_2 (FLOAT) Gyro rate offset temperature ^1 polynomial coefficient - Z axis 0.0
TC_G0_X2_0 (FLOAT) Gyro rate offset temperature ^2 polynomial coefficient - X axis 0.0
TC_G0_X2_1 (FLOAT) Gyro rate offset temperature ^2 polynomial coefficient - Y axis 0.0
TC_G0_X2_2 (FLOAT) Gyro rate offset temperature ^2 polynomial coefficient - Z axis 0.0
TC_G0_X3_0 (FLOAT) Gyro rate offset temperature ^3 polynomial coefficient - X axis 0.0
TC_G0_X3_1 (FLOAT) Gyro rate offset temperature ^3 polynomial coefficient - Y axis 0.0
TC_G0_X3_2 (FLOAT) Gyro rate offset temperature ^3 polynomial coefficient - Z axis 0.0
TC_G1_ID (INT32) ID of Gyro that the calibration is for 0
TC_G1_TMAX (FLOAT) Gyro calibration maximum temperature 100.0
TC_G1_TMIN (FLOAT) Gyro calibration minimum temperature 0.0
TC_G1_TREF (FLOAT) Gyro calibration reference temperature 25.0
TC_G1_X0_0 (FLOAT) Gyro rate offset temperature ^0 polynomial coefficient - X axis 0.0
TC_G1_X0_1 (FLOAT) Gyro rate offset temperature ^0 polynomial coefficient - Y axis 0.0
TC_G1_X0_2 (FLOAT) Gyro rate offset temperature ^0 polynomial coefficient - Z axis 0.0
TC_G1_X1_0 (FLOAT) Gyro rate offset temperature ^1 polynomial coefficient - X axis 0.0
TC_G1_X1_1 (FLOAT) Gyro rate offset temperature ^1 polynomial coefficient - Y axis 0.0
TC_G1_X1_2 (FLOAT) Gyro rate offset temperature ^1 polynomial coefficient - Z axis 0.0
TC_G1_X2_0 (FLOAT) Gyro rate offset temperature ^2 polynomial coefficient - X axis 0.0
TC_G1_X2_1 (FLOAT) Gyro rate offset temperature ^2 polynomial coefficient - Y axis 0.0
TC_G1_X2_2 (FLOAT) Gyro rate offset temperature ^2 polynomial coefficient - Z axis 0.0
TC_G1_X3_0 (FLOAT) Gyro rate offset temperature ^3 polynomial coefficient - X axis 0.0
TC_G1_X3_1 (FLOAT) Gyro rate offset temperature ^3 polynomial coefficient - Y axis 0.0
TC_G1_X3_2 (FLOAT) Gyro rate offset temperature ^3 polynomial coefficient - Z axis 0.0
TC_G2_ID (INT32) ID of Gyro that the calibration is for 0
TC_G2_TMAX (FLOAT) Gyro calibration maximum temperature 100.0
TC_G2_TMIN (FLOAT) Gyro calibration minimum temperature 0.0
TC_G2_TREF (FLOAT) Gyro calibration reference temperature 25.0
TC_G2_X0_0 (FLOAT) Gyro rate offset temperature ^0 polynomial coefficient - X axis 0.0
TC_G2_X0_1 (FLOAT) Gyro rate offset temperature ^0 polynomial coefficient - Y axis 0.0
TC_G2_X0_2 (FLOAT) Gyro rate offset temperature ^0 polynomial coefficient - Z axis 0.0
TC_G2_X1_0 (FLOAT) Gyro rate offset temperature ^1 polynomial coefficient - X axis 0.0
TC_G2_X1_1 (FLOAT) Gyro rate offset temperature ^1 polynomial coefficient - Y axis 0.0
TC_G2_X1_2 (FLOAT) Gyro rate offset temperature ^1 polynomial coefficient - Z axis 0.0
TC_G2_X2_0 (FLOAT) Gyro rate offset temperature ^2 polynomial coefficient - X axis 0.0
TC_G2_X2_1 (FLOAT) Gyro rate offset temperature ^2 polynomial coefficient - Y axis 0.0
TC_G2_X2_2 (FLOAT) Gyro rate offset temperature ^2 polynomial coefficient - Z axis 0.0
TC_G2_X3_0 (FLOAT) Gyro rate offset temperature ^3 polynomial coefficient - X axis 0.0
TC_G2_X3_1 (FLOAT) Gyro rate offset temperature ^3 polynomial coefficient - Y axis 0.0
TC_G2_X3_2 (FLOAT) Gyro rate offset temperature ^3 polynomial coefficient - Z axis 0.0
TC_G3_ID (INT32) ID of Gyro that the calibration is for 0
TC_G3_TMAX (FLOAT) Gyro calibration maximum temperature 100.0
TC_G3_TMIN (FLOAT) Gyro calibration minimum temperature 0.0
TC_G3_TREF (FLOAT) Gyro calibration reference temperature 25.0
TC_G3_X0_0 (FLOAT) Gyro rate offset temperature ^0 polynomial coefficient - X axis 0.0
TC_G3_X0_1 (FLOAT) Gyro rate offset temperature ^0 polynomial coefficient - Y axis 0.0
TC_G3_X0_2 (FLOAT) Gyro rate offset temperature ^0 polynomial coefficient - Z axis 0.0
TC_G3_X1_0 (FLOAT) Gyro rate offset temperature ^1 polynomial coefficient - X axis 0.0
TC_G3_X1_1 (FLOAT) Gyro rate offset temperature ^1 polynomial coefficient - Y axis 0.0
TC_G3_X1_2 (FLOAT) Gyro rate offset temperature ^1 polynomial coefficient - Z axis 0.0
TC_G3_X2_0 (FLOAT) Gyro rate offset temperature ^2 polynomial coefficient - X axis 0.0
TC_G3_X2_1 (FLOAT) Gyro rate offset temperature ^2 polynomial coefficient - Y axis 0.0
TC_G3_X2_2 (FLOAT) Gyro rate offset temperature ^2 polynomial coefficient - Z axis 0.0
TC_G3_X3_0 (FLOAT) Gyro rate offset temperature ^3 polynomial coefficient - X axis 0.0
TC_G3_X3_1 (FLOAT) Gyro rate offset temperature ^3 polynomial coefficient - Y axis 0.0
TC_G3_X3_2 (FLOAT) Gyro rate offset temperature ^3 polynomial coefficient - Z axis 0.0
TC_G_ENABLE (INT32) Thermal compensation for rate gyro sensors

Reboot required: true

Disabled (0)

UAVCAN

NameDescriptionMin > Max (Incr.)DefaultUnits
CANNODE_BITRATE (INT32) UAVCAN CAN bus bitrate 20000 > 1000000 1000000
CANNODE_NODE_ID (INT32) UAVCAN Node ID

Comment: Read the specs at http://uavcan.org to learn more about Node ID.

1 > 125 120
UAVCAN_BAT_MON (INT32) UAVCAN BATTERY_MONITOR battery monitor selection

Comment: This parameter defines that the system will select the battery monitor under the following conditions 0 - default battery monitor 1 - CUAV battery monitor

Values:
  • 0: default battery monitor
  • 1: CUAV battery monitor

Reboot required: true

0 > 1 0
UAVCAN_BITRATE (INT32) UAVCAN CAN bus bitrate

Reboot required: true

20000 > 1000000 1000000 bit/s
UAVCAN_ENABLE (INT32) UAVCAN mode

Comment: 0 - UAVCAN disabled. 1 - Enables support for UAVCAN sensors without dynamic node ID allocation and firmware update. 2 - Enables support for UAVCAN sensors with dynamic node ID allocation and firmware update. 3 - Enables support for UAVCAN sensors and actuators with dynamic node ID allocation and firmware update. Also sets the motor control outputs to UAVCAN.

Values:
  • 0: Disabled
  • 1: Sensors Manual Config
  • 2: Sensors Automatic Config
  • 3: Sensors and Actuators (ESCs) Automatic Config

Reboot required: true

0 > 3 0
UAVCAN_ESC_IDLT (INT32) UAVCAN ESC will spin at idle throttle when armed, even if the mixer outputs zero setpoints

Reboot required: true

Enabled (1)
UAVCAN_LGT_ANTCL (INT32) UAVCAN ANTI_COLLISION light operating mode

Comment: This parameter defines the minimum condition under which the system will command the ANTI_COLLISION lights on 0 - Always off 1 - When autopilot is armed 2 - When autopilot is prearmed 3 - Always on

Values:
  • 0: Always off
  • 1: When autopilot is armed
  • 2: When autopilot is prearmed
  • 3: Always on

Reboot required: true

0 > 3 2
UAVCAN_LGT_LAND (INT32) UAVCAN LIGHT_ID_LANDING light operating mode

Comment: This parameter defines the minimum condition under which the system will command the LIGHT_ID_LANDING lights on 0 - Always off 1 - When autopilot is armed 2 - When autopilot is prearmed 3 - Always on

Values:
  • 0: Always off
  • 1: When autopilot is armed
  • 2: When autopilot is prearmed
  • 3: Always on

Reboot required: true

0 > 3 0
UAVCAN_LGT_NAV (INT32) UAVCAN RIGHT_OF_WAY light operating mode

Comment: This parameter defines the minimum condition under which the system will command the RIGHT_OF_WAY lights on 0 - Always off 1 - When autopilot is armed 2 - When autopilot is prearmed 3 - Always on

Values:
  • 0: Always off
  • 1: When autopilot is armed
  • 2: When autopilot is prearmed
  • 3: Always on

Reboot required: true

0 > 3 3
UAVCAN_LGT_STROB (INT32) UAVCAN STROBE light operating mode

Comment: This parameter defines the minimum condition under which the system will command the STROBE lights on 0 - Always off 1 - When autopilot is armed 2 - When autopilot is prearmed 3 - Always on

Values:
  • 0: Always off
  • 1: When autopilot is armed
  • 2: When autopilot is prearmed
  • 3: Always on

Reboot required: true

0 > 3 1
UAVCAN_NODE_ID (INT32) UAVCAN Node ID

Comment: Read the specs at http://uavcan.org to learn more about Node ID.

Reboot required: true

1 > 125 1
UAVCAN_RNG_MAX (FLOAT) UAVCAN rangefinder maximum range

Comment: This parameter defines the maximum valid range for a rangefinder connected via UAVCAN.

200.0 m
UAVCAN_RNG_MIN (FLOAT) UAVCAN rangefinder minimum range

Comment: This parameter defines the minimum valid range for a rangefinder connected via UAVCAN.

0.3 m

UAVCAN v1

NameDescriptionMin > Max (Incr.)DefaultUnits
UAVCAN_V1_BAUD (INT32) UAVCAN/CAN v1 bus bitrate

Reboot required: true

20000 > 1000000 1000000 bit/s
UAVCAN_V1_ENABLE (INT32) UAVCAN v1

Comment: 0 - UAVCAN disabled. 1 - Enables UAVCANv1

Reboot required: true

Disabled (0)
UCAN1_ACTR_PUB (INT32) actuator_outputs uORB over UAVCAN v1 publication port ID -1 > 6143 -1
UCAN1_BMS_BP_SUB (INT32) DS-015 battery parameters subscription port ID -1 > 6143 -1
UCAN1_BMS_BS_SUB (INT32) DS-015 battery status subscription port ID -1 > 6143 -1
UCAN1_BMS_ES_SUB (INT32) DS-015 battery energy source subscription port ID -1 > 6143 -1
UCAN1_ESC0_SUB (INT32) ESC 0 subscription port ID -1 > 6143 -1
UCAN1_ESC_PUB (INT32) UAVCAN v1 ESC publication port ID -1 > 6143 -1
UCAN1_GPS0_SUB (INT32) GPS 0 subscription port ID -1 > 6143 -1
UCAN1_GPS1_SUB (INT32) GPS 1 subscription port ID -1 > 6143 -1
UCAN1_GPS_PUB (INT32) UAVCAN v1 GPS publication port ID -1 > 6143 -1
UCAN1_LG_BMS_SUB (INT32) UAVCAN v1 leagcy battery port ID -1 > 6143 -1
UCAN1_SERVO_PUB (INT32) UAVCAN v1 Servo publication port ID -1 > 6143 -1
UCAN1_UORB_GPS (INT32) sensor_gps uORB over UAVCAN v1 subscription port ID -1 > 6143 -1

UAVCANv1

NameDescriptionMin > Max (Incr.)DefaultUnits
UAVCAN_V1_ID (INT32) UAVCAN v1 Node ID

Comment: Read the specs at http://uavcan.org to learn more about Node ID.

Reboot required: true

1 > 125 1

UUV Attitude Control

NameDescriptionMin > Max (Incr.)DefaultUnits
UUV_DIRCT_PITCH (FLOAT) Direct pitch input 0.0
UUV_DIRCT_ROLL (FLOAT) Direct roll input 0.0
UUV_DIRCT_THRUST (FLOAT) Direct thrust input 0.0
UUV_DIRCT_YAW (FLOAT) Direct yaw input 0.0
UUV_INPUT_MODE (INT32) Select Input Mode Values:
  • 0: use Attitude Setpoints
  • 1: Direct Feedthrough
0
UUV_PITCH_D (FLOAT) Pitch differential gain 2.0
UUV_PITCH_P (FLOAT) Pitch proportional gain 4.0
UUV_ROLL_D (FLOAT) Roll differential gain 1.5
UUV_ROLL_P (FLOAT) Roll proportional gain 4.0
UUV_YAW_D (FLOAT) Yaw differential gain 2.0
UUV_YAW_P (FLOAT) Yawh proportional gain 4.0

UUV Position Control

NameDescriptionMin > Max (Incr.)DefaultUnits
UUV_GAIN_X_D (FLOAT) Gain of D controller X 0.2
UUV_GAIN_X_P (FLOAT) Gain of P controller X 1.0
UUV_GAIN_Y_D (FLOAT) Gain of D controller Y 0.2
UUV_GAIN_Y_P (FLOAT) Gain of P controller Y 1.0
UUV_GAIN_Z_D (FLOAT) Gain of D controller Z 0.2
UUV_GAIN_Z_P (FLOAT) Gain of P controller Z 1.0
UUV_STAB_MODE (INT32) Stabilization mode(1) or Position Control(0) Values:
  • 0: Position Control
  • 1: Stabilization Mode
1

VTOL Attitude Control

NameDescriptionMin > Max (Incr.)DefaultUnits
VT_ARSP_BLEND (FLOAT) Transition blending airspeed

Comment: Airspeed at which we can start blending both fw and mc controls. Set to 0 to disable.

0.00 > 30.00 (1) 8.0 m/s
VT_ARSP_TRANS (FLOAT) Transition airspeed

Comment: Airspeed at which we can switch to fw mode

0.00 > 30.00 (1) 10.0 m/s
VT_B_DEC_FF (FLOAT) Backtransition deceleration setpoint to pitch feedforward gain 0 > 0.2 (0.05) 0.12 rad s^2/m
VT_B_DEC_I (FLOAT) Backtransition deceleration setpoint to pitch I gain 0 > 0.3 (0.05) 0.1 rad s/m
VT_B_DEC_MSS (FLOAT) Approximate deceleration during back transition

Comment: The approximate deceleration during a back transition in m/s/s Used to calculate back transition distance in mission mode. A lower value will make the VTOL transition further from the destination waypoint. For standard vtol and tiltrotors a controller is used to track this value during the transition.

0.5 > 10 (0.1) 2.0 m/s^2
VT_B_REV_DEL (FLOAT) Delay in seconds before applying back transition throttle

Comment: Set this to a value greater than 0 to give the motor time to spin down. unit s

0 > 10 (1) 0.0
VT_B_REV_OUT (FLOAT) Output on airbrakes channel during back transition

Comment: Used for airbrakes or with ESCs that have reverse thrust enabled on a seperate channel Airbrakes need to be enables for your selected model/mixer

0 > 1 (0.01) 0.0
VT_B_TRANS_DUR (FLOAT) Duration of a back transition

Comment: Time in seconds used for a back transition

0.00 > 20.00 (1) 4.0 s
VT_B_TRANS_RAMP (FLOAT) Back transition MC motor ramp up time

Comment: This sets the duration during which the MC motors ramp up to the commanded thrust during the back transition stage.

0.0 > 20.0 3.0 s
VT_B_TRANS_THR (FLOAT) Target throttle value for the transition to hover flight

Comment: standard vtol: pusher tailsitter, tiltrotor: main throttle Note for standard vtol: For ESCs and mixers that support reverse thrust on low PWM values set this to a negative value to apply active breaking For ESCs that support thrust reversal with a control channel please set VT_B_REV_OUT and set this to a positive value to apply active breaking

-1 > 1 (0.01) 0.0
VT_DWN_PITCH_MAX (FLOAT) Maximum allowed angle the vehicle is allowed to pitch down to generate forward force

Comment: When fixed-wing forward actuation is active (see VT_FW_TRHUST_EN). If demanded down pitch exceeds this limmit, the fixed-wing forward actuators are used instead.

0.0 > 45.0 5.0
VT_ELEV_MC_LOCK (INT32) Lock elevons in multicopter mode

Comment: If set to 1 the elevons are locked in multicopter mode

Enabled (1)
VT_FWD_THRUST_EN (INT32) Enable/disable usage of fixed-wing actuators in hover to generate forward force (instead of pitching down)

Comment: This technique can be used to avoid the plane having to pitch down in order to move forward. This prevents large, negative lift values being created when facing strong winds. Fixed-wing forward actuators refers to puller/pusher (standard VTOL), or forward-tilt (tiltrotor VTOL). Only active if demaded down pitch is above VT_DWN_PITCH_MAX, and uses VT_FWD_THRUST_SC to get from demanded down pitch to fixed-wing actuation.

Values:
  • 0: Disable FW forward actuation in hover.
  • 1: Enable FW forward actuation in hover in altitude, position and auto modes (except LANDING).
  • 2: Enable FW forward actuation in hover in altitude, position and auto modes if above MPC_LAND_ALT1.
  • 3: Enable FW forward actuation in hover in altitude, position and auto modes if above MPC_LAND_ALT2.
  • 4: Enable FW forward actuation in hover in altitude, position and auto modes.
  • 5: Enable FW forward actuation in hover in altitude, position and auto modes if above MPC_LAND_ALT1 (except LANDING).
  • 6: Enable FW forward actuation in hover in altitude, position and auto modes if above MPC_LAND_ALT2 (except LANDING).
0
VT_FWD_THRUST_SC (FLOAT) Fixed-wing actuator thrust scale for hover forward flight

Comment: Scale applied to the demanded down-pitch to get the fixed-wing forward actuation in hover mode. Only active if demaded down pitch is above VT_DWN_PITCH_MAX. Enabled via VT_FWD_THRUST_EN.

0.0 > 2.0 0.7
VT_FW_ALT_ERR (FLOAT) Adaptive QuadChute

Comment: Maximum negative altitude error for fixed wing flight. If the altitude drops below this value below the altitude setpoint the vehicle will transition back to MC mode and enter failsafe RTL.

0.0 > 200.0 0.0
VT_FW_DIFTHR_EN (INT32) Differential thrust in forwards flight

Comment: Set to 1 to enable differential thrust in fixed-wing flight.

0 > 1 0
VT_FW_DIFTHR_SC (FLOAT) Differential thrust scaling factor

Comment: This factor specifies how the yaw input gets mapped to differential thrust in forwards flight.

0.0 > 1.0 (0.1) 0.1
VT_FW_MIN_ALT (FLOAT) QuadChute Altitude

Comment: Minimum altitude for fixed wing flight, when in fixed wing the altitude drops below this altitude the vehicle will transition back to MC mode and enter failsafe RTL

0.0 > 200.0 0.0
VT_FW_MOT_OFFID (INT32) The channel number of motors that must be turned off in fixed wing mode 0 > 12345678 (1) 0
VT_FW_PERM_STAB (INT32) Permanent stabilization in fw mode

Comment: If set to one this parameter will cause permanent attitude stabilization in fw mode. This parameter has been introduced for pure convenience sake.

Disabled (0)
VT_FW_QC_P (INT32) QuadChute Max Pitch

Comment: Maximum pitch angle before QuadChute engages Above this the vehicle will transition back to MC mode and enter failsafe RTL

0 > 180 0
VT_FW_QC_R (INT32) QuadChute Max Roll

Comment: Maximum roll angle before QuadChute engages Above this the vehicle will transition back to MC mode and enter failsafe RTL

0 > 180 0
VT_F_TRANS_DUR (FLOAT) Duration of a front transition

Comment: Time in seconds used for a transition

0.00 > 20.00 (1) 5.0 s
VT_F_TRANS_THR (FLOAT) Target throttle value for the transition to fixed wing flight

Comment: standard vtol: pusher tailsitter, tiltrotor: main throttle

0.0 > 1.0 (0.01) 1.0
VT_F_TR_OL_TM (FLOAT) Airspeed less front transition time (open loop)

Comment: The duration of the front transition when there is no airspeed feedback available.

1.0 > 30.0 6.0 s
VT_IDLE_PWM_MC (INT32) Idle speed of VTOL when in multicopter mode 900 > 2000 (1) 900 us
VT_MC_ON_FMU (INT32) Enable the usage of AUX outputs for hover motors

Comment: Set this parameter to true if the vehicle's hover motors are connected to the FMU (AUX) port. Not required for boards that only have a FMU, and no IO. Only applies for standard VTOL and tiltrotor.

Disabled (0)
VT_MOT_ID (INT32) The channel number of motors which provide lift during hover 0 > 12345678 (1) 0
VT_PSHER_RMP_DT (FLOAT) Pusher throttle ramp up window

Comment: Defines the time window during which the pusher throttle will be ramped up linearly to VT_F_TRANS_THR during a transition to fixed wing mode. Zero or negative values will produce an instant throttle rise to VT_F_TRANS_THR.

? > 20 (0.01) 3.0
VT_TILT_FW (FLOAT) Position of tilt servo in fw mode 0.0 > 1.0 (0.01) 1.0
VT_TILT_MC (FLOAT) Position of tilt servo in mc mode 0.0 > 1.0 (0.01) 0.0
VT_TILT_SPINUP (FLOAT) Tilt actuator control value commanded when disarmed and during the first second after arming

Comment: This specific tilt during spin-up is necessary for some systems whose motors otherwise don't spin-up freely.

0.0 > 1.0 (0.01) 0.0
VT_TILT_TRANS (FLOAT) Position of tilt servo in transition mode 0.0 > 1.0 (0.01) 0.3
VT_TRANS_MIN_TM (FLOAT) Front transition minimum time

Comment: Minimum time in seconds for front transition.

0.0 > 20.0 2.0 s
VT_TRANS_P2_DUR (FLOAT) Duration of front transition phase 2

Comment: Time in seconds it should take for the rotors to rotate forward completely from the point when the plane has picked up enough airspeed and is ready to go into fixed wind mode.

0.1 > 5.0 (0.01) 0.5 s
VT_TRANS_TIMEOUT (FLOAT) Front transition timeout

Comment: Time in seconds after which transition will be cancelled. Disabled if set to 0.

0.00 > 30.00 (1) 15.0 s
VT_TYPE (INT32) VTOL Type (Tailsitter=0, Tiltrotor=1, Standard=2) Values:
  • 0: Tailsitter
  • 1: Tiltrotor
  • 2: Standard

Reboot required: true

0 > 2 0
WV_GAIN (FLOAT) Weather-vane roll angle to yawrate

Comment: The desired gain to convert roll sp into yaw rate sp.

0.0 > 3.0 (0.01) 1.0 Hz

Vehicle Model

NameDescriptionMin > Max (Incr.)DefaultUnits
VM_INERTIA_XX (FLOAT) Inertia matrix, XX component (0.00001) 0.01 kg m^2
VM_INERTIA_XY (FLOAT) Inertia matrix, XY component (0.00001) 0. kg m^2
VM_INERTIA_XZ (FLOAT) Inertia matrix, XZ component (0.00001) 0. kg m^2
VM_INERTIA_YY (FLOAT) Inertia matrix, YY component (0.00001) 0.01 kg m^2
VM_INERTIA_YZ (FLOAT) Inertia matrix, YZ component (0.00001) 0. kg m^2
VM_INERTIA_ZZ (FLOAT) Inertia matrix, ZZ component (0.00001) 0.01 kg m^2
VM_MASS (FLOAT) Mass (0.00001) 1. kg

Miscellaneous

NameDescriptionMin > Max (Incr.)DefaultUnits
EXFW_HDNG_P (FLOAT) 0.1
EXFW_PITCH_P (FLOAT) 0.2
EXFW_ROLL_P (FLOAT) 0.2
MPC_LAND_RC_HELP (INT32) Enable user assisted descent speed for autonomous land routine

Comment: When enabled, descent speed will be: stick full up - 0 stick centered - MPC_LAND_SPEED stick full down - 2 * MPC_LAND_SPEED

Values:
  • 0: Fixed descent speed of MPC_LAND_SPEED
  • 1: User assisted descent speed
0 > 1 0
RV_YAW_P (FLOAT) 0.1
UUV_SKIP_CTRL (INT32) Skip the controller Values:
  • 0: use the module's controller
  • 1: skip the controller and feedthrough the setpoints
0

land_detector - APM, Mission-planner

Land Detector Configuration

The land detector is a dynamic vehicle model representing key vehicle states from ground contact through to landed. This topic explains the main parameters you may wish to tune in order to improve landing behaviour.

Auto-Disarming

The land-detector automatically disarms the vehicle on landing.

You can set COM_DISARM_LAND to specify the number of seconds after landing that the system should disarm (or turn off auto-disarming by setting the parameter to -1).

Multicopter Configuration

The complete set of relevant landing detector parameters are listed in the parameter reference with the prefix LNDMC (these can be edited in QGroundControl via the parameter editor).

:::tip Information about how the parameters affect landing can be found below in Land Detector States. :::

Other key parameters that you may need to tune in order to improve landing behaviour on particular airframes are:

  • MPC_THR_HOVER - the hover throttle of the system (default is 50%). It is important to set this correctly as it makes altitude control more accurate and ensures correct land detection. A racer or a big camera drone without payload mounted might need a much lower setting (e.g. 35%).

    :::note Incorrectly setting MPC_THR_HOVER may result in ground-contact or maybe-landed detection while still in air (in particular, while descending in Position mode or Altitude mode). This causes the vehicle to “twitch” (turn down the motors, and then immediately turn them back up). :::

  • MPC_THR_MIN - the overall minimum throttle of the system. This should be set to enable a controlled descent.

Fixed Wing Configuration

The complete set of relevant parameters is available under the LNDFW prefix. These two parameters are sometimes worth tuning:

  • LNDFW_AIRSPD_MAX - the maximum airspeed allowed for the system still to be considered landed. The default of 8 m/s is a reliable tradeoff between airspeed sensing accuracy and triggering fast enough. Better airspeed sensors should allow lower values of this parameter.
  • LNDFW_VEL_XY_MAX - the maximum horizontal velocity for the system to be still be considered landed.
  • LNDFW_VEL_Z_MAX - the maximum vertical velocity for the system to be still be considered landed. This parameter can be adjusted to ensure land detection triggers earlier or later on throwing the airframe for hand-launches.

Land Detector States

Multicopter Land Detection

In order to detect landing, the multicopter first has to go through three different states, where each state contains the conditions from the previous states plus tighter constraints. If a condition cannot be reached because of missing sensors, then the condition is true by default. For instance, in Acro mode and no sensor is active except for the gyro sensor, then the detection solely relies on thrust output and time.

In order to proceed to the next state, each condition has to be true for some predefined time. If one condition fails, the land detector drops out of the current state immediately.

Ground Contact

This state is reached if following conditions are true for 0.35 seconds:

If the vehicle is in position- or velocity-control and ground contact was detected, the position controller will set the thrust vector along the body x-y-axis to zero.

Maybe Landed

This state is reached if following conditions are true for 0.25 seconds:

  • all conditions of ground contact are true
  • is not rotating (LNDMC_ROT_MAX)
  • has low thrust MPC_THR_MIN + (MPC_THR_HOVER - MPC_THR_MIN) * 0.1

If the vehicle only has knowledge of thrust and angular rate, in order to proceed to the next state the vehicle has to have low thrust and no rotation for 8.0 seconds.

If the vehicle is in position or velocity control and maybe landed was detected, the position controller will set the thrust vector to zero.

Landed

This state is reached if following conditions are true for 0.3 seconds:

  • all conditions of maybe landed are true

flight_termination - APM, Mission-planner

Flight Termination Configuration

The Flight termination failsafe action may be triggered by a safety check (e.g. RC Loss, geofence violation, etc. on any vehicle type or in any flight mode), or by the Failure Detector.

When Flight termination is activated, PX4 simultaneously turns off all controllers and sets all PWM outputs to their failsafe values.

Depending on what devices are connected, the PWM failsafe outputs can be used to:

  • Deploy a parachute.
  • Extend retractable landing gear.
  • Move a PWM-connected gimbal to a safe orientation (or retract it) in order to protect the camera.
  • Trigger an inflatable device like an airbag.
  • Trigger an alarm.

There is no way to recover from flight termination. After triggering you should unplug the battery as soon as possible. You will need to reboot/power cycle the vehicle before it can be used again.

:::tip PX4 does not know what safety devices are attached - it just applies a predefined set of PWM values to its outputs. :::

:::tip Failsafe values are applied to all outputs on termination. There is no way to configure independent time-based (or other) triggering of the motors or specific safety devices. :::

:::note This is not an independent Flight Termination System. If power is lost or if the autopilot crashes completely, the failsafe devices will not be triggered. :::

Hardware Configuration

Any safety device(s) (e.g. a parachute) that can be triggered by changing a PWM value can be used, and may be connected to any free PWM port (both MAIN and AUX).

:::note If you’re using Pixhawk-series board you will have to separately power the servo rail (i.e. from a 5V BEC, which is often also available from your ESC). :::

Software Configuration

The Safety topic explains how to set the flight termination as the failsafe action to be performed for particular failsafe check.

The Failure Detector can also (optionally) be configured to trigger flight termination if the vehicle flips (exceeds a certain attitude) or if failure is detected by an external automatic trigger system (ATS):

For each MAIN output to which a safety device is attached, where “n” is the PWM port number, set:

For each AUX output to which a safety device is attached, where “n” is the PWM port number, set:

Finally, set the PWM_AUX_FAILn and PWM_MAIN_FAILn PWM values for any motors.

Logic Diagram

The diagram below shows the logical flow around flight termination.

Logic diagram

esc_calibration - APM, Mission-planner

ESC Calibration

:::note These instructions are only relevant to PWM ESCs. :::

Electronic Speed Controllers (ESCs) regulate motor speed (and direction) based on the PWM input value from the flight controller (FC). The range of inputs to which an ESC will respond is configurable, and the default range can differ even between ESCs of the same model.

This calibration updates all the ESCs with the maximum and minimum PWM input values that will be supplied by the flight controller. Subsequently all the ESCs/motors will respond to flight controller input in the same way (across the whole input range).

Calibration is recommended for all ESCs, and in particular for low cost models.

Preconditions

The system must include a power module (PX4 uses the measured voltage to determine whether or not a battery is connected).

Steps

To calibrate the ESCs:

  1. Remove the propellers.

    :::warning Never attempt ESC calibration with props on.

    The motors should not spin during ESC calibration. However if an ESC doesn’t properly support/detect the calibration sequence then it will respond to the PWM input by running the motor at maximum speed. :::

  2. Disconnect the battery and connect the flight controller via USB (only).
  3. Open the QGroundControl Settings > Power, then press the Calibrate button.

    ESC Calibration step 1

  4. Connect the battery when prompted:

    ESC Calibration step 2

    The calibration will begin automatically:

    ESC Calibration step 3

  5. Once the calibration complete you will be prompted to disconnect the battery.

    ESC Calibration step 4

:::note High-quality controllers come with a factory calibration. In theory this means that they can be configured by just setting the PWM_MAIN_MINn/PWM_AUX_MINn and PWM_MAIN_MAXn/PWM_AUX_MAXn parameters to the values provided in the ESC technical specification. In practice the input range may differ even on high quality controllers, which is why calibration is recommended. :::

compass_power_compensation - APM, Mission-planner

Compass Power Compensation

Compasses (magnetometers) should be mounted as far as possible from cables that carry large currents, as these induce magnetic fields that may corrupt the compass readings.

This topic explains how to compensate for the induced magnetic fields in the cases where moving the compass is not realistic.

:::tip Moving the compass away from power-carrying cables is the easiest and most effective way to fix this issue, because the strength of the magnetic fields decreases quadratically with the distance from the cable. :::

:::note The process is demonstrated for a multicopter, but is equally valid for other vehicle types. :::

When is Power Compensation Applicable?

Performing this power compensation is advisable only if all the following statements are true:

  1. The compass cannot be moved away from the power-carrying cables.
  2. There is a strong correlation between the compass readings and the thrust setpoint, and/or the battery current. Corrupted mag

  3. The drone cables are all fixed in place/do not move (calculated compensation parameters will be invalid if the current-carrying cables can move).

How to Compensate the Compass

  1. Make sure your drone runs a Firmware version supporting power compensation (current master, or releases from v.1.11.0).
  2. Perform the standard compass calibration.
  3. Set the parameter SDLOG_MODE to 2 to enable logging of data from boot.
  4. Set the parameter SDLOG_PROFILE checkbox for high rate (bit 2) to get more data points.
  5. Secure the drone so that it cannot move, and attach the propellers (so the motors can draw the same current as in flight). This example secures the vehicle using straps.

    strap

  6. Power the vehicle and switch into ACRO flight mode (using this mode ensures the vehicle won’t attempt to compensate for movement resulting from the straps).
    • Arm the vehicle and slowly raise the throttle to the maximum
    • Slowly lower the throttle down to zero
    • Disarm the vehicle

    :::note Perform the test carefully and closely monitor the vibrations. :::

  7. Retrieve the ulog and use the python script mag_compensation.py to identify the compensation parameters.
    python mag_compensation.py ~/path/to/log/logfile.ulg
    

    :::note If your log does not contain battery current measurements, you will need to comment out the respective lines in the python script, such that it does the calculation for thrust only. :::

  8. The script will return the parameter identification for thrust as well as for current and print them to the console. The figures that pop up from the script show the “goodness of fit” for each compass instance, and how the data would look if compensated with the suggested values. If a current measurement is available, using the current-compensation usually yields the better results. Here is an example of a log, where the current fit is good, but the thrust parameters are unusable as the relationship is not linear. line fit

  9. Once the parameters are identified, the power compensation must be enabled by setting CAL_MAG_COMP_TYP to 1 (when using thrust parameters) or 2 (when using current parameters). Additionally, the compensation parameters for each axis of each compass must be set.

    comp params

bootloader_update_from_betaflight - APM, Mission-planner

Bootloader Flashing onto Betaflight Systems

This page documents how to flash the PX4 bootloader onto boards preflashed with Betaflight (e.g. OmnibusF4 SD or Kakute F7).

There are two options for flashing the bootloader: via Betaflight Configurator (easier), or building from source.

Bootloader Update using Betaflight Configurator

To install the PX4 bootloader using the Betaflight Configurator:

  1. You should have downloaded already the pre-built bootloader binary (this depends on the board you want to flash).
  2. Download the Betaflight Configurator for your platform. :::tip If using the Chrome web browser, a simple cross-platform alternative is to install the configurator as an extension from here. :::
  3. Connect the board to your PC and start the Configurator.
  4. Press the Load Firmware [Local] button Betaflight Configurator - Local Firmware
  5. Select the bootloader binary from the file system and then flash the board.

You should now be able to install PX4 firmware on the board.

Bootloader Update using Source

Download Bootloader Source

Download and build the Bootloader via:

git clone --recursive  https://github.com/PX4/Bootloader.git
cd Bootloader
make <target> # For example: omnibusf4sd_bl or kakutef7_bl

Flash Bootloader

You can flash the PX4 bootloader using the dfu-util or the graphical dfuse tool on windows.

Don’t be afraid to try flashing using any of the methods below.

:::note The STM32 MCU cannot be bricked. DFU cannot be overwritten by flashing and will always allow you to install a new firmware, even if flashing fails. :::

Enter DFU mode

Both methods require the board to be in DFU mode. To enter DFU mode, hold the boot button down while connecting the USB cable to your computer. The button can be released after the board is powered up.

dfu-util
dfu-util -a 0 --dfuse-address 0x08000000 -D  build/<target>/<target>.bin

Reboot the flight controller and it let it boot without holding the boot button.

dfuse

See the dfuse manual here: https://www.st.com/resource/en/user_manual/cd00155676.pdf

Flash the **.bin** file.

Reinstall Betaflight

In order to switch back to Betaflight:

  • Backup the PX4 parameters, e.g. by exporting them to an SD card
  • Keep the bootloader button pressed while attaching the USB cable
  • Then flash Betaflight as usual with the Betaflight-configurator

bootloader_update - APM, Mission-planner

Bootloader Update

The PX4 bootloader is used to load firmware for Pixhawk boards (PX4FMU, PX4IO) and PX4FLOW.

This topic explains several methods for updating the Pixhawk bootloader.

:::note Hardware usually comes with an appropriate bootloader version pre-installed. A case where you may need to update is newer Pixhawk boards that install FMUv2 firmware: Firmware > FMUv2 Bootloader Update. :::

Building the new PX4 bootloader yourself

Boards starting with FMUv6X (STM32H7) use the in-tree PX4 bootloader. Older boards use the bootloader from the legacy PX4 bootloader repository. Please refer to the instructions in the README to learn how to use it.

Build the new bootloader in the PX4-Autopilot folder with:

make px4_fmu-v6x_bootloader

Which will build the bootloader binary as build/px4_fmu-v6x_bootloader/px4_fmu-v6x_bootloader.elf which can be flashed via SWD or DFU. If you are building the bootloader you should be familiar with one of these options already.

If you need a HEX file instead of an ELF file, use objcopy:

arm-none-eabi-objcopy -O ihex build/px4_fmu-v6x_bootloader/px4_fmu-v6x_bootloader.elf px4_fmu-v6x_bootloader.hex

QGroundControl Bootloader Update

The easiest approach is to first use QGroundControl to install firmware with the desired/latest bootloader. You can then initiate bootloader update on next restart by setting the parameter: SYS_BL_UPDATE.

:::note This approach can only be used if SYS_BL_UPDATE is present in firmware (currently just FMUv2 and some custom firmware). :::

The steps are:

  1. Insert an SD card (enables boot logging to debug any problems).
  2. Update the Firmware with an image containing the new/desired bootloader. :::note The updated bootloader might be supplied in custom firmware (i.e. from the dev team), or it or may be included in the latest master. :::

    FMUv2 update

  3. Wait for the vehicle to reboot.
  4. Find and enable the parameter SYS_BL_UPDATE.
  5. Reboot (disconnect/reconnect the board). The bootloader update will only take a few seconds.

Generally at this point you may then want to update the firmware again using the correct/newly installed bootloader.

Dronecode Probe Bootloader Update

The following steps explain how you can “manually” update the bootloader using the dronecode probe:

  1. Get a binary containing the bootloader (either from dev team or build it yourself).
  2. Connect the Dronecode probe to your PC via USB.
  3. Go into the directory containing the binary and run the following command in the terminal:
    arm-none-eabi-gdb px4fmuv5_bl.elf
    
  4. The gdb terminal appears and it should display the following output:
    GNU gdb (GNU Tools for Arm Embedded Processors 7-2017-q4-major) 8.0.50.20171128-git
    Copyright (C) 2017 Free Software Foundation, Inc.
    License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
    This is free software: you are free to change and redistribute it.
    There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
    and "show warranty" for details.
    This GDB was configured as "--host=x86_64-linux-gnu --target=arm-none-eabi".
    Type "show configuration" for configuration details.
    For bug reporting instructions, please see:
    <http://www.gnu.org/software/gdb/bugs/>.
    Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.
    For help, type "help".
    Type "apropos word" to search for commands related to "word"...
    Reading symbols from px4fmuv5_bl.elf...done.
    
  5. Find your <dronecode-probe-id> by running an ls command in the /dev/serial/by-id directory.
  6. Now connect to the Dronecode probe with the following command:
    tar ext /dev/serial/by-id/<dronecode-probe-id>
    
  7. Power on the Pixhawk with another USB cable and connect the Dronecode probe to the FMU-DEBUG port.

    :::note To be able to connect the Dronecode probe to the FMU-DEBUG port, you may need to remove the case (e.g. on Pixhawk 4 you would do this using a T6 Torx screwdriver). :::

  8. Use the following command to scan for the Pixhawk’s swd and connect to it:
    (gdb) mon swdp_scan
    (gdb) attach 1
    
  9. Load the binary into the Pixhawk:
    (gdb) load
    

After the bootloader has updated you can Load PX4 Firmware using QGroundControl.

Other Boards (Non-Pixhawk)

Boards that are not part of the Pixhawk Series will have their own mechanisms for bootloader update.

For boards that are preflashed with Betaflight, see Bootloader Flashing onto Betaflight Systems.

advanced_flight_controller_orientation_leveling - APM, Mission-planner

Advanced Flight Controller Orientation Tuning

The orientation and horizon level may be fine-tuned manually with parameters to correct for sensor board small misalignment or minor calibration errors.

:::note These instructions are not recommended for regular users. For basic settings stick to the instructions linked below:

If there is a persistent drift bias (often seen in multirotors but not limited to them), it is a good strategy to trim it with the help of this fine-tuning offset angle parameters instead of using the trimmers of your RC Transmitter. This way when in fully autonomous flight the aircraft will maintain the trimming.

Setting Orientation Parameters

To change the orientation parameters:

  1. Open QGroundControl menu: Settings > Parameters > Sensor Calibration.
  2. Change the parameters as shown below: FC Orientation QGC v2

Parameter information

The SENS_BOARD_ROT parameter defines the rotation relative to the platform, while the X,Y and Z fine tuning offsets are fixed relative to the board itself. What happens is that the fine tuning offsets are added to the SENS_BOARD_ROT angle in order to get the total offset angles for the Yaw, Pitch and Roll orientation of the flight controller.

SENS_BOARD_ROT

This parameter defines the rotation of the FMU board relative to the platform. Possible values are:

  • 0 = No rotation
  • 1 = Yaw 45°
  • 2 = Yaw 90°
  • 3 = Yaw 135°
  • 4 = Yaw 180°
  • 5 = Yaw 225°
  • 6 = Yaw 270°
  • 7 = Yaw 315°
  • 8 = Roll 180°
  • 9 = Roll 180°, Yaw 45°
  • 10 = Roll 180°, Yaw 90°
  • 11 = Roll 180°, Yaw 135°
  • 12 = Pitch 180°
  • 13 = Roll 180°, Yaw 225°
  • 14 = Roll 180°, Yaw 270°
  • 15 = Roll 180°, Yaw 315°
  • 16 = Roll 90°
  • 17 = Roll 90°, Yaw 45°
  • 18 = Roll 90°, Yaw 90°
  • 19 = Roll 90°, Yaw 135°
  • 20 = Roll 270°
  • 21 = Roll 270°, Yaw 45°
  • 22 = Roll 270°, Yaw 90°
  • 23 = Roll 270°, Yaw 135°
  • 24 = Pitch 90°
  • 25 = Pitch 270°

SENS_BOARD_X_OFF

Rotation, in degrees, around PX4FMU’s X axis or Roll axis. Positive angles increase in CCW direction, negative angles increase in CW direction.

SENS_BOARD_Y_OFF

Rotation, in degrees, around PX4FMU’s Y axis or Pitch axis. Positive angles increase in CCW direction, negative angles increase in CW direction.

SENS_BOARD_Z_OFF

Rotation, in degrees, around PX4FMU’s Z axis Yaw axis. Positive angles increase in CCW direction, negative angles increase in CW direction.

README - APM, Mission-planner

Advanced Configuration

This section contains advanced configuration topics, covering vehicle-specific tuning, and less-common sensors and peripherals.

:::tip The topics are useful if you are creating a new airframe type or significantly modifying a supported frame. Generally if you’re using a supported airframe (e.g. from QGroundControl > Airframe) the default tuning and configuration should be acceptable. :::

For the standard configuration appropriate to every vehicle see: Basic Configuration.

windows_cygwin_toolchain_setup - APM, Mission-planner

Windows Cygwin Development Environment (Maintenance Instructions)

This topic explains how to construct and extend the development environment used for the supported Cygwin-based Windows Development Environment.

Additional Information

Features / Issues

The following features are known to work (version 2.0):

  • Building and running SITL with jMAVSim with significantly better performance than a VM (it generates a native windows binary px4.exe).
  • Building and uploading NuttX builds (e.g.: px4_fmu-v2 and px4_fmu-v4)
  • Style check with astyle (supports the command: make format)
  • Command line auto completion
  • Non-invasive installer! The installer does NOT affect your system and global path (it only modifies the selected installation directory e.g. *C:\PX4* and uses a temporary local path).
  • The installer supports updating to a new version keeping your personal changes inside the toolchain folder

Omissions:

  • Simulation: Gazebo and ROS are not supported.
  • Only NuttX and JMAVSim/SITL builds are supported.
  • Known problems (Also use to report issues).

Shell Script Installation

You can also install the environment using shell scripts in the Github project.

  1. Make sure you have Git for Windows installed.
  2. Clone the repository https://github.com/PX4/windows-toolchain to the location you want to install the toolchain. Default location and naming is achieved by opening the Git Bash and executing:
    cd /c/
    git clone https://github.com/PX4/windows-toolchain PX4
    
  3. If you want to install all components navigate to the freshly cloned folder and double click on the script install-all-components.bat located in the folder toolchain. If you only need certain components and want to safe Internet traffic and or disk space you can navigate to the different component folders like e.g. toolchain\cygwin64 and click on the install-XXX.bat scripts to only fetch something specific.
  4. Continue with Getting Started.

Manual Installation (for Toolchain Developers)

This section describes how to setup the Cygwin toolchain manually yourself while pointing to the corresponding scripts from the script based installation repo. The result should be the same as using the scripts or MSI installer.

:::note The toolchain gets maintained and hence these instructions might not cover every detail of all the future changes. :::

  1. Create the folders: *C:\PX4*, *C:\PX4\toolchain* and *C:\PX4\home*
  2. Download the Cygwin installer file setup-x86_64.exe from the official Cygwin website
  3. Run the downloaded setup file
  4. In the wizard choose to install into the folder: *C:\PX4\toolchain\cygwin64*
  5. Select to install the default Cygwin base and the newest available version of the following additional packages:

    • Category:Packagename
    • Devel:cmake (3.3.2 gives no deprecated warnings, 3.6.2 works but has the warnings)
    • Devel:gcc-g++
    • Devel:gdb
    • Devel:git
    • Devel:make
    • Devel:ninja
    • Devel:patch
    • Editors:xxd
    • Editors:nano (unless you’re the vim pro)
    • Python:python2
    • Python:python2-pip
    • Python:python2-numpy
    • Python:python2-jinja2
    • Python:python2-pyyaml
    • Python:python2-cerberus
    • Archive:unzip
    • Utils:astyle
    • Shells:bash-completion
    • Web:wget

    :::note Do not select as many packages as possible which are not on this list, there are some which conflict and break the builds. :::

    :::note That’s what cygwin64/install-cygwin-px4.bat does. :::

  6. Write up or copy the batch scripts run-console.bat and setup-environment.bat.

    The reason to start all the development tools through the prepared batch script is they preconfigure the starting program to use the local, portable Cygwin environment inside the toolchain’s folder. This is done by always first calling the script setup-environment.bat and the desired application like the console after that.

    The script setup-environment.bat locally sets environmental variables for the workspace root directory PX4_DIR, all binary locations PATH, and the home directory of the unix environment HOME.

  7. Add necessary python packages to your setup by opening the Cygwin toolchain console (double clicking run-console.bat) and executing
    pip2 install toml
    pip2 install pyserial
    pip2 install pyulog
    

    :::note That’s what cygwin64/install-cygwin-python-packages.bat does. :::

  8. Download the ARM GCC compiler as zip archive of the binaries for Windows and unpack the content to the folder C:\PX4\toolchain\gcc-arm.

    :::note This is what the toolchain does in: gcc-arm/install-gcc-arm.bat. :::

  9. Install the JDK:
    • Download Java 14 from Oracle or AdoptOpenJDK.
    • Because sadly there is no portable archive containing the binaries directly you have to install it.
    • Find the binaries and move/copy them to C:\PX4\toolchain\jdk.
    • You can uninstall the Kit from your Windows system again, we only needed the binaries for the toolchain.

    :::note This is what the toolchain does in: jdk/install-jdk.bat. :::

  10. Download Apache Ant as zip archive of the binaries for Windows and unpack the content to the folder C:\PX4\toolchain\apache-ant.

    :::tip Make sure you don’t have an additional folder layer from the folder which is inside the downloaded archive. :::

    :::note This is what the toolchain does in: apache-ant/install-apache-ant.bat. :::

  11. Download, build and add genromfs to the path:
    • Clone the source code to the folder C:\PX4\toolchain\genromfs\genromfs-src with
      cd /c/toolchain/genromfs
      git clone https://github.com/chexum/genromfs.git genromfs-src
      
    • Compile it with:
      cd genromfs-src
      make all
      
    • Copy the resulting binary genromfs.exe one folder level out to: C:\PX4\toolchain\genromfs

    :::note This is what the toolchain does in: genromfs/install-genromfs.bat. :::

  12. Make sure all the binary folders of all the installed components are correctly listed in the PATH variable configured by setup-environment.bat.

system_tunes - APM, Mission-planner

System Notification Tunes

PX4 defines a number of standard tones/tunes that are used to provide audio notification for important system states and problems (e.g. system startup, arming success, battery warnings, etc.)

Tunes are specified using strings (in ANSI Music notation) and played by code using the tunes library. The tunes library also contains the list of default system tunes - see lib/tunes/tune_definition.desc.

PX4 also has a module that can be used to play (test) the default tunes or a user defined tune.

This topic provides general guidance on how to create your own tunes and add to/replace the system notification tones/tunes.

Creating Tunes

Tune strings are defined using ANSI Music notation.

:::tip More information about the format can be found in QBasic PLAY statement (Wikibooks) and has been reproduced in tune_definition.desc. :::

The easiest way to create a new tune is to use a music editor. This allows you to edit the music and play it back on your computer, then export it to a format that can be played by PX4.

ANSI music was popular in the days of ANSI BBS systems, and so the best editing tools are DOS utilities. On Windows, one option is to use Melody Master within Dosbox.

The steps for using the software are:

  1. Download DosBox and install the app
  2. Download Melody Master and unzip into a new directory
  3. Open the Dosbox console
  4. Mount the melody master directory in Dosbox as shown below:
    mount c C:\<path_to_directory\Melody21
    
  5. Start Melody Master with the following commands
    c:
    start
    
  6. You will then have the option to click through a few screens, then press 1 to display Melody Master: Melody Master 2.1

    The lower half of the screen provides helpful advice on keyboard shortcuts for using the tool (arrows for moving in stave, and numbers for selecting the note length, etc.).

  7. When you’re ready to save the music:
    • Press F2 to give the tune a name and save it in the /Music sub folder of your Melody Master installation.
    • Press F7, the scroll down the list of output formats on the right to get to ANSI. The file will be exported to the root of the Melody Master directory (with the same name and a file-type specific extension).
  8. Open the file. The output might look like this:

    ANSI Output from file

  9. The string that can be played in PX4 is the bit between MNT and P64: 150L1O3DL16CL32<B>C<AEL16A

Testing Tunes

When you’re ready to try it out a new tune on PX4, use the tune_control library. For example, to test the tune we “created” above you would enter the following command on a console or shell (e.g. the MAVLink Shell):

tune_control play -m "150L1O3DL16CL32<B>C<AEL16A"

:::note Out of the box, the tune_control is only present on real hardware (not the simulator). :::

Replacing Existing Tunes

Tunes are defined within tune_definition.desc.

If you just need to replace an existing tune, then you can replace the file in your own fork, and update the tune strings defined in PX4_DEFINE_TUNE.

Adding a New Tune

TBD.

switching_state_estimators - APM, Mission-planner

Switching State Estimators

This page shows you which state estimators are available and how you can switch between them.

:::tip EKF2 is highly recommended for all purposes (LPE is no longer supported/maintained). :::

Available Estimators

The available estimators are:

  • EKF2 attitude, position and wind states estimator - EKF2 is an extended kalman filter estimating attitude, 3D position / velocity and wind states.
  • LPE position estimator - The LPE position estimator is an extended kalman filter for 3D position and velocity states.
  • Q attitude estimator - The attitude Q estimator is a very simple, quaternion based complementary filter for attitude.

How to Enable Different Estimators

For multirotors and VTOL use the parameter SYS_MC_EST_GROUP to choose between the following configurations (LPE is not supported for Fixed Wing).

SYS_MC_EST_GROUP Q Estimator LPE EKF2
1 enabled enabled  
2     enabled
3 enabled    

:::note For FMU-v2 (only) you will also need to build PX4 to specifically include required estimator (e.g. EKF2: make px4_fmu-v2, LPE: make px4_fmu-v2_lpe). This is required because FMU-v2 is too resource constrained to include both estimators. Other Pixhawk FMU versions include both. :::

rtk_gps - APM, Mission-planner

RTK GPS (PX4 Integration)

Real Time Kinematic (RTK) provides centimeter-level GPS accuracy. This page explains how RTK is integrated into PX4.

:::tip Instructions for using RTK GPS are provided in Peripheral Hardware > RTK GPS. :::

Overview

RTK uses measurements of the phase of the signal’s carrier wave, rather than the information content of the signal. It relies on a single reference station to provide real-time corrections, which can work with multiple mobile stations.

Two RTK GPS modules and a datalink are required to setup RTK with PX4. The fixed-position ground-based GPS unit is called the Base and the in-air unit is called the Rover. The Base unit connects to QGroundControl (via USB) and uses the datalink to stream RTCM corrections to the vehicle (using the MAVLink GPS_RTCM_DATA message). On the autopilot, the MAVLink packets are unpacked and sent to the Rover unit, where they are processed to get the RTK solution.

The datalink should typically be able to handle an uplink rate of 300 bytes per second (see the Uplink Datarate section below for more information).

Supported RTK GPS modules

The list of devices that we have tested can be found in the user guide.

:::note Most devices come with two variants, a base and a rover. Make sure to select the correct variant. :::

Automatic Configuration

The PX4 GPS stack automatically sets up the GPS modules to send and receive the correct messages over the UART or USB, depending on where the module is connected (to QGroundControl or the autopilot).

As soon as the autopilot receives GPS_RTCM_DATA MAVLink messages, it automatically forwards the RTCM data to the attached GPS module.

:::note The u-blox U-Center RTK module configuration tool is not needed/used! :::

:::note Both QGroundControl and the autopilot firmware share the same PX4 GPS driver stack. In practice, this means that support for new protocols and/or messages only need to be added to one place. :::

RTCM messages

QGroundControl configures the RTK base station to output the following RTCM3.2 frames, each with 1 Hz, unless otherwise stated:

  • 1005 - Station coordinates XYZ for antenna reference point (Base position), 0.2 Hz.
  • 1077 - Full GPS pseudo-ranges, carrier phases, Doppler and signal strength (high resolution).
  • 1087 - Full GLONASS pseudo-ranges, carrier phases, Doppler and signal strength (high resolution).
  • 1230 - GLONASS code-phase biases.
  • 1097 - Full Galileo pseudo-ranges, carrier phases, Doppler and signal strength (high resolution)
  • 1127 - Full BeiDou pseudo-ranges, carrier phases, Doppler and signal strength (high resolution)

The raw RTCM messages from the base are packed into a MAVLink GPS_RTCM_DATA message and sent over the datalink. The maximum length of each MAVLink message is 182 bytes. Depending on the RTCM message, the MAVLink message is almost never completely filled.

The RTCM Base Position message (1005) is of length 22 bytes, while the others are all of variable length depending on the number of visible satellites and the number of signals from the satellite (only 1 for L1 units like M8P). Since at a given time, the maximum number of satellites visible from any single constellation is 12, under real-world conditions, theoretically an uplink rate of 300 B/s is sufficient.

If MAVLink 1 is used, a 182-byte GPS_RTCM_DATA message is sent for every RTCM message, irrespective of its length. As a result the approximate uplink requirement is around 700+ bytes per second. This can lead to link saturation on low-bandwidth half-duplex telemetry modules (e.g. 3DR Telemetry Radios).

If MAVLink 2 is used then any empty space in the GPS_RTCM_DATA message is removed. The resulting uplink requirement is about the same as the theoretical value (~300 bytes per second).

:::tip PX4 automatically switches to MAVLink 2 if the GCS and telemetry modules support it. :::

MAVLink 2 must be used on low-bandwidth links for good RTK performance. Care must be taken to make sure that the telemetry chain uses MAVLink 2 throughout. You can verify the protocol version by using the mavlink status command on the system console:

nsh> mavlink status
instance #0:
        GCS heartbeat:  593486 us ago
        mavlink chan: #0
        type:           3DR RADIO
        rssi:           219
        remote rssi:    219
        txbuf:          94
        noise:          61
        remote noise:   58
        rx errors:      0
        fixed:          0
        flow control:   ON
        rates:
        tx: 1.285 kB/s
        txerr: 0.000 kB/s
        rx: 0.021 kB/s
        rate mult: 0.366
        accepting commands: YES
        MAVLink version: 2
        transport protocol: serial (/dev/ttyS1 @57600)

realsense_intel_driver - APM, Mission-planner

Installing driver on Ubuntu for Intel RealSense R200

This tutorial aims to give instructions on how to install the camera driver of the Intel RealSense R200 camera head in Linux environment such that the gathered images can be accessed via the Robot Operation System (ROS). The RealSense R200 camera head is depicted below:

Intel Realsense Camera front view

The installation of the driver package is executed on a Ubuntu operation system (OS) that runs as a guest OS in a Virtual Box. The specifications of the host computer where the Virtual Box is running, the Virtual Box and the guest system are given below:

  • Host Operation System: Windows 8
  • Processor: Intel(R) Core(TM) i7-4702MQ CPU @ 2.20GHz
  • Virtual Box: Oracle VM. Version 5.0.14 r105127
  • Extensions: Extension package for Virtual Box installed (Needed for USB3 support)
  • Guest Operation System: Linux - Ubuntu 14.04.3 LTS

The tutorial is ordered in the following way: In a first part it is shown how to install Ubuntu 14.04 as a guest OS in the Virtual Box. In a second part is shown how to install ROS Indigo and the camera driver. The ensuing frequently used expressions have the following meaning:

  • Virtual Box (VB): Program that runs different Virtual Machines. In this case the Oracle VM.
  • Virtual Machine (VM): The operation system that runs in the Virtual Box as a guest system. In this case Ubuntu.

Installing Ubuntu 14.04.3 LTS in Virtual Box

  • Create a new Virtual Machine (VM): Linux 64-Bit.
  • Download the iso file of Ubuntu 14.04.3 LTS: (ubuntu-14.04.3-desktop-amd64.iso).
  • Installation of Ubuntu:
    • During the installation procedure leave the following two options unchecked:
      • Download updates while installing
      • Install this third party software
  • After the installation you might need to enable the Virtual Box to display Ubuntu on the whole desktop:
    • Start VM Ubuntu and login, Click on Devices->Insert Guest Additions CD image in the menu bar of the Virtual Box.
    • Click on Run and enter password on the windows that pop up in Ubuntu.
    • Wait until the installation is completed and then restart. Now, it should be possible to display the VM on the whole desktop.
    • If a window pops up in Ubuntu that asks whether to update, reject to update at this point.
  • Enable USB 3 Controller in Virtual Box:
    • Shut down Virtual Machine.
    • Go to the settings of the Virtual Machine to the menu selection USB and choose: “USB 3.0(xHCI)”. This is only possible if you have installed the extension package for the Virtual Box.
    • Start the Virtual Machine again.

Installing ROS Indigo

  • Follow instructions given at ROS indigo installation guide:
    • Install Desktop-Full version.
    • Execute steps described in the sections “Initialize rosdep” and “Environment setup”.

Installing camera driver

  • Install git:
    sudo apt-get install git
    
  • Download and install the driver
  • Follow instructions given in here.
    • Press the enter button when the questions whether to install the following installation packages show up:
      Intel Low Power Subsystem support in ACPI mode (MFD_INTEL_LPSS_ACPI) [N/m/y/?] (NEW)
      
      Intel Low Power Subsystem support in PCI mode (MFD_INTEL_LPSS_PCI) [N/m/y/?] (NEW)
      
      
      Dell Airplane Mode Switch driver (DELL_RBTN) [N/m/y/?] (NEW)
      
    • The following error message that can appear at the end of the installation process should not lead to a malfunction of the driver:
      rmmod: ERROR: Module uvcvideo is not currently loaded
      
  • After the installation has completed, reboot the Virtual Machine.

  • Test camera driver:
    • Connect the Intel RealSense camera head with the computer with a USB3 cable that is plugged into a USB3 receptacle on the computer.
    • Click on Devices->USB-> Intel Corp Intel RealSense 3D Camera R200 in the menu bar of the Virtual Box, in order to forward the camera USB connection to the Virtual Machine.
    • Execute the file [unpacked folder]/Bin/DSReadCameraInfo:
      • If the following error message appears, unplug the camera (physically unplug USB cable from the computer). Plug it in again + Click on Devices->USB-> Intel Corp Intel RealSense 3D Camera R200 in the menu bar of the Virtual Box again and execute again the file [unpacked folder]/Bin/DSReadCameraInfo.
        DSAPI call failed at ReadCameraInfo.cpp:134!
        
      • If the camera driver works and recognises the Intel RealSense R200, you should see specific information about the Intel RealSense R200 camera head.
  • Installation and testing of the ROS nodlet:
    • Follow the installation instructions in the “Installation” section given here, to install the ROS nodlet.
    • Follow the instructions in the “Running the R200 nodelet” section given here, to test the ROS nodlet together with the Intel RealSense R200 camera head.
      • If everything works, the different data streams from the Intel RealSense R200 camera are published as ROS topics.

parameters_and_configurations - APM, Mission-planner

Parameters & Configurations

PX4 uses the param subsystem (a flat table of float and int32_t values) and text files (for mixers and startup scripts) to store its configuration.

This section discusses the param subsystem in detail. It covers how to list, save and load parameters, and how to define them and make them available to ground stations.

:::tip System startup and the way that airframe configurations work are detailed on other pages. :::

Command Line Usage

The PX4 system console offers the param tool, which can be used to set parameters, read their value, save them, and export and restore to/from files.

Getting and Setting Parameters

The param show command lists all system parameters:

param show

To be more selective, a partial parameter name with wildcard “*” can be used:

nsh> param show RC_MAP_A*
Symbols: x = used, + = saved, * = unsaved
x   RC_MAP_AUX1 [359,498] : 0
x   RC_MAP_AUX2 [360,499] : 0
x   RC_MAP_AUX3 [361,500] : 0
x   RC_MAP_ACRO_SW [375,514] : 0

 723 parameters total, 532 used.

You can use the -c flag to show all parameters that have changed (from their defaults):

param show -c

You can use param show-for-airframe to show all parameters that have changed from their defaults for just the current airframe’s definition file (and defaults it imports).

Exporting and Loading Parameters

You can save any parameters that have been changed (that are different from airframe defaults).

The standard param save command will store the parameters in the current default file:

param save

If provided with an argument, it will store the parameters instead to this new location:

param save /fs/microsd/vtol_param_backup

There are two different commands to load parameters:

  • param load first does a full reset of all parameters to their defaults, and then overwrites parameter values with any values stored in the file.
  • param import just overwrites parameter values with the values from the file and then saves the result (i.e. effectively calls param save).

The load effectively resets the parameters to the state when the parameters were saved (we say “effectively” because any parameters saved in the file will be updated, but other parameters may have different firmware-defined default values than when the parameters file was created).

By contrast, import merges the parameters in the file with the current state of the vehicle. This can be used, for example, to just import a parameter file containing calibration data, without overwriting the rest of the system configuration.

Examples for both cases are shown below:

# Reset the parameters to when file was saved
param load /fs/microsd/vtol_param_backup
# Optionally save params (not done automatically with load)
param save
# Merge the saved parameters with current parameters
param import /fs/microsd/vtol_param_backup  

Creating/Defining Parameters

Parameters definitions have two parts:

  • Parameter metadata specifies the default value for each parameter in firmware along with other metadata for presentation (and editing) of parameters in ground control stations and documentation.
  • C/C++ Code that provides access to get and/or subscribe to parameter values from within PX4 modules and drivers.

Several approaches are described below for writing both the metadata and code. Where possible code should use newer YAML metadata and C++ API over the older C parameter/code definitions, as these are more flexible and robust.

Parameter metadata is compiled into the firmware, and made available to ground stations via the MAVLink Component Information service.

Parameter Names

Parameter names must be no more than 16 ASCII characters.

By convention, every parameter in a group should share the same (meaningful) string prefix followed by an underscore, and MC_ and FW_ are used for parameters related specifically to Multicopter or Fixed wing systems. This convention is not enforced.

The name must match in both code and parameter metadata to correctly associate the parameter with its metadata (including default value in Firmware).

C / C++ API

There are separate C and C++ APIs that can be used to access parameter values from within PX4 modules and drivers.

One important difference between the APIs is that the C++ version has a more efficient standardized mechanism to synchronize with changes to parameter values (i.e. from a GCS).

Synchronization is important because a parameter can be changed to another value at any time. Your code should always use the current value from the parameter store. If getting the latest version is not possible, then a reboot will be required after the parameter is changed (set this requirement using the @reboot_required metadata).

In addition, the C++ version has also better type-safety and less overhead in terms of RAM. The drawback is that the parameter name must be known at compile-time, while the C API can take a dynamically created name as a string.

C++ API

The C++ API provides macros to declare parameters as class attributes. You add some “boilerplate” code to regularly listen for changes in the uORB Topic associated with any parameter update. Framework code then (invisibly) handles tracking uORB messages that affect your parameter attributes and keeping them in sync. In the rest of the code you can just use the defined parameter attributes and they will always be up to date!

First include the required needed headers in the class header for your module or driver:

  • px4_platform_common/module_params.h to get the DEFINE_PARAMETERS macro:
    #include <px4_platform_common/module_params.h>
    
  • parameter_update.h to access the uORB parameter_update message:
    #include <uORB/topics/parameter_update.h>
    
  • Subscription.hpp for the uORB C++ subscription API:
    #include <uORB/Subscription.hpp>
    

Derive your class from ModuleParams, and use DEFINE_PARAMETERS to specify a list of parameters and their associated parameter attributes. The names of the parameters must be the same as their parameter metadata definitions.

class MyModule : ..., public ModuleParams
{
public:
	...

private:

	/**
	 * Check for parameter changes and update them if needed.
	 */
	void parameters_update();

	DEFINE_PARAMETERS(
		(ParamInt<px4::params::SYS_AUTOSTART>) _sys_autostart,   /**< example parameter */
		(ParamFloat<px4::params::ATT_BIAS_MAX>) _att_bias_max  /**< another parameter */
	)
	
	// Subscriptions
	uORB::SubscriptionInterval _parameter_update_sub{ORB_ID(parameter_update), 1_s};
	
};

Update the cpp file with boilerplate to check for the uORB message related to parameter updates.

Call parameters_update(); periodically in code to check if there has been an update:

void Module::parameters_update()
{
	if (_parameter_update_sub.updated()) {
		parameter_update_s param_update;
		_parameter_update_sub.copy(&param_update);

		// If any parameter updated, call updateParams() to check if
		// this class attributes need updating (and do so). 
		updateParams();
	}
}

In the above method:

  • _parameter_update_sub.updated() tells us if there is any update to the param_update uORB message (but not what parameter is affected).
  • If there has been “some” parameter updated, we copy the update into a parameter_update_s (param_update), to clear the pending update.
  • Then we call ModuleParams::updateParams(). This “under the hood” updates all parameter attributes listed in our DEFINE_PARAMETERS list.

The parameter attributes (_sys_autostart and _att_bias_max in this case) can then be used to represent the parameters, and will be updated whenever the parameter value changes.

:::tip The Application/Module Template uses the new-style C++ API but does not include parameter metadata. :::

C API

The C API can be used within both modules and drivers.

First include the parameter API:

#include <parameters/param.h>

Then retrieve the parameter and assign it to a variable (here my_param), as shown below for PARAM_NAME. The variable my_param can then be used in your module code.

int32_t my_param = 0;
param_get(param_find("PARAM_NAME"), &my_param);

:::note If PARAM_NAME was declared in parameter metadata then its default value will be set, and the above call to find the parameter should always succeed. :::

param_find() is an “expensive” operation, which returns a handle that can be used by param_get(). If you’re going to read the parameter multiple times, you may cache the handle and use it in param_get() when needed

# Get the handle to the parameter
param_t my_param_handle = PARAM_INVALID;
my_param_handle = param_find("PARAM_NAME");

# Query the value of the parameter when needed
int32_t my_param = 0;
param_get(my_param_handle, &my_param);

Parameter Metadata

PX4 uses an extensive parameter metadata system to drive the user-facing presentation of parameters, and to set the default value for each parameter in firmware.

:::tip Correct metadata is critical for good user experience in a ground station. :::

Parameter metadata can be stored anywhere in the source tree as either .c or .yaml parameter definitions (the YAML definition is newer, and more flexible). Typically it is stored alongside its associated module.

The build system extracts the metadata (using make parameters_metadata) to build the parameter reference and the parameter information used by ground stations.

:::warning After adding a new parameter file you should call make clean before building to generate the new parameters (parameter files are added as part of the cmake configure step, which happens for clean builds and if a cmake file is modified). :::

YAML Metadata

:::note At time of writing YAML parameter definitions cannot be used in libraries. :::

YAML meta data is intended as a full replacement for the .c definitions. It supports all the same metadata, along with new features like multi-instance definitions.

  • The YAML parameter metadata schema is here: validation/module_schema.yaml.
  • An example of YAML definitions being used can be found in the MAVLink parameter definitions: /src/modules/mavlink/module.yaml.
  • A YAML file is registered in the cmake build system by adding
    MODULE_CONFIG
    	module.yaml
    

    to the px4_add_module section of the CMakeLists.txt file of that module.

Multi-Instance (Templated) YAML Meta Data

Templated parameter definitions are supported in YAML parameter definitions (templated parameter code is not supported).

The YAML allows you to define instance numbers in parameter names, descriptions, etc. using ${i}. For example, below will generate MY_PARAM_1_RATE, MY_PARAM_2_RATE etc.

MY_PARAM_${i}_RATE:
            description:
                short: Maximum rate for instance ${i}

The following YAML definitions provide the start and end indexes.

  • num_instances (default 1): Number of instances to generate (>=1)
  • instance_start (default 0): First instance number. If 0, ${i} expands to [0, N-1]`.

For a full example see the MAVLink parameter definitions: /src/modules/mavlink/module.yaml

c Parameter Metadata

The legacy approach for defining parameter metadata is in a file with extension .c (at time of writing this is the approach most commonly used in the source tree).

Parameter metadata sections look like the following examples:

/**
 * Pitch P gain
 *
 * Pitch proportional gain, i.e. desired angular speed in rad/s for error 1 rad.
 *
 * @unit 1/s
 * @min 0.0
 * @max 10
 * @decimal 2
 * @increment 0.0005
 * @reboot_required true
 * @group Multicopter Attitude Control
 */
PARAM_DEFINE_FLOAT(MC_PITCH_P, 6.5f);
/**
 * Acceleration compensation based on GPS
 * velocity.
 *
 * @group Attitude Q estimator
 * @boolean
 */
PARAM_DEFINE_INT32(ATT_ACC_COMP, 1);

The PARAM_DEFINE_* macro at the end specifies the type of parameter (PARAM_DEFINE_FLOAT or PARAM_DEFINE_INT32), the name of the parameter (which must match the name used in code), and the default value in firmware.

The lines in the comment block are all optional, and are primarily used to control display and editing options within a ground station. The purpose of each line is given below (for more detail see module_schema.yaml).

/**
 * <title>
 *
 * <longer description, can be multi-line>
 *
 * @unit <the unit, e.g. m for meters>
 * @min <the minimum sane value. Can be overridden by the user>
 * @max <the maximum sane value. Can be overridden by the user>
 * @decimal <the minimum sane value. Can be overridden by the user>
 * @increment <the "ticks" in which this value will increment in the UI>
 * @reboot_required true <add this if changing the param requires a system restart.>
 * @boolean <add this for integer parameters that represent a boolean value>
 * @group <a title for parameters that form a group>
 */

Publishing Parameter Metadata to a GCS

Parameter metadata is collected into a JSON or XML file during each PX4 build.

For most flight controllers (as most have enough FLASH available), the JSON file is xz-compressed and stored within the generated binary. The file is then shared to ground stations using the MAVLink Component Information Protocol. This ensures that parameter metadata is always up-to-date with the code running on the vehicle.

Binaries for flight controller targets with constrained memory do not store the parameter metadata in the binary, but instead reference the same data stored on px4-travis.s3.amazonaws.com. This applies, for example, to the Omnibus F4 SD. The metadata is uploaded via github CI for all build targets (and hence will only be available once parameters have been merged into master).

:::note You can identify memory constrained boards because they specify CONSTRAINED_MEMORY in their cmake definition file). :::

:::note The metadata on px4-travis.s3.amazonaws.com is used if parameter metadata is not present on the vehicle. It may also be used as a fallback to avoid a very slow download over a low-rate telemetry link. :::

Anyone doing custom development on a FLASH-constrained board can adjust the URL here to point to another server.

The XML file of the master branch is copied into the QGC source tree via CI and is used as a fallback in cases where no metadata is available via the component information service (this approach predates the existence of the component information protocol).

Further Information

out_of_tree_modules - APM, Mission-planner

External Modules (Out-of-Tree)

External modules provide a convenient mechanism for developers to manage/group proprietary modules that they want add to (or update in) PX4 firmware. External modules can use the same includes as internal modules and can interact with internal modules via uORB.

This topic explains how to add an external (“out of tree”) module to the PX4 build.

:::tip We encourage you to contribute your changes into PX4, where possible! :::

Usage

To create an external module:

  • Create an external directory folder for grouping the external modules:
    • This can be located anywhere outside of the PX4-Autopilot tree.
    • It must have the same structure as PX4-Autopilot (i.e. it must contain a directory called src).
    • Later we refer to this directory using EXTERNAL_MODULES_LOCATION.
  • Copy an existing module (e.g. examples/px4_simple_app) to the external directory, or directly create a new module.
  • Rename the module (including MODULE in CMakeLists.txt) or remove it from the existing PX4-Autopilot cmake build config. This is to avoid conflicts with internal modules.
  • Add a file CMakeLists.txt in the external directory with content:
    set(config_module_list_external
        modules/<new_module>
        PARENT_SCOPE
        )
    
  • Add a line EXTERNAL to the modules/<new_module>/CMakeLists.txt within px4_add_module(), for example like this:

    px4_add_module(
    	MODULE modules__test_app
    	MAIN test_app
    	STACK_MAIN 2000
    	SRCS
    		px4_simple_app.c
    	DEPENDS
    		platforms__common
    	EXTERNAL
    	)
    

Out-of-Tree uORB Message Definitions

uORB messages can also be defined out-of-tree. For this, the $EXTERNAL_MODULES_LOCATION/msg folder must exist.

  • Place all new message definitions within the $EXTERNAL_MODULES_LOCATION/msg directory. The format of these new out-of-tree message definitions are the same as for any other uORB message definition.
  • Add a file $EXTERNAL_MODULES_LOCATION/msg/CMakeLists.txt with content:

    set(config_msg_list_external
        <message1>.msg
        <message2>.msg
        <message3>.msg
        PARENT_SCOPE
        )
    

    where <message#>.msg is the name of the uORB message definition file to be processed and used for uORB message generation.

The out-of-tree uORB messages will be generated in the same locations as the normal uORB messages. The uORB topic headers are generated in <build_dir>/uORB/topics/, and the message source files are generated in <build_dir>/msg/topics_sources/.

The new uORB messages can be used like any other uORB message as described here.

:::warning The out-of-tree uORB message definitions cannot have the same name as any of the normal uORB messages. :::

Building External Modules and uORB Messages

Execute make px4_sitl EXTERNAL_MODULES_LOCATION=<path>.

Any other build target can be used, but the build directory must not yet exist. If it already exists, you can also just set the cmake variable in the build folder.

For subsequent incremental builds EXTERNAL_MODULES_LOCATION does not need to be specified.

gimbal control - APM, Mission-planner

Gimbal Control Setup

If you want to control a gimbal with a camera (or any other payload) attached to the vehicle, you need to configure how you want to control it and how PX4 can command it. This page explains the setup.

PX4 contains a generic mount/gimbal control driver with different input and output methods.

  • The input defines how you control the gimbal: via RC or via MAVLink commands (for example in missions or surveys).
  • The output defines how the gimbal is connected: either via MAVLink commands or using the Flight Controller AUX PWM port. Any input method can be selected to drive any output, and both input and output have to be configured via parameters.

Parameters

The Mount parameters are used to setup the mount driver.

The most important ones are the input (MNT_MODE_IN) and the output (MNT_MODE_OUT) mode. By default, the input is disabled and the driver does not run. After selecting the input mode, reboot the vehicle so that the mount driver starts.

If the input mode is set to AUTO, the mode will automatically be switched based on the latest input. To switch from MAVLink to RC, a large stick motion is required.

To enable a MAVLink gimbal, first set parameter MNT_MODE_IN to MAVLINK_DO_MOUNT and MNT_MODE_OUT to MAVLINK.

The gimbal can be connected to any free serial port using the instructions in MAVLink Peripherals (GCS/OSD/Companion) (also see Serial Port Configuration).

A common configuration is to have a serial connection to the gimbal from the Flight Controller TELEM2 port (assuming TELEM2 is free). For this configuration you would set:

  • MAV_1_CONFIG to TELEM2 (if MAV_1_CONFIG is already used for a companion computer (say), use MAV_2_CONFIG).
  • MAV_1_MODE to NORMAL
  • SER_TEL2_BAUD to manufacturer recommended baud rate.

This will enable the user to command the gimbal using MAV_CMD_DO_MOUNT_CONTROL and MAV_CMD_DO_MOUNT_CONFIGURE.

Gimbal on Flight Controller (MNT_MODE_OUT=AUX)

The gimbal can be connected to the Flight controller AUX ports by setting the output mode to MNT_MODE_OUT=AUX.

A mixer file is required to define the mapping for the output pins and the mount mixer is automatically selected (this overrides any AUX mixer provided by the airframe configuration).

The output assignment is as following:

  • AUX1: Pitch
  • AUX2: Roll
  • AUX3: Yaw
  • AUX4: Shutter/retract

Customizing the mixer configuration

:::tip Read Mixing and Actuators for an explanation of how mixers work and the format of the mixer file. :::

The outputs can be customized by creating a mixer file on the SD card named etc/mixers/mount.aux.mix.

A basic mixer configuration for a mount is shown below.

# roll
M: 1
O:      10000  10000      0 -10000  10000
S: 2 0  10000  10000      0 -10000  10000

# pitch
M: 1
O:      10000  10000      0 -10000  10000
S: 2 1  10000  10000      0 -10000  10000

# yaw
M: 1
O:      10000  10000      0 -10000  10000
S: 2 2  10000  10000      0 -10000  10000

SITL

The Typhoon H480 model comes with a preconfigured simulated gimbal.

To run it, use:

make px4_sitl gazebo_typhoon_h480

To just test the mount driver on other models or simulators, make sure the driver runs (using vmount start), then configure its parameters.

Testing

The driver provides a simple test command - it needs to be stopped first with vmount stop. The following describes testing in SITL, but the commands also work on a real device.

Start the simulation with (no parameter needs to be changed for that):

make px4_sitl gazebo_typhoon_h480

Make sure it’s armed, eg. with commander takeoff, then use the following command to control the gimbal (for example):

vmount test yaw 30

Note that the simulated gimbal stabilizes itself, so if you send MAVLink commands, set the stabilize flags to false.

Gazebo Gimbal Simulation

dev env unsupported - APM, Mission-planner

Unsupported Developer Toolchains

This section contains topics about unsupported development platforms and tools (i.e. tools for which the code dev team are unlikely to be able to provide much advice).

:::tip See Toolchain Installation for information about the environments and tools we do support! :::

:::warning The environments and tools in this section are rarely tested and may not work. You should not use these unless you are and expert with the environment and capable of debugging the environment yourself. :::

comupter vision - APM, Mission-planner

Computer Vision (Optical Flow, MoCap, VIO, Avoidance)

Computer vision techniques enable computers to use visual data to make sense of their environment.

PX4 uses computer vision systems (primarily running on Companion Computers) in order to support the following features:

  • Optical Flow provides 2D velocity estimation (using a downward facing camera and a downward facing distance sensor).
  • Motion Capture provides 3D pose estimation using a vision system that is external to the vehicle. It is primarily used for indoor navigation.
  • Visual Inertial Odometry provides 3D pose and velocity estimation using an onboard vision system and IMU. It is used for navigation when global position information is absent or unreliable.
  • Obstacle Avoidance provides full navigation around obstacles when flying a planned path (currently missions are supported). This uses PX4/avoidance running on a companion computer.
  • Collision Prevention is used to stop vehicles before they can crash into an obstacle (primarily when flying in manual modes).

:::tip The PX4 Vision Autonomy Development Kit (Holybro) is a robust and inexpensive kit for developers working with computer vision on PX4. It comes with PX4 avoidance software pre-installed, and can be used as the base for your own algorithms. :::

Motion Capture

Motion Capture (MoCap) is a technique for estimating the 3D pose (position and orientation) of a vehicle using a positioning mechanism that is external to the vehicle. MoCap systems most commonly detect motion using infrared cameras, but other types of cameras, Lidar, or Ultra Wideband (UWB) may also be used.

:::note MoCap is commonly used to navigate a vehicle in situations where GPS is absent (e.g. indoors), and provides position relative to a local co-ordinate system. :::

For information about MoCap see:

Visual Inertial Odometry (VIO)

Visual Inertial Odometry (VIO) is used for estimating the 3D pose (position and orientation) and velocity of a moving vehicle relative to a local starting position. It is commonly used to navigate a vehicle in situations where GPS is absent (e.g. indoors) or unreliable (e.g. when flying under a bridge).

VIO uses Visual Odometry to estimate vehicle pose from visual information, combined with inertial measurements from an IMU (to correct for errors associated with rapid vehicle movement resulting in poor image capture).

:::note One difference between VIO and MoCap is that VIO cameras/IMU are vehicle-based, and additionally provide velocity information. :::

For information about configuring VIO on PX4 see:

Optical Flow

Optical Flow provides 2D velocity estimation (using a downward facing camera and a downward facing distance sensor).

For information about optical flow see:

External Resources

  • XTDrone - ROS + PX4 simulation environment for computer vision. The XTDrone Manual has everything you need to get started!

Readme - APM, Mission-planner

Advanced Topics

qav kiss racer - APM, Pixhawk4

QAV-R 5” KISS ESC Racer (Pixracer)

The Lumenier QAV-R 5” FPV Racing Quadcopter is a rigid, light, and fast FPV racer with removable arms. This topic provides full build and configuration instructions for using the frame with the Pixracer flight controller and KISS 24A Race Edition ESCs. It also provides information on the (optional) FPV setup.

Key information:

pixracer - px4 flight controller

mRo Pixracer

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

ppixhawk_series - px4 flight controller

Pixhawk Series

Pixhawk® is an independent open-hardware project providing readily-available, low-cost, and high-end, autopilot hardware designs to the academic, hobby and industrial communities.

Pixhawk is the reference hardware platform for PX4, and runs PX4 on the NuttX OS.

Manufacturers have created many different boards based on the open designs, with form factors that are optimised for applications from cargo carrying though to first person view (FPV) racers.

:::tip For computationally intensive tasks (e.g. computer vision) you will need a separate companion computer (e.g. Raspberry Pi 2/3 Navio2) or a platform with an integrated companion solution. :::

Key Benefits

ppixhawk_mini - px4 flight controller

Holybro Pixhawk Mini

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

The Holybro Pixhawk® Mini autopilot is a next-generation evolution of the Pixhawk. It is about 1/3rd the size of the original Pixhawk and has more powerful processors and sensors.

The Pixhawk Mini is based on the PX4 open-hardware project and has been optimized for the PX4 flight stack.

Pixhawk Mini

Wiring information is available below.

ppixhawk4 - px4 flight controller

Pixhawk 4

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

Pixhawk 4® is an advanced autopilot designed and made in collaboration with Holybro® and the PX4 team. It is optimized to run PX4 v1.7 and later, and is suitable for academic and commercial developers.

ppixhawk3_pro - px4 flight controller

Pixhawk 3 Pro

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

The Pixhawk® 3 Pro is based on the FMUv4 hardware design (Pixracer) with some upgrades and additional features. The board was designed by Drotek® and PX4.

Pixhawk 3 Pro hero image

ppixhawk - px4 flight controller

3DR Pixhawk 1 Flight Controller (Discontinued)

:::warning This flight controller has been discontinued and is no longer commercially available. You can use the mRo Pixhawk as a drop-in replacement. :::

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

The 3DR Pixhawk® 1 autopilot is a popular general purpose flight controller based on the Pixhawk-project FMUv2 open hardware design (it combines the functionality of the PX4FMU + PX4IO). It runs PX4 on the NuttX OS.

Pixhawk Image

Assembly/setup instructions for use with PX4 are provided here: Pixhawk Wiring Quickstart

ppixhawk-2 - px4 flight controller

Hex Cube Black Flight Controller

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

:::tip The Cube Orange is the successor to this product. We recommend however to consider products built on industry standards, such as the Pixhawk Standards. This flight controller is not following the standard and uses a patented connector. :::

pixhack_v3 - px4 flight controller

Pixhack V3

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

The CUAV Pixhack V3 flight controller board is a flexible autopilot intended primarily for manufacturers of commercial systems.

pixfalcon - px4 flight controller

Pixfalcon Flight Controller (Discontinued)

:::warning This flight controller has been discontinued and is no longer commercially available. :::

omnibus_f4_sd - px4 flight controller

Omnibus F4 SD

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

aerotenna ocpoc - px4 flight controller

Aerotenna OcPoC-Zynq Mini Flight Controller (Discontinued)

:::warning This flight controller has been discontinued and is no longer commercially available.

nxprddrone - px4 flight controller

NXP RDDRONE-FMUK66 FMU

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

mRo X2 - px4 flight controller

mRo-X2.1 Autopilot

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

mro pixhawk - px4 flight controller

mRo Pixhawk Flight Controller (Pixhawk 1)

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

mro_control_zero - px4 flight controller

mRo Control Zero F7 Flight Controller

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

modalai_voxl_flight - px4 flight controller

ModalAI VOXL Flight

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

modalai_fc_v1 - px4 flight controller

ModalAI Flight Core v1

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

mindracer - px4 flight controller

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

mind_series - px4 flight controller

(Air)Mind Series

AirMind® have created two new controller series branched from the Pixhawk Series.

kakutef7 - px4 flight controller

Kakute F7

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

holybr_pix32 - px4 flight controller

Holybro pix32 Flight Controller

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

px4 fc hardware - px4 flight controller

Flight Controller (Autopilot) Hardware

This section lists the autopilot hardware documented in this library (that can be used to run the PX4 flight stack). This list is not exhaustive - there are other compatible flight controllers and variants.

:::tip You can also try PX4 on a Complete Vehicle (consumer drones and reference platforms that can run PX4). :::

dropix - px4 flight controller

DroPix Flight Controller

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

cubepilot_cube_yellow - px4 flight controller

Cube Yellow Flight Controller

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

cubepilot_cube_orange - px4 flight controller

Cube Orange Flight Controller

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

:::tip The PX4 dev team supports this flight controller as a footprint compatible replacement for Cube Black. We recommend however to consider products built on industry standards, such as the Pixhawk Standards. This flight controller is not following the standard and uses a patented connector. :::

cuav_x7 - px4 flight controller

CUAV X7 Flight Controller

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

The X7® flight controller is a high-performance autopilot. It is an ideal choice for industrial drones and large-scale heavy-duty drones. It is mainly supplied to commercial manufacturers.

CUAV x7

The flight controller adopts a modular design and can be matched with different base plates. You can design a dedicated carrier board for your UAV to improve the integration of commercial systems, reduce wiring, improve system reliability, and enhance your UAV competitiveness (for example, integrating airspeed sensors, telemetry or even a companion computer, in the carrier board). CUAV has also provided a variety of carrier boards for you to choose from.

:::note This flight controller is manufacturer supported. :::

cuav_v5_plus - px4 flight controller

CUAV V5+ Autopilot

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

V5+® is an advanced autopilot manufactured by CUAV®. It was designed by CUAV® in collaboration with the PX4 team.

The autopilot is recommended for commercial systems integration, but is also suitable for academic research and any other use.

cuav_v5_nano - px4 flight controller

CUAV V5 nano Autopilot

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

V5 nano® is an autopilot for space-constrained applications, designed by CUAV® in collaboration with the PX4 team.

The autopilot is small enough to use in 220mm racing drones, but remains powerful enough for most drone use.

V5 nano - Hero image

:::note The V5 nano is similar to the CUAV V5+, but has an all-in-one form factor, fewer PWM ports (can’t be used for airframes that use AUX ports), and does not have internal damping. :::

cuav_v5 - px4 flight controller

CUAV v5 (Discontinued)

:::warning This flight controller has been discontinued and is no longer commercially available. :::

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

cuav_nora - px4 flight controller

CUAV Nora Flight Controller

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

The Nora® flight controller is a high-performance autopilot. It is an ideal choice for industrial drones and large-scale heavy-duty drones. It is mainly supplied to commercial manufacturers.

CUAV x7

Nora is a variant of the CUAV X7. It adopts an integrated motherboard (soft and hard board), which reduces flight controller’s internal connectors, improves reliability, and places all the interfaces on the side (making the wiring more concise).

beaglebone_blue - px4 flight controller

BeagleBone Blue

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

:::warning PX4 support for this flight controller is experimental. :::

BeagleBone Blue is an all-in-one Linux-based computer. Although it is optimized for robotics, this compact and inexpensive board has all necessary sensors and peripherals needed by a flight controller. This topic shows how to set up the board to run PX4 with librobotcontrol robotics package.

BeagleBone - labelled diagram

autopilot_pixhawk_standard - px4 flight controller

Pixhawk Standard Autopilots

Pixhawk series boards that fully comply with the Pixhawk Standard (including use of the Pixhawk trademark), and that are still being manufactured, are supported by the PX4 project.

These boards are maintained, updated, tested and otherwise supported by the PX4 project maintainers and Dronecode test team.

:::tip For more information about PX4 project autopilot board support levels see: px4.io/autopilots/. :::

autopilot_manufacturer_supported - px4 flight controller

Manufacturer-Supported Autopilots

Manufacturer-supported autopilots are maintained and supported by a board manufacturer (manufacturers commit to delivering compatibility with the current stable PX4 release within 4 months of the official release announcement).

:::tip For more information about PX4 project autopilot board support levels see: px4.io/autopilots/. :::

autopilot_experimental - px4 flight controller

Community Supported & Experimental Autopilots

:::tip For more information about PX4 project autopilot board support levels see: px4.io/autopilots/. :::

Community Supported Autopilots

Boards in this category are fully supported, but are not following industry standards and might have sole-source supply chain risks. See the list of Pixhawk standard boards for a list of products that are officially supported by PX4 and are following industry standards.

autopiolog_discontinued - px4 flight controller

Discontinued Autopilots/Vehicles

:::tip For more information about PX4 project autopilot board support levels see: px4.io/autopilots/. :::

This category is for discontinued autopilots and complete vehicles. These are not supported by the head revision of PX4 and are no longer no longer being manufactured.

Autopilots

AUAV X2 - px4 flight controller

AUAV-X2 Autopilot (Discontinued)

:::warning This flight controller has been discontinued and is no longer commercially available. :::

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

The AUAV® AUAV-X2 autopilot is based on the Pixhawk®-project FMUv2 open hardware design. It runs PX4 on the NuttX OS.

AUAVX2_case2

Quick Summary

  • Main System-on-Chip: STM32F427
    • CPU: STM32F427VIT6 ARM microcontroller - Revision 3
    • IO: STM32F100C8T6 ARM microcontroller
  • Sensors:
    • Invensense MPU9250 9DOF
    • Invensense ICM-20608 6DOF
    • MEAS MS5611 barometer
  • Dimensions/Weight
    • Size: 36mm x 50mm
    • Mounting Points: 30.5mm x 30.5mm 3.2mm diameter
    • Weight: 10.9g
  • Power OR-ing schematic with reverse voltage protection. 5V power module is required!

drones web-based gcs - gcs

Test flight after assembly

Our class team made its first test flight after assembly.

 
demo

Preview

drones sensorfusion - sensorfuison

Test flight after assembly

Our class team made its first test flight after assembly.

 
demo

Preview

drones ros - ros

Test flight after assembly

Our class team made its first test flight after assembly.

   
demo drone-slam

rtabmap_drone_example

2D navigation example of a drone using move_base with mavros/px4 and rtabmap visual SLAM.

Dependencies

Tested on ROS Melodic and ROS Noetic with the corresponding PX4 versions below.

sudo apt install \
   ros-$ROS_DISTRO-gazebo-dev \
   ros-$ROS_DISTRO-joy \
   ros-$ROS_DISTRO-imu-complementary-filter \
   ros-$ROS_DISTRO-teleop-twist-joy \
   ros-$ROS_DISTRO-geographic-msgs \
   ros-$ROS_DISTRO-dwa-local-planner \
   libgeographic-dev \
   geographiclib-tools \
   libgstreamer1.0-dev

# May need this on Melodic to avoid error about silt_gazebo
# and gstreamer (https://github.com/PX4/PX4-Autopilot/issues/13117):
sudo apt-get install libgstreamer-plugins-base1.0-dev

# If rtabmap is not already built from source:
sudo apt install ros-$ROS_DISTRO-rtabmap-ros

PX4 v1.12.3

cd ~
git clone https://github.com/PX4/PX4-Autopilot.git
cd PX4-Autopilot
git checkout v1.12.3
git submodule update --init --recursive
sudo pip3 install numpy toml packaging jinja2 empy numpy
make px4_sitl_default gazebo
# (do ctrl-c in terminal to close gazebo)
echo "source ~/PX4-Autopilot/Tools/setup_gazebo.bash ~/PX4-Autopilot ~/PX4-Autopilot/build/px4_sitl_default" >> ~/.bashrc
echo "export ROS_PACKAGE_PATH=$ROS_PACKAGE_PATH:~/PX4-Autopilot:~/PX4-Autopilot/Tools/sitl_gazebo" >> ~/.bashrc
source ~/.bashrc

cd ~/catkin_ws/src
# To work with PX4/Firmware 1.12.3, mavros 1.8.0 or 1.9.0 releases should be used
# (With mavros master branch there are a lot of "Detected jump back in time" TF errors)
git clone https://github.com/mavlink/mavros.git && cd mavros && git checkout 1.9.0 && cd ..
git clone https://github.com/SyrianSpock/realsense_gazebo_plugin.git

sudo ~/catkin_ws/src/mavros/mavros/scripts/install_geographiclib_datasets.sh

cd ~/catkin_ws
catkin_make

Usage

roslaunch rtabmap_drone_example gazebo.launch
roslaunch rtabmap_drone_example slam.launch
roslaunch rtabmap_drone_example rviz.launch

# Arm and take off:
rosrun rtabmap_drone_example offboard
  • Manual control: If a joystick is plugged, you can send twists by holding L1 and moving the joysticks. Hold L1+L2 with left joystick down to land (be gentle to land smoothly), then hold left joystick in bottom-right position to disarm after the drone is on the ground.
  • Autonomous control: use “2D Nav Goal” button in RVIZ to set a goal to reach

Preview

drones QGroundcontrol - qground

Test flight after assembly

Our class team made its first test flight after assembly.

 
demo

Preview

drones overview -

Test flight after assembly

Our class team made its first test flight after assembly.

 
demo

Preview

middleware devwork - middleware

Test flight after assembly

Our class team made its first test flight after assembly.

 
demo

Preview

drones mavsdk - mavsdk

Test flight after assembly

Our class team made its first test flight after assembly.

 
demo

Preview

drones mavlink - mavlink

Test flight after assembly

Our class team made its first test flight after assembly.

 
demo

Preview

drones hardware_specs - hardware

Test flight after assembly

Our class team made its first test flight after assembly.

 
demo

Preview

drones dronekit - dronekit

Test flight after assembly

Our class team made its first test flight after assembly.

 
demo

Preview

drones devcodes - devcodes

Test flight after assembly

Our class team made its first test flight after assembly.

 
demo

Preview

drones debugging - debugging

Test flight after assembly

Our class team made its first test flight after assembly.

 
demo

Preview

drone books - books

Test flight after assembly

Our class team made its first test flight after assembly.

 
demo

Preview

drones autonomous - airdrone

Test flight after assembly

Our class team made its first test flight after assembly.

 
demo

Preview

logging guide - APM, Pixhawk4

Logging

The logger is able to log any ORB topic with all included fields. Everything necessary is generated from the .msg file, so that only the topic name needs to be specified. An optional interval parameter specifies the maximum logging rate of a certain topic. All existing instances of a topic are logged.

The output log format is ULog.

dalrc - APM, Mission-planner

Darlc215

Type Details Type Details
frame   FC  
motor   ESC  
RC   mode  
weight   class  
battery   air-time  
configurator   last updated  
       

highlight

dalrc

Highlights
Angle-adjustable camera mount, with shock-absorber function
Motor protective mount, with landing gear function
Multiple antenna holes on upper board and center board, convenient to fix antenna
1.5MM 3K all carbon fiber upper layer board
3MM integrated arm and body, super tough
Smart layout, easy installation
Adopt imported YFS screw
Support Mobius 808, Runcam, SJCAM camera
DL180 is designed for FPV race, all carbon integrated fiber body, super powerful, very tough. It comes with motor protection base and adjustable camera base which can used to change angle

pixhawk cube - APM, cube

Pixhawk Cube Black

Type Details Type Details
frame   FC  
motor   ESC  
RC   mode  
weight   class  
battery   air-time  
configurator   last updated  
airframe      

Preview

pid tuning guide multicopter basic - APM, Pixhawk4

Multicopter PID Tuning Guide

This tutorial explains how to tune the PID loops on PX4 for all multicopter setups (Quads, Hexa, Octo etc).

Tuning is recommended for all new vehicle setups, because relatively small hardware and assembly changes can affect the gains required tuning gains for optimal flight. For example, different ESCs or motors require different tuning gains.

:::tip Generally if you’re using an appropriate supported airframe configuration (selected from QGroundControl > Airframe), the default tuning should allow you to fly the vehicle safely. To get the very best performance we recommend you tune your new vehicle. :::

pid tuning guide multicopter - APM, Pixhawk4

Multicopter PID Tuning Guide (Advanced/Detailed)

This topic provides detailed information about PX4 controllers, and how they are tuned.

:::tip We recommend that you follow the basic PID tuning guide for tuning the vehicles around the hover thrust point, as the approach described is intuitive, easy, and fast. This is all that is required for many vehicles. :::

Use this topic when tuning around the hover thrust point is not sufficient (e.g. on vehicles where there are non-linearities and oscillations at higher thrusts). It is also useful for a deeper understanding of how the basic tuning works, and to understand how to use the airmode setting.

Tuning Steps

filter tuning - APM, Pixhawk4

MC Filter Tuning & Control Latency

Filters can be used to trade off control latency, which affects flight performance, and noise filtering, which impacts both flight performance and motor health.

This topic provides an overview of control latency and PX4 filter tuning.

:::note Before filter tuning you should do a first pass at Basic MC PID tuning. The vehicle needs to be undertuned (the P and D gains should be set too low), such that there are no oscillations from the controller that could be interpreted as noise (the default gains might be good enough). :::

bebop parrot - APM, Mission-planner

bebop parrots

Type Details Type Details
frame   FC  
motor   ESC  
RC   mode  
weight   class  
battery   air-time  
configurator   last updated  
airframe      

bebop parrot ardupilot connection

parrotb_bebop_autopilot

Building_for_bebop2

Bebop_ROS

hacking bebop

autonomylab


vibration isolation - APM, Pixhawk4

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).

pixhawk lite - APM, bebop

Pixhawk lite

Type Details Type Details
frame   FC  
motor   ESC  
RC   mode  
weight   class  
battery   air-time  
configurator   last updated  
airframe from rapa      

APMdr a racing drone

mission planner connection

paramete reference - APM, Mission-planner, drones

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. :::

vscode to replace qt5-creator -

Visual Studio Code IDE (VSCode)

Visual Studio Code is a powerful cross-platform source code editor/IDE that can be used for PX4 development on Ubuntu 18.04 LTS and macOS (Windows support coming soon).

There are a number of reasons to use VSCode for PX4 development:

  • Getting setup really only takes a few minutes.
  • A rich extension ecosystem that enables a huge range of tools needed for PX4 development: C/C++ (with solid cmake integration), Python, Jinja2, ROS messages, and even UAVCAN dsdl.
  • Excellent Github integration.

This topic explains how to setup the IDE and start developing.

:::note There are other powerful IDEs, but they typically take more effort to integrate with PX4. With VScode, configuration is stored in the PX4/PX4-Autopilot tree (PX4-Autopilot/.vscode) so the setup process is as simple as adding the project folder. :::

Preconditions

You must already have installed the command line PX4 developer environment for your platform and downloaded the Firmware source code repo.

Installation & Setup

  1. Download and install VSCode (you will be offered the correct version for your OS).
  2. Open VSCode and add the PX4 source code:
    • Select Open folder … option on the welcome page (or using the menu: File > Open Folder): Open Folder
    • A file selection dialog will appear. Select the PX4-Autopilot directory and then press OK.

    The project files and configuration will then load into VSCode.

  3. Press Install All on the This workspace has extension recommendations prompt (this will appear on the bottom right of the IDE). Install extensions

    VSCode will open the Extensions panel on the left hand side so you can watch the progress of installation.

    PX4 loaded into VSCode Explorer

  4. A number of notifications/prompts may appear in the bottom right corner

    :::tip If the prompts disappear, click the little “alarm” icon on the right of the bottom blue bar. :::

    • If prompted to install a new version of cmake:
    • If prompted to sign into github.com and add your credentials:
      • This is up to you! It provides a deep integration between Github and the IDE, which may simplify your workflow.
    • Other prompts are optional, and may be installed if they seem useful.

Building PX4

To build:

  1. Select your build target (“cmake build config”):
    • The current cmake build target is shown on the blue config bar at the bottom (if this is already your desired target, skip to next step). Select Cmake build target

      :::note The cmake target you select affects the targets offered for when building/debugging (i.e. for hardware debugging you must select a hardware target like px4_fmu-v5). :::

    • Click the target on the config bar to display other options, and select the one you want (this will replace any selected target).
    • Cmake will then configure your project (see notification in bottom right). Cmake config project
    • Wait until configuration completes. When this is done the notification will disappear and you’ll be shown the build location: Cmake config project.
  2. You can then kick off a build from the config bar (select either Build or Debug). Run debug or build

After building at least once you can now use code completion and other VSCode features.

Debugging

SITL Debugging

To debug PX4 on SITL:

  1. Select the debug icon on the sidebar (marked in red) to display the debug panel. Run debug

  2. Then choose your debug target (e.g. Debug SITL (Gazebo Iris)) from the top bar debug dropdown (purple box).

    :::note The debug targets that are offered (purple box) match your build target (yellow box on the bottom bar). For example, to debug SITL targets, your build target must include SITL. :::

  3. Start debugging by clicking the debug “play” arrow (next to the debug target in the top bar - pink box).

While debugging you can set breakpoints, step over code, and otherwise develop as normal.

Hardware Debugging

The instructions in SWD (JTAG) Hardware Debugging Interface explain how to connect to the SWD interface on common flight controllers (for example, using the Dronecode or Blackmagic probes).

After connecting to the SWD interface, hardware debugging in VSCode is then the same as for SITL Debugging except that you select a debug target appropriate for your debugger type (and firmware) - e.g. jlink (px4_fmu-v5).

:::tip To see the jlink option you must have selected a cmake target for building firmware. :::

Image showing hardware targets with options for the different probes

Code Completion

In order for the code completion to work (and other IntelliSense magic) you need an active configuration and to have built the code.

Once that is done you don’t need to do anything else; the toolchain will automatically offer you symbols as you type.

IntelliSense

Troubleshooting

This section includes guidance on setup and build errors.

Ubuntu 18.04: “Visual Studio Code is unable to watch for file changes in this large workspace”

This error surfaces on startup. On some systems, there is an upper-limit of 8192 file handles imposed on applications, which means that VSCode might not be able to detect file modifications in /PX4-Autopilot.

You can increase this limit to avoid the error, at the expense of memory consumption. Follow the instructions here. A value of 65536 should be more than sufficient.

Preview

Tags: drone