ロボ > ロボティクス on M1KE BL0G

ロボット発話のパラフレーズが意味を壊す問題とNLIによる対策

Wed, 14 Oct 2026 23:20:00 +0900

背景

Sevilla-Salcedo et al. (2023) “Using Large Language Models to Shape Social Robots’ Speech”（IJIMAI Vol.8 No.3）は、社会的ロボットの定型発話を単調にしないため、LLMでパラフレーズ（言い換え）を生成する仕組みを提案している論文
この論文には、パラフレーズによって意味そのものが変わってしまった失敗例が報告されている。例えば「¿Cómo te llamas?（お名前は？）」が「¿Cómo se llama la llama?（そのリャマの名前は？）」にパラフレーズされてしまうケース
SPRING: 高齢者介護施設における社会的ロボットの実証実験でも、LLMによる対話生成が「受診前は断食すべき」という世界知識ハルシネーションを起こした例が報告されている
どちらの論文も、BLEU・BERTスコアといった自動評価指標だけでは、この種の意味の変質を十分に検出できていなかった。パラフレーズ生成後に、生成文が本当に元の意味を保っているかを検証する技術を整理する

なぜBLEU・BERTスコアだけでは不十分か

IJIMAI論文では、パラフレーズの質をBLEU（語彙的な類似度）とBERTスコア（埋め込みベースの意味的な類似度）の2つで評価していた
BLEUはそもそも「元の文とどれだけ違うか」を測る指標で、パラフレーズ生成では逆に「元の文に似すぎていない」ことが望ましいとされるため、意味保持そのものの検証には向かない
BERTスコアはトークンの埋め込み類似度に基づく指標のため、単語の重なりが大きい文同士には高いスコアを出しやすい。「¿Cómo te llamas?」と「¿Cómo se llama la llama?」のように、単語の大部分が共通していながら、質問の対象（相手の名前 vs リャマの名前）が入れ替わってしまうような構造的な意味の反転は、検出しづらい

NLIによるパラフレーズの意味保持フィルタリング

Klemen & Robnik-Šikonja (2021) “Extracting and filtering paraphrases by bridging natural language inference and paraphrasing”（arXiv:2111.07119）は、NLI（Natural Language Inference、自然言語推論）を使って、パラフレーズの正しさを機械的に検証する、具体的で検証可能な手法を提案している

双方向含意というアイデア

2つの文A・Bが「AはBを含意し（entail）、かつBもAを含意する」という双方向含意（bidirectional entailment）の関係にあるとき、AとBはパラフレーズであるとみなす、というのがこの手法の基本的な考え方
逆に言えば、どちらか一方でも含意が崩れていれば、意味が変わってしまった「偽のパラフレーズ」とみなせる
実際の判定には、含意確率に対する閾値（argmaxで判定する方法に加えて、0.75・0.90というより厳しい閾値）が使われ、閾値を上げるほど適合率が上がる一方で再現率は下がる、というトレードオフになる

実際の検証結果

BERT・multilingual BERT・RoBERTa（base/large）・XLM-RoBERTa（base/large）というNLIモデルを、SNLI（約57万件）・MNLI（約41万件）・XNLI（15言語、11.25万件）というNLIデータセットで検証している
この基準を既存のパラフレーズデータセットに適用したところ、QQPでは14.9万件中1.3万件（9.0%）、MRPCでは3,900件中230件（5.9%）が、実は意味の異なる「偽のパラフレーズ」として検出された
手動検証でも、フィルタリングで除外されたペアの90%以上が、実際に意味の異なる非パラフレーズだったことが確認されている
英語で学習した1つのモデルを15言語に適用する多言語設定でも、ドイツ語・フランス語で約80%の精度でパラフレーズを抽出できており、多言語のHRIシステムにも応用しやすい

HRIのパラフレーズ生成への応用

IJIMAI論文のパイプラインでは、パラフレーズ生成後の検証はBERTスコアのみで、NLIベースの検証は使われていなかった
仮に「¿Cómo te llamas?」と「¿Cómo se llama la llama?」のペアに双方向含意のチェックを追加していれば、前者は「名前を聞かれているのが話し相手」、後者は「名前を聞かれているのがリャマ」という点で、互いに含意し合わないため、このペアは機械的に弾けた可能性がある
SPRING論文・IJIMAI論文はどちらも、高齢者や認知機能に配慮が必要な利用者を対象にしている。意味がわずかに変わっただけでも混乱を招きやすい対象であることを踏まえると、生成後にNLIベースの意味保持チェックを挟む追加コストは、十分に見合うと考えられる
具体的には、パラフレーズ生成→NLIモデルで双方向含意を判定→含意が崩れていれば元の定型文にフォールバック、という追加ステップを、既存のパラフレーズ生成パイプラインの後段に挟む形になる

まとめ

IJIMAI論文のパラフレーズ生成には、意味が変わってしまう失敗例が実際に報告されており、BLEU・BERTスコアだけではこの種の失敗を十分に検出できていなかった
Klemen & Robnik-Šikonja (2021)のNLIベースの双方向含意フィルタリングは、QQP・MRPCという既存データセットから5〜9%の「偽のパラフレーズ」を検出できる、具体的で検証済みの手法
ロボットの発話パラフレーズのように、特に意味の正確さが重要なHRIの文脈でも、生成後にNLIベースの検証ステップを挟むことで、意味ドリフトを機械的に検出し、元の定型文にフォールバックすることができる可能性がある

参考文献

Sevilla-Salcedo, J., Fernández-Rodicio, E., Martín-Galván, L., Castro-González, Á., Castillo, J. C., & Salichs, M. A. (2023). “Using Large Language Models to Shape Social Robots’ Speech” International Journal of Interactive Multimedia and Artificial Intelligence, Vol. 8, No. 3 (DOI:10.9781/ijimai.2023.07.008、PDF)
Klemen, M., & Robnik-Šikonja, M. (2021). “Extracting and filtering paraphrases by bridging natural language inference and paraphrasing” (arXiv:2111.07119、PDF)
SPRING: 高齢者介護施設における社会的ロボットの実証実験
ROS4HRIの仕組み
How To Paraphrase In Six Easy Steps - A Comprehensive Writing Guide

Séverin Lemaignan論文チェック: ROS4HRI標準化論文

Wed, 14 Oct 2026 16:20:00 +0900

背景

ROS4HRIの仕組み・SPRING: 高齢者介護施設における社会的ロボットの実証実験で、ROS4HRIのエコシステムや、それを実際の医療現場で使った実証実験を整理してきた
Séverin Lemaignanは、PAL RoboticsでROS4HRIの開発に携わった研究者の1人（Mohamed & Lemaignan 2021でROS4HRIを提案し、2023年にREP-155として標準化）。今回は、その標準化内容をまとめたRos, Lemaignan, Ferrini, Andriella, Irisarri (2023) “ROS4HRI: Standardising an Interface for Human-Robot Interaction”（HRI 2023 Workshop “Advancing HRI Research and Benchmarking Through Open-Source Ecosystems”、ストックホルム）を、実際にPDFを読んで確認する

論文の問題意識: HRIにおけるベンチマークの困難さ

HRI（Human-Robot Interaction）研究では、人間の振る舞いの複雑さ・多様さゆえに、ベンチマークと再現性の確保が本質的に難しい
それに加えて、標準的かつオープンソースなソフトウェアプラットフォームが存在しないことが、問題をさらに悪化させている
唯一広く使われているのは、Aldebaran社のNAOqiフレームワーク（Nao・Pepperロボット向け）だが、オープンソースではなく、Aldebaran製ロボット以外では使えない
ROS4HRIは、Mohamed & Lemaignan（2021, IROS）で提案され、2022年にROS REP-155として正式に標準化された。ROS上に構築され、特定のロボットに依存しない設計になっている
論文は、ROS4HRIがベンチマーキング・再現性の問題を改善する理由として、(1) 異なるアルゴリズム間で直接性能比較できる共通インターフェースの確立、(2) あるソフトウェア基盤から別の基盤への移行をシステム全体から透過的にする、持続可能なソフトウェア開発の支援、の2点を挙げている

人間のIDモデル: 4種類のID

ROS4HRIの仕組みで扱った4種類のID（Face・Body・Voice・Person）について、論文では以下のように詳述されている
Face・Body・VoiceのIDは非永続的で、特徴が失われた時点（例えば人物がロボットの視界から外れた時点）で、そのIDはもう意味を持たなくなる。異なる検出器同士が、人物が再出現した際に同じIDを再割り当てしようと試みる必要はない、という設計方針も明記されている
Person IDは永続的で、一度割り当てられると、ロボットの知識として永続的に残り続ける
person_<personID>フレームは、/humans/persons/<personID>/location_confidenceの値と合わせて解釈する必要があり、以下の3つのケースに分かれる
- 追跡中（personIDが設定され、face/body/voiceのいずれかのIDが設定されている）: location_confidenceは1で、person_<personID>フレームは、利用可能なface/skeleton/音源定位などの最良の推定位置と同じ場所に置かれる
- 現在は見えていないが、過去の位置情報がある: location_confidenceは0より大きく1未満の値になり、その間はperson_<personID>フレームが配信され続ける
- 存在は分かっているが位置情報が全くない（例えば対話を通じて存在を知った場合）: location_confidenceは0になり、TFフレームは配信されない

人体キネマティクスモデル

ROS4HRIは、人体の運動学的モデルの表現にURDF規格を採用している
人体は15個のリンクが18個の関節（頭・肩・肘・膝・腰・腰部）で接続された構造として表現される
人によって身長・体格が異なるため、身体が検出されるたびに、観測された身長を主パラメータとして、標準的な人体測定学の比率から肩幅などの他の寸法を導出した、カスタムのURDFモデルを生成する
生成されたURDFモデルは、bodyIDをキーにROSパラメータサーバーに登録され、ネットワーク上の他のノードから利用できるようになる

ROSトピック構造とフレーム規約

全てのトピックは/humansというグローバルな名前空間の下にまとめられ、/humans/faces・/humans/bodies・/humans/voices・/humans/persons・/humans/interactionsという5つのサブ名前空間に分かれる
顔・身体・声・人物のフレーム命名規則について、論文では座標系の原点の定義まで踏み込んで説明している

フレーム	原点の定義
`body_<bodyID>`	両腰の中間点。x軸は前方、z軸は頭方向
`face_<faceID>`	セリオン（鼻と額がなす角の最も深い正中点）。x軸は前方、z軸は頭頂方向
`head_<bodyID>`	骨格トラッカーが頭部姿勢を推定できる場合に配信される、セリオン位置のフレーム。`face_<faceID>`と整合性を取ることが、顔検出器・骨格トラッカー双方の責任とされる
`gaze_<faceID>`	`face_<faceID>`と同じ位置だが、カメラの光学フレームの慣習（z軸が前方、y軸が下方）に従う

Intents（意図）の設計

2023年3月時点のREP-155は、知覚側のみをカバーしており、行動・振る舞いの標準化はまだ扱われていない。プラットフォーム・アプリケーションに依存する部分が大きく、標準化が難しいため
論文では、ロボットが実行すべき操作の抽象的な記述として、Intent（意図）の標準化に向けた最初の試みを紹介している
Androidのintentに着想を得つつ、ROSのintentはユーザーが開始した（明示的・暗黙的な）意図を捉えることを主眼に設計されている。例えば、タッチスクリーンのボタン操作（明示的）、チャットボットとの対話結果（暗黙的・明示的）、ロボットを見るという行動（暗黙的）などが対象になる
hri_actions_msgs/IntentというROSメッセージ型として表現され、/intentsトピックに配信される。ユーザーの活動を追跡するノード（タッチスクリーン・対話マネージャー・動作認識など）が発行し、アプリケーションコントローラーがそれを受け取って、行動のスケジューリング・リソース配分（2つの動作が同時に使われないようにするなど）を行う
Intentは、intent種別・data（主題役割に基づくJSONオブジェクト）・source（ユーザーかロボット自身か）・modality（伝達手段）・priority（任意）・confidence（0〜1）というフィールドを持つ
副作用のない短い反応的な応答（天気を聞く、バッテリー残量を確認するなど）には、Intentの仕組みは使うべきではないとされている。ロボットの状態・リソースに影響しないため

可視化ツール

共通インターフェースの提供に加えて、システムの挙動を理解・分析するための可視化ツールも、hri_rvizパッケージなどとして提供されている

ツール	内容
Humans	顔・身体のバウンディングボックス、顔のランドマーク、2D骨格の関節を、ROSの画像ストリーム上に可視化するrvizプラグイン
Skeletons 3D	RobotModelに着想を得た、複数の検出済み身体を関節状態・位置・向きに基づいて3D骨格として可視化するrvizプラグイン
TF (HRI)	標準のtfツールの再実装。IDが`/humans/*/tracked`から消えると、関連するフレームが即座にシーンから削除される
rqt_human_radar	ロボットの基準フレーム（base linkなど）に対する人物の位置を、レーダーのような視点で表示するrqtプラグイン

PAL ARIとの関係・今後の展望

