Kjøring av en DAgger-løkke på en SO-100 med en VLA-policy

Policyen din kjører. Den strekker seg etter kuben, lukker gripperen en centimeter for tidlig, og fortsetter som om den hadde den. Ingenting feiler, og ingen mengde stirring på treningsfeilen forklarer det. Fiksen er ikke ytterligere 20 000 gradientstig på de samme demonstrasjonene. Det er å legge hånden din tilbake på armen nøyaktig der den går galt, registrere hva du gjorde i stedet, og trene neste punkt på de gamle dataene pluss den korreksjonen. Det er en DAgger-runde, og slik kjøres den på en SO-100 med en vision-language-action policy.

Teorien er et annet sted: hvorfor datasettaggregering fungerer i det hele tatt og hva human gating endrer om det. Dette er betjeningshåndboken, og den forutsetter et trent punkt, et fungerende kamerasett, og en arm som beveger seg. De seks trinnene nedenfor er løkken som implementert på DAgger-siden av denne plattformen, men sekvensen er den samme fra dine egne skripter.

Hvorfor den andre runden ikke bare er mer data

Imitasjonskloning trener på tilstandene en menneske besøkte. Ved testtid besøker policyen tilstandene den forårsaker, og små handlingsfeil forbinder seg til tilstander ingen demonstrasjon dekket. Ross, Gordon og Bagnell formaliserte denne feilen for AISTATS 2011 og besvarte den med en iterativ algoritme som trener en stasjonær deterministisk policy og, under deres reduksjon, må prestere godt under tilstandsfordelingen den induserer: kjør nåværende policy, få eksperten til å merke tilstandene den faktisk nådde, legg dem til datasettet, tren på nytt, gjenta. Kelly et al. gjorde spørsmålet praktisk med HG-DAgger, hvor mennesket bestemmer når det skal ta kontroll i stedet for å merke tilstander uten å holde kontrollene; de rapporterer forbedret ytelse over både DAgger og imitasjonskloning på en simulert og en reell autonom kjøreoppgave. Human gating er hva som gjør løkken tålelig på en skrivebords-arm - du beveger bare hendene dine når noe går galt.

To konsekvenser betyr mer i praksis enn teorien gjør. Korreksjoner er ikke vanlige demonstrasjoner: de konsentrerer seg ved flaskehalsmomenter Mandlekar et al. beskriver, der en liten avvik får policyen inn i tilstander demonstrasjonene aldri dekket. Og et datasett laget bare av disse vanskelige delene er et dårlig formet datasett - Belkhale, Cui og Sadigh argumenterer fra datasiden at tilstandsdiversitet ikke alltid er fordelaktig, og at handlingsdivergense og overgangsdiversitet sammen avgjør datasetkvalitet. Det blandede datasettet er ikke et kompromiss, det er poenget.

Frys disse før runde en

En DAgger-runde sammenligner en policy mot seg selv over tid. Alt du endrer mellom runder som ikke er datasettet gjør sammenligningen meningsløs.

• Kameraposisjoner og monteringer, håndledd-kamera inkludert. Løsne en klamp og du endret observasjonsfordelingen, ikke policyen.
• Eksponering og hvitbalanse, hvis innsamlingsstakken din lar deg feste dem. Auto-eksponering drifter mellom runder er en langsom, usynlig domeneskift.
• Arm-kalibrering og servo-nullposisjoner. Hvis du må rekalibrere, behandle alt som ble registrert før det som et eget datasett.
• Oppgaveteksten. Alle VLA-ene her betinger seg på den; omformulering av den midt i løkken er en annen oppgave.
• Belysning, bordflate, objektsett. Et nytt objekt er et nytt eksperiment, ikke neste runde.
• Opptak-bildetakten. Sammenligning av intervensjonsrater på to samplingsraster gir forskjeller som kommer fra rasteret.

Runden, ende til ende

1. 1
   Kjør inferens og registrer den

   Start kjøringen mot punktet du vil forbedre, start deretter opptaket inn i inferensmappen. Registrert på den måten arver den kjøringens egen oppgavetekst, som er hva policyen ble trent på, i stedet for standard teleoperation-merke. Uten opptaket kan du se feilen men ikke trene på den.

   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
   Ta over når det går galt

   Trykk Ta over og velg inndatamodus: leder-arm, tastatur eller glidere. Løperen pause, du korrigerer, du leverer tilbake. Rammer registrert mens du kjørte flagges automatisk som intervensjoner.

   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 episodene

   Bestem per episode: arkiver som korreksjon, behold som evaluering, eller forkast. En kjøring som policyen fullførte uten hjelp er evalueringsdata.

4. 4
   Synkroniser korreksjonsdatasettet

   Korreksjoner samler seg i et lokalt datasett per policy og går til skytlagring gjennom den automatiske synkroniseringen. Ingenting er blandet inn som du ikke la dit.

5. 5
   Kombiner det blandede datasettet

   Kombiner det originale datasettet med korreksjonsdatasettet, og velg episoder eksplisitt per kilde. Resultatet er et vanlig datasett fra det punktet videre.

   bash

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

