Por que ROS?

Sumário

  1. Computação distribuída
  2. Reusabilidade de software
  3. Testagem rápida
  4. O ROS não é…

A comunidade de robótica tem feito um progresso expressivo nos últimos anos. Hardwares robóticos baratos e de confiança — desde robôs móveis terrestres, drone quadrimotores, a humanóides — estão muito mais acessíveis do que anos atrás. Talvez o que seja ainda mais impressionante, é como a comunidade também tem desenvolvido algoritmos que ajudam esses robôs a operarem com níveis crescentes de autonomia.

Apesar desse rápido progresso (ou, alguns podem argumentar, por causa dele), os robôs ainda apresentam alguns desafios significativos para os desenvolvedores de software. Este livro introduz uma plataforma de software chamada Robot Operating System, ou ROS1, cujo objetivo é facilitar algumas dessas dificuldades. A descrição oficial de ROS é:

ROS é um sistema open-source (código aberto), meta-operacional para o seu robô. Ele provê os serviços que você esperaria de um sistema operacional, incluindo abstrações de hardware, controle de dispositivos de baixo nível, implementação de funcionalidades comumente usadas, passagem (troca) de mensagens entre processos, e gestão de pacotes. Também fornece ferramentas e bibliotecas para obter, construir, escrever e rodar códigos através de múltiplos computadores.

Essa descrição é precisa — e enfatiza corretamente que o ROS não substitui, mas, ao invés disso, trabalha lado a lado com um sistema operacional tradicional — mas pode te levar a imaginar quais são as reais vantagens para o software que usa o ROS. Afinal de contas, aprender a utilizar um novo framework, particulamente um tão complexo e diverso quanto ROS, pode levar um pouco de tempo e energia mental, então é melhor ter certeza de que o investimento valerá a pena. Aqui estão alguns problemas específicos em desenvolver softwares para robôs que o ROS pode ajudar a resolver.

Computação distribuída

Muitos sistemas de robôs modernos dependem de softwares que abrangem diferentes processos e rodam através de vários computadores diferentes. Por exemplo:

  • Alguns robôs carregam múltiplos computadores, cada um com o controle de uma sub-seção dos atuadores ou sensores do robô.
  • Mesmo com um único computador, muitas vezes é uma boa ideia dividir o software do robô em partes pequenas e autonômas que cooperam para atingir o objetivo geral. Essa abordagem pode ser chamada de “complexidade via composição”.
  • Quando múltiplos robôs tentam cooperar numa tarefa compartilhada, eles, muitas vezes, tem uma necessidade de se comunicar uns com os outros para coordenar seus esforços.
  • Usuários humanos geralmente mandam comandos para o robô de um laptop, um computador desktop, ou um dispositivo móvel. Nós podemos pensar nessa interface humana como sendo uma extensão do software do robô.

A discussão comum entre todos esses casos é a necessidade de uma comunicação entre múltiplos processos que podem, ou não, estar no mesmo computador. O ROS provê dois mecanismos relativamente simples e contínuos para esse tipo de comunicação. Nós iremos discutir os detalhes nos Capítulos 3 e 8.

Reusabilidade de software

O rápido progresso de pesquisas na área de robótica resultou no crescimento de um conjunto de bons algoritmos para tarefas recorrentes como navegação, planejamento de trajetória, mapeamento e muitas outras. Evidentemente, a existência destes algoritmos só é verdadeiramente útil se há uma maneira de aplicá-los em novos contextos, sem a necessidade de reimplementá-los a cada novo sistema. O ROS pode ajudar na prevenção deste tipo de problema em pelo menos duas maneiras.

  • Os pacotes padrão do ROS provêem implementações estáveis e depuradas de muitos algoritmos importantes na área de robótica.
  • A interface de passagem de menssagens do ROS está se tornando uma referência na interoperabilidade de softwares robóticos, o que significa que o ROS é quase sempre compatível com os hardwares mais recentes e com algoritmos de ponta. Por exemplo, o website do ROS lista centenas de pacotes ROS de domínio público. Este tipo de compatibilidade reduz significativamente a necessidade de escrever códigos extras para conectar partes já existentes.

Como resultado, os desenvolvedores que utilizam o ROS podem esperar - após, claro, percorrerem a curva de aprendizagem inicial da ferramenta - aplicar mais tempo na experimentação de novas ideias, e menos tempo reinventando a roda.

Testagem rápida

Uma das razões pelas quais o desenvolvimento de software para robótica é ainda mais desafiador do que outros tipos de desenvolvimento é que a testagem pode ser demorada e sujeita a erros. Robôs físicos nem sempre estão disponíveis para experimentações, e quando estão, o processo pode ser lento e minucioso. Trabalhar com o ROS provê duas alternativas efetivas para este problema.

  • Sistemas ROS bem projetados separam o controle direto de baixo-nível do hardware e o processamento de alto-nível e de tomada de decisões em programas distintos. Devido a essa separação, podemos substituir temporariamente estes programas de baixo-nível (e o hardware correspondente) com um simulador, para testar o comportamento da parte alto-nível do sistema.
  • O ROS também fornece uma maneira simples de gravar e reproduzir dados de sensores e outros tipos de mensagens. Este recurso significa que podemos potencializar o tempo empregado na operação de um robô físico. Ao gravar os dados dos sensores do robô, podemos reproduzi-los inúmeras vezes de modo a testar maneiras diferentes de processar os mesmos dados. No linguajar ROS, estas gravações são chamadas de “bags” e uma ferramenta chamada rosbag é usada para gravá-las e reproduzi-las. Veja o capítulo 9.

Um ponto crucial destas duas funcionalidades é que a mudança é suave. Pelo fato do robô real, o simulador e o mecanismo de reprodução “bag” proverem interfaces idênticas (ou pelo menos muito semelhantes), seus programas não precisam ser modificados para operar nesses cenários distintos, e de fato nem precisam “saber” se a comunicação se dá com um robô real ou com qualquer outra coisa.

Obviamente, o ROS não é a única plataforma que oferece estas capacidades. O que é único a respeito do ROS é, pelo menos na visão do autor, o nível de suporte difundido na comunidade de robótica. Esta “massa crítica” de suporte torna razoável a previsão de uma contínua evolução, expansão e melhoramento do ROS no futuro.

O ROS não é…

Por fim, vamos reservar um tempo para rever algumas coisas que não são verdade sobre o ROS.

  • ROS não é uma linguagem de programação. Na verdade, os programas ROS são normalmente escritos em C++, e este livro tem algumas instruções explícitas de como fazer isso. Bibliotecas cliente também são disponibilizadas para Python, Java, Lisp, e um punhado de outras linguagens.
  • ROS não é (somente) uma biblioteca. Apesar do ROS incluir bibliotecas cliente, ele também inclui (entre outras coisas), um servidor central, um conjunto de ferramentas de linha-de-comando, um conjunto de ferramentas gráficas, e um build system.
  • ROS não é um ambiente de desenvolvimento integrado. Muito embora o ROS não prescreva qualquer ambiente de desenvolvimento específico, ele pode ser usado com as IDEs mais populares. É bem compreensível (e, de fato, esta é a preferência pessoal do autor) usar o ROS a partir de um editor de texto e por meio de linhas de comando, sem qualquer IDE.

1 Quando dito em voz alta, o nome “ROS” é quase sempre pronunciado como uma única palavra que rima com “moss”, e quase nunca soletrado como “Érre-ó-ésse”.