Realização de todos os testes apresentados na dissertação.
Escrita do capítulo 5.
Semana 13 (21 a 25 Mai)
- Redação do capítulo 4.
- Repetição dos testes de calibração.
- Repetição dos testes em situações propícias a falhas, zona com árvores e passagem em túnel.
- Tratamento de dados.
Semana 12 (14 – 18 Mai)
- Redação do capítulo 3.
- Pesquisa de referências relativas à navegação.
- Início da redação do capítulo 4.
Semana 11 (7 – 11 Mai)
- Escrita do capítulo 2 da dissertação.
- Estudo do funcionamento do sistema GNSS.
Não tenho muito para mostrar esta semana! Deixo aqui algo que encontrei e achei bastante interessante.
O vídeo seguinte, uma palestra de Sacha Arnoud, diretor de engenharia da Waymo no MIT, mostra algumas linhas orientadoras da Google no desenvolvimento do seu veículo autónomo.
Semana 10 (30 Abr – 4 Mai)
Monitorização
- Estabelecimento de comunicação com a base de dados instalada no servidor do LAR.
- Instalação do pacote php-pgsql de modo a possibilitar o acesso à base de dados no ficheiro php.
- Ajuste do ficheiro php à nova tabela e às suas variáveis.
- Introdução da API Key no widget – Google Maps da página web.
- Alterações ao ficheiro html responsável pelo design da página. Eliminação dos campos relativos às variáveis, que neste momento, não estão disponíveis e introdução de campos relativos ao local de destino.
- Introdução do icon ATLASCAR 2.
Documentação
- Escrita do primeiro capítulo da dissertação.
-> Pequena demonstração do sistema desenvolvido em funcionamento.
(Rosbag antigo com problemas perda de leituras. Este problema já foi resolvido. )
Semana 9 (23 – 27 Abr)
- Ajustes finais no planeador de rota.
- Aumento da distância limite entre a posição do veículo e o segmento de caminho para o recálculo da rota.
- Alteração do código de modo a garantir a sequência correta de segmentos de caminho – limpeza da lista de waypoints.
- Monitorização
- Configuração da base de dados instalada no servidor do LAR.
- Tentativas, sem sucesso, de conexão remota com a base de dados.
- Criação de uma tabela apenas com dados relativos à localização global.
- Criação de um package ROS para realização da gestão da base de dados.
- Alteração do ficheiro php para interação com a nova tabela.
NOTA: Eu ainda não consigo comunicar remotamente com a base de dados.
Semana 8 (16 -20 Abr)
- Correção do trabalho da semana anterior para a utilização apenas dos waypoints obtidos a partir de descodificação da string “overview polyline” devido à baixa qualidade dos waypoints obtidos a partir de da polyline de cada etapa.
- No final da semana passada havia a ideia clara que a string “overview polyline” permitia obter waypoints corretos, o que com mais experiências não se verificou. Por exemplo, num trajeto DEM -> Estádio Municipal de Aveiro em algumas ocasiões os waypoints não estam no local correto.
- SOLUÇÃO: Foi aplicação a solução tentada nas strings polyline de cada etapa – substituir todos os “\\” por “\”- desta feita resultou muito bem.
- Implementação de uma metodologia para verificar se o veículo está na rota correta, foram traçados segmentos de reta entre waypoints sucessivos e sempre que a posição do veículo se afaste 5 metos desse segmento é re-calculada a rota. O limite 5 metros foi uma primeira tentativa que resultou bem nos “rosbag” feitos anteriormente.
- Implementação de uma metodologia para identificar o waypoint anterior e o seguinte.
- Traçados os segmentos de reta entre os waypoints sucessivos é calculada a distância entre a posição do veículo e cada segmento, o segmento de reta a menor distância relativamente ao veículo indica dois waypoints o anterior e o seguinte.
- Para complementar a abordagem sempre que o veículo esteja a distância inferior a 4 metros do waypoint seguinte, decorrente do passo anterior, o waypoint seguinte avança para o próximo assim como o anterior.
- Publicação das coordenadas dos waypoints (anterior e seguinte) para subscrição por parte da navegação local. Esta coordenadas não foi possível avaliar a qualidade das mesmas. Contudo num primeiro pequeno teste de subscrição dessas coordenadas fica a indicação que se encontram corretas.
Preparação do servidor do ATLASCAR2 para acolher todos os trabalhos.
Replicação da base de dados criada anteriormente no computador pessoal.
………
Semana 7 (9 – 13 Abr)
Planeamento de rota utilizando o Google Maps API Directions.
- Criação de um nodo ROS novo, com a implementação de um serviço para pedido de rota, preparado para ser chamado através da aplicação Mapviz.
- Descodificação da mensagem recebida utilizando funções desenvolvidas pelo próprio.
- Busca pelos respetivos campos.
- Aplicação da função desenvolvida pelo Ivan Ferreira na descodificação do campo “Polyline”
- Alguns ajustes às tabelas criadas na semana anterior e introdução das variáveis no seu interior.
- Representação de todos os waypoints obtidos na aplicação Mapviz. (Criação de um novo plugin “global_planning”).
Exemplo de mensagem recebida.
{
"geocoded_waypoints" : [
{
"geocoder_status" : "OK",
"place_id" : "EiNSLiBkbyBDcmFzdG8gMzAsIDM4MTAtMTkzLCBQb3J0dWdhbA",
"types" : [ "street_address" ]
},
{
"geocoder_status" : "OK",
"place_id" : "ChIJHTTGW6uiIw0R9UAiSEJX02c",
"types" : [ "street_address" ]
}
],
"routes" : [
{
"bounds" : {
"northeast" : {
"lat" : 40.6301105,
"lng" : -8.656497200000002
},
"southwest" : {
"lat" : 40.62119440000001,
"lng" : -8.6622963
}
},
"copyrights" : "Map data ©2018 Google",
"legs" : [
{
"distance" : {
"text" : "1.6 km",
"value" : 1618
},
"duration" : {
"text" : "3 mins",
"value" : 175
},
"end_address" : "Rua de S. Tiago 9, 3810-193 Aveiro, Portugal",
"end_location" : {
"lat" : 40.6294585,
"lng" : -8.6583121
},
"start_address" : "R. do Crasto 30, 3810-193, Portugal",
"start_location" : {
"lat" : 40.6227396,
"lng" : -8.657280799999999
},
"steps" : [
{
"distance" : {
"text" : "0.2 km",
"value" : 184
},
"duration" : {
"text" : "1 min",
"value" : 24
},
"end_location" : {
"lat" : 40.6212048,
"lng" : -8.656497200000002
},
"html_instructions" : "Head \u003cb\u003esouth\u003c/b\u003e toward \u003cb\u003eR. do Crasto\u003c/b\u003e\u003cdiv style=\"font-size:0.9em\"\u003ePartial restricted usage road\u003c/div\u003e",
"polyline" : {
"points" : "cc}vF~zys@f@Sx@]j@[PI~@g@x@UXE"
},
"start_location" : {
"lat" : 40.6227396,
"lng" : -8.657280799999999
},
"travel_mode" : "DRIVING"
},
{
"distance" : {
"text" : "0.9 km",
"value" : 944
},
"duration" : {
"text" : "1 min",
"value" : 84
},
"end_location" : {
"lat" : 40.6271362,
"lng" : -8.661023699999999
},
"html_instructions" : "Turn \u003cb\u003eright\u003c/b\u003e onto \u003cb\u003eR. do Crasto\u003c/b\u003e",
"maneuver" : "turn-right",
"polyline" : {
"points" : "oy|vFbvys@@RE\\Gl@IZM^MZYv@e@lAQ`@OVm@l@kAbA}@r@EB[TiAt@cDjBWPkAz@a@Za@`@q@t@k@p@c@p@Yd@cA|@]XKFK@gAGKCECEMAKEwAG_AEYEMMU"
},
"start_location" : {
"lat" : 40.6212048,
"lng" : -8.656497200000002
},
"travel_mode" : "DRIVING"
},
{
"distance" : {
"text" : "0.2 km",
"value" : 227
},
"duration" : {
"text" : "1 min",
"value" : 22
},
"end_location" : {
"lat" : 40.6289326,
"lng" : -8.659822600000002
},
"html_instructions" : "Turn \u003cb\u003eleft\u003c/b\u003e toward \u003cb\u003eR. dos Lavadoiros\u003c/b\u003e",
"maneuver" : "turn-left",
"polyline" : {
"points" : "s~}vFjrzs@YAUG_@SkB}@{@g@OOs@{@]YKE"
},
"start_location" : {
"lat" : 40.6271362,
"lng" : -8.661023699999999
},
"travel_mode" : "DRIVING"
},
{
"distance" : {
"text" : "70 m",
"value" : 70
},
"duration" : {
"text" : "1 min",
"value" : 10
},
"end_location" : {
"lat" : 40.6295352,
"lng" : -8.6599223
},
"html_instructions" : "Continue onto \u003cb\u003eR. dos Lavadoiros\u003c/b\u003e",
"polyline" : {
"points" : "yi~vFzjzs@MIOA_@DWFc@P"
},
"start_location" : {
"lat" : 40.6289326,
"lng" : -8.659822600000002
},
"travel_mode" : "DRIVING"
},
{
"distance" : {
"text" : "0.2 km",
"value" : 193
},
"duration" : {
"text" : "1 min",
"value" : 35
},
"end_location" : {
"lat" : 40.6294585,
"lng" : -8.6583121
},
"html_instructions" : "Turn \u003cb\u003eright\u003c/b\u003e at \u003cb\u003eR. da Pega\u003c/b\u003e\u003cdiv style=\"font-size:0.9em\"\u003eDestination will be on the left\u003c/div\u003e",
"maneuver" : "turn-right",
"polyline" : {
"points" : "sm~vFnkzs@Sg@}AmBnAkBp@_A"
},
"start_location" : {
"lat" : 40.6295352,
"lng" : -8.6599223
},
"travel_mode" : "DRIVING"
}
],
"traffic_speed_entry" : [],
"via_waypoint" : []
}
],
"overview_polyline" : {
"points" : "cc}vF~zys@`Bq@|@e@~@g@x@UXE@RMjAWz@_BbEOVm@l@iCvBa@XmF`DcBlAcA|@}AfB}@vAaBvAWHsAKECGYMwCKg@MUYAu@[kB}@{@g@cAkA]YKEMIOAw@Lc@PSg@}AmBnAkBp@_A"
},
"summary" : "R. do Crasto",
"warnings" : [],
"waypoint_order" : []
}
],
"status" : "OK"
}
Representação dos waypoints obtidos.
A vermelho a localização do veículo e os pontos pretos são os waypoints.
Para complementar a intrepertação. (A linha reta une o início da rota e o destino)
Outros exemplos que mostram que nem todos os waypoints estão corretos.
zoom
Próximas etapas;
Calcular distâncias entre a posição do veículo e os waypoints.
Verificação dos pontos de início e fim de cada etapa e sua instrução.
Criação de uma metodologia para fecho dos waypoints.
Semana 6 (2 – 6 Abr)
Planeamento de rota usando o OSRM- Open Source Routing Machine
Colocar em funcionamento o trabalho do Ivan Ferreira. (Não conseguido na totalidade)
Criação de uma base de dados idêntica à do trabalho do Ivan.
Depois de algum estudo do projeto OSRM decidi tentar o GOOGLE MAPS API DIRECTIONS.
API Key criada com sucesso.
Pedido de rota através do código do Ivan com sucesso. (totalmente on-line)
Processamento da resposta em Json ……….(não está fácil).
Semana 5 (26 – 30 Mar)
Testes em ambiente urbano para analisar o comportamento do sensor.
- Alinhamento em condições favoráveis, céu aberto, piso sem irregularidades.
- Passagem por zona com constrangimentos (árvores de elevado porte, prédios e piso muito irregular)
- Passagem por túnel com aproximadamente 220 metros.
1º teste
Análise do processo de alinhamento.
tempo de alinhamento: 155 segundos
tempo com menos de 4 satélites: 24 segundos
Como é possível observar na saída do túnel continuam corretas.
2 º teste
Alinhamento em ambiente urbano.
tempo de alinhamento: 110 segundos
tempo com menos de 4 satélites: 46 segundos
Desfazamento à saída do túnel.
Problemas no rosbag não me permitem colocar a foto com a representação como no caso anterior. A posição à saída do túnel está na via errada.
—————————————————————————————————————————————-
Criação de 2 Plugins para a aplicação mapviz, gerando a possibilidade de representar o posicionamento no mapa da informação proveniente nos tópicos “/bestpos” e “/bestgnsspos”.
- Utilidade: A representação do tópico “/bestgnsspos” permite representar a posição calculada sem o contributo da unidade inércial. O tópico “/bestpos” permite representar a melhor posição fornecida pelo sensor segundo o protocolo de comunicação Novatel.
Desfasamento curioso!!
Será esta a razão? (inclinação do sensor no plano vertical perpendicular ao eixo do veículo)
Problema corrigido. Mas ainda não testada a sua influência no cálculo da posição.
—————————————————————————————————————————————–
Preparação de código para lançar dois nodos com parâmetros diferentes. Para suportar frequências de comunicação de 20Hz para dados relativos à posição e 100Hz para dados relativos à unidade inércial.
