Esecuzione di un Loop DAgger su un SO-100 con una Policy VLA

La tua policy si esegue. Raggiunge il cubo, chiude il gripper un centimetro troppo presto, e continua come se l'avesse preso. Nulla genera errori, e nessuna quantità di sguardi fissati sulla perdita di addestramento lo spiega. La soluzione non è altri 20.000 step di gradiente sugli stessi esempi. È mettere di nuovo la mano sul braccio esattamente dove sbaglia, registrare cosa hai fatto invece, e addestrare il checkpoint successivo sui dati vecchi più quella correzione. Questo è un round DAgger, e così è come uno si esegue su un SO-100 con una policy vision-language-action.

La teoria è altrove: perché l'aggregazione del dataset funziona affatto e cosa cambia il cancello umano rispetto ad essa. Questo è il manuale operativo, e presuppone un checkpoint addestrato, una serie di telecamere funzionante, e un braccio che si muove. I sei step seguenti sono il loop così implementato su la pagina DAgger di questa piattaforma, ma la sequenza è la stessa dai tuoi script.

Perché il secondo round non è solo più dati

Behaviour cloning si addestra sugli stati che un umano ha visitato. Al momento del test la policy visita gli stati che provoca, e piccoli errori di azione si compongono in stati che nessuna dimostrazione ha coperto. Ross, Gordon e Bagnell hanno formalizzato quel fallimento per AISTATS 2011 e lo hanno risolto con un algoritmo iterativo che addestra una policy deterministica stazionaria e, secondo la loro riduzione, deve funzionare bene sotto la distribuzione di stato che induce: esegui la policy attuale, fai etichettare gli stati che ha effettivamente raggiunto all'esperto, aggiungili al dataset, riaddestra, ripeti. Kelly et al. hanno reso la query pratica con HG-DAgger, dove l'umano decide quando prendere il controllo invece di etichettare stati senza tenere i comandi; riportano prestazioni migliori sia di DAgger che di behaviour cloning su un compito di guida autonoma simulato e reale. Il cancello umano è ciò che rende il loop tollerabile su un braccio da scrivania - muovi le mani solo quando qualcosa va male.

Due conseguenze importano più nella pratica che nella teoria. Le correzioni non sono dimostrazioni ordinarie: si concentrano nelle regioni di collo di bottiglia che Mandlekar et al. descrivono, dove una piccola deviazione getta la policy in stati che le dimostrazioni non hanno mai coperto. E un dataset fatto solo di quelle parti difficili è un dataset mal formato - Belkhale, Cui e Sadigh sostengono dal lato dei dati che la diversità di stato non è sempre vantaggiosa, e che la divergenza di azione e la diversità di transizione insieme decidono la qualità del dataset. Il dataset misto non è un compromesso, è il punto.

Congela questi prima del round uno

Un round DAgger confronta una policy con se stessa nel tempo. Qualunque cosa cambi tra i round che non sia il dataset rende quel confronto privo di significato.

• Posizioni e montature della telecamera, inclusa la telecamera del polso. Allenta un morsetto e hai cambiato la distribuzione di osservazione, non la policy.
• Esposizione e bilanciamento del bianco, se lo stack di acquisizione ti permette di fissarli. La deriva dell'auto-esposizione tra i round è uno shift del dominio lento e invisibile.
• Calibrazione del braccio e posizioni zero del servo. Se devi ricalibrare, tratta tutto ciò che è stato registrato prima come un dataset separato.
• Il testo dell'attività. Ogni VLA qui si condiziona su di esso; riformularlo a metà del loop è un'attività diversa.
• Illuminazione, superficie del tavolo, insieme di oggetti. Un nuovo oggetto è un nuovo esperimento, non il round successivo.
• La frequenza dei fotogrammi di registrazione. Confrontare i tassi di intervento su due raster di campionamento produce differenze che provengono dal raster.

Il round, da capo a fondo

