SO-100アームで最初のLeRobotデータセットを記録するためのAY-Robotsチュートリアルページ
LeRobotSO-100データセット記録テレイグジスタンス模倣学習

SO-100で最初のLeRobotデータセットを記録する

AY-Robots ResearchAugust 23, 202616 分で読めます

SO-100で利用可能なLeRobotデータセットを記録する:キャリブレーション、リーダー・フォロワー方式のテレイグジスタンス、実際のlerobot-recordフラグとデフォルト、カメラ設定、エピソード数、および実行を台無しにする欠陥。

SO-100フォロワー、同じ設計のリーダーアーム、および2台のUSBカメラを使用すると、午後にはポリシーを微調整できます。同じベンチで、ファイルブラウザで健全に見える60エピソードを簡単に生成し、6時間のGPU実行を無駄にすることもできます。違いはモデルにあることはめったになく、サーボとParquetファイルの間に何が起こったかです。

まず手動ルート、次に短いルートです。すべてのコマンドは、2026年8月3日にリリースされ、PyPIで最新のlerobot 0.6.1からのものです。コンソールエントリポイントに移行したため、python lerobot/scripts/control_robot.pyを実行するチュートリアルは、もはや存在しないファイルを記述しています。

簡易版

  • lerobot 0.6.1はv3.0を記録します。GR00T N1.7とN1.5はv2.1を必要とします。記録を開始する前にフォーマットを決定してください。
  • 4つのコマンド:lerobot-find-port、lerobot-setup-motors、lerobot-calibrate、lerobot-record。キャリブレーションから記録セッションまで、同じ--robot.idと--teleop.idを引き継いでください。
  • 実際のデフォルト:30 fps、エピソードあたり60秒、リセット60秒、50エピソード、実時間で約100分。
  • ここでの最小エピソード数:SmolVLAは30、その他は50。
  • 多様性は量に勝ります。データセットは次の4つの原因で機能しなくなります:カメラインデックスの入れ替わり、フレームのドロップまたはフリーズ、関節が限界位置で停止、読み取り不能なタスク文字列。

記録セッションがキャプチャするもの

A LeRobotデータセットは、動画のフォルダではなく、動画が添付された時間インデックス付きのテーブルです。制御ループの各ティックは、指令されたアクション、フォロワーが到達した状態、カメラごとの1フレーム、タイムスタンプ、およびインデックスを含む1行を書き込みます。ポリシーはこれらの列のみを参照します。のスキーマは、lerobot/svla_so100_pickplaceのmeta/info.jsonから読み取られます。

特徴データ型形状内容
actionfloat32[6]リーダーアームからの関節ターゲット
observation.statefloat32[6]フォロワーが到達した関節位置
observation.images.topvideo[480, 640, 3]シーンカメラ、MP4(ここではav1)
observation.images.wristvideo[480, 640, 3]手首カメラ、同レート
timestampfloat32[1]エピソード開始からの秒数
frame_index, episode_index, index, task_indexint64[1]自動入力される帳簿情報

関節はmain_shoulder_pan、main_shoulder_lift、main_elbow_flex、main_wrist_flex、main_wrist_roll、main_gripperです。これらはSO-100の6つの自由度です。アクションと状態が同じ形状を持つのは、リーダー・フォロワー型テレイグジスタンスがターゲットと、1ステップ後に到達した位置を記録するためです。このギャップは情報であり、アームが重力や固着した物体と戦った場所を示します。これらの文字列はそのデータセットのものです。本日0.6.1で記録されたセッションでは、shoulder_pan.posからgripper.posまで、バス上のID 1から6が書き込まれます。同じ6つの関節ですが、キーが異なります。これは、設定が名前で特徴を指定する際に重要になります。

実際のデータセットからの目安

このデータセットには、50エピソード、19,631フレームが30 fpsで含まれています。これは、1エピソードあたり約393フレーム、または13秒に相当します。もしあなたのデータセットが平均1分である場合、より難しいことをしているか、両端で無駄な時間を記録しているかのどちらかです。

AY-Robots の LeRobot データセット形式の用語集エントリ。ディレクトリレイアウトとメタデータファイルを示しています。
data/、videos/、meta/ に何があり、どのポリシーがどのバージョンを読み取るか。

ベンチで必要なもの

