Teleoperación de robots a través de Internet: manejo de la latencia y la pérdida de paquetes

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

[← Blog] T3)

La teleoperación remota a través de Internet es esencial para escalar la recopilación de datos a nivel mundial. Aquí está lo que se necesita para que funcione de manera confiable.

Requisitos de latencia por tarea

No todas las tareas de teleoperación tienen la misma tolerancia de latencia.

• Tascas de contacto de precisión (<30 ms requeridas): Insertar peg, seguir la superficie, apareamiento de conectores. A estas tolerancias, solo la teleoperación de la red local de área es viable. Incluso 50 ms introduce un retraso de fase suficiente en el bucle de retroalimentación del operador para hacer que el juicio preciso de contacto sea poco fiable.
• **Tascas de precisión media (100300ms aceptables):**Pick-and-place de objetos con tolerancia > 5 mm, manipulación de objetos grandes, control de movimiento.
• Tascas de alta latencia (>500ms no viable para el control directo): A esta latencia, la teleoperación directa se rompe para cualquier tarea que requiera control reactivo. control de supervisión (enviar comandos de alto nivel, el robot ejecuta de forma autónoma) es el único modo viable por encima de 500ms.

Fuentes de latencia y optimización

Pipeline Stage	Typical Latencia	Optimization
Network propagation (US coast-to-coast)	70–90ms	Operator geographic routing — match operators to nearby robots
Video encoding (H.264 software)	50–100ms	Switch to WebRTC VP8 hardware encode: 15–30ms
Video decoding (browser)	10–30ms	Enable hardware acceleration in browser
Control command serialization/deserialization	2–5ms	Binary protocol (MessagePack/protobuf) vs JSON
Robot controller loop overhead	5–20ms	High-priority RT thread for command processing
Camera capture + USB frame delivery	10–33ms	USB3 camera at 60fps: 16ms max frame age

Estrategias de compensación de la latencia

• Predictor Smith: Una técnica clásica de compensación de control para sistemas con un retraso constante conocido. El predictor Smith ejecuta un modelo interno de la dinámica del robot en paralelo, desplazado por el retraso de ida y vuelta, por lo que el operador controla efectivamente la salida del modelo en lugar de la salida real retrasada. Funciona bien cuando el retraso es estable y el modelo de la planta es preciso. Se desmorona con un temblor de Internet variable (±30 ms de oscilaciones rompen la suposición de retraso constante).
• Lidado visual: Los operadores están capacitados para apuntar a dónde estará el robot en lugar de donde el video lo muestra actualmente. Una superposición visual en la interfaz del operador muestra la posición del robot predicha en función del último comando y la latencia conocida.
• ** Selección de tareas por nivel de latencia:** La estrategia más robusta. Mide la latencia de ida y vuelta al inicio de la sesión y envía automáticamente a los operadores a las tareas apropiadas. Los operadores con RTT <50ms obtienen tareas críticas de contacto; los operadores con RTT 100200ms obtienen el lugar de selección estándar; los operadores superiores a 250ms se asignan a tareas de navegación o supervisión.

Comparación de tecnología de transmisión de video

Technology	Glass-to-Glass Latencia	Bandwidth	Recommendation
WebRTC VP8 (hardware encode)	30–50ms	2–8 Mbps	Best for teleoperation — use this
WebRTC H.264	40–80ms	1.5–5 Mbps	Good fallback if VP8 not available
H.264 over RTSP	100–150ms	1–3 Mbps	Acceptable for supervisory control
MJPEG over HTTP	100–300ms	10–50 Mbps	Avoid — high bandwidth, high latency
JPEG frames over WebSocket	200–500ms	5–20 Mbps	Do not use for teleoperation

El flujo de latencia: donde va cada milisegundo

La latencia total de extremo a extremo en un sistema de teleoperación es la suma de múltiples etapas de tubería, cada una contribuyendo de forma independiente.

Una sesión típica de teleoperatoria doméstica de EE.UU. (operador en SF, robot en NYC) tiene una línea total de: captura de cámara (16 ms a 60fps) + codificación de vídeo (25 ms WebRTC VP8) + propagación de red (75 ms de costa a costa) + decodificación de video (15 ms) + percepción y reacción del operador (150-300 ms) + serialización de comandos (3 ms) + viaje de regreso de red (75 ms) + deserialización de comandos (3 ms) + procesamiento del controlador robot (10 ms) = 372-522 ms latencia total de bucle. De esto, el tiempo de reacción del operador domina. La porción controlada por ingeniería (todo excepto la reacción humana) es de aproximadamente 222 ms, con la propagación de la red que representa el 68% de la latencia controlada.

