Simulação e Melhoramento do PiTank com Sistema de Inteligência Artificial

F

E

U

P

Simulação e Melhoramento do PiTank

com Sistema de Inteligência Artificial

Sérgio Daniel Marinho de Lima Teixeira

Mestrado Integrado em Engenharia Eletrotécnica e de Computadores Orientador: Armando Jorge Miranda de Sousa

c

Resumo

Pitank é um jogo de realidade mista (robôs controlados pelos jogadores são reais, elementos do jogo são projetados numa tela) inserido no sistema 3PiGaming desenvolvido na Faculdade de Engenharia da Universidade do Porto. É um jogo do tipo shooter cujo objetivo consiste em disparar sobre os robôs controlados pelos adversários de forma a obter a melhor pontuação em determinado intervalo de tempo. Aquando do início da elaboração desta dissertação este sistema apenas fornece a possibilidade de jogadores humanos fazerem partidas entre si. Este sistema é regularmente utilizado em eventos de carácter educativo como a Mostra da Universidade do Porto ou Universidade Júnior, pelo que é importante que seja interessante e apelativo.

Devido a existir apenas um sistema real físico do jogo, a implementação e desenvolvimento de novas funcionalidades (como o caso de IA) pode ser por vezes complicada ou demorada, pelo que foi desenvolvido e integrado no sistema existente uma componente de simulação que permite testar novos componentes do sistema e experienciar o jogo sem ser necessário recorrer ao sistema real. Foram feitos testes de forma a validar a implementação desenvolvida para o sistema em questão. Desta forma é garantida a robustez do sistema.

Relativamente à IA foi necessária a criação da possibilidade de jogos entre humanos e IA como forma de promover competitividade e aumentar a variedade de modos de jogo que tornam o jogo divertido. É ainda possível recorrendo a IA, a criação de diferentes níveis de dificuldade base e eventual dificuldade adaptativa que varia consoante diferentes estados de jogo. Foram im-plementadas e comparadas diferentes técnicas de IA com base tanto em máquinas de estado como em algoritmos de decisão derivados do algoritmo Negamax, sendo criados 4 diferentes algoritmos baseados nestas técnicas, e interpretados os resultados com base em aspetos de dificuldade e win ratio. IA com melhor desempenho foi a baseada em máquinas de estado.

Foi necessária a reformulação da arquitetura do sistema de forma a ser possível a integração tanto das funcionalidades de IA como do simulador. Foram criados novos nós ROS referentes ao simulador e IA e efetuadas as ligações necessárias entre eles e o sistema inicial.

Abstract

PiTank is a mixed reality game (several real robots controlled by several players, virtual game elements are projected onto a canvas) inserted in the 3PiGaming system developed at Faculdade de Engenharia da Universidade do Porto. It is a shooter game whose objective consists in shooting enemy robots controlled by enemy players in order to achieve the best score in a determined time. Before this dissertation was elaborated the system only permitted that human players could play against each other. This system is regularly used in educative events such as Mostra da Universidade do Porto or Universidade Júnior, so it’s important that it remains interesting and appealing.

Because there exists only a real physical system of the game, new components’ development and implementation (such as AI) can at times be very complicated or time consuming, whereby there was integrated in the existing system a simulation component which allows to easily test new system functions and even fully experiment the game without being necessary the use of the real system. Tests were made to guarantee that both real and simulated versions of the system worked with no big discrepancies between them in terms of position and robot orientation for the same plays. This allows the system robustness.

Regarding AI, it was necessary to create the possibility of games between humans and AI as a way to promote competition and increase the variety of game modes that make the game fun. It is still possible using AI, the creation of different difficulty levels, being it base difficulty or even adaptive difficulty which varies based on different game states. There were implemented and compared several AI techniques ranging from state machine implementations to Negamax algorithm, with 4 different algorithms, and the respective results were compared and analyzed based in the aspects of difficulty and win ratio. The AI with better results was based in state machines.

It was also necessary the reformulation of some of the system architecture to integrate the AI and Simulator functionalities. There were created new ROS nodes regarding AI and simulation and the necessary new connections between them and the system.

Agradecimentos

Esta dissertação é sobretudo dedicada aos meus pais que sempre me apoiaram e me forneceram suporte neste grande percurso da minha vida. Sem eles este percurso teria sido impossível.

Quero também agradecer ao meu orientador, Professor Armando Jorge Miranda de Sousa por me ter ajudado imenso na elaboração desta dissertação e me ter incentivado quando a vontade não estava presente.

Finalmente, mas não menos importante queria agradecer à minha namorada que me apoiou nos momentos mais desesperantes desta dissertação e me fez continuar e aos meus amigos com quem posso sempre contar.

Sérgio Teixeira

“Imagination is more important than knowledge. For knowledge is limited, whereas imagination embraces the entire world, stimulating progress, giving birth to evolution.”

Albert Einstein

Conteúdo

2 Estado inicial do Projeto e Estado da Arte 5 2.1 Pitank . . . 5

2.1.1 Caracterização do sistema . . . 5

2.1.2 Regras e modos de jogo . . . 6

2.1.3 Interações entre elementos . . . 7

2.2 Simuladores . . . 8

2.2.1 Gazebo . . . 8

2.2.2 V-REP . . . 9

2.2.3 ARGos . . . 10

2.3 Planeamento de Caminhos . . . 10

2.3.1 Decomposição do Mapa em Células . . . 11

2.3.2 Roadmaps. . . 12

2.3.3 Algoritmos de pesquisa . . . 14

2.3.4 Campos de Potencial . . . 16

2.4 Inteligência Artificial para Jogos . . . 16

2.4.1 Máquinas de estado finitas . . . 16

2.4.2 Minimax e Negamax . . . 17

2.4.3 Reinforcement Learning . . . 20

3 Soluções propostas para melhoramento do PiTank 21 3.1 Simulação . . . 21

3.2 Inteligência Artificial para Jogos . . . 22

3.3 Arquitetura ROS . . . 23

4 Criação do Simulador para PiTank 29 4.1 Características do 3pi . . . 29

4.2 Modelação do 3pi . . . 30

4.3 Controlo . . . 32

4.4 Validação e Resultados . . . 33

x CONTEÚDO

5 Inteligência Artificial para PiTank 41

5.1 Planeamento de Caminhos . . . 41

5.2 Máquina de estado finita . . . 47

5.3 Negamax . . . 49

5.4 Resultados . . . 50

6 Conclusão e Trabalho Futuro 53 6.1 Trabalho Futuro . . . 53

Lista de Figuras

2.1 Mapa do Jogo Pitank . . . 6

2.2 Sistema Real PiTank . . . 7

2.3 Exemplo de uma Apriltag utilizada [1] . . . 8

2.4 Diagrama dos elementos do sistema físico 3piGaming . . . 9

2.5 Representação da decomposição do mapa em células exatas [26] . . . 11

2.6 Representação da decomposição do mapa em células aproximadas de tamanho fixo [26] . . . 12

2.7 Representação da decomposição do mapa em células aproximadas de tamanho variável [26] . . . 13

2.8 Representação da decomposição do mapa Roadmaps - Visibility Graph [26] . . . 14

2.9 Representação da decomposição do mapa Roadmaps - Voronoi Diagram [26] . . 14

2.10 Exemplo de uma máquina de estados finita hierárquica [17] . . . 17

3.1 Arquitetura ROS inicial do projeto . . . 23

3.2 Nova arquitetura ROS proposta para o projeto (apenas nós e suas ligações) . . . . 24

3.3 Nova arquitetura ROS completa proposta para o projeto . . . 26

3.4 Arquitetura do sistema após mudanças . . . 27

4.1 Robô Pololu 3pi original [4] . . . 29

4.2 Robô Pololu 3pi modificado . . . 29

4.3 Vista geral do modelo produzido . . . 31

4.4 Vista lateral do modelo produzido . . . 31

4.5 Vista inferior do modelo produzido . . . 31

4.6 Comparação entre o robô Pololu 3pi modificado e o Modelo produzido . . . 32

4.7 Posição e orientação iniciais de 4 robôs no mapa de jogo e em Gazebo . . . 35

4.8 Posição e orientação iniciais de 2 robôs no mapa de jogo e em Gazebo . . . 36

4.9 Gráfico comparativo da velocidade linear em função do tempo num movimento em linha reta para a frente . . . 37

4.10 Gráfico comparativo da velocidade linear em função do tempo num movimento em linha reta para trás . . . 37

