SO-100 पर DAgger लूप चलाना VLA Policy के साथ

आपकी policy चलती है। यह cube तक पहुँचती है, gripper को एक सेंटीमीटर जल्दी बंद करती है, और ऐसे चलती है मानो वह इसे पकड़ गई हो। कोई error नहीं होती, और training loss को देखने से इसकी व्याख्या नहीं होती। fix यह नहीं है कि समान demonstrations पर 20,000 और gradient steps लें। यह है कि अपना हाथ arm पर वहीं वापस रखो जहाँ गलत होता है, record करो कि तुमने इसके बजाय क्या किया, और अगली checkpoint को पुराने data plus इस correction पर train करो। यह एक DAgger round है, और यह है कि कैसे एक पर चलता है SO-100 एक vision-language-action policy के साथ।

सिद्धांत कहीं और है: क्यों dataset aggregation बिल्कुल काम करता है और क्या human gating इसके बारे में बदलता है। यह operating manual है, और यह मानता है कि एक trained checkpoint है, एक working camera set है, और एक arm है जो चलता है। नीचे दिए गए छह steps इस platform पर लागू किए गए loop हैं DAgger page of this platform, लेकिन sequence आपकी own scripts से भी same है।

क्यों दूसरा राउंड सिर्फ अधिक data नहीं है

Behaviour cloning उन states पर train करता है जो एक human ने visit किए। Test time पर policy वह states visit करती है जो वह cause करती है, और छोटी action errors compound होती हैं states में जो कोई demonstration नहीं covered करता। Ross, Gordon और Bagnell ने इस failure को AISTATS 2011 के लिए formalize किया और इसका जवाब एक iterative algorithm के साथ दिया जो एक stationary deterministic policy को train करता है और, उनके reduction के तहत, उन state distribution के तहत well perform करना होता है जो यह induce करता है: current policy चलाएँ, expert को states label करने दो जो वह actually reach करता है, उन्हें dataset में add करो, retrain करो, repeat करो। Kelly et al. ने HG-DAgger के साथ query को practical बनाया, जहाँ human decide करता है कि कब control लें instead of states को label करने के बिना controls पकड़े; वे improve performance को report करते हैं दोनों DAgger और behaviour cloning के ऊपर एक simulated और एक real autonomous driving task पर। Human gating वह है जो loop को tolerable बनाता है एक desk arm पर - तुम अपना हाथ सिर्फ तभी move करते हो जब कुछ गलत हो रहा हो।

दो consequences ज्यादा matter करती हैं practice में theory से। Corrections साधारण demonstrations नहीं हैं: वे concentrate करती हैं bottleneck regions में जो Mandlekar et al. describe करते हैं, जहाँ एक छोटा deviation policy को states में drop करता है जो demonstrations ने कभी नहीं covered किए। और एक dataset जो सिर्फ इन hard parts से बनी है वह एक badly shaped dataset है - Belkhale, Cui और Sadigh argue करते हैं data side से कि state diversity हमेशा beneficial नहीं है, और कि action divergence और transition diversity together dataset quality को decide करते हैं। Mixed dataset एक compromise नहीं है, यह point है।

Round one से पहले इन्हें freeze करो

एक DAgger round एक policy को अपने against समय के साथ compare करता है। कुछ भी जो तुम change करते हो rounds के बीच जो dataset नहीं है वह comparison को meaningless बनाता है।

• Camera positions और mounts, wrist camera सहित। एक clamp को loosen करो और तुमने observation distribution को change कर दिया है, policy को नहीं।
• Exposure और white balance, अगर तुम्हारा capture stack तुम्हें उन्हें pin करने देता है। Auto-exposure drifting rounds के बीच एक slow, invisible domain shift है।
• Arm calibration और servo zero positions। अगर तुम्हें recalibrate करना है, तो इसके पहले record किए गए सब कुछ को एक अलग dataset के रूप में treat करो।
• Task text। हर VLA यहाँ इस पर condition करता है; mid-loop rewording करना एक different task है।
• Lighting, table surface, object set। एक नया object एक नया experiment है, अगला राउंड नहीं।
• Recording frame rate। Intervention rates को दो sampling rasters के साथ compare करना differences produce करता है जो raster से आती हैं।

Round, end to end

