fly316/PX4-Autopilot
7
0
Fork 0
mirror of https://gitee.com/mirrors_PX4/PX4-Autopilot.git synced 2026-10-22 22:23:33 +08:00
Code Issues 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
co-authored by Ramon Roche
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/uk/advanced/community_supported_dev_env.md
+23
View File
@@ -0,0 +1,23 @@
# Інструменти розробника, що підтримуються спільнотою
Ця секція містить інформацію про _підтримувані спільнотою_ середовища розробки, IDE, симулятори та інші інструменти.
:::warning
Ці налаштування не обслуговуються, не тестуються або не підтримуються основною командою розробників.
Вони можуть працювати або не працювати з поточними версіями PX4.
Дивіться [Встановлення інструментарію](../dev_setup/dev_env.md) для інформації про середовища та інструменти, що підтримуються основною командою розробників.
:::
Інструменти мають різний рівень підтримки своїми спільнотами (деякі добре підтримують, інші - ні).
Питання про ці інструменти повинні порушуватися на [форумах для обговорення](../contribute/support.md#forums-and-chat)
- Платформи/налаштування розробки
- [CentOS Linux](../dev_setup/dev_env_linux_centos.md)
- [Arch Linux](../dev_setup/dev_env_linux_arch.md)
- [Windows VM Toolchain](../dev_setup/dev_env_windows_vm.md) — встановлення Ubuntu на віртуальній машині Windows.
- [Windows Cygwin Toolchain](../dev_setup/dev_env_windows_cygwin.md) — налаштування Windows працює тільки для PX4 v1.12
- [Технічне обслуговування Windows Cygwin Toolchain](../dev_setup/dev_env_windows_cygwin_packager_setup.md)
- IDEs
- [Qt Creator IDE](../dev_setup/qtcreator.md)
- [Симулятори](../simulation/community_supported_simulators.md) — [Simulation-In-Hardware](../sim_sih/index.md), [FlightGear](../sim_flightgear/index.md), [JSBSim](../sim_jsbsim/index.md), [AirSim](../sim_airsim/index.md), [HITL](../simulation/hitl.md)
docs/uk/advanced/computer_vision.md
+87
View File
@@ -0,0 +1,87 @@
# Комп'ютерний зір (оптичний потік, MoCap, VIO, уникання)
Техніки [комп'ютерного зору](https://en.wikipedia.org/wiki/Computer_vision) дозволяють комп'ютерам використовувати візуальні дані для розуміння їх оточення.
PX4 використовує системи комп'ютерного зору (переважно запущені на [супутніх комп'ютерах](../companion_computer/README.md)) для підтримки наступних функцій:
- [Оптичний потік](#optical-flow) забезпечує оцінку швидкості у двох вимірах (з використанням камери, спрямованої вниз, та датчика відстані, спрямованого вниз).
- [Захоплення руху](#motion-capture) забезпечує оцінку позиції у трьох вимірах за допомогою візійної системи, яка знаходиться _поза_ транспортним засобом. Це переважно використовується для внутрішньої навігації.
Це переважно використовується для внутрішньої навігації.
- [Візуальна інерціальна оцінка положення](#visual-inertial-odometry-vio) забезпечує оцінку позиції та швидкості у трьох вимірах за допомогою вбудованої візійної системи та ІВП.
Це використовується для навігації в тих випадках, коли інформація про позицію GNSS відсутня або ненадійна.
- [Уникнення зіткнення](../computer_vision/collision_prevention.md) використовується для зупинки транспортних засобів перед тим, як вони зіткнуться з перешкодою (переважно при польоті у ручних режимах).
:::tip
[Набір для розвитку автономності візійної системи PX4](../complete_vehicles_mc/px4_vision_kit.md) (від Holybro) - це надійний та доступний набір для розробників, які працюють з комп'ютерним зором на PX4.
:::
## Захоплення руху
Motion Capture (MoCap) is a technique for estimating the 3D _pose_ (position and orientation) of a vehicle using a positioning mechanism that is _external_ to the vehicle.
Системи захоплення руху найчастіше виявляють рух за допомогою інфрачервоних камер, але також можуть використовуватися інші типи камер, лідар або ультраширокосмуговий радіорухометр (УШР).
:::info
MoCap is commonly used to navigate a vehicle in situations where GPS is absent (e.g. indoors), and provides position relative to a _local_ coordinate system.
:::
Для отримання інформації про MoCap, перегляньте:
- [Оцінка зовнішньої позиції ](../ros/external_position_estimation.md)
- [Літання з використанням захоплення руху (VICON, NOKOV, Optitrack) ](../tutorials/motion-capture.md)
- [Using PX4's Navigation Filter (EKF2) > External Vision System](../advanced_config/tuning_the_ecl_ekf.md#external-vision-system)
## Візуальна інерціальна оцінка положення (VIO)
Візуальна інерціальна оцінка положення (VIO) використовується для оцінки тривимірного _положення_ (позиції та орієнтації) та _швидкості_ руху транспортного засобу відносно _місцевої_ початкової позиції.
Часто використовується для навігації транспортного засобу в ситуаціях, де GPS відсутній (наприклад, всередині приміщень) або ненадійний (наприклад, при польоті під мостом).
Часто використовується для навігації транспортного засобу в ситуаціях, де GPS відсутній (наприклад, всередині приміщень) або ненадійний (наприклад, при польоті під мостом).
:::info
Однією з відмінностей між VIO і [MoCap](#motion-capture) є те, що камери/ІНС VIO базуються на транспортному засобі, і додатково надають інформацію про швидкість.
:::
Для отримання інформації щодо налаштування VIO на PX4 дивіться:
- [Using PX4's Navigation Filter (EKF2) > External Vision System](../advanced_config/tuning_the_ecl_ekf.md#external-vision-system)
- [Керівництво з налаштування T265](../peripherals/camera_t265_vio.md)
## Оптичний потік(Optical Flow)
[Оптичний потік](../sensor/optical_flow.md) забезпечує оцінку швидкості у двох вимірах (з використанням камери, спрямованої вниз, та датчика відстані, спрямованого вниз).
[Оптичний потік](../sensor/optical_flow.md) забезпечує оцінку швидкості у двох вимірах (з використанням камери, спрямованої вниз, та датчика відстані, спрямованого вниз).
- [Оптичний потік](../sensor/optical_flow.md)
- [Using PX4's Navigation Filter (EKF2) > Optical Flow](../advanced_config/tuning_the_ecl_ekf.md#optical-flow)
## Порівняння
### Порівняння
Обидва методи використовують камери і вимірюють різницю між кадрами.Оптичний потік використовує камеру, спрямовану вниз, тоді як VIO використовує стереокамеру або камеру з відстеженням під кутом 45 градусів.Припускаючи, що обидва методи добре калібруються, який з них краще для оцінки локального положення?
Обидва методи використовують камери і вимірюють різницю між кадрами.Оптичний потік використовує камеру, спрямовану вниз, тоді як VIO використовує стереокамеру або камеру з відстеженням під кутом 45 градусів.Припускаючи, що обидва методи добре калібруються, який з них краще для оцінки локального положення?
Консенсусом [здається](https://discuss.px4.io/t/vio-vs-optical-flow/34680):
- Оптичний потік, спрямований вниз, надає вам планарну швидкість, яка коригується на кутову швидкість за допомогою гіроскопа.
- Вимагає точної відстані до землі і передбачає планарну поверхню.Враховуючи ці умови, це може бути настільки ж точним / надійним, як VIO (для польотів у приміщенні)
- Має більшу надійність, оскільки має менше станів, ніж VIO.
- Значно дешевший і легший у налаштуванні оскільки для цього потрібен лише датчик оптичного потоку, дальномір та налаштування кількох параметрів (які можна підключити до керуючого пристрою польоту).
VIO:
- Дорожче придбати і складніше налаштувати.Потребує окремий супутній комп'ютер, калібрування, програмне забезпечення, конфігурацію та інше.
- Буде менш ефективним, якщо відсутні точкові особливості для відстеження (на практиці реальний світ зазвичай має точкові особливості).
- Більш гнучкий і дозволяє додаткові функції, такі як уникання перешкод і картографування.
Комбінація (об'єднання обох) ймовірно найбільш надійна, хоча не обов'язкова в більшості реальних сценаріїв.Зазвичай ви оберете систему, яка відповідає вашому робочому середовищу, потрібним функціям та обмеженням вартості:
- Використовуйте VIO якщо ви плануєте летіти на відкритому повітрі без GPS (або на відкритому повітрі) або якщо вам потрібно підтримати уникання перешкоди та інші функції зору комп'ютера.
- Використовувати оптичний потік, якщо ви плануєте лише літати в приміщенні (без GPS) і вартість є важливою.
## Додаткові ресурси
- [XTDrone](https://github.com/robin-shaun/XTDrone/blob/master/README.en.md) - ROS + PX4 середовище симуляцій для комп'ютерного бачення.
The [XTDrone Manual](https://www.yuque.com/xtdrone/manual_en) has everything you need to get started!
docs/uk/advanced/gimbal_control.md
+187
View File
@@ -0,0 +1,187 @@
# Конфігурація Gimbal(стабілізатора)
Ця сторінка пояснює, як налаштувати та контролювати стабілізатор, що має приєднану камеру (або будь-який інший вантаж).
## Загальний огляд
PX4 містить універсальний драйвер керування кріпленням/гімбалем, який підтримує різні методи введення та виведення:
- Метод введення визначає протокол, який використовується для керування gimbal mount який керується PX4.
Це може бути контролер RC, команда MAVLink, надіслана GCS, або обидва — автоматичне перемикання між ними.
- Метод виведення визначає, як PX4 взаємодіє з підключеним гімбалем.
Рекомендований протокол — MAVLink v2, але ви також можете підключитися безпосередньо до виходного порту шим контролера польоту.
PX4 приймає вхідний сигнал і маршрутизує/перекладає його для відправлення на вивід.
Будь-який метод введення може бути обраний для керування будь-яким виводом.
Як вхід, так і вихід налаштовуються за допомогою параметрів.
Вхід встановлюється за допомогою параметра [MNT_MODE_IN](../advanced_config/parameter_reference.md#MNT_MODE_IN).
За замовчуванням це встановлено як `Вимкнено (-1)`, і драйвер не запускається.
Після вибору режиму введення перезавантажте транспортний засіб, щоб запустити драйвер кріплення.
Ви повинні встановити `MNT_MODE_IN` одним із наступних: `RC (1)`, `Протокол гімбала MAVLink v2 (4)` або `Авто (0)` (інші варіанти застарілі).
Якщо ви виберете `Авто (0)`, гімбал автоматично вибере вхід RC або MAVLink відповідно до останнього введення.
Зверніть увагу, що для автоматичного перемикання з MAVLink на RC потрібен великий рух ручкою!
Вихід налаштовується за допомогою параметра [MNT_MODE_OUT](../advanced_config/parameter_reference.md#MNT_MODE_OUT).
Усталеним налаштування виходу PXM є (`AUX (0)`).
Якщо ваш гімбал підтримує [Протокол гімбала MAVLink v2](https://mavlink.io/en/services/gimbal_v2.html), ви повинні замість цього вибрати `Протокол гімбала MAVLink v2 (2)`.
Повний список параметрів для налаштування драйвера кріплення можна знайти в [Довідці параметрів > Кріплення](../advanced_config/parameter_reference.md#mount).
Нижче наведено відповідні налаштування для декількох поширених конфігурацій гімбалів.
## MAVLink Gimbal (MNT_MODE_OUT=MAVLINK)
Кожен фізичний пристрій гімбала в системі повинен мати свій власний високорівневий менеджер гімбала, який може бути виявлений наземною станцією за допомогою протоколу MAVLink для гімбалів.
Наземна станція надсилає високорівневі команди [MAVLink Gimbal Manager](https://mavlink.io/en/services/gimbal_v2.html#gimbal-manager-messages) менеджеру гімбала, який вона хоче керувати, а менеджер, в свою чергу, надсилає відповідні команди нижчого рівня "пристрою гімбала", щоб керувати гімбалом.
PX4 може бути налаштований як менеджер гімбала для керування одним пристроєм гімбала (which can either be physically connected or be a MAVLink gimbal that implements the [gimbal device interface](https://mavlink.io/en/services/gimbal_v2.html#gimbal-device-messages)).
Щоб увімкнути гімбал по протоколу MAVLink, спочатку встановіть параметр [MNT_MODE_IN](../advanced_config/parameter_reference.md#MNT_MODE_IN) на `Протокол гімбала MAVLink v2` і [MNT_MODE_OUT](../advanced_config/parameter_reference.md#MNT_MODE_OUT) на `Протокол гімбала MAVLink v2`..
Гімбал можна підключити до _будь-якого вільного послідовного порту_, використовуючи інструкції у розділі [Послідовні пристрої MAVLink (GCS/OSD/Компаньйон)](../peripherals/mavlink_peripherals.md) (див. також [Конфігурація послідовного порту](../peripherals/serial_configuration.md#serial-port-configuration)).
Наприклад, якщо порт `TELEM2` на контролері польоту не використовується, ви можете підключити його до гімбала і встановити наступні параметри PX4:
- [MAV_1_CONFIG](../advanced_config/parameter_reference.md#MAV_1_CONFIG) на **TELEM2** (якщо `MAV_1_CONFIG` вже використовується для компаньйонного комп'ютера (скажімо), використовуйте `MAV_2_CONFIG`).
- [MAV_1_MODE](../advanced_config/parameter_reference.md#MAV_1_MODE) до **NORMAL**
- [SER_TEL2_BAUD](../advanced_config/parameter_reference.md#SER_TEL2_BAUD) на рекомендовану виробником швидкість передачі даних.
### Підтримка декількох Gimbal
PX4 може автоматично створити менеджер гімбала для підключеного гімбала з PWM або першого пристрою гімбала MAVLink з тим самим ідентифікатором системи, який виявляється на будь-якому інтерфейсі.
Він не автоматично створює менеджер гімбала для будь-яких інших пристроїв гімбала MAVLink, які виявляються.
You can support additional MAVLink gimbals provided that they:
- Implement the gimbal _manager_ protocol.
- Становлять видимими для наземної станції та PX4 у мережі MAVLink.
Це може вимагати налаштування пересилання трафіку між PX4, НЗП та гімбалем.
- Have a unique component id, and this component id must be in the range 7 - 255.
## Gimbal з FC PWM Output (MNT_MODE_OUT=AUX)
Gimbal також можна контролювати шляхом підключення до трьох портів польоту контролера польоту і налаштування режиму виводу в `MNT_MODE_OUT=AUX`.
Вихідні піни, які використовуються для керування гімбалем, встановлюються в [Конфігурація приводів > Виведення](../config/actuators.md#actuator-outputs), вибравши будь-які три невикористані виводи приводів та призначивши їм наступні функції виводу:
- `Gimbal Roll`: вихід керує поворотом gimbal.
- `Gimbal pitch`: вихід контролює крок підвісу.
- `Gimbal Yaw`: Output controls Gimbal yaw.
Наприклад, у вас можуть бути наступні налаштування для призначення кочення, тангажу та рида гімбала на виведення AUX1-3.
![Gimbal Actuator config](../../assets/config/actuators/qgc_actuators_gimbal.png)
PWM значення для використання при відблокованому, максимальному та мінімальному значеннях можна визначити так само, як і для інших сервоприводів, використовуючи [повзунки тесту приводу](../config/actuators.md#actuator-testing), щоб підтвердити, що кожний повзунок переміщує відповідну вісь, і змінюючи значення так, щоб гімбал знаходився у відповідному положенні при відблокованому стані, низькому і високому положенні повзунка.
Значення також можуть бути наведені у документації гімбала.
## Gimbal Control in Missions
[Gimbal Manager commands](https://mavlink.io/en/services/gimbal_v2.html#gimbal-manager-messages) may be used in missions if supported by the vehicle type.
For example [MAV_CMD_DO_GIMBAL_MANAGER_PITCHYAW](https://mavlink.io/en/messages/common.html#MAV_CMD_DO_GIMBAL_MANAGER_PITCHYAW) is supported in [multicopter mission mode](../flight_modes_mc/mission.md).
In theory you can address commands to a particular gimbal, specifying its component id using the "Gimbal device id" parameter.
However at time of writing (December 2024) this is [not supported](https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/gimbal/input_mavlink.cpp#L889): all mission commands are sent to the (only) gimbal managed by the PX4 gimbal manager (if this is a MAVLink gimbal, it will be the gimbal with component id defined in the parameter [MNT_MAV_COMPID](../advanced_config/parameter_reference.md#MNT_MAV_COMPID), which is set by default to [MAV_COMP_ID_GIMBAL (154)](https://mavlink.io/en/messages/common.html#MAV_COMP_ID_GIMBAL)).
Gimbal movement is not immediate.
To ensure that the gimbal has time to move into position before the mission progresses to the next item (if gimbal feedback is not provided or lost), you should set [MIS_COMMAND_TOUT](../advanced_config/parameter_reference.md#MIS_COMMAND_TOUT) to be greater than the time taken for the gimbal to traverse its full range.
After this timeout the mission will proceed to the next item.
## Simulation / SITL
The following simulation environments come with a preconfigured simulated gimbal.
You can test the gimbal using the [QGroundControl UI](#qgc-testing) or by sending [driver commands](#driver-testing)
:::tip
If you only need to test the [gimbal driver](../modules/modules_driver.md#gimbal), then you can do this on any model or simulators.
Just make sure that the driver runs, using `gimbal start` in the MAVLink console, then configure the driver parameters.
:::
### Gazebo
To run the [Gazebo](../sim_gazebo_gz/index.md) simulation [Quadrotor(x500) with gimbal (Front-facing) in Gazebo](../sim_gazebo_gz/vehicles.md#x500-quadrotor-with-gimbal-front-facing), use:
```sh
make px4_sitl gz_x500_gimbal
```
![Quadrotor(x500) with gimbal (Front-facing) in Gazebo](../../assets/simulation/gazebo/vehicles/x500_gimbal.png)
### Gazebo Classic
To run the [Gazebo Classic](../sim_gazebo_classic/index.md) simulation [Typhoon H480 model](../sim_gazebo_classic/vehicles.md#typhoon-h480-hexrotor), use:
```sh
make px4_sitl gazebo-classic_typhoon_h480
```
![Typhoon H480 in Gazebo Classic](../../assets/simulation/gazebo_classic/vehicles/typhoon.jpg)
![Gazebo Gimbal Simulation](../../assets/simulation/gazebo_classic/gimbal-simulation.png)
## Тестування
### QGC Testing
The on-screen gimbal control can be used to move/test a connected MAVLink camera:
1. Start your preferred [simulator](#simulation-sitl) or connect to a real device.
2. Open QGroundControl and enable the on-screen camera control (Application settings).
![Quadrotor(x500) with gimbal (Front-facing) in Gazebo](../../assets/qgc/fly/gimbal_control_x500gz.png)
3. Make sure the vehicle is armed and flying, e.g. by entering with `commander takeoff`.
4. To change gimbal target position, click in the QGC GUI up, down, left, right, or use the buttons on the gimbal control (**Center**, **Tilt 90**, **Yaw lock**).
### Driver Testing
You can test a gimbal by sending `gimbal` driver commands in the [QGroundControl MAVLink Console](https://docs.qgroundcontrol.com/master/en/qgc-user-guide/analyze_view/mavlink_console.html):
1. Start your preferred [simulator](#simulation-sitl) or connect to a real device.
2. Open QGroundControl and connect to your vehicle.
3. Open the MAVLink Console using the menu: **Analyze > Mavlink Console**.
4. Make sure the vehicle is armed and flying, e.g. by entering the command: `commander takeoff`.
To check gimbal status enter:
```sh
gimbal status
```
To set the gimbal yaw to 30 degrees, use the command:
```sh
gimbal test yaw 30
```
More generally, you can set the angle or angular rate command using a command with this format:
```sh
gimbal test <axis> <value>
```
- `axis`:
- `<roll|pitch|yaw>` for angles
- `<rollrate|pitchrate|yawrate>` for angular rates
- `value`:
- `<degrees>` for angles
- `<degrees / second>` for angular rates
To set the MAVLink component that is in primary control of the gimbal:
```sh
gimbal primary-control <sys_id> <comp_id>
```
- `sys_id`: MAVLink system ID
- `comp_id`: MAVLink component ID
For other commands, see the [`gimbal`](../modules/modules_driver.md#gimbal) driver module document.
### MAVLink Testing
The gimbal can be tested by sending MAVLink gimbal manager commands using [MAVSDK](../robotics/mavsdk.md) or some other MAVLink library.
Зверніть увагу, що симульований гімбал стабілізується самостійно, тому якщо ви надсилаєте команди MAVLink, встановіть прапори `стабілізації` на значення `false`.
docs/uk/advanced/index.md
+1
View File
@@ -0,0 +1 @@
# Просунуті теми
docs/uk/advanced/out_of_tree_modules.md
+84
View File
@@ -0,0 +1,84 @@
# Зовнішні модулі (Out-of-Tree)
Зовнішні модулі забезпечують зручний механізм для розробників для керування/групування власних модулів, які вони хочуть додати до (або оновити в) прошивки PX4.Зовнішні модулі можуть використовувати ті ж самі включення, що й внутрішні модулі, і можуть взаємодіяти з внутрішніми модулями через uORB.
У цій темі пояснюється, як додати зовнішній модуль ("out of tree") до збірки PX4.
:::tip
Ми закликаємо вас внести ваші зміни до PX4, де це можливо!
:::
## Використання
Щоб створити зовнішній модуль:
- Створіть папку _зовнішнього каталогу_, щоб згрупувати зовнішні модулі:
- Його можна знайти будь-де за межами дерева **PX4-Autopilot**.
- Він повинен мати таку ж структуру, як **PX4-Autopilot** (тобто він повинен містити каталог з назвою **src**).
- Пізніше ми звернемося до цього каталогу за допомогою `EXTERNAL_MODULES_LOCATION`.
- Скопіюйте існуючий модуль (наприклад, **examples/px4_simple_app**) до зовнішнього каталогу або безпосередньо створіть новий модуль.
- Перейменуйте модуль (включаючи `MODULE` у **CMakeLists.txt**) або видаліть його з існуючої конфігурації збірки _cmake_ PX4-Autopilot.
Це щоб уникнути конфліктів з внутрішніми модулями.
- Додайте файл **CMakeLists.txt** у зовнішній каталозі з вмістом:
```cmake
set(config_module_list_external
modules/<new_module>
PARENT_SCOPE
)
```
- Додайте рядок `EXTERNAL` до `modules/<new_module>/CMakeLists.txt` у `px4_add_module()`, наприклад так:
```cmake
px4_add_module(
MODULE modules__test_app
MAIN test_app
STACK_MAIN 2000
SRCS
px4_simple_app.c
DEPENDS
platforms__common
EXTERNAL
)
```
## Визначення повідомлень поза деревами uORB
Повідомлення uORB також можна визначати поза деревом. Для цього має існувати папка `$EXTERNAL_MODULES_LOCATION/msg`.
- Розмістіть усі нові визначення повідомлень у каталозі `$EXTERNAL_MODULES_LOCATION/msg`.
Формат цих нових визначень повідомлень поза деревом такий самий, як і для будь-якого іншого [визначення повідомлень uORB](../middleware/uorb.md#adding-a-new-topic).
- Додати файл `$EXTERNAL_MODULES_LOCATION/msg/CMakeLists.txt` з змістом:
```cmake
set(config_msg_list_external
<message1>.msg
<message2>.msg
<message3>.msg
PARENT_SCOPE
)
```
Нове повідомлення uORB можна використовувати як будь-яке інше повідомлення uORB, як описано `тут`.
Поза деревом повідомлень uORB будуть створені в тих же місцях, що й звичайні повідомлення uORB.
Заголовки тем uORB генеруються в `<build_dir>/uORB/topics/`, а вихідні файли повідомлень – створено в `<build_dir>/msg/topics_sources/`.
Нові повідомлення uORB можна використовувати як будь-які інші повідомлення uORB, як описано [тут](../middleware/uorb.md#adding-a-new-topic).
:::warning
Визначення повідомлень поза деревом uORB не можуть мати ті ж самі назви, що й будь-які звичайні повідомлення uORB.
:::
## Побудова зовнішніх модулів та повідомлень uORB
Виконайте `make px4_sitl EXTERNAL_MODULES_LOCATION=<path>`.
Будь-яку іншу ціль збірки можна використовувати, але каталог для збирання не повинен існувати.
Якщо вона вже існує, ви також можете просто встановити змінну _cmake_ у папці збірки.
Для наступних поступових збірок `EXTERNAL_MODULES_LOCATION` не потрібно вказувати.
docs/uk/advanced/package_delivery.md
+67
View File
@@ -0,0 +1,67 @@
# Доставка пакунків у місіях
<Badge type="tip" text="PX4 v1.14" />
Місія доставки пакунка - це розширення операції з шляховою точкою, де користувач може планувати призначення пакету в якості шляхової точки.
Ця тема пояснює архітектуру функції доставки пакету.
Він призначений для розробників, які працюють над розширенням архітектури, наприклад, для підтримки нових механізмів доставки вантажу.
:::info
Зараз лише [Grippers](../peripherals/gripper.md) може бути використано для доставки пакету.
Лебідки поки що не підтримуються.
:::
:::info
Детальну документацію з налаштування плану місії доставки пакетів можна знайти [тут](../flying/package_delivery_mission.md).
Підготовка для модуля `payload_deliverer` описана у документації для механізму доставки, наприклад, [Gripper](../peripherals/gripper.md#px4-configuration).
:::
## Діаграма Архітектури доставки пакетів
![Package delivery architecture overview](../../assets/advanced_config/payload_delivery_mission_architecture.png)
Функціонал доставки пакетів зосереджений навколо повідомлень [VehicleCommand](../msg_docs/VehicleCommand.md) та [VehicleCommandAck](../msg_docs/VehicleCommandAck.md).
Основна ідея полягає в наявності сутності, яка обробляє команду транспортного засобу `DO_GRIPPER` або `DO_WINCH`, виконує її і надсилає підтвердження, коли успішна доставка підтверджена.
Оскільки PX4 автоматично транслює повідомлення uORB `VehicleCommand` до UART-порту, налаштованого на комунікацію у форматі MAVLink як повідомлення [`COMMAND_LONG`](https://mavlink.io/en/messages/common.html#COMMAND_LONG), зовнішній навантаження може отримати команду і виконати її.
Аналогічно, оскільки PX4 автоматично перекладає повідомлення [`COMMAND_ACK`](https://mavlink.io/en/messages/common.html#COMMAND_ACK), що надходить зовнішнім джерелом через порт UART, налаштований на MAVLink, в uORB-повідомлення `vehicle_command_ack`, підтвердження зовнішнього навантаження про успішне розгортання пакета може бути отримано модулем `navigator` PX4.
Нижче є пояснено кожен об'єкт, що бере участь в архітектурі доставки пакету.
## Навігатор
Навігатор обробляє приймання команди ТЗ (описано нижче).
Після отримання повідомлення про успішне розгортання воно встановлює прапорець на рівні блоку місії, щоб сигналізувати про успішне розгортання вантажу.
Це дозволяє місії перейти до наступного пункту (наприклад, Waypoint) безпечно, оскільки ми впевнені у підтвердженні успішного виконання розгортання.
## Транспортний Командний ACK
Ми чекаємо на підтвердження (ACK), яке може прийти як внутрішнє (через модуль `payload_deliverer`), так і зовнішнє (зовнішня сутність відправляє повідомлення MAVLink `COMMAND_ACK`), щоб визначити, чи була успішною дія доставки пакету (або `DO_GRIPPER`, або `DO_WINCH`).
## Місія
Команда «Захват/лебідка» розміщується як `предмет місії`.
Це можливо, оскільки всі пункти місії мають команду `MAV_CMD` для виконання (наприклад, Land, Takeoff, Waypoint і т. д.), яку можна встановити на `DO_GRIPPER` або `DO_WINCH`.
У логіці місії (зелена рамка вище), якщо досягнуто будь-який пункт місії Gripper/Winch, вона використовує функціональність brake_for_hold (яка встановлює прапорець `valid` наступного пункту місії зупинки на значення `false`) для вертольотів (наприклад, багтротика), щоб транспортний засіб утримував своє положення, поки виконується розгортання.
Для фіксованих крил та інших транспортних засобів не розглядається жодна особлива умова зупинки.
Для літаків з фіксованими крилами та інших типів транспортних засобів не передбачено жодних спеціальних умов щодо зупинки.
## Блок Місії
`MissionBlock` є батьківським класом `Mission`, який відповідає за частину "Чи завершена місія?".
Все це виконується у функції `is_mission_item_reached_or_completed`, щоб обробляти затримку часу / перехід до наступного пункту місії.
Також вона реалізує функцію issue_command, яка видасть команду транспортному засобу, відповідну команді `MAV_CMD` пункту місії, яку потім отримає зовнішній вантаж або модуль `payload_deliverer` внутрішньо.
## Доставщик Вантажу
Це спеціалізований модуль, який відповідає за підтримку захопника / лебідки, який використовується для стандартного [плану місії доставки пакетів](../flying/package_delivery_mission.md).
Налаштування для модуля `payload_deliverer` описано у документації щодо налаштування реального механізму випуску пакету, такого як [Gripper](../peripherals/gripper.md#px4-configuration).
docs/uk/advanced/parameters_and_configurations.md
+365
View File
@@ -0,0 +1,365 @@
# Параметри та налаштування
PX4 використовує _param subsystem_ (таблицю значень `float` і `int32_t`) і текстові файли (для скриптів запуску) для створення конфігурації.
This section discusses the _param_ subsystem in detail.
У ньому описано, як відображати, зберігати і завантажувати параметри, а також як їх описувати і робити доступними для наземних станцій.
:::tip
[Запуск системи](../concept/system_startup.md) та роботу скриптів запуску [конфігурації фреймів](../dev_airframes/adding_a_new_frame.md) описано на інших сторінках.
:::
## Використання командного рядка
[Системна консоль PX4](../debug/system_console.md) пропонує інструмент [param](../modules/modules_command.md#param), за допомогою якого можна встановлювати параметри, зчитувати їх значення, зберігати їх, а також експортувати й зберігати у файлах та відновлювати з них.
### Отримання та встановлення параметрів
Команда `param show` виводить усі параметри системи:
```sh
param show
```
Для більшої вибірковості можна використовувати часткове ім'я параметра з символом підстановки "\*":
```sh
nsh> param show RC_MAP_A*
Symbols: x = used, + = saved, * = unsaved
x RC_MAP_AUX1 [359,498] : 0
x RC_MAP_AUX2 [360,499] : 0
x RC_MAP_AUX3 [361,500] : 0
x RC_MAP_ACRO_SW [375,514] : 0
723 parameters total, 532 used.
```
Ви можете використовувати прапорець `-c`, щоб показати всі параметри, які було змінено (порівняно з їх значеннями за замовчуванням):
```sh
param show -c
```
Ви можете використати `param show-for-airframe`, щоб показати всі параметри, які було змінено від значень за замовчуванням лише для поточного файлу літального апарату (та значень за замовчуванням, які він імпортує).
### Параметри експорту та завантаження
Ви можете зберігати будь-які параметри, які були _змінені_ (які відрізняються від параметрів за замовчуванням).
Стандартна команда `param save` збереже параметри у поточному файлі за замовчуванням:
```sh
param save
```
Якщо вказати аргумент, вона збереже параметри у новому каталозі:
```sh
param save /fs/microsd/vtol_param_backup
```
Існує дві різні команди для _завантаження_ параметрів:
- `param load` спочатку виконує повне скидання всіх параметрів до значень за замовчуванням, а потім перезаписує значення параметрів будь-якими значеннями, збереженими у файлі.
- `param import` просто перезаписує значення параметрів значеннями з файлу, а потім зберігає результат (тобто фактично викликає `param save`).
Команда `load` ефективно скидає параметри до стану, у якому вони були збережені (ми говоримо "ефективно", тому що будь-які параметри, збережені у файлі, буде оновлено, але інші параметри можуть мати інші значення за замовчуванням, визначені у прошивці, ніж під час створення файлу параметрів).
By contrast, `import` merges the parameters in the file with the current state of the vehicle.
Наприклад, можна просто імпортувати файл параметрів, що містить дані калібрування, не перезаписуючи решту конфігурації системи.
Приклади для обох випадків показані нижче:
```sh
# Reset the parameters to when file was saved
param load /fs/microsd/vtol_param_backup
# Optionally save params (not done automatically with load)
param save
```
```sh
# Merge the saved parameters with current parameters
param import /fs/microsd/vtol_param_backup
```
## Створення/визначення параметрів
Опис параметрів складається з двох частин:
- [Метадані параметрів](#parameter-metadata) визначають значення за замовчуванням для кожного параметра у прошивці разом з іншими метаданими для відображення (і редагування) параметрів на наземних станціях керування та у документації.
- [Код C/C++](#c-c-api), який надає доступ до отримання та/або зміни значень параметрів з модулів та драйверів PX4.
Нижче описано кілька підходів до написання метаданих та коду.
Where possible code should use newer [YAML metadata](#yaml-metadata) and [C++ API](#c-api) over the older C parameter/code definitions, as these are more flexible and robust.
Метадані параметрів [компілюються у прошивку](#publishing-parameter-metadata-to-a-gcs),
і надаються наземним станціям за посередництвом служби [MAVLink Component Information service](https://mavlink.io/en/services/component_information.html).
### Назви параметрів:
Назви параметрів не повинні перевищувати 16 ASCII символів.
By convention, every parameter in a group should share the same (meaningful) string prefix followed by an underscore, and `MC_` and `FW_` are used for parameters related specifically to Multicopter or Fixed-wing systems.
Ця конвенція не є обов'язковою.
Назва має збігатися як у коді, так і у метаданих [параметру](#parameter-metadata), щоб правильно асоціювати параметр з його метаданими (включно зі значенням за замовчуванням у прошивці).
### C / C++ API
Існують окремі C і C++ API, які можна використовувати для отримання доступу до значень параметрів з модулів і драйверів PX4.
Однією з важливих відмінностей між API є те, що версія на C++ має більш ефективний стандартизований механізм синхронізації зі змінами значень параметрів (наприклад, з GCS).
Синхронізація важлива, оскільки параметр може бути змінений на інше значення в будь-який момент.
Your code should _always_ use the current value from the parameter store.
If getting the latest version is not possible, then a reboot will be required after the parameter is changed (set this requirement using the `@reboot_required` metadata).
Крім того, версія на C++ має кращу типізацію та менші витрати оперативної пам'яті.
Недоліком є те, що ім'я параметра має бути відоме під час компіляції, тоді як C API може приймати динамічно створене ім'я як рядок.
#### C++ API
The C++ API provides macros to declare parameters as _class attributes_.
You add some "boilerplate" code to regularly listen for changes in the [uORB Topic](../middleware/uorb.md) associated with _any_ parameter update.
Потім код фреймворку (невидимо) відстежує повідомлення uORB, які впливають на атрибути ваших параметрів, і підтримує їх синхронізацію.
У решті коду ви можете просто використовувати визначені атрибути параметрів, і вони завжди будуть актуальними!
Насамперед включіть необхідні заголовки до заголовка класу вашого модуля або драйвера:
- **px4_platform_common/module_params.h** для отримання макросу `DEFINE_PARAMETERS`:
```cpp
#include <px4_platform_common/module_params.h>
```
- **parameter_update.h** для доступу до повідомлень uORB `parameter_update`:
```cpp
#include <uORB/topics/parameter_update.h>
```
- **Subscription.hpp** для uORB C++ API підписки:
```cpp
#include <uORB/Subscription.hpp>
```
Derive your class from `ModuleParams`, and use `DEFINE_PARAMETERS` to specify a list of parameters and their associated parameter attributes.
Назви параметрів мають збігатися з визначеннями метаданих параметрів.
```cpp
class MyModule : ..., public ModuleParams
{
public:
...
private:
/**
* Check for parameter changes and update them if needed.
*/
void parameters_update();
DEFINE_PARAMETERS(
(ParamInt<px4::params::SYS_AUTOSTART>) _sys_autostart, /**< example parameter */
(ParamFloat<px4::params::ATT_BIAS_MAX>) _att_bias_max /**< another parameter */
)
// Subscriptions
uORB::SubscriptionInterval _parameter_update_sub{ORB_ID(parameter_update), 1_s};
};
```
Оновіть файл cpp за допомогою шаблону, щоб перевірити наявність повідомлення uORB, пов'язаного з оновленням параметрів.
Періодично викликайте `parameters_update();` у коді, щоб перевірити, чи відбулося оновлення:
```cpp
void Module::parameters_update()
{
if (_parameter_update_sub.updated()) {
parameter_update_s param_update;
_parameter_update_sub.copy(&param_update);
// If any parameter updated, call updateParams() to check if
// this class attributes need updating (and do so).
updateParams();
}
}
```
У наведеному вище методі:
- `_param_update_sub.updated()` повідомляє нам, чи є _будь-яке_ оновлення в uORB-повідомленні `param_update` (але не вказує, який саме параметр змінено).
- Якщо було оновлено "деякий" параметр, ми копіюємо оновлення у `parameter_update_s` (`param_update`), щоб очистити очікуване оновлення.
- Then we call `ModuleParams::updateParams()`.
This "under the hood" updates all parameter attributes listed in our `DEFINE_PARAMETERS` list.
Атрибути параметрів (`_sys_autostart` і `_att_bias_max` у цьому випадку) можна використовувати для відображення параметрів, і вони будуть оновлюватися щоразу, коли значення параметра змінюватиметься.
:::tip
Шаблон [Програми/Модуля](../modules/module_template.md) використовує новий стиль C++ API, але не включає метадані [параметрів](#parameter-metadata).
:::
#### C API
C API можна використовувати як у модулях, так і в драйверах.
Спочатку включіть параметр API:
```C
#include <parameters/param.h>
```
Then retrieve the parameter and assign it to a variable (here `my_param`), as shown below for `PARAM_NAME`.
The variable `my_param` can then be used in your module code.
```C
int32_t my_param = 0;
param_get(param_find("PARAM_NAME"), &my_param);
```
:::info
Якщо у метаданих параметра було оголошено `PARAM_NAME`, то буде встановлене його значення за замовчуванням, і наведений вище виклик для пошуку параметра завжди буде успішним.
:::
`param_find()` is an "expensive" operation, which returns a handle that can be used by `param_get()`.
If you're going to read the parameter multiple times, you may cache the handle and use it in `param_get()` when needed
```cpp
# Get the handle to the parameter
param_t my_param_handle = PARAM_INVALID;
my_param_handle = param_find("PARAM_NAME");
# Query the value of the parameter when needed
int32_t my_param = 0;
param_get(my_param_handle, &my_param);
```
### Метадані параметра
PX4 використовує розгалужену систему метаданих параметрів для управління дружнім до користувача представленням параметрів, а також для встановлення значень за замовчуванням для кожного параметра у прошивці.
:::tip
Правильні метадані мають вирішальне значення для якісного користувацького досвіду на наземній станції.
:::
Parameter metadata can be stored anywhere in the source tree as either **.c** or **.yaml** parameter definitions (the YAML definition is newer, and more flexible).
Зазвичай він зберігається разом з відповідним модулем.
Система збірки витягує метадані (за допомогою `make parameters_metadata`) для створення [довідника параметрів](../advanced_config/parameter_reference.md) та інформації про параметри, [що використовуються наземними станціями](#publishing-parameter-metadata-to-a-gcs).
:::warning
Після додавання файлу параметрів _new_ вам слід викликати `make clean` перед збіркою, щоб згенерувати нові параметри (файли параметрів додаються як частина кроку конфігурації _cmake_, який відбувається для чистих збірок і якщо файл cmake змінено).
:::
#### Метадані YAML
:::info
На момент написання статті визначення параметрів YAML не можна використовувати у _бібліотеках_.
:::
YAML meta data is intended as a full replacement for the **.c** definitions.
Він підтримує ті самі метадані, а також нові можливості, такі як множинні визначення.
- Схема метаданих параметрів YAML знаходиться тут: [validation/module_schema.yaml](https://github.com/PX4/PX4-Autopilot/blob/main/validation/module_schema.yaml).
- Приклад використання визначень YAML можна знайти у визначенні параметрів MAVLink: [/src/modules/mavlink/module.yaml](https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/mavlink/module.yaml).
- YAML-файл реєструється у системі збірки cmake шляхом додавання
```cmake
MODULE_CONFIG
module.yaml
```
до секції `px4_add_module` файлу `CMakeLists.txt` цього модуля.
#### Мета-дані YAML з багатьма екземплярами (шаблонами)
Шаблонні визначення параметрів підтримуються у [YAML визначеннях параметрів](https://github.com/PX4/PX4-Autopilot/blob/main/validation/module_schema.yaml) (шаблонний код параметрів не підтримується).
The YAML allows you to define instance numbers in parameter names, descriptions, etc. using `${i}`.
Наприклад, нижче буде згенеровано MY_PARAM_1_RATE, MY_PARAM_2_RATE і т.д.
```yaml
MY_PARAM_${i}_RATE:
description:
short: Maximum rate for instance ${i}
```
Наступні визначення YAML містять початковий та кінцевий індекси.
- `num_instances` (за замовчуванням 1): Кількість інстансів, які потрібно згенерувати (>=1)
- `instance_start` (default 0): First instance number. If 0, `${i}` expands to [0, N-1]\`.
For a full example see the MAVLink parameter definitions: [/src/modules/mavlink/module.yaml](https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/mavlink/module.yaml)
#### c параметр метаданих
Застарілий підхід для визначення метаданих параметрів знаходиться у файлі з розширенням **.c** (на момент написання цієї статті це підхід, який найчастіше використовується у дереві коду).
Розділи метаданих параметрів виглядають так, як показано в наступних прикладах:
```cpp
/**
* Pitch P gain
*
* Pitch proportional gain, i.e. desired angular speed in rad/s for error 1 rad.
*
* @unit 1/s
* @min 0.0
* @max 10
* @decimal 2
* @increment 0.0005
* @reboot_required true
* @group Multicopter Attitude Control
*/
PARAM_DEFINE_FLOAT(MC_PITCH_P, 6.5f);
```
```cpp
/**
* Acceleration compensation based on GPS
* velocity.
*
* @group Attitude Q estimator
* @boolean
*/
PARAM_DEFINE_INT32(ATT_ACC_COMP, 1);
```
Макрос `PARAM_DEFINE_*` в кінці визначає тип параметра (`PARAM_DEFINE_FLOAT` або `PARAM_DEFINE_INT32`), ім'я параметра (яке має відповідати імені, що використовується у коді) та значення за замовчуванням у прошивці.
Рядки в блоці коментарів є необов'язковими, і в основному використовуються для керування параметрами відображення та редагування на наземній станції.
The purpose of each line is given below (for more detail see [module_schema.yaml](https://github.com/PX4/PX4-Autopilot/blob/main/validation/module_schema.yaml)).
```cpp
/**
* <title>
*
* <longer description, can be multi-line>
*
* @unit <the unit, e.g. m for meters>
* @min <the minimum sane value. Can be overridden by the user>
* @max <the maximum sane value. Can be overridden by the user>
* @decimal <the minimum sane value. Can be overridden by the user>
* @increment <the "ticks" in which this value will increment in the UI>
* @reboot_required true <add this if changing the param requires a system restart.>
* @boolean <add this for integer parameters that represent a boolean value>
* @group <a title for parameters that form a group>
*/
```
## Публікація метаданих параметрів у GCS
The parameter metadata JSON file is compiled into firmware (or hosted on the Internet), and made available to ground stations via the [MAVLink Component Metadata service](https://mavlink.io/en/services/component_information.html).
Для отримання додаткової інформації див. <a href="../advanced/px4_metadata.md"> Метадані PX4 (трансляція і публікація)</a>.
This process is the same as for [events metadata](../concept/events_interface.md#publishing-event-metadata-to-a-gcs).
For more information see [PX4 Metadata (Translation & Publication)](../advanced/px4_metadata.md)
## Подальша інформація
- [Finding/Updating Parameters](../advanced_config/parameters.md)
- [Довідник параметрів](../advanced_config/parameter_reference.md)
- [Реалізація параметрів](https://github.com/PX4/PX4-Autopilot/blob/main/platforms/common/include/px4_platform_common/param.h#L129) (information on `.get()`, `.commit()`, and other methods)
docs/uk/advanced/px4_metadata.md
+89
View File
@@ -0,0 +1,89 @@
# Метадані PX4
PX4 використовує та генерує дані, які мають відповідні метадані, зрозумілі людині й машині:
- [Параметри](../advanced_config/parameters.md) налаштовують поведінку PX4.
- Параметр представлено рядком ідентифікатора, який зіставляється зі значенням, що зберігається у PX4.
- Відповідні метадані включають опис параметра, його можливі значення, інформацію про те, як значення може бути представлено (наприклад, для бітових масок).
- [Події](../concept/events_interface.md) повідомляють про події, такі як причини збою, попередження про низький заряд батареї, кінець калібрування і так далі.
- Подія позначається ідентифікатором і надсилається з відповідним рівнем журналу та аргументами.
- Пов'язані метадані включають повідомлення, опис та список аргументів (включаючи їх тип) кожної події.
- Конфігурація [приводів](../config/actuators.md) налаштовує конкретну геометрію транспортного засобу, призначає приводи та двигуни вихідними сигналами контролера польоту та перевіряє реакцію приводу та двигуна.
- Метадані містять інформацію про підтримувані геометрії транспортних засобів, список вихідних драйверів та їх конфігурацію.
- _QGroundControl_ використовує цю інформацію для динамічної побудови інтерфейсу конфігурації.
Метадані та переклади метаданих надаються зовнішнім системам, таким як QGroundControl, що дозволяє їм відображати інформацію про параметри та події, а також налаштовувати геометрію транспортного засобу та відображати відповідності виведення привода.
У цій темі пояснюється, як можна визначити метадані та допомогти перекладати рядки (а також "просто для інформації", як це все працює).
## Переклад метаданих
Переклад метаданих PX4 виконується за допомогою Crowdin у проєкті [PX4-Metadata-Translations](https://crowdin.com/project/px4-metadata-translations).
Для отримання додаткової інформації про роботу з PX4 та Crowdin див. [Переклад](../contribute/translation.md).
## Визначення метаданих
Метадані PX4 визначаються у вихідному коді PX4 разом з відповідними даними.
Це можна зробити або в коментарі на C/C++ зі спеціальною розміткою для вказівки полів метаданих та їх значень, або за допомогою файлів YAML.
Докладнішу інформацію див. у темах для кожного типу даних:
- [Параметри та конфігурації > Створення/визначення параметрів](../advanced/parameters_and_configurations.md#creating-defining-parameters)
- [Інтерфейс подій](. ./concept/events_interface.md)
- [Метадані приводу](#actuator-metadata) (нижче)
## Інструментарій метаданих
Процес обробки метаданих однаковий для всіх типів метаданих.
Метадані збираються у файли JSON кожного разу, коли збирається PX4.
Для більшості польотних контролерів (оскільки більшість з них мають достатньо доступного FLASH), файл JSON стискається xz-стисненням і зберігається у згенерованому бінарному файлі.
Потім файл передається ​​на наземні станції за допомогою протоколу MAVLink [Component Metadata Protocol](https://mavlink.io/en/services/component_information.html).
Використання протоколу метаданих компонентів гарантує, що одержувач завжди отримує актуальні метадані для коду, що виконується на апараті.
Метадані подій також додаються до файлів журналів, що дозволяє інструментам аналізу журналів (таким як Перегляд польотів) використовувати правильні метадані для відображення подій.
Бінарні файли для контролерів польоту з обмеженим обсягом пам'яті не зберігають метадані параметрів у бінарному файлі, а натомість посилаються на ті самі дані, що зберігаються на `px4-travis.s3.amazonaws.com`.
Це стосується, наприклад, [Omnibus F4 SD](../flight_controller/omnibus_f4_sd.md).
Метадані завантажуються через [github CI](https://github.com/PX4/PX4-Autopilot/blob/main/.github/workflows/metadata.yml) для всіх цілей збірки (таким чином, вони будуть доступні лише після того, як параметри будуть об'єднані в main).
:::info
You can identify memory constrained boards because they specify `CONFIG_BOARD_CONSTRAINED_FLASH=y` in their [px4board definition file](https://github.com/PX4/PX4-Autopilot/blob/main/boards/omnibus/f4sd/default.px4board).
Якщо ви виконуєте індивідуальну розробку на платі з обмеженою FLASH-пам'яттю, ви можете змінити URL-адресу [тут](https://github. com/PX4/PX4-Autopilot/blob/main/src/lib/component_information/CMakeLists.txt#L41), щоб вказати на інший сервер.
:::
Метадані на `px4-travis.s3.amazonaws.com` використовуються, якщо метадані параметрів відсутні на бортовому комп'ютері безпілотника.
Він також може використовуватися як запасний варіант, щоб уникнути дуже повільного завантаження через низькошвидкісне телеметричне з'єднання.
JSON-файли метаданих для CI-збірок `main` також копіюються до репозиторію github: [PX4/PX4-Metadata-Translations](https://github.com/PX4/PX4-Metadata-Translations/).
Це інтегрується з Crowdin для отримання перекладів, які зберігаються у теці [translated](https://github.com/PX4/PX4-Metadata-Translations/tree/main/translated) як xz-стиснуті файли перекладу для кожної мови.
На них посилаються метадані компонентів безпілотника, і вони завантажуються за необхідності.
Для отримання додаткової інформації див. [PX4-Metadata-Translations](https://github.com/PX4/PX4-Metadata-Translations/) та [Протокол метаданих компонентів > Переклад](https://mavlink.io/en/services/component_information.html#translation).
:::info
Файл параметрів XML з головної гілки проєкту PX4 копіюється до дерева джерел QGC за допомогою безперервної інтеграції (CI). Цей файл використовується як резервний варіант у випадках, коли метадані недоступні через протокол метаданих компонентів (цей підхід передує появі протоколу метаданих компонентів).
:::
### Метадані приводу
У наступній діаграмі показано, як метадані приводу складаються з вихідного коду та використовуються QGroundControl:
![Метадані приводів](../../assets/diagrams/actuator_metadata_processing.svg)
<!-- Source: https://docs.google.com/drawings/d/1hMQmIijdFjr21rREcXj50qz0C1b47JW0OEa6p5P231k/edit -->
- **Ліворуч**: метадані визначаються в файлах `module.yml` в різних модулях.
Модулі `control_allocator` визначають геометрії, тоді як кожен вихідний драйвер визначає свій набір каналів та параметрів конфігурації.
[Файл схеми](https://github.com/PX4/PX4-Autopilot/blob/main/validation/module_schema.yaml) документує структуру цих файлів yaml.
- **Середній**: Під час компіляції файли `module.yml` для всіх активованих модулів для поточної цілі компіляції аналізується і перетворюється у файл `actuators.json` за допомогою сценарію [Tools/module_config/generate_actuators_metadata.py](https://github.com/PX4/PX4-Autopilot/blob/main/Tools/module_config/generate_actuators_metadata.py).
Також є [файл схеми](https://github.com/mavlink/mavlink/blob/master/component_metadata/actuators.schema.json) для цього.
- **Правильно**: Під час виконання програми файли JSON запитуються QGroundControl через API метаданих компонентів MAVLink (який описано вище).
## Подальша інформація
- [Параметри та конфігурації](../advanced/parameters_and_configurations.md)
- [Інтерфейс подій](. ./concept/events_interface.md)
- [Переклад](../contribute/translation.md)
- [Протокол метаданих компонентів](https://mavlink.io/en/services/component_information.html) (mavlink.io)
- [PX4-Metadata-Translations](https://github.com/PX4/PX4-Metadata-Translations/) (Github)
docs/uk/advanced/realsense_intel_driver.md
+105
View File
@@ -0,0 +1,105 @@
# Встановлення драйвера на Ubuntu для Intel RealSense R200
Цей навчальний посібник має на меті надати інструкції щодо встановлення драйвера камери Intel RealSense R200 у середовищі Linux, так щоб зібрані зображення можна було доступити через систему робототехніки (ROS).
Голова камери RealSense R200 зображена нижче:
![Intel Realsense Camera front view](../../assets/hardware/sensors/realsense/intel_realsense.png)
Встановлення пакету драйвера виконується на операційній системі Ubuntu, яка працює як гостьова ОС у Virtual Box.
Специфікації хост-комп'ютера, на якому запущено Virtual Box, самого Virtual Box та гостьової системи подано нижче:
- Операційна система хоста: Windows 8
- Процесор: Intel(R) Core(TM) i7-4702MQ CPU @ 2.20GHz
- Віртуальний ящик: Oracle VM. Версія 5.0.14 r105127
- Розширення: Встановлено пакет розширень для VirtualBox (необхідно для підтримки USB3)
- Операційна система гостя: Linux - Ubuntu 14.04.3 LTS
У наведеному порядку, в першій частині показано, як встановити Ubuntu 14.04 як гостьову операційну систему в Virtual Box. У другій частині показано, як встановити ROS Indigo та драйвер камери. Додатково часто вживані вирази мають наступне значення:
- Virtual Box (VB): Програма, яка запускає різні віртуальні машини. У цьому випадку Oracle VM.
- Віртуальна машина (VM): Операційна система, яка працює в Virtual Box як гостьова система. У цьому випадку Ubuntu.
## Встановлення Ubuntu 14.04.3 LTS в Virtual Box
- Створіть нову віртуальну машину (VM): Linux 64-Bit.
- Завантажте файл iso з Ubuntu 14.04.3 LTS: ([ubuntu-14.04.3-desktop-amd64.iso](https://ubuntu.com/download/desktop)).
- Установка Ubuntu:
- Під час процедури встановлення залиште непозначеними наступні дві опції:
- Завантажувати оновлення під час встановлення
- Встановити це програмне забезпечення третьої сторони
- Після встановлення можливо знадобиться увімкнути VirtualBox для відображення Ubuntu на всьому робочому столі:
- Запустіть віртуальну машину Ubuntu та увійдіть у систему. Натисніть на меню **Devices->Insert Guest Additions CD image** на панелі інструментів VirtualBox.
- Натисніть **Run** і введіть пароль у вікнах, які з'являться в Ubuntu.
- Зачекайте, поки завершиться встановлення, а потім перезапустіть систему.
Тепер систему можна відображати на всьому робочому столі.
- Якщо в Ubuntu з'явиться вікно, яке запитує про оновлення, відхиліть оновлення на цьому етапі.
- Увімкніть контролер USB 3 в Virtual Box:
- Вимкнути віртуальну машину
- Перейдіть до налаштувань віртуальної машини у меню вибору USB і оберіть: "USB 3.0(xHCI)".
Це можливо лише у випадку, якщо ви встановили пакет розширення для віртуальної машини Virtual Box.
- Запустіть віртуальну машину знову.
## Встановлення ROS Indigo
- Слідуйте інструкціям, наведеним у [посібнику з встановлення ROS Indigo](http://wiki.ros.org/indigo/Installation/Ubuntu):
- Встановити версію Desktop-Full.
- Виконайте кроки, описані в розділах "Ініціалізація rosdep" та "Налаштування середовища".
## Встановлення драйвера камери
- Встановіть Git
```sh
sudo apt-get install git
```
- Завантажте та встановіть драйвер:
- Клонувати [репозиторій RealSense_ROS](https://github.com/bestmodule/RealSense_ROS):
```sh
git clone https://github.com/bestmodule/RealSense_ROS.git
```
- Дотримуйтеся інструкцій, наведених [тут](https://github.com/bestmodule/RealSense_ROS/tree/master/r200_install).
- Натисніть кнопку "Enter", коли з'явиться питання про встановлення наступних пакетів:
```sh
Intel Low Power Subsystem support in ACPI mode (MFD_INTEL_LPSS_ACPI) [N/m/y/?] (NEW)
```
```sh
Intel Low Power Subsystem support in PCI mode (MFD_INTEL_LPSS_PCI) [N/m/y/?] (NEW)
```
```sh
Dell Airplane Mode Switch driver (DELL_RBTN) [N/m/y/?] (NEW)
```
- Повідомлення про помилку, яке може з'явитися в кінці процесу встановлення, не повинно призводити до неполадок драйвера:
```sh
rmmod: ERROR: Module uvcvideo is not currently loaded
```
- Після завершення встановлення перезавантажте віртуальну машину.
- Тест драйвера камери:
- Підключіть камеру Intel RealSense до комп'ютера за допомогою кабелю USB3, який вставлено в роз'єм USB3 на комп'ютері.
- Натисніть на Пристрої->USB-> Intel Corp Intel RealSense 3D Camera R200 у меню панелі Virtual Box, щоб переслати підключення USB камери в віртуальну машину.
- Виконайте файл [розпакованої теки]/Bin/DSReadCameraInfo:
- Якщо з'явиться наступне повідомлення про помилку, відключіть камеру (фізично від'єднайте USB-кабель від комп'ютера). Підключіть його знову + Натисніть на Пристрої->USB-> Intel Corp Intel RealSense 3D Camera R200 у меню панелі Virtual Box знову і виконайте знову файл [розпакованої теки]/Bin/DSReadCameraInfo.
```sh
DSAPI call failed at ReadCameraInfo.cpp:134!
```
- Якщо драйвер камери працює і розпізнає камеру Intel RealSense R200, ви повинні побачити конкретну інформацію про камеру Intel RealSense R200.
- Інсталяція та тестування ROS nodelet:
- Дотримуйтеся інструкцій з розділу "Установка", наведеного [тут](https://github.com/bestmodule/RealSense_ROS/blob/master/realsense_dist/2.3/doc/RealSense-ROS-R200-nodelet.md), щоб встановити ROS nodelet.
- Follow the instructions in the "Running the R200 nodelet" section given [here](https://github.com/bestmodule/RealSense_ROS/blob/master/realsense_dist/2.3/doc/RealSense-ROS-R200-nodelet.md), to test the ROS nodlet together with the Intel RealSense R200 camera head.
- Якщо все працює правильно, різні потоки даних з камери Intel RealSense R200 публікуються як ROS-теми.
docs/uk/advanced/rtk_gps.md
+101
View File
@@ -0,0 +1,101 @@
# RTK GPS (PX4 інтеграція)
[Реальний кінематичний час](https://en.wikipedia.org/wiki/Real_Time_Kinematic) (RTK) забезпечує точність GPS на рівні сантиметрів.
Ця сторінка пояснює, як RTK інтегрується в PX4.
:::tip
Інструкції щодо _використання_ RTK GPS наведені в розділі [Периферійне обладнання > RTK GPS](../gps_compass/rtk_gps.md).
:::
## Загальний огляд
RTK використовує виміри фази несучої хвилі сигналу, а не інформаційний вміст сигналу.
Він покладається на одну вихідну станцію для надання корекцій у реальному часі, які можуть працювати з кількома мобільними станціями.
Для налаштування RTK з PX4 потрібні два модулі RTK GPS та даталінк.
Закріплена на землі GPS-одиниця називається Базою, а повітряна одиниця - Ровером_.
Базова одиниця підключається до _QGroundControl_ (через USB) та використовує даталінк для передачі поправок RTCM до транспортного засобу (за допомогою повідомлення MAVLink [GPS_RTCM_DATA](https://mavlink.io/en/messages/common.html#GPS_RTCM_DATA)). На автопілоті пакети MAVLink розпаковуються та надсилаються до пристрою Rover, де вони обробляються для отримання рішення RTK.
На автопілоті пакети MAVLink розпаковуються та надсилаються до пристрою Rover, де вони обробляються для отримання рішення RTK.
Канал передачі даних зазвичай має підтримувати швидкість висхідної лінії зв’язку 300 байт на секунду (додаткову інформацію див. у розділі [Швидкість передачі даних у висхідній лінії зв’язку](#uplink-datarate)).
## Підтримувані GPS-модулі RTK
Список пристроїв, які ми тестували, можна знайти [в посібнику користувача](../gps_compass/rtk_gps.md#supported-rtk-devices).
:::info
Більшість пристроїв поставляється з двома варіантами: базою та ровером.
Переконайтеся, що ви обрали правильний варіант.
:::
## Автоматична конфігурація
Стек GPS PX4 автоматично налаштовує модулі GPS для надсилання та отримання правильних повідомлень через UART або USB в залежності від того, куди підключений модуль (до QGroundControl або автопілота).
Як тільки автопілот отримує повідомлення MAVLink `GPS_RTCM_DATA`, він автоматично пересилає дані RTCM до приєднаного модуля GPS через існуючі канали передачі даних (для даних корекції не потрібен окремий канал).
:::info
Інструмент конфігурації модуля RTK U-Center від u-blox не потрібний/не використовується!
:::
:::info
Як _QGroundControl_, так і прошивка автопілота використовують один і той же стек драйверів GPS PX4 [(PX4 GPS driver stack)](https://github.com/PX4/GpsDrivers).
На практиці це означає, що підтримку нових протоколів і/або повідомлень потрібно додавати лише в одному місці.
:::
### RTCM повідомлення
QGroundControl налаштовує базову станцію RTK на вивід наступних рамок RTCM3.2, кожну з частотою 1 Гц, якщо не вказано інше:
- \*\*1005 - Координати станції XYZ для точки антени (Базова позиція), 0.2 Гц.
- \*\*1077 - Повні псевдодальності GPS, фази несучої, Доплер та сила сигналу (висока роздільна здатність).
- \*\*1087 - Повні псевдодальності ГЛОНАСС, фази несущої, Доплер і сила сигналу (висока роздільна здатність).
- **1230** - Зміщення фаз коду ГЛОНАСС.
- Повні псевдодальності GLONASS, фази несущої, Доплер і сила сигналу (висока роздільна здатність)
- **1127** - Повні псевдодальності BeiDou, фази несущої, Доплер і сила сигналу (висока роздільна здатність)
## Uplink datarate(Швидкість передачі даних вгору)
The raw RTCM messages from the base are packed into a MAVLink `GPS_RTCM_DATA` message and sent over the datalink.
Максимальна довжина кожного повідомлення MAVLink становить 182 байти. Залежно від RTCM-повідомлення, повідомлення MAVLink майже ніколи не заповнюється повністю.
Повідомлення про базову позицію RTCM (1005) має довжину 22 байти, тоді як інші всі мають змінну довжину, залежно від кількості видимих супутників та кількості сигналів від супутника (лише 1 для однодіапазонних пристроїв, наприклад, M8P).
Оскільки в будь-який момент часу _максимальна_ кількість видимих супутників з будь-якої констеляції становить 12, то за реальних умов теоретично достатньо максимальної швидкості передачі даних в 300 байт/с.
Якщо використовується _MAVLink 1_, для кожного повідомлення RTCM, незалежно від його довжини, надсилається повідомлення `GPS_RTCM_DATA` розміром 182 байти.
Внаслідок цього приблизна вимога до пропускної здатності каналу зв'язку складає близько 700 байт на секунду.
Це може призвести до насичення каналу зв'язку на модулях телеметрії з низькою пропускною здатністю напівдуплексного режиму (наприклад, телеметричні радіозв'язки 3DR).
Якщо використовується _MAVLink 2_, будь-який порожній простір у повідомленні `GPS_RTCM_DATA` видаляється.
Отримана вимога до пропускної здатності для передачі вгору становить приблизно ту ж величину, що і теоретичне значення (близько 300 байт на секунду).
:::tip
PX4 автоматично переключається на MAVLink 2, якщо контрольна станція та модулі телеметрії підтримують це.
:::
MAVLink 2 слід використовувати на каналах з низькою пропускною здатністю для хорошої продуктивності RTK. Необхідно вдбати про те, щоб впевнитися, що ланцюжок телеметрії використовує MAVLink 2 на всіх етапах передачі даних.
Ви можете перевірити версію протоколу, використовуючи команду `mavlink status` у системній консолі:
```sh
nsh> mavlink status
instance #0:
GCS heartbeat: 593486 us ago
mavlink chan: #0
type: 3DR RADIO
rssi: 219
remote rssi: 219
txbuf: 94
noise: 61
remote noise: 58
rx errors: 0
fixed: 0
flow control: ON
rates:
tx: 1.285 kB/s
txerr: 0.000 kB/s
rx: 0.021 kB/s
rate mult: 0.366
accepting commands: YES
MAVLink version: 2
transport protocol: serial (/dev/ttyS1 @57600)
```
docs/uk/advanced/switching_state_estimators.md
+48
View File
@@ -0,0 +1,48 @@
# Перемикання оцінювачів стану
Ця сторінка показує вам доступні оцінювачі стану та як ви можете перемикатися між ними.
:::tip
EKF2 є типовим і повинен використовуватися, якщо немає причин не робити цього (особливо на транспортних засобах з GNSS/GPS).
Q-оцінювач може бути використаний, якщо у вас немає GPS, і це часто використовується у [multicopter racers](../config_mc/racer_setup.md).
:::
## Доступні оцінювачі
Доступні оцінювачі:
- **EKF2 оцінювач стану орієнтації, положення та вітру** (_рекомендовано_) - Розширений фільтр Кальмана, який оцінює орієнтацію, тривимірну позицію/швидкість та стан вітру.
- **LPE оцінювач положення** (_не рекомендовано_) - Розширений фільтр Кальмана для тривимірної позиції та швидкості.
:::warning
LPE є застарілим.
Він працює (на момент написання, у версії PX4 v1.14), але більше не підтримується або не обслуговується.
:::
- **Q оцінювач положення** - Дуже простий додатковий фільтр на основі кватерніонів для орієнтації.
Він не вимагає наявності GPS, магнітомера або барометра.
<!-- Q estimator is supported (at time of writing in PX4 v1.14). Test added in PX4-Autopilot/pull/21922 -->
## Як увімкнути різні оцінювачі
<!-- Changed in https://github.com/PX4/PX4-Autopilot/pull/22567 after v1.14 -->
Щоб увімкнути певний оцінювач, увімкніть його параметр та вимкніть інші:
- [EKF2_EN](../advanced_config/parameter_reference.md#EKF2_EN) - EKF2 (за замовчуванням/рекомендовано)
- [ATT_EN](../advanced_config/parameter_reference.md#ATT_EN) - Q Estimator (оцінювач орієнтації на основі кватерніонів)
- [LPE_EN](../advanced_config/parameter_reference.md#LPE_EN) - LPE (не підтримується для фіксованого крила)
:::warning
Важливо увімкнути один, і тільки один оцінювач.
Якщо увімкнено більше одного, використовується перший, хто публікує теми UOrb [vehicle_attitude](../msg_docs/VehicleAttitude.md) або [vehicle_local_position](../msg_docs/VehicleLocalPosition.md).
Якщо жоден з них не увімкнено, то теми не публікуються.
:::
:::info
Для FMU-v2 (тільки) вам також потрібно збудувати PX4 з включенням необхідного оцінювача (наприклад, EKF2: `make px4_fmu-v2`, LPE: `make px4_fmu-v2_lpe`).
Це потрібно, оскільки FMU-v2 має недостатньо ресурсів для включення обох оцінювачів.
Інші версії FMU для Pixhawk включають обидва оцінювачі.
:::
docs/uk/advanced/system_tunes.md
+92
View File
@@ -0,0 +1,92 @@
# Системи звукового оповіщення
PX4 визначає ряд [стандартних мелодій/тем](../getting_started/tunes.md), які використовуються для забезпечення аудіо-повідомлень про важливі стани системи та проблеми (наприклад, запуск системи, успішне готування до роботи, попередження про заряд батареї і т. д.).
Мелодії вказуються за допомогою рядків (у форматі [ANSI Music notation](http://artscene.textfiles.com/ansimusic/information/ansimtech.txt)) та відтворюються за допомогою коду, використовуючи бібліотеку [tunes](https://github.com/PX4/PX4-Autopilot/tree/main/src/lib/tunes).
Бібліотека мелодій також містить список стандартних мелодій системи - див. [lib/tunes/tune_definition.desc](https://github.com/PX4/PX4-Autopilot/blob/main/src/lib/tunes/tune_definition.desc).
У PX4 також є модуль, який можна використовувати для відтворення (тестування) стандартних мелодій або користувацьких мелодій.
У цій темі наведено загальні вказівки щодо створення власних мелодій і додавання/заміни системних тонів/мелодій сповіщень.
## Формування Звукових Повідомлень
Рядки мелодій визначаються за допомогою [ANSI Music notation](http://artscene.textfiles.com/ansimusic/information/ansimtech.txt).
:::tip
Більше інформації про формат можна знайти в [QBasic PLAY statement](https://en.wikibooks.org/wiki/QBasic/Appendix#PLAY) (Wikibooks) та було відтворено в [tune_definition.desc](https://github.com/PX4/PX4-Autopilot/blob/main/src/lib/tunes/tune_definition.desc).
:::
Найпростіший спосіб створити нову мелодію – скористатися музичним редактором.
Це дозволяє редагувати музику та відтворювати її на вашому комп'ютері, а потім експортувати в формат, який можна відтворити за допомогою PX4.
Музика ANSI була популярною за часів систем ANSI BBS, тому найкращими інструментами редагування є утиліти DOS.
У Windows одним із варіантів є використання _Melody Master_ у _Dosbox_.
Кроки використання програмного забезпечення:
1. Завантажити [DosBox](http://www.dosbox.com/) і встановити додаток
2. Завантажити [Майстер Мелодій](ftp://archives.thebbs.org/ansi_utilities/melody21.zip) та розпакувати в нову директорію
3. Відкрийте консоль _Dosbox_
4. Змонтуйте основний каталог мелодій у Dosbox, як показано нижче:
```sh
mount c C:\<path_to_directory\Melody21
```
5. Запустіть _Melody Master_ за допомогою таких команд
```sh
c:
start
```
6. YПотім ви матимете можливість клацнути кілька екранів, а потім натиснути **1**, щоб відобразити _Master Melody_:
![Melody Master 2.1](../../assets/tunes/tunes_melody_master_2_1.jpg)
У нижній половині екрана надаються корисні поради щодо комбінацій клавіш для використання інструменту (стрілки для переміщення в ноті, цифри для вибору тривалості ноти тощо).
7. Коли ви будете готові зберегти музику:
- Натисніть **F2**, щоб дати мелодії назву та зберегти її у підпапці _/Music_ вашої інсталяції Melody Master.
- Натисніть **F7**, прокрутіть список вихідних форматів праворуч, щоб перейти до ANSI.
Файл буде експортовано в _кореневий каталог_ каталогу Melody Master (з такою самою назвою та розширенням типу файлу).
8. Відкрийте файл.
Результат може виглядати так:
![ANSI Output from file](../../assets/tunes/tune_musicmaker_ansi_output.png)
9. ядок, який можна відтворити в PX4, це біт між `MNT` і `P64`: `150L1O3DL16CL32<B>C<AEL16A`
## Тестування тунелів
Коли ви будете готові спробувати нову мелодію на PX4, скористайтеся бібліотекою [tune_control](../modules/modules_system.md#tune-control).
Наприклад, щоб перевірити мелодію, яку ми «створили» вище, ви повинні ввести таку команду на консолі чи оболонці (наприклад, [MAVLink Shell](../debug/mavlink_shell.md)):
```sh
tune_control play -m "150L1O3DL16CL32<B>C<AEL16A"
```
:::info
OЗа замовчуванням, `tune_control` присутній лише на реальному обладнанні (не у симуляторі).
:::
## Заміна існуючих звукових повідомлень
Мелодії визначаються в файлі [tune_definition.desc](https://github.com/PX4/PX4-Autopilot/blob/main/src/lib/tunes/tune_definition.desc).
Якщо вам потрібно лише замінити існуючу мелодію, ви можете замінити файл у власному репозиторії (fork) та оновити рядки мелодій, визначені в `PX4_DEFINE_TUNE`.
## Додати нову мелодію
TBD.
<!--
1. Assumption is that you need to define a new `PX4_DEFINE_TUNE` with its own number in the file.
2. Need to look at how tunes are played. Problem for another day.
-->