Mirrors_Framework/PX4-Autopilot
1
0
Fork 0
mirror of https://github.com/PX4/PX4-Autopilot.git synced 2026-05-26 09:26:25 +08:00
Code Issues Actions 5 Packages Projects Releases Wiki Activity

Move PX4 Guide source into /docs (#24490)

Browse Source 
* 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
2025-03-13 16:08:27 +11:00
committed by GitHub
parent 8e6d2ebe4a
commit 88d623bedb
5176 changed files with 558771 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/en/getting_started/flight_controller_selection.md
+42
View File
@@ -0,0 +1,42 @@
# Flight Controller Selection
Flight controllers are the "brains" of an unmanned vehicle.
PX4 can run on [many flight controller boards](../flight_controller/index.md).
You should select a board that suits the physical constraints of your vehicle, the activities you wish to perform, and of course cost.
<img src="../../assets/flight_controller/pixhawk6x/pixhawk6x_hero_upright.png" width="120px" title="Holybro Pixhawk6X"><img src="../../assets/flight_controller/cuav_pixhawk_v6x/pixhawk_v6x.jpg" width="200px" title="CUAV Pixhawk 6X" ><img src="../../assets/flight_controller/cube/orange/cube_orange_hero.jpg" width="250px" title="CubePilot Cube Orange" />
## Pixhawk Series
[Pixhawk Series](../flight_controller/pixhawk_series.md) open-hardware flight controllers run PX4 on NuttX OS.
With many form factors, there are versions targeted towards many use cases and market segments.
[Pixhawk Standard Autopilots](../flight_controller/autopilot_pixhawk_standard.md) are used as the PX4 reference platform.
They are supported and tested by the PX4 development team, and are highly recommended.
## Manufacturer-supported Controllers
Other flight controllers are [manufacturer-supported](../flight_controller/autopilot_manufacturer_supported.md).
This includes FCs that are heavily based on the Pixhawk standard (but which are not fully compliant), and many others.
Note that manufacturer-supported controllers can be just as "good" (or better) than those which are Pixhawk-standard.
## Autopilots for Computationally Intensive Tasks
Dedicated flight controllers like Pixhawk are not usually well-suited for general purpose computing or running computationally intensive tasks.
For more computing power, the most common approach is to run those applications on a separate onboard [Companion Computer](../companion_computer/index.md).
Some companion computers can also run PX4 on a separate DSP, as part of the same autopilot board.
Similarly, PX4 can also run natively Raspberry Pi (this approach is not generally considered as "robust" as having a separate companion or using a dedicated DSP):
- [Raspberry Pi 2/3 Navio2](../flight_controller/raspberry_pi_navio2.md)
- [Raspberry Pi 2/3/4 PilotPi Shield](../flight_controller/raspberry_pi_pilotpi.md)
## Commercial UAVs that can run PX4
PX4 is available on many popular commercial drone products, including some that ship with PX4 and others that can be updated with PX4 (allowing you to add mission planning and other PX4 Flight modes to your vehicle).
For more information see [Complete Vehicles](../complete_vehicles/index.md).
docs/en/getting_started/flight_modes.md
+1
View File
@@ -0,0 +1 @@
<Redirect to="../getting_started/px4_basic_concepts" />
docs/en/getting_started/flight_reporting.md
+50
View File
@@ -0,0 +1,50 @@
# Flight Reporting
PX4 logs detailed aircraft state and sensor data, which can be used to analyze performance issues.
This topic explains how you can download and analyse logs, and share them with the development team for review.
:::tip
Keeping flight logs is a legal requirement in some jurisdictions.
:::
## Downloading Logs from the Flight Controller
Logs can be downloaded using [QGroundControl](http://qgroundcontrol.com/): **[Analyze View > Log Download](https://docs.qgroundcontrol.com/master/en/qgc-user-guide/analyze_view/log_download.html)**.
![Flight Log Download](../../assets/qgc/analyze/log_download.jpg)
## Analyzing the Logs
Upload the log file to the online [Flight Review](http://logs.px4.io) tool.
After upload you'll be emailed a link to the analysis page for the log.
[Log Analysis using Flight Review](../log/flight_review.md) explains how to interpret the plots, and can help you to verify/reject the causes of common problems: excessive vibration, poor PID tuning, saturated controllers, imbalanced vehicles, GPS noise, etc.
::: info
There are many other great tools for visualising and analysing PX4 Logs.
For more information see: [Flight Analysis](../dev_log/flight_log_analysis.md).
:::
:::tip
If you have a constant high-rate MAVLink connection to the vehicle (not just a telemetry link) then you can use *QGroundControl* to automatically upload logs directly to *Flight Review*.
For more information see [Settings > MAVLink Settings > MAVLink 2 Logging (PX4 only)](https://docs.qgroundcontrol.com/master/en/qgc-user-guide/settings_view/mavlink.html#logging).
:::
## Sharing the Log Files for Review by PX4 Developers
The [Flight Review](http://logs.px4.io) log file link can be shared for discussion in the [support forums](../contribute/support.md#forums-and-chat) or a [Github issue](../index.md#reporting-bugs-issues).
## Log Configuration
The logging system is configured by default to collect sensible logs for use with [Flight Review](http://logs.px4.io).
Logging may further be configured using the [SD Logging](../advanced_config/parameter_reference.md#sd-logging) parameters or with a file on the SD card.
Details on configuration can be found in the [logging configuration documentation](../dev_log/logging.md#configuration).
## Key Links
- [Flight Review](http://logs.px4.io)
- [Log Analysis using Flight Review](../log/flight_review.md)
- [Flight Log Analysis](../dev_log/flight_log_analysis.md)
docs/en/getting_started/led_meanings.md
+89
View File
@@ -0,0 +1,89 @@
# LED Meanings (Pixhawk Series)
[Pixhawk-series flight controllers](../flight_controller/pixhawk_series.md) use LEDs to indicate the current status of the vehicle.
- The [UI LED](#ui_led) provides user-facing status information related to *readiness for flight*.
- The [Status LEDs](#status_led) provide status for the PX4IO and FMU SoC.
They indicate power, bootloader mode and activity, and errors.
<a id="ui_led"></a>
## UI LED
The RGB *UI LED* indicates the current *readiness for flight* status of the vehicle.
This is typically a superbright I2C peripheral, which may or may not be mounted on the flight controller board (i.e. FMUv4 does not have one on board, and typically uses an LED mounted on the GPS).
The image below shows the relationship between LED and vehicle status.
:::warning
It is possible to have a GPS lock (Green LED) and still not be able to arm the vehicle because PX4 has not yet [passed preflight checks](../flying/pre_flight_checks.md). **A valid global position estimate is required to takeoff!**
:::
:::tip
In the event of an error (blinking red), or if the vehicle can't achieve GPS lock (change from blue to green), check for more detailed status information in *QGroundControl* including calibration status, and errors messages reported by the [Preflight Checks (Internal)](../flying/pre_flight_checks.md).
Also check that the GPS module is properly attached, Pixhawk is reading your GPS properly, and that the GPS is sending a proper GPS position.
:::
![LED meanings](../../assets/flight_controller/pixhawk_led_meanings.gif)
* **[Solid Blue] Armed, No GPS Lock:** Indicates vehicle has been armed and has no position lock from a GPS unit.
When vehicle is armed, PX4 will unlock control of the motors, allowing you to fly your drone.
As always, exercise caution when arming, as large propellers can be dangerous at high revolutions.
Vehicle cannot perform guided missions in this mode.
* **[Pulsing Blue] Disarmed, No GPS Lock:** Similar to above, but your vehicle is disarmed.
This means you will not be able to control motors, but all other subsystems are working.
* **[Solid Green] Armed, GPS Lock:** Indicates vehicle has been armed and has a valid position lock from a GPS unit.
When vehicle is armed, PX4 will unlock control of the motors, allowing you to fly your drone.
As always, exercise caution when arming, as large propellers can be dangerous at high revolutions.
In this mode, vehicle can perform guided missions.
* **[Pulsing Green] Disarmed, GPS Lock:** Similar to above, but your vehicle is disarmed.
This means you will not be able to control motors, but all other subsystems including GPS position lock are working.
* **[Solid Purple] Failsafe Mode:** This mode will activate whenever vehicle encounters an issue during flight,
such as losing manual control, a critically low battery, or an internal error.
During failsafe mode, vehicle will attempt to return to its takeoff location, or may simply descend where it currently is.
* **[Solid Amber] Low Battery Warning:** Indicates your vehicle's battery is running dangerously low.
After a certain point, vehicle will go into failsafe mode. However, this mode should signal caution that it's time to end
this flight.
* **[Blinking Red] Error / Setup Required:** Indicates that your autopilot needs to be configured or calibrated before flying.
Attach your autopilot to a Ground Control Station to verify what the problem is.
If you have completed the setup process and autopilot still appears as red and flashing, there may be another error.
<a id="status_led"></a>
## Status LED
Three *Status LEDs* provide status for the FMU SoC, and three more provide status for the PX4IO (if present).
They indicate power, bootloader mode and activity, and errors.
![Pixhawk 4](../../assets/flight_controller/pixhawk4/pixhawk4_status_leds.jpg)
From power on, the FMU and PX4IO CPUs first run the bootloader (BL) and then the application (APP).
The table below shows how the Bootloader and then APP use the LEDs to indicate condition.
Color | Label | Bootloader usage | APP usage
--- | --- | --- | ---
Blue | ACT (Activity) | Flutters when the bootloader is receiving data | Indication of ARM state
Red/Amber | B/E (In Bootloader / Error) | Flutters when in the bootloader | Indication of an ERROR
Green |PWR (Power) | Not used by bootloader | Indication of ARM state
::: info
The LED labels shown above are commonly used, but might differ on some boards.
:::
More detailed information for how to interpret the LEDs is given below (where "x" means "any state")
Red/Amber | Blue | Green | Meaning
--- | --- | --- | ---
10Hz | x | x | Overload CPU load > 80%, or RAM usage > 98%
OFF | x | x | Overload CPU load <= 80%, or RAM usage <= 98%
NA | OFF | 4 Hz| actuator_armed->armed && failsafe
NA | ON | 4 Hz | actuator_armed->armed && !failsafe
NA | OFF |1 Hz | !actuator_armed-> armed && actuator_armed->ready_to_arm
NA | OFF |10 Hz | !actuator_armed->armed && !actuator_armed->ready_to_arm
docs/en/getting_started/px4_basic_concepts.md
+386
View File
@@ -0,0 +1,386 @@
# Basic Concepts
This topic provides a basic introduction to drones and using PX4 (it is meant mostly for novice users but is also a good introduction for more experienced users).
If you are already familiar with the basic concepts, you can move on to [Basic Assembly](../assembly/index.md) to learn how to wire your specific autopilot hardware.
To load firmware and set up the vehicle with _QGroundControl_, see [Basic Configuration](../config/index.md).
## What is a Drone?
A drone, or Unmanned Vehicles (UV), is an unmanned "robotic" vehicle that can be manually or autonomously controlled.
They can travel in air, on the ground, on/under the water, and are used for many [consumer, industrial, government and military applications](https://px4.io/ecosystem/commercial-systems/), including aerial photography/video, carrying cargo, racing, search and surveying, and so on.
Drones are more formally referred to as Unmanned Aerial Vehicles (UAV), Unmanned Ground Vehicles (UGV), Unmanned Surface Vehicles (USV), Unmanned Underwater Vehicles (UUV).
::: info
The term Unmanned Aerial System (UAS) typically refers to a UAV and all of the other components of a complete system, including a ground control station and/or radio controller, and any other systems used to control the drone, capture, and process data.
:::
## Drone Types
There are many different vehicle frames (types), and within the types there are many variations.
Some of the types, along with the use cases for which they are most suited are listed below.
- [Multicopters](../frames_multicopter/index.md) — Multi-rotors offer precision hovering and vertical takeoff, at the cost of shorter and generally slower flight.
They are the most popular type of flying vehicle, in part because they are easy to assemble, and PX4 has modes that make them easy to fly and very suitable as a camera platform.
- [Helicopters](../frames_helicopter/index.md) — Helicopters similar benefits to Multicopters but are mechanically more complex and more efficient.
They are also much harder to fly.
- [Planes (Fixed-wing)](../frames_plane/index.md) — Fixed-wing vehicles offer longer and faster flight than multicopters, and hence better coverage for ground surveys etc.
However they are harder to fly and land than multicopters, and aren't suitable if you need to hover or fly very slowly (e.g. when surveying vertical structures).
- [VTOL](../frames_vtol/index.md) (Vertical Takeoff and Landing) - Hybrid Fixed-wing/Multicopter vehicles offer the best of both worlds: take off in vertical mode and hover like a multicopter but transition to forward flight like an airplane to cover more ground.
VTOL are often more expensive than either multicopters and fixed-wing aircraft, and harder to build and tune.
They come in a number of types: tiltrotors, tailsitters, quadplanes etc.
- [Airships](../frames_airship/index.md)/[Balloons](../frames_balloon/index.md) — Lighter-than-air vehicles that typically offer high altitude long duration flight, often at the cost of having limited (or no) control over speed and direction of flight.
- [Rovers](../frames_rover/index.md) — Car-like ground vehicles.
They are simple to control and often fun to use.
They can't travel as fast as most aircraft, but can carry heavier payloads, and don't use much power when still.
- **Boats** — Water-surface vehicles.
- [Submersibles](../frames_sub/index.md) — Underwater vehicles.
For more information see:
- [Vehicle Types & Setup](../airframes/index.md)
- [Airframe setup](../config/airframe.md)
- [Airframe Reference](../airframes/airframe_reference.md).
## Autopilots
The "brain" of the drone is called an autopilot.
It minimally consists of _flight stack_ software running on a real time OS ("RTOS") on _flight controller_ (FC) hardware.
The flight stack provides essential stabilisation and safety features, and usually also some level of pilot assistance for manual flight and automating common tasks, such as taking off, landing, and executing predefined missions.
Some autopilots also include a general-purpose computing system that can provide "higher level" command and control, and that can support more advanced networking, computer vision, and other features.
This might be implemented as a separate [companion computer](#offboard-companion-computer), but in future it is increasingly likely to be a fully integrated component.
## PX4 Flight Stack
[PX4](https://px4.io/) is powerful open source autopilot _flight stack_ running on the NuttX RTOS.
Some of PX4's key features are:
- Supports many different vehicle frames/types, including: [multicopters](../frames_multicopter/index.md), [fixed-wing aircraft](../frames_plane/index.md) (planes), [VTOLs](../frames_vtol/index.md) (hybrid multicopter/fixed-wing), [ground vehicles](../frames_rover/index.md), and [underwater vehicles](../frames_sub/index.md).
- Great choice of drone components for [flight controller](#flight-controller), [sensors](#sensors), [payloads](#payloads), and other peripherals.
- Flexible and powerful [flight modes](#flight-modes) and [safety features](#safety-settings-failsafe).
- Robust and deep integration with [companion computers](#offboard-companion-computer) and [robotics APIs](../robotics/index.md) such as [ROS 2](../ros2/user_guide.md) and [MAVSDK](http://mavsdk.mavlink.io).
PX4 is a core part of a broader drone platform that includes the [QGroundControl](#qgc) ground station, [Pixhawk hardware](https://pixhawk.org/), and [MAVSDK](http://mavsdk.mavlink.io) for integration with companion computers, cameras and other hardware using the MAVLink protocol.
PX4 is supported by the [Dronecode Project](https://www.dronecode.org/).
## Ground Control Stations
Ground Control Stations (GCS) are ground based systems that allow UV operators to monitor and control a drone and its payloads.
A subset of the products that are known to work with PX4 are listed below.
### QGroundControl {#qgc}
The Dronecode GCS software is called [QGroundControl](http://qgroundcontrol.com/) ("QGC").
It runs on Windows, Android, MacOS or Linux hardware, and supports a wide range of screen form factors.
You can download it (for free) from [here](http://qgroundcontrol.com/downloads/).
![QGC Main Screen](../../assets/concepts/qgc_fly_view.png)
QGroundControl communicates with the drone using a telemetry radio (a bidirectional data link), which allows you to get real-time flight and safety information, and to control the vehicle, camera, and other payloads using a point-and-click interface.
On hardware that supports them, you can also manually fly the vehicle using joystick controllers.
QGC can also be used to visually plan, execute, and monitor autonomous missions, set geofences, and much more.
QGroundControl desktop versions are also used to install (flash) PX4 firmware and configure PX4 on the drone's autopilot/flight controller hardware.
### Auterion Mission Control (AMC) {#amc}
[Auterion Mission Control](https://auterion.com/product/mission-control/) is a powerful and fully featured ground control station application that is optimized for _pilots_ rather than vehicle configuration.
While designed to work with Auterion products, it can be used with "vanilla" PX4.
For more information see:
- [AMC docs](https://docs.auterion.com/vehicle-operation/auterion-mission-control)
- [Download from Auterion Suite](https://suite.auterion.com/)
## Drone Components & Parts
### Flight Controller
Flight controllers (FC) are the hardware onto which the PX4 flight stack firmware is loaded and run.
They are connected to sensors from which PX4 determines its state, and to the actuators/motors that it uses to stabilise and move the vehicle.
<img src="../../assets/flight_controller/cuav_pixhawk_v6x/pixhawk_v6x.jpg" width="230px" title="CUAV Pixhawk 6X" >
PX4 can run on many different types of [Flight Controller Hardware](../flight_controller/index.md), ranging from [Pixhawk Series](../flight_controller/pixhawk_series.md) controllers to Linux computers.
These include [Pixhawk Standard](../flight_controller/autopilot_pixhawk_standard.md) and [manufacturer-supported](../flight_controller/autopilot_manufacturer_supported.md) boards.
You should select a board that suits the physical constraints of your vehicle, the activities you wish to perform, and cost.
For more information see: [Flight Controller Selection](flight_controller_selection.md)
### Sensors
PX4 uses sensors to determine vehicle state, which it needs in order to stablise the vehicle and enable autonomous control.
The vehicle states include: position/altitude, heading, speed, airspeed, orientation (attitude), rates of rotation in different axes, battery level, and so on.
PX4 _minimally requires_ a [gyroscope](../sensor/gyroscope.md), [accelerometer](../sensor/accelerometer.md), [magnetometer](../gps_compass/magnetometer.md) (compass) and [barometer](../sensor/barometer.md).
This minimal set of sensors is incorporated into [Pixhawk Series](../flight_controller/pixhawk_series.md) flight controllers (and may also be in other controller platforms).
Additional/external sensors can be attached to the controller.
The following sensors are recommended:
- A [GNSS/GPS](../gps_compass/index.md) or other source of global position is needed to enable all automatic modes, and some manual/assisted modes.
Typically a module that combines a GNSS and Compass is used, as an external compass can be made less susceptible to electromomagnetic interference than the internal compass in the flight controller.
- [Airspeed sensors](../sensor/airspeed.md) are highly recommended for fixed-wing and VTOL-vehicles.
- [Distance Sensors \(Rangefinders\)](../sensor/rangefinders.md) are highly recommended for all vehicle types, as they allow smoother and more robust landings, and enable features such as terrain following on multicopters.
- [Optical Flow Sensors](../sensor/optical_flow.md) can be used with distance sensors on multcopters and VTOL to support navigation in GNSS-denied environments.
For more information about sensors see: [Sensor Hardware & Setup](../sensor/index.md).
### Outputs: Motors, Servos, Actuators
PX4 uses _outputs_ to control: motor speed (e.g. via [ESC](#escs-motors)), flight surfaces like ailerons and flaps, camera triggers, parachutes, grippers, and many other types of payloads.
The outputs may be PWM ports or DroneCAN nodes (e.g. DroneCAN [motor controllers](../dronecan/escs.md)).
The images below show the PWM output ports for [Pixhawk 4](../flight_controller/pixhawk4.md) and [Pixhawk 4 mini](../flight_controller/pixhawk4_mini.md).
![Pixhawk 4 output ports](../../assets/flight_controller/pixhawk4/pixhawk4_main_aux_ports.jpg) ![Pixhawk4 mini MAIN ports](../../assets/flight_controller/pixhawk4mini/pixhawk4mini_pwm.png)
The outputs are divided into `MAIN` and `AUX` outputs, and individually numbered (i.e. `MAINn` and `AUXn`, where `n` is 1 to usually 6 or 8).
They might also be marked as `IO PWM Out` and `FMU PWM OUT` (or similar).
:::warning
A flight controller may only have `MAIN` PWM outputs (like the _Pixhawk 4 Mini_), or may have only 6 outputs on either `MAIN` or `AUX`.
Ensure that you select a controller that has enough ports/outputs for your [airframe](../airframes/airframe_reference.md).
:::
You can connect almost any output to any motor or other actuator, by assigning the associated function ("Motor 1") to the desired output ("AUX1") in QGroundControl: [Actuator Configuration and Testing](../config/actuators.md).
Note that the functions (motor and control surface actuator positions) for each frame are given in the [Airframe Reference](../airframes/airframe_reference.md).
**Notes:**
- Pixhawk controllers have an FMU board and _may_ have a separate IO board.
If there is an IO board, the `AUX` ports are connected directly to the FMU and the `MAIN` ports are connected to the IO board.
Otherwise the `MAIN` ports are connected to the FMU, and there are no `AUX` ports.
- The FMU output ports can use [D-shot](../peripherals/dshot.md) or _One-shot_ protocols (as well as PWM), which provide much lower-latency behaviour.
This can be useful for racers and other airframes that require better performance.
- There are only 6-8 outputs in `MAIN` and `AUX` because most flight controllers only have this many PWM/Dshot/Oneshot outputs.
In theory there can be many more outputs if the bus supports it (i.e. a UAVCAN bus is not limited to this few nodes).
### ESCs & Motors
Many PX4 drones use brushless motors that are driven by the flight controller via an Electronic Speed Controller (ESC)
(the ESC converts a signal from the flight controller to an appropriate level of power delivered to the motor).
For information about what ESC/Motors are supported by PX4 see:
- [ESC & Motors](../peripherals/esc_motors.md)
- [ESC Calibration](../advanced_config/esc_calibration.md)
- [ESC Firmware and Protocols Overview](https://oscarliang.com/esc-firmware-protocols/) (oscarliang.com)
### Battery/Power
PX4 drones are mostly commonly powered from Lithium-Polymer (LiPo) batteries.
The battery is typically connected to the system using a [Power Module](../power_module/index.md) or _Power Management Board_, which provide separate power for the flight controller and to the ESCs (for the motors).
Information about batteries and battery configuration can be found in [Battery Estimation Tuning](../config/battery.md) and the guides in [Basic Assembly](../assembly/index.md) (e.g. [Pixhawk 4 Wiring Quick Start > Power](../assembly/quick_start_pixhawk4.md#power)).
### Manual Control
Pilots can control a vehicle manually using either a [Radio Control (RC) System](../getting_started/rc_transmitter_receiver.md) or a [Joystick/Gamepad](../config/joystick.md) controller connected via QGroundControl.
![Taranis X9D Transmitter](../../assets/hardware/transmitters/frsky_taranis_x9d_transmitter.jpg) <img src="../../assets/peripherals/joystick/micronav.jpg" alt="Photo of MicroNav, a ground controller with integrated joysticks" width="400px">
RC systems use a dedicated ground-based radio transmitter and vehicle-based receiver for sending control information.
They should always be used when first tuning/testing a new frame design, or when flying racers/acrobatically (and in other cases where low latency is important).
Joystick systems use QGroundControl to encode the control information from a "standard" computer gaming joystick into MAVLink messages, and sent it to the vehicle using the (shared) telemetry radio channel.
They can be used for most manual flight use cases such as taking off, surveys, and so on, provided your telemetry channel has a high enough bandwidth/low latency.
Joysticks are often used in integrated GCS/manual control systems because it is cheaper and easier to integrate a joystick than a separate radio system, and for the majority of use cases, the lower latency does not matter.
They are also perfect for flying the PX4 simulator, because you can plug them directly into your ground control computer.
::: info
PX4 does not _require_ a manual control system for autonomous flight modes.
:::
### Safety Switch
Vehicles may include a _safety switch_ that must be engaged before the vehicle can be [armed](#arming-and-disarming) (when armed, motors are powered and propellers can turn).
This switch is almost always integrated into the [GPS](../gps_compass/index.md) module that is connected to the Pixhawk `GPS1` port — along with the [buzzer](#buzzer) and [UI LED](#leds).
The switch may be disabled by default, though this depends on the particular flight controller and airframe configuration.
You can disable/enable use of the switch with the [CBRK_IO_SAFETY](../advanced_config/parameter_reference.md#CBRK_IO_SAFETY) parameter.
::: info
Safety switches are optional.
Many argue that it is safer for users never to approach a powered system, even to enable/disable this interlock.
:::
### Buzzer
Vehicles commonly include a buzzer for providing audible notification of vehicle state and readiness to fly (see [Tune meanings](../getting_started/tunes.md)).
This buzzer is almost always integrated into the [GPS](../gps_compass/index.md) module that is connected to the Pixhawk `GPS1` port — along with the [safety switch](#safety-switch) and [UI LED](#leds).
You can disable the notification tunes using the parameter [CBRK_BUZZER](../advanced_config/parameter_reference.md#CBRK_BUZZER).
### LEDs
Vehicles should have a superbright [UI RGB LED](../getting_started/led_meanings.md#ui-led) that indicates the current readiness for flight.
Historically this was included in the flight controller board.
On more recent flight controllers this is almost always an [I2C peripheral](../sensor_bus/i2c_general.md) integrated into the [GPS](../gps_compass/index.md) module that is connected to the Pixhawk `GPS1` port — along with the [safety switch](#safety-switch) and [buzzer](#buzzer).
### Data/Telemetry Radios
[Data/Telemetry Radios](../telemetry/index.md) can provide a wireless MAVLink connection between a ground control station like _QGroundControl_ and a vehicle running PX4.
This makes it possible to tune parameters while a vehicle is in flight, inspect telemetry in real-time, change a mission on the fly, etc.
### Offboard/Companion Computer
A [Companion Computer](../companion_computer/index.md) (also referred to as "mission computer" or "offboard computer"), is a separate on-vehicle computer that communicates with PX4 to provide higher level command and control.
The companion computer usually runs Linux, as this is a much better platform for "general" software development, and allows drones to leverage pre-existing software for computer vision, networking, and so on.
The flight controller and companion computer may be pre-integrated into a single baseboard, simplifying hardware development, or may be separate, and are connected via a serial cable, Ethernet cable, or wifi.
The companion computer typically communicates with PX4 using a high level Robotics API such as [MAVSDK](https://mavsdk.mavlink.io/) or [ROS 2](../ros2/user_guide.md).
Relevant topics include:
- [Companion Computers](../companion_computer/index.md)
- [Off-board Mode](../flight_modes/offboard.md) - Flight mode for offboard control of PX4 from a GCS or companion computer.
- [Robotics APIs](../robotics/index.md)
### SD Cards (Removable Memory)
PX4 uses SD memory cards for storing [flight logs](../getting_started/flight_reporting.md), and they are also required in order to use UAVCAN peripherals and fly [missions](../flying/missions.md).
By default, if no SD card is present PX4 will play the [format failed (2-beep)](../getting_started/tunes.md#format-failed) tune twice during boot (and none of the above features will be available).
::: tip
The maximum supported SD card size on Pixhawk boards is 32GB.
The _SanDisk Extreme U3 32GB_ and _Samsung EVO Plus 32_ are [highly recommended](../dev_log/logging.md#sd-cards).
:::
SD cards are never-the-less optional.
Flight controllers that do not include an SD Card slot may:
- Disable notification beeps are disabled using the parameter [CBRK_BUZZER](../advanced_config/parameter_reference.md#CBRK_BUZZER).
- [Stream logs](../dev_log/logging.md#log-streaming) to another component (companion).
- Store missions in RAM/FLASH.
<!-- Too low-level for this. But see FLASH_BASED_DATAMAN in Intel Aero: https://github.com/PX4/PX4-Autopilot/blob/main/boards/intel/aerofc-v1/src/board_config.h#L115 -->
## Payloads
Payloads are equipment carried by the vehicle to meet user or mission objectives, such as cameras in surveying missions, instruments used in for inspections such as radiation detectors, and cargo that needs to be delivered.
PX4 supports many cameras and a wide range of payloads.
Payloads are connected to [Flight Controller outputs](#outputs-motors-servos-actuators), and can be triggered automatically in missions, or manually from an RC Controller or Joystick, or from a Ground Station (via MAVLink/MAVSDK commands).
For more information see: [Payloads & Cameras](../payloads/index.md)
## Arming and Disarming
A vehicle is said to be _armed_ when all motors and actuators are powered, and _disarmed_ when nothing is powered.
There is also a _prearmed_ state when only servo actuators are powered, which is primarily used for testing.
A vehicle is usually disarmed on the ground, and must be armed before taking off in the current flight mode.
:::warning
Armed vehicles are dangerous because propellers can start spinning at any time without further user input, and in many cases will start spinning immediately.
:::
Arming and disarming are triggered by default using RC stick _gestures_.
On Mode 2 transmitters you arm by holding the RC throttle/yaw stick on the _bottom right_ for one second, and to disarm you hold the stick on bottom left for one second.
It is alternatively possible to configure PX4 to arm using an RC switch or button (and arming MAVLink commands can also be sent from a ground station).
To reduce accidents, vehicles should be armed as little as possible when the vehicle is on the ground.
By default, vehicles are:
- _Disarmed_ or _Prearmed_ (motors unpowered) when not in use, and must be explicitly _armed_ before taking off.
- Automatically disarm/prearm if the vehicle does not take off quickly enough after arming (the disarm time is configurable).
- Automatically disarm/prearm shortly after landing (the time is configurable).
- Arming is prevented if the vehicle is not in a "healthy" state.
- Arming is prevented if the vehicle has a [safety switch](#safety-switch) that has not been engaged.
- Arming is prevented if a VTOL vehicle is in fixed-wing mode ([by default](../advanced_config/parameter_reference.md#CBRK_VTOLARMING)).
- Arming may be prevented due to a number of other optional [arming pre-condition settings](../config/safety.md#arming-pre-conditions), such as low battery.
When prearmed you can still use actuators, while disarming unpowers everything.
Prearmed and disarmed should both be safe, and a particular vehicle may support either or both.
:::tip
Sometimes a vehicle will not arm for reasons that are not obvious.
QGC v4.2.0 (Daily build at time of writing) and later provide an arming check report in [Fly View > Arming and Preflight Checks](https://docs.qgroundcontrol.com/master/en/qgc-user-guide/fly_view/fly_view.html#arm).
From PX4 v1.14 this provides comprehensive information about arming problems along with possible solutions.
:::
A detailed overview of arming and disarming configuration can be found here: [Prearm, Arm, Disarm Configuration](../advanced_config/prearm_arm_disarm.md).
## Flight Modes
Modes are special operational states that provide different types/levels of vehicle automation and autopilot assistance to the user (pilot).
_Autonomous modes_ are fully controlled by the autopilot, and require no pilot/remote control input.
These are used, for example, to automate common tasks like takeoff, returning to the home position, and landing.
Other autonomous modes execute pre-programmed missions, follow a GPS beacon, or accept commands from an offboard computer or ground station.
_Manual modes_ are controlled by the user (via the RC control sticks/joystick) with assistance from the autopilot.
Different manual modes enable different flight characteristics - for example, some modes enable acrobatic tricks,
while others are impossible to flip and will hold position/course against wind.
:::tip
Not all modes are available on all vehicle types, and some modes can only be used when specific conditions have been met (e.g. many modes require a global position estimate).
:::
An overview of the flight modes implemented within PX4 for each vehicle can be found below:
- [Flight Modes (Multicopter)](../flight_modes_mc/index.md)
- [Flight Modes (Fixed-Wing)](../flight_modes_fw/index.md)
- [Flight Modes (VTOL)](../flight_modes_vtol/index.md)
- [Drive Modes (Differential Rover)](../flight_modes_rover/differential.md)
- [Drive Modes (Ackermann Rover)](../flight_modes_rover/ackermann.md)
Instructions for how to set up your remote control switches to enable different flight modes is provided in [Flight Mode Configuration](../config/flight_mode.md).
PX4 also supports external modes implemented in [ROS 2](../ros2/index.md) using the [PX4 ROS 2 Control Interface](../ros2/px4_ros2_control_interface.md).
These are indistinguishable from PX4 internal modes, and can be used to override internal modes with a more advanced version, or to create entirely new functionality.
Note that these depend on ROS 2 and can therefore only run on systems that have a [companion computer](#offboard-companion-computer).
## Safety Settings (Failsafe)
PX4 has configurable failsafe systems to protect and recover your vehicle if something goes wrong!
These allow you to specify areas and conditions under which you can safely fly, and the action that will be performed if a failsafe is triggered (for example, landing, holding position, or returning to a specified point).
::: info
You can only specify the action for the _first_ failsafe event.
Once a failsafe occurs the system will enter special handling code, such that subsequent failsafe triggers are managed by separate system level and vehicle specific code.
:::
The main failsafe areas are listed below:
- Low Battery
- Remote Control (RC) Loss
- Position Loss (global position estimate quality is too low).
- Offboard Loss (e.g. lose connection to companion computer)
- Data Link Loss (e.g. lose telemetry connection to GCS).
- Geofence Breach (restrict vehicle to flight within a virtual cylinder).
- Mission Failsafe (prevent a previous mission being run at a new takeoff location).
- Traffic avoidance (triggered by transponder data from e.g. ADSB transponders).
For more information see: [Safety](../config/safety.md) (Basic Configuration).
## Heading and Directions
All the vehicles, boats and aircraft have a heading direction or an orientation based on their forward motion.
![Frame Heading](../../assets/concepts/frame_heading.png)
::: info
For a VTOL Tailsitter the heading is relative to the multirotor configuration (i.e. vehicle pose during takeoff, hovering, landing).
:::
It is important to know the vehicle heading direction in order to align the autopilot with the vehicle vector of movement.
Multicopters have a heading even when they are symmetrical from all sides!
Usually manufacturers use a coloured props or coloured arms to indicate the heading.
![Frame Heading TOP](../../assets/concepts/frame_heading_top.png)
In our illustrations we will use red colouring for the front propellers of multicopter to show heading.
You can read in depth about heading in [Flight Controller Orientation](../config/flight_controller_orientation.md)
docs/en/getting_started/rc_transmitter_receiver.md
+168
View File
@@ -0,0 +1,168 @@
# Radio Control Systems
A Radio Control (RC) system can be used to _manually_ control your vehicle from a handheld RC controller.
This topic provides an overview of how RC works, how to choose an appropriate radio system for your vehicle, and how to connect it to your flight controller.
:::tip
PX4 can also be manually controlled using a [Joystick](../config/joystick.md) or gamepad-like controller: this is different to an RC system!
The [COM_RC_IN_MODE](../advanced_config/parameter_reference.md#COM_RC_IN_MODE) parameter [can be set](../advanced_config/parameters.md) to choose whether RC (default), Joystick, both, or neither, are enabled.
:::
::: info
PX4 does not require a remote control system for autonomous flight modes.
:::
## How do RC Systems Work?
An _RC system_ has a ground-based _remote control unit_ that is used by the operator to command the vehicle.
The remote has physical controls that can be used to specify vehicle movement (e.g. speed, direction, throttle, yaw, pitch, roll, etc.) and to enable autopilot [flight modes](../flight_modes/index.md) (e.g. takeoff, land, return to land, mission etc.).
On _telemetry-enabled_ RC systems, the remote control unit can also receive and display information from the vehicle, such as battery level, flight mode, and warnings.
![Taranis X9D Transmitter](../../assets/hardware/transmitters/frsky_taranis_x9d_transmitter.jpg)
The ground based RC controller contains a radio module that is bound to, and communicates with, a (compatible) radio module on the vehicle.
The vehicle-based unit is connected to the flight controller.
The flight controller determines how to interpret the commands based on the current autopilot flight mode and vehicle state, and drives the vehicle motors and actuators appropriately.
<!-- image showing the different parts here would be nice -->
::: info
The ground- and vehicle- based radio modules are referred to as the transmitter and receiver respectively (even if they support bidirectional communication) and are collectively referred to as a _transmitter/receiver pair_.
The RC controller and it's included radio module are commonly referred to as a "transmitter".
:::
An important quality of an RC system is how many "channels" it supports.
The number of channels defines how many different physical controls on the remote control can be used to send commands to the vehicle (e.g. how many switches, dials, control sticks can actually be used).
An aircraft must use a system that supports at least 4 channels (for roll, pitch, yaw, thrust).
Ground vehicles need at least two channels (steering + throttle). An 8 or 16 channel transmitter provides additional channels that can be used to control other mechanisms or activate different [flight modes](../flight_modes/index.md) provided by the autopilot.
## Types of Remote Controllers
<a id="transmitter_modes"></a>
### Remote Control Units for Aircraft
The most popular _form_ of remote control unit for UAVs is shown below.
It has separate control sticks for controlling roll/pitch and for throttle/yaw as shown (i.e. aircraft need at least 4 channels).
![RC Basic Commands](../../assets/flying/rc_basic_commands.png)
There are numerous possible layouts for the control sticks, switches, etc.
The more common layouts have been given specific "Mode" numbers. _Mode 1_ and _Mode 2_ (shown below) differ only in the placement of the throttle.
![Mode1-Mode2](../../assets/concepts/mode1_mode2.png)
::: info
The choice of mode is largely one of taste (_Mode 2_ is more popular).
:::
## Remote Control Units for Ground Vehicles
An Unmanned Ground Vehicle (UGV)/car minimally requires a 2 channel transmitter in order to send the values for steering and speed.
Commonly transmitters set these values using a wheel and trigger, two single-axis control sticks, or a single dual-axis control stick.
There is nothing to stop you using more channels/control mechanisms, and these can be very useful for engaging additional actuators and autopilot modes.
## Choosing RC System Components
You will need to select a transmitter/receiver pair that are compatible with each other.
In addition, receivers have to be [compatible with PX4](#compatible_receivers) and the flight controller hardware.
Compatible radio systems are often sold together.
For example, [FrSky Taranis X9D and FrSky X8R](https://hobbyking.com/en_us/frsky-2-4ghz-accst-taranis-x9d-plus-and-x8r-combo-digital-telemetry-radio-system-mode-2.html?___store=en_us) are a popular combination.
### Transmitter/Receiver Pairs
One of the most popular RC units is the _FrSky Taranis X9D_.
It has an internal transmitter module can be used with the recommended _FrSky X4R-SB_ (S-BUS, low delay) or _X4R_ (PPM-Sum, legacy) receivers out of the box.
It also has a custom radio transmitter module slot and customizable open source OpenTX Firmware.
::: info
This remote control unit can display vehicle telemetry when used with [FrSky](../peripherals/frsky_telemetry.md) or [TBS Crossfire](../telemetry/crsf_telemetry.md) radio modules.
:::
Other popular transmitter/receiver pairs
- Turnigy remote using, for example, the FrSky transmitter/receiver modules.
- Futaba Transmitters and compatible Futaba S-Bus receivers.
- Long range ~900MHz, low latency: "Team Black Sheep Crossfire" or "Crossfire Micro" set with a compatible remote (e.g. Taranis)
- Long Range ~433MHz: ImmersionRC EzUHF set with a compatible remote (e.g. Taranis)
### PX4-Compatible Receivers {#compatible_receivers}
In addition to the transmitter/receiver pairs being compatible, the receiver must also be compatible with PX4 and the flight controller hardware.
_PX4_ and _Pixhawk_ have been validated with:
- PPM sum receivers
- S.BUS and S.BUS2 receivers from:
- Futaba
- FrSky S.BUS and PPM models
- TBS Crossfire with SBUS as output protocol
- Herelink
- TBS Crossfire with ([CRSF protocol](../telemetry/crsf_telemetry.md))
- Express LRS with ([CRSF protocol](../telemetry/crsf_telemetry.md))
- TBS Ghost with (GHST protocol)
- Spektrum DSM
- Graupner HoTT
Receivers from other vendors that use a supported protocol are likely to work but have not been tested.
::: info
Historically there were differences and incompatibilities between receiver models, largely due to a lack of detailed specification of protocols.
The receivers we have tested all now appear to be compatible, but it is possible that others may not be.
:::
## Connecting Receivers
As general guidance, receivers connect to the flight controller using the port appropriate to their supported protocol:
- Spektrum/DSM receivers connect to the "DSM" input.
Pixhawk flight controllers variously label this as: `SPKT/DSM`, `DSM`, `DSM/SBUS RC`, `DSM RC`, `DSM/SBUS/RSSI`.
- Graupner HoTT receivers: SUMD output must connect to a **SPKT/DSM** input (as above).
- PPM-Sum and S.BUS receivers must connect directly to the **RC** ground, power and signal pins.
This is typically labeled: `RC IN`, `RCIN` or `RC`, but has in some FCs has been labeled `PPM RC` or `PPM`.
- PPM receivers that have an individual wire for each channel must connect to the RCIN channel _via_ a PPM encoder [like this one](http://www.getfpv.com/radios/radio-accessories/holybro-ppm-encoder-module.html) (PPM-Sum receivers use a single signal wire for all channels).
- TBS Crossfire/Express LRS Receivers using [CRSF Telemetry](../telemetry/crsf_telemetry.md) connect via a spare UART.
Flight controllers usually include appropriate cables for connecting common receiver types.
Instructions for connecting to specific flight controllers are given in their [quick-start](../assembly/index.md) guides (such as [CUAV Pixhawk V6X Wiring Quick Start: Radio Control](../assembly/quick_start_cuav_pixhawk_v6x.md#radio-control) or [Holybro Pixhawk 6X Wiring Quick Start: Radio Control](../assembly/quick_start_pixhawk6x.md#radio-control)).
:::tip
See the manufacturer's flight controller setup guide for additional information.
:::
<a id="binding"></a>
## Binding Transmitter/Receiver
Before you can calibrate/use a radio system you must _bind_ the receiver and transmitter so that they communicate only with each other.
The process for binding a transmitter and receiver pair is hardware specific (see your manual for instructions).
If you are using a _Spektrum_ receiver, you can put it into bind mode using _QGroundControl_: [Radio Setup > Spectrum Bind](../config/radio.md#spectrum-bind).
## Set Signal-Loss Behaviour
RC receivers have different ways of indicating signal loss:
- Output nothing (automatically detected by PX4)
- Output a low throttle value (you can [configure PX4 to detect this](../config/radio.md#rc-loss-detection)).
- Output the last received signal (PX4 cannot handle this case!)
Choose a receiver that can emit nothing (preferred) when RC is lost, or a low throttle value.
This behaviour may require hardware configuration of the receiver (check the manual).
For more information see [Radio Control Setup > RC Loss Detection](../config/radio.md#rc-loss-detection).
## Related Topics
- [Radio Control Setup](../config/radio.md) - Configuring your radio with PX4.
- Manual Flying on [multicopter](../flying/basic_flying_mc.md) or [fixed wing](../flying/basic_flying_fw.md) - Learn how to fly with a remote control.
- [TBS Crossfire (CRSF) Telemetry](../telemetry/crsf_telemetry.md)
- [FrSky Telemetry](../peripherals/frsky_telemetry.md)
docs/en/getting_started/tunes.md
+185
View File
@@ -0,0 +1,185 @@
# Tune Meanings (Pixhawk Series)
[Pixhawk-series flight controllers](../flight_controller/pixhawk_series.md) use audible tones/tunes from a [buzzer](../getting_started/px4_basic_concepts.md#buzzer) and colours/sequences from a [LED](../getting_started/led_meanings.md) to indicate vehicle state and events (e.g. arming success and failure, low battery warnings).
The set of standard sounds are listed below.
::: info
**Developers:** Tunes are defined in [/lib/tunes/tune_definition.desc](https://github.com/PX4/PX4-Autopilot/blob/main/src/lib/tunes/tune_definition.desc) and can be tested using the [tune-control](../modules/modules_system.md#tune-control) module.
You can search for tune use using the string `TUNE_ID_name`(e.g. `TUNE_ID_PARACHUTE_RELEASE)
:::
## Boot/Startup
These tunes are played during the boot sequence.
<!-- https://github.com/PX4/PX4-Autopilot/blob/main/ROMFS/px4fmu_common/init.d/rcS -->
#### Startup Tone
<audio controls><source src="../../assets/tunes/1_startup_tone.mp3" type="audio/mpeg">Your browser does not support the audio element.</audio>
<!-- tune: 1, STARTUP -->
- microSD card successfully mounted (during boot).
#### Error Tune
<audio controls><source src="../../assets/tunes/2_error_tune.mp3" type="audio/mpeg">Your browser does not support the audio element.</audio>
<!-- tune 2, ERROR_TUNE -->
- Hard fault has caused a system reboot.
- System set to use PX4IO but no IO present.
- UAVCAN is enabled but driver can't start.
- SITL/HITL enabled but *pwm_out_sim* driver can't start.
- FMU startup failed.
#### Make File System
<audio controls><source src="../../assets/tunes/16_make_fs.mp3" type="audio/mpeg">Your browser does not support the audio element.</audio>
<!-- 14, SD_INIT (previously tune 16) -->
- Formatting microSD card.
- Mounting failed (if formatting succeeds boot sequence will try to mount again).
- No microSD card.
#### Format Failed
<audio controls><source src="../../assets/tunes/17_format_failed.mp3" type="audio/mpeg">Your browser does not support the audio element.</audio>
<!-- 15, SD_ERROR (previously 17) -->
- Formatting microSD card failed (following previous attempt to mount card).
#### Program PX4IO
<audio controls><source src="../../assets/tunes/18_program_px4io.mp3" type="audio/mpeg">Your browser does not support the audio element.</audio>
<!-- 16, PROG_PX4IO (previously id 18) -->
- Starting to program PX4IO.
#### Program PX4IO Success
<audio controls><source src="../../assets/tunes/19_program_px4io_success.mp3" type="audio/mpeg">Your browser does not support the audio element.</audio>
<!-- 17, PROG_PX4IO_OK (previously tune 19) -->
- PX4IO programming succeeded.
#### Program PX4IO Fail
<audio controls><source src="../../assets/tunes/20_program_px4io_fail.mp3" type="audio/mpeg">Your browser does not support the audio element.</audio>
<!-- 18, PROG_PX4IO_ERR (previously tune 20) -->
- PX4IO programming failed.
- PX4IO couldn't start.
- AUX Mixer not found.
## Operational
These tones/tunes are emitted during normal operation.
<a id="error_tune_operational"></a>
#### Error Tune
<audio controls><source src="../../assets/tunes/2_error_tune.mp3" type="audio/mpeg">Your browser does not support the audio element.</audio>
<!-- 2, ERROR_TUNE -->
- RC Loss
#### Notify Positive Tone
<audio controls><source src="../../assets/tunes/3_notify_positive_tone.mp3" type="audio/mpeg">Your browser does not support the audio element.</audio>
<!-- 3, NOTIFY_POSITIVE -->
- Calibration succeeded.
- Successful mode change.
- Command accepted (e.g. from MAVLink command protocol).
- Safety switch off (vehicle can be armed).
#### Notify Neutral Tone
<audio controls><source src="../../assets/tunes/4_notify_neutral_tone.mp3" type="audio/mpeg">Your browser does not support the audio element.</audio>
<!-- 4, NOTIFY_NEUTRAL -->
- Mission is valid and has no warnings.
- Airspeed calibration: supply more air pressure, or calibration complete.
- Safety switch turned on/disarmed (safe to approach vehicle).
#### Notify Negative Tone
<audio controls><source src="../../assets/tunes/5_notify_negative_tone.mp3" type="audio/mpeg">Your browser does not support the audio element.</audio>
<!-- 5, NOTIFY_NEGATIVE -->
- Calibration failed.
- Calibration already completed.
- Mission is invalid.
- Command denied, failed, temporarily rejected (e.g. from MAVLink command protocol).
- Arming/disarming transition denied (e.g. pre-flight checks failed, safety not disabled, system not in manual mode).
- Reject mode transition.
#### Arming Warning
<audio controls><source src="../../assets/tunes/6_arming_warning.mp3" type="audio/mpeg">Your browser does not support the audio element.</audio>
<!-- 6, ARMING_WARNING -->
- Vehicle is now armed.
#### Arming Failure Tune
<audio controls><source src="../../assets/tunes/10_arming_failure_tune.mp3" type="audio/mpeg">Your browser does not support the audio element.</audio>
<!-- 10, ARMING_FAILURE -->
- Arming failed
#### Battery Warning Slow
<audio controls><source src="../../assets/tunes/7_battery_warning_slow.mp3" type="audio/mpeg">Your browser does not support the audio element.</audio>
<!-- 7, BATTERY_WARNING_SLOW -->
- Low battery warning ([failsafe](../config/safety.md#battery-level-failsafe)).
#### Battery Warning Fast
<audio controls><source src="../../assets/tunes/8_battery_warning_fast.mp3" type="audio/mpeg">Your browser does not support the audio element.</audio>
<!-- 8, BATTERY_WARNING_FAST -->
- Critical low battery warning ([failsafe](../config/safety.md#battery-level-failsafe)).
#### GPS Warning Slow
<audio controls><source src="../../assets/tunes/9_gps_warning_slow.mp3" type="audio/mpeg">Your browser does not support the audio element.</audio>
<!-- 9, GPS_WARNING -->
#### Parachute Release
<audio controls><source src="../../assets/tunes/11_parachute_release.mp3" type="audio/mpeg">Your browser does not support the audio element.</audio>
<!-- 11, PARACHUTE_RELEASE -->
- Parachute release triggered.
#### Single Beep
<audio controls><source src="../../assets/tunes/14_single_beep.mp3" type="audio/mpeg">Your browser does not support the audio element.</audio>
<!-- 12, SINGLE_BEEP (previously was id 14 -->
- Magnetometer/Compass calibration: Notify user to start rotating vehicle.
#### Home Set Tune
<audio controls><source src="../../assets/tunes/15_home_set_tune.mp3" type="audio/mpeg">Your browser does not support the audio element.</audio>
<!-- 13, HOME_SET (previously id 15) -->
- Home position initialised (first time only).
#### Power Off Tune
<audio controls><source src="../../assets/tunes/power_off_tune.mp3" type="audio/mpeg">Your browser does not support the audio element.</audio>
- Vehicle powering off.
<!--19, POWER_OFF -->
docs/en/getting_started/vehicle_status.md
+12
View File
@@ -0,0 +1,12 @@
# Vehicle Status Notifications
PX4 provides vehicle-based visual (LED) and audible (Buzzer) notifications of "high level" vehicle status and readiness to fly.
These notifications indicate, for example, whether or not the vehicle is properly calibrated, has an SD card, has position lock, is safe to approach, whether or not it is armed, when it is ready to fly, etc.
In addition, PX4 provides more fine-grained information about readiness to fly in QGroundControl.
The LED, tune, and GCS notifications are linked below:
* [LED Meanings](../getting_started/led_meanings.md)
* [Tune/Sound Meanings](../getting_started/tunes.md)
* [QGroundControl Flight-Readiness Status](../flying/pre_flight_checks.md)