SO-100でDROID、BridgeData V2、Open Xを使用する

Google Cloudバケットには100万軌跡の公開データセットがあり、机の上には部品代が110から150 EURのSO-100があります。なぜ前者が後者を教えることができないのでしょうか？部分的には可能ですが、人々が期待するような転送はほとんど起こらず、最も簡単に見える部分は全く機能しません。

以下では、DROID、BridgeData V2およびOpen X-Embodimentの内部がどうなっているか、それぞれが低コストの5自由度アームとどのように衝突するか、そして代わりに何をすべきかについて説明します。以下のすべての数値は、それぞれの論文、データセットカード、またはソースファイルから引用されています。

これら3つのデータセットが実際に含むもの

DROID

3つの中で最も標準化されています。どこでも同じ装置：Robotiq 2F-85グリッパーを備えたFranka Panda、2台の調整可能なZED 2ステレオカメラ、手首のZED Mini、Meta Quest 2コントローラーで遠隔操作され、Polymetisを介して15 Hzで関節空間とエンドエフェクタ空間の両方で記録されます。言語ラベルは後でtasq.aiを介して追加され、エピソードあたり最大3つです。

• 76kの軌跡、350時間、564のシーン、84のタスク、3大陸にわたる50のコレクター。
• 主要な結果は、単独トレーニングではなく共同トレーニングです。ドメイン内デモンストレーションと50/50で混合されたバッチは、次に優れた手法を、分布内での絶対成功率で22パーセント、分布外で17パーセント上回りました。
• IPEC-COMMUNITY/droid_lerobot: 92,233エピソード、27,044,326フレーム、franka、15 fps、codebase_version v2.0、180x320のAV1ストリーム3本、392 GB。
• 2 GB、100エピソードのデバッグサンプルがgs://gresearch/robotics/droid_100にあります。そこから始めてください。

BridgeData V2

ホビーセットアップに最も近いもの：WidowX 250 6自由度アーム、24の環境と13のスキルにわたる60,096の軌跡を5 Hzで。構成に注目してください：50,365の専門家による遠隔操作デモンストレーションと、ランダム化されたスクリプトによるピックアンドプレースポリシーからの9,731、つまり約16パーセントは人間によるデモンストレーションではありません。これは模倣学習の品質に影響します。通常のダウンロードであるIPEC-COMMUNITY/bridge_orig_lerobotは、53,192エピソードと1,893,026フレームを5 fpsで、robot_type widowxと報告しており、論文の60,096よりも少ないため、どちらかを引用するのではなく、meta/info.jsonからカウントを読み取ってください。

Open X-Embodiment

同じ意味でのデータセットではありません。34の研究室からの60の既存ロボットデータセットが1つのRLDSコレクションに集約され、22のエンボディメントと100万以上の軌跡をカバーしています。BridgeData V2はbridge_origとしてその中に含まれており、google_robotスライスであるfractal20220817_dataは、3 fpsで87,212エピソードに変換されます。

この集約には、論文が明示している注意点があります。RT-X実験では、著者らは各ソースを7自由度（DoF）のエンドエフェクタアクションに変換しますが、データセット間で座標系を整合させず、各ロボットの元の制御スキームに従って、アクション値が絶対位置または相対位置、あるいは速度のいずれかになることを許容しています。彼らの結論は、同じアクションベクトルが異なるロボットに対して非常に異なる動きを引き起こす可能性がある、というものです。

4部構成のミスマッチ

エンボディメントの不一致は、通常、漠然とした一つの問題として扱われます。しかし、実際には4つの異なる問題であり、それぞれ異なる形で失敗し、そのうち2つはスクリプトでは修正できません。

1. 自由度

SO-100は5つのアーム関節とグリッパーを備えています。モーターとして数えると6-DoFアームであり、SmolVLAの論文ではそのように呼ばれています。位置決め機構として数えると5-DoFであり、LeRobotはその逆運動学のドキュメント文字列でそのように呼んでいます。このドキュメント文字列は、手首が部分的にしか向きを追跡しない5-DOF SO-101におけるソフトオリエンテーションIKについて記述しています。Frankaは7つの位置決め関節を持っています。このギャップが、どのような姿勢が存在するかを決定します。5-DoFアームは一般的に、任意の姿勢と向きを同時に達成することはできないため、ソルバーは可能な限り近い姿勢を返します。これはデモンストレーションされた動きとは異なる動きです。背景: 自由度.