Esta descomposición revela una visión importante: optimizar el codificación de video de 100 ms a 25 ms (una mejora de 75 ms) tiene aproximadamente el mismo impacto que mover al operador 1,000 km más cerca del robot (lo que reduce el RTT en aproximadamente 10 ms por 1,000 km).

Compensación avanzada de retraso: Variables de onda y métodos de predicción

Fomulación variable de onda: Las variables de onda (Niemeyer y Slotine, 1991) transforman las señales de control de la fuerza de velocidad en variables de onda que se propagan a través del canal de comunicación. Esto hace que las variables de onda sean el enfoque teóricamente correcto para la teleoperación bilateral de retroalimentación de fuerza sobre redes de retraso variable.

En la práctica, las implementaciones de las ondas variables intercambian estabilidad por transparencia - el operador siente una respuesta "moscada" en lugar de retroalimentación de fuerza nítida, porque la transformación de onda suaviza la señal de fuerza. Para las tareas de recopilación de datos donde la calidad de retroalimentación de fuerza es secundaria a la finalización de la tarea, este compromiso es aceptable. Para la teleoperatoria quirúrgica en la que la transparencia de la fuerza es crítica, las variables de onda se combinan con modelos de fuerza locales que mejoran la transparencia percibida sin violar la pasividad.

** Compensamiento basado en predictor:** Más allá del predictor Smith (que asume un retraso constante), los predictores de retraso que varían en el tiempo utilizan un modelo dinámico local del robot para predecir su estado hacia adelante por el retraso estimado actual. El predictor basado en filtros de Kalman es el más común: mantiene una estimación del estado del robot remoto y lo propaga hacia adelante utilizando el modelo de dinámica del robot y los comandos de control más recientes. Este enfoque maneja bien el jitter variable pero requiere un modelo dinámico preciso del robot remoto.

Teléoperación mediada por modelo: El operador interactúa con una réplica virtual local del entorno remoto. La réplica se actualiza de manera sincrónica a partir de los datos de los sensores del robot real. El operador controla la réplica virtual con cero retraso, y el robot real realiza un seguimiento del estado de la réplica virtual con cualquier retraso que la red imponga. Esto separa completamente la experiencia del operador de la calidad de la red. El costo: la réplica virtual puede divergir de la realidad si el entorno cambia de manera que la réplica no se mude (un objeto se mueve, una persona entra en el espacio de trabajo).

Comparación de protocolo: TCP vs. UDP vs. QUIC vs. WebRTC

Protocol	Control Commands	Video	NAT Traversal	Recommendation
TCP (WebSocket)	Reliable delivery; head-of-line blocking adds 10-50ms on packet loss	Usable but suboptimal -- retransmits stale frames	Works everywhere	Use for non-time-critical data (logs, config)
UDP	Lowest latency; no retransmit; application handles loss	Requires custom codec integration	Often blocked by firewalls	Best for control commands if NAT is not an issue
QUIC	Independent streams -- no HOL blocking; built-in encryption	Promising; no mature video-over-QUIC stack yet	Built on UDP; ICE-like traversal needed	Future-best; not mature enough for production in 2026
WebRTC	DataChannel (SCTP/UDP): reliable or unreliable modes	Native video codec support; adaptive bitrate; congestion control	ICE + STUN/TURN built-in	Production choice for 2026 -- handles video + control + NAT

La plataforma de teleop de RCSV utiliza WebRTC tanto para video (canales de medios) como para comandos de control (DataChannel poco fiable). Para las señales de seguridad crítica (e-stop), un TCP WebSocket paralelo y fiable garantiza la entrega garantizada.

Medidas de latencia en el mundo real

RCSV ha recopilado datos de latencia de más de 500 sesiones de teleoperación remota en una variedad de condiciones de red.

Route	Median RTT	P95 RTT	Packet Loss	Data Quality Impact
Same city (fiber)	8ms	15ms	<0.01%	Indistinguishable from local
SF to NYC (fiber)	72ms	95ms	0.02%	5-8% lower demo quality (slower, more hesitant)
US to Europe (fiber)	130ms	180ms	0.05%	15-20% lower demo quality; contact tasks degraded
US to Asia (fiber)	175ms	250ms	0.1%	25-35% lower quality; pick-place only
Home WiFi (shared)	35ms	250ms	0.5-2%	Jitter is the killer -- intermittent 200ms+ spikes cause jerky demos

