Geração de trajetória nos robôs CAMBADA

(1)

Universidade de Aveiro Departamento deElectrónica, Telecomunica¸cões e Informática 2013

Paulo Alexandre

da Silva Soares

(2)

(3)

Universidade de Aveiro Departamento deElectrónica, Telecomunica¸cões e Informática 2013

Paulo Alexandre

da Silva Soares

Gera¸

c˜

ao de trajet´

oria nos robˆ

os CAMBADA

Disserta¸cão apresentada à Universidade de Aveiro para cumprimento dos requisitos necessários à obten¸cão do grau de Mestre em Engenharia de Computadores e Telemática, realizada sob a orienta¸cão cient´ıfica do Doutor Pedro Nicolau Faria da Fonseca (orientador), Professor Auxiliar do Depar-tamento de Eletrónica Telecomunica¸cões e Informática da Universidade de Aveiro e do Doutor António José Ribeiro Neves (coorientador), Professor Auxiliar do Departamento de Eletrónica Telecomunica¸cões e Informática da Universidade de Aveiro.

(4)

(5)

o j´uri / the jury

presidente / president Prof. Doutor Luis Filipe de Seabra Lopes

Professor Associado da Universidade de Aveiro

vogais / examiners committee Prof. Doutor Paulo Jos´e Cerqueira Gomes da Costa

Professor Auxiliar da Universidade de Porto

Prof. Doutor Pedro Nicolau Faria da Fonseca

(6)

(7)

agradecimentos Gostaria de agradecer a todos os que me acolheram o longo do meu percurso académico nesta excelente institui¸cão. Em especial ao grupo do projeto CAMBADA que me recebeu como filho da casa durante este último ano. Quero também agradecer ao meu orientador Pedro Fonseca e coorientador António Neves pela paciência que tiveram para com a minha pessoa ao longo deste ano. Agrade¸co também aos meus amigos e fam´ılia que sempre estiveram ao meu lado a dar-me for¸ca nos momentos mais dif´ıceis. Por ´

ultimo agrade¸co aos meus pais por todo o sacrif´ıcio que fizeram para eu atingir este objetivo.. . .

(8)

(9)

Resumo A robótica é uma área de estudo em grande expansão hoje em dia. Nesta disserta¸cão é abordado um problema relativo a robótica móvel, mais con-cretamente a gera¸cão de trajetórias para os robôs da equipa CAMBADA. Os robôs da equipa CAMBADA são robôs de futebol robótico com a ca-pacidade de efetuar movimentos holonómicos. Isto da-lhes a capacidade de se movimentarem em qualquer dire¸cão independentemente da sua ori-enta¸cão.Os movimentos dos robôs são conseguidos atualmente através da aplica¸cão de controladores PID baseados na distância a que um robô está do destino. Esta solu¸cão, apesar de eficaz, não permite ter controlo sobre a velocidade a que o robô se desloca ou da velocidade a que este atinge o destino. Nesta disserta¸cão serão abordados estes problemas de controlo com a implementa¸cão de duas solu¸cões. Uma será a implementa¸cão de um gerador de trajetórias que, previamente, calculará todos os pontos da trajetória do robô, seguindo um determinado perfil de velocidade. Adicio-nalmente será implementado um planeador de trajetórias que servirá para desviar o robô de obstáculos que lhe possam surgir no caminho do robô.

(10)

(11)

Abstract Robotics is a booming field of study nowadays. This dissertation addresses a problem related with mobile robotics, namely the trajectory generation for the robots of the CAMBADA project. The Team CAMBADA is a robotic soccer team with the ability to perform holonomic movements. This gives them the ability to move in any direction regardless of their orientation. The movements of the robots are currently achieved through the application of PID controllers based on the distance that a robot is from the destination. Although this solution is effective it does not allow the control of the speed which the robot moves, as well as, the speed which it reaches the desti-nation. These control problems will be addressed in this dissertation with the implementation of two solutions. One will be the implementation of a trajectory generator, which previously calculates all points of the trajectory of the robot, following a given velocity profile. The other one will be the implementation of a trajectory planner, with the aim to deflect the robot from obstacles that might appear in the path of the robot.

(12)

(13)

Conte´

udo

Conte´udo i

Lista de Figuras iii

1 Introdu¸c˜ao 1

1.1 Robˆo CAMBADA . . . 1

1.2 Objetivos . . . 3

1.3 Estrutura da tese . . . 3

2 Projecto CAMBADA 5 2.1 Plataforma CAMBADA – Hardware . . . 5

2.1.1 Base do robot . . . 6

2.1.2 Movimento do Robˆo . . . 6

2.1.3 Grabber . . . 7

2.1.4 Kicker . . . 9

2.2 Plataforma CAMBADA – Software . . . 9

2.2.1 Base Dados em Tempo Real (RTDB) . . . 9

2.2.2 Comunica¸c˜ao (comm) . . . 10

2.2.3 Comunica¸c˜oes com o Hardware (HWcomm) . . . 10

2.2.4 Vis˜ao . . . 11 2.2.5 Agente . . . 11 Loop . . . 13 Integrator . . . 13 Strategy . . . 13 Roles e Behaviours . . . 13

3 Movimento e Gera¸c˜ao de Trajet´orias no CAMBADA 15 3.1 Rodas Omni . . . 15

3.2 Movimento Holon´omico . . . 16

3.2.1 Rampas de acelera¸c˜ao e desacelera¸c˜ao . . . 17

3.3 Movimento antigo dos CAMBADA . . . 17

3.4 Gerador de trajet´orias . . . 18

3.4.1 Proposta . . . 18

3.4.2 Problema . . . 18

3.4.3 Calculo da trajet´oria . . . 18

3.4.4 Heur´ıstica do GT . . . 20

(14)

3.4.5 Movimentos em curva usando o GT . . . 23

4 Implementa¸c˜ao de um modelo de GT no CAMBADA 27 4.1 Implementa¸c˜ao do GT . . . 27

4.2 Estudo do funcionamento do GT . . . 28

4.3 Planeador de trajet´orias . . . 32

4.3.1 Planeador de desvio de obstaculos . . . 32

4.3.2 Desvio de obst´aculos . . . 32

4.3.3 Mapa de ocupa¸c˜ao . . . 33

Implementa¸c˜ao . . . 33

4.3.4 Preenchimento dos obst´aculos . . . 33

Implementa¸c˜ao . . . 34

A* . . . 34

Calculo do melhor caminho . . . 35

4.3.5 Indicar os pontos do plano ao GT . . . 35

5 Resultados Experimentais 37 5.1 Testes de posi¸c˜ao . . . 37

5.1.1 Testes repetitivos . . . 37

6 Conclus˜ao e trabalho futuro 45 6.1 Trabalho futuro . . . 45

(15)

Lista de Figuras

1.1 Imagens de alguns robôs usados e desenvolvidos na UA. Em a) uma imagem do robô NAO desenvolvido pela empresa ADEBARAN e usado na UA para futebol robótico. Em b) uma imagem do robô CAMBADA@HOME desenvolvido na UA com o objetivo de ser um robô de servi¸co para apoio a pessoas. Em c) podemos ver um robô CAMBADA que será objeto de estudo nesta disserta¸cão. 2 1.2 Duas versões dos robôs do projeto CAMBADA. Em a) a versão utilizada entre

2009 e 2012 e em b) a versão atual do robô, já utilizada nas competi¸cões de 2013. 2 2.1 Momento de um jogo da MSL entre a equipa CAMBADA e a equipa 5DPO da

universidade do Porto. . . 6

2.2 Bases dos novos robˆos CAMBADA. . . 6

2.3 Base do Robˆo em detalhe . . . 7

2.4 Coloca¸c˜ao dos motores e rodas nos Robˆos CAMBADA de modo a obter movi-mento omni-direcional. . . 7

2.5 Grabber antigo dos robˆos CAMBADA. . . 8

2.6 Novo Grabber dos robˆos CAMBADA. . . 8

2.7 Kicker dos novos robˆos CAMBADA. . . 9

2.8 Arquitetura geral do software do projeto CAMBADA. . . 10

2.9 Processo comm utilizado para a partilha de informa¸c˜ao entre os agentes CAM-BADA. . . 11

2.10 Processo Hwcomm respons´avel pela comunica¸c˜ao com o Hardware. . . 11

2.11 Imagem obtida pela câmara omnidirecional do robô CAMBADA e respetivas imagens depois de processadas. Em a) encontramos a imagem real obtida pelo robô, em b) a mesma imagem depois da segmenta¸cão de cor e em c) a posi¸cão dos objetos de interesse detetados na imagem. . . 12

2.12 Estrutura do processo do Agente. . . 12

2.13 Exemplo de uma forma¸c˜ao dos robˆos CAMBADA. . . 13

3.1 Exemplo de uma roda Omni . . . 15

3.2 Coloca¸c˜ao das rodas na base do robˆo CAMBADA. . . 16

3.3 Exemplos de movimentos obtidos de acordo com as velocidades aplicadas aos motores. Em a) verificamos a rota¸c˜ao sobre o centro do robot, em b) o movi-mento em frente e em c) movimovi-mento lateral do robˆo ([1]). . . 16

