Redes de robots: Wi-Fi, cable, 5G y la latencia

Un humanoide es un nodo móvil en una red que casi con toda seguridad se diseñó para portátiles que no se mueven. Ese desajuste es el origen de aproximadamente el 95% de los tickets de «hoy el robot está raro» que llegará a abrir. Los controladores de los motores están bien. La Jetson está bien. El modelo en el servidor de IA de Kentino está bien. El Wi-Fi no está bien.

Este artículo trata de la segunda mitad del esquema de dos cajas de I01, y en concreto del enlace que hay en medio. El robot que ha comprado solo es tan bueno como la red en la que lo ponga, y esa red probablemente haya que rehacerla antes de que merezca la palabra «bien».

Público: integradores, responsables de laboratorio y equipos de TI a los que les han dicho que el mes que viene llega un humanoide y que todavía no han asimilado que el Wi-Fi corporativo existente va a dejar a todo el mundo en evidencia.

Por qué la red de los robots es un problema aparte

La mayoría del Wi-Fi empresarial está dimensionado para patrones de tráfico a escala humana: descargas a ráfagas, alguna videollamada ocasional, largos periodos de inactividad. Un humanoide no hace nada de eso. Genera un flujo dúplex continuo de mensajes de control de baja tasa, ráfagas intermitentes de datos de imagen hacia el servidor de inferencia y un goteo constante de telemetría. El flujo de control es pequeño (kilobytes por segundo) pero patológicamente sensible al jitter. Las ráfagas de imagen son gruesas (de decenas a cientos de megabytes por segundo en bruto) y necesitan un camino ancho. La telemetría es indulgente y no le interesa a nadie.

Lo que hace único al problema:

• El nodo se mueve. El robot cruza la frontera de celda entre puntos de acceso y el evento de roaming descarta paquetes durante 50–500 ms según cómo esté configurada la red. El usuario de un portátil no lo nota. El controlador de equilibrio de un robot quizá sí.
• El entorno de RF es hostil. Un laboratorio de 30 m² con dos ingenieros, tres portátiles, una cafetera con Wi-Fi y un microondas es un entorno de RF perfectamente normal que destrozará sin piedad un enlace de robot en 5 GHz. El apantallamiento del propio cuerpo del robot bloquea la señal en direcciones impredecibles a medida que gira.
• Las interferencias entre varios robots se acumulan. Dos G1 en la misma sala y en el mismo canal no van a cooperar con elegancia. Tres ya son un problema. Una flota de ocho exige planificación de verdad.
• Los protocolos por encima de la radio también son frágiles. La configuración DDS por defecto de ROS 2 depende de multicast IP para el descubrimiento. El Wi-Fi gestiona mal el multicast. La combinación produce tickets de «los nodos no se ven entre sí» que parecen fallos del robot.

Esto tiene solución. Nada de ello está resuelto por defecto.

Wi-Fi 6E: el suelo actual

El punto de partida honesto en 2026 para un despliegue de Wi-Fi en robótica es Wi-Fi 6E con un SSID de 6 GHz dedicado exclusivamente a los robots. Ni Wi-Fi 6. Ni 5 GHz con un «ya lo arreglaremos». 6E, 6 GHz, SSID aparte, VLAN aislada.

La razón es la limpieza del espectro, no el caudal de catálogo. La banda de 6 GHz es lo bastante nueva como para que la morralla doméstica no la haya inundado todavía. No hay Bluetooth en 6 GHz, ni armónicos de microondas, ni impresoras de quince años emitiendo balizas. La radio de su robot dispone de un canal limpio. Ese canal limpio vale más que cualquier mejora sobre el papel.

Así es el RTT real de un robot con Wi-Fi 6E, medido desde la CPU del robot hasta el servidor de inferencia en el lado cableado del punto de acceso:

Un enlace limpio de 6 GHz ofrece un RTT de un solo dígito de milisegundos con la constancia suficiente para que los nodos ROS 2, los clientes gRPC contra vLLM y el teleoperado respondan bien. Ese mismo robot pasado a un SSID de 5 GHz compartido se notará «lento» de una forma que nadie sabrá cuantificar hasta que lo mida.

Wi-Fi 7 en 2026: soporte limitado, promesa real

La función estrella de Wi-Fi 7 es la operación multienlace (MLO): la radio agrupa dos o tres bandas (2.4/5/6 GHz) de forma simultánea y agrega caudal o replica los paquetes entre enlaces para ganar fiabilidad. La reducción de latencia de Wi-Fi 7 frente a 6E es real donde MLO está activado: los fabricantes hablan de caídas de latencia del 50–75%, y las mediciones de banco en condiciones controladas sitúan el RTT de Wi-Fi 7 con MLO en el rango de 1.5–4 ms frente a 3–6 ms en Wi-Fi 6E. En marketing se afirma a veces que baja del milisegundo, algo que no se ha reproducido en hardware robótico.

El inconveniente es la radio del robot. A mediados de 2026, las plataformas humanoides principales (Unitree G1/H1, Booster T1, EngineAI PM01/SE01) se entregan con Wi-Fi 6 o 6E. Ninguna anuncia Wi-Fi 7 en la SKU base. Poner un punto de acceso Wi-Fi 7 delante de un robot Wi-Fi 6E le da un backhaul Wi-Fi 7 y un enlace de robot 6E: correcto, pero está pagando por una capacidad que todavía no puede usar.

Cuándo empieza a importar Wi-Fi 7 para los robots:

• Cuando el robot incorpore de serie un módulo Wi-Fi 7 (previsto en las plataformas de 2027).
• Cuando MLO pueda replicar el flujo de paquetes del plano de control por 5 GHz y 6 GHz a la vez, eliminando los desvanecimientos de una sola banda.
• Cuando despliegue una flota lo bastante grande como para que la congestión de una única banda sea el cuello de botella, al margen de la latencia.

Para un laboratorio con un solo robot en 2026: 6E es suficiente. Para una flota prevista a partir de 2027: especifique ya los puntos de acceso como Wi-Fi 7 para no tener que volver a comprar la red en dieciocho meses.

Colocación y densidad de puntos de acceso

El instinto lleva a montar un punto de acceso en el techo, en la esquina de la sala. El resultado es una zona muerta de medio metro detrás del banco del laboratorio donde el robot pierde la señal justo durante la demostración que tenía programada.

Reglas prácticas que funcionan:

La visión directa gana a la potencia. Un punto de acceso de 30 dBm detrás de un rack de acero ofrece peor señal que uno de 20 dBm montado en el techo en el centro de la sala. Los robots son bajos: una antena en el pecho a 1.2 m ve un entorno de RF distinto del de un portátil sobre una mesa a 0.7 m, y peor que el de un teléfono a 1.5 m. Puntos de acceso por encima de 2.5 m, robots por debajo de 1.5 m y ningún obstáculo del tamaño de una persona en el camino dominante.

SSID dedicado a robótica. No es negociable. El SSID de los robots tiene su propia VLAN, su propio perfil de QoS, su propio ámbito DHCP y nada de tráfico de consumo. Mezclar el robot con el Wi-Fi del personal funciona en desarrollo durante una semana, hasta que un becario de marketing se mete en una videollamada y el robot se cae.

Apantallamiento del cuerpo: el problema de la antena

El torso de un humanoide es una caja de acero y plástico de unos 30 cm de ancho. La antena de radio suele vivir en algún punto dentro del peto, a menudo en la espalda o en un lateral. Cuando el robot se gira de espaldas al punto de acceso, el cuerpo se convierte en una jaula de Faraday parcial.

La pérdida de intensidad de señal suele ser de 6–15 dB según la colocación de la antena y la cantidad de metal del pecho. Basta para que un enlace al límite pase de «funciona bien» a «se cae cada pocos segundos» solo con girar. Los cuadrúpedos lo sufren menos porque son más bajos y planos y la antena suele ir en un borde del chasis con mejor visión del cielo.

