Redes para Robôs: Wi-Fi, Cabos, 5G e Porque a Latência Conta

Um humanoide é um nó móvel numa rede quase de certeza concebida para portáteis parados. Esse desajuste está na origem de cerca de 95% dos tickets do género "hoje o robô está estranho" que alguma vez irá abrir. Os controladores dos motores estão bem. O Jetson está bem. O modelo no servidor de IA Kentino está bem. O Wi-Fi é que não está bem.

Este artigo trata da segunda metade do cenário de duas caixas descrito em I01 — em concreto, da ligação no meio. O robô que comprou vale apenas tanto quanto a rede onde o coloca, e essa rede provavelmente precisa de ser reconstruída antes de merecer a palavra "bem".

Público-alvo: integradores, responsáveis de laboratório e equipas de TI a quem foi comunicado que um humanoide chega no próximo mês e que ainda não interiorizaram que o Wi-Fi empresarial existente vai envergonhar toda a gente.

Porque é que as redes para robôs são um problema à parte

A maioria do Wi-Fi empresarial está dimensionada para padrões de tráfego à escala humana: descargas em rajada, chamadas de vídeo ocasionais, longos períodos inativos. Um humanoide não faz nada disso. Gera um fluxo duplex contínuo de mensagens de controlo de baixo débito, rajadas intermitentes de dados de imagem para o servidor de inferência e um fio constante de telemetria. O fluxo de controlo é pequeno (kilobytes por segundo), mas patologicamente sensível ao jitter. As rajadas de imagem são pesadas (dezenas a centenas de megabytes por segundo em bruto) e exigem um caminho largo. A telemetria é tolerante e aborrece toda a gente.

O que torna o problema único:

• O nó move-se. O robô atravessa a fronteira de célula entre pontos de acesso e o evento de roaming faz perder pacotes durante 50–500 ms, consoante a configuração da rede. O utilizador de um portátil não repara. O controlador de equilíbrio de um robô pode reparar.
• O ambiente de RF é hostil. Um laboratório de 30 m² com dois engenheiros, três portáteis, uma máquina de café com Wi-Fi e um micro-ondas é um ambiente de RF perfeitamente normal que vai arrasar por completo uma ligação de robô a 5 GHz. O sombreamento provocado pelo próprio corpo do robô bloqueia o sinal em direções imprevisíveis à medida que este roda.
• A interferência entre vários robôs acumula-se. Dois G1 na mesma sala e no mesmo canal não cooperam com elegância. Três já são um problema. Uma frota de oito exige planeamento a sério.
• Os protocolos acima do rádio também são frágeis. A configuração DDS predefinida do ROS 2 depende de multicast IP para a descoberta. O Wi-Fi lida mal com multicast. A combinação gera tickets do tipo "os nós não se veem uns aos outros" que parecem bugs do robô.

Isto tem solução. Nada disto está resolvido por omissão.

Wi-Fi 6E: o patamar mínimo atual

O ponto de partida honesto em 2026 para uma implementação de Wi-Fi em robótica é Wi-Fi 6E com um SSID dedicado a 6 GHz exclusivo para os robôs. Não Wi-Fi 6. Não 5 GHz com "depois resolvemos". 6E, 6 GHz, SSID separado, VLAN isolada.

A razão é a limpeza do espetro de RF, não o débito de catálogo. A banda dos 6 GHz é suficientemente recente para ainda não ter sido invadida por tralha de consumo. Não há Bluetooth nos 6 GHz, nem harmónicas de micro-ondas, nem impressoras com 15 anos a emitir beacons. O rádio do seu robô fica com um canal limpo. Esse canal limpo vale mais do que qualquer melhoria de folha de especificações.

É este o aspeto do RTT real de um robô em Wi-Fi 6E, medido do CPU do robô até ao servidor de inferência do lado cablado do ponto de acesso:

Uma ligação limpa a 6 GHz entrega RTT de um único dígito de milissegundos com consistência suficiente para que os nós ROS 2, os clientes gRPC para o vLLM e o teleop pareçam responsivos. O mesmo robô ligado a um SSID partilhado de 5 GHz vai parecer "lento" de uma forma que ninguém consegue quantificar até medir.

