Запуск системи

Запуск PX4 контрольований скриптами оболонки. On NuttX they reside in the ROMFS/px4fmu_common/init.d folder - some of these are also used on Posix (Linux/macOS). Скрипти які використовуються тільки на Posix системах знаходяться у ROMFS/px4fmu_common/init.d-posix.

Усі файли, які починаються з числа і підкреслення (наприклад, 10000_airaipl) є попередньо визначеними конфігураціями планерів. They are exported at build-time into an airframes.xml file which is parsed by QGroundControl for the airframe selection UI. Як додати нову конфігурацію описано тут.

Файли що залишилися є частиною загальної логіки запуску. Перший файл що виконується є скрипт init.d/rcS (або 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. При виконанні двійкового файлу перевіряється його шлях (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 (сервером), де справжні модулі працюють як потоки. This is done through a UNIX socket. Сервер прослуховує сокет, до якого клієнти можуть під'єднатися та надіслати команду. Сервер відправляє вихідні дані та код повернення назад до клієнта.

• 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 вже запущено в системі. Наприклад:

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.

dyn ./test.px4mod

NuttX

NuttX має інтегрований інтерпретатор оболонки (NuttShell (NSH)), тому скрипти можуть бути виконані безпосередньо.

Налагодження завантаження системи

Відмова драйверу програмного компонента не призведе до перерваного завантаження. Це контролюється директивою set +e в скрипті запуску.

Послідовність завантаження можна налагодити під'єднавши системну консоль та перезавантажити плату за живленням. Отриманий журнал завантаження містить детальну інформацію про послідовність завантажування і має містити підказки, чому завантаження переривалось.

Основні причини невдалого завантаження

• Для користувацьких додатків: у системі закінчилася оперативна пам'ять. Run the free command to see the amount of free RAM.
• Відмова програмного забезпечення або припущення яке призвело до трасування стеку.

Заміна запуску системи

Весь процес завантаження може бути замінений шляхом створення файлу з новою конфігурацією /etc/rc.txt на картці microSD (ніщо в старій конфігурації не буде автоматично запущено, і якщо файл порожній, зовсім нічого не буде запущено).

Налаштування стандартного завантаження майже завжди є кращим підходом. Це описано нижче.

Налаштування запуску системи

Найкращий спосіб змінити запуск системи - це ввести нову конфігурацію планера. Файл конфігурації планеру може бути включений у прошивку або на SD карту.

Dynamic Customization

Якщо вам потрібно "підлаштувати" конфігурацію що існує, наприклад запустити один або більше застосунків або встановити значення кількох параметрів, можна вказати це створивши два файли у директорії /etc/ на SD картці:

• /etc/config.txt: modify parameter values
• /etc/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 з такими значеннями параметрів як показано:

param set-default PWM_MAIN_DIS3 1000
param set-default PWM_MAIN_MIN3 1120

Запуск додаткових застосунків (extras.txt)

extras.txt можна використовувати для запуску додаткових застосунків після завантаження основної системи. Зазвичай це будуть контролери корисного навантаження або подібні необов'язкові користувацькі компоненти.

WARNING

Виклик невідомої команди в файлах завантаження системи може призвести до збою завантаження. Зазвичай система не транслює повідомлення mavlink після збою при завантаженні, в такій ситуації перевірте повідомлення про помилки, які виведено в системній консолі.

Наступний приклад показує, як запускати користувацькі застосунки:

• Створіть файл на SD картці etc/extras.txt із цим вмістом:

  custom_app start

• Команду можна зробити необов'язковою шляхом оздоблення команди директивами set +e та set -e:

  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. Наприклад:

  # 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. Наприклад:

  # 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. Наприклад:

  make <target>_var