SO-100 वर DROID, BridgeData V2 आणि Open X वापरणे

Google Cloud बकेटवर एक दशलक्ष-ट्रॅजेक्टरी सार्वजनिक डेटासेट आहे आणि एक SO-100 डेस्कवर आहे ज्याला भागांमध्ये 110 ते 150 EUR खर्च आला. पहिले दुसऱ्याला का शिकवू शकत नाही? ते अंशतः शिकवू शकते, परंतु अपेक्षित ठिकाणी जवळजवळ कोणतेही हस्तांतरण होत नाही आणि जो भाग सर्वात सोपा दिसतो तो अजिबात काम करत नाही.

पुढे काय आहे: आत काय आहे DROID, BridgeData V2 आणि Open X-Embodiment, जिथे प्रत्येक कमी किमतीच्या 5-DoF आर्मशी टक्कर देतो आणि त्याऐवजी काय करावे. खालील प्रत्येक संख्या संबंधित पेपर, डेटासेट कार्ड किंवा सोर्स फाइलमधून आली आहे.

तीन डेटासेटमध्ये प्रत्यक्षात काय आहे

DROID

तिघांपैकी सर्वात प्रमाणित. सर्वत्र एकच रिग: Robotiq 2F-85 ग्रिपरसह एक Franka Panda, दोन समायोज्य ZED 2 स्टिरिओ कॅमेरे आणि एक मनगट ZED Mini, Meta Quest 2 कंट्रोलरसह दूरनियंत्रित, Polymetis द्वारे 15 Hz वर जॉइंट आणि एंड-इफेक्टर स्पेसमध्ये. भाषेचे लेबल्स नंतर tasq.ai द्वारे आले, प्रति भाग.

• 76k ट्रॅजेक्टरीज, 350 तास, 564 सीन्स, 84 टास्क, तीन खंडांमध्ये 50 कलेक्टर्स.
• मुख्य निष्कर्ष सह-प्रशिक्षण आहे, स्वतंत्र प्रशिक्षण नाही: इन-डोमेन प्रात्यक्षिकांसह 50/50 मिसळलेल्या बॅचेसने वितरणात 22 टक्के आणि त्याबाहेर 17 टक्के निरपेक्ष यश मिळवून पुढील सर्वोत्तम पद्धतीला हरवले.
• IPEC-COMMUNITY/droid_lerobot: 92,233 episodes, 27,044,326 frames, franka, 15 fps, codebase_version v2.0, three AV1 streams at 180x320, 392 GB.
• 2 GB चा, 100-एपिसोडचा डीबगिंग नमुना gs://gresearch/robotics/droid_100 येथे आहे. तेथून सुरुवात करा.

ब्रिजडेटा V2

हॉबी सेटअपच्या सर्वात जवळ: एक WidowX 250 6-DoF आर्म, 24 वातावरणांमध्ये आणि 13 कौशल्यांमध्ये 5 Hz वर 60,096 ट्रॅजेक्टरीज. रचना लक्षात घ्या: 50,365 तज्ञ टेलिऑपरेटेड प्रात्यक्षिके अधिक 9,731 यादृच्छिक स्क्रिप्टेड पिक-अँड-प्लेस पॉलिसीमधून, त्यामुळे सुमारे 16 टक्के मानवी प्रात्यक्षिक नाही, जे महत्त्वाचे आहे अनुकरण शिक्षण गुणवत्तेसाठी. नेहमीचे डाउनलोड, IPEC-COMMUNITY/bridge_orig_lerobot, 5 fps वर 53,192 एपिसोड्स आणि 1,893,026 फ्रेम्स, robot_type widowx: पेपरमधील 60,096 पेक्षा कमी, त्यामुळे दोन्हीपैकी कोणताही उद्धृत करण्याऐवजी meta/info.json मधून संख्या वाचा.

ओपन एक्स-एम्बॉडमेंट

त्याच अर्थाने हा डेटासेट नाही: 34 लॅबमधील 60 विद्यमान रोबोट डेटासेट एका RLDS संकलनात एकत्र केले गेले आहेत, ज्यात 22 एम्बॉडीमेंट्स आणि दहा लाखांहून अधिक ट्रॅजेक्टरीज समाविष्ट आहेत. BridgeData V2 त्यात bridge_orig म्हणून समाविष्ट आहे; google_robot स्लाइस, fractal20220817_data, 3 fps वर 87,212 एपिसोडमध्ये रूपांतरित होते.

