Semana #12 (18/04) – Continuação da escrita da dissertação

Continuando com a a escrita da dissertação, os primeiros dias da semana foram gastos a concluir o capítulo 4, “Solução de navegação local”, iniciado na semana anterior. Neste capítulo foi descrita a implementação do algoritmo utilizado para a navegação local e as alterações realizadas.

A segunda parte da semana serviu para escrever o capítulo 5, “Ambiente de simulação”, onde é descrito o simulador utilizado para os testes do algoritmo, do qual ficam duas imagens.

 

Anúncios

Semana #11 (11/04) – Continuação da escrita da dissertação

À semelhança da semana anterior, também esta foi ocupada com a escrita da dissertação, desta feita, do capítulo 3, “Infraestrutura experimental”.

Este capítulo apresenta a infraestrutura experimental utilizada durante a dissertação, não só os equipamentos físicos como o ATLASCAR2, mas também os softwares  utilizados como o ROS e o Gazebo. Também são descritos outros pacotes ROS desenvolvidos por colegas no âmbito do projeto ATLASCAR.

No fim da semana foi iniciada a redação do capítulo 4, “Solução de navegação local”, que se espera concluir no decorrer na próxima semana.

Este slideshow necessita de JavaScript.

Semana #9 (27/04) – Variação de trajetórias e simulador com dois modelos

Durante esta semana foi tentada a conclusão de duas tarefas da semana anterior, a variação de trajetórias e o simulador com dois modelos.

As simulações até aqui realizadas haviam demonstrado uma grande melhoria das trajetórias realizadas quando estas variam em função da velocidade. No entanto durante uma simulação foi colocado um obstáculo inesperado e o algoritmo conduziu à colisão do modelo com o mesmo. O motivo desta colisão foi a diminuição excessiva do comprimento do planeamento e foi então necessário aplicar um limiar para o comprimento mínimo das trajetórias. Nas simulações seguintes já não ocorreu colisão quando era colocado o obstáculo.

A conclusão do simulador com dois modelos está pendente de se conseguir replicar os controladores do Gazebo. Já foram realizadas mudanças nos launch files e os dois modelos já estão representados de forma independente, no entanto, como ambos os modelos utilizam os mesmos controladores e não podem coexistir dois controladores com o mesmo nome é impossível atuar sobre os dois modelos. Foram feitas várias tentativas para resolver este problema, mas sem sucesso. Ainda assim fica um ponto de situação do simulador.

Captura de ecrã de 2018-04-26 14-28-58
Planeador de trajetórias.
Captura de ecrã de 2018-04-26 14-28-58
Vista do simulador.

Por fim foi realizado o esqueleto da dissertação.

Semana #8 (20/04) – Variação de trajetórias, instalação de drivers e integração com navegação global

As tarefas propostas para esta semana eram três: a variação do comprimento das trajetórias com a velocidade no modelo, a variação da velocidade do modelo em função do ângulo de direção dado pela trajetória escolhida e a simulação de dois carros em sentidos opostos no Gazebo.

As duas primeiras tarefas foram realizadas em simultâneo devido à reestruturação de código necessária. Tiveram que ser realizadas modificações numa classe e criadas novas funções para ser possível não só atualizar a informação geométrica das trajetórias, mas também publicar os marcadores visuais no Rviz. A variação do comprimento das trajetórias em função da velocidade foi feita de acordo com a distância de travagem prevista no código da estrada. A regra então utilizada foi o quadrado da velocidade dividido por cem.  Já a variação da velocidade de acordo com o ângulo de direção seguiu uma linearização entre as velocidades máxima e de segurança pré-estabelecidas segundo o ângulo das rodas instantâneo.

A terceira tarefa não foi cumprida pois foi iniciado um processo de migração do código para o servidor do ATLASCAR2. Este processo foi especialmente moroso devido à instalação das drivers da placa gráfica do servidor. Ainda assim, foi conseguida a compilação total do código e foi iniciada uma etapa de comunicação entre a navegação local e a navegação global. A subscrição dos way points já se encontra terminada. Mas como se pode verificar no vídeo abaixo existe um rotação de referenciais que deve ser melhorada. Também é possível visualizar a variação do comprimento  das trajetórias, sendo que não existe qualquer relação entre os movimentos de direção reais e os previstos pelo algoritmo.

