استفاده از DROID، BridgeData V2 و Open X روی SO-100

یک مجموعه داده عمومی با میلیون‌ها مسیر در یک Google Cloud bucket و یک SO-100 روی میز وجود دارد که 110 to 150 EUR هزینه قطعات آن است. چرا اولی نمی‌تواند دومی را آموزش دهد؟ تا حدی می‌تواند، اما تقریباً هیچ یک از انتقال‌ها در جایی که مردم انتظار دارند اتفاق نمی‌افتد، و بخشی که آسان‌ترین به نظر می‌رسد اصلاً کار نمی‌کند.

در ادامه: آنچه در داخل DROID، BridgeData V2 و Open X-Embodiment، جایی که هر کدام با یک بازوی 5-DoF کم‌هزینه برخورد می‌کند، و اینکه به جای آن چه باید کرد. هر عددی که در ادامه می‌آید از مقاله، کارت مجموعه داده یا فایل منبع مربوط به آن گرفته شده است.

آنچه سه مجموعه داده واقعاً شامل می‌شوند

DROID

استانداردترین از بین این سه. یک تجهیزات در همه جا: یک Franka Panda با گریپر Robotiq 2F-85، دو دوربین استریو ZED 2 قابل تنظیم و یک ZED Mini مچی، که با کنترلرهای Meta Quest 2 از راه دور کنترل می‌شود، و از طریق Polymetis با فرکانس 15 Hz در هر دو فضای مفصلی و اند-افکتور فضا ضبط شده است. برچسب‌های زبان بعداً از طریق tasq.ai اضافه شدند، تا سه برچسب برای هر اپیزود.

• 76 هزار مسیر، 350 ساعت، 564 صحنه، 84 وظیفه، 50 جمع‌آوری‌کننده در سه قاره.
• نتیجه اصلی، آموزش مشترک است، نه آموزش مستقل: دسته‌هایی که 50/50 با نمایش‌های درون‌دامنه ترکیب شده‌اند، بهترین روش بعدی را با 22 درصد موفقیت مطلق در توزیع و 17 درصد خارج از آن شکست دادند.
• IPEC-COMMUNITY/droid_lerobot: 92,233 اپیزود، 27,044,326 فریم، فرانک، 15 فریم بر ثانیه، نسخه کد v2.0، سه جریان AV1 با ابعاد 180x320، 392 گیگابایت.
• یک نمونه اشکال‌زدایی 2 گیگابایتی و 100 اپیزودی در gs://gresearch/robotics/droid_100 قرار دارد. از آنجا شروع کنید.

BridgeData V2

نزدیک‌ترین به یک راه‌اندازی سرگرمی: یک بازوی WidowX 250 با 6 درجه آزادی، 60,096 مسیر در 24 محیط و 13 مهارت با فرکانس 5 هرتز. به ترکیب توجه کنید: 50,365 نمایش تله‌اپراتوری تخصصی به علاوه 9,731 از یک سیاست تصادفی اسکریپت‌شده برای برداشتن و قرار دادن، بنابراین حدود 16 درصد نمایش انسانی نیست، که برای یادگیری تقلیدی کیفیت اهمیت دارد. دانلود معمول، IPEC-COMMUNITY/bridge_orig_lerobot، 53,192 اپیزود و 1,893,026 فریم را با 5 فریم بر ثانیه گزارش می‌دهد، نوع ربات widowx: کمتر از 60,096 مورد مقاله، بنابراین تعداد را از meta/info.json بخوانید تا اینکه به هر یک از آنها استناد کنید.

Open X-Embodiment

نه یک مجموعه داده به همان معنا: 60 مجموعه داده ربات موجود از 34 آزمایشگاه در یک مجموعه RLDS گردآوری شده‌اند که 22 تجسم و بیش از یک میلیون مسیر را پوشش می‌دهد. BridgeData V2 به عنوان bridge_orig در آن قرار دارد؛ برش google_robot، fractal20220817_data، به 87,212 اپیزود با سرعت 3 فریم بر ثانیه تبدیل می‌شود.

این گردآوری یک هشدار دارد که مقاله به صراحت بیان می‌کند. برای آزمایش‌های RT-X، نویسندگان هر منبع را به یک عمل 7-DoF اند-افکتور تبدیل می‌کنند، اما فریم‌های مختصات را در بین مجموعه‌های داده هم‌تراز نمی‌کنند و اجازه می‌دهند مقادیر عمل، موقعیت‌های مطلق یا نسبی یا سرعت‌ها باشند، مطابق با طرح کنترل اصلی هر ربات. نتیجه‌گیری آن‌ها: یک بردار عمل مشابه ممکن است حرکات بسیار متفاوتی را برای ربات‌های مختلف ایجاد کند.

عدم تطابق، در چهار بخش

عدم تطابق تجسم معمولاً به عنوان یک مشکل مبهم در نظر گرفته می‌شود. این چهار مورد است، آنها به روش‌های متفاوتی شکست می‌خورند، و دو مورد با اسکریپت‌نویسی قابل رفع نیستند.

۱. درجات آزادی

