UNIVERSIDADE FEDERAL DO ABCMESTRADO EM CIÊNCIA DA

COMPUTAÇÃO

Evolução da infraestrutura embarcada do projeto VERO considerando integração e migração de arcabouços de

software e restrições de Tempo Real

Aluno: Anderson BetoniOrientador: Prof. Luiz Gustavo Bizarro Mirisola

Tema

Arcabouços de software para o desenvolvimento de sistemas robóticos

Veículo autônomo terrestre

Lacunas

ORCA - Soluções de comunicação distribuída

Problema 1: descontinuado

Problema 2: sem suporte a tempo real

OROCOS

Características de software de tempo real

Possibilidade de integração/comunicação

Justificativa

Projeto Vero

Complementariedade de ferramentas

Necessidade de tempo real

Necessidade de evolução do projeto

ICE

API Simplificada

Evitar introduzir novo middleware no ORCA

Possibilidade de integrar sistemas baseados neste middleware com OROCOS

Objetivo & Hipótese

Integração entre OROCOS e ORCA Integração direta via chamada de métodos remotos Integração indireta via serviço de eventos (IceStorm)

Implementação em tempo real no VERO Testes de desempenho de algoritmos: garantir período

constante Características e ferramentas complementares entre

arcabouços Geração de templates e documentação p/ outros

desenvolvedores Migração gradual ORCA → OROCOS Posterior evolução do sistema

Método de pesquisa

Estudo dos arcabouços: artigos, fóruns, documentação, etc.

Identificação e documentação das melhores práticas de programação destes arcabouços

Estudo do middleware ICE (implementações utilizando IceStorm e IceGrid)

Estudo das soluções de integração existentes OROCOS-ROS

Desenvolvimento de componentes em rede (OROCOS, ROS e ORCA)

Estudo de Linux para Tempo Real (RTAI)

Testes práticos em veículo autônomo terrestre

Projeto VERO

Projeto VERO

Ferramentas utilizadas

Linux para Tempo Real (RTAI) sob o OROCOS

Middlewares

CORBA – Para comunicação entre componentes OROCOS

ICE – Para comunicação entre componentes OROCOS/ORCA

IceGrid – Serviço de Nomes

IceStorm – Serviço de Eventos

Ferramentas utilizadas

Arcabouços de software: OROCOS

Desenvolvido desde 2001

Funcionamento dos componentes baseado em máquinas de estado

Voltado para tempo real

Baseado em C++

Ferramentas utilizadas

Arcabouços de software: ROS

Organizado em packages

Grande variedade de packages de terceiros disponíveis, mas, com qualidade muito variável (Bazar)

Troca de mensagens utilizando middleware próprio

Utilização crescente nos últimos anos

Ferramentas auxiliares relativamente maduras (e.g. logging, gráficos, configuração)

