Dronecode Devマニュアル抜粋&翻訳 -System Startup

#この記事は
前回の [PWM_limit State Machine](https://qiita.com/sakaeda11/items/b3e5eb65fb56a0519be6) に引き続き、
Dronecode本家サイトの[System Startup](https://dev.px4.io/master/en/concept/system_startup.html)ページの抜粋・翻訳です。

※主に自分の理解用に書いています。

#System Startup
PX4の起動は、シェルスクリプトによって制御されます。 NuttXでは、[ROMFS/px4fmu_common/init.d](https://github.com/PX4/Firmware/tree/master/ROMFS/px4fmu_common/init.d)フォルダーにあります。
これらの一部はPosix（Linux / MacOS）でも使用されます。 Posixでのみ使用されるスクリプトは[ROMFS/px4fmu_common/init.d-posix](https://github.com/PX4/Firmware/tree/master/ROMFS/px4fmu_common/init.d-posix)にあります。

数字とアンダースコアで始まるすべてのファイル（例：10000_airplane）は、事前定義された機体構成です。
これらはビルド時にairframes.xmlファイルにエクスポートされます。airframes.xmlファイルは[QGroundControl](http://qgroundcontrol.com/)によってパースされ、機体選択UIに使用されます。新しい構成の追加については[ここ](https://dev.px4.io/master/en/airframes/adding_a_new_frame.html)を参照してください。



残りのファイルは、一般的な起動ロジックの一部です。最初に実行されるファイルは[init.d/rcS](https://github.com/PX4/Firmware/blob/master/ROMFS/px4fmu_common/init.d/rcS)のスクリプトで、これが他のすべてのスクリプトを呼び出します。（Posixでは[init.d-posix/rcS](https://github.com/PX4/Firmware/blob/master/ROMFS/px4fmu_common/init.d-posix/rcS)）

以下のセクションは、PX4が実行されるOSに応じて割かれています。


## Posix (Linux/MacOS)
Posixでは、システムシェルはスクリプトインタープリターとして使用されます（Ubuntuでは`dash`にシンボリックリンクされている`/bin/sh`など）。それが機能するには、いくつかのことが必要です。

- PX4モジュールは、個々がシステムにとって実行可能ファイルとして見える必要があります。これはシンボリックリンクによって実現されます。各モジュールに対して、`px4-<module> -> px4`となるシンボリックリンクがビルドフォルダーのbinディレクトリに作成されます。実行されると、バイナリパスがチェックされ（argv[0]）てそれがモジュール（px4-で始まるもの）の場合、メインのpx4インスタンスにコマンドが送信されます（以下を参照）

>`px4-`のプレフィクスは、shutdownなどのシステムコマンドとの競合を回避するために使用されています。また、`px4-<TAB>`と入力することで簡単にタブを補完できます。

- シェルはシンボリックリンクがどこにあるかを知る必要があります。そのため、シンボリックリンクがあるbinディレクトリが、起動スクリプトを実行する直前に環境変数PATHに追加されます。　
- シェルは、各モジュールを新しい（クライアント）プロセスとして起動します。各クライアントプロセスは、px4のメインインスタンス（サーバー）と通信する必要があります。(実際のモジュールはスレッドとして実行されています。)この通信は[UNIXのsocket](https://man7.org/linux/man-pages/man7/unix.7.html)によって実現されています。サーバーはsocketをlistenし、クライアントはsocketに接続しコマンドを送信します。そして、サーバーは出力を生成し、return codeをクライアントに返します。
- 起動スクリプトはプレフィックス`px4-`を使用せず、モジュールを直接呼び出します(例：`commander start`)。これはエイリアスを介して機能します。各モジュールについて`<module>=px4-<module>`の形式のエイリアスが`bin/px4-alias.sh`のファイル内に作成されます。
- `rcS`スクリプトはメインのpx4インスタンスから実行されます。このスクリプトはモジュールは起動しませんが、最初に`PATH`変数を更新してから、`rcS`ファイルを引数としてシェルを実行します。
- さらに、複数車両シミュレーションのために、複数のサーバーインスタンスを起動できます。クライアントは`--instance`を介してインスタンスを選択します。インスタンスは`$px4_instance`変数を介してスクリプトで使用できます。


PX4がすでにシステムで実行されている場合、モジュールは任意のターミナルから実行できます。例えば：

```
cd <Firmware>/build/px4_sitl_default/bin
./px4-commander takeoff
./px4-listener sensor_accel
```

### Dynamic modules
通常、すべてのモジュールは単一のPX4実行可能ファイルにコンパイルされます。ただし、Posixでは、モジュールを別のファイルにコンパイルするオプションがあります。コンパイルされた個別モジュールは`dyn`コマンドを使用してPX4にロードできます。

```
dyn ./test.px4mod
```

## NuttX
NuttXにはシェルインタープリター[NuttShell(NSH)](https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=139629410)が統合されているため、スクリプトを直接実行できます。



### Debugging the System Boot
ソフトウェアコンポーネントのドライバーに障害が発生しても、起動は中止されません。これは、起動スクリプトに`set + e`と記述することで制御できます。

ブートシーケンスは、システムコンソールを接続してボードの電源を入れ直することでデバッグできます。ブートログ結果には、ブートシーケンスに関する詳細情報が含まれており、ブートが中止された理由のヒントが含まれているはずです。

#### Common boot failure causes
(よくある起動失敗の原因)

- カスタムアプリケーションの場合：　システムのRAM不足。freeコマンドを実行して、空きRAMの量を確認してみましょう。
- ソフトウェアの障害またはアサート： スタックトレースを確認してみましょう

### Replacing the System Startup
もしシステム起動処理を置き換えたいなら、ほとんどの場合は、以下のような方法でデフォルトのブートをカスタマイズする方が良い方法です。

起動処理を完全に置き換える必要がある場合は、microSDカードの`etc`フォルダーにある`/fs/microsd/etc/rc.txt`ファイルを作成します。このファイルが存在する場合、システム上の起動ファイルは何もしません

### Customizing the System Startup
システムの起動をカスタマイズする最良の方法は、[新しい機体構成を導入する](https://dev.px4.io/master/en/airframes/adding_a_new_frame.html)ことです。
微調整のみが必要な場合（1つ以上のアプリケーションを開始する、または単に別のミキサーを使用するなど）、起動時に利用できる特別なhookがあります。

> システムブートファイルは、UNIX LINE ENDINGS(改行コード)を必要とするUNIX FILESです。 Windowsで編集する場合は、適切なエディターを使用してください。

3つの主要なフックがあります。microsdカードのルートフォルダが`/fs/microsd`というパスになっていることに注意してください。(起動スクリプト[rcS](https://github.com/PX4/Firmware/blob/master/ROMFS/px4fmu_common/init.d/rcS#L93)でそうなるようにマウントしているようです。)

- /fs/microsd/etc/config.txt
- /fs/microsd/etc/extras.txt
- /fs/microsd/etc/mixers/NAME_OF_MIXER

#### Customizing the Configuration (config.txt)
`config.txt`ファイルを使用して、シェル変数を変更できます。これは「メインシステムの**構成後**」かつ「起動する前」に読み込まれます。


#### Starting additional applications
`extras.txt`は、「メインシステムの**起動後**」に追加のアプリケーションを起動するために使用できます。通常ここにはペイロードコントローラーまたは同様のオプションのカスタムコンポーネントを置きます。


>システムブートファイルで不明なコマンドを呼び出すとブートエラーが発生する可能性があります。通常、システムは起動失敗後にmavlinkメッセージをストリーミングしません。この場合、システムコンソールに出力されるエラーメッセージを確認してください。


次の例は、カスタムアプリケーションを起動する方法を示しています。

- 次の内容でSDカード`etc/extras.txt`にファイルを作成します。

```
custom_app start
```

- コマンドは、`set +e`および`set -e`コマンドでゲートすることにより、オプションにすることができます。
- (+eの場合は処理が失敗しても起動は止まらず、-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
```

#### Starting a custom mixer

デフォルトでは、システムは`/etc/mixers`からミキサーをロードします。`/fs/microsd/etc/mixers`に同じ名前のファイルが存在する場合は、代わりにそのファイルがロードされます。これにより、ファームウェアを再コンパイルせずにミキサーファイルをカスタマイズできます。


##### Example

次の例は、カスタムauxミキサーを追加する方法です。

- SDカードの`etc/mixers/gimbal.aux.mix`にmixerファイルを作成します。
- 次にそれを使用するために、次の内容で`etc/config.txt`ファイルを追加作成します。

```
set MIXER_AUX gimbal
set PWM_AUX_OUT 1234
set PWM_AUX_DISARMED 1500
set PWM_AUX_MIN 1000
set PWM_AUX_MAX 2000
set PWM_AUX_RATE 50
```