PublicouEmily Lalama Alterado mais de 4 anos atrás
4 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 – Necessidade de evolução do projeto
6 Método de pesquisa Estudo dos arcabouços: artigos, fóruns, documentação Aplicação das melhores práticas e conceitos de sistemas distribuídos (proxies, interfaces, mensagens, etc.) Estudo do middleware ICE (implementações utilizando IceStorm e IceGrid) Estudo das soluções de integração existentes OROCOS-ROS, OROCOS-YARP Desenvolvimento de componentes stand alone e em rede (OROCOS,ROS e ORCA) Estudo de Linux para Tempo Real (RTAI) Testes práticos em veículo autônomo terrestre
7 Ferramentas utilizadas Linux para Tempo Real (RTAI) Middlewares – CORBA – ICE IceGrid – Serviço de Nomes IceStorm – Serviço de Eventos
8 Ferramentas utilizadas Arcabouços de software – OROCOS Desenvolvido desde 2001 Funcionamento dos componentes baseado em máquinas de estado Voltado para tempo real
9 Ferramentas utilizadas Arcabouços de software – ROS Organizado em packages Bazar: Grande variedade de packages de terceiros disponíveis, mas, com qualidade muito variável Troca de mensagens utilizando middleware próprio Utilização crescente nos últimos anos
10 Ferramentas utilizadas Arcabouços de software – ORCA Camadas finas Utiliza middleware baseado em objetos distribuídos Tolerância a falhas Subprojeto Gearbox: alguns device drivers com processo de revisão por pares (catedral)
11 Integração OROCOS/ROS Mensagens Serviços rtt_toolkit Conexão das portas é feita através de script ou xml como é feito entre componentes OROCOS
12 Integração OROCOS/CORBA Instalação do CORBA é feita juntamente com o OROCOS Conexão das portas é feita através de script ou xml com comandos específicos para CORBA Disponibilização do nameservices do CORBA Componentes são desenvolvidos de forma transparente, somente no momento da implementação a configuração via CORBA é realizada.
13 Integração OROCOS/ORCA Para integrações ORCA->OROCOS basta implementar um componente OROCOS como subscriber de um tópico do IceStorm. Para integrações OROCOS->ORCA além de implementar um publisher é necessário implementar uma interface (servant) que possibilite receber requisições de um componente cliente. 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.
14 Integração OROCOS/ORCA 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. É necessário que o IceGrid e o IceStorm estejam disponíveis (em execução)
15 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. 266271. 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. 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)
16 Trabalhos relacionados Artigo: 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). Arcabouços envolvidos: MRROC++ e Player Metodologia: Thread de comunicação dentro de uma classe transmissora Player. Cenario: Joystick (Player) controlava um manipulador MRROC++
17 Classes implementadas Em elaboração (gerar figura a partir do doxgen) Composição Thread – responsável por conectar e receber as requisições. Também implementa métodos para configurar a conexão com parâmetros do IceGrid e IceStorm. Consumidor/Provedor – responsável por implementar o recebimento/envio dados.
18 Possíveis contribuições teóricas e práticas Facilidade de migração de componentes de um arcabouço para o outro Geração de documentação para a continuação do projeto Funcionalidades de tempo real para o projeto VERO Evolução do projeto VERO Possibilidade de integração do OROCOS com sistemas baseados em infraestrutura ICE.
19 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
20 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
21 Trabalhos futuros Estudo de restrições de tempo real (RTAI) Testes práticos no VERO do código desenvolvido Análise e comparação dos resultados obtidos