6. 6
   Fortsett opplæringen fra punktet

   Tren blandingen fra forrige punkt i stedet for basismodellen. Noter hvilket punkt og hvilken blanding; uten det paret er runden ikke reproduserbar.

   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

Trinn 2 i detalj: de to måtene å ta over

Med en leder-arm

I leder-følger modus er overtagelsen en overlevering mellom to armer som ikke er i samme posisjon. Å trykke Ta over pause løperen og kjører lederen inn i følgerens nåværende posisjon, så ingenting hopper når dreiemoment overføres. Hvis justeringen timeout, justerer du lederen for hånd og slipper bare når de to er innenfor fem grader. Derfra telopererer du normalt og handlingskolonnen registrerer hva du beordret.

Vær ærlig om denne stien: justeringsdriften og dreiemomentet overlevering er den minst testede delen av løkken på ekte maskinvare. Test overlevering på en langsom, harmløs posisjon før du stoler på den i en kjøring du bryr deg om. En leder-arm produserer de glatteste korreksjoner av de tre modiene, og har også mest som kan gå galt mekanisk.

Uten en leder-arm: tastatur og glidere

De fleste som leser dette eier en arm. Det er nok. Velg tastatur- eller glideinput i det øyeblikket du trykker Ta over, og overtagelsen er umiddelbar og manuell - det er ingen andre arm å justere, så det er intet justeringstrinn. Følgeren holder posisjonen sin og venter på inndata.

Klampene håndheves server-side, ikke i interfacet, fordi en feilskrevet delta på en buss-servo arm er en kollisjon. Tastaturkorreksjoner kommer ut trinnvis og litt grov; glidekorreksjoner er glattere, fordi serveren går mot målet mens interfacet holder å strømme. Uansett mottar handlingskolonnen den fullstendige beordrede pose-vektoren og intervensjonsmarkeringen er identisk med leder-stien, så tastaturkorreksjoner lander i samme datasett uten en formatforskjell.

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

Når du skal trykke knappen

Tidlig i stedet for sent. En korreksjon som starter etter at gripperen har lukket på ingenting lærer gjenoppretting fra en feil policyen ikke burde ha gått inn, og gjenopprettingsdata er verdt langt mindre enn unngåelsesdata. Avbryt i det første øyeblikket du er sikker på at banen er feil, korrigert gjennom den vanskelige delen, levering tilbake så snart tilstanden er en som policyen håndterte før. ThriftyDAgger automatiserer den avgjørelsen ved å gate intervensjoner på nyhet og estimert risiko under en fast menneskelig budget, men på en enkelt arm med et menneske som allerede ser på, er menneskets gate billigere og bedre kalibrert enn noe du vil tune.

Trinn 3 i detalj: triage bestemmer kvaliteten

Etter kjøringen har du en opptak med noen rammer merket som intervensjoner. Tre destinasjoner finnes, og den feil stille forgifte stilleggen runden.

• Arkiver som korreksjon når intervensjon var en ekte reparasjon: policyen gikk noe galt og ditt inndata viste det riktige fra en tilstand policyen selv produserte.
• Behold som evaluering for rene autonome kjøringer og for kjøringer du tok over av forsiktighet. Evaluerings-episoder er hvordan du måler neste punkt, og de må aldri trenes på.
• Forkast kjøringer ødelagt av noe urelated - en droppet kameraramme, en stallert servo, et objekt du banket over. En rotete korreksjon er verre enn ingen korreksjon.

Trinn 5 i detalj: sammensetning av blandingen

Sammensetning tar det originale datasettet pluss korreksjonsdatasettet og produserer et nytt, vanlig LeRobot datasett som trener som alle andre. Den viktige egenskapen er at episode-utvalget er eksplisitt per kilde - ingenting blandes inn automatisk. Det høres lite ut til det først gang en policy oppfører seg rart og du må rekonstruere hva den ble trent på.

Det åpne spørsmålet er forholdet, og ingen har et tall som overfører. Hva litteraturen er enig om er at korreksjoner burde telle for mer enn sin ramme-andel. Mandlekar et al. tren iterativt på dataene intervensjonssystemet deres samler inn, så policyen lærer å traversere flaskehalsen, og rapporterer at agenter trent på den måten utperformer agenter trent på et tilsvarende antall prøver fra ikke-intervensjonale demonstratorer. Sirius går videre og re-vekter trenings-prøver etter tilnærmet menneskelig tillit, og rapporterer en 8 prosent gevinst i simulering og 27 prosent på ekte maskinvare i policy-suksessrate mot metodene det sammenligner med, på dobbelt konvergenshastighet. Ingen av trenings oppgave-punktene her eksponerer en sample-veining knapp, så den grove erstatningen er å holde hver korreksjon-episode mens undersampling de opprinnelige demonstrasjonene - og skrive ned hva du gjorde.

Trinn 6 i detalj: hva det vil si å fortsette fra et punkt virkelig

Å trene blandingen fra basismodellen fungerer men kaster bort forrige runde og koster en full kjøring. Fortsettelse fra tidligere punkt er raskere og vanligvis bedre. Det er også mer begrenset enn frasen antyder.