La columna de impacto de la calidad de los datos refleja la diferencia medida en la suavidad de la demostración (tiro medio) y el tiempo de finalización de tareas en comparación con la teleoperación local. La conclusión crítica: la latencia por debajo de 100ms RTT produce demostraciones que son estadísticamente indistinguibles del control local para las tareas estándar de pick-place. Por encima de 200 ms, solo las tareas lentas y no de contacto producen datos de demostración utilizables.

Tratamiento de pérdidas de paquetes

La pérdida de paquetes de Internet es típicamente de 0,01-0,5% en buenas conexiones, pero puede aumentar a 2-5% durante la congestión. Para los comandos de control enviados a 50 Hz, la pérdida de 1% significa que se pierde un comando cada 2 segundos. El impacto depende de cómo el controlador receptor maneje los comandos faltantes:

• Hold last command (hold de orden cero): El robot continúa ejecutando el último comando recibido hasta que llega uno nuevo. Seguro para los comandos de velocidad (el robot continúa en la última velocidad ordenada).
• Extrapolar (detenerse en primer orden): El robot extrapola la trayectoria de comando en función de los dos últimos comandos recibidos. Mejor para una continuidad de movimiento suave, pero puede sobrepasar si el operador se estaba desacelerando.
• ** Puente de interpolación:** Puente de 2-3 comandos futuros (agrega una latencia de 40-60 ms) e interpola entre ellos.

El RCSV utiliza un buffer de interpolación de 2 comandos con profundidad adaptativa: el buffer crece durante los períodos de alta pérdida (detectado mediante el monitoreo de intervalos entre paquetes) y se reduce durante los períodos estables. Esto proporciona una calidad de movimiento consistente al costo de una latencia ligeramente variable (50-100 ms buffer adicional en el peor de los casos).

Lectura relacionada

• [Estudio de fatiga y ergonomía de la teleoperatoria]
• [Datos de formación de robots: métodos de recogida y mejores prácticas]
• [Annotación de la trayectoria de los robots: desafíos y normas de calidad]
• [Lista de control de despliegue de robots]
• [Plataforma de Teleop de la RCSV]
• [Servicios de recogida de datos del RCSV]

La gestión de los Jitter: el problema subestimado

La latencia de la red recibe la atención, pero el nerviosismo - la variación en la latencia a lo largo del tiempo - a menudo es más dañino para la calidad de la teleoperación que el retraso absoluto. Un retraso constante de 100 ms es manejable con técnicas de conducción visual. Una conexión que oscila entre 30 ms y 200 ms produce un comportamiento robótico torpe e impredecible al que los operadores no pueden adaptarse.

** Medir el nerviosismo.** RCSV mide el nerviosismo como el interquartilo de rango (IQR) de los tiempos de ida y vuelta durante una ventana de 30 segundos. Una conexión saludable tiene un IQR por debajo de 10 ms. Las conexiones marginales muestran un IQR de 10-30 ms. Las conexiones con IQR por encima de 30 ms producen demostraciones de calidad demostrativamente inferior y deben desencadenar una pausa de sesión hasta que las condiciones de la red mejoren.

** Puffer de jitter.** La mitigación estándar es un puffer de jitter en el lado del robot que retiene los comandos recibidos durante una duración configurable antes de ejecutarlos. Un puffer de jitter de 50 ms elimina la mayoría de los artefactos de jitter a costa de una latencia adicional de 50 ms. La profundidad del puffer debe ser adaptativa: fijada en el 95o percentil RTT menos el RTT medio, actualizado cada 10 segundos. Durante los períodos estables (bajo nerviosismo), el amortiguador se reduce para minimizar la latencia.

# adaptive_jitter_buffer.py -- Adaptive jitter buffer for teleop commands
import collections
import time
import numpy as np

class AdaptiveJitterBuffer:
    """Buffer incoming teleop commands to smooth out network jitter."""

    def __init__(self, min_depth_ms=10, max_depth_ms=100):
        self.min_depth = min_depth_ms / 1000.0
        self.max_depth = max_depth_ms / 1000.0
        self.rtt_history = collections.deque(maxlen=100)  # Last 100 RTT samples
        self.buffer = collections.deque()  # (release_time, command) pairs
        self.current_depth = self.min_depth

    def update_rtt(self, rtt_seconds):
        """Feed in a new RTT measurement."""
        self.rtt_history.append(rtt_seconds)
        if len(self.rtt_history) >= 20:
            p50 = np.percentile(list(self.rtt_history), 50)
            p95 = np.percentile(list(self.rtt_history), 95)
            self.current_depth = np.clip(p95 - p50, self.min_depth, self.max_depth)

    def enqueue(self, command):
        """Add a command with its scheduled release time."""
        release_time = time.monotonic() + self.current_depth
        self.buffer.append((release_time, command))

    def dequeue(self):
        """Return the next command if its release time has passed."""
        now = time.monotonic()
        if self.buffer and self.buffer[0][0] <= now:
            return self.buffer.popleft()[1]
        return None  # No command ready; use hold-last or extrapolation

