Mobile ALOHA-Setup-Guide: Hardware, Software und erste Aufgaben

[← Blog] T23)

Mobile ALOHA ist eine Teleoperationsplattform für den gesamten Körper auf einer Radbasis.

Was ist Mobile ALOHA

Mobile ALOHA, entwickelt von Tony Zhao und anderen an der Stanford Universität, erweitert das ursprüngliche ALOHA (A Low-Cost Open-Source Hardware System für Bimanual Teleoperation) durch die Montage des Bimanual-Arm-Systems auf einer allgegenwärtigen mobilen Basis. Dies ermöglicht die Teleoperation des ganzen Körpers: Ein Betreiber steuert gleichzeitig beide Arme und die Basis und zeigt Aufgaben an, die neben der Manipulation auch Bewegung erfordern, wie Türen zu öffnen, Wagen zu schieben, Tische zu reinigen, während man sich bewegt, und zwischen den Räumen zu navigieren.

Der Schlüsselforschungsbeitrag von Mobile ALOHA zeigt, dass Ko-Training auf verschiedenen statischen ALOHA-Daten sowie eine kleine Anzahl von mobilen Demonstrationen (so wenig wie 50 Episoden) zu Politiken führt, die sich überraschend gut auf mobile Manipulationsarbeiten verallgemeinern. Dies bedeutet, dass die teuren mobilen Demonstrationen durch billigere statische, bi-manuale Daten ergänzt werden, wodurch der Ansatz praktischer wird, als er zunächst erscheint.

Mobile ALOHA ist zu einer der am häufigsten replizierten Forschungsplattformen im Bereich Roboter-Lernen geworden. Mehrere Labors, Unternehmen und Maker-Gruppen haben Varianten gebaut, und das ursprüngliche Hardware-Design ist vollständig Open Source.

Hardware-Bill von Materialien

Ein komplettes Mobile ALOHA-System erfordert vier Hardwarekategorien: die mobile Basis, die Manipulationsarme (Führer und Anhänger), das Kamera-System und der Rechenstack.

** Mobilfunkbasis:**

AgileX Tracer Differenzantriebsbasis: $4,500-5,500 je nach Konfiguration. Dies ist die Plattform, die im Originalpapier verwendet wurde. Alternativen sind die AgileX Scout Mini ($6,800) für höhere Nutzlast oder der Clearpath Jackal ($20,000+) für Forschungsgrade-Odometrie, aber der Tracer ist die Standardwahl für kostengemäßige Bauten.
Ein individueller Montagerahmen (Aluminium-Extrusion 80/20 oder ähnlich): 300 bis 600 US-Dollar für Materialien und Bearbeitung.

Followerarme (die Roboterarme, die Aufgaben ausführen):

2x Trossen Robotics ViperX 300 S2 6-DOF Arme: $ 4.800 je, $ 9.600 insgesamt. Dies sind die Standard-Follower-Arme für ALOHA-Builds. Sie verwenden Dynamixel XM / XH-Servos der Serie mit Position, Geschwindigkeit und aktuellem (Torque) Feedback.
2x benutzerdefinierte Griffmontage: 200-400 USD je. Der Standard ALOHA Griff ist ein einfacher parallel-Kriegelgripper mit Dynamixel XL330 Servo. 3D-gedruckte Fingerabhänger sind für die meisten Aufgaben geeignet.

Führerarme (durch den Fernbedienungsteilnehmer gehalten):

2x Trossen Robotics WidowX 250 S 6-DOF Arme: $3.100 pro, $6.200 insgesamt. Die WidowX ist leichter (0,53 kg) und kürzer erreichbar als die ViperX, so dass es für den sitzenden oder stehenden Betreiber bequem ist, während mehrstündiger Datenerhebungssitzungen zu halten.
Die Anlagebeugungen für den Führerarm: 100-200 USD. An der Taille auf dem Mobilplattformrahmen montiert, so dass der Betreiber hinter der Plattform geht und den Führerarm hält.

Kamerasystem:

2x Intel RealSense D405 Handgelenkkameras: 300 Dollar je, insgesamt 600 Dollar.
1x Intel RealSense D435 Oberkamera: $350. Auf dem Rahmenmast für eine oben-unter-Bildung des Arbeitsraums montiert.
Kamera- und USB-Kabel: 100-150 Euro.

Berechnung:

Auf dem Arbeitsplatz: Intel NUC 13 Pro oder gleichwertiger Mini-PC mit i7, 32 GB RAM, 1 TB NVMe SSD: 800-1,200 USD. Dies bearbeitet Echtzeit-Telebetriebssteuerung, Kamera-Fassung und Datenaufzeichnung. Es benötigt keine GPU; das Training erfolgt offline.
Training Workstation (separat, nicht auf dem Roboter): Jede Desktop- oder Cloud-Instanz mit NVIDIA RTX 4090 oder A100 für ACT/Diffusion Policy-Training. Budget $2.000-3.000 für eine lokale Trainingsmaschine oder nutzen Sie Cloud-GPU-Instanzen bei $1-4/Stunde.

Gesamtkostenverteilung

Category	Cost Range
Mobile base (AgileX Tracer)	$4,500-5,500
Follower arms (2x ViperX 300 S2)	$9,600
Leader arms (2x WidowX 250 S)	$6,200
Grippers and mounting	$700-1,200
Camera system (3x RealSense)	$950-1,100
Onboard compute	$800-1,200
Frame, cables, misc hardware	$500-800
Total (robot only)	$23,250-25,600
Training workstation (separate)	$2,000-3,000
Total (complete system)	$25,250-28,600

