Beginnen Sie mit der Erfahrung, die Ihrem physischen System fehlt.
Die Lücke ist eine Aufgabe, ein Objekt, eine Umgebung oder ein Wiederherstellungszustand, den die Trainingsdaten nicht abbilden, oder Logs aus Jahren, die niemand zuverlässig laden, vergleichen oder wiederverwenden kann.
Ein Rohbild zeichnet die Bewegung auf, nicht die Aufgabe, der sie diente.
Ein Kamerabild zeigt, was das System beobachtet hat. Ein Zustandslog zeigt eine Gelenkposition. Eine Aktionsspur zeigt einen Befehl.
Die gelieferte Episode hält Beobachtungen, Roboterzustand, Aktionen, Aufgabenkontext, Timing und Ergebnis miteinander verbunden.
Dieser Zusammenhang ermöglicht es Ihrem Team, eine Entscheidung zu trainieren, zu vergleichen, zu prüfen und zu reproduzieren.
Vereinbaren Sie, was als eine gelieferte Einheit zählt.
Eine Stunde Teleoperation kann mehrere nützliche Episoden enthalten, eine lange Episode oder überwiegend Aufbau und ungültige Versuche. Eine kurze Sequenz aus Fehler und Wiederherstellung kann mehr Entscheidungswert haben als wiederholte fehlerfreie Ausführung.
Ihre Einheit kann sein:
- eine abgenommene Episode
- eine Aufgabendemonstration
- ein synchronisierter Zeitabschnitt
- eine Teleoperationssitzung
- eine Sequenz aus Fehler und Wiederherstellung
- ein evaluierter Policy-Durchlauf
- ein Datensatz-Release
Messen Sie Preis, Fortschritt, Qualität und Abnahme in derselben Einheit.
Beginnen Sie bei Ihrem tatsächlichen Engpass.
YPAI unterstützt Robotikteams dabei, bestehende Daten wiederherzustellen, fehlende reale Demonstrationen zu erfassen, Episoden zu strukturieren und zu annotieren, definierte Lücken mit synthetischen Daten zu schließen und die vollständige Aufgabe zu evaluieren.
-
Datenpfad: Wiederherstellung bestehender Logs
Beginnen Sie hier, wenn: Ihre Logs existieren, aber das Team kann sie nicht wiederverwenden.
Typisches Ergebnis: Eine Quellenübersicht, ein Ausschlussprotokoll, ein normalisierter Episodensatz, Abgleichsergebnisse, ein Manifest und ein mit dem Loader getesteter Export.
-
Datenpfad: Erfassung realer Demonstrationen
Beginnen Sie hier, wenn: Die benötigte Erfahrung wurde nie aufgezeichnet.
Typisches Ergebnis: Abgenommene Demonstrationen mit Beobachtungen, Zustand, Aktionen, Aufgabenkontext, Ergebnissen, Rechtenachweisen und Liefermetadaten.
-
Datenpfad: Strukturierung und Annotation von Episoden
Beginnen Sie hier, wenn: Aufzeichnungen existieren, aber die Aufgabenbedeutung fehlt.
Typisches Ergebnis: Episoden mit Aufgaben, Phasen, Interaktionen, Kontakt, Änderungen des Objektzustands, Ergebnissen, Fehlern, Eingriffen und Wiederherstellung.
-
Datenpfad: Schließen von Lücken durch Synthese und Simulation
Beginnen Sie hier, wenn: Reale Daten zeigen eine messbare Abdeckungslücke.
Typisches Ergebnis: Generierte Varianten gegen eine benannte Lücke, mit dokumentierter Herkunftskette der Generierung und einem Test des kombinierten Satzes an zurückgehaltenen realen Szenarien.
-
Datenpfad: Evaluierung physischer KI
Beginnen Sie hier, wenn: Das Team kann nicht erkennen, ob sich das System verbessert hat.
Typisches Ergebnis: Ein zurückgehaltener Testsatz, ein Durchführungsprotokoll, eine Fehlertaxonomie, ein Kennzahlenbericht, ein Abnahmeprotokoll und eine Regressionssuite.
-
Datenpfad: Ein wiederholbarer Datenbetrieb
Beginnen Sie hier, wenn: Diese Phasen sollen zu einem wiederholbaren Betrieb werden.
Typisches Ergebnis: Ein kontrollierter Workflow für Daten und Evaluierung über Erfassung, Archivübernahme, Kuratierung, Annotation, Evaluierung, Versionierung und Modellrückmeldung.
Wenn die Erfassung der gesamte Auftrag ist, lesen Sie weiter unter Datenerfassung für physische KI. Wenn Annotation der eigentliche Beschaffungsgegenstand ist, lesen Sie weiter beim spezialisierten Annotationsservice für Robotik und industrielle Bildverarbeitung.
BESTEHENDE DATEN
Prüfen Sie bestehende Daten, bevor Sie neue beauftragen.
Roboter- und Sensorarchive enthalten oft nützliche Erfahrung neben inkonsistenten Schemata, undokumentierten Feldern, gemischten Frequenzen, fehlender Kalibrierung, abgeschnittenen Episoden oder unzuverlässigen Ergebnislabels.
Inventarisieren → dekodieren und abgleichen → mit dem Loader getestete Stichprobe
Die Prüfung entscheidet, ob das Archiv wiederverwendet oder teilweise repariert wird, ob unbrauchbare Datensätze ausgeschlossen werden oder ob nur die noch fehlenden Bedingungen erfasst werden.
Eine Episode hält die physische Entscheidung intakt.
Die endgültige Struktur folgt dem tatsächlichen Roboter, den Sensoren, der Aufgabe, der Policy und dem empfangenden Loader.
Die Streams hängen vom System ab und stammen aus:
Repräsentative Episodenstruktur
- Beobachtungen
-
- Video von fester Kamera
- egozentrisches Video
- Video von Handgelenkkamera
- Multikamera-Streams
- RGB
- Tiefe
- Punktwolke
- Audio, sofern relevant
- Roboter- und Controller-Zustand
-
- Gelenkzustand
- Pose des Endeffektors
- Greiferzustand
- Basispose
- Objektzustand
- Werkzeugzustand
- Controller-Zustand
- Sicherheitszustand
- Aktionen
-
- Translation
- Rotation
- Greiferbefehle
- Gelenkbefehle
- Navigationsaktionen
- Werkzeugnutzung
- Steuerungsmodus
- Eingriff
- Stopp oder erneuter Versuch
- Kraft, Kontakt und Telemetrie
-
- Kraftsignale
- taktile Signale
- Kontaktereignisse
- Positionierung
- Gerätetelemetrie
- Aufgabenkontext
-
- Aufgabenanweisung
- strukturiertes Aufgabenziel
- Zielobjekt
- Zielort
- Randbedingungen
- unzulässige Aktionen
- Definition von Erfolg
- Definition von Fehlschlag
- Zeitmodell
-
- Quelluhren
- Zeitstempeleinheiten
- erwartete Frequenzen
- fehlende Samples
- Interpolation
- Kalibrierungsreferenzen
- zulässiger Versatz zwischen Streams
- Ergebnis
-
- erfolgreich
- teilweise erfolgreich
- fehlgeschlagen
- unterbrochen
- unsicher
- ungültig
- menschlicher Eingriff erforderlich
- erneuter Versuch eingeleitet
- wiederhergestellt
- abgebrochen
- Fehler und Wiederherstellung
-
- vorheriger Zustand
- versuchte Aktion
- Fehlerpunkt
- Ursachenkategorie
- Eingriff
- Wiederherstellungsaktion
- abschließende Einstufung
- Herkunftsnachweis und Abnahme
-
- Quelle
- Rechtestatus
- Erfassungsprotokoll
- Kalibrierungsnachweis
- Synchronisierungsstatus
- Annotationsversion
- Prüfstatus
- acceptance status
- Datensatzversion
Das Zeitmodell wird vor der Skalierung auf Produktionsumfang definiert und nicht durch das Wort „synchronisiert“ stillschweigend vorausgesetzt.
Quelluhren, Zeitstempeleinheiten, erwartete Frequenzen, fehlende Samples, Interpolation, Kalibrierungsreferenzen und zulässiger Versatz zwischen Streams werden schriftlich festgelegt.
Fehler und Eingriffe
gehören zu den Belegen.
Eine saubere Erfolgstrajektorie zeigt die bevorzugte Ausführung. Sie zeigt nicht, wie ein Fehler beginnt, welcher Zustand ihm vorausging, wann ein Mensch eingreifen sollte, welche Wiederherstellung gültig ist oder wann ein erneuter Versuch unsicher wird.
Ein nützlicher Fehlerdatensatz bewahrt den vorherigen Zustand, die versuchte Aktion, den Fehlerpunkt, die Ursachenkategorie, den Eingriff, die Wiederherstellungsaktion und die abschließende Einstufung. Eine Übernahme zeigt, wo die Autonomie nicht mehr ausreichte und ob die Episode zur autonomen Ausführung zurückkehrte.
Das Sicherheitsmodell legt fest, welche Fehler herbeigeführt werden dürfen, welche nur beobachtet werden dürfen und wann die Aufgabe anhalten muss.
Eine einmal aufgezeichnete Demonstration ist unter einer einzigen Bedingung aufgezeichnet.
Das System muss unter allen anderen handeln. Eine Policy, die in der Dämmerung versagt, und eine Aufnahme, die in der Dämmerung misslang, sind verschiedene Probleme, und nur der Datensatz kann sie auseinanderhalten.
Die Bedingung bleibt an die Episode gebunden. Die Evaluierung kann dann eine Policy, die nicht generalisiert, von Material unterscheiden, das nie unter der getesteten Bedingung erfasst wurde.
Halten Sie reale und generierte
Belege unterscheidbar.
Reale Daten legen die Verteilung von Aufgaben, Umgebungen und Fehlern fest. Synthetische oder simulierte Daten erweitern dann einen benannten Grenzfall oder eine seltene Bedingung.
Reale Basis Synthetische Abdeckung - Reale Basis
- Benannte Lücke
- Generieren
- Herkunftskette dokumentieren
- An zurückgehaltenen realen Daten evaluieren
- Für den angegebenen Zweck abnehmen
Synthetische Daten werden für eine definierte Aufgabe abgenommen, nicht um der Menge willen.
Evaluieren Sie die vollständige Aufgabe unter benannten Bedingungen.
Ein einzelner Gesamtwert kann verbergen, welche Objekte, Szenen, Embodiments, Bediener:innen oder Umgebungen die Fehler verursachen.
Der Vertrag legt Szenarioverteilung, Kennzahlformel, Hardware- und Policy-Version, Ausschlüsse, menschliche Prüfung und Abnahmeschwelle für den tatsächlichen Einsatz fest.
Wird mit der abgenommenen Version geliefert / abgenommene Episoden · Derivate · Kennungen · Episodengrenzen · Aufgaben- und Ergebniszustände · Kalibrierungsreferenzen · Herkunftskette der Quellen · Qualitätsergebnisse · Ausschlüsse · Manifest · Versionshistorie
Das empfangende Team erhält außerdem eine mit dem Loader getestete Stichprobe oder einen Referenzexport, der die vereinbarte Struktur in der Ziel-Toolchain öffnet und liest. Die Formatunterstützung wird anhand der Quelldaten, des Loaders und der Kundenanforderung geprüft, bevor sie zu einer Lieferzusage wird.
Physische KI umfasst
mehr als eine
industrielle Roboterzelle.
Embodiment, Objektgeometrie, Umgebung, Blickwinkel, Sensorkonfiguration, Bediener:in, Steuerungsmodus, Nutzlast, Wetter, Unordnung, Fehlerbedingung und Wiederherstellungspfad zählen nur dann, wenn sie die trainierte oder evaluierte Systementscheidung verändern können.
Dieselbe Datenlogik gilt über Embodiments hinweg. Generalistische Policies · Manipulation · Humanoide · mobile Roboter · Logistik · Serviceroboter · Maschinen im Freien · industrielle Inspektion · menschliche Aktivität · Weltmodelle.
Nachweise, die Ihr Team prüfen kann.
Technische und betriebliche Nachweise machen den Datenpfad prüfbar. Je nach Umfang entsteht in einem Auftrag eine Aufgaben- und Entscheidungsspezifikation, eine Datenlückenkarte, ein Stream-Schema, eine Beispielepisode, ein Synchronisierungsbericht, eine Fehlertaxonomie, ein Annotationsleitfaden, ein Evaluierungsszenario, eine Abnahmematrix, ein Loader-Test und ein versioniertes Manifest.
Mit diesen Artefakten können Robotik-, ML- und Betriebsteams prüfen, wie die Daten entstanden sind, was ausgeschlossen wurde und warum das abgenommene Material für die angegebene Aufgabe geeignet ist.
Legen Sie Hardware-, Standort- und Datenkontrollen im Betriebsvertrag fest.
Datensätze physischer KI können Personen, Arbeitsplätze, proprietäre Geräte und betriebliches Verhalten offenlegen. Jeder Auftrag regelt Zugang zu Roboter und Sensoren, Rollen der Bediener:innen, Standortgenehmigungen, Sicherheitsverfahren, Rechte, zulässige Nutzung, Sicherheitsprüfung, Aufbewahrung, Löschung, Umgang mit Problemen und Übergabe.
Diese Kontrollebene macht den Datenbetrieb prüfbar.
Bringen Sie Aufgabe, Embodiment und Datenengpass mit.
Ihr erstes Briefing kann kurz sein. Nennen Sie Roboter oder Embodiment, Aufgabe, Einsatzumgebung, vorhandene Daten, verfügbare Sensoren, Zielmodell oder Ziel-Policy, bekannte Fehler, benötigte Variation und Zeitrahmen, soweit Sie diese kennen. YPAI bestimmt anhand dieses Briefings den ersten Datenpfad, die gelieferte Einheit, die Fragestellung des Pilotprojekts und die Nachweise, die für eine Lieferentscheidung nötig sind.
Fragen vor dem ersten Gespräch
- Wir haben bereits Roboterlogs. Brauchen wir eine neue Erfassung?
- Nicht unbedingt. Beginnen Sie mit einer Archivprüfung. Die richtige Antwort kann sein, die bestehenden Daten zu nutzen, einen Teil davon zu reparieren, fehlenden Kontext zu ergänzen oder nur die Aufgabenbedingungen zu erfassen, die noch fehlen.
- Worin unterscheidet sich das von Robotik-Annotation?
- Daten für physische KI umfassen den breiteren Betrieb über Quellenwiederherstellung, Erfassung, Episodenaufbau, Annotation, Schließen von Lücken, Evaluierung und Lieferung. Die spezialisierte Annotationsseite übernimmt detaillierte Label- und Prüfarbeit, wenn diese der eigentliche Beschaffungsgegenstand ist.
- Können Fehler und Wiederherstellung einbezogen werden?
- Sie können einbezogen werden, wenn die Aufgabe und das Sicherheitsmodell die Erfassung zulassen oder wenn Fehler bereits in den Quelllogs vorhanden sind. Der Umfang legt fest, welche Fehler herbeigeführt werden dürfen, welche nur beobachtet werden dürfen und wann ein Mensch eingreifen muss.
- Lassen sich reale und synthetische Daten kombinieren?
- Ja, für eine definierte Abdeckungslücke. Reale und generierte Quellen bleiben unterscheidbar, und der kombinierte Satz wird vor der Abnahme für den vorgesehenen Einsatz an zurückgehaltenen realen Szenarien getestet.
- In welchem Lieferformat erhalten wir die Daten?
- Das Format richtet sich nach den Quelldaten, dem Ziel-Loader und dem empfangenden Workflow. YPAI prüft die Machbarkeit des Formats bei der Abgrenzung und kann eine mit dem Loader getestete Stichprobe oder einen Referenzexport in das Abnahmepaket aufnehmen.
Verwandte Themen
- Datenerfassung für physische KIDemonstrationen von Robotern und Menschen als strukturierte, trainingsfertige Episoden erfassen.
- Robotik-AnnotationLabeling für Wahrnehmung, Aufgabenphasen und Abnahme.
- VideodatenBreite Erfassung von Video- und multimodalen Daten.
- SensorfusionSynchronisierte multimodale Annotation.
- LiDAR und 3DPunktwolkenannotation und räumliche Daten.
- DatenerfassungKundenspezifische Erfassung von Video-, Bild-, Sensor- und multimodalen Daten.
- Connected DeliveryDaten und Evaluierung verbunden mit der Implementierung.
- PilotprojekteValidieren Sie Aufgabe, Ergebnis und Abnahmeplan vor der Skalierung.