Vertrieb kontaktieren
Zurück zu Guides

Einrichtung der Roboterkamera für die Telebetrieb und die Datenerhebung

Wie man Kameras für die Roboterdaten-Sammlung einrichtet <unk> Kameraarten, Platzierung, Synchronisierung, Kalibrierung und Aufnahme-Pipeline.

Kameraartenvergleich

Die drei Kamera-Technologien werden häufig in der Roboter-Daten-Sammlung eingesetzt.

Type Example Model Price Latenz Best For
USB (UVC) Logitech BRIO 4K ~$200 50-200ms variable Budget setups, low-frequency tasks
GigE Vision Basler ace2 a2A1920 $400-$1,500 <1ms deterministic High-quality datasets, policy training
Depth (RGB-D) Intel RealSense D435 ~$200 30-60ms Supplemental depth -- not recommended as primary

** USB-Kameras** (Logitech BRIO, ELP, Arducam) sind die zugänglichsten, leiden aber unter variabler Latenz, die durch die Planung des USB-Host-Controllers verursacht wird. Unter Belastung kann die Frame-Delivery um 20-50 ms jittern, was Multi-Kamera-Aufnahmen desynchronisiert und das politische Training schwächt. Für Einkamera- oder Low-Frame-Rate-Setups (<15 fps) ist USB akzeptabel.

GigE Vision Kameras (Basler ace2, FLIR Blackfly S, Allied Vision Alvium) liefern Frames über Ethernet mit einer deterministischen <1 ms Latenz, wenn sie hardware ausgelöst werden. Die Basler ace2 a2A1920-160ucBAS bei 650 US-Dollar bietet 1920x1200 bei 160 fps, mehr als genug für 30 fps Roboteraufzeichnung. GigE Kameras erfordern einen dedizierten NIC mit aktivierten Jumbo-Frame (T8) und einen PoE-Schalter oder Injektor.

Die Tiefenkameras (RealSense D435, Azure Kinect) sind für das ergänzende 3D-Szenenverständnis nützlich, werden aber nicht als primäre Aufnahmekameras empfohlen. Ihre Rollverschluss-, Tiefenlärm an den Objektgrenzen und Schwierigkeiten mit glänzenden/dunklen Oberflächen machen sie als einzige visuelle Beobachtung ungeeignet. Verwenden Sie sie zusätzlich zu RGB-Kameras, wenn Ihre Politik Tiefeninput erfordert.

Drei Kamera-Konfigurationen

Die verschiedenen Manipulationsarbeiten profitieren von verschiedenen Kamera-Arrangements.

Konfiguration 1: Mindest (1 Kamera, Budget-Setup)

  • ** Kamera:** 1x Oberbedienung USB-Kamera (Logitech BRIO, $ 200)
  • Einrichtung: 90-100 cm über dem Arbeitsplatz montiert, gerade nach unten
  • Auflösung: 1280x720 bei 30 Fps
  • Betriebsfall: Einfache Auswahl- und Platzierungsarbeiten, erste Prototypen, Einarmbänder-Tisch-Aufgaben
  • Beschränkung: Keine Höheninformationen, keine egozentrische Sicht, politische Leistung 15-25% unterhalb der 3-Kamera-Einstellung bei komplexen Aufgaben

Dies ist der schnellste Weg, um Daten zu sammeln. Keine Synchronisierungs-Hardware erforderlich. Geeignet für die Validierung Ihrer Aufgabendefinition, bevor Sie in eine Multi-Kamera-Einstellung investieren.

Konfiguration 2: Standard (3 Kamera, empfohlen)

Diese Konfiguration wird bei RCSV für die Standard-Manipulation-Datenerhebung verwendet und balanciert die Abdeckung, Auflösung und Speicherkosten:

  • ** Kamera 1 - Festlegende Oberkopf (von oben nach unten):** 80-100 cm über dem Arbeitsplatz hoch und direkt nach unten. Auflösung 1280x960 mit 30 Fps. Erfasst den gesamten Arbeitsplatz, die Platzierung von Objekten und den Griffanschritt von oben. Dies ist die informativste Ansicht für die meisten Pick-and-Place-Politiken.
  • Kamera 2 -- Feste Seite (lateral): An Arbeitsplatzhöhe, 60-80 cm zur Seite. Auflösung 1280x960 bei 30 fps. Bietet Höheninformationen, die die Obersicht nicht bieten kann. Kritisch für Stapel-, Gieß- und Einfügungsaufgaben.
  • Kamera 3 - Handgelenk (egozentrisch): An dem Endefektor oder Werkzeugflange des Roboters vorwärts montiert. Auflösung 640x480 bei 60 Fps. Die höhere Bildschraubrate erfasst schnelle Handgelenkbewegungen ohne Verschleierung. Egozentrische Ansichten verbessern die Fähigkeit zur Festnahme und Feinmanipulation in der Imitationslernungsforschung erheblich.