Dies ist die Gesamtkosten für den Bau eines Mobile ALOHA-Systems von Grund auf. Das ursprüngliche Stanford-Papier zitierte etwa 32.000 Dollar für ihre spezifische Konfiguration; der Unterschied spiegelt die Komponentenpreise 2026 wider und die Verwendung des Basis-Tracers anstatt der höheren Konfigurationen. Es ist zu beachten, dass dies nicht die Arbeit des Betreibers zur Datenerhebung einschließt, die die vorherrschenden laufenden Kosten für jedes Imitationslernprojekt ist.

Software-Stack: ROS2, ACT und LeRobot

Der Mobile ALOHA Software-Stack besteht aus drei Schichten, die jeweils eine bestimmte Rolle spielen.

Echtzeitsteuerungsschicht (ROS2 Humble auf Ubuntu 22.04). Die Niedrigsteuerung läuft als ROS2-Knoten: ein Dynamixel-Treiberknoten für jeden Arm, ein Basis-Treiberknoten für die AgileX-Plattform und Kamera-Treiberknoten für jede RealSense-Kamera. Die kritische Voraussetzung ist, dass alle Knoten eine synchronisierte Uhr (Chrony oder PTP verwenden) teilen und dass die Führer-zu-Folger-Befehlsschleife bei 50 Hz mit einer Latenz von weniger als 10 ms läuft.

Teleoperation und Aufnahmeliste. Ein Aufnahmeliste abonniert alle gemeinsamen Zustandsthemen und Kamerabildthemen, stempelt sie gegen eine gemeinsame Uhr und schreibt synchronisierte Episoden in HDF5-Dateien. Jede Episode enthält: 14-DOF-Gebundene Positionen (7 pro Arm) bei 50 Hz, 14-DOF-Gebundene Geschwindigkeiten, Grifföffnungen, drei Kamera-Streams bei 30 Fps, Basisgeschwindigkeitsbefehle und Episodendaten (Task-Label, Erfolgsflagge, Operator-ID). LeRobot von Hugging Face liefert standardisierte Aufnahmeskripte für ALOHA-Stil-Hardware, die diese Synchronisierung korrekt verarbeiten.

Ausbildungs-Layer (offline, auf der Ausbildungsstation). ACT (Action Chunking with Transformers) ist der Standard-Ausbildungsalgorithmus für ALOHA-Daten. ACT prognostiziert einen Teil zukünftiger Aktionen (typischerweise 100 Zeitschritte) aus der aktuellen Beobachtung, indem eine Transformator-Encoder-Decoder-Architektur mit CVAE (bedingter variabler Auto-Encoder) zur Aktionsvorhersage verwendet wird. Das Training dauert 4-8 Stunden auf einem einzelnen RTX 4090 für einen 200-Episoden-Datensatz.

Erste Aufgaben zum Lernen

Beginnen Sie mit diesen Aufgaben in der Schwierigkeitsfolge.

Aufgabe 1: stationäre, zweimanuale Übergabe. Der Roboter nimmt mit einem Arm ein Objekt auf und überträgt es dem anderen Arm. Die Basis bleibt stationär. Dies validiert die zweimanuale Kalibrierung und Koordinierung ohne die Komplexität der Basisbewegung hinzuzufügen. Ziel: 50 Demonstrationen, 60-70% politische Erfolgsquote beim ersten Training.

Task 2: Tischbussen (Tischreinigung). Der Roboter nimmt Objekte aus einem Tisch auf und legt sie in einen Müll auf der Roboterplattform und fährt dann zu einem Abgabeort. Dies führt neben der Manipulation auch die Basisbewegung ein. Ziel: 50 mobile Demonstrationen plus Ko-Training-Daten, 50-60% Erfolgsrate.

Aufgabe 3: Türen öffnen. Eine Tür näher kommen, den Griff greifen, ziehen/drücken, während die Bewegung der Basis koordiniert wird. Dies ist eine kanonische mobile ALOHA-Aufgabe, die die Koordination des gesamten Körpers zeigt: Die Basis muss sich mit dem Arm synchron bewegen, wenn die Tür schwingt. Dies ist wesentlich schwieriger als das Bussen des Tisches, da sich die Kontaktdynamik während der gesamten Bahnbahne ändert. Ziel: 100 Demonstrationen, Erfolgsrate von 40-50% anfangs.

** Aufgabe 4: Gegenstandübergabe an einen Menschen.** Der Roboter navigiert zu einem Menschen, erstreckt einen Arm und freisetzt ein Objekt, wenn der Mensch es ergreift. Dies erfordert die Erkennung der menschlichen Gegenwart und die Zeit des Freisetzens. Ziel: 75 Demonstrationen mit unterschiedlichen menschlichen Positionen, Erfolgsrate von 45-55%.

Häufige Fehler bei der Einrichtung

Dies sind die Fehler, die RCSV am häufigsten in Labors beim Bau ihres ersten Mobile ALOHA-Systems sieht.

