การใช้ DROID, BridgeData V2 และ Open X บน SO-100

มีชุดข้อมูลสาธารณะขนาดหนึ่งล้านวิถีการเคลื่อนที่อยู่บน Google Cloud bucket และ SO-100 อยู่บนโต๊ะซึ่งมีราคาชิ้นส่วน 110 ถึง 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 สูงสุดสามป้ายต่อ ตอน.

• 76k วิถีการเคลื่อนที่, 350 ชั่วโมง, 564 ฉาก, 84 งาน, 50 ผู้รวบรวมข้อมูลในสามทวีป
• ผลลัพธ์หลักคือการฝึกร่วม (co-training) ไม่ใช่การฝึกแบบเดี่ยว (standalone training): ชุดข้อมูลที่ผสม 50/50 กับการสาธิตในโดเมนเอาชนะวิธีที่ดีที่สุดถัดไปได้ถึง 22 เปอร์เซ็นต์ของความสำเร็จสัมบูรณ์ในการกระจายข้อมูล และ 17 เปอร์เซ็นต์นอกการกระจายข้อมูล
• IPEC-COMMUNITY/droid_lerobot: 92,233 ตอน, 27,044,326 เฟรม, franka, 15 fps, codebase_version v2.0, สตรีม AV1 สามรายการที่ 180x320, 392 GB.
• ตัวอย่างการดีบักขนาด 2 GB จำนวน 100 ตอนอยู่ที่ gs://gresearch/robotics/droid_100 เริ่มต้นจากตรงนั้นได้เลย

BridgeData V2

ใกล้เคียงกับการตั้งค่าสำหรับงานอดิเรกมากที่สุด: แขนหุ่นยนต์ WidowX 250 แบบ 6-DoF, 60,096 วิถีการเคลื่อนที่ใน 24 สภาพแวดล้อมและ 13 ทักษะที่ 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

ไม่ใช่ชุดข้อมูลในความหมายเดียวกัน: ชุดข้อมูลหุ่นยนต์ที่มีอยู่ 60 ชุดจาก 34 ห้องปฏิบัติการถูกรวบรวมไว้ในคอลเลกชัน RLDS เดียว ครอบคลุม 22 รูปแบบการใช้งานและวิถีการเคลื่อนที่กว่าหนึ่งล้านครั้ง BridgeData V2 อยู่ภายในนั้นในชื่อ bridge_orig; ส่วน google_robot, fractal20220817_data, แปลงเป็น 87,212 ตอนที่ 3 เฟรมต่อวินาที

การรวบรวมข้อมูลนี้มีข้อควรระวังที่ระบุไว้อย่างชัดเจนในเอกสาร สำหรับการทดลอง RT-X ผู้เขียนแปลงแต่ละแหล่งข้อมูลเป็นการกระทำของปลายแขนกลแบบ 7-DoF แต่ไม่ได้จัดแนวเฟรมพิกัดระหว่างชุดข้อมูล และอนุญาตให้ค่าการกระทำเป็นตำแหน่งสัมบูรณ์หรือสัมพัทธ์ หรือความเร็ว ตามแผนการควบคุมดั้งเดิมของหุ่นยนต์แต่ละตัว ข้อสรุปของพวกเขา: เวกเตอร์การกระทำเดียวกันอาจทำให้เกิดการเคลื่อนไหวที่แตกต่างกันมากสำหรับหุ่นยนต์แต่ละตัว

ความไม่ตรงกัน ในสี่ส่วน

ความไม่ตรงกันของกายภาพมักถูกมองว่าเป็นปัญหาคลุมเครือเพียงปัญหาเดียว แต่แท้จริงแล้วมีสี่ประการ ซึ่งแต่ละประการล้มเหลวต่างกัน และสองประการไม่สามารถแก้ไขได้ด้วยการเขียนสคริปต์

1. องศาอิสระ

