Comienza con la teleoperatoria robótica en 2026

Parte de: [Guía de la teleoperación]

La teleoperatoria - controlar un robot de forma remota en tiempo real - es la forma más rápida de recopilar datos de capacitación de alta calidad y la base de la implementación moderna de robots. Ya sea que esté construyendo un conjunto de datos de aprendizaje de imitación o ejecutando un piloto de inspección remota, esta guía le guiará a través de todo lo que necesita para comenzar.

¿Qué es la teleoperatoria robótica?

Teleoperación significa que un operador humano controla un robot usando una interfaz de control - transmitiendo comandos a través de una red local o remota mientras recibe retroalimentación sensorial (vídeo, fuerza, posición) a cambio. En el contexto del aprendizaje robótico, las demostraciones teleoperadas son el estándar de oro para la recopilación de datos de entrenamiento porque codifican estrategias humanas naturales que son difíciles de programar manualmente.

El bucle de teleoperación tiene cuatro etapas: (1) el operador observa el entorno del robot a través de las cámaras y los datos proprioceptivos, (2) el operador genera comandos a través de un dispositivo de control, (3) se transmiten comandos al robot y se ejecutan, (4) todas las observaciones y acciones se registran sincrónicamente para su posterior uso como datos de entrenamiento. La calidad de cada etapa afecta directamente tanto el rendimiento de control en tiempo real como la utilidad de la serie de datos registrada.

En 2026, la teleoperatoria sirve dos propósitos distintos que cada vez convergen más. El primero es ** operación remota directa** - un humano controla un robot para realizar un trabajo útil a distancia (inspección, mantenimiento, tareas de entorno peligroso). El segundo es demonstration collection - un humano opera el robot específicamente para generar datos de capacitación para políticas de aprendizaje de imitación como [ACT]T7) o Política de difusión. Los requisitos de hardware y software se superponen sustancialmente, por lo que los equipos que comienzan con la recopilación de datos a menudo pasan naturalmente a capacidades de despliegue remoto.

El hardware que necesitas para empezar

Una configuración básica de teleoperación requiere cinco componentes: un brazo robótico o plataforma móvil, cámaras, un dispositivo de control, un nodo de cálculo para la transmisión y registro y un sistema de registro para capturar observaciones y acciones sincronizadas. Para los equipos que usan OpenArm, la configuración del líder-seguidor de RCSV tarda menos de 30 minutos en ensamblarse.

Comparación de dispositivos de control

El dispositivo de control es la elección de hardware más importante porque determina el techo de calidad de sus demostraciones.

Control Device	Latencia	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

Nuestra recomendación: Para los equipos que recopilan datos de aprendizaje de imitación sobre tareas de manipulación de mesa, el brazo líder es el ganador claro. La configuración líder-seguidor al estilo ALOHA (cadena cinemática idéntica para los brazos líder y seguidor) elimina completamente el problema de retargeting: posiciones conjuntas desde el mapa del brazo líder directamente a comandos conjuntos en el brazo seguidor sin paso cinemático inverso. Es por eso que ACT funciona tan bien en los datos ALOHA: las demostraciones son mecánicamente limpias.

Para la teleoperación humanoide de todo el cuerpo (Unitree G1, Booster K1), los controladores VR emparejados con el seguimiento del cuerpo son el estándar actual. La Quest 3 con seguimiento manual proporciona un mapa de dedos adecuado para simples agarres, pero las tareas de deducción de deducción de deducción de deducción de deducción de deducción de deducción todavía requieren hardware de guantes dedicado. RCSV admite las cuatro interfaces a través de la [plataforma de control de teleópteros]

Por qué importa la latencia: el umbral de 50 ms

La latencia de extremo a extremo, el tiempo que pasa de la entrada del operador al movimiento del robot, es la métrica de rendimiento más importante en la teleoperación. Hay tres umbrales críticos:

• <20ms: El operador no percibe ningún retraso. El robot se siente como una extensión directa de la mano. Esto se puede lograr con los brazos del líder en una conexión USB local / serie. Los datos recogidos en esta latencia contienen el comportamiento humano más natural y fluido.
• 20-50ms: Perceptible pero manejable. Los operadores se adaptan en cuestión de minutos y producen buenos datos de demostración. Esto es típico de la teleoperación de la red local (operador en el mismo edificio, robot conectado a través de Ethernet).
• ** 50-150ms:** Los operadores se ralentizan significativamente para compensar el retraso. Las demostraciones se vuelven cautelosas y torpezas - el operador se mueve, espera comentarios, ajusta, espera de nuevo. Este patrón de "mover y esperar" entraña políticas que son lentas y vacilantes. La calidad de los datos se degrada sustancialmente por encima de los 50ms.
• >150ms: La manipulación fina se vuelve poco práctica. Sólo las tareas de posicionamiento bruto y navegación funcionan confiablemente. Esto es típico de la teleoperación remota basada en Internet a través de zonas horarias.