1. 1
   Inference चलाएँ और record करें

   उस checkpoint के विरुद्ध run शुरू करो जिसे तुम improve करना चाहते हो, फिर recording को inference root में शुरू करो। इस तरह record किए गए यह run के own task text को inherit करता है, जो कि वह है जिस पर policy को train किया गया, rather than default teleoperation label के। Recording के बिना तुम failure को देख सकते हो लेकिन इस पर train नहीं कर सकते।

   bash

   # two calls, not one: the run, then its recording
   POST /inference/start      # model_id, and hf_repo_id = the checkpoint to drive
   POST /recording/start      # root=inference
   # root=inference also makes the recording inherit the run's task text

2. 2
   जब गलत हो तो take over करो

   Take over दबाओ और input mode चुनो: leader arm, keyboard या sliders। Runner pause करता है, तुम correct करते हो, तुम hand back करते हो। Frames जो record किए जाते हैं जबकि तुम driving कर रहे हो वे automatically interventions के रूप में flagged होते हैं।

   bash

   POST /inference/takeover/start   # input = leader | keyboard | sliders
   POST /inference/takeover/nudge   # keyboard, relative delta per call
   POST /inference/takeover/set     # sliders, absolute target
   POST /inference/takeover/stop    # back to the policy

3. 3
   Episodes को triage करो

   Per episode decide करो: file as correction, keep as evaluation, या discard करो। एक run जिसे policy बिना मदद के complete किया है वह evaluation data है।

4. 4
   Correction dataset को sync करो

   Corrections एक local dataset per policy में collect होती हैं और automatic sync के माध्यम से cloud storage में जाती हैं। कुछ भी mixed में नहीं जाता जो तुमने वहाँ नहीं रखा।

5. 5
   Mixed dataset को compose करो

   Original dataset को corrections के साथ combine करो, explicitly चुनते हुए episodes per source। Result उस point से एक ordinary dataset है।

   bash

   POST /training/datasets/compose
     sources  = [ original_dataset, korrekturen_<policy> ]
     episodes = explicit selection per source

6. 6
   Checkpoint से continue training करो

   Mix को previous checkpoint से rather than base model से train करो। Note करो कि कौन सी checkpoint और कौन सा mix; इस pair के बिना round reproducible नहीं है।

   bash

   # field on the training job
   base_checkpoint = s3://ay-robots/checkpoints/<run>/<checkpoint>
   # the platform passes it to the training pod as BASE_CKPT_S3

Step 2 विस्तार में: take over करने के दो तरीके

एक leader arm के साथ

लीडर-फॉलोअर mode में leader-follower takeover दो arms के बीच एक handover है जो same pose में नहीं हैं। Take over दबाने से runner pause करता है और leader को follower के current pose पर drive करता है, तो कुछ भी jump नहीं करता जब torque transfer होता है। अगर यह alignment drive timeout होता है, तो तुम leader को manually align करते हो और release करते हो सिर्फ जब दोनों five degrees के भीतर हों। इसके बाद तुम normally teleoperate करते हो और action column record करता है जो तुमने commanded किया।

इस path के बारे में honest हो: alignment drive और torque handover loop का least tested part हैं real hardware पर। Handover को एक slow, harmless pose पर test करो इससे पहले कि तुम इस पर rely करो एक run में जिसकी तुम care करते हो। एक leader arm produce करता है smoothest corrections के तीनों modes में, और सबसे अधिक है जो mechanically गलत हो सकता है।

एक leader arm के बिना: keyboard और sliders

अधिकांश लोग जो यह पढ़ते हैं एक arm own करते हैं। यह enough है। Keyboard या slider input choose करो जिस moment तुम Take over दबाते हो, और takeover immediate और manual है - कोई दूसरा arm नहीं है align करने के लिए, तो कोई alignment step नहीं है। Follower अपना pose hold करता है और input का wait करता है।

Clamps server-side enforce किए जाते हैं, interface में नहीं, क्योंकि एक mistyped delta एक bus-servo arm पर एक collision है। Keyboard corrections stepwise निकलते हैं और slightly coarse; slider corrections smoother हैं, क्योंकि server target की ओर चलता है जबकि interface stream करना रखता है। किसी भी तरह से action column को full commanded pose vector मिलता है और intervention marking leader path के समान है, तो keyboard corrections एक format difference के बिना same dataset में land करती हैं।