1. 1
   Esegui l'inferenza e registra

   Inizia l'esecuzione rispetto al checkpoint che vuoi migliorare, poi avvia la registrazione nella radice dell'inferenza. Registrato in quel modo eredita il testo dell'attività della propria esecuzione, che è ciò su cui è stata addestrata la policy, piuttosto che l'etichetta di teleoperation predefinita. Senza la registrazione puoi guardare il fallimento ma non addestrarlo.

   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
   Prendi il controllo quando qualcosa va male

   Premi Take over e scegli la modalità di input: braccio leader, tastiera o slider. Il runner si ferma, correggi, riconsegni. I fotogrammi registrati mentre guidavi vengono contrassegnati come interventi automaticamente.

   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
   Triage gli episodi

   Decidi per ogni episodio: classifica come correzione, mantieni come valutazione, o scarta. Un'esecuzione che la policy ha completato senza aiuto è dato di valutazione.

4. 4
   Sincronizza il dataset di correzione

   Le correzioni si raccolgono in un dataset locale per policy e vanno nello storage cloud attraverso la sincronizzazione automatica. Nulla viene mescolato che non hai messo tu.

5. 5
   Componi il dataset misto

   Combina il dataset originale con il dataset di correzioni, scegliendo esplicitamente gli episodi per fonte. Il risultato è un dataset ordinario da quel punto in poi.

   bash

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

6. 6
   Continua l'addestramento dal checkpoint

   Addestra il mix dal checkpoint precedente piuttosto che dal modello base. Annota quale checkpoint e quale mix; senza quella coppia il round non è riproducibile.

   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 in dettaglio: i due modi di prendere il controllo

Con un braccio leader

In leader-follower mode il takeover è un handover tra due bracci che non sono nella stessa postura. Premere Take over mette in pausa il runner e guida il leader sulla postura attuale del follower, così nulla salta quando il torque si trasferisce. Se quel drive di allineamento va in timeout, allinea il leader a mano e rilascia solo una volta che i due sono entro cinque gradi. Da allora teleoperi normalmente e la colonna di azione registra ciò che hai comandato.

Sii onesto su questo percorso: il drive di allineamento e l'handover di torque sono la parte meno testata del loop sull'hardware reale. Testa l'handover su una postura lenta e innocua prima di affidarti ad esso in un'esecuzione che ti interessa. Un braccio leader produce le correzioni più fluide tra le tre modalità, e anche ha il massimo che può andare male meccanicamente.

Senza un braccio leader: tastiera e slider

La maggior parte delle persone che leggono questo possiede un braccio. Quello è abbastanza. Scegli input da tastiera o slider nel momento in cui premi Take over, e il takeover è immediato e manuale - non c'è un secondo braccio da allineare, quindi non c'è alcun passo di allineamento. Il follower mantiene la sua postura e aspetta l'input.

I clamp sono applicati lato server, non nell'interfaccia, perché un delta errato su un braccio bus-servo è una collisione. Le correzioni da tastiera escono a step e leggermente grossolane; le correzioni da slider sono più fluide, perché il server cammina verso il target mentre l'interfaccia continua a trasmettere. In entrambi i casi la colonna di azione riceve il vettore di postura comandata completo e il contrassegno di intervento è identico al percorso del leader, così le correzioni da tastiera atterrano nello stesso dataset senza una differenza di formato.

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

Quando premere il pulsante

Presto piuttosto che tardi. Una correzione che inizia dopo che il gripper si è chiuso sul nulla insegna il recupero da un fallimento in cui la policy non avrebbe dovuto entrare, e i dati di recupero valgono molto meno dei dati di evitamento. Interrompi nel primo momento in cui sei sicuro che la traiettoria è sbagliata, correggi attraverso la parte difficile, riconsegna non appena lo stato è uno che la policy ha gestito prima. ThriftyDAgger automatizza quella decisione cancellando gli interventi su novità e rischio stimato sotto un budget umano fisso, ma su un braccio singolo con un umano già in osservazione, il cancello umano è più economico e meglio calibrato di qualunque cosa tu sintonizzerai.

