Futebol de Robos F180 » Inteligência

Quando for orientado a objeto?

Nicolas Oliveira escreveu:

Quando for orientado a objeto?

Sim, será a próxima tarefa depois de planejarmos como vamos fazer a implementação.

Acabei de adicionar a primeira versão no github. Link(https://github.com/roboime/SSL_RRT)

O que foi feito até agora:

• util.hpp
  Definindo classe Point e operações(soma, produto interno, subtração e módulo)

• Environment
  Apenas o método distance da classe environment

• Tree
  Classe Node

Não sei se essa foi a menor maneira de fazer essas coisas, estava pensando em fazer direto as operações de produto interno e soma direto na classe node.

A cada nova função criada, elabore um teste básico para garantir que foi feito corretamente. No RRT temos muitas funções, se deixar pra testar tudo quando estiver pronto, vai ficar mais difícil de identificar os possíveis erros.

Acabei de adicionar a função extend como membro da classe Tree, ainda não está implementado a parte do ERRT. Estou tendo um pequeno problema com os números aleatórios do c++, falta resolver isso ainda, mas fora isso, as outras funções básicas já foram implementadas:

• randomState()
• extend()
• distance()
• colisão com a parede e obstáculos

Antonio de Souza Gomes Pereira escreveu:

Acabei de adicionar a função extend como membro da classe Tree, ainda não está implementado a parte do ERRT. Estou tendo um pequeno problema com os números aleatórios do c++, falta resolver isso ainda, mas fora isso, as outras funções básicas já foram implementadas:

Está criando a semente pros números aleatórios? se n vai dar ruim

Faz o RRT normal, mudar pra ERRT é relativamente simples depois, foi oq eu fiz.

Já adiantando aqui, o ideal é criar uma outra tarefa pra que agt possa utilizar algumas bibliotecas prontas úteis ao RRT. E aprender como inserir isso dentro da nossa dll. Assim poderíamos utilizar a biblioteca do k-nearest neighbors no nosso RRT. Pra isso é importante pensar bem nas estruturas de dados que vão ser utilizadas pra representar os nós e a árvore, pra que tudo seja compatível.

Nicolas Oliveira escreveu:

Faz o RRT normal, mudar pra ERRT é relativamente simples depois, foi oq eu fiz.

Já adiantando aqui, o ideal é criar uma outra tarefa pra que agt possa utilizar algumas bibliotecas prontas úteis ao RRT. E aprender como inserir isso dentro da nossa dll. Assim poderíamos utilizar a biblioteca do k-nearest neighbors no nosso RRT. Pra isso é importante pensar bem nas estruturas de dados que vão ser utilizadas pra representar os nós e a árvore, pra que tudo seja compatível.

Estava discutindo com a Carla isso, chegamos a conclusão de usar a biblioteca FLANN(https://github.com/mariusmuja/flann) que já é bem famosa para calcular os KNN e tem várias features úteis, como possuir vários parâmetros de busca e usar multithreading(não sei se vai ser útil no nosso caso, pois a dimensão é só 2). No caso da instalação, a biblioteca foi instalada no pc mesmo, não precisando de nenhum arquivo no diretório do código, mas não sei como vai se comportar como dll.

Acabei de fazer a primeira implementação usando a biblioteca FLANN. A instalação é feita no pc mesmo e há intruções na página do github(https://github.com/mariusmuja/flann), um único problema que eu tive foi a ausência da biblioteca LZ4(https://github.com/lz4/lz4), que é requerida e não vem junto. Além disso, para compilar, é necessário botar a flag -llz4.

Basicamente o que eu fiz foi colocar os métodos de inserir e pesquisar na kdtree, tive que pesquisar alguns exemplos pois não está muito bem explicitado a implementação na documentação da biblioteca(https://usermanual.wiki/Document/flannmanual184.1650808969/).

Porém houve o problema que só havia como inserir o vetor das coordenadas do ponto e não os outros atributos da classe Node(como o _parent, por exemplo), assim o resultado do knnSearch era só um vetor e não tinha como saber diretamente os outros atributos.
Procurei na internet e achei uma solução de criar um hash map dos nodes, com as coordenadas como key, assim mantemos a kdtree com as coordenadas e o hash map com os objetos em si. Não sei se é uma boa solução, mas foi o utilizado em outras implementações do FLANN.