Configuración de la cámara de robot para la teleoperación y la recopilación de datos
Cómo configurar cámaras para la recopilación de datos de robots <unk> tipos de cámaras, colocación, sincronización, calibración y conducto de grabación.
Tipo de cámara en comparación
Las tres tecnologías de cámara se utilizan comúnmente en la configuración de la recopilación de datos de robots.
| Type | Example Model | Price | Latencia | 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 |
Las cámaras USB (Logitech BRIO, ELP, Arducam) son las más accesibles pero sufren de latencia variable causada por la programación del controlador host USB. Bajo carga, la entrega de fotogramas puede temblar en 20-50 ms, lo que desincroniza las grabaciones de múltiples cámaras y degrada la formación de políticas. Para configuraciones de cámara única o de baja velocidad de fotograma (<15 fps), USB es aceptable.
Las cámaras GigE Vision (Basler ace2, FLIR Blackfly S, Allied Vision Alvium) ofrecen marcos a través de Ethernet con una latencia determinista de <1 ms cuando se activa con hardware. La Basler ace2 a2A1920-160ucBAS a 650 dólares ofrece 1920x1200 a 160 fps, más que suficiente para la grabación de robots de 30 fps. Las cámaras GigE requieren un NIC dedicado con marcos jumbo habilitados (
Las cámaras de profundidad (RealSense D435, Azure Kinect) son útiles para la comprensión de escenas 3D suplementarias pero no se recomiendan como cámaras de grabación primarias. Su obturador de rodamiento, ruido de profundidad en los límites de los objetos y dificultad con superficies brillantes/oscuras las hacen inadecuadas como única observación visual.
Tres configuraciones de cámara
Las diferentes tareas de manipulación se benefician de diferentes arreglos de cámara.
Configuración 1: Minimo (1 cámara, configuración presupuestaria)
- Cámara: 1x cámara USB por encima (Logitech BRIO, $200)
- Posición: Montado 90-100 cm sobre el espacio de trabajo, apuntando directamente hacia abajo
- Resolución: 1280x720 a 30 fps
- Caso de uso: Simples de selección y colocación, prototipos iniciales, tareas de mesa de un solo brazo
- Limitación: No hay información de altura, no hay visión egocéntrica, el rendimiento de las políticas es 15-25% inferior al de las tres cámaras en tareas complejas
Esta es la forma más rápida de comenzar a recopilar datos. No se necesita hardware de sincronización. Es adecuado para validar la definición de tu tarea antes de invertir en una configuración de múltiples cámaras.
Configuración 2: Estándar (3 cámaras recomendadas)
Esta configuración se utiliza en el RCSV para la recopilación de datos de manipulación estándar y equilibra la cobertura, la resolución y el coste de almacenamiento:
- Camera 1 -- Alta fija (de arriba hacia abajo): Montada a 80-100 cm sobre el espacio de trabajo, apuntando directamente hacia abajo. Resolución 1280x960 a 30 fps. Captura todo el espacio de trabajo, la colocación de objetos y el enfoque del agarre desde arriba. Esta es la vista más informativa para la mayoría de las políticas de pick-and-place.
- Camera 2 -- Lado fijo (lateral): Montado a una altura del espacio de trabajo, de 60-80 cm hacia el lado. Resolución 1280x960 a 30 fps. Proporciona información de altura que la vista aérea no puede. Es crítico para las tareas de apilamiento, vertido e inserción.
- Camera 3 - Muñeca (egocentrica): Montada en el efecto final o la flange de herramientas del robot, orientada hacia adelante. Resolución 640x480 a 60 fps. La velocidad de fotogramas más alta captura movimientos rápidos de la muñeca sin borros.
Para las configuraciones bimanual que utilizan el DK1, añadir una cuarta cámara fija en el lado opuesto de la cámara 2 para cubrir las oclusiones entre los brazos.
Configuración 3: Cobertura completa (5+ cámaras, avanzadas)
- Las cámaras 1-3:** Igual que la configuración 2 (por encima, lateral, muñeca)
- Camera 4 -- Lado opuesto: Espejos de cámara 2 en el otro lado del espacio de trabajo. Elimina las manchas ciegas de oclusión de manos/brazos.
- Camera 5 -- Ángulo delantero (45 grados): posicionado 60 cm delante en ángulo de 45 grados hacia abajo. Captura el acercamiento del objeto y la orientación del agarre que se pierde por encima.
- Camera 6 (opcional) --Camera de profundidad: Intel RealSense D435 montado cerca de la posición aérea para datos de nube de punto suplementarios.
Esta configuración genera 3-5 veces más datos por episodio, pero proporciona la cobertura visual más completa. Se utiliza para la investigación sobre el aprendizaje de políticas de múltiples visualizaciones y la reconstrucción de escenas en 3D. Requisito de almacenamiento: aproximadamente 500 MB / minuto a 15 Mbps por cámara.
Presupuesto de latencia de extremo a extremo
Para la teleoperación, la latencia total de vidrio a vidrio (desde el fotón que golpea el sensor hasta el movimiento del actuador) debe permanecer por debajo de 150 ms para una operación humana cómoda y por debajo de 100 ms para una manipulación precisa.
| 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 |
Para una teleoperación cómoda con el [OpenArm 1]
Métodos de sincronización
La sincronización de varias cámaras es crítica. Una dessincronización de 33 ms entre cámaras a 30 fps significa que una cámara está una imagen completa detrás - las políticas entrenadas en datos dessincronizados aprenden correlaciones temporales incorrectas.
Disponible para el uso de las cámaras de GigE
Un pulso de gatillo único se genera por un microcontrolador (Arduino Uno a $25 o Raspberry Pi GPIO) y se conecta al input de gatillo de todas las cámaras simultáneamente.
# 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
}
Sincronización de software a través de NTP
Sincronizar todas las máquinas de grabación a un servidor NTP común (
ROS2 mensaje_filtros para sincronización aproximada
Cuando no esté disponible el desencadenamiento de hardware, utilice el paquete ROS2
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)
Calibración de la cámara
La calibración tiene dos componentes: intrínsecos por cámara y extrínsecos (posiciones relativas entre cámaras y la base del robot).
** Calibración intrínseca** caracteriza la distancia focal, el punto principal y los coeficientes de distorsión de cada cámara. Utilice el módulo de calibración de OpenCV con un tablero de ajedrez 9x7 (25 mm cuadrados). Recoge 20-40 imágenes en diferentes ángulos y distancias.
** Calibración externa** determina la transformación de 6 DOF de cada marco de la cámara al marco de base del robot. Utilice una tabla ChArUco (mejor detección de esquinas que el tablero de ajedrez común) montada en varias posturas conocidas. Para cada cámara, recoge 15-20 observaciones de tablas en todo el volumen del espacio de trabajo. Las transformaciones resultantes se almacenan como marcos estáticos de TF en su archivo de parámetros ROS2 y se utilizan para proyectar las observaciones en un marco de coordenadas común en relación con el robot para la formación de políticas.
Verifique la calibración proyectando la posición TCP del robot (desde la cinemática delantera) en cada imagen de la cámara. El punto proyectado debe alinearse con el TCP visible a menos de 5 píxeles en todas las posiciones del espacio de trabajo. Los errores > 10 px suelen indicar una posición incorrecta de montaje de cámara - revise la rigidez de su montaje y recuerde datos extrínsecos.
ROS2 Imagen de la tubería de transporte
El paquete
| 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 |
Recomendación: Utilice el transporte comprimido JPEG con una calidad del 80% para la recopilación de datos estándar. Los artefactos de compresión de este nivel de calidad están por debajo del nivel de ruido de la mayoría de las líneas de formación de políticas. Para los conjuntos de datos de investigación de mayor fidelidad, use PNG sin pérdidas pero planea un aumento de almacenamiento de 10 veces.
El formato de grabación HDF5 para el aprendizaje de imitación
El tubo de grabación debe capturar marcos sincronizados, estados conjuntos de robots y etiquetas de acción en un solo archivo por demostración. HDF5 es el formato estándar utilizado por ACT, Política de difusión y la mayoría de los marcos de aprendizaje de imitación.
Estructura de la FHD5 recomendada
/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
Escribe HDF5 en 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
Alineamiento de marcos: Al momento de escribir, alinear todos los datos con el marcador de tiempo de activación.
Registro de la arquitectura de tuberías
El tubo de grabación completo desde el sensor de la cámara hasta el archivo HDF5:
- Nodo de conductor de cámara (uno por cámara): Publica
T15 en T16 y T17 . - Nodo de sincronización: Utiliza
T18 para alinear los marcos de todas las cámaras + T19 + T20 . Publica un mensaje personalizado T21 . - Nodo de grabación: Se suscribe a
T22 , se almacenan en la memoria y se despeja a HDF5 en el límite del episodio (desencadenado por la presión del botón del operador o la señal de parada de la teleoperación). - Compresión (opcional): Si se graba a alta resolución, ejecuta la codificación H.264 en un hilo separado para evitar bloquear el bucle de grabación.
Para el almacenamiento en la nube y la gestión de conjuntos de datos, utilice [Servicios de datos de RCSV]
Planificación del almacenamiento
Antes de iniciar una campaña de recopilación de datos, calcule sus necesidades de almacenamiento:
** Ejemplo: Configuración de 3 cámaras a 15 Mbps por cámara, 8 horas de día de recogida:** 3 cámaras x 15 Mbps x 3600s/h x 8hr / 8 bits/byte / 1e9 GB = 162 GB/día.
| 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 |
Configuración de la iluminación
Las políticas entrenadas bajo iluminación inconsistente a menudo fallan en su implementación cuando las condiciones de iluminación difieren.
- ** Temperatura de color:** Utilice ** 5500K de luz diurna de LED balanceadas luces de anillo** (por ejemplo, la luz de anillo de Neewer 18" en $60/unidad).
- Posición: Colocar las luces en ángulos de 45 grados desde el eje de la cámara superior para minimizar los reflejos especulares de los objetos brillantes y las superficies de los robots.
- Difusión: Agregar paneles de difusión (hojas de acrílico congelado) frente a las luces para eliminar las sombras duras.
- ** Cortinas de apagón:** Para las instalaciones de laboratorio cerca de las ventanas, instale cortinas de apagón para eliminar la variación de la luz ambiental de las nubes y el ángulo del sol. Esta es una de las inversiones de ROI más altas en la calidad de la recopilación de datos.
Problemas y soluciones comunes
| 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) |
| Calibración reprojection >1 px | Too few or poorly distributed calibration images | Collect 30+ images covering all corners at varied distances |
Tipo de cámara en comparación
Las tres tecnologías de cámara se utilizan comúnmente en la configuración de la recopilación de datos de robots.
| Type | Example Model | Price | Latencia | 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 |
Las cámaras USB (Logitech BRIO, ELP, Arducam) son las más accesibles pero sufren de latencia variable causada por la programación del controlador host USB. Bajo carga, la entrega de fotogramas puede temblar en 20-50 ms, lo que desincroniza las grabaciones de múltiples cámaras y degrada la formación de políticas. Para configuraciones de cámara única o de baja velocidad de fotograma (<15 fps), USB es aceptable.
Las cámaras GigE Vision (Basler ace2, FLIR Blackfly S, Allied Vision Alvium) ofrecen marcos a través de Ethernet con una latencia determinista de <1 ms cuando se activa con hardware. La Basler ace2 a2A1920-160ucBAS a 650 dólares ofrece 1920x1200 a 160 fps, más que suficiente para la grabación de robots de 30 fps. Las cámaras GigE requieren un NIC dedicado con marcos jumbo habilitados (
Las cámaras de profundidad (RealSense D435, Azure Kinect) son útiles para la comprensión de escenas 3D suplementarias pero no se recomiendan como cámaras de grabación primarias. Su obturador de rodamiento, ruido de profundidad en los límites de los objetos y dificultad con superficies brillantes/oscuras las hacen inadecuadas como única observación visual.
Tres configuraciones de cámara
Las diferentes tareas de manipulación se benefician de diferentes arreglos de cámara.
Configuración 1: Minimo (1 cámara, configuración presupuestaria)
- Cámara: 1x cámara USB por encima (Logitech BRIO, $200)
- Posición: Montado 90-100 cm sobre el espacio de trabajo, apuntando directamente hacia abajo
- Resolución: 1280x720 a 30 fps
- Caso de uso: Simples de selección y colocación, prototipos iniciales, tareas de mesa de un solo brazo
- Limitación: No hay información de altura, no hay visión egocéntrica, el rendimiento de las políticas es 15-25% inferior al de las tres cámaras en tareas complejas
Esta es la forma más rápida de comenzar a recopilar datos. No se necesita hardware de sincronización. Es adecuado para validar la definición de tu tarea antes de invertir en una configuración de múltiples cámaras.
Configuración 2: Estándar (3 cámaras recomendadas)
Esta configuración se utiliza en el RCSV para la recopilación de datos de manipulación estándar y equilibra la cobertura, la resolución y el coste de almacenamiento:
- Camera 1 -- Alta fija (de arriba hacia abajo): Montada a 80-100 cm sobre el espacio de trabajo, apuntando directamente hacia abajo. Resolución 1280x960 a 30 fps. Captura todo el espacio de trabajo, la colocación de objetos y el enfoque del agarre desde arriba. Esta es la vista más informativa para la mayoría de las políticas de pick-and-place.
- Camera 2 -- Lado fijo (lateral): Montado a una altura del espacio de trabajo, de 60-80 cm hacia el lado. Resolución 1280x960 a 30 fps. Proporciona información de altura que la vista aérea no puede. Es crítico para las tareas de apilamiento, vertido e inserción.
- Camera 3 - Muñeca (egocentrica): Montada en el efecto final o la flange de herramientas del robot, orientada hacia adelante. Resolución 640x480 a 60 fps. La velocidad de fotogramas más alta captura movimientos rápidos de la muñeca sin borros.
Para las configuraciones bimanual que utilizan el DK1, añadir una cuarta cámara fija en el lado opuesto de la cámara 2 para cubrir las oclusiones entre los brazos.
Configuración 3: Cobertura completa (5+ cámaras, avanzadas)
- Las cámaras 1-3:** Igual que la configuración 2 (por encima, lateral, muñeca)
- Camera 4 -- Lado opuesto: Espejos de cámara 2 en el otro lado del espacio de trabajo. Elimina las manchas ciegas de oclusión de manos/brazos.
- Camera 5 -- Ángulo delantero (45 grados): posicionado 60 cm delante en ángulo de 45 grados hacia abajo. Captura el acercamiento del objeto y la orientación del agarre que se pierde por encima.
- Camera 6 (opcional) --Camera de profundidad: Intel RealSense D435 montado cerca de la posición aérea para datos de nube de punto suplementarios.
Esta configuración genera 3-5 veces más datos por episodio, pero proporciona la cobertura visual más completa. Se utiliza para la investigación sobre el aprendizaje de políticas de múltiples visualizaciones y la reconstrucción de escenas en 3D. Requisito de almacenamiento: aproximadamente 500 MB / minuto a 15 Mbps por cámara.
Presupuesto de latencia de extremo a extremo
Para la teleoperación, la latencia total de vidrio a vidrio (desde el fotón que golpea el sensor hasta el movimiento del actuador) debe permanecer por debajo de 150 ms para una operación humana cómoda y por debajo de 100 ms para una manipulación precisa.
| 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 |
La ruta de la cámara USB puede superar los 100 ms bajo carga (múltiples dispositivos USB comparten un controlador host), causando un retraso de teleop notable. Para una teleoperación cómoda con el [OpenArm 1]
Métodos de sincronización
La sincronización de varias cámaras es crítica. Una dessincronización de 33 ms entre cámaras a 30 fps significa que una cámara está una imagen completa detrás - las políticas entrenadas en datos dessincronizados aprenden correlaciones temporales incorrectas.
Disponible para el uso de las cámaras de GigE
Un pulso de gatillo único se genera por un microcontrolador (Arduino Uno a $25 o Raspberry Pi GPIO) y se conecta al input de gatillo de todas las cámaras simultáneamente.
# 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
}
Sincronización de software a través de NTP
Sincronizar todas las máquinas de grabación a un servidor NTP común (
ROS2 mensaje_filtros para sincronización aproximada
Cuando no esté disponible el desencadenamiento de hardware, utilice el paquete ROS2
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)
Calibración de la cámara
La calibración tiene dos componentes: intrínsecos por cámara y extrínsecos (posiciones relativas entre cámaras y la base del robot).
** Calibración intrínseca** caracteriza la distancia focal, el punto principal y los coeficientes de distorsión de cada cámara. Utilice el módulo de calibración de OpenCV con un tablero de ajedrez 9x7 (25 mm cuadrados). Recoge 20-40 imágenes en ángulos y distancias variados. Aplique un error de reprojección <0.5 px (acetable hasta 1.0 px). ejecuta la calibración con:
** Calibración externa** determina la transformación de 6 DOF de cada marco de la cámara al marco de base del robot. Utilice una tabla ChArUco (mejor detección de esquinas que el tablero de ajedrez común) montada en varias posturas conocidas. Para cada cámara, recoge 15-20 observaciones de tablas en todo el volumen del espacio de trabajo. Las transformaciones resultantes se almacenan como marcos estáticos de TF en su archivo de parámetros ROS2 y se utilizan para proyectar las observaciones en un marco de coordenadas común en relación con el robot para la formación de políticas.
Verifique la calibración proyectando la posición TCP del robot (desde la cinemática delantera) en cada imagen de la cámara. El punto proyectado debe alinearse con el TCP visible a menos de 5 píxeles en todas las posiciones del espacio de trabajo. Los errores > 10 px suelen indicar una posición incorrecta de montaje de cámara - revise la rigidez de su montaje y recuerde datos extrínsecos.
ROS2 Imagen de la tubería de transporte
El paquete
| 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 |
Recomendación: Utilice el transporte comprimido JPEG con una calidad del 80% para la recopilación de datos estándar. Los artefactos de compresión de este nivel de calidad están por debajo del nivel de ruido de la mayoría de las líneas de formación de políticas. Para los conjuntos de datos de investigación de mayor fidelidad, use PNG sin pérdidas pero planea un aumento de almacenamiento de 10 veces.
El formato de grabación HDF5 para el aprendizaje de imitación
El tubo de grabación debe capturar marcos sincronizados, estados conjuntos de robots y etiquetas de acción en un solo archivo por demostración. HDF5 es el formato estándar utilizado por ACT, Política de difusión y la mayoría de los marcos de aprendizaje de imitación.
Estructura de la FHD5 recomendada
/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
Escribe HDF5 en 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
Alineamiento de marcos: Al momento de escribir, alinear todos los datos con el marcador de tiempo de activación.
Registro de la arquitectura de tuberías
El tubo de grabación completo desde el sensor de la cámara hasta el archivo HDF5:
- Nodo de conductor de cámara (uno por cámara): Publica
T31 en T32 y T33 . - Nodo de sincronización: Utiliza
T34 para alinear los marcos de todas las cámaras + T35 + T36 . Publica un mensaje personalizado T37 . - Nodo de grabación: Se suscribe a
T38 , se almacenan en la memoria y se despeja a HDF5 en el límite del episodio (desencadenado por la presión del botón del operador o la señal de parada de la teleoperación). - Compresión (opcional): Si se graba a alta resolución, ejecuta la codificación H.264 en un hilo separado para evitar bloquear el bucle de grabación.
Para el almacenamiento en la nube y la gestión de conjuntos de datos, utilice [Servicios de datos de RCSV]
Planificación del almacenamiento
Antes de iniciar una campaña de recopilación de datos, calcule sus necesidades de almacenamiento:
** Ejemplo: Configuración de 3 cámaras a 15 Mbps por cámara, 8 horas de día de recogida:** 3 cámaras x 15 Mbps x 3600s/h x 8hr / 8 bits/byte / 1e9 GB = 162 GB/día.
| 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 |
Configuración de la iluminación
Las políticas entrenadas bajo iluminación inconsistente a menudo fallan en su implementación cuando las condiciones de iluminación difieren.
- ** Temperatura de color:** Utilice ** 5500K de luz diurna de LED balanceadas luces de anillo** (por ejemplo, la luz de anillo de Neewer 18" en $60/unidad).
- Posición: Colocar las luces en ángulos de 45 grados desde el eje de la cámara superior para minimizar los reflejos especulares de los objetos brillantes y las superficies de los robots.
- Difusión: Agregar paneles de difusión (hojas de acrílico congelado) frente a las luces para eliminar las sombras duras.
- ** Cortinas de apagón:** Para las instalaciones de laboratorio cerca de las ventanas, instale cortinas de apagón para eliminar la variación de la luz ambiental de las nubes y el ángulo del sol. Esta es una de las inversiones de ROI más altas en la calidad de la recopilación de datos.
Problemas y soluciones comunes
| 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) |
| Calibración reprojection >1 px | Too few or poorly distributed calibration images | Collect 30+ images covering all corners at varied distances |