یک SO-100 دارای پنج مفصل بازو به علاوه یک گریپر است. اگر به عنوان موتور شمارش شود، یک بازوی 6-DoF است، و مقاله SmolVLA آن را اینگونه می‌نامد؛ اگر به عنوان یک مکانیزم موقعیت‌یابی شمارش شود، 5-DoF است، و LeRobot آن را در docstring سینماتیک معکوس خود اینگونه می‌نامد، که IK جهت‌گیری نرم را بر روی SO-101 5-DOF توصیف می‌کند که در آن مچ دست فقط تا حدی جهت‌گیری را ردیابی می‌کند. یک Franka دارای هفت مفصل موقعیت‌یابی است. این شکاف تعیین می‌کند که کدام ژست‌ها وجود دارند: یک بازوی 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 checkpoint آماده، میانبر نیست. Physical Intelligence مدل pi05_droid را در gs://openpi-assets/checkpoints/pi05_droid ارائه می‌دهد و همان README که گستردگی آن را ستایش می‌کند، هشدار می‌دهد که این checkpointهای تخصصی ممکن است برای تنظیمات شما قابل تعمیم نباشند. وضعیت آن هشت عدد مفصل Franka است و کلیدهای تصویر آن exterior_image_1_left و wrist_image_left هستند. هیچ فِلَگی آن را به یک فرمان SO-100 شش موتوره تبدیل نمی‌کند.

۲. بردار عمل در واقع چه می‌گوید

عمیق‌تر از ابعاد. در تبدیل‌های LeRobot، هر سه می‌گویند که گریپر باید به کجا برود، در فضای دکارتی. یک SO-100 می‌گوید که شش سروو باید به کجا بروند. تبدیل کردن به یک مدل کینماتیک و یک حل‌کننده نیاز دارد، نه یک تغییر شکل (reshape).

LeRobot قطعه گمشده را ارائه می‌دهد: دنبال‌کننده SO دارای یک پردازشگر کینماتیک با مراحل InverseKinematicsEEToJoints و ForwardKinematicsJointsToEE است. کلیدهای آن ee.x، ee.y، ee.z به علاوه یک بردار چرخش ee.wx، ee.wy، ee.wz و ee.gripper_pos هستند، بنابراین حتی کدگذاری جهت‌گیری نیز با roll-pitch-yaw در فایل‌ها متفاوت است. مرحله IK یک orientation_weight می‌گیرد، پیش‌فرض 0.01، که docstring آن می‌گوید برای IK فقط موقعیت در بازوهای با تحریک ناکافی، آن را 0.0 تنظیم کنید. شما می‌توانید پل را بسازید، اما نیمه جهت‌گیری هر عمل قرض گرفته شده تقریبی باقی می‌ماند.

3. نرخ کنترل

DROID 15 هرتز، BridgeData V2 5 هرتز، برش google_robot 3 فریم بر ثانیه است؛ نویسندگان pi0 بخش متن‌باز ترکیب خود را به عنوان کنترل با فرکانس پایین بین 2 تا 10 هرتز توصیف می‌کنند. DatasetRecordConfig در LeRobot به طور پیش‌فرض fps 30، episode_time_s 60، reset_time_s 60، num_episodes 50 است. یک آموزش‌دیده بر روی داده‌های 5 هرتز یاد گرفت که یک عمل 200 میلی‌ثانیه را پوشش می‌دهد. آن را با 30 هرتز بازپخش کنید و بازو به آرامی حرکت می‌کند؛ به طور ساده بازنمونه‌برداری کنید و فریمی که گریپر بسته می‌شود را تار می‌کنید. همچنین با به خوبی تعامل نمی‌کند: یک قطعه 100-مرحله‌ای در 5 هرتز 20 ثانیه و در 30 هرتز 3.3 ثانیه است.

4. دوربین‌ها

BridgeData V2 هر ۵۰ مسیر، دو وضعیت دوربین را تصادفی کرد و صفحه پروژه آن اشاره می‌کند که بیشتر داده‌ها به هر حال فقط نمای ثابت را حمل می‌کنند. DROID از پایه‌های قابل تنظیم ZED 2 به همراه یک ZED Mini مچی استفاده کرد. شما دو وب‌کم USB دارید که با چشم قرار داده شده‌اند. وضعیت دوربین یک متغیر مزاحم برای یک ؛ بلکه بخش زیادی از چیزی است که رمزگذار بصری بر آن تمرکز کرده و هیچ چیز در فرمت فایل به شما نمی‌گوید که وضعیت‌ها متفاوت هستند.

چه اتفاقی می‌افتد وقتی به هر حال سعی می‌کنید داده‌ها را ادغام کنید

نقشه واضح این است که آن‌ها را به هم متصل کنیم: چند هزار اپیزود DROID به علاوه ۵۰ اپیزود شما. LeRobot امتناع می‌کند و این امتناع سه تفاوت را نام می‌برد.

