第0章 はじめに ― なぜ今、ROS2を「使う側」の視点で整理するのか
― ROS2の座標系・オドメトリ・変換をエンジニア視点で整理する ―
ROS2は、自律走行、自動運転、空間認識（地図の認識や自己位置推定）といった分野を中心に、長年にわたって研究と実装が積み重ねられてきました。現在では、これらの技術は研究用途にとどまらず、エンジニアが実務や案件として利用できるレベルにまで成熟してきています。
もちろん、ROS2の内部では高度な数学や理論が数多く使われています。しかし、エンジニアとして成果を出す立場で考えた場合、それらを一つひとつ理論的に精査する必要はありません。研究者や開発者の方々が時間をかけて設計・検証してきた仕組みを前提として、正しく理解し、正しく使うことができれば十分です。
本記事では、ROS2を「勉強する対象」としてではなく、「動かすための道具」として捉えます。理論の正確さを競うのではなく、どのように動き、どのように見え、どのように扱えば破綻しないのかという、アプリケーションエンジニア視点で整理していきます。
第3弾となる今回は前提編として、実際にノードを動かす前に最低限押さえておきたい考え方を整理します。次回以降の実践編では、ここで整理した内容を実際に動かしながら体感していきます。
第1章 ROS2に登場する「主要キャラ」たち ― 概念ではなく、役割として理解する
ROS2の移動系を扱うと、必ず登場する要素があります。本章では難しい定義には踏み込まず、それぞれがどのような役割を担っているのかという観点で整理します。
/cmd_vel は、ロボットに対する移動命令を担当する存在です。前進、後退、旋回といった指示が、速度情報として送られます。重要なのは、これらの命令がロボット自身の目線、つまりロボット座標系で記述されているという点です。
/odom は、ロボットの自己位置、いわゆるオドメトリを知らせる役割を担います。現在の位置、向き、速度といった情報がまとめて配信されます。この情報は特定のノード専用ではなく、複数のノードやツールが共有して利用することを前提としています。
teleopは、人間の入力を/cmd_velに変換する橋渡し役です。キーボード操作などを通じて、人間の意図をロボットの移動命令へと変換します。teleop自身はロボットの内部構造を知りません。あくまで命令を送るだけの存在です。
ROS2の世界は、これらのキャラ同士がメッセージを介して会話することで成り立っています。お互いの内部実装に依存せず、決められた役割とインターフェースだけを守る疎結合な設計が、ROS2の大きな特徴です。
第2章 座標系とは何か ― 正しさではなく「見る立場の違い」
座標系という言葉に対して、数式や難解な理論を連想する必要はありません。エンジニア視点で重要なのは、同じ動きであっても、どこから見ているかによって数値の表現が変わるという点です。
移動ロボットには大きく分けて二つの目線があります。一つはロボット自身から見た前後左右の目線、もう一つは地図や空間全体から見た世界目線です。ROS2では、この二つの視点が明確に区別されています。
/cmd_velに流れる情報はロボット目線の命令です。一方、/odomは世界目線で見た結果を表します。この違いを理解していないと、動作が直感とズレて見えることがあります。
しかしそのズレは、バグや設計ミスではありません。単に見る立場が違うだけです。ROS2はこの前提のもとに設計されており、まずはこの考え方を受け入れることが重要です。
第3章 オドメトリとは何か ― ロボットが「信じている自己位置」
オドメトリとは、ロボットが「今ここにいるはずだ」と信じている自己位置のことです。必ずしも正確な位置を表しているわけではありません。
タイヤの滑りや計算誤差、センサー誤差などにより、オドメトリは時間とともにズレていく可能性があります。それでもオドメトリは、制御や判断、状態共有の基準として不可欠な情報です。
ROS2では、オドメトリは通常/odomトピックとして配信されます。この情報は、表示、ログ取得、自律制御、可視化など、さまざまな用途で同時に利用されます。
本シリーズで扱う仮想オドメトリは、センサーを使わず、命令と時間の経過だけから自己位置を計算します。この単純な構成により、オドメトリの本質が非常に分かりやすくなります。
第4章 変換とは何か ― 数学ではなく、アプリケーションの都合
ROS2における変換とは、難しい数学の話ではありません。エンジニア視点では、どの立場で情報を見たいかを決め、それに合わせて解釈する処理だと考えると分かりやすいでしょう。
世界座標で得られた移動量を、ロボットの向きに合わせて解釈することで、「前進しているのか」「後退しているのか」といった操作者の感覚に合った情報を得ることができます。
重要なのは計算式そのものではなく、なぜその変換が必要なのかという理由です。変換はユーザー体験を整えるためのアプリケーション設計の一部です。
第5章 teleopとodomがズレて見える理由 ― 違和感の正体
teleopで前進操作をしているにもかかわらず、/odomの数値が期待どおりに変化しないと感じることがあります。
この違和感は、座標系、オドメトリ、変換という前提を知らないと自然に生じます。しかし、これらを踏まえて見ると、ズレているのではなく、正しく別の視点で表現されているだけだと分かります。
この理解があることで、実際にノードを動かした際の挙動が安心して受け取れるようになります。
第6章 まとめ ― 動かすための最低限の地図
本記事では、コードを動かす前提として、ROS2における座標系、オドメトリ、変換の考え方をエンジニア視点で整理しました。
以下の次回の実践編では、ここで整理した前提を踏まえ、実際にノードを動かしながら挙動を確認していきます。
ROS2で「動いている感覚」をターミナルでつかむ