Skipping-Leiterarm Gravitationskompensation. Ohne Gravitationskompensation fühlen sich die Leiterarme für den Betreiber schwer. Die Müdigkeit des Betreiber beginnt nach 30 Minuten und die Datenqualität verschlechtert sich stark. Konfigurere Dynamixel-Stromlimits auf 30-50% des Nennmoments im Gravitationskompensationsmodus.
WiFi für Führer-Follower-Kommunikation. Das Routen der Führer-Follower-Steuerungslöcke über WiFi führt zu 20-100 ms variabler Latenz. Das System fühlt sich langsam an und der Betreiber überkompensert, was zu schwierigen Demonstrationen führt.
Synchronisierung der Kamera ignoriert. Wenn Handgelenkkameras und die Oberkamera nicht synchronisiert sind, enthalten die aufgezeichneten Beobachtungen eine zeitliche Fehlanpassung. Bei 30 fps beträgt eine 2-Bildfehlanpassung 66 ms, was für eine schnelle Manipulation bedeutend ist. Verwenden Sie Hardware-Trigger-Synchronisierung (RealSense Multi-Camera-Sync-Modul, $50) oder bei einer Mindestzeitstempel-basierten Ausrichtung während des Datenladen.
Die Basis während statischer Aufgaben nicht zu sperren. Wenn Sie nur Manipulationsdaten sammeln, um mobile Demonstrationen zu erweitern (der Ko-Training-Ansatz), schalten Sie die Basismotorbremse ein oder verwenden Sie Software-Geschwindigkeitsgrenzen, um zu verhindern, dass die Basis abtriebt.
Unzureichendes Kabelmanagement. Loose Kabel werden in Möbeln gefangen, in Armbändern während der Bewegung gefangen und während der Folgen gelegentlich abgeschaltet. Eine abgeschlossene Kamera in der Mitte der Folge beschädigt die gesamte Folge.
Sammeln von Daten mit inkonsistenten Aufgabendefinitionen. "Reinig die Tabelle" ist zu vage. "Holt die blaue Tasse von Position A und leg sie in den grauen Behälter" ist spezifisch genug.

Schritt für Schritt Zusammenstellungsleitfaden

Dieser Abschnitt behandelt die physische Montagefolge. Budget 2-3 volle Tage für die Montage, wenn Sie Erfahrung mit Robotik-Hardware haben, oder 4-5 Tage, wenn dies Ihre erste Bauweise ist.

Schritt 1: Vorbereitung der Basisplattform (2-4 Stunden). Entfernen Sie den AgileX Tracer und überprüfen Sie alle Komponenten mit der Verpackungsliste. Ladet die Batterie vollständig auf, bevor Sie weitermachen (4-6 Stunden von leeren). Montieren Sie den Tracer auf eine flache Oberfläche und überprüfen Sie die allgerichtete Bewegung, indem Sie das AgileX-Diagnosetool ausführen. Flash die neueste Firmware aus dem AgileX GitHub-Repository, bevor Sie weitermachen.

Schritt 2: Montagerahmenbau (4-8 Stunden). Aluminium-Extrusion (80/20-Serie 10 oder gleichwertig) zu den in den Stanford ALOHA CAD-Zeichnungen angegebenen Abmessungen schneiden. Der Rahmen hat drei kritische Montageoberflächen: zwei Armbasenplatten (eine links, eine rechts, 40 cm zwischen Zentrum und Zentrum getrennt) und eine vertikale Mast für die Oberkamera. Alle Armmontageoberflächen müssen mit einer Ebene von 1 mm zusammen sein. Beim Montage wird die Höhe eines Maschinenbaueres verwendet.

Schritt 3: Folgearminstallation (3-4 Stunden pro Arm). Setzen Sie jeden ViperX 300 S2 mit den zur Verfügung gestellten M6-Schrauben an seine Basisplatte. Drehmoment auf 6 Nm. Verbinden Sie den U2D2 (USB-zu-Dynamixel-Adapter) mit dem mit Dasi-Kette versehenen Servo-Bus des Arms. Laufen Sie den Dynamixel-Wizard aus, um die Kommunikation mit allen 7 Servos pro Arm (6 Armgelenke + 1 Griff) zu überprüfen. Wenn ein Servo nicht reagiert, überprüfen Sie die TTL-Kabelung für lose Verbindungen an jedem Gelenk. Setzen Sie jeden Servo auf Position-Current (Multi-Turn) -Steuerungsmodus. Konfigurieren Sie die PID-Gewinne auf die von Trossen empfohlenen Standardwerte: P=800, I=0, D=0 für die Positionsteuerung; Anpassen Sie erst nach Überprüfung der Grundbetrieb.

Schritt 4: Anbringung des Führerarms (2-3 Stunden pro Arm). Setzen Sie jede WidowX 250 S auf die Führerarmstützen in der Taillehöhe. Die Führerarme müssen so positioniert sein, dass der Betreiber sie bequem hinter der Plattform halten kann. Typische Montagehöhe: 90-100 cm vom Boden entfernt. Konfigureren Sie die Führerarmservos im Standpunktmodus für Gravitationskompensation. Setzen Sie die Stromgrenzen auf 40% des Nennmoments für einen komfortablen Betrieb. Testen Sie die Gravitationskompensation, indem Sie jeden Führerarm in verschiedenen Posen freisetzen - er sollte ungefähr stationär bleiben und über 30 Sekunden weniger als 5 Grad treiben.

Schritt 5: Grippermontage (1-2 Stunden pro Greifer). Die Parallel-Klauch-Greifer aus den bereitgestellten Teilen oder 3D-gedruckten benutzerdefinierten Fingerabhängern montieren. Setz den Betriebsbereich des Griffers: 0 (vollständig geschlossen) bis 1200 (vollständig geöffnet) in Dynamixel-Positions-Einheiten. 3D-Fingerabdrücke in TPU (flexibles Filament) für eine verbesserte Festnahme an glatten Objekten. Pad-Dicke: 2-3 mm bietet gute Konformität ohne übermäßige Verformung.

