Acesso ao Trabalho - Bacharelado em Ciência da Computação

Transcrição

Alexandre Heideker
Validação Robótica em Simulação Multiagentes: Uma
Proposta de Ligação Entre os Mundos Virtual e Real
Monografia
apresentada
ao
Centro
de
Matemática,
Computação e Cognição CMCC/UFABC - como parte dos requisitos
necessários à obtenção do título de Bacharel em
Ciência da Computação.
Orientadora: Dr a Maria das Graças Bruno Marietto
Co-Orientador: Dr. Wagner Tanaka Botelho
Universidade Federal do ABC
15 de Dezembro de 2010
R ESUMO
A simulação baseada em agentes tem mostrado seu valor em diversos estudos, criando
modelos para entender e aprimorar o sistema alvo considerado. Na literatura, existem
vários métodos e ferramentas para validar estas simulações. Porém, em determinados tipos
de Simulação Multiagentes (exemplo do modelo sócio-cognitivo), ainda existem modelos
conceituais que não podem ser validados pelos métodos tradicionais. O objetivo principal
desta pesquisa é apresentar uma proposta para a validação de Simulações Multiagentes
via interligação entre o mundo real e virtual com o uso de plataformas robóticas. Um
estudo sobre as Simulações Multiagentes é apresentado para contextualização das técnicas
utilizadas no processo de validação. O estudo dos métodos de validação robótica a ser
aplicado em um sistema multiagente e a adaptação da plataforma LEGO Mindstorms
permitirá a criação de um ambiente real.
ii
A GRADECIMENTOS
Gostaria de agradecer em primeiro lugar a Universidade Federal do ABC, sem a qual
esta realização não seria possível. Com a mesma consideração, agradeço também a
professora Dr a Maria das Graças Bruno Marietto e ao professor Dr. Wagner Tanaka Botelho,
meus orientadores neste projeto, cujos ensinamentos e conselhos sempre colocaram meus
esforços no rumo certo.
Agradeço também a minha esposa Samantha, pelo seu amor e paciência permanentes
ao longo destes quatro anos de graduação. A minha Mãe, pelo seu empenho em me
proporcionar a melhor educação que estava a seu alcance e meus familiares e amigos, por
compreenderem a longa ausência durante este período.
Finalmente, dedico esta conquista a memória de meu pai Carlos Heideker, que durante
sua vida me mostrou a importância do estudo e do trabalho para a formação de meu caráter,
sempre me desafiando a conquistar mais. Pai...Eu consegui!
S UMÁRIO
Resumo
ii
Sumário
iv
1 Introdução
1
1.1 Objetivos do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.2 Principais Contribuições . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.3 Organização do Texto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
I Referencial Teórico
3
2 Simulação Multiagentes: Conceitos Fundamentais
4
2.1 Modelos de Simulação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2.1.1
Simulação Multiagentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.1.2
Áreas da Simulação Multiagentes . . . . . . . . . . . . . . . . . . . . . . .
9
3 Verificação e Validação em Simulações Multiagentes
13
3.1 Verificação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
3.2 Validação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
3.2.1
Validação Estática . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
3.2.2
Validação Dinâmica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
3.2.3
Técnicas de Validação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
3.2.3.1
Técnicas Visuais . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
3.2.3.2
Técnicas Estatísticas . . . . . . . . . . . . . . . . . . . . . . . . .
17
3.2.3.3
Técnicas Comparativas . . . . . . . . . . . . . . . . . . . . . . . .
18
3.3 Validação Sócio-Cognitiva . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
4 Robótica: Conceitos Fundamentais
22
4.1 Sistema Mecatrônico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
4.1.1
Sistema Mecânico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
4.1.2
Atuadores e Sensores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
4.1.3
Elementos de Computação na Mecatrônica . . . . . . . . . . . . . . . . .
25
4.2 Simulação Robótica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
iv
SUMÁRIO
v
4.3 Validação Robótica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.1
27
Multiagentes Robóticos . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
5 Validação em Simulação Multiagentes: Um Estudo de Caso na Plataforma Swarm
31
5.1 Plataformas de Simulação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
5.1.1
Plataforma Repast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
5.1.2
Plataforma Ascape . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
5.1.3
Plataforma NetLogo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
5.2 Swarm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
5.2.1
Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
II Modelagem Conceitual e Computacional
40
6 Modelo Conceitual: Arquitetura de Integração dos Mundos Virtual e Real
41
6.1 Estrutura da Proposta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
6.2 Definição dos Componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
6.2.1
Protocolo de Comunicação . . . . . . . . . . . . . . . . . . . . . . . . . . .
7 Modelo Computacional e Análise de Dados
7.1 A Simulação do Robô Explorador . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
47
47
7.1.1
Objetivo da Simulação . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
7.1.2
Modelo Conceitual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
7.2 Ligação Entre Mundo Virtual e Real . . . . . . . . . . . . . . . . . . . . . . . . . .
51
7.3 Definição do Protocolo de Comunicação . . . . . . . . . . . . . . . . . . . . . . .
52
7.3.1
Interface Virtual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
7.4 O Agente Robô Real . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
7.4.1
Especificação de Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . .
55
7.4.2
Especificação dos Movimentos . . . . . . . . . . . . . . . . . . . . . . . .
56
7.4.3
Algoritmo de Correção de Erros . . . . . . . . . . . . . . . . . . . . . . . .
57
7.4.4
Interface Real e o Software de Controle . . . . . . . . . . . . . . . . . . . .
59
7.5 Cenário e Execução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
7.5.1
Reprodução de Movimentos . . . . . . . . . . . . . . . . . . . . . . . . . .
61
7.5.2
Reprodução de Eventos . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
62
7.5.3
Simulação Completa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
63
III Conclusão
7.6 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
R Referências
66
67
69
CAPÍTULO
1
I NTRODUÇÃO
A simulação baseada em agentes tem mostrado seu valor em diversos estudos, criando
modelos para entender e aprimorar a modelagem e a implementação de sistemas alvo.
O processo de validação destas simulações pode ser realizado utilizando uma grande
quantidade de métodos porém, em alguns casos, este pode ser o real desafio no processo
de simulação. A principal dificuldade neste processo é que não há consenso sobre quais
métodos são válidos e quando e onde aplicá-los.
Entre os métodos de validação disponíveis, algumas abordagens ainda não foram
totalmente exploradas. A proposta deste projeto de pesquisa é o estudo e exploração
de uma recente forma de validação onde os agentes virtuais e robóticos interagem em
tempo real, expandindo a percepção obtida nestas simulações e fornecendo novos dados
para melhor compreender e validar o modelo conceitual desenvolvido. Neste contexto,
não só a implementação desta nova abordagem como também a apresentação desta visão
à comunidade científica representa uma significativa contribuição à área de Simulações
Multiagentes.
Entre os desafios que este projeto apresenta destacam-se:
• Definição de modelos conceituais para diferentes técnicas de validação em simulações
multiagentes;
• A comunicação e interação entre simulação multiagentes virtual com a simulação real
robótica.
A integração entre abordagens real e virtual permite simular, entre outros fatores, falhas
não previstas na simulação, fatores difíceis de modelar computacionalmente, margens de
erro e variações aleatórias.
1
1.1. Objetivos do Projeto
2
1.1 Objetivos do Projeto
Este projeto de pesquisa apresenta dois objetivos. O primeiro objetivo refere-se ao
estudo de técnicas de validação em simulação multiagentes, considerando seus aspectos
teóricos e práticos. Uma das formas de validação de uma simulação virtual multiagentes,
e que é considerado com mais ênfase neste trabalho, é o uso de robôs em tempo real.
Com esta relação biunívoca com o agente virtual versus físico é possível analisar como
comportamentos em um ambiente virtual simulado podem ser replicados em um ambiente
real, suas interações e influências, assim como seus efeitos na validação do modelo
conceitual. O segundo objetivo geral está relacionado à implementação de uma simulação
computacional, e posterior validação com robôs em tempo real.
1.2 Principais Contribuições
Este projeto contribuiu na área de simulações multiagentes propondo um método de
validação que envolve os ambientes simulado e real. Com igual importância, considerando
a proposta multidisciplinar da UFABC, mostrou a possibilidade de integração entre as áreas
da computação, robótica e ciências sociais.
1.3 Organização do Texto
Este documento está dividido em três partes: Referencial Teórico, Modelagem Conceitual
e Computacional e Conclusão. O referencial teórico contém quatro capítulos, onde a teoria
de simulações multiagentes, técnicas de verificação e validação, conceitos de robótica e
plataformas de simulação são abordados. A modelagem conceitual e computacional possui
dois capítulos onde o modelo conceitual do experimento e a implementação do mesmo
na plataforma de simulação e robótica são abordados. Finalmente, a conclusão aborda o
resultado geral deste projeto assim como as propostas de trabalhos futuros.
I Referencial Teórico
3
CAPÍTULO
2
S IMULAÇÃO M ULTIAGENTES : C ONCEITOS
F UNDAMENTAIS
Nós somos aquilo que fazemos repetidamente. Excelência, então, não
é um modo de agir, mas um hábito.
—– Aristóteles.
A área de Simulação Multiagentes é formada pela intersecção das áreas de Inteligência
Artificial Distribuída (IAD) e Simulação Computacional. O objetivo dos pesquisadores
em Simulação Multiagentes, quando do uso do arcabouço oferecido pela IAD, é utilizálo na modelagem, implementação e análise de simulações que levem a um melhor
entendimento dos sistemas que estão sendo simulados. Para isto é preciso ter conhecimento
da infraestrutura necessária à construção de Simulação Multiagentes. Entretanto, o que
motiva suas pesquisas é o estudo da simulação e do modelo simulado.
2.1 Modelos de Simulação
Um modelo de simulação é um tipo particular de modelo que também procura
representar um determinado sistema, real ou abstrato. Entretanto, difere dos demais na
medida em que permite:
• Estudar como o sistema modelado se comporta sob determinadas condições;
• Examinar, em variados graus de detalhamento, as conseqüências de alterações
internas no comportamento geral do sistema, e vice-versa.
Os modelos de simulação emergiram como técnica identificável durante a Segunda
Guerra Mundial, quando os métodos denominados Monte Carlo foram usados por John Von
4
2.1. Modelos de Simulação
5
Neumann e Stanislaw Ulam em 1940. Estes pesquisadores associaram a expressão análise
de Monte Carlo a uma técnica matemática utilizada para solucionar certos problemas
de blindagem em reatores nucleares.
Este estudo seria muito caro em uma solução
experimental, ou muito complicada para um tratamento analítico. A análise de Monte
Carlo utiliza ferramentas estatísticas com amostragens aleatórias como método para obter
uma aproximação numérica de problemas complexos, ou seja, simular um comportamento
complexo através de um modelo estatístico. Apesar dos conceitos já serem utilizados
em diversos estudos anteriores, apenas na década de 1940 este método começou a ser
formalizado [Hammersley e Handscomb 1964].
Em [Gilbert e Troitzsch 1999, Ferber 1996], são apresentados alguns objetivos de uma
simulação:
• Descobrir e/ou formalizar novas teorias e modelos;
• Testar hipóteses do sistema modelado;
• Obter um melhor entendimento de algumas características do sistema real;
• Predizer comportamentos e ações futuras;
• Analisar e detectar elementos críticos.
Técnicas e ferramentas de simulação têm sido usadas em diversas áreas. Por exemplo,
pesquisadores da área médica usam ambientes simulados para treinar técnicas de cirurgia,
antes de testar em pacientes reais. Na indústria, projetos de máquinas, processos e produtos
são inicialmente desenvolvidos em ambientes simulados, táticas de guerra podem ser
simuladas em campos de batalha artificiais bem como a simulação de catástrofes, como
vazamento de óleo, queimadas, etc. podem ser analisadas com o uso se simulações. Um
simulador pode ser visto como um laboratório, e uma simulação como um experimento
realizado a partir de um modelo.
A infraestrutura técnico-teórica da área de Simulação Computacional permite capturar
elementos essenciais de um sistema alvo, sem trabalhar diretamente com o mesmo. Esta
característica é importante em situações onde, por exemplo:
• É proibitivo, por ser arriscado ou caro, realizar experiências em situações reais;
• Deseja-se saber os limites de um sistema, sem o risco de destruí-lo;
• O sistema a ser simulado é muito complexo, não havendo modelos analíticos
satisfatórios para sua representação.
Em geral, as variáveis de entrada e de saída são definidas por um modelo que tem como
objetivo estabelecer relações entre estas variáveis (veja Figura 2.1).
6
Figura 2.1: Modelo e suas Variáveis.
Ferramentas de simulação permitem ao experimentador estudar a dinâmica de sistemas
de maneira mais ampla, pois a simulação pode ser executada diversas vezes com valores
dos parâmetros modificados entre as execuções. Assim, as alterações nos valores de saída
podem ser analisados, em decorrência dos valores de entrada. A possibilidade de manipular
variáveis durante os experimentos é particularmente útil na área de Ciências Sociais, porque
fatores morais e psicológicos geralmente proíbem ou restringem experimentos com seres
humanos, sistemas e organizações [Berends e Romme 1999].
De forma geral, o desenvolvimento de uma simulação deve levar em consideração duas
características básicas [Berlanga 2003]:
• Definição de um objetivo, uma razão para o desenvolvimento de tal simulação.
Como exemplo tem-se a estimativa do tempo médio de espera de clientes em uma
fila, a estimativa da quantidade de colisões de pacotes em uma rede, análise do
comportamento coletivo em situações de pânico, análise da evolução de normas
sociais, etc;
• Realização de testes para a obtenção de conclusões e validação dos resultados, através
do processo de experimentação.
Figura 2.2: Ciclo de Vida de uma Simulação Computacional.
A Figura 2.2 ilustra um ciclo completo para o desenvolvimento de uma simulação.A
simulação ocorre quando há a transposição de uma parte do sistema alvo para um
7
modelo conceitual equivalente, seguido da codificação deste modelo para um modelo
computacional. Tendo como base o sistema alvo e o objetivo da simulação, os modeladores
iniciam a construção do modelo conceitual (passo 1). O objetivo da simulação guia a escolha
de quais partes do sistema alvo serão modelados. O processo de modelagem resulta na
criação do modelo conceitual do sistema alvo (passo 2). Vale ressaltar que as ações de
modelagem devem ser revisadas na medida em que o desenvolvimento do modelo avança.
Antes de ser codificado para uma linguagem de programação, este modelo precisa ser
analisado para determinar se a sua estrutura e funcionamento correspondem ao sistema
alvo. Esta etapa é denominada de validação estática/estrutural (passo 3). Após a validação
estrutural do modelo conceitual, passa-se à modelagem computacional e sua posterior
implementação (passo 4). Logo em seguida, a etapa de verificação objetiva assegurar que
o modelo conceitual foi transcrito corretamente para o ambiente computacional (passo 5).
Após a codificação, o programa é executado (passo 6), e seu funcionamento deve também
passar pela análise de verificação (passo 7). Caso os resultados da execução tenham sido
aprovados na etapa de verificação, a simulação pode ser executada muitas vezes para se
construir uma série de experimentos que permite extrair resultados e conclusões (passo 8).
Este é o passo da validação dinâmica, ou comportamental. O comportamento do programa
é chamado de simulação computacional.
Vale ressaltar que qualquer erro na modelagem e/ou na implementação acarreta em
erros nos resultados obtidos. Da mesma forma, a má definição da série de experimentos
pode conduzir a erros nas conclusões [Berlanga 2003].
Um modelo de simulação, independentemente do formalismo que é expresso, é sempre
composto pelos seguintes elementos:
• Um conjunto de parâmetros;
• Um conjunto de entidades, ou objetos;
• Um conjunto de relacionamentos entre as entidades, que em alguns casos são fixos, e
em outros casos mudam com o tempo;
• Um formalismo bem definido para o tempo.
Existem diferentes formas de utilização de um modelo de simulação, sendo que a
utilidade dos modelos pode ser dividida em duas categorias: exploratórias e preditivas.
A abordagem exploratória procura explorar e gerar teorias e/ou hipóteses. O objetivo
principal não é predizer o comportamento futuro de um sistema, mas sim oferecer um
framework no qual observações passadas podem ser entendidas como parte de um processo
mais amplo. Modelos exploratórios geralmente focam em um aspecto específico de um
sistema, colocando ênfase em alguns detalhes sobre um fenômeno e ignorando outros.
Tal direcionamento objetiva que este laboratório de explorações leve, empiricamente, a
insights relevantes. Estes modelos procuram definir como a realidade deveria ser, ou poderia
ser, sob determinadas circunstâncias.
8
Embora modelos exploratórios possam oferecer
insights consideráveis sobre a teoria, é difícil estabelecer se o modelo final é informativo
sobre sistemas específicos do mundo real. Um modelo exploratório poderia produzir uma
explicação candidata para a emergência de padrões observados. Em [Drogoul e Ferber 1994]
há um exemplo de simulação de uma colônia de formigas com objetivos exploratórios do
modelo.
Os modelos de predição são usados para extrapolar tendências, avaliar cenários e
predizer estados futuros. Modelos de predição são designados para fazer uma mímica de
sistemas do mundo real, e são particularmente úteis para o desenvolvimento de cenários e
decisões políticas. Um modelo preditivo para epidemias de dengue é exposto em [Jacintho
et al. 2010], onde diversos parâmetros podem ser aplicados para caracterizar diferentes
cenários para a doença.
2.1.1 Simulação Multiagentes
Modelos de simulação multiagentes são compostos de múltiplos agentes heterogêneos
interagindo entre si, que representam um ou mais comportamentos encontrados no objeto
de estudo. As relações entre agentes podem ser especificadas em uma variedade de formas,
desde uma abordagem reativa até uma abordagem direcionada a atitudes deliberativas por
parte dos componentes da agência. Em ambos os casos as ações dos agentes são decididas e
executadas de forma autônoma. Entretanto, suas ações devem ser sincronizadas, e por isto
é necessário escalonar uma estrutura mínima de eventos objetivando coordenar a execução
do sistema. O comportamento dos agentes pode ser escalonado para ser síncrono ou
assíncrono. No comportamento síncrono, a ação dos agentes é disparada pelo ciclo de
tempo discreto, ou seja, a cada ciclo os agentes recebem suas entradas e determinam suas
ações para o próximo ciclo. Já no comportamento assíncrono, as ações dos agentes são
escalonadas pela ação dos outros agentes e/ou em referência a um relógio, ou seja, o agente
não precisa esperar pelo sincronismo do relógio para realizar sua ação.
A seguir mostra-se uma lista não exaustiva de condições, onde modelos baseados em
agentes são úteis para capturar o comportamento emergente:
• A interação entre os agentes é não linear, descontínua. Isto pode ser particularmente
útil se a descrição de descontinuidade do comportamento individual é difícil, por
exemplo, usando equações diferenciais;
• A necessidade de designar uma população heterogênea de agentes é significativa. A
heterogeneidade permite especificar agentes com diferentes tipos de racionalidade e
comportamento;
• A topologia das interações entre agentes é heterogênea e complexa.
Isto é
particularmente importante para processos sociais, devido a questões das redes físicas
e sociais.
9
Dentre as vantagens do uso de uma abordagem baseada em agentes citam-se:
• Captura de fenômenos emergentes;
• Oferecimento de um ambiente adequado para o estudo de certos sistemas.
O fenômeno da emergência é caracterizado por padrões estáveis macroscópicos,
surgindo de interações locais entre indivíduos. Por definição o fenômeno emergente não
pode ser reduzido às partes que o compõe, ou seja, o todo é maior que a soma de suas partes.
As interações dos agentes dão origem a este comportamento emergente, característica
marcante em diversas áreas de estudo. Nas Ciências Sociais, por exemplo, a complexidade
e diversidade do comportamento humano, tem como alvo de estudo este comportamento
emergente que denota a formação de grupos e comportamentos sociais derivados da
interação entre os indivíduos.
O conceito da abordagem bottom-up é uma das bases da Simulação Multiagentes.
A idéia de modelagem ascendente é essencial para modelar sistemas complexos1 , já
que uma abordagem descendente é inviável devido ao grande número de interações
e comportamentos coletivos possíveis.
Esta abordagem permite que elementos que
constituem estes tipos de sistema possam ter seus comportamentos individuais modelados
de forma mais simples.
2.1.2 Áreas da Simulação Multiagentes
Em [David et al. 2004] tem-se uma proposta de classificação hierárquica dos modelos de
Simulação Multiagentes em classes, conforme ilustrado na Figura 2.3.
Figura 2.3: Classificação Hierárquica dos Modelos de Simulação Multiagentes [David et al. 2004].
1 Um sistema complexo pode ser entendido como um sistema composto por um número geralmente grande de
elementos, processos ou agentes interagindo, produzindo comportamentos coletivos não-lineares [Richards, Richards
e Mckay 1998], ou seja, as propriedades colectivas do sistema composto não estão relacionadas diretamente com as
propriedades dos seus elementos individuais [Dilão 1995].
10
Para este projeto, o foco de interesse está voltado para os modelos do tipo sóciocognitivo. Tais modelos são geralmente baseados na representação dos agentes e das
estruturas sociais de acordo com uma teoria específica. A simulação tem a finalidade de
verificar a consistência das teorias e de refinar as mesmas.
Sócio-Técnico
Servindo de arcabouço para os modelos, esta classe abrange o esforço interdisciplinar
entre a Ciência da Computação e as demais áreas do saber, sob um paradigma de integração
e de sistema complexo. Aqui as teorias baseadas em agentes são mais freqüentemente
transferidas entre diferentes domínios. A partir desta classe, tem-se duas grandes áreas
possíveis: sócio-analítico e tecnológico-analítico.
Sócio-Analítico
Esta classe combina modelos sócio-científicos com o caráter exploratório de modelos
sociais artificiais.
Sócio-Científico
Este modelo utiliza fundamentos teóricos de ciências sociais e/ou ciências ambientais
para modelar os fenômenos considerados. Os sistemas alvo são diretamente observáveis ou
há alguma evidência significativa de sua existência. Duas sub-áreas são evidentes: sóciocognitivos e sócio-concreto.
Sócio-Cognitivo
Neste modelo as simulações estão voltadas para uma visão mais formal e abstrata,
procurando construir e representar fundamentos da teoria social. Os problemas tratados
correspondem à descoberta, formalização e teste de teorias, modelos e hipóteses
relacionados a aspectos teórico-estruturais de sistemas sociais.
Assim, o objeto de
estudo corresponde à lógica estrutural do sistema alvo, analisando questões como o
estabelecimento de normas sociais [Conte e Castelfranchi 1995] e coalizões [David, Sichman
e Coelho 2001]. Em [R. e J. 1995] há o exemplo do sistema DEPNET, baseado na Teoria da
Dependência e Poder Social. Os autores exploram um mecanismo de raciocínio social onde
os agentes consideram seus objetivos e a suposição dos objetivos dos outros agentes para
sua tomada de decisão.
Sócio-Concreto
Neste caso, as simulações estão voltadas a uma visão mais pragmática da experimentação,
enfatizando a análise e a representação de modelos e processos sociais já existentes. Esta
abordagem não trata da construção de estruturas teóricas de sistemas sociais.
Antes,
utiliza-se modelos teóricos já existentes na modelagem de processos sociais e institucionais.
Esta abordagem procura obter um melhor entendimento de fenômenos sociais atuais,
11
ou para os quais haja evidências de sua existência. Dentre os fenômenos sociais temse o desenvolvimento de características culturais e efeitos de mudanças em estruturas
organizacionais. Em [S. et al. 1999] o objetivo do estudo é a civilização pré-histórica de
Kayenta Anasakii onde há dados concretos para validar a simulação, ou seja, a intenção é
confrontar os resultados da simulação com informações arqueológicas.
Tecnológico-Analítico
Esta classe aumenta a extensão da Prototipação para Resolução com a influência
exploratória de modelos sociais artificiais. O caráter abstrato alto e a validação estruturalfraca de sociedades artificiais dão lugar a níveis intermediários de abstração com validação
estrutural-forte aos modelos.
Social Artificial
Os sistemas alvo da área de análise de sociedades artificiais não se restringem a modelos
reais de sociedades e de ambientes físicos, permitindo ao pesquisador abstrair a priori
quaisquer relações físicas, sociais, psicológicas e econômicas usualmente conhecidas e
adotadas. Entretanto, esta abstração deve estar condicionada a teorias e hipóteses que
direcionem a construção do modelo conceitual da simulação. Isto porque sociedades
artificiais são modeladas e implementadas objetivando responder questões específicas, bem
como explorar fenômenos particulares. Em [Lovelock 1992], há um exemplo de modelo
sócio-científico onde é simulado o comportamento de auto-regulação de uma população de
flores, porém, com alto nível de abstração, já que Daisyworld (contextualizado no estudo) é
um planeta imaginário e consequentemente os resultados da simulação são confrontados
com uma estrutura idealizada de um mundo imaginário.
Prototipação para Resolução
Os sistemas alvo desta subárea são sistemas reais aonde agentes, humanos ou
não, interagem com ambientes reais tais como construções inteligentes e fenômenos
naturais.
Mesmo havendo testes de hipóteses e teorias, bem como alcançando um
melhor entendimento dos sistemas alvo, os objetivos principais destas simulações são
eminentemente práticos. São eles:
• Avaliação dos sistemas modelados, para posterior aplicação real;
• Treinamento de futuros usuários do sistema;
• Suporte à tomada de decisão, enfatizando predição de comportamentos e de ações
futuras.
Um exemplo de prototipação para resolução é um sistema simulado de tráfego [hadouaj,
Drogoul e ESPIÉ 2001], onde o comportamento do motorista humano é modelado para obter
um desempenho o mais próximo possível de uma situação de tráfego real. Outro exemplo é
12
a implementação de comportamentos em robôs que jogam futebol (RoboCup - [RoboCup
World Championship and Conference 2010]). A RoboCup é uma iniciativa internacional
de pesquisa para promover a pesquisa robótica e inteligência artificial, definindo um
problema padrão onde tecnologias de design, agentes autônomos, colaboração multiagente,
estratégia, robótica, etc. são aplicados na solução. Sob a mesma iniciativa, a RoboCup
Rescue [RoboCup Rescue World Championship and Conference 2010] fomenta a aplicação
destas mesmas tecnologias na solução de problemas de resgate e salvamento, onde agentes
robóticos estão cada vez mais presentes. A Figura 2.4 mostra um exemplo de aplicação
na categoria Standard Platform League da RoboCup.
A Figura 2.5 mostra a imagem
do simulador utilizado na categoria Soccer Simulation da RoboCup. Tanto na categoria
humanoide como na categoria de simulação os conceitos de modelagem multiagentes estão
presentes.
Figura 2.4: Exemplo do Futebol de Robôs [RoboCup World Championship and Conference 2010].
Figura 2.5: Imagem de um Simulador para RoboCup [Simulador RoboCup 2010].
CAPÍTULO
3
V ERIFICAÇÃO E VALIDAÇÃO EM S IMULAÇÕES
M ULTIAGENTES
Eu não procuro saber as respostas, procuro compreender as perguntas.
—– Confúcio.
A credibilidade e conseqüente aceitação de um modelo conceitual modelado computacionalmente é atestada através de duas metodologias: a verificação e a validação. Verificação
é definida em [Arthur e Nance 1996] em termos de Engenharia de software, atestando a
qualidade do software implementado. Já a validação atesta o resultado final do trabalho,
avaliando a sua correspondência com os resultados esperados e/ou objeto de estudo.
Nas próximas seções estes processos são discutidos, definindo o momento e a forma
de aplicação de cada um deles. Neste capítulo a ênfase é na validação que é o foco deste
trabalho.
3.1 Verificação
[Caughlin 2000] define a verificação como um processo que determina se a implementação
do modelo feita pelo desenvolvedor representa com precisão a descrição conceitual e suas
especificações. O processo de verificação é tratado pela teoria como um ou mais passos
no processo de Engenharia de software, assim como o levantamento de requisitos, análise,
modelagem, etc.
A metodologia utilizada segue as mesmas diretrizes dos diversos modelos de processos
de desenvolvimento, como cascata, evolucional, prototipação, espiral, RAD, etc.
Além do processo de Engenharia de software envolvido no desenvolvimento, [Sargent
1999] considera a linguagem de programação utilizada como um fator de incremento
13
3.2. Validação
14
na possibilidade de erros de verificação. O uso de linguagens específicas na simulação
em oposição às linguagens de programação de alto nível diminui consideravelmente a
quantidade de erros nesta fase do processo. Em geral, o processo de verificação pode ser
dividido em duas abordagens: testes estáticos e dinâmicos [Sargent 1999].
Testes Estáticos: Depuração de erros utilizando técnicas como walk-throughs, teste de
mesa, testes de caixa branca, etc.
Testes Dinâmicos: Instâncias dos dados são fornecidas ao software e os resultados obtidos
são examinados durante todo o processo de execução. As técnicas utilizadas são de
cross-validation, relação de entrada/saída, traces, etc.
O crescente número de variáveis presentes nas simulações pode representar um
obstáculo no processo de verificação, aumentando o esforço necessário nesta fase de
desenvolvimento. Uma abordagem comum é a escolha de variáveis-chave no processo de
verificação. O sucesso neste processo é crucial para a validação do modelo conceitual,
atestando que a teoria foi corretamente aplicada na modelagem do agente.
3.2 Validação
[Arthur e Nance 1996] definem a validação como um processo que comprove se o
comportamento de um modelo ou software está em conformidade com os requisitos
especificados. No domínio das modelagens e simulações, tais requisitos são derivados dos
objetos de estudo da simulação. Esta abordagem mostra uma tendência em validar um
modelo utilizando as mesmas técnicas de Engenharia de software, onde os requisitos são
confrontados com os dados obtidos de forma rigorosa, o que requer uma especificação de
requisitos também rigorosa.
Em [Caughlin 2000], a validação é determinada pelo grau que o modelo representa o
mundo real ou o objeto de estudo. Esta abordagem é mais abrangente, já que engloba
modelos onde os requisitos não são definidos e portanto não podem ser confrontados
no processo de validação. Em [Katerelos e Koulouris 2004] há um exemplo de simulação
de investidores tímidos e arrojados no mercado financeiro, onde os requisitos são
contraditórios, portanto não podem ser confrontados. Neste caso, a busca pelo equilíbrio
é o requisito a ser avaliado.
3.2.1 Validação Estática
A validação estática procura analisar se: as teorias sobre o modelo são válidas, a
representação lógica, matemática e as relações de causa e efeito são adequadas ao propósito
da simulação. Nesta fase, as técnicas de validação de face, análise matemática, estatística,
técnicas de indução lógica, etc. são aplicadas ao modelo conceitual para verificar a correta
relação destes efeitos com os dados do sistema real. Esta série de métodos e técnicas é
3.2. Validação
15
aplicada em cada um dos sub-modelos que compõe a simulação até que o modelo global
seja atingido.
A modelagem incorreta implica na revisão do modelo como um todo, já que o modelo
conceitual é a base de toda a simulação. Feita a correção, o processo de validação do modelo
é realizado novamente.
3.2.2 Validação Dinâmica
Na validação dinâmica/comportamental, a preocupação está em avaliar o comportamento do modelo em produção, observando a precisão do mesmo em relação à finalidade
e aplicabilidade pretendida. Este é o ponto de encontro entre todas as abordagens de
validação incluindo o processo de verificação. O fracasso neste ponto pode ser devido à um
modelo conceitual incorreto, erros de programação, precisão numérica, dados inválidos, etc.
3.2.3 Técnicas de Validação
Algumas técnicas de validação são propostas em [Sargent 1999] e são apresentadas aqui
em três grupos: visuais, estatísticas e comparativas.
3.2.3.1 Técnicas Visuais
Neste grupo a avaliação da simulação é realizada pela observação do comportamento e
dos dados produzidos durante a simulação.
Animação
Quando o comportamento do modelo pode ser demonstrado através de movimentos,
estes podem ser avaliados de forma similar ao mundo real. Como exemplo, o movimento
de formigas, de carros em trânsito, de pessoas em uma situação de pânico, etc. Em [França
2010], um modelo de pânico em multidões em um incêndio é apresentado. A movimentação
dos agentes representam estas pessoas durante o incêndio, sendo um dos itens avaliados
durante o processo de validação do modelo proposto. A Figura 3.1 mostra a visualização
gráfica da simulação proposta em [França 2010], com os agentes que representam as pessoas
dirigindo-se para a saída do ambiente onde está ocorrendo um incêndio.
3.2. Validação
16
Figura 3.1: Movimentação dos Agentes em Direção à Saída Formando um Arco [França 2010].
Validação de Eventos
A ocorrência de determinados eventos em uma simulação é comparada à mesma
ocorrência destes eventos no mundo real. Em uma simulação de trânsito, a ocorrência de
acidentes representa um evento inerente ao cenário real e simulado.
Validação Preditiva
Os modelos preditivos são utilizados para prever a ocorrência de determinados
fenômenos ou eventos, baseado em premissas bem estabelecidas. A correspondência destas
predições são avaliadas para atestar a validade do modelo.
Comparação Gráfica dos Dados
Os dados obtidos durante a simulação podem ser representados graficamente em várias
condições experimentais, objetivando determinar se o comportamento do modelo tem uma
precisão suficiente para a sua finalidade. Estes gráficos podem ser usados na validação do
modelo de maneira diferente. De forma similar ao método da animação, a apreciação dos
dados obtidos na simulação, suas tendências e similaridades com o sistema real podem
demonstrar a validade do modelo proposto.
Em [Gou 2006] é proposto um modelo de simulação do mercado financeiro utilizando
simulação multiagentes e teoria de jogos. Os resultados foram confrontados graficamente
com o índice Shanghai. O primeiro gráfico da Figura 3.2 mostra o comportamento da bolsa
de valores em comparação com gráfico produzido na simulação (segundo gráfico na Figura
3.2). O emparelhamento do gráfico não é exato mas mostra um comportamento similar em
alguns momentos, quando ocorrem quedas ou altas bruscas no índice.
3.2. Validação
17
Figura 3.2: Comparação Gráfica com o Índice Shanghai (a) e os Dados da Simulação (b) [Gou 2006].
3.2.3.2 Técnicas Estatísticas
Neste grupo, a aplicação de técnicas matemáticas e estatísticas nos resultados
produzidos pela simulação são utilizados para a validação da mesma.
Intervalos de Confiança
Para cada condição experimental são obtidos intervalos de confiança pelas diferenças
entre as médias, variâncias e distribuições de diferentes variáveis de saída do sistema. Tratase de um tratamento estatístico onde os valores obtidos possuem intervalos de variação bem
estabelecidos. O conhecimento estatístico, incluído também na modelagem conceitual,
permite estabelecer o grau de confiança no modelo, assim como estabelecer curvas de
tradeoff para escolha de valores adequados para os parâmetros.
Teste de Hipótese
O teste de hipótese é realizado através da definição de uma hipótese. Por exemplo, é
considerada verdadeira a hipótese de que o modelo é válido, ou seja, a partir desta hipótese,
os dados do modelo são comparados com os dados do sistema real e/ou intervalos de
confiança. Há a possibilidade de ocorrência de dois tipos de erros: rejeitar a validade de
um modelo válido ou aceitar a validade de um modelo inválido. O tratamento probabilístico
da ocorrência destes erros podem atestar, ou não, a validade do modelo. Em [Heppenstall,
Evans e Birkin 2006] um sistema de análise do mercado varejista é avaliado utilizando a
hipótese de que a lucratividade de um ponto de venda não representa sucesso. A avaliação
desta hipótese pelo teste Wilcoxon signed-rank [Wilcoxon 1945] mostra uma probabilidade
3.2. Validação
18
quase nula desta hipótese ser verdadeira, confirmando a validade do modelo proposto.
Análise da Sensibilidade à Variação de Parâmetros
As mudanças impostas às variáveis de entrada e parâmetros internos de uma simulação
devem ser similares aos efeitos no sistema real exposto às mesmas imposições. Não só a
ocorrência das mudanças, como também seus efeitos quantitativos devem ser avaliados.
Métodos Históricos
Três métodos são utilizados nesta ferramenta: racionalismo, empirismo e economia
positiva. No racionalismo, as premissas são consideradas verdadeiras e deduções lógicas
são utilizadas na validação do modelo. O empirismo exige que os resultados obtidos sejam
comparados com dados empíricos para a validação do modelo. A economia positiva trata de
modelos capazes de prever tendências, não se preocupando com os mecanismos utilizados
e as relações de causalidade do mesmo. Em outra abordagem, pode-se utilizar o método de
validação multi-estágio, onde é aplicado de forma sistemática os métodos históricos durante
o processo de modelagem, execução e validação comparando a relação entre os dados de
entrada/saída com os dados do sistema real.
Validação Interna
Várias repetições de uma simulação são feitas para determinar a variabilidade estocástica
do modelo. Uma grande variabilidade demonstra falta de coerência no modelo, tornando
seus resultados questionáveis. Se isso não representa um comportamento típico da sistema
real, o modelo conceitual é questionado.
Validação com Dados Históricos
Nesta abordagem, os dados obtidos pela simulação são comparados a dados existentes
durante os testes do modelo proposto. A forma mais comum é a utilização de uma parte
destes dados para a criação do modelo, e outra parte para estabelecer a validade do mesmo.
3.2.3.3 Técnicas Comparativas
As técnicas comparativas utilizam outros modelos e/ou padrões já atestados para a
avaliação dos dados produzidos pela simulação.
Comparação com Outros Modelos
No caso da existência de outros modelos já validados, os dados obtidos na simulação
podem ser comparados aos obtidos em outros estudos para validar os mesmos. Há também
casos onde diferentes abordagens são comparadas com dados de modelos analíticos,
reforçando ainda mais a validade do modelo proposto.
3.3. Validação Sócio-Cognitiva
19
Validade de Face
Esta técnica utiliza o conhecimento e opinião do especialista na área de conhecimento
do modelo para indicar se o comportamento e a modelagem são razoáveis. São avaliados
o modelo conceitual, seu comportamento, a relação de entrada/saída de dados, etc. Em
[Pahl-Wostl e Ebenhöh 2004] um modelo de simulação de dinâmica econômica/social é
proposto e sua avaliação é feita por especialistas, já que a modelagem foi feita com um maior
embasamento nos dados do que na teoria.
Seguidores (Traces)
Durante a simulação, o acompanhamento de determinadas variáveis ao longo do tempo
e a correspondência de seu comportamento com a lógica do modelo conceitual determinam
a validade do modelo.
Testes Degenerados
A escolha de valores adequados para a entrada de uma simulação pode demonstrar um
comportamento degenerado predito na modelagem. A correspondência entre o modelo
conceitual e o sistema real nestas situações é avaliada nesta abordagem. Uma abordagem
semelhante é a aplicação de padrões, ou constantes que implicam na obtenção de resultados
preditos que servem como ferramenta de validação para a simulação.
Testes em Condições Extremas
Da mesma forma que os eventos, condições extremas ocorrem, e podem ser avaliadas,
tanto no mundo real como nas simulações. A super-população de um formigueiro deve ter
as mesmas consequências no mundo real e na simulação. Para provocar estas condições, em
muitos casos é necessária a escolha apropriada das variáveis de entrada e dos parâmetros
internos, da mesma forma que os testes degenerados.
3.3 Validação Sócio-Cognitiva
De forma geral as simulações são vistas sob a mesma luz das teorias científicas em geral.
Por conseguinte, o problema da validação é debatido utilizando as posições clássicas da
filosofia e da ciência para a confirmação das teorias. Segundo [Küppers e Lenhard 2005],
esta estratégia não se aplica às ciências sociais, onde descobrir as regras que geram padrões
geralmente é o principal objetivo.
Nos modelos sócio-cognitivos o conhecimento produzido parece ser válido se algumas
das características da dinâmica social, conhecidas através de teorias relacionadas ao mundo
social modelado, são reproduzidas pela simulação. Neste caso, a simulação pode ser vista
como uma prova para as premissas básicas do modelo conceitual [Küppers e Lenhard 2005].
20
A credibilidade obtida por estas simulações é fortemente dependente dos objetivos da
simulação. É difícil definir um ou mais métodos para o tratamento destes tipos de validação,
pois os objetivos podem ter uma abrangência muito grande. De acordo com [Schmid 2005],
as simulações são usadas para conhecer e captar a complexidade. Por exemplo, em uma
simulação de pânico em multidões, se o objetivo é validar se uma pessoa procura sair de
um ambiente perigoso, o fato da simulação mostrar as pessoas saindo do ambiente auxilia
a validar o modelo [França 2010]. Se o objetivo for avaliar o comportamento destas pessoas
neste ambiente, as observações feitas podem não ser compatíveis com a realidade, se
considerada a impossibilidade de obter uma informação factual sobre este comportamento
tornando assim o processo de validação bem mais complexo.
[Moss 2008] defende que o melhor que se pode fazer na tentativa de validar um modelo
é comparar os resultados da simulação com os dados disponíveis. Uma alternativa é a
participação de stakeholders no processo de modelagem, usando suas percepções a respeito
do objeto de estudo. Esta abordagem utiliza o ponto de vista destes stakeholders como base
no processo de validação.
[Windrum, Fagiolo e Moneta 2007] coloca, sob o ponto de vista das ciências econômicas,
a questão da relação problemática entre os resultados obtidos e os dados empíricos. Neste
ponto a validação empírica de um modelo envolve a avaliação da representação de um
processo desconhecido e um conjunto de dados gerados. A questão levantada é qual a
base metodológica para o processo de validação empírica, e se este processo é específico
ou genérico para todas as modelagem. As três abordagens mais influentes na literatura são
a calibração indireta, a calibração empírica e a similaridade histórica.
Calibração Indireta
Como o próprio nome sugere, a abordagem da calibração indireta executa primeiro
a validação e, em seguida, indiretamente calibra o modelo, centrando o mesmo nos
parâmetros que são consistentes na validação de saída. Na primeira etapa identifica-se
um conjunto de fatos de interesse para sua reprodução ou estudo, tipicamente no nível
macro como por exemplo o relacionamento entre as taxas de desemprego e o crescimento
do PIB. Na segunda etapa, juntamente com as normas do procedimento de calibração
empírica, o pesquisador constrói o modelo mantendo a descrição micro tão próximo quanto
possível das empíricas sobre o seu comportamento e suas interações. Na terceira etapa, as
evidências empíricas são usadas para restringir o espaço de parâmetros. Finalmente, novos
comportamentos e fatos são identificados para uma possível validação.
Calibração Empírica
Proposta por [Brenner e Werker 2004], a calibração empírica de modelos é um processo
realizado em três etapas. A principal diferença do método de calibração indireta é que
busca-se parâmetros empíricos diretamente para calibrar o modelo. A primeira etapa
consiste em utilizar o conhecimento existente para calibrar as condições iniciais do
21
modelo assim como os intervalos dos parâmetros. [Brenner e Werker 2004] propõem que
as tolerâncias devem ser maiores para os parâmetros onde há pouco ou nenhum dado
confiável. A segunda etapa envolve a validação empírica dos resultados para cada um dos
parâmetros especificados na primeira etapa, atribuindo uma probabilidade de ser aceito,
com base no percentual de "realizações teóricas"que são compatíveis com cada "percepção
empírica". Finalmente é feita uma nova etapa de calibração recorrendo muitas vezes à
inferência de peritos e/ou historiadores sobre os artefatos obtidos na simulação.
Similaridade Histórica
A similaridade histórica oferece uma solução alternativa para o problema do excesso de
parametrização, comparada com outras abordagens que enfatizam o concreto. A diferença
fundamental é que essa abordagem usa estudos específicos, casos históricos, as interações
dos agentes e as suas regras de decisão. Os modelos são construídos sobre dados disponíveis
a partir de estudos detalhados e evidências históricas sobre o objeto de estudo. Finalmente,
os dados fornecidos pela simulação são rastreados e comparados com os dados históricos
para determinar a sua similaridade. No caso de divergência destes dados, deve ser realizado
um novo estudo, afim de rejeitar o modelo ou determinar novas teorias.
A análise destes métodos mostra uma grande similaridade com os métodos propostos na
Seção 3.2.3. A similaridade histórica é a validação com dados históricos, a calibração indireta
pode ser comparada com os testes degenerados associados a intervalos de confiança, etc.
mas há um ponto em comum nos estudos realizados em simulações sócio-cognitivas: a
utilização de dados ou modelos históricos para atestar a validade do modelo proposto.
CAPÍTULO
4
R OBÓTICA : C ONCEITOS F UNDAMENTAIS
Não basta ensinar ao homem uma especialidade, porque se tornará
assim uma máquina utilizável e não uma personalidade. É necessário
que adquira um sentimento, um senso prático daquilo que vale a pena
ser empreendido, daquilo que é belo, do que é moralmente correto.
—– Albert Einstein.
A Robótica, de acordo com [Rosário 2005], surge como um ramo tecnológico a partir
do início do século XX, relacionada à demanda pelo aumento da produtividade industrial.
Em 1940, o escritor norte-americano Isaac Asimov [Asimov] cria em suas obras de ficção a
cultura e a ética robótica para a convivência pacífica com humanos.
A história da Robótica [Robotics Laboratory 2010] porém remonta a Grécia onde por volta
do ano 350 A.C. o matemático Archytas de Tarentum criou um pássaro mecânico movido
a vapor voltado ao estudo do vôo. Os gregos utilizaram conceitos de automação, com as
tecnologias disponíveis, em relógios, peças teatrais e até mesmo em cerimônias religiosas.
Em 1495, Leonardo Da Vinci cria uma espécie de armadura que realiza movimentos
imitando as ações de um cavaleiro. Na França de 1738, Jacques de Vaucanson constrói três
autômatos: o primeiro era um flautista capaz de tocar doze canções. O segundo podia tocar
a flauta ou um tambor. Finalmente o terceiro, na tentativa de reproduzir a anatomia humana
e/ou animal, foi criado um pato que se movia, batia as asas, produzia ruídos imitando o
pato real e mastigava alimentos. Em 1959, Devol e Joseph F. Engelberger, considerados
pais da Robótica moderna, desenvolveram a primeira aplicação industrial utilizando um
robô, diferindo das outras automações industriais pela possibilidade de ser modificado e
re-programado para outras aplicações, muito semelhante ao conceito atual do mesmo. Em
1961, Heinrich Ernst desenvolveu no Instituto de Tecnologia de Massachusetts (MIT) o MH1, uma mão mecânica controlada por um computador. Na indústria, foi introduzido em
22
4.1. Sistema Mecatrônico
23
1962 o primeiro braço robótico industrial chamado Unimate que foi utilizado para executar
tarefas repetitivas ou perigosas em uma linha de montagem da General Motors.
Apesar de ter sido fortemente fomentado pela necessidade da automação nas indústrias,
as aplicações científicas para os robôs são de extrema importância. Desde a manipulação
de equipamentos perigosos, substâncias tóxicas e ambientes hostis até a reprodução de
comportamentos naturais ou não. Este último deve ser considerado neste trabalho, já que
o comportamento e suas conseqüências pode ser considerado útil na validação de uma
simulação multiagentes.
4.1 Sistema Mecatrônico
[Rosário 2005] define um sistema mecatrônico como um sistema mecânico que é
impulsionado por atuadores. Este sistema coleta informações do meio físico por intermédio
de sensores, os quais fornecem informações a algoritmos que determinam ações para os
atuadores. A linha pontilhada na Figura 4.1 determina a fronteira entre as grandes áreas da
ciência envolvidas na Robótica. A Mecânica concentrando-se no canto superior esquerdo,
a Computação no canto inferior direito e a Eletrônica na fronteira entre essas duas áreas.
Estas três áreas possuem seus respectivos papéis na Robótica, com igual peso, já que uma
boa mecânica não tem valor sem uma eletrônica adequada, assim como um bom algoritmo
não pode ser colocado em prática em um sistema mecânico ruim. Neste ponto, a simulação
tem seu valor como ferramenta para elaborar bons algoritmos sem vínculo direto com a
plataforma mecatrônica.
Figura 4.1: Sistema Mecatrônico [Rosário 2005].
4.1.1 Sistema Mecânico
Segundo [Rosário 2005], o sistema mecânico é concebido por meio dos conhecimentos
básicos de engenharia mecânica, como cinemática, dinâmica, resistência de materiais
e ciência de materiais. O sistema mecânico deste projeto é definido a partir de suas
necessidades definindo formas geométricas e como estas formas interagem entre si e
24
com o meio onde o projeto estará inserido, assim como o material empregado em cada
componente, considerando seus aspectos estruturais, físico e químicos.
4.1.2 Atuadores e Sensores
Antes de definir o que é um atuador ou um sensor, se faz necessário definir o que é um
transdutor. Um transdutor, neste contexto, é um elemento que converte um tipo de energia
em outro. Pode-se citar como exemplo, um dispositivo que transforma energia térmica em
energia elétrica, da mesma forma que a transformação de energia mecânica em elétrica, a
energia elétrica em mecânica, etc. Um sensor pode ser definido como o conjunto de um ou
mais transdutores que, utilizando esta característica de transformação, obtém informações
térmicas, magnéticas, mecânicas, químicas, etc. e as transformam em sinais elétricos.
A escolha do tipo de sensor está diretamente ligada ao tipo de grandeza física a ser
medida, além do tipo de resposta deste sensor. Estas respostas podem ser analógicas,
digitais ou binárias [Rosário 2005]. A analógica está em uma faixa de valores, onde há
uma relação não discreta entre o valor elétrico e o valor correspondente da grandeza que
é medida. A resposta digital é aquela onde os valores são discretos, ou seja, uma quantidade
de possíveis valores finitos. Uma analogia entre respostas analógicas e digitais pode ser feita
à números reais e inteiros. Por fim, a resposta binária é aquela definida entre dois valores
possíveis, o 0 e o 1.
A escolha do sensor apropriado para cada sistema projetado é determinado também pela
precisão, resolução, escala e confiabilidade requerida pela aplicação. A precisão representa
o quanto a informação fornecida pelo sensor é divergente do valor real da grandeza medida.
A resolução, que está intimamente ligada ao tipo de resposta do sensor, determina a
quantidade de valores da grandeza que podem ser identificados unicamente. A escala
representa o domínio de valores da grandeza a ser medida. Finalmente, a confiabilidade
atesta todas estas características.
Tomando como base a idéia do transdutor, o atuador converte um sinal em um
movimento, ou seja, transforma um tipo de energia em outro. De forma mais restrita, na
mecatrônica os atuadores convertem energia elétrica em movimento mecânico. Mesmo em
sistemas onde tem-se atuadores hidráulicos/pneumáticos (converte a força de um fluído em
um movimento), existe a ação de atuadores elétricos para direcionar estes fluídos.
No contexto da mecatrônica, a evolução destes elementos afim de torná-los mais
acessíveis e modulares, surgem os servomecanismos que agregam atuadores, sensores,
sistemas mecânicos e eletrônicos. O conceito do servomecanismo é agregar estes elementos
simplificando a modelagem mecânica e eletrônica, através da associação destas tecnologias
criando uma espécie de "serviço", ou seja, não importa o que acontece em seu interior, basta
saber que o movimento ordenado foi executado. A Figura 4.2 mostra um servomecanismo
típico, onde encontra-se um motor, um sensor de ângulo de rotação e um conjunto de
engrenagens para redução de velocidade/aumento de potência.
25
Figura 4.2: Servomecanismo [Servomecanismo 2010].
Para utilizar este tipo de servomecanismo, basta fornecer uma tensão elétrica para
alimentar os circuitos e o motor. Através de um sinal digital, o ângulo de rotação desejado é
informado ao servomecanismo. Este sistema se encarrega de posicionar seu eixo na posição
informada, assim como mantê-lo nesta posição mesmo que seu eixo seja deslocado para
outra posição por uma força externa.
4.1.3 Elementos de Computação na Mecatrônica
Utilizando a definição formal de computação como base, onde o problema envolve as
entradas, os algoritmos e as saídas. No contexto do sistema mecatrônico, a computação
toma como entrada a leitura de seus sensores e como saída a ação de seus atuadores.
A Figura 4.3 mostra a interação entre estes elementos, assim como a realimentação, que
consiste na avaliação do resultado instantâneo da ação dos atuadores permitindo a correção
e/ou validação do movimento desejado, presente na maioria dos sistemas robóticos.
Figura 4.3: Sistema Computacional no Contexto Mecatrônico.
Considerando um nível de abstração mais alto, a função da computação no sistema
mecatrônico é a tomada de decisão, ou seja, qual a decisão que deve ser tomada para
atingir um determinado objetivo. Várias abordagens podem ser consideradas, por exemplo
4.2. Simulação Robótica
26
sistemas especialistas, aprendizado de máquina, algoritmos de busca, redes neurais
artificiais, entre outras.
A implementação deste aparato computacional pode ser realizada através da eletrônica
analógica/digital pura, eletrônica digital reconfigurável ou sistemas baseados em software.
A eletrônica analógica/digital é utilizada em sistemas mais simples, onde a função é bem
definida. A eletrônica digital reconfigurável é utilizada para a criação de protótipos onde o
grau de complexidade é maior em sistemas dedicados. Os sistemas baseados em software
permitem a criação de sistemas com alto grau de complexidade em sistemas dedicados ou
não facilitando a interação com outros sistemas computacionais. Uma forma de determinar
qual abordagem deve ser utilizada é avaliar o quanto e de que forma a informação recebida
na entrada do sistema é manipulada e considerada para determinar a saída.
4.2 Simulação Robótica
O uso de simuladores na Robótica ocorre em dois momentos: no projeto mecânico, com
o uso de softwares CAD/CAM
1
e na simulação do software que mostra a movimentação
a mecânica. Em cada estágio, diferentes aspectos são avaliados e seus resultados podem
modificar o projeto mecânico ou a concepção do software. A simulação mecânica utiliza as
teorias da Física Estática, Dinâmica, Resistência de Materiais, Mecânica de Fluídos, entre
outras para avaliar se o design mecânico responde aos requisitos do projeto, definindo
também a modelagem do software de acordo com seus resultados. Este processo utiliza na
maioria dos casos uma abordagem puramente analítica. Neste tipo de simulação é possível
utilizar os recursos de CAM para a manufatura das peças utilizadas na montagem do robô.
A Figura 4.4 mostra um braço robótico para uso industrial em um simulador dedicado.
Figura 4.4: Simulação do Projeto Mecânico de um Braço Robótico [RobotMaster 2010].
1 Acrônimo de Computer Aided Desing - Projeto Assistido por Computador e Computer Aided Manufacturing -
Fabricação Assistida por Computador.
4.3. Validação Robótica
27
Na simulação do software, o uso de frameworks específicos permitem a criação de um
modelo tridimensional abstrato do projeto mecânico que permite avaliar o comportamento
do software sob vários cenários. Um exemplo ilustrado na Figura 4.5 é o MoRoS3D [Colon,
Sahli e Baudoin 2006] que é um framework para simulação voltado para a Robótica baseado
no padrão CORBA2 .
Figura 4.5: Simulação de um Robô em em Ambiente Externo [Colon, Sahli e Baudoin 2006].
4.3 Validação Robótica
A validação na área robótica acontece durante o processo de implementação do
robô, sendo que a simulação em muitos casos é apenas utilizada como ferramenta de
desenvolvimento.
Algumas técnicas discutidas na seção 3.2.3 são aplicadas de forma
isolada na robótica, com destaque para os métodos gráficos e de animação. Em [Lamon
e Siegwart 2007] tem-se o exemplo do robô SOLERO, direcionado à deslocamentos em
terrenos altamente acidentados, a mecânica deste robô é o ponto chave do projeto. As
Figuras 4.6 e 4.7 mostram a simulação do projeto mecânico e os experimentos realizados
com um modelo em menor escala deste robô, respectivamente.
2 CORBA (Common Object Request Broker Architecture) é um modelo de arquitetura distribuída para middleware,
visando garantir interoperabilidade em ambientes heterogêneos [Common Object Request Broker Architecture 2010].
28
Figura 4.6: Simulação do Robô SOLERO [Lamon e Siegwart 2007].
Figura 4.7: Versão em Escala Reduzida do Robô SOLERO Usado em Testes Práticos [Lamon e Siegwart
2007].
Outro exemplo de validação gráfica é visto em [Woo et al. 2007], onde o design é
avaliado analiticamente e comparado graficamente com o protótipo real. As Figuras 4.8 e
4.9 mostram a simulação analítica e o protótipo em ação, respectivamente.
29
Figura 4.8: Simulação Analítica [Woo et al. 2007].
Figura 4.9: Protótipo Reproduzindo o Movimento Simulado [Woo et al. 2007].
4.3.1 Multiagentes Robóticos
A união das áreas de Simulação Multiagentes e a Robótica deu origem a uma nova
área de estudo conhecida como Swarm Robotics [Swarm Robotics 2010]. Utilizando a
mesma filosofia do projeto Swarm, a idéia central é a construção de robôs em grande
número utilizando o conceito bottom-up para modelar os seus comportamentos. Dentre
as muitas iniciativas de implementação deste conceito, a Figura 4.10 mostra o robô
30
idealizado pelo grupo SwarmRobo [SwarmRobot 2010], com o conceito de um robô com
o tamanho e características adequadas para a implementação deste tipo de estudo, além de
ser desenvolvido dentro da filosofia de código aberto, disponibilizando as especificações,
software, know-how, etc.
Figura 4.10: Protótipos do Robô para Swarm Robotic Desenvolvidos por [SwarmRobot 2010].
O projeto [Swarm-Bot 2010] além do desenvolvimento do robô utilizado em suas
pesquisas também foi desenvolvido um simulador dedicado para plataforma robótica. A
Figura 4.11 mostra uma imagem do simulador e dos robôs em ação em um dos estudos
realizados em [Mondada et al. 2005] onde o deslocamento de objetos pesados é realizado
pela associação de vários robôs menores com o intuito de aumentar a força resultante.
(a)
(b)
Figura 4.11: (a)Simulador para a Plataforma Swarm-Bot. (b) Aplicação Utilizando os Robôs Reais
[Mondada et al. 2005].
CAPÍTULO
5
VALIDAÇÃO EM S IMULAÇÃO M ULTIAGENTES : U M
E STUDO DE C ASO NA P LATAFORMA S WARM
A sabedoria torna bons os homens. A simulação da sabedoria torna-os
péssimos.
—– Juan Luis Vives.
Neste capítulo tem-se a apresentação de diversas plataformas de simulação multiagentes
com ênfase na plataforma Swarm, que serve de base no processo de integração entre
simulação virtual e robótica deste projeto. A escolha de uma plataforma deve se basear
em itens tais como: especificidade do modelo, exigência de desempenho, escalabilidade e a
relação custo/benefício. Outro fator visto no Capítulo 2 é o uso de linguagens específicas
de simulação como fator de redução considerável na quantidade de erros na fase de
implementação [Sargent 1999].
5.1 Plataformas de Simulação
Entre as muitas opções de plataformas disponíveis, entre as mais utilizadas e citadas
na literatura tem-se: STARLOGO [OpenStarLogo 2010], AGENTSHEETS [AgentSheets,
Inc. 2010], CORMAS [CORMAS 2010], BREVE [Breve 2010], ORGAHEAD [OrgAhead - A
Simulation of Organizational Adaptation 2010], REPAST [Repast - Recursive Porous Agent
Simulation Toolkit 2010], ASCAPE [Ascape 2010], NETLOGO [NetLogo 2010] e Swarm [Swarm
Development Group 2010]. A seguir é feita uma breve apresentação das plataformas REPAST,
ASCAPE e NETLOGO. Uma atenção maior será dispensada à plataforma Swarm, utilizada na
implementação deste projeto.
31
5.1. Plataformas de Simulação
32
5.1.1 Plataforma Repast
O Repast (Recursiv Porus Agent Simulation Toolkit) [Repast - Recursive Porous Agent
Simulation Toolkit 2010] é um ambiente de simulação baseado em agentes que utiliza
muitos dos conceitos utilizados no Swarm, diferindo deste por estar disponível em
várias plataformas, em vários idiomas, além de características como regreções lineares
e algoritmos genéticos. Criado na Universidade de Chicago por [Collier, Howe e North
2003], atualmente é mantido por organizações sem fins lucrativos e agências de fomento de
pesquisas científicas. Além de permitir o desenvolvimento de um modelo em linguagens
como Java, C#, C++, Visual Basic.Net, Lisp, Prolog e Python, pode-se citar os seguintes
recursos:
• Uma variedade de modelos de agentes e exemplos. Além disso, oferece aos usuários
total flexibilidade para especificar as propriedades e comportamentos dos agentes;
• Orientada a objetos;
• Possui um scheduler que suporta operações seqüenciais e paralelas a eventos discretos;
• Oferece ferramentas gráficas para geração de logs;
• Framework para simulação de Monte Carlo;
• Oferece uma gama de ambientes bi-dimensionais para visualização de agentes;
• Permite aos usuários acessar e modificar dinamicamente as propriedades dos agentes,
comportamentos e propriedades do modelo em tempo de execução;
• Inclui bibliotecas de algoritmos genéticos, redes neurais, geração de números
aleatórios, etc.;
• Está disponível em praticamente todas as plataformas modernas, incluindo Windows,
Mac OS e Linux. Há também suporte a computadores de alto desempenho e clusters.
O Repast também conta com assistentes interativos integrados ao IDE Eclipse onde
é possível criar agentes e ambientes, assim como especificar suas ações e propriedades
utilizando um ambiente gráfico intuitivo.
33
Figura 5.1: Assistente para Criação de um Agente.
A Figura 5.1 mostra o assistente para criação de agentes, onde o usuário é guiado passo
a passo neste processo. Na Figura 5.2 tem-se o ambiente de programação gráfico, onde
as várias características do modelo conceitual do agente são traduzidas para o formato do
REPAST. A Figura 5.3 mostra a execução de uma simulação do modelo presa/predador nesta
plataforma.
Figura 5.2: Edição das Ações do Novo Agente Através de Blocos Gráficos.
34
Figura 5.3: Exemplo de Simulação sendo Executada: Modelo Presa/Predador [Repast - Recursive
Porous Agent Simulation Toolkit 2010].
Em [Altaweel, Alessa e Kliskey 2010] é proposto um modelo conceitual utilizando a
plataforma REPAST que mostra como as decisões tomadas em pequenas propriedades rurais
influenciam o acesso a água potável.
5.1.2 Plataforma Ascape
Segundo [Parker 2001], Ascape é um framework para simulação multiagentes muito
semelhante a outras ferramentas de modelagem disponíveis. As suas principais diretrizes
de desenvolvimento são:
• Possibilidade de definir um modelo completo usando a menor descrição possível;
• A descrição do modelo deve ser generalizada para que as mesmas idéias básicas de
modelagem possam ser testadas em diferentes ambientes e configurações;
• Permitir a interação com o modelo sem programação, mas permitir modelar diversos
modelos de sistemas complexos;
• Permitir sintetizar idéias e metodologias de modelagem no nível mais alto possível.
Com um projeto bastante maduro, o Ascape fornece uma série de ferramentas para
permitir que não-programadores possam interagir significativamente com os modelos.
Os usuários têm controle amplo sobre a visualização do modelo, o comportamento e a
dinâmica do mesmo.
35
Figura 5.4: Ambiente de Simulação Típico [Parker 2001].
O Ascape é desenvolvido em Java e pode ser integrado ao IDE Eclipse, mas sem contar
com os recursos de assistentes como a plataforma Repast. O modelo conceitual deve ser
implementado a princípio também na linguagem Java. Uma das implementações do estudo
da sociedade Anasazi em [Janssen 2009] utiliza o Ascape com o objetivo de replicar os
dados arqueológicos obtidos com o uso de simulações multiagentes. A Figura 5.5 ilustra
a representação da região na simulação.
Figura 5.5: Representação do Solo da Região de Long House Valley, no Arizona entre os Anos 800 e
1350 [Altaweel, Alessa e Kliskey 2010].
5.1.3 Plataforma NetLogo
O NetLogo é um ambiente para simulação multiagentes baseado na linguagem de
programação LOGO, que é um paradigma funcional de programação derivado do Lisp.
Além da linguagem LOGO, esta plataforma possui extensões próprias voltadas à simulação
multiagentes, bem como uma API para utilizar extensões escritas em Java.
36
Além de
implementar as simulações com visualização em 2D e 3D, a plataforma permite a criação
de interfaces com o usuário através de botões, caixas de texto, etc. Outra funcionalidade é
a possibilidade de exportar a simulação como um applet 1 , tornando a simulação disponível
através de páginas web. Criado por Uri Wilensky, hoje é desenvolvido e mantido pelo
CCL (Center for Connected Learning and Computer-Based Modeling System) na universidade
Northwestern. Em [NetLogo AIDS model 1997] há um modelo que simula a propagação do
vírus HIV, através de transmissão sexual em uma pequena população isolada. A Figura 5.6
mostra a execução desta simulação em um navegador.
Figura 5.6: Applet da Simulação de Propagação do Virus HIV no NetLogo [NetLogo AIDS model 1997].
Em [Filatova, Parker e Veen] um modelo conceitual de mercado imobiliário é proposto.
Outro exemplo é a implementação do problema clássico da computação conhecido como
"Jantar dos Filósofos"ilustrado na Figura 5.7 sobre concorrência e compartilhamento de
recursos.
1 De acordo com [Deitel e Deitel 2005] applets são programas Java que podem ser incorporados a documentos HTTP.
Quando o navegador carrega a página em questão, o aplicativo é executado no navegador.
5.2. Swarm
37
Figura 5.7: Applet da Simulação do Jantar dos Filósofos em NetLogo [NetLogo Dining Philosophers
model. 2003].
5.2 Swarm
Criado em 1994 no Santa Fe Institute, EUA por Christopher Langton em conjunto com
outros pesquisadores, hoje sobre o controle do Swarm Development Group (SDG) que no
contexto do projeto Swarm, tem como principais objetivos [Santos 2007]:
• Avançar as simulações baseadas em sistemas multiagentes, objetivando continuar o
avanço da plataforma e auxiliar os usuários deste sistema;
• Propor uma troca livre entre os desenvolvedores das simulações multiagentes e os
usuários pelo mundo;
• Manter e desenvolver a competência dos desenvolvedores das simulações baseadas
em agentes utilizando esta plataforma.
Desenvolvido na linguagem Objective C mas com uma interface para Java, o Swarm
possui uma boa variedade de recursos para o desenvolvedor de simulações multiagentes
como gerenciamento de memória, escalonamento de ações, geração de gráficos, interferência
em tempo de execução, etc.
O temo Swarm pode ser descrito como um tipo de comportamento animal caracterizado
pela união de muitos elementos similares que comportam-se como um organismos maior,
como um cardume ou um enxame de abelhas. Este tipo de comportamento é caracterizado
por flexibilidade (exemplo: uma colônia de insetos se adapta às constantes mudanças
5.2. Swarm
38
no ambiente), robustez (as tarefas são realizadas apesar da possível perda ou falha de
membros do grupo), descentralização (não existe um controle central em uma colônia)
e auto-organização (insetos dentro de uma colônia se auto-organizam para chegar a um
objetivo).
Seguindo esta filosofia, o projeto Swarm foi desenvolvido de forma a reproduzir estas
características e conceitos.
Utilizando o paradigma orientado a objeto, a modelagem
dos agentes como objetos, com características e ações reativas, mostra-se eficaz na
representação deste indivíduos. A Tabela 5.1 mostra uma analogia entre as características
definidas no modelo conceitual e sua equivalência na modelagem orientada à objeto no
Swarm. Outra característica desta plataforma é a criação de modelos hierárquicos, ou seja,
é possível criar simulações multiagentes onde os agentes são simulações multiagentes ,
possibilitando a criação de sistemas com um nível muito maior de complexidade.
Ítem Modelado
Equivalente em Swarm
Agente (exemplo: uma bactéria)
Objeto Bacilo
Estado (volume da bactéria)
Atributos de instância: int vol
Comportamentos (metabolismo)
Métodos: Bacilo.metabolize()
Ambiente (substrado da cultura)
Variáveis e Objetos Globais
Tabela 5.1: Comparativo entre características do modelo conceitual e a modelagem orientada a
objetos do Swarm [A tutorial introduction to Swarm 2000].
5.2.1 Arquitetura
A arquitetura básica de uma simulação em Swarm é composta de um ModelSwarm,
um ObserverSwarm e, opcionalmente, podem ser definidos Probes para a simulação. O
ModelSwarm contém a implementação do modelo conceitual, contendo o Swarm principal
e, opcionalmente, sub-Swarms. Nesta arquitetura são definidos os agentes, ativos e passivos,
suas estruturas e funcionalidades e o ambiente de suas influências. O ObserverSwarm é
responsável pela coleta de dados da simulação e consequente apresentação dos mesmos
via gráficos, animações, arquivos, etc. Finalmente, os Probes podem ser implementados
para interagir com a simulação através da modificação e observação de valores de variáveis,
estados de agentes, etc. A Figura 5.8 mostra a arquitetura básica de uma simulação em
Swarm.
5.2. Swarm
39
Figura 5.8: Arquitetura Básica de uma Simulação Swarm.
Outro elemento essencial para uma simulação na plataforma Swarm é o Schedule ou
escalonador. Ele é responsável por gerar o sincronismo entre as ações dos agentes de cada
swarm que constitui o modelo conceitual. Pode haver apenas um único escalonador, no caso
de um único swarm, ou multiplos escalonadores, um para cada sub-swarm que constitui o
modelo.
Para o desenvolvimento e implementação da simulação, o ambiente Swarm coloca a
disposição um conjunto de ferramentas, classes e bibliotecas pra uso do desenvolvedor. A
Figura 5.9 mostra os grupos de bibliotecas disponíveis na plataforma.
Figura 5.9: Bibliotecas da Plataforma Swarm.
II Modelagem Conceitual e Computacional
40
CAPÍTULO
6
M ODELO C ONCEITUAL : A RQUITETURA DE
I NTEGRAÇÃO DOS M UNDOS V IRTUAL E R EAL
O mais importante não é a Arquitetura, mas a vida, os amigos e este
mundo injusto que devemos modificar.
—– Oscar Niemeyer.
Neste capítulo tem-se a apresentação da arquitetura do modelo conceitual em níveis
decrescentes de abstração.
6.1 Estrutura da Proposta
As simulações são, de uma forma geral, avaliadas isoladas de seu mundo modelado,
criando uma fronteira entre os resultados de simulação e o que de fato ocorre na realidade.
De forma geral, em trabalhos encontrados na literatura, a validação dos resultados de
simulações são feitas utilizando técnicas apresentadas no Capítulo 3. A proposta deste
projeto é criar uma ligação entre a simulação e o objeto de estudo, utilizando os dados
obtidos nesta abordagem para aprimorar a simulação e, possivelmente, contribuir no
processo de validação da mesma. A Figura 6.1 mostra uma visão macro desta proposta.
41
6.2. Definição dos Componentes
42
Figura 6.1: Diagrama Conceitual da Proposta de Interligação entre os Mundos Virtual e Real.
Dentro do contexto da simulação do Robô Explorador, visto mais a frente na Seção 7.1, os
elementos da proposta deste projeto são traduzidos como mostra a Figura 6.2. Aqui tem-se a
simulação virtual multiagentes traduzida na simulação dos robôs explorando um labirinto.
No mundo real tem-se o labirinto físico, com paredes reais, onde os robôs reais fazem sua
exploração. A definição de um middleware, traduzindo o mecanismo de ligação, realiza a
comunicação entre a simulação e os robôs.
Figura 6.2: Modelo Conceitual para a Simulação do Robô Explorador.
6.2 Definição dos Componentes
Considerando a arquitetura proposta na Figura 6.2, pode-se definir os componentes
envolvidos na simulação e seus respectivos papéis:
• Ambiente Virtual;
• Agente Virtual;
• Ambiente Real;
43
• Agente Real;
• Middleware de Comunicação.
Ambiente Virtual
É o labirinto virtual. Este elemento deve representar uma abstração do ambiente real,
ou seja, o labirinto, de forma adequada. Seus caminhos devem ser iguais, assim como suas
proporções, para que a discretização realizada na simulação corresponda o mais próximo
possível ao mundo real. Como exemplo, se a cada passo o robô anda 10 cm, no ambiente
virtual cada célula representa 10 cm do ambiente real. Por outro lado, os mesmos elementos
detectados pelos sensores no ambiente real devem ser detectados da mesma forma no
ambiente virtual.
Agente Virtual
É o agente da simulação, ou seja, um objeto computacional com todas as ações, reações
e características do modelo conceitual.
Ambiente Real
É o labirinto físico.
Neste elemento as informações relevantes são dimensionais,
considerando suas dimensões físicas, proporções, adequação ao robô, ou seja, suas
dimensões permitem que o robô percorra seu interior e possa realizar as manobras
necessárias para mudanças de direção. Para tanto alguns itens devem ser considerados,
como por exemplo a altura das paredes que deve ser suficiente para que o robô possa efetuar
a leitura correta com seus sensores.
Agente Real
É o robô desenvolvido em uma plataforma robótica. Deve possuir capacidade motora
adequada para percorrer o labirinto e detectar as paredes do mesmo. Sua velocidade e
capacidade de manobra devem ser adequadas para que seu movimento seja o mais preciso
possível, evitando assim discrepância entre o movimento do agente virtual e do agente
real. Vale ressaltar que esta recomendação pode representar um elemento de avaliação no
processo de validação, já que distúrbios deste tipo não previstos podem ser considerados
como uma falha na modelagem da simulação.
Middleware de Comunicação
Corresponde à composição entre software/hardware necessária para interligar a simulação
com os agentes reais.
Aqui são definidos protocolos, estruturas de dados, formas de
interação entre os agentes, etc. Pode-se dividir este elemento em dois componentes básicos:
a interface real, hospedado pelo agente real e responsável por receber e enviar dados
de/para a simulação. E a interface virtual, hospedada na simulação e responsável pelo
44
envio e recebimento das informações para a interface real. Entre estas interfaces, definise o protocolo da comunicação, além é claro do meio pelo qual esta comunicação ocorre.
6.2.1 Protocolo de Comunicação
A arquitetura descrita até este ponto exige a definição de um protocolo de comunicação
entre o ambiente computacional e o ambiente robótico, determinando assim a arquitetura
do agente robótico.
Figura 6.3: Middleware e seus Elementos.
Na Figura 6.3 tem-se os elementos básicos que constituem o middleware responsável por
implementar este protocolo e realizar a interface entre o mundo virtual e o mundo real. A
interface virtual é responsável por receber os comandos do ambiente simulado, traduzindo
estes para o protocolo de comunicação e enviar para o agente real. Além disso, como tratase de um protocolo bi-direcional, este elemento é responsável por receber as informações
enviadas pela interface do real através do protocolo e traduzi-las para o mundo virtual.
A interface real é responsável por receber os comandos, originados na simulação e
enviados pela interface virtual através do protocolo de comunicação, e traduzir estes
comandos em ações para o agente real. Da mesma forma que a interface virtual, a interface
real recebe dados do agente real que são traduzidos para o protocolo de comunicação
enviando as mesmas para o ambiente virtual.
45
Figura 6.4: Diagrama da Arquitetura Geral do Middleware.
A Figura 6.4 ilustra o diagrama geral do middleware, com o fluxo de dados através das
interfaces real e virtual, assim como a sua posição lógica no ambiente virtual e no agente
real.
Interface Virtual
Pode-se observar na Figura 6.4 pelos passos de 1 à 3 que após a tomada de decisão por
parte do agente na simulação começa o processo de comunicação com o mundo real. O
próximo passo é traduzir esta ação em comandos dentro da especificação do protocolo de
comunicação. Em seguida os dados são enviados para o agente real através de um meio
qualquer - neste momento a interface virtual entra em um estado de espera pela resposta do
agente real. Após a execução das ações do robô, o controle retorna à interface do sistema
virtual no passo 10, onde ocorre a recepção dos dados do mundo real. No passo 11, é
feita a tradução desta resposta para que o ambiente virtual seja atualizado com estes dados.
Finalmente o controle é devolvido à simulação.
Interface Real
A Figura 6.4 mostra no passo 4 a interface real em um estado de espera por comandos
do mundo virtual. Estes comandos são traduzidos em ações para o agente real no passo 5 e
são executadas pelo mesmo no passo 6. Em seguida o ambiente real é avaliado pelo agente
real e estes dados são traduzidos para o protocolo de comunicação nos passos 7 e 8, sendo
46
enviados ao ambiente virtual na seqüência. Finalmente o agente real volta ao estado de
espera, aguardando um novo comando.
Sincronismo da Simulação com o Mundo Real
O sincronismo da simulação com o mundo real é definido nos passos 4 e 10, quando há
uma espera do ambiente real quando o ambiente virtual está em execução, e uma espera do
ambiente virtual quando o real está em execução, respectivamente.
CAPÍTULO
7
M ODELO C OMPUTACIONAL E A NÁLISE DE D ADOS
A criação prossegue incessantemente por meio do homem, mas o
homem não cria: descobre.
—– Antonio Gaudi.
Neste capítulo tem-se a apresentação da simulação escolhida para implementar a
proposta deste projeto, a implementação do modelo conceitual na plataforma Swarm, a
interface entre a simulação e o mundo real e a implementação utilizando a plataforma
robótica LEGO Mindstorms.
Finalmente, tem-se a demonstração e análise dos dados
fornecidos pela implementação.
7.1 A Simulação do Robô Explorador
A resolução de problemas de busca representa um vasto campo de pesquisa em IA, assim
como a sua influência na Robótica. O deslocamento, reconhecimento e planejamento dos
movimentos em um ambiente desconhecido permite que dispositivos autônomos possam
realizar suas funções em ambientes dinâmicos. Esta relação entre a IA e a Robótica, assim
como as diferentes influências que ambientes virtuais e reais podem ter sobre este sistema,
levou a escolha da simulação do Robô Explorador a ser validado no mundo real.
7.1.1 Objetivo da Simulação
Em um ambiente desconhecido, um labirinto ou uma sala com algumas paredes
divisórias e um grupo de robôs que compartilham sua informações criando uma memória
coletiva, busca-se mapear o ambiente na intenção de encontrar a saída. Além de detectar e
47
7.1. A Simulação do Robô Explorador
48
mapear as paredes, os robôs devem evitar trafegar em locais já conhecidos, evitar choques,
bem como determinar o melhor trajeto até à saída.
7.1.2 Modelo Conceitual
Em [Lee et al. 2008] é implementado um modelo simulado de robô explorador utilizando
a plataforma Swarm, onde vários agentes independentes constroem seus próprios mapas
através de um sistema de visão computacional simulado. A idéia em [Lee et al. 2008] é
utilizar tecnologias como visão computacional, busca de caminhos, criação de mapas, etc.
Partindo desta idéia, o robô explorador proposto neste trabalho é uma simulação em um
ambiente discreto com paredes e uma saída, a qual é o objetivo do agente. As premissas
para a criação do modelo conceitual são as seguintes:
• O agente está simulando um robô e, portanto, deve considerar suas características e
limitações;
• O robô possui quatro sensores que podem identificar obstáculos: frente, traz, direita e
esquerda;
• As paredes são detectadas por estes sensores e imediatamente adicionadas ao mapa;
• O mapa é compartilhado por todos os robôs, ou seja, todos contribuem para a
formação do mesmo;
• O mapa é confiável, ou seja, a informação fornecida por todos os robôs é real;
• Caminhos já percorridos devem ser evitados. Caminhos desconhecidos são priorizados;
• Quando há informação suficiente para encontrar a saída, algoritmos mais eficientes
devem ser utilizados.
O Ambiente e o Mapa
A Figura 7.1 mostra um exemplo de ambiente utilizado na simulação proposta neste
trabalho. Este ambiente pode ser personalizado através de um arquivo de texto que contém
seu desenho. No início da simulação este ambiente é carregado pelo programa e exibido e
os robôs são distribuídos aleatoriamente.
49
Figura 7.1: Ambiente Exemplo. Estão Identificados os Robôs, Paredes e a Saída.
O mapa é uma representação bi-dimensional implementada utilizando uma estrutura
de dados do Swarm conhecida como Discrete2dImpl, um tipo de matriz onde cada posição
contém um número inteiro. O significado deste número é determinado pelo seguinte
padrão:
0 - Sem informação, representada no mapa pela cor branca;
1 - Parede identificada, representada no mapa pela cor preta;
2 - Área livre identificada - caminho ou passagem, identificada no mapa pela cor azul;
3 a 15 - Caminho percorrido, incrementado a cada passagem, identificada por tons de verde
mais claros a cada passagem;
50 - Saída identificada pela cor vermelha.
A Figura 7.2(a) mostra o mapa no início da simulação. A Figura 7.2(b) mostra o mapa
após a conclusão da simulação onde os robôs encontraram a saída.
(a)
(b)
Figura 7.2: (a) Mapa na Memória no Início da Simulação. (b) O Mesmo Mapa ao Término da
Simulação.
50
O Agente Robô Virtual
Representado no ambiente simulado por um ponto azul. Seguindo as especificações
do modelo, é capaz de movimentar-se nas quatro direções e detectar os obstáculos nestas
direções. A cada movimento, o mesmo avalia a informação de seus sensores e seu último
movimento para determinar o seu próximo passo. Em primeiro lugar o agente verifica
em quais direções é possível movimentar-se, detectando paredes e outros agentes. Estas
informações são incluídas no mapa, informando onde há paredes e onde há espaços livres.
Com estas informações, o agente faz as seguintes inferências:
• A posição que possui uma parede é descartada imediatamente da lista de possíveis
movimentos;
• Se há um outro agente em alguma posição da lista, esta também é descartada.
A escolha da nova posição entre as disponíveis considera, nesta ordem:
• Saída do ambiente;
• Continuidade do movimento, ou seja, se o agente está indo para direção sul, ele prefere
continuar nesta direção, considerando custoso o processo de mudança da mesma;
• Locais nunca visitados;
• Locais menos visitados.
No momento que o agente robô ocupa uma nova posição, este ponto no mapa é
incrementado para identificar que uma nova visita foi feita neste ponto.
Na próxima
inferência, por este ou outro agente, esta posição será preterida.
Algoritmo de Busca
Considerando as heurísticas discutidas até o momento, pode-se classificar o algoritmo
de busca utilizado até então como busca cega, considerado pouco eficiente. Como não
há informação de maior alcance no mapa (o robô apenas consegue detectar o que há
nas posições adjacentes à sua), não é possível aplicar algoritmos mais avançados. Além
disso a exploração e consequente mapeamento do ambiente é favorecida por algoritmos
exploratórios.
No momento em que há informação suficiente, obtida por um ou mais agentes, ligando
a posição atual do agente até à saída, o algoritmo A ∗ (lê-se A estrela) é aplicado para obter
o caminho mais curto até à saída. Este algoritmo é uma soluções muito utilizada para
encontrar o caminho mais curto em um grafo [Russell e Norvig 2004]. A otimização é
alcançada avaliando o custo para atingir o nó adjacente e o custo para todo o caminho. Desta
forma a função objetivo, que é a heurística utilizada na escolha dos nós, fica:
f (n) = g (n) + h(n)
7.2. Ligação Entre Mundo Virtual e Real
51
Onde:
g(n) é o custo para atingir o nó adjacente;
h(n) é o custo para atingir o objetivo a partir da origem;
f(n) é o custo estimado da solução de custo mais baixo passando por n.
No contexto da simulação do robô explorador, o grafo utilizado pelo algoritmo pode ser
traduzido pela discretização do ambiente. A Figura 7.3 ilustra como esta discretização é
realizada e a tradução da mesma no grafo. O custo das arestas neste grafo é igual a 1, e o
custo total do trajeto da posição atual do robô até à saída é igual ao número de células, ou
vértices visitados durante o trajeto.
Figura 7.3: Ambiente Discretizado e Traduzido em um Grafo.
7.2 Ligação Entre Mundo Virtual e Real
A arquitetura proposta no Capítulo 6 traduz-se em elementos como o labirinto físico, o
robô, a simulação e os sofwares necessários. Reduzindo um pouco mais o nível de abstração
da arquitetura exibida na Figura 6.2, na Figura 7.4 é possível observar a presença do Swarm
como ambiente de simulação, o ambiente do labirinto. Além disso, este modelo apresenta o
mapeamento entre alguns agentes da simulação e seus respectivos robôs.
7.3. Definição do Protocolo de Comunicação
52
Figura 7.4: Modelo Conceitual para a Simulação do Robô Explorador Utilizando a Plataforma Swarm
e Robôs LEGO.
7.3 Definição do Protocolo de Comunicação
No contexto da simulação do robô explorador, o protocolo da comunicação é definido
pelas mensagens que a interface real pode receber e a respectiva ação e resposta. Esta
interface responde a dois tipos de comando: deslocamento e coleta de dados. O comando de
deslocamento ocorre pelo envio de um código por parte da interface virtual que corresponde
à nova posição que deve ser assumida pelo robô, relativa ao labirinto. Os seguintes códigos
podem ser enviados:
• N - O robô deve se posicionar na célula a norte da célula atual;
• S - O robô deve se posicionar na célula a sul da célula atual;
• L - O robô deve se posicionar na célula à leste da célula atual;
• O - O robô deve se posicionar na célula à oeste da célula atual;
• E - O robô deve efetuar um giro de 90 graus no sentido anti-horário;
• D - O robô deve efetuar um giro de 90 graus no sentido horário;
• A - O robô deve realizar um deslocamento a frente na distância equivalente a uma
célula;
• R - O robô deve realizar uma varredura de seus sensores;
• F - Encerra o programa servidor no robô.
7.3. Definição do Protocolo de Comunicação
53
Após a execução de qualquer um dos comandos acima, o robô efetua a varredura de
seus sensores (identificando obstáculos ou outros elementos do ambiente real) e envia o
resultado desta varredura para a interface virtual. Para esta implementação, os valores
enviados são booleanos, ou seja, o robô envia ao para a simulação a informação se há ou
não um obstáculo em cada uma das quatro direções.
O meio de comunicação escolhido é o sinal de rádio-freqüência utilizando a tecnologia
Bluetooth, que está implementado de forma nativa no LEGO Mindstorms.
7.3.1 Interface Virtual
A interface virtual, como foi descrito no Capítulo 6, é responsável por receber os
comandos da simulação, traduzi-los para o protocolo, enviar estes comandos para o robô,
receber sua resposta e finalmente devolver à simulação as informações fornecidas pelo robô
a respeito do ambiente real. A Figura 7.5 mostra o diagrama de classe da implementação
desta interface.
Figura 7.5: Diagrama de Classe da Interface Virtual.
Durante a criação das instâncias dos agentes da simulação, os agentes reais instanciam
a classe InterfaceVirtual no caso do agente em questão ser real. O construtor da classe
recebe um conjunto de seis números separados por dois pontos, que representa o endereço
único de um dispositivo bluetooth. Este endereço é especificado em cada dispositivo que
usa a tecnologia bluetooth e é utilizado para diferenciar o robô que receberá os comandos
da interface. Ao invocar o construtor da classe, uma conexão será estabelecida entre as
interfaces permitindo a transferência de dados.
Além do construtor, esta classe possui o método Send(), que envia um caractere, ou seja,
um comando ao robô. Após enviar este caractere, o método entra em estado de espera até
receber a resposta do robô. Após receber os dados do robô, o objeto mantém uma estrutura
de dados com os dados do ambiente fornecidos pelo robô.
A Figura 7.6 mostra como a classe InterfaceVirtual é utilizada, sendo instanciada pelo
objeto do agente que representa um agente real.
7.4. O Agente Robô Real
54
Figura 7.6: Instâncias dos Objetos Agentes Virtuais e Reais Ligados à Interface Virtual.
7.4 O Agente Robô Real
Os requisitos para o robô explorador real são:
• Capacidade de deslocamento por todo o labirinto;
• Capacidade de manobra, permitindo modificar sua direção a qualquer momento;
• Dimensões adequadas permitindo que o mesmo faça suas manobras sem modificar o
ambiente;
• Sistema de sensor capaz de obter informação a respeito de obstáculos adjacentes a sua
posição atual;
• Sistema de comunicação sem fio que permita o tráfego de dados bi-direcionais;
• Controle de movimento que permita a reprodução precisa dos movimentos desejados;
• Capacidade de processamento adequada ao algoritmo utilizado.
Para a implementação do robô foi escolhida a plataforma LEGO Mindstorms, por
sua versatilidade e simplicidade, além de suprir todos os requisitos do projeto de forma
satisfatória. A Figura 7.7a ilustra a imagem do protótipo utilizado no experimento. A Figura
7.7b ilustra o desenho simplificado do robô e a identificação de seus elementos básicos.
55
(a)
(b)
Figura 7.7: (a) Protótipo Desenvolvido para o Experimento. (b) Diagrama Simplificado do Robô.
Trata-se de uma montagem padrão sugerida pelo kit LEGO Mindstorms com algumas
modificações, munido de duas rodas com movimentos independentes e um ponto de apoio
central. Além disso, possui um sensor de distância por ultra-som giratório, capaz de detectar
obstáculos ao redor do robô.
7.4.1 Especificação de Hardware
A Figura 7.8 mostra o esquema de ligações entre o controlador conhecido como NXT e os
três motores utilizados na montagem. Há também a ligação entre o sensor de distância e o
controlador.
Figura 7.8: (a) Esquema de Ligações entre o Controlador NXT e os Diversos Periféricos.
56
O dispositivo Bluetooth mostrado na Figura 7.8 é parte integrante do controlador, ou seja,
trata-se de um dispositivo interno exibido na figura de forma ilustrativa. O controlador NXT
possui três portas de saída para servomotores, sendo a porta B e a porta C utilizadas para o
deslocamento do robô e a porta A para movimentar o sensor de distância. O NXT também
possui quatro entradas para sensores, porém apenas a Entrada 1 é utilizada no protótipo.
A implementação deste agente requer a detecção de obstáculos nos quatro lados do robô:
frente, trás, direita e esquerda. Para utilizar apenas um sensor de distância para esta tarefa,
é necessário rotacionar o sensor nestas direções e efetuar uma leitura do mesmo a cada 90
graus. A Figura 7.9 ilustra a forma utilizada para implementar este sensor rotativo.
Figura 7.9: Design Utilizado para Efetuar a Leitura de Obstáculos nas Quatro Direções.
O primeiro passo é efetuar a leitura do sensor na posição inicial. Em seguida o motor A é
rotacionado em 90 graus. Uma nova leitura é feita no sensor. Uma nova rotação de 90 graus é
realizada no motor A, seguida de uma nova leitura no sensor. Uma nova rotação de 90 graus
é realizada seguida de uma última leitura no sensor. Finalmente, o motor A é rotacionado
em 270 graus negativos para que o mesmo retorne a sua posição inicial.
7.4.2 Especificação dos Movimentos
Dois movimentos básicos são implementados neste robô: rotação e deslocamento.
Entende-se como rotação a operação de girar o robô 90 graus para a esquerda ou para a
direita, em torno de seu próprio eixo. Para realizar este movimento, tanto o motor B quanto
o motor C são acionados com a mesma especificação de movimento, porém, com sentidos
de rotação contrários. O movimento resultante em cada roda tem sentido oposto, fazendo
o robô rodar em seu próprio eixo. No deslocamento, o robô desloca-se em uma trajetória
retilínea, por uma distância de 30cm que corresponde à distância entre o centro de duas
células do labirinto real - neste caso, o motor B e o motor C recebem a mesma especificação
de movimento, com o mesmo sentido. As Figuras 7.10 e 7.11 mostram a realização do
movimento de rotação e deslocamento respectivamente.
57
Figura 7.10: (a) Rotação de 90 Graus à Esquerda. (b) Rotação de 90 Graus à Direita.
Figura 7.11: Deslocamento Retilíneo de 30cm.
7.4.3 Algoritmo de Correção de Erros
O movimento realizado pelo robô é influenciado por uma grande quantidade de
variáveis, desde diferenças de fabricação de componentes eletro-mecânicos, velocidade,
até características do solo como atrito, relevo, etc. Estes erros são acumulados durante o
experimento, tornando a conclusão do mesmo uma tarefa árdua. Para reduzir a influência
destas variáveis, é necessário utilizar algoritmos para correção de erros.
58
Nesta implementação foi utilizado uma algoritmo simples, que corrige erros de
deslocamento utilizando a distância entre as paredes detectadas do labirinto. De posse da
informação de distância entre a parede lateral e o robô, o mesmo pode tomar a decisão de
afastar-se da mesma de forma leve, caso a distância não seja muito pequena, ou de forma
drástica, caso a distância entre o robô e a parede seja muito pequena. A Figura 7.12 ilustra
os tipos de erro e a Figura 7.13 mostra como o algoritmo efetua a correção.
Figura 7.12: Tipos de Erro no Posicionamento do Robô.
Figura 7.13: Seqüência de Passos da Correção de Erro.
59
7.4.4 Interface Real e o Software de Controle
A interface real, como foi descrito no Capítulo 6, é responsável por receber os comandos
enviados pela simulação e traduzi-los em ações relacionadas ao estado atual do robô. O
software de controle realiza esta ação da melhor forma possível, corrigindo o movimento
quando necessário, além de obter os dados sobre o estado do ambiente real. Finalmente
estes dados são enviados através da interface real à simulação. A Figura 7.14 mostra o
diagrama de classes da interface real e do software de controle.
Figura 7.14: Diagrama de Classes da Interface Real e Software de Controle.
A classe Bussola é uma estrutura de dados utilizada para armazenar a posição relativa
atual do robô. Os métodos Direita() e Esquerda() atualizam esta estrutura quando estes
movimentos são realizados. A classe InterfaceReal contempla não só a interface real mas
também o software de controle do robô. Além dos vários atributos utilizados por esta classe,
o método main() é responsável por realizar a configuração inicial do robô e popular as
variáveis iniciais, realizando também a conexão com a simulação e entrando no estado de
espera por comandos. Os métodos relacionados ao controle do robô são viraDireita()
e viraEsquerda(), responsáveis por realizar a manobra de giro de 90 graus no robô. O
método Anda(), responsável por realizar o deslocamento de 30cm aplicando a correção de
erro quando necessário e os métodos getSensorVal() e runRadar(), responsáveis pela
7.5. Cenário e Execução
60
realização do movimento do sensor de distância e obtenção dos valores do mesmo. A
interface real é implementada pelo método MoveTo(), que recebe o caractere enviado pela
simulação e traduz este em uma seqüência de comandos necessários para a realização do
movimento.
7.5 Cenário e Execução
A Figura 7.15b mostra o labirinto real construído para a realização do experimento. Tratase da reprodução real do labirinto mostrado na Figura 7.15a, em uma matriz de oito por oito
células. As células no labirinto real são quadrados com 30cm de lado, e as paredes também
possuem 30cm de altura, altura esta suficiente para que o sensor do robô fique abaixo desta,
tornando possível a detecção da mesma.
(a)
(b)
Figura 7.15: (a) Desenho do Labirinto Virtual Utilizado no Experimento. (b) Foto do Labirinto Real.
A Tabela 7.1 mostra os parâmetros utilizados no experimento. Alguns parâmetros são
adimensionais, como a velocidade. Como ambiente de execução para os robôs foi utilizada
a Virtual Machine LeJOS [LeJOS Team 2010], que habilita o controlador NXT a executar
programas escritos na linguagem Java.
61
Parâmetro
Valor
Dimensão das células
30cm x 30cm
Velocidade dos motores durante o deslocamento
300
Velocidade dos motores durante a rotação
250
Força aplicada nos motores de tração
100%
Rotação do sensor de distância
92◦
Rotação dos motores de tração durante o deslocamento
620◦
Rotação dos motores de tração durante o giro
180◦
Rotação dos motores de tração para correção de erro
30◦
Tabela 7.1: Parâmetros Utilizados no Experimento.
7.5.1 Reprodução de Movimentos
A reprodução dos dois tipos de movimentos básicos do robô, bem como o deslocamento
entre as células de forma equivalente entre a simulação e o labirinto real são itens críticos
para o sucesso do experimento.
A Figura 7.16 mostra a realização do movimento de
deslocamento e mudança de direção através de imagens capturadas de um vídeo do
experimento, assim como a simulação no mesmo ponto reproduzindo o movimento.
Figura 7.16: Imagens do Movimento Realizado e o Mesmo Movimento Realizado na Simulação.
A Figura 7.17 mostra o algoritmo de correção de erro corrigindo a trajetória do robô
durante a realização de um determinado movimento.
62
Figura 7.17: Imagem da Correção de Erro Durante a Realização de um Movimento.
7.5.2 Reprodução de Eventos
Alguns eventos são de grande importância para a realização deste projeto, como o caso
de um agente virtual encontrar um agente real. Esta situação é ilustrada na Figura 7.18, onde
o encontro é exibido na simulação e a imagem capturada do mundo real.
Figura 7.18: Encontro entre o Agente Real e o Virtual na Simulação e Capturado pela Câmera.
A Figura 7.19 mostra o encontro de dois agentes reais durante o experimento, mostrando
a tomada de decisão por parte deste e a conseqüente mudança de direção.
63
Figura 7.19: Encontro entre Dois Agentes Reais.
7.5.3 Simulação Completa
O cenário escolhido para o experimento foi uma simulação com quatro agentes, sendo
dois reais e dois virtuais. A Figura 7.20 e a Figura 7.21 mostram as imagens do simulador
na execução deste experimento, com imagens capturadas a cada passo da simulação(lado
direito). Em cada imagem da simulação há a imagem capturada por uma câmera do
ambiente real(lado direito). O passo da simulação é definido pelo escalonador do Swarm
e compreende o tempo entre o disparo das ações de todos os agentes até a atualização
completa do ambiente simulado.
64
Figura 7.20: Imagem da Simulação a Cada Passo - Mundo Virtual e Mundo Real - Passos de 1 a 18.
65
Figura 7.21: Imagem da Simulação a Cada Passo - Mundo Virtual e Mundo Real - Passos de 19 a 34.
III Conclusão
66
C ONCLUSÕES
O estudo das técnicas de validação descritas na literatura, considerando o estado da arte
em simulações multiagentes, mostra a necessidade da criação e formalização de métodos
rigorosos e confiáveis para atestar a validade destes modelos. A proposta apresentada
neste projeto, e sua conseqüente implementação, mostra que a ligação entre mundos real
e virtual como ferramenta não só de validação como também de aprimoramento do modelo
conceitual é válida e pode ser utilizada como parte do processo de validação em simulações
multiagentes.
A interferência de fatores físicos como atrito, inércia, limitação de materiais, etc., muitas
vezes são deixados de lado na criação de modelos conceituais, colocando em discussão a
validade destes modelos frente ao cenário real. Durante a realização desta pesquisa este
fatores surgiram e foram tratados pelos agentes reais sem a interferência da simulação,
permitindo que o modelo conceitual proposto não fosse influenciado por estes fatores,
criando uma camada de abstração onde problemas virtuais são tratados na simulação e
problemas reais são tratados pelos robôs.
Outro resultado obtido com sucesso durante os experimentos foi a interação entre
agentes virtuais e os robôs. Este resultado mostra que é possível utilizar esta proposta para
desenvolver modelos parciais onde apenas parte dos agentes reais estão disponíveis para o
estudo.
7.6 Trabalhos Futuros
Durante o desenvolvimento deste projeto de pesquisa foram identificados alguns pontos
onde é necessário um maior aprofundamento, assim como o surgimento de novos desafios,
entre os quais destaca-se:
• Criação de um modelo mais complexo de middleware, onde características mais
abrangentes possam ser contempladas;
• Associação e comparação com as técnicas clássicas de validação e o contexto da
proposta deste projeto;
• Desenvolvimento de modelos com discretizações mais complexas e menos rígidas;
• Uso de plataformas robóticas específicas, com recursos mais avançados;
67
7.6. Trabalhos Futuros
68
• Criação de novos cenários, onde a quantidade de agentes e dimensões físicas serão
colocados como desafios na integração dos mundos.
R
R EFERÊNCIAS
[A tutorial introduction to Swarm 2000]A
tutorial
introduction
to
Swarm.
[S.l.]:
Swarm Development Group - Complex Systems Summer School 2000,
2000.
Http://www.swarm.org/csss-tutorial/frames.html.
[AgentSheets, Inc. 2010]AGENTSHEETS, Inc. Agosto 2010. Http://www.agentsheets.com/.
[Altaweel, Alessa e Kliskey 2010]ALTAWEEL, M.; ALESSA, L. N.; KLISKEY, A. D. Social
influence and decision-making: Evaluating agent networks in village responses to change
in freshwater. Journal of Artificial Societies and Social Simulation, v. 13, n. 1, p. 15, 2010.
ISSN 1460-7425. Disponível em: <http://jasss.soc.surrey.ac.uk/13/1/15.html>.
[Arthur e Nance 1996]ARTHUR, J. D.; NANCE, R. E. Independent Verification and Validation:
A Missing Link in Simulation Methodology? Blacksburg, VA, USA, 1996.
[Ascape 2010]ASCAPE. Julho 2010. Http://ascape.sourceforge.net.
[Asimov]ASIMOV, I. I, Robot (a collection of short stories originally published between 1940
and 1950). [S.l.: s.n.].
[Berends e Romme 1999]BERENDS,
research
tool
in
management
P.;
ROMME,
studies.
G.
[S.l.],
Simulation
1999.
as
Disponível
a
em:
<http://ideas.repec.org/p/ner/maastr/urnnbnnlui27-19248.html>.
[Berlanga 2003]BERLANGA, R. Simulacion Informática. Blacksburg, VA, USA, 2003.
[Brenner e Werker 2004]BRENNER, T.; WERKER, C. Empirical Calibration of Simulation
Models. [S.l.], ago. 2004. Disponível em: <http://ideas.repec.org/p/sce/scecf4/89.html>.
[Breve 2010]BREVE. Agosto 2010. Http://www.spiderland.org/.
69
70
[Caughlin 2000]CAUGHLIN, D. An integrated approach to verification, validation, an
accredition of models and simulations. Winter Simulation Conference, 2000.
[Collier, Howe e North 2003]COLLIER, N.; HOWE, T.; NORTH, M. J. Onward and upward: The
transition to repast 2.0. First Annual North American Association for Computational Social
and Organizational Science Conference, 2003.
[Colon, Sahli e Baudoin 2006]COLON, E.; SAHLI, H.; BAUDOIN, Y. Moros3d, a multi mobile
robot 3d simulator. In: Proceedings of the 9th International Conference on Climbing and
Walking Robots. [S.l.: s.n.], 2006. p. 722–728.
[Common Object Request Broker Architecture 2010]COMMON
Object
Request
Broker
Architecture. Julho 2010. Http://www.omg.org/gettingstarted/history_of_corba.htm.
[Conte e Castelfranchi 1995]CONTE, R.; CASTELFRANCHI, C. Understanding the functions
of norms in social groups through simulation. In: Artificial Societies. The Computer
Simulation of Social Life. London: [s.n.], 1995.
[CORMAS 2010]CORMAS. Agosto 2010. Http://cormas.cirad.fr/indexeng.htm.
[David et al. 2004]DAVID, N. et al. The Structure and Logic of Interdisciplinary Research in
Agent-Based Social Simulation. Journal of Artificial Societies and Social Simulation, v. 7,
n. 3, 2004.
[David, Sichman e Coelho 2001]DAVID, N.; SICHMAN, J. S.; COELHO, H. Agent-based social
simulation with coalitions in social reasoning. In: Proc. 2nd. International Workshop on
Multi-Agent Based Simulation. [S.l.]: Springer-Verlag, 2001. p. 244–265.
[Deitel e Deitel 2005]DEITEL, H. M.; DEITEL, P. J. Java: Como Programar? 6a . ed. São Paulo,
Brasil: Pearson Prentice Hall, 2005.
[Dilão 1995]DILãO,
R.
A
ciência
Universidade Técnica de Lisboa,
dos
v. 1,
sistemas
n. 1,
Técnica
complexos.
p. 14,
-
1995. Disponível em:
<http://sd.ist.utl.pt/Awareness/complexos.pdf>.
[Drogoul e Ferber 1994]DROGOUL, A.; FERBER, J. Multi-agent simulation as a tool for
modeling societies: Application to social differentiation in ant colonies. In: MAAMAW ’92:
Selected papers from the 4th European Workshop on on Modelling Autonomous Agents in
a Multi-Agent World, Artificial Social Systems. London, UK: Springer-Verlag, 1994. p. 3–23.
ISBN 3-540-58266-5.
[Ferber 1996]FERBER, J. Reactive distributed artificial intelligence:
principles and
applications. John Wiley & Sons, Inc., New York, NY, USA, p. 287–314, 1996.
[Filatova, Parker e Veen]FILATOVA, T.; PARKER, D.; VEEN, A. van der. Agent-based urban
land markets: Agentś pricing behavior, land prices and urban land use change. Journal
71
of Artificial Societies and Social Simulation, v. 12, n. 1, p. 3. ISSN 1460-7425. Disponível em:
<http://jasss.soc.surrey.ac.uk/12/1/3.html>.
[França 2010]FRANçA, R. dos S. Simulação Multi-Agentes Modelando o Comportamento
Coletivo de Pânico em Multidões. Dissertação (Mestrado) — UFABC, 2010.
[Gilbert e Troitzsch 1999]GILBERT, N.; TROITZSCH, K. G. Simulation for the Social Scientist.
[S.l.]: Open University Press, 1999.
[Gou 2006]GOU, C. The simulation of financial markets by agent-based mix-game models.
Journal of Artificial Societies and Social Simulation, v. 9, n. 3, p. 6, 2006. ISSN 1460-7425.
Disponível em: <http://jasss.soc.surrey.ac.uk/9/3/6.html>.
[hadouaj, Drogoul e ESPIÉ 2001]HADOUAJ, S. E.; DROGOUL, A.; ESPIÉ, S. How to combine
reactivity and anticipation: the case of conflicts resolution in a simulated road traffic.
In: MABS 2000: Proceedings of the second international workshop on Multi-agent based
simulation. Secaucus, NJ, USA: Springer-Verlag New York, Inc., 2001. p. 82–96. ISBN 3-54041522.
[Hammersley e Handscomb 1964]HAMMERSLEY, J. M.; HANDSCOMB, D. C. Book. Monte
Carlo methods. [S.l.]: Methuen, London, 1964. 178p. p.
[Heppenstall, Evans e Birkin 2006]HEPPENSTALL, A.; EVANS, A.; BIRKIN, M. Using hybrid
agent-based systems to model spatially-influenced retail markets. Journal of Artificial
Societies and Social Simulation, v. 9, n. 3, p. 2, 2006. ISSN 1460-7425. Disponível em:
[Jacintho et al. 2010]JACINTHO, L. F. de O. et al. An agent-based model for the spread of
the dengue fever: A swarm platform simulation approach. Proceedings of the ACM Agentdirected Simulation Symposium, Orlando, USA, p. 17–24, 2010.
[Janssen 2009]JANSSEN, M. A. Understanding artificial anasazi. Journal of Artificial Societies
and Social Simulation, v. 12, n. 4, p. 13, 2009. ISSN 1460-7425. Disponível em:
[Katerelos e Koulouris 2004]KATERELOS, I. D.; KOULOURIS, A. G. Seeking equilibrium leads
to chaos: Multiple equilibria regulation model. Journal of Artificial Societies and Social
Simulation, v. 7, n. 2, 2004.
[Küppers e Lenhard 2005]KüPPERS, G.; LENHARD, J. Validation of simulation: Patterns in
the social and natural sciences. Journal of Artificial Societies and Social Simulation, v. 8, n. 4,
p. 3, 2005. ISSN 1460-7425. Disponível em: <http://jasss.soc.surrey.ac.uk/8/4/3.html>.
[Lamon e Siegwart 2007]LAMON, P.; SIEGWART, R. 3d position tracking in challenging
terrain. Int. J. Rob. Res., Sage Publications, Inc., Thousand Oaks, CA, USA, v. 26, n. 2, p.
167–186, 2007. ISSN 0278-3649.
72
[Lee et al. 2008]LEE, B.-J. et al. Pyro implementation of swarm-bots exploring target objects
in an area with irregular barriers. In: Computer and Information Technology, 2008. CIT 2008.
8th IEEE International Conference on. [S.l.: s.n.], 2008. p. 670 –675.
[LeJOS Team 2010]LEJOS Team. Novembro 2010. Http://lejos.sourceforge.net/.
[Lovelock 1992]LOVELOCK, J. E. A numerical model for biodiversity. In: Philosophical
Transactions of the Royal Society of London Vol. 338. [S.l.: s.n.], 1992. p. 383–391.
[Mondada et al. 2005]MONDADA, F. et al. Object Transport by Modular Robots that Selfassemble. 2005.
[Moss 2008]MOSS, S. Alternative approaches to the empirical validation of agent-based
models. Journal of Artificial Societies and Social Simulation, v. 11, n. 1, p. 5, 2008. ISSN
1460-7425. Disponível em: <http://jasss.soc.surrey.ac.uk/11/1/5.html>.
[NetLogo 2010]NETLOGO. Agosto 2010. Http://ccl.northwestern.edu/netlogo/.
[NetLogo AIDS model 1997]NETLOGO
AIDS
model.
Evanston,
IL:
Center
for
Connected Learning and Computer-Based Modeling, Northwestern University, 1997.
Http://ccl.northwestern.edu/netlogo/models/AIDS.
[NetLogo Dining Philosophers model. 2003]NETLOGO
model.
Evanston,
Computer-Based
IL:
Center
Modeling,
for
Dining
Connected
Northwestern
Philosophers
Learning
University,
and
2003.
Http://ccl.northwestern.edu/netlogo/models/DiningPhilosophers.
[OpenStarLogo 2010]OPENSTARLOGO. Agosto 2010. Http://education.mit.edu/starlogo/.
[OrgAhead - A Simulation of Organizational Adaptation 2010]ORGAHEAD
-
A
Simulation
of
Organizational
Adaptation.
Agosto
2010.
Http://www.casos.cs.cmu.edu/projects/OrgAhead/.
[Pahl-Wostl e Ebenhöh 2004]PAHL-WOSTL, C.; EBENHöH, E. An adaptive toolbox model:
a pluralistic modelling approach for human behaviour based on observation. Journal
of Artificial Societies and Social Simulation, v. 7, n. 1, p. 3, 2004. Disponível em:
[Parker 2001]PARKER, M. T. What is ascape and why should you care?
Journal of
Artificial Societies and Social Simulation, v. 4, n. 1, p. 5, 2001. Disponível em:
[R. e J. 1995]R., C.; J., S. Depnet: how to benefit from social dependence. Journal of
Mathematical Sociology, N°20, p. pp161–177, 1995.
[Repast - Recursive Porous Agent Simulation Toolkit 2010]REPAST - Recursive Porous Agent
Simulation Toolkit. Junho 2010. Http://repast.sourceforge.net/repast_3/index.html.
73
[Richards, Richards e Mckay 1998]RICHARDS, D.; RICHARDS, W. A.; MCKAY, B. D. Collective
choice and mutual knowledge structures. In: Advances in Complex Systems. [S.l.: s.n.], 1998.
p. 221–236.
[RoboCup Rescue World Championship and Conference 2010]ROBOCUP
Rescue
World
Championship and Conference. Julho 2010. Http://www.robocuprescue.org/.
[RoboCup World Championship and Conference 2010]ROBOCUP World Championship and
Conference. Julho 2010. Http://www.robocup.org/.
[Robotics Laboratory 2010]ROBOTICS
Laboratory.
Julho
2010.
Http://robotics.megagiant.com/history.html.
[RobotMaster 2010]ROBOTMASTER. Agosto 2010. Http://www.robotmaster.com.
[Rosário 2005]ROSáRIO, J. M. Book. Princípios de Mecatrônica. São Paulo, Brasil: Prentice
Hall, Brasil, 2005. 356p. p.
[Russell e Norvig 2004]RUSSELL, S.; NORVIG, P. Inteligência Artificial. 2a . ed. Rio de Janeiro,
Brasil: Elsevier Editora, 2004.
[S. et al. 1999]S., D. J. et al. Undertanding anasaki culture change through agent-based. In:
Modeling Small Scale Societies. [S.l.]: Oxford University Press, 1999.
[Santos 2007]SANTOS, M. V. B. Inteligência Artificial Distribuída na Simulação de Vida
Artificial. [S.l.], 2007.
[Sargent 1999]SARGENT, R. G. Validation and verification of simulation models. Winter
Simulation Conference, 1999.
[Schmid 2005]SCHMID, A. What is the truth of simulation? Journal of Artificial Societies
and Social Simulation, v. 8, n. 4, p. 5, 2005. ISSN 1460-7425. Disponível em:
[Servomecanismo 2010]SERVOMECANISMO.
Agosto
2010.
Http://www.futaba-
rc.com/servos/servos.html.
[Simulador RoboCup 2010]SIMULADOR
RoboCup.
Agosto
2010.
Http://www.ifi.uzh.ch/ailab/people/nitschke/RoboCup.html.
[Swarm-Bot 2010]SWARM-BOT. Agosto 2010. Http://www.swarm-bots.org/.
[Swarm Development Group 2010]SWARM
Development
Group.
Agosto
2010.
Http://www.swarm.org.
[Swarm Robotics 2010]SWARM Robotics. Agosto 2010. Http://www.swarm-robotics.org.
[SwarmRobot 2010]SWARMROBOT. Agosto 2010. Http://www.swarmrobot.org/.
74
[Wilcoxon 1945]WILCOXON, F. Individual comparisons by ranking methods. Biometrics
Bulletin, v. 1, n. 6, p. 80–83, 1945. Disponível em: <http://www.jstor.org/stable/3001968>.
[Windrum, Fagiolo e Moneta 2007]WINDRUM, P.; FAGIOLO, G.; MONETA, A. Empirical
validation of agent-based models:
Alternatives and prospects. Journal of Artificial
Societies and Social Simulation, v. 10, n. 2, p. 8, 2007. ISSN 1460-7425. Disponível em:
[Woo et al. 2007]WOO, C.-K. et al. Optimal design of a new wheeled mobile robot based
on a kinetic analysis of the stair climbing states. J. Intell. Robotics Syst., Kluwer Academic
Publishers, Hingham, MA, USA, v. 49, n. 4, p. 325–354, 2007. ISSN 0921-0296.

Acesso ao Trabalho - Bacharelado em Ciência da Computação

Transcrição

Documentos relacionados

Roteiro

Untitled - Conenge

utilização da realidade virtual na área de meio ambiente nas

nanostream® 6095 wide flow

Confira nosso Boletim!

Apresentação do PowerPoint

CALIBRAÇÃO E VALIDAÇÃO DO MODELO SWAT PARA A

IMPLEMENTAÇÃO DE UM ROBÔ MÓVEL PARA AUTOMAÇÃO.

Fernandes

Desenvolvimento de Um Robô Autônomo para