หุ่นยนต์ SO-100 มีข้อต่อแขนห้าข้อบวกกับกริปเปอร์ เมื่อนับเป็นมอเตอร์ จะเป็นแขน 6-DoF และเอกสาร SmolVLA ก็เรียกเช่นนั้น; เมื่อนับเป็นกลไกการวางตำแหน่ง จะเป็น 5-DoF และ LeRobot ก็เรียกเช่นนั้นใน docstring ของ inverse-kinematics ซึ่งอธิบาย IK แบบ soft-orientation บน 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 เดียวกันที่ยกย่องความครอบคลุมของมันก็เตือนว่า expert checkpoint เหล่านี้อาจไม่สามารถนำไปใช้กับระบบของคุณได้ สถานะของมันคือตัวเลขข้อต่อ Franka แปดตัว และคีย์รูปภาพของมันคือ exterior_image_1_left และ wrist_image_left ไม่มี flag ใดที่เปลี่ยนสิ่งนั้นให้เป็นคำสั่ง SO-100 แบบหกมอเตอร์ได้

2. สิ่งที่ action vector บอกจริงๆ

ลึกซึ้งกว่ามิติ ในการแปลง LeRobot ทั้งสามตัวระบุว่า gripper ควรไปที่ใดในพื้นที่ Cartesian SO-100 ระบุว่าเซอร์โวหกตัวควรไปที่ใด การแปลงต้องใช้ kinematic model และ solver ไม่ใช่การปรับรูปร่างใหม่

LeRobot มีส่วนที่ขาดหายไป: SO follower มีโปรเซสเซอร์จลนศาสตร์ที่มีขั้นตอน 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 ระบุให้ตั้งค่าเป็น 0.0 สำหรับ IK เฉพาะตำแหน่งบนแขนกลที่ควบคุมได้ไม่เต็มที่ คุณสามารถสร้างสะพานเชื่อมได้ แต่ครึ่งหนึ่งของแอคชันที่ยืมมาซึ่งเกี่ยวข้องกับทิศทางจะยังคงเป็นการประมาณค่า

3. อัตราการควบคุม

DROID ทำงานที่ 15 Hz, BridgeData V2 ที่ 5 Hz, ส่วน google_robot ที่ 3 fps; ผู้เขียน pi0 อธิบายส่วนโอเพนซอร์สของส่วนผสมของพวกเขาว่าเป็นการควบคุมความถี่ต่ำระหว่าง 2 ถึง 10 Hz DatasetRecordConfig ของ LeRobot มีค่าเริ่มต้นเป็น fps 30, episode_time_s 60, reset_time_s 60, num_episodes 50 ที่ฝึกด้วยข้อมูล 5 Hz เรียนรู้ว่าหนึ่งแอคชันครอบคลุม 200 ms หากเล่นซ้ำที่ 30 Hz แขนกลจะเคลื่อนที่ช้ามาก; หากสุ่มตัวอย่างใหม่แบบง่ายๆ คุณจะทำให้เฟรมที่กริปเปอร์ปิดเบลอ นอกจากนี้ยังทำงานได้ไม่ดีกับ : ส่วน 100 ขั้นตอนคือ 20 วินาทีที่ 5 Hz และ 3.3 วินาทีที่ 30 Hz

4. กล้อง

BridgeData V2 สุ่มตำแหน่งกล้องสองตำแหน่งทุกๆ 50 วิถี และหน้าโปรเจกต์ของมันระบุว่าข้อมูลส่วนใหญ่มีเพียงมุมมองคงที่อยู่แล้ว DROID ใช้ฐานยึด ZED 2 ที่ปรับได้พร้อมกับ ZED Mini ที่ข้อมือ คุณมีเว็บแคม USB สองตัวที่จัดตำแหน่งด้วยสายตา ตำแหน่งกล้องไม่ใช่ตัวแปรที่ก่อกวนสำหรับ ; มันเป็นส่วนสำคัญที่ตัวเข้ารหัสภาพใช้ และไม่มีอะไรในรูปแบบไฟล์ที่บอกคุณว่าตำแหน่งแตกต่างกัน

จะเกิดอะไรขึ้นเมื่อคุณพยายามรวมข้อมูลอยู่ดี

แผนที่ชัดเจนคือการรวม: DROID หลายพันตอนบวกกับ 50 ตอนของคุณ LeRobot ปฏิเสธ และการปฏิเสธนั้นระบุสามสิ่งที่แตกต่างกัน