項目詳細備考
フォロワーアームSO-100、Feetech STS3215サーボ6個部品で約110~150ユーロ
リーダーアーム2つ目のSO-100、ギアは取り外し済み6つのリーダーモーターすべてからギアを取り外し済み:エンコーダーのみ、摩擦を低減
電源部品表にある7.4 V STS3215バリアントに適合下記の警告を参照
カメラUSBカメラ2台、640x480、30 fpsシーンビュー用1台、手首用1台
ホストPython 3.12以降、ffmpegrequires-python >= 3.12
HubアカウントHugging Face書き込みトークンoptional with --dataset.push_to_hub=false
7.4 V、12 Vではありません

STS3215には2つのバージョンがあります。SO-ARM100のREADMEでは、7.4 Vバージョンは6 Vで測定されたストールトルクが16.5 kg.cm、12 Vバージョンは30 kg.cmと評価されており、12 Vモーターを選択すると、5 V電源の代わりに12 V 5 A+電源を購入する必要があることに注意しています。部品表には7.4 Vサーボが記載されています。7.4 V定格のサーボに12 Vを供給すると破損するため、配線する前にモーターのラベルを読んでください。サーボが応答しない

アームがまだ組み立てられていない場合は、別の作業が必要です。まずはSO-100の開始方法SO-100セットアップ完全ガイドから始めてください。まだ何も購入していない場合は、SO-100とSO-101の比較を最初に読んでください。SO-101は配線が改善され、ギア取り外し工程が不要になった新しいリビジョンであり、記録ワークフローは同じです。

lerobot 0.6.1のインストール

bash
conda create -y -n lerobot python=3.12
conda activate lerobot

# TorchCodec is the default video decoder and needs ffmpeg
conda install ffmpeg -c conda-forge

# core_scripts = dataset + hardware + viz extras (record, replay, calibrate)
# feetech     = SDK for the STS3215 bus servos in the SO-100
pip install 'lerobot[core_scripts,feetech]'

lerobot-info
lerobot-infoは、PATH上で見つけられるffmpegのバージョンを含むシステム概要を出力します。

エクストラはほとんどの人がつまずく点です。pip install lerobotは、コアMLの依存関係のみをインストールし、ロボットと通信するものは何もインストールしません。Kochアームにはdynamixelの代わりにfeetechが必要です。もしシェルがlerobot-recordを認識しない場合、それが理由です。

ポート、モーターID、およびキャリブレーション

部品と動作するテレオペレーションループの間には、3つの1回限りのステップがあります。 は、あなたのロボットアームで学習されたポリシーを他のロボットアームで実行できるようにし、生のエエンコーダーカウントを共有の関節規約にマッピングします。

  1. 1
    各アームのUSBポートを見つける

    両方のアームを接続した状態で実行し、プロンプトが表示されたら識別するアームのプラグを抜き、どのポートが消えるかを確認します。Linuxでは、sudo chmod 666 /dev/ttyACM0が必要になる場合があります。

    bash
    lerobot-find-port
    # Finding all available ports for the MotorsBus.
    # Ports before disconnecting: ['/dev/ttyACM0', '/dev/ttyACM1']
    # Remove the USB cable from your MotorsBus and press Enter when done.
    # The port of this MotorsBus is '/dev/ttyACM1'
    # Reconnect the USB cable.
  2. 2
    モーターIDとボーレートを書き込む

    IDはモーターごとに1つずつ書き込まれ、その方法はドキュメントで厳密に定められています。コントローラーボードには、まだ他のモーターにデイジーチェーン接続されていないモーターを1つだけ接続してください。スクリプトはチェーンを逆方向にたどり、最初にグリッパーのプロンプトを表示してID 6を与え、次にwrist_rollにID 5、shoulder_panにID 1を与えます。組み立て前に行ってください。

    bash
    lerobot-setup-motors \
        --robot.type=so100_follower \
        --robot.port=/dev/ttyACM0
    
    lerobot-setup-motors \
        --teleop.type=so100_leader \
        --teleop.port=/dev/ttyACM1
  3. 3
    両方のアームをキャリブレーションする

    すべての関節を可動範囲の中央に移動させ、Enterキーを押し、その後、それぞれの関節を全範囲にわたって動かします。idはプロファイルファイル名になります。

    bash
    lerobot-calibrate \
        --robot.type=so100_follower \
        --robot.port=/dev/ttyACM0 \
        --robot.id=my_so100_follower
    
    lerobot-calibrate \
        --teleop.type=so100_leader \
        --teleop.port=/dev/ttyACM1 \
        --teleop.id=my_so100_leader
  4. 4
    何も記録する前にテレオペレーションを行う

    上記すべての受け入れテストです。テレオペレーションがぎこちない、ミラーリングされている、または1つの関節が追従しない場合、記録は50エピソードでそれを保持します。

    bash
    lerobot-teleoperate \
        --robot.type=so100_follower \
        --robot.port=/dev/ttyACM0 \
        --robot.id=my_so100_follower \
        --teleop.type=so100_leader \
        --teleop.port=/dev/ttyACM1 \
        --teleop.id=my_so100_leader \
        --display_data=true
