Vertrieb kontaktieren
Zurück zu Blog

2026 mit der Roboterteleoperation beginnen

Ein praktischer Leitfaden zum Einstieg in die Roboterteleoperation im Jahr 2026: Hardware-Einstellung, Steuerungsoberflächen, Latenz, Datenerhebung und Teleop-Plattform von RCSV.

Teil von: [Teleoperationsführer]

Teleoperation - die Fernbedienung eines Roboters in Echtzeit - ist sowohl der schnellste Weg, um qualitativ hochwertige Trainingsdaten zu sammeln als auch die Grundlage für den modernen Robotertreffen. Ob Sie einen Datensatz für das Nachahmen des Lernens erstellen oder einen Remote-Inspection-Pilot ausführen, führt Ihnen dieser Guide alles durch, was Sie brauchen, um zu beginnen.

Was ist Roboter-Teleoperation?

Teleoperation bedeutet, dass ein menschlicher Betreiber einen Roboter mit einer Steuerungsoberfläche steuert - Befehle über ein lokales oder ferngesteuertes Netzwerk übertragen und dabei sensorisches Feedback (Video, Kraft, Position) erhalten. Im Rahmen des Roboternutzens sind teleoperate Demonstrationen der Goldstandard für die Sammlung von Trainingsdaten, da sie natürliche menschliche Strategien kodieren, die schwer manuell zu programmieren sind.

Die Teleoperationsschleife besteht aus vier Stufen: (1) Der Betreiber beobachtet die Umgebung des Roboters durch Kamera-Feeds und proprioceptive Daten, (2) der Betreiber erzeugt Befehle über eine Steuerungseinrichtung, (3) Befehle werden dem Roboter übermittelt und ausgeführt, (4) alle Beobachtungen und Aktionen werden synchron als Trainingsdaten registriert. Die Qualität jeder Stufe wirkt sich sowohl auf die Echtzeitsteuerung als auch auf die Nachströmungsanwendung des aufgezeichneten Datensatzes direkt aus.

Im Jahr 2026 dient Teleoperation zwei verschiedenen Zwecken, die sich zunehmend zusammenfügen. Die erste ist ** direkte Fernbedienung** - ein Mensch steuert einen Roboter, um nützliche Arbeiten in der Ferne (Inspektion, Wartung, gefährliche Umgebungsaufgaben) durchzuführen. Die zweite ist die Demonstrationen-Sammlung - ein Mensch bedient den Roboter speziell, um Trainingsdaten für Imitationslernungsrichtlinien wie [ACT] oder Diffusion Policy zu generieren. Die Hardware- und Softwareanforderungen überlappen sich wesentlich, weshalb Teams, die mit der Datensammlung beginnen, oft natürlich in Remote-Deployment-Fähigkeiten übergehen.

Hardware, die Sie zum Einstieg benötigen

Ein grundlegendes Teleoperations-Setup erfordert fünf Komponenten: einen Roboterarm oder eine mobile Plattform, Kameras, ein Steuergerät, einen Rechenknoten für Streaming und Logging und ein Logging-System zur Erfassung synchronisierter Beobachtungen und Aktionen. Für Teams mit OpenArm dauert die Einrichtung des RCSV-Follower-Leader weniger als 30 Minuten.

Vergleich der Steuergeräte

Die Steuerung ist die wichtigste Hardware-Auswahl, da sie die Qualitätsobergrenze Ihrer Demonstrationen bestimmt.

Control Device Latenz DOF Mapped Best For Cost Training Curve
Leader arm (ALOHA-style) <2ms local Full joint-space (6-7 DOF) Bimanual manipulation, ACT data $2,000-5,000 per pair 2-4 hours
3D SpaceMouse 5-10ms 6 DOF (Cartesian + rotation) Single-arm pick-place, slow precision $200-500 1-2 days
Data glove (e.g., Paxini, Manus) 8-15ms 15-22 DOF (hand + wrist) Dexterous hand control, finger tasks $5,000-15,000 4-8 hours
VR controller (Quest 3, VIVE) 20-40ms 6 DOF + finger triggers Mobile base + arm, humanoid whole-body $300-1,000 30 minutes

