Semana #14 (23/5) – Continuação da escrita e simulação de GPS.

Esta semana foi dedicada à finalização da escrita dos capítulos 4 e 5.

Durante a realizações de simulações foi verificado que, devido à colocação do ponto atrator em frente ao carro, o calculo das trajectórias fica comprometido quando este executa manobras e se orienta na direcção das paredes.

Deste modo foi decidido criar um simulador que permita colocar o ponto atrator sempre no percurso desejado.

Anúncios

Semana #13 (17/5) – Condução pela via da direita

Tendo como objectivo desenvolver algoritmos que permitam ao veiculo executar manobras pré determinadas, é necessário que este circule na via da direita, de modo a permitir casos como a ultrapassagem ou o cruzamento de veículos.

Para tal foi analisado a solução proposta por outros trabalhos, onde era adicionado um parâmetro CL (central line) que dava maior valor a trajectórias de curvas para a direita. Deste modo, o veiculo tinha um comportamento instável, estando constantemente a desviar-se da parede direita.

Por esta razão foi optado uma nova abordagem que consistia no aproveitamento da nuvem de pontos já criada para simular a linha central, e utilizar esta como um obstáculo, não permitindo que o veiculo a ultrapassasse.

Como as ultrapassagens e outras manobras necessitam que o veiculo circule pela esquerda, foi criado um parâmetro booleano de “permissão” que ao ser falso, o planeador deixa de considerar a nuvem de pontos da linha, sendo esta ignorada pelo veiculo.

Semana #12 (10/5) – Escrita da dissertação

Esta semana foi dedicada à escrita dos primeiros 3 capítulos da dissertação.

Além disto foi criado um programa que permite configurar dinamicamente as variáveis da simulação, ou seja, que permite alterar os valores (velocidade, max. rotação, etc.) durante a simulação.

De modo a permitir desenvolver casos específicos é necessário que o veiculo circule pela direita. Neste momento está a ser analisado o código existente para perceber o porquê de este caso não se verificar.

Semana #11 (03/5) – Simulação de ultrapassagens

Com a utilização de dois ou mais veículos a simulação começa a ficar pesada para o meu computador colocando-se a possibilidade de utilizar um computador presente no LAR. Com isto em mente, visto que será necessário utilizar mais o GitHub, foi feita uma limpeza à pasta src do projecto, eliminando packages desnecessárias e ficheiros deixados por projectos anteriores. Com esta limpeza foi possível diminuir o numero de ficheiros de 4904 para 2965. Esta diminuição tem um grande peso no tempo de compilação e na actualização do GitHub.

Com o objectivo de simular ultrapassagens, tornou-se necessário extrair a velocidade do veiculo, permitindo a sua alteração quer na launch file, quer durante a simulação. Para tal foi criado um ficheiro yaml onde foram colocados diversos parâmetros influênciadores na simulação, tendo alterado todos os ficheiros onde estes são utilizados.

Estes valores são os valores por defeito, sendo alterados na launch file, podendo ser diferentes para cada veiculo.

Como verificado na semana passada, a colisão de veículos não correspondia ao desejado visto que o sensor LIDAR intersecta o próprio veiculo. Assim foi utilizado o programa SolidWorks para criar um ficheiro STL com uma geometria simplificada do carro consistindo na combinação de um paralelepípedo com um prisma triangular. De seguida foi utilizado o programa Blender para converter o ficheiro STL em .dae, formato preferido do simulador.

Com a simulação pronta a ser executada foi necessário corrigir o parâmetro CL que permite que o veiculo circule preferencialmente pela via da direita. Após correcção dos parâmetros que obtêm o valor CL este finalmente afectou o comportamento do veiculo, apesar de não se comportar como esperado.

No meio da semana foi realizado uma reunião sobre a escrita da dissertação, tendo alterado a organização desta e continuado a sua escrita.

Semana #10 (26/4) – Ajustes ao simulador

Esta semana estava previsto realizar testes como por exemplo a ultrapassagem ou a colisão de dois veiculos autonomos.

