Start med erfaringen det fysiske systemet ditt mangler.
Hullet er en oppgave, et objekt, et miljø eller en gjenopprettingstilstand som treningsdataene ikke dekker, eller årevis med logger som ingen kan laste inn, sammenligne eller gjenbruke med trygghet.
Et råbilde registrerer bevegelsen, ikke oppgaven den tjente.
Et kamerabilde viser hva systemet observerte. En tilstandslogg viser en leddposisjon. Et handlingsspor viser en kommando.
Den leverte episoden holder observasjoner, robottilstand, handlinger, oppgavekontekst, timing og utfall koblet sammen.
Det er den sammenhengen som gjør at teamet ditt kan trene, sammenligne, kontrollere og reprodusere en beslutning.
Bli enige om hva som teller som ett levert element.
En time med fjernstyring kan inneholde flere nyttige episoder, én lang episode eller for det meste oppsett og ugyldige forsøk. En kort sekvens med feil og gjenoppretting kan ha større verdi for beslutningen enn gjentatt ren utførelse.
Enheten din kan være:
- en godkjent episode
- en oppgavedemonstrasjon
- en synkronisert periode
- en fjernstyringsøkt
- en sekvens med feil og gjenoppretting
- en evaluert policy-kjøring
- en datasettutgivelse
Mål pris, fremdrift, kvalitet og aksept i samme enhet.
Start med flaskehalsen du har.
YPAI hjelper robotikkteam med å gjenopprette eksisterende data, samle inn manglende demonstrasjoner fra den virkelige verden, strukturere og annotere episoder, utvide definerte hull med syntetiske data og evaluere hele oppgaven.
-
Dataløp: Gjenoppretting av eksisterende logger
Start her når: Loggene finnes, men teamet kan ikke gjenbruke dem.
Typisk resultat: Et kildekart, en eksklusjonslogg, et normalisert episodesett, synkroniseringsresultater, manifest og en eksport testet i lasteren.
-
Dataløp: Innsamling av demonstrasjoner fra den virkelige verden
Start her når: Erfaringen som trengs, har aldri blitt tatt opp.
Typisk resultat: Godkjente demonstrasjoner med observasjoner, tilstand, handlinger, oppgavekontekst, utfall, rettighetsdokumentasjon og leveransemetadata.
-
Dataløp: Strukturering og annotering av episoder
Start her når: Opptakene finnes, men oppgavebetydningen mangler.
Typisk resultat: Episoder med oppgaver, faser, interaksjoner, kontakt, endringer i objekttilstand, utfall, feil, inngrep og gjenoppretting.
-
Dataløp: Utfylling av hull med syntetiske og simulerte data
Start her når: Ekte data avdekker et målbart hull i dekningen.
Typisk resultat: Genererte varianter rettet mot et navngitt hull, med registrert genereringsopphav og det samlede settet testet på tilbakeholdte ekte scenarier.
-
Dataløp: Evaluering av fysisk KI
Start her når: Teamet kan ikke se om systemet har blitt bedre.
Typisk resultat: Et tilbakeholdt sett, en kjøreprotokoll, en feiltaksonomi, en måleparameterrapport, en akseptlogg og en regresjonstestpakke.
-
Dataløp: En repeterbar datadrift
Start her når: Disse trinnene må bli en repeterbar drift.
Typisk resultat: En kontrollert arbeidsflyt for data og evaluering på tvers av opptak, mottak av arkiv, kuratering, annotering, evaluering, versjonering og tilbakemelding til modellen.
Når opptak er hele jobben, gå videre til datainnsamling for fysisk KI. Når annotering er det du primært skal kjøpe, gå videre til den spesialiserte annoteringstjenesten for robotikk og industrielt maskinsyn.
EKSISTERENDE DATA
Gå gjennom eksisterende data før du bestiller mer.
Robot- og sensorarkiver inneholder ofte nyttig erfaring side om side med inkonsistente skjemaer, udokumenterte felt, blandede frekvenser, manglende kalibrering, avkortede episoder eller upålitelige utfallsmerker.
Kartlegg → dekod og avstem → utvalg testet i lasteren
Gjennomgangen avgjør om arkivet skal gjenbrukes, deler av det repareres, ubrukelige poster utelukkes, eller om bare de forholdene som fortsatt mangler skal samles inn.
En episode holder den fysiske beslutningen intakt.
Den endelige strukturen følger den faktiske roboten, sensorene, oppgaven, policyen og lasteren som skal ta imot dataene.
Strømmene avhenger av systemet og hentes fra:
Representativ episodestruktur
- Observasjoner
-
- video fra fast kamera
- egosentrisk video
- video fra håndleddskamera
- flerkamerastrømmer
- RGB
- dybde
- punktsky
- lyd der det er relevant
- Robot- og kontrollertilstand
-
- leddtilstand
- pose for endeeffektor
- gripertilstand
- basepose
- objekttilstand
- verktøytilstand
- kontrollertilstand
- sikkerhetstilstand
- Handlinger
-
- translasjon
- rotasjon
- griperkommandoer
- leddkommandoer
- navigasjonshandlinger
- verktøybruk
- kontrollmodus
- inngrep
- stopp eller nytt forsøk
- Kraft, kontakt og telemetri
-
- kraftsignaler
- taktile signaler
- kontakthendelser
- posisjonering
- utstyrstelemetri
- Oppgavekontekst
-
- oppgaveinstruksjon
- strukturert oppgavemål
- målobjekt
- destinasjon
- begrensninger
- forbudte handlinger
- definisjon av suksess
- definisjon av feil
- Tidsmodell
-
- kildeklokker
- tidsstempelenheter
- forventede frekvenser
- manglende samples
- interpolering
- kalibreringsreferanser
- tillatt forskyvning mellom strømmer
- Utfall
-
- vellykket
- delvis vellykket
- mislykket
- avbrutt
- utrygt
- ugyldig
- krevde menneskelig inngrep
- nytt forsøk startet
- gjenopprettet
- forlatt
- Feil og gjenoppretting
-
- foregående tilstand
- forsøkt handling
- feilpunkt
- årsakskategori
- inngrep
- gjenopprettingshandling
- endelig disposisjon
- Opprinnelse og aksept
-
- kilde
- rettighetsstatus
- innsamlingsprotokoll
- kalibreringslogg
- synkroniseringsstatus
- annoteringsversjon
- kontrollørstatus
- acceptance status
- datasettversjon
Tidsmodellen defineres før produksjon i full skala, den antas ikke bare fordi ordet synkronisert brukes.
Kildeklokker, tidsstempelenheter, forventede frekvenser, manglende samples, interpolering, kalibreringsreferanser og tillatt forskyvning mellom strømmer blir skrevet ned.
Feil og inngrep
er en del av dokumentasjonen.
En ren, vellykket bane viser foretrukket utførelse. Den viser ikke hvordan en feil begynner, hvilken tilstand som gikk forut, når et menneske bør gripe inn, hvilken gjenoppretting som er gyldig, eller når et nytt forsøk blir utrygt.
En nyttig feilregistrering bevarer foregående tilstand, forsøkt handling, feilpunkt, årsakskategori, inngrep, gjenopprettingshandling og endelig disposisjon. En overtakelse viser hvor autonomien sluttet å strekke til, og om episoden gikk tilbake til autonom utførelse.
Sikkerhetsmodellen avgjør hvilke feil som kan fremkalles, hvilke som bare kan observeres, og når oppgaven må stoppes.
En demonstrasjon tatt opp én gang er tatt opp under ett forhold.
Systemet må handle under alle de andre. En policy som svikter i skumringen og et opptak som mislyktes i skumringen er ulike problemer, og bare registreringen kan skille dem.
Forholdet forblir knyttet til episoden. Evalueringen kan da skille en policy som ikke generaliserer fra materiale som aldri ble tatt opp under forholdet som testes.
Hold ekte og generert
dokumentasjon atskilt.
Ekte data fastsetter fordelingen av oppgaver, miljøer og feil. Syntetiske eller simulerte data utvider deretter et navngitt kanttilfelle eller et sjeldent forhold.
Ekte grunnlinje Syntetisk dekning - Ekte grunnlinje
- Navngitt hull
- Generer
- Registrer opphav
- Evaluer på tilbakeholdte ekte data
- Godkjenn for oppgitt bruk
Syntetiske data godkjennes for en definert oppgave, ikke for volum i seg selv.
Evaluer hele oppgaven under navngitte forhold.
En enkelt samlet poengsum kan skjule hvilke objekter, scener, plattformer, operatører eller miljøer som driver feilene.
Kontrakten definerer scenariofordelingen, formelen for måleparameteren, maskinvare- og policyversjon, eksklusjoner, menneskelig kontroll og akseptterskel for den faktiske bruken.
Leveres med den godkjente versjonen / godkjente episoder · avledede data · identifikatorer · episodegrenser · oppgave- og utfallstilstander · kalibreringsreferanser · kildeopprinnelse · kvalitetsresultater · eksklusjoner · manifest · versjonshistorikk
Teamet som tar imot, får også et utvalg testet i lasteren eller en referanseeksport som åpner og leser den avtalte strukturen i målverktøykjeden. Formatstøtte kontrolleres mot kildedataene, lasteren og kundens krav før den blir en leveranseforpliktelse.
Fysisk KI omfatter
mer enn en
industriell robotcelle.
Plattform, objektgeometri, miljø, synsvinkel, sensoroppsett, operatør, kontrollmodus, nyttelast, vær, rot, feilforhold og gjenopprettingsvei betyr bare noe når de kan endre beslutningen systemet trenes eller evalueres for.
Den samme datalogikken gjelder på tvers av plattformer. Generalistpolicyer · manipulasjon · humanoider · mobile roboter · logistikk · serviceroboter · maskiner utendørs · industriell inspeksjon · menneskelig aktivitet · verdensmodeller.
Dokumentasjon teamet ditt kan kontrollere.
Teknisk og operasjonell dokumentasjon gjør dataløpet etterprøvbart. Avhengig av omfang gir et oppdrag en spesifikasjon av oppgave og beslutning, et kart over datahull, et strømskjema, en eksempelepisode, en synkroniseringsrapport, en feiltaksonomi, en annoteringsveiledning, et evalueringsscenario, en akseptmatrise, en lastertest og et versjonert manifest.
Disse artefaktene lar robotikk-, ML- og driftsteam kontrollere hvordan dataene ble laget, hva som ble utelukket, og hvorfor det godkjente materialet egner seg for den oppgitte oppgaven.
Definer kontroller for maskinvare, anlegg og data i driftsavtalen.
Registreringer fra fysisk KI kan eksponere personer, arbeidsplasser, proprietært utstyr og driftsatferd. Hvert oppdrag fastsetter tilgang til roboter og sensorer, operatørroller, tillatelser på stedet, sikkerhetsprosedyre, rettigheter, tillatt bruk, sikkerhetsgjennomgang, oppbevaring, sletting, avvikshåndtering og overlevering.
Dette kontrollaget gjør datadriften etterprøvbar.
Send oppgaven, plattformen og flaskehalsen i dataene.
Den første briefen kan være kort. Ta med roboten eller plattformen, oppgaven, miljøet den skal brukes i, eksisterende data, tilgjengelige sensorer, målmodell eller -policy, kjente feil, nødvendig variasjon og tidsplan hvis du vet dem. YPAI bruker briefen til å finne det første dataløpet, den leverte enheten, pilotspørsmålet og dokumentasjonen som trengs for en leveransebeslutning.
Spørsmål før den første samtalen
- Vi har allerede robotlogger. Trenger vi ny innsamling?
- Ikke nødvendigvis. Start med en gjennomgang av arkivet. Riktig svar kan være å bruke de eksisterende dataene, reparere deler av dem, legge til manglende kontekst eller bare samle inn de oppgaveforholdene som fortsatt mangler.
- Hvordan skiller dette seg fra annotering for robotikk?
- Data for fysisk KI dekker hele driften på tvers av kildegjenoppretting, innsamling, episodebygging, annotering, utfylling av hull, evaluering og leveranse. Den spesialiserte annoteringstjenesten eier detaljert merking og kontroll når det er det primære kjøpet.
- Kan feil og gjenoppretting tas med?
- De kan tas med når oppgaven og sikkerhetsmodellen tillater innsamling, eller når feil allerede finnes i kildeloggene. Omfanget definerer hvilke feil som kan fremkalles, hvilke som bare kan observeres, og når et menneske må gripe inn.
- Kan ekte og syntetiske data kombineres?
- Ja, for et definert hull i dekningen. Ekte og genererte kilder holdes atskilt, og det samlede settet testes mot tilbakeholdte ekte scenarier før det godkjennes for den tiltenkte bruken.
- Hvilket leveranseformat får vi?
- Formatet følger kildedataene, mållasteren og arbeidsflyten som tar imot. YPAI kontrollerer om formatet er gjennomførbart under avgrensningen og kan inkludere et utvalg testet i lasteren eller en referanseeksport i akseptpakken.
Relatert
- Datainnsamling for fysisk KISamle inn demonstrasjoner fra roboter og mennesker som strukturerte, treningsklare episoder.
- Annotering for robotikkMerking av persepsjon, oppgavefaser og aksept.
- VideodataBred innsamling av video og multimodale data.
- SensorfusjonSynkronisert multimodal annotering.
- LiDAR og 3DAnnotering av punktskyer og romlige data.
- DatainnsamlingTilpasset innsamling av video, bilder, sensordata og multimodale data.
- Connected DeliveryData og evaluering koblet til implementering.
- PiloterValider oppgaven, resultatet og akseptplanen før du skalerer.