4.11 Gráfico comparativo da velocidade angular em função do tempo numa rotação para a esquerda . . . 38

4.12 Gráfico comparativo da velocidade angular em função do tempo numa rotação para a direita . . . 38

4.13 User Interface Melhorada do 3PiGaming . . . 39

5.1 Mapa divido em células com tamanho 20 e células inválidas . . . 42

5.2 Mapa divido em células com tamanho 50 e células inválidas . . . 42

5.3 Caminho 1 descoberto pelo algoritmo A* . . . 43

xii LISTA DE FIGURAS

5.4 Caminho 2 descoberto pelo algoritmo A* . . . 43

5.5 Caminho 1 descoberto pelo algoritmo A* melhorado . . . 44

5.6 Caminho 2 descoberto pelo algoritmo A* melhorado . . . 44

5.9 Diagrama de estados UML da Máquina de Estados desenvolvida . . . 49

Lista de Tabelas

4.1 Características físicas do robô 3pi modificado . . . 30

5.1 Resultados obtidos nos jogos entre diferentes técnicas de IA desenvolvidos . . . 50

Abreviaturas e Símbolos

MIEEC Mestrado Integrado de Engenharia Eletrotécnica e de Computadores IA Inteligência Artificial

AI Artificial Inteligence ROS Robotics Operating System 3D Tridimensional

ODE Open Dynamics Engine SDF Simulation Description Format URDF Universal Robotic Description Format CPU Central Processing Unit

RTF Real Time Factor UI User Interface

XML Extensible Markup Language YAML YAML Ain’t Markup Language PWM Pulse-width Modulation FSM Finite State Machine UI User Interface

Capítulo 1

Introdução

1.1

Contexto

Esta dissertação de mestrado será realizada no âmbito de continuação de trabalhos referentes ao projeto PiTank1[10] que foi sendo desenvolvido anteriormente pelo MIEEC e MIEIC.

Este projeto consiste num sistema de jogo interativo de realidade mista em que um número variado robôs se deslocam sobre um projetor e interagem entre si e com os componentes virtuais projetados, nomeadamente as paredes do mapa de jogo e as balas disparadas pelos robôs. A versão inicial permite que sejam jogadas partidas de um jogador contra outro ou de dois jogadores contra outros dois jogadores em que a equipa que acertar mais balas em robôs da equipa adversária obtém a vitória.

O sistema é composto pelos robôs, pelo sistema de projeção responsável por transmitir na tela de jogo o mapa e elementos de jogo, câmara responsável por adquirir as informações necessárias para poder ser obtido o estado atual de jogo, computador responsável por processar todos os dados de jogo e calcular os estados seguintes e joysticks com a função de interface entre os jogadores e o jogo.

Apesar de todos estes elementos já estarem devidamente implementados e como forma de con-tinuar o desenvolvimento deste projeto foi então proposto para esta dissertação o melhoramento do sistema de forma a adicionar mais modos de jogo em que os jogadores poderão jogar contra robôs controlados por inteligência artificial.

1.2

Motivação

Relativamente ao teor mais concreto de ambiente de jogo do projeto, o facto de o sistema fun-cionar através de realidade mista é já por si uma boa ferramenta para captar interesse no mesmo. No entanto, em termos de jogabilidade os elementos principais que melhor captam o interesse dos 1_{Página relativa ao PiTank do Professor Armando Jorge Miranda de Sousa de onde foi disponibilizado o Manual de}

Atividades e Manual de Instruções dos trabalhos mais recentes:fe.up.pt/asousa/3pigaming

2 Introdução

jogadores são o facto de cada jogador se sentir desafiado e sentir que o jogo é de certa forma com-petitivo. Na instância inicialmente existente de PiTank em que jogadores apenas podem jogar entre si este elemento nem sempre está presente pois grande parte das vezes existe um desequilíbrio en-tre as diferentes equipas e o jogo acaba por ser demasiado fácil para uma equipa e demasiado difícil para outra, sem que este elemento de competitividade se destaque.

O facto de ser inserido no sistema uma componente de inteligência artificial torna possível que este fator de competitividade possa ser modelado da melhor forma com o intuito de maximizar o interesse no jogo, seja por escolha de diferentes níveis de dificuldade que tornam o jogo mais ou menos difícil consoante o tipo de jogadores ou por adaptabilidade dinâmica do sistema de IA que varia o seu comportamento e as suas estratégias de modo a garantir que o jogo permaneça com um grau de competitividade elevado.

Devido a existir apenas um sistema real físico do jogo, a implementação e desenvolvimento de novas funcionalidades (como o caso de IA) pode ser por vezes complicada ou demorada, pelo que foi também desenvolvido e integrado no sistema existente uma componente de simulação que permite testar novos componentes do sistema e experienciar o jogo sem ser necessário recorrer ao sistema real. Foram feitos testes de forma a validar a implementação desenvolvida para o sistema em questão. Desta forma é garantida a robustez do sistema.

1.3

Objetivos

Um dos objetivos desta dissertação é o desenvolvimento de uma componente de simulação que facilite não só o trabalho futuro no PiTank bem como permita a elaboração de testes em ambiente remoto, isto é, sem ser necessária utilização do sistema real.

Outro objetivo importante é melhorar o sistema PiTank fazendo a integração de inteligência artificial no controlo dos robôs e permitindo a escolha de um novo modo de jogo que utilize a tecnologia desenvolvida.

Dentro deste objetivo geral estão inseridos diversos objetivos sendo que o que tem o carácter mais critico e fundamental será integrar inteligência artificial nos robôs de forma a ser possível implementar totalmente um modo de jogo de 1 jogador contra 1 IA.

Tendo em conta o caráter referido nas secções anteriores de competitividade, este projeto tem também como objetivo fundamental o desenvolvimento de diferentes níveis de dificuldade para cada modo de jogo de forma a ser adaptável a cada diferente tipo de jogador e implementação de algum tipo de algoritmo que permita que cada robô controlado por IA se adapte à situação de jogo, independentemente ou não do nível de dificuldade.

1.4

Contribuições

Tendo em conta os estados inicial e final do trabalho as contribuições desta dissertação para o projeto PiTank podem-se resumir em duas principais adições, nomeadamente simulação e inteli-gência artificial.

1.5 Estrutura da Dissertação 3

No que toca à parte da simulação foi criado um modelo realista do robô utilizado no PiTank, bem como a implementação de um modo de simulação que permite o teste e realização de partidas no próprio computador, em ambiente de simulação Gazebo, com elevado grau de semelhança com o sistema real.

Quanto à Inteligência Artificial foram criados quatro graus de dificuldade diferentes tendo em conta duas diferentes abordagens, Negamax e máquinas de estado finitas.

Após a realização desta dissertação, é possível no PiTank realizar jogos entre 1 jogador vs 1 IA ou 1 IA vs 1 IA quer em ambiente real ou em ambiente simulado com variados níveis de dificuldade.

1.5

Estrutura da Dissertação

Esta dissertação está dividida em 6 capítulos. Neste capítulo é feita a análise do contexto, motivação e objetivos inerentes à elaboração desta dissertação.

No capítulo 2 será analisado primeiramente o estado do projeto PiTank que serve como base para esta dissertação, bem como posteriormente feita a revisão do estado da arte relativamente a todas as tecnologias, algoritmos e técnicas relevantes ao projeto, nomeadamente, simuladores, planeamento de caminhos e técnicas de inteligência artificial.

No capítulo 3 é feita uma análise da diferente informação recolhida no Capítulo 2 e escolhida, tendo em conta diversos fatores, as melhores abordagens para a correta implementação de todos os fatores necessários para elaboração desta dissertação, definindo assim uma série de soluções propostas. Também neste capítulo é analisada a arquitetura inicial do sistema bem como defini-ção das alterações necessárias à mesma para uma correta estrutura do projeto tendo em conta as modificações ao sistema a elaborar.

No capítulo 4 são analisadas as características do robô utilizado no projeto e elaborado um modelo URDF a ser utilizado na simulação. De seguida são utilizadas diferentes ferramentas ROS para definir o controlo de cada robô na simulação de acordo com as regras definidas pelo motor do jogo.

No capítulo 5 são elaboradas e comparadas duas diferentes abordagens de inteligência artificial relevantes para este projeto, máquinas de estado finitas e algoritmo Negamax. É comparado o desempenho de cada um em diferentes jogos entre si.

O capítulo 6 corresponde às conclusões desta dissertação. São também feitas sugestões relati-vamente a potencial trabalho futuro no sistema PiTank.