Semana #7 (13/04) – Simulador em Gazebo e avaliação do algoritmo

O objetivo da criação de um simulador foi o teste do comportamento do algoritmo de planeamento em função dos parâmetros utilizados para o cálculo das pontuações das trajetórias em condições controladas. No entanto, o simulador até aqui utilizado tinha em consideração a dinâmica da suspensão do carro que, para além de não estar corretamente modelada, estava a introduzir mais ruído na simulação, não permitindo retirar conclusões efetivas da variação dos parâmetros do algoritmo. Foi então instalado e adaptado um novo package para a simulação que considera um modelo de Ackermann rígido. Foi necessária transformação do um modelo que simulava uma cadeira de rodas motorizada para um modelo à escala do ATLASCAR2 e a subscrição e publicação de novas mensagens de velocidade e direção. O simulador utiliza dados de direção e velocidade linear como entradas, que sofrem transformações de acordo com o esquema abaixo.

Captura de ecrã de 2018-04-11 19-18-01
Funcionamento do simulador.

 

Depois do simulador a funcionar corretamente importava então avaliar as trajetórias planeadas. A métrica encontrada para tal foi a distância do obstáculo mais próximo ao carro a cada iteração. Foi desenvolvido este cálculo em código C++ e publicado num tópico para poder ser feita uma análise posterior a estes dados.

Depois de realizar alguns testes passou-se à análise estatística dos dados com a sua representação num histograma e cálculo de valores médio e desvio padrão. Um dos gráficos obtidos foi o seguinte:

captura-de-ecrc3a3-de-2018-04-11-19-19-05.png
Distribuição estatística das distâncias.

Antes da escrita desta publicação foi detetada um falha no algoritmo que gera grande instabilidade na trajetória escolhida o que faz com que se tenha de repensar alguns parâmetros e descarte os 6 testes realizados até então.

 

Semanas #5 e #6 (29/03 e 6/04) – Simulador em Gazebo

Estando o desenvolvimento e programação do algoritmo de planeamento local numa fase bastante avançada seria importante ajustar alguns parâmetros com o teste do mesmo em condições que garantam repetibilidade e atuação segundo as variáveis calculadas. Como o ATLASCAR2 ainda não possui atuação no movimento de direção e garantir condições semelhantes em estrada é impossível foi sugerida a criação de um simulador em Gazebo onde se pudesse realizar um percurso e a direção do modelo fosse dada e atuada pelo algoritmo de planeamento.

Como não estava familiarizado com o simulador Gazebo comecei a semana #5 com a resolução dos tutoriais propostos no site de suporte do software. Depois iniciei a procura de um modelo com direção do tipo Ackermann  que pudesse ser adaptado ao ATLASCAR2 e encontrei um simulador de carros telecomandos como se pode ser na figura abaixo que subscreve um tópico onde é publicada a direção e velocidade pretendidas. O passo seguinte foi a adaptação desse modelo à escala do ATLASCAR2 e o ajuste de parâmetros cinemáticos. Depois do modelo adaptado foi então criado um nodo em ROS para publicar a direção calculada pelo algoritmo segundo o tipo de mensagens lidas pelo simulador.

A semana terminou com o início da integração de uma pista para a navegação do modelo.

captura-de-ecrc3a3-de-2018-04-04-22-04-40.png
Modelo inicial do simulador.

Na semana #6, depois de falhadas varias tentativas de integração de uma pista de Fórmula 1, criei um modelo de uma pista de rallye-cross onde consegui por o modelo a circular com o algoritmo de planeamento a funcionar. Não estando satisfeito com esta representação voltei à opção da pista de Fórmula 1 que desta vez deu frutos como mostra a imagem.