# src/lerobot/robots/so_follower/so_follower.py
motors = {
    "shoulder_pan":  Motor(1, "sts3215", norm_mode_body),
    "shoulder_lift": Motor(2, "sts3215", norm_mode_body),
    "elbow_flex":    Motor(3, "sts3215", norm_mode_body),
    "wrist_flex":    Motor(4, "sts3215", norm_mode_body),
    "wrist_roll":    Motor(5, "sts3215", norm_mode_body),
    "gripper":       Motor(6, "sts3215", MotorNormMode.RANGE_0_100),
}
# action keys are "<motor>.pos"; send_action sync_writes them to
# "Goal_Position"  ->  a 6-D ABSOLUTE JOINT POSITION command


# openpi/src/openpi/policies/droid_policy.py
def make_droid_example() -> dict:
    return {
        "observation/exterior_image_1_left": np.random.randint(256, size=(224, 224, 3), dtype=np.uint8),
        "observation/wrist_image_left":      np.random.randint(256, size=(224, 224, 3), dtype=np.uint8),
        "observation/joint_position":        np.random.rand(7),   # seven Franka joints
        "observation/gripper_position":      np.random.rand(1),
        "prompt": "do something",
    }
# state = concat(joint_position, gripper_pos)  ->  8-D

既製のDROIDチェックポイントは近道ではありません。Physical Intelligenceはpi05_droidをgs://openpi-assets/checkpoints/pi05_droidで提供しており、その広範な能力を称賛する同じREADMEには、これらのエキスパートチェックポイントがあなたのセットアップに一般化しない可能性があると警告されています。その状態は8つのFrankaジョイント番号であり、画像キーはexterior_image_1_leftとwrist_image_leftです。その状態を6モーターのSO-100コマンドに変換するフラグはありません。

2. アクションベクトルが実際に示すもの

次元性よりも深い問題です。LeRobotの変換では、3つすべてがグリッパーがデカルト空間のどこに行くべきかを示します。SO-100は6つのサーボがどこに行くべきかを示します。変換には、リシェイプではなく、運動学モデルとソルバーが必要です。

LeRobotは不足している部分を提供しています。SOフォロワーには、InverseKinematicsEEToJointsとForwardKinematicsJointsToEEのステップを持つ運動学プロセッサがあります。そのキーはee.x、ee.y、ee.zに加えて回転ベクトルee.wx、ee.wy、ee.wz、そしてee.gripper_posであり、ファイル内のロール・ピッチ・ヨーとは向きのエンコーディングも異なります。IKステップはorientation_weight（デフォルト0.01）を取り、そのドキュメント文字列には、低駆動アームでの位置のみのIKには0.0を設定するよう記載されています。ブリッジを構築することはできますが、借用されたすべてのアクションの向きの半分は近似されたままになります。

3. 制御レート

DROIDは15 Hz、BridgeData V2は5 Hz、google_robotスライスは3 fpsです。pi0の著者らは、彼らの混合物のオープンソース部分を2 Hzから10 Hzの低周波制御と説明しています。LeRobotのDatasetRecordConfigは、fps 30、episode_time_s 60、reset_time_s 60、num_episodes 50がデフォルトです。 5 Hzのデータで学習されたポリシーは、1つのアクションが200 msをカバーすることを学びました。これを30 Hzで再生するとアームはゆっくりと動き、安易にリサンプリングするとグリッパーが閉じるフレームがぼやけてしまいます。これは とも相性が悪いです。100ステップのチャンクは5 Hzでは20秒、30 Hzでは3.3秒になります。

4. カメラ

BridgeData V2は50軌道ごとに2つのカメラポーズをランダム化し、そのプロジェクトページでは、ほとんどのデータが固定ビューのみを保持していると述べられています。DROIDは調整可能なZED 2マウントと手首のZED Miniを使用しました。あなたは2つのUSBウェブカメラを目測で配置しています。カメラポーズはビジョン言語アクションモデルにとって邪魔な変数ではありません。それはビジュアルエンコーダが注目したものの多くであり、ファイル形式にはポーズが異なることを示すものは何もありません。

それでもデータをマージしようとするとどうなるか

明白な計画は、数千のDROIDエピソードとあなたの50エピソードを連結することです。LeRobotはこれを拒否し、その拒否は異なる3つの点を挙げています。

1. 1
   全体の1.7TBではなく、100エピソードのサンプルをプルする

   構造を確認するには2GBで十分です。

   bash

   pip install gsutil tensorflow tensorflow-datasets
   gsutil -m cp -r gs://gresearch/robotics/droid_100 ~/tensorflow_datasets/

2. 2
   RLDSをLeRobot形式に変換する

   openx2lerobotはOXE標準の変換をラップし、ロボットタイプと制御周波数をアノテーションします。READMEにはこれがconvert.shに記載されています。

   bash

   git clone https://github.com/Tavish9/any4lerobot.git
   cd any4lerobot/openx2lerobot
   
   python openx_rlds.py \
       --raw-dir ~/tensorflow_datasets/droid_100/1.0.0 \
       --local-dir ~/lerobot_droid100 \
       --repo-id you/droid100_lerobot \
       --use-videos