Capítulo 2

Estado inicial do Projeto e Estado da

Arte

2.1

Pitank

Tendo em conta que todo o trabalho desenvolvido nesta dissertação tem como base o Pitank, é de grande relevância fazer uma introdução ao sistema para que os capítulos seguintes fiquem bem enquadrados com o trabalho desenvolvido anteriormente.

O Pitank é um jogo do tipo shooter pertencente ao sistema de realidade mista 3PiGaming 1 [10] desenvolvido por alunos do MIEEC e MIEIC. Este sistema é composto por três diferentes jogos sendo que o trabalho desenvolvido nesta dissertação apenas se debruçou sobre o Pitank.

Os jogos pertencentes a este sistema intitulam-se de realidade mista devido à clara interação entre elementos reais e elementos virtuais, isto é, certas ações de elementos reais provocam cer-tas mudanças em elementos virtuais e vice-versa, sendo que todas as regras e modos de jogo se baseiam nestas interações entre estes dois domínios real e digital.

2.1.1 Caracterização do sistema

O sistema é composto por diversos robôs Pololu 3pi [4] modificados com uma Apriltag na sua capota que serve como um modo, quer de identificação de cada robô, como forma de obter a sua posição e orientação e um módulo de comunicações XBee. Apriltags [1] são uma variante de QRCode no sentido em que são códigos de identificação de duas dimensões codificados para menor número de bits o que permite que a sua identificação seja mais robusta e sejam possíveis deteções a distâncias maiores. Os 3pi (Figura4.1) em si são robôs de tração diferencial típicos com a vantagem do seu sistema de alimentação proporcionar uma tensão constante nos seus motores, independente da carga nas suas pilhas. Este fator é essencial no jogo em causa por se tratar de um jogo com caráter competitivo pelo que garante que todos os robôs se desloquem à mesma 1_{Página relativa ao PiTank do Professor Armando Jorge Miranda de Sousa de onde foi disponibilizado o Manual de}

Atividades e Manual de Instruções dos trabalhos mais recentes:fe.up.pt/asousa/3pigaming

6 Estado inicial do Projeto e Estado da Arte

Figura 2.1: Mapa do Jogo Pitank

velocidade independentemente dessa mesma carga. Cada 3pi contém também um módulo wireless XBee responsável pela comunicação com o computador.

Existe ainda uma câmara Logitech C920 HD Pro responsável pela aquisição das imagens do mapa de jogo que serão processadas no computador.

Um projetor tem como função projetar o mapa de jogo sobre uma tela posicionada no chão, bem como todos os elementos de jogo.

Até quatro joysticks podem ser utilizados dependendo do número de jogadores como forma de controlar os 3pi no campo de jogo.

Por fim, um adicional módulo wireless XBee é ligado ao computador para poder ser efetuada a comunicação entre os comandos inseridos pelos jogadores a partir dos respetivos joysticks e os respetivos 3pi.

Quanto aos elementos virtuais projetados na tela de jogo, estes podem ser balas disparadas por cada jogador, paredes que formam o campo, o tempo de jogo e as suas classificações.

2.1.2 Regras e modos de jogo

Tendo por base a secção anterior sobre o funcionamento do sistema, é também importante definir as regras do jogo bem como os seus objetivos.

Cada jogador controla o seu respetivo 3pi e pode enviar certos comandos para o mesmo. É possível andar para a frente e para trás, rodar para esquerda e para a direita, disparar sobre os adversários e andar a uma velocidade mais elevada premindo o botão de turbo.

Sempre que um tiro de um jogador acerta num jogador inimigo, o jogador que acertou ganha um ponto positivo e o jogador que foi atingido ganha um ponto negativo. Quando o tempo de jogo

2.1 Pitank 7

Figura 2.2: Sistema Real PiTank

chega a zero, ganha o jogador ou equipa (dependendo do modo de jogo) que tenha uma maior diferença entre pontos positivos e pontos negativos.

Existem atualmente dois modos de jogo, um individual em que um número até quatro joga-dores joga entre si sendo que todos os outros jogajoga-dores são considerados inimigos e um modo de equipa em que dois jogadores jogam contra outros dois jogadores.

2.1.3 Interações entre elementos

Como foi dito anteriormente, o facto deste sistema se tratar de um sistema de realidade mista implica que existam elementos reais a interagir com elementos virtuais visíveis, projetados sobre a tela de jogo. Existem diversas interações possíveis.

• As balas são disparadas a partir da parte da frente de cada robô. • Se as balas atingirem um robô adversário são convertidas em pontos.

8 Estado inicial do Projeto e Estado da Arte

Figura 2.3: Exemplo de uma Apriltag utilizada [1]

• Se as balas atingirem uma parede que não seja delimitadora do mapa de jogo retiram-lhe um ponto de vida. Inicialmente cada parede tem 5 pontos de vida. Quando este número chega a 0 a parede é eliminada e o mapa fica mais aberto.

• Se um jogador tentar andar através de uma parede é impedido e obrigado a recuar.

2.2

Simuladores

Havendo a necessidade de implementação de um ambiente de simulação para o trabalho a desenvolver, é importante analisar os diferentes simuladores relevantes para o trabalho em causa e escolher o que se melhor se enquadra nos objetivos e requisitos do projeto.

Os fatores que mais influenciaram a decisão nesta escolha foram a compatibilidade e integra-ção com ROS [5], framework concebido para desenvolvimento de projetos de robótica e dotado de diversas bibliotecas e ferramentas bastante úteis nesse mesmo sentido. É bastante popular nas comunidades de robótica e a base de todo o projeto 3PiGaming; possibilidade de teste com vários modelos de robôs, visto que podem haver jogos com um máximo de quatro 3pi simultaneamente; performance aceitável; fácil compatibilidade futura, isto é, como é certo que sejam implementadas mais funcionalidades neste sistema é importante que o software utilizado se mantenha relevante em versões futuras.

Tendo todos estes fatores em conta foram comparados três dos simuladores mais utilizados na indústria da robótica: Gazebo, VRep e ARGos.

2.2.1 Gazebo

Gazebo [3] é um simulador 3D open-source e é o simulador por defeito do framework ROS. Apesar de serem projetos diferentes são desenvolvidos lado a lado o que torna a integração do Gazebo em ROS um dos seus pontos fortes.

No que toca a motor de física apenas o ODE está integrado neste simulador. No entanto é possível integrar outros motores como Bullet ou Simbody se necessário manualmente.

2.2 Simuladores 9

Figura 2.4: Diagrama dos elementos do sistema físico 3piGaming

Gazebo está disponível para Linux e é possível interagir com os modelos dos robôs a meio da simulação, utilizando comandos ROS ou plug-ins.

Quanto aos modelos é possível tanto importar modelos produzidos exteriormente ao Gazebo no formato .SDF ou .URDF ou utilizar modelos pré-existentes sendo que estes têm uma seleção escassa. No entanto é irrelevante visto ser criado um novo modelo para o robô 3pi neste projeto.

Relativamente a simulação de multi-robôs, para o trabalho em causa (máximo de 4 robôs simultaneamente) o Gazebo apresenta resultados positivos [22] no que toca quer no fator real-time, quer na percentagem de CPU usada.

Outro ponto forte associado ao Gazebo é o facto de ser o simulador mais utilizado na comu-nidade de robótica pelo que existe uma grande quantidade de documentação sobre o simulador bem como uma comunidade aberta a discussões sobre certos parâmetros do mesmo o que torna um desenvolvimento e aprendizagem sem grandes dificuldades.

A sua principal desvantagem encontrada foi o facto de por vezes existirem crashes inesperados na criação do respetivo nó ROS, não sendo, no entanto, algo grave.

2.2.2 V-REP

V-REP [7] é um simulador 3D desenvolvido pela Coppelia Robotics e é um dos simuladores com maior número de funcionalidades e ferramentas no desenvolvimento de projetos de robótica. É possível utilizar por defeito uma grande variedade de motores de física como Bullet, ODE, Vortex e uma grande quantidade de linguagens de programação são suportadas como C++, Lua, Python.

10 Estado inicial do Projeto e Estado da Arte

Tem uma grande quantidade de modelos nativos sendo também possível importar modelos customizados e editar os mesmos no próprio simulador.

Apesar de V-REP ser independente de ROS existem atualmente diversas interfaces e plug-ins que permitem o desenvolvimento de projetos baseados em ROS sem muita dificuldade.