Suporte a diversas linguagens de programação (C++, Python, LISP e Octave

Ferramentas utilizadas

Arcabouços de software: ORCA

Camadas finas – permite foco no desenvolvimento dos sistemas robóticos

Utiliza middleware baseado em objetos distribuídos

Tolerância a falhas – componentes são capazes de identificar e tratar falhas (ex.: reiniciar device drivers)

Subprojeto Gearbox: alguns device drivers com processo de revisão por pares (catedral)

Integração OROCOS/ROS

rtt_ros_integration – pacote disponível que permite o envio e recebimento de dados entre os arcabouços

Mensagens – permite somente a comunicação de estrutura de dados

Execução de métodos remotos ainda não está disponível

Conexão das portas é feita através de script ou XML como é feito entre componentes OROCOS

Integração OROCOS/CORBA

Instalação do CORBA é feita juntamente com o OROCOS

Componentes são desenvolvidos sem se preocupar com a forma de comunicação com demais componentes

Biblioteca OCL encapsula a complexidade do CORBA. Responsável por:

Publicar o componente no serviço de nomes

Criar proxy para componentes remotos

Depois de instanciados os componentes remotos comunicam de forma transparente, da mesma forma, que é feita quando estão no mesmo host

Conexão das portas é feita através de script ou XML com comandos específicos para CORBA

Disponibilização do serviço de nomes (nameservices) do CORBA

Integração OROCOS/ORCA

Para transmissão de dados ORCA->OROCOS basta implementar um componente OROCOS como subscriber de um tópico do IceStorm

Para integrações OROCOS->ORCA o componente OROCOS, além de implementar um publisher, também deve-se implementar uma interface (servant) que possibilite receber requisições do componente cliente

Componente ORCA valida as interfaces dos componentes e aproveita para buscar configurações que não precisam ser repetidas sempre, antes de receber dados de outros componentes

Integração OROCOS/ORCA

Para ambos os casos foram feitas classes com <templates> para serem reconfiguráveis de acordo com a interface especifica, de forma a facilitar o desenvolvimento. Além disso, como a compilação do ORCA está difícil em versões de Linux mais novas, deve-se evitar usar as libs do ORCA diretamente

As classe desenvolvidas, assim como os componentes ORCA, possuem tolerância a falhas

Também permitem a alteração da configuração em tempo de execução

É necessário que o IceGrid e o IceStorm estejam disponíveis (em execução)

Trabalhos relacionados

L. Chaimowicz and A. Cowley and V. Sabella and C.J. Taylor, "ROCI: A distributed framework for multi-robot perception and control", in Intelligent Robots and Systems, 2003.(IROS 2003). Proceedings. 2003 IEEE/RSJ International Conference on vol. 1, (, 2003), pp. 266—271.

R. Bischoff and T. Guhl and E. Prassler and W. Nowak and G. Kraetzschmar and H. Bruyninckx and P. Soetens and M. Haegele and A. Pott and P. Breedveld and others, "BRICS-Best practice in robotics", in Robotics (ISR), 2010 41st International Symposium on and 2010 6th German Conference on Robotics (ROBOTIK) (, 2010), pp. 1—8.

Piotr Trojanek and Cezary Zieliński, "A method of integrating robot programming frameworks", 17th CISM-IFToMM Symposium on Robot Design, Dynamics, and Control (RoManSy'08) (2008).

K. Buys and S. Bellens and N. Vanthienen and W. Decre and M. Klotzbücher and T. De Laet and R. Smits and H. Bruyninckx and J. De Schutter, "Haptic coupling with the PR2 as a demo of the OROCOS-ROS-Blender integration", status: accepted (2011).

Service Component Architectures in Robotics: the SCA-Orocos integration - D. Brugali, L. Gherardi, M. Klotzb E cher, H. Bruyninckx – ISOLA 2011

Spirit of berlin: An autonomous car for the darpa urban challenge - hardware and software architecture. Rojo, J., Rojas, R., Gunnarsson, K., Simon, M., Wiesel, F., Ruff, F., Wolter, L., Zilly, F., Santrac, N., Ganjineh, T., Sarkohi, A., Ulbrich, F., Latotzky, D., Jankovic, B., and Hohl, G. (2007)

Classes implementadas

Em elaboração (gerar figura a partir do doxgen)

Composição

Classes ICEClient e ICEServer – responsável por conectar e receber as requisições em uma thread dedicada. Também implementa métodos para configurar a conexão com parâmetros do IceGrid e IceStorm.

Classes Consumer e Provider – responsável por implementar o recebimento/envio dados através do serviço de eventos (IceStorm)

Virar bolinhas?.

Possíveis contribuições teóricas e práticas

Facilitar a migração de componentes de um arcabouço para o outro

Complementariedade de ferramentas

Geração de documentação para a continuação do projeto

Funcionalidades de tempo real para o projeto VERO

Possibilidade de integração do OROCOS com sistemas baseados em infraestrutura ICE

Possíveis limitações do trabalho

Sensores sem possibilidade de leitura em tempo real

Integração com arcabouços diferentes dos listados no escopo deste projeto (ROS/ORCA/OROCOS)

Transporte de dados em tempo real

Cronograma

Conclusões

Familiarização com os arcabouços ORCA, ROS e OROCOS

Integração entre os arcabouços

Identificação de alguns conceitos utilizados no ORCA

Familiarização com o middleware ICE

Criação de typekits no OROCOS para viabilizar o transporte de objetos

Próximos passos até a defesa

Estudo de variantes de Linux para tempo real (RTAI)

Focado na utilização do OROCOS

Testes práticos no VERO do código desenvolvido

Análise e comparação dos resultados obtidos