fly316/PX4-Autopilot
7
0
Fork 0
mirror of https://gitee.com/mirrors_PX4/PX4-Autopilot.git synced 2026-10-23 11:33:34 +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/concept/architecture.md
+157
View File
@@ -0,0 +1,157 @@
# Огляд архітектури PX4
PX4 складається із двох головних шарів: [набору політного ПЗ](#flight-stack), що є системою керування та оцінки польоту, та [проміжного ПЗ](#middleware), яке є загальним робототехнічним прошарком ПЗ, що може підтримувати будь-який тип автономного робота, забезпечуючи внутрішній та зовнішній зв'язок та інтеграцію апаратного забезпечення.
Всі [планери](../airframes/README.md) PX4 мають окрему кодову базу (включаючи й інші роботизовані системи, такі як човни, ровери, підводні човни тощо). Побудова системи є [реакційною](http://www.reactivemanifesto.org), це означає що:
- Весь функціонал розділений на взаємозамінні та придатні для повторного використання компоненти
- Зв'язок зроблено через асинхронне передавання повідомлень
- Система може дати раду різним робочим навантаженням
<a id="architecture"></a>
## Високорівнева архітектура ПЗ
На діаграмі нижче показано детальний огляд будівельних блоків PX4.
Верхня частина діаграми містить блоки проміжного ПЗ, тоді як нижня частина - компоненти набору польотного ПЗ.
![PX4 Architecture](../../assets/diagrams/PX4_Architecture.svg)
<!-- This diagram can be updated from
[here](https://drive.google.com/file/d/0B1TDW9ajamYkaGx3R0xGb1NaeU0/view?usp=sharing)
and opened with draw.io Diagrams. You might need to request access if you
don't have a px4.io Google account.
Caution: it can happen that after exporting some of the arrows are wrong. In
that case zoom into the graph until the arrows are correct, and then export
again. -->
Вихідний код розділено на самодостатні модулі/програми (показано на діаграмі `моноширинним` шрифтом).
Зазвичай один блок відповідає одному модулю.
:::tip
Під час виконання можна переглянути який з модулів виконується за допомогою команди `top` в консолі, а кожен модуль може бути запущено окремо за допомогою `<module_name> start/stop`.
Хоча команда `top` характерна для оболонки NuttX, інші команди можуть бути використані також в оболонці SITL (pxh>).
Для додаткової інформації про кожен з цих модулів дивіться [Довідник команд та модулів](../modules/modules_main.md).
:::
Стрілки показують плин інформації для _найважливіших_ зв'язків між модулями.
В реальності зв'язків набагато більше ніж показано, а деякі дані (наприклад параметри) отримуються більшістю модулів.
Модулі спілкуються один з одним через шину повідомлень публікації/підписки яка називається [uORB](../middleware/uorb.md).
Використання схеми публікації/підписки означає, що:
- Система реакційна — тобто є асинхронною та миттєво оновиться при наявності нових даних
- Всі операції та комунікації повністю розпаралелено
- Системний компонент може споживати дані звідки завгодно у спосіб безпечний для потоків
:::info
Ця архітектура дозволяє швидко і легко замінити кожен з цих блоків навіть під час виконання.
:::
### Набір польотного ПЗ
Набір польотного ПЗ є колекцією алгоритмів керування, навігації та спрямування для автономних дронів.
Він включає контролери для планерів з фіксованим крилом, мультироторів та ВЗІП, а також спостерігача орієнтації та позиції.
У наступній діаграмі показано огляд будівельних блоків набору ПЗ для польоту.
Він містить повний конвеєр від датчиків, вхідних даних РК та контролера автономного польоту (Navigator), до двигуна або управління сервоприводами (Actuators).
![Високорівнева схема набору політного ПЗ у PX4](../../assets/diagrams/PX4_High-Level_Flight-Stack.svg)
<!-- This diagram can be updated from
[here](https://drive.google.com/a/px4.io/file/d/15J0eCL77fHbItA249epT3i2iOx4VwJGI/view?usp=sharing)
and opened with draw.io Diagrams. You might need to request access if you
don't have a px4.io Google account.
Caution: it can happen that after exporting some of the arrows are wrong. In
that case zoom into the graph until the arrows are correct, and then export
again. -->
**Спостерігач** приймає вхідні дані з одного або більше датчиків, поєднує їх та обчислює стан рухомого засобу (наприклад орієнтацію з даних датчика ІВП або ж IMU).
**Контролер** - це компонент, який приймає на вхід заданий і виміряний або ж визначений стан (змінну процесу).
Його мета - скорегувати значення змінної процесу, таким чином, щоб вона відповідала заданому значенню.
Вихідні дані - це корекційні значення, щоб врешті-решт досягти заданих.
Наприклад, контролер позиції приймає задані значення позиції на вході, змінна процесу є значенням позиції що оцінюється, а вихід - це орієнтація та задане значення газу, що рухає засіб до потрібної позиції.
**Змішувач** приймає команди примусу (наприклад "повернути вправо") і перекладає їх на окремі команди двигуна, при цьому гарантуючи, що певні межі не перевищено.
Цей переклад є специфічним для типу засобу і залежить від різних факторів такі як розташування двигунів відносно центру мас або інерція обертання засобу.
<a id="middleware"></a>
### Проміжне програмне забезпечення
[Проміжне ПЗ](../middleware/README.md) головним чином складається з драйверів для вбудованих датчиків, зв'язку із зовнішнім світом (допоміжним комп'ютером, GCS і т ін.) та шиною повідомлень uORB.
Крім того, в проміжне ПЗ включено [шар симуляції](../simulation/README.md), який дозволяє коду PX4 запускатися на настільній операційній системі та контролювати модельований комп'ютером рухомий засіб у симульованому "світі".
## Темпи оновлення даних
Оскільки модулі очікують оновлень повідомлень, зазвичай драйвери визначають як швидко оновлюється стан модуля.
Більшість драйверів ІВП роблять вибірку даних на частоті 1 кГц, інтегрують їх і публікують з частотою 250 Гц.
Інші частини системи, такі як `navigator` не потребують такої високої швидкості поновлення даних тому виконуються значно повільніше.
Частота оновлення повідомлень на системі може бути [перевірена](../middleware/uorb.md) в реальному часі, запустивши команду `uorb top`.
<a id="runtime-environment"></a>
## Середовище виконання
PX4 запускається на різних операційних системах які надають POSIX-API (наприклад, Linux, macOS, NuttX або QuRT).
Вони також повинні мати якусь форму планування завдань в реальному часі (наприклад FIFO).
Комунікація між модулями (за допомогою [uORB](../middleware/uorb.md)) заснована на розділюваній пам'яті.
Усе проміжне ПЗ PX4 виконується в єдиному адресному просторі, тобто пам'ять розділена між усіма модулями.
:::info
Система створена так, щоб з мінімальними зусиллями, можна було б запустити кожен модуль в окремому адресному просторі (частини, які необхідно буде змінити включають `uORB`, `parameter interface`, `dataman` та `perf`).
:::
Існує 2 різні способи запуску модуля:
- **Завдання**: Модуль виконується у своєму власному завданні з власним стеком і пріоритетом процесу.
- **Завдання робочої черги**: Модуль виконується в спільній робочій черзі, розділяючи той самий стек та пріоритет потоку робочої черги як і інші модулі в черзі.
- Усі завдання повинні поводитися скооперовано, оскільки вони не можуть переривати одне одного.
- Декілька _завдань робочої черги_ можуть запускатися у черзі, а також може бути кілька черг.
- _Завдання робочої черги_ планується вказанням визначеного часу у майбутньому або через зворотний виклик "поновлення теми" uORB.
Перевага запуску модулів у робочій черзі полягає в тому, що це використовує менше ОЗП, і потенційно призводить до меншої кількості перемикань завдань.
Недоліки в тому, що _завданням робочої черги_ не дозволено перебувати в режимі сну або опитувати наявність повідомлення, або виконувати блокуючу операцію вводу/виводу (наприклад, читання з файлу).
Довгострокові завдання (що виконують важкі обчислення) повинні потенційно також запускатися в окремому завданні або принаймні в окремій робочий черзі.
:::info
Завдання запущені в робочій черзі не з'являються у виводі [`top`](../modules/modules_command.md#top) (видно тільки робочі як такі, наприклад `wq:lp_default`).
Використовуйте [`work_queue status`](../modules/modules_system.md#work-queue) для показу всіх активних елементів черги.
:::
### Фонові завдання
`px4_task_spawn_cmd()` використовується для запуску нових завдань (NuttX) або потоків (POSIX - Linux/macOS), які працюють незалежно від (батьківського) завдання, що їх викликало:
```cpp
independent_task = px4_task_spawn_cmd(
"commander", // Process name
SCHED_DEFAULT, // Scheduling type (RR or FIFO)
SCHED_PRIORITY_DEFAULT + 40, // Scheduling priority
3600, // Stack size of the new task or thread
commander_thread_main, // Task (or thread) main function
(char * const *)&argv[0] // Void pointer to pass to the new task
// (here the commandline arguments).
);
```
### Інформація для певної ОС
#### NuttX
[NuttX](https://nuttx.apache.org//) є основною RTOS для запуску PX4 на платі керування польотами.
Вона має відкритий вихідний код (під BSD ліцензією), легка, ефективна і дуже стабільна.
Модулі виконуються як завдання: вони мають свої списки дескрипторів файлів, але мають єдиний адресний простір.
Завдання все ще може запустити один або кілька потоків, які розділяють той самий список дескрипторів файлів.
Кожне завдання/поток має стек фіксованого розміру, є періодичне завдання, яке перевіряє, що в всіх стеках залишилося достатньо вільного місця (засновано на розфарбовуванні стеку).
#### Linux/macOS
На Linux або macOS, PX4 виконується в одному процесі, а модулі запускаються у своїх потоках (бо немає різниці між завданнями та потоками як на NuttX).
docs/uk/concept/control_allocation.md
+81
View File
@@ -0,0 +1,81 @@
# Розподіл керування (змішування)
:::info
Розподіл керування замінює застарілий підхід змішування, який використовувався в PX4 v1.13 або раніше.
Документацію по PX4 v1.13 дивіться в: [Змішування та приводи](https://docs.px4.io/v1.13/en/concept/mixing.html), [Файли геометрії](https://docs.px4.io/v1.13/en/concept/geometry_files.html) та [Додавання налаштувань нового планера](https://docs.px4.io/v1.13/en/dev_airframes/adding_a_new_frame.html).
:::
PX4 приймає бажані команди моменту та тяги від основних контролерів і перекладає їх у команди приводів, які керують двигунами чи сервоприводами.
Переклад залежить від фізичної геометрії планеру.
Скажемо наприклад, за командою моменту "повернути праворуч":
- Літак з одним сервоприводом на елерон накаже одному сервоприводу підняти, а іншому опустити їх.
- Мультикоптер порине вправо змінивши швидкість всіх двигунів.
PX4 відокремлює цю логіку перекладу, що називається "змішуванням", від контролера позиції/швидкості.
Це гарантує, що основним контролерам не потрібна особлива обробка для кожної геометрії планерів і значно покращує повторне використання.
Крім того, PX4 абстрагує відображення функцій виводу до конкретних апаратних виходів.
Це означає, що будь-який двигун або сервопривід може бути призначений майже на будь-який фізичний вивід.
<!-- https://docs.google.com/drawings/d/1Li9YhTLc3yX6mGX0iSOfItHXvaUhevO2DRZwuxPQ1PI/edit -->
![Огляд змішування](../../assets/diagrams/mixing_overview.png)
## Конвеєр керування приводами
Огляд конвеєрів змішування в термінах модулів та uORB (натисніть для показу в повноекранному режимі):
<!-- https://drive.google.com/file/d/1L2IoxsyB4GAWE-s82R_x42mVXW_IDlHP/view?usp=sharing -->
![Pipeline Overview](../../assets/concepts/control_allocation_pipeline.png)
Примітки:
- Регулятор швидкості видає задані значення моменту та тяги
- модуль `control_allocator`:
- обробляє різні геометрії на основі параметрів конфігурації
- робить змішування
- обробляє відмови двигунів
- публікує сигнали керування двигуном та сервоприводами
- публікує корекції для сервоприводів окремо щоб їх можна було додати як відхилення при [перевірці приводів](../config/actuators.md#actuator-testing) (використовуючи тестувальні повзунки).
- Драйвери виходу:
- обробляють апаратну ініціалізацію та оновлення
- використовують поділювану бібліотеку [src/libs/mixer_module](https://github.com/PX4/PX4-Autopilot/blob/main/src/lib/mixer_module/).
Драйвер визначає префікс параметру, наприклад `PWM_MAIN`, який бібліотека використовує для налаштування.
Її головне завдання зробити вибірку з вхідних дані та призначити правильні дані на виходи засновуючись на встановлених користувачем значеннях параметрів `<param_prefix>_FUNCx`.
Наприклад, якщо `PWM_MAIN_FUNC3` встановлено у **Motor 2**, це означає що на 2-й двигун з `actuator_motors` встановлено 3-й вивід.
- функції виводу визначаються у [src/lib/mixer_module/output_functions.yaml](https://github.com/PX4/PX4-Autopilot/blob/main/src/lib/mixer_module/output_functions.yaml).
- якщо ви хочете керувати виводом з MAVLink, встановіть відповідну вихідну функцію в **Offboard Actuator Set x**, а потім відправте MAVLink команду [MAV_CMD_DO_SETUATOR](https://mavlink.io/en/messages/common.html#MAV_CMD_DO_SET_ACTUATOR).
## Додавання нової геометрії або функції виводу
Дивіться [цей коміт](https://github.com/PX4/PX4-Autopilot/commit/5cdb6fbd8e1352dcb94bd58918da405f8ff930d7) як додати нову геометрію.
Інтерфейс QGC автоматично покаже правильний інтерфейс налаштування, коли в новій геометрії встановлено [CA_AIRFRAME](../advanced_config/parameter_reference.md#CA_AIRFRAME).
[Цей коміт](https://github.com/PX4/PX4-Autopilot/commit/a65533b46986e32254b64b7c92469afb8178e370) показує як додати нову функцію виходу.
Будь-яка тема uORB може бути підписана і закріплена за функцією.
Зауважте що параметри для розподілу керування визначені у [src/modules/control_allocator/module.yaml](https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/control_allocator/module.yaml) Схема для цього файлу є [тут](https://github.com/PX4/PX4-Autopilot/blob/main/validation/module_schema.yaml#L440=) (конкретніше, шукайте термін `mixer:`
## Встановлення геометрії планеру за замовчуванням
Коли [додаєте нові налаштування планера](../dev_airframes/adding_a_new_frame.md), встановіть відповідне значення [CA_AIRFRAME](../advanced_config/parameter_reference.md#CA_AIRFRAME) змішувача та інші значення за замовчуванням для геометрії.
Ви можете це побачити наприклад, у файлі конфігурації планера [13200_generic_vtol_tailsitter](https://github.com/PX4/PX4-Autopilot/blob/main/ROMFS/px4fmu_common/init.d/airframes/13200_generic_vtol_tailsitter)
```sh
...
param set-default CA_AIRFRAME 4
param set-default CA_ROTOR_COUNT 2
param set-default CA_ROTOR0_KM -0.05
param set-default CA_ROTOR0_PY 0.2
...
```
## Налаштування геометрії та виходів
Геометрія для плати та параметри за замовчуванням для рухомого засобу встановлюються (з файлу налаштувань планера) коли планер обирається у QGroundControl: [Основне налаштування > Планери](../config/airframe.md).
Параметри геометрії та відображення виводу для певних планерів та апаратного забезпечення польотних контролерів потім налаштовується у QGroundControl на екрані **Приводи**: [Базове налаштування > Налаштування та перевірка приводу](../config/actuators.md).
docs/uk/concept/events_interface.md
+177
View File
@@ -0,0 +1,177 @@
# Інтерфейс подій
<Badge type="tip" text="PX4 v1.13" />
The _Events Interface_ provides a system-wide API for notification of events, which are published to GCSs via the _MAVLink Events Service_ (to GCSs and other components) and also stored in [system logs](../dev_log/logging.md).
Інтерфейс може використовуватися для публікації подій змін стану або будь-якого іншого типу події, включаючи такі речі, як стан готовності, завершення калібрування і досягнення цільової висоти злету.
:::info
Інтерфейс подій замінить використання викликів `mavlink_log_*` у коді PX4, (а також повідомлень `STATUS_TEXT` у MAVLink) для сповіщення про події в релізах PX4 після v1.13 та новіше.
Буде проміжний період коли [обидва підходи будуть підтримуватися](#backward-compatibility).
:::
## Використання
### Основне
А потім визначте та надішліть подію з бажаного місця коду:
```cpp
#include <px4_platform_common/events.h>
```
А потім визначте та надішліть подію з бажаного місця коду:
```cpp
events::send(events::ID("mymodule_test"), events::Log::Info, "Test Message");
```
#### Зворотна сумісність
Для старих версій GCS без підтримки інтерфейсу подій, PX4 на цей момент надсилає також всі події як `mavlink_log_*` `STATUSTEXT` повідомлення.
Крім того, повідомлення має бути промарковано додатковою табуляцією (`\t`), щоб нові GCS змогли проігнорувати це і показати тільки подію.
Отже, коли ви додаєте подію, не забудьте також додати виклик `mavlink_log_`. Наприклад:
```cpp
mavlink_log_info(mavlink_log_pub, "Test Message\t");
events::send(events::ID("mymodule_test"), events::Log::Info, "Test Message");
```
Вище - мінімальний приклад, цей - у більш розширеному вигляді.
### Докладно
Пояснення та вимоги:
```cpp
uint8_t arg1 = 0;
float arg2 = -1.f;
/* EVENT
* @description
* This is the detailed event description.
*
* - value of arg1: {1}
* - value of arg2: {2:.1}
*
* <profile name="dev">
* (This paragraph is only meant to be shown to developers).
* This behavior can be configured with the parameter <param>COM_EXAMPLE</param>.
* </profile>
*
* Link to documentation: <a>https://docs.px4.io</a>
*/
events::send<uint8_t, float>(events::ID("event_name"),
{events::Log::Error, events::LogInternal::Info}, "Event Message", arg1, arg2);
```
Події можуть мати незмінний набір аргументів, які можна вкласти у повідомлення або опис використовуючи шаблонні замінники (наприклад <code>{2:.1m}</code>, дивіться наступний розділ).
- `/* EVENT`: Цей тег вказує, що коментар описує метадані для наступної події.
- **event_name**: ім'я події (`events::ID(event_name)`).
- повинно бути унікальним в межах всього вихідного коду PX4.
Як загальне правило, додайте префікс з назвою модуля або вихідного файлу для великих модулів.
- має бути дійсна назва змінної, тобто не повинна містити пробіли, двокрапки тощо.
- з цього імені отримується 24-бітний ID події за допомогою геш-функції.
Це означає, що до тих пір, поки ім'я події залишається однаковим, ID залишиться тим же.
- **Рівень журналювання**:
- припустимі рівні журналювання такі ж, як і у перерахуванні MAVLink [MAV_SEVERITY](https://mavlink.io/en/messages/common.html#MAV_SEVERITY).
Рівні перелічені за зменшенням важливості:
```plain
Emergency,
Alert,
Critical,
Error,
Warning,
Notice,
Info,
Debug,
Disabled,
```
```
Попередньо ми вказали окремий зовнішній і внутрішній рівень журналювання, які є рівнями для користувачів GCS і в файлі журналу, відповідно: `{events::Log::Error, events::LogInternal::Info}`.
```
- **Повідомлення про подію**:
- Коротке повідомлення про подію в один рядок.
Може мати шаблонні замінники для аргументів (наприклад `{1}`). Для додаткової інформації дивіться нижче. Для додаткової інформації дивіться нижче.
- **Опис події**:
- Докладний, необов'язковий опис події.
- Може бути кілька рядів/абзаців.
- It may contain template placeholders for arguments (e.g. `{2}`) and supported tags (see below)
#### Аргументи та перерахування
Events can have a fixed set of arguments that can be inserted into the message or description using template placeholders (e.g. `{2:.1m}` - see next section).
Припустимі типи: `uint8_t`, `int8_t`, `uint16_t`, `int16_t`, `uint32_t`, `int32_t`, `uint64_t`, `int64_t` та `float`.
Формат тексту для опису повідомлення події:
- Користувацькі або характерні для PX4 перерахування для подій повинні бути визначені у [src/lib/events/enums.json](https://github.com/PX4/PX4-Autopilot/blob/main/src/lib/events/enums.json), та можуть бути використані як аргументи події у формі `events::send<events::px4::enums::my_enum_t>(...)`.
- "Загальні" події MAVLink визначені у [mavlink/libevents/events/common.json](https://github.com/mavlink/libevents/blob/master/events/common.json) та можуть бути використані як аргументи подій у формі `events::send<events::common::enums::my_enum_t>(...)`.
#### Формат тексту
Події записуються відповідно до рівня внутрішнього журналювання, а <a href="../log/flight_review.md">Огляд польоту</a> показує події.
- символи можна екранувати за допомогою \\
Ці символи повинні бути екрановані: '\\\\', '\\<', '\\{'.
- теги що підтримуються:
- Профілі: `<profile name="[!]NAME">CONTENT</profile>`
`CONTENT` буде показано, лише якщо назва збігається з налаштованим профілем.
Це може бути використано, наприклад, щоб приховати інформацію для розробників від кінцевих користувачів.
- URLs: `<a [href="URL"]>CONTENT</a>`.
If `href` is not set, use `CONTENT` as `URL` (i.e.`<a>https://docs.px4.io</a>` is interpreted as `<a href="https://docs.px4.io">https://docs.px4.io</a>`)
- Parameters: `<param>PARAM_NAME</param>`
- не дозволено використовувати вкладені теги того ж типу
- аргументи: шаблонні замінники, що відповідають синтаксису python з індексацією що починається з 1 (замість 0)
- загальна форма: `{ARG_IDX[:.NUM_DECIMAL_DIGITS][UNIT]}`
UNIT:
- m: горизонтальна відстань в метрах
- m_v: вертикальна відстань в метрах
- m^2: площа в метрах квадратних
- m/s: швидкість у метрах в секунду
- C: температура у градусах Цельсія
- `NUM_DECIMAL_DIGITS` підходить тільки для аргументів у вигляді дійсних чисел.
## Логування
Події записуються відповідно до рівня внутрішнього журналювання, а [Огляд польоту](../log/flight_review.md) показує події.
:::info
Огляд польоту завантажує метадані на основі головної гілки PX4, тому, якщо визначення ще немає на головній гілці, огляд зможе показати тільки ID події.
:::
## Імплементація
Метадані для всіх подій вбудовані в окремий JSON файл метаданих (з використанням python скрипту, який сканує весь вихідний код у пошуках викликів подій).
Метадані для всіх подій вбудовані в окремий JSON файл метаданих (з використанням python скрипту, який сканує весь вихідний код у пошуках викликів подій).
### Публікація метаданих події в GCS
Цей процес такий самий як і для [метаданих параметрів](../advanced/parameters_and_configurations.md#publishing-parameter-metadata-to-a-gcs).
Для отримання додаткової інформації див. <a href="../advanced/px4_metadata.md"> Метадані PX4 (трансляція і публікація)</a>.
Цей процес такий самий як і для [метаданих параметрів](../advanced/parameters_and_configurations.md#publishing-parameter-metadata-to-a-gcs).
Для отримання додаткової інформації див. [Метадані PX4 (трансляція і публікація)](../advanced/px4_metadata.md)
docs/uk/concept/flight_modes.md
+120
View File
@@ -0,0 +1,120 @@
# Режими польоту (для розробників)
Modes ("flight modes", "drive modes", and so on) are special operational states that control how the autopilot responds to user input and controls vehicle movement.
Вони вільним чином згруповані у _ручні_, _допоміжні_ та _автономні_ режими, засновуючись на рівні/типі керування що надається автопілотом.
Пілот перемикається між режимами польоту за допомогою перемикачів на пульті дистанційного керування або за допомогою наземної станції керування.
Modes can be implemented as [PX4 internal modes](#px4-internal-modes) running on the flight controller, or as [PX4 external (ROS2) modes](#px4-external-modes) running on a companion computer.
From the perspective of a ground station (MAVLink), the origin of a mode is indistinguishable.
This topic links to documentation for the supported modes, compares PX4 internal and external modes, provides implementation hints, and provides links to how PX4 modes can be used with MAVLink.
## Supported Modes
Not all modes are available (or makes sense), on all vehicle types, and some modes behave differently on different vehicle types.
Mode documentation for the PX4 internal modes are listed below:
- [Flight Modes (Multicopter)](../flight_modes_mc/index.md)
- [Flight Modes (Fixed-Wing)](../flight_modes_fw/index.md)
- [Flight Modes (VTOL)](../flight_modes_vtol/index.md)
- [Drive Modes (Differential Rover)](../flight_modes_rover/differential.md)
- [Drive Modes (Ackermann Rover)](../flight_modes_rover/ackermann.md)
- [Basic Configuration > Flight Modes](../config/flight_mode.md)
## Internal vs External Modes
With some exceptions a mode can be implemented in either the FC or companion computer.
The main considerations are listed below.
PX4 external modes cannot be used in the following cases:
- Modes that need to run on vehicles that don't have a companion computer.
- Modes that require low-level access, strict timing, and/or high update rate requirements.
For example, a multicopter mode that implements direct motor control.
- Safety critical modes, such as [Return mode](../flight_modes_mc/return.md).
- When you can't use ROS (for any reason).
External modes should be considered for all other cases.
They have the following benefits:
- Easier to implement as there is no need to deal with low-level embedded constraints and requirements (such as restricted stack sizes).
- Easier to maintain as the integration API is small, well defined, and stable.
- Porting custom PX4 modes on the flight controller between PX4 versions can be much harder, as often flight modes use interfaces that are considered internal, and allowed to change.
- Process termination of a ROS 2 mode results in a fallback to an internal flight mode (while termination of an internal mode may well crash the vehicle).
- They can override existing modes to provide more advanced features.
You can even override a safety-critical mode with a better versions: if the ROS 2 mode crashes the original mode will be engaged.
- High-level functionality is available, including a better-feature programming environment, and many useful Linux and ROS libraries.
- More available compute to do more advanced processing (e.g. computer vision).
Note that the [PX4 ROS 2 Control Interface](../ros2/px4_ros2_control_interface.md) used to create external modes first appeared in PX4 v1.15 and is still considered experimental.
There are still some limitations, but expect changes and ongoing enhancement.
## PX4 External Modes
PX4 external modes, are written in ROS 2 using the [PX4 ROS 2 Control Interface](../ros2/px4_ros2_control_interface.md) (see link for instructions).
## PX4 Internal Modes
<!--
The specific control behaviour of a mode at any time is determined by a [Flight Task](../concept/flight_tasks.md).
A mode might define one or more tasks that define variations of the mode behavior, for example whether inputs are treated as acceleration or velocity setpoints.
The task that is used is normally defined in a parameter, and selected in [src/modules/flight_mode_manager/FlightModeManager.cpp](https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/flight_mode_manager/FlightModeManager.cpp#L266-L285)
Name the relevant modules in which code directly related to flight modes is defined.
Name any base classes that modes must/should derive from
Explain the core things you need to do to make a mode work
Very high level architecture
-->
### Mode Restrictions
Some modes only make sense only under specific pre-flight and in-flight conditions.
For example, a manual control mode should not be used unless the system has a manual controller.
PX4 modes can specify these conditions as _restrictions_.
For internal modes the types of restrictions are listed in the [FailsafeFlags](../msg_docs/FailsafeFlags.md) uORB topic under "Per mode requirements" (duplicated below)
```text
# Per-mode requirements
mode_req_angular_velocity
mode_req_attitude
mode_req_local_alt
mode_req_local_position
mode_req_local_position_relaxed
mode_req_global_position
mode_req_mission
mode_req_offboard_signal
mode_req_home_position
mode_req_wind_and_flight_time_compliance # if set, mode cannot be entered if wind or flight time limit exceeded
mode_req_prevent_arming # if set, cannot arm while in this mode
mode_req_manual_control
mode_req_other # other requirements, not covered above (for external modes)
```
If the condition of restriction is not met:
- Озброєння неможливе, коли вибрано режим
- коли вже озброєний, режим не можна вибрати
- коли озброєний і обраний режим, відповідний аварійний режим спрацьовує (наприклад, втрата RC для вимоги до керування вручну).
Check [Safety (Failsafe) Configuration](../config/safety.md) for how to configure failsafe behaviour.
This is the corresponding flow diagram for the manual control flag (`mode_req_manual_control`):
The requirements for all modes are set in `getModeRequirements()` in [src/modules/commander/ModeUtil/mode_requirements.cpp](https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/commander/ModeUtil/mode_requirements.cpp#L46).
When adding a new mode you will need to add appropriate requirements in that method.
:::tip
Readers may note that this image is from [PX4 ROS2 Control Interface > Failsafes and mode requirements](../ros2/px4_ros2_control_interface.md#failsafes-and-mode-requirements).
The requirements and concepts are the same (though defined in different places).
The main difference is that ROS 2 modes _infer_ the correct requirements to use, while modes in PX4 source code must explicitly specify them.
:::
## MAVLink Integration
PX4 implements the MAVLink [Standard Modes Protocol](../mavlink/standard_modes.md) from PX4 v1.15.
This can be used to discover all modes and the current mode, and to set the current mode.
docs/uk/concept/flight_tasks.md
+221
View File
@@ -0,0 +1,221 @@
# Польотні завдання
_Польотні завдання_ використовуються у [Режимах польоту](../concept/flight_modes.md) для забезпечення певної поведінки під час руху, наприклад "слідуй за мною" або пом'якшування польоту.
## Загальний огляд
Польотне завдання є класом в програмному каркасі польотних завдань похідним від базового класу [FlightTask](https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/flight_mode_manager/tasks/FlightTask/FlightTask.hpp). Його мета - генерувати задані значення для контролера з довільних вхідних даних, де кожне завдання реалізує бажану поведінку рухомого засобу для певного режиму.
Розробники як правило перевизначаються віртуальні методи `activate()` та `update()` викликаючи мінімальну реалізацію базового завдання та розширяючи її реалізацією бажаної поведінки.
Метод `activate()` викликається при перемиканні на завдання та дозволяє ініціалізувати його стан й м'яко перебрати на себе функціонал базуючись на заданих значеннях які попереднє завдання тільки передало.
`update()` викликається на кожній ітерації циклу під час виконання і містить реалізацію базової поведінки створення заданих значень.
За загальним правилом, завдання містяться у піддиректорії [PX4-Autopilot/src/modules/flight_mode_manager/tasks](https://github.com/PX4/PX4-Autopilot/tree/main/src/modules/flight_mode_manager/tasks) за назвою завдання, а назви файлів вихідного коду мають префікс "FlightTask".
:::info
Відео огляди із зібрань розробників PX4 [надано нижче](#video).
:::
## Створення польотного завдання
Нижченаведені інструкції можуть бути використані для створення завдання _MyTask_:
1. Створіть каталог для нової польотної задачі в [PX4-Autopilot/src/modules/flight_mode_manager/tasks](https://github.com/PX4/PX4-Autopilot/tree/main/src/modules/flight_mode_manager/tasks).
За правилами директорія називається за завданням, тому ми назвемо її **/MyTask**.
```sh
mkdir PX4-Autopilot/src/modules/flight_mode_manager/tasks/MyTask
```
2. Створіть порожні файли вихідного коду та налаштування _cmake_ для нового завдання у директорії _MyTask_ використовуючи префікс "FlightTask":
- CMakeLists.txt
- FlightTaskMyTask.hpp
- FlightTaskMyTask.cpp
3. Оновіть **CMakeLists.txt** для нового завдання
- Скопіюйте вміст **CMakeLists.txt** з іншого завдання, наприклад, [Orbit/CMakeLists.txt](https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/flight_mode_manager/tasks/Orbit/CMakeLists.txt)
- Оновіть відмітку про авторське право до поточного року
```cmake
############################################################################
#
# Copyright (c) 2021 PX4 Development Team. All rights reserved.
#
```
- Модифікуйте код щоб він відповідав новому завданню, наприклад замініть `FlightTaskOrbit` на `FlightTaskMyTask`.
Код буде виглядати приблизно так:
```cmake
px4_add_library(FlightTaskMyTask
FlightTaskMyTask.cpp
)
target_link_libraries(FlightTaskMyTask PUBLIC FlightTask)
target_include_directories(FlightTaskMyTask PUBLIC ${CMAKE_CURRENT_SOURCE_DIR})
```
4. Оновіть файл заголовків (у цьому випадку **FlightTaskMyTask. pp**): Більшість завдань повторно реалізує віртуальні методи `activate()` і `update()`, в цьому прикладі ми також маємо приватну змінну.
```cpp
#pragma once
#include "FlightTask.hpp"
class FlightTaskMyTask : public FlightTask
{
public:
FlightTaskMyTask() = default;
virtual ~FlightTaskMyTask() = default;
bool update();
bool activate(const trajectory_setpoint_s &last_setpoint) override;
private:
float _origin_z{0.f};
};
```
5. Оновіть cpp файли відповідно.
Цей приклад надає як просту реалізацію **FlightTaskMyTask.cpp**, яка просто показує, що методи завдань викликаються.
```cpp
#include "FlightTaskMyTask.hpp"
bool FlightTaskMyTask::activate(const trajectory_setpoint_s &last_setpoint)
{
bool ret = FlightTask::activate(last_setpoint);
PX4_INFO("FlightTaskMyTask activate was called! ret: %d", ret); // report if activation was successful
return ret;
}
bool FlightTaskMyTask::update()
{
PX4_INFO("FlightTaskMyTask update was called!"); // report update
return true;
}
```
6. Add the new task to the list of tasks to be built in [PX4-Autopilot/src/modules/flight_mode_manager/CMakeLists.txt](https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/flight_mode_manager/CMakeLists.txt#L41).
```cmake
...
list(APPEND flight_tasks_all
Auto
Descend
...
ManualPositionSmoothVel
Transition
MyTask
)
...
```
::: tip
The task added above will be built on all boards, including those with constrained flash such as Pixhawk FMUv2.
If your task is not indended for use on boards with constrained flash it should instead be added to the conditional block shown below (as shown).
```cmake
...
if(NOT px4_constrained_flash_build)
list(APPEND flight_tasks_all
AutoFollowTarget
Orbit
MyTask
)
endif()
...
```
:::
7. Оновіть режим польоту, щоб переконатися, що завдання було викликано.
Зазвичай для обрання певного польотного завдання використовується параметр.
Наприклад, щоб активувати наше нове завдання `MyTask` в позиційному режимі мультикоптера:
- Оновіть `MPC_POS_MODE` ([multicopter_position_mode_params.](https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/mc_pos_control/multicopter_position_mode_params.c)), щоб додати варіант для вибору "MyTask", якщо параметр має раніше невикористане значення, наприклад 5:
```c
...
* @value 0 Direct velocity
* @value 3 Smoothed velocity
* @value 4 Acceleration based
* @value 5 My task
* @group Multicopter Position Control
*/
PARAM_DEFINE_INT32(MPC_POS_MODE, 5);
```
- Додайте мітку case для нового варіанту в операторі switch для параметра в [FlightModeManager.cpp](https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/flight_mode_manager/FlightModeManager.cpp#L266-L285), щоб увімкнути завдання коли `_param_mpc_pos_mode` має відповідне значення.
```cpp
...
// manual position control
...
switch (_param_mpc_pos_mode.get()) {
...
case 3:
error = switchTask(FlightTaskIndex::ManualPositionSmoothVel);
break;
case 5: // Add case for new task: MyTask
error = switchTask(FlightTaskIndex::MyTask);
break;
case 4:
....
...
```
## Перевірка нового польотного завдання
Щоб перевірити польотне завдання треба запустити рухомий засіб з увімкненим завданням.
Для прикладу вище це означає встановити параметр `MPC_POS_MODE` у 5, злетіти та перемикнути засіб у [Режим позиціювання](../flight_modes_mc/position.md).
:::info
Завдання, визначене вище, повинно перевірятися тільки на симуляторі.
Код не створює заданих значень, тому засіб не полетить.
:::
Зберіть симуляцію SITL (gazebo-classic)
```sh
make px4_sitl gazebo-classic
```
Відкрийте QGroundControl (якщо не відкрито, жодне повідомлення не буде надруковано).
В консолі, злетіть та перемкніться у режим позиціювання:
```sh
pxh> commander takeoff
pxh> commander mode posctl
```
Консоль постійно буде показувати: `INFO [FlightTaskMyTask] FlightTaskMyTask update was called!`.
Якщо ви хочете змінити режим польоту на інший, ви можете ввести команду для зміни режиму, наприклад `commander mode altctl`.
## Відео
Наступні відео дають огляд польотних завдань в PX4.
Перше охоплює стан програмного каркаса для польотних завдань в PX4 v1.9.
Друге - це оновлення, яке охоплює зміни в PX4 v1.11.
### Огляд архітектури польотних завдань PX4 (PX4 Developer Summit 2019)
Опис того, як працюють режими польоту у PX4 v1.9 (Dennis Mannhart, Matthias Grob).
<lite-youtube videoid="-dkQG8YLffc" title="PX4 Flight Task Architecture Overview"/>
<!-- datestamp:video:youtube:20190704:PX4 Flight Task Architecture Overview — PX4 Developer Summit 2019 -->
### Огляд управління мультикоптером від датчиків до двигунів (PX4 Developer Summit Virtual 2020)
<lite-youtube videoid="orvng_11ngQ" params="start=560" title="Overview of multicopter control from sensors to motors"/>
<!-- datestamp:video:youtube:20200720:Overview of multicopter control from sensors to motors — PX4 Developer Summit Virtual 2020 From 9min20sec - Section on flight tasks-->
Відповідний розділ цього відео з оновленою інформацією про польотні завдання в PX4 v11.1 на (9 мін. 20 сек.).
[Слайди знаходяться тут (PDF)](https://static.sched.com/hosted_files/px4developersummitvirtual2020/1b/PX4%20Developer%20Summit%202020%20-%20Overview%20of%20multicopter%20control%20from%20sensors%20to%20motors.pdf), відповідні слайди - 9 та 12.
docs/uk/concept/index.md
+3
View File
@@ -0,0 +1,3 @@
# Поняття
Цей розділ містить теми про [Системну архітектуру PX4](../concept/architecture.md) та інші основні поняття.
docs/uk/concept/pwm_limit.md
+27
View File
@@ -0,0 +1,27 @@
# Скінченний автомат PWM_limit
`Скінченний автомат PWM_limit` керує виходами ШІМ як функцією входів готового і попередньо готового стану.
Забезпечує затримку між твердженням стану "готовності" та нарощуванням тяги при твердженні сигналу готовності.
## Короткий опис
**Вхідні дані**
- готовий: стверджено щоб дозволити небезпечні дії, такі як обертання пропелерів
- попередньо готовий: стверджено щоб дозволити безпечні дії, такі як рух керівних поверхонь
- цей вхід перекриває поточний стан
- ствердження попередньо готового стану негайно примушує до поведінки стану ON незалежно від поточного стану
- відкидання попередньо готового стану повертає поведінку до поточного стану
**Стани**
- INIT та OFF
- ШІМ виходи встановлені у стан неготовності.
- RAMP
- ШІМ виходи нарощуються зі стану неготовності до мінімальних значень.
- УВІМК
- ШІМ виходи встановлюються відповідно до керівних значень.
## Діаграма зміну стану
![PWM Limit state machine diagram](../../assets/diagrams/pwm_limit_state_diagram.svg)
docs/uk/concept/px4_systems_architecture.md
+52
View File
@@ -0,0 +1,52 @@
# Архітектура системи PX4
Нижче наведено огляд апаратного та програмного забезпечення на PX4 для двох "типових" систем PX4; перша має лише польотний контролер, а друга має польотний контролер і супутній комп'ютер (також відомий як "комп'ютер політних завдань").
:::info
[Огляд архітектури PX4](../concept/architecture.md) надає інформацію про набір польотного програмного забезпечення та проміжного ПЗ.
Зовнішні API охоплено в розділах [ROS](../ros/README.md) та [MAVSDK](https://mavsdk.mavlink.io/main/en/).
:::
## Лише польотний контролер
На діаграмі нижче показано загальний огляд типової "простої" системи PX4 на основі польотного контролера.
![PX4 architecture - FC only system](../../assets/diagrams/px4_arch_fc.svg)
<!-- Source for drawing: https://docs.google.com/drawings/d/1_2n43WrbkWTs1kz0w0avVEeebJbfTj5SSqvCmvSOBdU/edit -->
Апаратне забезпечення складається з
- [Політного контролера](../flight_controller/README.md) (запускає набір польотного ПЗ PX4). Часто включає внутрішні ІВП, компас та барометр.
- [Електронного регулятора ходу двигунів](../peripherals/esc_motors.md) під'єднаного до [виводів ШІМ](../peripherals/pwm_escs_and_servo.md), [DroneCAN](../dronecan/escs.md) (DroneCAN дозволяє двонапрямну комунікацію, не в одному напрямку як показано) або іншої шини.
- Sensors ([GPS](../gps_compass/index.md), [compass](../gps_compass/index.md), distance sensors, barometers, optical flow, barometers, ADSB transponders, etc.) connected via I2C, SPI, CAN, UART etc.
- [Камера](../camera/index.md) або інше корисне навантаження. Камери можуть бути підключені до ШІМ виходів або за допомогою MAVLink.
- [Telemetry radios](../telemetry/index.md) for connecting to a ground station computer/software.
- [Система радіо керування](../getting_started/rc_transmitter_receiver.md) для ручного керування
Ліва частина діаграми показує набір програмного забезпечення, що по горизонталі (приблизно) вирівняно згідно з апаратними частинами діаграми.
- На комп'ютері наземної станції зазвичай працює [QGroundControl](../getting_started/px4_basic_concepts.md#qgc) (або інше програмне забезпечення наземної станції).
It may also run robotics software like [MAVSDK](https://mavsdk.mavlink.io/) or [ROS](../ros/index.md).
- The PX4 flight stack running on the flight controller includes [drivers](../modules/modules_driver.md), [comms modules](../modules/modules_communication.md), [controllers](../modules/modules_controller.md), [estimators](../modules/modules_controller.md) and other [middleware and system modules](../modules/modules_main.md).
## Польотний контролер та супутній комп'ютер
На діаграмі показано систему PX4, яка включає як політний контролер, так і супутній комп'ютер (тут згадується як "комп'ютер політного завдання").
![PX4 architecture - FC + Companion Computer](../../assets/diagrams/px4_arch_fc_companion.svg)
<!-- source for drawing: https://docs.google.com/drawings/d/1zFtvA_B-BmfmxFmAd-XIvAZ-jRqOydj0aBtqSolBcqI/edit -->
Польотний контролер виконує звичайний набір ПЗ PX4, тоді як супутній комп'ютер забезпечує просунуті функції наприклад [уникнення об'єктів](../computer_vision/obstacle_avoidance.md) та [запобігання зіткненням](../computer_vision/collision_prevention.md).
Дві системи з'єднані за допомогою швидкого послідовного або IP-з'єднання і зазвичай взаємодіють за допомогою протоколу [MAVLink](https://mavlink.io/en/).
Зв'язок з наземними станціями та хмарою зазвичай направляється через супутній комп'ютер (наприклад, за допомогою [MAVLink Router](https://github.com/mavlink-router/mavlink-router) від Intel).
Системи PX4 зазвичай виконують ОС Linux на супутньому комп'ютері (тому що проєкт [PX4/PX4-Avoidance](https://github. com/PX4/PX4-Avoidance) поставляє засновані на ROS бібліотеки уникнення розроблені для Linux).
Linux є набагато кращою платформою для "загальної" розробки програмного забезпечення, ніж NuttX; у Linux багато розробників і вже написано багато корисного програмного забезпечення (наприклад для комп'ютерного бачення, зв'язку, інтеграції з хмарою, апаратні драйвери).
Супутні комп'ютери іноді працюють на Android з тієї ж причини.
:::info
Діаграма показує підключення до хмарних або наземних станцій через LTE, підхід, який був використаний в ряді систем заснованих на PX4.
PX4 не надає програмного забезпечення для LTE та/або хмарної інтеграції (це потребує додаткової розробки).
:::
docs/uk/concept/sd_card_layout.md
+24
View File
@@ -0,0 +1,24 @@
# Структура файлів на SD картках для PX4
SD картка у PX4 використовуються для зберігання файлів налаштування, журналів польотів, інформації щодо польотного завдання тощо.
:::tip
SD картку слід відформатувати у FAT32 для використання з PX4 (за замовчуванням для SD карток).
Рекомендуємо відформатувати картки, які використовують іншу файлову систему.
:::
Структуру директорій/розкладку показано нижче.
| Директорія/Файл(и) | Опис |
| ------------------------------------- | ------------------------------------------------------------------------------------------------- |
| `/etc/` | Додаткові налаштування. Дивіться [Запуск системи > заміна запуску системи][replace system start]. |
| `/log/` | Повні [журнали польоту](../dev_log/logging.md) |
| `/mission_log/` | Скорочені журнали польоту |
| `/fw/` | Прошивка [DroneCAN](../dronecan/index.md) |
| `/uavcan.db/` | Сервер DB DroneCAN DNA + журнали |
| `/params` | Параметри (якщо вони не в FRAM/FLASH) |
| `/dataman` | Файл сховища польотних завдань |
| `/fault_<datetime>.txt` | Файли журналу апаратних відмов |
| `/bootlog.txt` | Журнал завантаження |
[replace system start]: ../concept/system_startup.md#replacing-the-system-startup
docs/uk/concept/system_startup.md
+152
View File
@@ -0,0 +1,152 @@
# Запуск системи
Запуск PX4 контрольований скриптами оболонки.
На NuttX вони знаходяться у директорії [ROMFS/px4fmu_common/init.d](https://github.com/PX4/PX4-Autopilot/tree/main/ROMFS/px4fmu_common/init.d), деякі з них також використовуються на Posix системах (Linux/MacOS).
Скрипти які використовуються тільки на Posix системах знаходяться у [ROMFS/px4fmu_common/init.d-posix](https://github.com/PX4/PX4-Autopilot/tree/main/ROMFS/px4fmu_common/init.d-posix).
Усі файли, які починаються з числа і підкреслення (наприклад, `10000_airaipl`) є попередньо визначеними конфігураціями планерів.
Вони експортуються під час збірки в файл `airframes.xml` який потім аналізується [QGroundControl](http://qgroundcontrol.com) для користувацького інтерфейсу вибору планера.
Як додати нову конфігурацію описано [тут](../dev_airframes/adding_a_new_frame.md).
Файли що залишилися є частиною загальної логіки запуску.
Перший файл що виконується є скрипт [init.d/rcS](https://github.com/PX4/PX4-Autopilot/blob/main/ROMFS/px4fmu_common/init.d/rcS) (або [init.d-posix/rcS](https://github.com/PX4/PX4-Autopilot/blob/main/ROMFS/px4fmu_common/init.d-posix/rcS) на Posix), який викликає інші скрипти.
Наступні секції розділені відповідно до операційної системи, на яких виконується PX4.
## Posix (Linux/MacOS)
На Posix системна оболонка використовується як інтерпретатор скриптів (наприклад, /bin/sh що є символьним посиланням на dash в Ubuntu).
Щоб це працювало потрібно кілька речей:
- Модулі PX4 повинні виглядати для системи як окремі виконувані файли.
Це робиться за допомогою символьних посилань.
For each module a symbolic link `px4-<module> -> px4` is created in the `bin` directory of the build folder.
При виконанні двійкового файлу перевіряється його шлях (`argv[0]`) і якщо це модуль (починається з `px4-`) він відправляє команду на основний екземпляр px4 (див. нижче).
:::tip
The `px4-` prefix is used to avoid conflicts with system commands (e.g. `shutdown`), and it also allows for simple tab completion by typing `px4-<TAB>`.
:::
- Оболонка повинна знати, де шукати символьні посилання.
For that the `bin` directory with the symbolic links is added to the `PATH` variable right before executing the startup scripts.
- Оболонка запускає кожен модуль як новий (клієнтський) процес.
Кожен клієнтський процес повинен спілкуватися з головним екземпляром px4 (сервером), де справжні модулі працюють як потоки.
Це зроблено через [сокет UNIX](http://man7.org/linux/man-pages/man7/unix.7.html).
Сервер прослуховує сокет, до якого клієнти можуть під'єднатися та надіслати команду.
Сервер відправляє вихідні дані та код повернення назад до клієнта.
- The startup scripts call the module directly, e.g. `commander start`, rather than using the `px4-` prefix.
This works via aliases: for each module an alias in the form of `alias <module>=px4-<module>` is created in the file `bin/px4-alias.sh`.
- Скрипт `rcS` виконується з основного екземпляра Px4.
Він не запускає жодних модулів, але спочатку оновлює змінну `PATH`, а потім просто запускає оболонку з файлом `rcS` як аргумент.
- Крім того, декілька екземплярів серверу можуть бути запущені для симуляції кількох засобів.
A client selects the instance via `--instance`.
В скрипті екземпляр доступний за допомогою змінної `$px4_instance`.
Модулі можна виконувати з будь-якого терміналу, коли PX4 вже запущено в системі.
Наприклад:
```sh
cd <PX4-Autopilot>/build/px4_sitl_default/bin
./px4-commander takeoff
./px4-listener sensor_accel
```
### Динамічні модулі
Зазвичай всі модулі компілюються в єдиний виконуваний файл PX4.
Однак, на Posix системах, є можливість компіляції модуля в окремий файл, який можна завантажити в PX4 використовуючи команду `dyn`.
```sh
dyn ./test.px4mod
```
## NuttX
NuttX має інтегрований інтерпретатор оболонки ([NuttShell (NSH)](https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=139629410)), тому скрипти можуть бути виконані безпосередньо.
### Налагодження завантаження системи
Відмова драйверу програмного компонента не призведе до перерваного завантаження.
Це контролюється директивою `set +e` в скрипті запуску.
Послідовність завантаження можна налагодити під'єднавши [системну консоль](../debug/system_console.md) та перезавантажити плату за живленням.
Отриманий журнал завантаження містить детальну інформацію про послідовність завантажування і має містити підказки, чому завантаження переривалось.
#### Основні причини невдалого завантаження
- Для користувацьких додатків: у системі закінчилася оперативна пам'ять.
Run the `free` command to see the amount of free RAM.
- Відмова програмного забезпечення або припущення яке призвело до трасування стеку.
### Заміна запуску системи
Весь процес завантаження може бути замінений шляхом створення файлу з новою конфігурацією `/etc/rc.txt` на картці microSD (ніщо в старій конфігурації не буде автоматично запущено, і якщо файл порожній, зовсім нічого не буде запущено).
Налаштування стандартного завантаження майже завжди є кращим підходом.
Це описано нижче.
### Налаштування запуску системи
Найкращий спосіб змінити запуск системи - це ввести [нову конфігурацію планера](../dev_airframes/adding_a_new_frame.md).
Файл конфігурації планеру може бути включений у прошивку або на SD карту.
Якщо вам потрібно "підлаштувати" конфігурацію що існує, наприклад запустити один або більше застосунків або встановити значення кількох параметрів, можна вказати це створивши два файли у директорії `/etc/` на SD картці:
- [/etc/config.txt](#customizing-the-configuration-config-txt): modify parameter values
- [/etc/extras.txt](#starting-additional-applications-extras-txt): start applications
Ці файли описані нижче.
:::warning
Системні файли завантаження - це UNIX файли, які потребують закінчення рядків UNIX.
Якщо редагуєте їх на Windows - використовуйте відповідний редактор.
:::
:::info
Ці файли згадуються в коді PX4 як `/fs/microsd/etc/config.txt` та `/fs/microsd/etc/extras.txt`, де коренева директорія microSD карти визначається шляхом `/fs/microsd`.
:::
#### Налаштування конфігурації (config.txt)
Файл `config.txt` можна використовувати для зміни параметрів.
Він завантажується після того, як головна система була налаштована та _перед тим_ як завантажена.
Наприклад, ви можете створити файл на SD картці, `etc/config.txt` з такими значеннями параметрів як показано:
```sh
param set-default PWM_MAIN_DIS3 1000
param set-default PWM_MAIN_MIN3 1120
```
#### Запуск додаткових застосунків (extras.txt)
`extras.txt` можна використовувати для запуску додаткових застосунків після завантаження основної системи.
Зазвичай це будуть контролери корисного навантаження або подібні необов'язкові користувацькі компоненти.
:::warning
Виклик невідомої команди в файлах завантаження системи може призвести до збою завантаження.
Зазвичай система не транслює повідомлення mavlink після збою при завантаженні, в такій ситуації перевірте повідомлення про помилки, які виведено в системній консолі.
:::
Наступний приклад показує, як запускати користувацькі застосунки:
- Створіть файл на SD картці `etc/extras.txt` із цим вмістом:
```sh
custom_app start
```
- Команду можна зробити необов'язковою шляхом оздоблення команди директивами `set +e` та `set -e`:
```sh
set +e
optional_app start # Will not result in boot failure if optional_app is unknown or fails
set -e
mandatory_app start # Will abort boot if mandatory_app is unknown or fails
```