1. 1
   نمونه ۱۰۰ اپیزودی را دریافت کنید، نه ۱.۷ ترابایت کامل را

   ۲ گیگابایت برای مشاهده ساختار کافی است.

   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) و ویژگی‌ها را در برابر اولین مورد در لیست بررسی می‌کند و در اولین عدم تطابق خطا می‌دهد.

   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، از ۳۰ فریم بر ثانیه شما شکایت می‌کند. نرخ فریم را اصلاح کنید و به بررسی robot_type می‌رسید؛ آن را اصلاح کنید و به بررسی ویژگی‌ها می‌رسید، ۷ در برابر ۶ برای عمل. هیچ ترتیبی از این بررسی‌ها عبور نمی‌کند و همین محافظ در زمان ضبط از طریق sanity_check_dataset_robot_compatibility اجرا می‌شود.

پس واقعاً چه چیزی منتقل می‌شود؟

وزن‌ها، نه اپیزودها. هر سیاست عمومی مدرن مقداری از آن را در پیش‌آموزش جذب کرده است، و وقتی شما از یک منتشر شده، آن را از قبل توسط افرادی که توان محاسباتی لازم برای انجام صحیح آن را دارند، به ارث می‌برید. مقاله pi0 در مورد نسبت آن صریح است: 9.1 درصد از ترکیب پیش‌آموزش آن، که بر حسب گام‌های زمانی شمارش می‌شود، داده‌های منبع باز شامل OXE، Bridge v2 و DROID است. این رقم مربوط به pi0 است؛ ترکیب هر فروشنده متفاوت است.

به همین دلیل SmolVLA روی یک بازوی کم‌هزینه متفاوت عمل می‌کند. مقاله آن ۴۸۱ مجموعه داده جامعه را از Hugging Face انتخاب می‌کند که بر اساس نوع تجسم، تعداد اپیزود، کیفیت داده و پوشش فریم فیلتر شده‌اند: ۲۲.۹ هزار اپیزود، ۱۰.۶ میلیون فریم، که روی بازوهای واقعی SO-100 و SO-101 ارزیابی شده‌اند. کوچک و منطبق بر بزرگ و نامنطبق برتری دارد. مقایسه کنید در ACT against SmolVLA.

سه مسیر ارزشمند

مسیر A: تنظیم دقیق از یک نقطه بازرسی که قبلاً داده‌ها را جذب کرده است

اکثر مردم باید این مسیر را انتخاب کنند. شما هرگز DROID یا Open X-Embodiment را لمس نمی‌کنید: یک سیاست را انتخاب کنید که پیش‌آموزش آن قبلاً داده‌های بین‌تجسمی را جذب کرده باشد، اپیزودهای خود را ضبط کنید، و تنظیم دقیق انجام دهید.

ACT یک مورد خاص صادقانه است: بدون مدل پایه، بنابراین هیچ یک از داده‌های عمومی هرگز به آن نمی‌رسد. این به طور خودکار یک نقطه ضعف نیست، زیرا با 20 میلی‌ثانیه در هر گام عملیاتی، تنها یکی از این پنج مورد است که می‌تواند یک حلقه سریع را ببندد، همانطور که صفحه ACT توضیح می‌دهد. بر اساس وظیفه با استفاده از مقایسه هر پنج مورد، GR00T N1.7 در برابر Pi0.5، و 332 نتیجه بنچمارک در 85 مدل در آرنا انتخاب کنید.

مسیر B: استفاده از DROID به عنوان یک ابزار تست

نمونه 100-اپیزودی بهترین 2 GB است که این ماه دانلود خواهید کرد، و نه برای آموزش. این یک مجموعه داده است که می‌دانید صحیح است. مبدل، لودر و یک کار کوتاه GPU خود را روی آن اجرا کنید؛ هر چیزی که شکست بخورد یک باگ زیرساختی است که در زمانی که ارزان بود پیدا شده است. NVIDIA همین کار را در مقیاس انجام می‌دهد: کارت GR00T N1.7 چهار نوع پس از آموزش را برای Bridge و Fractal در SimplerEnv، DROID و LIBERO فهرست می‌کند.

مسیر C: داده‌های خود را عمداً ضبط کنید

سی تا پنجاه در کنار ۷۶,۰۰۰ کم به نظر می‌رسد، تا زمانی که به یاد بیاورید داده‌های شما تنها مواردی هستند که با بازو، دوربین‌ها و میز شما مطابقت دارند. با تنظیمات پیش‌فرض LeRobot، پنجاه اپیزود معادل ۱۰۰ دقیقه زمان واقعی است. به ، و .

دو روش برای رسیدن از داده‌های عمومی به یک سیاست عملیاتی

هزینه هر مسیر

عدم تقارن نکته اصلی است: مسیری که بیشترین داده را قرض می‌گیرد، پرهزینه‌ترین و کمترین احتمال را برای حرکت بازوی شما دارد. کمتر از دو ساعت از تله‌اپریشن شما یک ترابایت از فرانکای شخص دیگری را شکست می‌دهد. هنوز بازو ندارید؟ /live یک SO-100 فیزیکی را بدون نیاز به ثبت‌نام پخش می‌کند. سپس اولین سیاست خود را آموزش دهید، و SmolVLA روی SO-100 برای راهنمای خاص.