La latencia tiene cuatro componentes, cada uno de los cuales debe medirse y minimizarse de forma independiente:

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

Configuración de la cámara: el estándar de tres cámaras

La colocación de la cámara es la segunda decisión más impactante después de la elección del dispositivo de control.

• Camera de la cabeza (fija): Proporciona una vista de espacio de trabajo desde arriba hacia abajo. Es esencial para el razonamiento espacial - donde los objetos son relativos entre sí. Montar a 0,8-1,2 m sobre la superficie de la mesa apuntando directamente hacia abajo. Resolución: 640x480 es suficiente; resoluciones más altas añaden ancho de banda sin mejoras proporcionales de la política.
• Camera lateral (fija): Captura la relación espacial entre el brazo y el objeto y el ángulo de aproximación.
• Camera de muñeca (montada en el efecto final): Captura la zona de contacto de agarre desde milímetros de distancia. Esta es la cámara única más impactante para la manipulación fina - estudios del equipo ALOHA y otros muestran que la adición de una cámara de muñeca mejora las tasas de éxito de la política en 20-40% en tareas ricas en contacto.

La sincronización de la cámara importa. Si las marcas de tiempo de observación están fuera de las marcas de tiempo de acción en más de 10 ms, estás entrenando la política sobre datos desalineados - ve el mundo en el tiempo t pero lo asocia con la acción desde el tiempo t+delta. En tareas rápidas (grapps completando en 200-400 ms), incluso 20 ms de desalineamiento degrada el rendimiento de la política de manera medible. Utilice disparadores de hardware o sincronización de software basada en timestamp.

Resolución de cámara vs. velocidad de fotogramas tradeoff: Para el aprendizaje de imitación, la velocidad de fotogramas importa más que la resolución. Una corriente de 640x480 a 30 fps produce mejores datos de entrenamiento que una corriente de 1920x1080 a 15 fps. La política necesita continuidad temporal para aprender dinámica de movimiento.

Teléoperación local vs remota

La teleoperatoria local (operador en la misma habitación) logra la latencia más baja, generalmente por debajo de 5 ms de extremo a extremo, y es el estándar para la recopilación de datos. La teleoperatoria remota (operador en una ubicación diferente) introduce la latencia de la red, pero permite escenarios de implementación como inspección remota, gestión de instalaciones y recopilación de datos distribuida. La [plataforma de datos] de RCSV(T10) admite ambos modos con compresión de corriente adaptativa y monitoreo de latencia incorporado.

Para la teleoperación remota, el flujo de video es el cuello de botella, no los comandos de control. Los comandos de control son pequeños (<100 bytes por paquete a 50Hz), pero un 640x480 RGB no comprimido a 30 fps es de 28 MB/s por cámara. Con tres cámaras, es 84 MB/s antes de comprimir. El código de hardware H.264 en el lado del robot reduce esto a 2-5 Mbps por flujo con una calidad aceptable, pero el código añade 15-30ms de latencia. La pila de teleop remoto RCSV utiliza el código acelerado por hardware en NVIDIA Jetson con parámetros ajustados para una latencia mínima (preestablecimiento de latencia cero, trama de trama, refrescamiento interno).

El formato de datos y la grabación de ACT

La mayoría de los marcos modernos de aprendizaje de imitación - ACT, Diffusion Policy, LeRobot - consumen datos de entrenamiento en formato HDF5 con una estructura específica. Cada episodio se almacena como un grupo que contiene matrices sincronizadas para observaciones (imágenes, posiciones conjuntas, estado de agarre) y acciones (posiciones o velocidades de las articulaciones objetivo). Aquí está el esquema estándar:

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

A continuación se muestra un script de grabación de Python mínimo que captura datos sincronizados de un OpenArm con tres cámaras USB. Esta es una versión simplificada de lo que funciona la tubería de grabación de RCSV: la versión de producción añade detección automática de éxito, métricas de calidad en tiempo real y carga en la nube.

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)")

Recopilar demostraciones de alta calidad

Las buenas demostraciones son consistentes, diversas y exitosas. La coherencia significa seguir un protocolo definido para la colocación de objetos, la estrategia de enfoque y la finalización de tareas. El control de calidad en RCSV incluye la revisión en tiempo real de los episodios, la detección automática de anomalías y los disparos de retoma cuando una demostración cae fuera de los límites de calidad.

Protocolo de formación de operadores

La calidad de los operadores es el factor más subestimado en los datos de demostración. Un operador experimentado produce demostraciones que son 2-3 veces más consistentes que un principiante, lo que se traduce directamente en el rendimiento de la política.

