Ein Trainer mit verschiedenen Roboter-Behandlungen: Kann man sich mit anderen Roboter ausbilden?
Was die Forschung über das Training an mehreren Robotertypen zeigt, um die Verallgemeinerung zu verbessern <unk> Open X-Embodiment, DROID, RT-2-X, Octo und praktische Co-Training-Einstellung mit Code-Beispielen.
Teil von: [Roboterleasing-Leitfaden]
[← Blog]
Das Training an 22 verschiedenen Robotertypen verbessert die Leistung an einem 23.
Die Kreuzkörperhypothese
Die zentrale Behauptung des Kreuzkörperlernens: Das Training einer Roboterpolitik auf Daten aus mehreren verschiedenen Robotertypen
Die Hypothese ist praktisch wichtig, weil Roboterdaten teuer sind. Bei RCSV benötigen 100 Expertendemonstrationen auf einem [OpenArm]
Offene X-Body: Die Beweise
Das Open X-Embodiment-Projekt (Padalkar et al., 2023; RTX-Kollaborationspapier) ist der umfassendste Test dieser Hypothese. Das wichtigste Ergebnis: RT-X, das auf dem vollständigen Multi-Incarnation-Datenpaket ausgebildet wurde, übertraf die Leistung von Einzelroboter-Spezialisten bei überholten Verallgemeinerungsarbeiten um etwa 50%.
Das Multi-Inkarnationsmodell wurde keine zusätzlichen Informationen über den Zielroboter erhalten
Detaillierte Datenstatistik
| Dataset | Robot Types | Episodes | Skills | Environments | Format |
|---|---|---|---|---|---|
| Open X-Embodiment (OXE) | 22 | 160,266 | 527 | 160+ | RLDS (TensorFlow) |
| DROID | 22 (different set) | 76,000 | 350+ | 564 | RLDS + HDF5 |
| RoboSet | 3 | 100,000+ | 12 | 100+ | HDF5 |
| Bridge V2 | 1 (WidowX) | 60,096 | 13 | 24 | RLDS |
| RT-1 Robot Action | 1 (Everyday Robot) | 130,000 | 700+ | 1 | RLDS |
| RCSV Shared Pool | 5 | 25,000+ | 40+ | 30+ | LeRobot HDF5 |
Der OXE-Datensatz ist ungleich verteilt: etwa 60% der Episoden stammen aus nur 3 Robotertypen (WidowX, Franka, Everyday Robot). Die verbleibenden 19 Robotertypen tragen jeweils 1.000
RT-2-X: Die VLA, die nachgewiesen hat, dass Kreuzkörper funktionieren
RT-2-X erweitert das Vision-Language-Action-Modell RT-2 um den gesamten OXE-Datenbestand zu verbrauchen.
- +50% bei neuen Bewertungen: Aufgaben, die neue Objektkombinationen oder räumliche Beziehungen erfordern, die nicht direkt in den Trainingsdaten für einen einzelnen Roboter enthalten sind.
- +25% bei Aufgaben im Vertrieb: Auch bei Aufgaben, die in Einrobotdatensätzen gut vertreten sind, war das Multi-Incarnation-Modell besser.
- Null-Shoot-Transfer: RT-2-X konnte Roboter nicht in seinem Trainings-Set mit einer höheren Erfolgsrate steuern, obwohl die Leistung wesentlich unter den fein abgestimmten Modellen lag.
Die Parameterzahl 55B ist ein wichtiger Kontext: Dies ist kein Modell, das Sie auf einer Labor GPU ausführen können. Die Inferenz erfordert mehrere A100s oder H100s. Die praktische Version für die meisten Teams ist ein kleineres Modell (1
Octo: Das praktische Modell der Kreuzkörper-Grundlage
Octo (Ghosh et al., 2024) ist das Modell, mit dem die meisten Teams für den Kreuz-Inkarnationsübertragung beginnen sollten. Es ist ein 93M-Parametertransformator, der auf 800K Roboter-Episoden aus dem OXE-Datensatz ausgebildet ist, speziell für effiziente Feintuning für neue Roboter und Aufgaben entwickelt wurde.
- Architektur: Transformer mit modalitätsspezifischen Tokenisierern für Bilder (ViT), Sprache (T5) und proprioception (MLP).
- Genaue Ausrichtungskosten: 50
200 Demonstrationen + 2 4 Stunden auf einer einzigen A100-GPU. - ** Leistung:** Octo, das mit 100 Zielroboter-Demos optimiert wurde, übertrifft das Training mit den gleichen 100 Demos bei Pick-and-Place-Aufgaben auf WidowX, Franka und anderen getesteten Plattformen um 25
40% von Null. - Inferenzgeschwindigkeit: 93M-Parameter laufen bei ~15 Hz auf einem einzelnen RTX 4090 oder bei ~8 Hz auf einem Jetson AGX Orin
schnell genug für die Echtzeit-Manipulationsteuerung.
# Fine-tuning Octo on your own robot data (simplified)
# Requires: pip install octo-model jax[cuda]
from octo.model.octo_model import OctoModel
from octo.data.dataset import make_single_dataset
# Load pre-trained cross-embodiment model
model = OctoModel.load_pretrained("hf://rail-berkeley/octo-base")
# Load your target robot dataset (LeRobot HDF5 or RLDS format)
target_dataset = make_single_dataset(
dataset_kwargs={
"name": "my_openarm_dataset",
"data_dir": "/data/openarm_pick_place/",
"image_obs_keys": {"primary": "image_wrist", "secondary": "image_overhead"},
"state_obs_keys": ["joint_positions"],
"language_key": "language_instruction",
},
traj_transform_kwargs={"window_size": 2},
frame_transform_kwargs={"image_size": (256, 256)},
)
# Fine-tune with new action head for your robot's action space
# OpenArm: 6 joint positions + 1 gripper = 7D action space
model = model.finetune(
target_dataset,
action_dim=7,
action_head="diffusion", # or "mse" for deterministic
learning_rate=3e-4,
batch_size=256,
num_steps=50_000, # ~2 hours on A100
save_dir="./octo_openarm_finetuned/",
)
DROID: Maßstab innerhalb des Kreuzkörpers
Das DROID-Papier (Khazatsky et al., 2024) erweiterte diese Analyse mit einem Schwerpunkt auf dem Maßstab. 76K-Trajektorien über 22 Roboter und 564 Umgebungen. UR5 beispielsweise).
Die Verbesserung war nicht einheitlich
Vorteil der Übertragung durch Robotersamkeit
| Source Robot | Target Robot | Similarity | Success Rate (Target Only) | Success Rate (+Source Data) | Improvement |
|---|---|---|---|---|---|
| WidowX-XL | WidowX 250 | Very High | 62% | 81% | +19% |
| Franka Panda | UR5e | High (both 7-DOF) | 55% | 68% | +13% |
| OpenArm | WidowX 250 | Moderate (6 vs 6 DOF) | 62% | 71% | +9% |
| Franka Panda | WidowX 250 | Moderate (7 vs 6 DOF) | 62% | 70% | +8% |
| Mobile Manipulator | WidowX 250 | Low | 62% | 65% | +3% |
| Allegro Hand | WidowX 250 | Very Low | 62% | 62% | +0% |
Das Muster ist klar: Transfervorteile korrelieren mit kinematischer Ähnlichkeit, aber auch mit moderater Ähnlichkeit sorgen Roboter für eine sinnvolle Verbesserung. Die praktische Erkenntnis ist, dass, wenn Sie 100 Demonstrationen auf Ihrem Zielroboter haben, die Hinzufügung von 1.000+ Demonstrationen von kinematisch ähnlichen Robotern Ihnen Leistung gleichwertig zu 150
Warum Körperübertragung funktioniert
Es gibt drei Mechanismen, die dafür verantwortlich sind:
1. Gemeinsame visuelle Funktionen: Unabhängig davon, welcher Roboter eine Aufgabe ausführt, sind die visuellen Eingaben (Objekte, Arbeitsplatz, Aufgabenstruktur) ähnlich. Ein Modell, das auf 22 Robotertypen ausgebildet wurde, entwickelt reichhaltige visuelle Darstellungen für manipulationsrelevante Funktionen
2. Aktionsraumabstraktion in VLAs: Vision-Language-Action-Modelle wie OpenVLA und RT-2-X repräsentieren Aktionen in einem tokenierten, abstrakten Raum, der das Aufgabenwissen von spezifischen Roboterkinematiken teilweise entkoppelt. Wenn Aktionen in Behälter (z.B. 256 Behälter pro Dimension) diskretisiert werden, hat ein "bewegen Sie sich nach rechts" Token von einer WidowX eine ähnliche semantische Bedeutung wie ein "bewegen Sie sich nach rechts" Token von einer Franka, obwohl die zugrunde liegenden gemeinsamen Flugbahnen völlig unterschiedlich sind.
3. Sprache-Erdung: Wenn Spracheinstructions Teil des Modell-Eingabes sind (wie in RT-2-X, Octo, OpenVLA), lernt das Modell eine gemeinsame Sprache-zu-Verhalten-Mapping über Ausführungsformen hinweg. "Pick up the red cup" bedeutet dasselbe, unabhängig davon, welcher Roboter ihn ausführt. Diese gemeinsame sprachliche Grundlegung bietet eine universelle Aufgabenrepräsentation, die sich perfekt über Ausführungsformen hinweg übertragen, auch wenn die Motoren-Exekutionsstrategien unterschiedlich sind.
Bei Versagen des Übertrags
- Viele verschiedene Kinematik: Der Transfer zwischen den fahrbaren mobilen Plattformen und den festgestützten Armen ist nahe Null. Die Abweichung des Aktionsraums ist zu groß, um die gemeinsamen visuellen Merkmale zu überwinden. Die Aktionen einer mobilen Basis (vx, vy, omega) geben keine nützlichen Gradientinformationen für die gemeinsamen Positionsaktionen eines 6-DOF-Arms.
- Unvereinbarkeit des Grippertyps: Daten von parallelen Kiefergriffen werden schlecht an Saugkupproboter und umgekehrt übertragen. Das Kontaktinteraktionsmodell ist zu unterschiedlich. Parallel Kieferdaten werden auch (auch mit unterschiedlichen Fingerschichtungen) gut an andere Parallelkieferroboter übertragen, aber das von Parallelkieferdemonstrationen gelernte Fang-Phase-Verhalten ist aktiv schädlich für das auf Saugbasierte Greifen.
- DOF-Skalaunpass: Daten von 7-DOF-Armen übertragen sich gut auf andere 7-DOF-Arme, aber schlecht auf 4-DOF-Arme. Der Dimensionaldurchschnitt schafft Aktionsraumdeckungsprobleme: Ein 7-DOF-Arm kann Objekte aus vielen Winkeln nähern, während ein 4-DOF-Arm eingeschränkt ist. Politiken, die auf 7-DOF-Daten ausgebildet sind, entwickeln Ansatzstrategien, die für 4-DOF-Hardware physisch unerreichbar sind.
- Schnelligkeits- und Dynamikverschiedenheit: Daten aus Hochgeschwindigkeitsindustriellen Armen (Zykluszeiten < 0,5 s) werden schlecht auf Forschungsarme mit 3
5s Zykluszeiten für dieselbe Aufgabe übertragen. Die visuellen Beobachtungen können Frame-by-Frame ähnlich aussehen, aber die Aktionssequenzen haben unterschiedliche Rhythmen. - ** Kontaktreiche versus kontaktfreie:** Daten aus kontaktreichen Aufgaben (Schrauben, Einfügen, Polieren) bieten einen minimalen Transfervorteil für kontaktfreie Aufgaben (Reaching, visuelle Inspektion) und umgekehrt.
Praktische Ko-Training-Einrichtung
Wenn Sie Daten über Kreuzkörperungen für Ihren Roboter und Ihre spezifischen Aufgaben nutzen möchten, ist hier der Workflow, der die besten Ergebnisse in unserer Erfahrung bei RCSV erzielt:
Schritt 1: Wählen Sie Ihre Datenbanken aus
Aus der OXE-Kollektion wählen Sie Datenmengen von Robotern mit ähnlichem DOF- und Grifftyp für Ihr Ziel aus. Für einen 6-DOF-Arm mit parallelem Kiefergriffer (wie [OpenArm](
Schritt 2: Normalisieren Sie die Aktionsräume
Verschiedene Roboter haben unterschiedliche gemeinsame Konfigurationen, so dass Roh-Gelenkspaß-Aktionen nicht übertragen. Der Standardansatz ist, alle Aktionen in End-Effektor-Raum umzuwandeln: (dx, dy, dz, droll, dpitch, dyaw, gripper). Diese 7D-Delta-End-Effektor-Repräsentation ist universell über alle Einarms-Manipulatoren mit jeder DOF-Zahl und jedem Griff. Die Umwandlung verwendet die Vorwärtskinematik jedes Robots (URDF + FK-Lösung) und ist ein einmaliger Vorverarbeitungsschritt pro Datensatz.
# Action space normalization: joint space -> EE delta space
import numpy as np
from lerobot.common.robot_devices.robots.configs import OpenArmConfig
def joint_to_ee_delta(joint_actions, joint_states, robot_config):
"""Convert joint-space actions to end-effector delta actions.
This normalization is required for cross-embodiment training:
different robots have different joints but share the same
6D end-effector space.
"""
ee_deltas = []
for i in range(len(joint_actions)):
# FK at current state
ee_current = robot_config.forward_kinematics(joint_states[i])
# FK at next state (current + action)
ee_next = robot_config.forward_kinematics(
joint_states[i] + joint_actions[i, :robot_config.n_joints]
)
# Delta in EE space
delta_pos = ee_next[:3] - ee_current[:3]
delta_rot = quaternion_to_axis_angle(
quaternion_multiply(ee_next[3:7], quaternion_inverse(ee_current[3:7]))
)
gripper = joint_actions[i, -1] # gripper action passes through
ee_deltas.append(np.concatenate([delta_pos, delta_rot, [gripper]]))
return np.array(ee_deltas)
Schritt 3: Datensatzmischungsstrategie
Das Mischverhältnis zwischen Ihren Zielrobot-Daten und den Daten zwischen den einzelnen Daten ist von großer Bedeutung. Zu viele Daten überwältigen die detaillierten Details der einzelnen Daten, zu wenig bringt keinen Nutzen.
- <50 Zieldemos: Mix 1:10 (Target:cross). Das Modell braucht die Vielfalt, weil es sehr wenig Zielsignal hat.
- 50
200 Zieldemos: Mix 1:5. Dies ist der Schatzpunkt, an dem Kreuzverkörperung den relativsten Nutzen bietet. - 200
1,000 Zieldemos: Mix 1:2. Cross-embodiment Daten helfen, aber der Randnutzen nimmt ab. Konzentrieren Sie sich nur auf hochwertige Cross-embodiment Datensätze. - >1.000 Zieldemos: Cross-embodiment-Vor-Training ist immer noch vorteilhaft (nutzen Sie es als Initialisierung), aber das Mischen während der Fein-Tuning bietet eine abnehmende Rendite.
Schritt 4: Ausbildung
Verwenden Sie Verkörperungsbedingte Ausbildung: Fügen Sie eine lernbare Verkörperungs-Token (eines pro Roboter-Typ) zur Eingabe-Sequenz des Modells hinzu. Dies ermöglicht es dem Modell, Verkörperungs-spezifische Verhaltensmuster zu lernen, während er visuelle und Aufgabenrepräsentationen über alle Roboter teilt. Während der Schlussfolgerung auf Ihrem Zielroboter verwendet das Modell den Verkörperungs-Token Ihres Roboters. Kosten: ~ 8 Stunden auf einem A100 für einen vollständigen Co-Training-Run mit 200K gemischten Episoden.
Mit HuggingFace LeRobot
Die zugänglichste Möglichkeit, Cross-Incarnation Co-Training zu betreiben, ist heute durch HuggingFace's LeRobot-Framework, das standardisierte Datenladen, Modelltraining und Evaluationsinfrastruktur bietet:
# LeRobot co-training config (YAML)
# Save as: configs/co_train_openarm.yaml
dataset:
# Primary: your target robot data
repo_id: "svrc/openarm_pick_place_v2"
mix_datasets:
# Cross-embodiment data, weighted by similarity
- repo_id: "lerobot/bridge_v2"
weight: 0.3 # WidowX - moderate similarity
- repo_id: "lerobot/droid_franka"
weight: 0.2 # Franka - moderate-high similarity
- repo_id: "svrc/shared_pool_6dof"
weight: 0.4 # RCSV pool - high similarity
action_space: "ee_delta_7d" # Normalized EE space
policy:
name: "diffusion"
pretrained: "lerobot/diffusion_oxe_base" # OXE pre-trained
chunk_size: 16
n_obs_steps: 2
n_diffusion_steps: 100
training:
batch_size: 256
learning_rate: 1e-4
num_epochs: 200
eval_freq: 10
device: "cuda"
# Run: python lerobot/scripts/train.py --config configs/co_train_openarm.yaml
Die Verteilung der Nutzen zwischen den Körpern
Um zu wissen, ob die Daten von Kreuzkörpern Ihrem Fall tatsächlich helfen, führen Sie ein kontrolliertes Experiment durch:
- Basislinie: Trainieren Sie nur auf Ihren Zielroboterdaten.
- +Kreuzverkörperung: Trainieren Sie Ihre Zieldaten mit Kreuzverkörperungsdaten gemischt.
- +Vor-Behandelt init: Initialisieren Sie von einem Octo/OpenVLA-Checkpoint, dann passen Sie nur Ihre Zieldaten an.
- ** Vollsteuerung:** Initialieren Sie an einem vorgeübten Kontrollpunkt und mischen Sie Daten über die Verkörperung während der Fein-Tuning-Verarbeitung.
In unserer Erfahrung schlägt Option 3 (vorgeübter init + nur zielgerichtete Feinschaltung) Option 2 (random init + gemischte Ausbildung) für die meisten Teams. Die vorgeübten visuellen Darstellungen sind die primäre Quelle des Transfervorteils und kommen "kostenlos" vom Checkpoint. Option 4 bietet eine weitere Verbesserung von 5
RCSV-Empfehlung: Für Teams mit <200 Demonstrationen an ihrem Zielrobot beginnen Sie mit Option 3: Laden Sie den Octo-Basis-Checkpoint herunter, passen Sie Ihre Daten für 2
Aktuelle Beschränkungen
- Negativer Transfer ist real: Die Hinzufügung von Daten von sehr unterschiedlichen Robotern (verschiedene DOF, unterschiedlicher Grifftyp, unterschiedliche Aufgabenbereich) kann die Leistung im Vergleich zu zielgerichtetem Training schädigen.
- Aktionsraum-Normalisierung verliert Informationen: Die Umstellung auf EE Delta-Raum verwirft Redundanzlösungsinformationen (wie sich die Arm-/Schulterkonfiguration ändert). Bei Aufgaben, bei denen die Armkonfiguration wichtig ist (in unordentliche Umgebungen zu gelangen, Hindernisse mit dem Ellbogen zu vermeiden), ist die Fein-Tuning des Gelenks nach dem Co-Training des EE-Raums manchmal notwendig.
- Datenbestandvarianzen: OXE- und DROID-Datenbestände unterscheiden sich enorm in der Demonstrationsqualität. Einige der beitrittswilligen Labors hatten Expertenbetreiber; andere verwendeten Neulingbetreiber oder teilweise automatisierte Systeme.
- Liniär: Mehr Daten über Querschnittkörper bedeuten verhältnismäßig mehr Schulungsrechen. Für ein Startup mit einer einzigen GPU dauert ein vollständiger OXE-Co-Training 3
5 Tage. Vorgeschulte Checkpoints (Octo, OpenVLA) amortizieren diese Kosten die Open-Source-Community hat bereits die Rechnungsrechnung bezahlt. - Sim-to-Real-Gap-Compounds: Wenn Ihre Cross-Incarnation-Daten Simulation-Daten enthalten (was einige OXE-Datensätze tun), fügt die Sim-to-Real-Gap-Untergrund-Gap-Untergrund-Gap-Untergrund. Filtern Sie Simulation-abgeleitete Datensätze aus Ihrem Cross-Incarnation-Mix, es sei denn, Sie haben überprüft, dass sie bei Ihrer spezifischen Aufgabe helfen.
Die Zukunft: Modelle der Universalroboter-Stiftung
Die Bahn ist klar: Das Feld der Robotik bewegt sich auf Basismodelle hin, die auf Daten von Hunderten von Robotertypen, Millionen von Episoden und Tausenden von Aufgaben ausgebildet wurden. Wenn diese Modelle reif werden, wird der Übertragung von Kreuzkörpern von "sicheres Co-Training-Rezept" zu "Download Checkpoint, fine-tune 30 Minuten, deploy" verschieben. Wir sind noch nicht dort im Jahr 2026, aber die Lücke schließt sich schnell.
Für die heutigen Teams ist der praktische Rat: Sammeln Sie Ihre Daten in standardisierten Formaten (LeRobot HDF5 oder RLDS), mit vollständigen Kalibrierungsmetadaten, damit Sie von diesen Grundmodellen profitieren können, wenn sie verfügbar werden.
Datenaustausch über RCSV
RCSV unterhält einen gemeinsamen Datensatzpool für Kreuzkörper, zu dem Kunden beitragen und daraus ziehen können. Wenn Sie Demonstrationsdaten über die [Datendienste] von RCSV erfassen, haben Sie die Möglichkeit, anonymisierte Demonstrationen im gemeinsamen Pool zu beitragen, um den Zugriff auf Daten für Kreuzkörper vor der Ausbildung von anderen Plattformen zu erhalten. Das reduziert den Effektivbedarf an Daten pro Aufgabe, indem Sie den Transfersffekt zwischen den Inkarnationen nutzen. Der Pool enthält derzeit mehr als 25.000 Episoden auf den Plattformen OpenArm, WidowX, Franka, UR5e und Unitree Z1, wobei wöchentlich neue Beiträge hinzugefügt werden.
Für Teams, die Daten, die auf ihrer eigenen Hardware gesammelt werden, einbringen möchten, bietet RCSV eine Validierung Pipeline, die die Formatkonformität, die Demonstrationsqualität (Gleisenheit, Erfolgsrate, Kamerakalibrierung) und die Privatsphäre (keine identifizierbaren Informationen in Kameraansichten) überprüft. Validierte Beiträge verdienen Datenkredite, die gegen alle Daten im Pool eingelöst werden können.
Verwandte Lesungen
Aktpolitik erklärt · Gemässliche Fehler beim Nachahmen · Start mit Teleoperation · RCSV Datensätze · Robotikglossarie
Leverage-Kreuzkörpervorbildung
Der gemeinsame Datensatz des RCSV liefert Daten über 5 Roboterplattformen.
[Erforschung von Datendiensten] [