mirror of
https://gitee.com/mirrors_PX4/PX4-Autopilot.git
synced 2026-04-14 10:07:39 +08:00
189 lines
12 KiB
Markdown
189 lines
12 KiB
Markdown
# Запуск системи
|
||
|
||
Запуск PX4 контрольований скриптами оболонки.
|
||
On NuttX they reside in the [ROMFS/px4fmu_common/init.d](https://github.com/PX4/PX4-Autopilot/tree/main/ROMFS/px4fmu_common/init.d) folder - some of these are also used on 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`) є попередньо визначеними конфігураціями планерів.
|
||
They are exported at build-time into an `airframes.xml` file which is parsed by [QGroundControl](https://qgroundcontrol.com) for the airframe selection UI.
|
||
Як додати нову конфігурацію описано [тут](../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)
|
||
|
||
On POSIX, the system shell is used as script interpreter (e.g. /bin/sh, being symlinked to dash on Ubuntu).
|
||
Щоб це працювало потрібно кілька речей:
|
||
|
||
- Модулі PX4 повинні виглядати для системи як окремі виконувані файли.
|
||
Це робиться за допомогою символьних посилань.
|
||
For each module a symbolic link `px4-<module> -> px4` is created in the `bin` directory of the build folder.
|
||
When executed, the binary path is checked (`argv[0]`), and if it is a module (starts with `px4-`), it sends the command to the main PX4 instance (see below).
|
||
|
||
:::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.
|
||
|
||
- Оболонка запускає кожен модуль як новий (клієнтський) процес.
|
||
Each client process needs to communicate with the main instance of PX4 (the server), where the actual modules are running as threads.
|
||
This is done through a [UNIX socket](https://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`.
|
||
|
||
- The `rcS` script is executed from the main PX4 instance.
|
||
Він не запускає жодних модулів, але спочатку оновлює змінну `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.
|
||
However, on POSIX, there's the option of compiling a module into a separate file, which can be loaded into PX4 using the `dyn` command.
|
||
|
||
```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 карту.
|
||
|
||
#### Dynamic Customization
|
||
|
||
Якщо вам потрібно "підлаштувати" конфігурацію що існує, наприклад запустити один або більше застосунків або встановити значення кількох параметрів, можна вказати це створивши два файли у директорії `/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
|
||
```
|
||
|
||
#### Additional Init-File Customization
|
||
|
||
In rare cases where the desired setup cannot be achieved through frame configuration or dynamic customization, you can add a script that will be compiled into the binary for a particular `make` target build variant.
|
||
|
||
:::warning
|
||
In almost all cases, you should use a frame configuration.
|
||
This method should only be used for edge-cases such as customizing `cannode` based boards.
|
||
:::
|
||
|
||
Кроки наступні:
|
||
|
||
- Add a new init script in `boards/<vendor>/<board>/init` that will run during board startup.
|
||
Наприклад:
|
||
|
||
```sh
|
||
# File: boards/<vendor>/<board>/init/rc.additional
|
||
param set-default <param> <value>
|
||
```
|
||
|
||
- Add a new board variant in `boards/<vendor>/<board>/<variant>.px4board` that includes the additional script.
|
||
Наприклад:
|
||
|
||
```sh
|
||
# File: boards/<vendor>/<board>/var.px4board
|
||
CONFIG_BOARD_ADDITIONAL_INIT="rc.additional"
|
||
```
|
||
|
||
- Compile the firmware with your new variant by appending the variant name to the compile target.
|
||
Наприклад:
|
||
|
||
```sh
|
||
make <target>_var
|
||
```
|