3. 3
   他の何よりも先にmeta/info.jsonを読み込む

   このファイルが、その後の作業がうまくいくかどうかを決定します。

   bash

   python -c "import json;d=json.load(open('meta/info.json'));\
   print(d['codebase_version'], d['robot_type'], d['fps']);\
   print(d['features']['action']['shape'], d['features']['observation.state']['shape'])"

4. 4
   マージを試してエラーを読む

   mergeはすべてのデータセットをロードし、validate_all_metadataはリストの最初のデータセットに対してfps、robot_type、およびfeaturesをチェックし、最初の一致しない箇所でエラーを発生させます。

   bash

   lerobot-edit-dataset \
       --new_repo_id you/mixed \
       --operation.type merge \
       --operation.repo_ids "['you/droid100_lerobot', 'you/my_so100_task']"
   
   # ValueError: Same fps is expected, but got fps=30 instead of 15.

参照値は、最初にリストしたデータセットから取得されます。そのため、メッセージはDROIDの15fpsではなく、あなたの30fpsについて不平を言います。fpsを修正するとrobot_typeチェックに引っかかり、それを修正するとアクションの7対6のfeatureチェックに引っかかります。どの順序でも通過せず、sanity_check_dataset_robot_compatibilityを介して記録時にも同じガードが実行されます。

では、実際に何が転移するのか？

転移するのはエピソードではなく、重みです。現代の汎用ポリシーはすべて、事前学習でその一部を吸収しており、を公開されたから行うと、適切に処理する計算能力を持つ人々によって既に調整されたものを継承することになります。pi0の論文では、その割合について率直に述べられています。タイムステップで数えると、事前学習混合の9.1%がOXE、Bridge v2、DROIDを含むオープンソースデータです。この数値はpi0のものであり、各ベンダーの混合は異なります。

これが、SmolVLAが低コストアームで異なる動作をする理由です。その論文では、Hugging Faceから481のコミュニティデータセットが選択され、エンボディメントタイプ、エピソード数、データ品質、フレームカバレッジでフィルタリングされています。22.9Kエピソード、10.6Mフレームが、実際のSO-100およびSO-101アームで評価されました。小規模で一致したものが、大規模で不一致なものよりも優れています。比較はACTとSmolVLAの比較で。

取るべき3つのパス

パスA: データを既に学習済みのチェックポイントからファインチューニングする

ほとんどの人はこのパスを選ぶべきです。DROIDやOpen X-Embodimentには決して触れません。プレトレーニングで既にクロスエンボディメントデータを吸収したポリシーを選択し、独自のエピソードを記録してファインチューニングします。

ACTは正直なエッジケースです。ベースモデルがないため、公開データがそれに到達することはありません。1アクションステップあたり20 msであるため、高速ループを閉じることができる5つのうち唯一のものであるため、自動的に不利になるわけではありません。ACTページで説明されています。タスクに応じて選択するには、5つすべてを比較、GR00T N1.7とPi0.5の比較、および85モデルにわたる332のベンチマーク結果はアリーナで確認できます。

パスB：DROIDをテストフィクスチャとして使用する

100エピソードのサンプルは、今月ダウンロードする2 GBのデータの中で最高のものであり、トレーニング用ではありません。これは、正しいとわかっているデータセットです。これに対してコンバーター、ローダー、および短いGPUジョブを実行してください。失敗したものは、安価なうちに発見されたインフラストラクチャのバグです。NVIDIAも同様に大規模でこれを行っています。GR00T N1.7カードには、SimplerEnvのBridgeとFractal、DROID、およびLIBERO用に、4つの後処理済みバリアントがリストされています。

パス C: 意図的に自分で記録する

30から50という数は、76,000という数字の隣では少なく聞こえますが、あなた自身の腕、カメラ、テーブルを使ったデータはそれだけであることを思い出してください。LeRobotのデフォルト設定では、50エピソードは実時間で100分です。参照：、、および.

公開データから実用的なポリシーを得る2つの方法

各パスのコスト

非対称性が重要です。最も多くのデータを借用するパスは最もコストがかかり、アームを動かす可能性が最も低いです。2時間未満の自身のテレイグジスタンスは、他人のFrankaの1テラバイトに勝ります。まだアームがありませんか？/liveでは、サインアップなしで物理的なSO-100をストリーミングしています。その後、最初のポリシーをトレーニングし、特定のガイドについてはSO-100でのSmolVLAを参照してください。