キャリブレーションの保存場所とIDが重要な理由

プロファイルは$HF_LEROBOT_CALIBRATION(デフォルトは~/.cache/huggingface/lerobot/calibration)に保存され、IDがルックアップキーとなります。lerobot-recordにキャリブレーション済みのIDを指定すると、Enterキーでプロファイルを再利用するか、cキーでやり直すかを選択できます。未知のIDを指定するとファイルが存在しないため、セッション中にキャリブレーションが開始されます。

カメラがポリシーの視覚を決定する

bash
lerobot-find-cameras opencv   # or: lerobot-find-cameras realsense

# --- Detected Cameras ---
# Camera #0:
#   Name: OpenCV Camera @ 0
#   Type: OpenCV
#   Id: 0
#   Backend api: AVFOUNDATION
#   Default stream profile:
#     Format: 16.0
#     Width: 1920
#     Height: 1080
#     Fps: 15.0
これはセッションごとに実行してください。ドキュメントでは、これらの識別子はオペレーティングシステムによっては再起動や再接続後に変更される可能性があると警告しています。

2つの視点とその配置が重要です。ワークスペースをカバーする固定シーンカメラと、エンドエフェクタの近くにある、グリッパーが触れようとしているものを示す手首カメラです。LeRobotのコミュニティデータセットチェックリストでは、できれば480x640 / 720p以上の2つの視点、静的な背景、中立で安定した照明、そしてリーダーアームと人間の手足がフレーム外にあることを求めています。記録ガイドには経験則が追加されています。カメラ画像だけを見て、自分でタスクを実行できるべきです。

カメラのインデックスは安定した識別子ではない

OpenCVのインデックスは列挙順に由来するため、再起動や再接続によってインデックス0と2が入れ替わり、手首の視点がセッション全体で最上位のスロットになることがあります。lerobot自身も、そのカメラクラスは整数だけでなくデバイスパスも受け取り、特にLinuxでは再起動やポート変更によってインデックスが不安定になることを警告しています。index_or_path/dev/v4l/by-id/の下にあるudevシンボリックリンクに向けます。これは列挙順ではなくデバイスに従います。これはデータセットが内部的に矛盾する最も一般的な方法であり、トレーニングではこれを修復できません。カメラが検出されない

recordコマンドとすべてのフラグ

bash
HF_USER=$(NO_COLOR=1 hf auth whoami | awk -F': *' 'NR==1 {print $2}')

lerobot-record \
    --robot.type=so100_follower \
    --robot.port=/dev/ttyACM0 \
    --robot.id=my_so100_follower \
    --robot.cameras="{ top: {type: opencv, index_or_path: 0, width: 640, height: 480, fps: 30}, wrist: {type: opencv, index_or_path: 2, width: 640, height: 480, fps: 30}}" \
    --teleop.type=so100_leader \
    --teleop.port=/dev/ttyACM1 \
    --teleop.id=my_so100_leader \
    --display_data=true \
    --dataset.repo_id=${HF_USER}/so100_pick_cube \
    --dataset.single_task="Pick the red cube and drop it in the box" \
    --dataset.num_episodes=50 \
    --dataset.fps=30 \
    --dataset.episode_time_s=25 \
    --dataset.reset_time_s=10 \
    --dataset.streaming_encoding=true \
    --dataset.encoder_threads=2
カメラ辞書はシェルで引用符で囲まれた1つの文字列です。ネストされた中括弧はシェル構文ではありません。

以下のデフォルト値はsrc/lerobot/configs/dataset.pyのmainブランチから取得したものであり、チュートリアルからではありません。いくつかについては、一般的に想定されているものとは異なります。