Q / A   joint 1      R / F   joint 4
W / S   joint 2      T / G   joint 5
E / D   joint 3      Z / X   gripper

कब button दबाएँ

Late के बजाय early। एक correction जो gripper के closed होने के बाद start होता है nothing पर teaches recovery एक failure से जो policy को enter नहीं करना चाहिए था, और recovery data worthless होता है avoidance data से। Interrupt करो first moment जब तुम confident हो कि trajectory गलत है, correct करो difficult part के through, hand back करो as soon as state एक है जो policy ने handle किया था। ThriftyDAgger automates करता है यह decision को novelty गating करके interventions पर और एक fixed human budget के तहत estimated risk, लेकिन एक single arm पर एक human के साथ पहले से watching, human gate cheaper है और better calibrated है than कुछ भी जो तुम tune करोगे।

Step 3 विस्तार में: triage quality decide करता है

Run के बाद तुम्हारे पास एक recording है कुछ frames के साथ interventions के रूप में marked। तीन destinations exist करते हैं, और गलत एक quietly अगले round को poison करता है।

• File as correction जब intervention एक genuine fix था: policy कहीं गलत जा रहा था और तुम्हारे input ने right thing दिखाया एक state से जो policy ने खुद produce किया।
• Keep as evaluation clean autonomous runs के लिए और runs के लिए जो तुमने caution से take over किए। Evaluation episodes हैं कि कैसे तुम अगली checkpoint को measure करते हो, और वे कभी trained नहीं होने चाहिए।
• Discard करो runs जो ruined हैं कुछ unrelated से - एक dropped camera frame, एक stalled servo, एक object जिसे तुमने knock over किया। एक messy correction no correction से worse है।

Step 5 विस्तार में: mix को compose करना

Composition original dataset को correction dataset के साथ लेता है और produce करता है एक नया, ordinary LeRobot dataset जो किसी अन्य की तरह train करता है। Important property यह है कि episode selection explicit है per source - कुछ भी automatically blend नहीं होता। यह minor लगता है जब तक पहली बार एक policy strangely behave नहीं करता और तुम्हें reconstruct करना पड़ता है कि यह किस पर train किया गया था।

Open question वह है ratio, और कोई भी एक number है जो transfer करता है। साहित्य सहमत है कि corrections अपने frame share के लिए अधिक count करने चाहिए। Mandlekar et al. iteratively retrain करते हैं data पर जो उनका intervention system collect करता है, तो policy learn करती है bottlenecks को traverse करने के लिए, और report करते हैं कि agents trained इस तरह outperform करते हैं agents trained को equivalent number के साथ samples से non-interventional demonstrators। Sirius further जाता है और re-weights करता है training samples by approximated human trust, reporting एक 8 percent gain simulation में और 27 percent real hardware पर policy success rate में methods के विरुद्ध जिनके साथ यह compares, convergence speed में double पर। कोई भी training entry points यहाँ expose नहीं करते एक sample-weighting knob, तो crude substitute original demonstrations को subsampling करना है जबकि every correction episode को keep करते हो - और लिखते हो कि तुमने क्या किया।

Step 6 विस्तार में: checkpoint से continuing really क्या means करता है

Mix को base model से training करना काम करता है लेकिन previous round को throw away करता है और एक full run cost करता है। Previous से continuing करना checkpoint faster है और usually better है। यह भी more limited है जो phrase suggest करता है।

Latency DAgger loop के अंदर compound करता है एक तरीके में जो demo के दौरान नहीं: लगभग 485 ms per action step पर तुम take over करते हो क्योंकि arm hesitated, गलत नहीं, और hesitation corrections useful training data नहीं हैं। अगर तुम data पर iterate कर रहे हो rather than final success rate को chase कर रहे हो, तो एक fast model पर iterate करो। Shukor et al. describe करते हैं SmolVLA को designed के रूप में एक single GPU पर train करने के लिए और deploy करने के लिए consumer GPUs या CPUs पर, एक asynchronous inference stack के साथ जो action prediction को execution से decouple करता है higher control rates को allow करने के लिए - property जो एक takeover loop को responsive रखता है।