論文の最後では、PAL Robotics社の社会的ロボットARI（Cooper et al. 2020、2019年初出荷）の認知アーキテクチャを、ROS4HRIの上に構築中であることが述べられている
ARIは、SHAPES・SPRING・TALBOT・PRO-CARED（EUプロジェクト）、NHOA・RAADICAL・AMIBA（国内プロジェクト）など、高齢者介護・支援ロボティクスに関する多数の研究プロジェクトで使われてきた。SPRINGの実証実験も、このプロジェクト群の1つにあたる
ARIのアーキテクチャは、(1) 人間の知覚パイプライン（ロボットの周囲の人物への気づきを拡張する）と、(2) 自然言語処理パイプライン（音声認識・音声分離・音源定位・対話管理）の2本柱で構成される
今後の方向性として、(1) インタラクションの可視化・記録ツールの拡充、(2) 表情認識・ジェスチャー認識・声の識別といった社会的機能の拡充、(3) コミュニティとのさらなる連携、(4) ROS4HRIのROS 2への移植、の4点が挙げられている。実際にROS4HRIはその後ROS 2に移植され、ROS4HRIの仕組みで扱った現在のエコシステムに繋がっている

まとめ

Ros, Lemaignan他 (2023)は、ROS4HRI（REP-155）の標準化内容を、HRI研究のベンチマーキング・再現性問題への対応として位置づけた論文
Face/Body/VoiceIDの非永続性・PersonIDの永続性、location_confidenceによるperson_<personID>フレームの3パターンの扱い、15リンク・18関節の人体キネマティクスモデルなど、ROS4HRIの仕組みで扱った内容の設計根拠が、この論文で詳しく説明されている
2023年時点では知覚側の標準化が中心で、行動側の標準化はIntent（Androidのintentに着想を得た、ユーザー起点の意図の抽象表現）として初期段階にあった
可視化ツール（Humans・Skeletons 3D・TF (HRI)・rqt_human_radar）の存在が、ROS4HRIがオープンな開発・デバッグエコシステムとしても機能していることを示している
ARIロボットの認知アーキテクチャをROS4HRI上に構築する計画が述べられており、これがSPRINGの実証実験のような、後の大規模な実証研究に繋がっている

参考文献

Ros, R., Lemaignan, S., Ferrini, L., Andriella, A., & Irisarri, A. (2023). “ROS4HRI: Standardising an Interface for Human-Robot Interaction.” In 2023 ACM/IEEE International Conference on Human-Robot Interaction (HRI) Workshop on Advancing HRI Research and Benchmarking Through Open-Source Ecosystems, Stockholm, Sweden. (PDF)
Mohamed, Y., & Lemaignan, S. (2021). “ROS for Human-Robot Interaction.” In 2021 IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS). (DOI:10.1109/IROS51168.2021.9636816)
Cooper, S., Di Fava, A., Vivas, C., Marchionni, L., & Ferro, F. (2020). “ARI: The social assistive robot and companion.” In 2020 29th IEEE International Conference on Robot and Human Interactive Communication (RO-MAN).
ROS4HRIの仕組み
SPRING: 高齢者介護施設における社会的ロボットの実証実験

SPRING: 高齢者介護施設における社会的ロボットの実証実験

Wed, 14 Oct 2026 16:10:00 +0900

背景

ROS4HRIの仕組みで、hri_person_manager（Mr. Potato algorithm）やPAL Robotics ARIといった、ROS4HRIのエコシステムを構成する要素を整理した
Alameda-Pineda, Addlesee, Hernández García他 (2024) “Socially Pertinent Robots in Gerontological Healthcare”（arXiv:2404.07560）は、これらの要素を組み合わせた実際のシステムを、高齢者介護施設で60人以上の患者・付添人を対象に検証した論文。ROS4HRIが実際の医療現場でどう使われているかの実例として、内容を整理する

論文の概要

EUのHorizon 2020プロジェクト「SPRING」の成果として、フランス・パリのBroca老年医学デイケア病院で、会話可能な社会的ロボットを実際の患者・付添人に使ってもらい、受容性（Acceptability）とユーザビリティを検証した実証研究
著者は、SPRINGプロジェクトに参加する複数機関にまたがる44名（筆頭著者はAlameda-Pineda、Addlesee、Hernández García）
臨床試験として登録されており（NCT05089799）、フランスの倫理審査委員会（CPP Ouest II）・パリ大学の倫理委員会の承認を得て実施された
arXivプレプリント（2404.07560）として公開された後、共著者Angus Addlesee氏のLinkedIn投稿によれば、International Journal of Social Roboticsに正式に掲載された

使用ロボット: PAL Robotics ARI

使用されたロボットは、PAL Robotics社のARI。ROS4HRIの仕組みで紹介した対応ロボットの1つ
身長1.65m、差動二輪駆動の移動ベース、タッチスクリーン付きの胴体、可動する腕、LCDの目を持つ表情豊かな頭部を備える
センサーとして、胴体前面の4マイクアレイ、頭部のRGBカメラ、胸部・背面の180度魚眼カメラ2台を搭載する

システムアーキテクチャ: 8つのモジュール

システム全体は、知覚系・行動系あわせて8つのモジュールで構成され、ROS 1 Noetic上で、52個のROSノードが170以上のトピック・アクションを介して通信する構成になっている
論文のFig. 2（アーキテクチャ全体図）を見ると、センサー（マイクアレイ・頭部カメラ・魚眼カメラ・RGB-Dカメラ）からアクチュエータ（スピーカー・モーター）まで、各モジュールがどう繋がっているかが一目で分かる

マイクアレイ・頭部カメラ・魚眼カメラがSpeech Processing・Human Localisationに入り、そこからBehaviour Analysisを経てPerson Managerに集約される。RGB-DカメラはSelf-Localisation専用の入力になっている
Person Managerに統合された人物情報は、Multi-party ConversationとNon-verbal Behaviourの両方に渡され、それぞれSpeech Synthesis（スピーカー）とMotors & Actuators（モーター）という、ロボットの実際の出力に繋がる
Experimenter Interfaceは、Multi-party Conversation・Non-verbal Behaviourの両方と接続されており、実験者がシステムの挙動をリアルタイムに監視・介入できるようになっている

知覚系

モジュール	内容
Self-Localisation	RTABMapとHLOC（Hierarchical-Localisation）を組み合わせ、90%のクエリで位置誤差1cm未満・回転誤差0.2度未満という精度で自己位置推定を行う
Human Localisation	視覚トラッカーFairMOTと、音源方向推定（GCC-PHAT）を組み合わせて人物を追跡する。姿勢推定にOpenPose、グループ検出にGCFFアルゴリズムを使う
Speech Processing	音声強調（Mixture of Deep Experts、Sep-TFAnet）、VAD・音源方向・話者埋め込み（ECAPA-TDNN）の抽出、NVIDIA RIVAによる音声認識という多段パイプライン
Human Behaviour Analysis	視線先の検出、視線分析によるエンゲージメント（社会的受容）の自動検出、表情感情認識（FER）、音声感情認識（SER）
Person Manager	ROS4HRI標準の実装で、顔・身体・声の特徴を1人の人物に統合する。ROS4HRIの仕組みで扱ったMr. Potato algorithmがここで使われている

補足: Person Managerによる特徴統合の具体例

論文のFig. 3は、Person Managerが実際にどうMr. Potato algorithmを使って、顔・身体・声をグループ・人物に統合するかを、具体的な数値例で示している

左側が、知覚モジュール（顔検出・骨格追跡・音源定位など）が個別に出力した、ノード（Body・Voice・Face・Person・Group）間の関連尤度グラフ。例えば「Body 1」と「Voice 2」の間には尤度0.9のエッジがあり、強く関連していそうだと分かる
右側が、Person Managerがこのグラフ全体の尤度を最大化するように調整した後の結果。左側で灰色になっていた弱い関連（例えば「Face 1」周りの0.1・0.6・0.2・0.8といったエッジ）は切り捨てられ、代わりに新しいPerson 3が追加されて、Body 1・Voice 2と紫色のエッジで結び直されている
キャプションの注記にあるように、Body 1とVoice 2という2つの特徴が、どの既存のPersonにも十分な尤度で結びつかなかったため、Person Managerが新しい匿名の人物Person 3を生成して割り当てている。これは、ROS4HRIの仕組みで触れたMr. Potato algorithmの要件「特徴に紐づく人物が見つからない場合は匿名の人物に紐付ける」が、実際にどう動くかを示す具体例になっている

行動系

モジュール	内容
Multi-party Conversation Manager	LLMを組み込んだ対話システムで、複数人が同時に参加する会話の目的追跡や、「誰に話しかけられているか」の認識を行う
Non-verbal Behaviour Generation	Petri-Net Plannerをベースにした行動マネージャーに、ジェスチャー・視線のコントローラー、人の存在を考慮した経路計画（MPCベースのSocial Navigation Controller）を組み合わせる
Experimenter Interface	タブレットから実験者がシステムを監視・操作するためのインターフェース

補足: Petri Netの基礎

Behaviour Manager（行動マネージャー）が基盤にしているPetri-Net Planner（PNP、Dondrup et al. 2019）を理解するため、Petri net自体の基礎を、Bonet & Haslum (2011) “Petri Nets (for Planners)"（ICAPS 2011チュートリアル）を読んで確認した
Petri netは、プレース（場所）・トランジション（遷移）・有向アーク（矢印）からなる離散イベントシステムのモデル化手法。C.A. Petriが1960年代に考案した
各プレースは0個以上の「トークン」を持つことができ、トークンの配置全体を「マーキング（marking、ロボットの行動文脈でいえば「今の状態」）」と呼ぶ
あるトランジションは、入力アークで繋がる全てのプレースにトークンがあるとき「発火可能（enabled）」になる。発火すると、入力側のプレースからトークンを消費し、出力側のプレースにトークンを生成する
複数のトランジションが同時に発火可能な場合、どれが発火するかは非決定的（non-deterministic）に決まる。これが、Petri netが複数のタスクの並行実行や、状態に応じた分岐を自然に表現できる理由になっている
特に「safe（1-bounded）」なPetri net（各プレースのトークンが常に0か1）は、プレースを命題（fluent）とみなせるため、STRIPS/PDDL形式のプランニング問題（各atomをプレース、各grounded actionをトランジションとして、前提条件を入力アーク・効果を出力アークに対応させる）に直接変換できる
SPRING論文のPNPは、この枠組みを使って、ロボットの行動（発話・ジェスチャー・視線・ナビゲーションなど）をPetri-Netのプランとして表現し、複数のPetri-Netマシンを並行実行しながら、ROSのトピック・アクションで実際の制御に繋げている

「人の存在を考慮した経路計画」の具体的な仕組みが、論文のFig. 5に示されている

人物・会話グループの位置を中心に、2Dガウス関数的な「社会的空間」のコスト分布（等高線で図示）を定義する。コストは、向き・移動方向・立っているか座っているかといった状態に応じて変化する
経路計画は、この社会的空間のコストと、障害物の占有マップのコストを組み合わせた損失関数$J$を最小化する形で、モーター出力の制御軌道を最適化する
図の例では、ロボットが右上のTarget Personに向かう際に、左側の2つの会話グループ（コンター表示）を避けるように、青い経路が迂回して描かれている。グループの真ん中（Group Centre）を突っ切らないよう、コストの低い領域を縫うように経路が計画されている

実験の概要

フランス・パリのBroca老年医学デイケア病院で、2つの波に分けて実験を実施した

波	期間	参加者
Wave 1	2023年5月〜7月	20名（患者15名、付添人5名）
Wave 2	2023年9月〜2024年1月	43名（患者33名、付添人10名）

合計63名が参加し、1回のインタラクションは5〜10分程度
ロボット搭載のカメラ・マイクと、外部カメラで記録を取り、インタビューの書き起こしは合計1,142分（418ページ）に及ぶ

評価結果

AES・SUSという2つの指標

受容性の評価には、Acceptability E-Scale（AES、6項目、6〜30点、消費者に受け入れられる目安は25/30）と、System Usability Scale（SUS、10項目、0〜100点、目安は72/100）という、2つの標準化された尺度を使っている
内部一貫性（信頼性）は、AESでCronbachのα=0.87、SUSでα=0.86と報告されている

スコアの結果

波	対象	AESスコア	SUSスコア
Wave 1	患者	14.7（±5.73）	45.5（±20.21）
Wave 1	付添人	18.0（±4.64）	55.0（±28.28）
Wave 2	患者	20.7（±6.25）	56.8（±12.63）
Wave 2	付添人	21.0（±3.30）	57.5（±10.40）

AESスコアは、Wave 1（平均15.5、SD5.88）からWave 2（平均20.8、SD5.20）にかけて、統計的に有意に上昇した（F(1,52)=10.42、p<.001、η²=.17）
この改善は、主に音声認識のファインチューニングと、対話管理へのLLM統合によるものとされている
好まれる用途を尋ねたところ（Fig. 8）、エンターテインメント（40%）、健康リスクなしでの社会的交流の促進（30%）、受診準備の補助（23%）、受付・案内（5%）、道案内（2%）という割合だった

