mirror of
https://gitee.com/mirrors_PX4/PX4-Autopilot.git
synced 2026-10-03 15:38:52 +08:00
Move PX4 Guide source into /docs (#24490)
* Add vitepress tree * Update existing workflows so they dont trigger on changes in the docs path * Add nojekyll, package.json, LICENCE etc * Add crowdin docs upload/download scripts * Add docs flaw checker workflows * Used docs prefix for docs workflows * Crowdin obvious fixes * ci: docs move to self hosted runner runs on a beefy server for faster builds Signed-off-by: Ramon Roche <mrpollo@gmail.com> * ci: don't run build action for docs or ci changes Signed-off-by: Ramon Roche <mrpollo@gmail.com> * ci: update runners Signed-off-by: Ramon Roche <mrpollo@gmail.com> * Add docs/en * Add docs assets and scripts * Fix up editlinks to point to PX4 sources * Download just the translations that are supported * Add translation sources for zh, uk, ko * Update latest tranlsation and uorb graphs * update vitepress to latest --------- Signed-off-by: Ramon Roche <mrpollo@gmail.com> Co-authored-by: Ramon Roche <mrpollo@gmail.com>
This commit is contained in:
Hamish Willee
co-authored by
Ramon Roche
Ramon Roche
parent
8e6d2ebe4a
commit
88d623bedb
@@ -0,0 +1,176 @@
|
||||
# MC Filter Tuning & Control Latency
|
||||
|
||||
Filters can be used to trade off [control latency](#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.
|
||||
|
||||
::: info
|
||||
Before filter tuning you should do a first pass at [Basic MC PID tuning](../config_mc/pid_tuning_guide_multicopter_basic.md).
|
||||
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).
|
||||
:::
|
||||
|
||||
## Control Latency
|
||||
|
||||
The _control latency_ is the delay from a physical disturbance of the vehicle until the motors react to the change.
|
||||
|
||||
:::tip
|
||||
Lowering latency allows you to increase the rate **P** gains, which results in better flight performance.
|
||||
Even one millisecond difference in the latency can have a significant impact.
|
||||
:::
|
||||
|
||||
The following factors affect control latency:
|
||||
|
||||
- A soft airframe or soft vibration mounting increases latency (they act as a filter).
|
||||
- Low-pass filters in software and on the sensor chip trade off increased latency for improved noise filtering.
|
||||
- PX4 software internals: the sensor signals need to be read in the driver and then pass through the controller to the output driver.
|
||||
- The maximum gyro publication rate (configured with [IMU_GYRO_RATEMAX](../advanced_config/parameter_reference.md#IMU_GYRO_RATEMAX)).
|
||||
A higher rate reduces latency but is computationally intensive/can starve other processes.
|
||||
4 kHz or higher is only recommended for controllers with STM32H7 processor or newer (2 kHz value is near the limit for less capable processors).
|
||||
- The IO chip (MAIN pins) adds about 5.4 ms latency compared to using the AUX pins (this does not apply to a _Pixracer_ or _Omnibus F4_, but does apply to a Pixhawk).
|
||||
To avoid the IO delay attach the motors to the AUX pins instead.
|
||||
- PWM output signal: enable [Dshot](../peripherals/dshot.md) by preference to reduce latency (or One-Shot if DShot is not supported).
|
||||
The protocol is selected for a group of outputs during [Actuator Configuration](../config/actuators.md).
|
||||
|
||||
Below we look at the impact of the low pass filters.
|
||||
|
||||
## Filters
|
||||
|
||||
The filtering pipeline for the controllers in PX4 is described below.
|
||||
|
||||
::: info
|
||||
Sampling and filtering is always performed at the full raw sensor rate (commonly 8kHz, depending on the IMU).
|
||||
:::
|
||||
|
||||
### On-chip DLPF for the Gyro Sensor
|
||||
|
||||
This is disabled on all chips where it can be disabled (if not, cutoff frequency is set to the highest level of the chip).
|
||||
|
||||
### Notch Filters
|
||||
|
||||
Setups that have a significant lower-frequency noise spike (e.g. due to harmonics at the rotor blade pass frequency) can benefit from using the notch filter to clean the signal before it is passed to the low pass filter (these harmonics have a similar detrimental impact on motors as other sources of noise).
|
||||
|
||||
Without the notch filter you'd have to set the low pass filter cutoff much lower (increasing the phase lag) in order to avoid passing this noise to the motors.
|
||||
|
||||
#### Static Notch Filters
|
||||
|
||||
One or two static notch filters on the gyro sensor data that are used to filter out narrow band noise, for example a bending mode of the airframe.
|
||||
|
||||
The static notch filters can be configured using:
|
||||
|
||||
- First notch filter: [IMU_GYRO_NF0_BW](../advanced_config/parameter_reference.md#IMU_GYRO_NF0_BW) and [IMU_GYRO_NF0_FRQ](../advanced_config/parameter_reference.md#IMU_GYRO_NF0_FRQ).
|
||||
- Second notch filter: [IMU_GYRO_NF1_BW](../advanced_config/parameter_reference.md#IMU_GYRO_NF1_BW) and [IMU_GYRO_NF1_FRQ](../advanced_config/parameter_reference.md#IMU_GYRO_NF1_FRQ).
|
||||
|
||||
::: info
|
||||
Only two notch filters are provided.
|
||||
Airframes with more than two frequency noise spikes typically clean the first two spikes with the notch filters, and subsequent spikes using the low pass filter.
|
||||
:::
|
||||
|
||||
#### Dynamic Notch Filters
|
||||
|
||||
Dynamic notch filters use ESC RPM feedback and/or the onboard FFT analysis.
|
||||
The ESC RPM feedback is used to track the rotor blade pass frequency and its harmonics, while the FFT analysis can be used to track a frequency of another vibration source, such as a fuel engine.
|
||||
|
||||
ESC RPM feedback requires ESCs capable of providing RPM feedback such as [DShot](../peripherals/esc_motors.md#dshot) with telemetry connected, a bidirectional DShot set up ([work in progress](https://github.com/PX4/PX4-Autopilot/pull/23863)), or [UAVCAN/DroneCAN ESCs](../dronecan/escs.md).
|
||||
Before enabling, make sure that the ESC RPM is correct.
|
||||
You might have to adjust the [pole count of the motors](../advanced_config/parameter_reference.md#MOT_POLE_COUNT).
|
||||
|
||||
The following parameters should be set to enable and configure dynamic notch filters:
|
||||
|
||||
| Parameter | Description |
|
||||
| ------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------ |
|
||||
| <a href="IMU_GYRO_DNF_EN"></a>[IMU_GYRO_DNF_EN](../advanced_config/parameter_reference.md#IMU_GYRO_DNF_EN) | Enable IMU gyro dynamic notch filtering. `0`: ESC RPM, `1`: Onboard FFT. |
|
||||
| <a href="IMU_GYRO_FFT_EN"></a>[IMU_GYRO_FFT_EN](../advanced_config/parameter_reference.md#IMU_GYRO_FFT_EN) | Enable onboard FFT (required if `IMU_GYRO_DNF_EN` is set to `1`). |
|
||||
| <a href="IMU_GYRO_DNF_MIN"></a>[IMU_GYRO_DNF_MIN](../advanced_config/parameter_reference.md#IMU_GYRO_DNF_MIN) | Minimum dynamic notch frequency in Hz. |
|
||||
| <a href="IMU_GYRO_DNF_BW"></a>[IMU_GYRO_DNF_BW](../advanced_config/parameter_reference.md#IMU_GYRO_DNF_BW) | Bandwidth for each notch filter in Hz. |
|
||||
| <a href="IMU_GYRO_DNF_HMC"></a>[IMU_GYRO_DNF_HMC](../advanced_config/parameter_reference.md#IMU_GYRO_NF0_BW) | Number of harmonics to filter. |
|
||||
|
||||
### Low-pass Filter
|
||||
|
||||
A low pass filter on the gyro data can be configured with the [IMU_GYRO_CUTOFF](../advanced_config/parameter_reference.md#IMU_GYRO_CUTOFF) parameter.
|
||||
|
||||
To reduce the control latency, we want to increase the cutoff frequency for the low-pass filters.
|
||||
The effect on latency of increasing `IMU_GYRO_CUTOFF` is approximated below.
|
||||
|
||||
| Cutoff (Hz) | Delay approx. (ms) |
|
||||
| ------------ | ------------------ |
|
||||
| 30 | 8 |
|
||||
| 60 | 3.8 |
|
||||
| 120 | 1.9 |
|
||||
|
||||
However this is a trade-off as increasing `IMU_GYRO_CUTOFF` will also increase the noise of the signal that is fed to the motors.
|
||||
Noise on the motors has the following consequences:
|
||||
|
||||
- Motors and ESCs can get hot, to the point where they get damaged.
|
||||
- Reduced flight time because the motors continuously change their speed.
|
||||
- Visible random small twitches.
|
||||
|
||||
### Low-pass Filter on D-term
|
||||
|
||||
The D-term is most susceptible to noise while slightly increased latency does not negatively affect performance.
|
||||
For this reason the D-term has a separately-configurable low-pass filter, [IMU_DGYRO_CUTOFF](../advanced_config/parameter_reference.md#IMU_DGYRO_CUTOFF).
|
||||
|
||||
### Slew-rate Filter on Motor Outputs
|
||||
|
||||
An optional slew-rate filter on the motor outputs.
|
||||
This rate may be configured as part of the [Multicopter Geometry](../config/actuators.md#motor-geometry-multicopter) when configuring actuators (which in turn modifies the [CA_Rn_SLEW](../advanced_config/parameter_reference.md#CA_R0_SLEW) parameters for each motor `n`).
|
||||
|
||||
## Filter Tuning
|
||||
|
||||
::: info
|
||||
The best filter settings depend on the vehicle.
|
||||
The defaults are set conservatively — such that they work on lower-quality setups as well.
|
||||
:::
|
||||
|
||||
First make sure to have the high-rate logging profile activated ([SDLOG_PROFILE](../advanced_config/parameter_reference.md#SDLOG_PROFILE) parameter).
|
||||
[Flight Review](../getting_started/flight_reporting.md) will then show an FFT plot for the roll, pitch and yaw controls.
|
||||
|
||||
:::warning
|
||||
|
||||
- Do not try to fix a vehicle that suffers from high vibrations with filter tuning!
|
||||
Instead fix the vehicle hardware setup.
|
||||
- Confirm that PID gains, in particular D, are not set too high as this can show up as vibrations.
|
||||
|
||||
:::
|
||||
|
||||
Filter tuning is best done by reviewing flight logs.
|
||||
You can do multiple flights right after each other with different parameters and then inspect all logs, but make sure to disarm in between so that separate log files are created.
|
||||
|
||||
The performed flight manoeuvre can simply be hovering in [Stabilized mode](../flight_modes_mc/manual_stabilized.md) with some rolling and pitching to all directions and some increased throttle periods.
|
||||
The total duration does not need to be more than 30 seconds.
|
||||
In order to better compare, the manoeuvre should be similar in all tests.
|
||||
|
||||
First tune the gyro filter [IMU_GYRO_CUTOFF](../advanced_config/parameter_reference.md#IMU_GYRO_CUTOFF) by increasing it in steps of 10 Hz while using a low D-term filter value ([IMU_DGYRO_CUTOFF](../advanced_config/parameter_reference.md#IMU_DGYRO_CUTOFF) = 30).
|
||||
Upload the logs to [Flight Review](https://logs.px4.io) and compare the _Actuator Controls FFT_ plot.
|
||||
Set the cutoff frequency to a value before the noise starts to increase noticeably (for frequencies around and above 60 Hz).
|
||||
|
||||
Then tune the D-term filter (`IMU_DGYRO_CUTOFF`) in the same way.
|
||||
Note that there can be negative impacts on performance if `IMU_GYRO_CUTOFF` and `IMU_DGYRO_CUTOFF` are set too far apart (the differences have to be significant though - e.g. D=15, gyro=80).
|
||||
|
||||
Below is an example for three different `IMU_DGYRO_CUTOFF` filter values (40Hz, 70Hz, 90Hz).
|
||||
At 90 Hz the general noise level starts to increase (especially for roll), and thus a cutoff frequency of 70 Hz is a safe setting.
|
||||
|
||||
|
||||
|
||||
|
||||
::: info
|
||||
The plot cannot be compared between different vehicles, as the y axis scale can be different.
|
||||
On the same vehicle it is consistent and independent of the flight duration.
|
||||
:::
|
||||
|
||||
If the flight plots shows significant low frequency spikes, like the one shown in the diagram below, you can remove it using a notch filter.
|
||||
In this case you might use the settings: [IMU_GYRO_NF0_FRQ=32](../advanced_config/parameter_reference.md#IMU_GYRO_NF0_FRQ) and [IMU_GYRO_NF0_BW=5](../advanced_config/parameter_reference.md#IMU_GYRO_NF0_BW) (note, this spike is narrower than usual).
|
||||
The low pass filters and the notch filter can be tuned independently (i.e. you don't need to set the notch filter before collecting the data for tuning the low pass filter).
|
||||
|
||||
|
||||
|
||||
## Additional Tips
|
||||
|
||||
1. Acceptable latency depends on vehicle size and expectations.
|
||||
FPV racers typically tune for the absolute minimal latency (as a ballpark `IMU_GYRO_CUTOFF` around 120, `IMU_DGYRO_CUTOFF` of 50 to 80).
|
||||
For bigger vehicles latency is less critical and `IMU_GYRO_CUTOFF` of around 80 might be acceptable.
|
||||
|
||||
1. You can start tuning at higher `IMU_GYRO_CUTOFF` values (e.g. 100Hz), which might be desirable because the default tuning of `IMU_GYRO_CUTOFF` is set very low (30Hz).
|
||||
The only caveat is that you must be aware of the risks:
|
||||
- Don't fly for more than 20-30 seconds
|
||||
- Check that the motors are not getting to hot
|
||||
- Listen for odd sounds and symptoms of excessive noise, as discussed above.
|
||||
@@ -0,0 +1,167 @@
|
||||
# Multicopter Configuration
|
||||
|
||||
Multicopter configuration and calibration follows the same high level steps as other frames: selection of firmware, configuration of the frame including actuator/motor geometry and output mappings, sensor configuration and calibration, configuration of safety and other features, and finally tuning.
|
||||
|
||||
This topic explains how to configure a multicopter using selected topics from [Standard Configuration](../config/index.md), [Advanced Configuration](../advanced_config/index.md), and [Flight Controller Peripherals](../peripherals/index.md), along with multicopter-specific tuning topics.
|
||||
|
||||
::: info
|
||||
This topic is the recommended entry point when performing first-time configuration and calibration of a new multicopter frame.
|
||||
:::
|
||||
|
||||
## Loading Firmware
|
||||
|
||||
The first step is to [load PX4 firmware](../config/firmware.md) onto your [flight controller](../flight_controller/index.md).
|
||||
This is most easily done using QGroundControl, which will automatically select appropriate firmware for your particular controller hardware.
|
||||
By default QGC will install the latest stable version of PX4, but you can choose beta or custom versions instead if needed.
|
||||
|
||||
Relevant topics:
|
||||
|
||||
- [Loading Firmware](../config/firmware.md)
|
||||
|
||||
## Frame Selection and Configuration
|
||||
|
||||
This section explains how to configure the vehicle type (multicopter), specific motor/flight control geometry, and motor outputs.
|
||||
|
||||
First [select a multicopter airframe](../config/airframe.md) (options are listed in [Airframe Reference > Copter](../airframes/airframe_reference.md#copter)).
|
||||
You should select the frame that matches your vehicle brand and model if one exists, and otherwise select the "Generic" frame type that most closely matches your geometry in terms of number of motors and their relative positions.
|
||||
For example, for a [Quadrotor X](../airframes/airframe_reference.md#quadrotor-x) frame you would look for the name of your frame in the list, and if it was not present select the [Generic Quadrotor X](../airframes/airframe_reference.md#copter_quadrotor_x_generic_quadcopter) frame.
|
||||
|
||||
::: info
|
||||
Any selected multicopter frame can be modified in the next step (actuator configuration) to add/remove motors and otherwise change the geometry, and to specify what flight controller outputs are connected to particular motors and the output properties.
|
||||
Selecting a frame that matches your vehicle reduces the configuration work required.
|
||||
|
||||
:::details How does this work (details)
|
||||
Selecting an airframe applies a [frame configuration file](../dev_airframes/adding_a_new_frame.md#adding-a-frame-configuration) that contains a predefined set of [parameters](../advanced_config/parameters.md), such as [CA_AIRFRAME=0](../advanced_config/parameter_reference.md#CA_AIRFRAME) for the vehicle type and [CA_ROTOR_COUNT](../advanced_config/parameter_reference.md#CA_ROTOR_COUNT) for the number of rotors.
|
||||
|
||||
A frame configuration can define everything about a vehicle, from it's geometry and output mappings, through to its tuning and calibration values.
|
||||
When you're bringing up a new vehicle though, the frame will usually contain a fairly minimal configuration:
|
||||
|
||||
- Frames named with "Generic" define the vehicle type, number of rotors, and "placeholder" rotor positions.
|
||||
After selecting the airframe you define the actual geometry and then configure outputs.
|
||||
- Frames named with model/brand will define the vehicle type, number of rotors, actual rotor positions, and motor directions.
|
||||
After selecting the airframe you usually still have to configure outputs.
|
||||
:::
|
||||
|
||||
The next step is to define your vehicle [geometry](../config/actuators.md#motor-geometry-multicopter) (the number of motors and their relative positions) and [assign those motors](../config/actuators.md#actuator-outputs) to the physical outputs that they are wired to on your flight controller (both of these are covered in [Actuator Configuration and Testing](../config/actuators.md)).
|
||||
|
||||
If using PWM ESCs and OneShot ESCs (but not DShot and DroneCAN/Cyphal ESC) you should then perform [ESC Calibration](../advanced_config/esc_calibration.md) before proceeding to [Motor Configuration](../config/actuators.md#motor-configuration).
|
||||
This ensures that all ESC provide exactly the same output for a given input (ideally we'd calibrate ESCs first, but you can't calibrate your ESCs until outputs are mapped).
|
||||
|
||||
The final step is [Motor Configuration](../config/actuators.md#motor-configuration):
|
||||
|
||||
- [Reverse any motors](../config/actuators.md#reversing-motors) that don't match the spin direction configured in the Geometry.
|
||||
For DShot ESC you can do this through the Acuator Testing UI.
|
||||
- PWM, OneShot, and CAN ESC, set the motor input limits for disarmed, low and high speed (not needed for DShot ESC)
|
||||
|
||||
Relevant topics:
|
||||
|
||||
- [Vehicle (Frame) Selection](../config/airframe.md) — Select vehicle type to match your frame.
|
||||
- [Actuator Configuration and Testing](../config/actuators.md) — Vehicle geometry, output mapping, motor configuration, testing.
|
||||
- [ESC Calibration](../advanced_config/esc_calibration.md) — Do between output mapping and motor configuration (topic above) for PWM and OneShot ESC.
|
||||
|
||||
## Sensor Setup and Calibration
|
||||
|
||||
PX4 most commonly relies on a magnetometer (compass) for direction information, a barometer for altitude, a gyroscope for body rates, an accelerometer for attitude and a GPS/GNSS for global position.
|
||||
Pixhawk flight controllers (and many others) have inbuilt magnetometer, accelerometer, gyroscope, and barometer.
|
||||
The inbuilt compass usually isn't particularly reliable, and it is common to also add an external compass (usually combined with a GNSS receiver in the same device).
|
||||
|
||||
We first need to set the [Sensor Orientation](../config/flight_controller_orientation.md), informing PX4 how the autopilot (and its inbuilt sensors) and external compasses are oriented relative to the vehicle.
|
||||
Generally you'll orient towards the front of the vehicle and not have to set anything.
|
||||
Once that is done we need to calibrate the compass(es), gyroscope, and accelerometer.
|
||||
|
||||
The core sensor setup is covered in these topics:
|
||||
|
||||
- [Sensor Orientation](../config/flight_controller_orientation.md)
|
||||
- [Compass](../config/compass.md)
|
||||
- [Gyroscope](../config/gyroscope.md)
|
||||
- [Accelerometer](../config/accelerometer.md)
|
||||
|
||||
PX4 can use other peripherals, such as distance sensors, optical flow sensors, traffic avoidance alarms, cameras, and so on:
|
||||
|
||||
- [Flight Controller Peripherals](../peripherals/index.md) - Setup specific sensors, optional sensors, actuators, and so on.
|
||||
|
||||
::: info
|
||||
Sensors that you don't need to calibrate/configure include:
|
||||
|
||||
- [Level Horizon](../config/level_horizon_calibration.md) calibration isn't usually needed if you have mounted the flight controller level.
|
||||
- Sensors that are not present, or that are not used by PX4 multicopter for flight control, such as [Airspeed sensors](../config/airspeed.md).
|
||||
- Sensors that don't need calibration, including: Barometers and GNSS.
|
||||
|
||||
:::
|
||||
|
||||
## Manual Control Setup
|
||||
|
||||
Pilots can control a vehicle manually using either a Radio Control (RC) System or a Joystick/Gamepad controller connected via QGroundControl.
|
||||
|
||||
::: info
|
||||
A manual control is essential in order to bring up a new vehicle safely!
|
||||
:::
|
||||
|
||||
Radio Control:
|
||||
|
||||
- [Radio Controller (RC) Setup](../config/radio.md)
|
||||
- [Flight Mode Configuration](../config/flight_mode.md)
|
||||
|
||||
Joystick/GamePad:
|
||||
|
||||
- [Joystick Setup](../config/joystick.md) (includes button/flight mode mapping)
|
||||
|
||||
## Safety Configuration
|
||||
|
||||
PX4 can be configured to automatically handle conditions such as low battery, losing radio or data links, flying too far from the home location, and so on:
|
||||
|
||||
- [Battery Estimation Tuning](../config/battery.md) — estimate remaining power (needed for low power failsafe).
|
||||
- [Safety Configuration (Failsafes)](../config/safety.md)
|
||||
|
||||
## Tuning
|
||||
|
||||
Tuning is the final step, carried out only after most other setup and configuration is complete.
|
||||
|
||||
- Rate and attitude controllers:
|
||||
- [Autotune](../config/autotune_mc.md) — Automates tuning PX4 rate and attitude controllers (recommended).
|
||||
|
||||
::: info
|
||||
Automatic tuning works on frames that have reasonable authority and dynamics around all the body axes.
|
||||
It has primarily been tested on racing quads and X500, and is expected to be less effective on tricopters with a tiltable rotor.
|
||||
|
||||
Manual tuning using these guides are only needed if there is a problem with autotune:
|
||||
|
||||
- [MC PID Tuning (Manual/Basic)](../config_mc/pid_tuning_guide_multicopter_basic.md) — Manual tuning basic how to.
|
||||
- [MC PID Tuning Guide (Manual/Detailed)](../config_mc/pid_tuning_guide_multicopter.md) — Manual tuning with detailed explanation.
|
||||
|
||||
:::
|
||||
|
||||
|
||||
- [MC Filter/Control Latency Tuning](../config_mc/filter_tuning.md) — Trade off control latency and noise filtering.
|
||||
- [MC Setpoint Tuning (Trajectory Generator)](../config_mc/mc_trajectory_tuning.md)
|
||||
- [MC Jerk-limited Type Trajectory](../config_mc/mc_jerk_limited_type_trajectory.md)
|
||||
- [Multicopter Racer Setup](../config_mc/racer_setup.md)
|
||||
|
||||
<!--
|
||||
- Explain what you have to tune on PX4, what you can tune, and what each topic covers
|
||||
- I expect we should start with an exhaustive list of the tuning you could want to do - such as position tuning, etc. Do we have one?
|
||||
-->
|
||||
<!-- TBD this is just text for me to mine
|
||||
|
||||
AFAIK autotune was tested on various not so custom platforms e.g. X500, racer quad, Loong standard VTOL. I honestly used it only once on a tricopter and it worked for roll and pitch but the resulting yaw tuning was not stable. Since then it was improved but that's not merged yet :eyes: https://github.com/PX4/PX4-Autopilot/pull/21857
|
||||
Autotune was never tested on a Helicopter.
|
||||
can you in theory autotune frame with any number of motors?
|
||||
In theory yes but it needs to be able to have reasonable authority around all axes so I'd expect autotune to not work well for a monocopter without swashplate and so on. Probably also the controllers wouldn't work out of the box. I saw issues before with designs that tilt the rotor e.g. tricopter, bicopter, ... again
|
||||
|
||||
|
||||
will PX4 still understand how to autotune?
|
||||
Autotune should work for any vehicle that has reasonable authority and dynamics around all the body axes. A tiltable motor e.g. tricopter has at the least dynamics which are less tested with autotune.
|
||||
My assumption is that the mixing system can cope with whatever geometry you throw at it.
|
||||
Yes but it must be physically feasible. E.g. if you make a quadrotor where all motors turn the same way it will "deal" with it but that cannot work without very specific controllers. Same for a monocopter or a tricopter without swiveling one motor.
|
||||
-->
|
||||
|
||||
## See Also
|
||||
|
||||
- [QGroundControl > Setup](https://docs.qgroundcontrol.com/master/en/qgc-user-guide/setup_view/setup_view.html)
|
||||
- [Flight Controller Peripherals](../peripherals/index.md) - Setup specific sensors, optional sensors, actuators, and so on.
|
||||
- [Advanced Configuration](../advanced_config/index.md) - Factory/OEM calibration, configuring advanced features, less-common configuration.
|
||||
- Vehicle-Centric Config/Tuning:
|
||||
- **Multicopter Config/Tuning**
|
||||
- [Helicopter Config/Tuning](../config_heli/index.md)
|
||||
- [Fixed Wing Config/Tuning](../config_fw/index.md)
|
||||
- [VTOL Config/Tuning](../config_vtol/index.md)
|
||||
@@ -0,0 +1,78 @@
|
||||
# Jerk-limited Type Trajectory for Multicopters
|
||||
|
||||
The Jerk-limited trajectory type provides smooth motion in response to user stick input or mission changes (e.g.: for filming, mapping, cargo).
|
||||
It generates symmetric smooth S-curves where the jerk and acceleration limits are always guaranteed.
|
||||
|
||||
This trajectory type is always enabled in [Mission mode](../flight_modes_mc/mission.md).
|
||||
To enable it in [Position mode](../flight_modes_mc/position.md) set the parameter [MPC_POS_MODE](../advanced_config/parameter_reference.md#MPC_POS_MODE) to `Smoothed velocity`.
|
||||
|
||||
::: info
|
||||
The jerk-limited type is not used _by default_ in position mode.
|
||||
It may not be suitable for vehicles/use-cases that require a faster response - e.g. racer quads.
|
||||
:::
|
||||
|
||||
## Trajectory Generator
|
||||
|
||||
The graph below shows a typical jerk-limited profile with the following constraints:
|
||||
|
||||
- `jMax`: maximum jerk
|
||||
- `a0`: initial acceleration
|
||||
- `aMax`: maximum acceleration
|
||||
- `a3`: final acceleration (always 0)
|
||||
- `v0`: initial velocity
|
||||
- `vRef`: desired velocity
|
||||
|
||||
The constraints `jMax`, `aMax` are configurable by the user via parameters and can be different in manual position control and auto mode.
|
||||
|
||||
The resulting velocity profile is often called "S-Curve".
|
||||
|
||||
|
||||
|
||||
## Manual Mode
|
||||
|
||||
In manual position mode, the sticks are mapped to velocity where a full XY-stick deflection corresponds to [MPC_VEL_MANUAL](../advanced_config/parameter_reference.md#MPC_VEL_MANUAL) and a full Z-stick deflection corresponds to [MPC_Z_VEL_MAX_UP](../advanced_config/parameter_reference.md#MPC_Z_VEL_MAX_UP) (upward motion) or [MPC_Z_VEL_MAX_DN](../advanced_config/parameter_reference.md#MPC_Z_VEL_MAX_DN) (downward motion).
|
||||
|
||||
### Constraints
|
||||
|
||||
XY-plane:
|
||||
|
||||
- `jMax`: [MPC_JERK_MAX](../advanced_config/parameter_reference.md#MPC_JERK_MAX)
|
||||
- `aMax`: [MPC_ACC_HOR_MAX](../advanced_config/parameter_reference.md#MPC_ACC_HOR_MAX)
|
||||
|
||||
Z-axis:
|
||||
|
||||
- `jMax`: [MPC_JERK_MAX](../advanced_config/parameter_reference.md#MPC_JERK_MAX)
|
||||
- `aMax` (upward motion): [MPC_ACC_UP_MAX](../advanced_config/parameter_reference.md#MPC_ACC_UP_MAX)
|
||||
- `aMax` (downward motion): [MPC_ACC_DOWN_MAX](../advanced_config/parameter_reference.md#MPC_ACC_DOWN_MAX)
|
||||
|
||||
## Auto Mode
|
||||
|
||||
In auto mode, the desired velocity is [MPC_XY_CRUISE](../advanced_config/parameter_reference.md#MPC_XY_CRUISE) but this value is automatically adjusted depending on the distance to the next waypoint, the maximum possible velocity in the waypoint and the maximum desired acceleration and jerk.
|
||||
The vertical speed is defined by [MPC_Z_V_AUTO_UP](../advanced_config/parameter_reference.md#MPC_Z_V_AUTO_UP) (upward motion) and [MPC_Z_V_AUTO_DN](../advanced_config/parameter_reference.md#MPC_Z_V_AUTO_DN) (downward motion).
|
||||
|
||||
### Constraints
|
||||
|
||||
XY-plane:
|
||||
|
||||
- `jMax`: [MPC_JERK_AUTO](../advanced_config/parameter_reference.md#MPC_JERK_AUTO)
|
||||
- `aMax`: [MPC_ACC_HOR](../advanced_config/parameter_reference.md#MPC_ACC_HOR)
|
||||
|
||||
Z-axis:
|
||||
|
||||
- `jMax`: [MPC_JERK_AUTO](../advanced_config/parameter_reference.md#MPC_JERK_AUTO)
|
||||
- `aMax` (upward motion): [MPC_ACC_UP_MAX](../advanced_config/parameter_reference.md#MPC_ACC_UP_MAX)
|
||||
- `aMax` (downward motion): [MPC_ACC_DOWN_MAX](../advanced_config/parameter_reference.md#MPC_ACC_DOWN_MAX)
|
||||
|
||||
Distance to velocity gains when close to a waypoint:
|
||||
|
||||
- [MPC_XY_TRAJ_P](../advanced_config/parameter_reference.md#MPC_XY_TRAJ_P)
|
||||
|
||||
### Related Parameters
|
||||
|
||||
- [MPC_XY_VEL_MAX](../advanced_config/parameter_reference.md#MPC_XY_VEL_MAX)
|
||||
- [MPC_Z_VEL_MAX_UP](../advanced_config/parameter_reference.md#MPC_Z_VEL_MAX_UP)
|
||||
- [MPC_Z_VEL_MAX_DN](../advanced_config/parameter_reference.md#MPC_Z_VEL_MAX_DN)
|
||||
- [MPC_TKO_SPEED](../advanced_config/parameter_reference.md#MPC_TKO_SPEED)
|
||||
- [MPC_LAND_SPEED](../advanced_config/parameter_reference.md#MPC_LAND_SPEED)
|
||||
- [MPC_LAND_ALT1](../advanced_config/parameter_reference.md#MPC_LAND_ALT1)
|
||||
- [MPC_LAND_ALT2](../advanced_config/parameter_reference.md#MPC_LAND_ALT2)
|
||||
@@ -0,0 +1,76 @@
|
||||
# Multicopter Setpoint Tuning (Trajectory Generator)
|
||||
|
||||
This document provides an overview of the multicopter tuning parameters that change the _user experience_: how fast the vehicle reacts to stick movements or direction changes in missions, the maximum allowed velocity, etc.
|
||||
|
||||
In other words, this topic explains how to tune the parameters that affect the value of a _desired setpoint_ rather than those that affect how well the vehicle _tracks_ the setpoint).
|
||||
|
||||
The algorithm that generates those setpoints is called a "trajectory generator".
|
||||
|
||||
:::warning
|
||||
This guide is for advanced users/experts.
|
||||
:::
|
||||
|
||||
:::tip
|
||||
Follow the instructions in the [Multicopter PID Tuning Guide](../config_mc/pid_tuning_guide_multicopter.md) _before_ doing any of the tuning described here.
|
||||
Do not use these tuning parameters to fix bad tracking or vibration!
|
||||
:::
|
||||
|
||||
## Overview
|
||||
|
||||
The input to the P/PID controller is a _desired setpoint_ that the vehicle should attempt to track.
|
||||
[PID Tuning](../config_mc/pid_tuning_guide_multicopter.md) ("Lower level tuning") aims to reduce the error between the desired setpoint and the estimate of the vehicle state.
|
||||
|
||||
The _desired setpoint_ passed to the P/PID controller is itself calculated from a _demanded setpoint_ based on a stick position (in RC modes) or from a mission command.
|
||||
The demanded setpoint can change very quickly (e.g. if a user moves stick from zero to maximum value as a "step").
|
||||
Vehicle flight characteristics are better if the corresponding desired setpoint changes as a "ramp".
|
||||
|
||||
_Setpoint value tuning_ ("higher level tuning") is used to specify the mapping between the _demanded_ and the _desired_ setpoints - i.e. defining the "ramp" at which the desired setpoint follows the demanded setpoint.
|
||||
|
||||
:::tip
|
||||
Poorly tuned [P/PID Gains](../config_mc/pid_tuning_guide_multicopter.md) can lead to instability.
|
||||
Poorly tuned _setpoint values_ cannot result in instability, but may result in either very jerky or very unresponsive reactions to setpoint changes.
|
||||
:::
|
||||
|
||||
<a id="modes"></a>
|
||||
|
||||
## Flight Modes Trajectory Support
|
||||
|
||||
[Mission mode](../flight_modes_mc/mission.md) used the [Jerk-limited](../config_mc/mc_jerk_limited_type_trajectory.md) trajectory all the time.
|
||||
|
||||
[Position mode](../flight_modes_mc/position.md) supports the [implementations](#position-mode-implementations) listed below.
|
||||
It uses the acceleration based mapping by default; other types can be set using [MPC_POS_MODE](../advanced_config/parameter_reference.md#MPC_POS_MODE).
|
||||
|
||||
[Altitude mode](../flight_modes_mc/altitude.md) similarly supports the [implementations](#altitude-mode-implementations) selected by [MPC_POS_MODE](../advanced_config/parameter_reference.md#MPC_POS_MODE), but _only_ for smoothing the vertical component (i.e. when controlling the altitude).
|
||||
|
||||
No other modes support trajectory tuning.
|
||||
|
||||
## Position Mode Implementations
|
||||
|
||||
The following list provides an _overview_ of the different implementations of how the stick input is interpreted and turned into trajectory setpoints:
|
||||
|
||||
- Acceleration based (Default)
|
||||
- Horizontal stick input mapped to acceleration setpoints.
|
||||
- Intuitive stick feel because it's like pushing the vehicle around.
|
||||
- No unexpected tilt changes upon reaching travel speed velocity.
|
||||
- Vertical stick input mapped with jerk-limited trajectory.
|
||||
- Set in position mode using `MPC_POS_MODE=Acceleration based`.
|
||||
- [Jerk-limited](../config_mc/mc_jerk_limited_type_trajectory.md)
|
||||
- Used when smooth motion is required (e.g.: filming, mapping, cargo).
|
||||
- Generates symmetric smooth S-curves where the jerk and acceleration limits are always guaranteed.
|
||||
- May not be suitable for vehicles/use-cases that require a faster response - e.g. race quads.
|
||||
- Set in position mode using `MPC_POS_MODE=Smoothed velocity`.
|
||||
- **Simple position control**
|
||||
- Sticks map directly to velocity setpoints without smoothing.
|
||||
- Useful for velocity control tuning.
|
||||
- Set in position mode using `MPC_POS_MODE=Direct velocity`.
|
||||
|
||||
## Altitude Mode Implementations
|
||||
|
||||
Analogously to [position mode implementations](#position-mode-implementations) these are the implementations for interpreting vertical stick input:
|
||||
|
||||
- [Jerk-limited](../config_mc/mc_jerk_limited_type_trajectory.md)
|
||||
- Smoothed vertical input.
|
||||
- Set in altitude mode with `MPC_POS_MODE` Smoothed velocity or Acceleration based.
|
||||
- **Simple altitude control**
|
||||
- Unsmoothed vertical input.
|
||||
- Set in altitude mode only when using `MPC_POS_MODE=Direct velocity`.
|
||||
@@ -0,0 +1,293 @@
|
||||
# Multicopter PID Tuning Guide (Manual/Advanced)
|
||||
|
||||
This topic provides detailed information about PX4 controllers, and how they are tuned.
|
||||
|
||||
:::tip
|
||||
[Autotune](../config/autotune_mc.md) is recommended 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](#airmode-mixer-saturation) setting.
|
||||
|
||||
## Tuning Steps
|
||||
|
||||
::: info
|
||||
For safety reasons, the default gains are set to low values.
|
||||
You must increase the gains before you can expect good control responses.
|
||||
:::
|
||||
|
||||
Here are some general points to follow when tuning:
|
||||
|
||||
- All gains should be increased very slowly as large gains may cause dangerous oscillations!
|
||||
Typically increase gains by 20-30% per iteration, reducing to 5-10% for final fine tuning.
|
||||
- Land before changing a parameter.
|
||||
Slowly increase the throttle and check for oscillations.
|
||||
- Tune the vehicle around the hovering thrust point, and use the [thrust curve parameter](#thrust-curve) to account for thrust non-linearities or high-thrust oscillations.
|
||||
- Optionally enable the high-rate logging profile with the [SDLOG_PROFILE](../advanced_config/parameter_reference.md#SDLOG_PROFILE) parameter so you can use the log to evaluate the rate and attitude tracking performance (the option can be disabled afterwards).
|
||||
|
||||
:::warning
|
||||
Always disable [MC_AIRMODE](../advanced_config/parameter_reference.md#MC_AIRMODE) when tuning a vehicle.
|
||||
:::
|
||||
|
||||
### Rate Controller
|
||||
|
||||
The rate controller is the inner-most loop with three independent PID controllers to control the body rates (roll, pitch, yaw).
|
||||
|
||||
::: info
|
||||
A well-tuned rate controller is very important as it affects _all_ flight modes.
|
||||
A badly tuned rate controller will be visible in [Position mode](../flight_modes_mc/position.md), for example, as "twitches" or oscillations (the vehicle will not hold perfectly still in the air).
|
||||
:::
|
||||
|
||||
#### Rate Controller Architecture/Form
|
||||
|
||||
PX4 supports two (mathematically equivalent) forms of the PID rate controller in a single "mixed" implementation: [Parallel](#parallel-form) and [Standard](#standard-form).
|
||||
|
||||
Users can select the form that is used by setting the proportional gain for the other form to "1" (i.e. in the diagram below set **K** to 1 for the parallel form, or **P** to 1 for the standard form - this will replace either the K or P blocks with a line).
|
||||
|
||||
|
||||
|
||||
<!-- The drawing is on draw.io: https://drive.google.com/file/d/1hXnAJVRyqNAdcreqNa5W4PQFkYnzwgOO/view?usp=sharing -->
|
||||
|
||||
- _G(s)_ represents the angular rates dynamics of a vehicle
|
||||
- _r_ is the rate setpoint
|
||||
- _y_ is the body angular rate (measured by a gyro)
|
||||
- _e_ is the error between the rate setpoint and the measured rate
|
||||
- _u_ is the output of the PID controller
|
||||
|
||||
The two forms are described below.
|
||||
|
||||
::: info
|
||||
The derivative term (**D**) is on the feedback path in order to avoid an effect known as the [derivative kick](http://brettbeauregard.com/blog/2011/04/improving-the-beginner%E2%80%99s-pid-derivative-kick/).
|
||||
:::
|
||||
|
||||
:::tip
|
||||
For more information see:
|
||||
|
||||
- [Not all PID controllers are the same](https://www.controleng.com/articles/not-all-pid-controllers-are-the-same/) (www.controleng.com)
|
||||
- [PID controller > Standard versus parallel (ideal) PID form](<https://en.wikipedia.org/wiki/PID_controller#Standard_versus_parallel_(ideal)_form>) (Wikipedia)
|
||||
|
||||
:::
|
||||
|
||||
##### Parallel Form
|
||||
|
||||
The _parallel form_ is the simplest form, and is (hence) commonly used in textbooks.
|
||||
In this case the output of the controller is simply the sum of the proportional, integral and derivative actions.
|
||||
|
||||
|
||||
|
||||
##### Standard Form
|
||||
|
||||
This form is mathematically equivalent to the parallel form, but the main advantage is that (even if it seems counter intuitive) it decouples the proportional gain tuning from the integral and derivative gains.
|
||||
This means that a new platform can easily be tuned by taking the gains of a drone with similar size/inertia and simply adjust the K gain to have it flying properly.
|
||||
|
||||
|
||||
|
||||
#### Rate PID Tuning
|
||||
|
||||
The related parameters for the tuning of the PID rate controllers are:
|
||||
|
||||
- Roll rate control ([MC_ROLLRATE_P](../advanced_config/parameter_reference.md#MC_ROLLRATE_P), [MC_ROLLRATE_I](../advanced_config/parameter_reference.md#MC_ROLLRATE_I), [MC_ROLLRATE_D](../advanced_config/parameter_reference.md#MC_ROLLRATE_D), [MC_ROLLRATE_K](../advanced_config/parameter_reference.md#MC_ROLLRATE_K))
|
||||
- Pitch rate control ([MC_PITCHRATE_P](../advanced_config/parameter_reference.md#MC_PITCHRATE_P), [MC_PITCHRATE_I](../advanced_config/parameter_reference.md#MC_PITCHRATE_I), [MC_PITCHRATE_D](../advanced_config/parameter_reference.md#MC_PITCHRATE_D), [MC_PITCHRATE_K](../advanced_config/parameter_reference.md#MC_PITCHRATE_K))
|
||||
- Yaw rate control ([MC_YAWRATE_P](../advanced_config/parameter_reference.md#MC_YAWRATE_P), [MC_YAWRATE_I](../advanced_config/parameter_reference.md#MC_YAWRATE_I), [MC_YAWRATE_D](../advanced_config/parameter_reference.md#MC_YAWRATE_D), [MC_YAWRATE_K](../advanced_config/parameter_reference.md#MC_YAWRATE_K))
|
||||
|
||||
The rate controller can be tuned in [Acro mode](../flight_modes_mc/acro.md) or [Stabilized mode](../flight_modes_mc/manual_stabilized.md):
|
||||
|
||||
- _Acro mode_ is preferred because it allows for isolated rate control testing.
|
||||
However it is significantly harder to pilot.
|
||||
|
||||
::: warning
|
||||
If you choose this mode, you must [disable all stick expo and have reasonable maximum rates for all axes](../flight_modes_mc/acro.md#stick-input-mapping):
|
||||
- `MC_ACRO_EXPO` = 0, `MC_ACRO_EXPO_Y` = 0, `MC_ACRO_SUPEXPO` = 0,
|
||||
`MC_ACRO_SUPEXPOY` = 0
|
||||
- `MC_ACRO_P_MAX` = 200, `MC_ACRO_R_MAX` = 200
|
||||
- `MC_ACRO_Y_MAX` = 100
|
||||
|
||||
For PX4 v1.15 and later the defaults are set for this purpose to a maximum rate of 100°/s linear mapping for all axes.
|
||||
:::
|
||||
|
||||
- _Stabilized mode_ is simpler to fly, but it is also much more difficult to distinguish if attitude or rate controller causes a certain behavior.
|
||||
|
||||
If the vehicle does not fly at all:
|
||||
|
||||
- If there are strong oscillations when first trying to takeoff (to the point where it does not fly), decrease all **P** and **D** gains until it takes off.
|
||||
- If the reaction to RC movement is minimal, increase the **P** gains.
|
||||
|
||||
The actual tuning is roughly the same in _Manual mode_ or _Acro mode_:
|
||||
You iteratively tune the **P** and **D** gains for roll and pitch, and then the **I** gain.
|
||||
Initially you can use the same values for roll and pitch, and once you have good values,
|
||||
you can fine-tune them by looking at roll and pitch response separately (if your vehicle is symmetric, this is not needed).
|
||||
For yaw it is very similar, except that **D** can be left at 0.
|
||||
|
||||
##### Proportional Gain (P/K)
|
||||
|
||||
The proportional gain is used to minimize the tracking error (below we use **P** to refer to both **P** or **K**).
|
||||
It is responsible for a quick response and thus should be set as high as possible, but without introducing oscillations.
|
||||
|
||||
- If the **P** gain is too high: you will see high-frequency oscillations.
|
||||
- If the **P** gain is too low:
|
||||
- the vehicle will react slowly to input changes.
|
||||
- In _Acro mode_ the vehicle will drift, and you will constantly need to correct to keep it level.
|
||||
|
||||
##### Derivative Gain (D)
|
||||
|
||||
The **D** (derivative) gain is used for rate damping.
|
||||
It is required but should be set only as high as needed to avoid overshoots.
|
||||
|
||||
- If the **D** gain is too high: the motors become twitchy (and maybe hot), because the **D** term amplifies noise.
|
||||
- If the **D** gain is too low: you see overshoots after a step-input.
|
||||
|
||||
Typical values are:
|
||||
|
||||
- standard form (**P** = 1): between 0.01 (4" racer) and 0.04 (500 size), for any value of **K**
|
||||
- parallel form (**K** = 1): between 0.0004 and 0.005, depending on the value of **P**
|
||||
|
||||
##### Integral Gain (I)
|
||||
|
||||
The **I** (integral) gain keeps a memory of the error. The **I** term increases when the desired rate is not reached over some time.
|
||||
It is important (especially when flying _Acro mode_), but it should not be set too high.
|
||||
|
||||
- If the I gain is too high: you will see slow oscillations.
|
||||
- If the I gain is too low: this is best tested in _Acro mode_, by tilting the vehicle to one side about 45 degrees, and keeping it like that.
|
||||
It should keep the same angle.
|
||||
If it drifts back, increase the **I** gain.
|
||||
A low **I** gain is also visible in a log, when there is an offset between the desired and the actual rate over a longer time.
|
||||
|
||||
Typical values are:
|
||||
|
||||
- standard form (**P** = 1): between 0.5 (VTOL plane), 1 (500 size) and 8 (4" racer), for any value of **K**
|
||||
- parallel form (**K** = 1): between 0.3 and 0.5 if **P** is around 0.15
|
||||
The pitch gain usually needs to be a bit higher than the roll gain.
|
||||
|
||||
#### Testing Procedure
|
||||
|
||||
To test the current gains, provide a fast **step-input** when hovering and observe how the vehicle reacts.
|
||||
It should immediately follow the command, and neither oscillate, nor overshoot (it feels 'locked-in').
|
||||
|
||||
You can create a step-input for example for roll, by quickly pushing the roll stick to one side, and then let it go back quickly (be aware that the stick will oscillate too if you just let go of it, because it is spring-loaded — a well-tuned vehicle will follow these oscillations).
|
||||
|
||||
::: info
|
||||
A well-tuned vehicle in _Acro mode_ will not tilt randomly towards one side, but keeps the attitude for tens of seconds even without any corrections.
|
||||
:::
|
||||
|
||||
#### Logs
|
||||
|
||||
Looking at a log helps to evaluate tracking performance as well.
|
||||
Here is an example for good roll and yaw rate tracking:
|
||||
|
||||
|
||||
|
||||
|
||||
And here is a good example for the roll rate tracking with several flips, which create an extreme step-input.
|
||||
You can see that the vehicle overshoots only by a very small amount:
|
||||
|
||||
|
||||
### Attitude Controller
|
||||
|
||||
This controls the orientation and outputs desired body rates with the following tuning parameters:
|
||||
|
||||
- Roll control ([MC_ROLL_P](../advanced_config/parameter_reference.md#MC_ROLL_P))
|
||||
- Pitch control ([MC_PITCH_P](../advanced_config/parameter_reference.md#MC_PITCH_P))
|
||||
- Yaw control ([MC_YAW_P](../advanced_config/parameter_reference.md#MC_YAW_P))
|
||||
|
||||
The attitude controller is much easier to tune.
|
||||
In fact, most of the time the defaults do not need to be changed at all.
|
||||
|
||||
To tune the attitude controller, fly in _Stabilized mode_ and increase the **P** gains gradually.
|
||||
If you start to see oscillations or overshoots, the gains are too high.
|
||||
|
||||
The following parameters can also be adjusted. These determine the maximum rotation rates around all three axes:
|
||||
|
||||
- Maximum roll rate ([MC_ROLLRATE_MAX](../advanced_config/parameter_reference.md#MC_ROLLRATE_MAX))
|
||||
- Maximum pitch rate ([MC_PITCHRATE_MAX](../advanced_config/parameter_reference.md#MC_PITCHRATE_MAX))
|
||||
- Maximum yaw rate ([MC_YAWRATE_MAX](../advanced_config/parameter_reference.md#MC_YAWRATE_MAX))
|
||||
|
||||
### Thrust Curve
|
||||
|
||||
The tuning above optimises performance around the hover throttle.
|
||||
But you may start to see oscillations when going towards full throttle.
|
||||
|
||||
To counteract that, adjust the **thrust curve** with the [THR_MDL_FAC](../advanced_config/parameter_reference.md#THR_MDL_FAC) parameter.
|
||||
|
||||
::: info
|
||||
The rate controller might need to be re-tuned if you change this parameter.
|
||||
:::
|
||||
|
||||
The mapping from motor control signals (e.g. PWM) to expected thrust is linear by default — setting `THR_MDL_FAC` to 1 makes it quadratic.
|
||||
Values in between use a linear interpolation of the two. Typical values are between 0.3 and 0.5.
|
||||
|
||||
If you have a [thrust stand](https://www.tytorobotics.com/pages/series-1580-1585) <!-- RCbenchmark Series 1580/1585 Test Stand --> (or can otherwise _measure_ thrust and motor commands simultaneously), you can determine the relationship between the motor control signal and the motor's actual thrust, and fit a function to the data.
|
||||
The motor command in PX4 called `actuator_output` can be PWM, Dshot, UAVCAN commands for the respective ESCs in use.
|
||||
[This Notebook][THR_MDL_FAC_Calculation] shows one way for how the thrust model factor `THR_MDL_FAC` may be calculated from previously measured thrust and PWM data.
|
||||
The curves shown in this plot are parametrized by both α and k, and also show thrust and PWM in real units (kgf and μs).
|
||||
In order to simplify the curve fit problem, you can normalize the data between 0 and 1 to find `k` without having to estimate α (α = 1, when the data is normalized).
|
||||
|
||||
] <!-- removed link to THR_MDL_FAC_Calculation as causes problems for link checker -->
|
||||
|
||||
::: info
|
||||
The mapping between PWM and static thrust depends highly on the battery voltage.
|
||||
:::
|
||||
|
||||
An alternative way of performing this experiment is to make a scatter plot of the normalized motor command and thrust values, and iteratively tune the thrust curve by experimenting with the `THR_MDL_FAC` parameter.
|
||||
An example of that graph is shown here:
|
||||
|
||||
|
||||
|
||||
If raw motor command and thrust data is collected throughout the full-scale range in the experiment, you can normalize the data using the equation:
|
||||
|
||||
_normalized_value = ( raw_value - min (raw_value) ) / ( max ( raw_value ) - min ( raw_value ) )_
|
||||
|
||||
After you have a scatter plot of the normalized values, you can try and make the curve match by plotting the equation
|
||||
|
||||
_rel_thrust = ( `THR_MDL_FAC` ) _ rel*signal^2 + ( 1 - `THR_MDL_FAC` ) * rel*signal*
|
||||
|
||||
over a linear range of normalized motor command values between 0 and 1.
|
||||
Note that this is the equation that is used in the firmware to map thrust and motor command, as shown in the [THR_MDL_FAC](../advanced_config/parameter_reference.md#THR_MDL_FAC) parameter reference.
|
||||
Here, _rel_thrust_ is the normalized thrust value between 0 and 1, and _rel_signal_ is the normalized motor command signal value between 0 and 1.
|
||||
|
||||
In this example above, the curve seemed to fit best when `THR_MDL_FAC` was set to 0.7.
|
||||
|
||||
[THR_MDL_FAC_Calculation]: https://github.com/PX4/PX4-user_guide/blob/main/assets/config/mc/ThrustCurve.ipynb
|
||||
|
||||
If you don't have access to a thrust stand, you can also tune the modeling factor empirically.
|
||||
Start off with 0.3 and increase it by 0.1 at a time.
|
||||
If it is too high, you will start to notice oscillations at lower throttle values.
|
||||
If it is too low you'll notice oscillations at higher throttle values.
|
||||
|
||||
<a id="airmode"></a>
|
||||
|
||||
### Airmode & Mixer Saturation
|
||||
|
||||
The rate controller outputs torque commands for all three axis (roll, pitch and yaw) and a scalar thrust value, which need to be converted into individual motor thrust commands.
|
||||
This step is called mixing.
|
||||
|
||||
It can happen that one of the motor commands becomes negative, for example for a low thrust and large roll command (and similarly it can go above 100%).
|
||||
This is a mixer saturation.
|
||||
It is physically impossible for the vehicle to execute these commands (except for reversible motors).
|
||||
PX4 has two modes to resolve this:
|
||||
|
||||
- Either by reducing the commanded torque for roll such that none of the motor commands is below zero (Airmode disabled).
|
||||
In the extreme case where the commanded thrust is zero, it means that no attitude correction is possible anymore, which is why a minimum thrust is always required for this mode.
|
||||
- Or by increasing (boosting) the commanded thrust, such that none of the motor commands is negative (Airmode enabled).
|
||||
This has the big advantage that the attitude/rates can be tracked correctly even at low or zero throttle.
|
||||
It generally improves the flight performance.
|
||||
|
||||
However it increases the total thrust which can lead to situations where the vehicle continues to ascend even though the throttle is reduced to zero.
|
||||
For a well-tuned, correctly functioning vehicle it is not the case, but for example it can happen when the vehicle strongly oscillates due to too high P tuning gains.
|
||||
|
||||
Both modes are shown below with a 2D illustration for two motors and a torque command for roll <span style="color:#9673A6">r</span>.
|
||||
On the left motor <span style="color:#9673A6">r</span> is added to the commanded thrust, while on the right motor it is subtracted from it.
|
||||
The motor thrusts are in <span style="color:#6A9153">green</span>.
|
||||
With Airmode enabled, the commanded thrust is increased by <span style="color:#B85450">b</span>.
|
||||
When it is disabled, <span style="color:#9673A6">r</span> is reduced.
|
||||
|
||||
|
||||
|
||||
<!-- The drawing is on draw.io: https://drive.google.com/file/d/1N0qjbiJX6JuEk2I1-xFvigLEPKJRIjBP/view?usp=sharing
|
||||
On the first Tab
|
||||
-->
|
||||
|
||||
If mixing becomes saturated towards the upper bound the commanded thrust is reduced to ensure that no motor is commanded to deliver more than 100% thrust.
|
||||
This behaviour is similar to the Airmode logic, and is applied whether Airmode is enabled or disabled.
|
||||
|
||||
Once your vehicle flies well you can enable Airmode via the [MC_AIRMODE](../advanced_config/parameter_reference.md#MC_AIRMODE) parameter.
|
||||
@@ -0,0 +1,130 @@
|
||||
# Multicopter PID Tuning Guide (Manual/Basic)
|
||||
|
||||
This tutorial explains how to _manually_ tune the PID loops on PX4 for all [multicopter setups](../airframes/airframe_reference.md#copter) (Quads, Hexa, Octo etc).
|
||||
|
||||
:::tip
|
||||
[Autotune](../config/autotune_mc.md) is recommended for most users, as it is far faster, easier and provides good tuning for most frames.
|
||||
Manual tuning is recommended for frames where autotuning does not work, or where fine-tuning is essential.
|
||||
:::
|
||||
|
||||
Generally if you're using an appropriate [supported frame configuration](../airframes/airframe_reference.md#copter), the default tuning should allow you to fly the vehicle safely.
|
||||
Tuning is recommended for all new vehicle setups to get the _very best_ performance, because relatively small hardware and assembly changes can affect the gains required tuning gains for optimal flight.
|
||||
For example, different ESCs or motors change the optimal tuning gains.
|
||||
|
||||
## Introduction
|
||||
|
||||
PX4 uses **P**roportional, **I**ntegral, **D**erivative (PID) controllers (these are the most widespread control technique).
|
||||
|
||||
The _QGroundControl_ **PID Tuning** setup provides real-time plots of the vehicle setpoint and response curves.
|
||||
The goal of tuning is to set the P/I/D values such that the _Response_ curve matches the _Setpoint_ curve as closely as possible (i.e. a fast response without overshoots).
|
||||
|
||||
|
||||
|
||||
The controllers are layered, which means a higher-level controller passes its results to a lower-level controller.
|
||||
The lowest-level controller is the **rate controller**, followed by the **attitude controller**, and finally the **velocity & position controller**.
|
||||
The PID tuning needs to be done in this same order, starting with the rate controller, as it will affect all other controllers.
|
||||
|
||||
The testing procedure for each controller (rate, attitude, velocity/position) and axis (yaw, roll, pitch) is always the same: create a fast setpoint change by moving the sticks very rapidly and observe the response.
|
||||
Then adjust the sliders (as discussed below) to improve the tracking of the response to the setpoint.
|
||||
|
||||
:::tip
|
||||
|
||||
- Rate controller tuning is the most important, and if tuned well, the other controllers often need no or only minor adjustments
|
||||
- Usually the same tuning gains can be used for roll and pitch.
|
||||
- use Acro/Stabilized/Altitude mode to tune the rate controller
|
||||
- Use [Position mode](../flight_modes_mc/position.md) to tune the _Velocity Controller_ and the _Position Controller_.
|
||||
Make sure to switch to the _Simple position control_ mode so you can generate step inputs.
|
||||
|
||||
:::
|
||||
|
||||
## Preconditions
|
||||
|
||||
- You have selected the closest matching [default frame configuration](../config/airframe.md) for your vehicle.
|
||||
This should give you a vehicle that already flies.
|
||||
- You should have done an [ESC calibration](../advanced_config/esc_calibration.md).
|
||||
- If using PWM outputs their minimum values should be set correctly in the [Actuator Configuration](../config/actuators.md).
|
||||
These need to be set low, but such that the **motors never stop** when the vehicle is armed.
|
||||
|
||||
This can be tested in [Acro mode](../flight_modes_mc/acro.md) or in [Stabilized mode](../flight_modes_mc/manual_stabilized.md):
|
||||
|
||||
- Remove propellers
|
||||
- Arm the vehicle and lower the throttle to the minimum
|
||||
- Tilt the vehicle to all directions, about 60 degrees
|
||||
- Check that no motors turn off
|
||||
|
||||
- Use a high-rate telemetry link such as WiFi if at all possible (a typical low-range telemetry radio is not fast enough for real-time feedback and plots).
|
||||
This is particularly important for the rate controller.
|
||||
- Disable [MC_AIRMODE](../advanced_config/parameter_reference.md#MC_AIRMODE) before tuning a vehicle (there is an options for this in the PID tuning screen).
|
||||
|
||||
:::warning
|
||||
Poorly tuned vehicles are likely to be unstable, and easy to crash.
|
||||
Make sure to have assigned a [Kill switch](../config/safety.md#emergency-switches).
|
||||
:::
|
||||
|
||||
## Tuning Procedure
|
||||
|
||||
The tuning procedure is:
|
||||
|
||||
1. Arm the vehicle, takeoff, and hover (typically in [Position mode](../flight_modes_mc/position.md)).
|
||||
1. Open _QGroundControl_ **Vehicle Setup > PID Tuning**
|
||||
|
||||
1. Select the **Rate Controller** tab.
|
||||
1. Confirm that the airmode selector is set to **Disabled**
|
||||
1. Set the _Thrust curve_ value to: 0.3 (PWM, power-based controllers) or 1 (RPM-based ESCs)
|
||||
|
||||
::: info
|
||||
For PWM, power-based and (some) UAVCAN speed controllers, the control signal to thrust relationship may not be linear.
|
||||
As a result, the optimal tuning at hover thrust may not be ideal when the vehicle is operating at higher thrust.
|
||||
|
||||
The thrust curve value can be used to compensate for this non-linearity:
|
||||
|
||||
- For PWM controllers, 0.3 is a good default (which may benefit from [further tuning](../config_mc/pid_tuning_guide_multicopter.md#thrust-curve)).
|
||||
- For RPM-based controllers, use 1 (no further tuning is required as these have a quadratic thrust curve).
|
||||
|
||||
For more information see the [detailed PID tuning guide](../config_mc/pid_tuning_guide_multicopter.md#thrust-curve).
|
||||
:::
|
||||
|
||||
1. Set the _Select Tuning_ radio button to: **Roll**.
|
||||
1. (Optionally) Select the **Automatic Flight Mode Switching** checkbox.
|
||||
This will _automatically_ switch from [Position mode](../flight_modes_mc/position.md) to [Stabilised mode](../flight_modes_mc/manual_stabilized.md) when you press the **Start** button
|
||||
1. For rate controller tuning switch to _Acro mode_, _Stabilized mode_ or _Altitude mode_ (unless automatic switching is enabled).
|
||||
1. Select the **Start** button in order to start tracking the setpoint and response curves.
|
||||
1. Rapidly move the _roll stick_ full range and observe the step response on the plots.
|
||||
:::tip
|
||||
Stop tracking to enable easier inspection of the plots.
|
||||
This happens automatically when you zoom/pan.
|
||||
Use the **Start** button to restart the plots, and **Clear** to reset them.
|
||||
:::
|
||||
1. Modify the three PID values using the sliders (for roll rate-tuning these affect `MC_ROLLRATE_K`, `MC_ROLLRATE_I`, `MC_ROLLRATE_D`) and observe the step response again.
|
||||
The values are saved to the vehicle as soon as the sliders are moved.
|
||||
::: info
|
||||
The goal is for the _Response_ curve to match the _Setpoint_ curve as closely as possible (i.e. a fast response without overshoots).
|
||||
:::
|
||||
The PID values can be adjusted as follows:
|
||||
- P (proportional) or K gain:
|
||||
- increase this for more responsiveness
|
||||
- reduce if the response is overshooting and/or oscillating (up to a certain point increasing the D gain also helps).
|
||||
- D (derivative) gain:
|
||||
- this can be increased to dampen overshoots and oscillations
|
||||
- increase this only as much as needed, as it amplifies noise (and can lead to hot motors)
|
||||
- I (integral) gain:
|
||||
- used to reduce steady-state error
|
||||
- if too low, the response might never reach the setpoint (e.g. in wind)
|
||||
- if too high, slow oscillations can occur
|
||||
1. Repeat the tuning process above for the pitch and yaw:
|
||||
- Use _Select Tuning_ radio button to select the axis to tune
|
||||
- Move the appropriate sticks (i.e. pitch stick for pitch, yaw stick for yaw).
|
||||
- For pitch tuning, start with the same values as for roll.
|
||||
:::tip
|
||||
Use the **Save to Clipboard** and **Reset from Clipboard** buttons to copy the roll settings for initial pitch settings.
|
||||
:::
|
||||
1. Repeat the tuning process for the attitude controller on all the axes.
|
||||
1. Repeat the tuning process for the velocity and positions controllers (on all the axes).
|
||||
|
||||
- Use Position mode when tuning these controllers
|
||||
- Select the **Simple position control** option in the _Position control mode ..._ selector (this allows direct control for the generation of step inputs)
|
||||
|
||||
|
||||
|
||||
All done!
|
||||
Remember to re-enable airmode before leaving the setup.
|
||||
@@ -0,0 +1,153 @@
|
||||
# Multicopter Racer Setup
|
||||
|
||||
This page describes how to setup and configure a multicopter racer for optimal performance (in particular for [Acro mode](../flight_modes_mc/acro.md)).
|
||||
|
||||
Keep in mind that racers are fast vehicles, specifically designed to be overpowered!
|
||||
You should already have some experience, or let someone with experience help you.
|
||||
|
||||
::: tip
|
||||
Many things described here can also be applied to improve the flight performance of other types of multicopters.
|
||||
:::
|
||||
|
||||
::: info
|
||||
A racer usually omits some sensors (e.g. GPS).
|
||||
As a result, fewer failsafe options are available.
|
||||
:::
|
||||
|
||||
## Build Options
|
||||
|
||||
A racer usually omits some sensors.
|
||||
|
||||
The minimal configuration is to use only a gyro and accelerometer sensor.
|
||||
|
||||
::: info
|
||||
If the board has an internal magnetometer, it should not be used (small racers are particularly prone to strong electromagnetic interference).
|
||||
:::
|
||||
|
||||
Racers typically do not have a GPS as it adds some weight and is prone to damage during crashes (a GPS + external magnetometer must be placed on a GPS mast away from high currents to avoid magnetic interference, which unfortunately means that it is easy to break).
|
||||
|
||||
There are however some benefits in adding GPS, particularly for beginners:
|
||||
|
||||
- You can go into position hold and the vehicle will just stay in one place.
|
||||
This is handy if you lose the orientation or need a brake.
|
||||
It can also be used to land safely.
|
||||
- [Return mode](../flight_modes_mc/return.md) can be used, either on a switch or as RC loss/low battery failsafe.
|
||||
- You will have the last position when it crashes.
|
||||
- The log contains the flight track, which means you can review the flight (in 3D).
|
||||
This can help to improve your acrobatic flight skills.
|
||||
|
||||
::: info
|
||||
During aggressive acrobatic maneuvers the GPS can lose its position fix for a short time.
|
||||
If you switch into [position mode](../flight_modes_mc/position.md) during that time, [altitude mode](../flight_modes_mc/altitude.md) will be used instead until the position becomes valid again.
|
||||
:::
|
||||
|
||||
## Hardware Setup
|
||||
|
||||
The following paragraphs describe a few important points when building the vehicle.
|
||||
If you need complete build instructions, you can follow the [QAV-R 5" KISS ESC Racer](../frames_multicopter/qav_r_5_kiss_esc_racer.md) build log.
|
||||
|
||||
### Vibration Setup
|
||||
|
||||
There are various mounting approaches to reduce vibrations.
|
||||
For example, the flight controller can be mounted with vibration dampening foam, or using [O-rings](../frames_multicopter/qav_r_5_kiss_esc_racer.md#mounting).
|
||||
|
||||
While there is no single best method, you will typically have fewer problems with vibrations if you use high-quality components (frame, motors, props) as for example used in the [QAV-R 5" KISS ESC Racer](../frames_multicopter/qav_r_5_kiss_esc_racer.md).
|
||||
|
||||
Make sure to use **balanced props**.
|
||||
|
||||
### Center of Gravity
|
||||
|
||||
Make sure that the center of gravity is as close as possible to the center of thrust.
|
||||
Left-right balance is usually not a problem, but front-back balance may be.
|
||||
You can move the battery until it is correct and mark it on the frame so you will always place it correctly.
|
||||
|
||||
::: info
|
||||
The integral term can account for an imbalanced setup, and a custom mixer can do that even better.
|
||||
However it is best to fix any imbalance as part of the vehicle setup.
|
||||
:::
|
||||
|
||||
## Software Setup
|
||||
|
||||
After having built the racer, you will need to configure the software.
|
||||
|
||||
Go through the [Basic Configuration Guide](../config/index.md).
|
||||
In particular, set the [Airframe](../config/airframe.md) that most closely matches your frame (typically you will choose the [Generic 250 Racer](../airframes/airframe_reference.md#copter_quadrotor_x_generic_250_racer) airframe, which sets some racer-specific parameters by default).
|
||||
|
||||
These parameters are important:
|
||||
|
||||
- Enable One-Shot or DShot by selecting the protocol for a group of outputs during [Actuator Configuration](../config/actuators.md).
|
||||
- Set the maximum roll-, pitch- and yaw rates for Stabilized mode as desired: [MC_ROLLRATE_MAX](../advanced_config/parameter_reference.md#MC_ROLLRATE_MAX), [MC_PITCHRATE_MAX](../advanced_config/parameter_reference.md#MC_PITCHRATE_MAX) and [MC_YAWRATE_MAX](../advanced_config/parameter_reference.md#MC_YAWRATE_MAX).
|
||||
The maximum tilt angle is configured with [MPC_MAN_TILT_MAX](../advanced_config/parameter_reference.md#MPC_MAN_TILT_MAX).
|
||||
- The minimum thrust [MPC_MANTHR_MIN](../advanced_config/parameter_reference.md#MPC_MANTHR_MIN) should be set to 0.
|
||||
|
||||
### Estimator
|
||||
|
||||
If you use a GPS you can skip this section and use the default estimator.
|
||||
Otherwise you should switch to the Q attitude estimator, which works without a magnetometer or barometer.
|
||||
|
||||
To enable it set [ATT_EN = 1](../advanced_config/parameter_reference.md#ATT_EN), [EKF2_EN =0 ](../advanced_config/parameter_reference.md#EKF2_EN) and [LPE_EN = 0](../advanced_config/parameter_reference.md#LPE_EN) (for more information see [Switching State Estimators](../advanced/switching_state_estimators.md#how-to-enable-different-estimators)).
|
||||
|
||||
Then change the following parameters:
|
||||
|
||||
- Set [SYS_HAS_MAG](../advanced_config/parameter_reference.md#SYS_HAS_MAG) to `0` if the system does not have a magnetometer.
|
||||
- Set [SYS_HAS_BARO](../advanced_config/parameter_reference.md#SYS_HAS_BARO) to `0` if the system does not have a barometer.
|
||||
- Configure the Q estimator: set [ATT_ACC_COMP](../advanced_config/parameter_reference.md#ATT_ACC_COMP) to `0`, [ATT_W_ACC](../advanced_config/parameter_reference.md#ATT_W_ACC) to 0.4 and [ATT_W_GYRO_BIAS](../advanced_config/parameter_reference.md#ATT_W_GYRO_BIAS) to 0.
|
||||
You can tune these later if you wish.
|
||||
|
||||
### Failsafe
|
||||
|
||||
Configure [RC loss and low battery failsafe](../config/safety.md).
|
||||
If you do not use a GPS, set the failsafe to **Lockdown**, which turns off the motors.
|
||||
Test RC loss on the bench without props attached by turning off the remote when the vehicle is armed.
|
||||
|
||||
Make sure to assign a [kill switch](../config/safety.md#kill-switch) or an [arming switch](../config/safety.md#arm-disarm-switch).
|
||||
Test it and train to use it!
|
||||
|
||||
### PID Tuning
|
||||
|
||||
::: info
|
||||
Make sure to calibrate the ESCs before doing any tuning.
|
||||
:::
|
||||
|
||||
At this point you should be ready for a first test flight.
|
||||
|
||||
Assuming the vehicle is able to fly using the default settings, we then do a first pass of [Basic MC PID tuning](../config_mc/pid_tuning_guide_multicopter_basic.md).
|
||||
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).
|
||||
This is important for the [filter tuning](#filter-tuning) (there will be a second PID tuning round later).
|
||||
|
||||
### Control Latency
|
||||
|
||||
The _control latency_ is the delay from a physical disturbance of the vehicle until the motors react to the change.
|
||||
|
||||
:::tip
|
||||
It is _crucial_ to reduce the control latency as much as possible!
|
||||
A lower latency allows you to increase the rate **P** gains, which means better flight performance.
|
||||
Even one millisecond added to the latency makes a difference.
|
||||
:::
|
||||
|
||||
These are the factors that affect the latency:
|
||||
|
||||
- A soft airframe or soft vibration mounting increases latency (they act as a filter).
|
||||
- [Low-pass filters](../config_mc/filter_tuning.md) in software and on the sensor chip trade off increased latency for improved noise filtering.
|
||||
- PX4 software internals: the sensor signals need to be read in the driver and then pass through the controller to the output driver.
|
||||
- The IO chip (MAIN pins) adds about 5.4 ms latency compared to using the AUX pins (this does not apply to a _Pixracer_ or _Omnibus F4_, but does apply to a Pixhawk).
|
||||
To avoid the IO delay attach the motors to the AUX pins instead.
|
||||
- PWM output signal: enable [Dshot](../peripherals/dshot.md) by preference to reduce latency (or One-Shot if DShot is not supported).
|
||||
The protocol is selected for a group of outputs during [Actuator Configuration](../config/actuators.md).
|
||||
|
||||
### Filter Tuning
|
||||
|
||||
Filters trade off control latency and noise filtering, both of which impact performance.
|
||||
For information see: [Filter/Control Latency Tuning](../config_mc/filter_tuning.md)
|
||||
|
||||
### PID Tuning (Second Round)
|
||||
|
||||
Now do a second round of PID tuning, this time as tight as possible, and also tuning the thrust curve.
|
||||
|
||||
:::tip
|
||||
You can use the approach described in [Basic MC PID tuning](../config_mc/pid_tuning_guide_multicopter_basic.md) to tune the frame, but you will need to use the [Advanced Multicopter PID Tuning Guide (Advanced/Detailed)](../config_mc/pid_tuning_guide_multicopter.md#thrust-curve) to understand how to tune the thrust curve.
|
||||
|
||||
### Airmode
|
||||
|
||||
After you have verified that the vehicle flies well at low and high throttle, you can enable [airmode](../config_mc/pid_tuning_guide_multicopter.md#airmode) with the [MC_AIRMODE](../advanced_config/parameter_reference.md#MC_AIRMODE) parameter.
|
||||
This feature makes sure that the vehicle is still controllable and tracks the rate at low throttle.
|
||||
Reference in New Issue
Block a user