Captura de ecrã de 2018-04-04 19-41-27.png
Simulador com modelo do ATLASCAR2 e pista de Fórmula 1.

Como forma de avaliar melhor o funcionamento do algoritmo e descartar algumas suspeitas de mau funcionamento tive que fazer alterações aos marcadores visuais apresentados no Rviz. Foi melhorada a representação de alguns marcadores como a trajetória escolhida e as pontuações das trajetórias e foi criado um novo que desenha o polígono do carro ao longo da trajetória escolhida. No fim da semana a representação em Rviz encontrava-se assim:

Captura de ecrã de 2018-04-04 19-42-13.png
Representação do algoritmo em Rviz.

Semana #4 (23/03) – Algoritmos de planeamento e LAR toolkit v5

Antes de ter qualquer conhecimento prático da implementação de algoritmos de planeamento estava quase decidido a implementar um algoritmo baseado em grelhas, o A* ou A star, com algumas adaptações que permitissem definir trajetórias capazes de respeitar o modelo cinemático de um automóvel. Mas, após verificar que a frequência de publicação do polígono do espaço livre é cerca de duas vezes superior à de publicação de uma grelha de ocupação que nem sequer representa todo o espaço analisado pelos scans laser, percebi que optar pelo planeamento em grelhas iria trazer um custo computacional que limitaria a capacidade de análise de dados e consequentemente a velocidade máxima de operação do ATLASCAR2. Desta forma comecei a estudar melhor a possibilidade de implementar um algoritmo já utilizado nos modelos ATLAS à escala e pouco referenciado na literatura que consiste no traçado de trajetórias circulares simples ou compostas e posterior avaliação das mesmas para escolha da melhor pontuada.

Depois de uma troca de ideias com o Orientador no fim da semana anterior ficou o desafio de nesta semana fazer a representação dessas mesma trajetórias. No entanto, da apresentação do relatório preliminar o Professor Miguel Riem sugeriu a possibilidade da utilização de algum software desenvolvido pelo LAR que utiliza este algoritmo para simular e testar trajetórias de estacionamento automático. Apesar das dificuldades em compilar e conseguir obter a representação dos dados, que foram superadas com a ajuda do Professor Miguel, este pacote de software revelou-se uma ferramenta bastante capaz e completa para o planeamento que se pretende executar.  Mais uma vez, utilizar software já desenvolvido implica percebê-lo e adaptá-lo. A primeira fase desta adaptação foi a alteração dos dados publicados de um polígono para uma point cloud para minimizar o número de alterações a realizar. Depois foram substituídas as trajetórias de estacionamento por trajetórias em arco simples para percecionar melhor as interseções com os obstáculos e aí foram detetados mais dois problemas, a elevada densidade da point cloud estava a retirar eficiência ao algoritmo e estavam a aparecer pontos na zona de sombra do carro. O segundo problema tinha origem numa densificação desnecessária da point cloud e o primeiro foi eliminado com a implementação de uma função de redução de pontos pouco significativos, como mostra a figura.

pontosm
Pontos removidos a negro e preservados a vermelho.

A adaptação que se seguiu foi realizada nos referenciais utilizados e transformações associadas. Foi criado um novo publicador responsável por publicar a transformação entre o referencial principal do nodo de deteção de espaço livre e o referencial principal do nodo de planeamento. Por fim foram introduzidos os parâmetros geométricos do ATLASCAR2 e realizado um ajuste nas representações para que estas sejam atualizadas automaticamente bastando apenas alterar os parâmetros pré-definidos. Atualmente a representação dos dados encontra-se assim:

rviz_screenshot_2018_03_23-15_18_20
Representação gráfica do algoritmo de planeamento.

Semana #3 (16/03) – Integração na plataforma ATLSCAR2 e apresentação do relatório preliminar