フラグデフォルト機能
--dataset.repo_idempty名前; デフォルトでタイムスタンプが追加されます
--dataset.single_taskempty各エピソードと共に保存されるタスク文字列
--dataset.root$HF_LEROBOT_HOME/repo_id書き込みパス、デフォルトは ~/.cache/huggingface/lerobot/
--dataset.fps30制御ループレートとデータセットのフレームレート
--dataset.episode_time_s60エピソードが自動的に進行するまでの秒数
--dataset.reset_time_s60シーンのリセット; アームが動き、何も保存されません
--dataset.num_episodes50このセッションで記録されるエピソード数
--dataset.push_to_hubtrueセッション終了時にアップロード; falseの場合はローカルに保持
--dataset.streaming_encodingfalse in the dataclass, true in the docs tableキャプチャ中にエンコード; 明示的に設定してください
--dataset.encoder_queue_maxsize30カメラごとのバッファリングされるフレーム数、30 fpsで約1秒
--dataset.encoder_threadsnull (codec decides)エンコーダーごとのスレッド数; キャプチャが途切れる場合は減らしてください
--dataset.no_stampfalserepo_idをタイプされた通りに保持
--resumefalse既存のデータセットに追加; --dataset.rootが必要です
不意に1時間を費やすことになる2つのフラグ

入力した名前でデータセットは作成されません。lerobotは日付時刻タグを付加するため、so100_pick_cubeso100_pick_cube_20260823_141530になります。安定した名前には--dataset.no_stamp=trueを使用してください。再開は追加分をカウントし、合計ではありません。--resume=trueを使用すると、--dataset.num_episodes追加のエピソード数をカウントし、--dataset.rootは必須になります。30エピソードのデータセットで50を要求すると、80になります。

セッション中のキーボード操作

  • 右矢印またはn: エピソードを終了するか、フェーズを早期にリセットします。クリーンな把持は25秒を必要とすることが稀であるため、最もよく使うキーです。
  • 左矢印またはr: エピソードを破棄してやり直します。悪いテイクは今では何も費用がかかりませんが、後で多くの費用がかかります。
  • Escapeまたはq: セッションを停止し、エンコードを完了し、アップロードします。
  • これらはX11、Wayland、およびヘッドレスSSHで機能します。グローバルキーバックエンドがない場合、lerobot-recordは制御端末から同じキーを読み取ります。矢印シーケンスが分割されるような遅延のあるSSHリンクでも、文字は機能します。
  • キーボードによる遠隔操作は異なり、グローバルバックエンド(X11、Windows、またはアクセシビリティを備えたmacOS)が必要です。

エピソード数と良いエピソードの例

記録ガイドでは、最初のタスクとして少なくとも50エピソード、オブジェクトの場所ごとに約10エピソードを推奨しています。 ポリシーページにはモデルごとの最小値が記載されており、それを下回るとGPU時間を費やす価値がありません。

ポリシー最小エピソード数データセット形式GPUティア実行あたりのコスト
SmolVLA30LeRobot v3.0RTX 4090 or any 24 GB cardabout 1 to 3 USD
ACT50LeRobot v3.0RTX 4090 or any 24 GB cardabout 1 to 3 USD
GR00T N1.750LeRobot v2.0 or v2.1A100 80 GB or H100 80 GBabout 4 to 12 USD
GR00T N1.550LeRobot v2.0 or v2.1A100 80 GB or H100 80 GBabout 4 to 12 USD
Pi0.550LeRobot v3.0A100 80 GB or H100 80 GBabout 4 to 12 USD

より良い質問は、何がいくつあるかです。 Data Scaling Laws in Imitation Learning for Robotic Manipulation (Lin et al., 2024) は、40,000を超えるデモンストレーションを収集し、15,000を超える実世界でのロールアウトを実行しました。汎化は、環境とオブジェクトの数とほぼべき乗則の関係にあり、環境またはオブジェクトごとの閾値を超えると、追加のデモンストレーションの効果は最小限でした。あるベンチでは、1つのテイクを繰り返すのではなく、オブジェクトを動かし、照明を変更し、キューブを交換します。

データソースとしてのリーダー・フォロワー型テレイグジスタンス
利点
  • キーボードやゲームパッドとは異なり、サーボが再現できる連続的な関節軌道
  • アクションと状態が座標規則を共有するため、ポリシーは直接コマンドできるターゲットを学習します。
  • 25秒のエピソードと10秒のリセットで、1時間あたり約100エピソードになります。
  • オペレーターはフォロワーの失速や拘束を感じるため、データがコミットされる前に障害が表面化します。
