Mirrors_Framework/PX4-Autopilot
1
0
Fork 0
mirror of https://github.com/PX4/PX4-Autopilot.git synced 2026-08-20 22:13:46 +08:00
Code Issues Actions 27 Packages Projects Releases Wiki Activity

docs(i18n): PX4 guide translations (Crowdin) - uk (#27756)

Browse Source 
Co-authored-by: Crowdin Bot <support+bot@crowdin.com>
This commit is contained in:
PX4 Build Bot
2026-06-28 14:47:21 +10:00
committed by GitHub
co-authored by Crowdin Bot
parent ed84d04bfc
commit d7bd51a86d
16 changed files with 454 additions and 111 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/uk/SUMMARY.md
+2
View File
@@ -534,6 +534,7 @@
- [Шина I2C](sensor_bus/i2c_development.md)
- [UART/Послідовний порт](uart/index.md)
- [Драйвери послідовного порту і їх налаштування](uart/user_configurable_serial_driver.md)
- [Serial Passthrough (MAVLink SERIAL_CONTROL)](uart/serial_passthrough.md)
- [RTK GPS (Інтеграція)](advanced/rtk_gps.md)
- [PPS Time Synchronization](advanced/pps_time_sync.md)
- [Проміжне програмне забезпечення](middleware/index.md)
@@ -912,6 +913,7 @@
- [Multi-Vehicle Sim with JMAVSim](sim_jmavsim/multi_vehicle.md)
- [JSBSim Simulation](sim_jsbsim/index.md)
- [AirSim Simulation](sim_airsim/index.md)
- [RotorPy Simulation](sim_rotorpy/index.md)
- [Hardware Simulation](simulation/hardware.md)
- [HITL Simulation](simulation/hitl.md)
- [SIH on Hardware](sim_sih/hardware.md)
docs/uk/companion_computer/index.md
+1 -1
View File
@@ -4,7 +4,7 @@ Companion computers ("mission computers"), are separate on-vehicle computers tha
На схемі нижче показана можлива архітектура безпілотного транспортного засобу, яка включає в себе контролер польоту і супутній комп'ютер.
![Архітектура PX4 - система з політним контролером і супутнім комп'ютером](../../assets/diagrams/px4_companion_computer_simple.svg)
<img src="../../assets/diagrams/px4_companion_computer_simple.svg" alt="PX4 architecture - FC + Companion Computer" class="diagram-invert">
<!-- source for drawing: https://docs.google.com/drawings/d/1ZDSyj5djKCEbabgx8K4ESdTeEUizgEt8spUWrMGbHUE/edit?usp=sharing -->
docs/uk/concept/pwm_limit.md
+1 -1
View File
@@ -24,4 +24,4 @@
## Діаграма зміну стану
![PWM Limit state machine diagram](../../assets/diagrams/pwm_limit_state_diagram.svg)
<img src="../../assets/diagrams/pwm_limit_state_diagram.svg" alt="PWM Limit state machine diagram" class="diagram-invert">
docs/uk/concept/px4_systems_architecture.md
+2 -2
View File
@@ -11,7 +11,7 @@
На діаграмі нижче показано загальний огляд типової "простої" системи PX4 на основі польотного контролера.
![PX4 architecture - FC only system](../../assets/diagrams/px4_arch_fc.svg)
<img src="../../assets/diagrams/px4_arch_fc.svg" alt="PX4 architecture - FC only system" class="diagram-invert">
<!-- Source for drawing: https://docs.google.com/drawings/d/1_2n43WrbkWTs1kz0w0avVEeebJbfTj5SSqvCmvSOBdU/edit -->
@@ -34,7 +34,7 @@
На діаграмі показано систему PX4, яка включає як політний контролер, так і супутній комп'ютер (тут згадується як "комп'ютер політного завдання").
![PX4 architecture - FC + Companion Computer](../../assets/diagrams/px4_arch_fc_companion.svg)
<img src="../../assets/diagrams/px4_arch_fc_companion.svg" alt="PX4 architecture - FC + Companion Computer" class="diagram-invert">
<!-- source for drawing: https://docs.google.com/drawings/d/1zFtvA_B-BmfmxFmAd-XIvAZ-jRqOydj0aBtqSolBcqI/edit -->
docs/uk/dev_setup/dev_env_linux_ubuntu.md
+5 -2
View File
@@ -10,8 +10,11 @@ The environment includes:
The build toolchain for other flight controllers, simulators, and working with ROS are discussed in the [Other Targets](#other-targets) section below.
:::info
PX4 targets the **current Ubuntu LTS** (24.04) for CI and release builds, with the **previous LTS** (22.04) also supported.
Older Ubuntu versions are not supported and may not work.
The current CI and release target is **Ubuntu 24.04**, with build tests also run on **Ubuntu 22.04**.
Ubuntu 26.04 is not yet supported.
More generally, PX4 supports all currently active Ubuntu LTS releases, dropping versions when they reach end-of-life.
Support for a new LTS release is added once it provides the toolchain packages required by CI — including the ability to build for hardware targets and run SIH-based integration tests.
:::
## Симуляція та NuttX (Pixhawk)
docs/uk/flight_stack/controller_diagrams.md
+3 -1
View File
@@ -44,7 +44,9 @@ The diagrams use the standard [PX4 notation](../contribute/notation.md) (and eac
- The attitude controller makes use of [quaternions](https://en.wikipedia.org/wiki/Quaternion).
- The controller is implemented from this [article](https://www.research-collection.ethz.ch/bitstream/handle/20.500.11850/154099/eth-7387-01.pdf).
- При налаштуванні цього контролера єдиний параметр, що становить зацікавленість, - це коефіцієнт P.
- The attitude setpoint is first smoothed by a 2nd-order critically-damped reference model ([MC_REF_W_N](../advanced_config/parameter_reference#MC_REF_W_N)); the P-law tracks its reference attitude, and the model's reference body rate is fed forward to the rate setpoint, removing the pure-P law's steady-state tracking lag.
- The feedforward is scaled by `MC_REF_FF` (`0` disables it), clipped per axis by `MC_REF_FF_MAX`, and suppressed during autotuning.
- Higher `MC_REF_W_N` or `MC_REF_FF` tracks more aggressively but demands more peak rate; the P gain remains the main tuning parameter.
- Команда швидкості насичена.
### Перетворення заданого значення прискорення мультикоптера в тягу та положення
docs/uk/mavlink/security_hardening.md
+1
View File
@@ -17,6 +17,7 @@ When MAVLink signing is not enabled, an attacker within communication range can:
| Capability | MAVLink mechanism |
| ------------------------------------------- | ------------------------------------------------ |
| Execute shell commands | `SERIAL_CONTROL` with `SERIAL_CONTROL_DEV_SHELL` |
| Read/write arbitrary UART pin | `SERIAL_CONTROL` |
| Read, write, or delete files | MAVLink FTP protocol |
| Change any flight parameter | `PARAM_SET` / `PARAM_EXT_SET` |
| Upload or overwrite missions | Mission protocol |
docs/uk/middleware/uxrce_dds.md
+135 -75
View File
@@ -22,13 +22,13 @@ PX4 uses an XRCE-DDS implementation that leverages [eProsima Micro XRCE-DDS](htt
![Architecture uXRCE-DDS with ROS 2](../../assets/middleware/xrce_dds/architecture_xrce-dds_ros2.svg)
In order for PX4 uORB topics to be shared on the DDS network you will need _uXRCE-DDS client_ running on PX4, connected to the _micro XRCE-DDS agent_ running on the companion.
In order for PX4 uORB topics to be shared on the DDS network you will need _uXRCE-DDS client_ running on PX4, connected to the _Micro XRCE-DDS Agent_ running on the companion.
The PX4 [uxrce_dds_client](../modules/modules_system.md#uxrce-dds-client) publishes to/from a defined set of uORB topics to the global DDS data space.
The [eProsima micro XRCE-DDS _agent_](https://github.com/eProsima/Micro-XRCE-DDS-Agent) runs on the companion computer and acts as a proxy for the client in the DDS/ROS 2 network.
The [eProsima Micro XRCE-DDS _Agent_](https://github.com/eProsima/Micro-XRCE-DDS-Agent) runs on the companion computer and acts as a proxy for the client in the DDS/ROS 2 network.
Сам агент не залежить від коду на стороні клієнта і може бути побудований та/або встановлений незалежно від PX4 або ROS.
The agent itself has no dependency on client-side code and can be built and/or installed independent of PX4 or ROS, as long as version compatibility is ensured.
Код, який хоче підписатися/публікувати до PX4, залежить від коду на стороні клієнта; йому потрібні визначення повідомлень uORB, які збігаються з тими, що були використані для створення клієнта PX4 uXRCE-DDS, щоб він міг інтерпретувати повідомлення.
@@ -41,7 +41,7 @@ The [eProsima micro XRCE-DDS _agent_](https://github.com/eProsima/Micro-XRCE-DDS
The PX4 [uxrce_dds_client](../modules/modules_system.md#uxrce-dds-client) is generated at build time and included in PX4 firmware by default.
Агент не залежить від клієнтського коду.
Він може бути побудований окремо або в робочому просторі ROS 2, або встановлений як snap пакет в Ubuntu.
It can be built standalone or in a ROS 2 workspace.
When PX4 is built, a code generator uses the uORB message definitions in the source tree ([PX4-Autopilot/msg](https://github.com/PX4/PX4-Autopilot/tree/main/msg)) to compile support for the subset of uORB topics in [/src/modules/uxrce_dds_client/dds_topics.yaml](../middleware/dds_topics.md) into [uxrce_dds_client](../modules/modules_system.md#uxrce-dds-client).
@@ -51,6 +51,28 @@ ROS 2 applications need to be built in a workspace that includes the _same_ mess
These can be included into a workspace by cloning the interface package [PX4/px4_msgs](https://github.com/PX4/px4_msgs) into your ROS 2 workspace and switching to the appropriate branch.
Зауважте, що вся генерація коду, пов'язана з повідомленнями, обробляється ROS 2.
## Version selection
There are two main major active Micro XRCE-DDS versions: `v2.x` and `v3.x`.
These need to be paired to the corresponding major DDS version.
In standalone DDS applications you should use the latest DDS version with `Micro XRCE-DDS v3.x`.
However, in ROS 2 applications the DDS version is locked down by the chosen ROS 2 distribution: `v3.x` is required if you want to use the latest ROS 2 distributions.
<Badge type="tip" text="PX4 v1.18" /> In its default configuration `uxrce_dds_client` is built targeting Micro XRCE-DDS `v2.x`.
To target `v3.x` instead, the [`Kconfig`](../hardware/porting_guide_config.md#px4-menuconfig-setup) variable `UXRCE_DDS_CLIENT_USE_DDS_V3` must be set, and a custom build performed.
The following table explains the required Micro-XRCE-DDS-Agent versions and `UXRCE_DDS_CLIENT_USE_DDS_V3` value for different ROS 2 distributions.
| ROS 2 version | fast-dds version | required Micro-XRCE-DDS-Agent version | `UXRCE_DDS_CLIENT_USE_DDS_V3` <Badge type="tip" text="PX4 v1.18" /> |
| ------------- | -------------------------------------- | ------------------------------------- | ------------------------------------------------------------------- |
| Foxy | 2.0.x | 2.4.2 | unset / `N` |
| Humble | 2.6.x | 2.4.2 | unset / `N` |
| Jazzy | 2.14.0 | 2.4.3 | unset / `N` |
| Kilted | 2.14.4 | 2.4.3 | unset / `N` |
| Lyrical | 3.6.x | 3.0.1 | set / `Y` |
| Rolling | 3.6.x | 3.0.1 | set / `Y` |
## Встановлення Micro XRCE-DDS Agent
Micro XRCE-DDS Agent може бути встановлений на комп'ютер за допомогою бінарного пакета, зібраний і встановлений з вихідного коду, або зібраний і запущений з робочого простору ROS 2.
@@ -61,14 +83,14 @@ The official (and more complete) installation guide is the Eprosima: [micro XRCE
У цьому розділі узагальнено варіанти, які були протестовані за допомогою PX4 під час створення цієї документації.
:::
:::warning
PX4 Micro XRCE-DDS Client is based on version `v2.x` which is not compatible with the latest `v3.x` Agent version.
:::
### Окреме встановлення з вихідного коду
В Ubuntu ви можете зібрати з вихідного коду і встановити Агент окремо за допомогою наступних команд:
::::tabs
:::tab DDS v2
```sh
git clone -b v2.4.3 https://github.com/eProsima/Micro-XRCE-DDS-Agent.git
cd Micro-XRCE-DDS-Agent
@@ -80,47 +102,36 @@ sudo make install
sudo ldconfig /usr/local/lib/
```
:::
:::tab DDS v3
```sh
git clone -b v3.0.1 https://github.com/eProsima/Micro-XRCE-DDS-Agent.git
cd Micro-XRCE-DDS-Agent
mkdir build
cd build
cmake ..
make
sudo make install
sudo ldconfig /usr/local/lib/
```
Don't forget to set `UXRCE_DDS_CLIENT_USE_DDS_V3` before building PX4 when using DDS v3!
:::
::::
:::info
There are various build configuration options linked from the corresponding topic in the [official guide](https://micro-xrce-dds.docs.eprosima.com/en/latest/installation.html#installing-the-agent-standalone), but these have not been tested.
:::
Запустити агент з налаштуваннями для підключення до клієнта uXRCE-DDS, запущеного у симуляторі:
```sh
MicroXRCEAgent udp4 -p 8888
```
### Встановлення з Snap пакунку
Встановіть з пакунка snap на Ubuntu за допомогою наступної команди:
```sh
sudo snap install micro-xrce-dds-agent --edge
```
Запустити агента з налаштуваннями для підключення до клієнта uXRCE-DDS, запущеного у симуляторі (зверніть увагу, що назва команди відрізняється від назви, яку ви збираєте локально):
```sh
micro-xrce-dds-agent udp4 -p 8888
```
### Збірка/Запуск у межах робочого простору ROS 2
The agent can be built and launched within a ROS 2 workspace (or build standalone and launched from a workspace).
The agent can be built and launched within a ROS 2 workspace (or built standalone and launched from a workspace).
You must already have installed ROS 2 following the instructions in: [ROS 2 User Guide > Install ROS 2](../ros2/user_guide.md#install-ros-2).
:::warning
This approach will use the existing ROS 2 versions of the Agent dependencies, such as `fastcdr` and `fastdds`.
This considerably speeds up the build process but requires that the Agent dependency versions match the ROS 2 ones:
| ROS 2 version | Micro-XRCE-DDS-Agent version |
| ------------- | -------------------------------------- |
| Foxy | v2.4.2 |
| Humble | v2.4.2 |
| Jazzy | v2.4.3 |
:::
Створити агента в межах ROS:
1. Створіть директорію робочого простору для агента:
@@ -133,6 +144,28 @@ This considerably speeds up the build process but requires that the Agent depend
::::tabs
::: tab lyrical
```sh
cd ~/px4_ros_uxrce_dds_ws/src
git clone -b v3.0.1 https://github.com/eProsima/Micro-XRCE-DDS-Agent.git
```
Don't forget to set `UXRCE_DDS_CLIENT_USE_DDS_V3` before building PX4 when using DDS v3!
:::
::: tab kilted
```sh
cd ~/px4_ros_uxrce_dds_ws/src
git clone -b v2.4.3 https://github.com/eProsima/Micro-XRCE-DDS-Agent.git
```
:::
::: tab jazzy
```sh
@@ -169,6 +202,26 @@ This considerably speeds up the build process but requires that the Agent depend
:::: tabs
::: tab lyrical
```sh
source /opt/ros/lyrical/setup.bash
colcon build
```
:::
::: tab kilted
```sh
source /opt/ros/kilted/setup.bash
colcon build
```
:::
::: tab jazzy
```sh
@@ -201,51 +254,58 @@ This considerably speeds up the build process but requires that the Agent depend
::::
This builds all the folders under `/src` using the sourced toolchain.
This builds all the folders under `~/px4_ros_uxrce_dds_ws/src` using the sourced toolchain.
Для запуску агента micro XRCE-DDS в робочому просторі:
To run the Micro XRCE-DDS Agent in the workspace you just need to source the `local_setup.bash` to make the executables available in the terminal (also `setup.bash` if using a new terminal).
1. Source the `local_setup.bash` to make the executables available in the terminal (also `setup.bash` if using a new terminal).
:::: tabs
:::: tabs
::: tab jazzy
```sh
source /opt/ros/jazzy/setup.bash
source install/local_setup.bash
```
:::tab lyrical
```sh
source /opt/ros/lyrical/setup.bash
source install/local_setup.bash
```
:::
::: tab humble
```sh
source /opt/ros/humble/setup.bash
source install/local_setup.bash
```
:::tab kilted
```sh
source /opt/ros/kilted/setup.bash
source install/local_setup.bash
```
:::
::: tab foxy
```sh
source /opt/ros/foxy/setup.bash
source install/local_setup.bash
```
:::tab jazzy
```sh
source /opt/ros/jazzy/setup.bash
source install/local_setup.bash
```
:::
::::
:::tab humble
1) Запустіть агента з налаштуваннями для підключення до клієнта uXRCE-DDS, який працює на симуляторі:
```sh
source /opt/ros/humble/setup.bash
source install/local_setup.bash
```
```sh
MicroXRCEAgent udp4 -p 8888
```
:::
:::tab foxy
```sh
source /opt/ros/foxy/setup.bash
source install/local_setup.bash
```
:::
::::
## Запуск агента та клієнта
@@ -328,7 +388,7 @@ The configuration can be done using the [UXRCE-DDS parameters](../advanced_confi
Це забезпечує логічне розділення мереж DDS і може бути використано для розділення клієнтів на різні мережі.
За замовчуванням, ROS 2 працює з ID 0.
- [UXRCE_DDS_PTCFG](../advanced_config/parameter_reference.md#UXRCE_DDS_PTCFG): uXRCE-DDS participant configuration.
It allows to restrict the visibility of the DDS topics to the _localhost_ only and to use user-customized participant configuration files stored on the agent side.
It allows you to restrict the visibility of the DDS topics to the _localhost_ only and to use user-customized participant configuration files stored on the agent side.
- [UXRCE_DDS_SYNCT](../advanced_config/parameter_reference.md#UXRCE_DDS_SYNCT): Bridge time synchronization enable.
Клієнтський модуль uXRCE-DDS може синхронізувати мітку часу повідомлень, якими обмінюються через міст.
Це стандартна конфігурація. In certain situations, for example during [simulations](../ros2/user_guide.md#ros-gazebo-and-px4-time-synchronization), this feature may be disabled.
@@ -339,7 +399,7 @@ The configuration can be done using the [UXRCE-DDS parameters](../advanced_confi
To use hardware flow control, a custom MicroXRCE Agent needs to be adopted. Please refer to [this PR](https://github.com/eProsima/Micro-XRCE-DDS-Agent/pull/407) for the required changes, cherry-pick them on top of the [agent version](#build-run-within-ros-2-workspace) you need to use and then run the agent with the additional `--flow-control` option.
:::info
Many ports are already have a default configuration.
Many ports already have a default configuration.
Щоб використовувати ці порти, спочатку вимкніть існуючу конфігурацію:
- `TELEM1` and `TELEM2` are set up by default to connect via MAVLink to a GCS and a companion computer (respectively).
@@ -376,7 +436,7 @@ Environment variables are provided that override some [UXRCE-DDS parameters](../
- `ROS_DOMAIN_ID`: Use this to replace [UXRCE_DDS_DOM_ID](../advanced_config/parameter_reference.md#UXRCE_DDS_DOM_ID).
- `PX4_UXRCE_DDS_PORT`: Use this to replace [UXRCE_DDS_PRT](../advanced_config/parameter_reference.md#UXRCE_DDS_PRT).
For example, the following command can be used to start a Gazebo simulation with che client operating on the DDS domain `3`, port `9999` and topic namespace `drone`.
For example, the following command can be used to start a Gazebo simulation with the client operating on the DDS domain `3`, port `9999` and topic namespace `drone`.
```sh
ROS_DOMAIN_ID=3 PX4_UXRCE_DDS_PORT=9999 PX4_UXRCE_DDS_NS=drone make px4_sitl gz_x500
@@ -545,7 +605,7 @@ subscriptions_multi:
```
Each (`topic`,`type`) pairs defines:
Each (`topic`, `type`) pair defines:
1. A new `publication`, `subscription`, or `subscriptions_multi`, depending on the list to which it is added.
2. The topic _base name_, which **must** coincide with the desired uORB topic name that you want to publish/subscribe.
@@ -644,7 +704,7 @@ Take a look at the [client startup section](#starting-the-client) to learn how t
#### New file for setting which topics are published
The list of topics that are published and subscribed for a particular firmware is now managed by the [dds_topics.yaml](../middleware/dds_topics.md) configuration file, which replaces [urtps_bridge_topics.yaml](https://github.com/PX4/PX4-Autopilot/blob/release/1.13/msg/tools/urtps_bridge_topics.yaml)
The list of topics that are published and subscribed for a particular firmware is now managed by the [dds_topics.yaml](../middleware/dds_topics.md) configuration file, which replaces [urtps_bridge_topics.yaml](https://github.com/PX4/PX4-Autopilot/blob/release/1.13/msg/tools/urtps_bridge_topics.yaml).
See [Supported uORB Messages](#supported-uorb-messages) and [DDS Topics YAML](#dds-topics-yaml) sections for more information.
@@ -673,7 +733,7 @@ There are many ways to install it on your PC / companion computer - for more inf
#### Application-Specific Changes
If you where not using ROS 2 alongside the agent ([Fast DDS Interface ROS-Independent](https://docs.px4.io/v1.13/en/middleware/micrortps#agent-in-an-offboard-fast-dds-interface-ros-independent)), then you need to migrate to [eProsima Fast DDS](https://fast-dds.docs.eprosima.com/en/latest/index.html).
If you were not using ROS 2 alongside the agent ([Fast DDS Interface ROS-Independent](https://docs.px4.io/v1.13/en/middleware/micrortps#agent-in-an-offboard-fast-dds-interface-ros-independent)), then you need to migrate to [eProsima Fast DDS](https://fast-dds.docs.eprosima.com/en/latest/index.html).
ROS 2 applications still need to compile alongside the PX4 messages, which you do by adding the [px4_msgs](https://github.com/PX4/px4_msgs) package to your workspace.
You can remove the [px4_ros_com](https://github.com/PX4/px4_ros_com) package as it is no longer needed, other than for example code.
docs/uk/msg_docs/DifferentialPressure.md
+10 -8
View File
@@ -13,14 +13,15 @@ The information is published in the `SCALED_PRESSURE_n` MAVLink messages (along
## Fields
| Назва | Тип | Unit [Frame] | Range/Enum | Опис |
| ----------------------------------------------------------------------------------------------------------- | --------- | ---------------------------------------------------------------- | ---------- | ------------------------------------------------------------------------- |
| <a id="fld_timestamp"></a>timestamp | `uint64` | us | | Time of publication (since system start) |
| <a id="fld_timestamp_sample"></a>timestamp_sample | `uint64` | us | | Time of raw data capture |
| <a id="fld_device_id"></a>device_id | `uint32` | | | Unique device ID for the sensor that does not change between power cycles |
| <a id="fld_differential_pressure_pa"></a>differential_pressure_pa | `float32` | Pa | | Differential pressure reading (may be negative) |
| <a id="fld_temperature"></a>temperature | `float32` | degC | | Temperature (Invalid: NaN if unknown) |
| <a id="fld_error_count"></a>error_count | `uint32` | | | Number of errors detected by driver |
| Назва | Тип | Unit [Frame] | Range/Enum | Опис |
| ----------------------------------------------------------------------------------------------------------- | --------- | ---------------------------------------------------------------- | ---------- | ---------------------------------------------------------------------------------------------------------------- |
| <a id="fld_timestamp"></a>timestamp | `uint64` | us | | Time of publication (since system start) |
| <a id="fld_timestamp_sample"></a>timestamp_sample | `uint64` | us | | Time of raw data capture |
| <a id="fld_device_id"></a>device_id | `uint32` | | | Unique device ID for the sensor that does not change between power cycles |
| <a id="fld_differential_pressure_pa"></a>differential_pressure_pa | `float32` | Pa | | Differential pressure reading (may be negative) |
| <a id="fld_temperature"></a>temperature | `float32` | degC | | Temperature (Invalid: NaN if unknown) |
| <a id="fld_pitot_temperature"></a>pitot_temperature | `float32` | degC | | Pitot temperature (if available) (Invalid: NaN if unknown) |
| <a id="fld_error_count"></a>error_count | `uint32` | | | Number of errors detected by driver |
## Source Message
@@ -41,6 +42,7 @@ uint64 timestamp_sample # [us] Time of raw data capture
uint32 device_id # [-] Unique device ID for the sensor that does not change between power cycles
float32 differential_pressure_pa # [Pa] Differential pressure reading (may be negative)
float32 temperature # [degC] [@invalid NaN if unknown] Temperature
float32 pitot_temperature # [degC] [@invalid NaN if unknown] Pitot temperature (if available)
uint32 error_count # [-] Number of errors detected by driver
```
docs/uk/peripherals/dshot.md
+21 -1
View File
@@ -51,7 +51,7 @@ DShot comes with different speed options: _DShot150_, _DShot300_, and _DShot600_
## ESC Commands {#commands}
Commands can be sent to the ESC via the [MAVLink shell](../debug/mavlink_shell.md).
See [here](../modules/modules_driver.md#dshot) for a full reference of the supported commands.
See the [`dshot` module](../modules/modules_driver.md#dshot) for a full reference of the supported commands.
## ESC Telemetry
@@ -144,3 +144,23 @@ PX4 can read and write AM32 ESC firmware settings (EEPROM) via a ground station,
PX4 automatically reads the full EEPROM from each ESC on boot.
The ground station can then display individual settings and allow the user to modify them.
Changes are written back to the ESC one byte at a time using the DShot programming protocol.
<!-- Section below commented out until serial passthrough bridge productised: https://github.com/PX4/PX4-Autopilot/pull/27654#discussion_r3434404781 -->
<!--
## ESC Serial Passthrough
<Badge type="tip" text="PX4 v1.18" />
PX4 supports direct UART communication through an ESC signal pin using a software bit-bang UART.
This enables ESC configuration tools, such as _BLHeli Suite_ and the _AM32 configurator_, to communicate with the ESC using UART over MAVLink.
Note that a MAVLink-to-UART bridge is required on the ground station or companion computer side (you'll need to write your own).
::: warning
The `PASSTHRU_EN` parameter must be set to `1` (and the vehicle rebooted) before using ESC bitbang passthrough.
This **disables DShot and PWM output** at boot.
After the next reboot, `PASSTHRU_EN` automatically resets to `0`, thereby restoring normal DShot/PWM operation.
:::
See [Serial Passthrough (MAVLink SERIAL_CONTROL)](../uart/serial_passthrough.md) for full configuration details.
-->
docs/uk/releases/1.18.md
+20 -13
View File
@@ -44,21 +44,28 @@ Please continue reading for [upgrade instructions](#upgrade-guide).
### Загальні
- [Remote ID (Open Drone ID) in-flight failsafe](../peripherals/remote_id.md): extended [COM_ARM_ODID](../advanced_config/parameter_reference.md#COM_ARM_ODID) to also trigger a configurable failsafe action (Return, Land, or Terminate) if the Remote ID heartbeat is lost while airborne. Users previously on `COM_ARM_ODID=2` retain the same arming behaviour; set to `3` or higher to enable the in-flight action. ([PX4-Autopilot#27029](https://github.com/PX4/PX4-Autopilot/pull/27029))
- [QGroundControl Bootloader Update](../advanced_config/bootloader_update.md#qgc-bootloader-update-sys-bl-update) via the [SYS_BL_UPDATE](../advanced_config/parameter_reference.md#SYS_BL_UPDATE) parameter has been re-enabled after being broken for a number of releases. ([PX4-Autopilot#25032: build: romf: fix generation of rc.board_bootloader_upgrade](https://github.com/PX4/PX4-Autopilot/pull/25032)).
- [Feature: Allow prioritization of manual control inputs based on their instance number in ascending or descending order](../config/manual_control.md#px4-configuration). ([PX4-Autopilot#25602: Ascending and descending manual control input priorities](https://github.com/PX4/PX4-Autopilot/pull/25602)).
- Removed parameters:
| Назва | Примітки |
| ------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `COM_FLT_PROFILE` | Unused ([PX4-Autopilot#26735](https://github.com/PX4/PX4-Autopilot/pull/26735)) |
| `COM_KILL_DISARM` | Autopilot now always disarms if still killed after 5 sections (previous default). ([PX4-Autopilot#26736](https://github.com/PX4/PX4-Autopilot/pull/26736)) |
| `COM_MOT_TEST_EN` | Motor tests now always possible (was the default). ([PX4-Autopilot#26775](https://github.com/PX4/PX4-Autopilot/pull/26775)) |
| `COM_TAKEOFF_ACT` | Vehicle always switches to Hold mode when the takeoff is done. If you want to automatically do a mission, take off in Mission mode. ([PX4-Autopilot#26808](https://github.com/PX4/PX4-Autopilot/pull/26808)) |
| `COM_HLDL_REG_T` | When a high latency link is regained it's always considered regained immediately (was the default). ([PX4-Autopilot#26809](https://github.com/PX4/PX4-Autopilot/pull/26809)) |
| `COM_ARM_SDCARD` | There's now always warning when the autopilot SD card is missing (was the default). Boards that don't have an SD card need to skip the check with a compile time define. ([PX4-Autopilot#27259](https://github.com/PX4/PX4-Autopilot/pull/27259)) |
| `COM_IMB_PROP_ACT` | There's now always a warning when imbalanced propellers (high vibration) is detected (was the default). ([PX4-Autopilot#27260](https://github.com/PX4/PX4-Autopilot/pull/27260)) |
| `COM_OBC_LOSS_T` | Timeout for missing heartbeats from the onboard computer is always 5 seconds (was the default). ([PX4-Autopilot#27261](https://github.com/PX4/PX4-Autopilot/pull/27261)) |
| `COM_LKDOWN_TKO` | Takeoff failure detection always runs for 3 seconds (was the default). ([PX4-Autopilot#27262](https://github.com/PX4/PX4-Autopilot/pull/27262)) |
| Назва | Примітки |
| ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `COM_FLT_PROFILE` | Unused ([PX4-Autopilot#26735](https://github.com/PX4/PX4-Autopilot/pull/26735)) |
| `COM_KILL_DISARM` | Autopilot now always disarms if still killed after 5 seconds (previous default). ([PX4-Autopilot#26736](https://github.com/PX4/PX4-Autopilot/pull/26736)) |
| `COM_MOT_TEST_EN` | Motor tests now always possible (was the default). ([PX4-Autopilot#26775](https://github.com/PX4/PX4-Autopilot/pull/26775)) |
| `COM_TAKEOFF_ACT` | Vehicle always switches to Hold mode when the takeoff is done. If you want to automatically do a mission, take off in Mission mode. ([PX4-Autopilot#26808](https://github.com/PX4/PX4-Autopilot/pull/26808)) |
| `COM_HLDL_REG_T` | When a high latency link is regained it's always considered regained immediately (was the default). ([PX4-Autopilot#26809](https://github.com/PX4/PX4-Autopilot/pull/26809)) |
| `COM_ARM_SDCARD` | There's now always a warning when the autopilot SD card is missing (was the default). Boards that don't have an SD card need to skip the check with a compile time define. ([PX4-Autopilot#27259](https://github.com/PX4/PX4-Autopilot/pull/27259)) |
| `COM_IMB_PROP_ACT` | There's now always a warning when imbalanced propellers (high vibration) is detected (was the default). ([PX4-Autopilot#27260](https://github.com/PX4/PX4-Autopilot/pull/27260)) |
| `COM_OBC_LOSS_T` | Timeout for missing heartbeats from the onboard computer is always 5 seconds (was the default). ([PX4-Autopilot#27261](https://github.com/PX4/PX4-Autopilot/pull/27261)) |
| `COM_LKDOWN_TKO` | Takeoff failure detection always runs for 3 seconds (was the default). ([PX4-Autopilot#27262](https://github.com/PX4/PX4-Autopilot/pull/27262)) |
- [Serial Passthrough (MAVLink SERIAL_CONTROL)](../uart/serial_passthrough.md): new `serialpassthrough` driver enables MAVLink clients to read from and write to FC serial ports (TEL1/2, GPS1/2, TEL3/4).
On STM32F7/H7 boards, ESC signal pins can also be written via a software bit-bang UART (device IDs 20–27): note that a bridge application is also required, so this functionality is not usable out of the box.
([PX4-Autopilot#27605: feat(drivers): implemented serial passthrough](https://github.com/PX4/PX4-Autopilot/pull/27605)).
### Управління
@@ -108,9 +115,9 @@ Please continue reading for [upgrade instructions](#upgrade-guide).
- Уточнюється
### uXRCE-DDS / Zenoh / ROS2
### uXRCE-DDS / Zenoh / ROS 2
- Уточнюється
- uXRCE-DDS, add support for DDS `v3`, ROS 2 Lyrical and Rolling ([PX4-Autopilot#27597](https://github.com/PX4/PX4-Autopilot/pull/27597))
<!-- MOVED THIS TO v1.17
docs/uk/sensor/inertiallabs.md
+34 -7
View File
@@ -42,27 +42,52 @@ You can set offsets for coordinate axes in the sensor-configuration software tha
To use the Inertial Labs driver:
1. Build the firmware with the [ilabs](../modules/modules_driver_ins.md#ilabs) module.
- Make sure the UART RX-buffer for the serial port connected to the INS is at least **600 bytes**.
The module is included by default for many boards.
You can check by searching for the keys `CONFIG_COMMON_INS` (all INS drivers) and `CONFIG_DRIVERS_INS_ILABS` (ilabs driver) in the [default.px4board](https://github.com/PX4/PX4-Autopilot/blob/main/boards/px4/fmu-v6c/default.px4board#L25) configuration file for your target board.
::: tip
For example, when using `TELEM2` on Pixhawk 6X, add the following setting to [defconfig](https://github.com/PX4/PX4-Autopilot/blob/main/boards/px4/fmu-v6x/nuttx-config/nsh/defconfig):
`CONFIG_UART5_RXBUFSIZE=600`
If it is not present, you can add the key to your `default.px4board` file, or include it using the [kconfig board configuration](../hardware/porting_guide_config.md#px4-board-configuration-kconfig): Drivers -> INS -> ilabs.
Note that the mapping between UART number and port name can usually be found in your board's [Serial Port Mapping](../flight_controller/pixhawk6x.md#serial-port-mapping) section.
:::
- Include the module in firmware in the [kconfig board configuration](../hardware/porting_guide_config.md#px4-board-configuration-kconfig) by setting the kconfig variables: `CONFIG_DRIVERS_INS_ILABS`.
In the kconfig interface: Drivers -> INS -> ilabs.
2. [Set the parameter](../advanced_config/parameters.md) [SENS_ILABS_CFG](../advanced_config/parameter_reference.md#SENS_ILABS_CFG) to the hardware port connected to the sensor, such as a spare `GPS` or `TELEM`.
Make sure that nothing else is configured to use the port (for more information see [Serial Port Configuration](../peripherals/serial_configuration.md)).
3. Перезавантажте PX4.
::: warning
Disable or change port of other sensors that are using the same one, for example [GPS_1_CONFIG](../advanced_config/parameter_reference.md#GPS_1_CONFIG) if using GPS1 port.
4. Налаштуйте водія як зовнішній INS або надайте сирові дані:
:::
3. Allow the Inerital Labs driver to initialize by restarting PX4.
4. Configure driver to provide IMU data or Raw sensors data :
- For external INS, set [ILABS_MODE](../advanced_config/parameter_reference.md#ILABS_MODE) to `INS`.
In this case, the [EKF2_EN](../advanced_config/parameter_reference.md#EKF2_EN), [SENS_IMU_MODE](../advanced_config/parameter_reference.md#SENS_IMU_MODE), and [SENS_MAG_MODE](../advanced_config/parameter_reference.md#SENS_MAG_MODE) parameters are disabled at startup (set to `0`). Аnd the INS's internal EKF is used for orientation.
- For raw inertial sensors, set [ILABS_MODE](../advanced_config/parameter_reference.md#ILABS_MODE) to `Sensors Only`.
You can then prioritize inertial labs sensors using [CAL_GYROn_PRIO](../advanced_config/parameter_reference.md#CAL_GYRO0_PRIO), [CAL_ACCn_PRIO](../advanced_config/parameter_reference.md#CAL_ACC0_PRIO), [CAL_BAROn_PRIO](../advanced_config/parameter_reference.md#CAL_BARO0_PRIO), [CAL_MAGn_PRIO](../advanced_config/parameter_reference.md#CAL_MAG0_PRIO), where `n` is the instance number of the IMU component (0, 1, etc.).
Prioritize Inertial Labs sensors using [CAL_GYROn_PRIO](../advanced_config/parameter_reference.md#CAL_GYRO0_PRIO), [CAL_ACCn_PRIO](../advanced_config/parameter_reference.md#CAL_ACC0_PRIO), [CAL_BAROn_PRIO](../advanced_config/parameter_reference.md#CAL_BARO0_PRIO), [CAL_MAGn_PRIO](../advanced_config/parameter_reference.md#CAL_MAG0_PRIO), where `n` is the instance number of the IMU component (0, 1, etc.).
::: tip
In most cases the external IMU is the highest-numbered.
Ви можете отримати список доступних компонентів IMU, використовуючи [`uorb top -1`](../middleware/uorb.md#uorb-top-command), ви можете відрізняти їх за допомогою команди [`listener`](../modules/modules_command.md#listener) та розглядаючи дані чи просто швидкості.
За потреби ви можете перевірити [CAL_GYROn_ID](../advanced_config/parameter_reference.md#CAL_GYRO0_ID), щоб побачити ідентифікатор пристрою.
Пріоритет становить 0-255, де 0 абсолютно вимкнено, а 255 - найвищий пріоритет.
:::
::: warning
When configuring both Inertial Labs and Pixhawk sensors to have non-zero priority, if the selected sensor is errored (timeout), it can change during operation without being notified.
In this case, MAVLink messages will be updated with the newly selected sensor.
If you don't want to have this fallback mechanism, you must disable unwanted sensors.
:::
5. Перезавантажте PX4.
@@ -90,6 +115,8 @@ If enabled as an external INS, publishes:
- [vehicle_local_position](../msg_docs/VehicleLocalPosition.md)
- [vehicle_global_positon](../msg_docs/VehicleGlobalPosition.md)
- [vehicle_attitude](../msg_docs/VehicleAttitude.md)
- [estimator_status](../msg_docs/EstimatorStatus.md)
- [estimator_status_flags](../msg_docs/EstimatorStatusFlags.md)
If enabled as external sensor only:
docs/uk/sim_rotorpy/index.md
+96
View File
@@ -0,0 +1,96 @@
# RotorPy Simulation
:::warning
This simulator is [community supported and maintained](../simulation/community_supported_simulators.md).
Це може працювати або не працювати з поточними версіями PX4.
Дивіться [Встановлення інструментарію](../dev_setup/dev_env.md) для інформації про середовища та інструменти, що підтримуються основною командою розробників.
:::
RotorPy is a Python-based multirotor simulation environment with [aerodynamic wrenches](https://arxiv.org/abs/2306.04485), useful for education and research in estimation, planning, and control for UAVs.
It provides stand-alone classes and a [Gymnasium environment](https://gymnasium.farama.org/).
<lite-youtube videoid="L8-QZgc6Vwk" title="Demo of PX4 with RotorPy simulator"/>
## Why Use RotorPy?
RotorPy simulates the aerodynamic forces and moments acting on a multirotor, along with actuator limits, sensor noise, wind, and obstacles.
This makes it useful when you want to test estimation, planning, or control algorithms against more realistic vehicle dynamics than a simple point-mass or kinematic simulation.
The Gymnasium interface is useful for reinforcement learning and other Python-based research workflows.
It lets you connect policies and learning pipelines to a PX4-controlled multirotor simulation without rewriting them around PX4-specific APIs.
## Встановлення
RotorPy can be installed using `pip`:
```sh
pip install rotorpy[px4]
```
To install other tagged versions, see [`pyproject.toml`](https://github.com/spencerfolk/rotorpy/blob/main/pyproject.toml).
## Запуск симуляції
This example will allow you to control the quadrotor through QGroundControl.
:::tip
If instead you want RotorPy to take control of the drone you can pass the `autopilot_controller=False` argument to the `PX4Multirotor` constructor when instantiating it.
This can be useful to test perception pipelines, since the environment is controlled through RotorPy's own controllers.
:::
First you need to build the SITL binary by setting up the toolchain and running:
```sh
make px4_sitl
```
Then run the PX4 SITL binary with the command:
```sh
PX4SIMULATOR=rotorpy PX4_SYS_AUTOSTART=10040 ./build/px4_sitl_default/bin/px4
```
Start the `example/px4_basic_example.py`, available [here](https://github.com/spencerfolk/rotorpy/blob/main/examples/basic_usage_px4.py) and referenced in the code below:
```python
# test_px4_sitl.py
from rotorpy.environments import Environment
from rotorpy.trajectories.circular_traj import ThreeDCircularTraj
from rotorpy.vehicles.px4_multirotor import PX4Multirotor
from rotorpy.vehicles.px4_sihsim_quadx_params import quad_params as sihsim_quadx
from rotorpy.controllers.quadrotor_control import SE3Control
from rotorpy.trajectories.hover_traj import HoverTraj
import numpy as np
circular_trajectory = ThreeDCircularTraj(radius=np.array([1,1,0]))
hover_trajectory = HoverTraj(x0=np.array([0, 0, 5]))
def main():
vehicle = PX4Multirotor(sihsim_quadx, enable_ground=True)
controller = SE3Control(sihsim_quadx)
env = Environment(
vehicle = vehicle,
controller = controller,
trajectory = circular_trajectory,
sim_rate = 100,
)
results = env.run(
t_final = 60,
use_mocap=False,
plot_mocap=False,
plot_estimator=False,
plot_imu=False,
plot = True,
animate_bool = False,
verbose = True,
)
print("Done—PX4 SITL ran for", len(results["time"]), "steps")
if __name__ == '__main__':
main()
```
docs/uk/simulation/community_supported_simulators.md
+1
View File
@@ -18,6 +18,7 @@ These simulators are not maintained, tested, or supported, by the core developme
| [JMAVSim](../sim_jmavsim/index.md) | <p>A simple multirotor/quad simulator. This was previously part of the PX4 development toolchain but was removed in favour of [Gazebo](../sim_gazebo_gz/index.md).</p> <p><strong>Supported Vehicles:</strong> Quad</p> |
| [JSBSim](../sim_jsbsim/README.md) | <p>Симулятор, який надає моделі просунутої динаміки польоту. Він може використовуватися для моделювання реалістичної динаміки польоту, заснованої на даних з аеродинамічної труби.</p> <p><strong>Рухомі засоби, що підтримуються:</strong> Літак, Квадрокоптер, Гексакоптер</p> |
| [AirSim](../sim_airsim/README.md) | <p>Міжплатформовий симулятор який надає фізично та візуально реалістичні симуляції. This simulator is resource intensive, and requires a significantly more powerful computer than the other simulators described here.</p><p><strong>Supported Vehicles:</strong> Iris (MultiRotor model and a configuration for PX4 QuadRotor in the X configuration).</p> |
| [RotorPy](../sim_rotorpy/index.md) | <p>A Python-based multirotor simulation environment with aerodynamic forces and moments, actuator limits, sensor noise, wind, obstacles, and a Gymnasium interface for research workflows.</p><p><strong>Supported Vehicles:</strong> Quad</p> |
:::tip
[Gazebo](../sim_gazebo_gz/index.md) and [SIH](../sim_sih/index.md) are the officially supported simulators. See the [Simulation](index.md) page for more information.
docs/uk/uart/index.md
+1
View File
@@ -3,3 +3,4 @@
У цьому розділі містяться теми про послідовну шину і драйвери послідовної шини:
- [Making Serial Port Drivers User-Configurable](../uart/user_configurable_serial_driver.md)
- [Serial Passthrough (MAVLink SERIAL_CONTROL)](../uart/serial_passthrough.md)
docs/uk/uart/serial_passthrough.md
+121
View File
@@ -0,0 +1,121 @@
# Serial Passthrough (MAVLink SERIAL_CONTROL)
<Badge type="tip" text="PX4 v1.18" />
Serial Passthrough allows a MAVLink client to read from and write to selected flight controller serial interfaces using the [SERIAL_CONTROL](https://mavlink.io/en/messages/common.html#SERIAL_CONTROL) message.
Typical use cases include: providing a direct serial channel for ESC configuration tools, and debugging serial peripherals over a telemetry link.
Two cases are supported:
- Control of normal ports, such as telemetry or GPS ports.
This works automatically as long as the [`serialpassthrough` driver](../modules/modules_driver.md#serialpassthrough) is present in firmware.
- Control of ESC signal pins on STM32F7/H7 boards via a bit-bang UART implemented in software.
This requires additional configuration.
When serial control is enabled/supported, passthrough is automatic.
If `SERIAL_CONTROL` traffic is sent to a supported target, PX4 starts handling that target and returns reply data over MAVLink.
You can also start and stop passthrough manually from the PX4 shell.
## Ідентифікатори пристрою(ID)
The `SERIAL_CONTROL.device` field selects the target UART that is to be controlled.
The following device IDs are allowed (note that this is a subset of the IDs specified in [SERIAL_CONTROL_DEV](https://mavlink.io/en/messages/common.html#SERIAL_CONTROL_DEV)):
| Device ID | Цільова платформа |
| --------- | ------------------------------------------------------ |
| `0` | TEL1 |
| `1` | TEL2 |
| `2` | GPS1 |
| `3` | GPS2 |
| `4` | TEL3 |
| `5` | TEL4 |
| `20` | ESC channel 0 ([bitbang](#bitbang)) |
| `21` | ESC channel 1 (bitbang) |
| `22` | ESC channel 2 (bitbang) |
| `23` | ESC channel 3 (bitbang) |
| `24` | ESC channel 4 (bitbang) |
| `25` | ESC channel 5 (bitbang) |
| `26` | ESC channel 6 (bitbang) |
| `27` | ESC channel 7 (bitbang) |
The UART device path for each port (e.g. `/dev/ttyS1`) is taken from the board's corresponding Kconfig symbols, such as `CONFIG_BOARD_SERIAL_TEL1`, `CONFIG_BOARD_SERIAL_GPS1`, and so on.
If the used device ID is not configured on the board, the driver logs a warning and rejects the message.
## UART Control
Normal UARTs such as those for telemetry and GPS are targeted using device IDs 0 to 5.
This feature requires only that the [`serialpassthrough` driver](../modules/modules_driver.md#serialpassthrough) is present in firmware (the KConfig key `CONFIG_DRIVERS_SERIALPASSTHROUGH=y` must be set).
Note that the `PASSTHRU_EN` parameter need not be set.
## ESC Channel Mode (Bitbang UART) {#bitbang}
:::tip
This feature is not yet useful because PX4 does not ship a ready-made tool for using serial passthrough with common ESC configuration or firmware flashing tools.
Information on how such a tool might be developed is given below in [Bridge Application](#bridge-application).
:::
Device IDs 20–27 route through a software bit-bang UART on the ESC signal pin rather than a hardware UART.
This is useful for communicating with ESCs that expose a UART telemetry or configuration port on their signal wire (such as BLHeli_32 passthrough, AM32, or ESC configuration tools).
Bitbang UART is implemented using a hardware timer and direct GPIO toggling.
Due to interrupt latency, reliable operation is only guaranteed up to **19200 baud**.
Because only one hardware timer is used, only one ESC channel can be active at a time.
When a request arrives for a different ESC channel, the driver stops the current instance and waits up to 100 ms for it to exit before starting the new one.
Bitbang UART support requires that both `CONFIG_DRIVERS_SERIALPASSTHROUGH=y` and `CONFIG_SERIALPASSTHROUGH_BITBANG=y` are set before building (the timer is selected with `CONFIG_UART_BITBANG_TIMER`, and defaults to `TIM13`).
The `PASSTHRU_EN` parameter must be set to `1` and the device rebooted in order to enable this mode.
### Bridge Application
Developers can create their own bridge application if needed.
This would connect to the vehicle over MAVLink, expose a virtual serial port (e.g. a Unix PTY) to the tool on the host, and translate traffic bidirectionally.
Data written to the PTY would be sent as `SERIAL_CONTROL` messages with `SERIAL_CONTROL_FLAG_RESPOND | SERIAL_CONTROL_FLAG_EXCLUSIVE` set, and incoming `SERIAL_CONTROL` reply messages (with `FLAG_REPLY` set) would be written back to the PTY.
To initialise the passthrough, the bridge should send one `SERIAL_CONTROL` message with the target device ID, the desired UART baud rate in the `baudrate` field, and `count=0` (no payload), then wait approximately 2 seconds for PX4 to spawn the passthrough task before sending real traffic.
For ESC bitbang mode (device IDs 20–27), the bridge must first set `PASSTHRU_EN=1` via `PARAM_SET`, confirm the `PARAM_VALUE` acknowledgement, send `MAV_CMD_PREFLIGHT_REBOOT_SHUTDOWN`, and wait for the FMU heartbeat to return before sending the init message — this ensures the DShot/PWM drivers are not running when the bitbang driver takes over the ESC signal pins.
## Налаштування
### Firmware Configuration (Build-Time)
The driver is enabled via [Kconfig](../hardware/porting_guide_config.md).
You will need to set the following key in your board:
```text
CONFIG_DRIVERS_SERIALPASSTHROUGH=y # Include the driver
```
If you want to use ESC channel targets you must also set the following keys:
```text
CONFIG_SERIALPASSTHROUGH_BITBANG=y # ESC channel support (NuttX & STM32 only)
CONFIG_UART_BITBANG_TIMER=13 # Timer instance (default TIM13)
```
Then rebuild the firmware.
### PX4 Configuration (ESC targets)
For ESC channel targets (only) you must also set [PASSTHRU_EN](../advanced_config/parameter_reference.md#PASSTHRU_EN) to `1` and reboot the vehicle.
This disables motor control after the reboot (the motor output drivers `dshot` and `pwm_out` are not started).
This is required when you intend to use the ESC bitbang passthrough mode, because the bitbang driver and the DShot/PWM driver cannot share the same ESC signal pins.
:::tip
The parameter auto-resets to `0` on the following reboot, so DShot/PWM output is automatically restored after power cycling.
:::
## Обмеження
- **Single sender:** only one MAVLink sender is supported at a time.
A single sender can communicate with multiple ports simultaneously, but replies are always routed back to the MAVLink channel that sent the most recent `SERIAL_CONTROL` message.
This means that concurrent senders could interfere with each other's replies.
- **ESC bitbang baud rate:** maximum reliable baud rate is 19200.
Higher rates may work but are not guaranteed.
- **ESC channel exclusivity:** only one ESC bitbang channel can be active at a time.
- **Platform:** bitbang UART is only available on NuttX with STM32F7/H7.
Requesting ESC bitbang on an unsupported platform logs an error.
- **Buffer size:** each instance has a 1 kB receive and 1 kB transmit buffer.
Frames larger than 1 kB will be truncated with a warning logged.