Wi-Fi 7 em 2026: suporte limitado, promessa real

A funcionalidade de destaque do Wi-Fi 7 é a Multi-Link Operation (MLO) — o rádio agrega duas ou três bandas (2.4/5/6 GHz) em simultâneo e ou soma débito ou replica pacotes pelas ligações para ganhar fiabilidade. A redução de latência do Wi-Fi 7 face ao 6E é real onde a MLO está ativa: os fabricantes anunciam quedas de latência de 50–75% e as medições de bancada em condições controladas apontam para RTT de Wi-Fi 7 com MLO na ordem dos 1.5–4 ms, contra 3–6 ms em Wi-Fi 6E. O valor abaixo do milissegundo surge ocasionalmente no marketing, mas não foi reproduzido em hardware de robótica.

O senão é o rádio do robô. Em meados de 2026, as plataformas humanoides correntes (Unitree G1/H1, Booster T1, EngineAI PM01/SE01) saem com Wi-Fi 6 ou 6E. Nenhuma anuncia Wi-Fi 7 na SKU base. Colocar um ponto de acesso Wi-Fi 7 à frente de um robô Wi-Fi 6E dá-lhe um backhaul Wi-Fi 7 e uma ligação de robô 6E — não há mal nisso, mas está a pagar por capacidade que ainda não pode usar.

Quando o Wi-Fi 7 começa a interessar para robôs:

• Quando o robô sair de fábrica com um módulo Wi-Fi 7 por omissão (previsto para as plataformas de 2027).
• Quando a MLO conseguir replicar o fluxo de pacotes do plano de controlo em 5 GHz e 6 GHz em simultâneo, eliminando os desvanecimentos de banda única.
• Quando estiver a implementar uma frota suficientemente grande para que o congestionamento de uma única banda seja o estrangulamento, independentemente da latência.

Para um laboratório com um só robô em 2026: 6E chega. Para uma frota planeada de 2027 em diante: especifique já os pontos de acesso como Wi-Fi 7, para não ter de voltar a comprar a rede daqui a dezoito meses.

Colocação e densidade dos pontos de acesso

O instinto é montar um ponto de acesso no teto, ao canto da sala. O resultado é uma zona morta de meio metro atrás da bancada do laboratório, onde o robô perde sinal exatamente durante a demonstração que agendou.

Regras práticas que funcionam:

A linha de vista vale mais do que a potência. Um ponto de acesso de 30 dBm atrás de um rack de aço entrega pior sinal do que um de 20 dBm montado no teto, ao centro da sala. Os robôs são baixos — uma antena ao nível do peito, a 1.2 m, vê um ambiente de RF diferente do de um portátil numa secretária a 0.7 m, e pior do que o de um telemóvel a 1.5 m. Pontos de acesso acima de 2.5 m, robôs abaixo de 1.5 m, sem obstáculos do tamanho de pessoas no percurso dominante.

SSID dedicado à robótica. Não é negociável. O SSID dos robôs tem a sua própria VLAN, o seu perfil de QoS, o seu âmbito de DHCP e nenhum tráfego de consumo. Juntar o robô ao Wi-Fi do pessoal funciona em desenvolvimento durante uma semana, até que um estagiário do marketing entre numa videochamada e o robô caia.

Sombreamento pelo corpo — o problema da antena

O tronco de um humanoide é uma caixa de aço e plástico com cerca de 30 cm de largura. A antena de rádio costuma ficar algures dentro da placa peitoral, muitas vezes nas costas ou de um dos lados. Quando o robô se vira de costas para o ponto de acesso, o corpo passa a funcionar como uma gaiola de Faraday parcial.

A perda de intensidade de sinal ronda normalmente os 6–15 dB, consoante a colocação da antena e a quantidade de metal no peito. É quanto basta para passar uma ligação marginal de "funciona bem" a "cai de poucos em poucos segundos" apenas por rotação. Os quadrúpedes sofrem menos porque são mais baixos e mais planos e a antena fica normalmente num bordo do chassis, com vista mais limpa para cima.

