ROS, sigla de Robot Operating System, é um conjunto gratuito e de código aberto de bibliotecas e ferramentas para desenvolver software de robôs. Apesar do nome, não é um sistema operacional como Windows ou Linux. Ele roda em cima de um, quase sempre o Ubuntu Linux, e oferece aos vários programas de um robô um jeito comum de trocar dados, compartilhar drivers e reaproveitar o trabalho uns dos outros.

O nome confunde muita gente, então vale ser preciso sobre o que o ROS cobre. Ele é muito bom em organizar tudo o que acontece dentro de um robô: o scanner a laser, as rodas, o mapa, o planejador. Já sobre o prédio onde o robô trabalha, com suas portas, elevadores, sensores e as pessoas que precisam saber quando algo dá errado, ele tem bem menos a dizer. Onde termina um e começa o outro é uma questão prática para quem coloca robôs para trabalhar fora do laboratório.

O essencial

  • O ROS é um middleware: um sistema de mensagens, um conjunto de convenções e uma grande biblioteca de pacotes reutilizáveis que rodam sobre um sistema operacional comum.
  • Dentro do robô, pequenos programas chamados nós (nodes) publicam e assinam fluxos de dados nomeados, os tópicos (topics). Assim, um driver de lidar e um planejador de navegação podem ser escritos por pessoas diferentes e ainda funcionar juntos.
  • O ROS 2 é a geração atual; o ROS 1 chegou ao fim do ciclo de vida em maio de 2025, por isso projetos novos começam em uma versão de suporte de longo prazo do ROS 2.
  • O ROS coordena as partes de um robô. Conectar esse robô às portas, sensores e alarmes de uma instalação exige uma camada separada acima dele.

O que é um sistema operacional para robôs?

Um robô é um monte de hardware feito por empresas diferentes: um scanner a laser de um fornecedor, drivers de motor de outro, câmeras, sensores de impacto, uma placa de gerenciamento de bateria. Cada peça vem com sua própria interface. Antes do ROS, cada laboratório e cada empresa escrevia o próprio código de integração para fazer essas peças conversarem, e quase nada disso podia ser reaproveitado no robô seguinte.

Um sistema operacional para robôs resolve isso ficando entre os drivers de hardware e o comportamento do robô. Ele dá aos programas um jeito padronizado de enviar dados uns aos outros, de modo que o código que lê o laser não precisa saber quem usa o que ele produz. Define formatos de mensagem padrão para dados comuns, como uma varredura a laser, uma imagem de câmera ou um comando de velocidade. E traz ferramentas para gravar dados, visualizar o que o robô enxerga e simulá-lo antes de rodar em hardware real.

O rótulo de “sistema operacional” é uma metáfora. Assim como um sistema operacional permite que os aplicativos ignorem qual disco ou placa de rede o computador tem, o ROS permite que o software do robô ignore a marca do scanner parafusado nele, desde que um driver publique a mensagem padrão.

O ROS surgiu em 2007, com os primeiros trabalhos em Stanford e o desenvolvimento na empresa de robótica Willow Garage. Hoje ele é mantido pela Open Robotics e pela Open Source Robotics Foundation, com uma grande comunidade de empresas e universidades contribuindo com pacotes. Dois dos pacotes mais conhecidos são o Nav2, a pilha de navegação para robôs móveis, e o MoveIt, que planeja os movimentos de braços robóticos.

Como funciona o Robot Operating System (ROS)?

O jeito mais fácil de entender é acompanhar um robô. Pense em um robô de entregas que leva suprimentos por um corredor de hospital.

  1. Um nó de driver lê o scanner a laser e publica cada varredura em um tópico chamado /scan, mais ou menos de dez a quarenta vezes por segundo, dependendo do sensor.
  2. Um nó de localização assina o /scan e a odometria das rodas, compara os dois com um mapa armazenado e publica onde o robô acha que está.
  3. A pilha de navegação recebe um destino, como “vá para a ala 3”, planeja um caminho que desvia dos obstáculos da varredura mais recente e publica comandos de velocidade em um tópico chamado /cmd_vel.
  4. Um nó de controle dos motores assina o /cmd_vel e transforma esses comandos em velocidades de roda.