Schritt 6: Kamerainstallation (2-3 Stunden). Die beiden D405-Handkameras werden mit den vorgegebenen oder benutzerdefinierten Halterungen auf den Folgerarmhandkammern angebracht. Der D405 hat eine Mindesttieftengrenze von 7 cm, die ihn für die Manipulation in der Nähe geeignet macht. Die D435-Oberkopfkamera wird auf dem Mast auf 80-120 cm über dem Arbeitsplatz angebracht.

Schritt 7: Berechnungsinstallation (1-2 Stunden). Installieren Sie die Intel NUC oder gleichwertige Anlage auf der Rahmenbasisplatte, die mit Anti-Vibrations-Manten gesichert ist (wesentlich - die Basisbewegung überträgt Schwingungen, die USB-Verbindungen lockern können). Verbinden Sie alle USB-Geräte: 2x U2D2 (Nacharm), 2x U2D2 (Führarm), 3x RealSense-Kameras, 1x AgileX-Basis. Verwenden Sie einen USB 3.0-Hub für die Kameras, um ausreichende Bandbreite zu gewährleisten.

ROS2-Software-Stack-Einstellung

Der Software-Stack erfordert Ubuntu 22.04 mit ROS2 Humble. Nutzen Sie nicht Ubuntu 24.04 oder ROS2 Iron/Jazzy - die Interbotix-Pakete sind ab 2026 nicht vollständig in neueren Versionen validiert.

Basis-OS-Installation:

# Install ROS2 Humble (follow official docs, then):
sudo apt install ros-humble-desktop python3-colcon-common-extensions

# Install Interbotix ROS2 packages for arm control
curl 'https://raw.githubusercontent.com/Interbotix/interbotix_ros_manipulators/main/interbotix_ros_xsarms/install/amd64/xsarm_amd64_install.sh' > xsarm_install.sh
chmod +x xsarm_install.sh && ./xsarm_install.sh -d humble

# Install RealSense SDK and ROS2 wrapper
sudo apt install ros-humble-librealsense2* ros-humble-realsense2-camera

# Install AgileX ROS2 driver
cd ~/colcon_ws/src
git clone https://github.com/agilexrobotics/agx_sdk_ros2.git
cd ~/colcon_ws && colcon build --symlink-install

# Install LeRobot for data recording and training
pip install lerobot

Konfiguration und Kalibrierung:

Setzen Sie die Dynamixel-Bow-Rate auf 1M (1000000) auf allen Servos mit Dynamixel Wizard.
Kalibrieren Sie Servo-Null-Positionen: Bewegen Sie jeden Arm in seine mechanische Heimposition und erfassen Sie die Encoder-Offset-Punkte.
Konfigureren Sie die Führer-Follower-Karte: Jede Führer-Gelenke zeigt 1:1 auf die entsprechende Folger-Gelenke. Das Beispiel der Interbotix-Teleoperation bietet diese Karte aus dem Feld, überprüft aber, dass alle 7 Gelenke (einschließlich Greifer) vor der Datenerhebung korrekt verfolgt werden.
Setzen Sie Zeit-Synchronisierung ein: Installieren Sie Chrony und konfigurieren Sie alle Knoten, um die gleiche Systemuhr zu verwenden. Die Zeitstempel der Kamera müssen für saubere Daten innerhalb von 5 ms von gemeinsamen Zeitstempeln liegen.

Kamera-Kalibrierungsprozedur

Die Kalibrierung der Kameras ist nicht optional. Nichtkalibrierte Kameras verursachen eine räumliche Fehlanpassung der aufgezeichneten Daten, die die Politikleistung um 10-25% abschwächt.

Einheitliche Kalibrierung: Die RealSense-Kameras werden mit Fabrikkalibrierung versorgt, diese Kalibrierung kann sich jedoch im Laufe der Zeit oder nach physischen Auswirkungen abschwächen. Überprüfen Sie die Eingliederung durch das RealSense-Selbstkalibrierungstool. Wenn der Fehler bei der Wiederverwerfung 0,5 Pixel übersteigt, laufen Sie die Kalibrierung am Chip erneut aus. Für höhere Genauigkeit können Sie die T5 ROS2-Paket mit einem 9x6-Schachbrett (25 mm Quadrat) verwenden, um benutzerdefinierte Inhalte zu berechnen.

Extrinsiche Kalibrierung (Transformation von Kamera zu Basis): Die Position und Orientierung jeder Kamera gegenüber dem Roboter-Basisrahmen müssen genau gemessen werden. Für die Handgelenkkameras wird dies vor allem durch die vorwärtsgehende Kinematik des Arms sowie die Kamera-Anlage-Offset bestimmt. Für die Oberkamera verwenden Sie einen ArUco-Marker, der in einer bekannten Position im Roboter-Basisrahmen gelegt wird und das PnP-Problem lösen, um die Kamera-zu-Basis-Transformation zu berechnen. Überprüfen Sie die Kalibrierung, indem Sie den Arm in eine bekannte Position befehlen und überprüfen, ob die Kameraprojektion des End-Effektors mit der erwarteten Pixelposition innerhalb von 5 Pixel übereinstimmt.

** Multi-Kamera-Synchronisierung:** Verbinden Sie die RealSense D435 und D405 Kameras mit dem Intel Multi-Camera Sync Cable (separativ verfügbar, ca. $ 50). Konfigureren Sie eine Kamera als Master und die anderen als Slaves. Dies sorgt dafür, dass alle Kameras die Frames gleichzeitig erfassen, und beseitigt die zeitliche Fehlanpassung, die sonst 30-60 ms Zittern zwischen den Kameraströmen verursacht. Ohne Hardware-Synchronisierung müssen Sie eine zeitmarkenbasierte Ausrichtung in Ihrer Datenladen-Pipeline verwenden, die weniger zuverlässig ist.