トレードオフ
  • 2本目のアームは部品コストをほぼ2倍にする
  • デモンストレーションはオペレーターの習慣を受け継ぎます。Mandlekar et al. は、ポリシーの品質がデモンストレーションの品質に大きく依存することを発見しました。
  • リーダーはループレートでサンプリングされるため、一時停止はほぼ同一の行となり、ポリシーに待機することを教え込みます。
  • セッション間の整合性を強制するものはありません。カメラが5 cmずれると、隠れた分布シフトが発生します。

良いエピソードは退屈である:再現可能なホームポーズ、一つのことを実行し、オブジェクトがビンに入ったら終了、チェックリストが推奨する25〜50文字のタスク文字列。 Pick the red cube and drop it in the box はタスク文字列であり、task1 はチェックリストが明示的に挙げるアンチパターンである。曖昧なアノテーションが問題リストの筆頭に挙げられており、これらは特にビジョン言語アクションモデル において重要である。なぜなら、文字列はファイル名ではなくモデルの入力となるからだ。

データセットを静かに台無しにする欠陥

どれも例外をスローしない。すべてトレーニングまで生き残り、見た目は問題ない損失曲線と、何も動作しないロボットとして現れる。シーンがセットアップされている間に確認すること。

欠陥見た目原因検出方法
カメラビューの入れ替わり手首の画像がトップキーの下に再接続後のインデックス再割り当てlerobot-find-cameras をセッションごとに実行; by-id パス
フリーズしたフレーム数十行にわたって同じ画像カメラが配信を停止; ループが最後のフレームを繰り返すlerobot-dataset-viz で確認
ドロップされたフレーム行数がfps×秒を下回るキューがオーバーフローし、ブロックせずにドロップ'Encoder queue full' in the log; 行数 vs fps×期間
関節が限界に達している一つの関節が最小または最大で平坦リーダーの範囲がフォロワーの範囲を超える、または悪い中間ポーズds.meta.stats の関節ごとの最小/最大; 事前に lerobot-find-joint-limits
画像とアクションのずれポリシーが先行または遅延カメラがループとは異なるfpskeep every camera at --dataset.fps
デッドタイム同一アクション行の長い連続オペレーターがレコーダーを起動したまま一時停止連続する同一アクション行の割合
使用できないタスク文字列task1, demo2, test高速タイピングmeta/tasks.parquet in v3.0 (it was meta/tasks.jsonl in v2.1); lerobot-edit-dataset modify_tasks で修正
ドロップされたフレームは隠れる

エンコーダはカメラごとにバウンドキューを保持し、デフォルトで30フレームです。処理が追いつかない場合、フレームはブロックされるのではなくドロップされます。キャプチャは継続され、何もクラッシュしません。エピソードの終わりに、Encoder queue full for {camera}, dropped N frame(s)というメッセージとカメラごとの合計が表示されます。lerobotのしきい値:約5%の欠落はシステムが過負荷であることを意味し、2%は起動時の予想される負荷です。修正策(順不同):--display_data=false--dataset.encoder_threadsの値を下げる、vcodec=h264、ストリーミングをオフにする。

一つ注意点があります。ストリーミングエンコーディングガイドのテーブルではデフォルトがTrueと記載されていますが、mainブランチのデータクラスではstreaming_encoding: bool = Falseとなっています。ドキュメントとコードが一致しないため、明示的に設定してください。lerobotは、このフラグがオフの状態で起動するたびに、設定を推奨するヒントをログに出力します。

GPUをレンタルする前にデータセットを確認する

ドキュメントに記載されている受け入れテスト:CLIが報告したエピソードの期間とビデオの期間を比較し、行数がfpsに期間を掛けた値と等しいことを確認します。これは合計ではなく、エピソードごとに行います。

python
from lerobot.datasets import LeRobotDataset

ds = LeRobotDataset("your-user/so100_pick_cube_20260823_141530")
print("fps:", ds.fps, "frames:", ds.num_frames)

# In v3.0 the per-episode records live in meta/episodes/ as chunked parquet:
# lengths, tasks and offsets into the shared parquet and mp4 shards.
# They load through the datasets stack, so this is a datasets.Dataset --
# use .column_names and integer indexing, not pandas .columns / .head().
eps = ds.meta.episodes
print(eps.column_names)
print(eps[0])