Nenhum desses nós chama outro diretamente. Eles só combinam nomes de tópicos e tipos de mensagem, então dá para trocar o scanner a laser por outro modelo substituindo um único nó de driver.

Tópicos servem para fluxos contínuos. O ROS tem outros dois padrões para tarefas diferentes. Um serviço é uma requisição com resposta rápida, como “salve o mapa atual”. Uma ação é um objetivo de longa duração, com retorno de progresso e a opção de cancelar, que é como “vá até a ala 3” costuma ser enviado. Parâmetros configuram os nós, e arquivos de launch iniciam um conjunto inteiro de nós com um único comando.

Mais uma peça faz muito trabalho silencioso: o tf2, a biblioteca de transformações. Cada sensor está montado em algum ponto do robô, e cada mapa tem a própria origem. O tf2 acompanha como todos esses sistemas de coordenadas se relacionam ao longo do tempo. Assim, quando a câmera vê um obstáculo 1,2 metro à frente e 30 centímetros à esquerda, o planejador consegue convertê-lo em uma posição no mapa sem que cada nó faça a própria geometria.

Em volta desse núcleo ficam as ferramentas do dia a dia: o RViz, para ver em 3D os dados dos sensores e os planos do robô; o rosbag, para gravar e reproduzir tópicos; e o simulador Gazebo, para testar um robô em um mundo virtual.

No ROS 2, a camada de mensagens roda sobre o DDS (Data Distribution Service), um padrão industrial de publicação e assinatura. Os nós se descobrem na rede sem o processo mestre central de que o ROS 1 precisava, e cada tópico pode ter configurações de qualidade de serviço, por exemplo se mensagens perdidas devem ser reenviadas.

ROS 1 vs ROS 2: qual versão do ROS escolher?

A maioria das equipes que começa hoje já sabe que vai usar ROS. O que ainda falta escolher é a geração e a versão, e se algumas partes do robô devem rodar outra coisa.

ROS 1 ROS 2
Situação Última versão Noetic, fim da vida útil em maio de 2025 Em desenvolvimento ativo, nova versão todo mês de maio
Mensagens Protocolo próprio com um mestre central DDS, sem ponto único de falha
Suporte de longo prazo Nenhum daqui em diante Versões LTS com cinco anos de suporte, por exemplo Jazzy Jalisco até 2029
Segurança Sem segurança de transporte nativa O SROS2 adiciona criptografia e controle de acesso
Indicado para Manter robôs existentes Projetos e produtos novos

Na prática, algumas perguntas definem a escolha:

  • Drivers. O fornecedor do seu sensor ou braço oferece um driver para ROS 2? A falta de um driver pode custar mais tempo do que todo o resto junto.
  • Ritmo de lançamentos. Uma nova versão do ROS 2 sai todo mês de maio. As versões de anos pares recebem cinco anos de suporte, e as intermediárias, cerca de um ano e meio. Por isso, produtos costumam fixar uma versão LTS e planejar a migração para a seguinte.
  • Hardware pequeno. O micro-ROS leva os conceitos do ROS 2 para microcontroladores, de modo que uma placa de sensor pode participar diretamente dos tópicos do robô.
  • Braços industriais. Muitos braços industriais são programados pelo controlador e pela linguagem do próprio fabricante. O ROS costuma ficar ao lado desse controlador em vez de substituí-lo, um caminho em que o consórcio ROS-Industrial trabalha há anos.

Planeje a rede desde cedo também. O DDS descobre os nós automaticamente, o que é prático na bancada de testes e gera muito ruído em uma rede corporativa compartilhada com vários robôs. As equipes costumam separar os robôs com IDs de domínio do DDS, restringir a descoberta a hosts conhecidos e ativar o SROS2 antes que o robô saia do laboratório.

Algumas empresas constroem sobre o ROS 2 com pilhas próprias por cima, como os pacotes Isaac ROS da NVIDIA para percepção acelerada por GPU. Outras mantêm uma pilha de software proprietária e expõem só uma interface para fora. Os dois caminhos são comuns, e o segundo pesa quando o robô precisa trabalhar com todo o resto de uma instalação.

Como conectar o ROS a dispositivos IoT?