Step 3 in dettaglio: triage decide la qualità

Dopo l'esecuzione hai una registrazione con alcuni fotogrammi contrassegnati come interventi. Tre destinazioni esistono, e quella sbagliata avvelena silenziosamente il round successivo.

• Classifica come correzione quando l'intervento è stata una vera fix: la policy stava andando da qualche parte sbagliata e il tuo input ha mostrato la cosa giusta da uno stato che la policy stessa ha prodotto.
• Mantieni come valutazione per esecuzioni autonome pulite e per esecuzioni su cui hai preso il controllo per cautela. Gli episodi di valutazione sono come misuri il checkpoint successivo, e non devono mai essere addestrati.
• Scarta esecuzioni rovinate da qualcosa di estraneo - un fotogramma della telecamera caduto, un servo bloccato, un oggetto che hai fatto cadere. Una correzione disordinata è peggiore di nessuna correzione.

Step 5 in dettaglio: comporre il mix

La composizione prende il dataset originale più il dataset di correzione e produce un nuovo, ordinario LeRobot dataset che si addestra come qualunque altro. La proprietà importante è che la selezione degli episodi è esplicita per fonte - nulla viene mescolato automaticamente. Questo suona minore finché la prima volta che una policy si comporta strangamente e devi ricostruire su cosa è stata addestrata.

La domanda aperta è il rapporto, e nessuno ha un numero che si trasferisce. Ciò su cui la letteratura concorda è che le correzioni dovrebbero contare per più della loro quota di fotogrammi. Mandlekar et al. riaddestrare iterativamente sui dati che il loro sistema di intervento raccoglie, così la policy impara a traversare i colli di bottiglia, e riportano che gli agenti addestrati in quel modo superano gli agenti addestrati su un numero equivalente di campioni da dimostratori non-interventisti. Sirius va oltre e ri-pesa i campioni di addestramento da trust umano approssimato, riportando un guadagno dell'8% in simulazione e del 27% su hardware reale nel tasso di successo della policy contro i metodi con cui confronta, a due volte la velocità di convergenza. Nessuno degli entry point di addestramento qui espone una manopola di ri-pesatura del campione, così il sostituto grezzo è mantenere ogni episodio di correzione mentre si sottocampionano le dimostrazioni originali - e scrivere quello che hai fatto.

Step 6 in dettaglio: cosa significa veramente continuare da un checkpoint

Addestrare il mix dal modello base funziona ma butta via il round precedente e costa un run completo. Continuare dal checkpoint precedente è più veloce e di solito migliore. È anche più limitato di quanto la frase suggerisca.

La latenza si compone all'interno di un loop DAgger in un modo in cui non lo fa durante una demo: a circa 485 ms per azione step prendi il controllo perché il braccio ha esitato, non perché era sbagliato, e i dati di correzione di esitazione non sono dati di addestramento utili. Se stai iterando sui dati piuttosto che inseguire un tasso di successo finale, itera su un modello veloce. Shukor et al. descrivono SmolVLA come progettato per addestrare su una singola GPU e deployare su GPU consumer o CPU, con uno stack di inferenza asincrono che disaccoppia la predizione di azione dall'esecuzione per consentire tassi di controllo più alti - la proprietà che mantiene un loop di takeover responsivo.

I formati del dataset non sono intercambiabili neanche. GR00T prende LeRobot v2.0 o v2.1, e il repository Isaac-GR00T descrive il suo input come un sapore del formato LeRobot v2 con un file di descrizione di modalità aggiunto; i trainer più recenti qui si aspettano v3.0. Un mix composto nella versione sbagliata fallisce al tempo di carico piuttosto che produrre una policy cattiva - la modalità di fallimento migliore, comunque uno slot di coda sprecato. Il dataset documentation elenca quale formato ogni trainer prende.