Lo que ayuda:

• Antena en la cabeza o los hombros, no en el pecho. Algunos humanoides de gama investigación permiten reubicar la antena o añadir una externa. La mayoría de las unidades de gama de consumo, no. Pregunte antes de comprar si la fiabilidad de RF es un requisito del despliegue.
• Dos puntos de acceso con diversidad. Con puntos de acceso en paredes opuestas, el robot queda «de cara» a uno de ellos sea cual sea su orientación. El roaming gestiona el cambio: mal, pero mejor que quedarse sin señal.
• Antenas más bajas en el lado del punto de acceso. Si sus puntos de acceso están en el techo a 3 m y la antena del robot está a 1.0 m, el ángulo de elevación es lo bastante pronunciado como para que el pecho bloquee buena parte del camino. Puntos de acceso montados en pared a 2 m consiguen un trayecto más plano y fácil.

El cable: así trabajan los equipos serios

Todo equipo de robótica serio tiene un cable de conexión. Casi nadie lo cuenta porque estropea la estética de «mira, sin cables» de la demostración. Cualquiera que haga trabajo de integración de verdad enchufa el robot.

El cable es un USB-C, un Ethernet M12 con codificación X o, en unidades de gama investigación, un umbilical en espiral que lleva juntas alimentación y datos. El ancho de banda es de 1 Gbps o más; la latencia es de menos de un milisegundo de ida y vuelta, a menudo por debajo de 200 µs. Eso es dos órdenes de magnitud mejor que el mejor enlace Wi-Fi.

La razón para usar cable durante el desarrollo no es el ancho de banda: es eliminar la variable. Cuando el Wi-Fi va irregular, no puede saber si lo lento es su nodo ROS 2, el modelo o el aire. Enchufe y ya no hay aire. Todo lo demás resulta más fácil de depurar.

El Unitree G1 EDU y el Booster T1 ofrecen ambos opciones de cable solventes. El H1 es incómodo de cablear. El PM01 y el SE01 admiten cable de desarrollo mediante USB-C o Ethernet estándar. Los cuadrúpedos (Go2) rara vez se cablean porque su caso de uso es exterior; si va a hacer trabajo serio de aprendizaje por refuerzo en interiores con uno, quizá le convenga hacerlo igualmente.

Redes 5G privadas: cuándo merecen la pena

El 5G privado —su propia red celular con licencia o espectro compartido en sus instalaciones— entró en el terreno de «producto real» en 2025 y en 2026 ya se despliega a escala. La tecnología funciona.

Cuándo tiene sentido el 5G privado:

• Grandes emplazamientos al aire libre. Instalaciones de varias hectáreas, minería, agricultura extensiva, puertos. Las celdas Wi-Fi no escalan aquí; el número de puntos de acceso y el esfuerzo de estudio superan el coste de una pequeña red 5G de small cells.
• Campus de varios edificios. Cuando el robot tiene que pasar de interior a exterior y volver, o moverse entre edificios, el roaming Wi-Fi se vuelve feo. El 5G gestiona la movilidad de forma nativa.
• Despliegues centrados en la movilidad. Robots de inspección que recorren kilómetros, robots móviles autónomos en grandes almacenes, cualquier caso en que el enlace de radio deba seguir a la unidad por el territorio.
• Flotas mixtas con otros activos 5G. Si el emplazamiento ya tiene 5G privado para carretillas, AGV o redes de sensores, añadir robots es un coste incremental, no un proyecto nuevo.

Cuándo es excesivo:

• Un laboratorio, un edificio, de uno a cuatro robots. El Wi-Fi 6E hace este trabajo con 3–8 k€ de puntos de acceso. El 5G privado lo hace con 60–200 k€ de small cells, EPC/5GC, licencias de espectro y una relación con un proveedor. La proporción no cuadra.
• Entornos puramente de desarrollo. El cable más Wi-Fi le da todo lo que daría el 5G y nada más que gestionar.
• No tiene equipo de redes. El 5G privado no es «instalar y olvidarse». Es un sistema de producción adicional que hay que operar, monitorizar y actualizar.