倫理的な懸念と限界

半構造化インタビューからは、以下のような懸念が挙がった
- データのプライバシー・透明性: データの保存方針が不明確なことへの不快感
- 外見: 機械的な見た目よりも、より温かみのあるデザインを求める声
- 医療現場でのミスへのリスク: 人間による監督があることで一定程度は緩和されている
- 感情的な依存のリスク: 特に脆弱な立場の利用者において懸念される
- 雇用代替への不安
研究自体の限界としては、以下が挙げられている
- インタラクションを拒否する人は対象から除外されたため、「拒否の認識」自体は評価できていない
- 実験にはNVIDIA RTX A6000（48GBメモリ）クラスの外部GPUが必要で、実運用上の制約になる
- マルチパーティ対話や、人を考慮した経路計画の能力自体は、病院内で正式には評価されていない
- 医療従事者側の受け止め方は評価対象に含まれていない
- 実験室が20m²未満と小さかったため、自己位置推定・ナビゲーション自体は「自明」な難易度だった

まとめ

SPRINGプロジェクトは、PAL Robotics ARIをベースに、ROS4HRI標準のPerson Manager（Mr. Potato algorithm）を含む8モジュール・52 ROSノードからなるシステムを構築し、フランスの老年医学デイケア病院で63名の患者・付添人を対象に実証実験を行った
AES・SUSという標準化された受容性・ユーザビリティ指標で評価した結果、Wave 1からWave 2にかけてスコアが統計的に有意に改善しており、音声認識の精度向上とLLMによる対話管理の強化が主な要因とされている
利用者はエンターテインメント・社会的交流の促進としての利用を好んだ一方、データのプライバシー・外見の温かみ・医療現場でのミスのリスク・感情的依存・雇用代替への不安といった、倫理的な懸念も半構造化インタビューから得られている
著者らは、本研究を「60人以上の実際の患者・付添人を対象に、これほど高度なインタラクションアーキテクチャを検証した初めての事例」と位置づけている

参考文献

Alameda-Pineda, X., Addlesee, A., Hernández García, D., et al. (2024). “Socially Pertinent Robots in Gerontological Healthcare” (arXiv:2404.07560)。International Journal of Social Robotics掲載版のPDFはこちら
Angus Addlesee氏によるLinkedIn投稿 - 本論文がInternational Journal of Social Roboticsに掲載された旨の告知
Bonet, B., & Haslum, P. (2011). “Petri Nets (for Planners)” (ICAPS 2011 Tutorial) (PDF)
ROS4HRIの仕組み

差動二輪ロボットの駆動系とAMCL・SLAM・Nav2

Wed, 14 Oct 2026 11:00:00 +0900

背景

ROS2の概念を理解するためのメモでTF2・SLAM・Nav2・Gazeboの概念をざっと整理したが、「ホイールのオドメトリとLiDARが、具体的にAMCL・SLAM・Nav2のどこに入り、どう使われるのか」という駆動系（ドライブトレイン）側の繋がりが曖昧だった
そこで、Gazebo上での差動二輪駆動（Differential Drive）のシミュレーションを起点に、オドメトリ・LiDARがAMCL・SLAM・Nav2にどう流れていくのかを整理する

全体像: 駆動系からナビゲーションまでのデータの流れ

大まかな処理の流れは以下の通り

順序	段階	内容
1	駆動系シミュレーション	Gazeboが、ホイールの関節の回転からロボットの移動をシミュレートし、オドメトリを計算する
2	センサーシミュレーション	Gazeboが、LiDARセンサーをシミュレートし、距離測定データを生成する
3	自己位置推定	AMCL（既知の地図がある場合）またはSLAM（地図がない場合）が、オドメトリとLiDARデータから、地図上での自己位置を推定する
4	経路計画・制御	Nav2が、推定された自己位置とLiDARベースのコストマップを使って、経路を計画し、速度指令（`cmd_vel`）を出す
5	駆動系への反映	`cmd_vel`がGazeboの駆動系シミュレーションに戻され、ロボットが実際に動く

つまり、駆動系（1・5）とセンサー（2）がGazebo側の入出力、自己位置推定（3）とナビゲーション（4）がROS 2側の処理という役割分担になっており、この2つがオドメトリ・LiDARデータ・cmd_velを通じて閉じたループを作っている

TFツリー全体像

このループを理解する上で軸になるのが、TF2が管理する座標フレームのツリー
代表的な構成は以下の通り

1

map -> odom -> base_footprint -> base_link -> base_laser（LiDARなど各センサーのフレーム）

変換	発行元	内容
`odom` -> `base_footprint`（実質的に`base_link`）	駆動系シミュレーション（Gazeboのプラグイン、実機ではモータードライバ側）	ホイールの回転から計算した、ロボット自身の移動量（オドメトリ）
`map` -> `odom`	AMCLまたはSLAM	オドメトリの誤差を、LiDARと地図の照合で補正した分のズレ
`base_footprint` -> `base_link`、`base_link` -> `base_laser`など	`robot_state_publisher`（URDFから自動計算）	ロボット本体の構造に対する、各フレーム・センサーの固定された取り付け位置

重要なのは、AMCL・SLAMはodom->base_link系の変換を書き換えるのではなく、それとは別にmap->odomの変換を発行するという点
odom->base_link系は駆動系が出し続けるオドメトリそのもの（ドリフトを含む、短期的には滑らかだが長期的にはズレていく値）であり、AMCL・SLAMはそのズレを、別のレイヤーで補正する役割分担になっている

TF2の仕組み: 分散システム前提の座標変換ライブラリ

TF2は、複数のノードに分かれて動く分散システムであることを前提にした、座標変換のためのライブラリ
各ノードが、自分の知っている2つのフレーム間の位置・姿勢関係をtransform_broadcasterで発行し、それらを集約することで、ロボット全体の全フレームが繋がった1つのツリーが構築される
位置・姿勢を知りたい側は、transform_listenerでこのツリーをたどり、任意の2フレーム間の変換を取得する
位置は$x, y, z$（メートル単位）、姿勢はクォータニオン（四元数）で表現される

ROS座標フレームの一覧

ここまで出てきたmap・odom・base_footprint・base_link・base_laserは、ROSのコミュニティで広く使われている座標フレームの命名規約（移動ロボット向けの標準規約REP-105ほか）に沿ったもので、それぞれの役割は以下の通り

フレーム	種類	内容
`map`	ワールド座標	ロボットが位置する世界座標系。REP-105によれば、Z軸が上向きで、地図に対する位置は長期的にほとんどドリフトしないが、再位置推定のタイミングで不連続にジャンプすることがある
`odom`	ワールド座標（ローカルに連続）	オドメトリ（車輪エンコーダなどの距離計）を積分した座標系。REP-105によれば連続的でなめらかな一方、実際の世界座標（`map`）とは長期的にズレ（ドリフト）ていく。このズレを補正するのが、前述の`map`->`odom`変換
`base_footprint`	ローカル座標	`base_link`を地面に投影したフレーム。XY座標・向きは`base_link`と連動するが、Z座標は常に地面の高さ（0）に固定される。2Dのナビゲーションアルゴリズムが、ロボットを平面上の点として扱えるようにするためのフレーム
`base_link`	ローカル座標	ロボット本体に固定された基準フレーム。車体の実際の高さ・姿勢を含む、ロボットそのものの位置
`base_laser`（本記事では`laser_link`と表記）	ローカル座標	LiDARなどのレーザースキャナが取り付けられている位置を表すフレーム。具体的な名前はロボットごとに異なる

mapとodomはどちらも世界座標だが、mapは長期的に正確な代わりに不連続、odomは連続的だが長期的にはズレていくという、正反対の性質を持つ
base_footprint・base_link・base_laserはどれもロボット本体を基準にしたローカル座標で、odom->base_footprintの変換さえ分かれば、そこから先は固定されたロボットの構造（URDF）だけで計算できる

Gazeboでの駆動系シミュレーション

差動二輪駆動の仕組み

差動二輪駆動（Differential Drive）は、左右2つの独立した駆動輪の回転速度の差で、前進・後退・旋回を実現する機構
左右輪の角速度を$\omega_L$、$\omega_R$、ホイール半径を$r$、ホイール間距離（トレッド）を$L$とすると、ロボット本体の並進速度$v$と角速度$\omega$は以下の式で計算される

$$ v = \frac{r(\omega_R + \omega_L)}{2}, \quad \omega = \frac{r(\omega_R - \omega_L)}{L} $$

Nav2やteleopノードがcmd_vel（並進速度$v$・角速度$\omega$）を指令すると、駆動系はこの式を逆に解いて、左右輪それぞれの目標角速度を求める

gz-simのDiffDriveシステムプラグイン

現行のGazebo（gz-sim、旧Ignition Gazebo）では、DiffDriveというシステムプラグインが、この差動二輪駆動のシミュレーションとオドメトリ計算をまとめて担う
実際にソースを確認したところ、役割は以下の通り

項目	内容
入力トピック	`/model/<モデル名>/cmd_vel`（`geometry_msgs/Twist`、トピック名は`<topic>`タグで変更可能）
出力トピック（オドメトリ）	`/model/<モデル名>/odometry`（`<odom_topic>`タグで変更可能）
出力トピック（TF）	`/model/<モデル名>/tf`（`<tf_topic>`タグで変更可能）
主なパラメータ	`<left_joint>`・`<right_joint>`（ホイールの関節名）、`<wheel_separation>`（ホイール間距離、デフォルト1.0m）、`<wheel_radius>`（ホイール半径、デフォルト0.2m）、`<odom_publish_frequency>`（オドメトリ配信周波数、デフォルト50Hz）
発行するTF	`frame_id`は`<モデル名>/odom`、`child_frame_id`は`<モデル名>/<ホイールが接続されたリンク名>`がデフォルト

つまり、SDF（Gazeboのロボット記述形式）やURDFの中でこのプラグインに左右ホイールの関節名と、ホイール半径・間距離を指定するだけで、cmd_velを受け取って物理的にホイールを回転させ、その回転量から上の式を使ってオドメトリを逆算し、odom->base_link相当のTFとトピックを配信してくれる
ROSとの橋渡し（ros_gz_bridge）を使うことで、これらのGazebo側トピックを、ROS 2標準の/cmd_vel・/odomトピックに変換して繋ぎ込む

オドメトリのドリフトという前提

このDiffDriveプラグインが計算するオドメトリは、ホイールの回転量だけから並進・回転を積分しているため、実機ではスリップ（ホイールの空転・横滑り）やエンコーダのノイズによって、時間が経つほど実際の位置とズレていく（ドリフトする）
Gazeboでも、タイヤと地面の摩擦パラメータ次第でこのスリップが再現されるため、オドメトリ単体では長時間・長距離の自己位置推定には使えない、という実機と同じ制約がシミュレーション上でも成り立つ
このドリフトを補正するのが、後述のAMCL・SLAMの役割になる

GazeboでのLiDARシミュレーション

GazeboのLiDARセンサープラグインは、仮想空間内でレイを飛ばして周囲のオブジェクトとの交差点を計算することで、実際のLiDARと同じ形式の距離測定データ（sensor_msgs/LaserScan、各角度ごとの距離値の配列）を生成する
このセンサーも、URDF上でbase_linkからの相対位置・向きを指定したリンク（例えばlaser_link）に取り付ける形で定義し、robot_state_publisherがそのリンクのTFフレームを自動的に配信する
出力は、ROS 2標準では/scanトピックとして配信され、このトピックを後述のAMCL・SLAM・Nav2のコストマップが共通して利用する

AMCL: オドメトリとLiDARで自己位置を補正する

パーティクルフィルタの基本

AMCL（Adaptive Monte Carlo Localization）は、既知の地図上でのロボットの自己位置を、パーティクルフィルタで推定する手法
「ロボットがここにいるかもしれない」という仮説を、数百〜数千個の粒子（パーティクル、それぞれが位置・向きの候補）として保持し、センサー情報が入るたびに、尤度の高い粒子を生き残らせ、低い粒子を淘汰する、というリサンプリングを繰り返す

動作モデル（オドメトリ）と観測モデル（LiDAR）

実際にリポジトリで確認したところ、AMCLはodom（オドメトリ）・scan（LiDARのスキャン）・map（既知の地図）・initialpose（初期位置の手動指定）をsubscribeし、particlecloud（粒子群の可視化用）・amcl_pose（推定された自己位置）をpublishする
動作モデルは、直前のオドメトリの変化量を使って、各粒子を同じだけ移動させる。ただし、ドリフトを考慮して、移動量にはランダムなノイズを加える
観測モデルは、各粒子の位置から見たときに、今回のLiDARスキャンがどれだけ「地図と一致していそうか」を計算し、一致度が高い粒子ほど尤度を高くする
この2つを組み合わせることで、「オドメトリでおおよその動きを予測し、LiDARと地図の照合でその予測を補正する」というベイズフィルタ的な推定を、観測が入るたびに繰り返す

map -> odom変換の補正という役割