A integração na plataforma ATLASCAR2 começou no fim da semana #2 com a comunicação em tempo real com os sensores LIDAR e continuou durante toda esta semana com a instalação, compilação e interpretação do package ROS de deteção do espaço livre. A compilação deste software desenvolvido no LAR revelou-se algo traiçoeira pois foi necessária a instalação de algumas dependências necessárias à execução deste package. Depois de ultrapassado este problema foram reproduzidos dois bags com informação sensorial recolhida na A25 e no Alboi para confirmar a publicação de todos os tópicos criados por este package e verificar a forma como a calibração dos sensores é utilizada. Foi gasto algum tempo a tentar perceber como os ficheiros de calibração devem ser carregados e que o sensor de referência utilizado é o LIDAR planar instalado no lado esquerdo do ATLASCAR2. Com a instalação e compilação completas comecei a esmiuçar o código em C++ que permite a representação do espaço livre num polígono ou numa grelha de ocupação. A interpretação deste código é importante por dois motivos. O primeiro é pelo simples facto de perceber como o software é implementado e que tipo de estruturas e classes são utilizadas nesta linguagem de programação nova. O segundo motivo tem origem na subscrição dos tópicos publicados por este nodo. Ao criar outro nodo que subscreva o polígono de espaço livre ou a grelha de ocupação deve-se ter em atenção que tipo de mensagens são publicadas nestes tópicos e quais as suas estruturas de dados.

Com a informação das mensagens publicadas nos tópicos iniciei a criação de um novo package capaz de subscrever a informação do espaço livre e calcular o centróide do polígono. E porque o cálculo do centróide? Mais uma vez duas razões, ganhar destreza na programação e criar um alvo que possa ser utilizado na implementação de um algoritmo. Quando são utilizados algoritmos de navegação como os Campos de Potencial, o RRT, o A* ou as Grelhas Evidenciais é necessário existir um ponto atrator onde o algoritmo deve convergir.

Captura de ecrã de 2018-03-15 22-45-50.png
Exemplo de representação do centróide do polígono de espaço livre.

Por fim resta referir que os trabalhos foram intercalados com a realização da apresentação do relatório preliminar a ocorrer na sexta-feira.

Semana #2 (09/03) – Conclusão Workshop ROS + Relatório Preliminar

À semelhança da semana anterior, esta também pode ser divida em duas partes. De segunda a quarta feira foi terminado o relatório preliminar. Isto implicou a escrita das últimas três tarefas do enunciado da dissertação relacionadas com a combinação dos dados sensoriais, teste de algoritmos e desenvolvimento da aplicação final. A tarefa que apresentou mais dificuldades foi a da combinação dos dados sensoriais. Primeiro foi feita uma pesquisa bibliográfica para se perceber que tipo de representações se podiam encontrar e como se podiam enquadrar com a utilização dos algoritmos encontrados na tarefa de revisão bibliográfica. Como a generalidade dos algoritmos encontrados trabalha sobre grelhas de ocupação e representações polinomiais do espaço livre decidi aproveitar os trabalhos anteriores realizados no LAR que já dão estas representações e só em caso de estes não se adequarem ao algoritmo escolhido partir para novas representações. As duas últimas tarefas foram de redação mais rápida o que permitiu a preparação do workshop de ROS a realizar na quinta feira.

Esta semana o workshop só ocupou um dia e foram apresentadas ferramentas como o rosbag para gravação de tópicos o que possibilita o trabalho offline, neste caso fora do ATLASCAR2. Durante o workshop foram realizados jogos entre as três equipas, o que não correu da melhor maneira porque a nossa equipa foi derrotada..

Na sexta feira foram retomados os trabalhos da dissertação e a manhã foi passada a tentar realizar a instalação dos packages ROS desenvolvidos no LAR e consequente comunicação com os sensores instalados. Depois de muita dificuldade devido a erros de compilação conseguimos obter dados diretamente dos sensores. A parte da tarde foi maioritariamente ocupada pela reunião de discussão do relatório preliminar de onde surgiram novas ideias e elementos a serem investigados.

Desta reunião firam dois grandes objetivos para a semana seguinte: a realização da apresentação do relatório preliminar e interpretar e colocar em funcionamento o software de deteção e representação do espaço livre dados pelos LIDAR’s.