1. ** Familiarización (30 min):** Exploración gratuita con el dispositivo de control y el robot. No se graba datos. Objetivo: construir la intuición cinestética para el espacio de trabajo del robot, los límites de velocidad y los límites de fuerza.
2. Episodos de práctica (20-30 episodios): Realice la tarea objetivo con comentarios de un operador experimentado. Estos episodios no se utilizan para entrenamiento, son datos de calentamiento.
3. ** Prueba de calibración (10 episodios):** Registrar 10 episodios y medir la tasa de éxito, el tiempo de finalización y la suavidad de la trayectoria (magnitud media de sacudida).
4. Registro de producción: Registra demostraciones para datos de formación. Cada 50 episodios, revise las métricas de calidad para detectar la deriva.

Metricas de calidad de los episodios

Para cada episodio registrado, el canal de RCSV calcula y registra estas señales de calidad:

• Tiempo de finalización: Debe estar dentro de 1,5 veces de la media de referencia. Los episodios anormalmente rápidos a menudo indican pasos saltados; los episodios anormalmente lentos indican la vacilación del operador.
• Seability of trajectory: El jerk medio (tercer derivado de la posición conjunta) debe estar por debajo de un umbral específico de la tarea.
• Duración del agarre: Tiempo desde el primer contacto hasta el agarre estable.
• Exito de tarea: Binario - ¿alcanzó el episodio el estado objetivo? Los episodios fallidos se registran por separado y se pueden utilizar para ejemplos negativos o entrenamiento de comportamiento de recuperación, pero no deben incluirse en el conjunto de entrenamiento primario.

Los modos de falla comunes y cómo solucionarlos

Después de apoyar cientos de programas de teleoperación, RCSV ha catalogado los modos de falla más frecuentes que los equipos encuentran al configurar la teleoperación por primera vez:

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.
Gripper commands lag behind arm commands	Gripper 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.

La pila de software: qué funciona dónde

Una configuración de teleoperación de producción ejecuta software en tres máquinas.

• ** Computación en el lado del robot (por ejemplo, Jetson Orin Nano, $249):** Ejecuta el bucle de control en tiempo real (50-500Hz), captura y codificación de la cámara y ejecución de la acción. Esta máquina debe ejecutar un kernel en tiempo real (PREEMPT_RT) o al menos un kernel de baja latencia para evitar el jitter. Python es aceptable para la ruta de registro pero el bucle de control interno debe ser C++ o usar una extensión de Python que libere el GIL.
• ** Estación de trabajo del operador:** Ejecuta el controlador de interfaz de control, el decodificador de video y la interfaz de usuario del operador. Para la teleoperación local, esta puede ser la misma máquina que el computación del lado del robot. Para la teleoperación remota, es una máquina separada conectada a través de WebRTC o un protocolo de transmisión UDP personalizado.
• Servidor de datos / nube: Se ejecuta almacenamiento de episodios, cálculo de métricas de calidad, gestión de conjuntos de datos y coordinación de la tubería de entrenamiento.

Cómo iniciar un programa de teleoperatoria con RCSV

Hay tres caminos dependiendo de tu punto de partida:

• ** Recopilación de datos de servicio completo ($2,500 piloto / $8,000 campaña):** Describe su tarea y robot objetivo - RCSV proporciona el hardware, operadores capacitados, entorno de laboratorio y conjunto de datos postprocesados en formato HDF5/RLDS. Lo mejor para equipos que necesitan datos de capacitación sin construir infraestructura de teleop.
• Plataforma + su hardware: Usted es propietario o arrenda el robot - RCSV proporciona la pila de software de teleop, la tubería de grabación, la gestión de conjuntos de datos y las métricas de calidad a través de la plataforma de datos. Suscripción mensual, no se requiere compra de hardware.
• Arrendamiento de hardware + plataforma: Alquiler de un OpenArm u otra plataforma a través del [programa de arrendamiento] de RCSV(T16) y obtener la pila completa de software incluido. Camino más rápido desde cero a la recopilación de datos - la mayoría de los equipos graban su primer episodio dentro de las 4 horas de entrega de hardware.

Para los equipos que quieran explorar la interfaz antes de comprometerse, pruebe la [caja de arena de teleoperación virtual] ((T17) -- un simulador basado en un navegador que ejecuta la interfaz de usuario completa de la teleop de RCSV contra un robot simulado.

Lectura relacionada

• Política ACT explicada -- cómo el algoritmo de aprendizaje de imitación más popular utiliza datos de teleop
• Erros comunes en el aprendizaje por imitación de robots -- trampas de calidad de datos para evitar
• [¿Qué es los datos de entrenamiento de robots?] T20) -- formatos, estándares y mejores prácticas
• Servicios de datos de la RCSV -- Teléoperación y recopilación de datos gestionados
• [Cómo alquilar un robot]T22) -- conseguir hardware para su programa de teleop

¿Listo para comenzar a recopilar datos de Teleop?

RCSV proporciona la recopilación de datos de teleoperación de servicio completo, hardware arrendado y la plataforma de software para administrar sus conjuntos de datos. Obtenga su primer conjunto de datos en días, no meses.

[Servicios de datos] [T23] [Hablar con un ingeniero] [T24]