El presupuesto de latencia: qué cargas sobreviven a qué

El patrón está claro: el trabajo en lazo cerrado va local o por cable, la percepción con razonamiento admite Wi-Fi y la conversación admite WAN. El error arquitectónico es poner código próximo al lazo de los motores en un camino que puede sufrir jitter de red. El otro error es pagar por un transporte de 5 ms cuando la latencia del modelo es de 400 ms: habrá ahorrado 30 ms sobre un total de 430 ms. Optimice el término dominante.

El patrón de «siempre con un pie en la nube»

Incluso en un despliegue estrictamente on-premise, el robot rara vez está aislado por completo. Cosas que legítimamente quieren WAN:

• Telemetría hacia su propio stack de monitorización (Prometheus / Grafana / Datadog). Útil, de poco ancho de banda, aguanta cualquier RTT.
• Actualizaciones de modelos y firmware. Descargar nuevos pesos de VLM, imágenes de contenedor, parches del sistema operativo. A ráfagas, se puede hacer de noche.
• Datos de mapas y de entorno. Planos de planta, sincronización de nubes de puntos, copia de seguridad de la memoria de escena.
• Respaldo de teleoperación remota. A veces; sujeto a revisión de seguridad.

El patrón es on-premise primero para la ruta caliente, salida WAN con cortafuegos para la ruta fría. El robot no necesita nunca una dirección WAN entrante. El servidor tampoco necesita una dirección WAN entrante. Solo salida, destinos en lista blanca, TLS, sin excepciones.

Multicast, mDNS, DDS: por qué el Wi-Fi los hace doler

ROS 2 viene con DDS como middleware por defecto. DDS usa multicast IP para el descubrimiento de participantes. El Wi-Fi gestiona el multicast transmitiendo a la tasa más baja común a todos los clientes del BSSID, lo que:

1. Desperdicia tiempo de aire.
2. Parece una inundación para el firmware del punto de acceso.
3. A menudo acaba descartado por los puntos de acceso empresariales con la supresión de multicast activada.

El resultado es «mis nodos ROS 2 se ven por Ethernet pero no por Wi-Fi», un fallo bien documentado y del todo evitable. La pérdida de paquetes medida en Wi-Fi para tráfico multicast de ROS 2 ronda el 1–3% incluso en enlaces sanos; en Ethernet es cero. Dos robots ROS 2 en el mismo Wi-Fi pueden desencadenar tormentas de descubrimiento que desestabilicen el punto de acceso.

Las soluciones, por orden de preferencia:

1. Use el Discovery Server de Fast-DDS. Ejecute un servidor de descubrimiento (normalmente en el servidor de inferencia o en una VM dedicada), apunte todos los nodos ROS 2 a él por unicast y el descubrimiento pasa a ser un flujo cliente-servidor normal que el Wi-Fi gestiona sin problemas.
2. Configuración estática de pares mediante perfil XML. Fije a mano la IP del otro extremo. Es frágil, pero funciona para una pareja fija.
3. Active el IGMP snooping y la conversión de multicast a unicast en el punto de acceso. Aruba, Ruckus, Cisco Meraki y el firmware reciente de UniFi lo admiten. Dígaselo al ingeniero de redes; son dos casillas.
4. Cambie de implementación RMW. Algunos usuarios pasan de Cyclone DDS a Fast-DDS o a un puente Zenoh precisamente para escapar de la semántica de descubrimiento por multicast. Último recurso; tiene un coste de integración.

QoS, DSCP y cómo conseguir prioridad

El SSID de los robots tiene su propia VLAN; la VLAN tiene su propio perfil de QoS. La siguiente capa consiste en asegurarse de que la red coincide en que el tráfico de los robots importa más que la sincronización de Dropbox del equipo de marketing.

