docs: Codespell check on English sources + swd fixes (#26657)

This commit is contained in:
Hamish Willee
2026-03-05 12:50:59 +11:00
committed by GitHub
parent 5528ebec64
commit b37733459d
96 changed files with 180 additions and 174 deletions
+1 -1
View File
@@ -67,7 +67,7 @@ The consensus [appears to be](https://discuss.px4.io/t/vio-vs-optical-flow/34680
Optical flow:
- Downward facing optical flow gives you a planar velocity thats corrected for angular velocity with the gyro.
- Downward facing optical flow gives you a planar velocity that's corrected for angular velocity with the gyro.
- Requires an accurate distance to the ground and assumes a planar surface.
Given those conditions it can be just as accurate/reliable as VIO (such as indoor flight)
- Is more robust than VIO as it has fewer states.
+1 -1
View File
@@ -20,7 +20,7 @@ By default this is set to `Disabled (-1)` and the driver does not run.
After selecting the input mode, reboot the vehicle to start the mount driver.
You should set `MNT_MODE_IN` to one of: `RC (1)`, `MAVlink gimbal protocol v2 (4)` or `Auto (0)` (the other options are deprecated).
If you select `Auto (0)`, the gimbal will automatically select either RC or or MAVLink input based on the latest input.
If you select `Auto (0)`, the gimbal will automatically select either RC or MAVLink input based on the latest input.
Note that the auto-switch from MAVLink to RC requires a large stick motion!
The output is set using the [MNT_MODE_OUT](../advanced_config/parameter_reference.md#MNT_MODE_OUT) parameter.
@@ -1,6 +1,6 @@
# Bootloader Update Pixhawk V6X-RT via USB
This topic explains explains to flash [Pixhawk FMUv6X-RT](../flight_controller/pixhawk6x-rt.md) bootloader via USB _without needing a debug probe_.
This topic explains how to flash [Pixhawk FMUv6X-RT](../flight_controller/pixhawk6x-rt.md) bootloader via USB _without needing a debug probe_.
## Overview
@@ -33,7 +33,7 @@ arm-none-eabi-objcopy -O ihex build/px4_fmu-v6xrt_bootloader/px4_fmu-v6xrt_bootl
## Flashing the bootloader through USB
The Pixhawk V6X-RT comes with a build-in bootloader located on the ROM.
The Pixhawk V6X-RT comes with a built-in bootloader located on the ROM.
To flash a new bootloader through USB you've got to download the [NXP MCUXpresso Secure Provisioning tool](https://www.nxp.com/design/design-center/software/development-software/mcuxpresso-software-and-tools-/mcuxpresso-secure-provisioning-tool:MCUXPRESSO-SECURE-PROVISIONING).
The tool is available for Windows, Linux and macOS.
@@ -79,7 +79,7 @@ The tool is available for Windows, Linux and macOS.
![Flash bootloader through Secure provisioning - Step 7](../../assets/advanced_config/bootloader_6xrt/bootloader_update_v6xrt_step7.png)
1. When the Target Memory configuration is succesful you can press the the **Erase All** button
1. When the Target Memory configuration is successful you can press the **Erase All** button
![Flash bootloader through Secure provisioning - Step 8](../../assets/advanced_config/bootloader_6xrt/bootloader_update_v6xrt_step8.png)
+2 -2
View File
@@ -337,7 +337,7 @@ Note:
Note that the PWM outputs are often labeled `AUX` or `MAIN`.
Use the `AUX` bus if both are present, and `MAIN` otherwise.
- [DShot ESC](../peripherals/dshot.md) (recommended) can only be used on the FMU PWM outputs.
- Motor outputs should be grouped together as much as possible rather than spread randomly across both the FMU and IO busses.
- Motor outputs should be grouped together as much as possible rather than spread randomly across both the FMU and IO buses.
This is because if you assign some function to an output, such as DShot ESC, you can't then assign adjacent unused pins for anything other than a DShot ESC.
### Servos
@@ -363,7 +363,7 @@ If you don't use servos that all accept the same voltage, you'll need to separat
Other peripherals, such as high-power radios, cameras, and so on have their own power requirements.
These will usually be supplied off a separate BEC.
The wiring and configuration of optional/less common components is covered within the [Hardware Hardware Selection & Setup](../hardware/drone_parts.md) topics for individual peripherals.
The wiring and configuration of optional/less common components is covered within the [Hardware Selection & Setup](../hardware/drone_parts.md) topics for individual peripherals.
## Build Tutorials
+1 -1
View File
@@ -52,7 +52,7 @@ The instructions below show how to connect the different types of receivers:
Pixracer has inbuilt WiFi, but also supports telemetry via external Wi-Fi or radio telemetry modules connected to the `TELEM1` or `TELEM2` ports.
This is shown in the wiring diagram below.
![Pixracer external telemtry options](../../assets/flight_controller/pixracer/pixracer_top_telemetry.jpg)
![Pixracer external telemetry options](../../assets/flight_controller/pixracer/pixracer_top_telemetry.jpg)
::: info
The `TELEM2` port must be configured as a second MAVLink instance using the [MAV_2_CONFIG](../advanced_config/parameter_reference.md#MAV_2_CONFIG) parameter.
+1 -1
View File
@@ -36,7 +36,7 @@ The `camera_trigger`, `camera_capture` and `camera_feedback` modules are not use
This work is handled by three PX4 components: [`camera_trigger` driver](https://github.com/PX4/PX4-Autopilot/tree/main/src/drivers/camera_trigger), [`camera_capture` driver](https://github.com/PX4/PX4-Autopilot/tree/main/src/drivers/camera_capture), [`camera-feedback` module](../modules/modules_system.md#camera-feedback).
`camera_trigger` subscribes to the [VehicleCommand](../msg_docs/VehicleCommand.md) topic and monitors for updates to its [supported commands](../camera/fc_connected_camera.md#mavlink-command-interface).
Thes updates occur when either a command is received via MAVLink or when a [camera item is reached in a mission](#camera-commands-in-missions).
These updates occur when either a command is received via MAVLink or when a [camera item is reached in a mission](#camera-commands-in-missions).
The commands enable and disable triggering, and configure triggering at time and distance intervals.
The driver tracks these intervals, and when needed triggers the outputs.
+1 -1
View File
@@ -78,7 +78,7 @@ The shutter integration setting (`param2`) is only obeyed with a GPIO backend.
## Trigger Configuration
Cameras can be connected to the FC for triggering using different intefaces, such as PWM, and GPIO, by specifying the appropriate [trigger interface backend](#trigger-interface-backends).
Cameras can be connected to the FC for triggering using different interfaces, such as PWM, and GPIO, by specifying the appropriate [trigger interface backend](#trigger-interface-backends).
You can also indicate the camera [trigger mode](#trigger-modes).
This configuration can most easily be done from the _QGroundControl_ [Vehicle Setup > Camera](https://docs.qgroundcontrol.com/master/en/qgc-user-guide/setup_view/camera.html#px4-camera-setup) section.
+2 -2
View File
@@ -1,4 +1,4 @@
# Simple MAVLink Cameras (Camera Protcol v1)
# Simple MAVLink Cameras (Camera Protocol v1)
This topic explains how to use PX4 with a MAVLink [camera](../camera/index.md) that implements the [Camera Protocol v1 (Simple Trigger Protocol)](https://mavlink.io/en/services/camera_v1.html) with PX4 and a Ground Station.
@@ -18,7 +18,7 @@ This approach is retained for use with older MAVLink cameras.
PX4 supports this command set for triggering cameras with native support for the protocol (as described in this topic), and also for [cameras attached to flight controller outputs](../camera/fc_connected_camera.md).
Ground stations and MAVLink SDKs generally address camera commands to the autopilot, which then forwards them to a connected MAVLink channel of type `onboard`.
PX4 also re-emits any camera mission items it encouters in a mission as camera commands: commands that aren't accepted are logged.
PX4 also re-emits any camera mission items it encounters in a mission as camera commands: commands that aren't accepted are logged.
In all cases the commands are sent with the system id of the autopilot and the component ID of 0 (i.e. addressed to all components, including cameras).
PX4 will also emit a [CAMERA_TRIGGER](https://mavlink.io/en/messages/common.html#CAMERA_TRIGGER) whenever an image capture is triggered (the camera itself may also emit this message on triggering).
@@ -783,7 +783,7 @@ sudo apt install build-essential cmake git genromfs kconfig-frontends libncurses
## Building/Flashing the Pixhawk
The recommended way to update PX4 is on the Pixhawk part of the board is to use your development computer.
You can either install install prebuilt binaries with QGroundControl, or first build and then upload custom firmware.
You can either install prebuilt binaries with QGroundControl, or first build and then upload custom firmware.
Alternatively, you can build and deploy PX4 firmware to the Pixhawk part from the Jetson.
+1 -1
View File
@@ -33,7 +33,7 @@ They are listed here as they can be updated with "vanilla" PX4 firmware for test
## Companion Computer Options
PX4 can be used with computers that can be configured to communicate via MAVLink or microROS/uXRCE-DDS over over a serial port (or Ethernet port, if present).
PX4 can be used with computers that can be configured to communicate via MAVLink or microROS/uXRCE-DDS over a serial port (or Ethernet port, if present).
A small subset of possible alternatives are listed below.
Larger high power examples:
+1 -1
View File
@@ -1,6 +1,6 @@
# Raspberry Pi Companion with Pixhawk
This topic describes how to setup a Raspberry Pi ("RPi") companion companion running [ROS 2](../ros2/user_guide.md) on Linux Ubuntu OS, connecting to a [Pixhawk](../flight_controller/autopilot_pixhawk_standard.md) flight controller using a serial connection between the Pixhawk `TELEM2` port and the RPi's TX/RX pins.
This topic describes how to setup a Raspberry Pi ("RPi") companion running [ROS 2](../ros2/user_guide.md) on Linux Ubuntu OS, connecting to a [Pixhawk](../flight_controller/autopilot_pixhawk_standard.md) flight controller using a serial connection between the Pixhawk `TELEM2` port and the RPi's TX/RX pins.
These instructions should be readily extensible to other RPi and flight controller configurations.
+1 -1
View File
@@ -33,7 +33,7 @@ For this build this includes an [Auterion Skynode](../companion_computer/auterio
If using a standard Pixhawk you could connect the RoboClaw to the Autopilot without an Adapter Board.
:::
The RoboClaw should be connected to a suitable suitable serial (UART) port on the flight controller, such as `GPS2` or `TELEM1`.
The RoboClaw should be connected to a suitable serial (UART) port on the flight controller, such as `GPS2` or `TELEM1`.
Other RoboClaw wiring is detailed in the [RoboClaw User Manual](https://downloads.basicmicro.com/docs/roboclaw_user_manual.pdf) 'Packet Serial Wiring' section and shown below (this setup has been validated for compatibility).
![Serial Wiring Encoders](../../assets/airframes/rover/aion_r1/wiring_r1.jpg)
@@ -143,7 +143,7 @@ If you wish to move freely into directions without sensor coverage, this can be
### Acceleration Constraining
For this we split out the acceleration setpoint into two components, one parallel to the closest distance to the obstacle and one normal to it. Then we scale each of these components according the the figure below.
For this we split out the acceleration setpoint into two components, one parallel to the closest distance to the obstacle and one normal to it. Then we scale each of these components according to the figure below.
![Scalefactor](../../assets/computer_vision/collision_prevention/scalefactor.png)
+1 -1
View File
@@ -92,7 +92,7 @@ Explanations and requirements:
```
- Above we specify a separate external and internal log level, which are the levels displayed to GCS users and in the log file, respectively: `{events::Log::Error, events::LogInternal::Info}`.
For the majority of cases you can pass a single log level, and this will be used for both exernal and internal cases.
For the majority of cases you can pass a single log level, and this will be used for both external and internal cases.
There are cases it makes sense to have two different log levels.
For example an RTL failsafe action: the user should see it as Warning/Error, whereas in the log, it is an expected system response, so it can be set to `Info`.
+1 -1
View File
@@ -114,7 +114,7 @@ The instructions below might be used to create a task named _MyTask_:
::: tip
The task added above will be built on all boards, including those with constrained flash such as Pixhawk FMUv2.
If your task is not indended for use on boards with constrained flash it should instead be added to the conditional block shown below (as shown).
If your task is not intended for use on boards with constrained flash it should instead be added to the conditional block shown below (as shown).
```cmake
...
+2 -2
View File
@@ -124,7 +124,7 @@ Additional notes:
<div v-if="$frontmatter.frame === 'Multicopter'">
- The instructions above tune the vehicle in [Altitude mode](../flight_modes_mc/altitude.md).
You can instead takeoff in [Takeoff mode](../flight_modes_mc/takeoff.md) and tune in [Position mode](../flight_modes_mc/position.md) if the vehicle is is _known_ to be stable in these modes.
You can instead takeoff in [Takeoff mode](../flight_modes_mc/takeoff.md) and tune in [Position mode](../flight_modes_mc/position.md) if the vehicle is _known_ to be stable in these modes.
</div>
<div v-else-if="$frontmatter.frame === 'Plane'">
@@ -241,7 +241,7 @@ To map a switch:
2. Set [RC_MAP_AUX1](../advanced_config/parameter_reference.md#RC_MAP_AUX1) to match the RC channel for your switch (you can use any of `RC_MAP_AUX1` to `RC_MAP_AUX6`).
3. Set [FW_AT_MAN_AUX](../advanced_config/parameter_reference.md#FW_AT_MAN_AUX) to the selected channel (i.e. `1: Aux 1` if you mapped `RC_MAP_AUX1`).
The auto tuner will be disabled when the switch is below `0.5` (on the manual control setpoint range of of `[-1, 1]`) and enabled when the switch channel is above `0.5`.
The auto tuner will be disabled when the switch is below `0.5` (on the manual control setpoint range of `[-1, 1]`) and enabled when the switch channel is above `0.5`.
If using an RC AUX switch to enable autotuning, make sure to [select the tuning axes](#select-tuning-axis) before flight.
+3 -3
View File
@@ -274,7 +274,7 @@ The parameters that control when the quad-chute will trigger are listed in the t
## High Wind Failsafe
The high wind failsafe can trigger a warning and/or other mode change when the wind speed exceeds the warning and maximum wind-speed threshhold values.
The high wind failsafe can trigger a warning and/or other mode change when the wind speed exceeds the warning and maximum wind-speed threshold values.
The relevant parameters are listed in the table below.
| Parameter | Description |
@@ -328,8 +328,8 @@ The failure detector can be configured to detect a motor failure while armed (an
| -------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| <a id="FD_ACT_EN"></a>[FD_ACT_EN](../advanced_config/parameter_reference.md#FD_ACT_EN) | Enable/disable the motor failure trigger completely. |
| <a id="FD_ACT_MOT_THR"></a>[FD_ACT_MOT_THR](../advanced_config/parameter_reference.md#FD_ACT_MOT_THR) | Minimum normalized [0,1] motor command below which motor under current is ignored. |
| <a id="FD_ACT_MOT_C2T"></a>[FD_ACT_MOT_C2T](../advanced_config/parameter_reference.md#FD_ACT_MOT_C2T) | Scale between normalized [0,1] motor command and expected minimally reported currrent when the rotor is healthy. |
| <a id="FD_ACT_MOT_TOUT"></a>[FD_ACT_MOT_TOUT](../advanced_config/parameter_reference.md#FD_ACT_MOT_TOUT) | Time in miliseconds for which the under current detection condition needs to stay true. |
| <a id="FD_ACT_MOT_C2T"></a>[FD_ACT_MOT_C2T](../advanced_config/parameter_reference.md#FD_ACT_MOT_C2T) | Scale between normalized [0,1] motor command and expected minimally reported current when the rotor is healthy. |
| <a id="FD_ACT_MOT_TOUT"></a>[FD_ACT_MOT_TOUT](../advanced_config/parameter_reference.md#FD_ACT_MOT_TOUT) | Time in milliseconds for which the under current detection condition needs to stay true. |
| <a id="CA_FAILURE_MODE"></a>[CA_FAILURE_MODE](../advanced_config/parameter_reference.md#CA_FAILURE_MODE) | Configure to not only warn about a motor failure but remove the first motor that detects a failure from the allocation effectiveness which turns off the motor and tries to operate the vehicle without it until disarming the next time. |
### External Automatic Trigger System (ATS)
@@ -13,7 +13,7 @@ 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).
PX4 uses **P**roportional, **I**integral, **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).
+2 -2
View File
@@ -16,7 +16,7 @@ Configure the following [parameters](../advanced_config/parameters.md) in QGroun
Put the rover into stabilized mode and move the left stick of your controller up to drive forwards.
Disarm the rover and from the flight log plot the `measured_yaw` and the `adjusted_yaw_setpoint` from the [RoverAttitudeStatus](../msg_docs/RoverAttitudeStatus.md) message over each other.
Increase/Decrease the parameter until you are satisfied with the setpoint tracking.
If you observe a steady state error in the yaw setpoint increase the the integrator of the rate controller: [RO_YAW_RATE_I](../advanced_config/parameter_reference.md#RO_YAW_RATE_I) .
If you observe a steady state error in the yaw setpoint increase the integrator of the rate controller: [RO_YAW_RATE_I](../advanced_config/parameter_reference.md#RO_YAW_RATE_I) .
:::
The rover is now ready to drive in [Stabilized mode](../flight_modes_rover/manual.md#stabilized-mode) and the configuration can be continued with [velocity tuning](velocity_tuning.md).
@@ -29,7 +29,7 @@ The attitude controller uses the following structure:
![Rover Attitude Controller](../../assets/config/rover/rover_attitude_controller.png)
The rate and attitude controllers are cascaded, therefor we only require one integrator in the structure to eliminate steady state errors.
The rate and attitude controllers are cascaded, therefore we only require one integrator in the structure to eliminate steady state errors.
We placed the integrator in the rate controller since it can run without the attitude controller but not the other way around.
## Parameter Overview
+1 -1
View File
@@ -129,7 +129,7 @@ In [Manual mode](../flight_modes_rover/manual.md#manual-mode) we can additionall
- Differential Rover: $r=$ [RD_YAW_STK_GAIN](#RD_YAW_STK_GAIN), which enables adjusting the slope of the input mapping. This leads to a normalized steering input $\hat{\delta} = \delta \cdot r \in$ [-[RD_YAW_STK_GAIN](#RD_YAW_STK_GAIN), [RD_YAW_STK_GAIN](#RD_YAW_STK_GAIN)].
- Mecanum Rover: $r=$ [RM_YAW_STK_GAIN](#RM_YAW_STK_GAIN), which enables adjusting the slope of the input mapping. This leads to a normalized steering input $\hat{\delta} = \delta \cdot r \in$ [-[RM_YAW_STK_GAIN](#RM_YAW_STK_GAIN), [RM_YAW_STK_GAIN](#RM_YAW_STK_GAIN)].
This scaling is useful to limit the normalized steering setpoint, if it is too aggresive for your rover in manual mode.
This scaling is useful to limit the normalized steering setpoint, if it is too aggressive for your rover in manual mode.
You can experiment with the relationships graphically using the [PX4 SuperExpo Rover calculator](https://www.desmos.com/calculator/gwm8lrlanx).
+1 -1
View File
@@ -39,7 +39,7 @@ make px4_fmu-v6x_rover
Note that configuration targets are constructed with the format "VENDOR_MODEL_VARIANT".
The built firmware can be installed as custom firmware, as shown above in in [Flashing the Rover Build](#flashing-the-rover-build).
The built firmware can be installed as custom firmware, as shown above in [Flashing the Rover Build](#flashing-the-rover-build).
::: info
You can also enable the modules in default builds by adding these lines to your [board configuration](../hardware/porting_guide_config.md) (e.g. for fmu-v6x you might add them to [`main/boards/px4/fmu-v6x/default.px4board`](https://github.com/PX4/PX4-Autopilot/blob/main/boards/px4/fmu-v6x/default.px4board)):
+1 -1
View File
@@ -11,7 +11,7 @@ Configure the following [parameters](../advanced_config/parameters.md) in QGroun
1. [RO_YAW_RATE_LIM](#RO_YAW_RATE_LIM): Maximum yaw rate you want to allow for your rover.
:::tip
Limiting the yaw rate is necessary if the rover is prone rolling over, loosing traction at high speeds or if passenger comfort is important.
Limiting the yaw rate is necessary if the rover is prone rolling over, losing traction at high speeds or if passenger comfort is important.
Small rovers especially can be prone to rolling over when steering aggressively at high speeds.
If this is the case:
+2 -2
View File
@@ -54,7 +54,7 @@ To tune the velocity controller configure the following [parameters](../advanced
## Manual Position Mode Parameters
These steps are only necessary if you are tuning/want to unlock the manual [Position mode](../flight_modes_rover/manual.md#position-mode). Othwerwise, you can continue with [position tuning](position_tuning.md) where these same parameters will also be configured.
These steps are only necessary if you are tuning/want to unlock the manual [Position mode](../flight_modes_rover/manual.md#position-mode). Otherwise, you can continue with [position tuning](position_tuning.md) where these same parameters will also be configured.
1. [PP_LOOKAHD_GAIN](#PP_LOOKAHD_GAIN): When driving in a straight line (right stick centered) position mode leverages the same path following algorithm used in [auto modes](../flight_modes_rover/auto.md) called [pure pursuit](position_tuning.md#pure-pursuit-guidance-logic-info-only) to achieve the best possible straight line driving behaviour.
This parameter determines how aggressive the controller will steer towards the path.
@@ -99,7 +99,7 @@ The speed controller uses the following structure:
The feed forward mapping is done by interpolating the speed setpoint from [-[RO_MAX_THR_SPEED](../advanced_config/parameter_reference.md#RO_MAX_THR_SPEED), [RO_MAX_THR_SPEED](../advanced_config/parameter_reference.md#RO_MAX_THR_SPEED)] to [-1, 1].
For ackermann and differential rovers the bearing is aligned with the vehicle yaw. Therefor the bearing is simply sent as a yaw setpoint to the [yaw controller](attitude_tuning.md#attitude-controller-structure-info-only) and the speed setpoint is always defined in body x direction.
For ackermann and differential rovers the bearing is aligned with the vehicle yaw. Therefore the bearing is simply sent as a yaw setpoint to the [yaw controller](attitude_tuning.md#attitude-controller-structure-info-only) and the speed setpoint is always defined in body x direction.
For mecanum vehicles, the bearing and yaw are decoupled. The direction is controlled by splitting the velocity vector into one speed component in body x direction and one in body y direction.
Both these setpoint are then sent to their own closed loop speed controllers.
+1 -1
View File
@@ -6,7 +6,7 @@ Ice shedding is a feature that periodically spins unused motors in fixed-wing
flight, to break off any ice that is starting to build up in the motors while it
is still feasible to do so.
It is configured by the paramter `CA_ICE_PERIOD`. When it is 0, the feature is
It is configured by the parameter `CA_ICE_PERIOD`. When it is 0, the feature is
disabled, when it is above 0, it sets the duration of the ice shedding cycle in
seconds. In each cycle, the rotors are spun for two seconds at a motor output of
0.01.
+1 -1
View File
@@ -7,7 +7,7 @@ const { site } = useData();
<div v-if="site.title !== 'PX4 Guide (main)'">
<div class="custom-block danger">
<p class="custom-block-title">This page may be out out of date. <a href="https://docs.px4.io/main/en/contribute/dev_call">See the latest version</a>.</p>
<p class="custom-block-title">This page may be out of date. <a href="https://docs.px4.io/main/en/contribute/dev_call">See the latest version</a>.</p>
</div>
</div>
+1 -1
View File
@@ -7,7 +7,7 @@ const { site } = useData();
<div v-if="site.title !== 'PX4 Guide (main)'">
<div class="custom-block danger">
<p class="custom-block-title">This page may be out out of date. <a href="https://docs.px4.io/main/en/contribute/">See the latest version</a>.</p>
<p class="custom-block-title">This page may be out of date. <a href="https://docs.px4.io/main/en/contribute/">See the latest version</a>.</p>
</div>
</div>
+1 -1
View File
@@ -7,7 +7,7 @@ const { site } = useData();
<div v-if="site.title !== 'PX4 Guide (main)'">
<div class="custom-block danger">
<p class="custom-block-title">This page may be out out of date. <a href="https://docs.px4.io/main/en/contribute/support">See the latest version</a>.</p>
<p class="custom-block-title">This page may be out of date. <a href="https://docs.px4.io/main/en/contribute/support">See the latest version</a>.</p>
</div>
</div>
+1 -1
View File
@@ -22,7 +22,7 @@ This tutorial shows how to send the MAVLink message `NAMED_VALUE_FLOAT` using th
The code for this tutorial is available here:
- [Debug Tutorial Code](https://github.com/PX4/PX4-Autopilot/blob/main/src/examples/px4_mavlink_debug/px4_mavlink_debug.cpp)
- [Enable the tutorial app](https://github.com/PX4/PX4-Autopilot/blob/main/boards/px4/fmu-v5/default.px4board) by ensuring the MAVLink debug app (**CONFIG_EXAMPLES_PX4_MAVLINK_DEBUG**) is in the config of your board and set set to 'y'.
- [Enable the tutorial app](https://github.com/PX4/PX4-Autopilot/blob/main/boards/px4/fmu-v5/default.px4board) by ensuring the MAVLink debug app (**CONFIG_EXAMPLES_PX4_MAVLINK_DEBUG**) is in the config of your board and set to 'y'.
All required to set up a debug publication is this code snippet.
First add the header file:
+1 -1
View File
@@ -107,7 +107,7 @@ To enable this feature for use in Eclipse:
![NuttX: Menuconfig: CONFIG_DEBUG_TCBINFO](../../assets/debug/nuttx_tcb_task_aware.png)
1. Compile the **jlink-nuttx.so** library in the terminal by running the following command in the terminal: `make jlink-nuttx`
1. Modify Eclipse to use this libary.
1. Modify Eclipse to use this library.
In the _J-Link GDB Server Setup_ configuration, update **Other options** to include `-rtos /home/<PX4 path>/Tools/jlink-nuttx.so`, as shown in the image below.
![Eclipse: GDB Segger Debug config RTOS aware: debugger tab](../../assets/debug/eclipse_settings_debug_config_gdb_segger_task_aware.png)
+1 -1
View File
@@ -70,7 +70,7 @@ cd ~/PX4-Autopilot
make px4_sitl gz_x500
```
Open another terminal and start the `MicroXRCEAgent` to connect to the the simulator:
Open another terminal and start the `MicroXRCEAgent` to connect to the simulator:
```sh
MicroXRCEAgent udp4 -p 8888; exec bash
+1 -1
View File
@@ -1,6 +1,6 @@
# MCU-Link Debug Probe
The [MCU-Link Debug Probe](https://www.nxp.com/design/design-center/software/development-software/mcuxpresso-software-and-tools-/mcu-link-debug-probe:MCU-LINK) is a cheap, fast and highly capable debug probe that can serve as a stand-alone debug and console communicator whn working with Pixhawk boards.
The [MCU-Link Debug Probe](https://www.nxp.com/design/design-center/software/development-software/mcuxpresso-software-and-tools-/mcu-link-debug-probe:MCU-LINK) is a cheap, fast and highly capable debug probe that can serve as a stand-alone debug and console communicator when working with Pixhawk boards.
Key features:
+42 -36
View File
@@ -1,6 +1,6 @@
# SWD Debug Port
PX4 runs on ARM Cortex-M microcontrollers, which contain dedicated hardware for interactive debugging via the [_Serial Wire Debug (SWD)_][swd] interface and non-invasive profiling and high-bandwidth tracing via the [_Serial Wire Ouput (SWO)_][itm] and [_TRACE_ pins][etm].
PX4 runs on ARM Cortex-M microcontrollers, which contain dedicated hardware for interactive debugging via the [_Serial Wire Debug (SWD)_][swd] interface and non-invasive profiling and high-bandwidth tracing via the [_Serial Wire Output (SWO)_][itm] and [_TRACE_ pins][etm].
The SWD debug interface allows direct, low-level, hardware access to the microcontroller's processor and peripherals, so it does not depend on any software on the device.
Therefore it can be used to debug bootloaders and operating systems such as NuttX.
@@ -27,9 +27,7 @@ The SWO pin can emit low-overhead, real-time profiling data with nanosecond time
The TRACE pins require specialized debug probes to deal with the high bandwidth and subsequent datastream decoding.
They are usually not accessible and are typically only used to debug very specific timing issues.
<a id="debug-ports"></a>
## Autopilot Debug Ports
## Autopilot Debug Ports {#debug-ports}
Flight controllers commonly provide a single debug port that exposes both the [SWD Interface](#debug-signals) and [System Console](system_console).
@@ -40,40 +38,52 @@ The debug port location and pinouts for a subset of autopilots are linked below:
<a id="port-information"></a>
| Autopilot | Debug Port |
| :---------------------------------------------------------------------------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Holybro Pixhawk 6X-RT (FMUv6X-RT) | [Pixhawk Debug Full](#pixhawk-debug-full) |
| Holybro Pixhawk 6X (FMUv6x) | [Pixhawk Debug Full](#pixhawk-debug-full) |
| Holybro Pixhawk 5X (FMUv5x) | [Pixhawk Debug Full](#pixhawk-debug-full) |
| [Holybro Durandal](../flight_controller/durandal.md#debug-port) | [Pixhawk Debug Mini](#pixhawk-debug-mini) |
| [Holybro Kakute F7](../flight_controller/kakutef7.md#debug-port) | Solder pads |
| [Holybro Pixhawk 4 Mini](../flight_controller/pixhawk4_mini.md#debug-port) (FMUv5) | [Pixhawk Debug Mini](#pixhawk-debug-mini) |
| [Holybro Pixhawk 4](../flight_controller/pixhawk4.md#debug_port) (FMUv5) | [Pixhawk Debug Mini](#pixhawk-debug-mini) |
| [Drotek Pixhawk 3 Pro](../flight_controller/pixhawk3_pro.md#debug-port) (FMU-v4pro) | [Pixhawk Debug Mini](#pixhawk-debug-mini) |
| [CUAV V5+](../flight_controller/cuav_v5_plus.md#debug-port) | 6-pin JST GH<br>Digikey: [BM06B-GHS-TBT(LF)(SN)(N)][bm06b-ghs-tbt(lf)(sn)(n)] (vertical mount), [SM06B-GHS-TBT(LF)(SN)(N)][sm06b-ghs-tbt(lf)(sn)(n)] (side mount) |
| [CUAV V5nano](../flight_controller/cuav_v5_nano.md#debug_port) | 6-pin JST GH<br>Digikey: [BM06B-GHS-TBT(LF)(SN)(N)][bm06b-ghs-tbt(lf)(sn)(n)] (vertical mount), [SM06B-GHS-TBT(LF)(SN)(N)][sm06b-ghs-tbt(lf)(sn)(n)] (side mount) |
| [3DR Pixhawk](../flight_controller/pixhawk.md#swd-port) | ARM 10-pin JTAG Connector (also used for FMUv2 boards including: _mRo Pixhawk_, _HobbyKing HKPilot32_). |
| Autopilot | Debug Port |
| :----------------------------------------------------------------------------------- | :---------------------------------------- |
| [Holybro Pixhawk 6X-RT](../flight_controller/pixhawk6x-rt.md#debug_port) (FMUv6X-RT) | [Pixhawk Debug Full](#pixhawk-debug-full) |
| [Holybro Pixhawk 6X](../flight_controller/pixhawk6x.md#debug_port) (FMUv6x) | [Pixhawk Debug Full](#pixhawk-debug-full) |
| [Holybro Pixhawk 5X](../flight_controller/pixhawk5x.md#debug_port) (FMUv5x) | [Pixhawk Debug Full](#pixhawk-debug-full) |
| [Holybro Durandal](../flight_controller/durandal.md#debug-port) | [Pixhawk Debug Mini](#pixhawk-debug-mini) |
| [Holybro Pixhawk 4](../flight_controller/pixhawk4.md#debug_port) (FMUv5) | [Pixhawk Debug Mini](#pixhawk-debug-mini) |
| [Holybro Pixhawk 6X Pro](../flight_controller/pixhawk6x_pro.md#debug-port) | [Pixhawk Debug Full](#pixhawk-debug-full) |
| [Holybro Pixhawk 6C](../flight_controller/pixhawk6c.md#debug_port) | [Pixhawk Debug Full](#pixhawk-debug-full) |
| [Holybro Pixhawk 6C Mini](../flight_controller/pixhawk6c_mini.md#debug_port) | [Pixhawk Debug Mini](#pixhawk-debug-mini) |
| [Holybro Pix32 v6](../flight_controller/holybro_pix32_v6.md#debug_port) | [Pixhawk Debug Full](#pixhawk-debug-full) |
| [Holybro Pix32 v5](../flight_controller/holybro_pix32_v5.md#debug-port) | [Pixhawk Debug Mini](#pixhawk-debug-mini) |
| [Holybro Kakute H7](../flight_controller/kakuteh7.md#debug-port) | SWD pads and system console |
| [Holybro Kakute H7 mini](../flight_controller/kakuteh7mini.md#debug-port) | SWD pads and system console |
| [Holybro Kakute H7 V2](../flight_controller/kakuteh7v2.md#debug-port) | SWD pads and system console |
| [CUAV V5+](../flight_controller/cuav_v5_plus.md#debug-port) | Custom port but comes with adaptor cable |
| [CUAV V5nano](../flight_controller/cuav_v5_nano.md#debug_port) | Custom port but comes with adaptor cable |
| [CUAV Pixhawk V6X](../flight_controller/cuav_pixhawk_v6x.md#debug_port) | [Pixhawk Debug Full](#pixhawk-debug-full) |
| [CUAV X25-SUPER](../flight_controller/cuav_x25-super.md#debug_port) | [Pixhawk Debug Mini] |
| [CUAV X25-EVO](../flight_controller/cuav_x25-evo.md#debug_port) | [Pixhawk Debug Mini] |
| [CUAV Nora](../flight_controller/cuav_nora.md#debug-port) | Custom port but comes with adaptor cable. |
| [ARK Pixhawk Autopilot Bus Carrier](../flight_controller/ark_pab.md#debug-port) | [Pixhawk Debug Full](#pixhawk-debug-full) |
| [NXP MR-VMU-RT1176](../flight_controller/nxp_mr_vmu_rt1176.md#debug_port) | [Pixhawk Debug Full](#pixhawk-debug-full) |
| [mRo Pixracer](../flight_controller/pixracer.md#debug-port) | [Pixhawk Debug Mini](#pixhawk-debug-mini) |
| [S-Vehicle E2](../flight_controller/svehicle_e2.md#debug-port) | [Pixhawk Debug Mini] |
| [AP-H743-R1](../flight_controller/x-mav_ap-h743r1.md#debug-port) | 4-pin JST GH (SWD only) |
| [mRo Control Zero F7](../flight_controller/mro_control_zero_f7.md#debug_port) | |
<a id="pixhawk-standard-debug-ports"></a>
## Pixhawk Connector Standard Debug Ports
## Pixhawk Connector Standard Debug Ports {#pixhawk-standard-debug-ports}
The Pixhawk project has defines a standard pinout and connector type for different Pixhawk FMU releases:
:::tip
::: tip
Check your [specific board](#port-information) to confirm the port used.
:::
| FMU Version | Pixhawk Version | Debug Port |
| :---------- | :-------------------------------------------------------------- | :---------------------------------------- |
| FMUv2 | [Pixhawk / Pixhawk 1](../flight_controller/pixhawk.md#swd-port) | 10 pin ARM Debug |
| FMUv3 | Pixhawk 2 | 6 pin SUR Debug |
| FMUv4 | Pixhawk 3 | [Pixhawk Debug Mini](#pixhawk-debug-mini) |
| FMUv5 | Pixhawk 4 FMUv5 | [Pixhawk Debug Mini](#pixhawk-debug-mini) |
| FMUv5X | Pixhawk 5X | [Pixhawk Debug Full](#pixhawk-debug-full) |
| FMUv6 | Pixhawk 6 | [Pixhawk Debug Full](#pixhawk-debug-full) |
| FMUv6X | Pixhawk 6X | [Pixhawk Debug Full](#pixhawk-debug-full) |
| FMUv6X-RT | Pixhawk 6X-RT | [Pixhawk Debug Full](#pixhawk-debug-full) |
| FMU Version | Pixhawk Version | Debug Port |
| :---------- | :------------------ | :---------------------------------------- |
| FMUv2 | Pixhawk / Pixhawk 1 | 10 pin ARM Debug |
| FMUv3 | Pixhawk 2 | 6 pin SUR Debug |
| FMUv4 | Pixhawk 3 | [Pixhawk Debug Mini](#pixhawk-debug-mini) |
| FMUv5 | Pixhawk 4 FMUv5 | [Pixhawk Debug Mini](#pixhawk-debug-mini) |
| FMUv5X | Pixhawk 5X | [Pixhawk Debug Full](#pixhawk-debug-full) |
| FMUv6 | Pixhawk 6 | [Pixhawk Debug Full](#pixhawk-debug-full) |
| FMUv6X | Pixhawk 6X | [Pixhawk Debug Full](#pixhawk-debug-full) |
| FMUv6X-RT | Pixhawk 6X-RT | [Pixhawk Debug Full](#pixhawk-debug-full) |
::: info
There FMU and Pixhawk versions are (only) consistent after FMUv5X.
@@ -142,9 +152,7 @@ You can connect to the debug port using a [cable like this one](https://www.digi
![10-pin JST SH Cable](../../assets/debug/cable_10pin_jst_sh.jpg)
<a id="debug-probes"></a>
## Debug Probes for PX4 Hardware
## Debug Probes for PX4 Hardware {#debug-probes}
Flight controllers commonly provide a [single debug port](#autopilot-debug-ports) that exposes both the [SWD Interface](#debug-signals) and [System Console](system_console).
@@ -217,5 +225,3 @@ This reduces the risk or poor wiring contributing to debugging problems, and has
[swd]: https://developer.arm.com/documentation/ihi0031/a/The-Serial-Wire-Debug-Port--SW-DP-
[itm]: https://developer.arm.com/documentation/ddi0403/d/Appendices/Debug-ITM-and-DWT-Packet-Protocol?lang=en
[etm]: https://developer.arm.com/documentation/ihi0064/latest/
[bm06b-ghs-tbt(lf)(sn)(n)]: https://www.digikey.com/en/products/detail/jst-sales-america-inc/BM06B-GHS-TBT/807804
[sm06b-ghs-tbt(lf)(sn)(n)]: https://www.digikey.com/en/products/detail/jst-sales-america-inc/SM06B-GHS-TB/807790
+1 -1
View File
@@ -141,7 +141,7 @@ Note that the value is generated fresh for each log, and any value specified in
You can use choose different locations for your keys as long as they aren't used by anything else.
:::
The key in `CONFIG_PUBLIC_KEY1` is the public key used to wrap the symmetric key in the the beginning of `.ulge` file (by default: see [SDLOG_EXCH_KEY](../advanced_config/parameter_reference.md#SDLOG_EXCH_KEY)).
The key in `CONFIG_PUBLIC_KEY1` is the public key used to wrap the symmetric key in the beginning of `.ulge` file (by default: see [SDLOG_EXCH_KEY](../advanced_config/parameter_reference.md#SDLOG_EXCH_KEY)).
You can use the `rsa2048.pub` key for testing, or replace it with the path to your own public key in the file (see [Generate RSA Public & Private Keys](#generate-rsa-public-private-keys)).
Build the firmware like this:
+2 -2
View File
@@ -28,7 +28,7 @@ Order this module from:
- Pixhawk Standard SPI Connector
- 7 Pin JST GH
- PWM Connector
- 10 Pin JST JST
- 10 Pin JST
- 8 PWM Outputs
- Matches Pixhawk 4 PWM Connector Pinout
- Pixhawk Standard Debug Connector
@@ -77,7 +77,7 @@ DroneCAN configuration in PX4 is explained in more detail in [DroneCAN > Enablin
You will need to enable the subscriber appropriate for each of the sensors that are connected to the ARK CANnode.
This is done using the the parameters named like `UAVCAN_SUB_*` in the parameter reference (such as [UAVCAN_SUB_ASPD](../advanced_config/parameter_reference.md#UAVCAN_SUB_ASPD), [UAVCAN_SUB_BARO](../advanced_config/parameter_reference.md#UAVCAN_SUB_BARO) etc.).
This is done using the parameters named like `UAVCAN_SUB_*` in the parameter reference (such as [UAVCAN_SUB_ASPD](../advanced_config/parameter_reference.md#UAVCAN_SUB_ASPD), [UAVCAN_SUB_BARO](../advanced_config/parameter_reference.md#UAVCAN_SUB_BARO) etc.).
## Ark CANNode Configuration
+1 -1
View File
@@ -103,7 +103,7 @@ You need to set necessary [DroneCAN](index.md) parameters and define offsets if
### Parameter references
This GPS is using ARK's private driver, the prameters below only exist on the firmware we ship the GPS with. You can set these params either in QGC or using the DroneCAN GUI Tool.
This GPS is using ARK's private driver, the parameters below only exist on the firmware we ship the GPS with. You can set these params either in QGC or using the DroneCAN GUI Tool.
#### SEP_OFFS_YAW (float)
@@ -86,7 +86,7 @@ DroneCAN configuration in PX4 is explained in more detail in [DroneCAN > Enablin
### Sensor Position Configuration
- For the the single Rover the module should be mounted with the included mast.
- For the single Rover the module should be mounted with the included mast.
- For the Dual ZED-F9P setup (moving baseline), the DroneCAN modules should be placed at least 30cm apart on the airframe and elevated on a mast also.
See the following [mast](https://holybro.com/products/30-antenna-mount?_pos=20&_sid=67b49d76b&_ss=r).
- F9P module arrow(s) should be pointing forward with respect to the autopilot orientation.
+2 -2
View File
@@ -152,7 +152,7 @@ DroneCAN peripherals connected to PX4 can also be [configured using parameters v
By convention, parameters named with the prefix [CANNODE\_](../advanced_config/parameter_reference.md#CANNODE_BITRATE) have prefined meaning, and may be documented in the parameter reference.
`CANNODE_` parameters prefixed with `CANNODE_PUB_` and `CANNODE_SUB_` enable the peripheral to publish or subscribe the associated DroneCAN message.
These allow DroneCAN peripherals to be configured to only subscribe and publish messages that they actually need (in the same way that PX4 uses the corresponding `UAVCAN_PUB_`/`UAVCAN_SUB_` parameters).
Note that a peripheral might might not use `CANNODE_` parameters, in which case it may have to publish/subscribe to particular messages whether or not they are needed.
Note that a peripheral might not use `CANNODE_` parameters, in which case it may have to publish/subscribe to particular messages whether or not they are needed.
The following sections provide additional detail on the PX4 and DroneCAN peripheral parameters used to enable particular features.
@@ -285,7 +285,7 @@ Note that DroneCAN ESCs should be on their own dedicated CAN interface(s) becaus
PX4 can control external LEDs on a connected DroneCAN peripheral using the standard DroneCAN [LightsCommand](https://dronecan.github.io/Specification/7._List_of_standard_data_types/#lightscommand) message.
Up to 2 lights acan be controlled.
Each light can independently show [system status colours](../getting_started/led_meanings.md#ui-led), a fixed colour (commonly used for indciating aircraft orientation), or switch between both depending on arm state.
Each light can independently show [system status colours](../getting_started/led_meanings.md#ui-led), a fixed colour (commonly used for indicating aircraft orientation), or switch between both depending on arm state.
See [DroneCAN Lights](lights.md) for full configuration details.
+2 -2
View File
@@ -59,7 +59,7 @@ AIRLink has two computers and integrated LTE Module:
- Ethernet 10/100/1000 Native Gigabit
- WiFi 802.11a/b/g/n/ac, Bluetooth
- USB 3.0 Type C
- 2x Video: 4-Lane MIPI CSI (FPV Camera) and 4-Lane MIPI CSI with HMDI Input (Payload Camera)
- 2x Video: 4-Lane MIPI CSI (FPV Camera) and 4-Lane MIPI CSI with HDMI Input (Payload Camera)
- **LTE/5G Connectivity Module**
- Up to 600 Mbps bandwidth
@@ -327,7 +327,7 @@ For PPM receivers please use RC Connector PPM pin located on the left side of th
## Outputs
AIRLink has 16 PWM ouputs. Main outputs 1-8 and connected to IO MCU. AUX outputs 1-8 are connected to FMU.
AIRLink has 16 PWM outputs. Main outputs 1-8 and connected to IO MCU. AUX outputs 1-8 are connected to FMU.
| Output | Timer | Channel |
| ------ | -------- | --------- |
@@ -73,14 +73,14 @@ To [build PX4](../dev_setup/building_px4.md) for this target:
make mro_ctrl-zero-f7
```
## Debug Ports
## Debug Ports {#debug_port}
### Console Port
The [PX4 System Console](../debug/system_console.md) runs on `USART7` using the pins listed below.
This is a standard serial pinout, designed to connect to a [3.3V FTDI](https://www.digikey.com/en/products/detail/TTL-232R-3V3/768-1015-ND/1836393) cable (5V tolerant).
| mRo control zero f7 | | FTDI |
| mRo control zero f7 | | FTDI | |
| ------------------- | ----------- | ---- | ---------------- |
| 17 | USART7 Tx | 5 | FTDI RX (yellow) |
| 19 | USART7 Rx | 4 | FTDI TX (orange) |
+1 -1
View File
@@ -132,7 +132,7 @@ Connector pin assignments are left to right (i.e. Pin 1 is the left-most pin).
:::
- The [camera capture pin](../camera/fc_connected_camera.md#camera-capture-configuration) (`PI0`) is pin 2 on the AD&IO port, marked above as `FMU_CAP1`.
- _Pixhawk 5X_ pinouts can be downloaded in PDF from from [here](https://github.com/PX4/PX4-user_guide/blob/main/assets/flight_controller/pixhawk5x/pixhawk5x_pinout.pdf) or [here](https://cdn.shopify.com/s/files/1/0604/5905/7341/files/Holybro_Pixhawk5X_Pinout.pdf).
- _Pixhawk 5X_ pinouts can be downloaded in PDF from [here](https://github.com/PX4/PX4-user_guide/blob/main/assets/flight_controller/pixhawk5x/pixhawk5x_pinout.pdf) or [here](https://cdn.shopify.com/s/files/1/0604/5905/7341/files/Holybro_Pixhawk5X_Pinout.pdf).
## Serial Port Mapping
+1 -1
View File
@@ -131,7 +131,7 @@ make x-mav_ap-h743r1_default
Any multirotor/airplane/rover or boat that can be controlled using normal RC servos or Futaba S-Bus servos.
The complete set of supported configurations can be found in the [Airframe Reference](../airframes/airframe_reference.md).
## Debug Port
## Debug Port {#debug_port}
### SWD
+5 -5
View File
@@ -56,7 +56,7 @@ Missions can be paused by switching out of mission mode to any other mode (such
If the vehicle was not capturing images when it was paused, on resuming it will head from its _current position_ towards the same waypoint as it as was heading towards originally.
If the vehicle was capturing images (has camera trigger items) it will instead head from its current position towards the last waypoint it traveled through (before pausing), and then retrace its path at the same speed and with the same camera triggering behaviour.
This ensures that in survey/camera missions the planned path is captured.
A mission can be uploaded while the vehicle is paused, in which which case the current active mission item is set to 1.
A mission can be uploaded while the vehicle is paused, in which case the current active mission item is set to 1.
::: info
When a mission is paused while the camera on the vehicle was triggering, PX4 sets the current active mission item to the previous waypoint, so that when the mission is restarted the vehicle will retrace its last mission leg.
@@ -210,7 +210,7 @@ The diagram below shows the sorts of paths that you might expect.
![acc-rad](../../assets/flying/acceptance_radius_mission.png)
Vehicles switch to the next waypoint as soon as they enter the acceptance radius.
This is defined by the "L1 distance", which is is computed from two parameters: [NPFG_DAMPING](../advanced_config/parameter_reference.md#NPFG_DAMPING) and [NPFG_PERIOD](../advanced_config/parameter_reference.md#NPFG_PERIOD), and the current ground speed.
This is defined by the "L1 distance", which is computed from two parameters: [NPFG_DAMPING](../advanced_config/parameter_reference.md#NPFG_DAMPING) and [NPFG_PERIOD](../advanced_config/parameter_reference.md#NPFG_PERIOD), and the current ground speed.
By default, it's about 70 meters.
The equation is:
@@ -312,7 +312,7 @@ On _QGroundControl_ a popup button appears during landing to enable this.
Aborting the landing results in a climb out to an orbit pattern centered above the land waypoint.
The maximum of the aircraft's current altitude and [MIS_LND_ABRT_ALT](#MIS_LND_ABRT_ALT) is set as the abort orbit altitude height relative to (above) the landing waypoint.
Landing configuration (e.g. flaps, spoilers, landing airspeed) is disabled during abort and the aicraft flies in cruise conditions.
Landing configuration (e.g. flaps, spoilers, landing airspeed) is disabled during abort and the aircraft flies in cruise conditions.
The abort command is disabled during the flare for safety.
Operators may still manually abort the landing by switching to any manual mode, such as [Stabilized mode](../flight_modes_fw/stabilized.md)), though it should be noted that this is risky!
@@ -352,7 +352,7 @@ Note that if the wheel controller is enabled ([FW_W_EN](#FW_W_EN)), the controll
::: info
Nudging should not be used to supplement poor position control tuning.
If the vehicle is regularly showing poor tracking peformance on a defined path, please refer to the [fixed-wing control tuning guide](../flight_modes_fw/position.md) for instruction.
If the vehicle is regularly showing poor tracking performance on a defined path, please refer to the [fixed-wing control tuning guide](../flight_modes_fw/position.md) for instruction.
:::
| Parameter | Description |
@@ -363,7 +363,7 @@ If the vehicle is regularly showing poor tracking peformance on a defined path,
### Near Ground Safety Constraints
In landing mode, the distance sensor is used to determine proximity to the ground, and the airframe's geometry is used to calculate roll contraints to prevent wing strike.
In landing mode, the distance sensor is used to determine proximity to the ground, and the airframe's geometry is used to calculate roll constraints to prevent wing strike.
![Fixed-wing landing nudging](../../assets/flying/wing_geometry.png)
+2 -2
View File
@@ -14,7 +14,7 @@ Vehicles are [hand or catapult launched](#catapult-hand-launch) by default, but
- Flying vehicles will failsafe if they lose the altitude estimate.
- Disarmed vehicles can switch to mode without valid altitude estimate but can't arm.
- RC control switches can be used to change flight modes.
- RC stick movement is ignored in catapult takeoff but can can be used to nudge the vehicle in runway takeoff.
- RC stick movement is ignored in catapult takeoff but can be used to nudge the vehicle in runway takeoff.
- The [Failure Detector](../config/safety.md#failure-detector) will automatically stop the engines if there is a problem on takeoff.
<!-- https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/commander/ModeUtil/mode_requirements.cpp -->
@@ -111,7 +111,7 @@ The _launch detector_ is affected by the following parameters:
## Runway Takeoff {#runway_launch}
Runway takeoffs can be used by vehicles with landing gear and and steerable wheel (only).
Runway takeoffs can be used by vehicles with landing gear and steerable wheel (only).
You will first need to enable the wheel controller using the parameter [FW_W_EN](#FW_W_EN).
Vehicle should be centered and aligned with runway when takeoff is initiated.
+2 -2
View File
@@ -31,7 +31,7 @@ By default it will follow from directly behind the target at a distance of 8 met
Users can adjust the follow angle, height and distance using an RC controller as shown above:
- _Follow Height_ is controlled with the `up-down` input ("Throttle").
Center the stick to keep follow the target at a constant hight. Raise or lower the stick to adjust height.
Center the stick to keep follow the target at a constant height. Raise or lower the stick to adjust height.
- _Follow Distance_ is controlled with the `forward-back` input ("Pitch").
Pushing the stick forward increases the follow distance, pulling it back decreases the distance.
- _Follow Angle_ is controlled with the `left-right` input ("Roll").
@@ -117,7 +117,7 @@ The altitude control mode determine whether the vehicle altitude is relative to
- `2D + Terrain` makes the drone follow at a fixed height relative to the terrain underneath it, using information from a distance sensor.
- If the vehicle does not have a distance sensor following will be identical to `2D tracking`.
- Distance sensors aren't always accurate and vehicles may be "jumpy" when flying in this mode.
- Note that that height is relative to the ground underneath the vehicle, not the follow target.
- Note that height is relative to the ground underneath the vehicle, not the follow target.
The drone may not follow altitude changes of the target!
- `3D tracking` mode makes the drone follow at a height relative to the follow target, as supplied by its GPS sensor.
+1 -1
View File
@@ -59,7 +59,7 @@ Missions can be paused by switching out of mission mode to any other mode (such
If the vehicle was not capturing images when it was paused, on resuming it will head from its _current position_ towards the same waypoint as it as was heading towards originally.
If the vehicle was capturing images (has camera trigger items) it will instead head from its current position towards the last waypoint it traveled through (before pausing), and then retrace its path at the same speed and with the same camera triggering behaviour.
This ensures that in survey/camera missions the planned path is captured.
A mission can be uploaded while the vehicle is paused, in which which case the current active mission item is set to 1.
A mission can be uploaded while the vehicle is paused, in which case the current active mission item is set to 1.
::: info
When a mission is paused while the camera on the vehicle was triggering, PX4 sets the current active mission item to the previous waypoint, so that when the mission is restarted the vehicle will retrace its last mission leg.
+1 -1
View File
@@ -48,7 +48,7 @@ This is useful when there are few obstacles near the destination, because it may
![Return mode cone](../../assets/flying/rtl_cone.jpg)
The cone affects the minimum return altitude if return mode is triggered within the cylinder defined by the maximum cone radius and `RTL_RETURN_ALT`: outside this cyclinder `RTL_RETURN_ALT` is used.
The cone affects the minimum return altitude if return mode is triggered within the cylinder defined by the maximum cone radius and `RTL_RETURN_ALT`: outside this cylinder `RTL_RETURN_ALT` is used.
Inside the code the minimum return altitude is the intersection of the vehicle position with the cone, or `RTL_DESCEND_ALT` (whichever is higher).
In other words, the vehicle must always ascend to at least `RTL_DESCEND_ALT` if below that value.
+1 -1
View File
@@ -11,7 +11,7 @@ For more information see the specific docs for each mode:
- [Mission Mode (MC)](../flight_modes_mc/mission.md)
- [Mission Mode (FW)](../flight_modes_fw/mission.md)
The following sections outline mission mode behaviour that is VTOL specificL.
The following sections outline mission mode behaviour that is VTOL specific.
## Mission Commands
+1 -1
View File
@@ -109,7 +109,7 @@ Increasing aircraft pitch angle will cause an increase in height but also a decr
Increasing the throttle will increase airspeed but also height will increase due to the increase in lift.
Therefore, we have two inputs (pitch angle and throttle) which both affect the two outputs (airspeed and altitude) which makes the control problem challenging.
TECS offers a solution by respresenting the problem in terms of energies rather than the original setpoints.
TECS offers a solution by representing the problem in terms of energies rather than the original setpoints.
The total energy of an aircraft is the sum of kinetic and potential energy. Thrust (via throttle control) increases the total energy state of the aircraft. A given total energy state can be achieved by arbitrary combinations of potential and kinetic energies.
In other words, flying at a high altitude but at a slow speed can be equivalent to flying at a low altitude but at a faster airspeed in a total energy sense. We refer to this as the specific energy balance and it is calculated from the current altitude and true airspeed setpoint.
The specific energy balance is controlled via the aircraft pitch angle.
+1 -1
View File
@@ -71,7 +71,7 @@ If you see the vehicle "twitch" during landing (turn down the motors, and then i
## Flight Controls/Commands
Vehicle movement is controlled using the 4 basic commands: roll, yaw, pitch and throttle.
As the throttle is increased the rotors spin faster and the vehicle moves up, if the vehicle pitches forward then some of that that force will move the vehicle forward, if it rolls to the left/right, then some of that force will move the vehicle left/right, and changing the yaw spins the vehicle on its axis over the ground plane.
As the throttle is increased the rotors spin faster and the vehicle moves up, if the vehicle pitches forward then some of that force will move the vehicle forward, if it rolls to the left/right, then some of that force will move the vehicle left/right, and changing the yaw spins the vehicle on its axis over the ground plane.
These commands therefore allow you to move left/right, spin left/right, forward/back, and up/down, respectively, as shown on the [Mode 2](../getting_started/rc_transmitter_receiver.md#remote-control-units-for-aircraft) RC controller shown below.
+1 -1
View File
@@ -27,7 +27,7 @@ The following kits are currently available:
## Build Guides
The build guides below show how to assemble a number of kits.
Many kits vary only a little between revisions (for example, the new kit might simply upgrade the flight controller used, and is otherwise identical), so these are likely to be be useful for building the kits in the section above.
Many kits vary only a little between revisions (for example, the new kit might simply upgrade the flight controller used, and is otherwise identical), so these are likely to be useful for building the kits in the section above.
- [Holybro X500 v2 (Pixhawk 6C)](../frames_multicopter/holybro_x500v2_pixhawk6c.md)
- [Holybro X500 v2 (Pixhawk 5X)](../frames_multicopter/holybro_x500V2_pixhawk5x.md) — Discontinued (v2 kit uses Pixhawk 6c)

Some files were not shown because too many files have changed in this diff Show More