3.4 Modelo do movimento dos robˆos CAMBADA. . . 18

3.5 Gr´afico de velocidade do movimento trapezoidal . . . 19

(16)

3.7 Grafico dos vetores de velocidade vi e vf. . . 20

3.8 Calculo Valor k . . . 22

3.9 Fase interm´edia do calculo de vp . . . 22

3.10 Degenera¸c˜ao do Movimento . . . 23

3.11 Gr´afico final do GT para os pontos pi,pa,pw e pf . . . 25

3.12 Gr´afico final dos pontos calculados pelo GT . . . 25

3.13 Exemplo da divis˜ao de uma trajet´oria curva em segmentos de reta. . . 26

4.1 Arquitetura antiga do software do Agente . . . 27

4.2 Nova arquitetura do Agente . . . 28

4.3 Compara¸cão da posi¸cão do robô estimada e a posi¸cão calculada pelo GT. . . 29

4.4 Teste repetitivo elaborado para testar a convergˆencia do GT. . . 29

4.5 Movimento imposs´ıvel para o GT pois o vetor de velocidade no destino encontra-se na dire¸c˜ao oposta ao movimento. . . 30

4.6 Poss´ıvel solu¸c˜ao para resolver a incompatibilidade do movimento da Figura 4.5. 31 4.7 C´alculo do centro de um c´ırculo a partir de 3 pontos. . . 31

4.8 Modelo da fase final do agente incluindo o GT e o planeador . . . 32

4.9 Exemplo da divisão do campo em células com uma resolu¸cão de 8 por 8 células 33 4.10 Exemplo de preenchimento do mapa de ocupa¸cão num determinado ciclo. As bolas representam posi¸cões reais dos robôs. As cores vermelho, laranja e verde representam células ocupadas, células de poss´ıvel ocupa¸cão no futuro e células livres, respetivamente. . . 34

4.11 Poss´ıvel solu¸c˜ao obtida pelo A*. . . 36

5.1 Compara¸cão da posi¸cão do robô estimada e a posi¸cão calculada pelo GT. . . 38

5.2 Gráfico de posi¸cão para trajetória repetitiva. . . 38

5.3 Detalhe da Figura 5.2 nos pontos problem´aticos do GT. . . 39

5.4 Leitura da velocidade por parte do GT referente ao gr´afico apresentado na Figura 5.2 . . . 40

5.5 Exemplo de teste efetuado ao GT com a trajet´oria repetitiva, depois de efetuar alguns melhoramentos na leitura da velocidade. . . 41

5.6 Exemplo de teste efetuado ao GT com a trajet´oria repetitiva, depois de efetuar alguns melhoramentos na leitura da velocidade, aproximada num dos pontos de Pa. . . 41

5.7 Exemplo de teste efetuado ao GT com a trajetória repetitiva, depois de efetuar alguns melhoramentos na leitura da velocidade e constru¸cão de trajetória. . . 42

5.8 Detalhe da figura 5.7 nos pontos problem´aticos do GT. . . 42

5.9 Leitura da velocidade por parte do GT referente ao gr´afico apresentado na Figura 5.7. . . 43

5.10 Exemplo da repeti¸cão da trajetória múltiplas vezes. . . 43

5.11 Exemplo do GT para acelera¸c˜oes e velocidades patamar mais elevadas. . . 44

(17)

Cap´ıtulo 1

Introdu¸

c˜

ao

A robótica é uma área que se encontra em grande expansão. Depois de grandes desenvol-vimentos na área da robótica industrial, as aten¸cões centram-se agora na robótica móvel e na ´

area da inteligência artificial. Em qualquer uma destas áreas de estudo encontram-se barreiras tecnológicas por resolver. Esta disserta¸cão aborda problemas ligados à robótica móvel. Esta ´

area tem como base de estudo a inclus˜ao de robˆos no ambiente dos humanos e a forma como estes se deslocam.

Na Universidade de Aveiro, nomeadamente no Departamento de Engenharia Eletrónica e Informática (DETI) e no Instituto de Engenharia Eletrónica e telemática de Aveiro (IEETA) estão a decorrer diversos projetos em robótica móvel. Entre estes projetos estão o CAMBADA, CAMBADA@HOME e o CAMBADA@SPL. Algumas imagens dos robôs desenvolvidos na UA estão apresentadas na Figura 1.1.

Estes projetos focam diversas aplica¸cões, desde a robótica multi-agente, robótica de servi¸co, até aos robôs humanoides. Em termos tecnológicos são também todos eles diferentes, sendo que, devido à natureza do ambiente ou dos objetivos do projeto em questão, estes podem usar rodas para se deslocarem, como no caso do CAMBADA e CAMBADA@HOME, ou então usar um movimento antropomórfico no caso dos robôs do projeto CAMBADA@SPL.

Esta disserta¸cão foca o problema do movimento dos robôs CAMBADA. Dado que estes robôs se deslocam a uma velocidade considerável e necessitam de fazer movimentos bruscos dada a aplica¸cão onde são usados (futebol), são necessários algoritmos de controlo eficientes. Este documento propõe um conjunto de algoritmos que se destinam à gera¸cão de trajetórias de forma a determinar o movimento dos robôs.

1.1 Robˆ

o CAMBADA

O robô CAMBADA (Figura 1.2) é um robô criado na UA, que participa na Liga de robôs médios de futebol robótico do Robocup. Este robô tem capacidade de chutar, passar e de se deslocar livremente num meio semelhante a um campo de futebol. Com a análise do meio é capaz de tomar decisões e de atuar cooperativamente para atingir o objetivo final, marcar golos.

O movimento dos robôs CAMBADA, apesar de todos os avan¸cos feitos no projeto, continua a ser uma das áreas a necessitar de melhoramentos. Hoje em dia, estes conseguem deslocar-se rapidamente no campo (atingindo velocidades de 3 m/s) e com grande precisão de uma posi¸cão A para uma posi¸cão B. Ao contrário do que o movimento aparenta, existe pouco

(18)

a) b) c)

Figura 1.1: Imagens de alguns robôs usados e desenvolvidos na UA. Em a) uma imagem do robô NAO desenvolvido pela empresa ADEBARAN e usado na UA para futebol robótico. Em b) uma imagem do robô CAMBADA@HOME desenvolvido na UA com o objetivo de ser um robô de servi¸co para apoio a pessoas. Em c) podemos ver um robô CAMBADA que será objeto de estudo nesta disserta¸cão.

a) b)

Figura 1.2: Duas versões dos robôs do projeto CAMBADA. Em a) a versão utilizada entre 2009 e 2012 e em b) a versão atual do robô, já utilizada nas competi¸cões de 2013.

controlo em movimentos com uma trajetória curva e não é poss´ıvel especificar a velocidade de chegada ao destino. Por outro lado, também não existe nenhum controlo sobre que pontos do

(19)

campo serão utilizados na desloca¸cão entre dois pontos. Isto acontece pois, na versão atual do projeto, não existe nenhum planeamento de caminho, nem planeamento de trajetória entre dois pontos. O movimento atual consiste apenas na defini¸cão de um ponto destino ao qual é aplicado uma fun¸cão para conversão de distância para velocidade. Para evitar a existência de movimentos violentos, a potência a aplicar aos motores no in´ıcio e final do movimento é controlada por rampas de acelera¸cão, que aumentam ou diminuem a potência a aplicar progressivamente ao longo do tempo.

1.2 Objetivos

Com o evoluir do projeto CAMBADA a exigência dos movimentos torna-se maior. Esta exigência faz com que surja a necessidade de se obter um maior controlo da velocidade do robô. Movimentos como rematar enquanto o robô se desloca, mudan¸cas rápidas de dire¸cão e de velocidade e defini¸cão de movimentos curvil´ıneos exigem a necessidade da gera¸cão de uma trajetória prévia. Para além da gera¸cão de trajetórias (GT ) existe a necessidade de desviar os robôs de obstáculos que aparecem pelo caminho (equipa adversária e membros da mesma equipa), sem que o mesmo necessite de efetuar movimentos violentos, ou seja, combinar o maior controlo entre a trajetória com a defini¸cão previa de um caminho calculado.