Erste Datenerhebung: Validierungsaufgabe

Bevor Sie eine echte Forschungsarbeit ausführen, sammeln Sie einen Validierungsdatensatz, um die gesamte Pipeline von Ende zu Ende zu überprüfen.

** Aufgabe Definition:** Nehmen Sie einen Tennisball von der Mitte des Tisches und legen Sie ihn in eine Schüssel 30 cm nach rechts. Dies ist die einfachste zweibrochige Aufgabe: Ein Arm nimmt den Ball auf, während der andere Arm die Schüssel stabil hält. Wenn Ihr System mit 50 Demonstrationen nicht zu 80% erfolgreich bei dieser Aufgabe ist, gibt es ein Hardware- oder Kalibrierungsproblem, das behoben werden muss, bevor Sie weitermachen.

Sammlungsverfahren:

Stellen Sie den Tennisball für die ersten 20 Demonstrationen (Fixed-Position Validierung) in die gleiche Position.
Die Position des Balls innerhalb eines Radius von 20 cm für die nächsten 30 Demonstrationen (Positionsvielfalt) variieren.
Jede Demonstration sollte 15 bis 30 Sekunden aktive Teleoperation dauern. Ablehnen Sie Episoden, in denen der Ball fallen gelassen wird, die Platzierung der Schale verpasst wird oder der Betreiber eine Korrekturbewegung länger als 2 Sekunden macht.
Erfassen Sie alle Daten mit LeRobots T6-Skript: T7

**Ausbildung und Bewertung:**Ausbildung ACT auf den 50 Demonstrationen mit LeRobot-Vorgaben. Das Training sollte in 1-2 Stunden auf einem einzigen RTX 4090 abgeschlossen werden. Wenn weniger als 40% liegen, überprüfen Sie vor der Erhebung weiterer Daten Folgendes: Kamerakalibrierungsgenauigkeit, Lead-Follower-Tracking-Latenz, Zeitstempel-Synchronisierung und Datenaufzeichnung Vollständigkeit (keine abgestürzten Rahmen).

Drehmoment-Spezifikationen und Sicherheit

Überspannte Schrauben streifen die Fäden in Aluminium-Extrusion.

Connection	Torque (Nm)	Notes
Frame extrusion joints (M8)	10-12	Use threadlocker on vibrating joints
Arm base mounting (M6)	6	Check monthly for loosening
Camera mount (M4)	2-3	Easy to strip; use calibrated driver
Greifer finger pads (M3)	1-1.5	3D-printed parts; low torque to avoid cracking
Base-to-frame (M8)	12-15	Critical for base stability; double-check after first drive test

** Sicherheitsgründe:** Die ViperX-Arme haben ein ausreichendes Drehmoment, um Verletzungen zu verursachen. Stellen Sie immer Softwaregebunden (in der Interbotix YAML-Konfiguration festgelegt) ein, um zu verhindern, dass die Arme mit dem Betreiber, dem Rahmen oder einander in Kontakt treten. Setzen Sie bei den ersten Tests Geschwindigkeitsgrenzen auf 1,0 Rad/s und erhöhen Sie sie erst nach Überprüfung eines kollizionsfreien Betriebs auf 1,5 Rad/s. Implementieren Sie einen Notfallstop-Button (Hardware-E-Stop, der mit der Dynamixel-Stromversorgung verbunden ist), der die Servo-Stromversorgung sofort abschaltet.

Wartung und Fehlerbehebung

Regelmäßige Wartung verhindert Ausfallzeiten bei der Datenerfassung.

Vor jeder Sitzung (5 min): Überprüfen Sie Kabelverbindungen, überprüfen Sie die Kamerafeeds, testen Sie den Führer und den Nachfolger auf 3 Posen, überprüfen Sie den Akkuwert (minimum 40% Aufladung für eine 2-stündige Sitzung).
Wöchentlich: Überprüfen Sie alle Rahmenbolzen, um sich zu lockern. Reinigen Sie die Kameraobjektive mit Mikrofiberstoff. Überprüfen Sie, ob die Servomperatur nach einem 1-Stunden-Run unter 60°C liegt (überprüfen Sie über den Dynamixel Wizard). Backup der gesammelten Daten auf einen zweiten Laufwerk.
Monatlich: Neukalibrieren Sie die Kamera-Extrinsics (die Oberkamera-Festung kann über einen Monat des Betriebs 1-2 mm abweichen). Inspektieren Sie Dynamixel-Servokabels auf Verschleiß an den Gelenken. Aktualisieren Sie ROS2-Pakete, wenn Sicherheitspatches vorhanden sind.
** Häufige Fehlerbehebung:** Wenn ein Servo in der Mitte der Sitzung nicht mehr reagiert, ist es wahrscheinlich überhitzt. Warten Sie 10 Minuten, bis es abgekühlt ist. Wenn das Problem anhält, überprüfen Sie das TTL-Kabel an diesem Gelenk.

Aufzeichnung der Daten

Die korrekte Daten-Aufzeichnungskonfiguration bestimmt, ob Ihre gesammelten Demonstrationen tatsächlich eine nutzbare Politik ausbilden.