Für die zweimanschließende Einrichtung mit dem DK1 wird eine vierte feste Kamera auf der gegenüberliegenden Seite von Kamera 2 hinzugefügt, um die zwischenarmigen Okklusionen zu decken.

Konfiguration 3: Vollständiges Abdecken (mehr als 5 Kameras, fortgeschritten)

  • Kameras 1-3: Gleiche wie in der Konfiguration 2 (überkopf, seitlich, handgelenk)
  • Kamera 4 - Gegenseite: Kamera 2 spiegelt sich auf der anderen Seite des Arbeitsplatzes ab.
  • Kamera 5 -- Vorderwinkel (45 Grad): 60 cm vorne in 45 Grad Abwärtswinkel positioniert.
  • Kamera 6 (optional) -- Tiefenkamera: Intel RealSense D435 für zusätzliche Punktwolkdaten in der Nähe der Oberfläche montiert.

Diese Konfiguration erzeugt 3-5x mehr Daten pro Episode, bietet aber die vollständigste visuelle Abdeckung.

End-to-End-Latenz-Budget

Für die Teleoperation muss die Gesamtlatenz von Glas zu Glas (von dem auf den Sensor schlagenden Photon bis zur Bewegung des Aktoren) für einen komfortablen menschlichen Betrieb unter 150 ms und für eine präzise Manipulation unter 100 ms liegen.

Stage Component GigE Camera USB Camera
1 Sensor exposure 5-10 ms 5-33 ms (auto-exposure)
2 Readout + transfer <1 ms (Ethernet) 10-50 ms (USB scheduling)
3 Driver processing 1-2 ms 2-5 ms
4 ROS2 topic publish 1-3 ms 1-3 ms
5 Policy inference 10-30 ms (GPU) 10-30 ms (GPU)
6 Motor command + execution 5-10 ms 5-10 ms
Total 23-56 ms 33-131 ms

Der USB-Kameraweg kann unter Belastung 100 ms überschreiten (mehrere USB-Geräte teilen einen Host-Controller), was zu spürbarem Teleop-Verzögerung führt. Für komfortablen Telebetrieb mit dem [OpenArm 1]T40] empfehlen wir GigE-Kameras oder zumindest sicherzustellen, dass jede USB-Kamera auf einem dedizierten USB-Host-Controller ist (check mit T9).

Synchronisierungsmethoden

Eine 33 ms Desynchronisierung zwischen Kameras mit 30 fps bedeutet, dass eine Kamera einen ganzen Rahmen hinter sich hat.

Hardware GPIO-Trigger (zur Anwendung bei GigE-Kameras empfohlen)

Ein einzelner Auslöserpulse wird von einem Mikrocontroller (Arduino Uno bei 25 US-Dollar oder Raspberry Pi GPIO) generiert und gleichzeitig an den Auslöser-Eingang aller Kameras gekabelt.

# Arduino trigger sketch for 30 fps synchronized capture
void setup() {
  pinMode(2, OUTPUT);  // Trigger pin → all camera trigger inputs
}
void loop() {
  digitalWrite(2, HIGH);
  delayMicroseconds(100);  // 100us pulse width
  digitalWrite(2, LOW);
  delay(33);  // 33ms → 30 fps
}

Software-Synchronisierung über NTP

Synchronisieren Sie alle Aufnahmegeräte mit einem gemeinsamen NTP-Server (T10, verwenden Sie pool.ntp.org oder einen lokalen Chrony-Server für +/-2 ms Genauigkeit auf LAN). ROS2-Zeitstempel mit T11 werden dann über Maschinen hinweg auf +/-10 ms konsistent sein. Für 15 fps Aufnahme geeignet, aber nicht für 60 fps Handgelenkkameras.

ROS2-Meldungsfilter für die Nähere Synchronisierung

Wenn die Hardware-Auslösung nicht verfügbar ist, verwenden Sie das ROS2 T12-Paket, um die Kamera-Themen nach Zeitstempel ungefähr zu synchronisieren:

from message_filters import ApproximateTimeSynchronizer, Subscriber
from sensor_msgs.msg import Image

sub_overhead = Subscriber(node, Image, '/cam_overhead/image_raw')
sub_side = Subscriber(node, Image, '/cam_side/image_raw')
sub_wrist = Subscriber(node, Image, '/cam_wrist/image_raw')