Em primeiro lugar o APgenerator e o planeador de trajectórias foram alterados de forma a permitir o movimento dos veículos autónomos ao iniciar a simulação no Gazebo (esta simulação é apenas iniciada quando é clicado no botão play do Gazebo, ao contrario do que ocorria anteriormente, onde a simulação começava assim que os nós eram lançados).

Ao realizar os dois testes referidos anteriormente deparei-me com resultados estranhos que, apesar de esperar maus resultados devido ao planeador não estar optimizado, os veículos colidiam com pouco ou nenhum movimento de manobras que evitassem esta colisão. Não só colidiam como também ocupavam o mesmo espaço levando à conclusão que algum parâmetro estava mal configurado.

Ao investigar os parâmetros referentes ao lançamento do modelo no Gazebo, foi verificado que o modelo do ATLASCAR2 está em formato .stl e não no formato .dae que é mais utilizado. O formato .stl tem como desvantagens a impossibilidade de adicionar texturas e controlar os movimentos das diferentes peças do modelo, que neste caso seria interessante o movimento das rodas.

Apesar deste pormenor, a utilização de ficheiros .stl não deveria influenciar as colisões. Depois de muitas tentativas de contornar o problema descobri a opção do Gazebo de visualizar apenas os objectos que contêm colisões, onde finalmente descobri a origem do problema. Apesar do ficheiro de lançamento do modelo estar configurado para incluir colisões, esta foi criada utilizando um paralelepípedo com dimensões muito reduzidas (tamanho de um pedal), tamanho perfeito para existir colisão e ao mesmo tempo não ser fácil de detectar pelos LIDARs.

Visualização das “hitboxes” do veiculo

Alterando o tamanho da “hitbox” consegui finalmente com que os LIDARs a reconhecessem e os veículos, tal como era previsto, se desviassem desta.

Semana #8 (12/4) – Simulador com múltiplos veículos

“Esperávamos, desejávamos, conseguimos: Vitória!” – Marcelo Rebelo de Sousa

Todas as dificuldades encontradas para criar um ambiente que simule múltiplos veículos autónomos no Gazebo tornou esta semana critica no desenvolvimento da dissertação. Desde a inexistência de soluções que simulassem múltiplos veículos sem qualquer intervenção por parte do utilizador, quer nos problemas existentes nos que estavam próximos da solução, tornou a continuação do desenvolvimento deste ambiente de simulação perigoso devido à aproximação do limite de entrega da dissertação tendo em conta as tarefas ainda por realizar. Com isto em mente, esta semana o simulador teria de estar operacional, caso contrario seria necessário rever os planos da dissertação.

Após algumas alterações foi obtido sucesso na junção de todos os nós e tópicos num único namespace tendo depois de corrigir alguns detalhes de modo a que o Gazebo e alguns nós específicos se conseguissem reconhecer e distinguir.

Com todos os nós e tópicos a comunicarem entre si (e porque todos adoramos desafios) surgiu mais um problema: os nós responsáveis por analisar as nuvens de pontos morriam assim que eram iniciados, impedindo a analise às suas log files (provavelmente porque não tiveram tempo sequer de as criar) e sem informação do problema na linha de comandos.

Após pesquisar o problema (e para futura referência) descobri que é possível iniciar nós fora da linha de comandos inicial (mas continuando agregados ao sistema global), permitindo assim obter mais informação sobre o sucedido. Para tal é colocado no nó em questão o seguinte argumento, cuja função passa por lançar uma janela do programa de debugg gdb que contem a execução deste nó.

launch-prefix=”xterm -e gdb -ex run –args

Deste modo descobri que o problema era resultado da utilização de namespaces, que alterou os frame_id das nuvens de pontos, e que igualmente influenciou a geração do ponto atrator. Com a alteração de código para permitir a variação dos frame_id e o aperfeiçoamento do APgenerator finalmente foi obtido sucesso na simulação de um único veiculo.

A maior surpresa aconteceu quando ao executar dois veículos, tendo apenas duplicado o lançamento do primeiro alterando a posição e o namespace, não surgiu qualquer erro e a simulação decorreu perfeitamente.

Nas imagens acima é possível ver a execução do simulador com dois veículos e os respectivos Rviz (à esquerda o veiculo de trás e à direita o veiculo que circula à frente).