Diseño de interfaz de operador para la latencia

La interfaz de usuario del operador puede mitigar significativamente el impacto percibido de la latencia a través de la visualización predictiva y la retroalimentación del estado.

• Posicionamiento superficial previsto: Muestre un fantasma semitransparente del robot en la posición que alcanzará basándose en el último comando enviado y el retraso estimado actual. Implementación: mantener un modelo cinemático local que procesa los comandos de inmediato y hace la predicción junto con la transmisión de vídeo retrasada.
• ** Indicador de latencia:** Muestre el RTT actual de forma prominente en la interfaz del operador. Utilice el código de color verde/amarillo/rojo: verde por debajo de 100 ms, amarillo por debajo de 100-200 ms, rojo por encima de 200 ms. Los operadores deben ajustar su velocidad y nivel de precaución en función del nivel de latencia actual. La plataforma de RCSV utiliza un indicador de latencia en la esquina superior derecha de la vista de teleop.
• Escalado de retroalimentación de fuerza: Al utilizar dispositivos de retroalimentación háptica, escala el aumento de retroalimentación de fuerza inverso a la latencia. A baja latencia (< 50ms), la retroalimentación de fuerza completa proporciona información de contacto útil. A alta latencia (> 150ms), el retroalimentación de fuerza de alta ganancia causa oscilación porque el retraso de fase entre la entrada del operador y la respuesta de fuerza supera el margen de estabilidad. Reducir la ganancia al 30-50% en 150 ms + latencia.
• Limitar la velocidad: Reducir automáticamente la velocidad máxima ordenada a medida que aumenta la latencia. A 50 ms RTT, permitir la operación de velocidad completa (1.0 m/s efecto final). A 150 ms RTT, limitar a 0.3 m/s. A 300 ms RTT, limitar a 0.1 m/s. Estos límites impiden que el operador de ordenar movimientos que se sobrepasaría debido a la retroalimentación visual tardía.

Evaluación de la calidad de los datos para sesiones remotas

La calidad de las demostraciones realizadas en sesiones de teleoperación remota debe evaluarse por separado de las sesiones locales.

• Liscosidad de trayectoria (tortura media): Compute la tercera derivada de la trayectoria de posición del efecto final. Las demostraciones remotas con una latencia superior a 100 ms generalmente muestran un tirón medio de 40 a 80% más alto que las demostraciones locales de la misma tarea. Las demostraciones con tirón superior a 2 veces la línea de base local deben ser marcadas para revisión - aún pueden tener éxito pero producen una señal de entrenamiento más ruidosa.
• Ratio de tiempo de finalización de tareas: Las demostraciones remotas tardan más que las demostraciones locales. Una relación de tiempo de finalización superior a 2,0x (el tiempo de finalización remoto dura más del doble que el tiempo local) se correlaciona con una calidad de demostración degradada (hesición excesiva, movimientos correctivos).
• Listo de comandos: Analizar el flujo de comandos en bruto del operador para discontinuidades - reversiones repentinas de velocidad, pausas largas y oscilaciones rápidas. Estos indican que el operador está luchando contra la latencia. Más de 3 reversiones por episodio en una simple tarea de pick-place es una bandera de calidad.

En la experiencia de RCSV, las demostraciones remotas recogidas en RTT de menos de 100 ms son indistinguibles de las demostraciones locales para fines de entrenamiento. Entre 100-200 ms, las demostraciones son utilizables, pero deben mezclarse 2:1 con las demostraciones locales en el conjunto de entrenamiento.

Configuración WebRTC para la teleoperación de robots

WebRTC es el protocolo estándar para la transmisión de vídeo en tiempo real en la teleoperación robótica porque maneja NAT traversal, bitrate adaptativo y buffer jitter nativo. Sin embargo, la configuración predeterminada de WebRTC está optimizada para la videoconferencia, no el control de robots. Cambios clave de configuración para la teleoperación:

// WebRTC configuration optimized for robot teleoperation
const rtcConfig = {
  iceServers: [
    { urls: 'stun:stun.l.google.com:19302' },
    { urls: 'turn:turn.roboticscenter.ai:3478',
      username: 'teleop', credential: 'token' }
  ],
  iceCandidatePoolSize: 10,  // Pre-gather candidates for faster connection
};