sync = ApproximateTimeSynchronizer(
    [sub_overhead, sub_side, sub_wrist],
    queue_size=10,
    slop=0.033  # 33ms tolerance (1 frame at 30fps)
)
sync.registerCallback(synchronized_callback)

Kalibrierung der Kamera

Die Kalibrierung besteht aus zwei Komponenten: Inneres pro Kamera und Extrinsics (relative Posen zwischen Kameras und der Roboterbasis).

Intrinsiche Kalibrierung charakterisiert die Brennlänge, den Hauptpunkt und die Verzerrungskoeffizienten jeder Kamera. Verwenden Sie das Kalibrierungsmodul von OpenCV mit einem 9x7-Schachbrett (25 mm Quadrat). Sammeln Sie 20-40 Bilder an verschiedenen Winkeln und Entfernungen. Zielen Sie auf einen Wiederwerferfehler <0,5 px (akzeptabel bis zu 1,0 px). Laufen Sie die Kalibrierung mit: T13.

Extrinsiche Kalibrierung bestimmt die 6-DOF-Transformation von jedem Kamerarahmen zum Roboter-Basisrahmen. Verwenden Sie ein ChArUco-Board (besser Eckdetektion als ein einfaches Schachbrett), das in mehreren bekannten Posen montiert ist. Für jede Kamera sammeln Sie 15-20 Aufnahmen auf dem Arbeitsplatz. Die daraus resultierenden Transformationen werden als statische TF-Räume in Ihrer ROS2-Parameterdatei gespeichert und zur Projektion von Beobachtungen in einen gemeinsamen robot-relativen Koordinatenrahmen für die Politikbildung verwendet.

Überprüfen Sie die Kalibrierung, indem Sie die TCP-Position des Robots (von der vorwärtsgeführten Kinematik) in jedes Kamerabild projizieren. Der projizierte Punkt sollte sich mit dem sichtbaren TCP innerhalb von 5 Pixel in allen Arbeitsplatzsätzen ausrichten. Fehler >10 px zeigen typischerweise eine falsche Kamera-Mount-Position an - überprüfen Sie die Steifheit Ihres Mounts erneut und erinnern Sie sich an extrinsische Daten.

ROS2 Bildtransportpipeline

Das T14-Paket in ROS2 bietet einfachverzwingbare Kompression für Kamera-Themen.

Transport Bandwidth (1280x960@30fps) CPU Load Quality Loss Best For
raw ~880 Mbps Minimal None Intra-process, shared memory
compressed (JPEG 80%) ~30-60 Mbps Moderate Slight (lossy) Cross-machine recording
h264 (ffmpeg_image_transport) ~10-30 Mbps High (GPU encode helps) Moderate (lossy) Long recording sessions, storage-limited
compressed (PNG) ~300-500 Mbps High None (lossless) Archival, precision-critical data

** Empfehlung:** Verwenden Sie JPEG-komprimierte Transport mit einer Qualität von 80% für die Standarddatenerhebung. Die Komprimierungsartefakte auf diesem Qualitätsniveau liegen unter dem Lärmgrund der meisten Politik-Schulungsleitungen.

HDF5 Aufnahmemodell für das Nachahmen

Die Aufnahme-Pipeline muss synchronisierte Rahmen, Roboter-Gebundene und Aktionsetiketten in einer einzigen Datei pro Demonstration erfassen. HDF5 ist das Standardformat, das von ACT, Diffusion Policy und den meisten Imitations-Lern-Frameworks verwendet wird.

Empfohlene HDF5-Struktur

/episode_0042/
  observations/
    images/
      cam_overhead    # (T, H, W, 3) uint8 JPEG-decoded frames
      cam_side        # (T, H, W, 3) uint8
      cam_wrist       # (T, H, W, 3) uint8
    joint_positions   # (T, 6) float64 — radians
    joint_velocities  # (T, 6) float64 — rad/s
    ee_pose           # (T, 7) float64 — xyz + quaternion
    gripper_state     # (T, 1) float64 — 0.0 closed to 1.0 open
    tactile/          # optional
      left_finger     # (T, 16, 16) uint16 — Paxini pressure
      right_finger    # (T, 16, 16) uint16
  actions/
    joint_positions   # (T, 6) float64 — target joint positions
    gripper_action    # (T, 1) float64 — target gripper state
  metadata/
    timestamp         # (T,) float64 — Unix timestamps
    trigger_pulse     # (T,) uint8 — hardware trigger confirmation
    fps               # scalar — recording frame rate
    camera_intrinsics # dict — per-camera calibration
    camera_extrinsics # dict — camera-to-base transforms

