DROID، BridgeData V2 اور Open X کا SO-100 پر استعمال

گوگل کلاؤڈ بکٹ پر ایک ملین ٹراجیکٹری کا عوامی ڈیٹا سیٹ موجود ہے اور ڈیسک پر ایک SO-100 ہے جس کے پرزوں کی لاگت 110 سے 150 EUR آئی تھی۔ پہلا دوسرے کو کیوں نہیں سکھا سکتا؟ یہ جزوی طور پر سکھا سکتا ہے، لیکن تقریباً کوئی بھی منتقلی وہاں نہیں ہوتی جہاں لوگ توقع کرتے ہیں، اور وہ حصہ جو سب سے آسان لگتا ہے وہ بالکل کام نہیں کرتا۔

مندرجہ ذیل: DROID، BridgeData V2 اور Open X-Embodiment کے اندر کیا ہے، جہاں ہر ایک کم لاگت والے 5-DoF بازو سے ٹکراتا ہے، اور اس کے بجائے کیا کرنا ہے۔ نیچے دیا گیا ہر نمبر اس کاغذ، ڈیٹا سیٹ کارڈ یا سورس فائل سے آیا ہے جس سے اس کا تعلق ہے۔

تینوں ڈیٹا سیٹس میں دراصل کیا شامل ہے

DROID

تینوں میں سب سے زیادہ معیاری۔ ہر جگہ ایک ہی رگ: ایک فرینکا پانڈا جس میں روبوٹک 2F-85 گریپر، دو ایڈجسٹ ایبل ZED 2 سٹیریو کیمرے اور ایک کلائی ZED منی، میٹا کویسٹ 2 کنٹرولرز کے ساتھ ٹیلی آپریٹڈ، پولیمیٹس کے ذریعے 15 ہرٹز پر جوائنٹ اور اینڈ-ایفیکٹر اسپیس دونوں میں ریکارڈ کیا گیا۔ زبان کے لیبل بعد میں tasq.ai کے ذریعے آئے، فی ایپیسوڈ۔

• 76k ٹراجیکٹریز، 350 گھنٹے، 564 مناظر، 84 کام، تین براعظموں پر 50 کلیکٹرز۔
• سرخی کا نتیجہ مشترکہ تربیت ہے، نہ کہ اکیلی تربیت: ان-ڈومین مظاہروں کے ساتھ 50/50 کے تناسب سے ملے ہوئے بیچز نے اگلے بہترین طریقہ کار کو تقسیم میں 22 فیصد اور اس سے باہر 17 فیصد مطلق کامیابی سے شکست دی۔
• IPEC-COMMUNITY/droid_lerobot: 92,233 ایپی سوڈز، 27,044,326 فریمز، فرینکا، 15 fps، codebase_version v2.0، 180x320 پر تین AV1 سٹریمز، 392 GB۔
• ایک 2 GB، 100-ایپی سوڈ ڈیبگنگ نمونہ gs://gresearch/robotics/droid_100 پر موجود ہے۔ وہاں سے شروع کریں۔

BridgeData V2

ایک شوقیہ سیٹ اپ کے قریب ترین: ایک WidowX 250 6-DoF بازو، 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 موجودہ روبوٹ ڈیٹا سیٹس کو ایک RLDS کلیکشن میں جمع کیا گیا جو 22 ایمباڈیمنٹس اور دس لاکھ سے زیادہ ٹراجیکٹریز کا احاطہ کرتا ہے۔ BridgeData V2 اس کے اندر bridge_orig کے طور پر موجود ہے؛ google_robot سلائس، fractal20220817_data، 3 fps پر 87,212 ایپی سوڈز میں تبدیل ہوتا ہے۔

