Mecanismos de comunicação entre nodos do ROS

O ROS utiliza mecanismos que permitem que os nodos possam se comunicar. Dentre estes mecanismos estão os tópicos, os serviços e os action servers.

4.2.4.1 Tópicos

Os tópicos são um mecanismo publisher/subscriber através do qual os nós podem trocar mensagens (ROBOT OPERATING SYSTEM, 2014b), possuindo uma semântica anônima com relação a qual o nodo que publica ou subscreve a mensagem, assim o nodo não possui a informação de qual o seu parceiro na comunicação.

Ao invés disso o nodo que precisar de um determinado dado em específico deve subs- crever no tópico apropriado, assim como nodos que publicam dados devem publicar no tópico apropriado. Um único tópico pode ter uma série de nodos publicando e subscre- vendo ao mesmo tempo.

4.2.4.2 Serviços

Os nodos são destinados à transmissão unidirecional de dados, e para os casos onde há a necessidade de execução de alguma RPC por parte do nodo, ou seja, receber uma confirmação em relação a um pedido o nodo deve utilizar um serviço para tal fim (ROBOT OPERATING SYSTEM, 2014b).

O modelo publisher/subscriber de mensagens é extremamente flexível mas a grande quantidade de trocas unidirecionais não é apropriada para requisições do tipo RPC ou interações do tipo requisição/resposta que são geralmente solicitadas em sistemas dis- tribuídos. Neste caso, o ROS oferece um serviço, que é um processo que possui uma estrutura do tipo requisição/resposta, permitindo também operações do tipo RPC entre nodos (ROBOT OPERATING SYSTEM, 2014b).

No ROS os serviços são identificados por um nome (uma string), permitindo que um cliente faça uma chamada ao serviço enviando uma mensagem e esperando pela resposta.

4.2.4.3 Action Servers

Em sistemas de grande porte baseados no ROS ocorrem situações onde um usuário pode querer enviar uma requisição a um nodo a fim de executar determinada tarefa, e também receber uma resposta referente a requisição enviada. Este procedimento pode ser obtido através de utilização de serviços.

Porém, nos casos em que um serviço exige um longo tempo de execução, o usuário pode querer cancelar a requisição enviada durante sua execução ou receber informações sobre o status de execução da requisição. Assim é possível a criação de action servers utilizando o pacote actionlib que fornece ferramentas para a criação dos mesmos.

Os action servers executam tarefas de longo período de execução que podem ser pre- emptadas e fornecem também uma interface para que clientes possam enviar solicitações. 4.2.5 Controladores do ROS

O ROS ainda não possui uma boa capacidade para implementação de controladores avançados assim como o proposto neste trabalho. A princípio, o ROS não é um sistema de tempo real apesar de que pode apresentar algumas características de tempo real se for

executado em um sistema Linux com PREEMPT_RT kernel patch. Mesmo neste caso,

existe um único laço de tempo real onde todos os controladores serão supervisionados por um gerenciador de controladores (pertencente à classeControllerMannager).

Este laço de tempo real roda a uma taxa fixa de 1kHz, a qual não é adequada para aten- der todas as tarefas de tempo real em um sistema complexo. Neste caso, uma alternativa para sistemas que necessitem executar muitas tarefas de tempo real com diferentes taxas é a utilização do framework OROCOS (Open Robot Control Software) (BRUYNINCKX, 2001) como uma camada de baixo nível para implementação da etapa de tempo real do sistema.

Do ponto de vista da engenharia de controle, o ROS apresenta algumas particulari- dades quando se quer implementar um controlador. Uma delas é a nomenclatura, pois o que o ROS chama de controlador não é necessariamente um controlador na nomen- clatura de um sistema de controle. No ROS um controlador é um plugin para o geren- ciador de controladores que está implementando a interface de controle, a qual tipica- mente possui uma interface para a joint command interface e, ou joint state interface. Observe que um controlador no ROS pode efetuar uma função que não é necessaria- mente a função de um controlador em um sistema de controle. Como exemplo têm-se

o joint_state_controller, que por sua nomenclatura poderia ser interpretado

como um controlador das juntas no espaço de estados, porém trata-se de um publisher dos valores das posições e velocidades das juntas.

Outro problema é que aparentemente a infraestrutura do ROS foi concebida para con- troladores com apenas uma entrada e uma saída (SISO - Single-Input-Single-Output) que gerenciam apenas uma valor escalar de referência, o valor de um sensor e geram uma saída escalar.

Além disso, há discussões em fóruns de desenvolvedores do ROS que assumem a pos- sibilidade de desenvolver controladores com múltiplas entradas e múltiplas saídas (MIMO - Multiple-Input-Multiple-Output) através da composição de controladores SISO. O que não se aplica. Leis avançadas de controle de robôs são intrinsecamente do tipo MIMO e não podem ser decompostas em um conjunto de leis do tipo SISO, sem falar no pro- blema de sincronizar muitos controladores SISO, de forma a se comportarem como um único controlador MIMO. Entretanto neste trabalho, a implementação de um controlador no ROS é apresentada, buscando um melhor entendimento das capacidades e limitações do ROS com relação a implementação de controladores de baixo nível. Implementações similares utilizando o framework OROCOS para implementar capacidades de tempo real podem ser verificadas em IORIS; LAGES; SANTINI (2012); LAGES; IORIS; SANTINI (2014); SANTINI; LAGES (2010).

A Figura 22 mostra a arquitetura de baixo nível dos controladores no ROS. Os contro- ladores são plugins carregados pelo gerenciador de controladores, o qual pode carregar, descarregar, ativar e desativar os controladores. A seção 4.2.6 traz o detalhamento da arquitetura apresentada na Figura 22.

Cada ciclo de controle é realizado a uma frequência de 1kHz. Em cada ciclo a função

update()de cada um dos controladores ativos é invocada sequencialmente e assim cada controlador pode realizar sua tarefa dentro do ciclo. Se o controlador tiver que executar em uma taxa menor, o mesmo deverá implementar uma subamostragem independente. Do ponto de vista de controle digital, o modelo é o de um controlador de tempo contínuo implementado em um computador digital com uma taxa de amostragem tão rápida que os efeitos da digitalização podem ser ignorados. Deve-se notar entretanto que a taxa de 1kHz nem sempre é suficiente para desconsiderar os efeitos da digitalização em qualquer

Figura 22: Arquitetura de controladores de baixo nível no ROS.

sistema robótico, principalmente nos que implementam controle de força e controle de impedância.

O modelo de um controlador de tempo contínuo é apropriado para controladores não lineares, assim como o controlador proposto neste trabalho. A função update() do controlador proposto neste trabalho implementa a lei de controle definida por (197), (199- 201), (238),(239) e (257).