# Global feature statistics, including per-joint min and max.
# A joint whose min equals its max never moved. A joint sitting at a
# hard limit for most of the run is the one that will stall the policy.
print(ds.meta.stats["observation.state"])
fpsとdurationから大きく外れたエピソードは、トレーニングではなく削除の候補です。

次に、それを見てください。lerobot-dataset-viz は、カメラビューの横にジョイントトレースを表示しながら、RerunまたはFoxgloveでエピソードをフレームごとに再生します。カメラの入れ替わりやフリーズしたフレームは10秒で表示されます。多くの人はこのステップをスキップします。

bash
# Replay one episode with camera views and joint traces
lerobot-dataset-viz \
    --repo-id your-user/so100_pick_cube_20260823_141530 \
    --episode-index 0

# Foxglove instead, for a seekable, scrubbable timeline
lerobot-dataset-viz \
    --repo-id your-user/so100_pick_cube_20260823_141530 \
    --episode-index 0 \
    --display-mode foxglove

# Drop the episodes that did not survive review
lerobot-edit-dataset \
    --repo_id your-user/so100_pick_cube_20260823_141530 \
    --new_repo_id your-user/so100_pick_cube_clean \
    --operation.type delete_episodes \
    --operation.episode_indices "[3, 17, 41]"
lerobot-edit-datasetは、分割、マージ、特徴の削除、タスクの変更、統計の再計算も行います。惜しみなく削除してください。悪いエピソードは1つのエピソードのコストですが、それを保持すると、それを使ってトレーニングされたすべての実行にコストがかかります。
AY-Robotsデータセットディレクトリには、エピソード数とフォーマットが記載された公開LeRobotデータセットがリストされています。
比較可能なデータセットがどのようにサイズ設定され、アノテーションされているか。

v2.1またはv3.0: 記録する前に決定してください

v2.1はエピソードごとに1つのparquetファイルと1つのMP4ファイルを書き込みました。v3.0は多数のエピソードを共有シャードに連結し、メタデータから境界を再構築するため、info.jsonにはエピソード番号の代わりにパスのテンプレート(例:data/chunk-{chunk_index:03d}/file-{file_index:03d}.parquet)が含まれます。この変更の根拠は、ファイル数を減らし、ファイルサイズを大きくすることで、初期化を高速化し、大規模なファイルシステムへの負荷を軽減することです。

LeRobot v2.1LeRobot v3.0
レイアウトエピソードごとに1つのparquetと1つのMP4シャードごとに多数のエピソード
エピソードメタデータJSONLファイルmeta/episodes/下のチャンク化されたparquet(データセットスタック経由)
Hubからのストリーミングいいえはい、StreamingLeRobotDataset経由
lerobot 0.6.1による書き込みいいえはい、現在得られるもの
GR00T N1.7およびN1.5による読み取りはいいいえ、ダウングレード変換が必要
今日記録、明日GR00Tをトレーニング

lerobot 0.6.1はv3.0を書き込みますが、GR00T N1.7およびN1.5はv2.0またはv2.1を読み取り、v3.0ではクラッシュします。変換の方向性に注意してください: src/lerobot/scripts/にはconvert_dataset_v21_to_v30.pyがありますが、逆方向のスクリプトはありません。セッション前にこの問題を解決してください。修正: v3として拒否されたデータセット

bash
# Upgrade an older v2.1 dataset to v3.0
python -m lerobot.scripts.convert_dataset_v21_to_v30 \
    --repo-id=your-user/so100_pick_cube

# By default it pushes the converted dataset back to the hub and tags it v3.0.
# To convert a local copy and keep it off the hub:
python -m lerobot.scripts.convert_dataset_v21_to_v30 \
    --repo-id=your-user/so100_pick_cube \
    --root=/path/to/dataset/directory \
    --push-to-hub=false
50エピソードのクイック変換。規模の大きい作業は別です。生DROIDをv3.0に移植するためのlerobotのポーティングガイドでは、7日以上のローカル処理と約400 GBの予算を見込んでいます。

同じデータセットへの2つの経路

上記のすべてを自分のマシンで実行します。USB列挙、ffmpegビルド、エンコーダーチューニング、キャリブレーションファイルをすべて自分で管理します。パイプラインを理解し、珍しいカメラリグを実行し、またはデータをローカルに保持するための適切な経路です。

この経路のコスト

時間:アームごとに組み立てに一晩、手間のかかる初回キャリブレーション、そしてカメラが間違ったスロットに入っていたために破棄する最初のセッション。

