Programação de robôs de serviço

O que fazemos para o cliente

Pegamos a sua plataforma de serviço — robô de entrega, de desinfecção ou de recepção — e escrevemos para ela o software de trabalho e os cenários de comportamento. A programação de robôs de serviço, conosco, significa implantar o stack no computador de bordo, configurar os drivers do lidar, das câmeras e da base de rodas, construir o mapa do ambiente e a lógica de rotas. Não fabricamos o próprio chassi e não imprimimos a carcaça — quem transporta e desinfeta é o equipamento do cliente, e nós preparamos a camada de controle que o faz agir de forma previsível. O trabalho inclui a integração com os seus sistemas: chamada de elevador, abertura de portas, entrega do pedido, transmissão de status ao sistema de gestão via API. Na saída você recebe não um demo, mas uma máquina configurada, que executa as tarefas definidas no seu prédio.

Como isso funciona na essência

O robô constrói e refina continuamente o mapa do espaço pelos dados do lidar e da odometria, e depois se localiza nesse mapa em tempo real. Sobre a localização trabalha o planejador: ele traça a rota global até o objetivo e, na mesma hora, recalcula a trajetória local, desviando de pessoas, carrinhos e obstáculos temporários. Cada ação aplicada — entrar num quarto, parar junto ao balcão, contornar a fila — é descrita por um cenário próprio, com condições e reações a falhas. Configuramos os limiares de velocidade, as zonas de segurança e o comportamento em caso de perda do objetivo, para que a máquina pare, e não colida com o obstáculo. Toda essa integração de navegação e cenários é o que transforma o hardware do cliente num robô de serviço funcional.

De onde veio a robótica de serviço

Como ponto de partida costuma-se considerar o robô Shakey, desenvolvido no Stanford Research Institute (SRI) de 1966 a 1972. Foi o primeiro robô móvel de uso geral capaz de raciocinar sobre as próprias ações: ele percebia o ambiente, montava um plano, dividia o comando em passos e se recuperava após um erro. A robótica de serviço comercial começou mais tarde: Joseph Engelberger fundou a Transitions Research Corporation em 1984, e em 1988 instalou o primeiro robô hospitalar, o HelpMate, no hospital de Danbury (Connecticut). O HelpMate distribuía sozinho pelos andares medicamentos e amostras, e ao longo de uma década essas máquinas já trabalhavam em mais de uma centena de hospitais. Foi justamente essa linha — do Shakey de pesquisa ao HelpMate de série — que definiu a lógica de navegação e cenários sobre a qual se apoia toda a técnica de serviço de hoje.

Por que a parte de software é crítica

Num robô de serviço a física do chassi é secundária — o resultado é determinado pela precisão da localização e pela qualidade dos cenários. Um erro de posicionamento de dez centímetros significa que a máquina não vai passar pelo vão da porta ou vai parar fora do balcão de entrega; uma divergência entre o mapa e a realidade leva ao travamento no corredor. Por isso a configuração dos parâmetros do planejador, a filtragem de ruído dos sensores e a calibração das zonas de segurança influenciam o resultado mais do que as características dos motores. O robô anda e desinfeta com o próprio hardware, mas quem o conduz é o software, e é dele que depende se ele chega ao destino sem colisões e sem intervenção do operador. Uma programação de robôs de serviço bem feita não é uma opção adicional à plataforma, mas a condição sem a qual ela permanece um conjunto imóvel de componentes.

Em qual stack trabalhamos

A ferramenta básica é o ROS2, framework aberto de robótica: sobre ele se constrói a arquitetura de nós, a troca de mensagens entre sensores e controle, a inicialização e o diagnóstico dos módulos. A navegação implementamos sobre o stack Nav2 — a solução padrão para ROS2, responsável pela construção do mapa, pela localização, pelo planejamento global e local de rota e pelas árvores de comportamento. A combinação ROS2 e Nav2 cobre todo o trajeto do robô: da recepção da nuvem de pontos do lidar ao comando concreto para o acionamento. A lógica aplicada — a ordem das tarefas, as reações a eventos, a integração com elevadores e sistemas de gestão — escrevemos sobre esse stack para o objeto específico do cliente. O stack é aberto e mantido, por isso a solução não fica presa a um único fornecedor e evolui junto com o ecossistema.

Quando surgiram as principais ferramentas

O próprio ROS (Robot Operating System) apareceu na empresa Willow Garage: o repositório do projeto foi criado em 7 de novembro de 2007, e a versão 1.0 saiu em 2010 e rapidamente se tornou o padrão setorial de pesquisa e desenvolvimento. A primeira geração tinha limitações de arquitetura para tarefas de série e multirrobô, por isso foi reescrita: a primeira distribuição do ROS2, com o nome Ardent Apalone, saiu em 8 de dezembro de 2017. O Nav2 evoluiu como sucessor do antigo stack de navegação do ROS, reformulado para ROS2 com uso de abordagens do transporte autônomo. Essas datas importam na prática: trabalhamos na atual segunda geração, projetada para operação industrial, e não num ramo obsoleto. O stack é comprovado pelo tempo e pela comunidade, o que reduz os riscos na operação prolongada da sua plataforma.

Por que dá para confiar isso a nós

Por trás do desenvolvimento está uma equipe com experiência somada em TI de mais de 45 anos, e para nós o robô é antes de tudo uma tarefa de engenharia, e não de marketing. Não prometemos milagres do seu hardware: avaliamos com sobriedade o que a plataforma é capaz de fazer e levamos o software até esse limite. Cada cenário passa por verificação em simulação e em bancada antes de o robô entrar na área de trabalho com pessoas — a partida de verdade ocorre só após a rodagem das situações anormais. Respondemos pela camada de controle: navegação, cenários, integrações e configuração do equipamento do cliente, deixando a fabricação do hardware com o fabricante dele. Essa abordagem repartida dá uma área de responsabilidade clara e um resultado que se reproduz, em vez de ficar bonito numa única demonstração.