AMCLは、odom->base_linkのTFを書き換えるのではなく、map->odomのTFを配信することで、地図座標系での自己位置を表現する
つまり、駆動系（DiffDriveプラグイン）が出し続ける生のオドメトリはそのまま残しつつ、AMCLがその上に「このオドメトリ座標系は、実際の地図上ではこれだけズレている」という補正値を重ねる、というレイヤー構造になっている
このため、AMCLが何らかの理由で推定に失敗しても、odom->base_link自体は駆動系から配信され続けるため、システム全体が完全に座標情報を失うことはない

SLAM: 地図がない場合はslam_toolboxが代わりを担う

AMCLは「既知の地図」が前提になっているため、未知の環境ではそもそも使えない
そこで使われるのが、2D LiDARベースのSLAMとしてよく使われるslam_toolbox
AMCLとの違いは以下の通り

項目	AMCL	slam_toolbox
前提	既知の地図が必要	地図は不要（走行しながら作る）
役割	自己位置推定のみ	自己位置推定＋地図作成（SLAM）を同時に行う
使う情報	オドメトリ＋LiDARスキャン＋既存の地図	オドメトリ＋LiDARスキャンのスキャンマッチングで地図を構築・更新
内部構造	パーティクルフィルタ	ポーズグラフ（過去の位置同士の関係をグラフ化）とループクロージャ（同じ場所に戻ったことを検出して誤差を補正）の最適化
発行するTF・トピック	`map`->`odom`	`map`->`odom`、および`/map`（占有格子地図）、`/slam_toolbox/pose`

slam_toolboxも、AMCLと同様にオドメトリとLiDARスキャンを使ってスキャンマッチングを行い、その結果をもとにmap->odomのTFを配信する、という同じレイヤー構造を取る
つまり、AMCLとSLAMは「地図を使うか作るか」の違いであり、駆動系（オドメトリ）・LiDARからの入力の受け方、map->odomという出力の形は共通している
作成した地図を保存しておけば、以降はAMCLで既知の地図として使い回せる、という使い分けになる

SLAMとAMCLは同時に動かさない

AMCLとslam_toolboxは、どちらもmap->odomのTFを配信する役割を持つため、両者を同時に動かすとこの変換が競合してしまう
通常の運用では、地図作成中はslam_toolboxが地図と自己位置の両方を提供し、地図が完成した後はAMCLに切り替えて、既知の地図上での自己位置推定に専念するという使い分けが基本になる
つまり「地図作成フェーズ（SLAM）」と「運用フェーズ（AMCL）」を明確に切り分け、同じタイミングでは片方しか動かさないのが前提

発展: 意味情報を加えるOWL/RDFとSemantic SLAM

ここまでのSLAM・AMCLは、あくまで「空間のどこに壁や障害物があるか」という幾何学的な情報を扱う技術で、「その場所が何をする場所なのか」という意味までは扱わない
OWL（Web Ontology Language）・RDF（Resource Description Framework）は、場所やオブジェクトに「101号室は病室」「薬品庫はスタッフ専用エリア」といった意味・関係をオントロジー・知識グラフとして記述するための標準規格で、SLAM・AMCLとは独立した、意味情報を載せるためのレイヤーにあたる
通常のSLAMが「そこに壁や物体がある」という幾何学的な地図しか作らないのに対し、Semantic SLAM（意味的SLAM）は「それはドアなのか机なのか部屋なのか」といった意味ラベルも地図に結びつける研究分野で、OWL/RDFはこの意味情報を整理する手段の1つとして使われることがあるが、必須というわけではない
ROS4HRIの仕組みのLLM対応チュートリアルで触れたknowledge_coreも、OWL/RDFベースの記号的な知識ベースであり、位置情報そのものではなく、その位置・場所が持つ意味を扱う用途で使われている
整理すると、SLAM（地図を作る）→AMCL（地図上で位置を知る）→OWL/RDF（その位置・場所に意味を与える）という積み重ねで理解すると分かりやすいが、OWL/RDFはSLAM・AMCLの必須要素ではなく、必要に応じて追加する別レイヤー

Nav2との接続: コストマップと速度指令

AMCL・SLAMがamcl_pose（またはそれに相当するTF）として自己位置を確定させると、Nav2はそれをもとにグローバルプランナーで大まかな経路を計画し、コントローラー（ローカルプランナー）が直近の障害物を避けながら実際の速度指令を計算する
この「直近の障害物」を表すのがコストマップで、/scanのLiDARデータがリアルタイムに反映される。地図上の静的な障害物（グローバルコストマップ）と、今まさにLiDARが検出している動的な障害物（ローカルコストマップ）の両方に、同じ/scanデータが使われる
最終的にコントローラーが計算した速度指令がcmd_velとして配信され、それが駆動系シミュレーション（DiffDriveプラグイン）に渡って実際にホイールが回り、ロボットが移動する。この移動がまた新しいオドメトリ・LiDARスキャンを生み、ループが続いていく

まとめ

Gazebo上の駆動系シミュレーション（差動二輪駆動の場合はgz-simのDiffDriveプラグイン）は、cmd_velを受けてホイールを回転させ、その回転量からオドメトリを逆算し、odom->base_linkのTFとトピックを配信する
このオドメトリは、ホイールの回転だけから積分した値のため、実機・シミュレーション問わずドリフトする。この誤差を補正するのが、既知の地図があるときのAMCL、地図がないときのslam_toolboxの役割
AMCL・slam_toolboxはどちらも、オドメトリ（動作モデル／スキャンマッチングの初期値）とLiDARスキャン（観測モデル／地図とのマッチング）を使い、odom->base_link自体は書き換えず、別レイヤーのmap->odomというTFを配信することで、地図座標系での自己位置を補正する
両者ともmap->odomを配信するため、同時には動かさず、地図作成フェーズ（SLAM）と運用フェーズ（AMCL）を切り分けて使う
Nav2は、この自己位置と、LiDARスキャンから作られるコストマップをもとに経路計画・障害物回避を行い、最終的な速度指令cmd_velを駆動系に戻すことで、駆動系→センサー→自己位置推定→ナビゲーション→駆動系という1つの閉じたループが成立する
SLAM・AMCLが扱うのはあくまで幾何学的な位置情報で、「その場所が何をする場所か」という意味はOWL/RDFのような別レイヤー（Semantic SLAMという研究分野も含む）で扱う、必須ではない拡張領域になる

参考文献

ROS4HRIの仕組み

Tue, 13 Oct 2026 16:30:00 +0900

背景

ROS上でHRI（Human-Robot Interaction、人間とロボットのインタラクション）を扱うための標準規格・OSSツール群であるROS4HRIについて、仕組みを整理する

ROS4HRIとは

ROS REP-155として仕様化された、ROS 1・ROS 2の両方に対応する、人間の認識・表現のための標準的なメッセージ型・規約
「ロボットが共有空間の中で人間を意味のある形で認識・解釈・応答できるようにする」ことを目的とした、オープンソースのリソース群
EUの資金援助を受けて開発されており、Apache 2.0ライセンスで公開されている
REP-155自体は、骨格追跡・顔認識・音声処理といった分野で、ROSエコシステムの他の分野ほど広く受け入れられた共通インターフェースがなかったという問題意識から作られている

REP-155の仕様

4種類のID

REP-155は、人物を4種類のIDで表現する

ID	永続性	割り当て元
Person ID	永続的なUUID。セッションを超えて同一人物を表す	顔認識・声認識など、人物識別が可能なノード
Face ID	非永続的。顔がフレームから外れると無効になる	顔検出ノード
Body ID	非永続的。骨格が追跡されている間だけ有効	骨格追跡ノード
Voice ID	非永続的	音声分離ノード

トピックの名前空間

全てのHRI関連トピックは/humans/以下に置かれ、faces・bodies・voices・persons・interactionsという5つのサブ名前空間に分かれる
例えば/humans/faces/<faceID>/croppedのように、個々の実体（顔など）ごとの名前空間を持つことで、下流のノードが情報を追加していける

なぜ単一のFaceメッセージではなく分割するのか

仮に全ての顔情報をまとめた汎用的な1つのFaceメッセージを発行する設計にすると、1つのノードが顔に関する全ての情報を先に統合しなければならなくなり、モジュール性が損なわれる
そのため、切り出し・表情認識・ランドマーク検出といった個々の情報を、別々のノードがそれぞれのサブトピックに発行する設計になっている

座標フレーム

REP-120の慣習に従い、以下のような座標フレームが定義されている

フレーム	原点	軸の向き
`face_<faceID>`	セリオン（両目の中間点）	x軸が前方、z軸が頭頂方向
`body_<bodyID>`	腰の中間点	x軸が前方、z軸が頭方向
`gaze_<faceID>`	`face_<faceID>`と同じ位置	z軸が視線方向
`person_<personID>`	追跡中はface/bodyフレームと同じ位置、そうでなければ最後に確認された位置	-

person_<personID>フレームの位置は、location_confidence（位置の確信度）によって扱いが変わる。追跡中は1.0、最近見えていた場合は1.0未満、既知だが一度も観測されていない場合は0になる
人体のキネマティックモデルは、頭・胴体・肩・肘・手首・腰・膝・足首など15個の主要なリンクで構成され、URDFが/human_description_<bodyID>としてパラメータサーバーに動的に読み込まれる

視線の非対称性

「AがBを見ている」という関係は、必ずしも「BもAを見ている」ことを意味しない。視線（Gaze）は送り手（sender）と受け手（receiver）の非対称な関係として表現される

Kinematic Model of the Human

The main 15 links defined on the human body are presented in the above diagram. Frames orientations and naming are based on REP-103 and REP-120. Right: render of the reference URDF model of the human body in rviz.

全体像: ROS4HRIエコシステムの構成

公式サイト（ros4hri.github.io）で確認すると、ROS4HRIは単なるメッセージ規約ではなく、「知覚→人物統合→インタラクションのスキル→UI・可視化」という一連の流れを、パッケージ群として提供するエコシステムになっている
大まかな処理の流れは以下の通り

順序	段階	内容
1	知覚（Perception）	カメラ・マイクから、顔・身体・声を個別に検出する
2	人物統合（Person Fusion）	検出された顔・身体・声を、hri_person_managerが1人の人物として統合する
3	インタラクションスキル（Interaction Skills）	統合された人物の情報を使って、発話・注視・ナビゲーション・動作・把持といった、標準化された「スキル」をロボットに実行させる
4	UI・可視化（UI & Visualization）	開発中のデバッグや、ロボットの対話用インターフェースの構築に使う

パッケージのカテゴリ一覧

公式サイトでは、パッケージは大きく5つのカテゴリに分けられている

カテゴリ	内容
コアライブラリ・メッセージ	hri_msgsなど、全体の基盤となるメッセージ定義・ライブラリ
知覚（Perception）	顔・身体・音声の検出と、それらを人物に統合する機能
インタラクションスキル	発話・ナビゲーション・操作など、ロボットに実行させる標準化された動作
可視化・デバッグ	開発時の確認・デバッグ用のツール
UI構築	対話的なユーザーインターフェースを作るための部品

下の表では、「知覚」と「インタラクションスキル」をさらに細かいサブカテゴリ（知覚（顔）・知覚（身体）など）に分けて示している

カテゴリ別パッケージ一覧

カテゴリ	パッケージ	役割
コアライブラリ・メッセージ	hri_msgs	顔・身体・声・人物に関する標準メッセージ
コアライブラリ・メッセージ	hri_actions_msgs	HRIのIntent（意図）に関する標準アクション
コアライブラリ・メッセージ	human_description	人体の標準URDFモデル
コアライブラリ・メッセージ	libhri（C++）／pyhri（Python）	ROS4HRIトピックを簡単に扱うためのライブラリ
知覚（顔）	hri_face_detect	顔検出・ランドマーク・視線
知覚（顔）	hri_emotion_recognizer	表情認識
知覚（顔）	hri_face_identification	顔の識別・認識
知覚（身体）	hri_body_detect	身体に関する知覚機能
知覚（音声）	asr_vosk	音声特徴の抽出・発話区間検出
人物追跡・統合	hri_face_body_matcher	顔と身体のマッチング
人物追跡・統合	hri_person_manager	人物への統合（Mr. Potato algorithm）
人物追跡・統合	hri_engagement	エンゲージメント（関わりの度合い）の追跡
インタラクションスキル	Communication	発話・対話（Say、Chat、Ask）
インタラクションスキル	Interaction	社会的インタラクション（LookAt、LookFor、LED、Expressions）
インタラクションスキル	Navigation	ナビゲーション（Navigate、Waypoints、Zones）
インタラクションスキル	Motions	動作実行（関節・直交座標系の軌道）
インタラクションスキル	Manipulation	操作（Grasp、Place、ハンド制御）
開発ツール	rpk	スキル・タスク・アプリケーションのパッケージ生成器
開発ツール	architecture_schemas / architecture_tools / std_skills	スキル定義のJSONスキーマ・検証・標準メッセージ
可視化・デバッグ	hri_rviz	RVizでの3Dスケルトン等の可視化プラグイン
可視化・デバッグ	hri_visualization	カメラ画像への顔・身体・表情のオーバーレイ表示
可視化・デバッグ	rqt_human_radar / rqt_chat	人物のレーダー表示／対話デバッグ用チャットUI
可視化・デバッグ	interaction_sim	HRI研究用のROS 2シミュレーション環境
UI構築	ui_server / ui_msgs / ros-qml-plugin	QMLを使った対話的UIの表示・ROS連携

