Desenvolvimento de robô guarda-redes para a equipa MinhoTeam

Universidade do Minho Escola de Engenharia Joel Alberto Abreu Sousa da Costa Desenvolvimento de Robô Guarda-Redes Para a Equipa MinhoTeam Dissertação de Mestrado Engenharia Eletrónica Industrial e Computadores Trabalho efetuado sob a orientação de Professor Doutor António Fernando Macedo Ribeiro janeiro 2024 Universidade do Minho Escola de Engenharia Joel Alberto Abreu Sousa da Costa Desenvolvimento de Robô Guarda-Redes Para a Equipa MinhoTeam Dissertação de Mestrado Engenharia Eletrónica Industrial e Computadores Trabalho efetuado sob a orientação de Professor Doutor António Fernando Macedo Ribeiro janeiro 2024 Direitos de Autor e Condições de Utilização do Trabalho por Terceiros Este é um trabalho académico que pode ser utilizado por terceiros desde que respeitadas as regras e boas práticas internacionalmente aceites, no que concerne aos direitos de autor e direitos conexos. Assim, o presente trabalho pode ser utilizado nos termos previstos na licença abaixo indicada. Caso o utilizador necessite de permissão para poder fazer um uso do trabalho em condições não previstas no licenciamento indicado, deverá contactar o autor, através do RepositóriUM da Universidade do Minho. Licença concedida aos utilizadores deste trabalho: Atribuição CC BY https://creativecommons.org/licenses/by/4.0/ i Agradecimentos Dedico esta secção para transmitir os meus mais sinceros agradecimentos a todas as pessoas que contribuíram e me apoiaram ao longo destes anos de curso que são finalizados com esta dissertação. Em primeiro lugar quero agradecer ao meu orientador Professor Dr. Fernando Ribeiro por todo o apoio e confiança que me foi transmitido assim como pela sua orientação que me fez crescer em todos os aspetos. Agradecer ao Professor Dr. Gil Lopes por toda a ajuda que deu a toda a equipa. Agradecerlhes pela oportunidade de fazer parte do LAR, deste projeto de equipa que seria impossível sem as suas intervenções e ainda pela possibilidade de representar esta equipa em competições nacionais e internacionais. Agradeço a todos os meus amigos, em especial aos membros da equipa por todos os dias e noites que passamos a trabalhar para alcançar o objetivo do projeto. Obrigado a todos por todas as experiências adquiridas que me permitiram evoluir a nível pessoal e profissional. Agradecer à minha namorada Alisson Faria, que sem ela seria incapaz de finalizar o curso e que tornou esta minha etapa muito mais fácil. Obrigado por toda a paciência e trabalho que causei, e por toda a ajuda e incentivo que recebi. À minha irmã e irmão, que sempre me apoiaram em todos os momentos e me permitiram focar em todo o trabalho da universidade. Obrigado por todos os concelhos que hoje me fazem uma pessoa melhor. Por último, e mais importante, agradecer ao meu pai, Manuel Costa e à minha mãe, Anabela Costa, por esta oportunidade de continuar a estudar. Sei que tiveram de lutar muito para isso ser possível e sem vocês nada disto aconteceria. Por tudo, obrigado pai e obrigado mãe. A todos, muito obrigado. ii Declaração de Integridade Declaro ter atuado com integridade na elaboração do presente trabalho académico e confirmo que não recorri à prática de plágio nem a qualquer forma de utilização indevida ou falsificação de informações ou resultados em nenhuma das etapas conducente à sua elaboração. Mais declaro que conheço e que respeitei o Código de Conduta Ética da Universidade do Minho. Universidade do Minho, Braga, janeiro 2024 Joel Alberto Abreu Sousa da Costa iii Resumo Desde 1997 que a equipa MinhoTeam, equipa de futebol robótico do Laboratório de Automação e Robótica do Departamento de Eletrónica Industrial da Universidade do Minho, participa em vários torneios, sendo um deles a Middle Size League do RoboCup [1]. Este projeto consiste no desenvolvimento de uma nova geração de robôs capaz de fazer frente às equipas atuais participantes na MSL. Mais concretamente, este projeto foca-se no desenvolvimento do robô guarda-redes da equipa de forma que seja capaz de participar num jogo de futebol robótico, conseguindo defender qualquer oportunidade de golo da equipa adversária e que participe em jogadas com a equipa. O desenvolvimento deste projeto passa então por módulos como visão por computador, controlo de movimento (robótica móvel) e alterações de hardware dos robôs da equipa anterior. O módulo de visão tem de ser capaz de identificar remates ou oportunidades de golo da equipa adversária e calcular trajetórias da bola. Também tem de ser capaz de perceber onde a bola se encontra em campo e qual a melhor posição do guarda-redes na baliza de forma a reduzir as possibilidades de golo. O módulo de controlo de movimento vai-se focar em mover o robô. Através de posições de referência, ou distâncias que tem de percorrer, este módulo deverá ser capaz de efetuar esses movimentos com a maior precisão possível. As alterações de hardware são necessárias para atualizar a tecnologia usada por estes robôs. Uma função inovadora é a implementação de um sistema que permite ao guarda-redes aumentar temporariamente a sua área para cima, em dez centímetros num máximo de um segundo. Palavras-Chave: Robótica móvel, RoboCup, MSL, Visão por Computador, Guarda-Redes iv Abstract Since 1997, the MinhoTeam robotic football team from the Laboratory of Automation and Robotics of the Department of Industrial Electronics at the University of Minho, has participated in several RoboCup leagues, one of them being the RoboCup Middle Size League [1]. The development of this project goes through modules such as computer vision, movement control and hardware updates on the robots. The vision module must be able to identify shots or goal opportunities of the opposing team and calculate ball trajectories. The module also needs to understand where the ball is on the field and what is the best position for the goalkeeper in order to prevent as much goals as possible. The movement control module focus on moving the robot. If the robot needs to go to reference positions, or go through certain distances, this module must be able to do these movements with the greatest possible precision. Hardware changes happen for the necessity to update the technology used by these robots. An innovative function is the implementation of a system that allows the goalkeeper to increase his size upwards, by ten centimeters for a maximum of one second, permitted by the rules. Keywords: Mobile Robotics, RoboCup, MSL, Computer Vision, Goalkeeper v Conteúdo 1 Introdução 1 1.1 MinhoTeam ...................................... 1 1.2 RoboCup ....................................... 2 1.2.1 RoboCupSoccer ............................... 2 1.2.2 RoboCup@Home ............................... 2 1.3 Middle Size League .................................. 4 1.4 Definição do problema ................................ 5 1.5 Objetivos ....................................... 5 1.6 Motivação ...................................... 6 1.7 Estrutura do documento ............................... 6 2 Estado da arte 7 2.1 Visão por computador ................................. 7 2.1.1 RGBD .................................... 8 2.1.2 HSV ..................................... 9 2.1.3 Redes neuronais ............................... 9 2.2 Equipas participantes na MSL ............................. 11 2.2.1 CAMBADA .................................. 11 2.2.2 Tech United Eindhoven ............................ 13 2.2.3 Falcons ................................... 15 2.3 Conclusões ...................................... 16 3 Robôs da equipa LAR@MSL 17 3.1 Estrutura mecânica .................................. 17 3.1.1 Sistema de manipulação de bola (dribblers) .................. 19 3.1.2 Compartimento do computador ........................ 20 vi 107 a) Imagem da Microsoft Kinect . b) Posição e orientação desejada. c) Posição e orientação real do robô na baliza. (Posicionamento e orientação - 2º teste) .......... 90 108 a) Imagem da Microsoft Kinect . b) Posição e orientação desejada. c) Posição e orientação real do robô na baliza. (Posicionamento e orientação - 3º teste) .......... 91 109 Altura máxima da estrutura móvel ........................... 91 110 Estrutura móvel subida ................................ 92 111 Defesa com a estrutura móvel ............................. 92 112 Teste de trajetórias no penálti ............................. 93 113 a) Imagem da Microsoft Kinect . b) Representação do robô (azul) na baliza (preto) e das coordenadas desejadas em centímetros. (Cálculo da trajetória do penálti - 1º teste) . . . 93 114 a) Imagem da Microsoft Kinect . b) Representação do robô (azul) na baliza (preto) e das coordenadas desejadas em centímetros. (Cálculo da trajetória do penálti - 2º teste) . . . 94 115 a) Imagem da Microsoft Kinect . b) Posição e orientação desejados para o robô. c) Posição e orientação real do robô na baliza. (Defesa do penálti - 1º teste) ........ 94 116 a) Imagem da Microsoft Kinect . b) Posição e orientação desejados para o robô. c) Posição e orientação real do robô na baliza. (Defesa do penálti - 2º teste) ........ 95 117 Festival Nacional de Robótica ............................. 97 118 RoboCup 2023 .................................... 98 xiii Lista de Acrónimos 3D Três Dimensões ADC Analog-to-Digital Converter DC Direct Current GB GigaByte GPIO General Purpose Input/Output GPU Graphics Processing Unit HSV Hue, Saturation, Value I2C Inter-Integrated Circuit IA Inteligência Artificial LAR Laboratório de Automação e Robótica LUT Look-Up Table MSL Middle Size League PC Portable Computer PLA Poliácido Láctico PPR Polipropileno Copolímero Aleatório PWM Pulse Width Modulation RAM Random Acess Memory RGB Red, Green, Blue xiv SSD Solid-State Drive TCP Transmission Control Protocol WLAN Wireless Local Area Network xv Capítulo 1 Introdução Esta dissertação tem como objetivo documentar o trabalho desenvolvido durante todo o projeto do robô guarda-redes para a equipa MinhoTeam. Neste primeiro capítulo é apresentada essa equipa, o RoboCup e a liga em que este projeto se insere, a Middle Size League (MSL). É ainda apresentada a definição do problema, assim como os objetivos, motivação e estrutura do documento. 1.1 MinhoTeam A MinhoTeam é uma equipa de robótica da Universidade do Minho em Portugal que compete em muitas competições, sendo uma delas a RoboCup . A equipa participou em várias ligas diferentes na competição, como RoboCup@Home , RoboCupJunior Soccer e ainda a MSL [11]. A MinhoTeam teve sucesso na competição RoboCup e sempre se classificou entre as melhores equipas nas suas ligas. Esta equipa dá a oportunidade de trabalhar em projetos de investigação, de desenvolvimento em robótica e participar em competições nacionais e internacionais [12]. A última vez que a MinhoTeam participou na MSL foi em 2016. Era utilizado um sistema de visão omnidirecional e uma câmara com canal de profundidade (apenas no guarda-redes). Uma das tecnologias a salientar, era o uso de três rodas omnidirecionais que permitiam ao robô obter uma movimentação omnidirecional [13]. A equipa desde que iniciou a sua atividade tem desenvolvido várias versões de robôs para competir na MSL. Nessas versões foram implementadas algumas soluções inovadoras que ainda hoje são utilizadas por outras equipas, tais como, o sistema de chuto eletromagnético [14] e os dribblers [15]. 1 1.2 RoboCup O RoboCup é uma competição internacional anual de robótica fundada em 1997 com o objetivo de promover a pesquisa e o desenvolvimento na área de robótica. O objetivo final do RoboCup é ter uma equipa de futebol constituída por robôs totalmente autónomos que sejam capazes de vencer, obedecendo às regras oficiais da FIFA , a equipa vencedora do Campeonato Mundial de humanos no ano de 2050 [1]. No entanto, devido ao crescimento e necessidade, o RoboCup expandiu para novos desafios, sendo estes: • RoboCupSoccer • RoboCupRescue • RoboCup@Home • RoboCupIndustrial • RoboCupJunior Nesta secção é abordada a liga RoboCupSoccer devido à participação da equipa, assim como a liga RoboCup@Home pois o Laboratório de Automação e Robótica (LAR) também tem uma equipa participante que se mostrou de grande ajuda no desenvolvimento do projeto. 1.2.1 RoboCupSoccer Nesta competição o desafio é o futebol robótico. Todas as ligas que englobam esta competição têm como objetivo a realização de jogos de futebol de duas equipas com robôs completamente autónomos. Estes têm de ser cooperativos num ambiente dinâmico que é o futebol [16]. Algumas das ligas focam-se apenas no desenvolvimento de software ( Simulation e Standard Platform ), enquanto outras procuram também o desenvolvimento de hardware ( Humanoid , Middle Size , Small Size ). Um requisito da liga de futebol robótico é que todos os robôs envolvidos na competição têm de ser completamente autónomos. A MSL é abordada individualmente devido à participação deste projeto na competição. 1.2.2 RoboCup@Home Esta competição tem o objetivo de desenvolver robôs de serviços para uso profissional e doméstico [17]. De forma a avaliar as habilidades e o desempenho dos robôs é efetuado um conjunto de testes em 2 ambientes domésticos realistas não padronizados. O foco da liga passa pelos seguintes pontos: • Interação e Cooperação Humano-Robô • Navegação e Mapeamento em ambientes dinâmicos • Visão Computacional e Reconhecimento de Objetos sob condições de luz natural • Manipulação de Objetos • Comportamentos Adaptativos • Integração Comportamental • Inteligência Ambiental • Padronização e Integração de Sistemas Esta competição conta com três ligas, Open Platform , Domestic Standard Platform e Social Standard Platform . A liga Open Platform não tem nenhuma restrição de hardware e oferece maior liberdade, pois o robô pode ser desenvolvido pelas equipas. A liga Domestic Standard Platform concentra-se em tarefas domésticas, sendo obrigatório o uso do robô TOYOTA , enquanto a Social Standard Platform foca-se nos aspetos sociais da interação de robôs humanos, utilizando o robô Pepper . A Figura 1apresenta o robô desenvolvido pelo LAR da Universidade do Minho para participar nesta competição, o CHARMIE ( Collaborative Home Assistant Robot Minho Industrial Electronics ) [18]. Figura 1: RoboCup@Home - CHARMIE 3 1.3 Middle Size League Esta liga existe desde 1997 com o objetivo de derrotar a equipa campeã mundial de humanos no ano de 2050. Desde a sua existência foram recorrentes ao longo dos anos alterações nas regras de forma a se aproximar do objetivo final. Uma dessas alterações foi em 2008 onde houve uma remoção das cores das balizas, pois até então uma baliza era amarela e outra azul para facilitar o processo de localização dos robôs. Esta atualização aproxima as equipas do objetivo final, pois num campo de futebol as balizas são brancas e desta forma o robô precisa de se localizar com as linhas e dimensões do campo, sendo necessário conseguir identificar as balizas e objetos desse [19]. As dimensões do campo são de 12 por 18 metros. O interior da baliza tem um metro de altura, dois metros de largura e cinquenta centímetros de profundidade e os robôs têm que possuir dimensões iguais ou inferiores às medidas de uma caixa de 52x52x80 centímetros. O guarda-redes pode aumentar a área lateral temporariamente em dez centímetros em qualquer direção. O robô pode pesar até um máximo de 40kg. Os jogos têm duas partes de quinze minutos cada, com um intervalo máximo de 10 minutos entre elas. As equipas são constituídas por cinco robôs, sendo que um é o guarda-redes. Como num jogo de futebol existem árbitros na partida que marcam faltas, foras, etc. As informações do árbitro são passadas aos robôs através de um computador externo denominado BaseStation que também pode calcular a estratégia da equipa. De forma a efetuar esta comunicação entre a BaseStation e os robôs é fornecida uma rede Wireless Local Area Network (WLAN). Figura 2: Jogo da MSL [2] 4 1.4 Definição do problema A última geração de robôs futebolistas desenvolvidos até à data do inicio deste projeto não dispunha de características ao nível das atuais exigências da MSL, tanto pela evolução das equipas como pela evolução das regras da liga. Por isso, pretende-se construir uma nova geração de robôs, a qual deve ter em conta a atual dinâmica de jogo. Para o desenvolvimento desta equipa de robôs futebolistas com as atuais exigências, é necessário um robô guarda-redes que seja capaz de assegurar a equipa para a defesa da baliza. O hardware e software necessários para este projeto são desenvolvidos por seis alunos do 5º ano do Mestrado Integrado em Engenharia Eletrónica Industrial e Computadores da Universidade do Minho. 1.5 Objetivos Este trabalho está inserido no desenvolvimento duma nova geração de robôs, consistindo na especificação e desenvolvimento do robô guarda-redes, um robô capaz de defender qualquer oportunidade de golo num jogo de futebol e permitindo que o mesmo participe nas jogadas de equipa. O desenvolvimento deste robô está inserido em módulos de visão, controlo de movimento, alterações da estrutura e também de hardware . O objetivo do módulo de visão é que o robô seja capaz de identificar remates ou passes, e que em caso de remate ou situação eminente de golo, consiga detetar a trajetória da bola e defender a mesma. O sistema de visão também precisa de identificar onde a bola se localiza em campo de forma a ter o melhor posicionamento possível na baliza. O módulo de controlo de movimento é responsável tanto por mover o robô, como por localizar o mesmo. O robô tem de ser capaz de se localizar no campo assim como identificar outros objetos no mesmo. A movimentação do robô tem de ser eficaz, onde este módulo tem de atualizar os atuadores de forma ao robô mexer-se para as posições desejadas da baliza. As alterações da estrutura e de hardware devem-se ao facto dos robôs não disporem das características ao nível das atuais exigências. Uma grande alteração efetuada foi adicionar mecanismos que permitem ao guarda-redes aumentar a sua área em dez centímetros de altura, por no máximo, um segundo. 5 1.6 Motivação Tendo como objetivo recriar a equipa MinhoTeam e voltar a participar nos campeonatos de futebol robótico, é necessário o desenvolvimento de um guarda-redes que seja capaz de atuar nas competições com as exigências atuais. A motivação para o desenvolvimento deste projeto para a equipa passa pela importância estratégica deste robô guarda-redes para a mesma, sendo necessário haver um foco individual para este robô devido às ações diferentes que este exerce em comparação com os restantes robôs. Com o desenvolvimento deste projeto espera-se que a MinhoTeam volte às competições e também melhore a sua prestação nas competições em que venha a participar. 1.7 Estrutura do documento Este primeiro capítulo faz uma introdução ao projeto, abordando a equipa em que este se insere assim como as ligas do RoboCup que essa participa. São também definidos o problema e objetivos assim como a motivação para este projeto. Além deste, existem mais 6 capítulos. O capítulo 2 faz uma análise ao que é robótica, robótica móvel e visão por computador. Ainda neste capítulo, é feito um estudo de métodos utilizados por outras equipas na MSL. O capítulo 3 aborda os robôs da equipa com uma descrição das alterações na estrutura mecânica, hardware e software . É um capítulo que descreve o trabalho efetuado que não se enquadra nos objetivos desta dissertação, mas que necessita de ser referido devido à sua relevância e trabalho, pois sem essas alterações não seria possível de efetuar o desenvolvimento do guarda-redes da equipa. No capítulo 4, denominado ”Implementação do Guarda-Redes”, são apresentados todos os métodos desenvolvidos para cumprir os objetivos impostos no guarda-redes da equipa, sendo este o tópico principal da dissertação. O capítulo 5 contém os testes efetuados, assim como os resultados obtidos dos métodos desenvolvidos para os objetivos do guarda-redes, sendo feita uma análise a todos esses resultados. No capítulo 6 é feito um resumo das participações da equipa no Festival Nacional de Robótica e no RoboCup2023 . O capítulo 7, como último capítulo, é constituído pelas conclusões retiradas no desenvolvimento deste projeto, assim como sugestões e ideias para trabalho futuro sobre o guarda-redes. 6 Capítulo 2 Estado da arte Neste capítulo é feita uma descrição do que é visão por computador e de dois métodos diferentes para deteção de objetos, através de visão clássica (modelo de cores) ou através de redes neuronais. Por fim, são vistas outras equipas participantes na MSL de forma a estudar os melhores e mais recentes métodos utilizados na construção do robô guarda-redes. 2.1 Visão por computador A visão por computador é um campo da Inteligência Artificial (IA) que permite que computadores e outros sistemas obtenham informações significativas de imagens digitais, vídeos e outras entradas visuais, tomando ações com base nessas informações. Se a IA permite que os computadores ”pensem”, a visão por computador permite que eles vejam, observem e ”entendam”. A visão por computador funciona da mesma forma que a visão humana, no entanto, os humanos têm uma vantagem inicial. A visão humana tem a vantagem de várias ajudas externas, como outros sentidos e até ajuda de outras pessoas para compreensão do observado, assim como anos de ”treino”que permitem identificar os objetos, a que distância estão, se eles se estão a mover, etc. A visão por computador treina as máquinas para executar essas funções, mas precisa de fazer isso em muito menos tempo com câmaras, informações e algoritmos, em vez de retinas, nervos óticos e córtex visual. Por exemplo, um sistema treinado para inspecionar produtos, pode analisar milhares de produtos por minuto, detetando defeitos ou problemas impercetíveis desse produto, ultrapassando rapidamente as capacidades humanas [20]. A Figura 3, retirada de um projeto do LAR, mostra um sistema de visão capaz de identificar sinais de trânsito. O sistema de visão representado na Figura 3utiliza redes neuronais para a identificação de objetos, sendo essas explicadas num dos tópicos adiante. 7 Figura 9: Defesa Penálti - Tech United [7] 2.2.2.2 Guarda-redes segurar a bola A tecnologia seguinte, tem como objetivo combater o facto do guarda-redes nunca segurar a bola, pois sempre que o mesmo defende, a bola vai para uma zona aleatória, podendo ser jogadores, zonas vazias, ou até mesmo para fora de campo. De forma a evitar essas situações, a equipa criou um método para o guarda-redes segurar a bola quando defende a mesma. Para o guarda-redes conseguir segurar a bola, a energia cinética da bola tem de ser dissipada num curto espaço de tempo. Utilizando um tecido com tensão folgada, existe mais tempo para dissipar essa energia, sendo utilizado um pano e uma rede na frente e nas costas do robô que dissipam a maior parte da energia cinética da bola antes de a apanhar para os seus dribblers . Esse pano dá à bola um movimento ascendente, devido ao fato da bola não ser capaz de se separar imediatamente do pano, reduzindo a velocidade da bola, sendo necessária a rede para levar a bola até ao buraco que conecta a bola aos dribblers (Figura 10). Figura 10: Protótipo Guarda-redes - Tech United [8] Durante o primeiro conjunto de experiências que a equipa fez, o guarda-redes foi capaz de apanhar a bola 82% das vezes (26 remates). O que acontecia, era que a bola ao ir da rede em direção ao buraco, 14 esta falhava o mesmo e em seguida saltava para fora. A solução foi adicionar uma camada de espuma em baixo, impossibilitando a bola de saltar devido à redução de energia. No segundo teste a percentagem de bolas apanhadas foi de 100% (em 39 remates) [8]. Esta solução demonstra-se bastante eficaz para combater lances de jogo em que o guarda-redes defende a bola mas a posse da mesma é perdida, devido ao mesmo não conseguir ficar com a bola. Evitam-se assim possíveis lances de golo em que os adversários marcavam após o guarda-redes defender na sua direção. 2.2.3 Falcons Falcons é uma equipa formada em novembro de 2013 que participa na MSL, sendo que todos os seus membros são funcionários da empresa ASML , estando situados em Eindhoven como a equipa anterior. A tecnologia referida desta equipa é a estrutura móvel. Essa é uma das tecnologias mais recentes instaladas nos guarda-redes atuais, permitindo ao guarda-redes estender a sua área num máximo de um segundo. A estrutura que a equipa desenvolveu é feita em fibra de carbono para se obter a máxima força com o menor peso. Para o acionamento da estrutura foi escolhido um atuador elétrico por ser leve, robusto e rápido. Utilizado um design com um íman móvel e uma bobina, são evitados cabos na zona da estrutura móvel, tornando a mesma menos suscetível a danos em cabos e na própria estrutura. Numa situação normal a bobina retém o íman com uma força de retenção. Quando o comando para estender a estrutura é enviado, leva menos de 100 milissegundos para a estender completamente. São utilizados três motores, sendo dois para os lados e um para cima [9]. Na Figura 11 é possível observar a estrutura móvel desenvolvida, assim como os atuadores utilizados bem como a sua localização. Figura 11: Estrutura móvel - Falcons [9] 15 2.3 Conclusões Sendo o RoboCup uma competição de robótica, demonstra uma gama de equipas bastante desenvolvidas e com tecnologias inovadoras, desde o desenvolvimento de hardware até sistemas de software bastante robustos e com aplicações no dia a dia. Sendo a competição que a equipa participou bastante relevante, as equipas apresentadas demonstram tecnologias muito interessantes. Uma dessas equipas, os CAMBADA , já não competiram nas últimas edições, sendo uma das equipas mais competitivas nos tempos em que participavam. As outras duas equipas apresentadas, os Tech United e os Falcons , foram as equipas que conquistaram os dois primeiros lugares na última competição, sendo os campeões a equipa dos Tech United . Estas duas equipas vêm constantemente a disputar estes lugares nos últimos anos, sendo fruto de muitos anos de trabalho contínuo em investigação e desenvolvimento de novos algoritmos e hardware . Analisando estas equipas é possível retirar algumas conclusões. A primeira conclusão é que grande parte das equipas utiliza o mesmo método para identificar a bola, utilizando a deteção da cor da mesma. Outra tecnologia que todas estas equipas demonstram no seu guarda-redes é a estrutura móvel, sendo ligeiramente diferente de equipa para equipa, demonstrando-se um desenvolvimento importante e necessário para suporte ao robô. Uma atualização bastante interessante e que apenas uma equipa utiliza, é a defesa de penáltis desenvolvida pelos Tech United , sendo que pode ser uma mais valia. Para concluir, as equipas utilizam métodos bastante semelhantes no desenvolvimento do guarda-redes sendo que têm umas pequenas alterações dentro de cada método, fazendo a diferença para melhores resultados. 16 Capítulo 3 Robôs da equipa LAR@MSL LAR@MSL é o novo nome da equipa da MinhoTeam que participa na liga MSL. Conforme já mencionado, a equipa MinhoTeam compete em várias competições, tanto nacionais como internacionais, sendo uma delas o RoboCup . Como uma das primeiras equipas a surgir nesta prova, contribui ao longo dos anos para a evolução da mesma nas várias ligas que participa e participou. A equipa já participou várias vezes na liga MSL com o objetivo de acompanhar a evolução tecnológica e jogar ao mais alto nível da liga, visto que desde a primeira vez que participou, a equipa já desenvolveu várias versões de robôs. A última alteração na estrutura dos robôs foi em 2016, sendo atualizada para uma estrutura mecânica mais estável. Mesmo assim devido à necessidade de evolução, os robôs tiveram de receber algumas alterações mecânicas. A nível de hardware foi necessário algumas reformulações, pois o existente era de difícil evolução, sendo que todos os processos de alterações mecânicas e de hardware foram desenvolvidos no LAR da Universidade do Minho. O software e a sua arquitetura também foram desenvolvidos do zero, de forma a estar mais atualizado com as especificações atuais, tornando assim mais fácil para a continuação do projeto. Neste capítulo são apresentadas as alterações da estrutura mecânica e a nova arquitetura de hardware , assim como o que foi reutilizado da plataforma. Por fim é feita uma análise da arquitetura de software implementada nos robôs, como o código de baixo nível, a comunicação e localização dos robôs, as ferramentas utilizadas e ainda o funcionamento do guarda-redes como atacante. 3.1 Estrutura mecânica Na MSL existem várias regras sobre os robôs, desde dimensão, peso e até cor. No entanto, desde que esteja dentro dessas regras estipuladas, o robô pode ter qualquer formato para a estrutura mecânica. Desta forma, ao longo das competições é possível ver equipas com várias formas pelas suas desvantagens 17 e vantagens, assim como para estratégia de jogo. Esta equipa utiliza uma plataforma de base circular com 50 cm de diâmetro (constituída por 3 chapas), que desta forma cumprem o limite máximo de 52 cm × 52 cm x 80 cm determinado pelas regras. Na Figura 12 está representada a chapa superior, do meio e a inferior de cada robô respetivamente. Figura 12: Chapas dos robôs Na chapa do meio, na parte de baixo, ficam os motores dos robôs, sendo que cada robô é constituído por três motores, um em cada roda. Na parte de cima desta chapa encontra-se o chuto eletromagnético. Na chapa superior encontra-se o sistema de manipulação de bola ou dribblers . O robô tem 4 ferros que funcionam como uma torre de forma a atingir o limite máximo de altura de 80 cm, onde é instalada a câmara omnidirecional. Para estabilidade desta torre, estão fixadas quatro barras de aço que unem a chapa superior com a torre. Esta torre, assim como as barras de estabilidade são possíveis de observar na Figura 13. Nesta Figura também se observa em cima o sistema de visão omnidirecional, com uma câmara virada para um espelho. Figura 13: Robô futebolista 18 3.1.1 Sistema de manipulação de bola (dribblers) O sistema de manipulação de bola tem como objetivo manter a bola na posse do robô, mesmo este estando em movimento, sendo obrigado a manter um movimento natural da bola. O mecanismo utilizado, é um mecanismo idêntico ao de outras equipas, consistindo em dois braços de controlo com um motor cada, com uma roda aparafusada de forma a receber a bola. Para manter os motores fixos à plataforma foi utilizado um tubo assim como uma pequena chapa de ferro (Figura 14a), que foram cortados de forma a prender o motor ao tubo. Este tubo foi fixado na peça de ferro que está aparafusada na chapa, por meio de um ferro cilíndrico, permitindo a liberdade de movimento dos dribblers para cima e para baixo, facilitando a entrada da bola nos mesmos (Figura 14b). (a) (b) Figura 14: a) Peças dribblers. b) Motores dribblers. Por fim, nos dribblers , são adicionadas as rodas que prendem a bola nos mesmos, permitindo um movimento natural da bola, como se pode ver na Figura 15 (estas rodas foram desenvolvidas por outro projeto da equipa). Figura 15: Dribblers dos robôs 19 3.1.2 Compartimento do computador Devido a alterações de hardware o robô passou a ser controlado por um computador portátil, sendo necessária a criação de um compartimento para proteção do mesmo. Portanto, foi criada uma caixa em ferro no meio do robô, aparafusada às quatro barras de aço por meio de umas chapas de ferro dos dois lados em forma de triângulo, não permitindo que a caixa perca estabilidade e se comece a deformar (Figura 16). Figura 16: Caixa do computador De forma a que o computador não fique em contacto com o ferro, é usada uma esponja que protege o computador e não permite que o mesmo se arranhe ou movimente pela caixa. Para dissipar o calor gerado pelo computador, foram feitas aberturas na esponja, que permitem a libertação de ar (Figura 17). Figura 17: Esponja da caixa do computador 20 3.1.3 Estrutura do guarda-redes Devido a esta alteração do compartimento do motor a estrutura do guarda-redes, usada para aumentar a área de defesa, teve de ser alterada. Em primeiro lugar, como a estrutura era composta por peças separadas e aparafusadas, criando mais instabilidade, foi decidido soldar todas as peças para se tornar uma peça única como se vê na Figura 18a. Em seguida, a estrutura foi movida mais para a frente para não ficar sobreposta ao compartimento do computador, criando assim mais proteção para o mesmo, como se pode ver na Figura 18b. (a) (b) Figura 18: a) Estrutura do guarda-redes. b) Estrutura no guarda-redes. Devido a esta alteração da posição da estrutura, um novo problema surgiu. Como as dimensões máximas do robô são de 52cm x 52cm x 80cm, a diagonal da sua base tem cerca de 73,5cm, sendo esse o tamanho máximo da estrutura caso colocada ao meio. Como a mesma foi passada para a frente, o robô, com a estrutura desse tamanho, já não se encontrava dentro das medidas. Por esse motivo, foram feitos cortes ligeiros nas barras horizontais, perto das pontas, permitindo dobrar as laterais verticais um bocado para trás, colocando-se assim o robô dentro das regras (Figura 19). Figura 19: Estrutura do guarda-redes alterada 21 3.1.4 Rodas omnidirecionais No eixo de cada caixa redutora está acoplado uma roda omnidirecional (Figura 20) que garante um movimento omnidirecional. Este tipo de movimento não apresenta qualquer restrição, podendo assim o robô mover-se em qualquer direção com uma qualquer orientação, tornando possível movimentos de translação e rotação em simultâneo. Figura 20: Rodas omnidirecionais Com o uso destas rodas, surgiu um problema, o desgaste dos rolos das rodas. Com o uso contínuo destas rodas, depois de algum tempo verificou-se um desgaste grave nos rolos, chegando até alguns a rasgar. Foi necessário desenvolver novos rolos em 3D (Figura 21a e21b) para imprimir numa impressora de resina. (a) (b) Figura 21: a) Modelo da peça 3D do rolo. b) Peça 3D do rolo. A resina utilizada foi a Resina lavável FlashForge , devido ao seu preço/qualidade, com boa resistência ao calor e sem fissuras ou deformações. A resistência ao calor é bastante relevante devido aos robôs andarem a grandes velocidades sobre o campo. 22 3.2 Hardware Um dos principais objetivos da equipa era tornar o hardware de todos os robôs bastante estável e fiável, de forma a permitir que em projetos futuros os elementos apenas se foquem no desenvolvimento de software e alterações inovadoras no hardware (como por exemplo chutos em parabólica). Este capítulo descreve todo o hardware comum entre robôs (o guarda-redes tem umas adições que são descritas no capítulo seguinte), desde a sua arquitetura, até aos vários elementos individuais. 3.2.1 Arquitetura de hardware No desenvolvimento desta nova arquitetura de hardware foi necessário tomar em conta alguns fatores, como o orçamento, estabilidade e eficácia. Esta arquitetura é composta por cinco sistemas, sendo esses os sensores, os atuadores, a fonte de energia, o sistema de controlo e o sistema de processamento. O sistema de processamento é composto pelas duas unidades de processamento, sendo essas o Portable Computer (PC) (unidade de processamento principal) e a placa de hardware com a ESP32 - SPARKFUN THING (unidade de processamento de baixo nível). O sistema de controlo é composto por duas placas, uma responsável pelo controlo dos motores e a outra pelo controlo do chuto eletromagnético. Essas placas vão ser abordadas na secção dos atuadores no seu respetivo atuador. Os sensores são constituídos por três encoders (um por cada motor), uma bússola e duas câmaras, a câmara BlackFly PGE 13S2C que é responsável pela localização dos robôs e a câmara da Xbox 360 , Microsoft Kinect , câmara para deteções mais precisas no ambiente. No caso do guarda-redes, é ainda adicionado outro sensor para suporte da localização, o LIDAR URG-04LX-UG01 . Os atuadores são os motores dos dribblers já referenciados para manipulação da bola, os motores de movimentação dos robôs, o chuto eletromagnético e ainda um pequeno ecrã colocado no topo do robô para disposição de algumas informações. A fonte de energia é uma Power Box desenvolvida por outra dissertação da equipa, onde a mesma é alimentada por umas baterias desenvolvidas no LAR. A Figura 22 representa uma visão geral do sistema onde se pode perceber como é que todos se relacionam entre si. 23 Figura 32: Motores na base do robô De forma a controlar estes três motores, é utilizada a placa OMNI3D-MAX (Figura 33) desenvolvida pela empresa SAR (Soluções de Automação e Robótica). Esta placa abstrai o procedimento de controlo individual destes três motores à unidade de processamento de baixo nível, pois é capaz de controlar de forma independente três motores DC de 24V até 50A de corrente por motor. Assim, a unidade de processamento de baixo nível apenas precisa de indicar o tipo de movimento desejado para a OMNI3DMAX calcular os valores a aplicar a cada motor individualmente. Figura 33: OMNI3D-MAX [10] Para simplificar a interação do utilizador com a placa OMNI3D-MAX , é disponibilizada uma biblioteca open-source para programação em C e direcionada para o Arduino IDE . Esta biblioteca contém funções de configuração, de leitura e de movimentação. Esta placa contém vários modos de movimentação, sendo o mais relevante a movimentação omnidirecional, linear e posicional de três motores com ou sem controlo PID. Um modo que a placa também oferece é o modo de calibração. Este modo coloca os motores a rodar de forma a perceber qual a força 30 mínima necessária para os motores arrancarem com o peso a que estão sujeitos. Nos robôs é implementado o modo de movimentação omnidirecional de três motores com controlo PID. Deste modo o controlo é em malha fechada com esse controlador, sendo necessária a leitura do valor da contagem incremental dos encoders dos três motores. Na biblioteca disponível existe uma função que recebe três parâmetros. O primeiro e segundo parâmetro são recebidos em percentagem e equivalem à velocidade linear e angular respetivamente. O terceiro parâmetro equivale à direção do movimento de translação que é recebido em graus, equivalente ao ângulo entre a frente do robô e a direção desejada. Sendo assim, caso seja desejado que o robô vá com velocidade máxima para a sua esquerda enquanto o mesmo tem uma velocidade angular de 10%, é enviado para esta placa o comando de movimentação com os valores de 100, 10 e 90 respetivamente. Todo o processo de cálculo para obter os valores necessários a aplicar a cada motor é feito por esta placa de controlo. De forma a obter o movimento desejado existem dois componentes importantes a serem calibrados, o PID e a rampa de aceleração [28]. A rampa de aceleração é configurada através do parâmetro slope e do parâmetro Kl , sendo este o ”fator limiar”, um fator dedicado à potência que é necessário aplicar aos motores para os colocar no limiar do movimento. Uma rampa de aceleração bem ajustada permite um arranque eficaz, suave e com deslizamento mínimo. 3.2.4.2 Chuto eletromagnético O chuto eletromagnético, é constituído por uma bobina eletromagnética, uma bateria de condensadores com um total de 4,3 mF e 441 V de tensão máxima, uma placa controladora e duas bobinas com 3,8 mH de indutância conjunta, usadas para recarregar a bateria de condensadores (Figura 34). Figura 34: Componentes chuto eletromagnético 31 À esquerda na Figura 34 é possível observar a bobina eletromagnética [29]. Como se verifica nessa figura, existe uma abertura no meio da mesma. Dentro desta abertura é colocada uma haste constituída por ferro e nylon , onde cada um ocupa exatamente metade da haste separadamente. A parte de trás dessa haste é apertada a um elástico que obriga a mesma a manter o nylon dentro da bobina. Percorrendo corrente elétrica por essa bobina, é gerado um campo eletromagnético que impulsiona a haste para o lado do nylon , o que faz impulsionar um objeto que esteja à frente da mesma, neste caso a bola. Como a haste está apertada ao elástico, quando o campo eletromagnético desaparece, o elástico coloca a mesma na posição inicial, pronta para outro remate. A força aplicada pela haste na bola é proporcional à quantidade de energia que percorre a bobina. Esta quantidade de energia, armazenada na bateria de condensadores, é controlada por uma placa de controlo desenvolvida por um ex-elemento da equipa (placa à direita na Figura 34), que contém circuitos de controlo e de potência. Assim, com esta placa é possível controlar a duração da descarga de energia para a bobina. 3.2.4.3 Ecrã Um dos atuadores adicionados foi um Display OLED com 0,98 polegadas com comunicação InterIntegrated Circuit (I2C). Este ecrã situa-se na parte de cima do robô com o intuito de fornecer algumas informações à equipa, desde percentagem das baterias, carga dos condensadores do chuto, posição do robô no campo e até mesmo os parâmetros enviados para a OMNI3D-MAX . Existe ainda um quadrado no ecrã, que indica se a unidade de processamento de baixo nível está a funcionar corretamente (se o quadrado estiver a piscar é porque está a funcionar como desejado). Na Figura 35 é possível ver este ecrã com a posição dessas informações, sendo que algumas estão no valor por defeito devido ao robô não estar com tudo ligado. Figura 35: Ecrã robô 32 3.2.5 Fonte de alimentação A fonte de alimentação deste robô é uma caixa de potência que é alimentada pela bateria do robô. Todo o circuito de potência desta caixa, assim como a caixa em si, foram realizados por outra dissertação da equipa, sendo uma das peças fundamentais de todo o projeto. Figura 36: Caixa de potência Em relação às baterias, foram desenvolvidas 14 baterias, duas para cada robô. Cada bateria tem uma capacidade de 22,2V e 6700mAh . Nestas baterias são usadas pilhas LI-ION 18650 3,7V 3350mAh , o que faz um sistema de dois packs de pilhas em paralelo, sendo que cada pack é constituído por seis pilhas em série. Para fazer estas baterias foi usada uma máquina de solda por ponto (Figura 37a) de forma a ligar as células (Figura 37b) para criar cada um dos packs . (a) (b) Figura 37: a) Máquina de solda por pontos. b) Células conectadas. Após ligar todas as células foi necessário soldar os cabos de alimentação e de balanceamento, assim como aplicar uma manga retrátil para proteção das mesmas (Figura 38). 33 Figura 38: Packs baterias Cada bateria necessita de dois packs , sendo necessário criar uma caixa, tanto para proteção, como para facilidade de transporte. Devido à necessidade da criação desta caixa, foi ainda instalado um display que mostra informação sobre a carga da bateria. Figura 39: Caixa bateria Esta caixa tem também uma característica bastante interessante, que é uma espécie de carril (como é possível ver na Figura 39 à direita). Assim, colocar e tirar baterias tornou-se um processo muito mais rápido, pois é só colocar a bateria no carril que está no robô (Figura 40), ligado à caixa de potência, fazendo o contacto entre a bateria e esse conector. Figura 40: Carril do robô 34 3.3 Software No MSL cada robô tem de jogar autonomamente e partilhar informações em tempo real. De forma a tornar o robô autónomo, é necessário uma estratégia para os robôs saberem que funções executar em cada momento. Esta estratégia é calculada pela BaseStation (desenvolvida por outra dissertação da equipa), que funciona como uma espécie de treinador. Esta comunica com os robôs orientando-os para o local onde se devem deslocar e que habilidades usar (chutar, passar, receber a bola, mover para a bola, etc), sendo que estas habilidades foram desenvolvidas por outra dissertação da equipa. Estes projetos apenas se interligam com o guarda-redes quando se decide usar o mesmo como atacante, pois como guarda-redes, todo o processo de posicionamento e decisão é feito por ele mesmo como será visto mais à frente (exceto decisões de paragem de jogo em que a BaseStation envia a informação para o mesmo parar, como por exemplo, quando a bola vai ser reposta em jogo pós golo). Um processo bastante importante que sem ele seria impossível de jogar e até mesmo o guarda-redes sendo independente necessita dele, é a localização dos robôs. De forma a controlar os robôs, é também necessário controlar o hardware (código de baixo nível) assim como toda a comunicação entre o mesmo. Assim sendo, este tópico explica o software geral dos robôs da equipa (código de baixo nível), o tipo de comunicação entre o hardware do robô, os métodos de localização e ainda as ferramentas utilizadas para o software do guarda-redes. 3.3.1 Código baixo nível O hardware de baixo nível foi modificado sendo assim necessário o desenvolvimento de um novo código para possibilitar o controlo completo do hardware . Esse código foi desenvolvido para a ESP32 - SPARKFUN THING devido ao seu preço baixo, performance elevada e módulos de Bluetooth e Wi-Fi já integrados. O código foi desenvolvido em linguagem C no IDE do Arduíno. Este código fica responsável por receber comandos por parte da unidade de processamento principal, decifrá-los e atuar respetivamente, atualizando os atuadores desejados com os valores calculados. Assim sendo, existe uma função dedicada a receber comandos e outra a decifrá-los, estando sempre em ciclo pronto a receber os mesmos. É também responsável por ler os valores do ADC sobre as baterias, assim como os valores da bússola e da OMNI3D-MAX , de forma a enviá-los para a unidade de processamento principal. Existe uma função de setup para inicializar todos os módulos, como o baudrate , atribuição de pinos 35 para comunicação I2C, General Purpose Input/Output (GPIO), OMNI3D-MAX , etc. Para perceber melhor esta explicação, são apresentados dois fluxogramas deste programa (Figura 41), a função principal e a função responsável por receber os caracteres vindos da unidade de processamento principal. Figura 41: Fluxogramas código baixo nível A função Scanner verifica o primeiro carácter do comando, e dependendo do valor desse carácter, age em conformidade. Por exemplo, para atribuir uma velocidade aos motores é utilizado o carácter M , em que é necessário três valores, velocidade linear, rotacional e direção separados por vírgulas. Então o comando recebido pode ser, por exemplo, ” M,80,10,270 ”, que resulta num movimento com velocidade linear de 80%, rotacional de 10% na direção dos 270º do robô. Caso o Scanner não receba esses três 36 valores, o comando é ignorado. Para comunicar com a OMNI3D-MAX existem algumas funções da biblioteca que permitem atualizar os valores tanto da rampa como do PID, assim como enviar a velocidade linear, rotação e direção desejadas para o robô, sendo que é a OMNI3D-MAX que calcula através desses valores a velocidade desejada para cada motor. 3.3.2 Comunicação entre hardware Uma informação bastante relevante do software é o meio de comunicação. No caso destes robôs existe a comunicação entre esses e a BaseStation , sendo esta desenvolvida por outro projeto, onde foi usado o protocolo de WebSocket , que é baseado no protocolo Transmission Control Protocol (TCP). Outras comunicações bastante relevantes, sendo essas o foco principal desta secção, é a comunicação entre os módulos de hardware do robô (Figura 42). Figura 42: Diagrama de comunicação 37 Um protocolo de comunicação bastante usado nestes robôs é o protocolo I2C, sendo um protocolo utilizado para ligar periféricos de baixa velocidade a uma placa principal. A principal vantagem deste protocolo é o facto de conter um barramento compartilhado, permitindo que se possa adicionar dispositivos de forma independente. Este protocolo foi usado para as comunicações entre a ESP32 - SPARKFUN THING , a bússola, o ecrã e ainda a placa de controlo dos motores. A comunicação da ESP32 - SPARKFUN THING para a placa de controlo do chuto e motores dos dribblers é feita através da ativação de certos pinos com uso de Pulse Width Modulation (PWM), sendo a comunicação através do GPIO da placa. A comunicação entre a Microsoft Kinect , o LIDAR e a ESP32 - SPARKFUN THING com o PC, é feita por Serial Communication . Por fim a comunicação entre a câmara BlackFly PGE 13S2C e o PC é feita por Ethernet ( GigE Vision ). 3.3.3 Localização guarda-redes A localização de um robô no espaço de jogo é talvez uma das tarefas mais importantes, uma vez que a falha neste processo leva à atribuição de informação errada sobre todo o mundo que o rodeia [30]. Para a localização destes robôs é utilizada a câmara BlackFly PGE 13S2C orientada para um espelho catadióptrico, permitindo obter uma imagem dos 360º do robô. Este método de visão é usado por quase todas as equipas da MSL e foi desenvolvido por um dos projetos da equipa. Resumindo o método de localização, após a obtenção da imagem à volta do robô, são aplicados filtros para encontrar as linhas brancas do campo e com uso de um Template Matching conseguir perceber em que zona do campo se encontra este robô. O funcionamento do Template Matching pode ser resumido a sobreposição da imagem filtrada com uma imagem do campo de futebol (Figura 43) com as dimensões corretas, verificando-se em que posição tem mais pixeis coincidentes. Figura 43: Template localização 38 Na Figura 44 é possível ver o resultado da localização de um robô e da bola no campo. Na esquerda da imagem também se podem ver as linhas brancas que a câmara deteta, assim como a localização antes e depois de ser filtrada. Como se vê na imagem, a precisão não é muito elevada, sendo que também não é necessária para os robôs na frente. O mesmo já não se pode dizer em relação ao guarda-redes, pois este necessita da localização exata, pois uns centímetros de diferença podem significar um golo. Isso também se aplica para a bola, sendo esse um dos motivos de se usar a Microsoft Kinect para detetar a bola com mais precisão no espaço de coordenadas. Figura 44: Localização robô Desta forma, para complementar a localização, o guarda-redes usa um LIDAR que indica com precisão onde se encontra o guarda-redes na baliza, através da deteção da parte de trás da mesma e dos postes com o uso do Template Matching . O LIDAR não pode ser usado como único método de localização pois tem um processamento de informação lento, visto que a informação do robô é atualizada menos de 10 vezes por segundo. Assim sendo, para a localização do guarda-redes é utilizado o melhor dos dois mundos, sendo a câmara o método de localização principal, pois tem um processamento de informação rápido, com o complemento do LIDAR que torna a localização muito mais precisa. 39 4.1.2.2 Redes Neuronais para deteção de objetos A equipa decidiu utilizar redes neuronais (algoritmos de YOLO com uso de segmentação), para detetar objetos no meio envolvente do robô, como a bola, a baliza, os robôs da equipa e os adversários. O desenvolvimento da rede ficou a cargo de outra dissertação tendo a equipa ajudado na aquisição de dados ( dataset ). Para construir esta rede com vários objetos foram recolhidas várias fotos, onde de seguida era feita a classificação desses objetos. Foi usado o Label Image para marcar os objetos com os respetivos nomes. Em cenários normais a legenda de imagens é feita com quadrados sobre os objetos, mas no âmbito deste projeto foi usada a segmentação, que se baseia no recorte exato do objeto para o identificar. Assim, os pixeis identificados como objeto dizem respeito apenas a esse, enquanto que na legenda com quadrados, muitos pixeis identificados no objeto dizem respeito ao cenário por trás do robô. Isto torna a rede mais robusta e permite que a identificação de objetos sobrepostos aconteça mais facilmente, pois a área de um objeto é menor que a área do quadrado envolvente do mesmo. Na Figura 48 é possível ver essa segmentação sobre os vários objetos e à esquerda as classes (objetos) que aparecem nesta imagem. Figura 48: Segmentação de objetos Após legendar todos os objetos em todas as imagens foi utilizado o Roboflow [34] para dividir as imagens em imagens de treino, de teste e de validação, passando em seguida para o treino da rede com o novo dataset . Este foi o método final utilizado para deteção da bola, sendo também utilizado para deteção de robôs e da baliza. 46 4.1.3 Posição da bola Após a bola ser detetada na imagem foi necessário calcular as coordenadas dessa. O cálculo da posição da bola no plano cartesiano passou por duas fases. Na primeira fase, o referencial do plano era o robô em si, sendo as coordenas em relação ao guarda-redes. Numa segunda fase, essas coordenadas foram transformadas para ter o centro da baliza como referencial. Também se descrevem as transformações necessárias a realizar quando a informação da posição da bola vem do módulo da câmara de localização ou da BaseStation . 4.1.3.1 Referência no robô Numa primeira fase é detetada a posição da bola relativamente ao robô. Para se obter esta posição, o primeiro passo é obter o ângulo da bola relativamente ao robô, como exemplificado na Figura 49. Figura 49: Ângulo da bola ao robô Sabendo a resolução da imagem da Microsoft Kinect é calculada a distância da bola ao centro da imagem em pixeis (Figura 50). Subtrai-se metade dessa resolução a essa posição, obtendo-se a distância representada na figura. Caso a bola se encontre na esquerda dessa metade, esse valor será negativo, definindo o lado em que a bola se encontra. 47 Figura 50: Distância da bola ao centro Para se obter o ângulo é usada uma regra de três simples (equação 4.1), visto que o ângulo total ou campo de visão é conhecido (57º nesta câmara), assim como a resolução total e a distância ao meio em pixeis (obtida na explicação anterior). α=dist_meio ∗57 Largura (4.1) Após calcular o ângulo é necessário utilizar a distância que a câmara indica. A obtenção desta distância trouxe um problema, pois em processo de desenvolvimento descobriu-se que a Microsoft Kinect tem duas versões, uma em que a distância recebida é entre a câmara e o objeto, e outra em que essa distância é entre o plano do objeto (bola) e a câmara, sendo a segunda versão a utilizada neste projeto. Essa distância está representada na Figura 51 com a letra D. Figura 51: Posição da bola relativa ao robô 48 A ordenada da bola é dada pela distância retornada pela Microsoft Kinect e a abcissa é dada por essa distância a multiplicar pela tangente do ângulo calculado. Como a outra versão da câmara também foi utilizada no início do projeto, a transformação também é explicada. A distância que a câmara fornecia está representada com a letra Cna Figura 51, sendo a ordenada da bola calculada com a multiplicação de Ccom o cosseno do ângulo e a abcissa a multiplicar com o seno. 4.1.3.2 Referência no centro da baliza Na segunda fase é calculada a posição da bola em relação ao centro da baliza. Foram necessárias algumas transformações, dando uso a partes do método anterior e reutilizando-se trabalho desenvolvido. A troca de referencial consiste numa rotação e numa translação do robô para o centro da baliza, sendo esta mais simples uma vez que a localização já indica a posição e rotação do robô em relação ao centro da baliza. Na Figura 52 está representado o processo de rotação do referencial do robô. Figura 52: Rotação do referencial 49 Como se vê na Figura 52 a rotação tem influência no ângulo α, sendo este uma soma do ângulo do robô em relação ao centro da baliza (retornado pela localização), equivalente ao ângulo θ, com o ângulo α’, calculado como na secção 4.1.3.1 (equação 4.2). α=θ+α′(4.2) A rotação do referencial fica assim completa, sendo o novo ângulo entre a bola e o referencial no centro da baliza dado por α. Devido ao uso desta versão da câmara a distância retornada equivale à letra Dda Figura 52, sendo necessário calcular a distância representada com a letra Catravés da divisão de Dcom o cosseno de α’ (equação 4.3). C=D cos(α′)(4.3) Em seguida é necessário fazer uma translação do referencial obtido no passo anterior para o referencial do centro da baliza, estando este processo representado na Figura 53. Figura 53: Translação do referencial 50 No primeiro passo são calculadas as coordenadas da bola no novo referencial após a rotação, sendo a abcissa (distância L) e a ordenada (distância D) do referencial X′Y′representada na Figura 53. Tendo sido já calculado o ângulo αe a letra C, é utilizada a equação 4.4 de forma a obter a distância L. L=C∗sen(α)(4.4) A distância Dé obtida através da equação 4.5. D=C∗cos(α)(4.5) Calculadas as coordenadas da bola neste novo referencial X′Y′, a translação equivale, como representado nas equações 4.6 e4.7, à soma dessas coordenadas com a posição do guarda-redes em relação ao centro da baliza (PxePy), sendo estas posições fornecidas pela localização do robô. Ballx=L+Px(4.6) Bally=D+Py(4.7) 4.1.3.3 Posições externas No caso da Microsoft Kinect não encontrar a bola a informação da mesma é obtida pela câmara de localização ou pela BaseStation . Estes dois processos utilizam um referencial com origem no centro do campo e uma orientação horizontal. Na Figura 54 está representado a vermelho o referencial utilizado pela câmara de localização e pela BaseStation , e a verde o referencial utilizado pelo guarda-redes. Figura 54: Referenciais da BaseStation (vermelho) e do robô (verde) 51 De forma a fazer uma transformação do referencial vermelho para o verde, é necessário rodar o referencial 90º e fazer uma translação de meio campo. A abcissa do referencial verde equivale ao negativo da ordenada do vermelho (equação 4.8) e a ordenada do referencial verde equivale à abcissa do vermelho somado com a distância de meio campo (equação 4.9). XGK =−Y(4.8) YGK =X+HorizontalSize 2(4.9) 4.1.4 Filtro da posição da bola Um problema detetado na posição da bola eram as variações da mesma, até mesmo com a bola parada. Devido à deteção do ponto central da bola não ser sempre exatamente o mesmo, havia oscilações na posição da bola, sendo que esta oscilação era proporcional à distância à bola. Por esse motivo foi criado um filtro simples que procura combater estas pequenas oscilações, e que coloca um certo peso nas posições anteriores, fazendo depois uma média desses valores. Considera-se que o filtro vai utilizar nvalores anteriores, sendo que o índice 0equivale ao valor mais recente e o índice nao mais antigo sendo acrescentado o novo valor ao início do array . Sendo então o array composto por nelementos i, o peso de cada elemento será igual a 1/(1 + i), tornando assim o peso menor para posições mais antigas. Como se pode ver na equação 4.10 todos os nvalores são somados com o seu respetivo peso, faltando apenas fazer a média destes valores. h= n ∑ i=0 x[i] 1 + i(4.10) De forma a fazer a média de todos estes valores é necessário somar todos os pesos que se usaram anteriormente (equação 4.11) para dividir aos valores somados (equação 4.10). sum = n ∑ i=0 1 1 + i(4.11) O valor final filtrado com as nposições anteriores é dado pela equação 4.12. filtered =h sum (4.12) 52 4.1.5 Deteção de remates Após ser calculada a posição da bola o guarda-redes necessita de perceber quando existe algum remate em direção à baliza. Desta forma, o robô verifica em todos os momentos se há algum tipo de remate para atuar de acordo. A única forma de identificar um remate é através da velocidade da bola. Visto que os robôs podem andar com a bola em direção à baliza, foi necessário levar em conta estas velocidades de forma a que o guarda-redes não identificasse remates quando existe algum jogador a deslocar-se com a bola em direção à baliza. Isto possibilita que bolas em direção à baliza, abaixo da velocidade mínima estipulada para remate, o guarda-redes não o considera, não se movimentando para fazer a defesa. Este problema foi resolvido com o posicionamento do guarda-redes na baliza. Na Figura 55 está representado o fluxograma da função responsável por verificar remates, retornando True no caso positivo e False caso contrário. Figura 55: Verificar Remate 53 A velocidade da bola é calculada com base na distância a cada ciclo de processamento do código, sendo que a cada iteração é calculada a velocidade com base no tempo de ciclo e com a distância do robô à bola no ciclo atual e anterior (equação 4.13). vel =dist −dist_ant time −time_ant (4.13) Enquanto a velocidade da bola permanecer acima da velocidade mínima o robô estará sempre a detetar um remate, fazendo-o calcular a trajetória da bola repetidamente e solucionando assim um problema, bolas em arco, permitindo que o guarda-redes atualize sempre a posição em que a bola vai intercetar a linha da baliza. 4.1.6 Defesa de remates Para o guarda-redes defender os remates foi necessário desenvolver uma previsão da trajetória da bola, sendo que sem este método a única solução seria o robô seguir a mesma, fazendo o guarda-redes raramente chegar a tempo de defender. Foram desenvolvidos e testados dois métodos de previsão, um relativamente ao robô e outro relativamente à baliza, sendo analisada a razão do escolhido. O que todos estes métodos têm em comum é a necessidade de dois frames em que o remate é encontrado, pois para uma previsão são necessários no mínimo dois momentos da bola em movimento. 4.1.6.1 Previsão da trajetória - Referência ao robô Este método usa o plano cartesiano da bola relativamente ao robô. Nos momentos em que um remate é detetado, com dois frames , a posição da bola desses dois é guardada, sendo possível traçar uma reta que permitirá perceber onde a bola vai intercetar o eixo do robô (Figura 56). Para determinar a função da reta são utilizados esses dois pontos. De forma a descobrir o declive, é usada a equação 4.14: m=Y2−Y1 X2−X1 (4.14) È usada a equação 4.15 para descobrir a ordenada na origem. 54 b=Y2−(m∗X2)(4.15) A posição que a bola interceta o eixo do robô equivale ao valor das abcissas que tem como ordenada 0, dado pela equação 4.16. P=−b m(4.16) Se este valor for negativo significa que a bola vai intercetar o eixo do robô no seu lado esquerdo, definindo assim a direção que o mesmo tem de se mover. Figura 56: Previsão da trajetória - Robô O principal foco deste método era o tempo de reação quando o robô se encontra na lateral da baliza, pois dessa forma em vez do robô se deslocar para trás para onde a bola vai intercetar a baliza (representado na Figura 57 com uma cruz (X)), andava lateralmente para impedir esse remate (representado na Figura 57 com um certo (✓)). 55 Figura 65: Orientação por gama de valores Diferente dos métodos anteriores que usavam a posição da bola para se orientar, a segunda alternativa (método final implementado) utiliza como referência a posição do guarda-redes na baliza (demonstrado na secção 4.2), pois esse já depende da posição da bola. Assim, a orientação é calculada através de uma equação de terceiro grau em que a entrada xcorresponde à localização do robô na baliza e a saída y corresponde à orientação do robô. y=A∗x3+B∗x(4.19) Após alguns testes, os valores de AeBescolhidos foram 0.00014 e0.1respetivamente, obtendo o gráfico representado na Figura 66. Figura 66: Equação 3º grau - Orientação 62 O eixo das abcissas corresponde à localização do robô na baliza em centímetros e o eixo das ordenadas corresponde à orientação em graus. A equação escolhida foi de terceiro grau de forma a obter valores negativos quando o robô se encontra no lado negativo da baliza, obrigando o guarda-redes a rodar para lados diferentes. Este método mostrou-se bastante robusto, pois mesmo havendo oscilações na posição do guardaredes, não eram acentuadas o suficiente para se notar no controlo da orientação. 4.4 Controlo de movimento O controlo de movimento é a função responsável por calcular e enviar os comandos do PC para o baixo nível, sobre a velocidade linear, velocidade rotacional e direção de movimento. A Figura 67 representa o fluxograma desta função. Figura 67: Fluxograma da Cinemática 63 Após calcular o erro da orientação através da subtração do ângulo desejado com o ângulo do robô, é utilizado um controlador PID para calcular a velocidade rotacional desejada. Em seguida é calculada a distância entre a posição do robô e a posição desejada para o mesmo segundo a equação 4.20. dist =√(Pd.Y −PGK.Y )2+ (Pd.X −PGK.X)2(4.20) Esta distância é utilizada para entrada do atrator, uma função que calcula a velocidade linear desejada de forma ao robô convergir para um ponto desejado (ponto atrator). Este atrator é uma função exponencial com dois parâmetros de calibração, KaeKi, que permitem um ajuste para obter a saída desejada (equação 4.21). vel =Ka∗exp x∗Ki(4.21) Os valores finais destes parâmetros KaeKisão 6.6e0.04 respetivamente, sendo o gráfico final representado pela Figura 68. O eixo das abcissas corresponde à distância entre o robô e a posição desejada em centímetros e o eixo das ordenadas corresponde à velocidade linear em percentagem (100% equivale à velocidade linear máxima estabelecida pela placa controladora dos motores). Foram estabelecidos limites que não permitem a velocidade linear ultrapassar os 100% e percentagens abaixo dos 8% sejam equivalentes a 0%. Figura 68: Atrator velocidade linear 64 Na situação de remate à baliza, as entradas (eixo das abcissas) não são representadas em centímetros mas sim em percentagem, pois numa situação de remate é desejado que o robô saia do ponto de repouso em velocidade máxima, independentemente da distância inicial para o objetivo. Assim sendo, no momento que um remate é detetado, essa distância ao alvo é considerada a distância máxima e, posteriormente, a distância em percentagem é dada pela divisão da distância atual por essa máxima multiplicada por 100 (equação 4.22). dist(%) = dist distmax ∗100 (4.22) Para calcular a direção do movimento linear é necessário o ângulo entre o alvo e o robô, no referencial da baliza, obtido através da função ATan2 entre esses dois pontos (equação 4.23). ang_target =arctan 2((Pd.Y −PGK .Y ),(Pd.X −PGK.X)) (4.23) Esse ângulo é somado ao do robô em relação ao referencial para se obter a direção do movimento linear desejada (Figura 69). Figura 69: Direção do movimento linear Os valores da velocidade linear, rotacional e direção são enviados para o baixo nível via porta série. 65 4.5 Estrutura móvel Numa atualização recente dos regulamentos do RoboCup , foi permitido que o guarda-redes, dentro da pequena área, estendesse a sua área em 920cm2para qualquer lado durante um segundo, sendo necessário um intervalo de quatro segundos para o fazer novamente [35]. Foi decidido criar uma estrutura capaz de subir e proteger a parte superior do guarda-redes. Visto que a estrutura fixa do guarda-redes tem 70cm de comprimento, para criar uma área de 920cm2, a estrutura móvel poderia subir cerca de 12cm. Para subir a estrutura e tomando como referência a equipa dos Tech United , foi utilizado um motor centrado com a estrutura que tem como função enrolar um fio ligado a parte inferior da mesma, fazendo com que esta suba até uma certa altura. Para garantir que a estrutura suba no máximo 12cm foram utilizados batentes. Para descer a estrutura o fio é desenrolado e a mesma cai com a força gravítica. A estrutura móvel é colocada na estrutura fixa, sendo necessária uma distância de 38,5cm entre os eixos principais e um tamanho horizontal total de 70cm, sendo esse o tamanho máximo citado pelo regulamento. A Figura 70 representa um modelo desta estrutura móvel. Figura 70: Modelo da estrutura móvel 66 4.5.1 Tipo de material Grande parte das equipas que utilizam este tipo de estrutura usam fibra de carbono devido à sua rigidez e peso, pois é um material que não se deforma e é bastante leve. Porém, estes materiais de carbono são bastante caros, pretendendo esta equipa uma solução fiável e económica. O material escolhido acabou por ser o Polipropileno Copolímero Aleatório (PPR) devido ao seu baixo preço, alta rigidez e baixo peso. Os tubos de PPR mostraram-se rijos o suficiente para aguentar remates de humanos, mesmo sendo um material leve e barato. Os tubos foram cortados às dimensões necessárias e ligados aos elos, sendo o resultado apresentado na Figura 71. Figura 71: Estrutura modelizada 4.5.2 Batentes Os batentes foram impressos a Três Dimensões (3D), com uso de filamento Poliácido Láctico (PLA) e foram desenhados de forma a servir de encaixe entre a estrutura móvel e fixa. Como a estrutura fixa é composta por um ferro quadrado e a estrutura móvel por um tubo redondo, foi desenvolvida uma peça que ligasse esses dois tipos. A peça desenvolvida é aparafusada a outra igual pela estrutura fixa, englobando as duas estruturas e funcionando como batente (Figura 72a). Na Figura 72b é possível observar um dos batentes a ligar as duas estruturas no robô. Foram colocados quatro batentes no total, sendo que dois deles funcionam como conectores entre estruturas. 67 Os dois batentes estão situados na parte superior das duas barras e os conectores na parte inferior, de forma a aumentar a estabilidade desta estrutura. (a) (b) Figura 72: a) Modelo dos batentes. b) Batentes na estrutura. 4.5.3 Suporte e veio do motor Visto que o motor foi colocado no meio da estrutura, era necessário desenvolver uma peça que englobasse o motor e fizesse uma ligação entre esse e a estrutura fixa do guarda-redes, de forma a servir de suporte. Também foi utilizada modelagem 3D para o desenvolvimento deste suporte. O motor é colocado e aparafusado dentro do suporte, criando assim uma camada de proteção do mesmo, tendo ainda sido desenvolvido um encaixe quadrado de forma a prender o motor aos ferros da estrutura fixa (Figura 73). Figura 73: Modelo do suporte do motor 68 Como este motor tem o objetivo de enrolar um fio com a sua rotação foi desenhada uma peça para o veio com esse propósito. Esta peça entra no veio aparafusada ao mesmo, tendo um furo ao centro que possibilita a passagem do fio de um lado ao outro (Figura 74). Visto que o motor utilizado é um motor DC de 12Ve 150 rotações por minuto, o perímetro do círculo no meio da peça é de 24cm, de forma a garantir que a estrutura aumenta os 12cm com apenas meia rotação do motor. O tempo de subida da estrutura é dado pelo tempo que o motor demora a fazer meia rotação, o que equivale a 200 milissegundos. Figura 74: Modelo do veio do motor O resultado final destas duas peças no robô é apresentado na Figura 75, onde é possível ver que o fio passa por duas roldanas em cada lado para transformar o movimento horizontal, gerado pelo motor e pela peça do veio, num movimento vertical responsável por subir a estrutura. Figura 75: Motor da estrutura móvel 69 4.5.4 Placa de controlo Após o desenvolvimento da estrutura foi necessário criar um sistema de controlo para dar ao motor a movimentação desejada em determinado tempo. Num cenário ideal, a placa responsável por controlar este motor seria a unidade de processamento de baixo nível, porém, devido à utilização desta placa para todo o projeto, esta ficou sem pinos de comunicação e Input/Output . Foi necessário escolher outro microcontrolador de baixo custo pois apenas ia exercer uma função, a ativação de um motor num determinado tempo. Foi selecionada a Raspberry Pi Pico como o microcontrolador dedicado a controlar esse motor pelo seu baixo preço. Esta placa controla o motor com ajuda de uma ponte H , usada para controlar motores de corrente contínua. A Figura 76 representa a arquitetura de hardware do sistema da estrutura que é apenas utilizada pelo guarda-redes, sendo esse o motivo de não ser representada na figura da arquitetura de hardware de todos os robôs (Figura 22). A comunicação entre a Raspberry Pi Pico e o PC é feita através de uma porta série. Figura 76: Arquitetura de hardware da estrutura móvel Para a ligação entre a Raspberry Pi Pico e a ponte H são necessários três pinos de Input/Output . Um é dedicado ao pino de ativação da ponte H , sendo este um pino de PWM que dita a velocidade do motor. Os outros dois são pinos simples de High/Low dedicados a ativar o motor e sinalizar o sentido do mesmo, sendo ativados independentemente e respetivos a cada um dos sentidos. 70 Foi utilizado o GPIO 20 da Raspberry Pi Pico como PWM, e o GPIO 21 e GPIO 22 como pinos simples de High/Low , correspondendo à subida e descida da estrutura respetivamente. Esta ligação entre a ponte H e os pinos da Raspberry Pi Pico está representada na Figura 77, assim como a ligação entre a ponte H , o motor e a Power Box . Figura 77: Ligação do microcontrolador (estrutura móvel) A linguagem de programação utilizada neste microcontrolador foi o MicroPython , a mais utilizada no desenvolvimento de projetos com este microcontrolador. O MicroPython é uma implementação do Python projetada especificamente para operar em dispositivos com recursos limitados, como microcontroladores. 4.5.4.1 Compartimento da placa de controlo Após ser desenvolvida a placa com a ligação do microcontrolador à Ponte H , foi necessário criar um compartimento que a protegesse e fixasse no robô. Foi desenvolvida uma caixa em modelização 3D e impressa em filamento PLA. A caixa desenvolvida tem por dentro uma zona mais elevada para a ponte H ficar mais subida que a placa e o microcontroaldor, pois apenas se liga a essa com uns jumpers na zona de ligação com os pinos. Assim essa camada foi adicionada para a mesma não ficar pendurada ou a forçar os jumpers . Tem também uma abertura na zona de ligação do cabo do microcontrolador com o PC, assim como na zona de ligação da Power Box e do motor com a Ponte H . Nessa caixa foram feitos furos por dentro para aparafusar a placa e a Ponte H , assim como furos em cima das paredes para aparafusar a tampa. Na tampa existem duas aberturas, uma circular para ser possível carregar no botão de Reset do microcontrolador e verificar o LED de ligação, e a abertura quadrada, que serve para o dissipador da 71 De acordo com estes dois testes é possível concluir que quanto mais longe do centro do referencial se encontra o robô, maior é o desvio da localização real, demonstrando também que a localização tem mais precisão que exatidão. Para testar a orientação do robô, o mesmo foi colocado numa orientação de 45º segundo o referencial da baliza com uso de pontos colocados no chão, sendo obtidos os resultados apresentados na Figura 86. Figura 86: a) Imagem da Microsoft Kinect . b) Ângulo obtido pelo robô Analisando estes resultados foi obtido o gráfico da Figura 87 onde se pode observar que a média dos valores retirados é de 44º, equivalente a um erro de 1º para a orientação real de 45º. Figura 87: Gráfico da orientação do Robô 78 5.2 Sistema de visão Em primeiro lugar, vão ser analisados os testes e resultados obtidos sobre a distância à bola lida pela Microsoft Kinect assim como a deteção da bola com o modelo de cores HSV e com a rede neuronal. Em seguida são analisados os testes do cálculo da posição da bola e é finalizado com a deteção e defesa de remates. 5.2.1 Deteção da bola e distância Na primeira fase a deteção da bola era feita através do modelo de cores HSV. Na Figura 88 é possível observar na imagem a) uma máscara relativa à deteção da cor laranja da imagem obtida pela câmara, e na imagem b) a deteção da bola na câmara. Figura 88: a) Máscara para deteção de cor laranja. b) Deteção da bola Um inconveniente deste tipo de deteção provém do funcionamento da deteção se basear na cor e não na forma da bola, o que faz ser necessária uma nova calibração caso a bola seja de outra cor. Na Figura 89 está representado este problema em que apenas a bola laranja é detetada. Figura 89: a) Máscara para deteção de cor laranja. b) Deteção de apenas uma bola (HSV) Relativamente à deteção da bola pelo modelo de cores HSV existe outro grande problema, sendo que este se mostrou bastante inconveniente no Festival Nacional de Robótica, a primeira competição 79 que a equipa participou. No LAR, este problema não foi muito relevante devido às pequenas dimensões do campo ali existente, já na competição, em que o campo apresenta umas dimensões maiores, foi bastante notório. Este problema deve-se à distância reduzida que este modelo consegue detetar a bola (até aproximadamente 4200 milímetros), sendo que na competição, devido ao tamanho do campo, as equipas rematavam de distâncias consideráveis fazendo o guarda-redes não conseguir defender devido à deteção tardia da bola. Na Figura 90 é possível observar que o robô deixa de detetar a bola quando bastante afastada do guarda-redes devido à máscara utilizada. Esta distância representada na imagem (aproximadamente 5 metros) é a distância de onde grande parte dos remates são feitos nas competições. Figura 90: Deteção da bola limitada pela distância (HSV) Para resolver este problema a equipa passou para a deteção da bola através de redes neuronais desenvolvidas por outra dissertação tal como indicado na secção 4.1.2.2. Essa deteção é demonstrada na Figura 91, sendo também possível observar a distância entre o plano da câmara à bola em milímetros e a percentagem de fiabilidade. Nesta imagem a bola foi colocada a 2700 milímetros do plano da câmara, sendo o resultado retornado pela câmara 2690 milímetros. Figura 91: Deteção e distância da bola (rede neuronal) 80 Os dois problemas que o modelo de cores HSV demonstrava foram descartados com o uso da rede. Como é possível observar na Figura 92, além de serem detetadas todo o tipo de bolas independentemente da cor, a bola também é detetada a distâncias bastante elevadas. Nesta imagem é possível analisar mais valores para as distâncias, sendo que a bola que se encontra a 10000 milímetros segundo a imagem está a 10500 milímetros, e a bola laranja foi colocada a 2500 milímetros, sendo retornada pela câmara 2478 milímetros. Figura 92: Deteção das bolas (rede neuronal) 5.2.2 Posição da bola Um tópico importante desta dissertação é a transformação da bola detetada na câmara para o plano cartesiano com a referência no centro da baliza. De forma a testar e perceber os resultados obtidos por parte do robô, foi criado um algoritmo que representa a posição da bola no campo. Para testar a fiabilidade deste algoritmo a bola foi colocada em três posições diferentes com coordenadas recolhidas previamente. De forma a não ocorrerem oscilações nestes testes por causa do módulo da localização, visto que a posição da bola depende da posição do robô, o robô foi colocado e manipulado manualmente para o ponto com valor de coordenadas de 0 milímetros nas abcissas e 200 milímetros nas ordenadas segundo o referencial da baliza, com uma orientação de 0º com o eixo das ordenadas. Para a representação da bola numa imagem do campo, foi feita uma translação do referencial da baliza para o canto do campo, como é representado na imagem c) da Figura 93. As coordenadas da bola nesta imagem são de 1300 milímetros nas abcissas e 2750 milímetros nas ordenadas. É possível observar a posição da bola na câmara (imagem a) ), a posição da bola calculada representada no campo 81 (imagem c) ) assim como as coordenadas calculadas da posição da bola em centímetros (imagem b) ). Analisando os valores obtidos, o erro nas ordenadas é de 30 milímetros, enquanto que nas abcissas é de 50 milímetros. Figura 93: a) Imagem da Microsoft Kinect . b) Coordenadas da bola obtidas em centímetros (x,y). c) Representação da posição da bola no campo. (Posição da bola - 1º teste) Num segundo teste, a bola foi colocada na posição (1900,4850) milímetros (Figura 94). Analisando os resultados obtidos, verifica-se que a posição nas abcissas tem um erro máximo de 10 milímetros, enquanto nas ordenadas é de 90 milímetros. Figura 94: a) Imagem da Microsoft Kinect . b) Coordenadas da bola obtidas em centímetros (x,y). c) Representação da posição da bola no campo. (Posição da bola - 2º teste) 82 Foi feito um terceiro teste com a bola nas coordenadas (3700, 5850) milímetros (Figura 95). É possível observar que o erro nas abcissas é de 100 milímetros e nas ordenadas é de 170 milímetros. Figura 95: a) Imagem da Microsoft Kinect . b) Coordenadas da bola obtidas em centímetros (x,y). c) Representação da posição da bola no campo. (Posição da bola - 3º teste) Com estes três testes é possível observar duas coisas: Primeiro, quanto a bola se encontra mais para os lados na imagem da câmara, maior é o erro nas abcissas. Segundo, quanto maior a distância à bola maior é o erro nas abcissas e ordenadas. Isto deve-se ao facto de haver duas dependências no cálculo da posição da bola. A primeira dependência consiste no ângulo entre a bola e o robô, que irá conter mais erro conforme a bola se encontra mais nas laterais da imagem, pois o ângulo de visão da câmara não é proporcional aos pixeis da mesma devido à deformação provocada pela lente. Tendo a Microsoft Kinect 57º de ângulo de visão horizontal e 640 pixeis de resolução horizontal, caso esta fosse proporcional, os pixeis que se encontrem na posição 160 horizontal seriam equivalentes a 14,25º. Devido a uma pequena deformação da imagem da Microsoft Kinect isto não se verifica, produzindo um pequeno erro no ângulo de no máximo 1º pelos testes efetuados na posição da bola. Este ângulo, junto com a segunda dependência, geraram um erro máximo de 100 milímetros nas abcissas. A segunda dependência é a distância, que conforme a bola está mais distante, maior é o erro obtido dessa distância. Visto que o robô está orientado para a frente, a posição da bola no eixo das ordenadas equivale a posição do robô nas ordenadas (que foi manipulada manualmente) com a distância retornada pela câmara. Assim, os 170 milímetros de erro obtidos no terceiro teste nesse eixo, são devidos a essa distância. 83 Num último teste o robô foi colocado na posição (500,200) milímetros com um ângulo de -40º e a bola na posição do primeiro teste (coordenadas (1300,2750) milímetros). Este teste foi efetuado para perceber se a transformação do referencial do robô para o referencial da baliza era feito corretamente. Os resultados obtidos estão representados na Figura 96, sendo que o erro no eixo das abcissas é de 10 milímetros, e no eixo das ordenadas é de 20 milímetros. Figura 96: a) Imagem da Microsoft Kinect . b) Coordenadas da bola obtidas em centímetros (x,y). c) Representação da posição da bola no campo. (Posição da bola - 4º teste) Este teste também comprova a explicação anterior sobre as dependências visto que a bola se encontra na mesma posição do primeiro teste, mas devido à orientação do robô a mesma encontra-se mais no centro da imagem, provocando menor erro. 5.2.3 Deteção de remates Um dos últimos testes no sistema de visão recai sobre a deteção de remates. Para estes testes, e da mesma forma que os apresentados anteriormente, a localização do robô foi manipulada manualmente para não ser um fator influente nestes testes. Nos primeiros dois testes apresentados, o robô foi colocado no centro da baliza na posição (0,200) milímetros orientado para a frente. No primeiro teste, a bola foi rematada em direção ao poste que se encontra nas coordenadas (1000, 0) milímetros. Na Figura 97 é possível observar na imagem a) a imagem da Microsoft Kinect , na imagem c) está representada uma imagem retirada noutro ângulo sobre esse remate, e por fim na imagem b) está representada a previsão do robô no momento do remate sobre o ponto que a bola vai intercetar a baliza com essa informação por baixo em centímetros. 84 Neste teste, a deteção do remate calculou que a bola iria intercetar a baliza a 980 milímetros do centro da baliza para o lado direito, equivalente à posição (980, 0) milímetros, o que equivale a um erro de 20 milímetros. Figura 97: a) Remate efetuado visto pela imagem da Microsoft Kinect . b) Posição da bola após o remate na baliza representada a preto. c) Remate efetuado noutro ângulo. (1º teste) No segundo teste a bola foi rematada para um ponto marcado no chão com uma posição de (-750,0) milímetros. Na Figura 98 é observado que a previsão calculou que a bola intercetaria a baliza na posição (-710,0) milímetros, equivalente a um erro de 40 milímetros. Figura 98: a) Remate efetuado visto pela imagem da Microsoft Kinect . b) Posição da bola após o remate na baliza representada a preto. c) Remate efetuado noutro ângulo. (2º teste) 85 No último teste efetuado, o robô foi colocado nas coordenadas (500,200) milímetros com uma orientação de -30º, de forma a perceber se os remates eram detetados corretamente mesmo com uma translação e rotação do robô. A bola foi rematada para o centro da baliza, coordenadas (0,0) milímetros. O resultado obtido está representado na Figura 99 onde se observa um erro de 20 milímetros. Figura 99: a) Remate efetuado visto pela imagem da Microsoft Kinect . b) Posição da bola após o remate na baliza representada a preto. c) Remate efetuado noutro ângulo. (3º teste) Nestes testes é possível observar que a previsão da trajetória da bola tem uma grande eficácia pois depende da posição da bola, que segundo os testes da secção 5.2.2, não tem muito erro associado. 5.2.4 Defesa de remates Os últimos testes deste sistema de visão estão associados à defesa dos remates que após ter uma posição desejada de deslocamento, depende apenas dos ganhos do atrator e da localização do robô. No primeiro teste apresentado foi feito um remate para a zona central da baliza quando o robô se encontrava mais para a esquerda dessa. A posição e orientação desejada do robô é demonstrada na imagem b) da Figura 100 em milímetros, na imagem c) é apresentada a posição do robô visualmente e na imagem a) é a imagem da câmara da Microsoft Kinect . A posição final do robô foi (-50,200) milímetros com uma orientação de 3º, o que origina um erro de 122 milímetros na posição e de cerca de 1º na orientação. 86 Figura 100: a) Remate efetuado visto pela imagem da Microsoft Kinect . b) Posição e orientação desejada do robô. c) Posição do robô na baliza. (Defesa de remate - 1º teste) No segundo teste foi feito um remate para a esquerda da baliza sendo obtida a posição e orientação desejada representadas na imagem b) da Figura 101. Figura 101: a) Imagem da Microsoft Kinect após remate. b) Posição e orientação desejada do remate (Defesa de remate - 2º teste) Na Figura 102 está representado o momento do remate (imagem a) ) assim como a posição e orientação final do robô (imagem b) ), que após ser medidas o robô estava na posição (500,250) milímetros com uma orientação de -14º. Assim, o erro na posição era de 130 milímetros e de 2,4º na orientação. Figura 102: a) Momento do remate. b) Posição e orientação final do robô (Defesa de remate - 2º teste) 87 No segundo teste o robô atacante foi movido em torno da bola onde foi verificado que a posição desejada do guarda-redes se moveu em correspondência pela baliza, sendo por fim colocado na trajetória do ponto (-800,0) milímetros. Da mesma forma que na trajetória anterior, o ponto da abcissa dessa reta para um valor de ordenada de 200 milímetros equivale a -730 milímetros. O resultado obtido é representado na Figura 114 e analisando a imagem é possível observar um erro de 80 milímetros. Figura 114: a) Imagem da Microsoft Kinect . b) Representação do robô (azul) na baliza (preto) e das coordenadas desejadas em centímetros. (Cálculo da trajetória do penálti - 2º teste) Após o cálculo da trajetória entre a posição do robô e da bola, são demonstrados os testes da movimentação do robô para esses pontos desejados. Na Figura 115 é possível observar o primeiro teste, sendo representado na imagem a) a imagem da Microsoft Kinect , na imagem b) a posição desejada calculada em milímetros e na imagem c) a posição final do robô na baliza que após ser medida tinha as coordenadas (470,200) milímetros. Desta forma, a posição desejada teve um erro associado de 77 milímetros. Figura 115: a) Imagem da Microsoft Kinect . b) Posição e orientação desejados para o robô. c) Posição e orientação real do robô na baliza. (Defesa do penálti - 1º teste) 94 Na Figura 116 está representado o segundo teste da defesa de penáltis, sendo a posição do guardaredes representada na imagem c) equivalente à posição (-810,150), o que demonstra um erro de 64 milímetros. Figura 116: a) Imagem da Microsoft Kinect . b) Posição e orientação desejados para o robô. c) Posição e orientação real do robô na baliza. (Defesa do penálti - 2º teste) Com estes testes é possível perceber que mesmo a posição tendo um erro associado, o robô coloca-se numa posição que torne possível intercetar a bola na baliza. A fiabilidade deste algoritmo não foi testada no LAR com os robôs atacantes a rematar, mas sim no mundial RoboCup no jogo de terceiro e quarto lugar da equipa, que de 10 remates o guarda-redes defendeu 5 (taxa de sucesso de 50%). Este algoritmo demonstrou-se útil mas menos efetivo que o esperado, pois após a análise dos resultados da outra equipa com este algoritmo, os Tech United , era expectável uma defesa de quase 100% dos penáltis. Assim como nos remates, esta percentagem de sucesso deve-se à calibração utilizada na placa de controlo dos motores como explicado na secção 5.2.4. 95 Capítulo 6 Competições Este capítulo descreve a experiência das duas competições em que a equipa participou, o Festival Nacional de Robótica e o mundial de robótica, RoboCup 2023 . Estas duas competições foram demonstradas bastante relevantes para o desenvolvimento da dissertação, tanto a nível de evolução como de testes. 6.1 Festival Nacional de Robótica O Festival Nacional de Robótica 2023 que ocorreu em Tomar, contou com a inscrição de uma grande equipa que compete no RoboCup , sendo a equipa campeã nos últimos anos, os Tech United . A equipa LAR@MSL foi a única equipa portuguesa a participar neste evento. Com esta participação foi possível observar uma das grandes complicações nestas competições, os problemas de rede. O acesso aos computadores instalados nos robôs era feito através da rede, e visto que nestes eventos centenas de pessoas utilizam a mesma, tornou-se uma tarefa complicada, atrasando o progresso da equipa. Um dos grandes problemas encontrados nesta competição foi a deteção da bola por parte do guardaredes, sendo que foi nesse momento que a equipa decidiu migrar da deteção da bola com o modelo de cores HSV para o uso de redes neuronais. Para além disto, este evento foi muito relevante para retirar fotos para o DataSet da rede neuronal que se iria desenvolver. Outro problema detetado nesta competição foi o sobreaquecimento dos computadores devido ao calor e uso das camisolas de jogo. Para contornar esta situação foi decidido fazer aberturas em certas zonas das camisolas para permitir a dissipação do calor. No que diz respeito ao trabalho desenvolvido nesta dissertação, foi possível neste evento validar todo o software desenvolvido até esse momento. Foi validada a deteção e defesa de remates por parte do guarda-redes, assim como o posicionamento do mesmo na baliza. Neste evento a ideia da orientação 96 ainda seria de que o guarda-redes estaria sempre orientado para a frente, o que se demonstrou impossível devido ao campo de visão reduzido da Microsoft Kinect , fazendo o mesmo nunca detetar remates pois não conseguia ver a bola. Assim surgiu a ideia de existir algum tipo de orientação para a zona da bola. A estrutura móvel e a defesa de penáltis ainda não tinham sido desenvolvidas, sendo que foi entre este evento e o mundial RoboCup2023 que essas foram criadas. Com a participação da outra equipa neste evento, foi possível discutir ideias e perceber evoluções que a equipa poderia efetuar, realçando que foi nesta competição e em conversa com a equipa campeã que se obteve a ideia utilizada para a estrutura móvel. Figura 117: Festival Nacional de Robótica 6.2 RoboCup2023 O mundial de robótica RoboCup 2023 ocorreu em Bordéus, contando com a participação de seis equipas na MSL, sendo a única equipa portuguesa o LAR@MSL . Esta competição iniciou-se com uma derrota contra a equipa francesa por 1−0. Conforme o evento foi passando e a equipa efetuando todos os seus jogos, foi alcançado um lugar nas meias finais. No jogo das meias finais foi defrontada a equipa campeã dos últimos anos, os Tech United , onde se saiu com a derrota. Posteriormente, essa equipa acabou por vencer a final e vencer o título novamente. No último jogo, o LAR@MSL defrontou a equipa francesa para o jogo dos terceiros e quartos. Este jogou acabou por ir a penáltis sendo que o guarda-redes de 10 penáltis conseguiu defender 5 com o uso do algoritmo de defesa penáltis. 97 No que diz respeito a esta dissertação, todos os restantes módulos foram testados com sucesso. Os mais importantes, por não terem sido testados no evento anterior, eram a orientação, a estrutura móvel e a defesa de penáltis. A orientação demonstrou-se eficaz pois diferente do evento anterior, o guarda-redes apenas deixava de ver a bola caso um robô se coloca-se à frente. A estrutura móvel também demonstrou bons resultados pois não houve golos sofrido por cima do guarda-redes. A eficácia dos penáltis já foi referida, demonstrando uma taxa de sucesso abaixo do expectável. Os resultados obtidos neste evento foram fruto de um ano inteiro de trabalho por parte de todos os membros da equipa. Figura 118: RoboCup 2023 98 Capítulo 7 Conclusão e trabalho futuro Este capítulo descreve as conclusões sobre o trabalho desenvolvido nesta dissertação e algumas ideias que poderiam ser implementadas no futuro. 7.1 Conclusão Nesta dissertação foram cumpridos todos os objetivos iniciais, o desenvolvimento de um guardaredes capaz de detetar a bola, detetar e defender remates, posicionar-se corretamente na baliza, participar em jogadas de equipa e desenvolver uma estrutura móvel dentro das regras da competição. Pode ser verificado nos capítulos 4e5que todos estes objetivos foram cumpridos e testados, tendo sido tudo colocado em prática nas competições que a equipa participou. Com todos os testes foram verificados algoritmos desenvolvidos que eram possíveis de melhorar. No desenvolvimento da deteção da bola, começou-se por um método pouco robusto que acabou por ser alterado para um que se demonstrou perfeito para o que era desejado. A deteção e defesa de remates foi demonstrada capaz e com pouco erro associado, mas infelizmente, foi verificada uma dificuldade do guarda-redes no seu tempo de resposta devido à calibração da placa de controlo dos motores como explicado na secção 5.2.4, sendo que o mesmo passou a detetar remates relativamente cedo (dentro do possível da Microsoft Kinect ) mas demorava a reagir com o seu movimento. Devido a esta reação, acabou por sofrer alguns golos nas competições. O posicionamento e orientação do robô na baliza acabou por se tornar uma das implementações mais úteis e eficientes, pois demonstrou um erro associado bastante reduzido e graças a isso permitiu que o guarda-redes fosse capaz de defender bolas apenas com o seu posicionamento. Graças à orientação, o robô conseguia ter maior parte do tempo contacto visual com a bola usando a Microsoft Kinect . A estrutura móvel foi uma das atualizações mais importantes pois demonstrou resultados acima do esperado com uma taxa de sucesso de 95%, sendo que grande parte dos robôs adversários remata por 99 cima do guarda-redes. A possibilidade do guarda-redes participar como atacante ficou presente no robô, pois o robô tem a função de guarda-redes através da habilidade que lhe é atribuída pela BaseStation , sendo neste caso a habilidade de defesa. Caso a BaseStation defina que quer o guarda-redes como atacante, apenas precisa de lhe colocar uma habilidade diferente, desenvolvida por outra dissertação. Um trabalho extra desenvolvido foi a defesa de penáltis que se demonstrou útil na última competição que o robô participou. Este algoritmo não é perfeito, pois o guarda-redes não defende todos os penáltis, mas foi bastante útil, visto que fez o mesmo defender penáltis que não seriam possíveis apenas com a deteção e defesa do remate. Importa salientar que além deste trabalho de software cumprido, foi também efetuado bastante trabalho na estrutura dos robôs, hardware e software de baixo nível, sendo que desta forma se criou uma estrutura muito mais estável, robusta e preparada para competições futuras, estando perto do nível das equipas atuais. Concluindo, foram feitas atualizações no guarda-redes para poder jogar ao nível atual da liga, e provou ser bastante robusto, capaz de participar nos jogos entre equipas de grande calibre e grande desenvolvimento. É de salientar que este trabalho de dissertação é apenas um módulo de um conjunto de software desenvolvido pela equipa LAR@MSL , sendo alguns desses módulos necessários para esta dissertação, pois sem eles seria impossível o guarda-redes jogar. Com o desenvolvimento de todos estes módulos, foi possível alcançar não só os objetivos do guarda-redes, mas sim de toda a equipa, obtendo resultados melhores que os expectáveis, pois foi a primeira equipa a jogar com apenas 10 meses de desenvolvimento. 7.2 Trabalho futuro Durante o desenvolvimento deste projeto e com a experiência obtida nas competições que a equipa participou, surgiram algumas ideias para evolução do guarda-redes da equipa, não só a nível de software , mas da mecânica do robô também. A nível de software , uma grande evolução para este robô é o mesmo efetuar em alguns momentos saídas da baliza para cortar a bola a jogadores, não como jogador atacante mas sim como guarda-redes. Já é possível, através da implementação desenvolvida, o guarda-redes ser um atacante, pois apenas é necessário atribuir uma habilidade ao guarda-redes diferente da de defesa (habilidade do guarda-redes) através da estratégia da BaseStation . A ideia para o futuro corresponde ao guarda-redes ser capaz de concretizar uma espécie de mancha como os guarda-redes de futebol, que em situações de um para um 100 com o atacante, atacam a bola e deixam a baliza. Isto poderá ser feito exatamente da mesma forma com o robô, que em situações de um para um com outro, é feito um cálculo de onde é o ponto que o guarda-redes precisa de se posicionar de forma a cobrir a baliza toda ao adversário e não ter espaço para colocar a bola por cima do guarda-redes. A nível de mecânica e hardware , existem duas evoluções que são bastante recomendadas. Primeiramente, mover a zona do PC para um sítio diferente, permitindo que a estrutura do guarda-redes seja colocada novamente ao meio, obtendo o seu tamanho máximo. A segunda evolução seria o desenvolvimento da estrutura móvel para os lados e não apenas para cima. A ideologia desta seria exatamente a mesma da já existente, sendo que a única alteração seria que a estrutura voltaria à sua posição inicial através do uso de elásticos e não com a força gravítica. 101 Bibliografia [1] Minoru Asada, Hiroaki Kitano, Itsuki Noda, and Manuela Veloso. Robocup: Today and tomorrow— what we have learned. Artificial intelligence , 110(2):193–214, 1999. [2] Robocupsoccer: Middle size league. [Online] https://www.robocup.org/leagues/6. (Accessed: Dec-2022). [3] Modelo de cores hsv. [Online] https://jpsvsite.wordpress.com/2017/02/10/ modelos-rgb-cmyk-hsv-yuv/. (Accessed: Dec-2022). [4] Robôs cambada. [Online] http://robotica.ua.pt/cambada/index.php?a= 27f5e15b6af3223f1176293cd015771d. (Accessed: Dec-2022). [5] C Bernardo, J António, R Neves, P Dias, J Azevedo, N Lau, R Dias, F Amaral, E Pedrosa, et al. CAMBADA’2015: Team Description Paper . CAMBADA, (2015). [6] António José Ribeiro Neves, Alina Trifan, Paulo Dias, and José Luís Azevedo. Detection of aerial balls in robotic soccer using a mixture of color a-nd depth information. In 2015 IEEE International Conference on Autonomous Robot Systems and Competitions , pages 227–232. IEEE, 2015. [7] Ferry Schoenmakers, Koen Meessen, Yanick Douven, Harrie van de Loo, Dennis Bruijnen, Wouter Aangenent, Bob van Ninhuijs, Matthias Briegel, Patrick van Brakel, Jordy Senden, et al. Tech united eindhoven middle size league winner 2016. In RoboCup 2016: Robot World Cup XX 20 , pages 542–553. Springer, 2017. [8] ST Kempers, DMJ Hameeteman, RM Beumer, JP van der Stoel, JJ Olthuis, WHTM Aangenent, PEJ van Brakel, M Briegel, DJH Bruijnen, R van den Bogaert, et al. Tech united eindhoven middle size league winner 2022. In Robot World Cup , pages 337–348. Springer, 2022. [9] Jaap Vos. Qualification for World Championship Montreal, Canada 2018 . Falcons, (2018). 102 [10] Tiago João Fernandes Maia. Desenvolvimento de sistema de controlo de movimento para plataformas móveis autónomas. Master’s thesis, Universidade do Minho (Portugal), 2019. [11] F Ribeiro, G Lopes, H Ribeiro, P Silva, T Maia, R Roriz, A Gomes, and N Ferreira. Minho team ‘2016: Team description paper. University of Minho, Guimarães, Portugal , 2016. [12] A Fernando Ribeiro, Ivo Moutinho, Nino Pereira, Fernando Oliveira, José Fernandes, Nuno Peixoto, and Antero Salgado. Cooperative behaviour of specific tasks in multi-agent systems and robot control using dynamic approach. 2006. [13] A Fernando Ribeiro, Ivo Moutinho, Pedro Silva, Carlos Fraga, and Nino Pereira. Three omni-directional wheels control on a mobile robot. Control 2004 , 2004. [14] A Fernando Ribeiro, Gil Lopes, João Costa, João Pedro Rodrigues, Bruno Pereira, João Silva, Sérgio Silva, Paulo Ribeiro, and Paulo Trigueiros. Minho msl: a new generation of soccer robots. 2011. [15] A Fernando Ribeiro, Paulo Braga, Jorge Monteiro, Ivo Moutinho, Pedro Silva, and Victor Silva. New improvements of minho team for robocup middle size league in 2003. University of Minho, Guimarães, Portugal , 2004. [16] Robocupsoccer. [Online] https://www.robocup.org/domains/1. (Accessed: Dec-2022). [17] Robocup@home. [Online] https://athome.robocup.org/. (Accessed: Dec-2022). [18] Tiago Ribeiro, Fernando Gonçalves, Marco Luís, Eduardo Fernandes, Rui Silva, António Dias, Nuno Oliveira, Diogo Martins, Syed Fawad, Gil Lopes, et al. Lar@home 2023 team description paper. University of Minho, Guimarães, Portugal , 2023. [19] Robin Soetens, René van de Molengraft, and Bernardo Cunha. Robocup msl-history, accomplishments, current status and challenges ahead. RoboCup 2014: Robot World Cup XVIII 18 , pages 624–635, 2015. [20] Nanning Zheng, George Loizou, Xiaoyi Jiang, Xuguang Lan, and Xuelong Li. Computer vision and pattern recognition, 2007. [21] Sabine Süsstrunk, Robert Buckley, and Steve Swen. Standard rgb color spaces. In Proc. IS&T;/SID 7th Color Imaging Conference , volume 7, pages 127–134, 1999. 103