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.
34 Criação do Simulador para PiTank
Nas figuras4.7 e 4.8 estão representados as imagens referentes ao Gazebo e mapa de jogo para diferentes estados e tipos de jogo. Na Figura4.7está presente a posição inicial de 4 robôs e as suas respetivas orientações. Na Figura4.8estão apenas presentes 2 robôs num estado de jogo quase final. É possível ver interações entre elementos como balas a serem disparadas pelo jogador 2 e uma parede destruída. Como é possível ver as posições dos robôs e conversões de coordenadas SI para pixeis apresentam-se corretas.
As variáveis a analisar serão o valor da mensagem de controlo publicada no tópico /robot1/cmd_vel e o valor da velocidade real do modelo representado no tópico /gazebo/model_states[1].
As figuras seguintes representam os gráficos comparativos para as situações descritas acima. No caso do movimento de rotação é visível que a velocidade de rotação em ambos os sentidos tende para o valor de velocidade pretendida com um tempo de estabelecimento de cerca de 0.15 segundos o que é mais que suficiente para as situações presentes durante um jogo. Não apresenta overshoot, o que é fator positivo visto que não é pretendido que o robô apresente acelerações elevadas no início do seu movimento devido ao risco de instabilidade. De uma forma geral, pode- se considerar que o sistema cumpre os objetivos no que diz respeito à velocidade angular.
Por outro lado, os resultados do movimento em linha reta para teste da velocidade linear não foram perfeitos. Devido ao baixo valor de velocidade pretendido, o tempo de estabelecimento é bastante baixo, na ordem das centésimas de segundo. Contudo, na primeira subida da curva de velocidade existe um erro entre o valor de referência e o valor obtido na casa dos 0.01m/s apenas estabilizando no valor correto numa segunda subida da curva de velocidade. Apesar deste comportamento não ser o esperado, visto o valor estabilizar relativamente rápido e o erro em relação ao valor de referência ser praticamente nulo, estes resultados podem ser aceites.
De seguida será analisado o trânsito de dados relativos à simulação num exemplo de uma partida simulada entre dois jogadores humanos. Nestas condições, apenas os nós /game_engine, /gazeboe /key_input serão relevantes visto que os restantes nós são apenas inerentes quer ao sis- tema real ou IA.
A Figura4.13mostra a UI modificada para a possibilidade de escolha de simulação. É possível ver os botões "Setup Game + Autodetect", responsável por criar todos os elementos de jogo e no caso do sistema real reconhecer quais robôs estão presentes no campo, e o botão "Start". Estes botões funcionam utilizando a funcionalidade de QT de signals and slots que permite enviar um sinal para determinado trecho de código (slot) quando determinado evento acontece (neste caso, o premir dos botões).
Quando o botão "Setup Game + Autodetect"é premido, em vez da deteção dos robôs no campo (sistema real) são adicionados à cena de simulação do Gazebo um número de robôs definidos por "Number of Robots Sim:"utilizando o serviço SpawnModel do pacote nativo do Gazebo ga- zebo_msgs. Este serviço permite definir os valores iniciais de certo modelo de robô a simular como posição e orientação e criar uma instância desse modelo no Gazebo.
De seguida é necessário premir o botão "Start"para começar o jogo. Quando este botão é pre- mido é iniciada a iteração base do sistema. Esta iteração tem por base a utilização de "callback
4.4 Validação e Resultados 35
36 Criação do Simulador para PiTank
4.4 Validação e Resultados 37
Figura 4.9: Gráfico comparativo da velocidade linear em função do tempo num movimento em linha reta para a frente
Figura 4.10: Gráfico comparativo da velocidade linear em função do tempo num movimento em linha reta para trás
functions"em ROS. Sempre que uma nova mensagem referente à posição de cada robô no simu- lador (publicada no tópico /gazebo/model_states) é atualizada, são convertidos esses valores de unidades SI para pixeis e armazenados numa estrutura de dados referente a cada um dos robôs em jogo.
38 Criação do Simulador para PiTank
Figura 4.11: Gráfico comparativo da velocidade angular em função do tempo numa rotação para a esquerda
Figura 4.12: Gráfico comparativo da velocidade angular em função do tempo numa rotação para a direita
Simultaneamente, existem diferentes threads em execução, nomeadamente, threads do tipo QT referentes à atualização do movimento dos elementos de jogo e respetiva impressão no mapa de jogo (por overide da função paint pertencente à classe QObject nativa do framework QT). Foi criado também um thread relativo aos controlos dos jogadores através do teclado.
4.4 Validação e Resultados 39
Figura 4.13: User Interface Melhorada do 3PiGaming
Cada jogador utiliza o teclado para comandar o seu robô. Para tal, o nó /key_input está constan- temente a ler o input dos utilizadores e a enviar essa informação para o motor de jogo publicando nos tópicos /shootandturbo e /vel. O motor de jogo converte o valor da velocidade para unidades SI , calcula se a ordem é válida, por exemplo, se um jogador tentar atravessar uma parede o motor de jogo impede que tal aconteça e publica esse valor no tópico /robotx/cmd_vel subscrito pelo respetivo modelo associado no Gazebo que por sua vez efetua o movimento do robô.
Capítulo 5
Inteligência Artificial para PiTank
5.1
Planeamento de Caminhos
Relativamente ao planeamento de caminhos foi escolhida a técnica de decomposição em célu- las aproximadas de tamanho fixo e como algoritmo de pesquisa o algoritmo A*. Esta escolha foi feita tendo em conta alguns requisitos do sistema bem como características do mesmo.
Em primeiro lugar foi tido em conta o dinamismo do mapa de jogo, sendo que o algoritmo A* sem modificações apresenta melhores resultados quando menos dinâmico for o sistema. O mapa do PiTank é apenas constituído por paredes estacionárias que podem ser eventualmente destruídas e por um determinado número de robôs, ou seja, apresenta um baixo grau de dinamismo.
Outro fator importante é a complexidade do algoritmo de identificação do caminho, pois sendo o PiTank um sistema em tempo real, será necessária a existência de algum tipo de controlo do tempo de execução de determinada ação e a técnica de decomposição do mapa em células permite exatamente isso, variando o tamanho de cada célula e consequentemente o número de células.
Um dos pontos fortes do algoritmo A* é o facto da utilização de algum valor de heurística, como distância euclidiana, para redução do tempo de pesquisa e obtenção de um resultado ótimo. O facto de a posição dos robôs no PiTank, tanto no sistema real, como no sistema simulado estar bem definido (através da análise das AprilTags ou coordenadas publicadas pelo Gazebo) promove adicionalmente a utilização de algoritmos de heurística.
Foi escolhido o algoritmo A* em vez de outros algoritmos baseados em pesquisa, como Gre- edy ou Dijkstra por apresentar a vantagem de descobrir a solução ótima.
O primeiro passo será a divisão do mapa em células com tamanhos semelhantes. Assim, o comprimento e largura (em número de células) de um certo mapa poderá ser calculado através das equações seguintes. sizex=tamanhodocampoemx(pixeis) tamanhodecadacelula + 1 (5.1) sizey=tamanhodocampoemy(pixeis) tamanhodecadacelula + 1 (5.2) 41
42 Inteligência Artificial para PiTank
Figura 5.1: Mapa divido em células com ta- manho 20 e células inválidas
Figura 5.2: Mapa divido em células com ta- manho 50 e células inválidas
Escolhido o tamanho do mapa de células é de seguida criado um vetor bidimensional do tipo booleano em que a cada elemento de x e y (determinada célula) corresponde um valor de 1, se a célula estiver livre, ou um valor de 0 se a célula estiver ocupada.
É determinado que cada célula que contenha uma parede é considerada uma célula ocupada, mesmo que também contenha algum espaço livre. Da mesma forma, tendo em conta que o raio de um 3pi representado em pixeis corresponde a 36, será considerado que todas as células a uma distância de 40 (raio do robô + 4 pixeis de tolerância) pixeis ou menos serão também consideradas ocupadas.
As figuras5.1e5.2contêm a representação gráfica de um mapa com tamanho de célula 50 e 20, respetivamente. A vermelho correspondem as zonas ocupadas com pontos azuis sobre cada célula. Ao contrário das representações normalmente feitas neste tipo de técnica de decomposição, em que as coordenadas de uma célula representam o seu ponto central, é assumido que a interseção entre as linhas horizontais e verticais representam essas mesmas coordenadas. Desta forma, os todos os outros pontos correspondem às coordenadas de cada uma das células livres, ou seja, células que um robô pode ocupar.
Obtendo o mapa resta apenas a criação de uma função que implemente o algoritmo A*. Esta função necessita apenas do ponto de partida e do ponto de destino pretendidos. No entanto, a cada nó neste tipo de algoritmos está inerente não só as suas coordenadas (em células) mas também as coordenadas do seu nó pai (nó imediatamente anterior no caminho calculado) como forma de ser possível obter um caminho corretamente ordenado de nós e também o valor da heurística associado a cada nó. Para tal, foi criado uma estrutura Node com todas essas informações a ela associadas.
Relativamente ao algoritmo em si, é em primeiro lugar criado e inicializado um vetor de Nodes com dimensões semelhantes ao mapa de células, que irá representar a lista aberta de nós. Para a lista fechada basta a criação de um vetor bidimensional booleano.
É então corrido o algoritmo processando todos os nós através do cálculo do valor de heurís- tica e do nó pai associados a cada nó relevante da lista aberta até a mesma ficar vazia (destino encontrado ou caminho impossível para o mesmo) e criado um vetor de nós ordenados referentes ao caminho calculado.
5.1 Planeamento de Caminhos 43
Figura 5.3: Caminho 1 descoberto pelo al- goritmo A*
Figura 5.4: Caminho 2 descoberto pelo al- goritmo A*
Para a determinação do valor de heurística, como é pretendido que o algoritmo A* encontre o menor caminho possível até ao destino, foi utilizada a distância de cada nó ao nó destino. Esta distância pode ser calculada de várias formas, sendo as mais utilizadas a distância euclidiana (equação5.3) e distância de Manhattan (equação5.4).
dist= q
(x f − xi)2+ (y f − yi)2 (5.3)
dist= |x f − xi|+|y f − yi| (5.4) Tendo em conta que no PiTank não existe restrição de movimento, no sentido em que é possível mover o robô para qualquer direção (desde que esteja livre) a distância euclidiana é mais apropri- ada em certas circunstâncias, nomeadamente caminhos entre células diagonais entre si porque a distância de Manhattan apresentaria um custo maior do que o real. Nas figuras5.3 e 5.4 estão representados alguns caminhos descobertos pelo algoritmo.
Apesar de apresentar resultados positivos, a implementação do algoritmo ainda poderá ser melhorada. Em casos de espaços abertos como é ilustrado na figura5.3, entre os pontos inicial e final estão presentes 5 nós. No entanto, não existindo obstáculos entre eles, é possível desprezar estes nós e não só minimizar ainda mais a distância percorrida como diminuir o número de nós a percorrer o que consequentemente melhora a eficiência do algoritmo. Nas figuras5.5e5.6estão representados os resultados do algoritmo modificado para os mesmos caminhos da figura5.3 e
44 Inteligência Artificial para PiTank
Figura 5.5: Caminho 1 descoberto pelo al- goritmo A* melhorado
Figura 5.6: Caminho 2 descoberto pelo al- goritmo A* melhorado
5.4.
Obtendo o vetor dos nós pertencentes ao caminho a percorrer resta apenas criar uma função que percorra a mesma. Para tal, foi implementada uma simples função GoToXY. É composta por três estados.
O estado inicial ROTATE garante a rotação do robô para o ponto de destino. Esta rotação pode ser efetuada para a esquerda ou direita, dependendo do sentido de rotação mais rápido. Este sentido pode ser descoberta a partir do elemento z do produto vetorial entre o vetor referente à orientação do robô vR e o vetor que define a direção entre o robô e o ponto final vRF. Se este
valor for positivo o menor tempo de rotação corresponde à direita e se for negativo corresponde à esquerda. É então efetuada a rotação nesse sentido até à diferença entre o ângulo do robô e o ângulo do vetor vRF (erro_theta) for inferior a uma constante MAX_ETF, onde ocorre a transição
para o estado seguinte.
O estado seguinte corresponde ao estado de translação TRANSL responsável por movimentar o robô em linha reta até ao ponto de destino. É assumida a chegada ao ponto de destino quando a distância a esse ponto for inferior à constante ERRO_DIST. Neste estado é não só definida a velo- cidade linear correspondente ao valor definido no Capítulo 4, como também é definida uma certa velocidade angular erro_theta * -GAIN_FWD. Isto garante que se o robô se desviar do caminho correta por alguma razão como deslizamento de uma roda, esse caminho será corrigido aplicando uma velocidade angular no sentido oposto de erro_theta. Quando o destino é atingido é feita a transição para o último estado STOP que simplesmente para o movimento do robô até ser pedida
5.1 Planeamento de Caminhos 45
uma nova ação.
Para validação do planeamento de caminhos serão vistos não só os caminhos escolhidos pelo algoritmo, bem como analisada a posição e orientação do robô em função do tempo durante o caminho.
Será comparado o desempenho do algoritmo A* normal e do modificado.
As figuras seguintes ilustram os resultados obtidos para os caminhos definidos pelas figuras
5.3e5.4assumindo tamanho de célula igual a 50 pixeis.
(a) Posição e ângulo do robô em função do tempo para caminho 1 com A* normal
46 Inteligência Artificial para PiTank
(a) Posição e ângulo do robô em função do tempo para caminho 2 com A* normal