UaiSoccer SSL - TDP para LARC / CBR 2014

Transcrição

1 UaiSoccer SSL - TDP para LARC / CBR 2014 Bruno de P. O. Paiva 1 e Rodrigo R. Caputo 2 Abstract Este artigo apresenta a UaiSoccer, uma equipe da RoboCup Small Size League. Descreveremos os três módulos principais: mecânica, eletrônica e software, mostrando nossas soluções para os desafios que a categoria nos fornece. Apresentaremos o novo robô que desenvolvemos no último ano, o que nos possibilitou um grande salto de desempenho e resultados para nossa equipe. I. INTRODUÇÃO UaiSoccer é uma equipe brasileira de futebol de robôs formada por estudantes da Universidade Federal de São João del-rei. Ela foi fundada em 2009 e no ano seguinte participou da Latin American Robotics Competition pela Small Size League, obtendo o 4 o lugar e se tornando a melhor estreante na categoria daquele ano. Em 2013, com o novo robô finalizado, conquistou o 3 o lugar na CBR (Brasilian Robotics Competition). Em quase cinco anos adquirimos uma experiência significativa que nos permitiu transpor várias barreiras, e atingir alguns objetivos importantes. Hoje possuímos um robô SSL que pode ser utilizado não apenas para as competições da categoria, mas também para pesquisas em áreas afins. Descreveremos inicialmente a estrutura mecânica dando uma visão geral das construções de itens como nossa roda e chute. Em seguida serão apresentados os componentes eletrônicos que utilizamos embarcados no nosso robô, os microcontroladores, motores, drivers, além dos módulos de comunicação, dentre outros. Por fim iremos expor nosso sistema de software juntamente com os algoritmos e técnicas utilizadas. II. MECÂNICA Cada robô possui as dimensões de 178mm de diâmetro e 148mm de altura, dentro das regras da competição e são produzidos em grande parte por materiais de alta resistência mecânica e baixa densidade, como ligas de alumínio e açosliga, para garantir agilidade na movimentação dos mesmos sem prejudicar as questões estruturais. Para a movimentação dos robôs, são utilizadas quatro rodas omnidirecionais. O acionamento delas em conjunto gera o movimento do robô de acordo com o desejado, como descrito em [2]. Este sistema de movimentação é muito ágil pois o robô não precisa ser re-orientado para se mover, sendo assim muito utilizado no projeto das equipes que participam da SSL. 1 Bruno de P. O. Paiva é graduando em Engenharia Elétrica pela Universidade Federal de São João del-rei - MG. brunodepaula3p@yahoo.com.br 2 Rodrigo R. Caputo é graduando em Ciência da Computação pela Universidade Federal de São João del-rei - MG. rodrigokaputo@hotmail.com A roda é o componente mais importante do sistema de movimentação omnidirecional, pois o projeto delas deve ser feito de modo com que ela possa transladar na direção perpendicular ao eixo do motor sem que ela tenha que arrastar, o que diminui o atrito. Para que isso ocorra, a roda possui roldanas em sua volta envolvidas por anéis de vedação o-rings que tem o objetivo de facilitar a movimentação. As rodas (ver Fig. 1) são acionadas por motores EC 45 flat brushless de 30 Watt e a transmissão é feita por engrenagens cilíndricas retas usinadas em nylon 6.6 devido suas propriedades e requisitos do sistema. Fig. 1. Vista explodida da roda O ângulo de disposição das rodas em um sistema omnidirecional é relevante em alguns parâmetros como o esforço exigido em cada motor de transmissão. Algumas configurações são utilizadas por diversos modelos de projeto. O nosso modelo foi projetado em parceria com com o trabalho [1]. Elas são configuradas a 33, 147, 225 e 315 graus e levam em consideração restrições de espaço devido ao posicionamento dos sistemas de chute e drible. O sistema de chute é composto por um conjunto eixosolenoide de grande diâmetro acionado por uma placa eletrônica, o movimento do eixo é baseado nas leis de eletromagnetismo, o que impulsiona-o para frente com grande energia. O sistema de drible é responsável por manter o robô com o posse da bola durante a partida, o eixo revestido de borracha de silicone é acionado por um motor EC 20 flat brushless de 5 Watt e seu movimento de rápida rotação cria uma força de backspin, que direciona a bola contra o robô, e mantém a mesma em contato constante. No nosso atual projeto, o sistema de drible envolve cerca de 16% da bola. Na Fig. 2 é possível ver em (a) o modelo 3D do robô feito em CAD e em (b) o robô real usinado já com os circuitos eletrônicos conectados.