対応ロボット

区分	ロボット	特徴
商用	PAL TIAGo	7自由度アーム＋昇降トルソーを持つ、研究向けモバイルマニピュレータ
商用	PAL TIAGo Pro	両腕7自由度、画面・LEDなどの対話機能を強化した上位版
商用	PAL TIAGo Pro Head	表情豊かな頭部のみの単体版。社会的信号・視線研究向け
商用	PAL ARI	受付・案内・エンターテインメント向けの、表情豊かな顔とジェスチャーを持つ社会的ロボット
OSS・研究用	EMOROBCARE	ICMAT/IIIA（CSIC）が開発する、自閉症療育向けの低コストな社会的ロボット（球状の台座＋3自由度の頭部）

開発元のPAL Robotics社自身が、TIAGo・ARIといった商用ロボットシリーズを展開しており、ROS4HRIはこれらのロボットの人間認識基盤としても使われている
EUのHorizon Europe研究助成を受けて開発されている

メッセージ定義: hri_msgs

ROS4HRIでは、人間の認識結果を表現するための専用メッセージ型が定義されている。実際にリポジトリをクローンして、msg/以下の17種類のファイルを確認した

カテゴリ一覧

17種類のメッセージは、内容に応じて5つのカテゴリに分けられる

カテゴリ	対象	含まれるメッセージ
顔・表情	顔から読み取れる情報	Expression、FacialActionUnits、FacialLandmarks、Gaze
身体	身体から読み取れる情報	Skeleton2D、Gesture、BodyPosture
属性・音声	年齢・性別や、音声から読み取れる情報	SoftBiometrics、AudioFeatures、LiveSpeech
集団・ID管理・関係性	複数の人物・特徴の間の関係	Group、IdsList、IdsMatch、EngagementLevel
幾何的なプリミティブ型	他のメッセージから使われる座標の基礎型	NormalizedPointOfInterest2D、NormalizedPointOfInterest2DStamped、NormalizedRegionOfInterest2D

顔・表情に関するメッセージ

メッセージ	内容
Expression	表情を、カテゴリ（neutral、angry、happyなど25種類、Chambers 2020年MSc論文・Ekmanの基本6感情モデルに基づく）と、Valence/Arousalモデル（感情のpositive/negative度を表すvalence、興奮度を表すarousal、それぞれ-1.0〜+1.0）の両方で表す
FacialActionUnits	Ekmanが開発したFACS（Facial Action Coding System）の命名に従い、99種類のAU（Action Unit、表情を作る顔の部位ごとの動き）それぞれの強度と確信度を配列で表す。頭の向き・視線の向き・顔の可視性なども含む
FacialLandmarks	dlib・OpenPoseの規約に従った70点の顔のランドマーク（輪郭・眉・目・鼻・口など）を、正規化された2D座標の配列として表す
Gaze	視線の送り手（sender）と受け手（receiver）の人物IDを表す。空文字列はロボット自身を意味する

身体に関するメッセージ

メッセージ	内容
Skeleton2D	OpenPoseのCOCOモデルの規約に従い、鼻・両肩・両肘・両手首・両腰・両膝・両足首・両目・両耳という18点の骨格キーポイントを、正規化された2D座標の配列として表す
Gesture	手を顔に当てる・腕を組む・手を挙げる・手を振るといった、身体から検出されるジェスチャーを表す
BodyPosture	立っている・座っている・しゃがんでいる・寝ているという、身体の姿勢を記号的に表す

属性・音声に関するメッセージ

メッセージ	内容
SoftBiometrics	推定した年齢・性別を、それぞれの確信度（confidence）付きで表す
AudioFeatures	INTERSPEECH 2009 Emotion Challengeで選定された16種類の音声特徴（ゼロ交差率、RMSフレームエネルギー、ピッチ、調波対雑音比、MFCC1〜12）を、openSMILEツールキットで抽出した値として表す
LiveSpeech	音声認識の途中結果（incremental）と最終結果（final）、その確信度、ISO 639-1の言語コード＋ISO 3166-1の地域コードによるlocale（例: en_GB）を表す

集団・ID管理・関係性に関するメッセージ

メッセージ	内容
Group	グループIDと、そのグループに属する人物IDのリストを表す
IdsList	顔ID・身体ID・人物IDなど、ROS4HRIのIDのリストを表す汎用的なメッセージ。例えば`/humans/faces/tracked`で、現在検出されている顔のIDの一覧が配信される
IdsMatch	一時的なID（顔・身体・声）と永続的なID（人物）の対応候補を、確信度付きで表す。確信度0.0は「この2つは対応しない」という意味を持つ特別な値。`/humans/candidate_matches`に配信され、Mr. Potato algorithmの入力になる
EngagementLevel	人間がロボットにどれだけ関わっているかを、unknown・disengaged・engaging・engaged・disengagingという5段階の離散値で表す。`/humans/persons/<person_id>/engagement_status`で配信される

幾何的なプリミティブ型

Skeleton2DやFacialLandmarksなど、複数のメッセージから共通して使われる、座標を表すための基礎的な型も定義されている

型	内容
NormalizedPointOfInterest2D	正規化された（0.0〜1.0の範囲の）点の座標（x, y）と、その点の確信度（c）を表す
NormalizedPointOfInterest2DStamped	NormalizedPointOfInterest2Dにタイムスタンプ付きヘッダを加えたもの
NormalizedRegionOfInterest2D	正規化された矩形領域を、左上（xmin, ymin）と右下（xmax, ymax）の座標と確信度（c）で表す

hri_actions_msgs: アクション・意図の定義

hri_msgsが「知覚（Perception）」側のメッセージを扱うのに対し、hri_actions_msgsは「アクション（Action）」側、つまりロボットに何をさせるか・人間が何を意図しているかを表すメッセージを扱う

Intent: 意図の表現

Androidのintentに着想を得た、ロボットに実行させたい操作を抽象的に表すメッセージ
intent（どの操作か）と、data（JSON形式のパラメータ）という2つの必須フィールドを持つ
dataの中身は、動作主（agent）・対象（object）・目的地（goal）・受け手（recipient）という、言語学の主題役割（thematic role）に基づくキーで指定する
例えば「キッチンにいるLukeに食材を持っていって」は、intent: BRING_OBJECT、data: {"object": "groceries", "goal": "kitchen_1", "recipient": "person_luke"}のように表現される

定義済みIntent	意味
RAW_USER_INPUT	意図の抽出に失敗した場合のフォールバック
ENGAGE_WITH	相手と関わりたい
MOVE_TO	指定した場所に移動する
GUIDE	誰かをどこかへ案内する
GRAB_OBJECT / BRING_OBJECT / PLACE_OBJECT	物を取る／持っていく／置く
GREET	挨拶する
SAY	指定したテキストを話す
PRESENT_CONTENT	画面などで決められたコンテンツを提示する
PERFORM_MOTION	ダンスや手を振るなどの動作を実行する
START_ACTIVITY / STOP_ACTIVITY	スクリプト化された振る舞いの開始・停止
WAKEUP / SUSPEND	システムの再起動・休止

Intentには、他にもsource（ロボット自身・リモート監督者・不明な相手のどれが発した意図か。REP-155準拠の場合は人物IDも使える）、modality（発話・動作・タッチスクリーン・内部処理のどれで伝えられたか）、priority（0〜255）、confidence（0.0〜1.0）といったフィールドがある

その他のメッセージ

メッセージ	内容
ActivityList	START_ACTIVITY／STOP_ACTIVITY Intentで起動できる、アクティビティ名の一覧
ClosedCaption	発話者ID・テキスト・localeを持つ、字幕（クローズドキャプション）表示用のメッセージ
LookAtWithStyle	注視対象の3D座標に加え、目だけ／頭だけ／両方（デフォルト）という、視線の動かし方のスタイルを指定する

アクション定義

ROS 2のAction（Goal・Result・Feedbackからなる、時間のかかる処理向けの通信方式）として、以下のようなものが定義されている

アクション	内容
LookAt	指定した3D座標を注視する
ApplicationControl	下位のアプリケーションコントローラーにJSON形式のパラメータを渡す
SelfPresentation	自己紹介などの、複数のフレーズからなる発話を実行し、進行状況（現在のフレーズ数／総フレーズ数）をフィードバックする
FaceOverlay	顔のディスプレイに画像・アニメーションを重ねて表示する。表示時間・レイヤー（背景／前景）・レイアウト（両目に表示／左右の目ごとなど）・スケール・位置・フェード効果を指定できる
PointTrajectory	複数の3D座標点と、それぞれに到達する時刻を指定し、軌道を描かせる

hri_person_manager: 顔・身体・声を1人の人物に統合する

カメラ・マイクなど複数のセンサーから得られる顔・身体・声の検出結果は、それぞれ別々に検出されるが、それらが同じ1人の人物のものだと紐付けなければ、ロボットは人間を1人の人物として認識できない
hri_person_managerは、検出された顔・身体・声を集約し、一貫した「人物（person）」として扱い、それぞれの検出結果への紐付けを外部に公開するノード

Mr. Potato algorithm

他のノード（顔認識ノードなど）が/humans/candidate_matchesに投稿する、IdsMatchメッセージ（特徴同士・特徴と人物の対応候補、確信度付き）を受け取り、確率的なグラフ（person features graph）を構築する
アルゴリズムは、クローンしたリポジトリのdoc/ALGORITHM.mdに、以下のような形式的な定義がある
- 特徴（feature）: 顔・身体・声のいずれか
- 許容されるパス（permissible path）: 同じ種類のノードを2つ以上含まない経路。尤度はパス上の尤度の積
- 関連（association）: 閾値（デフォルト0.5）を超える尤度の許容パスで結ばれた、ノードの連結集合
- 要件として、(1) 全ての関連の尤度の合計を最大化する、(2) 全ての特徴は必ず1人の人物（匿名も含む）に紐付く、(3) 人物に紐付かない特徴は匿名の人物に紐付ける、(4) 間接的なパスが切れた場合も、尤度が閾値を超えていれば直接的な関連として安定的に維持する、という4点が定義されている
この手法は、“Probabilistic fusion of persons’ body features: the Mr. Potato algorithm"という論文として発表されている（DOI: 10.1145/3610977.3637479）

パラメータ

パラメータ	デフォルト値	意味
match_threshold	0.5	顔・身体・声を同じ人物とみなす最小尤度
reference_frame	map	人物のTFフレームを配信する基準フレーム。固定された基準フレームを使うことで、人物が一度カメラの視界から外れても、最後に見えた位置に留まり続ける
personal_distance	1.2m	近接学（proxemics）に基づく、個人距離圏の上限
social_distance	3.6m	社会距離圏の上限
public_distance	20m	公共距離圏の上限

主なトピック

トピック	内容
/humans/candidate_matches	他ノードから受け取る、特徴同士・特徴と人物の対応候補
/humans/persons/known・/humans/persons/tracked	人物の一覧
/humans/persons/in_{personal\|social\|public}_space	各近接圏にいる人物の一覧
/humans/persons/<person_id>/proxemic_space	個々の人物の近接圏
/humans/graph	特徴同士の対応関係をDOT形式で可視化したもの

hri_engagement: 視線と距離からエンゲージメントを検出する

実際にリポジトリをクローンして確認したところ、hri_engagementは、Webb, Giuliani, Lemaignan (2022) “Measuring Visual Social Engagement from Proxemics and Gaze”（RO-MAN 2022、DOI: 10.1109/RO-MAN53752.2022.9900801）で定義された「visual social engagement」指標を使って、人物ごとのエンゲージメント状態を検出するノード
この指標は、ロボットと人物の距離と、相互注視（お互いがお互いを見ているか）の度合いを組み合わせたもの。カメラに映っている人物ごとに、この指標を一定時間窓で時間方向にフィルタリングし、結果をEngagementLevelとして/humans/persons/<person_id>/engagement_statusに配信する
動作には、hri_face_detect・hri_face_identification・hri_person_managerが事前に起動している必要がある。/humans/persons/trackedと/humans/persons/<person_id>/face_idをsubscribeし、エンゲージメント状態に加えて、人物が「関わっている」と判定されるとhri_actions_msgs/IntentのENGAGE_WITHを/intentsにpublishする
主なパラメータは以下の通り（config/00-default.yamlで確認）

パラメータ	デフォルト値	意味
reference_frame	sellion_link	距離・相互注視を計算する基準となる、ロボット側の視線方向フレーム
max_distance	4.0m	これより遠い人物は自動的にDISENGAGEDとみなされる
field_of_view	60度	人物・ロボット双方の「注意」の半画角。相手がこの範囲外なら見ていないとみなされる
engagement_threshold	0.5	ENGAGING/DISENGAGINGと判定する閾値
observation_window	10秒	エンゲージメントレベルを計算する時間窓。大きいほど判定が安定する
rate	10Hz	エンゲージメントレベルを計算・配信する周期