// Video encoder settings for low-latency robot camera streams
const videoConstraints = {
  width: { ideal: 640, max: 1280 },
  height: { ideal: 480, max: 720 },
  frameRate: { ideal: 30, max: 30 },
};

// SDP modifications for low latency (apply to offer/answer)
function optimizeSdp(sdp) {
  // Force VP8 (lower latency than H.264 in software encode)
  // Set max bitrate to prevent congestion-induced latency spikes
  sdp = sdp.replace(/a=fmtp:(\d+) /, 'a=fmtp:$1 max-fr=30;max-fs=3600;');
  // Add x-google-max-bitrate for Chrome
  sdp = sdp.replace(/a=mid:video\r\n/,
    'a=mid:video\r\nb=AS:2000\r\n');  // 2 Mbps cap
  return sdp;
}

Decisiones clave de sintonización: (1) Utilice VP8 sobre H.264 cuando no está disponible la codificación de hardware - VP8 tiene una latencia de codificación de software más baja. (2) Rate de bitratación de límite a 2 Mbps por cámara para evitar la hinchazón de búfer en la capa de red. (3) Utilice una resolución de 640x480 en lugar de 720p o 1080p - la diferencia de latencia a calidad favorece fuertemente una resolución más baja para la teleoperación. (4) Establezca la velocidad de fotogramas a 30 fps; bajar a 15 fps ahorra ancho de banda pero degrada el rendimiento del operador en tareas rápidas en ~ 20%.

Display predictivo: compensación por retraso visual

La pantalla predictiva es la técnica más efectiva para mantener el rendimiento del operador a 100-300 ms de latencia. El sistema reproduce un estado del robot previsto sobre la imagen de la cámara retrasada, mostrando al operador dónde está el robot ahora (predecible) en lugar de dónde estaba cuando se capturó la imagen.

La implementación requiere: (1) un modelo cinemático del robot que pueda predecir las posiciones conjuntas T_latency segundos en el futuro, (2) una superposición de renderización 3D que muestra la posición del robot predicha en la parte superior de la cámara de alimentación, y (3) un estimador de latencia que mantiene el horizonte de predicción coincidiendo con el retraso de ida y vuelta real.

Para los movimientos simples (llegando al espacio libre), la predicción cinemática avanzada utilizando la última trayectoria ordenada es suficiente y agrega computación insignificante. En las evaluaciones de RCSV, la pantalla predictiva mantiene el rendimiento del operador a 150ms RTT a un 90% de la línea de base de latencia cero para tareas de pick-and-place y dentro del 70% para tareas de inserción.

Gestión de flujo de múltiples cámaras

Las configuraciones de teleoperación de producción suelen utilizar 2-4 cámaras (overhead, wrist, side views).

• Camera de pulsera: La máxima prioridad. Resolución completa (640x480), 30 fps, compresión más baja. Esta es la referencia espacial principal del operador para la manipulación fina.
• Corrido secundario (overhead): Prioridad media. 320x240, 15fps durante el movimiento en el espacio libre; 640x480, 30fps durante la fase de captura. La vista overhead proporciona contexto del espacio de trabajo pero es menos crítica en marco por marco.
• Reacciones terciarias (visualizaciones laterales): Prioridad más baja. 320x240, 10fps normalmente. Activado a resolución completa solo cuando el operador selecciona explícitamente la vista. Estas corrientes son reservas de ancho de banda que se pueden recuperar cuando la corriente primaria necesita más ancho de banda.

Ancho de banda total para esta configuración: 3-6 Mbps sostenido, 8 Mbps máximo. Si el ancho de banda disponible cae por debajo de 4 Mbps, reduzca progresivamente las corrientes secundarias y terciarias antes de degradar la primaria. La plataforma de RCSV implementa este esquema de prioridad automáticamente con monitoreo de ancho de banda en tiempo real.

Lectura relacionada

Guía de aprendizaje de imitación · Costo por análisis de demostración · Guía de configuración de ALOHA móvil · Desafíos de anotación de datos · Servicios de datos · Plataforma RCSV

Protocolos de comando de control: UDP vs. TCP vs. WebSocket

La elección del protocolo de transporte para los comandos de control tiene un impacto significativo en la latencia y fiabilidad de la teleoperación.

Protocol	Latencia Overhead	Reliability	NAT Traversal	Best Use Case
Raw UDP	Minimal (< 1ms)	Unreliable (no retransmit)	None (need VPN or port forward)	LAN teleoperation with direct network access
WebRTC DataChannel	Low (2-5ms)	Configurable (ordered/unordered, reliable/unreliable)	Built-in (STUN/TURN)	Internet teleoperation (RCSV recommendation)
WebSocket (TCP)	Medium (5-20ms)	Reliable (TCP retransmit)	Easy (HTTP upgrade)	Monitoring, non-time-critical control
gRPC (HTTP/2)	Medium (5-15ms)	Reliable	Requires proxy	Structured control APIs, microservice architecture