2 Fig. 3. Mother Board e BRD Motores conectadas no robô Fig. 2. (a) (b) (a) Modelo 3D do robô UaiSoccer (b) Robô real III. ELETRÔNICA O Departamento de Eletrônica é o responsável pelo desenvolvimento dos sistemas que controlam o acionamento e funcionamento dos diversos circuitos eletrônicos necessários para o correto funcionamento do robô. O Projeto UaiSoccer 1.0 Small Size é composto basicamente em sua parte eletrônica de duas placas de circuito impresso, que são chamadas Mother Board e BRD Motores. Estas são suficientes e necessárias ao correto funcionamento de sistemas como, controle de motores, comunicação wireless, acionamento do chute, detecção de bola, dentre outros fundamentais ao robô que serão citados como mais detalhes logo abaixo. A. Microcontroladores O Projeto UaiSoccer 1.0 Small Size na sua parte eletrônica, pode ser visto como de alta complexidade, logo quando foi analisado qual tipo de microcontrolador que se iria utilizar, a partir da consideração de questões como verba disponível e também a necessidade de componente com alto desempenho em processamento, chegou conclusão que a melhor opção seria microcontroladores dedicados ao tratamento de sinais os DSP s. Os DSP s adquiridos foram os seguintes: uma unida-de do DSPIC33EP64GP504 e duas unidades do DSPIC33EP- 64MC202, onde se tem que o primeiro dele recebe o nome de CONTROLE MOTORES, pois a sua função é apenas o acionamento dos motores que são responsáveis pela movimentação do robô. Já os outros dois microcontroladores, sendo um chamando CONTROLE ROBO e outro DSPIC CHUTE, têm funções diferentes e específicas. O DSP CONTROLE ROBO tem a função de receber informações de sensores como acelerômetro e giroscópio que possibilitam o controle da movimentação do robô como um todo de uma forma mais robusta e precisa, enquanto que o outro DSP chamando DS- PIC CHUTE tem a função de acionamento e monitoramento dos seguintes itens drible, chute, sensor infravermelho e nível de bateria. Uma observação interessante é que todos se ligam ao modulo de comunicação wireless via comunicação UART e que os DSP s CONTROLE ROBO e CONTROLE MOTORES possui entre eles comunicações UART, SPI, I2C que visam facilitar ao máximo as ações de controle para movimentação. B. Motores e acionamento Os motores utilizados nas rodas são os Brushless Maxon EC-45 Flat, que após pesquisa na literatura e com outras equipes da categoria foram vistos por todos os membros que participaram do projeto como a melhor opção para a função, pois a sua comutação e controle por intermédio do sensor de efeito hall e a possibilidade de atingir altas velocidades em baixas voltagens eram pré-requisitos fundamentais ao robô que em uma partida necessita de acelerações e desacelerações rápidas. Todavia para o correto funcionamento destes motores é necessário o uso de um driver que faz o acionamento dos mesmos através de um comando do DSP que indicará a velocidade desejada. Uma visão geral do sistema de acionamento das rodas é o seguinte: as rodas são acionadas

