アーカイブ / LLM / Robotics
乗客の音声指示をAutowareの許可済み操作につなぐ二段階LLM方式
Modular Autonomy with Conversational Interaction
Modular Autonomy with Conversational Interactionの原論文から掲載した図です。細部はクリックして拡大できます。
原論文の図の説明を読む
Fig. 1: Conceptual diagram of the LLM -based co-pilot interfacing natural language instructions and requests with the modular ADS software stack.
概要
- 乗客の音声と車両状態からDSL命令を作り、許可されたAutowareの操作に対応付ける。
- 著者らの200組の指示による評価では翻訳正解率97.0％で、命令例を除く条件では73.0％だった。
- 五種類の依頼を含むシミュレーションは30回中29回成功した。定量結果は定めたシナリオに限られる。
補足：編集した模式図で仕組みを確認する
VISUAL EXPLAINER
図でつかむ、Modular Autonomy with Conversational Interactionの仕組み
- 01乗客の音声・車両状態
- 02LLMが命令に変換
- 03ROS2で検証・実行
- 04成否を音声で返答
原論文の説明をもとにした模式図です。処理の細部は省略しています。
研究の背景
Autowareのような自動運転ソフトでは、周囲の認識、経路の計画、車両の制御を別々の機能が担う。乗客の多様な言い回しを、各機能が受け付ける限られた操作へ結び付けるには、言葉と実行可能な命令の間に変換が要る。
例えば希望する車間距離を伝える依頼と、現在の状態を尋ねる質問では、必要な処理が違う。誤った変換を操作に回さないことに加え、依頼が実際に処理されたかを乗客に伝えることも課題になる。
手法
乗客の音声、車両状態、命令形式の説明と例をLLMに渡し、専用の構造化命令へ変換する。この命令形式をDSLと呼ぶ。命令には五種類の区分、操作、必要な値を記す。例えば「最高速度を時速90キロに設定」は、設定変更、速度上限の設定、値90.0という形になる。
次に接続部が命令を解析し、事前に人手で対応付けた許可済み操作と値の範囲を確認する。ROS2というソフト間の通信基盤を通じてAutowareに操作を渡し、確定した成否と元の依頼を再びLLMへ送る。生成された返答は音声に変換して乗客に伝える。音声はLLMが直接処理し、独立した音声文字起こし段階は置いていない。
新規性
著者らは乗客とのやり取りを、情報照会、目的地などの指示、設定変更、局所的な運転への協力、認識や判断への介入の五種類に整理した。その分類を基に、依頼を車両ソフトの構成に依存しない命令形式へ変換する。
実行前には許可された操作と値の範囲を確認し、実行後には確定した成否を使って返答を作る。言葉の解釈、操作の検証、乗客への報告を順に接続した点が提案の中心である。
従来手法との違い
比較対象のAutoware.Flexは、Autowareのモジュールに沿った命令形式を使う。本方式は乗客が求める操作を軸に命令を表し、接続部でAutowareの操作に対応付ける。この違いは、別の車両ソフトへ移す際の設計上の狙いとして説明されている。
著者らは翻訳正解率97.0％に対し、先行研究の報告値は87.0％と記す。ただし、データセット、言語モデル、命令形式、実験条件が異なる。数値の差を方式だけの効果とは判断できない。
実験結果
著者らは、五種類の依頼と対象外の依頼を含む、人手作成の指示と正解DSL命令200組を評価した。指示を合成音声にして入力し、車両状態、命令の説明、少数の例を与える条件では194件が正解で、翻訳正解率は97.0％、平均翻訳時間は1.723秒だった。例を除く条件では正解率が73.0％になった。
Autowareの計画シミュレーションでは、五種類の依頼を含む同一シナリオを30回実行した。著者らは29回成功、タスク成功率96.7％と報告し、失敗１回は返答生成時のAPIサーバーエラーだった。成功した29回で、命令実行時間の中央値は0.461ミリ秒、返答生成時間の中央値は1.778秒だった。
応用の可能性
編集上の応用案 · 論文が実証した用途とは区別しています。
編集上の応用案：研究車両の乗客が「前の車との距離を広げて」と音声で依頼し、設定変更として受け付ける。入力は乗客の音声と既存の車両ソフトから得る状態情報、出力は検証を通った設定命令と、実際の成否を伝える音声とする。
追加学習用データは前提にせず、許可する設定と値の範囲、車両ソフトの操作先を人手で定める。評価には依頼文と正解命令のラベルが必要になる。この案で使う入力以外のセンサー情報が必要かは、対象車両の実装時に確認する。
応用先の候補からNauhに相談できます。
導入時の検証
導入時の検証案 · 対象データでの再評価が必要です。
導入時の検証案：まず対象システムで使える車両状態、許可する操作と値の範囲を確認し、各命令を操作先へ人手で対応付ける。入力音声を得る手段を用意し、追加学習は行わず、依頼文と正解DSL命令のラベルを小規模に作る。外界センサー情報を命令に使うなら、その取得元と必要性も明示する。
同じ依頼を固定の操作画面でも処理し、完了率と所要時間を基準値として測る。シミュレーションで翻訳正解率、許可外の依頼の拒否、操作の完了率、返答と実際の成否の一致率を記録する。結果は設定した依頼と交通状況の範囲で判断する。
限界と課題
著者らは、クラウド上のLLMへの通信が遅延と単一障害点を生むこと、運転分野向けの追加学習をしていないこと、曖昧な指示への頑健性を十分に調べていないことを限界に挙げる。五種類を通した定量評価も、定めた一つのシナリオに限られる。
編集上の検証事項は、車内雑音を含む音声、矛盾する依頼、状態情報の欠落、通信障害時の扱いである。研究車両では基本的な命令を実行したと報告されるが、多様な交通状況での成功率を示す結果ではない。
出典
元のタイトル・要旨を確認する（英語）
Modular Autonomy with Conversational Interaction: An LLM-driven Framework for Decision Making in Autonomous Driving
Recent advancements in Large Language Models (LLMs) offer new opportunities to create natural language interfaces for Autonomous Driving Systems (ADSs), moving beyond rigid inputs. This paper addresses the challenge of mapping the complexity of human language to the structured action space of modular ADS software. We propose a framework that integrates an LLM-based interaction layer with Autoware, a widely used open-source software. This system enables passengers to issue high-level commands, from querying status information to modifying driving behavior. Our methodology is grounded in three key components: a taxonomization of interaction categories, an application-centric Domain Specific Language (DSL) for command translation, and a safety-preserving validation layer. A two-stage LLM architecture ensures high transparency by providing feedback based on the definitive execution status. Evaluation confirms the system's timing efficiency and translation robustness. Simulation successfully validated command execution across all five interaction categories. This work provides a foundation for extensible, DSL-assisted interaction in modular and safety-conscious autonomy stacks.
論文本体の取得範囲に基づく解説。AIが作成した未校閲の記事です。性能の数値は著者の評価条件に依存します。応用例と検証計画は編集上の提案です。解説更新：2026-10-01