Guía de selección de protocolos: Para implementaciones solo LAN (robot y operador en el mismo edificio), UDP crudo proporciona la latencia más baja con una complejidad mínima. Para la teleoperación basada en Internet a través de NAT y firewalls, los canales de datos WebRTC son la opción clara: manejan el cruce de NAT automáticamente y proporcionan confiabilidad configurable sin el problema de bloqueo de línea principal de TCP. WebSocket sobre TCP es adecuado solo para monitorear paneles de control o comandos no críticos en el tiempo (grabación de inicio/presa, cambios de parámetros de tareas) donde la fiabilidad es más importante que la latencia. gRPC es útil para las API de control estructuradas en las arquitecturas de microservicios, pero añade gastos generales de serialización que lo hacen inadecuado para los bucles de control de alta frecuencia.

El RCSV utiliza WebRTC DataChannels configurados en modo "no confiable, no ordenado" para comandos de control. Esto da latencia similar a UDP con cruce de NAT incorporado. Los comandos de control se envían a 50 Hz con números de secuencia; el receptor descarta comandos fuera de orden en lugar de reordenarlos (un comando obsoleto es peor que uno omitido). Para la retroalimentación del estado (posiciones conjuntas, lecturas de F/T), un canal de datos separado "confiable y ordenado" asegura que no se pierden actualizaciones de estado, a costa de una latencia ligeramente mayor en la retransmisión.

Compensación de la latencia por la calidad de la recopilación de datos

Las demostraciones de teleoperación remota recogidas en diferentes niveles de latencia requieren un manejo diferente en la línea de entrenamiento. La mezcla ciega de demostraciones de alta latencia y baja latencia puede degradar la calidad de la política porque los artefactos de latencia (hesaciones, correcciones, oscilaciones) son interpretados por la política como comportamiento intencional.

• Tag demostraciones con latencia de recogida. Registrar el promedio y P95 RTT para cada episodio.
• Demonstrantes de peso por calidad de latencia. Durante el entrenamiento, asignen pesas inversamente proporcionales a la latencia de la recopilación: peso = 1,0 para sub-50ms, 0,8 para 50-100ms, 0,5 para 100-200ms, 0,3 para 200ms. Esto reduce la influencia de los episodios degradados de latencia sin descartarlos por completo.
• Filtrar por suavidad de trayectoria. Calcule el jerk medio (tercera derivada de posición) para cada episodio. Los episodios con jerk superior a 2 desviaciones estándar de la media de tarea probablemente tengan una degradación de latencia.
• Lisquidad temporal como postprocesamiento. Aplicar un filtro Savitzky-Golay (ventana=11, orden=3) a las trayectorias de acción de los episodios de alta latencia antes de utilizarlos para el entrenamiento. Esto elimina las oscilaciones de alta frecuencia introducidas por el comportamiento del operador que compensa la latencia mientras se conserva la forma de trayectoria bruta.
• Formación estratificada por latencia. Para grandes conjuntos de datos recogidos en condiciones de red variables, entrenar políticas separadas sobre subconjuntos de baja latencia (<50ms) y alta latencia (50-200ms), y luego comparar el rendimiento. En la experiencia de RCSV, los conjuntos de datos donde más del 30% de los episodios tienen un RTT superior a 100 ms se benefician de filtración basada en latencia.

Gestión de sesiones de teleoperación para la recopilación de datos de producción

La gestión de múltiples operadores remotos en diferentes zonas horarias requiere infraestructura de gestión de sesiones más allá de la conectividad básica de WebRTC.