Este simulador apresenta também bastante documentação útil e a sua UI é considerada bastante acessível e intuitiva.

Apesar de todos estes pontos positivos, V-REP fica um pouco atrás no que toca a simulações com vários robôs. Segundo [22] para uma cena simples e apenas 5 robôs o fator real-time diminuiu consideravelmente e o uso do CPU aumenta drasticamente.

Podemos concluir que este simulador é bom para projetos que necessitem de física extrema-mente realista e de diversas funcionalidades, mas no que toca a projetos com considerável número de robôs torna-se uma escolha mais fraca.

2.2.3 ARGos

ARGos [2] é um simulador desenvolvido com o objetivo de ser utilizado em aplicações de robótica com grande quantidade de robôs.

Este simulador apresenta uma escassa escolha de modelos de robôs e estes são pouco detalha-dos, uma das razões pela qual este simulador é bom para ambientes complexos. Utiliza motores de física próprios podendo não estar otimizados.

Ao contrário de Gazebo e V-REP este simulador não tem muita documentação e a sua comuni-dade é pequena pelo que desenvolvimento em ARGos pode ser mais desafiante. Existe um plug-in que permite fazer a ponte com ROS.

Em termos de performance, para uma pequena cena com 5 robôs [22] este simulador apresen-tou os melhores resultados dos três.

A maior desvantagem deste simulador é o facto de não ser possível a importação de modelos para o simulador.

2.3

Planeamento de Caminhos

Uma grande parte de aplicações robóticas móveis é a habilidade de um robô se deslocar de forma autónoma para determinado destino definido ou pelo utilizador ou por algum tipo de camada superior de controlo [16] [26]. Este fator está muitas vezes associado ao cálculo ou estimação da posição do robô, seja por odometria ou balizas refletoras ou outras técnicas. No entanto, neste trabalho a posição de cada robô é fácil de obter tanto no sistema real, devido às Apriltags, ou no sistema simulado devido às variáveis de posição e orientação fornecidas pelo simulador. Desta forma, com a posição e orientação dos robôs facilmente definida, resta apenas estudar as técnicas de planeamento de caminhos de modo a que cada robô se desloque de forma autónoma sem colidir com obstáculos.

Adicionalmente, para um robô se poder movimentar corretamente em determinado espaço é crucial que o mesmo tenha conhecimento desse espaço para ser possível a determinação do

2.3 Planeamento de Caminhos 11

caminho ótimo até ao ponto de destino. Assim é importante existir inicialmente uma discretização do espaço onde o robô se vai movimentar. Desta forma, as técnicas mais utilizadas são técnicas de decomposição em células ou roadmaps e campo de potencial.

2.3.1 Decomposição do Mapa em Células

Uma das técnicas mais utilizadas na criação de um mapa para planeamento de caminhos é a divisão do espaço físico num determinado conjunto de células. Células sobrepostas a obstáculos são consideradas ocupadas e inválidas para o movimento do robô e todas as outras são válidas.

Dependendo da forma de como são escolhidas as células, existem dois principais grupos de decomposição.

2.3.1.1 Células exatas

Nesta técnica o espaço é dividido geometricamente de forma a que a totalidade de cada obs-táculo corresponda a uma única célula ocupada e o restante espaço pode ser divido para formar células livres. Este espaço pode ser divido por exemplo fazendo a ligação entre os vértices dos diferentes obstáculos ou então traçando linhas verticais sobre cada vértice.

Figura 2.5: Representação da decomposição do mapa em células exatas [26]

Este tipo de decomposição não é muito utilizado devido não só à inconsistência do tamanho de células como também na relativa dificuldade de implementação. Como as células não têm necessa-riamente tamanho arbitrário e têm formas variadas o caminho obtido pode não ser necessanecessa-riamente o caminho ótimo.

2.3.1.2 Células aproximadas

Neste tipo de divisão o espaço é dividido em células com forma quadrada com um determinado espaçamento entre si que podem ser do mesmo tamanho ou de tamanhos variados, dependendo da

12 Estado inicial do Projeto e Estado da Arte

implementação. Ao contrário do método de células exatas que apenas contém células livres ou ocupadas, este método pode também apresentar células parcialmente ocupadas no caso em que um quadrado contém tanto espaço livre como um obstáculo.

A variante mais utilizada é a chamada decomposição em células aproximadas de tamanho fixo onde, como o nome indica, o mapa é constituído por células de tamanhos iguais independentes dos objetos do espaço. O tamanho destas células é definido pelo utilizador sendo que quando menor o tamanho, mais células vão existir e consecutivamente maior tempo de computação. A vantagem deste tipo de abordagem é a sua baixa complexidade e simples implementação que juntamente com certos algoritmos de pesquisa a tornam bastante robusta e utilizada. A principal desvantagem é a memória pois para grandes espaços e para um tamanho de célula pequeno a memória necessária para armazenar o mapa será considerável. No entanto, memória não é um problema comparativamente ao tempo de execução do algoritmo de pesquisa.

Figura 2.6: Representação da decomposição do mapa em células aproximadas de tamanho fixo [26]

Outra abordagem chamada decomposição em células aproximadas de tamanho variável ou quadtreeconsiste em criar mapa de forma recursiva com base numa primeira célula respetiva a todo o espaço. A cada iteração o espaço é dividido em quatro quadrados mais pequenos e cada um desses quadrados será posteriormente dividido se dentro dele estiver contido um obstáculo e mantido se dentro dele só estiver contido espaço livre. Desta forma, para espaços com poucos obstáculos a memória é bastante otimizada relativamente à abordagem de células de tamanho fixo. A sua desvantagem é que tal como no método de células exatas, com células de grandes dimensões o espaço percorrido pode não ser o menor possível.

2.3.2 Roadmaps

Outro método de divisão do espaço consiste em roadmaps. Ao contrário da secção anterior em que o mapa é dividido em células que definem a possibilidade do robô nelas permanecer, são

2.3 Planeamento de Caminhos 13

Figura 2.7: Representação da decomposição do mapa em células aproximadas de tamanho variável [26]

criados certos caminhos com base na geometria do espaço que definem o conjunto de espaço que o robô poderá ocupar. Estes métodos procuram minimizar a distância percorrida até ao ponto de destino ou garantir que não haja colisões dependendo da implementação.

2.3.2.1 Visibility Graph

Esta técnica baseia-se na construção do roadmap tendo em conta todos os vértices visíveis uns em relação aos outros, isto é, para cada vértice (vértices de polígonos dos obstáculos, ponto de partida, ponto de chegada) é traçada uma reta até cada um dos restantes vértices observados. Considera-se que um vértice observa outro quando na reta que os une não existe nenhum obstáculo. É então obtido um roadmap em que todas as retas definem a menor distância entre cada vértice observável. Cabe ao planeamento de caminhos encontrar o conjunto de retas que corresponde ao menor caminho entro o ponto inicial e final.

É importante referir que apesar de ser uma técnica bastante adotada e de simples implementa-ção o seu desempenho diminui drasticamente para espaços com um grande número de obstáculos e consequentemente grande número de vértices.

2.3.2.2 Voronoi Diagram

Ao contrário da abordagem anterior, esta técnica pretende maximizar o espaço entre o robô e os obstáculos, ou seja, o caminho com menores chances de colisão com os obstáculos.

Para cada ponto do espaço é calculada a distância aos diferentes obstáculos e se seguida cons-truido o mapa que contém todos os pontos equidistantes aos dois obstáculos mais próximos do robô.

14 Estado inicial do Projeto e Estado da Arte

Figura 2.8: Representação da decomposição do mapa Roadmaps - Visibility Graph [26]

Figura 2.9: Representação da decomposição do mapa Roadmaps - Voronoi Diagram [26] A grande desvantagem deste tipo de abordagem é o facto de não ser otimizado para obter a distância mínima possível entre dois pontos.

2.3.3 Algoritmos de pesquisa

Após a decomposição do espaço em células ou roadmaps utilizando uma das técnicas acima é ainda necessário descobrir o melhor caminho para determinado destino, ou seja, encontrar o conjunto de células, caminhos ou vértices (nós) do ponto inicial ao final dependendo da imple-mentação.

Existem dois grandes tipos de algoritmos de pesquisa que se diferenciam no facto da utilização ou não de métodos heurísticos na sua composição.

2.3 Planeamento de Caminhos 15