Quattro modi di sprecare un round

1. Addestramento solo sulle correzioni

L'errore più comune e la scorciatoia più allettante. Un dataset di sole correzioni è quasi interamente il mezzo difficile dell'attività, con approccio e ritirata mancanti; la policy migliora sulla parte difficile e dimentica come arrivarci. L'aggregazione non è un dettaglio di implementazione del metodo, è il meccanismo: i dati vecchi sono quello che mantiene il resto del comportamento mentre le correzioni spostano una parte di esso.

2. Spostamento di una telecamera tra i round

Una telecamera che cambia di due centimetri tra i round produce una policy peggiore di quella con cui hai iniziato, e una diagnosi che costa un giorno. Ogni VLA qui si condiziona su immagini; lo stato articolare da solo non disambigua dove si trova l'oggetto. Fotografa la configurazione prima del primo round e controlla quella fotografia prima di ogni round successivo.

3. Lasciare che gli artefatti di handover entrino nell'addestramento

Coperto sopra, e sulla lista perché è invisibile. Il sintomo è una policy che si ferma per una frazione di secondo esattamente dove l'operatore del round precedente ha preso il controllo. Sembra esitazione; è imitazione.

4. Chiamare un warm start un resume

Se credi che lo stato dell'optimizer si sia trasferito, lo spike di perdita iniziale si legge come un bug e vai a caccia di dati corrotti. Se sai che l'optimizer ha iniziato da zero, lo spike è previsto e guardi cosa viene dopo. Stessi numeri, conclusioni opposte.

Misurare il round

La metrica per un loop con cancello umano è l'intervention rate: fotogrammi registrati mentre eri in controllo, diviso per fotogrammi totali dell'esecuzione. È nello stato del takeover, ed è l'unico numero che risponde alla domanda che il round ha posto. La perdita di addestramento cade indipendentemente dal fatto che la policy sia migliorata; il tasso di successo è binario e rumoroso alle dimensioni del campione che un braccio da scrivania produce. L'intervention rate è continuo, misurato negli stati che la policy stessa ha causato, e diminuisce man mano che la policy ha meno bisogno di te.

Confrontalo solo su esecuzioni registrate in condizioni identiche. L'argomento completo, e come costruire un set di valutazione che sopravvive a più di due round, è in l'articolo su misurare un loop DAgger. Il round uno è realisticamente un test di fattibilità: stai controllando che il takeover funzioni sul tuo hardware, che le correzioni atterrino con i loro contrassegni, e che il run continuato ha caricato il checkpoint che hai nominato. I round due e tre sono dove il tasso dovrebbe iniziare a muoversi. Se non si è mosso entro il round quattro, il problema è a monte di DAgger.

Se non hai ancora un checkpoint

Il loop non ha alcun entry point senza uno. Registra un primo dataset, addestra una prima policy, eseguila - recording, training e running the policy coprono quel percorso. Il client di registrazione è su the download page, i tier di GPU e le tariffe orarie su the pricing page, e che cosa un episodio usabile assomiglia nel SO-100 data collection guide. Rendi le dimostrazioni giuste prima delle correzioni: DAgger è un meccanismo di riparazione, e funziona molto meglio su qualcosa che era già quasi giusto.

Nulla di questo è un problema risolto e nulla di esso è un clic. Interactive imitation learning è un'area di ricerca attiva precisamente perché le sue domande - quando intervenire, come pesare quello che l'umano ha fatto, quanti dati vecchi mantenere - non hanno risposte stabilite; il sondaggio di Celemin et al. mappa cosa è ancora aperto. Quello che il loop ha è convergenza misurabile quando viene eseguito con cura, su hardware che costa poche centinaia di euro. Congela la configurazione, intervieni presto, triage onestamente, componi deliberatamente, e registra l'intervention rate ogni volta.