• Calificación de red previa a la sesión. Antes de cada sesión de recogida, ejecuta una prueba de calidad de red de 30 segundos que mide el RTT, el jitter, la pérdida de paquetes y el ancho de banda disponible. Si la red no cumple con los umbrales mínimos (RTT < 200ms, IQR < 30ms, ancho de banda > 5 Mbps), posponga la sesión. La recolección de datos sobre una red degradada desperdicia el tiempo del operador y produce demostraciones de baja calidad que pueden necesitarse descartar.
• ** Programación del operador.** Asesinar a los operadores a estaciones robóticas basadas en el nivel de latencia. Los operadores con RTT de menos de 50 ms (la misma región que el robot) obtienen prioridad para las tareas de precisión (L3/L4).
• Monitoreo automático de la calidad de la sesión. Rastrear RTT, jitter, pérdida de paquetes, velocidad de fotogramas y rendimiento del operador en tiempo real. Alertar al supervisor de la sesión cuando las métricas de calidad caigan por debajo de los umbrales (RTT > 200ms durante > 30 segundos, IQR de jitter > 50ms, velocidad de fotogramas < 20fps).
• Integritud de grabación de la sesión. Grabar el estado completo de la sesión (feeds de la cámara, estados conjuntos, datos de F/T, comandos del operador, métricas de red) en un archivo HDF5 sincronizado. Incluir métricas de calidad de la red como un canal de observación separado para que las tuberías de entrenamiento aguas abajo puedan utilizar información de latencia para la ponderación de datos.
• ** Manejo de la fatiga del operador.** Implemente sesiones de teleoperatoria continuas de 45 minutos máximos con descansos de 15 minutos obligatorios. Más allá de 45 minutos, la calidad de la demostración se degrada entre un 15 y un 25% debido a la fatiga independientemente de la calidad de la red. Consulte nuestro estudio de fatiga y ergonomíaT16) para más detalles.

Transmisiones de bitrate adaptativas para los vídeos de robots

A diferencia de la transmisión de video de entretenimiento donde el amortiguamiento es aceptable, el video de teleoperación del robot debe mantener una latencia baja constante incluso cuando el ancho de banda fluctúa.

Bandwidth Available	Resolution	Frame Rate	Bitrate	Operator Impact
> 20 Mbps	1280x720	30 fps	4-6 Mbps	Full quality; no perceptible degradation
10-20 Mbps	960x540	30 fps	2-3 Mbps	Slightly reduced clarity; no throughput impact
5-10 Mbps	640x480	30 fps	1-2 Mbps	Noticeable compression; 5-10% throughput reduction
2-5 Mbps	640x480	15 fps	0.5-1 Mbps	Choppy motion; 15-25% throughput reduction; L1/L2 tasks only
< 2 Mbps	480x360	10 fps	0.3-0.5 Mbps	Significant degradation; pause session if sustained > 60 seconds

El principio clave: siempre sacrificar la resolución antes de la velocidad de fotogramas. Los operadores pueden funcionar bien a una resolución de 640x480, pero luchan por debajo de 15 fps porque el retraso de retroalimentación visual dificulta el posicionamiento preciso. El codificador de video del lado del robot (codificación de hardware de VP8 en Intel / NVIDIA, o codificación de software VP9) debe responder a las estimaciones de ancho de banda dentro de 200 ms para evitar la cola de cuadros, lo que agrega una latencia peor que cualquier reducción de resolución.

Calidad de los datos de la teleoperación de medición e información

Cada sesión de recopilación de datos de teleoperación debe elaborar un informe de calidad junto con los datos de demostración.

• ** Medidas de calidad de la red por episodio:** Medida de RTT, P95 RTT, IQR jitter, porcentaje de pérdida de paquetes, utilización media de ancho de banda.
• Métricas de rendimiento del operador: Tiempo de finalización de tareas, fluidez de trayectoria (tiro medio), número de correcciones/hesaciones (detectadas a partir de cruces de velocidad cero), porcentaje de tiempo de inactividad.
• Estado del hardware en el momento de la recogida: Estabilidad de la velocidad de los cuadros de la cámara (cualquier cuadros caídos), velocidad de lectura del codificador conjunto, nivel de ruido del sensor F/T. La degradación del hardware es a menudo gradual y solo se detecta mediante monitoreo sistemático.
• Informe de sesión agregado: Total de episodios recogidos, tasa de éxito, puntaje medio de calidad, distribución de niveles de calidad de red, ID del operador y horas trabajadas.

La plataforma de datos de RCSV genera estos informes automáticamente para cada sesión de recogida y los pone a disposición a través de la interfaz de gestión de conjuntos de datos.

Display predictivo: Reducción de la latencia percibida

Las técnicas de visualización predictiva hacen que un estado futuro predecible del robot se base en los comandos del operador, superpuestos en el feed de cámara retrasado. Esto reduce la latencia percibida por el horizonte de predicción (generalmente 50-150 ms), haciendo que la teleoperación se sienta más receptiva incluso cuando la latencia de la red real es alta.