後述するIROS22のチュートリアルで自作する、相互視線の指標$M_{RP}$・$S_{RP}$は、次に見るWebb, Giuliani, Lemaignan (2022)論文で提案されている指標と、構造的にほぼ同じもの

Webb, Giuliani, Lemaignan (2022)論文を読む

OpenAlex経由で、UWE Bristolのリポジトリに置かれたオープンアクセス版の要旨を確認した（IEEE Xplore本体・UWEリポジトリのPDFは、どちらもアクセスがブロックされ直接は読めなかった）
この論文は、集団に近づいていく際に人がやり取りする、言葉・非言語の社会的シグナルに着目し、オンラインで88人の参加者を集めたデータ収集実験を行っている。参加者には、ソーシャルなやり取りを伴うゲームをオンラインでプレイしてもらい、その際の行動データを収集した
中心的な貢献は、proxemics（参加者間の距離）と相互注視（mutual gaze）という2つの社会的シグナルから導かれる、新しい視覚的エンゲージメント指標の提案
要旨によれば、相互注視の指標は「両者それぞれの光軸からの距離の積を、参加者間の距離で割ったもの」という数式で定式化されている。これは、hri_engagementのパラメータにあったfield_of_view（光軸からの許容角度）やmax_distance（距離の上限）の設計とも整合する
この指標を使って、参加者ごとに固有の「インタラクションスタイル」のプロファイルを作れることを示している。一方で、性格特性（パーソナリティ）とこのインタラクションパターンとの間には、明確な相関は見られなかったと報告されている
つまり、IROS22のチュートリアルで扱った$M_{RP}$（光軸からの距離の積）・$S_{RP}$（それを参加者間の距離で正規化したもの）という式は、学習用に簡略化されたものではなく、この論文で提案された指標そのものの構造を踏襲したものだったと分かる

libhri: 人間の認識結果への簡単なアクセス

ROS4HRIの各トピックを生のまま扱う代わりに、HRIListenerというクラスを通じて、検出された人間・顔・身体をオブジェクトとして扱える、簡易的なAPIを提供する
C++実装のhriパッケージと、それをPybind11でラップしたPython版のpyhriパッケージがある

チュートリアル

ROS4HRIには、公式サイトの新しいチュートリアルと、IROS22で行われた（ROS 1 Noetic時代の）より古いチュートリアルの、2種類がある

新しいチュートリアル: LLM対応インタラクティブアプリの構築

公式サイトには「ROS4HRIの知覚・スキルを使って、LLM対応のインタラクティブアプリを構築する」という、実践的なチュートリアルが用意されている
使われているツール・ノードは以下の通り

層	ツール・ノード	役割
知覚	gscam	Webカメラの映像を配信
知覚	hri_face_detect	顔検出（確信度の閾値付き）
知覚	hri_emotion_recognizer	検出した顔からの表情分類
知識・推論	knowledge_core	OWL/RDFベースの記号的な知識ベース（Webビューア付き）
知識・推論	hri_person_manager	顔・身体・声を1人の人物に統合
対話	dialogue_manager	発話の入出力管理
対話	ollama	ローカルLLM推論（カスタムのチャットボットが利用）
対話	rqt_chat	テキストでの対話確認用プラグイン
可視化	rqt_human_radar	検出した人物・空間的な関係のレーダー表示
制御・表出	interaction_sim	2Dのソーシャルインタラクション・シミュレーター

このチュートリアルで出てくるGUIは、ロボット・人間のアバターをSVGで描いた2Dの見下ろし型シミュレーター（interaction_sim）と、procedural（手続き的）に生成された目だけの表情豊かなロボットの顔の2種類がある。アニメ風に見えたのは、おそらくこのどちらか
手順は、Part 0（Docker環境構築）→Part 1（顔検出の動作確認）→Part 2（シミュレーターと知識ベースの導入）→Part 3（rpkでミッションコントローラーを生成し、/skill/sayでの発話や、検出した表情をロボットの表情にそのまま反映する「感情ミラーリング」を実装）→Part 4（ollamaでのLLM統合、意図抽出のプロンプト設計、知識ベースを使ったコンテキスト付与）という流れで進む

古いチュートリアル: IROS22のROS4HRI完全ウォークスルー

ROS 1 Noetic時代に、IROS22で実施された、1日がかりの完全なチュートリアル
題材として「OfficeBots」という、HRI研究用のマルチプレイヤーゲーム型シミュレーターを使っている。キャラクターを選んでプレイする、ゲームらしい見た目のGUIを持つ
3部構成になっている

パート	内容
Part 1	OfficeBotsを使い、ROS4HRIのAPIに触れながら、視線の合致度（mutual gaze）を使ったエンゲージメント推定器を自作する
Part 2	Webカメラの実データを使い、顔検出（hri_face_detect）・骨格検出（hri_fullbody）・ジェスチャー認識（waving検出）を実装する
Part 3	Rasaで作ったチャットボットと、音声認識結果（LiveSpeech）を統合した、マルチモーダルなチャットボットを完成させる

Part 1のエンゲージメント推定は、ロボットと人物が互いを見ている度合いを表す相互視線の指標$M_{RP}$（ロボットの視野内での人物の位置と、人物の視野内でのロボットの位置、それぞれの光軸からの距離の積）と、それを距離で正規化した社会的エンゲージメントの指標$S_{RP}=\min(1, M_{RP}/\text{dist}(R,P))$を使う
Part 2のhri_face_detect・hri_fullbody（2D/3D骨格検出）はどちらもGoogleのMediaPipeを使っている。骨格検出の結果はrobot_state_publisherとhuman_descriptionパッケージのURDFを使って、3Dの関節状態・TFツリーとして公開される
waving（手を振る）ジェスチャーの検出は、肩・肘・手首の間の距離（肩肘間・肘手首間・肩手首間）が、それぞれ特定の範囲（0.1〜0.25、0.1〜0.25、0.15〜0.25）に収まるかどうかで判定する、シンプルな閾値ベースの手法
Part 3では、音声認識結果を/humans/voices/<id>/speechからRasaのチャットボットサーバーに送り、その応答を/sayトピック（ROS4HRI標準ではない、OfficeBots独自のトピック）でロボットに発話させる
顔と人物の対応付けも、rostopic pub /humans/candidate_matches hri_msgs/IdsMatchのように、手動でIdsMatchメッセージを配信することで体験できる

今後の展望: 生理指標への拡張（Sense4HRI）

Scheibl, Leichert, Görmez, Wrede (2026, Bielefeld University) “Sense4HRI: A ROS 2 HRI Framework for Physiological Sensor Integration and Synchronized Logging”（arXiv:2603.19914）は、ROS4HRIを生理指標（EEG・ECG・PPGなど）の統合に拡張する論文
生理信号はHRIにおけるユーザーの心理状態の推定に重要性が増しているが、ROS 2ベースのHRIフレームワークには、こうしたデータストリームを標準化された形で統合する再利用可能な仕組みがまだ無いという問題意識から提案されている
センサードライバと解釈ロジックを分離し、PhysioRaw.msgという汎用的なメッセージ形式、ROS4HRIの命名規則に準拠した階層的なトピック名、複数センサーを同期させるためのデバイス側タイムスタンプなどを導入している
Polar社のECG・PPGセンサーと表情認識を統合したプロトタイプで、複数モダリティを組み合わせた感情状態の推定を実証している
ROS4HRI自体はこれまで顔・身体・声・表情といった外部から観測できる情報を中心にしていたが、Sense4HRIのような拡張によって、生理指標という内部状態の推定も同じ命名規則・名前空間の中に統合していく方向性が今後見込まれる

まとめ

ROS4HRI（REP-155）は、ROS上で人間を認識・表現するための標準的なメッセージ型・規約を定めた、OSSのフレームワーク
REP-155は、Person ID（永続）・Face/Body/Voice ID（非永続）という4種類のIDと、/humans/以下の名前空間、face_<faceID>などの座標フレームを定義している。汎用的な単一メッセージではなく、サブトピックに分割することでモジュール性を確保している
全体としては、知覚（顔・身体・声の検出）→人物統合（Mr. Potato algorithm）→インタラクションスキル（発話・注視・ナビゲーション・操作）→UI・可視化という流れを、一貫したパッケージ群として提供するエコシステムになっている
開発元のPAL Robotics社のTIAGo・ARIといった商用ロボットや、CSICのEMOROBCAREのような研究用ロボットで実際に使われている
hri_msgsが、表情（カテゴリ＋Valence/Arousal）・FACS準拠のAU・顔のランドマーク・視線・骨格・ジェスチャー・姿勢・年齢性別・音声特徴・音声認識結果・グループ・ID対応候補（IdsMatch）・エンゲージメント・座標のプリミティブ型を含む、全17種類のメッセージ型を定義している
hri_actions_msgsが、知覚の反対側にあたる「アクション」側として、Androidのintentに着想を得たIntent（主題役割に基づくdata、14種類の定義済みIntent）や、LookAt・FaceOverlay・SelfPresentationといったROS 2 Actionを定義している
hri_person_managerが、別々に検出される顔・身体・声を、確率的グラフマッチング（Mr. Potato algorithm、尤度の積で計算される許容パスと、要件を満たす最大尤度の分割）によって1人の人物として統合する
近接学に基づく3つの距離圏（personal/social/public）と、固定された基準フレームによる位置の記憶も、hri_person_managerの機能の一部
hri_engagementが、ロボットと人物の距離・相互注視を組み合わせたvisual social engagement指標（Webb, Giuliani, Lemaignan 2022、88人参加のオンライン実験で提案）を使い、人物ごとのエンゲージメント状態を検出する。判定にはhri_person_managerが必要で、エンゲージしたと判定するとIntentのENGAGE_WITHを発行する。IROS22チュートリアルの$M_{RP}$・$S_{RP}$も、この論文と同じ構造の指標
libhriが、これらの情報にオブジェクト指向的にアクセスできる簡易APIを提供する
公式サイトのLLM対応チュートリアルでは、知覚（顔検出・表情認識）・知識ベース（knowledge_core）・対話（ollamaによるローカルLLM）・シミュレーター（interaction_sim）までを一通り組み合わせた、実践的な構築手順が示されている
IROS22の古いチュートリアルでは、OfficeBotsというゲーム型シミュレーターを使い、相互視線に基づくエンゲージメント推定・骨格検出によるジェスチャー認識・Rasaチャットボットの統合を、実際にコードを書きながら体験できる
Sense4HRIのように、ROS4HRIの命名規則・名前空間を踏襲しつつ、生理指標のような新しいモダリティを統合する拡張も登場している

参考文献

ROS4HRI 公式サイト
Build a complete LLM-enabled interactive app - ROS4HRI Tutorial
ROS4HRI Complete walk-through - ROS Wiki (IROS22)
REP 155 – Conventions, Topics, Interfaces for Perception in Human-Robot Interaction
Scheibl, M., Leichert, J., Görmez, S., & Wrede, B. (2026). “Sense4HRI: A ROS 2 HRI Framework for Physiological Sensor Integration and Synchronized Logging” (arXiv:2603.19914)
ros4hri - GitHub Organization
ros4hri/hri_msgs - GitHub
ros4hri/hri_actions_msgs - GitHub
ros4hri/libhri - GitHub
ros4hri/hri_person_manager - GitHub
“Probabilistic fusion of persons’ body features: the Mr. Potato algorithm” (DOI:10.1145/3610977.3637479)
ros4hri/hri_engagement - GitHub
Webb, N., Giuliani, M., & Lemaignan, S. (2022). “Measuring Visual Social Engagement from Proxemics and Gaze” (DOI:10.1109/RO-MAN53752.2022.9900801、オープンアクセス版)
Facial Action Coding System - Wikipedia

ROS2の概念を理解するためのメモ

Tue, 25 Aug 2026 12:00:00 +0900

背景

業務でROS2を使う必要が出てきた
しかし、正直あまりROS2を触っていない
そこで、自分向けにROS2の基本的な考え方と用語をAIで整理したログ
さくっと全体概念を理解するのが目的

ROS2とは

Robot Operating System 2の略だが、OS（オペレーティングシステム）そのものではない
ロボット向けのソフトウェアを作るためのミドルウェア兼フレームワーク
「センサーで取得した値を処理して、モーターに指令を送る」といった、ロボットの各機能をバラバラのプログラム（後述のノード）として作り、それらを通信でつなげて1つのロボットとして動かす、という考え方が中心にある
前身のROS1に対して、以下のような改善が入っている
- 通信の基盤にDDSという業界標準の仕組みを採用し、単一障害点（後述）をなくした
- リアルタイム性や、Windows・組み込み環境への対応が強化された
- セキュリティ機能が追加された

ディストリビューションとインストール

ROS2は、毎年1回コードネームつきのバージョン（ディストリビューション）がリリースされる
全てのバージョンがLTS（長期サポート）というわけではなく、偶数年リリースのものがLTS（サポート期間5年）、奇数年リリースのものは短期サポート（サポート期間約1年半）になっている主なLTS版は以下の通り。

