章16: 実機特有のトラブルと復帰

← 前章: 実機で搬送・アクション・可視化 | 目次 | 次章: 卒業課題とまとめ →

対応する第1部: なし(実機だけの内容)。simのトラブルはTROUBLESHOOTING.md。

狙い

simには無かった3つの実機トラブルを、わざと起こして復帰させる
BLEの切断と再接続
マット境界での位置ロスト
起動順序を間違えたときの復旧
「どの端末を再起動すれば戻るか」を判断できるようになる

実機フリート運用で必ず向き合う現実がこれ。壊れ方を知っていると、怖がらずに運用できる。

再起動の範囲 ── まずこれを頭に入れる

直したいもの	再起動する端末	触らなくてよい端末
RMF側の設定(`finishing_request`、閾値、アクションのYAML)	端末2	端末1(BLE接続は維持)
キューブとの接続(BLE切断)	端末1	端末2 ── ただし下記の注意
起動順序を間違えた(Nav2が死んだ)	両方(端末1 → 端末2の順で)	──

1. BLEの切断と再接続

【要確認】切断後にNav2が失敗するか停止するか、ブリッジが自動再接続するかは、構成からの推定を含む(実測は #21)。

起こし方: patrol中にキューブの電源ボタンを長押しして切る(またはBluetoothの範囲外へ持ち出す)。

見えるもの:

端末1のブリッジが切断を報告し、/toio1/toio/pose の更新が止まる
RMFの /fleet_states の位置が最後の値で固まる。RVizのマゼンタも動かない
Nav2はゴールに向かって指令を出し続けるが、キューブは動かない。しばらくするとNav2側でタイムアウトし、タスクが失敗または停止する

復帰: キューブの電源を入れ直す。多くの場合ブリッジが自動で再接続する。再接続しなければ端末1を再起動する。位置報告が戻ったら、止まっていたタスクを cancel_task で片付け、投げ直す。

端末1を再起動するとき、端末2は起動したままでよい。Nav2のTF待ち(initial_transform_timeout)が効くのは活性化時だけなので、すでに活性化済みのNav2はTFが一時的に途切れても死なない。位置報告が戻ればそのまま続けられる。戻らなければ次節の「逆順起動」と同じ手順で全体を起動し直す。

2. マット境界での位置ロスト

【要確認】ロスト中のNav2の挙動(空回りするか、止まるか)は構成からの推定を含む(実測は #21)。

起こし方: go_to_placeの走行中に、キューブを手でマットの端の外側へずらす(またはマットの印刷が無い余白に置く)。

見えるもの:

toioのPosition IDが読めなくなり、/toio1/toio/pose が止まる(章12の観察1で見た現象)
BLEは繋がったままなので、ブリッジはエラーを出さない。「繋がっているのに位置が来ない」という、BLE切断より気づきにくい状態
Nav2は最後の位置を信じて指令を出し、キューブがマット外で空回りすることがある

復帰: キューブをマットの上(できれば最後に居た付近)に戻す。poseが再開し、Nav2が現在位置を取り直して走行を続ける。ずれが大きいときは cancel_task してチャージャーへ戻し、投げ直す方が安全。

予防: navグラフの頂点と経路はマット内側に収めてある(A4の approach_* が端から離れているのはこのため)。自分で地図を作るときも、読み取り不能領域に頂点を置かないのが鉄則。

3. 起動順序を間違えた(逆順起動)

起こし方: わざと端末2(RMF+Nav2)を先に起動し、あとから端末1(ブリッジ)を起動する。

見えるもの:

端末2でNav2のcostmapが map → toio1/base_link のTFを待ち続ける
initial_transform_timeout(300秒)を超えると活性化が失敗し、lifecycle managerがbringup全体を中止する。自動リトライは無い
あとから端末1を起動しても、Nav2は戻らない

復帰: 端末2を落とし、端末1が位置を出していることを確かめてから、端末2を起動し直す(正しい順序。章11)。端末1は落とさなくてよい。

300秒の猶予があるので、端末2を先に起動してしまっても5分以内に端末1が位置を出し始めれば間に合う、とタイムアウト値から推定できる。「逆順=即死」ではなく「逆順で5分放置=死」。

4. 起動直後の最初のタスクが消える

トラブルというより毎回の作法で、章11が正本。Managed nodes are active から25秒待ち、投げたらログで Direct request … queued / Add Task を確かめ、出ていなければ投げ直す。

理解する

実機の故障は「位置が来ない」に集約される。BLE切断もマット境界も、RMFから見れば「ロボット層③が位置を報告しなくなった」という同じ症状。章2の「位置は別経路で上がる」という構造が、故障の見え方も決めている。
どの層が壊れたかで、再起動の範囲が決まる。③(端末1)が壊れても①②(端末2)は生きている。逆に①②の設定変更で③を触る必要はない。三層モデルは学習用の図ではなく、運用のチェックリストになる。
simは「位置が常に来る世界」だった。だから第1部では位置ロストを扱えなかった。実機編でしか学べないのはここ。

確認課題

patrol中にBLEを切り、/fleet_states の位置が固まるまでの時間と、Nav2が諦めるまでの時間を測る。復帰後に投げ直したタスクが通ることを確認する。
マット外にずらしたとき、ブリッジのログに何も出ないことを確認する。「繋がっているのに位置が来ない」を検知するには何を監視すればよいか考える(ヒント: /toio1/toio/pose の更新間隔)。
わざと逆順で起動し、端末1を5分以内に起動してNav2が活性化することと、5分放置して失敗することの両方を試す。

壊し方と直し方まで分かれば、実機フリート運用の入口に立ったことになる。最後に卒業課題で答え合わせをする。

← 前章: 実機で搬送・アクション・可視化 | 目次 | 次章: 卒業課題とまとめ →