El predictor efectivo más simple es un modelo avanzado cinemático: dada la velocidad conjunta ordenada actual, predecir dónde estará el robot en 100 ms en el futuro y hacer una superposición fantasma de la posición del efecto final previsto en el feed de vídeo. Este enfoque no requiere ningún modelo aprendido, solo la cinemática del robot hacia adelante (disponible desde el URDF) y la suposición de que se lograrán velocidades ordenadas. Para el [OpenArm 1]T18), esta suposición se mantiene dentro de 3 mm de error de posición para predicciones hasta 150 ms adelante a velocidades típicas de teleoperación.

Los predictores más avanzados utilizan un modelo de dinámica aprendida para predecir la evolución completa de la escena visual, pero estos agregan latencia de cálculo que compensa parcialmente el beneficio perceptivo. La superposición cinemática de fantasma es la opción pragmática para la recopilación de datos de producción: es rápida (computación < 1 ms), confiable y proporciona al operador la información crítica (posición del factor final previsto) necesaria para planificar su siguiente movimiento.

Requisitos de conexión

• Fibra simétrica (hogar o oficina): RTT típicamente <30ms doméstico, <80ms intercontinental. Más fiable para sesiones de teleoperación sostenidas. Recomendado como mínimo para operadores que realizan sesiones de más de 4 horas.
• ** 5G mmWave:** 1020ms RTT, ancho de banda de 100Mbps +. Excelente cuando está disponible. La cobertura se limita aún a áreas urbanas densas; no es confiable para las configuraciones de operadores móviles.
• ** 4G LTE:** 3080ms RTT típicamente, variable. Viable para tareas de media precisión. Jitter es el problema principal Implementar el amortiguador de jitter adaptativo en el lado de recepción del comando de control.
• Starlink: 25-60ms RTT, 50-200 Mbps descarga. RTT varía con la posición del satélite y experimenta picos periódicos de latencia (200-500ms) durante la entrega del satélite (cada 15-30 minutos). Viable para tareas L1/L2 con amortiguación de jitter, pero no se recomienda para tareas de precisión. RCSV ha probado Starlink para recoger datos remotos de sitios rurales y lo ha encontrado aceptable para tareas simples de pick-place con amortiguadores de jitter configurados adecuadamente.
• ** WiFi doméstico (compartido):** variable de 20 100 ms, con posibles picos de 200 500 ms durante el tráfico doméstico.

El RCSV plataforma de teleópticos mide la RTT al inicio de la sesión, envía automáticamente a los operadores a las colas de tareas apropiadas y utiliza WebRTC VP8 con código de hardware para todas las transmisiones de vídeo.

Solución de emergencia y seguridad en red

La teleoperación remota presenta un desafío de seguridad único: el operador está físicamente separado del robot y no puede presionar un botón físico de parada electrónica.

• Montaje de la frecuencia cardíaca. El cliente operador envía una señal de la frecuencia cardíaca a 10 Hz. Si el controlador robot no recibe un latido cardíaco durante 500 ms (5 latidos perdidos), activa una rampa automática de velocidad a cero por encima de 200 ms, seguida del compromiso de frenos articulares. Esto garantiza que el robot se detenga de forma segura incluso si la conexión a la red cae por completo.
• ** E-stop de doble vía.** Implemente un botón de parada electrónica de software en la interfaz de usuario del operador que envía un comando de parada a través del WebRTC DataChannel primario y una conexión WebSocket redundante. El controlador robot activa la parada de emergencia si cualquiera de los caminos entrega el comando. Este enfoque de doble vía sobrevive a fallas de un solo canal.
• Monitor de seguridad local. Un proceso separado en el controlador del robot monitoriza las velocidades conjuntas, las fuerzas y los límites del espacio de trabajo independientemente de la conexión de red. Si el robot se acerca a un límite del espacio de trabajo (definido por un volumen de seguridad configurable) o supera los umbrales de fuerza, el monitor local activa una parada electrónica independientemente de los comandos del operador. Esto proporciona defensa contra las fallas de la red y comandos maliciosos o errados del operador.
• Cheque de seguridad de inicio de sesión. Antes de habilitar el control de teleoperación, compruebe: las cámaras están en streaming, los codificadores conjuntos están informando, el circuito de parada electrónica es sensible (título y prueba de liberación) y el espacio de trabajo está limpio (no hay obstrucciones detectadas por las cámaras de seguridad). Esta lista de verificación se ejecuta automáticamente al inicio de la sesión y bloquea la teleoperación hasta que se pasen todas las verificaciones.

Estas medidas de seguridad añaden 2-5 ms de latencia (control del latido cardíaco, control de límites) pero no son negociables para la teleoperación de producción.

Infraestructura de telecomunicaciones remotas

La plataforma de RCSV maneja la pila de redes, la compensación de latencia y el enrutamiento del operador para la recopilación remota de datos.

[Ver la plataforma]