コードネーム	リリース年	対応Ubuntu
Humble Hawksbill	2022年	Ubuntu 22.04
Jazzy Jalisco	2024年	Ubuntu 24.04

迷ったら、その時点の最新LTS版を、対応するUbuntuのバージョンに入れるのが基本
ROS1と違い、ROS2はOSのバージョンとの結びつきが強いため、Ubuntuのバージョンを先に決めてから、対応するROS2のバージョンを選ぶことになる

全体アーキテクチャ

DDS（Data Distribution Service）

ROS2の通信を裏で支えているミドルウェアの規格
「マスターレス」という特徴があり、ROS1にあったroscoreのような、通信を仲介する中央サーバーが存在しない
各ノードが自律的にお互いを見つけて（Discoveryと呼ぶ）、直接データをやり取りする
中央サーバーがないため、その1台が落ちるとシステム全体が止まる、という単一障害点の問題が起きにくい

ノード（Node）

ROS2における処理の最小単位
1つのノードが、1つのプログラム（プロセス）に対応する
例えば「カメラ画像を取得するノード」「物体検出をするノード」「モーターを制御するノード」のように、機能ごとにノードを分けて作る
ノード同士は、後述のTopic・Service・Actionという3つの方式で通信する

ノード間の通信

ノード同士の通信には、目的に応じて3つの方式がある。

方式	通信の形	用途の例
Topic	非同期のpub/sub	センサーの値を流し続ける
Service	同期的なリクエスト/レスポンス	一度だけの問い合わせ・設定変更
Action	非同期＋進捗報告＋キャンセル可能	時間のかかる動作（アーム移動など）

Topic（トピック）

特定の名前（トピック名）に対して、データを送り続ける側（Publisher）と、受け取り続ける側（Subscriber）が非同期に繋がる仕組み
PublisherとSubscriberはお互いの存在を意識しなくてよく、同じトピック名にさえ繋がれば、何対何でも通信できる
センサーの値のように、継続的に流れてくるデータに向いている

Service（サービス）

関数呼び出しのように、リクエストを送って、その場でレスポンスを待つ同期的な通信
「今の設定値を教えて」「このパラメータを変更して」のような、1回のやり取りで完結する処理に向いている
レスポンスが返るまで基本的に待つことになるので、時間のかかる処理には向かない

Action（アクション）

Serviceに、進捗報告（フィードバック）とキャンセル機能を足したような仕組み
「アームを目標位置まで動かす」のように、時間がかかり、途中経過を知りたかったり、途中で中断したくなったりする処理に向いている
内部的にはTopicとServiceの組み合わせで実現されている

メッセージ型・インターフェース

Topic・Service・Actionでやり取りするデータの型（インターフェース）は、それぞれ.msg・.srv・.actionという専用のファイル形式で定義される標準で用意されている型は、目的別のパッケージにまとまっている。

パッケージ	主な型
`std_msgs`	Int32・String・Boolなど、基本的な型
`geometry_msgs`	Twist（速度）・Pose（位置・姿勢）など、幾何情報の型
`sensor_msgs`	Image・LaserScan・PointCloud2など、センサーデータの型

標準の型で足りない場合は、自分のパッケージ内に.msgファイルなどを作って独自の型を定義できる
ros2 interface show <型名>で、その型がどんなフィールドを持つか確認できる

cmd_vel（速度指令）

ロボットを動かすための速度指令に、事実上の標準として使われているトピック名
geometry_msgs/Twist（またはTwistStamped）という、並進速度（linear）と回転速度（angular）を持つメッセージ型を使う
Nav2の出力や、キーボード操作用のteleopノードなど、様々なノードがこの/cmd_velにpublishし、ロボット側のモーター制御ノードがそれをsubscribeして実際に動かす、という流れが一般的
複数のノードが同時に/cmd_velを出そうとすると競合するため、優先順位をつけて1つの指令にまとめるtwist_muxのようなノードがよく使われる

QoS（Quality of Service）

DDSが持つ、通信の品質を細かく設定できる仕組み
ROS1にはなかった、ROS2特有の重要な概念代表的な設定項目は以下の通り。

設定項目	内容
Reliability	通信の信頼性。多少データが欠けてもいいから速さを優先する（Best Effort）か、確実に届ける（Reliable）か
Durability	新しく繋がったSubscriberに対して、過去のデータも渡すかどうか
History	直近何件分のデータを保持しておくか

PublisherとSubscriberでQoSの設定が噛み合っていないと、通信自体が繋がらないことがあるため、初心者がハマりやすいポイントの1つ

開発の基本的な流れ

ワークスペース

ROS2のプロジェクト全体を置く作業ディレクトリ
中にsrc/ディレクトリを作り、その下に複数のパッケージ（後述）を置く構成が基本
colcon buildというビルドツールで、ワークスペース内の全パッケージをまとめてビルドする

パッケージ

ROS2における、機能をまとめる単位（1つ以上のノードやライブラリをまとめたもの）
各パッケージにはpackage.xml（パッケージの情報・依存関係を書くファイル）が必須
ビルド方式によって、以下のように使うファイルが変わる
- C++の場合: CMakeLists.txt
- Pythonの場合: setup.py（ament_pythonというビルドタイプを使う）

rosdepとワークスペースのsource

パッケージが依存する外部ライブラリを、OSのパッケージマネージャ経由で解決してくれるツールがrosdep
ワークスペースのsrc/以下にある全パッケージの依存関係を、rosdep install --from-paths src -y --ignore-srcのようなコマンドでまとめて解決できる
colcon buildでビルドした後は、source install/setup.bashを実行しないと、ビルドしたパッケージがシェルから認識されない
「ビルドは通ったのにros2 runできない」というのは、大抵このsourceのし忘れが原因で、初心者が最初につまずきやすいポイントの1つ

基本的なコマンド

ros2 run <パッケージ名> <実行ファイル名>: 1つのノードを実行する
ros2 launch <パッケージ名> <launchファイル名>: 複数のノードをまとめて起動する
ros2 node list: 今動いているノードの一覧を見る
ros2 topic list / ros2 topic echo <トピック名>: トピックの一覧確認・流れているデータの確認
ros2 service list: サービスの一覧を見る
rviz2: センサーの値やロボットの状態を可視化するツール
rqt: ノードの構成やログをGUIで確認できるツール

最小限のコード例（rclpy）

ここまでは概念の説明だったので、実際に最小限のノードを書いてみる
以下は、Pythonのクライアントライブラリrclpyを使った、シンプルなPublisherの例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27


import rclpy
from rclpy.node import Node
from std_msgs.msg import String

class MinimalPublisher(Node):
 def __init__(self):
 super().__init__('minimal_publisher')
 self.publisher_ = self.create_publisher(String, 'topic', 10)
 self.timer = self.create_timer(0.5, self.timer_callback)
 self.count = 0

 def timer_callback(self):
 msg = String()
 msg.data = f'Hello World: {self.count}'
 self.publisher_.publish(msg)
 self.get_logger().info(f'Publishing: "{msg.data}"')
 self.count += 1

def main(args=None):
 rclpy.init(args=args)
 node = MinimalPublisher()
 rclpy.spin(node)
 node.destroy_node()
 rclpy.shutdown()

if __name__ == '__main__':
 main()

ポイント
- Nodeを継承したクラスを作るのが基本形
- create_publisherでPublisherを作り、create_timerで一定間隔ごとにtimer_callbackを呼ぶ
- rclpy.spin(node)で、ノードを動かし続ける（この中で、後述のExecutorがコールバックを回している）
Subscriberの場合はcreate_subscriptionを使い、メッセージが届くたびに呼ばれるコールバック関数を登録する形になる

Executor

ノード内の複数のコールバック（タイマー・Subscriberなど）を、実際にどう実行するかを管理する仕組み
rclpy.spin(node)を呼ぶと、内部でデフォルトのExecutor（SingleThreadedExecutor）が動き、登録されたコールバックを順番に処理する
シングルスレッドのExecutorだと、1つのコールバックの処理が終わるまで次のコールバックは実行されない
- 時間のかかる処理を1つのコールバックに書いてしまうと、他のコールバック（他のトピックの受信など）がその間ブロックされてしまう
複数のコールバックを並行して処理したい場合は、MultiThreadedExecutorを使う
「トピックが来ているはずなのに反応が遅い/来ない」という不具合の原因が、実はExecutorのブロッキングだった、というのはよくあるハマりどころ

実行時の設定と制御

パラメータ（Parameters）

ノードに渡す設定値のこと。プログラムを書き換えずに、動作を外から調整できる仕組み
例えば「カメラのフレームレート」「しきい値」のような値を、パラメータとして持たせることが多い
コマンドでの確認・操作
- ros2 param list: あるノードが持つパラメータの一覧を見る
- ros2 param get <ノード名> <パラメータ名>: 値を取得する
- ros2 param set <ノード名> <パラメータ名> <値>: 値を変更する
実際の運用では、パラメータを1つずつsetするのではなく、後述のLaunchファイルからYAMLファイルでまとめて渡すのが一般的

Namespace・Remapping

Namespaceは、ノード名やトピック名の前につける「名前空間」で、同じパッケージ・同じノードを複数のインスタンスとして区別して動かすときに使う
- 例: robot1/cmd_vel、robot2/cmd_velのように、ロボットごとに名前空間を分ける
Remappingは、ノードが元々使っているトピック名・サービス名などを、実行時に別の名前に付け替える仕組み
- 例: ros2 run pkg node --ros-args -r cmd_vel:=robot1/cmd_vel
どちらも、コードを一切変更せずに、起動時のオプションやLaunchファイルの引数だけで名前を切り替えられるのがポイント
複数台のロボットを同時に動かす場合や、他人が作ったパッケージをそのまま自分のシステムに組み込む場合に、ほぼ必須になる知識

Launchファイル

複数のノードを、パラメータ付きでまとめて起動するための設定ファイル
Python・XML・YAMLのいずれかで書ける（最近はPythonで書くことが多い）
実際のロボットは複数のノードが同時に動いて成り立っているため、1つずつros2 runするのではなく、launchファイルでまとめて立ち上げるのが基本的な運用になる

ライフサイクルノード（Managed Nodes）

通常のノードは起動したらすぐ全機能が有効になるが、ライフサイクルノードは明示的な状態管理を持つ主な状態は以下の通り。

状態	内容
Unconfigured	起動直後、まだ設定されていない状態
Inactive	設定は終わっているが、まだ動いていない状態
Active	実際に処理を行っている状態
Finalized	終了処理が終わった状態

状態遷移は、configure・activate・deactivate・cleanup・shutdownといったサービス呼び出しで制御する
Nav2は、内部の各サーバー（Planner、Controllerなど）がこのライフサイクルノードとして作られていて、lifecycle_managerというノードが、それらの状態をまとめて管理・遷移させている
Nav2起動時に「なぜか動かない」場合、実はライフサイクルがActiveまで遷移していないだけ、ということもよくある

ロボット特有の周辺技術

rosbag2

トピックに流れているデータを記録・再生するツール（ROS1のrosbagのROS2版）
実機やシミュレーションで流れたデータをファイルに記録しておき、後から同じデータを何度でも再生できる
実機を毎回動かさなくても、記録済みのデータでノードの開発・デバッグを進められるのが大きな利点
主なコマンド
- ros2 bag record -a: 全トピックを記録する
- ros2 bag record <topic1> <topic2>: 指定したトピックだけ記録する
- ros2 bag play <bagファイル>: 記録したデータを再生する
- ros2 bag info <bagファイル>: 記録内容（トピック・件数・期間など）を確認する
保存形式はsqlite3かmcapが使われる

URDF（Unified Robot Description Format）

ロボットの物理的な構造（リンクとジョイント）を記述するXML形式
リンク（Link）は剛体の部品（腕の一部、車体など）、ジョイント（Joint）はリンク同士をつなぐ関節（回転・スライドなど）を表す
各リンクの見た目（形状・色）や、衝突判定用の形状、質量・慣性などの物理情報もここに書ける
robot_state_publisherというノードが、URDFとジョイントの角度情報から、後述のTF2の座標変換を自動的に計算・配信してくれる
RVizでロボットの3Dモデルを表示したり、Gazeboでシミュレーションしたりする際の元データにもなる

TF2（座標変換）

ロボットに関わる複数の座標系（フレーム）の関係を、時系列で管理する仕組み
例えば「地図（map）」「ロボット本体（base_link）」「カメラ（camera_link）」は、それぞれ別の座標系を持っていて、TF2はこれらの間の相対位置・姿勢を管理する
各フレームは木構造（ツリー）でつながっていて、map -> odom -> base_link -> camera_linkのように親子関係を辿ることで、任意の2点間の座標変換を計算できる
ros2 run rqt_tf_tree rqt_tf_treeで、今のフレーム構成をツリー図として確認できる
Nav2のようなナビゲーションスタックは、TF2が正しく配信されていることが前提になっているため、ロボット開発で最初につまずきやすいポイントの1つ

SLAM（Simultaneous Localization and Mapping）