O que ajuda:

• Antena na cabeça ou nos ombros, não no peito. Alguns humanoides de gama de investigação permitem mudar a antena de sítio ou acrescentar uma externa. A maioria das unidades de gama de consumo não permite. Pergunte antes de comprar se a fiabilidade de RF for um requisito da implementação.
• Dois pontos de acesso com diversidade. Com pontos de acesso em paredes opostas, o robô está "de frente" para um deles seja qual for a sua orientação. O roaming do ponto de acesso trata da mudança — mal, mas melhor do que ficar sem sinal.
• Antenas mais baixas do lado do ponto de acesso. Se os seus pontos de acesso estão montados no teto a 3 m e a antena do robô está a 1.0 m, o ângulo de elevação é suficientemente acentuado para que o peito bloqueie boa parte do percurso. Pontos de acesso montados na parede a 2 m ficam com um percurso mais plano e mais fácil.

O cabo umbilical: como trabalham as equipas sérias

Todas as equipas sérias de robótica têm um cabo umbilical. A maioria nunca fala nisso porque estraga a estética da demonstração "olha, sem fios". Quem faz trabalho de integração a sério liga o robô à ficha.

O umbilical é um cabo USB-C, um cabo Ethernet M12 X-code ou, nas unidades de gama de investigação, um cabo espiralado que transporta energia e dados em conjunto. A largura de banda é de 1 Gbps ou superior; a latência é de ida e volta abaixo do milissegundo, muitas vezes abaixo de 200 µs. Isto é duas ordens de grandeza melhor do que a melhor ligação Wi-Fi.

A razão para usar o umbilical durante o desenvolvimento não é a largura de banda; é a eliminação da variável. Quando o Wi-Fi está instável, não se consegue perceber se o nó ROS 2 é lento, se o modelo é lento ou se o ar está mau. Ligue o cabo e deixa de haver ar. Tudo o resto fica mais fácil de depurar.

O Unitree G1 EDU e o Booster T1 têm ambos soluções credíveis de umbilical. O H1 é incómodo de ligar por cabo. O PM01 e o SE01 suportam umbilical de desenvolvimento por USB-C ou Ethernet padrão. Os quadrúpedes (Go2) raramente levam cabo, porque o caso de uso é no exterior; se estiver a fazer trabalho sério de RL em interior com um deles, talvez queira ligá-lo na mesma.

Redes 5G privadas: quando compensam

O 5G privado — a sua própria rede móvel no local, com espetro licenciado ou partilhado — entrou no território de "produto a sério" em 2025 e é fornecido em escala em 2026. A tecnologia funciona.

Quando o 5G privado faz sentido:

• Grandes locais ao ar livre. Instalações de vários hectares, mineração, grande agricultura, portos. As células Wi-Fi não escalam aqui; o número de pontos de acesso e o esforço de levantamento ultrapassam o custo de uma única rede 5G de pequenas células.
• Campus com vários edifícios. Quando o robô tem de passar do interior para o exterior e voltar, ou circular entre edifícios, o roaming Wi-Fi torna-se feio. O 5G trata da mobilidade de forma nativa.
• Implementações centradas na mobilidade. Robôs de inspeção que percorrem quilómetros, robôs móveis autónomos em grandes armazéns, qualquer cenário em que a ligação de rádio tenha de acompanhar a unidade pelo território.
• Frotas mistas com outros ativos 5G. Se o local já tem 5G privado para empilhadores, AGV ou redes de sensores, acrescentar robôs é um custo incremental e não um projeto novo.

Quando é exagero:

• Um laboratório, um edifício, um a quatro robôs. O Wi-Fi 6E faz este trabalho por €3–8k de pontos de acesso. O 5G privado fá-lo por €60–200k de pequenas células, EPC/5GC, licenciamento de espetro e uma relação com fornecedor. A proporção não compensa.
• Ambientes puramente de desenvolvimento. O umbilical mais o Wi-Fi dão-lhe tudo o que o 5G daria e nada de extra para gerir.
• Não tem uma equipa de redes. O 5G privado não é "configurar e esquecer". É mais um sistema de produção para operar, monitorizar e atualizar.

O orçamento de latência: que cargas de trabalho sobrevivem a quê

O padrão é claro: o trabalho em malha fechada fica local ou por cabo, a perceção com raciocínio aguenta Wi-Fi, a conversação aguenta WAN. O erro arquitetural é pôr código próximo do ciclo dos motores num caminho que pode apanhar jitter de rede. O outro erro é pagar por um transporte de 5 ms quando a latência do modelo é de 400 ms — poupou 30 ms num total de 430 ms. Otimize o termo dominante.

O padrão "sempre com um pé na cloud"

Mesmo numa implementação rigorosamente on-premise, o robô raramente está totalmente isolado da rede. Coisas que legitimamente precisam de WAN:

• Telemetria para a sua própria stack de monitorização (Prometheus / Grafana / Datadog). Útil, de baixa largura de banda, sobrevive a qualquer RTT.
• Atualizações de modelos e de firmware. Descarregar novos pesos de VLM, imagens de contentor, patches do sistema operativo. Em rajada, pode ser feito de noite.
• Dados de mapas e do ambiente. Planta do espaço, sincronização de nuvens de pontos, cópia de segurança da memória de cena.
• Recurso a teleop remoto. Por vezes; sujeito a revisão de segurança.

O padrão é on-premise primeiro para o caminho crítico, saída WAN com firewall para o caminho frio. O robô nunca precisa de um endereço WAN de entrada. O servidor também não precisa de um endereço WAN de entrada. Apenas saída, destinos em lista branca, TLS, sem exceções.

Multicast, mDNS, DDS — e porque é que o Wi-Fi os faz doer

O ROS 2 vem com DDS como middleware predefinido. O DDS usa multicast IP para a descoberta de participantes. O Wi-Fi trata o multicast transmitindo ao débito mínimo comum a todos os clientes do BSSID, o que:

1. Desperdiça tempo de antena.
2. Parece uma inundação ao firmware do ponto de acesso.
3. Muitas vezes é descartado por pontos de acesso empresariais com supressão de multicast ativada.

O resultado é "os meus nós ROS 2 veem-se por Ethernet mas não por Wi-Fi" — uma falha bem documentada e perfeitamente evitável. A perda de pacotes medida em Wi-Fi para tráfego ROS 2 multicast ronda 1–3% mesmo em ligações saudáveis; em Ethernet é zero. Dois robôs ROS 2 no mesmo Wi-Fi podem gerar tempestades de descoberta que desestabilizam o ponto de acesso.

As correções, por ordem de preferência:

1. Use o Fast-DDS Discovery Server. Coloque um servidor de descoberta a correr (normalmente no servidor de inferência ou numa VM dedicada), aponte todos os nós ROS 2 para ele por unicast e a descoberta passa a ser um fluxo cliente-servidor normal, que o Wi-Fi trata bem.
2. Configuração estática de pares por perfil XML. Fixe no código o IP do outro lado. É frágil, mas funciona para um par fixo.
3. Ative o IGMP snooping e a conversão de multicast em unicast no ponto de acesso. A Aruba, a Ruckus, a Cisco Meraki e o firmware recente da UniFi suportam isto. Diga-o ao engenheiro de redes; são duas caixas para marcar.
4. Mude de implementação RMW. Alguns utilizadores passam do Cyclone DDS para o Fast-DDS ou para o Zenoh-bridge justamente para escapar à semântica de descoberta por multicast. Último recurso; tem um custo de integração.

QoS, DSCP e conseguir prioridade

O SSID do robô tem a sua própria VLAN; a VLAN tem o seu próprio perfil de QoS. A camada seguinte é garantir que a rede concorda que o tráfego do robô é mais importante do que a sincronização do Dropbox da equipa de marketing.