Os métodos que não utilizam qualquer heurística são os chamados métodos de pesquisa inten-siva ou métodos de pesquisa sem informação. Isto deve-se ao facto de todos os nós precisarem de ser analisados antes de ser descoberta a solução. Adicionalmente, raramente este tipo de algorit-mos apresenta um resultado ótimo, ou seja, o resultado com menor custo e só são considerados completos (admitem uma solução) se o número de nós for finito. No caso do número de nós ser elevado, o tempo de computação é exponencialmente mais elevado.

Alguns destes algoritmos são pesquisa por profundidade, pesquisa por largura e pesquisa por aprofundamento iterativo.

O outro tipo de métodos é a pesquisa utilizando algum tipo de informação, ou seja, métodos de pesquisa heurísticos. Existem três principais algoritmos nesta categoria: Dijkstra, Greedy e A* [9], sendo que todos estes podem ser modificados dependendo da necessidade. Estes algoritmos são mais utilizados devido a diminuírem consideravelmente o tempo de pesquisa dos nós.

O algoritmo Dijkstra [11] tem como heurística o custo de cada nó ao nó inicial. Apesar de diminuir consideravelmente o tempo de execução relativamente aos algoritmos de pesquisa inten-siva, Dijkstra continua na maior parte dos casos a ser um algoritmo não ótimo (exceto quando o custo de todas as ligações entre os nós é igual).

O algoritmo Greedy [9], ao contrário do Dijkstra tem como heurística o custo de cada nó ao nó de destino e tal como o anterior, a solução não é garantidamente ótima.

O algoritmo A* [13] utiliza como heurística tanto a distância ao nó inicial e a distância ao nó final relativamente a cada nó. Apresenta uma solução ótima dependente da função heurística utilizada.

Este algoritmo funciona da seguinte forma: a cada célula ou vértice (em representações por roadmaps) corresponde um nó. Começando no nó inicial, para o nó atual é calculado o custo desde o nó inicial até ao nó atual e a estimativa do custo do nó atual até ao nó destino. Esta estimativa corresponde a uma heurística definida na implementação do algoritmo que vai ser analisada mais à frente. É de seguida calculado o custo total correspondente à soma do custo até ao nó atual e da heurística e colocado o respetivo nó numa lista aberta correspondente aos nós vistos mas ainda não processados. As seguintes instruções são repetidas até se chagar ao nó de destino ou até a lista aberta ficar vazia. É escolhido o nó com melhor função custo da lista aberta, isto é, o nó cujo custo total é o menor. Este nó é considerado processado e colocado numa lista fechada. São posteriormente analisados os nós adjacentes ao nó atual e colocados na lista aberta caso não lhe pertençam nem à lista fechada; se pertencer à lista aberta é calculada a função custo e verificado se este novo valor é menor que o valor anterior que corresponde ao nó e em caso positivo, este valor é substituído e o seu nó anterior também; se pertencer à lista fechada e a nova função custo for menor que a anterior, é colocado novamente na lista aberta.

Apesar da popularidade deste tipo de algoritmo, a sua eficiência é bastante dependente da função de heurística escolhida, sendo que se essa função for boa, o algoritmo é dos mais eficientes em literatura mas se a função escolhida não for adequada torna-se pouco eficiente. É então de extrema importância a escolha correta de uma função heurística adequada para o algoritmo. A

16 Estado inicial do Projeto e Estado da Arte

função heurística mais comum neste tipo de algoritmos corresponde à distância euclidiana entre cada nó e o ponto de destino.

2.3.4 Campos de Potencial

Planeamento de caminho através de campos de potencial tem por base a criação de um mapa de gradiente análogo a um campo magnético com o objetivo de guiar o robô através do campo até ao destino pretendido [15]. O ponto de destino funciona como uma força atrativa enquanto que todos os obstáculos funcionam como uma força repulsiva. A soma pontual destas forças é calculada para determinada posição do robô o que faz com que este seja guiado até ao destino.

Esta técnica é utilizada no projeto PiTank para no fim de cada jogo guiar os robôs para o pódio. É bastante boa em situações de obstáculos móveis (como outros robôs) mas por vezes pode apresentar comportamentos imprevisíveis.

2.4

Inteligência Artificial para Jogos

Uma parte importante quer da robótica quer do domínio dos jogos é a Inteligência Artificial. No entanto, existe alguma discussão sobre o que realmente é ou se qualifica como IA. Há quem diga que um sistema é dotado de IA apenas se for capaz de tomar decisões sem qualquer input humano. Outros dizem que um sistema só contém IA se for capaz de replicar comportamento humano. Apesar do debate, o termo sempre foi utilizado em vários contextos nomeadamente no mundo dos jogos.

IA em jogos [17] [25] tem como objetivo principal fornecer ao jogador uma experiência apela-tiva e competiapela-tiva. Cada tipo de jogo apresenta desafios diferentes e consequentemente algoritmos diferentes para responder a esses desafios.

Sendo que o PiTank se insere no grupo dos jogos do tipo shooter, a utilização de técnicas normalmente utilizadas neste domínio será à partida bastante relevante. As principais técnicas utilizadas neste tipo de jogos são as máquinas de estado finitas, mas vão ser avaliadas duas outras possibilidades.

2.4.1 Máquinas de estado finitas

Máquina de estados finita é uma técnica usada que consiste na definição de diferentes esta-dos que representam certos comportamentos ou ações do objeto dotado de IA. Dependendo de diferentes fatores do estado do jogo, os estados vão variando e consecutivamente as suas ações também. Esta técnica é a mais usada atualmente no domínio dos jogos não só devido à sua baixa complexidade como à facilidade de implementação.

Existem várias formas de implementação deste tipo de abordagem sendo que não existem algoritmos totalmente definidos para tal. No entanto, todas seguem a mesma receita. É importante definir dois fatores importantes, nomeadamente, o que cada estado representa no contexto do jogo, correspondente a uma ação ou um certo comportamento do objeto e as ligações entre estados, ou

2.4 Inteligência Artificial para Jogos 17

seja, as variáveis que permitem a transição de estados, que correspondem normalmente a uma mudança dessas variáveis.

Alguns exemplos de estados em jogos do tipo shooter vão desde apontar para o adversário, disparar, fugir, patrulhar, entre outros. Enquanto que algumas transições simples poderão ser inimigo avistado, inimigo em mira.

É adicionalmente possível em algumas aplicações em que seja necessário a definição de má-quinas de estado hierárquicas, ou seja, a existência de estados mais importantes na escala hierár-quica que contém estados de nível menos elevado.

Figura 2.10: Exemplo de uma máquina de estados finita hierárquica [17]

Esta implementação é útil por exemplo em situações em que seja necessário definir um estado de ataque ou defesa, sendo que para cada um desses estados existem táticas ou abordagens dife-rentes ao problema, ou seja, estados difedife-rentes. É ainda útil nas situações de alarme, isto é, se estiver a ser efetuada uma manobra de defesa mas alguma variável no estado de jogo mudar de forma a que o estado hierárquico superior passe para ataque, a manobra de defesa é imediatamente interrompida e é iniciada o respetivo ataque.

2.4.2 Minimax e Negamax

Teoria dos Jogos é um ramo da matemática que estuda certos problemas com o objetivo de descobrir a melhor resposta [20] [21]. Pode ser diferenciado pelo número de jogadores, quanti-dade de informação e tipo de jogo. As análises mais simples, bem como a grande maioria de jogos de tabuleiro apresentam apenas dois jogadores que jogam entre si. Da mesma forma, predominam os jogos denominados zerosum, ou seja, quando um jogador vence, o outro jogador tem necessa-riamente de perder. Por exemplo, se um jogador efetuar uma jogada que lhe valha +2 pontos, o

18 Estado inicial do Projeto e Estado da Arte

seu adversário acabou de ganhar -2 pontos ou perder +2 pontos. Esta característica é bastante re-levante para o algoritmo negamax que será analisado mais à frente. Quanto à informação, podem existir jogos com informação completa, ou seja, em que todos os jogadores têm o total conheci-mento do estado de jogo em todos os moconheci-mentos, como xadrez ou damas, e jogos com informação incompleta em que falta informação a um ou mais jogadores, por exemplo sueca ou copas.

A maior parte dos jogos pertence ao grupo de jogos zerosum com informação completa e dois jogadores. A este grupo podem então ser associados algoritmos de minimax ou negamax para obter a melhor jogada possível.

As técnicas de minimax e negamax são principalmente utilizadas para criação de IA em jogos baseados em turnos ou de tabuleiro, como por exemplo xadrez ou Go [17].

