Isaac SimからNav2、そして本番へ：シミュレーションが教えないこと

NVIDIA Isaac Sim上でナビゲーションが完璧に動く。それが確実に示すのは、コードがビルドでき、TFの座標変換に矛盾がなく、ビヘイビアツリーが書いたとおりに動く、ということだけです。倉庫の1シフトを、誰かが動けなくなったロボットを助けに行くことなく、ロボット群が走り切れるかどうかについては、ほとんど何も教えてくれません。

この2つの状態のあいだの距離が sim-to-real ギャップです。シミュレータの欠陥ではありません。Isaac Simは、こちらが記述した世界を忠実にモデル化しているだけです。ギャップは、記述しなかったすべてと、存在しない世界に合わせて静かにチューニングされたNav2のパラメータから生まれます。本稿では、そのギャップの中身と、実機投入前にその大半を潰すための検証の作法を扱います。

Isaac Simが得意なこと

• 形状とレイアウト。通路幅、ラックのせり出し、ドックの高さ、ドア枠。シミュレーションで通れない隙間は、現場でも通れません。
• 剛体ダイナミクス。平坦な床の上で剛体シャーシとして振る舞うロボットについて、PhysXは質量・慣性・接触をそれなりに信頼できる精度で扱います。
• センサの幾何配置と視野。LiDARが自機のフレームに遮蔽される位置、深度カメラがバンパー下で見落とす範囲、荷物を高く積んだときの死角。
• ROS 2グラフ全体。トピック、TFツリー、QoSプロファイル、ライフサイクル遷移、ビヘイビアツリーが実際に動きます。結合バグの多くはここで死にます。
• 再現性。同じシナリオ、同じシード、同じ結果。実機の現場では決して得られません。

この最後の性質を、検証と取り違えるチームが多くあります。完全に再現できるテストはリグレッションテストであって、システムが動く証拠ではありません。

Isaac Simが不得意なこと

• 現実の質感を持つセンサノイズ。シミュレーションのLiDAR点群はきれいです。実機では、黒いゴムやマットな暗色プラスチックで反射が返らず、磨かれたコンクリートやストレッチフィルムから偽の反射が生まれ、再帰反射テープの近くでは点が膨らみます。obstacle layerが見る点群は、チューニング時のものとは別物です。
• 物理的な原因を伴うオドメトリのドリフト。シミュレーションのオドメトリは、そう設定したからドリフトします。実機では、タイヤの空気圧がわずかに低い、キャスターが振れる、床に数メートルおきに伸縮目地がある、制動時に積載物が重心をずらす、といった理由でドリフトします。
• 路面とトラクション。粉塵、ドック扉付近の薄い水膜、周囲と摩擦係数が違うエポキシ補修部、段差のリップ。車輪スリップは自己位置推定失敗の代表的な原因ですが、シミュレーションにはほぼ存在しません。
• タイミング。実機では認識処理がコントローラとCPUを奪い合い、Wi-Fiのローミングが機体外に出る通信にジッタを乗せ、シフト開始時のDDSディスカバリの集中がノードを止め、リカバリ動作を誘発することさえあります。
• 人。シミュレーションの歩行者はポリシーに従います。現実では、フォークリフトが内輪差でコーナーを切り、ピッカーがヘッドフォンを付けて通路に立ち止まり、パレットジャッキが通路に半分はみ出して置かれます。人の振る舞いには、スクリプト化された群衆では再現できないロングテールがあります。
• 時間とともに変わる環境。1週目に作った地図は、6週目にはもう存在しない建物を記述しています。ラックは動き、季節在庫が通路の形を変え、空きスペースだった場所に梱包材の塊が現れます。床マーキングの摩耗と照明の劣化が重なれば、カメラベースの検出やドッキングも一緒にずれていきます。

転移で生き残らないNav2のチューニング

以下の設定はどれもシミュレーション上では妥当です。だからこそ、実機の初日に開き直すべき項目でもあります。

最初に締めすぎるのがコストマップのインフレーションです。シミュレーションではobstacle layerが鋭いため、小さいinflation_radiusと強いcost_scaling_factorでも、狭い隙間を縫う美しい経路が出ます。現場では同じ値が、偽反射が出るたびにロボットを自分の安全マージンの内側に置き、プランナは昨日通った経路を拒み始めます。インフレーションは、きれいなスキャンではなく、実測したセンサノイズと現実の自己位置の不確かさに合わせるものです。