Unsere Empfehlung: Für Teams, die imitierende Lerndaten über Aufgaben der Tabelle-Manipulation sammeln, ist der Führungsarm der klare Gewinner. Die ALOHA-Stil-Leiter-Follower-Konfiguration (identielle kinematische Kette für Führer- und Anhänger-Arme) eliminiert das Retargeting-Problem vollständig - gemeinsame Positionen von der Führer-Arm-Karte direkt zu gemeinsamen Befehlen auf dem Anhänger-Arm ohne Umkehr-Kinematik-Schritt.

Für die humanoide Ganzkörper-Teleoperation (Unitree G1, Booster K1) sind VR-Controller mit Körperverfolgung der aktuelle Standard. Die Quest 3 mit Handverfolgung bietet eine ausreichende Finger-Mapping für einfache Greifen, aber Präzisionsfinger-Tätigkeiten erfordern immer noch dedizierte Handschuh-Hardware. RCSV unterstützt alle vier Schnittstellen über die [Teleop-Kontrollplattform]T9.

Warum die Latenz wichtig ist: Die 50ms-Schwelle

End-to-end-Latenz - die Zeit vom Operator-Eingang bis zur Roboterbewegung - ist die wichtigste Leistungsmessung in der Teleoperation.

  • <20ms: Der Betreiber erkennt keine Verzögerung. Der Roboter fühlt sich wie eine direkte Erweiterung der Hand an. Dies ist mit den Führungsarmen auf einer lokalen USB/Serienabbindung möglich. Die bei dieser Latenz erfassten Daten enthalten das natürlichste, flüssigste menschliche Verhalten.
  • 20-50ms: Wahrnehmbar, aber handhabbar. Betreiber passen sich innerhalb weniger Minuten an und erzeugen gute Demonstrationsdaten. Dies ist typisch für die lokale Netzwerktelebetrieb (Betreiber im gleichen Gebäude, Roboter über Ethernet verbunden).
  • 50-150ms: Die Betreiber verlangsamen sich deutlich, um die Verzögerung zu kompensieren. Die Demonstrationen werden vorsichtig und zerklüftend - der Betreiber bewegt sich, wartet auf Feedback, passt sich an, wartet wieder. Dieses "Bewegung und Warte" -Muster schaltet Politiken ein, die langsam und zögern. Die Datenqualität verschlechtert sich wesentlich über 50ms.
  • >150ms: Feine Manipulation wird unpraktisch. Nur grossartige Positionierungs- und Navigationsarbeiten funktionieren zuverlässig. Dies ist typisch für internetbasierte Fernteleoperation über Zeitzonen hinweg.

Die Latenz besteht aus vier Komponenten, die jeweils unabhängig gemessen und minimiert werden müssen:

Component Typical Range How to Minimize
Control device read 0.5-5ms USB polling at 1kHz, avoid Bluetooth
Network transport 0.1ms (local) to 200ms (cross-continent) Wired Ethernet for local; WebRTC with STUN for remote
Command processing 1-10ms Dedicated real-time thread, avoid Python GIL on control loop
Motor execution 2-20ms Use position servo mode, not velocity; 500Hz+ servo rate

Kamera-Konfiguration: Der Standard für drei Kameras