Esta disserta¸cão propõe duas implementa¸cões para colmatar as limita¸cões acima apresen-tadas. Uma será a implementa¸cão de um GT ( entre dois pontos e outra será a implementa¸cão de um planeador de trajetórias, com capacidade de desviar o robô de obstáculos que possi-velmente obstruam o caminho do mesmo para o destino. Com estas duas implementa¸cões espera-se obter um maior controlo sobre os movimentos do robô.

1.3 Estrutura da tese

Esta disserta¸cão tem a seguinte estrutura. No Cap´ıtulo 2 apresenta-se o projeto CAM-BADA e identifica-se os pontos chave tanto do software como do hardware. No Cap´ıtulo 3 aborda-se a solu¸cão existente para o movimento dos robôs e introduz-se o conceito de GT para resolver as falhas do mesmo. O Cap´ıtulo 4 apresentará o trabalho desenvolvido ao longo desta disserta¸cão, desde a implementa¸cão e corre¸cão de algumas falhas do algoritmo de gera¸cão de trajetórias como a necessidade de implementa¸cão de um planeador de trajetórias. No Cap´ıtulo 5 é feita uma analise dos resultados obtidos com a solu¸cão GT. Para finalizar, no Cap´ıtulo 6 apresentam-se conclusões sobre o trabalho desenvolvido e eventuais melhorias para o futuro.

(20)

(21)

Cap´ıtulo 2

Projecto CAMBADA

O projeto CAMBADA da Universidade de Aveiro (UA) é uma equipa de futebol robótico da chamada Middle Size League (MSL) ou Liga de Tamanho Médio do RoboCup, que deu os seus primeiros passos em Outubro de 2003. Este surgiu como um projeto financiado pela Funda¸cão para a Ciência e a Tecnologia (FCT) e tinha como objetivo fazer investiga¸cão na ´

area da robótica multi-agente [2]. Ao longo dos anos, este projeto arrecadou vários prémios a n´ıvel nacional e internacional, sendo de destacar o primeiro lugar no campeonato do mundo conquistado em 2008 em Suzhou China e os primeiros lugares alcan¸cados de 2007 até 2012 no Festival Nacional de Robótica. Além dos resultados obtidos em competi¸cão este projeto tem sido fonte de inúmeras publica¸cões cient´ıficas e uma excelente plataforma de ensino para os alunos do DETI.

A liga em que competem estes robôs é a MSL (Figura 2.1). Esta impõe as seguintes regras para o design dos robô:

• At´e 5 robˆos por equipa.

• M´axima Largura, Altura, Peso: 50cm, 80cm, 40 kg.

• Totalmente autónomos: comunica¸cão entre robôs e poss´ıvel através da rede sem fios da organiza¸cão, sendo que não e permitido enviar informa¸cão para os robôs externamente. • Campo de jogo: 18 x 12 metros.

• Jogo: 2 partes de 15 min cada.

• Cores: verde para o campo, branco para as linhas do campo e preto para o robˆos.

2.1 Plataforma CAMBADA – Hardware

A plataforma CAMBADA foi atualizada no ano de 2013 com a constru¸cão de 6 novos robôs (Figura 2.2). Estes foram constru´ıdos completamente de raiz, aproveitando apenas os motores, controladores de baterias e espelhos dos anteriores robôs. Apesar desta plataforma ser completamente nova, usa um conceito muito simples de constru¸cão que já se verificava na anterior, o conceito de constru¸cão modular. Este tipo de constru¸cão permite um melhor acesso aos componentes de hardware em caso de necessidade de repara¸cão ou substitui¸cão.

(22)

Figura 2.1: Momento de um jogo da MSL entre a equipa CAMBADA e a equipa 5DPO da universidade do Porto.

Figura 2.2: Bases dos novos robˆos CAMBADA.

2.1.1 Base do robot

O novo robô é constru´ıdo com uma base triangular (Figura 2.3), ao contrário do anterior que tinha uma base redonda. Isto deve-se ao facto de a equipa querer aproveitar a superf´ıcie lateral plana para desviar a bola. Isto torna-se vantajoso pois abre um novo leque de op¸cões para jogadas, sem que os robô tenham de estar em controlo da bola para a desviar para um lugar pretendido. O facto de os robôs poderem disputar a bola com o corpo torna-os mais rápidos, não tendo de estar constantemente a tentar “agarrar a bola” para a jogar, processo que necessita que o robô execute rota¸cões sobre ele próprio ou sobre a bola.

2.1.2 Movimento do Robˆo

O movimento do robô CAMBADA é omni-direcional, isto é, consegue movimentar-se em qualquer dire¸cão e rodar sobre ele próprio. Este tipo de movimento é perfeito para

(23)

Figura 2.3: Base do Robˆo em detalhe

objetivo do projeto, pois como estes robô têm como objetivo jogar futebol, as posi¸cões que o robôs quer atingir em campo estão em constante movimento, podendo de um momento para o outro mudar totalmente de dire¸cão. Sendo assim, os robôs necessitam de poder mudar o mais rapidamente poss´ıvel a dire¸cão de movimento. Uma forma eficiente de um robô se movimentar entre dois pontos alterando a sua rota¸cão enquanto se desloca é utilizando movimento holonómico. Este tipo de movimento pode ser obtido através da coloca¸cão de três rodas especiais separadas por 120 graus (Figura 2.4). A constru¸cão apenas com três motores, apesar de ser mais lento que a coloca¸cão de quatro rodas a 90 graus, tem a vantagem de não necessitar de uma superf´ıcie plana para funcionar. Para além disso, este tipo de constru¸cão favorece a constru¸cão do Grabber do robô que será explicado mais à frente.

Figura 2.4: Coloca¸c˜ao dos motores e rodas nos Robˆos CAMBADA de modo a obter movimento omni-direcional.

2.1.3 Grabber

O Grabber é o elemento f´ısico do robô CAMBADA que permite o controlo da bola. Este e montado na frente do robô e tem como objetivo ajudar a manter a bola encostada ao corpo do robô enquanto executa determinada tarefa. Segundo as regras, o robô não pode prender a bola, isto é, a bola tem que ser facilmente solta caso haja algum contacto com outro robô. Por outro lado, caso o robô se desloque com a bola controlada, esta tem de se encontrar em rolamento. Caso esta se desloque sem rolar é assinalada falta.

(24)

robôs CAMBADA. Na versão anterior dos CAMBADA os Grabbers eram constitu´ıdos apenas por um motor com uma roda na ponta (Figura 2.5). Esta solu¸cão permitia, através da friçcão originada pela roda na bola, “segurar” a bola e efetuar movimentos muito simples para a frente com a bola controlada. Caso se tentasse efetuar um movimento mais rápido em curva para a frente ou se tentasse efetuar um movimento para trás ou lateral havia um elevado risco desta se perder. Para além disso, a rece¸cão desta era bastante complicada pois não havia forma de amortecer a bola à chegada e de a redirecionar para a frente do robô. Bastava a bola vir um pouco mais rápida e descentrada do centro e a rece¸cão tornava-se imposs´ıvel. Este problema era especialmente enfatizado nas situa¸cões de bola parada, em que o robô precisava de receber a bola e virar-se para a baliza para rematar. Na maior parte dos casos a rece¸cão e a rota¸cão com bola era demasiado lenta, fazendo com que as equipas adversarias conseguissem fazer oposi¸cão antes do robô rematar.

Figura 2.5: Grabber antigo dos robˆos CAMBADA.

Na nova versão, a equipa decidiu optar por tentar resolver o problema do Grabber com uma solu¸cão parecida com as de outras equipas de topo. Em vez de se usar apenas um motor com uma roda na vertical a fazer friçcão sobre a bola, foram colocados dois motores com duas rodas omnidireccionais nas pontas praticamente perpendiculares à bola (Figura 2.6).

Figura 2.6: Novo Grabber dos robˆos CAMBADA.

Os motores agora funcionam como pequenos bra¸cos que for¸cam as rodas contra a bola, sendo que esta for¸ca é controlada pela tensão imposta por uma mola que segura os motores. Com esta solu¸cão torna-se poss´ıvel receber bolas que não venham totalmente centradas com o Grabber e com maior velocidade, pois as molas vão permitir o amortecimento da bola à chegada. As rodas nas pontas dos motores girando para dentro for¸cam com que a bola se encaminhe para o centro do Grabber.

(25)

Esta solu¸c˜ao tem ainda muitas potencialidades para serem exploradas futuramente, como o movimento para tr´as com bola controlada e possivelmente o movimento lateral com bola.

2.1.4 Kicker

O Kicker é o elemento do robô que permite chutar a bola. A constru¸cão assenta no mesmo conceito da versão anterior, uma pe¸ca de metal é disparada a alta velocidade e dependendo do tipo de disparo pretendido passe/remate rasteiro ou em parábola, este embate na bola de forma diferente (Figura 2.7). Caso se queira efetuar um passe/remate em parábola, a pe¸ca metálica é disparada contra uma barra vertical com a ponta inclinada que se encontra atrás da bola. Esta embate na bola por baixo, fazendo com que a mesma ganhe altura. No caso de um passe/remate rasteiro, um atuador puxa a barra vertical para ao lado fazendo com que a pe¸ca metálica embata no centro da bola, levando a que esta descreva uma trajetória plana.

Figura 2.7: Kicker dos novos robˆos CAMBADA.

Para se obter a propulsão da pe¸ca metálica é utilizada uma solu¸cão desenvolvida pela equipa CAMBADA, vulgarmente conhecida por Kicker Electro-magnético. Este consiste num solenoide electromecânico enrolado a volta de um centro ferromagnético. Isto faz com que seja criado um campo magnético quando é aplicada uma corrente elétrica, movendo a pe¸ca metálica em dire¸cão à bola.

2.2 Plataforma CAMBADA – Software

A constru¸cão do software tomou como base os seguintes princ´ıpios: todos os robôs tem de ser autónomos e têm de conseguir comunicar entre si, para cooperativamente atingirem os seus objetivos [3]. Olhando para a Figura 2.8 podemos observar que no centro da arquitetura do software CAMBADA encontra-se um módulo designado por Real time database (RTDB) e que será descrito de seguida.

2.2.1 Base Dados em Tempo Real (RTDB)

Tendo em considera¸cão que um dos pontos principais do projeto é a partilha de informa¸cão sensorial entre os robôs, houve necessidade de criar uma forma de partilhar esta informa¸cão.

(26)

Figura 2.8: Arquitetura geral do software do projeto CAMBADA.

Dado o facto de os robôs se deslocarem a relativamente grandes velocidades (3 m/s), a im-plementa¸cão de uma base dados t´ıpica assente num modelo cliente-servidor não seria o mais indicado, pois a informa¸cão facilmente ficaria desatualizada entre comunica¸cões. Para com-bater esta degrada¸cão da informa¸cão foram implementadas duas funcionalidades. A primeira é difusão da informa¸cão partilhada por Broadcast e a segunda é a replica¸cão da informa¸cão partilhada nos diversos robôs através de um modelo de memoria partilhada. Com esta imple-menta¸cão os robôs têm sempre acesso as variáveis necessária para o seu funcionamento, pois tem sempre a uma copia local de toda suas informa¸cões e dos outros membros da equipa. Na RTDB [3, 4] estão normalmente contidas informa¸cões como a posi¸cão absoluta de cada robô da equipa e posi¸cão da bola. Esta solu¸cão foi chamada de Real Time Data Base (RTDB).

2.2.2 Comunica¸c˜ao (comm)

O comm é o processo responsável por enviar e receber as informa¸cões partilhadas através da RTDB [3, 5]. Este é formado por duas Threads (Figura 2.9), uma de rece¸cão e outra de envio. A de envio encontra-se num constante loop e a cada ciclo de 100ms transmite parte da informa¸cão partilhada via BroadCast. A de rece¸cão fica à escuta de mensagens dos outros membros da equipa para atualizar a sua cópia local da RTDB.

2.2.3 Comunica¸c˜oes com o Hardware (HWcomm)

O HWcomm é um processo semelhante ao comm mas neste caso é responsável pelas comunica¸cões internas do robô [3, 6], ou seja, é o processo que trata da comunica¸cão entre o software e o hardware (Figura 2.10). Este tem, tal como no comm, duas Threads: uma para de rece¸cão de informa¸cão do hardware e outra para envio. É ele o responsável pelo cálculo da odometria e a decomposi¸cão do movimento (coordenadas X, Y e orienta¸cão) em velocidades v1, v2 e v3 para os motores.

(27)

Figura 2.9: Processo comm utilizado para a partilha de informa¸c˜ao entre os agentes CAM-BADA.

Figura 2.10: Processo Hwcomm respons´avel pela comunica¸c˜ao com o Hardware.

2.2.4 Vis˜ao

O sistema de visão no robô CAMBADA [7] utiliza duas câmaras, uma em perspetiva para identificar a bola pelo ar e uma segunda que aponta para um espelho, permitindo ter um sistema omnidirecional. Esta última permite ao robô ver o mundo 360 graus à sua volta e extrair informa¸cão sobre as linhas do campo, posi¸cão da bola e obstáculos (Figura 2.11). Em termos de software há dois processos envolvidos: o vision e o frontvision (Figura 2.8). Os algoritmos utilizados para a dete¸cão de obstáculos e bola baseiam-se em segmenta¸cão de cor, constru¸cão de regiões com a mesma cor e análise da forma das regiões obtidas. Para a dete¸cão de linhas é utilizado um algoritmo que deteta transi¸cões de cor.

2.2.5 Agente

O agente é o cérebro de cada um dos robô CAMBADA. Nele são reunidas a informa¸cão dos diversos componentes sensoriais do robô, bem como a informa¸cao produzida pelos outros

(28)

a) b) c)