Schreiben von HDF5 in Python:

import h5py
import numpy as np

with h5py.File('episode_0042.hdf5', 'w') as f:
    ep = f.create_group('episode_0042')
    obs = ep.create_group('observations')
    imgs = obs.create_group('images')
    # Store images with chunk-based compression
    imgs.create_dataset('cam_overhead', data=overhead_frames,
                        chunks=(1, 960, 1280, 3), compression='gzip')
    obs.create_dataset('joint_positions', data=joint_data)
    obs.create_dataset('ee_pose', data=ee_data)
    # Actions
    acts = ep.create_group('actions')
    acts.create_dataset('joint_positions', data=action_data)
    # Metadata
    meta = ep.create_group('metadata')
    meta.create_dataset('timestamp', data=timestamps)
    meta.attrs['fps'] = 30

Rahmenbereitung: Alle Daten werden zum Schreibzeitpunkt auf den Auslöserzeitstempel angeordnet.

Aufzeichnung von Pipeline-Architektur

Die komplette Aufnahmegröte vom Kamera-Sensor bis zur HDF5-Datei:

  1. Kamera-Treiberknoten (ein pro Kamera): Veröffentlicht T15 auf T16 und T17.
  2. Synchronisierungsknoten: verwendet T18, um die Frames von allen Kameras auszurichten + T19 + T20. Veröffentlicht eine benutzerdefinierte T21-Nachricht.
  3. Recorder-Knoten: Abonniert T22, buftet im Speicher und flushet auf HDF5 an der Episodegrenze (ausgelöst durch den Tast des Operator-Tasten oder das Teleoperationsstop-Signal).
  4. Kompression (optional): Bei Aufnahme mit hoher Auflösung laufen Sie die H.264-Codierung in einem separaten Thread aus, um die Aufnahmeschleife zu verhindern. Bei 10 Mbps verwendet ein 1280x960-Stream mit 30 fps etwa 75 MB/min pro Kamera.