Die Kamera-Einstellung ist die zweitwirksamste Entscheidung nach der Wahl des Steuergeräts.

  • Overhead-Kamera (festige): Bietet eine oben nach unten gerichtete Arbeitsflächeansicht. Wichtig für räumliche Argumente - wo Objekte miteinander relativ sind. Steigen Sie 0,8-1,2 m über der Tischoberfläche und zeigen gerade nach unten. Auflösung: 640x480 reicht aus; höhere Auflösungen fügen Bandbreite ohne proportionale Verbesserung der Politik hinzu.
  • ** Seitenaufnahme (feste):** Erfasst die Raumbeziehung zwischen Arm und Gegenstand und den Annahmegel.
  • Handkamera (auf End-Effektor montiert): Erfasst die Griffkontaktzone von Millimeter Entfernung. Dies ist die einzig wirksamste Kamera für feine Manipulationen - Studien des ALOHA-Teams und anderer zeigen, dass die Hinzufügung einer Handkamera die Erfolgsraten der Politik um 20-40% bei kontaktreichen Aufgaben verbessert.

Die Kamera-Synchronisierung ist wichtig. Wenn die Beobachtungszeitmarken von mehr als 10 ms von den Aktionszeitmarken ab sind, trainieren Sie die Politik auf falsch ausgerichtete Daten - sie sieht die Welt in der Zeit t, verbindet sie aber mit der Aktion aus der Zeit t+delta. Bei schnellen Aufgaben (Grasps, die in 200-400 ms abgeschlossen werden), schlechtert selbst 20 ms der Fehlstellung die Politikleistung messbar. Verwenden Sie Hardware-Trigger oder zeitstemplarbasierte Software-Synchronisierung.

** Kamera-Auflösung vs. Bildschraubrate-Ausgleich:** Für das Nachahmen des Lernens ist die Bildschraubrate wichtiger als die Auflösung. Ein 640x480-Stream bei 30 fps erzeugt bessere Trainingsdaten als ein 1920x1080-Stream bei 15 fps. Die Politik benötigt zeitliche Kontinuität, um die Bewegungsdynamik zu lernen. Wir führen alle RCSV-Daten-Sammlungen mit 30 fps-Mindest, wobei 50 fps für schnelle Manipulationsarbeiten bevorzugt ist.

Lokal-Versus Fernbedienung

Lokale Telebetrieb (Betreiber im selben Raum) erreicht die niedrigste Latenz - typischerweise unter 5ms End-to-End - und ist der Standard für die Datenerhebung. Ferntelebetrieb (Betreiber an einem anderen Standort) führt Netzwerk-Latenz ein, ermöglicht aber Einsatzsszenarien wie Fernüberprüfung, Facility Management und verteilte Datenerhebung. RCSV Datenplattform unterstützt beide Modi mit integrierter adapter Stromkompression und Latenzüberwachung.

Für Fernteleoperation ist der Video Stream der Engpässigkeit - nicht die Steuerungskommandos. Die Steuerungskommandos sind winzig (<100 Byte pro Paket bei 50Hz), aber unkomprimierte 640x480 RGB bei 30 fps ist 28 MB/s pro Kamera. Mit drei Kameras ist das 84 MB/s vor Kompression. H.264 Hardware-Coding auf der Roboterseite reduziert dies auf 2-5 Mbps pro Stream mit akzeptabler Qualität, aber die Codierung fügt 15-30ms Latenz hinzu.

Die ACT-Datenformat- und Aufnahmegrohrleitung

Die meisten modernen Imitations-Lern-Frameworks - ACT, Diffusion Policy, LeRobot - verbrauchen Trainingsdaten im HDF5-Format mit einer bestimmten Struktur. Jede Episode wird als Gruppe gespeichert, die synchronisierte Arrays für Beobachtungen (Bilder, gemeinsame Positionen, Griffzustand) und Aktionen (Ziel-Gelenkpositionen oder Geschwindigkeiten) enthält. Hier ist das Standardschema:

episode_0/
  observations/
    images/
      cam_high    (T, 480, 640, 3) uint8     # overhead camera
      cam_low     (T, 480, 640, 3) uint8     # side camera
      cam_wrist   (T, 480, 640, 3) uint8     # wrist camera
    qpos          (T, 7) float32              # joint positions + gripper
    qvel          (T, 7) float32              # joint velocities
  actions         (T, 7) float32              # target joint positions
  timestamps      (T,) float64               # Unix timestamps in seconds
  metadata/
    success       bool                        # did episode achieve goal?
    task_name     string                      # e.g., "pick_cube_place_bin"
    operator_id   string                      # for tracking operator quality

Hier ist ein minimales Python-Aufnahmeschrift, das synchronisierte Daten aus einem OpenArm mit drei USB-Kameras erfasst. Dies ist eine vereinfachte Version dessen, was die Aufnahmeitung von RCSV läuft - die Produktionsversion fügt automatische Erfolgserkennung, Echtzeit-Qualitätsmessungen und Cloud-Upload hinzu.

import h5py
import numpy as np
import time
import cv2
from openarm_sdk import OpenArm  # RCSV OpenArm Python SDK

# Initialize hardware
arm = OpenArm(port="/dev/ttyUSB0", baudrate=1000000)
cameras = {
    "cam_high":  cv2.VideoCapture(0),
    "cam_low":   cv2.VideoCapture(2),
    "cam_wrist": cv2.VideoCapture(4),
}
for cam in cameras.values():
    cam.set(cv2.CAP_PROP_FRAME_WIDTH, 640)
    cam.set(cv2.CAP_PROP_FRAME_HEIGHT, 480)
    cam.set(cv2.CAP_PROP_FPS, 30)

CONTROL_HZ = 50  # 50 Hz control loop
MAX_STEPS = 500  # 10 seconds at 50 Hz
dt = 1.0 / CONTROL_HZ

def record_episode(episode_id: int, hdf5_path: str):
    """Record one teleoperation episode to HDF5."""
    images = {k: [] for k in cameras}
    qpos_list, qvel_list, action_list, ts_list = [], [], [], []

    print(f"Recording episode {episode_id}... Press Ctrl+C to stop.")
    try:
        for step in range(MAX_STEPS):
            t_start = time.time()

            # Read leader arm (control device) as target action
            leader_state = arm.read_leader()
            action = leader_state.joint_positions  # 7-dim: 6 joints + gripper

            # Read follower arm (robot) current state
            follower_state = arm.read_follower()
            qpos = follower_state.joint_positions
            qvel = follower_state.joint_velocities

            # Send action to follower
            arm.command_follower(action)

            # Capture images from all cameras
            for name, cap in cameras.items():
                ret, frame = cap.read()
                if ret:
                    images[name].append(frame[:, :, ::-1])  # BGR to RGB

            qpos_list.append(qpos)
            qvel_list.append(qvel)
            action_list.append(action)
            ts_list.append(time.time())

            # Maintain control frequency
            elapsed = time.time() - t_start
            if elapsed < dt:
                time.sleep(dt - elapsed)

    except KeyboardInterrupt:
        pass

    # Write to HDF5
    T = len(qpos_list)
    with h5py.File(hdf5_path, "a") as f:
        ep = f.create_group(f"episode_{episode_id}")
        obs = ep.create_group("observations")
        img_grp = obs.create_group("images")
        for name in cameras:
            img_grp.create_dataset(name, data=np.array(images[name]),
                                   chunks=(1, 480, 640, 3), compression="gzip")
        obs.create_dataset("qpos", data=np.array(qpos_list, dtype=np.float32))
        obs.create_dataset("qvel", data=np.array(qvel_list, dtype=np.float32))
        ep.create_dataset("actions", data=np.array(action_list, dtype=np.float32))
        ep.create_dataset("timestamps", data=np.array(ts_list, dtype=np.float64))

    print(f"Episode {episode_id}: {T} steps saved ({T / CONTROL_HZ:.1f}s)")

Die Sammlung hochwertiger Demonstrationen