Figura 2.11: Imagem obtida pela câmara omnidirecional do robô CAMBADA e respetivas imagens depois de processadas. Em a) encontramos a imagem real obtida pelo robô, em b) a mesma imagem depois da segmenta¸cão de cor e em c) a posi¸cão dos objetos de interesse detetados na imagem.

modulos de software, e tomadas as decisões sobre o que o robô irá executar [3, 8]. O agente segue uma estrutura semelhante à encontrada na Figura 2.12.

(29)

Loop

O funcionamento do agente baseia-se num ciclo de 33 milissegundos. Em cada ciclo ativa a fun¸cão “thinkandact” (Figura 2.12) que não é mais do que uma máquina de estados. Esta máquina de estados recolhe a cada ciclo as informa¸cões do sistema para tomar decisões. No final do ciclo, e de acordo com as decisões tomadas, são passadas as ordens ao hardware para que este as execute. No ciclo seguinte volta-se a repetir o processo até que o robô atinja o seu objetivo ou exista um novo objetivo.

Integrator

O Integrator, tal como o nome indica, é o modulo responsável por processar toda a in-forma¸cão dispon´ıvel (visão, odometria, posicionamentos dos outros robôs,etc.) e a juntar de forma a que o robô tenha uma “imagem” global do estado do sistema para que este possa tomar decisões sobre o que irá fazer.

Strategy

O Strategy define quais a posi¸cões estratégicas que os vários agentes devem tomar em campo de acordo com a situa¸cão de jogo.

Figura 2.13: Exemplo de uma forma¸c˜ao dos robˆos CAMBADA.

Roles e Behaviours

Os Roles e os Behaviours são os elementos mais importantes do agente [3, 8]. São eles que vão definir qual a fun¸cão do robô na estratégia da equipa e que movimentos deverão efetuar. Os Roles definem qual a fun¸cão do agente dentro da estratégia da equipa. Existem 3 Roles poss´ıveis de serem escolhidos numa situa¸cão de jogo normal. O primeiro é o Goalie, que indica que o robô é guarda redes. O segundo Role é o de Midfielder, que indica que o robô deve se mover de acordo com a estratégia da equipa, sendo um jogador passivo não procurando intercetar a bola. Por ultimo temos o Role Striker, que será um jogador ativo que tentará procurar a bola. Um robô que tenha a bola em seu puder e controlada tornar-se automaticamente Striker.

Em situa¸cões de bola parada existem dois Roles: Receiver e Replacer. O primeiro é responsável por receber a bola passada pelo segundo, seguindo as regras do jogo para o efeito. Os Behaviours são os estados de cada um dos roles. São eles que definem quais os movi-mentos ou habilidades que cada um dos robôs deverá efetuar, de acordo com o Role escolhido.

(30)

Se um jogador for, por exemplo, um Strikker com bola será o Behaviour que definira para onde é que o robô se deverá deslocar e qual será o momento em que o robô deverá rematar.

(31)

Cap´ıtulo 3

Movimento e Gera¸

c˜

ao de

Trajet´

orias no CAMBADA

Os Robôs CAMBADA, tal como foi apresentado anteriormente, deslocam-se de forma omnidirecional. Devido à natureza do jogo de futebol era importante que o robô não só andasse em qualquer dire¸cão mas que conseguisse manter-se orientado para a bola enquanto se deslocasse lateralmente. Uma das melhores formas para obtermos este tipo de movimento é a utiliza¸cão de rodas Omni.

3.1 Rodas Omni

As rodas Omni são rodas em que as suas extremidades são compostas por pequenas rodas com movimento perpendicular ao da roda principal [9]. Este tipo de constru¸cão permite que a roda se desloque na sua dire¸cão de rota¸cão mas também que se desloque facilmente num sentido perpendicular à rota¸cão. Devido a esta caracter´ıstica, as rodas Omni permitem a constru¸cão de sistemas com movimento holonómico, em que a velocidade aplicada a cada uma das rodas determina a dire¸cão para que este se desloca, sem que haja altera¸cão da dire¸cão das rodas.

(32)

3.2 Movimento Holon´

omico

Um sistema com capacidade de produzir um movimento holonómico é um sistema que se consegue mover com os mesmos graus de liberdade do espa¸co em questão. Os robôs CAM-BADA conseguem-se movimentar em qualquer dire¸cão independentemente da sua orienta¸cão num campo de futebol que é um espa¸co planar a duas dimensões. Posto isto, podemos afir-mar então que os robôs CAMBADA são robôs com movimento holonómico [10]. Para obter este tipo de movimento por parte do robô foram utilizados motores com rodas Omni nas suas extremidades. Na solu¸cão em particular são utilizados 3 conjuntos de rodas e motores separados por 120 graus (Figura 3.2).

Figura 3.2: Coloca¸c˜ao das rodas na base do robˆo CAMBADA.

Na figura 3.3 encontramos uma demonstra¸cão de como obter alguns movimentos simples através desta solu¸cão: rota¸cão sobre o centro do robô, movimente em frente e movimento lateral.

a) b) c)

Figura 3.3: Exemplos de movimentos obtidos de acordo com as velocidades aplicadas aos motores. Em a) verificamos a rota¸c˜ao sobre o centro do robot, em b) o movimento em frente e em c) movimento lateral do robˆo ([1]).

(33)

