UNIVERSIDADE FEDERAL DO ABC MESTRADO 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 Betoni Orientador: 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

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 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 IEEE/RSJ International Conference on vol. 1, (, 2003), pp 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), st International Symposium on and th German Conference on Robotics (ROBOTIK) (, 2010), pp. 18. 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 ̈ 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