Minimaxing tem por base o conceito que durante um jogo entre dois jogadores, A e B, no ponto de vista do jogador A, no seu turno pretende fazer a jogada que maximiza a sua pontuação enquanto que o adversário procura sempre fazer a jogada que minimiza a sua pontuação (do joga-dor A), ou seja, assume-se que A pretende maximizar a sua pontuação e B pretende minimiza-la.

Estas transições entre maximização e minimização podem ser efetuadas inúmeras vezes, de-pendendo da profundidade definida na árvore de pesquisa, definida por diferentes nós e suas li-gações em que cada nó em cada patamar de profundidade corresponde a uma jogada possível de determinado jogador. Desta forma, quanto maior for a profundidade maior será a probabilidade da melhor jogada ser escolhida, mas consecutivamente maior será o custo computacional de pesquisa associado a essa jogada. É então importante garantir um bom equilíbrio entre estes dois fatores.

2.4 Inteligência Artificial para Jogos 19

function minimax(node, depth, maximizingPlayer); if depth = 0 OR terminal node then

return evaluation; end

if maximizingPlayer then value = −∞

for each child of node do

value := minimax(child, depth-1, FALSE) return value

end else

value = ∞

for each child of node do

value := minimax(child, depth-1, TRUE) return value

end end

Algoritmo 1: Pseudo-código do algoritmo Minimax

Nas implementações do algoritmo minimax, como se pode ver no pseudo-código são necessá-rias duas funções, uma de maximização associada ao jogador e uma de minimização associada ao inimigo. No entanto, segundo a definição de jogos zerosum, num jogo desse tipo em que um jo-gador efetua uma jogada que vale +1 ponto, essa jogada vale automaticamente para o seu inimigo -1 ponto. Tirando partido desta característica foi criado um algoritmo baseado em minimax que utiliza apenas uma função. É o chamado algoritmo negamax.

Negamax consiste num algoritmo recursivo em que a cada iteração é alterado o ponto de vista de quem joga e a respetiva pontuação de um certo conjunto de jogadas é constantemente convertida em positiva (ponto de vista do jogador) ou negada (ponto de vista do inimigo) utilizando a característica de jogos zerosum analisada em cima.

function negamax(node, depth, player); if depth = 0 OR terminal node then

return player * evaluation; end

value = −∞

for each child of node do

value := max(value, -negamax(child, depth-1, -player)) return value

end

20 Estado inicial do Projeto e Estado da Arte

2.4.3 Reinforcement Learning

Para além das duas técnicas apresentadas acima, uma das técnicas que começou a ser mais utilizada é a criação de IA através de aprendizagem, mais concretamente aprendizagem reforçada ou reinforcement learning [27]. Como o nome indica, consiste resumidamente em ensinar um sistema com base em algum tipo de feedback relativamente a uma ação por si tomada.

A técnica mais comum de reinforcement learning em jogos é Q-Learning e funciona de certa forma como máquinas de estado. Cada estado representa o estado do jogo a determinada iteração. Tal como nas técnicas vistas anteriormente é necessário analisar e definir todas as variáveis ou fatores que influenciam o estado de jogo e que queiramos que sejam vítimas de aprendizagem e arranjar uma função que transforme cada estado de jogo num valor numérico. Variáveis não incluídas nessa função não afetam nem a aprendizagem nem a tomada de decisão.

Depois de escolhida e efetuada uma ação por parte do agente, o estado de jogo é analisado e averiguado por uma função de avaliação se a jogada for boa ou má (normalmente valores compre-endidos entre -1 e 1, sendo -1 a pior jogada possível, 1 a melhor jogada possível e 0 impossibili-dade de averiguação do carácter da jogada) e guardado o resultado. Desta forma, quando o agente se encontrar num estado em que já esteve anteriormente pode decidir se deve efetuar alguma das jogadas que já tentou anteriormente ou tentar outra jogada se os resultados anteriores não forem positivos.

Assim, a chamada regra de aprendizagem ou learning rule é a função que relaciona o valor guardado por aprendizagens passadas do conjunto de um certo estado e respetiva ação com o quão bom foi a ação e quão bom será o próximo estado. Esta regra depende das variáveis de taxa de aprendizagem que define quanto é que certa ação influencia a aprendizagem e fator de desconto que valoriza mais as ações tomadas anteriormente do que as ações tomadas recentemente.

Capítulo 3

Soluções propostas para melhoramento

do PiTank

3.1

Simulação

Tendo em conta os objetivos do projeto é importante definir as técnicas e ferramentas analisa-das no Capítulo 2 que serão mais relevantes para o projeto.

Relativamente ao simulador, os fatores com maior importância são:

• Capacidade de importação de modelos criados externamente ao simulador.

Devido à falta de existência de um modelo do robô 3pi utilizado no sistema real do Pi-Tank, será necessário a criação do mesmo. Desta forma, é crucial que o simulador utilizado permita a criação e importação de modelos externos.

• Garantia de RTF superior ou igual a 1 para simulações de até 4 robôs.

Real Time Factor, ou RTF, corresponde ao quociente entre tempo simulado e tempo real. Quanto mais perto de 1 for este valor, mais próxima da realidade será a simulação.

Visto o PiTank se tratar de um jogo em tempo real é importante que a simulação ocorra aproximadamente com um fator de tempo igual ao real (RTF = 1), porque de outra forma os resultados obtidos no sistema real seriam diferentes dos obtidos no sistema simulado. • Simples integração com ROS.

Tendo em conta que todo o trabalho relacionado com PiTank efetuado até à data foi feito sobre o framework ROS é importante que o simulador escolhido permita uma simples inte-ração com o mesmo, principalmente criação de um nó a si associado que comunique com os restantes nós do projeto.

• Desenvolvimento futuro

22 Soluções propostas para melhoramento do PiTank

É certo que após a elaboração desta dissertação mais alunos irão trabalhar e melhorar o PiTank. Assim é importante que o simulador escolhido nunca seja considerado depreciado ou outdated e permita sempre um desenvolvimento fácil.

Existem outros fatores menos importantes como motores de física extremamente precisos e UI bem estruturada que são pouco relevantes para o trabalho em causa apesar de serem um ponto forte de alguns dos simuladores.

Enumerados e analisados os principais requisitos foi escolhido o Gazebo como simulador para este projeto devido a responder melhor a todos os requisitos, principalmente os dois últimos pontos.

O facto da sua integração com ROS e de serem desenvolvidos simultaneamente tornam-no no melhor candidato pois não só é garantido que o seu desenvolvimento futuro estará a par com ROS, tal como a sua comunicação e interação é feita de forma intuitiva.

Segundo [22] o Gazebo apresenta o melhor resultado de RTF com 5 robôs e sempre garantido que o seu valor não baixe de 1, como é necessário. Adicionalmente é também possível importar modelos externos e utiliza-los no Gazebo sobre o formato .SDF ou .URFD.

3.2

Inteligência Artificial para Jogos

Como foi analisado no Capítulo 2, a técnica de IA mais utilizada em jogos do tipo shooter é a utilização de máquinas de estado finitas. Isto deve-se principalmente ao facto de sendo jogos em tempo real, existir sempre uma restrição de tempo do algoritmo utilizado, o que não acontece com outros tipos de jogos, como jogos por turnos, sendo que se cada iteração for demorada, não só as informações de decisão poderão estar desatualizadas, bem como o adversário se pode aproveitar desse tempo de processamento o que potencialmente torna o jogo menos divertido.

No entanto, apesar de poderosa e relevante para o trabalho em causa, esta técnica é relativa-mente fácil de implementar e pode tornar o jogo um pouco linear e consequenterelativa-mente aborrecido sendo que as transições de estado são algo bem definido e dependem diretamente da forma como são implementadas.

Assim, achou-se interessante experimentar utilizar técnicas normalmente usadas em tabuleiro, nomeadamente Negamax, e potencialmente integra-las de alguma forma com a técnica de máqui-nas de estado, comparando-as com a mesma. Deste modo, o jogo poderá tornar-se mais dinâmico pois não será definido por transições de estado lineares mas sim pela análise da melhor jogada para uma certa profundidade da árvore de pesquisa.

Importante referir que é crucial escolher uma profundidade adequada que mantenha o equilí-brio entre tempo de processamento e nível de inteligência. Este fator será revisto num Capítulo posterior.

3.3 Arquitetura ROS 23

3.3

Arquitetura ROS