Gute Demonstrationen sind konsistent, vielfältig und erfolgreich. Konsistenz bedeutet, ein definiertes Protokoll für die Platzierung von Objekten, die Ansatzstrategie und die Abwicklung von Aufgaben zu befolgen. Vielfalt bedeutet unterschiedliche Positionen, Orientierungen und Umweltbedingungen für die einzelnen Episoden. Die Qualitätskontrolle bei RCSV umfasst Echtzeit-Episodenüberprüfung, automatisierte Ausfalldetektion und Wiederaufnahme-Trigger, wenn eine Demonstration außerhalb der Qualitätsgrenzen fällt.

Protokoll über die Ausbildung von Betreibern

Die Qualität der Betreiber ist der am wenigsten geschätzte Faktor in den Demonstrationsdaten. Ein erfahrener Betreiber produziert Demonstrationen, die 2-3 mal konsistenter sind als ein Anfänger, was sich direkt auf die politische Leistung übersetzt.

  1. Familiarierung (30 min): Kostenlose Erkundung mit Steuergerät und Roboter. Keine Datenaufzeichnung. Ziel: Kinesthetische Intuition für den Arbeitsraum des Robots, Geschwindigkeitsgrenzwerte und Kraftgrenzwerte aufzubauen.
  2. ** Übungsprozesse (20-30 Episoden):** Erledige die Zieltasche mit Feedback eines erfahrenen Betreibers.
  3. ** Kalibrierungsversuch (10 Episoden):** 10 Episoden aufzeichnen und die Erfolgsrate, Fertigstellungszeit und Streckenglässigkeit messen (durchschnittliche Schlaggröße).
  4. Produktionsaufzeichnung: Aufzeichnen von Demonstrationen für Schulungsdaten. Alle 50 Folgen überprüfen Sie die Qualitätsmesswerte für Drift.

Episodenqualitätsmessungen

Für jede aufgezeichnete Episode berechnet und verzeichnet die Pipeline der RCSV diese Qualitätssignale:

  • Abschlusszeit: sollte innerhalb von 1,5x des Referenzmittels liegen. Unnormal schnell vorkommende Episoden zeigen häufig übersprungenen Schritte an; unnormal langsam vorkommende Episoden zeigen die Zögerung des Betreibers an.
  • Gleichheit der Strecke: Die durchschnittliche Schlagzeile (Dritte Ableitung der gemeinsamen Position) sollte unter einer Aufgabengrenze liegen.
  • Durchschnittsdauer: Zeit vom ersten Kontakt bis zum stabilen Griff.
  • Task-Erfolg: Binär - hat die Episode den Zielzustand erreicht? Fehlende Episoden werden separat protokolliert und können für negative Beispiele oder Wiederherstellungsverhaltenstraining verwendet werden, sollten aber nicht in den Primärtraining-Set aufgenommen werden.

Häufige Fehler und wie sie behoben werden

Nach Unterstützung von Hunderten von Teleoperationsprogrammen hat RCSV die häufigsten Fehlermodi aufgeführt, mit denen Teams beim ersten Setup der Teleoperation konfrontiert sind:

Symptom Root Cause Fix
Robot jerks or oscillates during teleoperation Control loop rate too low (<30Hz) or PD gains too high Increase control loop to 50Hz+. Reduce P gain by 30% and add velocity damping. Check USB polling rate.
Policy trained on teleop data fails at deployment Camera moved between collection and deployment, or lighting changed Use rigid camera mounts with alignment markers. Log camera intrinsics/extrinsics per session. Match lighting.
Video feed lags during remote teleop H.264 encoder buffering frames for quality, not latency Use -tune zerolatency and -preset ultrafast in ffmpeg/GStreamer. Reduce resolution to 480p.
Greifer commands lag behind arm commands Greifer on separate serial bus with different polling rate Synchronize arm and gripper commands in the same control loop iteration. Use a single serial bus if possible.
Timestamps in HDF5 not monotonically increasing NTP time sync adjusting system clock during recording Use time.monotonic() for relative timestamps. Store absolute time only in episode metadata.
Operator fatigue after 30 minutes of collection Ergonomic issues with leader arm position or weight Mount leader arm at elbow height. Add arm rest. Enforce 10-min break every 45 min. Rotate operators.

