Cone Calorimetry Analysis

• SimWare RTIok

• Openskies RTIwiki

• BH RTI • CERTI • HLA direct • MAK RTI • OHLA • Open RTI • Portico • RTI-s

2.5

CERTI HLA

Trabalhos demonstram a capacidade que o HLA tem de comunicar sistemas distribuídos em tempo real, que o tornam indicado para futebol de robôs que precisam trocar informações em tempo hábil (BOUKERCHE; SHADID; ZHANG, 2007) (ZHAO; GEORGANAS, 2001) (GERVAIS et al., 2012). Aliado a isso, também devido à sua característica, a implementação do HLA não gera códigos extensos, como ocorre com os middleware baseados em CORBA (NAMOSHE et al., 2008). Outro fator que influenciou sobremaneira a escolha do HLA foi o fato de ser padronizado internacionalmente pelas normas IEEE P1516-2010(IEEE, 2010a), P1516.1-2001 (IEEE, 2001) e P1516.2 (IEEE, 2010b).

Além dos fatores apresentados, que influenciaram o pesquisador a optar pelo HLA, destaca-se a falta de um foco específico por parte dos diversos middlewares existentes nas limitações das redes sem fio. Assim, como a proposta é para aplicações de futebol de robôs, a comunicação sem fio é de fundamental importância, e pelo fato de o HLA dar suporte à UDP e à TCP, ele adéqua-se perfeitamente aos experimentos deste estudo.

2.5 CERTI HLA 21 Algumas implementações estão descontinuadas, e outras são comerciais. Esses fatores, aliados à falta de disponibilidade de alguns recursos, dificultam a pesquisa, já que muitos pesquisadores não dispõem de recursos suficientes para adquirir ferramentas caso sejam co- merciais.

Figura 2.3: Arquitetura do Certi

Adaptado de: (NOULARD; ROUSSELOT; SIRON, 2009)

Uma implementação que merece destaque e foi escolhida para o presente trabalho é o CERTI, uma implementação RTI HLA sob licença GPL Open source, que implementa a especificação HLA 1.3 (C++ e java). Pelo fato de o CERTI ser Open source, utilizar TCP e UDP e de poder ser utilizado em várias plataformas, incluindo Linux e Windows (CHAUDRON et al., 2011b), foi escolhido para nossa pesquisa.

O responsável pelo desenvolvimento e pelo aprimoramento do CERTI é o French Aeros-

pace Laboratory(ONERA) que, há anos, desenvolve seu próprio middleware RTI compatível

com o HLA. A implementação do RTI CERTI envolve, em sua arquitetura para a simulação distribuída, dois processos: um local, chamado de RTIA, e um global, denominado de RTIG, bem como uma biblioteca conectada a cada federado.

2.5 CERTI HLA 22 A Figura 2.3 apresenta a arquitetura RTI do CERTI. Nela, cada processo pertencente ao federado se comunica localmente com um processo RTI Ambassador por meio de um socket, no caso do UNIX ou socket TCP, se a plataforma for WINDOWS. O RTIA interage através da rede utilizando o processo global RTIG que gerencia a comunicação entre os federados no processo de troca de mensagens, no qual é utilizado um socket TCP bem como UDP, visando executar algoritmos distribuídos confederados com os serviços do RTI (CHAUDRON et al., 2011a) (CHAUDRON; NOULARD; SIRON, 2011).

Capítulo 3

Trabalhos Relacionados

Alguns autores têm realizado diversos estudos nessa área, com a intenção de levantar as par- ticularidades dos vários middlewares existentes, traçar o que esses projetos já conseguem oferecer com boa funcionalidade e o que ainda está em aberto. Nesse sentido, Mohamed e Al-Jaroodi (2008), Mohamed, Al-Jaroodi e Jawhar (2009) e Mohamed, Al-Jaroodi e Jawhar (2008) apresentam vários projetos de middlewares destinados à comunicação de robôs. Den- tre as várias características destacadas e observadas pelos autores em relação aos middlewa- res investigados, há a facilidade de uso, a extensibilidade, a conectividade e a segurança. Depois de apresentar as características dos middlewares brevemente estudados, os autores identificam e apontam algumas questões em aberto, tais como: segurança, recursos avança- dos de integração e abstração de alto nível de hardware e software.

Na lista de avaliação, estão Miro (ENDERLE et al., 2001) e o RT-middleware(ANDO et al., 2005), ambos baseados no CORBA, que consiste numa arquitetura padrão criada pelo

Object Management Group e utilizada por sistemas distribuídos (GROUP, 1995). Embora

o CORBA seja bastante completo, com diversos serviços, sua implementação gera muita complexidade e deixa-a extensa, o que prejudica a facilidade de uso, fator muito forte a ser considerado nesses middlewares.

O miro (middleware for robots) é um middleware orientado a objetos para robôs de- senvolvido pela universidade de Ulm da Alemanha. Esse middleware utiliza o TAO (ACE ORB) que consiste em uma implementação CORBA, que inclui uma especificação minimun CORBA (FERREIRA, 2006). O TAO possibilitou a aplicação do CORBA para robótica móvel.

