はじめに

はじめまして！
去年も同じ基盤モデル×Robotics Advent Calender2022の16日目で記事を投稿させていただいたNAIST修士2年生のmakolonです。

今年は、基盤モデル×Robotics2023のカレンダー7日目になります。
https://qiita.com/advent-calendar/2023/robot-ai

この記事では、Carnegie Mellon UniversityとGoogle DeepMindの方が書かれた論文『CREATIVE ROBOT TOOL USE WITH LARGE LANGUAGE MODELS』を取り上げたいと思います。こちらの論文はCoRL2023 LangRobo Workshopに投稿された論文です。
私は普段Task And Motion Planning(TAMP)の研究をやっていることもあり、長期的なタスクをロボットで行う研究を中心にサーベイしていたところ、推しの論文『Differentiable Physics and Stable Modes for Tool-Use and Manipulation Planning』に近い研究がLLMでやられていたため、どんなものかと思い読んだので、紹介させていただきます。

RoboToolとは？

RoboToolを一言で表すと、4つのLLMによってロボット動作を計画することで、長期的かつ道具を使用することでのみ達成可能なタスクを実現する手法になります。
以下のFigure. 2のようにユーザーから与えられた制約条件、シーン情報、状況説明、タスク情報を含む言語情報が与えられたのち、本研究のキモの部分であるAnalyzer、Planner、Calculator、Coderの4つのLLMによってロボットが実行可能なプログラムを生成する手法になっています。

こちら去年同じアドベントカレンダーで紹介したProgPromptと同じようにロボットで実行可能なPythonプログラムを生成します。違いとしてはより実世界に接地しており、知性を感じることができる(？)道具を使用したロボットの動作生成が可能な点が挙げられます。

RoboToolの何がすごい？

LLMが持つCommon Senseのような知識をうまく用いることで、サルやカラスなど知的な動物が行うことが可能な道具操作を含む動作を実現したことになります。
従来の長期的なプランニングでは、こうした道具の操作を必要とするようタスクでは、細かなサブタスク間の幾何学的な関係性などの依存関係を捉えることが難しく、道具がどのように使えるかなどの事前知識を導入する手法が多く見られます。
一方で、こうした人間であれば共通認識として持っているような知識をLLMが代替し、提供してくれることで、Affordanceのような道具の使用方法をZero-shotで実現しています。

また、この研究以前に多く見られるようなLLMを用いて直接ロボットの動作を生成する方法と異なり、長期的なタスクを遂行する上で重要な特徴を抽出する箇所、幾何的な情報から制約を記述する箇所、長期的なタスクを実現するために順に動作を計画する箇所、ロボットが動作するためのプログラミングを行う箇所と分担し、それぞれの得意分野を繋ぎ合わせるような構造を取り入れることで道具を使用する賢い動作の生成を実現しています。

RoboToolの概要

RoboToolは上のFigure. 2で示されているようにAnalyzer、Calculator、Planner、Coderの4つの機能から構成されています。以下では、それぞれ順に説明し、それらの機能がどのように統合されているのかを解説していこうと思います。

Analyzer

Analyzerでは、与えられた雑多な言語情報からタスクを遂行するために必要な精錬された特徴を抽出する処理を行います。これによって、無駄な情報を省き、タスクに必要な情報だけを抜き出すことが可能になります。この機能の必要性に関してですが、実験結果を見る限りですと、かなり重要な役割を担っていることがわかります。

Analyzerからの出力の例としては以下のFigure 3のようなものが得られ、タスクを記述するために必要な特徴を取られる部分が抽出されています。簡単に言ってしまえば、言語情報$L$からより精錬された言語情報$L^*$を取り出す処理を行っているだけです。

Planner

Analyzerによって抽出された言語$L^*$からロボットの動作シーケンス(Plan Skeleton)$H$を生成する機能がPlannerです。Plan Skeletonという言葉は少し聞きなれない言葉かもしれないですが、TAMPの論文だとよく出てきます。この時点では、まだ具体的なパラメータは決定されておらず、スキルのシーケンスのみが得られているような状況になります。
このように物体の位置やロボットの移動先などパラメータがスキルに肉付けされていないことからPlan Skeletonと呼ばれているものだと勝手に認識しています。(正解をご存知だったら教えてください。)

Plannerは、他の3種の機能と同様にLLMでモデル化されており言語情報から、環境中の各物体の機能や用途といった部分までを考慮し、ロボットが持つスキルを繋げていきます。Plannerから得られる情報は以下のFigure. 4のようなものが得られます。

Calculator