Latens sammensetter seg inne i en DAgger løkke på en måte den ikke gjør under en demo: på omtrent 485 ms per handlingstrinn tar du over fordi armen nølte, ikke fordi det var galt, og nølte-korreksjoner er ikke nyttig treningsdata. Hvis du gjentar på data i stedet for jager en endelig suksessrate, gjenta på en rask modell. Shukor et al. beskriver SmolVLA som designet for å trene på en enkelt GPU og implementere på forbruker-GPUer eller CPUer, med en asynkron inferens-stabel som frikoblet handlingsforutsigelse fra henrettelse for å tillate høyere kontrollhastigheter - egenskapen som holder en overtakelse-løkke responsiv.

Datasetformaten er ikke utskiftbar heller. GR00T tar LeRobot v2.0 eller v2.1, og Isaac-GR00T depotet beskriver inngangen sin som en smak av LeRobot v2 formatet med en ekstra modalitet beskrivelses fil; de nyere trenerene her forventer v3.0. En blanding komponert i feil versjon mislykkes ved last tid i stedet for å produsere en dårlig policy - den bedre feilen modus, likevel et bortkastet køplass. Den datasett dokumentasjon lister hvilken format hver trener tar.

Fire måter å kaste bort en runde

1. Trening på bare korreksjoner

Den mest vanlige svikten og den mest fristende snarveien. Et korreksjon-kun datasett er nesten helt vanskelig midten av oppgaven, med tilnærming og retrett mangler; policyen blir bedre på den vanskelige delen og glemmer hvordan å ankomme der. Aggregering er ikke en implementeringsdetalj av metoden, det er mekanismen: de gamle dataene er hva som holder resten av atferden på plass mens korreksjoner beveger en del av det.

2. Flytte et kamera mellom runder

Et kamera som skifter to centimeter mellom runder produserer en policy verre enn den du startet med, og en diagnose som koster en dag. Alle VLA her betinger seg på bilder; leddtilstand alene disambiguerer ikke hvor objektet er. Fotografer oppsettet før den første runden og sjekk det fotografiet før hver senere.

3. La handover-artefakter inn i opplæring

Dekket ovenfor, og på listen fordi det er usynlig. Symptomet er en policy som står stille for en brøkdel av et sekund nøyaktig der tidligere rundes operatør tok over. Det ser ut som nøling; det er etterligning.

4. Kaller en varm start et resume

Hvis du tror optimiseringer tilstand overførte, leser den initiale tap-pigget som en bug og du går på jakt etter korrupt data. Hvis du vet optimisereren startet frisk, er pigget forventet og du ser på hva som kommer etter det. Samme tall, motsatte konklusjoner.

Måling av runden

Metrikken for en human-gated løkke er intervensjonsraten: rammer registrert mens du var i kontroll, delt på totale rammer av kjøringen. Den er i overtakelse statusen, og den er det eneste nummeret som svar spørsmålet runden spurte. Treningsfeilen faller uansett om policyen forbedret seg; suksessrate er binær og støyete på prøve størrelsene en skrivebords-arm produserer. Intervensjonsrate er kontinuerlig, målt på tilstandene som policyen selv forårsaket, og den faller når policyen trenger deg mindre.

Sammenlign den bare på tvers av kjøringer registrert under identiske forhold. Det fullstendige argumentet, og hvordan bygge et evalueringsmengde som overlever mer enn to runder, er i artikkelen om måling av en DAgger-løkke. Runde en er realistisk en gjennomførbarhets-test: du sjekker at overtagelsen fungerer på maskinvaren din, at korreksjoner lander med flagg, og at den fortsatte kjøringen lastet punktet du navngav. Runder to og tre er der hastigheten burde begynne å bevege seg. Hvis den ikke har beveget seg ved runde fire, er problemet oppstrøm for DAgger.

Hvis du ikke har et punkt ennå

Løkken har ingen oppgave-punkt uten en. Registrer et første datasett, tren en første policy, kjør den - opptak, opplæring og kjøring av policyen dekk denne stien. Opptak-klienten er på nedlastingssiden, GPU-nivåer og timer-hastigheter på prissiden, og hva en brukbar episode ser ut i SO-100 data samlings veiledning. Få demonstrasjonene riktig før korreksjoner: DAgger er en reparasjons mekanisme, og den fungerer langt bedre på noe som var nesten riktig allerede.

Ingenting av dette er et løst problem og ingenting av det er en klikk. Interaktiv imitasjonslæring er et aktivt forskningsområde nettopp fordi spørsmålene - når skal intervensjon, hvordan skal veie hva mennesket gjorde, hvor mye gamle data skal holde - har ingen oppgjorte svar; oversikten av Celemin et al. kartlegger hva som fortsatt er åpen. Hva løkken har er målbar konvergering når den kjøres forsiktig, på maskinvare som koster noen få hundre euro. Frys oppsettet, intervensjon tidlig, triage ærlig, blande bevisst, og registrer intervensjonsraten hver gang.