Como podemos observar através da Figura 3.3, a chave para os diferentes tipos dos mo-vimentos é a aplica¸cão de velocidades espec´ıficas a cada uma das rodas. Olhando mais ao pormenor para a op¸cão a) e atendendo a que o vetor de cada uma das roda é representado pelas setas ao seu lado, podemos verificar que quando os motores têm todos a mesma velo-cidade o robô rodará sobre ele próprio. Já na op¸cão b) este desloca-se na dire¸cão do eixo y pois o motor M1 está parado, sendo que a soma dos vetores M3 e M2 resultam num vetor na dire¸cão y. Na op¸cão c) obtemos um movimento lateral na dire¸cão do eixo x, pois o motor M1 tem uma maior velocidade do que M3 e M2. Como a soma M3 e M2 resulta num vetor no sentido do eixo x, em conjunto com o valor de M1, que também se encontra na dire¸cão do eixo x, resulta um vetor de velocidade no sentido deste eixo.

A determina¸cão de velocidades a atribuir a cada um dos motores para cada tipo de mo-vimento não é trivial, visto que o hardware necessita de três valores de velocidade para os motores e o software trabalha num sistema egocêntrico (sistema em que as localiza¸cões no espa¸co são obtidas com base no observador, neste caso o robô). Para fazer a ponte entre os dois existe no processo HWcomm uma camada de software chamada de movimento ho-lonómico. Esta camada é responsável por converter valores de velocidade relativas à base do robô em valores de velocidade para cada um dos motores. Para além disso, esta camada tem de garantir que não são aplicadas a cada motor velocidades superiores ao valor máximo do sistema. Adicionalmente é também definido um valor máximo de acelera¸cão para evitar tra-vagens e arranques bruscos, que causariam danos no robô e no ambiente. Para garantir estas condi¸cões o movimento holonómico do HWcomm, além de converter as velocidades, aplica rampas de acelera¸cão e desacelera¸cão e controla a satura¸cão dos motores.

3.2.1 Rampas de acelera¸c˜ao e desacelera¸c˜ao

As rampas de acelera¸cão e desacelera¸cão filtram a velocidade que se deseja que o robô atinja. Assim, se um robô pretender acelerar ou desacelerar muito rapidamente, estas limitam a velocidade a aplicar aos motores de acordo com a velocidade anterior e um fator de acelera¸cão previamente calculado. Isto evita que o robô tombe ou derrape as suas rodas quando tenta iniciar e finalizar o seu movimento.

3.3 Movimento antigo dos CAMBADA

O controlo dos robôs CAMBADA é feito em posi¸cão e orienta¸cão. É definido um destino que o robô deve atingir. O ciclo de controlo calcula o erro em posi¸cão e orienta¸cão em rela¸cão ao destino. Este erro é depois compensado por um conjunto de controladores PID que irão converter este erro em velocidades. Estas velocidades serão as velocidade fornecidas ao movimento holonómico para calcular a potência a fornecer a cada motor. Estes controladores PID, por norma, estarão sempre num estado saturado, sendo que só fornecerão valores úteis para controlo quando o robô estiver próximo do destino (Figura 3.4). Até esse momento, as velocidades são controladas pelas rampas de acelera¸cão do movimento holonómico.

Esta forma de movimento é muito limitativa. Não existe forma de definir momentanea-mente qual a velocidade a que o robô deve passar num determinado local ou que trajetória deve tomar até atingir o destino. Desta forma é necessário procurar uma nova solu¸cão.

(34)

Figura 3.4: Modelo do movimento dos robˆos CAMBADA.

3.4 Gerador de trajet´

orias

A solu¸cão proposta assenta num algoritmo que faz um pré-calculo da trajetória do robô, utilizando um modelo f´ısico, tomando em conta as restri¸cões cinodinâmicas dos robôs CAM-BADA. A esta solu¸cão chamamos de Gerador de Trajetória (GT). A primeira versão desta proposta está apresentada em [11]

3.4.1 Proposta

O GT será inclu´ıdo numa camada de software entre o Agente e o movimento holonómico. Para atingir o objetivo proposto este irá pegar no ponto de destino indicado pelo Agente e pré-calcular uma trajetória entre a posi¸cão do robô e o destino. Esta trajetória será composta por um conjunto de posi¸cões e velocidades muito próximas uma das outras, que deverão ser fornecidas controladamente ao robô em cada ciclo de controlo.

3.4.2 Problema

Olhando agora mais profundamente para o problema do movimento, é poss´ıvel definir cada movimento do robô como um segmento. Estes segmentos são definidos pelas suas condi¸cões iniciais, restri¸cões de movimento e pela dinâmica do robô. Neste caso podemos assinalar que nos robô CAMBADA, cada um destes segmentos tem uma velocidade inicial e final, uma posi¸cão inicial e final, uma velocidade patamar a que se deseja que o robô ande e uma capacidade máxima de acelera¸cão. Posto isto verifica-se que na defini¸cão deste segmento apenas um valor será constante: o da capacidade máxima de acelera¸cão. Isto verifica-se pois é um valor associado à f´ısica do próprio robô e do terreno de jogo. Todos os outros valores são parâmetros de entrada de cada um dos segmentos, mesmo que estes estejam já definidos no in´ıcio do segmento, como é o caso da velocidade e posi¸cão inicial que são lidos diretamente do sistema. O caminho que o robô segue entre o inicio e o destino é definido pelos pontos que são fornecidos ao movimento holonómico a cada itera¸cão do sistema. Ao tempo entre cada itera¸cão chamamos de Ta. A missão do GT é calcular os valores a fornecer ao movimento

holon´omico em cada itera¸c˜ao do sistema, para cada segmento do movimento.

3.4.3 Calculo da trajet´oria

O robô situa-se no mundo através da sua posi¸cão x e y e pelo ângulo da sua orienta¸cão. Tendo em conta que os robôs CAMBADA são omnidirecionais e holonómicos, este facto permite-nos tratar dos movimentos de rota¸cão e transla¸cão separadamente, apesar de se ter em considera¸cão que estes movimentos têm de ser sincronizados. Partindo do principio que

(35)

o robˆo tem forma de garantir um leitura de velocidade e posicionamento com erro finito, podemos assumir que este algoritmo consegue calcular um conjunto de pontos que o robˆo consegue seguir ao longo do tempo.

Para obter estes pontos o GT ser´a baseado no algoritmo de perfil de velocidade trapezoidal (Figura 3.5). Sendo assim o movimento ser´a dividido em 3 fazes:

• 1a _{fase - acelera¸}_c˜_{ao de velocidade inicial ate velocidade patamar, de 0 at´}_{e t} 1.

• 2a _{fase - movimento em velocidade constante, de t} 1 a t2.

• 3a _{fase - acelera¸}_c˜_{ao de velocidade patamar at´}_{e velocidade final, de t}

2 at´e t3.

Figura 3.5: Gr´afico de velocidade do movimento trapezoidal

Ao contrário do algoritmo habitual de perfil de velocidade trapezoidal, o GT não terá normalmente 0 como velocidade inicial e final (Figura 3.6). Sendo assim, o movimento será definido por uma velocidade inicial vi, uma posi¸cão inicial pi, uma velocidade e posi¸cão final

vf e pf, uma velocidade patamar Vp e acelera¸c˜oes a1 e a3 para as fase 1 e 3 respetivamente.

De notar que os valores para as acelera¸c˜oes a1 e a3 e velocidades patamar Vp ser˜ao definidos

por valores absolutos correspondentes `a sua quantidade f´ısica.

Figura 3.6: Gr´afico de velocidade do movimento do GT

Pensando agora apenas no movimento de transla¸cão, visto que o de rota¸cão seguirá o mesmo principio mas a uma dimensão, o GT terá de pegar nas velocidades e posi¸cões iniciais e finais (notar que este valores correspondem às coordenadas XY no espa¸co), na acelera¸cão da fase 1 e fase 3 do movimento, na velocidade patamar e calcular os pontos p0,p1...,pn da

trajetória XY espa¸cados pelos tempos de itera¸cão do sistema Ta. Sendo assim temos que: • p₀=pi será o ponto inicial do movimento e pn=pf ponto final do movimento.

• (p1− p0)/Ta=vi em que vi ser´a a velocidade inicial e (pn− pn− 1)/Ta=vf velocidade

(36)

• |v_k+1−vk|/Ta=a1em que a1para k¡=k1 ser´a a acelera¸c˜ao da fase 1 e |vk+1−vk|/Ta=a3

para k¡=k2 será a acelera¸cão da fase 3 (em que k1 é a última amostra de velocidade da

fase 1 e k2 a ´ultima amostra de velocidade da fase 2).

• |p_k+ 1 − pk|/Ta=vp em que vp para k1 ¡ k ¡ k2 ser´a a velocidade patamar.

Analisando agora a Figura 3.7 verificamos que o GT ter´a de calcular uma trajet´oria de maneira a transformar a velocidade vi no ponto inicial p0 na velocidade vf do ponto final pn.

Isto respeitando os valores de acelera¸cão máxima do robô.

Figura 3.7: Grafico dos vetores de velocidade vi e vf.

3.4.4 Heur´ıstica do GT

Para conseguir calcular uma trajetória que obede¸ca às condi¸cões impostas anteriormente, o GT necessita, em primeiro lugar, de calcular o ponto em que atinge a velocidade patamar (pa), o ponto em que deixa a velocidade patamar (pw) e a própria velocidade patamar (vp).

O problema ´e que estes valores de pa e pw dependem de vp e o pr´oprio vp depende de pa e pw.

Para resolver este problema o GT tenta iterativamente encontrar um valor para vp. O GT

come¸ca por criar uma estimativa para o valor de vp atrav´es de pf-pi. Com esta estimativa o

GT entra num ciclo em que calcula os pontos pa e pw. Ap´os o calculo destes pontos o GT

volta a fazer uma nova estimativa para o vp, que depois ser´a combinada com a estimativa

anterior numa fun¸cão de convergência. O processo repete-se um número finito de vezes até se encontrar ou não uma solu¸cão para vp.

O critério de convergência do GT é aplicado pela fun¸cão descrita no Algoritmo 2, que verifica se a estimativa calculada para vp e para os pontos pa e pw correspondem a um

caminho que obedece `as restri¸c˜oes imposta pelo GT.