Frecording Frequency. Aufzeichnen Sie die gemeinsame Zustände bei 50 Hz (Standard für ALOHA-Klasse-Systeme). Kamera-Behäuse bei 30 fps. Wenn Sie Kraft-Torks-Sensoren verwenden (optional, aber empfohlen für kontaktreiche Aufgaben), aufzeichnen Sie bei 500 Hz und nehmen Sie eine Nachprobenprobe auf 50 Hz während des Datenladen, um die gemeinsame Zustandsfrequenz zu entsprechen.

Aktionsraum-Konfiguration. ACT erwartet absolute gemeinsame Positionsziele als Aktionen. Jeder Aktionsvektor ist 14-dimensionaler: 7 Gelenke pro Arm (6 Armgelenke + 1 Griff). Die Gelenkepositionen sind in Radianen, und die Grifföffnung ist in Dynamixel-Positions-Einheiten (0-4095, auf den physischen Bereich gemappt). Die Aufzeichnung der Aktion in der Zeitstufe t entspricht der gemeinsamen Position, auf die der Nachfolgerarm in der Zeitstufe t befohlen wurde, nicht der Position, in der er gemessen wurde.

Episodendaten. Jede HDF5-Episodendatei sollte Folgendes enthalten:

T8: Form (T, 14), d-Typ float32 -- Befehlsgefäße bei jeder Zeitstufe
T9: Form (T, 14), d-Typ float32 -- gemessene Gelenkpositionen
T10: Form (T, 14), d-Typ float32 -- gemessene Gelenksgeschwindigkeiten
T11: Form (T, 480, 640, 3), dtype uint8 -- Oberkamera
T12: Form (T, 480, 640, 3), d-Typ uint8
T13: Form (T, 480, 640, 3), dType uint8
T14: Form (T, 14), dtype float32 - Servo-Strom-Lesewerte (optional, nützlich für Kontakt-Ausweisungsrichtlinien)
T15: Form (T, 2), d-Typ float32 -- Basis-Linien- und Winkelgeschwindigkeitsbefehle
Attribute: Aufgabe_Name (String), Erfolg (Bool), Operator_id (String), Zeitstempel (ISO-Format)

# Verify a recorded episode for completeness
import h5py
import numpy as np

def verify_episode(filepath):
    with h5py.File(filepath, 'r') as f:
        T = f['/action'].shape[0]
        checks = {
            'action_shape': f['/action'].shape == (T, 14),
            'qpos_shape': f['/observations/qpos'].shape == (T, 14),
            'images_top': f['/observations/images/top'].shape[0] == T,
            'images_lwrist': f['/observations/images/left_wrist'].shape[0] == T,
            'images_rwrist': f['/observations/images/right_wrist'].shape[0] == T,
            'no_nan_actions': not np.any(np.isnan(f['/action'][:])),
            'joint_limits': np.all(np.abs(f['/action'][:]) < 3.14),
            'episode_length': 50 < T < 3000,  # 1-60 sec at 50Hz
        }
        for check, passed in checks.items():
            status = 'PASS' if passed else 'FAIL'
            print(f'  {check}: {status}')
        return all(checks.values())

Gemäße Aufzeichnungsfehler:

Zeitstempel-Drift: Wenn Sie Zeitstempeln für Software und nicht für Hardware-Synchronisierung verwenden, überprüfen Sie, ob die Zeitstempeln für die Kamera und die gemeinsamen Zustandstempeln innerhalb von 10 ms über die gesamte Episode hinweg ausgerichtet bleiben.
** Abfallende Kamera-Rahmen:** USB-Bandbreite-Kriterien verursachen Rahmenabfälle, wenn drei RealSense-Kameras einen USB 3.0-Hub teilen. Überprüfen Sie, ob die Anzahl der Kamera-Rahmen der erwarteten Anzahl entspricht (Episode_Dauer * 30fps +/- 1 Frame). Wenn die Frames fehlen, wird die HDF5-Episode fehlgelegte Beobachtungs-Aktionspaare haben, die das Training beschädigen.
Greifer-Aktion-Codierungsfehler: Die Greifer-Aktion muss die gleiche Codierung wie die Trainingspipeline verwenden. ACT erwartet, dass die Gripperposition im gleichen Koordinatenspielraum wie die Armgelenke liegt (Radiane gleich oder normalisiert 0-1). Ein Ungleichgewicht zwischen Aufzeichnung und Trainingscodierung ist die häufigste Ursache für "die Politik funktioniert, aber der Greifer schließt nie".

Erziehe deine erste Politik

Nach der Erhebung Ihres Validierungsdatensatzes folgt der Training einer ACT-Richtlinie bei LeRobot einem einfachen Prozess.

# Step 1: Push your dataset to HuggingFace Hub (or train locally)
# Assumes data was recorded with LeRobot's record script
python lerobot/scripts/push_dataset_to_hub.py \
  --raw-dir data/aloha_validation \
  --repo-id your-username/aloha-validation \
  --raw-format aloha_hdf5

# Step 2: Train ACT policy
python lerobot/scripts/train.py \
  policy=act \
  dataset_repo_id=your-username/aloha-validation \
  env=aloha \
  training.num_epochs=2000 \
  training.batch_size=8 \
  policy.chunk_size=100 \
  policy.kl_weight=10 \
  policy.n_obs_steps=1 \
  wandb.enable=true

# Step 3: Evaluate on the real robot
python lerobot/scripts/control_robot.py record \
  --robot-path lerobot/configs/robot/aloha.yaml \
  --fps 50 \
  --policy-path outputs/train/act_aloha_validation/checkpoints/last/pretrained_model \
  --warmup-time-s 2 \
  --episode-time-s 30 \
  --num-episodes 20