या एकत्रीकरणामध्ये एक चेतावणी आहे जी पेपरमध्ये स्पष्टपणे नमूद केली आहे. RT-X प्रयोगांसाठी लेखकांनी प्रत्येक स्त्रोताला 7-DoF एंड-इफेक्टर ॲक्शनमध्ये रूपांतरित केले आहे, परंतु डेटासेटमधील समन्वय फ्रेम्स संरेखित केल्या नाहीत आणि प्रत्येक रोबोटच्या मूळ नियंत्रण योजनेनुसार ॲक्शन व्हॅल्यूजला निरपेक्ष किंवा सापेक्ष पोझिशन्स किंवा वेगांमध्ये राहण्याची परवानगी दिली आहे. त्यांचे निष्कर्ष: समान ॲक्शन वेक्टर वेगवेगळ्या रोबोट्ससाठी खूप भिन्न हालचाली निर्माण करू शकतो.

चार भागांमध्ये विसंगती

एम्बॉडिमंट मिसमॅचला सामान्यतः एक अस्पष्ट समस्या मानले जाते. ती चार प्रकारची आहे, ते वेगवेगळ्या प्रकारे अयशस्वी होतात आणि त्यापैकी दोन स्क्रिप्टिंगद्वारे दुरुस्त करता येत नाहीत.

1. स्वातंत्र्याच्या अंशांची संख्या

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 आहेत, त्यामुळे ओरिएंटेशन एन्कोडिंग देखील फाइल्समधील रोल-पिच-यावपेक्षा वेगळे आहे. IK स्टेप एक orientation_weight घेते, डीफॉल्ट 0.01, ज्याच्या डॉकस्ट्रिंगमध्ये असे म्हटले आहे की अंडर-ॲक्टुएटेड आर्म्सवर केवळ पोझिशन-ओन्ली 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 मिनी वापरले. तुमच्याकडे डोळ्यांनी पोझिशन केलेले दोन USB वेबकॅम आहेत. कॅमेरा पोझ हे त्रासदायक व्हेरिएबल नाही ; कारण व्हिज्युअल एन्कोडरने त्यावरच लक्ष केंद्रित केले होते, आणि फाइल फॉरमॅटमध्ये पोझ भिन्न आहेत असे काहीही सांगितले जात नाही.

तुम्ही डेटा विलीन करण्याचा प्रयत्न केल्यास काय होते

स्पष्ट योजना अशी आहे की काही हजार DROID एपिसोड्स आणि तुमचे ५० एपिसोड्स एकत्र जोडणे. LeRobot नकार देतो, आणि या नकारामागे तीन भिन्न गोष्टींची नावे आहेत.

1. 1
   संपूर्ण १.७ TB ऐवजी १००-एपिसोडचा नमुना खेचा

   संरचना पाहण्यासाठी २ 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 मानक परिवर्तनांना समाविष्ट करते आणि रोबोटचा प्रकार व नियंत्रण वारंवारता (control frequency) नोंदवते. 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) करून पहा आणि त्रुटी वाचा

   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 च्या १५ fps ऐवजी तुमच्या ३० fps बद्दल तक्रार करतो. fps दुरुस्त करा आणि तुम्हाला robot_type तपासणीचा सामना करावा लागेल; ते दुरुस्त करा आणि तुम्हाला वैशिष्ट्य तपासणीचा सामना करावा लागेल, कृतीसाठी (action) ७ विरुद्ध ६. कोणतीही क्रमवारी यशस्वी होत नाही, आणि sanity_check_dataset_robot_compatibility द्वारे रेकॉर्ड करताना तेच संरक्षण (guard) चालते.

मग प्रत्यक्षात काय हस्तांतरित होते?

वजन, भाग नाही. प्रत्येक आधुनिक सामान्यवादी धोरणाने पूर्व-प्रशिक्षणात काही भाग शोषून घेतला आहे, आणि जेव्हा तुम्ही रिलीझ केलेल्या मधून वारसा मिळवता, तेव्हा ते योग्यरित्या करण्यासाठी आवश्यक संगणकीय शक्ती असलेल्या लोकांनी ते आधीच जुळवून घेतलेले असते. pi0 च्या पेपरमध्ये प्रमाणाबद्दल स्पष्टपणे सांगितले आहे: त्याच्या पूर्व-प्रशिक्षण मिश्रणाचा 9.1 टक्के भाग, टाइमस्टेप्समध्ये मोजला जातो, तो OXE, Bridge v2 आणि DROID सह ओपन-सोर्स डेटा आहे. ही आकडेवारी pi0 ची आहे; प्रत्येक विक्रेत्याचे मिश्रण वेगळे असते.

यामुळेच SmolVLA कमी किमतीच्या आर्मवर वेगळ्या पद्धतीने कार्य करते. त्याच्या पेपरमध्ये Hugging Face मधून 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 विशिष्ट मार्गदर्शनासाठी.