Padrão habitual:

• Marque o tráfego de controlo do robô com DSCP EF (Expedited Forwarding, DSCP 46). O fluxo do plano de controlo é pequeno e crítico em latência; EF é a classe de manual para este caso.
• Fluxos de imagem marcados como AF41 (DSCP 34). Vídeo em tempo real, débito elevado, prioridade mais baixa do que o controlo.
• Telemetria e descarga de modelos marcadas como predefinição (DSCP 0). Sem tratamento especial.
• O mapeamento WMM do ponto de acesso tem de respeitar as marcações. A maioria dos pontos de acesso empresariais (Aruba, Cisco Meraki, Ruckus) faz isto automaticamente quando a confiança em DSCP está ativa. A UniFi exige configuração explícita no firmware recente.

Arquitetura de rede concreta para um laboratório de robótica

Uma configuração que funciona para um laboratório de 1–4 robôs, calibrada pela realidade de hardware de I01:

Rede de laboratório de referência: robôs → pontos de acesso dedicados de 6 GHz → switch de 10 GbE → servidor de IA Kentino. Saída com firewall, apenas de saída.

Para 1–4 robôs numa única sala, esta configuração fica em €4–12k de equipamento de rede, consoante a gama do fabricante. A Ruckus e a Aruba são as melhores em RF em ambientes densos ou hostis. A Cisco Meraki ganha na simplicidade, com a penalização de um custo recorrente. A UniFi ganha no preço e serve perfeitamente para trabalho num único laboratório.

Modos de falha, mais ou menos pela ordem em que o vão morder

• O roaming entre pontos de acesso mata um fluxo. O robô atravessa a fronteira de célula, a associação cai durante 100–400 ms, o socket ROS 2 recupera, mas fica uma lacuna no fluxo de controlo registada nos logs. Mitigue com células sobrepostas, roaming rápido 802.11k/v/r e, acima de tudo, não dependendo da rede para controlo em malha fechada.
• Interferência entre vários robôs em canais partilhados. Três G1 no mesmo canal de 6 GHz pisam o tempo de antena uns dos outros. Planeie canais de 80 MHz não sobrepostos nos 6 GHz (há sete na UE, mais nos EUA).
• Estrutura do edifício. Paredes de betão armado tiram 20–30 dB. Portas de aço de sala de servidores tiram 40 dB. Levantamento de RF do local antes de montar os pontos de acesso, sempre.
• Expiração do aluguer DHCP a meio de uma tarefa. Sessão longa do robô, a renovação de DHCP falha, o IP muda, os sockets quebram. Reservas DHCP estáticas para o robô. Sempre.
• Modos de poupança de energia. A poupança de energia do Wi-Fi no rádio do robô acrescenta latência em nome da autonomia da bateria. Desative-a explicitamente. A autonomia da bateria é um problema de bateria; não o pague em jitter.
• Incompatibilidade de MTU. O SDK do fabricante do robô usa 1500, a sua infraestrutura usa 9000, há fragmentação e o desempenho colapsa em silêncio. Faça corresponder o MTU de ponta a ponta.

A opinião honesta

A frase mais útil deste artigo: 95% dos "problemas do robô" reportados no primeiro mês de implementação são problemas de configuração de Wi-Fi. O robô está bem. O modelo está bem. O Wi-Fi é que não está bem, o SSID é partilhado com o escritório, não há VLAN dedicada, o multicast corre solto, os pontos de acesso estão no sítio errado e o integrador passa três semanas a depurar a camada errada.

Contrate cedo a pessoa de redes. Pague-lhe mais do que pensa. O engenheiro de redes sénior que sabe desenhar um plano de Wi-Fi 6E, configurar QoS de ponta a ponta e afinar a descoberta DDS vale o mesmo que um roboticista sénior neste projeto e é bastante mais difícil de encontrar.

---

Isto faz parte da Kentino Wiki, uma série de referência sobre computação de IA, robótica e os sistemas que os ligam. Comentários e correções são bem-vindos em info@kentino.com.