اس پولنگ میں ایک انتباہ شامل ہے جسے مقالے میں واضح طور پر بیان کیا گیا ہے۔ RT-X تجربات کے لیے مصنفین ہر سورس کو 7-DoF اینڈ-ایفیکٹر ایکشن میں تبدیل کرتے ہیں، لیکن ڈیٹا سیٹس کے درمیان کوآرڈینیٹ فریمز کو سیدھ میں نہیں لاتے، اور ہر روبوٹ کی اصل کنٹرول اسکیم کے مطابق ایکشن ویلیوز کو مطلق یا نسبتی پوزیشنز یا ویلوسٹیز ہونے کی اجازت دیتے ہیں۔ ان کا نتیجہ: ایک ہی ایکشن ویکٹر مختلف روبوٹس کے لیے بہت مختلف حرکات پیدا کر سکتا ہے۔

عدم مطابقت، چار حصوں میں

ایمباڈیمنٹ کی عدم مطابقت کو عام طور پر ایک مبہم مسئلہ سمجھا جاتا ہے۔ یہ چار ہیں، وہ مختلف طریقے سے ناکام ہوتے ہیں، اور دو کو اسکرپٹنگ کے ذریعے ٹھیک نہیں کیا جا سکتا۔

آزادی کی ڈگریاں

ایک SO-100 میں پانچ بازو کے جوڑ اور ایک گریپر ہوتا ہے۔ موٹرز کے طور پر شمار کیا جائے تو یہ ایک 6-DoF بازو ہے، اور SmolVLA پیپر اسے یہی کہتا ہے؛ پوزیشننگ میکانزم کے طور پر شمار کیا جائے تو یہ 5-DoF ہے، اور LeRobot اسے اپنی انورس-کائنیمیٹکس ڈاکسٹرنگ میں یہی کہتا ہے، جو 5-DOF SO-101 پر نرم-اورینٹیشن IK کو بیان کرتا ہے جہاں کلائی صرف جزوی طور پر اورینٹیشن کو ٹریک کرتی ہے۔ ایک فرینکا میں سات پوزیشننگ جوڑ ہوتے ہیں۔ یہ فرق فیصلہ کرتا ہے کہ کون سی پوز موجود ہیں: ایک 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 چیک پوائنٹ کوئی شارٹ کٹ نہیں ہے۔ فزیکل انٹیلی جنس pi05_droid کو gs://openpi-assets/checkpoints/pi05_droid پر فراہم کرتا ہے، اور وہی README جو اس کی وسعت کی تعریف کرتا ہے، خبردار کرتا ہے کہ یہ ماہر چیک پوائنٹس آپ کے سیٹ اپ پر عام نہیں ہو سکتے۔ اس کی حالت آٹھ فرینکا جوائنٹ نمبرز ہے اور اس کی تصویری کیز exterior_image_1_left اور wrist_image_left ہیں۔ کوئی فلیگ اسے چھ موٹر SO-100 کمانڈ میں تبدیل نہیں کرتا۔

2. ایکشن ویکٹر دراصل کیا کہتا ہے

جہت سے گہرا۔ LeRobot کی تبدیلیوں میں، تینوں بتاتے ہیں کہ گریپر کو کارٹیشین اسپیس میں کہاں جانا چاہیے۔ ایک SO-100 بتاتا ہے کہ چھ سرووز کو کہاں جانا چاہیے۔ تبدیلی کے لیے ایک کائینیٹک ماڈل اور ایک سالور کی ضرورت ہوتی ہے، نہ کہ ری شیپ کی۔

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 Hz ہے، BridgeData V2 5 Hz ہے، google_robot سلائس 3 fps ہے؛ pi0 کے مصنفین اپنے مکسچر کے اوپن سورس حصے کو 2 اور 10 Hz کے درمیان کم فریکوئنسی کنٹرول کے طور پر بیان کرتے ہیں۔ LeRobot کی DatasetRecordConfig کا ڈیفالٹ fps 30، episode_time_s 60، reset_time_s 60، num_episodes 50 ہے۔ ایک جو 5 Hz ڈیٹا پر تربیت یافتہ ہے، نے سیکھا کہ ایک ایکشن 200 ms کا احاطہ کرتا ہے۔ اسے 30 Hz پر دوبارہ چلائیں تو بازو رینگتا ہے؛ اگر آپ اسے سادہ لوحی سے دوبارہ سیمپل کریں تو آپ اس فریم کو دھندلا دیں گے جہاں گرپر بند ہوتا ہے۔ یہ کے ساتھ بھی بری طرح تعامل کرتا ہے: ایک 100-اسٹیپ چنک 5 Hz پر 20 سیکنڈ اور 30 Hz پر 3.3 سیکنڈ کا ہوتا ہے۔

