Atividade #597
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 A* para cálculo de trajetória
Descrição
Esse algoritmo vai ser implementado para testes para que a equipe possa avaliar se vai ser uma boa opção a ser aplicada no projeto.
Arquivos
Atualizado por Rebeca Reis há quase 7 anos
- Arquivo jansen2016bsc.pdf jansen2016bsc.pdf adicionado
O documento que está sendo usado de referência para estudo encontra-se anexado.
Atualizado por Nicolas Oliveira há quase 7 anos
- Data prevista ajustado para 02/03/2018
Buscar mais artigos de referência, principalmente de outras equipes implementando isso.
Atualizado por Luciano Barreira há quase 7 anos
[este](https://forums.ni.com/t5/Community-Documents/Example-Code-Submission-Priority-Queue/ta-p/3530099) link talvez possa ajudar na parte do open set, mantendo a prioridade como o valor do F, e os elementos cada nó.
Atualizado por Nicolas Oliveira há quase 7 anos
Rebeca, atualizar a tarefa com o que foi feito até agora.
Atualizado por Rebeca Reis há quase 7 anos
Até agora, já foi feita a VI que discretiza o campo e constrói o grid, pintando os nós que correspondem a obstáculos. O grid é uma grande matriz em que cada elemento é um cluster que guarda id, G, H, F. No início, pontos vazios são setados com valores muito grandes (99999999) enquanto obstáculos são setados com o valor de inf, para diferenciar. A parte de identificar os obstáculos por enquanto foi abordada de uma maneira mais simples, pintou-se inicialmente apenas o ponto correspondente à posição de um robô no campo e também todos os seus vizinhos adjacentes. O parâmetro de precisão do grid (tamanho do lado de cada quadrado) foi escolhido como 100 mm nessa primeira abordagem, de forma que pintando uma vez os vizinhos em volta da posição do obstáculo isso é suficiente para cobrir totalmente o espaço que um robô ocupa no campo. Após a conclusão do algoritmo dessa forma, isso será refinado. A ideia é que exista, além do parâmetro de precisão do grid, um parâmetro do raio de influência do obstáculo, e com base nesse raio vamos saber quantos níveis de vizinhos ao redor da posição de um robô deverão ser pintados. Outra ideia para isso seria utilizar o algoritmo midpoint circle algorithm, que pode ser encontrado nesse link https://en.wikipedia.org/wiki/Midpoint_circle_algorithm
Foram criadas ViS auxiliares, como as de inserção, remoção e busca na lista ClosedSet usada no alogritmo. Para o OpenSet, está sendo usada como estrutura de dados uma priority queue já implementada, que foi encontrada num fórum do LabView no link https://forums.ni.com/t5/Example-Program-Drafts/Advanced-Data-Structures-in-LabVIEW/ta-p/3519662
Por enquanto, a estrutura geral do algoritmo já foi feita, ou seja, o nó inicial adicionada à fila, o grande loop while criado com a busca por cada vizinho e verificação se ele está no closedSet. Falta agora avaliar os vizinhos e recalcular o F para cada um, preenchendo também o vetor dos pais, para finalizar com o backtracking.
Atualizado por Luciano Barreira há quase 7 anos
- Arquivo pixil-frame-0-2.png pixil-frame-0-2.png adicionado
Rebeca Reis escreveu:
Até agora, já foi feita a VI que discretiza o campo e constrói o grid, pintando os nós que correspondem a obstáculos. O grid é uma grande matriz em que cada elemento é um cluster que guarda id, G, H, F. No início, pontos vazios são setados com valores muito grandes (99999999) enquanto obstáculos são setados com o valor de inf, para diferenciar. A parte de identificar os obstáculos por enquanto foi abordada de uma maneira mais simples, pintou-se inicialmente apenas o ponto correspondente à posição de um robô no campo e também todos os seus vizinhos adjacentes. O parâmetro de precisão do grid (tamanho do lado de cada quadrado) foi escolhido como 100 mm nessa primeira abordagem, de forma que pintando uma vez os vizinhos em volta da posição do obstáculo isso é suficiente para cobrir totalmente o espaço que um robô ocupa no campo. Após a conclusão do algoritmo dessa forma, isso será refinado. A ideia é que exista, além do parâmetro de precisão do grid, um parâmetro do raio de influência do obstáculo, e com base nesse raio vamos saber quantos níveis de vizinhos ao redor da posição de um robô deverão ser pintados. Outra ideia para isso seria utilizar o algoritmo midpoint circle algorithm, que pode ser encontrado nesse link https://en.wikipedia.org/wiki/Midpoint_circle_algorithm
Foram criadas ViS auxiliares, como as de inserção, remoção e busca na lista ClosedSet usada no alogritmo. Para o OpenSet, está sendo usada como estrutura de dados uma priority queue já implementada, que foi encontrada num fórum do LabView no link https://forums.ni.com/t5/Example-Program-Drafts/Advanced-Data-Structures-in-LabVIEW/ta-p/3519662
Por enquanto, a estrutura geral do algoritmo já foi feita, ou seja, o nó inicial adicionada à fila, o grande loop while criado com a busca por cada vizinho e verificação se ele está no closedSet. Falta agora avaliar os vizinhos e recalcular o F para cada um, preenchendo também o vetor dos pais, para finalizar com o backtracking.
Quanto a pintar o círculo na matriz, poderia ser feito, para cada ponto (x,y) dos robôs obstáculos, em duas etapas: para raio de influência ``r`` e para ``r-1``, sendo r já mapeado na medida discretizada do grafo, uma vez que pintar o interior do obstáculo é desnecessário ( o meio "oco" do obstáculo continua inalcançável pro algoritmo ) . E caso fosse feito apenas para ``r``, a travessia do grafo pela diagonal poderia entrar no obstáculo:
![](pixil-frame-0-2.png)
Sugiro que essa pintura seja feita por meio de uma VI à parte, de forma que consigamos pintar no grafo outras figuras geométricas, como retângulos (as bordas do campo e area do gol), sem precisar refatorar demais o código. E essa VI recebendo parâmetros do mundo real (na perspectiva do campo) e o grid e retornando o grid já alterado. Pelas dimensões do campo e pelo número de linhas/colunas já é possível fazer o mapeamento real (campo) -> discreto (grafo)
Atualizado por Rebeca Reis há mais de 6 anos
Após término da VI, comecei a debugar e encontrei diversos erros, como por ex que o próprio robô estava afetando na sua trajetória, pois os tanto os robôs inimigos quanto os amigos são considerados obstáculos e faltava essa verificação. Após corrigidos esses bugs, o problema principal agora é que o código está muito pesado, rodando a menos de 10 FPS, e eu limitei a quantidade de iterações para testar o momento em que o ponto final seria alcançado. Já estou em 1000 iterações e até agora o goal point não foi atingido, sendo que o processamento do código só piora conforme aumento o número máximo de loops.
O algoritmo, então, está se mostrando muito pouco eficiente, e não sei se será possível encontrar uma trajetória com ele sem estourar a capacidade de processamento.
Atualizado por Luiz Renault Leite Rodrigues há mais de 6 anos
Antes de condenar o algoritmo poderíamos marcar para discutir a implementação e verificar possibilidade de otimização.
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