開発ボードのセットアップ
最終更新
開発ボードはチームの dev 鍵を信頼するため、チームの誰がビルドしたものでもインストールします。製品版ロボットは設定が異なり、それらのビルドを意図的に拒否します。
このページの内容はすべて開発ボードを前提としています。製品版ロボットではありません。
緩められているものは何もない
誤解しやすいので明記します。dev ビルドも同じ署名・ハッシュ検証、同じヘルスゲート、同じ自動ロールバックを通ります。違うのは署名した鍵だけです。
そしてそれこそが、これらのビルドを製品版ロボットに入れさせない仕組みでもあります。製品版は二重に拒否します。allow_dev_keys = false であること、そして信頼された鍵がファイル名 .dev.pub で終わる場合のみ dev 鍵と見なされること。以下の設定は、まさにこの 2 つを反転させるために存在します。
ボードを焼く
Armbian imager を使い、Radxa Zero 3 → Armbian 26.2.1 Minimal を選びます。
書き込む前に imager のプロファイルを埋めてください——wifi の SSID とパスワード、使いたいユーザー名とパスワード。ここで入れておくと後でシリアルコンソールを使わずに済みます。初回起動でネットワークに参加し、すぐ ssh で届きます。
次に ssh 鍵を送ります。プロビジョニングがボードを再起動した後に再接続するために必要です。
ssh-copy-id radxa@192.168.1.42必要なもの
- ボードの IP アドレス。 このイメージの mDNS は当てになりません。
duckctl ipは Bluetooth 経由でロボットに尋ねるので、自分側のネットワークが不要です。 - ssh 鍵によるアクセス。 プロビジョニングは再起動して自分で再接続するため、パスワード入力はそれを越えられません。
- GitHub トークン（リポジトリが非公開の間）。リリース資産に到達できません。
- リポジトリのクローン。 必要な dev 公開鍵は
deploy/dev-key/team.dev.pubにコミット済みで、誰かに頼む必要はありません。
インストール
export DUCK_TOKEN=github_pat_replace_with_your_token
./scripts/provision-board.sh --pause-btd-on-pair --name <MY_ROBOT> radxa@192.168.1.42dev 鍵を送り、プロビジョニングを開始し、再起動を待ち、ログを流し、robotctl health で終わります。
ログ出力はビューアであって、作業そのものではありません。 プロビジョニングは起動時に再開する systemd unit を入れるので、見ているかどうかに関係なくボードは完走します。Ctrl-C で失うものはありません。
ssh -t radxa@192.168.1.42 'sudo tail -f /var/lib/robot/provision.log'なぜ --pause-btd-on-pair が既定なのか
aic8800 無線チップでは、btd がアドバタイズ中は新しいボンドを作れません。このフラグはマーカーを残し、robotctl pad pair がペアリングの間だけ btd を止めてアダプタを電源再投入し、その後再開するようにします。既存のボンドには影響しません。
既定である理由は実際的です。必要だったのに付けずにプロビジョニングしたボードは「パッドがペアリングできない」という症状を示し、最初に疑う原因はすべて見当外れの場所にあります。
3 つの構成と、自分がどれかの見分け方
独立した不具合が 2 つあるので、フラグも 2 つです。一度パッドをペアリングして、その失敗の仕方を読んでください。
| 見えている現象 | そのボードに必要なもの |
|---|---|
| パッドがボンドして走行できる | 何も不要——フラグなしでプロビジョニング |
| ボンドできず、最後の SMP 段階が完了しない | --pause-btd-on-pair |
btd を止めてもボンドできない |
--weird-ble（一時停止を含み、Privacy = device を追加） |
ボンドはするが切断を繰り返す——PIN or Key Missing (0x06)、入力デバイスが作られない |
--weird-ble が間違い：外して一時停止だけを残す |
最後の行が要注意です。 一時停止だけで足りるボードに Privacy = device を設定すると、ボンドはできるのにすぐ機能しなくなります。これは「明らかにペアリングできない」より診断が困難です。ある個体での実測では、off ＋一時停止は安定していたのに device は 45 秒で 46 回切断しました。したがって --weird-ble は既定ではありません。
2 つの構成を行き来する
# --weird-ble から一時停止だけに戻す
sudo sed -i 's/^Privacy = device/Privacy = off/' /etc/bluetooth/main.conf && sudo reboot
# 逆方向（プロビジョニングがボードに残したスクリプトを使う）
sudo DUCK_WEIRD_BLE=1 /usr/local/sbin/robot-setup-board && sudo reboot
# どちらも不要か確認する
sudo rm /var/lib/robot/weird-ble
sudo sed -i '/^Privacy = /d' /etc/bluetooth/main.conf && sudo reboot
Privacyを変えたら必ず再ペアリングしてください。 保存された鍵が導出された元のアドレスが変わるため、既存のボンドは一致しなくなり、作り直すまでPIN or Key Missingで切断を繰り返します。
ブランチからプロビジョニングする
./scripts/provision-board.sh --ref BRANCH radxa@192.168.1.42理解しておく価値のある設計判断が一つあります。golden は安定リリースのままです——起動時リカバリのフォールバックであり、ブランチビルドを golden にすることは壊れたブランチに壊れた命綱を与えることだからです。ブランチになるのは current だけです。
そのビルドがインストールできない場合、あるいはインストール後にヘルスゲートで巻き戻された場合、プロビジョニングは失敗します。これは意図的です。
ブランチを要求されたのに静かに安定リリースを動かしている開発ボードは、最もデバッグしにくい失敗です。すべてインストール済みに見えるのに、テスト対象のコードがそこにありません。
成功したかの確認
robotctl health
grep -c 'DEV BOARD' /var/lib/robot/provision.log鍵が本当にインストールされて初めて開発ボードと言え、それは記憶に頼らず確認できます。 1 なら成功。0 なら鍵が届いておらず、後で --ref が拒否されます——しかも壊れたリリースのように読めるエラーで。このチェックは、その失敗を早期に捕まえるために存在します。