24 O miro é estruturado em três camadas Kramer e Scheutz (2007) :

• A camada do dispositivo tem como função, oferecer uma interface de abstração orien-

tada a objetos para todos os sensores e dispositivos atuadores;

• A camada de serviço apresenta ou fornece abstrações para dispositivos via interface

CORBA de definição de linguagem (IDL – Interface Definition Language). A fun- ção dessa interface é de implementar os serviço como objetos de uma rede que são transparentes na plataforma onde serão aplicados;

• A terceira e última camada se responsabiliza pelos módulos funcionais mais utilizados

pelo sistema robótico, que incluem: mapeamento, autolocalização, geração de com- portamento, planejamento de trajetória, registro etc.

Embora o miro seja utilizado com frequência, e tenha como suporte as plataformas Win-

dowse Linux, ele não dá suporte para aplicações em tempo real.

Outro middleware é o RSCA (Robot Software Communication Architecture – Arquitetura de Software de comunicação de robôs), que foi desenvolvido pela Universidade Nacional de Seul e tem como característica marcante o fato de ter suporte em tempo real (4108850). Como informa (YOO; KIM; HONG, 2006). Como informa Hong et al. (2006) O RSCA ofe- rece um ambiente operacional padrão e um framework de desenvolvimento para aplicações de robôs. O ambiente apresenta um sistema operacional em tempo real (RTOS – real-time operating system), um middleware de comunicação e um de implantação. O RTOS oferece uma camada de abstração que torna as aplicações de robô portáteis e reutilizáveis em diferen- tes plataformas de hardware. O middleware de comunicação apresenta-se como uma camada essencial que fornece mecanismos para componentes heterogêneos distribuídos se comuni- carem em tempo real. Por último, a camada de middleware de implementação fornece um mecanismo, através do qual os pedidos dos robôs podem ser carregados, reconfigurados e executados.

Como pode ser observado nos trabalhos apresentados, existem vários desses sistemas que se apresentam como soluções de comunicação de sistemas multirrobôs. Porém, como não existe nenhuma padronização, cada projeto constrói seu próprio middleware destinado a resolver as necessidades da equipe ou do projeto. Assim, o fato de haver diversos middlewa-

25 solução única que abranja todos os requisitos de um middleware ideal para a comunicação desses sistemas.

Conforme já apresentado no capítulo 1, o RTDB é um middleware para ser aplicado em futebol de robôs, criado pelo PROJETO CAMBADA (ALMEIDA et al., 2004). Como o foco dessa dissertação foi de apresentar uma proposta alternativa de um middleware para ser aplicado em futebol de robôs utilizando HLA, esse é um trabalho que mais se aproxima de nossa proposta. Conforme já explanado, o HLA não apresenta tantas perdas de mensagens em relação ao RTDB. O diferencial de nossa proposta, que pode ser apresentado em rela- ção aos middlewares MIRO e RSCA, é o fato de o uso do CERTI HLA não gerar códigos extensos, como ocorre com esses middlewares, já que ele não é baseado em CORBA.

A seguir, apresenta-se uma tabela 3.1 com um breve comparativo dos trabalhos apresen- tados com a proposta apresentada.

Tabela 3.1: Comparação entre os middlewares

middlewares Windows/Linux Realtime Open source Ambiente distribuído

Miro Sim Não Sim Sim

RSCA Sim Sim Sim Sim

RTDB Não Sim Sim Sim

Capítulo 4

Resultados e discussões

Neste capítulo, serão apresentados e discutidos os experimentos realizados com a finalidade de averiguar a validade da proposta apresentada. Foram utilizados nos testes o CERTI e o RTDB, como base de comunicação entre robôs que tiveram seus papéis desempenhados por computadores portáteis (notebooks, notebooks e uma Raspberry PI), todos com distintos poderes de processamento, em que o Raspberry PI representa o robô com menos poder de processamento. Assim, com essa estrutura, foi possível estudar mais amplamente o funcio- namento do HLA, em suas configurações distintas, durante o processo de comunicação.

O estudo foi dividido em três experimentos para diagnosticar a eficiência do HLA no processo de comunicação de sistemas multirrobôs. Os resultados encontrados foram relaci- onados a esses experimentos.

No experimento 1, o propósito almejado foi de verificar o comportamento do HLA quando utilizado para comunicação, em que os elementos envolvidos têm diferentes poderes de processamento. Além disso, esse experimento teve como objetivo analisar os modos de funcionamento do HLA (seção 4.2).

No experimento 2, procurou-se determinar o valor do amortecimento utilizado pelo algo- ritmo desenvolvido que garantisse o desempenho máximo dos robôs. Esse valor é aplicado às maquinas que apresentarem mais velocidade, forçando-os a reduzir sua taxa de envio e dando chance ao robô mais lento para processar o recebimento das mensagens dos demais e poder enviar as suas mensagens. Nesse experimento também objetivou-se a verificação do desempenho da abordagem desenvolvida, comparando-o com as formas padrões do HLA, apurado no experimento 1 .

4.1 Experimento 1 27