No Algoritmo 3 encontramos a implementa¸cão da fun¸cão h, responsável pelas estimativas provisórias da velocidade patamar vp. Nesta fun¸cão o valor k corresponde ao rácio entre o

total do deslocamento s e o deslocamento em velocidade patamar s’ (Figura 3.8). Este valor tem como fun¸cão diminuir o valores temporários da vp, de maneira a aumentar a distância a

percorrer em velocidade vp. Este passo e necess´ario pois se a distˆancia a percorrer entre Pa

e Pw for muito pequena torna-se muito complicado obtermos a convergˆencia do algoritmo.

Na Figura 3.9 encontra-se uma situa¸cão intermédia do algoritmo em que Pa e Pw ainda não

se encontram alinhados, não perfazendo uma situa¸cão de convergência do algoritmo até esse momento.

(37)

Algorithm 1 mov2d : Heur´ıstica do movimento 2D Require: s · vi ≥ 0, s · vf ≥ 0

s ← pf − pi;

v(0)p ← ˆs · vp∗ {Primeira estimativa para vp; ˆu = _|u|u}

continue ← true while continue do {Estimativa de pα} ∆v1← vp(i)− vi a1 ← ˆ∆v1· a∗1 s1 ← ∆v_a₁1 ·vi+v₂ p pα = pi+ s1 {Estimativa de pω} ∆v3← vf − vp(i) a3 ← ˆ∆v3· a∗3 s3 ← ∆v_a₃3 · vp+vf 2 pω ← pf − s3

{Estimativa do erro da velocidade patamar} sπ ← pω− pα

vπ ← ˆsπ· vp∗

if φ(vp(i−1), vπ, sπ) then

{φ defini¸cão do critério de convergência} {Valor final atingido}

continue ← false else {Update da estimativa} v(i)p ← h(s, vp(i−1), sπ, vπ) end if Increment i end while

Algorithm 2 Defini¸cão da fun¸cão do critério de convergência φ return |v(i−1)p − vπ||s_|vπ_π|_| <

Algorithm 3 Defini¸c˜ao da fun¸c˜ao h Require: s, vp(i−1), sπ, vπ

k ← s·sπ

|s|2

(38)

Figura 3.8: Calculo Valor k

Figura 3.9: Fase interm´edia do calculo de vp

No Algoritmo 4 identificam-se situa¸c˜oes em que os vetores s = pi - pf e s0 = Pw − Pa

se encontram em dire¸cões opostas (Figura 3.10). Nestes casos o GT não consegue encontrar uma solu¸cão, originando a necessidade de reduzir o valor de vpestimada para tentar encontrar

uma solu¸c˜ao v´alida.

Algorithm 4 Heur´ıstica da degenera¸c˜ao do movimento if s · sπ < 0 then

v_p∗← λv∗

p {0 < λ < 1}

if v_p∗ < v∗_p,min then

{N˜ao foi poss´ıvel encontrar um valor para v∗_p} return with fail code

end if vp(i)← ˆs · v∗p

Increment i

continue {Reiniciar LOOP com um novo valor para v_p∗} end if

Após a determina¸cão dos pontos pa e pw e da determina¸cão da velocidade vp, passa para

a fase de constru¸cão da trajetória que o robô terá de seguir. Para isso é necessário calcular o número de ciclos que cada fase do movimento terá.

No caso da fase 1, a fase de acelera¸cão para a velocidade patamar, calculamos a diferen¸ca entre a velocidade patamar e a velocidade inicial e dividimos esse valor pelo valor absoluto da acelera¸cão para a fase 1. Esta opera¸cão fornece o tempo que a fase 1 demorará a ser

(39)

Figura 3.10: Degenera¸c˜ao do Movimento

conclu´ıda, dividindo este valor pelo pela unidade de tempo de clock do sistema Ta obtemos o

número de ciclos desta fase. Na fase 2 visto que a velocidade é constante, divide-se a distância percorrida entre pa e pw pelo valor absoluto da velocidade patamar para obtermos o tempo

da fase. Em seguida efetua-se a mesma opera¸cão da fase 1, dividindo o tempo da fase pelo tempo do sistema Tapara obter-se o número de ciclos da fase 2. A terceira fase é semelhante

a fase numero 1 mas com a diferen¸ca de se usar um poss´ıvel valor diferente para a acelera¸c˜ao do robˆo.

C´alculo dos pontos da trajet´oria

Após a determina¸cão do número de ciclos de cada fase passasse à constru¸cão do caminho. Cada uma das fases terá um número finito de itera¸cões correspondente ao numero de ciclos calculados anteriormente. A cada itera¸cão de cada fase, será escrito numa lista um ponto e uma velocidade a percorrer pelo robô. Atendendo ao algoritmo 5 podemos verificar que esse ponto e essas velocidades são construidos com base no valor da itera¸cão anterior e pelo tempo percorrido entre as itera¸cões. Assim sendo a velocidade de uma itera¸cão é construida a custa da velocidade anterior mais a acelera¸cão da fase multiplicada pelo tempo decorrido entre as itera¸cões (Ta). Os pontos em cada itera¸cão são construidos a custa do ponto anterior mais a

distancia a percorrer nessa itera¸cão. Essa distância e calculada pela velocidade nessa itera¸cão multiplicada pelo tempo entre as itera¸cões (Ta). Isto é valido para as fases 1 e 3. Na fase 2

como a velocidade é constante apenas é calculado o ponto seguinte a cada itera¸cão. De notar que, quando à mudan¸ca de fase, os valor de velocidade e posi¸cão do robô a serem usados para o in´ıcio das itera¸cões, são os estimados e não os últimos valores da fase anterior. Na Figura 3.12 podemos encontrar uma situa¸cão final em que temos a convergência do algoritmo.

3.4.5 Movimentos em curva usando o GT

O movimento em curva gerado pelo GT é obtido através da subdivisão da trajetória em curva em pequenos segmentos de reta (Figura 3.13). Para isto o GT usa o vetor entre posi¸cão inicial e um centro de rota¸cão fornecido e aplica-lhe N rota¸cões. A cada rota¸cão o deslocamento entre o ponto inicial e o ponto destino rodado é considerado um movimento a duas dimensões e calculado pelos algoritmos acima descritos para o movimento 2D. A distância entre cada

(40)

Algorithm 5 motion comp: Calcula pontos da trajet´oria {Elementos da fase 1}

∆v1 ← vp− vi {∆v na fase 1}

t1← |∆v_a∗1| 1

{Tempo para cumprir a fase 1} n1← d_Tt1_ae {N´umero de ciclos da fase 1}

a1← d∆v1a∗1

{Elementos da fase 3}

∆v3 ← vf − vp {∆v na fase 3}

t3← |∆v_a∗3| 3

{Tempo para cumprir a fase 3} n3← d_Tt3_ae {N´umero de ciclos da fase 3}

a3← d∆v3a∗3