O ROS foi feito para o interior de um robô, ou para uma frota em uma mesma rede. Um prédio ou uma fábrica tem um segundo conjunto de dispositivos que o robô não consegue perceber: um contato de porta do outro lado do armazém, um sensor de vazamento em uma casa de máquinas, o estado de uma porta corta-fogo, uma medição da qualidade do ar em uma ala. Esses dispositivos normalmente falam LoRaWAN, MQTT, Modbus ou BACnet, não tópicos ROS.

Existem pontes conhecidas. O rosbridge expõe tópicos ROS como JSON via WebSockets, pacotes da comunidade retransmitem tópicos escolhidos de e para brokers MQTT, e o Open-RMF, o Open Robotics Middleware Framework, coordena várias frotas de robôs com infraestrutura compartilhada, como portas e elevadores. Isso resolve o transporte. Decidir qual evento de sensor deve mandar qual robô para onde, e testar essa lógica antes de ela rodar em uma instalação real, é outro trabalho.

Vale decidir cedo o que atravessa essa fronteira. Tópicos brutos, como varreduras a laser e quadros de câmera, são volumosos e detalhados demais para os sistemas da instalação. O que o restante do local precisa é de um conjunto pequeno e estável de fatos e pedidos: a posição do robô no mapa da instalação, o nível de bateria, o estado da missão atual e algumas tarefas que ele aceita, como ir até um local nomeado, voltar à base ou pausar. Manter essa interface enxuta permite que a equipe do robô mude tudo dentro do ROS sem quebrar a lógica da instalação.

Essa camada de decisão é o que um sistema operacional para IA física acrescenta acima do ROS, e é essa a camada que construímos o Kilo para ser. Se a integração do robô expõe alguns comandos via MQTT, por exemplo “ir até o ponto” ou “voltar à base”, você pode salvá-los no Kilo e criar uma regra que envie um deles quando um sensor em outro ponto da instalação relatar um evento, enquanto o ROS continua cuidando da navegação a bordo. Cada comando enviado assim aparece no histórico como Pendente, Entregue, Confirmado, Aviso leve ou Falhou.

Como esses comandos movem uma máquina de verdade, você ensaia a regra antes: executa a regra passo a passo no depurador do Kilo e simula a resposta do robô, para ver cada caminho se desenrolar antes de qualquer implantação.

Perguntas frequentes sobre o Robot Operating System

O ROS é gratuito?

Sim. O ROS é de código aberto, com licenças permissivas que permitem uso comercial sem taxas de licença. Os custos que restam são o tempo de engenharia, o hardware e um eventual contrato de suporte comercial que a empresa decida fechar com uma das consultorias especializadas em ROS.

Qual linguagem de programação o ROS usa?

As duas bibliotecas cliente oficiais são em C++ (rclcpp) e Python (rclpy), e um mesmo robô muitas vezes mistura as duas. Há bibliotecas da comunidade para Rust, Java e outras linguagens, e os tipos de mensagem são definidos em arquivos de interface simples que geram código para cada linguagem.

Dá para rodar o ROS no Windows?

O ROS 2 inclui o Windows entre as plataformas suportadas, ao lado do Ubuntu Linux, e cada versão publica seus níveis exatos de suporte por plataforma em um documento chamado REP 2000. Mesmo assim, a maioria dos tutoriais, drivers e robôs em produção ainda usa Ubuntu, então o Linux continua sendo o caminho mais tranquilo.

O ROS 2 é um sistema operacional de tempo real?

Não sozinho. O ROS 2 foi projetado para poder ser usado em sistemas de tempo real, mas isso também exige um kernel de tempo real, como o Linux com o patch PREEMPT_RT, uma configuração cuidadosa de memória e threads e um hardware que mantenha a temporização. O framework ros2_control é o caminho habitual para rodar malhas de controle rigorosas de braços e rodas dentro do ROS 2.

Se você já opera um robô com ROS 2, ele serve para um primeiro teste enxuto do lado da instalação. Use uma das pontes da comunidade para publicar três tópicos dele em MQTT, como nível de bateria, estado da missão e posição, cadastre o robô como um dispositivo no Kilo e mostre os três valores em gráficos em um painel. Depois, crie uma regra que avise você quando a bateria cair abaixo de 20% com uma missão ainda em andamento. É um único dispositivo e uma única regra, bem dentro do plano gratuito, e nada muda no robô além da ponte.