YouDuck.ai

開発ボード早見表

最終更新

開発ボードでしか意味のないコマンドです。日常のものは robotctl コマンドリファレンスにあります。

dev チャネル

sudo robotctl update apply --ref <branch> daemon
sudo robotctl update apply --ref main daemon

--version は特定のリリースに固定します。「安定版に戻る」と本当に言いたいのでなければ、どちらかを指定してください

--ref なしの apply は罠

--ref を付けない apply daemon は最新の安定リリースを入れます。開発ボードではこれは通常ダウングレードです。

意味は「最新のものを入れる」ではなく「安定チャネルが提供するものを入れる」です。

ブランチがマージされた直後でも、その安定リリースはあなたがテストしてきたすべてより古いままです。さらに厄介なことに、いまボード上に unit ファイルを持つデーモンより古い場合、その ExecStart は旧リリースに存在しないバイナリを指し、再起動が失敗して更新がロールバックします。これはゲートが正常に働いているのですが、それを引き起こしたコマンドこそが一番自然に見えるものでした。

ブランチタグの挙動

タグ daemon-dev-<branch> はブランチと共に動くので、コピーすべきバージョン番号はありません。一方でバージョン内部はビルドごとに一意(0.1.0-dev.42.c719ec8)なので、同じブランチの 2 つのビルドが混同されることはありません。

--ref maindev チャネルに留まったままメインラインに戻る方法です。素の apply daemon はチャネルを離れます。

マージは即座に公開されません。 CI が main をビルドするまで --ref main は解決しません。

リリース候補

sudo robotctl update apply --staging daemon

release.yml が staging に公開し、まだ誰も昇格させていないもの——昇格前にカナリア機が動かすべきものです。

候補もリリース鍵で署名されています。フラグなしで届かないのはプレリリースとしてマークされているためで、素の apply はそれを飛ばします。誰も検証していないビルドにロボットが漂流しないためです。

更新後——ここが噛む

覚えておく価値のある節です。ここが生む症状は「修正は確かに入っているのに、確かに効いていない」です。

再起動は 2 波に分かれる

  • robotdconfigdpadd は更新中に再起動します。
  • updaterdbtd は応答の 5 秒後に再起動します——前者は更新中に自分を再起動できず、後者はその応答を運んでいる可能性があるためです。

なので btd の修正は数秒後に有効になります。手動の操作は要りません。

その再起動が起きなかった場合

次の updaterd 起動が直します——updaterd 自身を除いて。それは自分を再起動せず、不一致を報告します。

そのためにはもう一度 apply を実行してください。already_current と答え、動いていないデーモンを名指しし、再起動を予定します。

古いボードにはこの仕組みが無い

0.4.0 より古い updaterd のボードは、手動で再起動するまで両者を古いバイナリのままにします。1 回の更新で直り、その次の更新から正常に振る舞います

already_current はもう「何もしない」ではない

ボードが既に持つバージョンを要求すると already_current と報告して何もインストールしません——しかしもう惰性ではありません。そのリリースで動いているデーモンを確認し、動いていないものを再起動して stale に名指しします。

つまり、修正が効いていないように見えるときに使うべきコマンドがこれです。 直るか、stale が空で「その修正はそのリリースに最初から入っていなかった」と分かるかのどちらかです。

どのデーモンが遅れているか

robotctl health

units ブロックがデーモンごとに 1 行、そのプロセスがどのリリースから起動したかを表示し、インストール済みと食い違えば名指しで警告します。

build unknown (old) は、そのデーモンが「答え方を教わった」リリースより古いことを意味します。再起動すれば答えるようになります。

ノート PC からパッドで操作する

パッドは手元、ロボットは作業台、どちらにも何もインストールしない構成です。padd は普通のクライアントなので、転送したソケットに対してクローンから実行できます。

sudo systemctl stop padd                                    # ロボット側
ssh -L /tmp/robotd.sock:/run/robotd.sock radxa@192.168.1.42
cargo run -p padd -- --socket /tmp/robotd.sock              # クローンから

padd のフラグが本当に役立つのもここです——--max-linear(m/s)、--max-angular(rad/s)、--max-head(ラジアン)、そして --deadzoneアナログスティックがぴったりゼロで止まることは稀で、これが無いとロボットがじわじわ動き出すために存在します。

関連