Dataset formats interchangeable नहीं हैं या। GR00T लेता है LeRobot v2.0 या v2.1, और Isaac-GR00T repository describe करता है इसके input को एक flavour के रूप में LeRobot v2 format का एक added modality description file के साथ; newer trainers यहाँ expect करते हैं v3.0। एक mix composed गलत version में load time पर fail करता है rather than एक bad policy produce करने से - better failure mode, still एक wasted queue slot। dataset documentation lists करता है कौन सा format हर trainer लेता है।

Round को waste करने के चार तरीके

1. Corrections alone पर training करना

Most common failure और most tempting shortcut। एक correction-only dataset almost entirely difficult middle है task का, approach और retreat missing; policy बेहतर हो जाती है hard part पर और भूल जाती है कि कैसे वहाँ आना है। Aggregation एक implementation detail नहीं है method का, यह mechanism है: old data वह है जो rest को behavior में रखता है जबकि corrections एक part को move करते हैं।

2. Rounds के बीच एक camera move करना

एक camera जो दो centimeters shift करती है rounds के बीच एक policy produce करता है जो worse है जिस से तुम start किए, और एक diagnosis जो एक day cost करता है। हर VLA यहाँ conditions करता है images पर; joint state alone disambiguate नहीं करता जहाँ object है। पहली बार से पहले setup को photograph करो और check करो कि photograph को हर बाद में।

3. Handover artefacts को training में होने देना

ऊपर covered, और list पर क्योंकि यह invisible है। Symptom एक policy है जो stalls करती है एक fraction second exactly जहाँ previous round का operator take over करता है। यह hesitation की तरह दिखता है; यह imitation है।

4. एक warm start को एक resume कहना

अगर तुम believe करते हो कि optimizer state carry over किया, तो initial loss spike एक bug के रूप में read करता है और तुम corrupted data के लिए hunt करते हो। अगर तुम जानते हो कि optimizer fresh start किया, तो spike expected है और तुम देखते हो कि इसके बाद क्या आता है। Same numbers, opposite conclusions।

Round को measure करना

Human-gated loop के लिए metric वह है intervention rate: frames जो record किए जाते हैं जबकि तुम control में थे, divided by run के total frames से। यह takeover status में है, और यह एक ही number है जो question का answer देता है जो round ने पूछा। Training loss गिरता है चाहे policy improve हुई या नहीं; success rate binary है और noisy एक desk arm produce करता है sample sizes पर। Intervention rate continuous है, measured पर states जो policy ने खुद cause किया, और यह drops जैसे policy को तुम्हें कम जरूरत है।

इसे compare करो सिर्फ across runs जो identical conditions के तहत record किए गए हैं। Full argument, और कैसे एक evaluation set build करो जो दो rounds से ज्यादा survive करता है, में है the article on measuring a DAgger loop। Round one realistically एक feasibility test है: तुम check कर रहे हो कि takeover तुम्हारे hardware पर काम करती है, कि corrections अपने flags के साथ land करती हैं, और कि continued run checkpoint को load करता है जो तुमने named किया। Rounds two और three जहाँ rate को start moving करना चाहिए। अगर चौथे round तक move नहीं हुई है, तो problem DAgger के upstream है।

अगर तुम्हारे पास अभी कोई checkpoint नहीं है

Loop का कोई entry point नहीं है इसके बिना। एक first dataset record करो, एक first policy train करो, run करो - recording, training और running the policy वह path cover करते हैं। Recording client में है the download page, GPU tiers और hourly rates the pricing page पर, और क्या एक usable episode दिखता है SO-100 data collection guide में। Demonstrations को right करो corrections से पहले: DAgger एक repair mechanism है, और यह far better काम करता है कुछ ऐसा पर जो पहले ही nearly right था।

कोई भी यह solved problem नहीं है और कोई भी यह एक click नहीं है। Interactive imitation learning एक active research area है precisely क्योंकि इसके questions - कब intervene करें, कैसे weight करें जो human ने किया, कितना old data keep करें - no settled answers हैं; Celemin et al. द्वारा survey maps करता है क्या still open है। जो loop को have है वह है measurable convergence जब यह carefully run होता है, hardware पर जो एक few hundred euros cost करता है। Setup को freeze करो, early intervene करो, honestly triage करो, deliberately mix करो, और intervention rate को हर बार record करो।