パイプラインを自分で配線せずにLeRobotデータセットを記録

AY-Robotsデスクトップクライアントは、テレイグジスタンスセッションからLeRobot形式でエピソード、カメラストリーム、ジョイント状態を記録し、そのデータセットをトレーナーに渡します。

デスクトップクライアントを入手

データセットからポリシーへ

50個のクリーンなエピソードが、ここでのあらゆるの実行に供給されます。は、あなたのタスクのみでゼロから学習し、約80Mのパラメータを持ち、アクションステップあたり約20msで動作します。5つのうち、高速な動きに対応できる唯一のものです。は、24GBのカードで約450Mのパラメータを持ちます。は、約3Bのパラメータを持つ基盤モデルで、は約40Mのパラメータに影響を与え、A100またはH100を必要とし、v2.1データセットを求めます。

次に、あなたの組み合わせに応じたガイドです:、または。最初の実行には、がより短いです。ポリシーがベンチでは機能するものの、テーブルを動かした瞬間に破綻する場合、それはデータの問題です:とで多様性について詳しく説明しています。

最初の動作するポリシーには、実際にいくつのエピソードが必要ですか?

SmolVLAには30、ACT、Pi0.5、GR00T N1.5、N1.7には50が、AY-Robotsのトレーナーが強制する最小値です。LeRobotのガイドでは、最初のタスクには少なくとも50、オブジェクトの場所ごとに約10を独自に推奨しています。データスケーリングの研究では、汎化はデモンストレーションの数よりも環境やオブジェクトの数に比例することが判明しており、そのため1つのシーンで100回撮影するよりも、5つの配置で50回撮影する方が優れています。

リーダーアームは必要ですか、それともキーボードで遠隔操作できますか?

はい、チューニングが必要です。ストリーミングエンコーディングガイドには、現代の4コアマシンやRaspberry Pi 5をカバーする低リソースの項目があり、640x480で30 fpsのカメラ2台を「ある程度のチューニングが必要」なカテゴリに入れています。そのアドバイスは、--dataset.rgb_encoder.vcodec=h264と--dataset.streaming_encoding=falseを使用して、エンコーダがキャプチャループと競合するのを止めることです。640x480のカメラ2台を約5500万ピクセル/秒、1920x1080のカメラ2台を約3億7300万ピクセル/秒と評価しています。

Raspberry Piや小型ミニPCで記録できますか?

はい、チューニングが必要です。ストリーミングエンコーディングガイドには、現代の4コアマシンやRaspberry Pi 5をカバーする低リソースの項目があり、640x480で30 fpsのカメラ2台を「ある程度のチューニングが必要」なカテゴリに入れています。そのアドバイスは、--dataset.rgb_encoder.vcodec=h264と--dataset.streaming_encoding=falseを使用して、エンコーダがキャプチャループと競合するのを止めることです。640x480のカメラ2台を約5500万ピクセル/秒、1920x1080のカメラ2台を約3億7300万ピクセル/秒と評価しています。

記録したデータセットが実際に健全であるかどうかをどうやって知ることができますか?

3つの簡単なチェックがあります。各エピソードのビデオ再生時間をCLIが報告した再生時間と比較し、行数がその再生時間とfpsを掛けたものに等しいことを、合計ではなくエピソードごとに確認します。これがlerobotのエンコーディングガイドが示す受け入れテストです。ds.meta.statsを読み、minとmaxが等しいジョイントは一度も動いていないことを確認します。次に、lerobot-dataset-vizで2、3のエピソードを再生します。これが、ビューの入れ替わりやフリーズしたフレームが現れる唯一の方法です。フレーム落ちについては、ガイドでは約5パーセントの欠落を許容範囲としています。約2パーセントは通常の過渡的な負荷であり、多くの場合、起動時のみです。

私の学習ジョブがデータセットをv3.0として拒否しました。どうすればよいですか?

GR00T N1.7とN1.5はLeRobot v2.0またはv2.1を読み込み、v3.0ではクラッシュします。v3.0はlerobot 0.6.1が記録する形式です。学習前に形式を確定するか、v3.0をネイティブに読み込むポリシー(Pi0.5、SmolVLA、またはACT)を使用してください。lerobotはv2.1からv3.0へのコンバーターを提供していますが、逆方向のものは提供していません。

Ready for high-quality robotics data?

AY-Robots connects your robots to skilled operators worldwide.

Get Started