Calculatorでは、パラメータのサンプリングのような機能を実現しています。Calculatorの入力としては、Analyzerから抽出された言語情報$L^*$とPlannerによって得られたPlan Skeleton$H$になります。これらの情報から制約条件を満たすパラメータ$X$をサンプリングします。
この機能はPDDLStreamに代表されるように、上位のTask Planningと下位のMotion Planningを繋ぐような役割を持っており、幾何的なパラメータをサンプリングします。Task Planningでは連続的な幾何制約を考慮することが難しく、一方でMotion Planningでは、制約を満たすパラメータまで最適化するのでは、計算コストが非常に高くなってしまいます。こうした問題を避けるために、制約多様体上から値を獲得するSamplerを用意することで効率的に階層構造を持つプランニングを実現しています。最近ですと、LLMとこうしたSamplerを混ぜる手法も注目されてきています。LLM-GROPなど。

Coder

最後の機能であるCoderは、Plan Sleleton$H$とCalculatorによって与えられるパラメータ$X$からロボットが実行可能なプログラム$\tau$を生成します。こちらは想像がつきやすいと思いますが、単純にロボットが持つスキルをつなぎ合わせ、具体的な実行手順をPythonで生成するものになります。

以上に紹介した機能をFigure 2のように順に実行していくことで、餅は餅屋といったように役割を分担しながら最終的なロボットの動作を計画します。

実験

実験設定

実験では、ロボットアームと四足歩行ロボットの2種類のロボットを使用して、道具操作タスクを行なっています。

ロボットアーム:
Kinova Gen3で検証を行なっています。
シミュレーション環境としてはrobosuiteをベースにタスクを構築し、物体の位置やサイズは既知としています。一方で、実環境では、OWL-ViTを使用し、各物体の位置をバウンディングボックスから獲得しています。また、ロボットは["get_position", "get_size", "open_gripper", "close_gripper", "move_to_position"]という5種類のスキルを取ることができます。
四足歩行ロボット:
Unitree Go1で検証を行なっています。
シミュレーションでは生成されたコードとユーザーの評価に基づいて行っています。実環境では、ロボットアームに比べて大きなワークスペースがあることを考慮し、AprilTagsを各物体に取り付けて位置を取得しています。
両実験で、四足歩行ロボットのスキルセットは["get_position", "get_size", "walk_to_position", "climb_to_position", "push_to_position"]です。以下のFigure. 8が四足歩行ロボット用に用意された環境と物体です。

タスク設定

また、それぞれタスクとしては次の6種類のタスクが用意されています。タスクは大きく以下の3種類に分類できます。
(1) Tool Selection: 複数ある道具から正しく選択する必要のあるタスク
$~~~$ - Sofa-Traversing: 板をうまく使って次のソファーへ移動するタスク
$~~~$ - Milk-Reaching: 金槌を使用して、牛乳パックを手前に引き寄せるタスク
(2) Sequential Tool Use: 道具を正しい手順で使う必要のあるタスク
$~~~$ - Sofa-Climing: 台を押し、登ることでソファーの上に移動するタスク
$~~~$ - Can-Grasping: 棒を使用し、缶を紙の上に配置し、手前に引き寄せるタスク
(3) Tool Manufactureing: 道具を作成し、その道具を使用する必要のあるタスク
$~~~$ - Cube-Lifting: 椅子をどかし、台を用いて重いブロックを持ち上げるタスク
$~~~$ - Button-Pressing: 磁石のブロックから棒を作成し、ボタンを押すタスク

比較手法

比較としてAblationを行なっています。

Coder: Code-as-Policiesを派生させた手法
Planner-Coder: AnalyzerとCalculatorをRoboToolから除いた手法
RoboTool w/o Analyzer: Analyerのみを除いた手法
RoboTool w/o Calculator: Calculatorのみを除いた手法

実機での実験結果

以上の6つのタスクにおいてRoboToolとその他4種類の比較手法の実験結果は以下のようになっています。以下のTable 1を見るとRoboToolはシミュレーション環境ですが平均87%成功しており、他の手法に比べても高い成功率を実現しています。シミュレーションと実機環境では10%性能が異なりますが、これは実機特有のロボットの動作の位置誤差やシミュレーション環境のモデル化誤差などによるもので発生しているみたいです。

これらの実験の動画は以下のサイトから見ることができます。
https://creative-robotool.github.io/

まとめ

今回紹介したRoboToolは、何かしら道具を使用することが求められるタスクにおいて4つのLLMを用いることでロボットでタスクをこなすことができるようにする手法でした。

去年に比べると、着実にLLMを用いたTask Plannerの研究が増え、基盤が整ってきたように思います。というのも、代表的な手法の派生研究が増えていて、各研究機関固有の手法が多く見受けられるようになってきたと思います。

TAMPにおける上位Plannerに当たるTask PlannerとしてLLMを統合していく研究も多く提案されるようになってきていていますが、一方で、Motion Planning側の環境や物体との接触や柔軟物体のマニピュレーションなどロボット特有の問題を含むタスクに対してうまく統合している研究はまだ少ない気がしています。こうした課題に今後どのような研究がされていくのかが個人的に気になります。