1. 1
   ดึงตัวอย่าง 100 ตอน ไม่ใช่ 1.7 TB เต็ม

   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 และ 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.

ค่าอ้างอิงมาจากชุดข้อมูลใดก็ตามที่คุณระบุไว้เป็นอันดับแรก ซึ่งเป็นเหตุผลที่ข้อความบ่นเกี่ยวกับ 30 fps ของคุณแทนที่จะเป็น 15 fps ของ DROID แก้ไข fps แล้วคุณจะเจอการตรวจสอบ robot_type แก้ไขสิ่งนั้นแล้วคุณจะเจอการตรวจสอบ feature โดย 7 เทียบกับ 6 สำหรับ action ไม่มีลำดับใดผ่านไปได้ และการป้องกันเดียวกันนี้จะทำงานในเวลาบันทึกผ่าน sanity_check_dataset_robot_compatibility

แล้วอะไรที่ถ่ายทอดได้จริงบ้าง?

น้ำหนักโมเดล ไม่ใช่ตอนการเรียนรู้ นโยบายทั่วไปที่ทันสมัยทุกตัวได้ดูดซับบางส่วนของการเรียนรู้ล่วงหน้า และเมื่อคุณ จากที่เผยแพร่ออกมา คุณจะได้รับมรดกที่ได้รับการปรับปรุงแก้ไขแล้วโดยผู้ที่มีกำลังประมวลผลเพียงพอที่จะทำได้อย่างถูกต้อง เอกสารของ pi0 เปิดเผยสัดส่วนอย่างตรงไปตรงมา: 9.1 เปอร์เซ็นต์ของส่วนผสมการเรียนรู้ล่วงหน้า ซึ่งนับเป็นไทม์สเต็ป เป็นข้อมูลโอเพนซอร์ส รวมถึง OXE, Bridge v2 และ DROID ตัวเลขนี้เป็นของ pi0; ส่วนผสมของผู้จำหน่ายแต่ละรายจะแตกต่างกันไป

นี่คือเหตุผลว่าทำไม SmolVLA จึงทำงานแตกต่างกันบนแขนกลราคาประหยัด งานวิจัยของมันเลือกชุดข้อมูลชุมชน 481 ชุดจาก Hugging Face โดยกรองตามประเภทของตัวหุ่นยนต์ จำนวนตอน คุณภาพข้อมูล และความครอบคลุมของเฟรม: 22.9K ตอน, 10.6M เฟรม, ประเมินผลบนแขนกล SO-100 และ SO-101 จริง ขนาดเล็กและตรงกันดีกว่าขนาดใหญ่และไม่ตรงกัน เปรียบเทียบกับ ACT เทียบกับ 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: บันทึกข้อมูลของคุณเองอย่างตั้งใจ

สามสิบถึงห้าสิบ อาจดูน้อยเมื่อเทียบกับ 76,000 จนกว่าคุณจะจำได้ว่าข้อมูลของคุณเป็นชุดเดียวที่มีแขนกล กล้อง และโต๊ะของคุณ ตามค่าเริ่มต้นของ LeRobot, 50 ตอนใช้เวลาจริง 100 นาที ดู , และ .

สองวิธีในการเปลี่ยนจากข้อมูลสาธารณะไปสู่นโยบายที่ใช้งานได้จริง

ค่าใช้จ่ายของแต่ละเส้นทาง

ความไม่สมมาตรคือประเด็นสำคัญ: เส้นทางที่ยืมข้อมูลมากที่สุดคือเส้นทางที่แพงที่สุดและมีโอกาสน้อยที่สุดที่จะขยับแขนของคุณ การใช้เวลาไม่ถึงสองชั่วโมงในการทำ การควบคุมระยะไกล ดีกว่าข้อมูล Franka ของคนอื่นเป็นเทราไบต์ ยังไม่มีแขนหุ่นยนต์ใช่ไหม? /live สตรีม SO-100 จริงโดยไม่ต้องลงทะเบียน จากนั้น ฝึกนโยบายแรกของคุณ, และ SmolVLA บน SO-100 สำหรับคู่มือเฉพาะ