Microduck のシステム構成

最終更新 2026-09-03

ロボット側のソフトウェアは Rust、ワークスペース 1 つ、フレームワークなし。systemd がライフサイクル、クラッシュ時の再起動、起動順序、ウォッチドッグを担います。

このページの価値は診断にあります。症状が誰の担当かが分かれば、どのプロセスのログを読むかが決まります。

デーモンの分担

サービス	担当	備考
`robotd`	モーター制御、運動学、オドメトリ、歩容ポリシー、センサーループ、安全	準リアルタイムの中核。ロボットを傷つけうる事柄すべてに最終権限を持つ
`mediad`	カメラ・マイク、エンコード、知覚、WebRTC とリモートゲートウェイ	最も重いサービスで、リモート API の玄関でもある
`updaterd`	更新エンジン	署名済みリリースを導入し、起動後に不健全なら巻き戻す
`configd`	wifi、ロボットの identity、電源、ゲームパッドのペアリング
`btd`	BLE GATT サーバー	トランスポートアダプタのみ。状態を持たない
`padd`	ゲームパッドの読み取り	意図的に非特権クライアント
`tofd`	頭部 ToF センサー（HAT の I²C バス上の 8×8 深度行列）	センサー 1 つを所有してフレームを publish するだけ。何も読まない

どれも恣意的ではありません。

mediad を robotd から分離しているのは、メディアや知覚のクラッシュがモーター制御を巻き添えにしないためです。

tofd は同じ規則をより小さなセンサーに適用したもので、具体的な事情がその判断を裏づけます。

このためのリトライループを、モーターを所有するプロセスに置くべきではありません。制御ループは深度を読まないので、外に出しても失われるものはありません。

mediad にも意図的に入れていません。 深度はバス上のセンサーであってメディアパイプラインではなく、注釈をつけるカメラが存在するよりずっと前から有用だからです。

ペアリングが padd ではなく configd にあるのは、デバイスのボンドに root と BlueZ が必要な一方、padd は意図的に非特権クライアントだからです。

設定が configd 自身の担当なのは、robotd が死んでいても到達可能でなければならず、かつ btd は何も持ってはいけないためです。どちらのものでもないので、自分で持ちます。

利用者にとって重要な性質が一つあります。

どのクライアント——スマホアプリ、コンソール、ゲームパッド、自作スクリプト——もまったく同じ呼び出しを送ります。

公式アプリにできることは、スクリプトにもできます。隠された私的インターフェースはありません。

センサーのストリームはコントロールプレーンを通りません。利用者はそれを所有するデーモン自身のソケットを購読します（tofd の tof.stream、padd の生入力）。robotd を経由しません。

tofd はセンサー視点のフレームを publish し、自分に計算できない幾何を装いません。ロボット座標系への再投影には、robot.state の関節状態と kinematics クレートの頭部順運動学が必要です。

設計文書が一節を割いている点で、覚えておく価値があります。

「何が動いているか」と「何が入っているか」は別の問いです。 robotctl version が両方を報告し食い違いを警告するのはこのためです。更新後に古いコードのまま動いているデーモンは、いま直したはずの修正が効いていない状態とまったく同じに見えます。

健全性は一つの問いなので、一つのコマンドです。 robotctl health はハードとソフトを 1 つのレポートにまとめ、7 つのプロセスを個別に確認させません。

制御ループ内の構造体です。理由は単純で、その入力がまさにループが既に読んだサンプルだからです。

robotctl monitor の軌跡図の性質もここから来ます。足の接地と IMU から得られ、磁力計はありません。したがって相対運動であり、ドリフトします。「一周したか」には答えられ、「いまどこにいるか」には答えられません。