Für die Cloud-Speicherung und Datensatzmanagement verwenden Sie [RCSV's Data Services]T41) die automatisches Upload, Deduplikation und Datensatzversion ermöglicht.

Speicherungsplanung

Berechnen Sie vor dem Start einer Datenerhebungskampagne Ihre Speicheranforderungen:

** Beispiel: 3-Kamera-Setup bei 15 Mbps pro Kamera, 8-Stunden-Aufnahmetag:** 3 Kameras x 15 Mbps x 3600s/hr x 8hr / 8 bits/byte / 1e9 GB = 162 GB/Tag. Bei 10 Mbps-Durchschnitt: 108 GB/Tag. Plan für eine 4 TB NVMe SSD pro Aufnahmesitze, mit nächtlicher Rsync zu einem NAS oder Cloud-Bucket.

Configuration Cameras GB/day (8 hr) Days on 4 TB SSD Monthly Cloud Cost (S3)
Minimal (JPEG) 1 36 ~110 ~$18
Standard (H.264) 3 108 ~37 ~$55
Full coverage (H.264) 5 180 ~22 ~$92
Full coverage (PNG lossless) 5 900 ~4 ~$460

Einrichtung der Beleuchtung

Die Politik, die unter unvereinbarem Licht ausgebildet wird, wird oft nicht eingesetzt, wenn die Lichtbedingungen unterschiedlich sind.

  • Farbe-Temperatur: Verwenden Sie 5500K LED-Ringlichter mit Tageslicht (z.B. Newer 18" Ringlichter bei 60 US-Dollar).
  • Einrichtung: Befestigen Sie die Lichter in einem Winkel von 45 Grad von der Oberkameraachse, um Spekulationen von glänzenden Objekten und Roboteroberflächen zu minimieren.
  • ** Diffusion:** Fügen Sie Diffusionspaneele (gefrorene Acrylblätter) vor Licht hinzu, um harte Schatten zu beseitigen.
  • Blackout-Vorhänge: Für Laborsetze in der Nähe von Fenstern sollten Sie Blackout-Vorhänge installieren, um die Umgebungslichtvariationen von Wolken und Sonnenwinkel zu beseitigen.

Häufige Probleme und Lösungen

Issue Cause Solution
Dropped frames USB bandwidth saturation Move cameras to separate USB controllers; use GigE
GigE incomplete frames Jumbo frames not enabled ip link set eth0 mtu 9000
Color inconsistency between cameras Auto white balance enabled Set manual white balance (5500K) on all cameras
Blurry wrist camera Motion blur from long exposure Set exposure to <5 ms; increase lighting intensity
High CPU during recording Software JPEG encoding per frame Use camera-side JPEG encoding or GPU H.264 (NVENC)
Kalibrierung reprojection >1 px Too few or poorly distributed calibration images Collect 30+ images covering all corners at varied distances

Kameraartenvergleich

Die drei Kamera-Technologien werden häufig in der Roboter-Daten-Sammlung eingesetzt.

Type Example Model Price Latenz Best For
USB (UVC) Logitech BRIO 4K ~$200 50-200ms variable Budget setups, low-frequency tasks
GigE Vision Basler ace2 a2A1920 $400-$1,500 <1ms deterministic High-quality datasets, policy training
Depth (RGB-D) Intel RealSense D435 ~$200 30-60ms Supplemental depth -- not recommended as primary

** USB-Kameras** (Logitech BRIO, ELP, Arducam) sind die zugänglichsten, leiden aber unter variabler Latenz, die durch die Planung des USB-Host-Controllers verursacht wird. Unter Belastung kann die Frame-Delivery um 20-50 ms jittern, was Multi-Kamera-Aufnahmen desynchronisiert und das politische Training schwächt. Für Einkamera- oder Low-Frame-Rate-Setups (<15 fps) ist USB akzeptabel.

GigE Vision Kameras (Basler ace2, FLIR Blackfly S, Allied Vision Alvium) liefern Frames über Ethernet mit einer Deterministik <1 ms Latenz, wenn sie hardware ausgelöst werden. Die Basler ace2 a2A1920-160ucBAS bei 650 US-Dollar bietet 1920x1200 bei 160 fps, mehr als genug für 30 fps Roboteraufzeichnung. GigE Kameras benötigen einen dedizierten NIC mit aktivierten Jumbo-Frame (T24) und einen PoE-Schalter oder Injektor.

Die Tiefenkameras (RealSense D435, Azure Kinect) sind für das ergänzende 3D-Szenenverständnis nützlich, werden aber nicht als primäre Aufnahmekameras empfohlen. Ihre Rollverschluss-, Tiefenlärm an den Objektgrenzen und Schwierigkeiten mit glänzenden/dunklen Oberflächen machen sie als einzige visuelle Beobachtung ungeeignet. Verwenden Sie sie zusätzlich zu RGB-Kameras, wenn Ihre Politik Tiefeninput erfordert.

Drei Kamera-Konfigurationen

Die verschiedenen Manipulationsarbeiten profitieren von verschiedenen Kamera-Arrangements.

Konfiguration 1: Mindest (1 Kamera, Budget-Setup)

  • ** Kamera:** 1x Oberbedienung USB-Kamera (Logitech BRIO, $ 200)
  • Einrichtung: 90-100 cm über dem Arbeitsplatz montiert, gerade nach unten
  • Auflösung: 1280x720 bei 30 Fps
  • Betriebsfall: Einfache Auswahl- und Platzierungsarbeiten, erste Prototypen, Einarmbänder-Tisch-Aufgaben
  • Beschränkung: Keine Höheninformationen, keine egozentrische Sicht, politische Leistung 15-25% unterhalb der 3-Kamera-Einstellung bei komplexen Aufgaben

Dies ist der schnellste Weg, um Daten zu sammeln. Keine Synchronisierungs-Hardware erforderlich. Geeignet für die Validierung Ihrer Aufgabendefinition, bevor Sie in eine Multi-Kamera-Einstellung investieren.

Konfiguration 2: Standard (3 Kamera, empfohlen)

Diese Konfiguration wird bei RCSV für die Standard-Manipulation-Datenerhebung verwendet und balanciert die Abdeckung, Auflösung und Speicherkosten:

  • ** Kamera 1 - Festlegende Oberkopf (von oben nach unten):** 80-100 cm über dem Arbeitsplatz hoch und direkt nach unten. Auflösung 1280x960 mit 30 Fps. Erfasst den gesamten Arbeitsplatz, die Platzierung von Objekten und den Griffanschritt von oben. Dies ist die informativste Ansicht für die meisten Pick-and-Place-Politiken.
  • Kamera 2 -- Feste Seite (lateral): An Arbeitsplatzhöhe, 60-80 cm zur Seite. Auflösung 1280x960 bei 30 fps. Bietet Höheninformationen, die die Obersicht nicht bieten kann. Kritisch für Stapel-, Gieß- und Einfügungsaufgaben.
  • Kamera 3 - Handgelenk (egozentrisch): An dem Endefektor oder Werkzeugflange des Roboters vorwärts montiert. Auflösung 640x480 bei 60 Fps. Die höhere Bildschraubrate erfasst schnelle Handgelenkbewegungen ohne Verschleierung. Egozentrische Ansichten verbessern die Fähigkeit zur Festnahme und Feinmanipulation in der Imitationslernungsforschung erheblich.

Für die zweimanschließende Einrichtung mit dem DK1 wird eine vierte feste Kamera auf der gegenüberliegenden Seite von Kamera 2 hinzugefügt, um die zwischenarmigen Okklusionen zu decken.

Konfiguration 3: Vollständiges Abdecken (mehr als 5 Kameras, fortgeschritten)

  • Kameras 1-3: Gleiche wie in der Konfiguration 2 (überkopf, seitlich, handgelenk)
  • Kamera 4 - Gegenseite: Kamera 2 spiegelt sich auf der anderen Seite des Arbeitsplatzes ab.
  • Kamera 5 -- Vorderwinkel (45 Grad): 60 cm vorne in 45 Grad Abwärtswinkel positioniert.
  • Kamera 6 (optional) -- Tiefenkamera: Intel RealSense D435 für zusätzliche Punktwolkdaten in der Nähe der Oberfläche montiert.

Diese Konfiguration erzeugt 3-5x mehr Daten pro Episode, bietet aber die vollständigste visuelle Abdeckung.

End-to-End-Latenz-Budget

Für die Teleoperation muss die Gesamtlatenz von Glas zu Glas (von dem auf den Sensor schlagenden Photon bis zur Bewegung des Aktoren) für einen komfortablen menschlichen Betrieb unter 150 ms und für eine präzise Manipulation unter 100 ms liegen.

Stage Component GigE Camera USB Camera
1 Sensor exposure 5-10 ms 5-33 ms (auto-exposure)
2 Readout + transfer <1 ms (Ethernet) 10-50 ms (USB scheduling)
3 Driver processing 1-2 ms 2-5 ms
4 ROS2 topic publish 1-3 ms 1-3 ms
5 Policy inference 10-30 ms (GPU) 10-30 ms (GPU)
6 Motor command + execution 5-10 ms 5-10 ms
Total 23-56 ms 33-131 ms

Die USB-Kamera-Pfad kann unter Belastung 100 ms überschreiten (mehrere USB-Geräte teilen einen Host-Controller), was zu spürbarem Teleop-Verzögerung führt. Für komfortable Teleoperation mit dem [OpenArm 1]T42), empfehlen wir GigE-Kameras oder zumindest sicherzustellen, dass jede USB-Kamera auf einem dedizierten USB-Host-Controller ist (check mit T25).

Synchronisierungsmethoden

Eine 33 ms Desynchronisierung zwischen Kameras mit 30 fps bedeutet, dass eine Kamera einen ganzen Rahmen hinter sich hat.

Hardware GPIO-Trigger (zur Anwendung bei GigE-Kameras empfohlen)

Ein einzelner Auslöserpulse wird von einem Mikrocontroller (Arduino Uno bei 25 US-Dollar oder Raspberry Pi GPIO) generiert und gleichzeitig an den Auslöser-Eingang aller Kameras gekabelt.

# Arduino trigger sketch for 30 fps synchronized capture
void setup() {
  pinMode(2, OUTPUT);  // Trigger pin → all camera trigger inputs
}
void loop() {
  digitalWrite(2, HIGH);
  delayMicroseconds(100);  // 100us pulse width
  digitalWrite(2, LOW);
  delay(33);  // 33ms → 30 fps
}

Software-Synchronisierung über NTP

Synchronisieren Sie alle Aufnahmegeräte auf einen gemeinsamen NTP-Server (T26, verwenden Sie pool.ntp.org oder einen lokalen Chrony-Server für +/-2 ms Genauigkeit auf LAN). ROS2-Zeitstempel mit T27 werden dann über Maschinen hinweg auf +/-10 ms konsistent sein. Für 15 fps Aufnahme geeignet, aber nicht für 60 fps Handgelenkkameras.

ROS2-Meldungsfilter für die Nähere Synchronisierung

Wenn die Auslösung der Hardware nicht verfügbar ist, verwenden Sie das ROS2 T28-Paket, um die Kamera-Themen nach Zeitstempel ungefähr zu synchronisieren:

from message_filters import ApproximateTimeSynchronizer, Subscriber
from sensor_msgs.msg import Image

sub_overhead = Subscriber(node, Image, '/cam_overhead/image_raw')
sub_side = Subscriber(node, Image, '/cam_side/image_raw')
sub_wrist = Subscriber(node, Image, '/cam_wrist/image_raw')

sync = ApproximateTimeSynchronizer(
    [sub_overhead, sub_side, sub_wrist],
    queue_size=10,
    slop=0.033  # 33ms tolerance (1 frame at 30fps)
)
sync.registerCallback(synchronized_callback)

Kalibrierung der Kamera

Die Kalibrierung besteht aus zwei Komponenten: Inneres pro Kamera und Extrinsics (relative Posen zwischen Kameras und der Roboterbasis).

Intrinsiche Kalibrierung charakterisiert die Brennlänge, den Hauptpunkt und die Verzerrungskoeffizienten jeder Kamera. Verwenden Sie das Kalibrierungsmodul von OpenCV mit einem 9x7-Schachbrett (25 mm Quadrat). Sammeln Sie 20-40 Bilder an verschiedenen Winkeln und Entfernungen. Zielen Sie auf einen Wiederwerferfehler <0,5 px (akzeptabel bis zu 1,0 px). Führen Sie die Kalibrierung mit: T29 aus.

Extrinsiche Kalibrierung bestimmt die 6-DOF-Transformation von jedem Kamerarahmen zum Roboter-Basisrahmen. Verwenden Sie ein ChArUco-Board (besser Eckdetektion als ein einfaches Schachbrett), das in mehreren bekannten Posen montiert ist. Für jede Kamera sammeln Sie 15-20 Aufnahmen auf dem Arbeitsplatz. Die daraus resultierenden Transformationen werden als statische TF-Räume in Ihrer ROS2-Parameterdatei gespeichert und zur Projektion von Beobachtungen in einen gemeinsamen robot-relativen Koordinatenrahmen für die Politikbildung verwendet.

Überprüfen Sie die Kalibrierung, indem Sie die TCP-Position des Robots (von der vorwärtsgeführten Kinematik) in jedes Kamerabild projizieren. Der projizierte Punkt sollte sich mit dem sichtbaren TCP innerhalb von 5 Pixel in allen Arbeitsplatzsätzen ausrichten. Fehler >10 px zeigen typischerweise eine falsche Kamera-Mount-Position an - überprüfen Sie die Steifheit Ihres Mounts erneut und erinnern Sie sich an extrinsische Daten.

ROS2 Bildtransportpipeline

Das T30-Paket in ROS2 bietet einfachverzwingbare Kompression für Kamera-Themen.

Transport Bandwidth (1280x960@30fps) CPU Load Quality Loss Best For
raw ~880 Mbps Minimal None Intra-process, shared memory
compressed (JPEG 80%) ~30-60 Mbps Moderate Slight (lossy) Cross-machine recording
h264 (ffmpeg_image_transport) ~10-30 Mbps High (GPU encode helps) Moderate (lossy) Long recording sessions, storage-limited
compressed (PNG) ~300-500 Mbps High None (lossless) Archival, precision-critical data

** Empfehlung:** Verwenden Sie JPEG-komprimierte Transport mit einer Qualität von 80% für die Standarddatenerhebung. Die Komprimierungsartefakte auf diesem Qualitätsniveau liegen unter dem Lärmgrund der meisten Politik-Schulungsleitungen.

HDF5 Aufnahmemodell für das Nachahmen

Die Aufnahme-Pipeline muss synchronisierte Rahmen, Roboter-Gebundene und Aktionsetiketten in einer einzigen Datei pro Demonstration erfassen. HDF5 ist das Standardformat, das von ACT, Diffusion Policy und den meisten Imitations-Lern-Frameworks verwendet wird.

Empfohlene HDF5-Struktur

/episode_0042/
  observations/
    images/
      cam_overhead    # (T, H, W, 3) uint8 JPEG-decoded frames
      cam_side        # (T, H, W, 3) uint8
      cam_wrist       # (T, H, W, 3) uint8
    joint_positions   # (T, 6) float64 — radians
    joint_velocities  # (T, 6) float64 — rad/s
    ee_pose           # (T, 7) float64 — xyz + quaternion
    gripper_state     # (T, 1) float64 — 0.0 closed to 1.0 open
    tactile/          # optional
      left_finger     # (T, 16, 16) uint16 — Paxini pressure
      right_finger    # (T, 16, 16) uint16
  actions/
    joint_positions   # (T, 6) float64 — target joint positions
    gripper_action    # (T, 1) float64 — target gripper state
  metadata/
    timestamp         # (T,) float64 — Unix timestamps
    trigger_pulse     # (T,) uint8 — hardware trigger confirmation
    fps               # scalar — recording frame rate
    camera_intrinsics # dict — per-camera calibration
    camera_extrinsics # dict — camera-to-base transforms

Schreiben von HDF5 in Python:

import h5py
import numpy as np

with h5py.File('episode_0042.hdf5', 'w') as f:
    ep = f.create_group('episode_0042')
    obs = ep.create_group('observations')
    imgs = obs.create_group('images')
    # Store images with chunk-based compression
    imgs.create_dataset('cam_overhead', data=overhead_frames,
                        chunks=(1, 960, 1280, 3), compression='gzip')
    obs.create_dataset('joint_positions', data=joint_data)
    obs.create_dataset('ee_pose', data=ee_data)
    # Actions
    acts = ep.create_group('actions')
    acts.create_dataset('joint_positions', data=action_data)
    # Metadata
    meta = ep.create_group('metadata')
    meta.create_dataset('timestamp', data=timestamps)
    meta.attrs['fps'] = 30

Rahmenbereitung: Alle Daten werden zum Schreibzeitpunkt auf den Auslöserzeitstempel angeordnet.

Aufzeichnung von Pipeline-Architektur

Die komplette Aufnahmegröte vom Kamera-Sensor bis zur HDF5-Datei:

  1. Kamera-Treiberknoten (ein pro Kamera): Veröffentlicht T31 auf T32 und T33.
  2. Synchronisierungsknoten: verwendet T34, um die Frames von allen Kameras auszurichten + T35 + T36. Veröffentlicht eine benutzerdefinierte T37-Nachricht.
  3. Recorder node: Abonniert T38, buftet im Speicher und flushes auf HDF5 an der Episodegrenze (ausgelöst durch den Tast des Operator-Tasten oder das Teleoperationsstop-Signal).
  4. Kompression (optional): Bei Aufnahme mit hoher Auflösung laufen Sie die H.264-Codierung in einem separaten Thread aus, um die Aufnahmeschleife zu verhindern. Bei 10 Mbps verwendet ein 1280x960-Stream mit 30 fps etwa 75 MB/min pro Kamera.

Für die Cloud-Speicherung und Datensatzverwaltung verwenden Sie [RCSV's Data Services]T43), die automatisches Upload, Deduplikation und Datensatzversion ermöglicht.

Speicherungsplanung

Berechnen Sie vor dem Start einer Datenerhebungskampagne Ihre Speicheranforderungen:

** Beispiel: 3-Kamera-Setup bei 15 Mbps pro Kamera, 8-Stunden-Aufnahmetag:** 3 Kameras x 15 Mbps x 3600s/hr x 8hr / 8 bits/byte / 1e9 GB = 162 GB/Tag. Bei 10 Mbps-Durchschnitt: 108 GB/Tag. Plan für eine 4 TB NVMe SSD pro Aufnahmesitze, mit nächtlicher Rsync zu einem NAS oder Cloud-Bucket.

Configuration Cameras GB/day (8 hr) Days on 4 TB SSD Monthly Cloud Cost (S3)
Minimal (JPEG) 1 36 ~110 ~$18
Standard (H.264) 3 108 ~37 ~$55
Full coverage (H.264) 5 180 ~22 ~$92
Full coverage (PNG lossless) 5 900 ~4 ~$460

Einrichtung der Beleuchtung

Die Politik, die unter unvereinbarem Licht ausgebildet wird, wird oft nicht eingesetzt, wenn die Lichtbedingungen unterschiedlich sind.

  • Farbe-Temperatur: Verwenden Sie 5500K LED-Ringlichter mit Tageslicht (z.B. Newer 18" Ringlichter bei 60 US-Dollar).
  • Einrichtung: Befestigen Sie die Lichter in einem Winkel von 45 Grad von der Oberkameraachse, um Spekulationen von glänzenden Objekten und Roboteroberflächen zu minimieren.
  • ** Diffusion:** Fügen Sie Diffusionspaneele (gefrorene Acrylblätter) vor Licht hinzu, um harte Schatten zu beseitigen.
  • Blackout-Vorhänge: Für Laborsetze in der Nähe von Fenstern sollten Sie Blackout-Vorhänge installieren, um die Umgebungslichtvariationen von Wolken und Sonnenwinkel zu beseitigen.

Häufige Probleme und Lösungen

Issue Cause Solution
Dropped frames USB bandwidth saturation Move cameras to separate USB controllers; use GigE
GigE incomplete frames Jumbo frames not enabled ip link set eth0 mtu 9000
Color inconsistency between cameras Auto white balance enabled Set manual white balance (5500K) on all cameras
Blurry wrist camera Motion blur from long exposure Set exposure to <5 ms; increase lighting intensity
High CPU during recording Software JPEG encoding per frame Use camera-side JPEG encoding or GPU H.264 (NVENC)
Kalibrierung reprojection >1 px Too few or poorly distributed calibration images Collect 30+ images covering all corners at varied distances