Ausbildung der wichtigsten Hyperparameter:

T16: Vorhersagt 100 zukünftige Zeitstufen (2 Sekunden bei 50 Hz). Größere Stücke reduzieren den Zusammenschlussfehler, erfordern jedoch, dass die Aufgabenbahn über die Demonstrationen hinweg konsistent ist. Beginnen Sie mit 100 und reduzieren Sie es auf 50 wenn die Politik osziliert.
T17: Steuert die Regulierung der CVAE. Höhere Werte (50-100) führen zu reibungsloseren, aber weniger präzisen Aktionen. Niedrigere Werte (1-5) führen zu schärferen Aktionen, aber Risikomodus kollabiert.
T18: Standard für das Ein-GPU-Training auf RTX 4090. Erhöhen auf 16-32 bei Einsatz von A100 mit 80 GB VRAM für eine schnellere Konvergenz.
T19: ACT konvergiert typischerweise um 1000-1500 Epochen.

Erwartete Trainingsmetriken: Die MSE-Verluste der Aktion sollten in den ersten 500 Epochen von ~0,01 auf ~0,001 zurückgehen, dann nach und nach auf ~0.0005 durch Konvergenz. Wenn die KL-Divergenz nahe Null ist, erhöhen Sie das KL-Gewicht -- die CVAE kollabiert zu einem einzigen Modus.

Die Größe wird erhöht: Von der Validierung bis zu den Forschungsarbeiten

Wenn Ihre Validierungsaufgabe (Tennisball-Pick-and-Place) >60% Erfolg erreicht hat, können Sie sicher auf kompliziertere Aufgaben skalieren.

Vergrößern Sie die Vielfalt, nicht nur das Volumen. 200 Demonstrationen mit unterschiedlichen Objektepositionen (5 cm Grille über den Arbeitsplatz) und 3-5 verschiedenen Objekten werden eine bessere Politik als 500 Demonstrationen mit einem einzigen Objekt in einer festen Position ausbilden.
Verwenden Sie Ko-Training für mobile Aufgaben. Sammeln Sie 50-100 mobile Demonstrationen und kombinieren Sie sie mit 200-500 statischen bimanuellen Demonstrationen während des Trainings. Die statischen Daten lehren Manipulationsfähigkeiten; die mobilen Daten lehren die Basiskoordination. LeRobot unterstützt das Multi-Datensatz-Training durch den T20-Parameter, der eine Liste von Datensätzen akzeptiert.
Siehe die Erfolge pro Phasen. Wenn eine Aufgabe mehrere Phasen (Anschließung, Greifen, Transport, Ort) hat, verfolgen Sie, wo Fehler auftreten. Wenn 80% der Fehler während der Greifen stattfinden, sammeln Sie HG-DAgger-Korrekturen speziell für die Greifenphase anstatt vollständige Episoden neu zu sammeln.
Haushalt für Iteration. Der typische Zyklus ist: Sammeln 50 Demos, trainieren, bewerten, Fehlermodus identifizieren, sammeln 50 weitere Demos, die auf diese Fehler abzielen, umschulen. Budget 3-5 Sammel-Schulungszyklen pro Aufgabe. Die verwalteten Daten-Sammlungsdienste von RCSV können diesen Iterationszyklus beschleunigen - unsere Betreiber sind geschult, gezielte Korrekturdemonstrationen auf der Grundlage von Analyse von Fehlern der Politik zu sammeln. Siehe unsere [Datendienste] T31) Seite für Details, beginnend bei 2.500 US-Dollar für eine Pilotkollektion.

Fehlerbehebung Häufiger Ausbildungsfehler

Wenn Ihre ACT-Richtlinie auf dem echten Roboter nicht funktioniert, verwenden Sie diesen Diagnosegleitfaden, bevor Sie Daten wieder sammeln.

Symptom	Likely Cause	Fix
Robot does not move	Action normalization mismatch	Verify action stats (mean/std) match between training and deployment config
Arms collide with each other	Demonstrationen include a wide range of arm positions; policy interpolates between modes	Add joint limit safety checks in deploy script; increase KL weight to 50 to reduce mode averaging
Policy drifts after 2-3 seconds	Control frequency mismatch: training at 50Hz, deploying at 30Hz	Match `--fps` between record and deploy commands exactly
Greifer never closes	Greifer action polarity inverted or normalized incorrectly	Check gripper min/max in the YAML config; verify open=0.0, closed=1.0 convention
Works on day 1, fails on day 2	Camera bumped or lighting changed	Rigidly mount cameras with Loctite; run calibration check at start of each session
Jerky, oscillating motion near objects	Inconsistent operator strategies across demonstrations	Use a single operator; filter episodes by trajectory smoothness; increase temporal_agg weight

Integration der mobilen Basis: Koordinierung von Bewegung und Manipulation

Die "mobile" in Mobile ALOHA ergänzt im Vergleich zu statischem ALOHA eine erhebliche Komplexität.

Basisgeschwindigkeitssteuerung. Die Tracer-Basis akzeptiert Geschwindigkeitsbefehle (linear x, angular z) bei 50Hz über den CAN-Bus. Die Basisposition des Führerrobots (überwacht durch Odometrie) wird auf Geschwindigkeitsbefehle abgegliedert: Die Verlagerung zwischen der aktuellen Position des Führers und der Position der Nachfolgersbasis erzeugt proportionale Geschwindigkeitsbefehle. Maximale sichere Geschwindigkeiten bei der Manipulation: 0,3 m/s linear, 0,5 rad/s angular. Bei Überschreiten dieser Risiken kann die Armversammlung abgeschoben oder die Geschwindigkeitsgrenze überschritten werden.