次がフットプリントです。多くのチームはシャーシをモデル化します。実際に出荷されるロボットは、後方にはみ出す積載物、突き出た充電接点、アンテナを持ち、積むものによって輪郭が変わります。フットプリントが積載物込みの実際の掃引形状でなければ、コストマップはコントローラに嘘をついています。

コントローラの選択は、転移の前より後のほうが効いてきます。DWBは理解しやすい反面、特定のシミュレーションシナリオに過剰適合させやすく、サンプリングした軌道は指令速度への追従が良いことを前提にします。MPPIはモデル誤差をよく吸収しますが、認識処理の後に残っていない計算資源を要求し、制御周期を落とし始めると挙動が変わります。Regulated Pure Pursuitは、長い通路を走る差動二輪ロボットには現実的な選択です。パラメータが少なく、挙動が読め、曲率や障害物近傍で素直に減速します。問うべきは「どれが最良か」ではなく、「劣化の仕方が運用チームにとって許容できるのはどれか」です。

リカバリ動作は、シミュレーションでは正直に試されることがほとんどありません。シミュレーション上のロボットは本当の意味で立ち往生しないからです。本番では絶えず走ります。積載状態で狭い通路を回るスピン動作は、空の仮想ホールでの動作とは別物ですし、幻の障害物を消すためのコストマップクリアは、そこに実在するパレットも一緒に消します。衝突監視（Collision Monitor）は最後の防衛線であって、唯一の防衛線ではありません。

自己位置推定は、シミュレーションが最も甘い顔をする領域です。静的地図に対するAMCLは、地図が正確なら安定して動きます。シミュレーションでは構造上、地図は常に正確です。稼働中の建物では、地図は歴史的文書です。Lifelong SLAMは地図を最新に保ちますが、別の失敗モードを持ち込みます。ロボットが世界の一時的な状態を素直に地図化し、それを信じてしまうのです。現実的な折衷案は、構造については管理された静的地図を持ち、再測量の手順を決めておき、自己位置の健全性を監視することです。そうすればロボットは、誤った位置へ自信満々に走る代わりに「自分は迷子だ」と宣言できます。

単機では起きず、フリートで壊れるもの

1台のロボットが建物を走るのは、ほぼ解決済みの問題です。面白い故障は2台目から始まり、10台目で複合します。

• 混雑は足し算ではありません。互いの姿がコストマップ上の移動障害物として現れ、双方が減速し、双方が再計画し、その再計画が、素早く復帰するために必要だった計算資源を食い潰します。
• 隘路でのデッドロック。ドア、エレベータホール、柱まわりの単線区間。2台が出会い、互いに譲り、互いに相手の経路へ再計画し、2台で振動します。Nav2は相手ロボットの意図を知りません。動いた障害物としてしか見えていません。
• 地図の乖離。各機が自前で地図を更新すると、同じ建物についての認識が機体ごとにずれ、2つのダッシュボードを見た運用者にはどちらが正しいか判断できません。
• 共有リソース。充電ドック、エレベータ、扉、狭い通路には調停が要ります。Nav2の内部に調停役はおらず、各機のビヘイビアツリーで即興的に作れば、持ち主のいない分散プロトコルが出来上がります。
• 相関故障。ネットワークの瞬断、時刻同期のずれ、不良な地図の配信は、シフトの最中に全機を同時に襲います。

構造的な答えは、交通管理はナビゲーションの上位レイヤだ、ということです。Nav2は1台をうまく走らせます。どの機体を先に通すか、誰が通路を占有するか、エレベータをどう予約するかは、Open-RMFなり自前のフリートマネージャなり、別の場所の仕事です。

段階的な検証のはしご

うまくいく方法は地味です。各段には、テストを走らせる前に合意した合格基準を置きます。