Com a adição de novos componentes ao projeto é necessário rever e reformular se necessário a arquitetura de software do sistema, nomeadamente a parte relacionada com ROS.

Aquando o início da elaboração desta dissertação o sistema era composto por cinco nós re-presentados na Figura3.1. Este diagrama foi obtido através do comando rqt_graph que permite a representação gráfica não só dos nós pertencentes ao projeto, as mensagens trocadas entre os mesmos e os tópicos a elas associados, bem como o sentido das mensagens (nós subscrevem ou publicam nos tópicos respetivos).

Figura 3.1: Arquitetura ROS inicial do projeto

O nó /uvc_camera é responsável pela configuração e manutenção da câmara. Fornece in-formações ao nó /p_calib sobre parâmetros de câmara e trata da aquisição em bruto da imagem correspondente ao mapa de jogo.

/p_calib subscreve ao tópico /calibration_thresh que corresponde ao valor introduzido pelo utilizador na UI quando o programa é iniciado que define os cantos do mapa de jogo captado pela câmara. Estes cantos são de seguida publicados pelo motor de jogo e subscritos por /april-tag_detectorpor forma de ser possível efetuar as transformações geométricas necessárias para o cálculo correto das posições das apriltags relativas ao mapa de jogo.

Por sua vez o nó /joystick é responsável por configurar e ler os comandos introduzidos pe-los jogadores em cada um dos diferentes joysticks. É de seguida enviada essa informação para o motor de jogo sobre forma de uma mensagem do tipo Twist, que é um tipo nativo de ROS perten-cente ao pacote /geometry_msgs. Esta mensagem é composta por um vetor tridimensional a que correspondem as velocidades lineares sobre o eixo do x,y e z e outro vetor tridimensional a que correspondem as velocidades angulares em volta do eixo x, y e z. Adicionalmente, visto apenas ser utilizado linear.x e angular.z, para não ser criada outra mensagem à parte, os comandos de disparar e de turbo são publicados com valores arbitrários sobre a variável angular.z o que não é uma prática decente e pode trazer problemas inesperados.

24 Soluções propostas para melhoramento do PiTank

Por fim, o nó /game_engine corresponde ao motor de jogo e é o nó central onde toda a informa-ção é processada ou distribuída entre os restantes nós. É responsável não só pela UI como também por implementar as regras de jogo e garantir que estas são cumpridas. Recebe as mensagens do comandos dos jogadores e converte-as numa trama possível de enviar para determinado robô.

Tendo em conta as novas funcionalidades a serem implementadas é necessária a criação de mais alguns nós. Foram considerados suficientes três nós adicionais como mostra a Figura 3.2

(arquitetura simplificada sem tópicos) e Figura3.4(arquitetura completa com tópicos).

Figura 3.2: Nova arquitetura ROS proposta para o projeto (apenas nós e suas ligações) Todos os nós já existentes foram mantidos, exatamente com as mesmas funções e foram apenas adicionados e integrados no sistema os três novos nós responsáveis pela simulação, IA e controlo dos robôs na ausência de joysticks. Houve também mudanças relativamente à tipologia e organi-zação das mensagens.

Em primeiro lugar será criado um namespace associado a cada robô (até um máximo de 4) ao contrário de um único namespace para todos como existia anteriormente. Isto é útil não só por ser intuitivo e produzir uma melhor organização como também será útil no controlo de cada um dos robôs no Gazebo pois se enviarmos, por exemplo, uma mensagem de controlo para quatro robôs com o mesmo modelo no mesmo namespace, todos irão responder da mesma forma, a não ser que a cada robô estejam associados quatro diferentes tópicos de controlo (cmd_vel) o que não é uma boa prática. Por outro lado se cada robô pertencer a um namespace único, basta ter a ele associado um único tópico (cmd_vel).

Outro fator mal implementado é o facto de as ações de disparo e turbo estarem associadas ao tópico das velocidades de cada robô. Até à data, não existia grande problema em utilizar este tipo de arquitetura para poupar um tópico ao sistema. No entanto, com a integração de um novo nó responsável pela simulação, em que cada robô é diretamente controlado pelo mesmo tipo de mensagem proveniente dos joysticks (Twist), a atribuição de um valor a angular.z irá influenciar

3.3 Arquitetura ROS 25

diretamente a velocidade angular de um certo robô. Desta forma, é mais correto criar uma men-sagem customizada que trata da informação relativa a disparar e utilizar turbo e criar um tópico associado a este tipo de mensagem para cada namespace dos diferentes robôs. Este tópico será chamado /shootandturbo como pode ser visto na Figura3.2.

Relativamente aos nós ROS, será necessário criar um nó associado ao simulador que será responsável por abrir o Gazebo, carregar a cena correta do mapa de jogo, carregar um certo número de robôs dependendo do que o utilizador definir, permitir o controlo de cada um desses robôs e publicar a posição dos mesmos num tópico subscrito pelo motor de jogo.

Desta forma, todas as regras e controlo do jogo serão na mesma efetuados no nó /game_engine sendo a única diferença a origem dos inputs relativos às posições de cada robô. Se o utilizador selecionar o sistema físico a origem será a leitura de cada AprilTag presente no mapa de jogo. Por outro lado, se o utilizador escolher o sistema simulado a origem será as posições de cada modelo do robô no Gazebo. Assim, é garantido um sistema bastante flexível e serão necessárias mudanças mínimas no nó /game_engine relativamente à integração do simulador.

Será também criado um nó de controlo dos robôs no caso de ausência de joysticks. Este nó será baseado no pacote nativo ROS teleop_twist_keyboard que publica mensagens do tipo Twist para controlo a partir do teclado. Serão efetuadas algumas alterações para ser possível acomodar quatro jogadores simultaneamente bem como a possibilidade de disparar e turbo.

Finalmente, resta o nó relativo a IA. Este nó será responsável pela tomada de decisão e con-trolo de cada robô do tipo IA (definido no início do jogo). Visto que a tomada de decisão será dependente não só das posições dos robôs, mas também do estado da UI (tempo de jogo, difi-culdade escolhida, etc..) e certos elementos de jogo como as paredes, é necessário que este nó subscreva aos tópicos associados a todos esses elementos publicados pelo /game_engine.

Um diagrama mais complexo (com tópicos associados aos nós) é mostrado abaixo na Figura

26 Soluções propostas para melhoramento do PiTank

3.3 Arquitetura ROS 27

Capítulo 4

Criação do Simulador para PiTank

4.1

Características do 3pi

Um dos fatores mais importantes na obtenção de uma simulação com resultados semelhantes à realidade é a utilização de um modelo que caracterize corretamente o modelo real.

Os robôs utilizados no PiTank são versões modificadas do robô 3pi desenvolvido pela Pololu [4]. Foi criada uma espécie de capota de forma a acomodar a utilização de AprilTags para deteção de cada um dos robôs durante o jogo. Desta forma, visto não existir nenhum modelo desta versão modificada do 3pi foi necessária a elaboração de um modelo 3D que o caracterize corretamente.

Figura 4.1: Robô Pololu 3pi original [4] Figura 4.2: Robô Pololu 3pi modificado A fase inicial corresponde, obviamente, à recolha e medição das características do modelo real, nomeadamente valores de altura, diâmetro do chassis, diâmetro das rodas, distância entre rodas, entre outros. Após a recolha de informação em [4] e medição de alguns valores relevantes foi criada a Tabela4.1abaixo.

Uma nota importante é o facto de devido às capotas terem sido criadas de forma customizada, existe uma pequena variância no valor de altura dos diferentes robôs, sendo que o seu valor médio ronda os 5 centímetros, pelo que foi adotado esse valor como altura de todos os robôs simulados.

30 Criação do Simulador para PiTank

Parâmetro Valor

Altura do robô 6.00 cm Diâmetro do chassis 9.50 cm Diâmetro das rodas 3.40 cm Distância entre rodas 9.00 cm Distância do chassis ao chão 0.85 cm Peso (com pilhas) 0.50 kg

Tabela 4.1: Características físicas do robô 3pi modificado

Foram desprezados os parâmetros de software e alguns parâmetros de hardware como tipo de processador e gama de tensões de funcionamento, visto não serem relevantes para o caráter físico do sistema.

4.2

Modelação do 3pi

Com todos os dados necessários obtidos, é agora possível a criação de um modelo 3D que represente o modelo real.