Software-Stack: Was läuft wo

Eine Produktionsteleoperations-Einstellung läuft Software auf drei Maschinen.

  • Roboterseitiges Computer (z.B. Jetson Orin Nano, $249): Lauft die Echtzeit-Steuerungslöcke (50-500Hz), Kamera-Fassung und -kodierung und Aktionsvollstreckung. Diese Maschine muss einen Echtzeit-Kernel (PREEMPT_RT) oder mindestens einen Low-Latenz-Kernel ausführen, um jitter zu vermeiden. Python ist für den Logging-Pfad akzeptabel, aber die innere Steuerungslöcke sollte C++ sein oder eine Python-Erweiterung verwenden, die die GIL freisetzt.
  • Betriebsstation: Laufen der Steuerungs-Interface-Treiber, Video-Decoder und der Betriebsschnittstelle des Betreibers. Für die lokale Telebetrieb kann dies die gleiche Maschine sein wie die Roboterspeicher. Für die Remote-Telebetrieb ist es eine separate Maschine, die über WebRTC oder ein benutzerdefiniertes UDP-Streaming-Protokoll verbunden ist.
  • Datenserver / Cloud: Laufen Episodenspeicher, Qualitätsmetrikenberechnung, Datensatzmanagement und Trainingspipeline Koordination.

Wie man ein Teleoperationsprogramm mit RCSV startet

Es gibt drei Wege, je nach Ausgangspunkt:

  • ** Vollservice-Daten-Sammlung ($ 2.500 Pilot / $ 8.000 Kampagne):** Sie beschreiben Ihre Aufgabe und Zielroboter - RCSV bietet die Hardware, geschulten Betreiber, Lab-Umgebung und postverarbeitete Datensätze im HDF5/RLDS-Format. Am besten für Teams, die Trainingsdaten brauchen, ohne Teleop-Infrastruktur zu bauen. Beginnen Sie mit Datendienste.
  • Plattform + Ihre Hardware: Sie besitzen oder mieten den Roboter - RCSV liefert den Teleop-Software-Stack, die Aufzeichnung Pipeline, das Datensatzmanagement und die Qualitätsmessungen über die [Datenplattform] (T14). Monatliches Abonnement, kein Hardware-Kauf erforderlich.
  • ** Hardware Lease + Platform:** Lease eine OpenArm oder eine andere Plattform durch RCSVs Leasing-Programm und erhalten den gesamten Software-Stack enthalten.

Für Teams, die die Schnittstelle erkunden möchten, bevor sie sich engagieren, versuchen Sie die [virtuelle Teleoperations-Sandbox]T17) - ein browserbasierter Simulator, der die komplette RCSV-Teleop-UI gegen einen simulierten Roboter ausführt.

Verwandte Lesungen

  • ACT-Politik erklärt -- wie der beliebteste Imitationslernalgorithmus Teleop-Daten verwendet
  • Gemässliche Fehler beim Roboternimitieren -- Datenqualitätsfalle zu vermeiden
  • [Was sind Roboter-Training-Daten?] T20) -- Formate, Standards und bewährte Verfahren
  • RCSV-Datendienste -- verwaltete Teleoperationen und Datenerhebung
  • [Wie man einen Roboter mietet] T22) -- holen Sie sich Hardware für Ihr Teleop-Programm

Bereit, Teleop-Daten zu sammeln?

RCSV bietet eine vollständige Teleoperationsdaten-Sammlung, vermietetes Hardware und die Softwareplattform, um Ihre Datensätze zu verwalten.

[Datendienste] [T23] [Gespräch mit einem Ingenieur] [T24]