自分の位置が分かるだけでは自律移動はできない。周囲の地図を作り(SLAM)、その地図上でゴールまでの経路を計画・追従する(ナビゲーション)機能が必要になる。newbotでは3D LiDARによるオドメトリを土台に2D地図を生成するハイブリッド構成を採用し、Nav2でゴール到達を実現している。
ROS 2画像: Robot Operating Systemロゴ、Wikimedia Commons(CC BY-SA 4.0)
SLAM: 3Dオドメトリ + 2D地図生成のハイブリッド構成
当初は2D LiDARによる地図作成のみを想定していたが、3D LiDAR(Livox Mid-360)を活かすため、3D LiDAR-Inertial Odometry(FAST-LIO2)をオドメトリ源にし、2D(slam_toolbox)で大域地図を作るハイブリッド構成に変更した。FAST-LIOが出力する整形済みの3D点群を、水平方向にスライスして2D LiDARのスキャンデータ形式(LaserScan)へ変換するノードを介して、slam_toolboxへ入力する。生の3D点群形式は2D SLAMがそのままでは扱えないため、この変換が両者をつなぐ要になっている。
TFツリーは map --(slam_toolbox)--> odom --(FAST-LIO)--> base_link --(URDF)--> livox_frame という構成である。
Nav2: ゴール地点までの自律移動
Nav2は、地図上の指定したゴール地点まで、障害物を避けながら経路を計画・追従するナビゲーションスタックである。コントローラーが速度指令を生成し、速度平滑化・衝突監視を経てモーターへ送られる(この経路の詳細は「安全な速度制御の仕組み」の記事を参照)。
Nav2の導入過程では、公式のlaunchファイルのremap設定に、安全機構を実質的に無効化する重大な配線ミスが潜んでいたことを発見した。ナビゲーションコントローラーの生出力(未平滑化・衝突未チェック)が、衝突監視後の出力と同じトピック名で公開される設定になっており、下流のノードが意図せず未検査の指令を受け取ってしまう経路が存在していた。これはソースコードを直接確認して発覚したもので、実機走行前に見つけられたことは幸いだった。
実機初回自律走行までの道のり
実機での自律走行確認までには、Nav2の設定の他にもいくつかの環境固有の問題を解決する必要があった。Wi-Fi省電力設定に起因する通信の瞬断が、ROS2のノード間通信基盤(DDS)を不安定にしていた問題や、ナビゲーション完了後にゴールが正しくクリアされずに残留する不具合などが実機検証を通じて見つかっている。これらを一つずつ解消した上で、実機での自律走行(指定したゴール地点への到達)を確認した。
Nav2起動を安定させた机上点検
実機投入前の点検で、Nav2の起動プロセス自体に潜んでいた不具合をいくつか修正している。
- 空のBehavior Tree XMLパス:
default_nav_to_pose_bt_xmlパラメータが空文字列に設定されており、これが原因で起動時に空パスのBTファイルを読もうとして失敗する可能性があった。このパラメータ自体を削除し、Nav2同梱の既定BTに委ねる形にした。 - ライフサイクル管理下のノード設定漏れ: 使用しているNav2のバージョンでは、
navigation_launch.pyがsmoother_serverやwaypoint_followerもライフサイクル管理の対象として起動するが、対応する設定が存在しないとautostartが止まる可能性があった。両ノードの標準的な最小構成をパラメータファイルに追加して解消している。 - 未確定要素の排除: Nav2標準launchが内部で使うroute_server・docking_serverの起動可否が構成によって不確定だったため、必要な8ノードとlifecycle_managerだけを明示的に立ち上げる自作launchファイルに切り替え、起動失敗の可能性を決定論的に排除した。
2026-08-19、初めて成立した自律走行
これらの積み重ねの末、2026年8月19日に初めて「詰みのない自律走行」が成立した。8分30秒・14.88mを、局所化の暴走やNav2のデッドロック、ゴールの残留、非常停止のいずれも発生させずに走破し、フロンティア探査(未知領域の境界を順次目標にする手法)を完了して全面カバレッジフェーズへ遷移するところまで確認できている。
この到達点に至った決め手は、新機能の追加ではなく幾何・方位に関する3件の誤りを修正したことだった。具体的には、LiDARの搭載方位が90度ずれていたこと、車体後端の実測寸法が設定値と食い違っていたこと、その場旋回に必要な掃引半径の計算式が前端の寸法しか使っておらず後端を計算し忘れていたこと、の3点である。これらはいずれも足回りの物理寸法という基礎的な入力の誤りであり、それまでの詰みの多くはアルゴリズムの欠陥ではなく入力の誤りに起因していたことを示す結果になった。裏付けとして、障害物ガードを一時的に無効化してこの制約自体を取り除く実験も行ったが、走行の成功率は改善せず、むしろ悪化した。この結果は、詰みの原因が単純な過保護ではなく、より根深い設計上の課題であることを示している。
なぜ2件の寸法誤りが長期間見逃されていたか
車体後端の寸法と掃引半径の誤りは、単なる測り忘れではなく、「真実の置き場所」が分散していたことに根がある。車体寸法はURDF・Nav2のパラメータファイル・障害物ガードの設定ファイルという3箇所に、それぞれ独立した値として書かれていた。しかも障害物ガードの設定ファイルには「footprintの値に対応させている」というコメントまで付いており、2つの暫定値が偶然にも整合していたため、レビューで見比べても矛盾は見つからなかった。掃引半径に至っては、計算式そのものはコメントに明記されていたが、その式が車体前端の寸法しか使っておらず、より遠い後端の寸法を式に入れ忘れていた。式が書いてあることは、その式が正しく検証されたことを意味しない。
この経験から導いた対処方針は、寸法の真実をURDFの1箇所に絞り、footprint・オーバーハング・掃引半径といった派生値はそこから計算して導出するという設計への転換である。導出そのものにもテストを付け、footprintを入力に掃引半径や内接・外接半径を検算することで、今回と同種のバグを構造的に防ぐ狙いがある。
試験環境の広さという物理的な制約
自律走行の評価には、試験環境そのものの広さが強く影響することも分かってきた。使用している試験スペースは約1.9m²、機体の外接半径は0.327mで、その場旋回に必要な円の直径は0.654mになる。単純に計算すると、旋回可能な領域は面積比で全体の3割に満たない。差動駆動方式は横移動ができないため、姿勢を変える手段は事実上その場旋回に限られる。つまり試験環境の7割強では、姿勢を変えようとした時点で壁や障害物に接触しうるということになり、これは走行距離や探査アルゴリズムの巧拙とは別次元の制約である。一方で、必要な走行距離(走破幅から逆算した理論値)そのものは実際の走行距離を下回っており、「距離は足りているのに覆いきれない」という状況は、走行量ではなく姿勢の自由度不足が原因だと整理している。この整理から、アルゴリズムの改善よりも広い環境での再評価を優先度の高い施策として位置づけている。
カバレッジ探査アルゴリズムの評価関数とその限界
未探査領域の境界(フロンティア)から次の目標地点を選ぶ評価関数は、フロンティアの連結成分サイズ\text{size}とロボットからの距離dを使ったシンプルな式を採用している。
サイズを0.6乗という劣線形(sublinear)のべき乗にしているのは、単純にサイズに比例させると巨大な1つのフロンティアだけを優先し続け、小さいが近くにある未探査領域が後回しにされ続けるのを防ぐためである。分母に1.0を足しているのは、ロボットの現在地がフロンティアに極めて近い(d \to 0)場合にスコアが発散するのを防ぐ安全策になっている。実運用を通じて、この式にはいくつかの構造的な限界があることも分かってきた。
- 距離が直線距離である: 実際に走行する経路長ではなく、ロボットからの直線距離を使っているため、壁の裏側にあり実際には遠回りが必要なフロンティアを、近いと過大評価してしまうことがある
- 到達可能性を考慮しない: 選んだ目標が実際には到達不能だった場合、Nav2のタイムアウト(60秒)を経て初めて失敗と判定され、リトライを経てようやく除外リストに入る。1つの到達不能な目標のために数分単位の時間を浪費しうる
- ヒステリシスがない: 走行中に地図が更新されると評価値も変わるため、目標が短時間で入れ替わる(振動する)ことがある
- 障害物ガードのクランプ状態を考慮しない: 探査ノードは障害物ガードがどの方向をクランプしているかを見ていないため、物理的に進めない方向を選び続ける可能性が残る(この点は「安全な速度制御の仕組み」の記事で扱った、ガードとNav2が互いを知らないという設計課題とも関係している)
改善の方向性としては、直線距離をプランナの実際の経路コストに置き換えること、目標を送信する前に到達可能性を安価に判定すること、タイムアウトを短縮した上で失敗理由(クランプによる停止か経路自体が存在しないか)に応じて対処を分岐させることを検討している。
効果とコストの比で優先順位を並べる
一連の実測を経て、次に何へ投資すべきかを「効果÷コスト」の観点で並べ替えている。上位ほど実装コストが小さく効果が大きいと判断した項目である。
- より広い試験環境の確保 — 実装コストがゼロで得られる効果が最大。これをやらない限り、以降のどんな改善も効果を正しく測定できない
- LiDAR電源の根治(「自己位置推定とセンサーフュージョンの仕組み」の記事で扱った脱落の根本原因) — 1日あたり複数回の脱落は、他のあらゆる検証結果を汚染する
- エンコーダの分解能向上 — オドメトリの質が上がり、LiDAR脱落時のフォールバック先としてEKF経由の車輪オドメトリを積極的に使える道が開く
- 幾何をURDFから導出し、テストで守る — 前節で扱った2件と同種のバグを構造的に防ぐ
- 近傍センサーの追加 — LiDARの死角(高さ18cm未満の低い障害物)を埋める
- LiDAR再起動後の再局所化 — 自動復旧を「オドメトリが再開する」から「自己位置が本当に復旧する」へ引き上げる
- 障害物ガードとNav2の情報統合 — 詰みの発生率そのものを下げる本筋の対策(詳細は「安全な速度制御の仕組み」の記事を参照)
この順序自体が、今回の実測から導かれた結論を裏付けている。上位2件はアルゴリズムの改善ではなく、試験環境と電源という「物理的な余裕」の確保である。アルゴリズムに手を入れる施策(7番目)は最後に位置しており、賢い探査アルゴリズムやより高度なプランナへの投資は、現時点では優先順位が低いと判断している。