3 por esses motores, que, por sua vez, são acionados por circuitos integrados L6235PD que são os nossos drivers, leem a posição do rotor através dos sensores de efeito hall e fazem a lógica de acionamento do motor. Uma informação importante é que para o controle de velocidade dos motores, um dos sensores de efeito hall de cada motor é ligado no microcontrolador (DSPIC33EP64GP504). Ciente que este tipo de motor tem oito polos e que isto resulta dezesseis pulsos a cada giro é possível calcular a velocidade do motor através do tempo entre um pulso e outro do sensor de efeito hall. C. Sistema de chute Quando se pensou no sistema de chute haviam-se um problema considerável que era como seria possível gerar uma força considerável para lançar a bola, tendo no robô apenas uma alimentação de aproximadamente 12 V DC. Para solucionar a questão da tensão após pesquisa na literatura chegou à conclusão que o emprego do Chopper DC denominado conversor Boost seria capaz de resolver esta limitação que nós tínhamos até então. Por meio deste conversor foi possível que uma tensão de 12 V DC aplicada na sua entrada se tornasse 180 V DC que são empregado no carregamento de dois capacitores. Os parâmetros de chaveamento do conversor são 42 KHz com duty cycle de 70 por meio de uma comunicação sem fio. Sua interface com os microcontroladores é feita através da comunicação serial (RS-232). O processo de envio de informações é feito pela estação base que tem a função de enviar um broadcast com todas as informações para os robôs em campo que são capazes de identificar neste pacote recebido qual informação lhe pertence e descarta os dados que não são destinados a ele. E. Acionamento do motor do drible O motor do drible é o EC-20 flat Brushless Sensorless, ou seja, o mesmo não possui sensor de efeito hall. Logo foi necessário que o driver escolhido de acionamento do mesmo tivesse a capacidade de controlar a velocidade do motor sem o sensor de medição de velocidade. O circuito integrado TDA5145T é capaz de executar esta tarefa, devido ao artifício de FEM do motor para identificar a posição do motor e fazer a lógica de comutação. IV. SOFTWARE O software tem por objetivo entender os acontecimentos do jogo, definir estratégias e enviá-las para os robôs, para que os mesmos possam executar. O sistema é escrito em C++ usando o Qt Creator Framework, rodando numa plataforma Ubuntu GNU/Linux OS. Todo o processo que envolve o software pode ser definido como visto na Fig. 5. Antes de se tomar qualquer decisão, é necessário que tenhamos conhecimento do posicionamento e do estado de jogo em que estamos. Para isso há duas ferramentas fornecidas pela RoboCup: o Árbitro Eletrônico e o SSL-Vision [7]. Fig. 4. Circuito do Conversor Boost Com os dois capacitores carregados, é possível realização do chute. O qual é acionado e controlado através de um MOSFET em modo de saturação, que funciona como uma chave fechada entre o solenoide e o capacitor, sendo que quanto maior o tempo de chave fechada, maior será o fluxo de corrente sobre o solenoide e maior será a força a ser aplicada na bola. Por questões de segurança a tensão na saída do conversor Boost é monitorada pelo DSPIC CHUTE por intermédio de um divisor de tensão que relaciona o máximo de tensão de saída permitida no conversor Boost com o máximo de tensão suportado pelo DSPIC. D. Comunicação Para comunicação o projeto faz uso do módulo XBEE (série 1) que é capaz de receber e transmitir dados Fig. 5. Diagrama do sistema de software da equipe UaiSoccer A. Árbitro e SSL-Vision O Árbitro Eletrônico é um programa capaz de enviar as informações sobre o estado do jogo (falta, jogo acontecendo, pênalti, intervalo,...). Essas informações são cruciais para determinar os tipos de possíveis ações dos jogadores de acordo com as regras estabelecidas. O SSL-Vision é um sistema de captura e processamento das imagens do campo. Esse software, bem como o Arbitro Eletrônico, envia as informações por meio de pacotes UDP por uma rede que

