Atividade #602
FechadaObjetivo #562: Consiguir fazer um jogo sem colisões inesperadas
Meta #563: Obter robustez nos algoritmos de planejamento de trajetória
Estudar e implementar algoritmo RRT para calculo de trejetória
Descrição
Nos basearemos no case de sucesso da equipe CMDragons, papers anexos.
Arquivos
Atualizado por Nicolas Oliveira há quase 7 anos
- Arquivo RRT-cmdragons.pdf RRT-cmdragons.pdf adicionado
Artigo lido, segue versão com partes importantes destacadas.
Vou criar agora um VI para mostrar as trajetórias calculadas em nosso software. Após isso partirei para implementação.
Assim que puder descreverei o algoritmo na wiki.
Uma coisa boa é que para teste a cmd dragons utilizaram uma movimentação goto como a nossa também, o que vai facilitar os testes.
Atualizado por Nicolas Oliveira há quase 7 anos
Consegui gerar uma trajetória usando ERRT. E ainda utilizei a suavização proposta pelo artigo, o que melhora significativamente a movimentação quando não há obstáculos há frente.
Porém tinha um erro no meu código que o vetor com os pontos da trajetória estava invertido, ou seja, começando pelo fim. Por isso o robô se movia bem rápido e esbarrava nos obstáculos.
Após ajeitar isso nenhuma colisão foi vista mais, porém como fazemos apenas um GoTo para o ponto seguinta na tragetória o robô se move bem lentamente.
Cabe agora focar no controle para que o robô possa seguir essa trajetória da maneira mais rápida possível.
Amanhã postarei melhor os resultados e descreverei na wiki como a implementação foi feita
Atualizado por Nicolas Oliveira há quase 7 anos
Resultados nessa branch : https://github.com/roboime/SSLView/tree/pathplanning
Apenas funcionando com um robô.
Atualizado por Luciano Barreira há quase 7 anos
Poderia linkar um vídeo do RRT funcionando. Sugiro que continuemos focando em otimizar o planejamento de trajetória antes de passar pros algoritmos de navegação em si. Depois disso, quanto a usar para mais de um robô, podemos avaliar se utilizaremos o RRT apenas para alguns roles que se movimentam mais durante a partida ( como atacante e striker ) baseando-se no custo computacional, e aprofundar a pesquisa em como outras equipes lidam com isso. Existem outros fatores a se avaliar como condições de recálculo da trajetória que podem mitigar o problema da latência. Criarei uma tarefa de contato com o Andre Ryll da Tigers.
Feita a navegação, podemos avaliar a melhoria quanto ao último algoritmo utilizado (Campo potencial artificial).
Além disso, seria interessante se a VI de cálculo do RRT puder gerar uma estimativa de tempo de translocação, que pode ser utilizada em nossas heurísticas de defesa do goleiro, interceptação de bola e do atacante.
Caso o tempo de processamento comece a ser um problema, podemos avaliar se é o caso reprojetar nosso debugger visual a partir [deste](https://forums.ni.com/t5/Example-Program-Drafts/OpenGL-sample-program-with-LabVIEW/ta-p/3490883) exemplo utilizando OpenGL. Outra opção é alocar a recursos da GPU para os algoritmos em si em vez de apenas para debugger visual, a partir [deste](http://www.ni.com/white-paper/14077/pt/) artigo.
Atualizado por Nicolas Oliveira há quase 7 anos
Wiki sobre a implementação do RRT feita.Planejamento de Tragetória
Não lembro como coloca video aqui, segue anexo.
Atualizado por Luiz Renault Leite Rodrigues há quase 7 anos
Excelente.
Em algumas situações parece não encontrar solução para a trajetória. Isso é normal?
Após a seleção da trajetória, é possível otimizá-la para um número menor de pontos ou uma SPLINE?
Em seguida, deveria ser consultado se a trajetória ainda é válida, para evitar um novo cálculo.
Qual é o custo computacional do cálculo?
Atualizado por Nicolas Oliveira há quase 7 anos
- Arquivo custocomputacional.jpeg custocomputacional.jpeg adicionado
Atualmente os obstáculos são círculos ao redor do inimigo de diâmetro 300mm, assim caso eu coloque a bola muito perto deles o RRT não é capaz de encontrar uma solução. Uma sugestão que já se encontra na wiki seria conforme a bola se aproxima de um obstáculo a área de influencia dele deve ficar cada vez menor até desaparecer.
Eu também limitei a quantidade de nós gerados pela árvore para que o labview não trave nesse tipo de situação, assim a trajetória não fica completa nesses casos.
Já estamos suavizando a trajetória com o algoritmo proposto por mim no final da wiki, me baseei não sugestão da cmdragons de como fazer isso. Mas nas curvas ainda há muitos pontos.
Ainda estou pensando em como fazer para que recálculos de trajetória sejam evitados.
O custo computacional foi gerado pela ferramenta do labview e segue abaixo:
![](custocomputacional.jpeg)
O maior problema é a VI nearest que varre a árvore toda em busca do ponto mais próximo do objetivo, mas com certeza ela pode ser otimizada.
Atualizado por Nicolas Oliveira há quase 7 anos
- Arquivo smooth.PNG smooth.PNG adicionado
Carla, revisar a VI de suvização com base no algoritmo descrito na wiki.
Atualizado por Nicolas Oliveira há quase 7 anos
Nosso software agora também mostra os waypoints(em branco). Em breve ele será capaz de mostrar tragetórias geradas por algoritmos diferentes ao mesmo tempo, para nossa avaliação.
![](print.PNG)
Atualizado por Rebeca Reis há quase 7 anos
- Arquivo Paper RRT LaValle.pdf Paper RRT LaValle.pdf adicionado
Segue anexado outro artigo para referência e estudo de RRT.
Atualizado por Nicolas Oliveira há quase 7 anos
- Arquivo etdp2015ERFORCE.pdf etdp2015ERFORCE.pdf adicionado
Irei adicionar a possiblidade de inserir waypoints por onde a tragetória deve passar. Isso seria últil para o módulo de testes já que assim os robôs vão poder se mover sobre circulos, 8 etc. Também dessa forma poderimos calcular todos os pontos por onde o atacante deve passar de uma vez só e mandar gerar a tragetória.
Quando o ponto inicial da árvore já esteja em um obstáculo, atualmente, o nosso RRT não é capaz de gerar um tragetória, uma forma de resolver seria deslocarmos o ponto inicial o suficiente numa direção lateral para desviar do obstáculo, e a árvore ser gerada a partir dele.
Nossos robôs também devem ser considerados obstáculos, porém com um raio muito menor.
A proximidade com a bola deve diminuir o raio do obstáculo (robôs) próximo a ela. E a velocidade dos robôs deve alterar sua área de influencia. Sugestão de implementação no tdp anexo.
Atualizado por Carla Cosenza há quase 7 anos
Foi implementado o algoritmo SmoothPath que procura reduzir o número de pontos na curva. O algoritmo consiste em remover todos os pontos que ao serem retirados não causarão choque. O algoritmo só está com um bug quando o inimigo está muito perto do robô sendo analisado, pois nesse caso ele escolhe um ponto que vai causar choque.
Atualizado por Lucas Germano há quase 7 anos
O código não está comentado!!
Atualizar isso quando der, por favor..
Atualizado por Nicolas Oliveira há quase 7 anos
Agora o raio do obstáculo (robô inimigo) leva em consideração a proximidade com o objetivo, com o ponto inicial e a velocidade relativa dos robôs. Assim caso chegamos a colidir ou ficarmos muito perto de um inimigo o rrt ainda vai ser capaz de gerar uma trajetória. E quando a bola fica perto de um inimigo também somos capazes de chegar até ela, praticamente ignorando este inimigo.
![](raio.PNG)
![](raio2.PNG)
Existem parâmetros a serem calibrados, de quanto devemos ignorar do inimigo por exemplo.
Atualizado por Nicolas Oliveira há quase 7 anos
- Arquivo navigation.wmv navigation.wmv adicionado
- Arquivo recalc.wmv recalc.wmv adicionado
- Arquivo disabledrawpath.PNG disabledrawpath.PNG adicionado
- Arquivo drawpath.PNG drawpath.PNG adicionado
RRT agora funcionando para todos os robôs. Com recalculo de trajetória apenas se o goal se mover "muito" ou se a trajetória antiga passar agora por algum obstáculo. Praticamente todas as VIs foram transformadas em clone, o que aumentou razoavelmente o desempenho do software. Porém o debbug fica bem complicado.
Nesse video podemos ver que o recalculo (aparece rapidamente uma trajetória não suavizada, estou plotando as duas) só é feito quando algum robô entra na frente da trajetória. Já quando o robô sai do caminho ele apenas re-suaviza (podemos ver que as duas trajetórias viram uma só, já que n há recalculo).
O desenho da trajetória agora fica nas mesmas cores da personalidade para facilitar a visualização e podemos ver a trajetória só das personalidades que quisermos. Evitando a poluição na tela.
Desenhando para todas:
![](drawpath.PNG)
Striker, por exemplo, sem desenho:
![](disabledrawpath.PNG)
E a navegação está sendo feita por meio de GoTo para os sucessivos waypoints.
Também é possível optar pela navegação com campo potencial antiga ou desligar a movimentação em qualquer estado de jogo. O que se mostrou muito útil na hora de validar o funcionamento das VIs. Tudo isso feito por controls no ssl vision log player.
Só resta melhorar a suavização que ainda apresenta erros quando há robôs próximos.
Atualizado por Nicolas Oliveira há quase 7 anos
- Arquivo navigation.mp4 navigation.mp4 adicionado
- Arquivo recalc.mp4 recalc.mp4 adicionado
Atualizado por Nicolas Oliveira há quase 7 anos
Não estou conseguindo reproduzir os videos direto aqui no redmine.
Atualizado por Luiz Renault Leite Rodrigues há quase 7 anos
Excelente trabalho. Muito show!
Atualizado por Luciano Barreira há quase 7 anos
Excelente! Acredito que só falte ajeitar esses casos de borda de quando o robô obstáculo está muito próximo (parece que não está calculando direito a trajetória suavizada). Fora isso, muito bom ver que horas de estudo e trabalho chegaram neste resultado!
Caso seja necessário retomarmos à ideia da KD-Tree - perceberemos isso simulando partidas em um grSim com 4 câmeras, após implementação do algoritmo de navegação - , podemos cogitar o uso do [nanoflann](https://github.com/jlblancoc/nanoflann) fazendo [chamadas de .dll em LV](https://forums.ni.com/t5/Developer-Center-Resources/Calling-C-C-DLLs-from-LabVIEW/ta-p/3522488). Neste link explica direitinho como funcionam essas chamadas. Torçamos que com a amortização provocada pela ideia da heurística de recálculo da trajetória e a resuavização isto não seja necessário.
Vimos que o uso de VIs clone em alguns pedaços do código melhorou bastante a questão do tempo, certo? Será que não é isso que esteja fazendo a KD-tree diminuir o throughput do nosso algoritmo, em vez da questão da recursão em LV em si? Podemos usar o performance tools para testar essa hipótese.
Atualizado por Lucas Germano há quase 7 anos
Ótimo trabalho!! Boa!
Quanto ao debug, podemos gerar logs em arquivos ".txt" com todas as variáveis interessantes de se analisar e com uma variável que soma mais um a cada nível de profundidade na recursão, igual quando fizemos para debugar a KD-tree.
Atualizado por Carla Cosenza há mais de 6 anos
- Situação alterado de Em andamento para Feedback
Foi encontrado o erro no algoritmo do Smooth Path. Agora ele consegue contornar um inimigo perto dele.
Atualizado por Nicolas Oliveira há mais de 6 anos
- Situação alterado de Feedback para Em andamento
Próximos passos:
- Tornar os nossos robôs obstáculos, porém com um raio menor.
- Tornar as áreas dos goleiros e a parte de trás do gol em obstáculos
- Colocar a bola como obstáculo na situação de stop
- Tornar o RRT otimizado para diferentes personalidades
- Tornar o RRT capaz de receber diversos pontos pelos quais ele deve passar.
Atualizado por Nicolas Oliveira há mais de 6 anos
- Arquivo desvio.mp4 desvio.mp4 adicionado
- Arquivo ourrobots.PNG ourrobots.PNG adicionado
Nossos robôs se consideram como obstáculos agora:
![](ourrobots.PNG)
Naturalmente eles ainda se chocam quando todos se movimentam ao mesmo tempo, já que coloquei o raio do obstáculo bem reduzido em relação ao raio de um inimigo, mas agora eles sempre vão ser capazes de chegar a posição desejada.
Atualizado por Nicolas Oliveira há mais de 6 anos
- Arquivo bolaobstaculo.PNG bolaobstaculo.PNG adicionado
Bola agora é obstáculo. Não vamos mais cometer faltas no stop!
![](bolaobstaculo.PNG)
Atualizado por Nicolas Oliveira há mais de 6 anos
Merge da branch pathplanning feito na development.
Atualizado por Luciano Barreira há mais de 6 anos
- Versão ajustado para RoboCup 2018
Atualizado por Nicolas Oliveira há mais de 6 anos
Fiz uma implementação para calcular se uma trajetória reta já não satisfaz os critérios antes de calcular pelo RRT, como diversas equipes fazem. Assim o custo computacional deve cair razoavelmente principalmente para a defesa e o goleiro que normalmente não ficam perto de obstáculos.
Outro detalhe era que quando a bola se movia precisávamos recalcular a trajetória constantemente devido a mudança do ponto de destino, agora mitigamos um pouco esse problema.
Atualizado por Gabriel Borges da Conceição há mais de 6 anos
- Situação alterado de Em andamento para Resolvida
Atualizado por Gabriel Borges da Conceição há mais de 6 anos
- Situação alterado de Resolvida para Fechada