1. シミュレーション上のコンポーネントテスト。プランナ、コントローラ、ビヘイビアツリーを固定シナリオとアサーションで、コミットごとに。
2. ランダム化シナリオ。同じテストを、摩擦、センサノイズモデル、注入した遅延、質量と重心のばらつき、照明、ランダムな障害物で揺らして再生します。見るべきは合否ではなく、スタックが壊れ始める境界と、そこにマージンが残っているかどうかです。
3. 記録した現実に対するリプレイ。実際の建物で取ったbagファイルを、認識と自己位置推定に流し直します。自分で作っていないセンサノイズと向き合う、最も安上がりな方法です。
4. HIL（Hardware-in-the-Loop）。実機の計算ユニット、実際のセンサドライバ、実際のDDS設定に、世界だけをシミュレータから供給します。タイミング起因の問題はここで表面化します。ワークステーション単体の実行では決して現れません。
5. 実サイトでの1台。まず営業時間外の隔離エリアで、次に稼働中の現場で人が付き添って。2段目の目的は成功の証明ではなく、失敗の収集です。
6. 2台、そしてフリート全体を、最も楽な区画ではなく最も混雑する区画で。買っている情報は混雑時の挙動です。

段を飛ばすのは、自分では選べないタイミングで後から知ることを選ぶ、という決定です。

現場で計測すべき指標

効く指標は学術的ではなく運用的なもので、いずれも配備前に決めておく必要があります。稼働中のフリートに後から可観測性を足すのは、はるかに難しいプロジェクトです。

• 人的介入率。人がロボットに触れるたびに原因コードを付けて記録します。配備が経済的に成立するかを決める数字です。
• 再計画の間隔（距離と時間）。特定エリアでの再計画頻度の上昇は、地図・チューニング・レイアウトのいずれかがずれた最初の兆候です。
• 停止時間。ゴール保持中に静止していた累積時間を、人待ち・他機待ち・扉待ち・本当のスタックに分けて。
• リカバリの発火回数（種類別）と成功率。頻繁に発火して成功しているリカバリは問題を隠しています。頻繁に発火して失敗しているリカバリは、それ自体が問題です。
• 自己位置の健全性。姿勢共分散、地図とのマッチスコア、シフトあたりの再局在化回数。
• ニアミスと非常停止の発火。直前数秒のセンサデータを保持しておきます。

この数字を使えるものにする実務が2つあります。インシデントを再構成できる粒度でログを取ること。通常は生センサとTFのリングバッファを持ち、異常検知時に凍結します。そして現場で働く人たちと決まった頻度でレビューすること。「梱包エリアの近くでロボットの様子がおかしい」という運用者の一言は、グラフに現れるずっと前の本物の信号です。

チームに求められること

• シミュレーションをプロダクトとして持つ人。シナリオのカバレッジ、ランダム化のパラメータ、そして「何をモデル化できていないか」を正直に言えること。
• 物理的な真実を持つ人。キャリブレーション、センサの取り付け、車輪と積載のばらつき、そして変化し続ける建物そのもの。
• データと可観測性のエンジニアリング。フリートのテレメトリはパイプラインを要求します。bagファイルのフォルダでは足りません。
• 名前と頻度を持つ現場フィードバックループ。運用が故障を報告し、開発がシミュレーションで再現し、そのシナリオがリグレッション群に入り、修正がまたはしごを登る。事後にシミュレーションで再現できない故障は、それ自体がシミュレーションの穴です。
• デプロイの規律。フリートへのNav2パラメータ変更は本番デプロイです。段階的ロールアウトとロールバック経路を用意します。

文化面も同じくらい重要です。現場介入を恥だと扱うチームは、報告をやめます。介入のたびに追加すべきシナリオが1つ増えたと扱うチームは、毎週良くなります。

結論

Isaac Simは問題ではありませんし、忠実度をいくら上げても十分にはなりません。シミュレーションは、記述できる故障を潰す場所です。記述できなかったものはすべて建物の中で待っています。そこを抜ける道は、段階的な検証のはしご、必要になる前に仕込んだ計装、そして現場の故障を恒久的なテストへ変えるフィードバックループだけです。

動くフリートを出せるチームは、最もフォトリアルなシミュレーションを持つチームではありません。シミュレーションは間違っていると仮定し、どこが間違っているかを突き止めるプロセスを作ったチームです。

Abbealは、パリ・モントリオール・東京の拠点からエンジニアリングチームを構築・支援しています。ロボティクスとROS 2も対象です。ナビゲーションスタックをシミュレーションから本番フリートへ移す途中で、検証の進め方を一緒に整理したい方はご連絡ください。