Koordinierte Aktionsfläche. Der vollständige Aktionsfläche für Mobile ALOHA ist 16-dimensionaler: 7 Gelenke pro Arm (14 insgesamt) + 2 Basisgeschwindigkeitsbefehle. Die Basisspiegelungsdimensionen sollten jedoch anders als die gemeinsamen Positionen normalisiert werden, da ihre Einheiten und Bereiche unterschiedlich sind - basierende Basisspiegelungen auf [-1, 1] basierend auf der maximalen sicheren Geschwindigkeit normalisieren.

Wann Mobilität genutzt werden sollte. Nicht jede Aufgabe profitiert von Mobilität. Mobilität nur dann ermöglichen, wenn die Aufgabe sie wirklich erfordert: Gegenstände von verschiedenen Standorten abholen, zwischen Arbeitsstationen navigieren oder Objekte außerhalb des statischen Arbeitsraums erreichen.

Kamerakonfiguration für Mobile ALOHA

Die Kamera-Einstellung ist entscheidend für die Qualität der Mobile ALOHA-Politik.

Camera	Position	Resolution	Role	Required?
Top/overhead	Center of base frame, 40-60cm above workspace	640x480 @ 30fps	Global workspace awareness, object layout	Yes (primary)
Left wrist	Left arm wrist, pointing at gripper	640x480 @ 30fps	Left arm grasp precision, contact detection	Recommended
Right wrist	Right arm wrist, pointing at gripper	640x480 @ 30fps	Right arm grasp precision, contact detection	Recommended
Front-facing	Base frame front, eye-level	640x480 @ 30fps	Navigation awareness, approach planning	Optional (mobile tasks only)

** USB-Bandbreite-Zwang:** 3 Kameras mit 640x480 30fps (unkomprimiert YUYV) benötigen ungefähr 1,1 GB/s USB-Bandbreite. Ein einzelner USB 3.0-Anschluss liefert 5 Gbps (praktisch: 3.2 Gbps). Verwenden Sie separate USB 3.0-Controller für jede Kamera - das Teilen eines einzelnen USB-Hubs verursacht Bildschirmtröpfungen. Intel RealSense D435 und Logitech C922 Kameras funktionieren beide gut. Überprüfen Sie mit T22, ob alle Kameras vor dem Datenerfassungssammeln gleichzeitig 30 fps erreichen.

** Kamera Kalibrierungs-Checkliste:** Nach dem Montieren kalibrieren Sie die In- und Extrinsic-Elemente jeder Kamera (OpenCV-Schakerbrett) im Verhältnis zum Roboter-Basisrahmen. Speichern Sie die Kalibrierung als Teil des Datensatzes. Physisch gesicherte Kameras mit einer Schleifverbindung (Loctite 222) auf den Montierschrauben - eine Kameraverschiebung von 3 mm macht alle zuvor gesammelten Daten für diesen Standpunkt ungültig. Überprüfen Sie die Kalibrierung zu Beginn jeder Sammelsitzung, indem Sie die Kameraansicht in einer bekannten Armkonfiguration beobachten.

Alternativen zum Aufbau des eigenen

Das Aufbau eines mobilen ALOHA-Systems erfordert 2-4 Wochen fokussierten Aufwand für einen erfahrenen Robotiker oder 6-8 Wochen für ein Team ohne vorherige Dynamixel- und ROS2-Erfahrung.

UMI (Universal Manipulation Interface): Ein viel günstigerer Ansatz (insgesamt 2.000-3.000 USD), der einen Handgriffer mit einer GoPro-Kamera verwendet, um Demonstrationen ohne Roboterhardware zu sammeln. UMI kann keine Basismobilitätsdaten erfassen, daher ist es kein Ersatz für Mobile ALOHA, wenn Ihre Aufgaben Bewegungsbedarf haben, aber es ist ein hervorragender Ausgangspunkt für die Manipulation der Datenerhebung.

RCSV-verwaltete Datenerhebung: Wenn Sie Daten zur mobilen Manipulation benötigen, aber die Hardware nicht bauen und warten möchten, betreibt RCSV Mobile ALOHA-Systeme und andere bi-manuale Plattformen in unserer Anlage in San Francisco. Sie definieren die Aufgabenbeschreibung und den Objektsatz; wir sammeln, annoteren und liefern den Datensatz im LeRobot- oder RLDS-Format. Dies eliminiert die Hardware-Build vollständig und gibt Ihnen professionell gesammelte Daten von Anfang an. Siehe unsere [Datendienste]T39) für Details und Preise.

Leasing a system: RCSVs Roboterleasing-Programm kann ein vollständig montiertes und kalibriertes Mobile ALOHA-System für die monatliche Leasing bereitstellen. Dies ermöglicht es Ihnen, Daten in Ihrer eigenen Umgebung zu sammeln, ohne dass Sie vorher hardwareinvestitionen machen müssen. Kontaktieren Sie uns, um die Verfügbarkeit und Konfigurationsmöglichkeiten für das Leasing zu besprechen.

Überspringen Sie die Hardware-Build

RCSV betreibt Mobile ALOHA und andere bi-manuelle Systeme für die verwaltete Datenerhebung.

[Schauen Sie Datendienste]

OpenArm

Browse the Store

Data Marketplace

Get Started with Physical AI

Wuji Teleop Glove

Unitree Go2 — Setup & SDK