4. کیمرے

BridgeData V2 نے ہر 50 ٹراجیکٹریز کے بعد دو کیمرہ پوز کو بے ترتیب کیا، اور اس کے پروجیکٹ پیج میں بتایا گیا ہے کہ زیادہ تر ڈیٹا ویسے بھی صرف فکسڈ ویو پر مشتمل ہوتا ہے۔ DROID نے ایڈجسٹ ایبل ZED 2 ماؤنٹس کے علاوہ ایک کلائی ZED Mini استعمال کیا۔ آپ کے پاس دو USB ویب کیمز ہیں جو آنکھوں سے پوزیشن کیے گئے ہیں۔ کیمرہ پوز ایک پریشان کن متغیر نہیں ہے ؛ یہ بہت کچھ ہے جس پر ویژول انکوڈر نے توجہ مرکوز کی تھی، اور فائل فارمیٹ میں کچھ بھی آپ کو نہیں بتاتا کہ پوز مختلف ہیں۔

جب آپ ویسے بھی ڈیٹا کو ضم کرنے کی کوشش کرتے ہیں تو کیا ہوتا ہے

واضح منصوبہ یہ ہے کہ چند ہزار DROID ایپی سوڈز کو آپ کے 50 کے ساتھ جوڑ دیا جائے۔ LeRobot انکار کرتا ہے، اور یہ انکار ان تین چیزوں کا نام لیتا ہے جو مختلف ہیں۔

1. 1
   مکمل 1.7 TB کے بجائے 100 ایپی سوڈ کا نمونہ کھینچیں۔

   ساخت دیکھنے کے لیے 2 GB کافی ہے۔

   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 کے 15 کے بجائے آپ کے 30 fps کے بارے میں شکایت کرتا ہے۔ fps کو ٹھیک کریں اور آپ robot_type کی جانچ پر پہنچ جائیں گے؛ اسے ٹھیک کریں اور آپ فیچر کی جانچ پر پہنچ جائیں گے، ایکشن کے لیے 6 کے مقابلے میں 7۔ کوئی ترتیب کام نہیں کرتی، اور وہی گارڈ ریکارڈ کے وقت sanity_check_dataset_robot_compatibility کے ذریعے چلتا ہے۔

تو اصل میں کیا منتقل ہوتا ہے؟

وزن، نہ کہ ایپی سوڈز۔ ہر جدید عمومی پالیسی نے پری ٹریننگ میں اس کا کچھ حصہ جذب کیا، اور جب آپ ایک جاری کردہ سے کرتے ہیں تو آپ کو یہ پہلے ہی ان لوگوں کے ذریعے حل شدہ حالت میں وراثت میں ملتا ہے جن کے پاس اسے صحیح طریقے سے کرنے کے لیے کمپیوٹ موجود ہے۔ pi0 کا مقالہ اس تناسب کے بارے میں واضح ہے: اس کے پری ٹریننگ مکسچر کا 9.1 فیصد، ٹائم سٹیپس میں شمار کیا گیا، اوپن سورس ڈیٹا ہے جس میں OXE، Bridge v2 اور DROID شامل ہیں۔ یہ اعداد و شمار pi0 کے ہیں؛ ہر وینڈر کا مکسچر مختلف ہوتا ہے۔

یہی وجہ ہے کہ SmolVLA ایک کم لاگت والے بازو پر مختلف طریقے سے برتاؤ کرتا ہے۔ اس کے مقالے میں ہگنگ فیس سے 481 کمیونٹی ڈیٹا سیٹس کا انتخاب کیا گیا ہے، جسے ایمباڈیمنٹ کی قسم، ایپی سوڈ کی تعداد، ڈیٹا کے معیار اور فریم کوریج کے لحاظ سے فلٹر کیا گیا ہے: 22.9K ایپی سوڈز، 10.6M فریمز، جن کا حقیقی SO-100 اور SO-101 بازوؤں پر جائزہ لیا گیا۔ چھوٹا اور مماثل، بڑے اور غیر مماثل سے بہتر ہے۔ موازنہ کریں ACT against SmolVLA۔