4 conecte os todos os computadores envolvidos no jogo. Esses pacotes enviados pelo SSL-Vision contem informações gerais, como tamanho e largura do campo, bem como especificações mais avançadas, como posição e orientação de cada robô no campo. B. Recepção dos dados Há, dentro do sistema da UaiSoccer, um módulo de recepção responsável por manter todos os dados obtidos pela rede atualizados. Esse módulo é composto por dois subsistemas, responsáveis pelos dados do Árbitro e do SSL- Vision, como mostrado. Dentro desse módulo também é onde age filtros de ruídos de dados, como o Kalman [4], tornando os dados recebidos menos susceptíveis a erros de captação ou transmissão. C. Máquina de estados Para tomar ações durante o jogo, como avançar com a bola, entrar em modo de defesa, entre outros, escolhemos por usar uma máquina de estados finito (FSM). Uma FSM é um modelo matemático usado para representar a mudança de comportamento de um programa, dependendo dos parâmetros de entrada. Em nosso programa, utilizamos as informações vindas do árbitro e do sslvision sobre o estado do jogo, para decidirmos as ações que cada robô irá tomar. D. Designação de tarefas Logo após o estado do time ser definido, é necessário designar tarefas a cada um dos jogadores. Para cada estado da FSM, existe uma fila de prioridades definindo quais funções cada robô irá assumir, como mostrado na Fig. 6. A partir do primeiro elemento da fila, escolhemos o robô mais apto a assumi-lo, designando ao mesmo sua respectiva função. Assim então, realizamos a retirada dessa função e realizamos o processo até que não haja mais robôs. a posição e orientação que o robô deve alcançar e quais elementos ele deve acionar (drible, chute). F. Navegação Após a definição das novas coordenadas a serem alcançadas, é aplicado um algoritmo de navegação para definir o caminho para se efetuar o novo posicionamento. Esse algoritmo é baseado em um modelo de menor caminho em grafos. Para isso, modelamos um grafo como sendo cada um dos vértices as bordas do robô perpendiculares a uma reta imaginaria entre a origem e o destino do caminho a ser percorrido; e as arestas as ligações entre qualquer par de vértice que possa alcançar em linha reta o segundo a partir do primeiro, e vice-versa. A partir desse modelo, aplicamos o algoritmo de Dijkstra [5] e definimos a trajetória a partir do menor caminho obtido. G. Envio das informações Tendo então o caminho obtido, definimos as velocidades em cada uma das rodas para executar tal trajetória e geramos então um pacote com todas as informações que os robôs devem receber. Esse pacote é então enviado ao módulo responsável. Esse módulo pode assumir duas posturas diferentes: enviar os dados para os robôs reais presentes no campo, ou enviar os dados para o simulador GrSim [6]. Caso os dados sejam enviados para os robôs reais, é utilizado o protocolo de comunicação do transmissor de radiofrequência XBee R. Caso seja para o simulador, o pacote é enviado via protocolo UDP em rede local, com IP e porta específica do receptor. Sendo assim, cada meio de execução realiza suas atividades, gerando novos dados para que um novo ciclo recomece. V. TRABALHOS FUTUROS Após a utilização do nosso novo robô na CBR 2013 e na RoboCup 2014, fica claro a necessidade de uma reformulação no sistema de drible para facilitar o domínio da bola. É importante também uma medida para aumentar a confiabilidade dos nossos robôs, para enfim ser possível a utilização do time completo em campo. Por fim, novos estudos estão sendo feitos em relação às táticas e jogadas utilizadas durante o jogo. O STP [8] tem sido um trabalho bastante investigado pela nossa equipe e possivelmente trará bons resultados até a competição. REFERENCES Fig. 6. Fila de prioridades de um estado de ataque E. Execução das ações dos jogadores Após a determinação de cada ação aos jogadores, é realizado o calculo da nova posição que os mesmos devem assumir. Esse cálculo leva em consideração a formação que o jogador deve assumir. Cada função a ser executada está ligada a uma função específica no código, que determina [1] SOARES, S. J. P. Controle de um Robô Móvel utilizando linearização por realimentação f. Tese (Mestrado em Engenharia elétrica) Programa de Pós-Graduação em Engenharia Elétrica, Universidade Federal de São João Del Rei, São João Del Rei [2] INIESTA, E. D. (2006): Diseño e Implementación de Los Robots F180 Del ITAM. Instituto técnologico autônomo do México, [3] Fialho, A. S., Búrigo, A. C., Jurkovski, B., de Azevedo, C. K., Adolfo, C., Dalbem, C. M., de Melo Leonardi, E., da Fontoura Beltrão, F., Chies, F. A., Silva, G. H., Schmidt, I. A., Lopes, I. F., de Mello Bones da Rocha, J. P., da Silveira, K. S., Barreto, L. C. M., Zawacki, L. F., Cavinato, M. V., e Barone, D. A. C. RoboPET team description paper. Proceedings of 14th International RoboCup Symposium, Singapore, 2010.

5 [4] G. Welch and G. Bishop. An introduction to the kalman filter. Department of Computer Science, University of North Carolina, Tech. Rep. TR , [5] Cormen, Thomas H.; Leiserson, Charles E.; Rivest, Ronald L.; Stein, Clifford (2001). Section 24.3: Dijkstra s algorithm. Introduction to Algorithms (Second ed.). MIT Press and McGraw Hill. pp [6] GrSim RoboCup Small Size Robot Soccer Simulator; V. Monajjemi, A. Koochakzadeh, S. S. Ghidary ; [7] SSL-vision: The shared vision system for the RoboCup Small Size League; Zickler, Stefan and Laue, Tim and Birbach, Oliver and Wongphati, Mahisorn and Veloso, Manuela, 2010; [8] STP: Skills, tactics, and plays for multi-robot control in adversarial environments; Browning, Brett and Bruce, James and Bowling, Michael and Veloso, Manuela, 2005.