Universal Robotic Description Format, ou URDF, é o formato predefinido em ROS, baseado na linguagem XML, utilizado para descrever todos os elementos pertencentes a um modelo de um robô [6]. Apesar de ser o formato standard, não é capaz de suportar algumas característi-cas necessárias com a evolução da simulação robótica. Desta forma, o Gazebo utiliza Simulation Description Format (SDF) que consegue responder aos problemas no qual URDF é incapaz. No entanto, Gazebo é capaz de importar um ficheiro URDF e convertê-lo automaticamente para o formato SDF o que poupa imenso trabalho. Tirando partido deste fator procedeu-se ao desenvol-vimento do modelo sobre URDF.

Os dois principais elementos que definem o formato URDF são os elementos link e joint. link corresponde aos componentes que formam o modelo e joint corresponde às ligações entre esses elementos. Por exemplo, se fosse desenvolvido um modelo simples de uma pessoa utilizando URDF, seria criado um link para cada membro superior e inferior, torço e cabeça e diversos joints que corresponderiam às articulações entre membros. Importante referir que quanto mais simples (menos elementos) for o modelo, melhor desempenho terá o sistema simulado.

Cada elemento tem a ele associado diversas palavras chave que configuram diversos parâme-tros do robô. Cada link necessita de ter tanto valores de pose (translação e rotação nos diferentes eixos) como de inércia (massa e momento de inércia). Adicionalmente pode conter elementos vi-suais e de colisão que definem, como o nome indica, a sua forma geométrica vista pelo utilizador e a sua forma utilizada em colisões, respetivamente. Se não apresentar elemento visual, o link torna-se invisível mesmo que contenha elemento de colisão. Da mesma forma se conter elemento visual mas não conter elemento de colisão não pode interagir com outros elementos da simulação. No caso deste trabalho achou-se suficiente a criação de apenas três links, um que representa o chassis e outros dois que representam a roda esquerda e roda direita. Relativamente ao chassis e

4.2 Modelação do 3pi 31

tendo em conta as características acima referidas, a forma mais simples de definir este elemento é como um cilindro vertical com diâmetro 9.50 cm e altura equivalente à diferença entre a altura do robô e distância do chassis ao chão. Desta forma, obtém-se um cilindro com 6.00 cm - 0.85 cm = 5.15 cm de altura e 9.50 cm de diâmetro. Sendo vertical considera-se que não existe translação nem rotação sobre nenhum dos eixos.

Quanto às rodas, podem ser assumidas também como cilindros horizontais, ou seja, que so-freram uma rotação de π

2 no eixo do y e z, com os valores de comprimento e diâmetro definidos

acima.

No que toca à componente de inércia a massa é também definida na tabela acima, no entanto o momento de inércia necessita ser calculado. Momento de inércia, I representa a capacidade de resistência rotacional de algum objeto segundo cada um dos eixos de rotação. Para objetos com formas bem definidas como esferas ou cilindros é possível calcular o seu momento de inércia através de fórmulas gerais. No caso do cilindro uniforme (que representa a forma de todos os componentes do modelo desenvolvido) o cálculo é efetuado segundo as equações4.1e4.2.

Ix= Iy= 1 12m(3r 2_{+ h}2_{) (4.1)} Iz= 1 2mr 2 _(4.2)

De seguida foram criadas caster wheels com a função de manterem o robô equilibrado. A sua característica mais importante é conter atrito com valor muito baixo ou até mesmo desprezável de forma a não terem impacto no movimento do robô. Para tal, não foi necessária a criação de dois novos links que as representassem visto que a sua única função é de suporte. Assim foram apenas adicionadas ao link do chassis e definidos os seus valores de fricção a 0.

Com todos os elementos construidos resta apenas fazer a ligação entre esses elementos através da criação de junções ou joints. Existem vários tipos de junção, como contínua, prismática ou de revolução. São apenas necessárias duas junções, uma entre a roda esquerda e o chassis e outra entre a roda direita e o chassis. Para definir cada junção é necessário escolher o parent link (chassis) e child link (rodas esquerda e direita) e a posição do child link relativamente ao parent link. É também possível definir valores máximos de velocidade e esforço associados à junção.

Figura 4.3: Vista geral do mo-delo produzido

Figura 4.4: Vista lateral do

mo-delo produzido Figura 4.5: Vista inferior do modelo produzido

32 Criação do Simulador para PiTank

Figura 4.6: Comparação entre o robô Pololu 3pi modificado e o Modelo produzido Diversas vistas do resultado final do modelo podem ser observadas nas Figura4.3,4.4e4.5.

4.3

Controlo

Obtendo o modelo do robô, resta apenas implementar o controlo do mesmo. Este controlo será atuado sobre cada uma das joints e pode ser efetuado de diversas maneiras.

O formato URDF permite a definição de certos plugins no seu corpo de texto que permitem a alteração ou controlo de parâmetros associados ao modelo durante a simulação em Gazebo, desde aplicação de velocidade em joints a aquisição de dados de um laser simulado.

Uma das formas de controlo seria a utilização do plugins standard gazebo_ros_control que permite o controlo de velocidade, esforço ou posição de uma joint. Para tal seria necessário a criação de dois elementos do tipo transmission cuja função é servir como interface entre a junção e determinado atuador. Este atuador corresponde ao tipo de controlo pretendido definidos acima. De seguida é necessária a criação de um ficheiro YAML que define as propriedades das trans-missionsa controlar, nomeadamente, tipo de controlo, valores do controlador PID, joint associada e frequência de atuação. Resta apenas publicar as mensagens pretendidas no tópico respetivo referente a cada junção.

Outra técnica mais simples correspondente à técnica utilizada neste trabalho é a utilização de um plugin , differential_drive_controller desenvolvido para aplicações de controlo de robôs de tração diferencial, como é o caso do robô 3pi utilizado. Ao contrário da técnica anterior, utili-zando este plugin não é necessária a criação de elementos do tipo transmission devido ao controlo ser efetuado sempre em termos de velocidade linear e angular do robô diferencial. Para tal, é necessário definir valores necessários ao correto cálculo das velocidades a serem aplicadas a cada roda segundo as equações abaixo, nomeadamente distância entre rodas e diâmetro de cada roda. Adicionalmente é possível definir outros parâmetros como o nome do tópico onde será possível publicar a mensagem de controlo da velocidade de cada robô. Esta mensagem é representada em m/s e rad/s para a velocidade linear e angular, respetivamente.

4.4 Validação e Resultados 33 v(t) =vl+ vr 2 (4.3) w(t) = vr− vl d (4.4) vr= d 2w(t) + v(t) (4.5) vr= v(t) − d 2w(t) (4.6)

d corresponde à distância entre rodas, v(t) e w(t) são as velocidades linear e angular em tempo contínuo, respetivamente e vre v − l as velocidades do motor da roda direita e esquerda,

respeti-vamente.

A velocidade dos motores dos 3pi reais é controlada através de PWM variando o duty-cicle da onda de controlo de alimentação de cada motor. Este duty-cicle apresenta uma resolução de 8 bits, sendo que 255 representa o valor de velocidade máxima (100% duty-cicle) e 0 representa o robô estacionário (0% duty-cicle).

No sistema real, cada robô é então controlado pelo valor do duty-cicle de cada motor. Estes valores correspondem a 8.2% para velocidade linear e 24.6% para velocidade angular. No en-tanto, no sistema simulado são utilizados diretamente os valores de velocidade linear e angular em unidades SI, sendo necessária a conversão entre duty-cicle e as respetivas unidades SI.

Em condições normais, num ambiente plano, a velocidade máxima de um 3pi é cerca de 1m/s. Nesta condições, é possível considerar que a reta que relaciona o duty-cicle com a velocidade do robô é linear. Desta forma é utilizada a equação4.7 para o cálculo da velocidade de cada motor (m/s) em função do número de bits que representam o duty-cicle.

vm/s=

vvalue

255 (4.7)

São obtidos os valores de 0.082m/s e 2.734rad/s para velocidade linear e angular, respetiva-mente.

4.4

Validação e Resultados

Criado e modelo e efetuados todos os cálculos para controlo do mesmo é necessária a validação dos resultados.

Para tal, é importante verificar se o modelo criado responde corretamente às publicações de controlo de velocidade no tópico ao qual subscreve. Assim, será analisada a resposta do sistema a certas mudanças de velocidade, quer num movimento de rotação para a esquerda, direita, frente e trás, feita uma análise de trânsito de dados e comparadas imagens relativas ao Gazebo e mapa de jogo para diferentes situações.