Patrón estándar:

• Marque el tráfico de control del robot como EF (Expedited Forwarding, DSCP 46). El flujo del plano de control es pequeño y crítico en latencia; EF es la clase de manual para él.
• Flujos de imagen marcados como AF41 (DSCP 34). Vídeo en tiempo real, mucho caudal, menor prioridad que el control.
• Telemetría y descargas de modelos marcadas por defecto (DSCP 0). Sin trato especial.
• El mapeo WMM del punto de acceso debe respetar las marcas. La mayoría de puntos de acceso empresariales (Aruba, Cisco Meraki, Ruckus) lo hacen de forma automática cuando la confianza DSCP está activada. UniFi requiere configuración explícita en el firmware reciente.

Arquitectura de red concreta para un laboratorio de robótica

Un montaje que funciona para un laboratorio de 1–4 robots, calibrado según la realidad de hardware de I01:

Red de laboratorio de referencia: robots → puntos de acceso dedicados de 6 GHz → switch de 10 GbE → servidor de IA de Kentino. Salida con cortafuegos, solo saliente.

Para 1–4 robots en una sola sala, este montaje sale por 4–12 k€ de equipamiento de red según la gama del fabricante. Ruckus y Aruba son los mejores en RF en entornos densos u hostiles. Cisco Meraki gana en simplicidad, con una penalización de coste recurrente. UniFi gana en precio y basta para el trabajo de un único laboratorio.

Modos de fallo, más o menos en el orden en que le morderán

• El roaming entre puntos de acceso mata un flujo. El robot cruza la frontera de celda, la asociación se cae durante 100–400 ms, el socket de ROS 2 se recupera, pero en los registros aparece un hueco en el flujo de control. Mitíguelo con celdas solapadas, roaming rápido 802.11k/v/r y, sobre todo, no dependiendo de la red para el control en lazo cerrado.
• Interferencia entre varios robots en canales compartidos. Tres G1 en el mismo canal de 6 GHz se pisan el tiempo de aire. Planifique canales de 80 MHz que no se solapen en 6 GHz (hay siete en la UE, más en EE. UU.).
• La estructura del edificio. Los muros de hormigón armado restan 20–30 dB. Las puertas de acero de las salas de servidores, 40 dB. Haga un estudio de RF antes de montar los puntos de acceso, siempre.
• Caducidad de la concesión DHCP a mitad de tarea. Sesión larga del robot, la renovación DHCP falla, la IP cambia, los sockets se rompen. Reservas DHCP estáticas para el robot. Siempre.
• Modos de ahorro de energía. El ahorro de energía del Wi-Fi en la radio del robot añade latencia a cambio de autonomía. Desactívelo de forma explícita. La autonomía es un problema de batería; no lo pague en jitter.
• MTU desparejada. El SDK del fabricante del robot usa 1500, su red usa 9000, aparece fragmentación y el rendimiento se hunde en silencio. Haga coincidir la MTU de extremo a extremo.

La opinión honesta

La frase más útil de este artículo: el 95% de los «problemas del robot» que se notifican en el primer mes de despliegue son problemas de configuración del Wi-Fi. El robot está bien. El modelo está bien. El Wi-Fi no está bien, el SSID está compartido con la oficina, no hay VLAN dedicada, el multicast campa a sus anchas, los puntos de acceso están mal colocados y el integrador lleva tres semanas depurando la capa equivocada.

Contrate pronto a la persona de redes. Páguele más de lo que cree. El ingeniero de redes sénior capaz de trazar un plan de Wi-Fi 6E, configurar la QoS de extremo a extremo y afinar el descubrimiento de DDS vale lo mismo que un roboticista sénior en este proyecto y es mucho más difícil de encontrar.

---

Esto forma parte de la Kentino Wiki, una serie de referencia sobre computación de IA, robótica y los sistemas que las conectan. Comentarios y correcciones son bienvenidos en info@kentino.com.