自己位置推定（Localization）と地図作成（Mapping）を同時に行う技術
ロボットが未知の環境を動き回りながら、センサー情報をもとに「今どこにいるか」と「周囲の地図」を同時に構築していく
前述のNav2は自己位置推定を行わない（AMCLなどと組み合わせる前提）ため、Nav2を使うには、事前にSLAMで地図を作っておくか、SLAMをリアルタイムで動かしながらナビゲーションする、という使い方になる
ROS2では、2D LiDARを使ったSLAMの標準的な実装としてslam_toolboxというパッケージがよく使われる

Visual SLAM

LiDARなどの距離センサーではなく、カメラ映像を使って自己位置推定・地図作成を行うSLAM
画像内の特徴点（際立った点）をフレーム間で追跡し、その動きからカメラ（ロボット）自身の移動量と、周囲の3次元構造を推定する
LiDARより安価なセンサー（カメラ）で実現できる一方、照明条件の変化や、特徴点の少ない環境（真っ白な壁など）に弱いという弱点がある
代表的な実装として、ORB-SLAMやRTAB-Map（ROS2にも対応）などがある

cuVSLAM

NVIDIAが開発した、GPU（CUDA）で高速化されたVisual SLAMの実装
Isaac ROS（NVIDIAが提供するROS2向けのGPUアクセラレーションパッケージ群）の一部として提供されている
ステレオカメラの映像を使い、GPU上で並列処理することで、CPUベースのVisual SLAMより高速・低遅延に自己位置推定を行える
Jetsonシリーズのようなエッジデバイス上でのリアルタイム動作を意識して設計されている

Nav2（Navigation2）

ROS2上で自律移動（ナビゲーション）を実現するための標準的なソフトウェアスタック
地図上で目的地を指定すると、経路計画と障害物回避をしながら自律的に移動できるようにする主な構成要素は以下の通り。

構成要素	役割
Global Planner	地図全体を使って、大まかな経路を計画する
Controller（Local Planner）	直近の障害物やロボットの動特性を考慮して、実際の速度指令（前述の`cmd_vel`）を計算する
Costmap	障害物や走行コストを表現する地図。全体用のGlobal Costmapと、直近用のLocal Costmapの2種類がある
Behavior Tree	経路計画→移動→リカバリー動作といった、Nav2全体の動作フローを制御する仕組み
Recovery Behaviors	経路が見つからない・スタックしたときに行う復帰動作（その場回転、後退など）

Nav2自体は「自分が今どこにいるか」は推定しないため、AMCLなどの自己位置推定と組み合わせて使うのが前提
launchファイルで各構成要素をまとめて立ち上げ、パラメータYAMLで細かい挙動をチューニングするのが基本的な使い方

順運動学（FK）と逆運動学（IK）

Nav2・SLAMが移動ロボット向けの話だったのに対し、ここからはロボットアーム（マニピュレータ）向けの基礎知識
順運動学（Forward Kinematics, FK）: 各関節の角度が分かっているときに、アームの先端（エンドエフェクタ）がどの位置・姿勢にあるかを計算すること
- 「関節の角度 → 先端の位置」という向きの計算で、URDFのリンク・ジョイント情報から比較的簡単に求まる
逆運動学（Inverse Kinematics, IK）: 逆に、アームの先端を「この位置・姿勢にしたい」と決めたときに、そのために必要な各関節の角度を計算すること
- 「先端の位置 → 関節の角度」という向きの計算で、同じ先端位置に対して関節角度の組み合わせが複数存在したり、そもそも解が存在しない（届かない位置）こともあり、FKより計算が難しい

DHパラメータとリンク長

FKを計算する際、隣り合う関節同士の座標系の関係を統一的に表現するための方法が、Denavit-Hartenberg（DH）パラメータ
以下4つのパラメータの組み合わせで、隣り合う座標系同士の変換を表現する
- リンク長$a_i$: $x_i$軸に沿って測った、$z_i$軸から$z_{i+1}$軸までの距離。そのリンク（関節と関節の間の剛体部分）の物理的な長さにあたる
- リンクのねじれ角$\alpha_i$: $x_i$軸まわりに測った、$z_i$軸から$z_{i+1}$軸までの角度
- リンクオフセット$d_i$: $z_i$軸に沿って測った、$x_{i-1}$軸から$x_i$軸までの距離
- 関節角$\theta_i$: $z_i$軸まわりに測った、$x_{i-1}$軸から$x_i$軸までの角度
回転関節の場合、可変なのは関節角$\theta_i$だけで、リンク長$a_i$を含む残り3つはロボットの機械構造によって決まる定数になる

PID制御とPD制御

関節や車輪を目標値（角度・速度・位置など）に追従させるための、古典的で最も広く使われるフィードバック制御手法
目標値と現在値の差（誤差）$e(t)$を使って、以下の3項を組み合わせて制御量$u(t)$を計算する

$$ u(t) = K_p e(t) + K_i \int_0^t e(\tau)\,d\tau + K_d \frac{de(t)}{dt} $$

比例項（P, Proportional）: 誤差の大きさに比例した制御量。誤差が大きいほど強く補正する
積分項（I, Integral）: 誤差の累積に比例した制御量。比例項だけでは埋まらずにじわじわ残る誤差（定常偏差）を解消する
微分項（D, Derivative）: 誤差の変化率に比例した制御量。急激な変化を抑え、目標値を行き過ぎるオーバーシュートを防ぐ
PID制御: 上記3項全てを使う、最も一般的な構成
PD制御: 積分項を使わず比例項と微分項だけを使う構成。積分項による巻き込み（積分ワインドアップ）を避けたい場合や、定常偏差が問題になりにくい速度制御などで使われる
ROS2では、ros2_controlフレームワークのcontrol_toolboxパッケージにPID制御の実装があり、ros2_controllersのpid_controllerから直接利用できる

クランプ（Clamp）

値を決められた上限・下限の範囲内に収まるように制限する処理のこと
制御出力$u(t)$が、モーターの実際の駆動範囲を超えないように上限・下限で切り詰める、といった使い方をする
積分ワインドアップへの対策の1つに、クランプ方式のアンチワインドアップ（Clamping Anti-Windup）がある
- 出力が上限・下限に達している間は、積分項の蓄積を止める（またはその値自体を制限する）ことで、誤差が解消された後に出力が行き過ぎるのを防ぐ

Command InterfaceとState Interface（ActVel）

PID制御が誤差$e(t)$を計算するには、目標値だけでなく「今どうなっているか」という実測値が必要になる
ros2_controlでは、コントローラーからハードウェアへの指令をCommand Interface、ハードウェアからコントローラーへのフィードバックをState Interfaceとして抽象化している
代表的な種類にはHW_IF_POSITION（位置）・HW_IF_VELOCITY（速度）・HW_IF_EFFORT（トルク・力）があり、同じ関節でもCommand用とState用で別々のインターフェースとして扱われる
速度のState Interface（実測速度）は、しばしば「ActVel（Actual Velocity）」と呼ばれる。モータードライバの標準規格であるCiA402（CANopenのドライブ用プロファイル）でも、指令速度とは別に「Velocity actual value」というオブジェクトが定義されており、ActVelという略称はここに由来することが多い
前述のcmd_velが、ナビゲーションスタックなど上位からロボット全体への速度指令であるのに対し、ActVelは個々の関節・モーターレベルでの実測値であり、抽象化のレイヤーが異なる点に注意

MoveIt

ROS2上でロボットアームの動作計画（モーションプランニング）を行うための標準的なソフトウェアスタック
Nav2が移動ロボット向けの標準スタックなのに対し、MoveItはアーム向けの標準スタックという位置づけ
前述のIKを解いて目標姿勢までの関節角度を求めつつ、障害物を避けながらの経路計画や衝突検知も行う
URDFで定義したロボットの構造をそのまま利用でき、Gazeboのようなシミュレータ上での動作確認にも対応している

Gazebo（シミュレータ）

ロボットの物理シミュレーションを行うためのソフトウェア
前述のURDFで記述したロボットモデルを仮想空間に配置し、重力・摩擦・衝突などを考慮した動きをシミュレートできる
実機がまだない、あるいは実機を壊すリスクがある動作を試したいときに、ROS2のノードをそのまま実機と同じように動かして検証できる
カメラ・LiDARなどのセンサーのシミュレーションデータも出力できるので、Nav2のようなセンサー入力が前提のスタックのテストにもよく使われる
最近は従来のGazebo Classicから、後継のGazebo（旧Ignition Gazebo）への移行が進んでいる

まとめ

ROS2は、ロボットの各機能をノードという単位に分けて、通信でつなげて動かすためのフレームワーク
インストールは、その時点の最新LTSディストリビューションを、対応するUbuntuのバージョンに入れるのが基本
通信の基盤はDDSで、ROS1にあった中央サーバー（単一障害点）がない
ノード間の通信は、Topic（非同期の流し込み）・Service（同期的な問い合わせ）・Action（進捗報告つきの長時間処理）の3種類を目的に応じて使い分ける。QoSはその通信の品質を細かく設定する仕組み
実際のコードは、Nodeを継承したクラスにPublisher/Subscriberやコールバックを持たせる形で書き、rclpy.spinが内部のExecutorでコールバックを回す
開発は、ワークスペースの中にパッケージを作り、rosdepで依存関係を解決してcolconでビルドし、setup.bashをsourceして使う、という流れが基本
動作の調整はパラメータで行い、Namespace・Remappingで名前を実行時に切り替えられる。複数ノードとパラメータをまとめて起動するのがLaunchファイルの役割
rosbag2でデータを記録・再生できるので、実機を毎回動かさなくても開発・デバッグを進められる
URDFでロボットの構造を記述し、そこからTF2が座標変換を計算・配信する。この2つはNav2などの前提になる基礎的な仕組み
SLAM（Visual SLAM・cuVSLAMも含む）で自己位置推定と地図作成を行い、その地図をもとにNav2が自律移動する、という役割分担になっている
速度指令はcmd_velという標準的なトピック名でやり取りされ、ライフサイクルノードで状態管理されたNav2が、そのcmd_velを出す自律移動用の標準スタック
ロボットアームの場合は、関節角度から先端位置を求めるFK、先端位置から関節角度を求めるIKが基本になり、MoveItがそれを担うNav2の対になる標準スタック
Gazeboを使えば、実機なしでもロボットのシミュレーションができる

ロボ > ロボティクス on M1KE BL0G

ロボット発話のパラフレーズが意味を壊す問題とNLIによる対策

背景

なぜBLEU・BERTスコアだけでは不十分か

NLIによるパラフレーズの意味保持フィルタリング

双方向含意というアイデア

実際の検証結果

HRIのパラフレーズ生成への応用

まとめ

参考文献

Séverin Lemaignan論文チェック: ROS4HRI標準化論文

背景

論文の問題意識: HRIにおけるベンチマークの困難さ

人間のIDモデル: 4種類のID

人体キネマティクスモデル

ROSトピック構造とフレーム規約

Intents（意図）の設計

可視化ツール

PAL ARIとの関係・今後の展望

まとめ

参考文献

SPRING: 高齢者介護施設における社会的ロボットの実証実験

背景

論文の概要

使用ロボット: PAL Robotics ARI

システムアーキテクチャ: 8つのモジュール

知覚系

補足: Person Managerによる特徴統合の具体例

行動系

補足: Petri Netの基礎

補足: Social Navigation Controller（人の存在を考慮した経路計画）

実験の概要

評価結果

AES・SUSという2つの指標

スコアの結果

倫理的な懸念と限界

まとめ

参考文献

差動二輪ロボットの駆動系とAMCL・SLAM・Nav2

背景

全体像: 駆動系からナビゲーションまでのデータの流れ

TFツリー全体像

TF2の仕組み: 分散システム前提の座標変換ライブラリ

ROS座標フレームの一覧

Gazeboでの駆動系シミュレーション

差動二輪駆動の仕組み

gz-simのDiffDriveシステムプラグイン

オドメトリのドリフトという前提

GazeboでのLiDARシミュレーション

AMCL: オドメトリとLiDARで自己位置を補正する

パーティクルフィルタの基本

動作モデル（オドメトリ）と観測モデル（LiDAR）

map -> odom変換の補正という役割

SLAM: 地図がない場合はslam_toolboxが代わりを担う

SLAMとAMCLは同時に動かさない

発展: 意味情報を加えるOWL/RDFとSemantic SLAM

Nav2との接続: コストマップと速度指令

まとめ

参考文献

ROS4HRIの仕組み

背景

ROS4HRIとは

REP-155の仕様

4種類のID

トピックの名前空間

なぜ単一のFaceメッセージではなく分割するのか

座標フレーム

視線の非対称性

Kinematic Model of the Human

全体像: ROS4HRIエコシステムの構成

パッケージのカテゴリ一覧

カテゴリ別パッケージ一覧

対応ロボット

メッセージ定義: hri_msgs

カテゴリ一覧

顔・表情に関するメッセージ

身体に関するメッセージ

属性・音声に関するメッセージ

集団・ID管理・関係性に関するメッセージ

幾何的なプリミティブ型