Veredito primeiro: quando os AMRs começam a se comportar como assombrados, o WiFi é culpado até prova em contrário. Tarefas perdidas, paradas de emergência repentinas, uma frota que desacelera sem motivo: antes de ligar para o fornecedor de AMR para reclamar, pegue um laptop e faça um ping no corredor onde aconteceu.
Vi essa armadilha exata três vezes. Todas as vezes, o site culpou o algoritmo de despacho, depois o LiDAR, depois o firmware. Duas semanas de acusações cruzadas depois, alguém finalmente verificou a rede: uma zona morta de cobertura entre duas fileiras de racks, ou handoffs de roaming tão lentos que os robôs continuavam estourando o tempo limite. Conserte a rede e a 'doença' dos robôs desaparece da noite para o dia.
Duas histórias de guerra
Março de 2024, um armazém 3PL no leste da China, pouco mais de 20,000 metros quadrados, seis AMRs com duas semanas de go-live. 'Tarefas perdidas' mais de vinte vezes por dia. O engenheiro do fornecedor acampou no local por dois dias, vasculhando logs de despacho, e concluiu que era 'provavelmente um problema intermitente de lógica de atribuição de tarefas'. Caminhei pelo corredor problemático com um laptop e fiz um ping: duas fileiras de racks estavam numa zona morta de cobertura de AP com perda de pacotes acima de 40 por cento. O AMR entrava, seus pacotes de heartbeat nunca saíam, e o despachador assumia que ele havia apagado e puxava a tarefa de volta para reatribuição. Essa era a chamada 'tarefa perdida'.
A correção foi quase embaraçosa: reposicionar três APs, subir um nível a agressividade do roaming nas placas WiFi dos AMRs. As reclamações caíram a zero em uma semana. Ainda me lembro da cara do engenheiro do fornecedor quando ele foi embora.
Junho de 2025, um grande centro de fulfillment de e-commerce, AMRs adicionados logo após o festival de compras 618. Antes do festival haviam elevado os racks dois níveis. As prateleiras metálicas sólidas bloqueavam completamente o sinal de 5 GHz, e os APs ainda estavam montados na altura antiga. Resultado: todo AMR que entrava na zona de racks altos começava a 'fazer papel de bobo': desacelerava, pausava, uma parada de emergência ocasional, e depois voltava à vida no momento em que saía da zona. Refizemos o levantamento de mapa de calor sem fio, baixamos a altura de montagem dos APs para baixo das vigas dos racks, replanejamos os canais. Corrigido sem o fornecedor nunca se envolver.
Por que um handoff de WiFi pode matar um AMR
O mecanismo é simples. À medida que um AMR se move, seu cliente WiFi precisa saltar entre APs: escolher um AP alvo, reautenticar, reassociar, retomar o fluxo de dados. Numa rede sem ajuste, esse handoff leva centenas de milissegundos. Sem o roaming rápido 802.11r habilitado, um handoff pode derrubar a conexão por mais de um minuto, nada incomum.
E os fornecedores de AMR jogam pelo seguro: um tempo limite de comunicação dispara uma parada de emergência. Então o que você vê é 'o robô falhando', mas a doença está na rede. Pior, um armazém é o pior ambiente de rádio possível: racks metálicos, baias de carregamento de empilhadeiras e portas de rolo metálicas são todos assassinos de WiFi, e um armazém está cheio dos três.
A lista de verificação de campo: cinco passos
Esta é a seção completa de rede da minha lista de verificação da véspera do go-live para cada projeto de AMR. Trabalhe nela e marque cada caixa.
Passo 1: Faça o levantamento do site antes do go-live. Não confie nos desenhos.
Percorra o piso com software de levantamento (até uma ferramenta de nível de app de celular serve) e gere um mapa de calor do sinal. Verifique três coisas: intensidade do sinal ao longo de cada rota de viagem dos AMRs, sobreposição suficiente entre APs para handoffs limpos, e nenhuma zona morta atrás de racks metálicos. As posições dos APs no desenho e a realidade do piso discordam oito em cada dez vezes: os racks foram movidos, um AP foi atingido por uma empilhadeira, uma parede divisória que nunca chegou ao desenho foi levantada.
Passo 2: Planeje o posicionamento dos APs contra três regras duras.
Altura de montagem: os APs devem ficar abaixo das vigas dos racks para que o sinal tenha linha de visão para as antenas dos AMRs. Montagem no teto parece arrumada, mas racks metálicos comem o sinal no café da manhã. Densidade: erre para o lado de mais APs. Um AP extra custa muito menos do que uma hora de linha de AMR parada. Planejamento de canais: APs vizinhos não devem compartilhar canal, planeje 2.4 GHz e 5 GHz separadamente, e mantenha os AMRs em 5 GHz onde a interferência é menor.
Passo 3: Ajuste o roaming. Este é o núcleo.
Habilite o roaming rápido 802.11r nos APs para empurrar a latência de handoff para abaixo de 150 milissegundos. Depois ajuste a agressividade do roaming nas placas WiFi dos AMRs: muito 'leal' e o cliente se agarra a um AP moribundo; muito 'paquerador' e ele fica pulando entre dois APs. Meu ponto de partida é o ajuste do meio, depois meço as taxas de sucesso de handoff e testo um nível em cada direção, mantendo o mais estável. Cada placa WiFi se comporta de forma diferente. Não há ajuste universal, apenas ajustes medidos.
Passo 4: Construa redundância para as rotas que não podem se dar ao luxo de uma queda.
Se os AMRs rodam na artéria principal, cruzam andares ou trabalham nas portas de doca, em qualquer lugar onde uma desconexão seja inaceitável, considere placas WiFi duplas ou WiFi mais failover celular. Sim, custa mais. Custa menos do que um evento de parada de emergência da frota inteira. Redundância é para rotas críticas, não para cada robô.
Passo 5: Lista de verificação da véspera do go-live mais testes de aceitação.
Na noite antes do go-live, percorra o piso com esta lista: execute cada rota de AMR de ponta a ponta três vezes, registrando cada timestamp de handoff de AP e qualquer perda de pacotes. Depois simule o pior caso: carregadores de empilhadeira todos ligados, portas de rolo fechadas, todos os aparelhos no WiFi no início do turno, e execute tudo de novo. Qualquer ponto com latência de handoff acima de 150 milissegundos é sinalizado e reajustado no dia seguinte, depois retestado. Escreva a barra de aceitação no contrato: 72 horas seguidas com zero perdas de tarefas causadas pela rede antes de a rede ser assinada.
Erros clássicos (todos pagos com sangue)
| O que você vê | Não comece com isso | Comece com isso em vez disso |
|---|---|---|
| AMRs perdem tarefas no mesmo ponto | Pedir ao fornecedor para ler logs de despacho | Faça um ping nesse corredor e verifique a cobertura de AP |
| Uma zona inteira desacelera junta | Adicionar mais robôs ou aumentar a prioridade das tarefas | Verifique a carga dos APs e a interferência de canais nessa zona |
| Bem de manhã, falhando à tarde | Reiniciar os AMRs ou atualizar o firmware | Procure interferência com padrão temporal: baias de carga, portas de rolo |
| Ótimo na primeira semana, degradando na segunda | Suspeitar de envelhecimento do hardware AMR | Verifique novos racks, novas divisórias ou um AP atingido |
Uma opinião contrária
A maioria dos projetos inverte a ordem das operações: duas semanas do fornecedor de AMR desmontando coisas, e só então alguém pensa em verificar a rede. A ordem correta é sempre ping primeiro, ligação depois. Uma verificação de rede custa um laptop e meio dia. Uma visita do fornecedor custa a viagem mais duas semanas de discussão. E aqui está a parte que as pessoas perdem: uma vez que a rede está ajustada, muitos 'problemas de desempenho de AMR' se resolvem sozinhos. A velocidade da frota sobe, as taxas de sucesso de tarefas sobem, e você nunca precisou daqueles robôs extras.
Um AMR é um trabalhador honesto. Ele só faz o que lhe dizem. Quando as instruções não conseguem alcançá-lo, tudo o que ele pode fazer é uma parada de emergência para se manter seguro. Não culpe o trabalhador. Verifique seu WiFi primeiro.
Por Lin Xiao, Consultor de implementação de WMS
Traduzido do inglês. Em caso de divergência, prevalece a versão em inglês.