تین قابلِ عمل راستے

راستہ A: ایک چیک پوائنٹ سے فائن ٹیون کریں جس نے پہلے ہی ڈیٹا جذب کر لیا ہو

زیادہ تر لوگوں کو یہ راستہ اختیار کرنا چاہیے۔ آپ کبھی DROID یا Open X-Embodiment کو نہیں چھوتے: ایک ایسی پالیسی کا انتخاب کریں جس کی پری ٹریننگ نے پہلے ہی کراس ایمباڈیمنٹ ڈیٹا کو جذب کر لیا ہو، اپنے ایپی سوڈز ریکارڈ کریں، فائن ٹیون کریں۔

ACT ایک ایماندار ایج کیس ہے: کوئی بیس ماڈل نہیں، لہذا کوئی بھی عوامی ڈیٹا اس تک نہیں پہنچتا۔ یہ خود بخود کوئی نقصان نہیں، کیونکہ 20 ms فی ایکشن قدم پر یہ پانچ میں سے واحد ہے جو ایک تیز لوپ کو بند کر سکتا ہے، جیسا کہ ACT صفحہ بیان کرتا ہے۔ کام کے لحاظ سے انتخاب کریں تمام پانچ کا موازنہ، GR00T N1.7 بمقابلہ Pi0.5، اور 85 ماڈلز میں 332 بینچ مارک نتائج ارینا میں۔

راستہ B: DROID کو ٹیسٹ فکسچر کے طور پر استعمال کریں

100 ایپی سوڈ کا نمونہ اس مہینے میں آپ کا ڈاؤن لوڈ کردہ بہترین 2 GB ہے، اور یہ تربیت کے لیے نہیں ہے۔ یہ ایک ایسا ڈیٹا سیٹ ہے جس کے بارے میں آپ جانتے ہیں کہ یہ درست ہے۔ اس پر اپنا کنورٹر، لوڈر اور ایک مختصر GPU جاب چلائیں؛ جو کچھ بھی ناکام ہوتا ہے وہ ایک انفراسٹرکچر بگ ہے جو سستے میں پایا گیا ہے۔ NVIDIA بڑے پیمانے پر بھی ایسا ہی کرتا ہے: GR00T N1.7 کارڈ میں چار پوسٹ ٹرینڈ ویرینٹس درج ہیں، SimplerEnv میں Bridge اور Fractal، DROID اور LIBERO کے لیے۔

پاتھ C: اپنا خود کا، جان بوجھ کر ریکارڈ کریں

تیس سے پچاس 76,000 کے مقابلے میں کم لگتے ہیں جب تک آپ کو یاد نہ ہو کہ آپ کے اپنے بازو، آپ کے کیمرے اور آپ کی میز کے ساتھ صرف آپ کے ہی ہیں۔ LeRobot کی ڈیفالٹس پر، 50 ایپیسوڈز 100 منٹ کی وال کلاک ہیں۔ دیکھیں ، اور .

عوامی ڈیٹا سے ایک فعال پالیسی تک پہنچنے کے دو طریقے

ہر راستے کی لاگت کیا ہے

عدم توازن ہی اصل نکتہ ہے: وہ راستہ جو سب سے زیادہ ڈیٹا لیتا ہے سب سے مہنگا ہے اور آپ کے بازو کو حرکت دینے کا امکان سب سے کم ہے۔ آپ کے اپنے ٹیلی آپریشن کے دو گھنٹے سے کم کسی اور کے فرینکا کے ایک ٹیرا بائٹ سے بہتر ہے۔ ابھی تک کوئی بازو نہیں ہے؟ /live بغیر سائن اپ کے ایک فزیکل SO-100 کو سٹریم کرتا ہے۔ پھر اپنی پہلی پالیسی کی تربیت دیں، اور مخصوص گائیڈ کے لیے SO-100 پر SmolVLA دیکھیں۔