{Inicio do c´alculo dos pontos} p ← pi; v ← vi; {Valores iniciais} {fase 1} for n = 1 at´e n1 do v ← v + a1Ta p ← p + vTa pp ( p {A ( b: append b to A} end for {fase 2}

p ← pα; v ← vp {Valores iniciais da fase 2}

pp ( p for n = 1 at´e n2 do p ← p + vTa pp ( p end for {fase 3}

p ← pω {Valores iniciais da fase 3}

pp ( p for n = 1 at´e n3 do v ← v + a3Ta p ← p + vTa pp ( p end for

p ← pf { ´Ultimo ponto do movimento}

(41)

Figura 3.11: Gr´afico final do GT para os pontos pi,pa,pw e pf

Figura 3.12: Gráfico final dos pontos calculados pelo GT movimento vai depender do valor N e do ângulo de rota¸cão fornecido ao GT.

Tendo em considera¸cão os algoritmos presentes na solu¸cão GT é poss´ıvel concluir que o GT poderá ser uma solu¸cão viável a introduzir no software CAMBADA de maneira a refinar o controlo da trajetória do robô e a obter um melhor controlo sobre a velocidade do mesmo. Nos Cap´ıtulos 4 e 5 será feita uma abordagem à implementa¸cão do GT no software CAMBADA e aos testes efetuados ao mesmo para comprovar a sua convergência.

(42)

(43)

Cap´ıtulo 4

Implementa¸

c˜

ao de um modelo de

GT no CAMBADA

Este Cap´ıtulo vai abordar as altera¸cões efetuadas à arquitetura do CAMBADA para a implementa¸cão do GT. Para este fim foi necessário alterar a estrutura do Agente e do movi-mento holonómico. Este Cap´ıtulo aborda também diversos testes elaborados cujos resultados serão apresentados no Cap´ıtulo 5.

4.1 Implementa¸

c˜

ao do GT

Na estrutura anterior do Agente (Figura 4.1), os Behaviours eram responsáveis por cal-cular as velocidades a passar ao movimento holonómico. Sendo agora o GT responsável por calcular estas velocidades, deixa de fazer sentido a existência de fun¸cões de cálculo de veloci-dades nos Behaviours (Figura 4.2). Existem ainda fun¸cões do Behaviour que exigem a escrita de valores na RTDB, como é o caso dos valores para o Kicker e para o Grabber. Como o GT se situa numa camada abaixo dos Beahviours torna-se pouco prático a escrita na RTDB em duas fases diferentes. Optou-se então por criar uma camada de software num n´ıvel mais abaixo do GT chamada de LOWLEVEL. Esta camada é responsável por escrever os valores fornecidos pelos Behaviours e pelo GT na RTDB.

Figura 4.1: Arquitetura antiga do software do Agente

Para além da cria¸cão da camada LOWLEVEL houve a necessidade de alterar todos os Behaviours de maneira a estarem de acordo com a nova ordem de opera¸cões. Em especial

(44)

todos os Behaviours que envolviam movimento, devido às novas condi¸cões iniciais, tiveram de ser revistos para não suportarem apenas um destino, mas também uma velocidade final e uma velocidade patamar pretendida.

O movimento holonómico também teve necessidade de ser revisto, pois deixa de haver necessidade de utiliza¸cão de rampas de acelera¸cão. O GT leva em considera¸cão as carac-ter´ısticas f´ısicas do robô como a acelera¸cão e velocidade máxima no cálculo dos seus pontos, logo o resultado final são valores que depois de convertidos para velocidades dos motores não necessitam de filtragem.

Figura 4.2: Nova arquitetura do Agente

4.2 Estudo do funcionamento do GT

Após a implementa¸cão do GT no software CAMBADA houve lugar a uma fase experimen-tal do GT para verificar o seu correto funcionamento. Este estudo come¸cou por ser efetuado no simulador dos CAMBADA passando mais tarde a ser efetuado nos robôs. Durante este estudo foram encontradas algumas situa¸cões que impediam a convergência do GT, bem como altera¸cões que poderiam ser efetuadas para melhorar o seu funcionamento.

As situa¸c˜oes que impediam o normal funcionamento do GT foram:

• Dificuldades na transi¸c˜ao entre os movimentos em que o robˆo teria de passar num ponto com uma determinada velocidade e continuar para outro ponto.

• Dificuldades relacionadas com as altera¸cões rápidas do ponto de destino do robô, que originavam movimentos bruscos do robô.

• Dificuldades em implementar o GT no software CAMBADA devido `as carater´ısticas do movimento dos CAMBADA, o que dificultava por vezes o cumprimento dos requisitos do GT, deixando por diversas vezes o robˆo imobilizado.

(45)

Identificados os problemas, come¸cou-se por analisar a causa de cada um deles. Para isto procedeu-se à elabora¸cão de gráficos de posi¸cão entre os pontos fornecidos ao GT e os pontos reais pelo que o robô passava. Na Figura 4.4 podemos observar um dos primeiros teste efetuados ao GT, em que os pontos a vermelho representam a trajetória calculada pelo GT e os verdes os valores reais estimados para a posi¸cão do robô.

Figura 4.3: Compara¸cão da posi¸cão do robô estimada e a posi¸cão calculada pelo GT. Com a análise dos testes efetuados tornou-se claro, apesar de um pequeno atraso no cum-primento da trajetória pedida, que o grande problema do GT encontrava-se na transi¸cão entre as trajetórias calculadas pelo GT. O problema agravava-se com o aumentar das velocidades de trabalho do robô como se poderá verificar no Cap´ıtulo 5.

Levando em considera¸cão este ponto criou-se um teste com uma trajetória repetitiva para observar o comportamento do robô em diversas condi¸cões de acelera¸cão e velocidade (Figura 4.4). Durante a realiza¸cão deste teste foram elaborados gráficos de posi¸cão e gráficos de velocidade.

Figura 4.4: Teste repetitivo elaborado para testar a convergˆencia do GT.

A analise destes testes permitiu concluir que a causa para os problemas nas transi¸cões entre trajetórias encontrava-se no ru´ıdo da leitura da velocidade do robô.

(46)

Para combater este problema na leitura da velocidade pelo GT, deixou de se fazer a leitura pelo valor registado no estado do robô, que é obtido através da visão, e passou-se fazer a leitura através do último valor fornecido aos motores. Esta altera¸cão melhorou substancialmente o desempenho do GT para acelera¸cões e velocidades mais baixas, sendo que, para valores mais elevados o problema manteve-se.

Após esta altera¸cão nas velocidades tornou-se também evidente que os valores pa e pW ,

valores estimados para os pontos de entrada e sa´ıda da velocidade patamar, deveriam não per-tencer a trajetória, pois como eram estimados por vezes desviam-se ligeiramente da trajetória esperada, provocando ligeiras imperfei¸cões no movimento.

Com análise dos gráficos identificou-se também a causa de problemas relacionados com a imobiliza¸cão total do robô. Esta situa¸cão advém do facto de se indicar um vetor de velocidade de passagem num ponto ao GT incompat´ıvel com o ponto de origem do mesmo. Pode-se encontrar um exemplo prático na Figura 4.5.

Figura 4.5: Movimento imposs´ıvel para o GT pois o vetor de velocidade no destino encontra-se na dire¸c˜ao oposta ao movimento.

Na Figura 4.5 chega-se à conclusão de que para determinados movimentos o GT necessita de criar pontos intermédios para que se respeitem as condi¸cões de funcionamento do GT como se verifica na Figura 4.6. Para a cria¸cão destes pontos seria necessário criar uma camada de software entre os Behaviour e o GT responsável pelo planeamento de trajetória do robô. A esta solu¸cão deu-se o nome de Planeador de Trajetórias.

Para a cria¸cão de um planeador de trajetórias houve necessidade de identificar quais os movimentos que este poderia realizar. Desde logo identifica-se que trajetórias em linha reta e movimentos em curva como sendo trajetórias básicas para a constru¸cão de um plano de trajetórias de um robô. Olhando para o GT verifica-se que os movimentos em linha reta são facilmente calculados, sendo apenas necessário fornecer o ponto de destino e as velocidades pretendidas. Já os movimentos em curva são mais complicados, pois para serem efetuados têm de se fornecer um ponto de rota¸cão e um ângulo de rota¸cão. Para além disso, estes só podem ser efetuados à velocidade que o robô se encontra no in´ıcio do movimento, não sendo poss´ıvel, por exemplo, iniciar um movimento em curva a partir de uma velocidade 0.

Para melhorar a implementa¸cão dos movimentos em curva foi adicionada uma fun¸cão ao GT que permite diminuir a complexidade do calculo da trajetória em curva. Em vez de se

(47)

Figura 4.6: Poss´ıvel solu¸c˜ao para resolver a incompatibilidade do movimento da Figura 4.5.

fornecer ao GT um centro de rota¸cão e um ângulo de rota¸cão, fornece-se um ponto de destino e um ponto de passagem entre o in´ıcio e o fim do movimento. Estes dois pontos em conjunto com o ponto inicial permitem o calculo de um circulo que servirá para calcular os valores de entrada para a fun¸cão anterior do GT.

No cálculo do c´ırculo a partir destes três pontos foi usada a fun¸cão Circle, que constrói um circulo a partir de 3 pontos, já inclu´ıda no software CAMBADA no módulo geometry. Considerandos os pontos A, B e C como apresentado na Figura 4.7, a fun¸cão circle tem em considera¸cão os segmentos de reta formados entre os pontos e calcula o centro do c´ırculo com base na interce¸cão das retas perpendiculares aos referidos segmentos de reta que passam nos médios. A interce¸cão deste segmentos fornece o centro da circunferência que depois é usado para calcular o ângulo entre o vetor do ponto inicial com o centro e o ponto final com o centro. Este ângulo será depois o segundo parâmetro para a fun¸cão original do GT.

(48)

Esta fun¸cão permite obter movimentos mais complexos de um forma mais facilitada, pois com apenas um ponto de destino e com o ponto intermédio é poss´ıvel definir a abertura da semicircunferência que desejamos obter.

4.3 Planeador de trajet´

orias

A gera¸cão de trajetórias usando o modulo GT discutido nesta disserta¸cão pode tornar-se bastante complicada, pois este envolve um conjunto de restri¸cões de movimento que podem culminar na imobiliza¸cão total do robot. Para fazer face a este problema há necessidade de criar uma camada superior entre a informa¸cão de destino vinda do Behaviour e a informa¸cão que será carregada para o GT. É nesse ponto que entra o Planeador de Trajetórias, que vai verificar as restri¸cões do movimento pretendido e criar pontos intermédios para que este se torne um movimento poss´ıvel.

4.3.1 Planeador de desvio de obstaculos

Devido a restri¸cões de tempo e de complexidade na cria¸cão de um planeador de trajetórias totalmente funcional foi apenas abordado nesta disserta¸cão a cria¸cão de um planeador de trajetórias para desvio de obstáculos. O planeador em questão será baseado num mapa de ocupa¸cão que registará todos os espa¸cos preenchidos do campo e um algoritmo de planeamento que efetuará o calculo do melhor caminho poss´ıvel até ao destino. A ideia fundamental é aplicar o planeador apenas nos momentos em que existam obstáculos pela frente do robô sendo que em outras situa¸cões será aplicado apenas o GT.

Figura 4.8: Modelo da fase final do agente incluindo o GT e o planeador

4.3.2 Desvio de obst´aculos

O desvio de obstáculos no planeador consiste na gera¸cão de pontos intermédios entre o ponto inicial e ponto final de forma a que a trajetória entre esse pontos intermédios tenha uma menor probabilidade de encontrar obstáculos pelo caminho do que a trajetória direta. Fala-se em probabilidade, pois os obstáculos no futebol robótico são robôs móveis, pelo que no instante seguinte ao cálculo de um determinado plano este pode deixar de ser válido.

A obten¸cão destes pontos intermédios baseiam-se no uso de um mapa de ocupa¸cão, que terá uma representa¸cão de todos os obstáculos encontrados no mundo, e de um algoritmo de pesquisa de melhor caminho, neste caso o A*. Para além de encontrar estes pontos intermédios o planeador terá de definir uma velocidade de passagem nos mesmos e fazer com que sejam respeitadas as condi¸cões do GT, sendo que até este momento esta condi¸cão para a velocidade ainda não foi aplicada. Após a aquisi¸cão destes pontos, o planeador terá de fornecer a cada ciclo os novos dados ao GT e recalcular um novo caminho sempre que as condi¸cões se alterem.

(49)

4.3.3 Mapa de ocupa¸c˜ao

O mapa de ocupa¸cão baseia-se numa matriz que divide o campo em células iguais com um valor associado (Figura 4.9). Cada uma destas células representará uma parte do campo, que dependendo do seu valor será assinalada como a célula ocupada, possivelmente ocupada, ou vazia.

Figura 4.9: Exemplo da divisão do campo em células com uma resolu¸cão de 8 por 8 células

Implementa¸c˜ao

O mapa é implementado através da cria¸cão de um array uni-dimensional de valores reais a representar a matriz. O tamanho deste array corresponde à resolu¸cão do sistema e cada uma das célula representa uma por¸cão do campo real. Esta resolu¸cão do sistema é indicada aquando da cria¸cão do mapa e carateriza-se pelo número de células desejado para a largura e comprimento do mapa. Para além da largura e do comprimento, o mapa é caracterizado também por um valor máximo que pode ser indicado em cada célula, que representa a célula como ocupada, e por um valor de subtra¸cão, que indica o valor a ser retirado a cada ciclo a uma célula preenchida. O calculo da área que cada célula representa no mapa real é feito a partir da divisão do comprimento e largura real do campo pelo número de células correspondentes ao comprimento e à largura.

4.3.4 Preenchimento dos obst´aculos

O funcionamento do sistema é bastante simples. A cada ciclo o mapa recebe uma lista de obstáculos com um raio e uma posi¸cão. O mapa, utilizando esta lista, faz o preenchimento das células que estão ocupadas pelos obstáculos com o valor máximo. Depois, as células à volta destas são definidas com um valor menor que representa a possibilidade de erro ou de futuras posi¸cões dos obstáculos. Esta lista de obstáculos é calculada pelo sistema de visão e atualmente apenas identifica até um máximo de 20 obstáculos.

No in´ıcio de cada ciclo é feita a atualiza¸cão de todas as células, diminuindo todos os valores, fazendo com que ao fim de algum tempo falsos positivos ou obstáculos que mudem de posi¸cão não fiquem a ocupar as células indefinidamente.

Com esta implementa¸cão é poss´ıvel a cada ciclo ter uma imagem geral da ocupa¸cão do campo e gerar um plano para evitar as zonas mais ocupadas (Figura 4.10).

(50)

Figura 4.10: Exemplo de preenchimento do mapa de ocupa¸cão num determinado ciclo. As bolas representam posi¸cões reais dos robôs. As cores vermelho, laranja e verde representam células ocupadas, células de poss´ıvel ocupa¸cão no futuro e células livres, respetivamente. Implementa¸cão

Os obst´aculos s˜ao preenchidos no array seguinte forma:

• Em primeiro lugar calcula-se a célula onde se encontra o centro do obstáculo, através da divisão da posi¸cão real do robô pela largura e comprimento de cada célula respeti-vamente.

• De seguida, com o raio do obstáculo, calculamos as células que são afetadas à volta (cima, baixo, esquerda e direita). Para este cálculo usamos novamente no centro do obstáculo e calculamos espa¸co ocupado na célula onde se encontra o centro do robô. Em seguida, com o valor do raio restante em cada uma das dire¸cões, verifica-se quantas células vão ser ocupada nessas respetivas dire¸cões.

• Por último, sabendo o número de células a percorrer em cada dire¸cão, aplica-se um ciclo para percorrer cada uma das células à volta e preenche-se com o valor de ocupado. Aplica-se ainda uma célula a mais em cada dire¸cão a ser preenchida com metade do valor máximo para indicar a probabilidade de erro ou de posi¸cão futura.

Para construir o caminho entre as zonas ocupadas uma das melhores solu¸cões é a imple-menta¸cão de um algoritmo de pesquisa de caminho.

A*

Para efetuar a pesquisa de um caminho com menor custo sobre o mapa de ocupa¸cão acima descrito foi selecionado o algoritmo A* [12]. Este algoritmo oferece boa rela¸cão entre precisão e performance e baseia-se numa filosofia de escolha do melhor caminho poss´ıvel. O algoritmo tenta encontrar o melhor caminho percorrendo o mapa pelo caminho que aparenta ter o custo mais baixo. Para isto, na pesquisa do caminho o algoritmo leva em conta não só a distância já percorrida até a uma célula X (g(x)), mas também uma Heur´ıstica euclidiana com um valor de custo estimado desse ponto X até ao ponto de destino. (h(x)). Para esta (h(x)) ser válida tem de conter sempre um valor menor ou igual ao custo desse mesmo ponto até ao destino.

(51)

Normalmente o valor estimado calculado em (h(x)) corresponde ao valor em linha reta da célula a ser analisada até a célula de destino.

Calculo do melhor caminho

O calculo do melhor caminho ´e efetuado da seguinte forma pelo A*:

• Em primeiro lugar o A* verifica se as posi¸cões de origem e destino são válidas. Sendo válidas este atribui a cada uma das posi¸cões a célula correspondente no mapa.

• Em segundo lugar o A* olha para a célula que contém o ponto inicial e verifica se não ´

e tamb´em o ponto de destino.

• No passo seguinte A* olha para as células que tem a sua volta e calcula para cada uma delas o seu f (x) = (g(x) + h(x)). Estas células são depois colocadas numa lista de prioridades de acordo com o valor de f (x). A célula atual é depois colocada numa lista de células já visitadas, sendo que a nova célula a ser analisada passa a ser a primeira da lista de prioridades. O processo repete-se nas células seguintes até ser encontrada a célula de destino ou então que todas as células estejam na lista de visitadas.

• Assim que seja encontrado o caminho mais curto (ou caminhos, pois podem existir vários caminhos mais curtos) é construida uma lista com as células deste caminho examinando o ponto antecedente a cada ponto, isto é, quando é gravado um ponto na lista de visitados ´

e tamb´em guardado o ponto que antecede ao mesmo no caminho. Ao chegar ao destino basta construir a lista com o caminho mais curto de tr´as para a frente, acedendo ao ponto anterior de cada ponto.

4.3.5 Indicar os pontos do plano ao GT

Após ao obten¸cão da lista de células intermédios por parte do A* o planeador irá calcular o ponto central de cada célula. Estes pontos serão fornecidos ao GT de uma forma controlada,ou seja, sempre que o robô atinja um ponto intermédio o planeador fornece outro. Este processo mantém-se enquanto as condi¸cões originais se mantiverem, ou seja, mesmo destino e sem obstáculos entre o ponto atual e o ponto intermédio seguinte. Caso apare¸ca um obstáculo ou o ponto destino mude volta-se a repetir todo o processo de planeamento. Um exemplo teórico do resultado final para o mapa da figura 4.10 pode ser verificado na figura 4.11

(52)