desenvolvimento de sistemas de aquisiÇÃo …...sistemas de aquisição e processamento de dados em...
TRANSCRIPT
1
2
DESENVOLVIMENTO DE SISTEMAS DE AQUISIÇÃO DE SINAIS
BIOMECÂNICOS
Daniel Moreira Guimarães
Projeto de Graduação apresentado ao Curso de
Engenharia Eletrônica e de Computação da Escola
Politécnica, Universidade Federal do Rio de
Janeiro, como parte dos requisitos necessários à
obtenção do título de Engenheiro.
Orientador: Alexandre Visintainer Pino
Rio de Janeiro
Março de 2019
3
4
5
UNIVERSIDADE FEDERAL DO RIO DE JANEIRO
Escola Politécnica – Departamento de Eletrônica e de Computação
Centro de Tecnologia, bloco H, sala H-217, Cidade Universitária
Rio de Janeiro – RJ CEP 21949-900
Este exemplar é de propriedade da Universidade Federal do Rio de Janeiro, que
poderá incluí-lo em base de dados, armazenar em computador, microfilmar ou adotar
qualquer forma de arquivamento.
É permitida a menção, reprodução parcial ou integral e a transmissão entre
bibliotecas deste trabalho, sem modificação de seu texto, em qualquer meio que esteja
ou venha a ser fixado, para pesquisa acadêmica, comentários e citações, desde que sem
finalidade comercial e que seja feita a referência bibliográfica completa.
Os conceitos expressos neste trabalho são de responsabilidade do(s) autor(es).
6
DEDICATÓRIA
Dedico este trabalho à minha vó Marlene, por todos os anos de carinho.
7
AGRADECIMENTO
Agradeço a minha mãe, Maria Helena, por todo o apoio e incentivo nesses anos.
Ao meu irmão, Miguel, por estar sempre por perto quando precisei.
À Rúbia, pelo companheirismo e afeto durante a jornada.
Aos meus amigos, pelos momentos compartilhados, sem os quais teria sido mais difícil.
Aos colegas de curso, pelos inúmeros auxílios durante a minha formação.
Aos companheiros de laboratório, por me mostrar a engenharia de outros ângulos.
Ao Prof. Alexandre Pino, por todos os anos de paciência.
Ao Prof. Marcio Souza, por me ensinar a soldar e olhar atento.
Ao Prof. Frederico Jandre, pelas constantes discussões.
Ao Samuel Souza, pela ajuda com as placas analógicas.
8
9
RESUMO
Sistemas de aquisição e processamento de dados em ambientes de pesquisa são,
muitas vezes, desenvolvidos para um experimento específico, e sua vida útil limita-se
ao tempo que o pesquisador se dedica àquela empreitada. Novos experimentos acabam,
muitas vezes, desenvolvendo novamente dispositivos e programas similares aos
utilizados anteriormente, mesmo no contexto de um único laboratório. Este trabalho
apresenta um sistema de aquisição e processamento de sinais biomecânicos modular e
extensível que objetiva fornecer uma plataforma inicial para a criação de sistemas mais
complexos, padronizando as interações entre as múltiplas partes que constituem este
sistema. O projeto utilizou o framework ROS como base das convenções e arquitetura
adotadas, e um sistema de aquisição de dados relevantes à biomecânica foi utilizado
como prova de conceito para o projeto. Esta prova de conceito implementa estimação de
aceleração, velocidade, posição e orientação a partir de leituras de sensores IMU e GPS
que são lidos e processados por uma Raspberry Pi e um microcontrolador ESP32 e foi
avaliado a partir de testes para determinar sua capacidade de prover as funcionalidades
propostas.
Palavras-Chave: Biomecânica, framework, ROS, IMU, filtro de Kalman
10
ABSTRACT
Data processing and acquisition systems used in research environments are often
used in a single specific experiment, having its lifetime is constrained to the period that
the researcher dedicates to that endeavor. New experiments frequently develop similar
devices and programs to those previously designed, even in the context of a single
research laboratory. This work presents a modular and extensible data processing and
acquisition system for biomechanical signals that aims to provide an initial platform for
the creation of more complex systems, standardizing the interaction between the
multiple constituent parts. This project used the ROS framework as foundation for the
adopted conventions and architecture and a data acquisition system was developed as
proof of concept for the project. This system implements acceleration, velocity, position
and orientation estimates based on IMU and GPS measurements that are read and
processed by a Raspberry Pi and an ESP32 microcontroller and was evaluated by
several tests to determine its fitness according to the proposed functionality.
Key-words: Biomechanics, framework, ROS, IMU, Kalman filter
11
SIGLAS
ROS – Robot Operating System
API – Application Programming Interface
REP – ROS Enchancement proposal
IMU – Inertial Measurement Unit
GPS – Global Positioning System
NMEA - National Marine Electronics Association
I2C - Inter-Integrated Circuit
12
Sumário 1 Introdução ............................................................................................................... 16
1.1 Tema ................................................................................................................. 16
1.2 Delimitação ...................................................................................................... 16
1.3 Justificativa ...................................................................................................... 17
1.4 Objetivos .......................................................................................................... 17
1.5 Metodologia ..................................................................................................... 18
1.6 Descrição ......................................................................................................... 19
2 Conceitos Teóricos.................................................................................................. 20
2.1 Robot Operating System .................................................................................. 20
2.2 Zeroconf ........................................................................................................... 25
2.3 FreeRTOS ........................................................................................................ 26
2.4 Inertial measurement unit ................................................................................ 26
3 Módulos de Hardware ............................................................................................ 35
3.1 Raspberry Pi 3 .................................................................................................. 35
3.2 ESP32 ............................................................................................................... 37
3.3 Sensores ........................................................................................................... 39
4 Panorama do sistema .............................................................................................. 44
4.1 Caso de uso ...................................................................................................... 45
4.2 Aquisição de sinais .......................................................................................... 47
4.3 Calibração ........................................................................................................ 53
4.4 Estimação de orientação .................................................................................. 58
4.5 Estimação do vetor de estado completo ........................................................... 61
5 Avaliação do sistema .............................................................................................. 64
5.1 Calibração de sensores ..................................................................................... 64
5.2 Teste de sistema de orientação ......................................................................... 69
5.3 Teste de estimação de trajetória ....................................................................... 82
6 Limitações .............................................................................................................. 90
6.1 Placas analógicas ............................................................................................. 90
6.2 Alimentação da Raspberry Pi........................................................................... 91
6.3 Leitura dos sensores ......................................................................................... 91
6.4 Performance da Raspberry Pi........................................................................... 92
6.5 Modularidade dos sensores .............................................................................. 93
7 Conclusões .............................................................................................................. 94
8 Referências ............................................................................................................. 95
13
9 Anexo A – Shields desenvolvidos ........................................................................... 98
9.1 Shield da Raspberry Pi ..................................................................................... 98
9.2 Shield da ESP32 ............................................................................................. 100
10 Anexo B – RowingCore ....................................................................................... 102
11 Anexo C – Ferramentas de visualização .............................................................. 104
14
Lista de Figuras Figura 1: ESP32 Model B. .............................................................................................. 36 Figura 2: Raspberry Pi com Shield e bateria portátil...................................................... 37 Figura 3 Breakout comercial para ESP32, modelo DOIT ESP32-DEVKIT. ................. 38 Figura 4: ESP32 com Shield. .......................................................................................... 39 Figura 5 GY-80. .............................................................................................................. 40
Figura 6: GY-9250. ........................................................................................................ 41 Figura 7: GY-273. .......................................................................................................... 42 Figura 8: GY-GPS6MV2. ............................................................................................... 43 Figura 9: Possível configuração do sistema. .................................................................. 45 Figura 10: Configuração da prova de conceito. .............................................................. 45
Figura 11: Fluxo de sinais para veículo (a esquerda) e para o elemento móvel (a direita).
........................................................................................................................................ 46 Figura 12: Fluxo das mensagens do sistema para veículo (a esquerda) e para o elemento
móvel (a direita).............................................................................................................. 47 Figura 13: Estrutura de classes do imu_reader. .............................................................. 48 Figura 14: Diagrama de sequência do imu_node. .......................................................... 50
Figura 15: Diagrama de sequência da task readSensors. ................................................ 51 Figura 16: Diagrama de sequência da task publishData. ................................................ 52 Figura 17: Processo de calibração. ................................................................................. 53
Figura 18: Interface do imu_calibrator_node. ................................................................ 56 Figura 19: Fluxo das mensagens no imu_calibrator. ...................................................... 57
Figura 20: Sistemas de coordenadas TF. ........................................................................ 59 Figura 21: Fluxo lógico de mensagens. .......................................................................... 63 Figura 22: Nuvens de pontos utilizadas na estimativa. .................................................. 67
Figura 23: Nuvens de pontos antes e depois da calibração. ........................................... 68 Figura 24: Setup de bancada utilizado nos testes. .......................................................... 70
Figura 25: Ângulos estimados pelo filtro de estimação (Raspberry). ............................ 74
Figura 26: Diferença entre ângulos estimados e sua média (Raspberry). ...................... 75
Figura 27: Ângulos estimados ao longo do tempo (ESP32). .......................................... 76 Figura 28: Detalhe da descontinuidade observada. ........................................................ 77
Figura 29: Diferença entre ângulos estimados e sua média (ESP32). ............................ 78 Figura 30: Comparação entre posição real e estimada (Primeira configuração). ........... 79 Figura 31: Comparação entre posição real e estimada (segunda configuração). ............ 80
Figura 32: Comparação entre posição real e estimada (Terceira configuração). ............ 80 Figura 33: Comparação entre posição real e estimada (quarta configuração). ............... 81
Figura 34: Trecho inicial do percurso entre os bairros de Charitas e São Francisco. ..... 83 Figura 35: Curva em Charitas. ........................................................................................ 83 Figura 36: Curva no entorno da Igreja............................................................................ 84 Figura 37: Parada no sinal de trânsito. ........................................................................... 85 Figura 38: Entrada no túnel São Francisco – Icaraí. ...................................................... 85
Figura 39: Saída do túnel. ............................................................................................... 86
Figura 40: Ponte Rio-Niterói. ......................................................................................... 86
Figura 41: Chegada ao Fundão. ...................................................................................... 87 Figura 42: Primeira discrepância entre estimação e leitura do GPS............................... 87 Figura 43: Segunda discrepância entre estimação e leitura do GPS............................... 88 Figura 44: Terceira discrepância entre estimação e leitura do GPS. .............................. 88 Figura 45: Shield da Raspberry Pi. Parte superior da placa com a silhueta das placas de
breakout da IMU e GPS. O plano contínuo é o plano de terra da placa. ........................ 99
15
Figura 46: Shield da Raspberry Pi Parte inferior da placa, exibindo o roteamento das
trilhas e o plano de Vcc da placa. ................................................................................... 99
Figura 47: Esquemático do shield da Raspberry Pi. ..................................................... 100 Figura 48: Shield da ESP32 (Vista inferior). ................................................................ 101 Figura 49: Shield da ESP32 Face inferior, exibindo as trilhas e o plano de Vcc. ........ 102 Figura 50: Esquemático do Shield da ESP32. .............................................................. 102 Figura 51: Manipulador robótico exibido no rviz. ....................................................... 105
Figura 52: Trajetória e imagens de câmeras exibidas no mapviz. ................................ 105
16
1 Introdução
1.1 Tema
O tema deste trabalho consiste no desenvolvimento de um sistema de aquisição,
gravação e processamento de sinais biomecânicos em tempo real e offline, de forma
modular, a fim de permitir a expansão e adaptação do sistema a futuras configurações
que difiram daquelas para as que este foi inicialmente projetado.
O sistema a ser desenvolvido deve ser capaz de adquirir os sinais relevantes e
processá-los com os algoritmos necessários, armazenando as informações brutas de
forma sistemática possibilitando a reprodução e reprocessamento posterior dos dados.
1.2 Delimitação
O sistema foi desenvolvido para ser utilizado como uma plataforma modular para a
aquisição de variáveis biomecânicas em contextos de pesquisa e que necessitam de
flexibilidade para a adição de novos sensores e utilização de novos processamentos de
dados.
O escopo do trabalho consiste em:
• Criar um sistema modular de aquisição de sinais, com arquitetura extensível;
• Criar um módulo de aquisição independente integrado ao sistema como
prova de conceito;
• Realizar experimentos teste para validar o funcionamento e adequação do
sistema aos objetivos propostos.
17
1.3 Justificativa
Ambientes de pesquisa possuem por característica o desenvolvimento e utilização de
sistemas dedicados para uma finalidade específica, como um experimento em particular,
por exemplo. Além disso, é comum que diferentes projetos existentes sejam
desenvolvidos em paralelo, ainda que parte dos sistemas tenha finalidades e
funcionalidades comuns.
Esse paralelismo, aliado à customização realizada para cada projeto, muitas vezes
ocasiona a reimplementação de algoritmos e funcionalidades que poderiam ser
aproveitadas através de diferentes projetos. Ademais, o desenvolvimento de sistemas
paralelos promove a fragmentação do conhecimento de como estes foram desenvolvidos
pelos participantes, tornando cada sistema menos capaz de sobreviver à rotatividade de
integrantes de um grupo de pesquisa.
O desenvolvimento de uma plataforma de aquisição modular, projetada para que sua
extensão seja possível, pretende, portanto, aliviar esses problemas, permitindo que o
grupo compartilhe o custo de desenvolvimento ao aproveitar o trabalho realizado
anteriormente e o conhecimento a respeito de um único sistema e suas caraterísticas
particulares.
1.4 Objetivos
O objetivo principal do trabalho é, portanto, o desenvolvimento de um sistema
modular, portátil e autônomo de aquisição que atenda às necessidades descritas
anteriormente, sendo extensível e manutenível. Desta forma, os objetivos específicos
consistem em:
• Desenvolver drivers para os sensores utilizados, preservando e
exemplificando a modularidade do sistema;
• Criar um procedimento de calibração, utilizando os algoritmos relevantes
para cada um dos sensores utilizados;
18
• Criar um módulo de aquisição de sinais independente, explicitando a
modularidade da solução para a adição de novos sensores;
• Integrar os sinais adquiridos e processá-los em tempo real;
• Armazenar os dados adquiridos, permitindo sua reprodução posterior.
1.5 Metodologia
A metodologia adotada para o projeto consiste em utilizar um estudo de caso como
modelo para a definição de necessidades a serem supridas e abordagens a serem
adotadas em relação ao sistema desenvolvido. Este se debruça sobre um sistema de
aquisição de sinais relevantes para a prática de esporte. Neste trabalho foram
considerados apenas: aceleração; velocidade angular; posição e sentido de movimento.
Com o objetivo de produzir um sistema manutenível, foi adotada como
estratégia a utilização prioritária de hardwares e softwares de ampla utilização e que
tornem mais fácil a familiarização de futuros utilizadores com ele. Tendo esta orientação
como fio condutor, o hardware da unidade central de processamento foi construído em
torno de um microcomputador Raspberry Pi 3B (Raspberry Pi Foundation, Reino
Unido), associado a uma placa de circuito impresso que abriga sensores capazes de
medir as grandezas de interesse.
A adoção da Raspberry se deve ao seu excelente suporte a Linux e ampla
popularidade no mercado, facilitando, em grande medida, a obtenção de informações, a
resolução de problemas e utilização de sistemas previamente desenvolvidas para esta
placa e para Linux em geral. A placa de circuito impresso foi desenvolvida para integrar
ao projeto as placas de IMU (Inertial Measurement Unit) comerciais GY-80, GY-9250 e
a placa de GPS (Global Positioning System) GY-GPS6MV2.
A outra unidade de hardware desenvolvida tem por objetivo demonstrar a adição
de um módulo de aquisição independente ao sistema, como forma de validação da sua
capacidade de expansão. Essa unidade foi desenvolvida utilizando o microcontrolador
ESP32, que possui diversas características interessantes como a grande capacidade de
memória RAM e Flash, um módulo Wifi e Bluetooth integrado e pequena dimensão
física, e uma placa analógica que abriga e provê a conexão aos sensores relevantes.
19
O software do sistema foi desenvolvido baseado no Robot Operating System
(ROS). O ROS é um framework para desenvolvimento de aplicações de robótica. A
utilização desta ferramenta tem por objetivo aproveitar as ferramentas, bibliotecas e
infraestrutura desenvolvidas, guiando ao mesmo tempo o sistema desenvolvido para que
este possua melhor padronização e compatibilidade com outras ferramentas.
A funcionalidade final do software do sistema, dentre as funcionalidades
desenvolvidas e já presentes no ROS, é, então, a leitura dos sensores suportados pelo
hardware, a calibração das medidas realizadas pelos sensores, a estimação de orientação
no espaço de um número arbitrário de sensores a partir das leituras de aceleração,
velocidade angular e campo magnético, a estimação de um vetor de estados com 15
variáveis cinéticas, visualização em tempo real da posição do GPS e IMU do sistema
com a Raspberry em 3D e sobre mapa. O sistema suporta ainda a gravação e reprodução
de todos os dados produzidos, permitindo o reprocessamento com novos parâmetros,
além da implementação inicial de um esquema de autodescoberta dos endereços de rede
dos módulos do sistema.
Apesar de o objetivo final ser a utilização em esporte, os testes foram realizados em
ambientes de bancada.
1.6 Descrição
O Capítulo 2 descreve alguns conceitos importantes para o entendimento dos
sistemas desenvolvidos e algoritmos utilizados.
O Capítulo 3 trata dos módulos de hardware que foram utilizados para o
desenvolvimento do projeto.
O Capítulo 4 provê uma visão geral do sistema desenvolvido e como os módulos
interagem entre si e descreve os módulos desenvolvidos no decorrer do projeto
O Capítulo 5 apresenta a avaliação do sistema a partir de alguns experimentos.
O Capítulo 6 discute algumas limitações do sistema e possíveis soluções
O Capítulo 7 conclui o trabalho.
20
2 Conceitos Teóricos
2.1 Robot Operating System
O ROS é um framework para o desenvolvimento de aplicações de robótica, sendo
composto por diversas ferramentas, bibliotecas e convenções [1]. Este framework provê
uma camada estruturada de comunicação sobre os sistemas operacionais de um conjunto
heterogêneo de computação [2]. Cada módulo do conjunto pode ser implementado
sobre diferentes sistemas operacionais, como Linux e Windows, utilizando qualquer
linguagem de programação que ofereça suporte à API do ROS.
O modelo de comunicação adotado por este framework é um modelo ponto a ponto,
em que as diferentes aplicações que compõem o sistema implementado se comunicam
diretamente entre si, sem que as informações trafeguem por uma aplicação central. Há,
no entanto, uma aplicação central responsável por permitir a descoberta mútua dos
processos em tempo de execução [2]. Cada aplicação pode ser executada em um
diferente dispositivo, desde que haja suporte ao ROS.
A especificação do ROS se dá no nível da camada de mensagens, permitindo que o
framework seja utilizado a partir de diferentes linguagens de programação. Uma
linguagem de definição de mensagens foi adotada, associada a geradores de código
automáticos que produzem o código necessário para cada linguagem, permitindo que
novos tipos de mensagens sejam implementados [2].
A arquitetura adotada pelo ROS promove o desenvolvimento de sistemas
distribuídos, compostos de múltiplos programas menores com funções e interfaces bem
definidas. A filosofia é desenvolver módulos que possam ser reutilizados em diferentes
contextos sem que os programas tenham que ser modificados, mas apenas configurados.
Para entender melhor este processo e como o ROS funciona, as próximas seções
apresentam em mais detalhes a sua estrutura e organização funcional além de termos
que serão utilizados ao longo deste texto.
21
2.1.1 Nodes
Um node é um processo capaz de realizar computação, cujo escopo deve ser
granular e contido de forma a preservar a arquitetura distribuída baseada em troca de
mensagens [3].
A redução do escopo destes processos provê vantagens como a redução do impacto
em momentos de falha, redução da complexidade do código e melhor encapsulamento
das funções, permitindo que cada node exponha apenas uma API externa e reduza seu
acoplamento em relação ao restante do sistema [3].
Os nodes se comunicam por mensagens, que são publicadas em tópicos e serviços,
além de serem configurados por parâmetros, por meio do parameter server. Estes são,
ainda, identificados por um nome único, permitindo que um grafo de relações seja
construído entre os diversos nodes [3].
Um node tipicamente funciona como um filtro de mensagens, recebendo mensagens,
realizando alguma espécie de processamento e as republicando. Existem ainda nodes
que apenas recebem mensagens, como os que realizam funções de monitoramento, e
aqueles que apenas publicam, como no caso de leitores de sensor.
2.1.2 Tópicos
Tópicos são a principal forma de troca de mensagens entre nodes, funcionando
como barramentos que podem ser escritos e lidos por múltiplos nodes simultaneamente.
Tópicos possuem nomes únicos que os identificam e permitem que seu escopo seja
descrito [4].
Os nodes interagem com os tópicos a partir de uma relação de publisher, que
publicam as mensagens ou de subscriber, que recebem as mensagens publicadas neste
tópico. Ambas as relações são consideradas anônimas, e cada node não se torna ciente
de que outros nodes estão publicando ou se inscrevendo em um tópico. A anonimidade
ajuda a separar a produção das mensagens de seu consumo, diminuindo
interdependências entre os nodes [4].
22
Como a publicação das mensagens é controlada pelo node que as publica, toda a
comunicação realizada por tópicos é assíncrona, acarretando na necessidade dos nodes
lidarem com o recebimento de mensagens que podem não ter uma consistência temporal
pré-definida.
O transporte das mensagens publicadas nos tópicos se dá por TCP/IP na maioria dos
casos, com UDP/IP sendo utilizado em situações específicas [4].
Tópicos são comumente utilizados para a transferência continua de informação entre
os nodes, como medidas tomadas, sinais processados e status do sistema.
2.1.3 Serviços
Serviços são uma forma de comunicação alternativa aos tópicos em que é definido
um par de mensagens, uma funcionando como requisição e a outra como resposta a essa
requisição. A semântica de requisição/resposta significa que as comunicações são
sempre entre dois nodes e não é possível que vários nodes recebam e respondam à
mesma mensagem em um serviço [5].
Serviços proveem a capacidade dos nodes requisitarem tarefas uns aos outros que
sejam realizados de forma síncrona e cuja requisição é atendida com uma resposta.
Casos de uso para este tipo de comunicação incluem requisições discretas como de
calibração, status, coleta de sensores esporádicos.
2.1.4 Mensagens
Mensagens são a unidade de informação que é trocada em tópicos e serviços. Elas
são compostas por uma estrutura de dados com campos de tipos bem definidos,
suportando arrays de tipos e estruturas aninhadas [6].
Os arquivos de definição de mensagem são convertidos em código fonte pelas
bibliotecas do ROS, sendo então compiladas ou interpretadas em conjunto com o
restante do código fonte [6].
23
2.1.5 Master
O Master é o módulo que provê os serviços de nomeação e registro para os nodes,
estando ciente quais deles são publishers e subscribers de cada tópico e serviço. Desta
forma ele permite que os nodes se encontrem na rede e se comuniquem entre si [7].
Apesar de servir como ponto central para os nodes, nenhum tráfego de mensagens é
roteado por ele, preservando a arquitetura ponto a ponto do ROS [7].
2.1.6 Comunicação serial
2.1.6.1 rosserial
O rosserial é um protocolo que permite serializar mensagens e multiplexar múltiplos
tópicos e serviços através de um dispositivo serial como uma porta serial ou um socket
de rede [8].
Esse protocolo é utilizado para a integração de dispositivos que seriam incapazes de
suportar todos os protocolos necessários para a utilização do ROS diretamente,
permitindo que estes sejam integrados utilizando uma ponte entre eles e o restante do
sistema.
2.1.6.2 rosserial_python
Este node é um host para comunicações utilizando o protocolo rosserial. Ele permite
a conexão de dispositivos como microcontroladores ao restante do ROS servindo de
ponte entre o protocolo serializado e o utilizado no restante do sistema [9].
2.1.6.3 rosserial_client
Esta é uma biblioteca que implementa o protocolo rosserial, sendo utilizada em
microcontroladores para permitir sua utilização como cliente e comunicar com um node
host que realiza a conversão entre o protocolo serializado e o utilizado no restante do
sistema [10].
24
2.1.7 Names
No ROS, todo recurso, seja um node, parâmetro, tópico ou serviço, possui um nome
específico que segue uma estrutura hierárquica para prover encapsulamento dos
recursos de uma parte do sistema em relação a outro. Cada recurso é definido em um
namespace e pode encapsular diversos recursos diferentes que se comunicam. Alguns
exemplos de namespaces são:
• /(namespace global)
• /RowingProject
• /RowingProject/boat
• /RowingProject/boat/imu/data
Cada recurso assume que está no namespace global, e pode ser empurrado para um
namespace mais específico durante a sua invocação. Dessa forma, o mesmo node pode
ser invocado diversas vezes sem que haja conflito na resolução dos nomes, uma vez que
eles estariam presentes em namespaces diferentes [11].
2.1.8 Parâmetros
2.1.8.1 Parameter Server
O parameter server é um dicionário de parâmetros compartilhado entre os nodes,
sendo usado primordialmente como ponto de armazenamento e recuperação de
parâmetros de configuração [12].
Os parâmetros seguem o mesmo tipo de nomenclatura dos tópicos e serviços,
permitindo que parâmetros de mesmo nome sejam armazenados sob namespaces
distintos e não colidam [12].
2.1.9 Bags
O bag é o formato de arquivo utilizado pelo ROS para armazenar mensagens. Estes
25
arquivos podem ser criados a partir da gravação de tópicos, guardando sua informação
de forma serializada. Ademais, o formato permite ainda que as mensagens gravadas
sejam reproduzidas, simulando os envios anteriores do sistema como se estivessem
acontecendo no presente [13].
Todos os experimentos realizados neste trabalho utilizaram o bag como formato de
armazenamento para o processamento posterior.
2.1.10 Transform Library
A Transform Library (TF) é uma biblioteca do ROS que permite produzir um
sistema de coordenadas temporal. Ela permite que uma árvore de sistemas de
coordenadas seja criada e cujos pontos e vetores sejam transformados entre quaisquer
dois sistemas em um momento desejado no tempo [14].
2.1.11 roslaunch
A roslaunch é uma ferramenta que permite controlar a inicialização de múltiplos
nodes ao mesmo tempo, além de permitir a definição de parâmetros no parameter
server [15].
Essa ferramenta permite ainda a definição de namespaces e remapeamento de
tópicos, tornando possível a orquestração do funcionamento de um sistema utilizando
múltiplos nodes sem que scripts customizados sejam utilizados [15].
A configuração é realizada por meio de arquivos XML denominados arquivos
launch. A utilização de arquivos launch para realizar a configuração do sistema permite
que um mesmo conjunto de programas atenda diversos casos de uso, dependendo
apenas dos parâmetros de configuração utilizados e como os nodes e tópicos são
organizados.
2.2 Zeroconf
Como as mensagens são trocadas usando um protocolo TCP/IP, cada dispositivo
26
conectado ao ROS precisa de um endereço apropriado. Isso não é conveniente quando
se deseja um sistema modular, pois os endereços deveriam ser definidos no firmware ou
software dos dispositivos. Uma forma de contornar este problema passa pelo uso do
Zeroconf.
O Zeroconf é um conjunto de tecnologias que objetivam a criação automática de
uma rede de computadores quando os dispositivos estão conectados por uma rede
TCP/IP, e suas principais funcionalidades são a atribuição automática de dispositivos de
endereços de rede, atribuição e resolução de hostnames e registro e localização de
serviços [16].
Esses protocolos permitem que diversos dispositivos em uma rede TCP/IP possam
ser configurados sem a presença de um arbitrador para as diversas configurações
necessárias para a operação desta rede.
2.3 FreeRTOS
Para computadores com sistemas operacionais Linux, como é o caso da Raspberry,
todas as funcionalidades para o uso do ROS estão disponíveis, porém, para sistemas
menores, como microcontroladores, outras alternativas são necessárias.
O FreeRTOS é um sistema operacional embarcado de tempo real que provê métodos
para a criação de tarefas, threads, mutexes, semáforos e timers [17]. Este sistema
implementa um escalonador round-robin, que, de forma conjunta com os métodos
fornecidos, permite a criação de programas embarcados multi-threaded.
2.4 Inertial measurement unit
Os principais sensores de interesse para esse trabalho são o acelerômetro, giroscópio
e magnetômetro, que, em conjunto são conhecidos também como inertial measurement
unit. Estes sensores são comumente utilizados de forma combinada para estimar
variáveis como posição, velocidade e orientação no espaço.
As variáveis de posição e velocidade podem ser estimadas com base na integração
27
dos dados do acelerômetro. No entanto, devido a imprecisões e vieses presentes na
medida, os valores estimados rapidamente divergem da realidade.
De maneira similar, a orientação no espaço pode ser estimada a partir da integração
dos dados provenientes do giroscópio, sofrendo dos mesmos problemas do
acelerômetro, e dos dados do magnetômetro, que poderiam estimar diretamente a
orientação, mas estão sujeitos a interferências ambientais com relativa facilidade.
O procedimento normalmente adotado passa ser, então, a fusão dos dados destes
sensores como forma de realizar uma compensação mútua entre eles. Por exemplo, a
velocidade angular medida pelo giroscópio deve estar relacionada à orientação estimada
pelo magnetômetro por meio de uma operação de derivação no tempo. Quaisquer
discrepâncias indicam que há uma possível fonte de incerteza no sistema, que pode ser
compensada por uma série de algoritmos. As técnicas utilizadas para este fim são
apresentadas nas seções 2.4.2 e 2.4.3.
Os modelos e características dos sensores utilizados neste trabalho podem ser
encontradas na seção 3.2.1.
2.4.1 Calibração
Como quaisquer sensores, os utilizados neste trabalho estão sujeitos a distorções,
interferências e não-linearidades cuja compensação pode trazer grande melhora à
acurácia das medidas [18].
As medidas realizadas por estes sensores costumam apresentar três tipos de erros
sistemáticos: vieses; erros de escala e erros de alinhamento [19].
Os vieses são erros presentes na medida independentes das intensidade dos sinais
medidos e os que podem ser mais facilmente compensados são os offsets [18]. Outros
vieses incluem erros de escala e cross-talk. Erros de escala são erros de sensibilidade da
função entrada real versus saída medida [18]. Erros de cross-talk costumam ser
causados por um alinhamento imperfeito entre o sensor e o eixo que deveria ser medido,
fazendo com que as medidas sejam contaminadas pelos sinais presentes em outros eixos
[18].
28
Para os sensores de aceleração e velocidade angular, as distorções são mais
comumente produzidas por estresses na montagem, variação de temperatura e
envelhecimento [17]. Magnetômetros, no entanto, estão sujeitos a distorções produzidas
por outras fontes como equipamentos elétricos e objetos metálicos [20].
As distorções às quais magnetômetros são sujeitos podem ser classificadas em duas
categorias:
• Hard iron - Distorções presentes com posição fixa em relação ao sensor, em
geral produzidas por outros componentes da placa ou outros equipamentos ao
qual o sensor está afixado [20];
• Soft iron - Distorções presentes com posição fixa no eixo de coordenadas da
Terra. Produzidas por fontes de campo magnético presentes no ambiente [20].
Ambas essas distorções podem ser corrigidas por diferentes métodos, sendo
utilizado, neste trabalho, um algoritmo de ellipsoid fitting, descrito na seção 2.4.1.1
2.4.1.1 Estimação de parâmetros de calibração por ellipsoid fitting
Esse método de estimação de parâmetros de calibração é baseado na aquisição de
múltiplas medidas em diversas posições a fim de estimar os valores de offset, ganho e
alinhamento utilizando o método dos mínimos quadrados [21]. Desta forma, o algoritmo
recebe um conjunto de dados brutos, contaminado pelos vieses descritos anteriormente,
e os compensa para produzir um conjunto de medidas ótimo do ponto de vista do erro
médio quadrático.
No caso geral, a equação cujos parâmetros devem ser estimados é:
𝑎 𝑋2 + 𝑏 𝑌2 + 𝑐 𝑍2 + 𝑑 2𝑋𝑌 + 𝑒 𝑋𝑍 + 𝑓 2𝑌𝑍 + 𝑔 2𝑋 + ℎ 2𝑌 + 𝑖 2𝑍 = 1
Na qual 𝑋, 𝑌 e 𝑍 são vetores [Nx1].
Define-se, então, a matriz D de dimensão [Nx9], onde N é o número de medidas
obtidas:
𝐷 = [𝑋2, 𝑌2, 𝑍2, 2𝑋𝑌, 2𝑋𝑍, 2𝑌𝑍, 2𝑋, 2𝑌, 2𝑍]
E o vetor 𝑣 de dimensão [9x1], representando os parâmetros a serem estimados:
29
𝑣 = [𝑎 𝑏 𝑐 𝑑 𝑒 𝑓 𝑔 ℎ 𝑖]𝑇
A aproximação por mínimos quadrados é calculada então:
𝐷 ∗ 𝑣 = 1⃖
𝐷𝑇 ∗ 𝐷 ∗ 𝑣 = 𝐷𝑇 ∗ 1⃖
𝑣 = (𝐷𝑇 ∗ 𝐷)−1 ∗ (𝐷𝑇 ∗ 1⃖ )
Definindo, então, a matriz auxiliar 𝐴3 e o vetor auxiliar 𝑣𝑔ℎ𝑖:
𝐴3 = [𝑎 𝑑 𝑒𝑑 𝑏 𝑓𝑒 𝑓 𝑐
]
𝑣𝑔ℎ𝑖 = [𝑔 ℎ 𝑖]𝑇
Os offsets podem ser calculados:
𝑜 = [𝑜𝑥 𝑜𝑦 𝑜𝑧] = −𝐴3−1 ∗ 𝑣𝑔ℎ𝑖
Definindo, então, as matrizes auxiliares 𝑇, 𝐴4, 𝐵3 𝑒 𝐵4:
𝑇 = [
1 0 0 00 1 0 00 0 1 0𝑜𝑥 𝑜𝑦 𝑜𝑧 1
]
𝐴4 = [
𝑎 𝑑 𝑒 𝑔𝑑 𝑏 𝑓 ℎ𝑒 𝑓 𝑐 𝑖𝑔 ℎ 𝑖 −1
]
𝐵4 = [
𝑏11 𝑏12 𝑏13 𝑏14
𝑏21 𝑏22 𝑏23 𝑏24
𝑏31 𝑏32 𝑏33 𝑏34
𝑏41 𝑏42 𝑏43 𝑏44
] = 𝑇 ∗ 𝐴4 ∗ 𝑇𝑇
𝐵3 = − [
𝑏11 𝑏12 𝑏13
𝑏21 𝑏22 𝑏23
𝑏31 𝑏32 𝑏33
] 𝑏44⁄
30
Sejam os três autovalores de 𝐵3 denotados por 𝑒𝑥, 𝑒𝑦 e 𝑒𝑧 e os três autovetores por
𝒗𝒙, 𝒗𝒚 e 𝒗𝒛.
Os ganhos dos erros de escala, geometricamente equivalentes aos raios do elipsóide,
podem ser calculados como a raiz quadrada do inverso dos autovalores de 𝐵3.
𝑔𝑥 = √1 𝑒𝑥⁄
𝑔𝑦 = √1 𝑒𝑦⁄
𝑔𝑧 = √1 𝑒𝑧⁄
Os ganhos entre eixos, que corrigem o erro de alinhamento, e são representados por
uma matriz 3x3, podem ser determinados pela justaposição dos autovetores de 𝐵3.
𝑔𝑒𝑛𝑡𝑟𝑒−𝑒𝑖𝑥𝑜𝑠 = [𝒗𝒙 𝒗𝒚 𝒗𝒛]
De posse dos ganhos e offsets calculados, as leituras, denotadas por 𝑙𝑥, 𝑙𝑦 e 𝑙𝑧,
podem ser corrigidas utilizando as seguintes equações:
[𝑑𝑥 𝑑𝑦 𝑑𝑧] = ([𝑙𝑥 𝑙𝑦 𝑙𝑧] − [𝑜𝑥 𝑜𝑦 𝑜𝑧]) ∗ 𝑔𝑒𝑛𝑡𝑟𝑒−𝑒𝑖𝑥𝑜𝑠
[𝑐𝑥 𝑐𝑦 𝑐𝑧] = [𝑑𝑥 𝑑𝑦 𝑑𝑧] [𝑔𝑥 𝑔𝑦 𝑔𝑧]⁄
Onde 𝑐𝑥, 𝑐𝑦 e 𝑐𝑧 representam os valores calibrados.
2.4.2 Filtro de orientação
As medidas do giroscópio proveem os sinais de velocidade angular que podem ser
integrados para obter a orientação relativa ao início do processo de integração [20].
A medida do vetor de aceleração da gravidade no sistema de coordenadas do sensor
permite que a orientação conhecida do vetor de aceleração da gravidade da Terra seja
utilizada para calcular a orientação do sensor relativa a esse vetor. Esse cálculo, no
entanto, não determina completamente a orientação do sensor, uma vez que infinitas
posições no entorno do vetor de aceleração da gravidade são possíveis [20].
31
Da mesma forma, a medida do magnetômetro fornece a medida do vetor de campo
magnético, que pode ser utilizada para calcular a orientação do sensor em relação a esta.
Como campo magnético da Terra não é constante em toda sua superfície, possuindo
uma distorção horizontal, comumente denominada declinação magnética, e uma
distorção vertical, a inclinação magnética, a orientação estimada não é absoluta em
relação à Terra.
Enquanto a declinação magnética não pode ser compensada a não ser por
informação externa, a inclinação magnética é corrigível pela presença da estimação de
orientação do acelerômetro, que provê uma medida adicional de inclinação para o
sistema.
Essas medidas são, então, fundidas utilizando um algoritmo de otimização que
utiliza o método do gradiente para estimar a proporção com que qual medida deve ser
utilizada para estimar a orientação total em um dado instante de tempo [20]. A
estimação de orientação utilizada neste trabalho baseia-se no método desenvolvido por
Sebastian O.H. Madgwick [20], que propôs um algoritmo derivado analiticamente para
calcular a orientação com base nas leituras de acelerômetro, giroscópio e magnetômetro.
Este algoritmo é consideravelmente menos exigente do ponto de vista computacional do
que um filtro de Kalman equivalente (seção 2.4.3), além de exigir uma taxa de
atualização muito mais baixa [20], tornando-o mais adequado para a utilização em
sistemas embarcados e de pouco poder computacional.
O algoritmo está implementado em um node do ROS específico para este fim, como
descrito na seção 4.3.2, sendo utilizando para produzir a estimação de orientação das
IMUs quando esta é a única informação de interesse ou como entrada para o filtro de
Kalman descrito a seguir na seção 2.4.3.
2.4.3 Filtro de Kalman
O filtro de Kalman, criado por Rudolf Kalman em 1960, é um método matemático
utilizado para estimação a partir de medidas ruidosas de sensores, sendo um dos
métodos mais conhecidos e utilizados [22].
Neste trabalho, este filtro é utilizado como forma de realizar a fusão dos sensores
32
presentes na IMU e dos dados de GPS, produzindo uma estimativa mais acurada de
posição, velocidade, aceleração, velocidade angular e orientação.
O filtro implementa um estimador preditor-corretor ótimo em relação à redução da
covariância estimada do erro quando as condições de adequação do modelo à realidade
são atendidas [23].
Apesar de as suas condições ótimas do filtro dificilmente serem atendidas, o filtro
produz resultados satisfatórios, tendo sido usado largamente em áreas como navegação
autônoma e assistida [22].
O filtro utiliza um ciclo de predição e correção em que o estado de um determinado
instante de tempo é predito a partir das equações que descrevem a dinâmica do sistema
e, então, medidas são realizadas e utilizadas como entrada para corrigir a predição
realizada [22].
A presença deste ciclo de predição e correção torna a estimativa do filtro muito mais
próxima do valor real do que outros métodos que utilizam a totalidade dos dados
disponíveis para produzir uma estimativa [22].
Segundo [23] este método tem por objetivo produzir a estimativa o estado 𝑥 ∈ ℜ𝑛
do processo governado pela equação de diferenças:
𝑥𝑘 = 𝐴𝑥𝑘−1 + 𝐵𝑢𝑘−1 + 𝑤𝑘−1
e medida 𝑧 ∈ ℜ𝑚:
𝑧𝑘 = 𝐻𝑥𝑘 + 𝑣𝑘
Onde 𝐴 relaciona o estado 𝑥𝑘−1 com o estado no momento atual 𝑥𝑘 e 𝐵 relaciona a
entrada 𝑢 ∈ ℜ𝑙 ao estado 𝑥. 𝐻 relaciona o estado 𝑥𝑘 a medida 𝑧𝑘.
As variáveis aleatórias 𝑤𝑘 e 𝑣𝑘 representam o ruído branco e gaussiano de
variâncias 𝑄 e 𝑅 do processo e da medida.
Definindo �̂�𝑘− ∈ ℜ𝑛 como a estimativa do erro a priori no passo 𝑘 dado o
conhecimento do estado 𝑥𝑘 no passo 𝑘 e �̂�𝑘 ∈ ℜ𝑛 como a estimativa do estado a
posteriori no passo 𝑘 dada a medida 𝑧𝑘, podem-se definir os erros a priori e a posteriori
33
como:
𝑒𝑘− = 𝑥𝑘 − �̂�𝑘
−
e
𝑒𝑘 = 𝑥𝑘 − �̂�𝑘
A covariância da estimativa do erro a priori é:
𝑃𝑘− = 𝐸[𝑒𝑘
−𝑒𝑘−𝑇]
A covariância da estimativa do erro a posteriori é:
𝑃𝑘 = 𝐸[𝑒𝑘𝑒𝑘𝑇]
A estimação a posteriori do estado, �̂�𝑘, é dada como uma combinação linear da
estimativa a priori do vetor de estado �̂�𝑘−, e a diferença ponderada pela matriz 𝐾 da
medida 𝑧𝑘 e a predição desta medida 𝐻�̂�𝑘−:
�̂�𝑘 = �̂�𝑘− + 𝐾(𝑧𝑘 − 𝐻�̂�𝑘
−)
A diferença (𝑧𝑘 − 𝐻�̂�𝑘−) é denominada inovação e representa a discrepância entre a
medida e a predição desta medida.
A matriz 𝐾 é uma matriz de ganhos que minimiza o erro a posteriori e assume a
forma:
𝐾𝑘 = 𝑃𝑘−𝐻𝑇(𝐻𝑃𝑘
−𝐻𝑇 + 𝑅)−1
As equações para o filtro de Kalman que predizem o vetor de estados no próximo
instante de tempo são então:
�̂�𝑘− = 𝐴𝑥𝑘−1 + 𝐵𝑢𝑘−1
𝑃𝑘− = 𝑃𝑘−1𝐴𝑇 + 𝑄
As equações que corrigem a estimação utilizando as medidas são:
𝐾𝑘 = 𝑃𝑘−𝐻𝑇(𝐻𝑃𝑘
−𝐻𝑇 + 𝑅)−1
34
�̂�𝑘 = �̂�𝑘− + 𝐾𝑘(𝑧𝑘 − 𝐻�̂�𝑘
−)
𝑃𝑘 = (𝐼 − 𝐾𝑘𝐻)𝑃𝑘−
O processo funciona de forma cíclica tal que cada estimativa a posteriori é usada
para produzir uma estimativa a priori cuja correção dará origem a uma nova estimativa
a posteriori.
O filtro descrito aqui assume em sua derivação que o processo estocástico sendo
estimado é determinado por um conjunto de equações lineares. Quando essa limitação
não pode ser atendida, existem adaptações em relação a esta formulação que permitem a
estimação de sistemas não lineares, como o filtro estendido de Kalman, comumente
abreviado como EKF, que lineariza as equações do sistema em torno de sua média como
forma de atender os requisitos de linearidade [23].
Outra extensão do filtro de Kalman é o filtro unscented que, em vez de utilizar
linearizações para propagar o estado, utiliza um conjunto de amostras
deterministicamente escolhidas e as propaga através das equações não-lineares
originais. Os pontos resultantes dessa propagação são, então, utilizados para estimar a
variável de interesse [24].
35
3 Módulos de Hardware
Esta seção descreve os módulos de hardware responsáveis pela aquisição e
processamento de dados no escopo deste trabalho, além dos sensores utilizados.
3.1 Raspberry Pi 3
O desenvolvimento de um sistema baseado em ROS requer a utilização de um
computador que seja suportado por alguma distribuição Linux, de preferência com base
em Debian, cujo suporte ao ROS é mais maduro. Aliado a isso, os requisitos de
autonomia e portabilidade limitam as possíveis escolhas a computadores cujas
dimensões físicas permitam sua utilização em um ambiente embarcado. A capacidade de
comunicação com sensores de diferentes tipos, utilizando protocolos variados é também
um fator importante a ser considerado.
Computadores classificados como single board computers são pequenos
computadores montados em uma única placa de circuito impresso [25]. Dentre os vários
modelos de computadores desta categoria presentes no mercado, optou-se pela
utilização da placa Raspberry Pi 3, por conta do suporte robusto em Linux, a ampla
comunidade que se desenvolveu em seu entorno, inclusive na comunidade do ROS,
suporte a diversos protocolos em seu GPIO, conexão ethernet via cabo RJ-45 e Wi-Fi
[26] e velocidade de processamento.
Mais especificamente, a Raspberry Pi model B consiste em uma placa de circuito
impresso de 86 mm x 56 mm, o tamanho de um cartão de crédito, que integra um SoC
(System-on-a-Chip) Broadcom BCM2837 com quatro núcleos ARM Cortex-A53 de
arquitetura ARMv7 e 1 GB de RAM. Em relação à conectividade, a placa suporta os
protocolos Wi-Fi e Bluetooth, além de ter portas USB, HDMI e um GPIO de 40 pinos.
Esta placa pode ser vista na Figura 1:
36
3.1.1 Shield da Raspberry
O shield tem por objetivo permitir a conexão de sensores diretamente à Raspberry
Pi, tornando-a um módulo capaz de realizar medidas sem outros componentes externos
O shield desenvolvido para a Raspberry Pi, cujo design será descrito na seção 9.1, é
exibido na Figura 2, abrigando as placas de breakout de GY-80 IMU e GY-GPS6MV2
de GPS. A Raspberry está afixada sobre uma bateria portátil, geralmente utilizada para
carregar celulares, que fornece alimentação para o sistema quando outra fonte não está
disponível.
Figura 1: ESP32 Model B.
37
3.2 ESP32
Para exemplificar o caráter modular do sistema, decidiu-se implementar um módulo
independente em relação à unidade central e que fosse responsável por ler os sensores e
transmitir estas leituras por comunicação wireless. Dessa forma, necessitava-se de um
microcontrolador que permitisse a comunicação sem fio, a leitura dos sensores e tivesse
capacidade de suportar a utilização dos protocolos do ROS.
A ESP32 é uma série de microcontroladores SoC, desenvolvidos pela Espressif, com
Wi-Fi e Bluetooth integrados [27]. Ela emprega o microcontrolador Tensilica Xtensa
LX6 e inclui os circuitos necessários para a comunicação wireless como antenas,
amplificadores de potência e recepção, filtros e gerenciamento de energia.
Além de suas características físicas, a série ESP32 possui ainda compatibilidade
com as bibliotecas e ambientes de programação desenvolvidos para Arduino que,
devido a sua popularidade, contribui para o objetivo de tornar o sistema acessível para
desenvolvimentos futuros. Essa compatibilidade facilita ainda a integração com o ROS,
Figura 2: Raspberry Pi com Shield e bateria portátil.
38
uma vez que este possui bibliotecas projetadas para Arduino e que podem ser utilizadas
pela ESP32 com pouca modificação.
As bibliotecas de compatibilidade com Arduino da ESP32 são implementadas sobre
o FreeRTOS, o que permite que a API do Arduino e do FreeRTOS sejam utilizadas de
forma concomitante.
Como a ESP32 consiste apenas em um módulo que deve ser conectado a outros
circuitos de suporte cujo desenvolvimento não estava incluído no escopo deste projeto,
optou-se pela utilização de uma placa Breakout comercial, a DOIT ESP32-DEVKIT. A
placa Breakout e o módulo SoC serão denominados ESP32 de forma intercambiável no
contexto deste trabalho. Esta placa breakout é ilustrada pela Figura 3:
3.2.1 Shield da ESP32
De forma similar ao shield desenvolvido para a Raspberry Pi, uma outra placa foi
projetada para abrigar os sensores utilizados em conjunto com a ESP32 (Figura 4). Essa
placa suporta os módulos GY-80, GY-9250 e GY-273.
Os dois fios estão conectando os pinos do barramento I2C da ESP32 aos pinos do
shield, devido a um erro de montagem que impediu o barramento de funcionar. Espera-
se que novas placas montadas não apresentem esta característica.
Figura 3 Breakout comercial para ESP32, modelo DOIT ESP32-DEVKIT.
39
3.3 Sensores
A estimação de estado que se pretende realizar é baseada na leitura de sensores de
aceleração, velocidade angular, campo magnético e posição. A escolha desses sensores
baseou-se primordialmente em sua disponibilidade no mercado, com menor importância
dada à sua performance.
A adoção deste critério justifica-se pelo fato de o foco do trabalho ser o
desenvolvimento de um sistema que possa ser utilizado para diversos fins, com
diferentes requisitos de performance, custo e outras características físicas, e não a
demonstração de que o sistema produzido é adequado a um uso específico com seus
próprios requisitos.
Os sensores escolhidos são, portanto, exemplos de sensores encontrados em
dispositivos fabricados em larga-escala, como celulares, vídeo games e afins, e não
sensores utilizados em aplicações mais sensíveis à qualidade dos dados, como
equipamentos científicos e militares.
Figura 4: ESP32 com Shield.
40
Ademais, a utilização dos sensores foi realizada por meio da utilização de placas de
breakout, que expõem os pinos mais importantes dos sensores que abrigam na forma de
pinos compatíveis com protoboards, utilizando o padrão DIP. Essas placas facilitam a
utilização dos sensores, evitando a necessidade de prover os circuitos de alimentação e
outros componentes passivos que os sensores possam necessitar. Elas são, no entanto,
maiores e impedem uma maior customização da forma com que estes sensores são
utilizados.
3.3.1 GY-80
A GY-80 (Figura 5) é uma placa breakout que abriga 4 sensores: um acelerômetro,
um giroscópio, um magnetômetro e um barômetro (descritos nas próximas seções). Ela
pode ser alimentada com uma tensão de 5 V ou 3,3 V, dependendo do pino que é
utilizado. A utilização do pino de 5 V toma proveito do circuito de regulação de tensão
presente nesta placa, enquanto o pino de 3,3 V alimenta os sensores diretamente.
3.3.1.1 ADXL345
O ADXL345 [28] é um acelerômetro de 3 eixos fabricado pela Analog Devices com
faixa de operação selecionável em ±2, ±4, ±8 ou ±16 g1, resolução máxima de 13 bits,
taxa de amostragem de até 3,2 kHz e offset típico entre 35 e 40 mg1.
1 A unidade g se refere ao valor da aceleração da gravidade.
Figura 5 GY-80.
41
3.3.1.2 L3G4200D
Este giroscópio produzido pela STMicroelectronics é indicado quando peso e
tamanho são críticos [29]. Suas principais características são sua faixa de operação
selecionável entre ±250, ±500 ou ±2000 graus/s, resolução de 16 bits para todas as
faixas dinâmicas, taxa de amostragem configurável de 100, 200, 400 ou 800 Hz e offset
típico de 15 a 75 graus/s, dependendo da faixa dinâmica
3.3.1.3 HMC5883L
O magnetômetro HMC5883L, fabricado pela Honeywell, é capaz de realizar
medidas que possibilitam a determinação da orientação absoluta com precisão de 2º
[30]. Suas principais características são uma faixa de operação configurável entre ±0,88
a ±8 Gauss, resolução de 12 bits em todas as faixas dinâmicas e taxa de amostragem de
até 160 Hz.
3.3.2 GY-9250
A placa breakout GY-9250 (Figura 6) abriga o circuito integrado MPU9250 e os
circuitos auxiliares de alimentação e componentes passivos necessários ao seu
funcionamento.
Figura 6: GY-9250.
42
3.3.2.1 MPU9250
A MPU9250 é um módulo multichip que integra dois dies em um único
encapsulamento desenvolvido pela InvenSense. O acelerômetro e giroscópio são
integrados em um mesmo die, que é o mesmo utilizado no sensor MPU6500. Já o
magnetômetro AK8693 é montado no outro die, pela Asahi Kasei Microdevices
Corporation [31].
3.3.2.1.1 MPU6500
Este sensor integra tanto o acelerômetro quanto o giroscópio em um mesmo chip.
Suas cujas principais características são [31] um acelerômetro com faixa dinâmica de
±2, ±4, ±8 ou ±16 g e um giroscópio com faixa dinâmica de 250, 500, 1000 ou 2000
graus/s, taxa de amostragem de até 4 kHz para o acelerômetro e 8 kHz para o giroscópio
e offset típico de ±80 mg para o acelerômetro e ±5 graus/s para o giroscópio.
3.3.2.1.2 AK8693
As principais características do magnetômetro incluso na MPU9250 são [32] uma
faixa dinâmica de ±4800 µT, resolução de 14 bits e período mínimo de amostragem de
9 ms.
3.3.3 GY-273
A placa breakout GY-273 (Figura 7), facilita o acesso ao sensor HMC5883L, que já
foi descrito na seção 3.3.1.3.
Figura 7: GY-273.
43
3.3.4 GY-GPS6MV2
A placa breakout GY-GPS6MV2 abriga o módulo GPS u-blox NEO-6M, expondo
sua interface serial e alimentação pelos 4 pinos padrão DIP, como pode ser visto na
Figura 8. A placa é ainda acompanhada de uma antena.
3.3.4.1 NEO-6M
O NEO-6M é um receptor GPS desenvolvido pela u-blox capaz de fornecer medidas
de posição com uma frequência de até 5 Hz, um tempo de cold-start de 27 segundos e
hot-start de 1 s, uma acurácia de posição de 2,5 m e acurácia de velocidade de 0,1 m/s.
Figura 8: GY-GPS6MV2.
44
4 Panorama do sistema
Um sistema de aquisição foi construído como prova de conceito para uma
plataforma modular de aquisição utilizando múltiplos sensores. Nesta seção, serão
descritos a organização física, como os módulos se relacionam, os fluxos de sinais e os
casos de uso suportados pelo sistema.
No caso geral, a estrutura pensada para um sistema genérico de aquisição consiste
num computador central, que executa o Master do ROS, sendo o ponto de orquestração
das atividades. A conexão entre computadores utilizando ROS se dá pelo protocolo TCP,
de forma que este computador central e os demais precisam estar presentes em uma
mesma rede para que possam se comunicar. Alternativamente, módulos menores podem
utilizar o protocolo rosserial que permite a comunicação em ambientes mais limitados
como microcontroladores. No entanto, esses módulos dependem da existência de uma
ponte que realize a tradução entre o protocolo rosserial e o utilizado pelo restante dos
módulos.
O sistema fica organizado então em módulos físicos com diferentes funcionalidades
de forma a suprir as necessidades de um projeto específico, sendo o módulo central o
único que necessariamente existe em qualquer possível implementação.
O módulo central e outros módulos periféricos capazes de executar o ROS ficam
responsáveis pelo processamento e visualização dos dados, sendo a distribuição de
tarefas arbitrária e configurada da forma que for mais conveniente para o projeto
específico por meio de arquivos launch.
Módulos que não são capazes de rodar o ROS e se comunicam com o restante do
sistema por meio do protocolo rosserial, são primariamente responsáveis pela aquisição
de dados, uma vez que são incapazes de rodar programas arbitrários sem terem seu
firmware reprogramado.
Um exemplo de configuração possível para este sistema é ilustrado na Figura 9:
45
4.1 Caso de uso
O sistema desenvolvido simula a utilização em um veículo, com sensores para a
aquisição de medidas referentes ao veículo como um todo, e outros para algum
elemento cuja posição relativa ao veículo seja fixa, mas não sua orientação, como o
volante de um carro, o remo de um barco, ou o guidom ou pé de vela de uma bicicleta.
Para deixar ainda mais específico, será adotado o caso de um barco a remo, com a
unidade central (Raspebrry Pi) sobre o barco e um módulo wireless, utilizando a ESP32,
posicionado em um dos remos. A estrutura de hardware está ilustrada na Figura 10.
A unidade central consiste na Raspberry Pi associada ao shield desenvolvida para
ela, abriga os sensores IMU e GPS. Este módulo é responsável pela aquisição das
informações relativas ao veículo, estando hipoteticamente afixada a este. As medidas de
interesse obtidas pela unidade central são: aceleração, velocidade angular e campo
magnético nos três eixos e posição absoluta. Utilizando estas medidas, a posição,
velocidade, aceleração, orientação e velocidade angular são estimados. A Raspberry Pi é
responsável ainda por executar o ROS Master e orquestrar os demais módulos, e
executar todos os filtros de calibração e estimação necessários ao funcionamento do
Figura 9: Possível configuração do sistema.
Figura 10: Configuração da prova de conceito.
46
sistema, uma vez que é o único módulo capaz de rodar nodes na configuração atual.
O módulo wireless é implementado pela ESP32 e seu shield, utilizando uma unidade
IMU para adquirir os sinais relativos à movimentação do elemento móvel. Os dados
coletados são aceleração, velocidade angular e campo magnético nos três eixos. Estas
informações são utilizadas para calcular a orientação do elemento. Este módulo
transmite seus dados para o módulo central via Wi-Fi, utilizando o protocolo rosserial.
4.1.1 Fluxo de sinais
Como mencionado, o projeto busca a posição, velocidade, aceleração, orientação e
velocidade angular, além da orientação absoluta do elemento móvel. Para realizar essa
estimação, um fluxo de informações partindo da coleta dos dados até a estimação dos
sinais de interesse foi desenvolvido.
Há dois fluxos paralelos, mas bastante similares: o do veículo e o do elemento
móvel. O fluxo do veículo é composto pela aquisição dos sinais, sua calibração
(remoção de vieses), estimação de orientação e estimação do vetor de estado completo.
Essa sequência é ilustrada pela Figura 11.
Figura 11: Fluxo de sinais para veículo (a esquerda) e para o elemento móvel (a
direita).
47
O fluxo responsável pela estimação do elemento móvel é basicamente o mesmo,
com exceção que o vetor completo não é estimado ao final. Este fluxo é exibido na
Figura 11.
4.1.2 Estrutura de nodes e tópicos
No caso específico deste projeto os nodes e tópicos utilizados até a estimação estão
ilustrados na Figura 12. Cada retângulo representa um node e as setas os tópicos que os
ligam, ilustrando como a topologia apresentada na Figura 11 foi implementada nesse
projeto.
4.2 Aquisição de sinais
A leitura dos sensores, incluindo a configuração de registradores, a adequação a
Figura 12: Fluxo das mensagens do sistema para veículo (a esquerda) e para o
elemento móvel (a direita).
48
unidades de medida padrão e permitir a configuração dos sensores a partir dos métodos
de mais alto-nível disponibilizados pelo ROS, como arquivos launch e o parameter
server, é realizado por dois módulos. O primeiro é responsável pela leitura dos sensores
presentes na Raspberry Pi (imu_reader), enquanto o segundo constitui o firmware
implementado na ESP32 (imu_node), cuja principal função é ler e comunicar os dados
dos sensores.
4.2.1 imu_reader
O imu_reader é um pacote ROS, desenvolvido em Python no contexto deste
trabalho, responsável pela leitura dos sensores ligados à Raspberry Pi. Além da leitura,
este é responsável pela conformação dos dados lidos às convenções do ROS, como
descrito pelo REP 145 [33]. Este módulo procura abstrair as diferenças entre diferentes
IMU, expondo uma interface comum para o restante do sistema.
Internamente, há uma estrutura em que a classe base de cada tipo de sensor expõe a
interface interna comum, com classes derivadas sendo responsáveis pelo tratamento das
especificidades de cada sensor. O diagrama da Figura 13 abaixo ilustra essa estrutura:
Figura 13: Estrutura de classes do imu_reader.
49
Atualmente, os sensores são suportados apenas através do protocolo I2C, utilizando
a biblioteca smbus do Python. Os sensores suportados pelo pacote são: ADXL345,
L3G4200D, HMC5883L e MPU6050/MPU6500.
4.2.2 imu_node
Este módulo destina-se a ser executado na ESP32 utilizando o shield desenvolvido
para conectar um sensor IMU a ela. O módulo se comunica por Wi-Fi com um node
rosserial por um canal TCP.
No entanto, a necessidade de coordenar as operações de leitura do sensor,
configuração das mensagens do ROS e comunicação com Wi-Fi tornou-se complexa o
suficiente para necessitar de estruturas de controle como tasks e filas.
A biblioteca rosserial_client foi utilizada para realizar a comunicação com o node
rosserial_python. O endereço IP deste último node é encontrado utilizando o protocolo
zeroconf, evitando que o programa tenha que ser modificado apenas para a mudança de
um IP.
Como a das mensagens não é tão consistente quanto uma comunicação por meio
físico está sujeita a uma maior variabilidade no tempo de transmissão. Esta
inconsistência causa perdas de leituras do sensor quando a comunicação Wi-Fi demora
mais que o período de amostragem, diminuindo a qualidade da estimação realizada
posteriormente.
Por conta disso, o módulo foi desenvolvido para que a leitura dos sensores e a
comunicação com o ROS aconteçam em tasks separadas cuja execução é controlada
pelo escalonador do FreeRTOS. Ao mesmo tempo, sua execução é confinada ao núcleo
zero da ESP32, enquanto o stack de comunicação Wi-Fi é executado exclusivamente no
núcleo um. Dessa forma, a execução e processamento dos protocolos ligados à
comunicação Wi-Fi não interfere com a leitura dos sensores e preparação das
mensagens. Outra preocupação tomada foi a obtenção da timestamp da leitura pela task
de leitura dos sensores, evitando que algum atraso eventual distorça o tempo de leitura
real da mensagem. Os valores de timestamp enviados na mensagem são utilizados para
o cálculo do período de integração dos filtros posteriores.
50
O fluxo de funcionamento do sistema é ilustrado pelo diagrama de sequência da
Figura 14 a seguir:
Após a criação das duas tasks, estas realizam a leitura dos sensores e publicação das
mensagens. Os diagramas da Figura 15 e Figura 16 ilustram seu funcionamento:
Figura 14: Diagrama de sequência do imu_node.
51
Figura 15: Diagrama de sequência da task readSensors.
52
Figura 16: Diagrama de sequência da task publishData.
53
4.3 Calibração
Os dados lidos pelas unidades IMU da unidade central e do módulo periférico
precisam ser calibrados antes de serem utilizados para calcular sua orientação. Esta
tarefa foi designada a um node específico para este fim, o imu_calibrator_node,
descrito na seção 4.3.2. Este node é responsável pela calibração das mensagens, e um
procedimento de calibração para cada tipo de sensor foi desenvolvido.
Este node utiliza uma topologia de filtro, recebendo as mensagens como lidas do
sensor e realizando a calibração, como ilustrado pela Figura 17.
A operação de calibração é iniciada pela utilização de um serviço fornecido pelo
node imu_calibrator_node que o informa que um determinado sensor deve ter os
parâmetros de calibração estimados. Ao enviar a requisição de serviço, o processo de
calibração deve ser realizado como descrito na seção seguinte.
4.3.1 Procedimentos de calibração
Os dados lidos são filtrados por este node para compensar as distorções presentes
nas leituras dos sensores, sendo só então utilizadas para estimar a orientação da IMU. O
procedimento de calibração utilizado é descrito a seguir para cada tipo de sensor:
• Giroscópio
O procedimento de calibração para este sensor é o mais simples dos três,
Figura 17: Processo de calibração.
54
uma vez que este visa compensar apenas o offset presente nas leituras. O
giroscópio deve ser mantido estático durante o processo de calibração para
que os offsets sejam calculados corretamente.
Um script chamado servicetester é utilizado para requisitar a calibração do
giroscópio por um número determinado de amostras. Ao receber a
requisição, o imu_calibrator_node emite as mensagens de log informando do
início e término do processo de calibração:
• Magnetômetro
O magnetômetro é calibrado utilizando o método de ellipsoid fitting,
exigindo que o sensor seja rotacionado em todas as direções, de forma a
produzir uma nuvem de pontos que possibilite uma calibração satisfatória.
O processo de calibração compensa offsets, distorções de escala e
alinhamento, incluindo distorções de soft-iron e hard-iron. Por conta da
susceptibilidade a distorções externas apresentadas pelo magnetômetro, é
ideal que a calibração seja realizada na presença das mesmas interferências
externas a que o sensor estará sujeito durante sua operação habitual.
A requisição é realizada pelo servicetester, e o node imu_calibrator_node
registra a requisição nos logs.
• Acelerômetro
O acelerômetro é também calibrado utilizando a técnica de ellipsoid fitting e
uma nuvem de pontos que represente o elipsoide deve ser produzida. No
entanto, devido ao fato de que a movimentação do sensor interfere com as
medidas, o procedimento e o algoritmo de calibração precisam ser
adaptados.
Para este sensor, o procedimento a ser realizado é uma adaptação do six-
point tumble calibration, que é uma técnica em que o sensor é
[INFO] [1548604614.847508]: Receiving calibration request for gyroscope with method default [INFO] [1548604650.884196]: {'method': 'offsets', 'offsets': array([ 0.01116342, -0.017669 , 0.00069877])}
55
cuidadosamente posicionado em seis posições diferentes, todas com algum
dos três eixos perfeitamente alinhados com o vetor de aceleração da
gravidade [34].
A exigência de alinhamento perfeito desta técnica impede que ela seja
realizada sem uma infraestrutura adequada, impedindo que seja utilizada
durante um experimento de campo.
O procedimento consiste então em rotacionar o sensor de forma que ele
esteja aproximadamente alinhado com o vetor de aceleração da gravidade e
mantê-lo nessa posição por alguns segundos. Após estes segundos, o sensor
deve ser rapidamente rotacionado para as próximas posições até que todas
elas tenham sido utilizadas.
A utilização de todas as orientações do six-point tumble calibration permite
que o elipsoide seja encaixado sem ambiguidade e a calibração realizada
com sucesso.
A rotação entre cada posição deve ser suficientemente rápida para que o
filtro que descarta as medidas baseado na velocidade angular, descrito
anteriormente, possa discernir entre as amostras válidas e inválidas.
4.3.2 imu_calibrator_node
O node implementado no contexto deste projeto para cumprir o papel de estimar os
parâmetros de calibração e aplica-los às mensagens provenientes dos nodes
responsáveis por ler as IMUs foi denominado imu_calibrator_node
O imu_calibrator_node age como um filtro para mensagens dos tipos IMU e
MagneticField, ouvindo um tópico de mensagens não calibradas e as republicando em
outro tópico após a calibração, como ilustrado na Figura 18:
56
Desassociar os processos de leitura dos sensores e sua calibração traz vantagens
como reaproveitamento, diminuindo o esforço de implementar novos leitores de
sensores, e a possibilidade de utilizar técnicas de calibração mais computacionalmente
intensas ao permitir que este node seja executado em um computador diferente do
responsável pela aquisição dos dados. Outra vantagem é a reunião de todos os tipos de
dados em um mesmo programa, permitindo usar os dados de vários sensores
simultaneamente para realizar a calibração. Possíveis desvantagens são o aumento do
consumo de memória e a necessidade de coordenar mais nodes para realizar a mesma
função.
Este node funciona internamente agindo sobre três filas: uma fila de mensagens não
calibradas (fila de entrada), uma de mensagens calibradas (fila de saída) e uma de
mensagens que serão utilizadas para calcular a calibração. A fila de entrada está sempre
sendo preenchida pelas mensagens recebidas no tópico de entrada e consumida ao ter
suas mensagens recolhidas e calibradas. Após a calibração ser efetuada sobre uma
mensagem específica, ela é publicada pelo publisher da classe.
A terceira fila só é utilizada quando o serviço disponibilizado pelo node recebe uma
requisição de calibração. A partir deste momento, esta fila passa a receber as mesmas
mensagens que a fila de entrada, até atingir o número de mensagens especificado no
serviço. Quando a fila atinge o tamanho necessário, essas mensagens são utilizadas para
calcular os valores de calibração que serão utilizados para calibrar as mensagens
futuras.
O comportamento do fluxo de mensagens é ilustrado pela Figura 19:
Figura 18: Interface do imu_calibrator_node.
57
Os três tipos de sensores suportados pelo imu_reader podem ser calibrados pelo
imu_calibrator, utilizando diferentes técnicas, como descrito na seção 4.3.1.
4.3.3 servicetester
Este node é apenas um pequeno script que realiza uma requisição de calibração para
o node imu_calibrator_node. Ele não suporta nenhum parâmetro de configuração, e
qualquer mudança deve ser realizada diretamente em seu código-fonte, uma vez que é
uma ferramenta de desenvolvimento.
Figura 19: Fluxo das mensagens no imu_calibrator.
58
4.4 Estimação de orientação
Após serem calibradas, as mensagens provenientes do imu_calibrator_node são
enviadas para o node imu_filter_madgwick, disponível no pacote imu_tools, que realiza
a estimação de orientação.
Este node publica mensagens que contêm a informação de orientação e mensagens
para a biblioteca TF para registrar a posição e orientação do eixo de coordenadas
estimado em relação aos demais utilizados pelo sistema. A taxa da estimação realizada é
configurável por um parâmetro, sendo dissociada da taxa das mensagens recebidas.
Quando os dados coletados incluem a informação de campo magnético, a orientação
estimada é relativa à Terra. Quando apenas giroscópio e acelerômetro são utilizados, a
estimativa é alinhada utilizando o campo gravitacional, mas a orientação no entorno
deste vetor é arbitrária, como descrito na seção 2.4.2.
O pacote imu_tools do ROS disponibiliza o node imu_filter_madgwick, que estima a
orientação de um dispositivo IMU a partir de suas leituras de aceleração, velocidade
angular e, opcionalmente, campo magnético [35].
4.4.1 Sistemas de coordenadas
A biblioteca TF é utilizada para acompanhar e determinar as relações entre os
diversos sistemas de coordenadas utilizados.
O projeto busca utilizar as convenções estabelecidas pelo documento REP (ROS
Enchancement Proposal) 105, que propõe a utilização de alguns sistemas de
coordenadas com nomes e funções pré-definidas, assim como a suas relações [36].
Esses sistemas de coordenadas são definidos de acordo com o projeto sendo
implementado, uma vez que a configuração física dificilmente se mantém. As relações
são definidas por meio de arquivos launch e pelas mensagens publicadas pelos nodes.
59
O sistema de coordenadas definido neste trabalho está ilustrado na Figura 20.
Neste diagrama, os eixos de coordenadas são representados pelos retângulos, com a
relação hierárquica entre eles descrita pelas setas. Cada sistema de coordenadas definido
na implementação deste trabalho está descrito a seguir:
• base_link
Este sistema de coordenadas é rigidamente ligado à base do objeto que está
sendo acompanhado. Representa a Raspberry Pi e o veículo.
• map
O map é um sistema fixo em relação ao mundo, representando a posição do
objeto em relação a este. Este sistema de coordenadas não provê nenhuma
garantia em relação à continuidade, de forma que a posição do objeto pode
sofrer saltos instantâneos.
• odom
Figura 20: Sistemas de coordenadas TF.
60
Este sistema de coordenadas também é fixo em relação ao mundo, sendo, no
entanto, contínuo. A posição do objeto segundo este sistema de coordenadas
nunca possui descontinuidades.
• right_row_fulcrum
Representa, a posição do fulcro sobre o qual um remo está apoiado em um
barco. Está relacionado ao base_link por uma transformação fixa, uma vez
que é um apoio afixado ao barco.
• right_row_imu
Representa a posição de um remo em relação a posição do seu barco. Sua
posição sempre coincide com right_row_fulcrum, apenas rotacionando em
torno deste eixo, assumindo que o remo está apoiado sobre o ponto
específico do barco que é representado pelo right_row_fulcrum.
4.4.1.1 imu_tf_differential
A biblioteca TF do ROS permite a criação de uma árvore de sistemas de
coordenadas em que cada um destes sistemas é referenciado em relação ao anterior
através de uma translação e rotação [10].
A convenção do ROS, codificada pela REP 145, informa que a orientação reportada
pelas mensagens do tipo Imu deve ser em relação ao sistema de coordenadas absoluto,
uma vez que essa é a orientação naturalmente produzida ao utilizar-se um
magnetômetro como bússola [16]. Ao mesmo tempo, os dados de aceleração e
velocidade angular são dados em relação ao sistema de coordenadas ao qual o sensor
está afixado.
Essas duas convenções são conflitantes no caso em que uma IMU tenha que ser
referenciada em um sistema de coordenadas diferente do absoluto, uma vez que a
orientação da mensagem não será dada em relação a este sistema.
Para solucionar essa limitação, o node imu_tf_differential é responsável por
converter a orientação absoluta reportada pela IMU em uma orientação relativa ao seu
sistema de coordenadas local. Para tanto, esse node se utiliza da biblioteca TF para
aferir a rotação entre o sistema de coordenadas absoluto e o local da IMU e da
61
orientação reportada pelo sensor para calcular a rotação relativa entre o sistema local e a
IMU. Após o cálculo, a mensagem Imu é republicada com a nova orientação relativa.
O node é implementado a partir de uma classe que possui um subscriber para um
tópico de mensagens do tipo Imu, realizando as operações necessárias todas as vezes
que uma nova mensagem é recebida. O resultado dessas mensagens é publicado em um
novo tópico do tipo Imu e a biblioteca TF é utilizada para registrar a nova orientação do
sistema de coordenadas da IMU.
4.5 Estimação do vetor de estado completo
A estimação de estado é atualmente calculada pelos nodes fornecidos pelo pacote
robot_localization, utilizando dois nodes do tipo ekf_localization_node e um do tipo
navsat_transform_node. O estado é estimado apenas para a posição do veículo. A
Figura 21 ilustra o fluxo completo de mensagens, da leitura à estimação de estado,
mostrando a relação entre cada um dos nodes. Entre cada par de nodes, a seta simboliza
o tópico pelo qual a comunicação é realizada, explicitando qual tipo de informação
trafega entre eles.
Todos os três nodes do pacote robot_localization publicam o resultado por meio de
mensagens do tipo odometry, que abarca todo o vetor de estado e as respectivas
covariâncias. Na Figura 21, essas mensagens são representadas acompanhadas da
informação que representam.
A primeira instância do ekf_localization_node (ekf_se_odom) realiza a estimação
baseada apenas nos dados da IMU, sem nenhuma correção externa, também
denominado dead_reckoning, de forma que a estimativa naturalmente diverge por
acúmulo de erros durante a integração dos dados de acelerômetro e giroscópio. Apesar
de não estar sendo utilizado, a presença deste node representa a possibilidade de realizar
estimação sem correção externa, caso novos sensores, como de velocidade, fossem
adicionados ao sistema. Esse node é responsável por publicar a transformação entre
odom e base_link utilizando a biblioteca TF, descrita na seção 2.1.10, representando o
deslocamento do barco sem considerar a correção do GPS.
A segunda instância, ekf_se_map, realiza a estimação baseada não apenas nos dados
62
da IMU, mas também na correção de posição recebida pelo GPS. A estimação de estado
produzida por este node possui saltos descontínuos, mas é constantemente corrigida
pela informação do GPS, de forma que a estimação pode ser corrigida e não diverge da
posição verdadeira. A sua saída representa o vetor de estados estimado do veículo em
relação ao eixo de coordenadas map.
O node navsat_transform_node é responsável por converter os dados de GPS, que
são informados por latitude e longitude, na posição relativa ao frame map,
possibilitando a fusão dos seus dados ao demais. A sua saída representa a mensagem do
GPS convertida de um eixo de coordenadas universal para o eixo de coordenadas
utilizado pelo sistema, nesse caso o map.
O node gps_serial é responsável por ler as mensagens NMEA enviadas pelo
barramento serial do GPS e publicar a informação com uma mensagem do tipo gps_fix
do ROS.
63
Figura 21: Fluxo lógico de mensagens.
64
5 Avaliação do sistema
5.1 Calibração de sensores
Para testar o node imu_calibrator_node em relação à sua capacidade de realizar a
calibração dos dados corretamente, dois tipos de teste foram realizados: com dados
simulados e leituras reais dos sensores.
As medidas dos sensores são representadas por meio de uma nuvem de pontos em
que cada ponto é uma medida com valores nos 3 eixos. Quando desenhados em um
espaço tridimensional, os pontos coletivamente representam todas as medidas tomadas
pelo sensor, com os respectivos erros e distorções incluídas.
As métricas utilizadas para a avaliação do desempenho são o desvio padrão do raio,
como forma de determinar o quão esférica a nuvem de pontos é e o centro da nuvem de
pontos, para avaliar a correção de offset. No caso dos dados simulados, onde se conhece
o dado livre de distorção e podemos comparar o resultado antes e depois da calibração,
o somatório do quadrado das diferenças dos pontos antes e depois da utilização do
algoritmo é calculada para avaliar o desempenho da solução como um todo.
5.1.1 Dados simulados
5.1.1.1 Nuvens de pontos
A utilização de dados simulados permite que a distorção aplicada à nuvem de pontos
seja conhecida a priori, de forma que o funcionamento da calibração pode ser avaliado
de forma direta comparando os dados originais e calibrados.
Esse teste utiliza 4 nuvens de pontos para avaliar o desempenho da solução:
• Os dados limpos simulados, usados como ground-truth;
• O dado cru simulado, representando as medidas do sensor com as distorções a
serem corrigidas;
65
• Os dados após a calibração realizada pelo algoritmo;
• Os dados após a calibração e alinhados aos dados limpos.
Os dados limpos são produzidos utilizando coordenadas esféricas em que os dois
ângulos, theta e phi, e o raio são criados como variáveis aleatórias. Os ângulos são
produzidos seguindo uma distribuição uniforme entre 0 e 2π. O raio segue uma
distribuição normal de média um e desvio padrão controlável, representando o ruído da
medição.
Os dados crus são produzidos a partir dos dados limpos, adicionando a eles um
offset e ganhos em cada um dos eixos e uma rotação arbitrária.
Esses dados então são utilizados como entrada para o algoritmo de calibração que
estima o offset e a distorção em cada um dos eixos. Como o algoritmo não possui uma
fonte de informação que o permita determinar a direção absoluta da nuvem de pontos
original a nuvem crua é corrigida, mas sua orientação permanece distorcida em relação
aos dados limpos.
Como esses dados são simulados e a distorção da orientação é conhecida, pode-se
corrigir os dados calibrados de forma que eles estejam alinhados aos dados limpos e
calcular a qualidade das estimativas produzidas pelo algoritmo.
5.1.1.2 Teste de calibração
Os testes simulados são realizados alterando as configurações de offset, ganhos e
rotação simuladas e executando o script novamente. Cada execução produz as
estatísticas de antes e após a execução do algoritmo de calibração, e exibe as nuvens de
pontos.
Os parâmetros da simulação encontram-se na Tabela 1 abaixo:
66
Ruído
(desvio padrão)
Offset (x/y/z) Ganhos (x/y/z) Rotação (x/y/z)
0,05 1/-1/1 1/0,5/2 -π/(π/6)/(π/20)
A nuvem de pontos simulada possui apenas 40 pontos, o que corresponderia a uma
aquisição de décimos de segundos a alguns segundos, dependendo da frequência de
amostragem do sensor. Esse número foi escolhido de forma a não utilizar uma nuvem de
pontos muito mais densa do que seria obtido em campo, o que melhoraria a
performance do algoritmo.
Os parâmetros estimados pelo algoritmo estão listados na Tabela 2:
Desvio
padrão
Offset (x/y/z) Ganhos (x/y/z) Erro quadrático médio
(x/y/z)
0,04853 1,016/-1,007/0,989 1/0,494/2,027 0,021/0,072/0,015
As nuvens de pontos utilizadas nesta estimativa podem ser vistas na Figura 22:
Tabela 1: Parâmetros da simulação.
Tabela 2: Parâmetros de calibração estimados.
67
5.1.2 Dados reais
O teste com dados reais foi utilizado com as medidas dos magnetômetros presentes
na ESP32 (Figura 4).
O protocolo realizado para a coleta dos dados foi realizado conforme descrito
anteriormente, sobre bancada livre de outros objetos capazes de produzir interferência
eletromagnética sobre ela.
Figura 22: Nuvens de pontos utilizadas na estimativa.
68
A nuvem de pontos coletada possui claro deslocamento nos eixos X e Y, e pouca
distorção nos eixos, de forma que praticamente todas as medidas estão no mesmo
quadrante. Após a calibração realizada pelo método do ellipsoid fitting, a nuvem passa a
estar centrada em relação à origem dos eixos de coordenada, tendo a pequena distorção
em seus eixos corrigida.
Os parâmetros estimados para esta correção estão listados na Tabela 3:
X Y Z
Offset 7,698 7,698 0,147
Ganho 23,731 29,504 27,122
A calibração exibida aqui foi utilizada para os demais experimentos.
5.1.3 Análise
O sistema implementado de calibração permite que a calibração seja realizada de
forma conveniente, sem o auxílio de outros equipamentos.
Figura 23: Nuvens de pontos antes e depois da calibração.
Tabela 3: Parâmetros de calibração estimados.
69
No entanto, para a utilização deste protocolo e algoritmo em outros contextos, o seu
desempenho precisa ser avaliado para determinar se é capaz de atender os requisitos.
A arquitetura utilizada permite ainda que um número arbitrário de sensores seja
utilizado e calibrado simultaneamente. Além disso, a separação da aquisição e
calibração dos dados permite ainda que tanto os dados crus como calibrados sejam
armazenados, permitindo a utilização de melhores algoritmos ou calibração mais
cuidadosa durante o processamento dos dados.
Uma limitação que ainda está presente no método atual é a ausência de uma
referência externa para corrigir a orientação e garantir que o Norte medido está alinhado
ao real. Apesar do hardware e dos ambientes de teste deste trabalho não terem
introduzido distorções suficientemente grandes que tornassem essa correção imperativa,
outros contextos podem ter necessidade de realizar esta correção.
O node imu_calibrator_node pode ser facilmente estendido para suportar um novo
serviço que permita realizar essa correção a partir do alinhamento do sensor com o
Norte real.
Outro possível ponto de melhoria é a utilização de algoritmos de calibração que
utilizem múltiplos sensores concomitantemente. A arquitetura do imu_calibrator_node
considera essa possibilidade, mas não provê suporte explícito a ela.
5.2 Teste de sistema de orientação
O sistema de estimação de orientação composto pela IMU associada ao filtro de
estimação de orientação teve seu funcionamento avaliado em relação à sua acurácia nas
rotações.
5.2.1 Teste de acurácia
Este teste avalia a acurácia da estimação de orientação em relação à rotação real
aplicada ao sensor. Esse teste foi realizado em bancada com o auxílio de esquadros para
realizar a rotação com ângulos conhecidos. O setup é exibido na Figura 24.
70
A rotação foi realizada em torno de cada um dos eixos individualmente, sempre
realizada com o eixo de rotação paralelo ao vetor de aceleração da gravidade, de forma
que os dados de acelerômetro têm pouca influência sobre o resultado.
O filtro de estimação mistura dinamicamente os dados dos múltiplos sensores para
produzir uma estimativa mais acurada. No entanto, esse experimento foi realizado
esperando o período necessário para que o filtro convergisse para uma solução estável, o
que acontece em poucos segundos em situações normais. A espera pela convergência do
filtro de estimação significa que, quando os dados de magnetômetro são utilizados, a
estimação é dada basicamente pela orientação absoluta calculada a partir do campo
magnético e gravitacional terrestre.
Já quando os dados do magnetômetro não são utilizados, a variação do ângulo é
dada apenas pelo campo gravitacional da Terra e pela integração da informação de
velocidade angular do giroscópio.
Dois testes foram realizados então, um utilizando os dados do magnetômetro e outro
apenas com as leituras do giroscópio e acelerômetro. Todos os testes foram realizados
após calibração dos sensores, segundo o protocolo descrito anteriormente.
O procedimento do teste consiste em colocar o sensor com orientação neutra e,
Figura 24: Setup de bancada utilizado nos testes.
71
então, realizar rotações de 90º em torno de cada um dos eixos. Como as rotações reais
são conhecidas, a estimação pode ter sua acurácia avaliada. As medidas foram tomadas
uma única vez para cada orientação, mas devido à natureza de otimização do algoritmo,
a estimação possui um estado transiente curto e a estimativa rapidamente converge para
os mesmos valores dada uma mesma entrada.
5.2.1.1 Utilizando magnetômetro
Os resultados quando utilizando os dados de magnetômetro estão listados na Tabela
4, Tabela 5 e Tabela 6.
Rotação real Ângulo medido Erro
0 → 90º 75º -15º
0 → 180º 182º 2º
0 → 270º 265º -5º
Rotação real Ângulo medido Erro
0 → 90º 75º -15º
0 → 180º 182º 2º
0 → 270º 265º -5º
Rotação real Ângulo medido Erro
Tabela 4: Erro no ângulo no entorno do eixo X.
Tabela 5: Erro no ângulo no entorno do eixo Y.
Tabela 6: Erro no ângulo entorno do eixo Z.
72
0 → 90º 97º 7º
0 → 180º 175º -5º
0 → 270º 265º 5º
Como mencionado, os resultados representam basicamente a qualidade da medida
do magnetômetro. A classe dos sensores utilizados impede que os resultados tenham
acurácia melhor de 2º, mesmo em condições ideais, de forma que erros de alguns
poucos graus são esperados. Os dois ângulos que apresentaram erro acima de 10º podem
ser explicados por uma calibração incapaz de compensar todos as fontes de distorção e a
realização de um processo de calibração mais cuidadoso seria capaz de melhorar esses
resultados.
5.2.1.2 Sem utilizar o magnetômetro
Sem utilizar o magnetômetro, o ângulo paralelo ao vetor de aceleração da gravidade
fica sujeito à instabilidade de longo-prazo, mas o efeito não é rápido o suficiente para
comprometer este teste.
Como o ângulo sendo avaliado é sempre colocado paralelo ao vetor de aceleração da
gravidade, o resultado é basicamente o resultado da integração dos dados do giroscópio
do entorno deste eixo.
Os resultados estão listados na Tabela 7, Tabela 8 e Tabela 9:
73
Rotação real Ângulo medido Erro
0 → 90º 88º 2º
0 → 180º 174º -6º
0 → 270º 277º 7º
5.2.2 Teste de drift
Neste teste, as placas foram colocadas em repouso e a orientação delas calculada e
gravada em uma rosbag. Os dados foram, então, processados para avaliar a drift da
estimativa de orientação na situação de repouso. O teste foi realizado tanto com a
Raspberry Pi quanto a ESP32.
Para cada teste foram plotados os gráficos com a diferença entre a estimativa num
Tabela 7: Erro no ângulo no entorno do eixo X.
Rotação real Ângulo medido Erro
0 → 90º 86º -4º
0 → 180º 183º 3º
0 → 270º 278º 8º
Tabela 8: Erro no ângulo no entorno do eixo Y.
Rotação real Ângulo medido Erro
0 → 90º 87º -3º
0 → 180º 181º 2º
0 → 270º 283º 13º
Tabela 9: Erro no ângulo no entorno do eixo Z
74
instante e a média durante o experimento, como forma de avaliar um possível drift na
estimativa.
A coleta foi realizada utilizando todos os dados disponibilizados pelas IMU,
incluindo os do magnetômetro.
Os gráficos de diferença em relação à média foram filtrados com um filtro
passa-baixas de forma a facilitar a visualização, uma vez que o ruído de alta frequência
torna mais difícil a avaliação do sinal. O filtro utilizado foi um filtro Butterworth de
segunda ordem, sintonizado em uma frequência de 1 Hz. Foi realizada uma filtragem de
fase zero, implementada pela função filtfilt do Scipy.
No teste realizado utilizando a Raspberry, visto na Figura 25, a estimativa parece
não ter sofrido efeito de drift.
Já observando a distância em relação à média, vista na Figura 26, pode-se observar
que houve um desvio relativamente grande no início da estimativa. No entanto, em
termos absolutos, o erro ainda é menor que 0,5 º e mantêm-se em torno de 0º no restante
Figura 25: Ângulos estimados pelo filtro de estimação (Raspberry).
75
do experimento.
No experimento com a ESP32, exibido na Figura 27, também não parece haver drift,
mas a visualização é prejudicada pelas duas grandes descontinuidades presentes na
estimativa.
Figura 26: Diferença entre ângulos estimados e sua média (Raspberry).
76
Aproximando a estimativa no momento de uma descontinuidade, como exibido na
Figura 28, pode-se observar que a estimativa apresentou uma brusca variação, tendo,
então, convergido para os valores anteriores novamente em torno de 5 s. O erro é devido
a mau contato na conexão I2C, fazendo com que uma amostra apresente uma leitura
incorreta.
Figura 27: Ângulos estimados ao longo do tempo (ESP32).
77
Desconsiderando as descontinuidades causadas pelo mau-contato, a Figura 29
mostra que a estimativa se manteve estável, excetuando-se uma variação similar à
observada na estimativa da Raspberry nos momentos iniciais do experimento para o
ângulo Yaw (ângulo no entorno do eixo Z). Os outros ângulos mantiveram-se constantes
durante o experimento.
Figura 28: Detalhe da descontinuidade observada.
78
Ao aproximar e ignorar os dois momentos de descontinuidade, fica visível na
5.2.3 Teste de orientação relativa
Como descrito anteriormente, o node imu_tf_differential permite calcular a
orientação relativa da IMU em relação ao seu sistema de coordenadas local e republicar
a mensagem utilizando a nova orientação.
Para avaliar seu funcionamento, as estimações de orientação produzidas a partir das
IMUs da Raspberry e ESP32 foram produzidas de forma simultânea para avaliar se a
árvore de eixos produzidas pelos nodes representa corretamente as orientações reais.
O teste foi realizado colocando ambas as IMU em repouso e alternadamente
alterando a orientação de uma delas até que a estimação de orientação tenha sido
rotacionada em 90º. Espera-se que a rotação de uma não altere a orientação da outra,
enquanto a rotação relativa entre elas seja modificada.
Na Figura 30, Figura 31, Figura 32 e Figura 33 temos a posição inicial dos sensores
Figura 29: Diferença entre ângulos estimados e sua média (ESP32).
79
e a estimação produzida pelo filtro de orientação para a Raspberry Pi, representada pelo
barco, e para a ESP32, representada pelo remo.
Na Figura 30, ambas as IMUs tem seu eixo X alinhado segundo a estimativa
produzida. A posição física das placas mostra que ambas as placas possuem a mesma
orientação física, com o eixo X aproximadamente alinhado, como esperado devido a
utilização do campo magnético terrestre para produzir essa estimação.
Na Figura 31, a Rapsberry foi rotacionada em 90º no entorno do eixo Z, passando
seu eixo X a estar apontado para o lado direito da imagem. A estimação produzida e
exibida pelo gráfico mostra o mesmo movimento tendo sido realizado. O fato de a
rotação da Raspberry não ter influenciado a estimação de orientação da ESP32
demonstra o funcionamento do node imu_tf_differential. A falta de alinhamento entre as
placas é um resultado esperado, como visto na seção 5.2.1
Figura 30: Comparação entre posição real e estimada (Primeira configuração).
80
Já na Figura 32 e na Figura 33 a ESP32 sofre duas rotações de 90º, de forma
consistente entre estimação e a rotação real.
Figura 32: Comparação entre posição real e estimada (Terceira configuração).
Figura 31: Comparação entre posição real e estimada (segunda configuração).
81
Figura 33: Comparação entre posição real e estimada (quarta configuração).
5.2.4 Análise
A estimação de orientação produzida pelo node imu_filter_madgwick produziu
resultados com repetibilidade e sem presença de drift. O pacote do ROS que provê este
node implementa ainda o node imu_complementary_filter, que é baseado em um
algoritmo mais recente e afirma ser mais resistente a distorções magnéticas variantes no
tempo e pode ser uma possível fonte de melhoria.
Os melhores resultados nos testes de acurácia são provavelmente obteníveis a partir
da utilização de sensores de melhor qualidade e, principalmente, calibração mais
cuidadosa.
Os testes de estabilidade mostram que o sistema é capaz de ser utilizado para
experimentos de duração mais longa do que apenas alguns minutos. Apesar de não ter
sido realizado um teste controlado, observou-se que a estimação de orientação
permanece estável por múltiplas horas.
O node desenvolvido para calcular a orientação relativa entre os múltiplos sistemas
de coordenadas, imu_differential_tf funcionou corretamente, aumentando a
flexibilidade do sistema de eixos de referência.
82
5.3 Teste de estimação de trajetória
Este teste objetiva avaliar a capacidade do sistema de realizar a estimação de
posição durante um longo período, utilizando os sinais do GPS e IMU.
Neste teste, a Raspberry foi afixada no painel de um carro que percorreu o trajeto
entre Charitas, Niterói, e a Cidade Universitária da UFRJ. Esse trajeto é constituído de
um movimento no sentido sudeste-noroeste, sendo as coordenadas iniciais
(-22,932497, -43,096415) e as finais (-22,862290, -43,228538). Os dados produzidos
foram armazenados utilizando a ferramenta de aquisição do ROS, a rosbag, e
processados posteriormente.
Durante o processamento, os dados de aceleração, velocidade angular, campo
magnético e posição foram utilizados para estimar o vetor de estado do carro durante o
trajeto em duas dimensões, uma vez que não há variações abruptas de altitude no
percurso. A estimação de orientação foi realizada pelo node imu_madgwick_node, cujos
resultados são utilizados como entrada para os filtros de Kalman responsáveis por
estimar o vetor de estados completo.
O percurso é exibido pelo mapviz (visualizador 2D do ROS), no qual os pontos
verdes representam a leitura crua do GPS, e a linha vermelha, a estimação de posição do
filtro de Kalman.
Na Figura 34, pode-se observar as leituras de GPS para o trecho inicial entre os
bairros de Charitas e São Francisco. Nesta imagem, não é exibida a estimação pelo filtro
de Kalman.
83
Detalhe de uma curva em Charitas (Figura 35), demostrando a estimação com base
nos dados da IMU (vermelho) no período entre cada par de leituras do GPS (verde).
Curva no entorno da Igreja Histórica de São Francisco. Na Figura 36, podemos ver a
predição de trajetória funcionando no período em que não há leitura de GPS, e como as
inacurácias na leitura da IMU produzem uma discrepância entre a posição real e a
Figura 34: Trecho inicial do percurso entre os bairros de Charitas e São
Francisco.
Figura 35: Curva em Charitas.
84
predita. Os saltos descontínuos na linha vermelha ilustram a capacidade do filtro de
Kalman de fundir múltiplas fontes de informação, dando mais importância àquelas que
apresentam melhor precisão.
Aqui, durante uma parada no percurso ilustrada pela Figura 37, a perda natural de
precisão do GPS em posição estática associada ao drift não compensado do
acelerômetro causa um movimento aparente errático. Quando o carro passa a se
movimentar novamente, a estimação se recupera.
Esse resultado é esperado uma vez que as IMU utilizadas neste trabalho são de
baixo custo e apresentam vieses variantes com o tempo e temperatura que não podem
ser corrigidos por uma calibração estática no início da coleta, de forma que o erro se
acumula rapidamente e é apenas ocasionalmente corrigido pelo GPS.
Figura 36: Curva no entorno da Igreja.
85
A Figura 38 mostra o comportamento do filtro após a entrada em um túnel
engarrafado, caso em que há a perda do sinal de GPS e uma estimação dead reckoning
inicial. Infelizmente, o GPS forneceu leituras errôneas durante a travessia, fazendo com
que a estimação do filtro adotasse uma direção completamente incorreta.
Uma vez fora do túnel, o GPS passou a fornecer leituras corretas novamente e a
estimação passou a ser realizada corretamente, sofrendo um salto em direção à saída do
túnel, representado pela seta verde, como visto na Figura 39.
Figura 37: Parada no sinal de trânsito.
Figura 38: Entrada no túnel São Francisco – Icaraí.
86
A estimação durante a travessia da ponte Rio-Niterói, vista na Figura 40, manteve-se
estável, incluindo a estimação de velocidade que atingiu velocidade,s máximas de 75
km/h, condizentes com a velocidade lida no velocímetro do automóvel.
A chegada ao Fundão, ilustrada pela Figura 41, mostra mais claramente as pequenas
discrepâncias entre a estimativa do filtro e das leituras de GPS que ocorrem
principalmente durante mudanças de direção.
Figura 39: Saída do túnel.
Figura 40: Ponte Rio-Niterói.
87
A Figura 42 mostra a discrepância entre estimação e leitura do GPS na alça de
acesso ao Fundão pela Linha Vermelha
A Figura 43 exibe discrepâncias ocorridas nas proximidades do CENPES e do
prédio do Instituto de Física
Figura 41: Chegada ao Fundão.
Figura 42: Primeira discrepância entre estimação e leitura do GPS.
88
Figura 43: Segunda discrepância entre estimação e leitura do GPS.
A Figura 44 ilustra a diferença observada na rotatória nas proximidades do Centro
de Tecnologia, prédio da Faculdade de Letras e Reitoria.
Figura 44: Terceira discrepância entre estimação e leitura do GPS.
5.3.1 Análise
Este teste demonstrou a integração e funcionamento de múltiplas partes do sistema
simultaneamente, da leitura dos sensores até a estimação realizada pelo filtro de
Kalman.
Quando em ambiente aberto em que o GPS possui boa acurácia, a estimação de
trajetória funciona muito bem, com valores razoáveis sendo estimados para todo o vetor
89
de estados e boa concordância entre a predição realizada pela integração dos dados da
IMU e as subsequentes leituras do GPS.
Em outras situações, o desempenho é comprometido, como no caso em que o
veículo está parado. Nesta situação, o GPS naturalmente perde precisão e os dados se
tornam erráticos dentro de uma faixa de incerteza. Ao mesmo tempo, a integração dos
dados da IMU passa a sofrer maior efeito de quaisquer offsets não corrigidos, fazendo
com que a estimação prediga uma trajetória incorreta.
De forma ainda mais grave, quando os dados de GPS não estão disponíveis, como
na passagem por um túnel, a predição baseada somente nos dados da IMU é pior,
rapidamente produzindo valores absurdos. Novamente, este comportamento é devido ao
acúmulo de erros durante a integração realizada pelo filtro de Kalman, que, sem o GPS,
não possui uma segunda fonte de informação para corrigi-los.
O desempenho da estimação poderia ser melhorado a partir da adição de outras
fontes de informação que permitissem corrigir esse acúmulo de erros, como a adição da
informação de velocidade, que evitaria que a velocidade divergisse sem controle da
realidade ou a adição de outras IMU para realizar a compensação mútua. Outra opção
ainda é a utilização de odometria visual, que utiliza fluxo ótico para determinar a
movimentação do corpo no espaço.
Em relação ao filtro de Kalman, não se obteve resultados consideravelmente
melhores aumentando a frequência de predição ou mudando parâmetros da estimação, o
que indica que o limitante atual é a qualidade da informação de entrada.
Este experimento serve ainda como demonstração da capacidade do sistema de
armazenar informações de um experimento e processá-las posteriormente. Neste caso
específico, a coleta foi realizada meses antes da sua análise, sem que o protocolo de
calibração tivesse sido realizado. Posteriormente, no momento do processamento, a
calibração foi realizada, e os dados, utilizados para calibrar a informação bruta que
havia sido gravada.
90
6 Limitações
6.1 Placas analógicas
As placas analógicas desenvolvidas cumpriram os objetivos propostos a elas,
tornando a ligação com os sensores confiável e conveniente. No entanto algumas
limitações e possíveis pontos de melhora foram identificados no decorrer do projeto.
O shield da Raspberry Pi impede a utilização das caixinhas disponíveis no mercado,
dificultando a proteção da placa em ambientes mais inóspitos, como seria o caso de um
barco. Soluções possíveis são o desenvolvimento de uma caixinha própria,
possivelmente utilizando impressão 3D, que considere a existência do shield ou a
utilização de uma placa separada à Raspberry ligada por um flat cable.
Outra limitação é a posição da antena de GPS que fica projetada para além dos
limites do shield. Esta antena deveria ficar inscrita nos limites do shield, além de
possuir algum sistema de fixação, uma vez que o conector não é muito firme para a sua
utilização na presença de muita vibração, como numa bicicleta.
A fixação desta placa realizada pelo GPIO é adequada para a utilização em bancada,
mas não é firme o suficiente para outros ambientes. Para este caso, um sistema melhor
de fixação deve ser projetado para evitar que haja problemas de desconexão da placa
durante a utilização.
Já a placa da ESP32 é mecanicamente mais bem construída e não possui partes
móveis. A principal questão a ser revista são as trilhas que fazem a conexão I2C que
apesar de estarem ligadas aos pinos corretos, não permitiram a comunicação com os
sensores. Não foi determinado se o problema foi algum simples erro na montagem ou se
há alguma questão elétrica mais séria. No escopo deste projeto, a solução adotada foi a
realização da conexão por dois fios externos, como pode ser observado na Figura 4.
91
6.2 Alimentação da Raspberry Pi
Apesar de possuir uma dimensão física relativamente reduzida, a Raspberry Pi
requer uma corrente de 2,5 A para funcionar adequadamente [37]. Quando a corrente
que a fonte de alimentação é capaz de fornecer não atende a estes requisitos, a placa
automaticamente reduz o clock e a tensão de alimentação do processador para evitar o
seu desligamento. Esse comportamento impede que a placa desligue, mas a performance
sofre uma grande redução.
Durante o projeto, verificou-se que a Raspberry é capaz de rodar todos os algoritmos
utilizados em tempo real, incluindo o filtro de Kalman, mas apenas quando alimentada
com corrente suficiente. Quando a alimentação não fornece a corrente necessária, as
leituras e processamentos tornam-se erráticos e o funcionamento é impossibilitado.
Apesar de esta situação de degradação ocorrer quando alimentada pela bateria
presente na Figura 2, a performance ainda é suficiente para a aquisição dos dados sem
processamento posterior. Por conta da arquitetura descentralizada do ROS, o
processamento dos dados pode ser movido para um outro computador disponível.
A solução mais factível seria a aquisição de uma bateria ou o desenvolvimento de
uma fonte alimentada por baterias de lítio associadas a um regulador capaz de fornecer
mais de 2,5 A.
6.3 Leitura dos sensores
No escopo do projeto, as frequências de leitura dos sensores foram escolhidas de
forma arbitrária, uma vez que os requisitos de performance não eram muito restritivos.
Apesar disso, o suporte para a modificação das frequências de amostragem está
implementado e poderia ser utilizado caso houvesse necessidade tanto na Raspberry Pi
quanto na ESP32. Por conta do modelo assíncrono imposto pela troca de mensagens do
ROS, nenhum node desenvolvido faz qualquer hipótese a respeito da frequência de
recebimento de mensagens.
92
6.4 Performance da Raspberry Pi
A performance da Raspberry Pi mostrou-se adequada para os objetivos presentes no
escopo deste trabalho. No entanto, há a possibilidade de que ela passe a ser um
problema caso muitos outros sensores sejam adicionados ao sistema.
Novamente, devido à arquitetura descentralizada do ROS, essa limitação poderia ser
resolvida pela adição de outra placa capaz de compartilhar o processamento ou ainda
algum outro computados presente na rede.
Para o caso em que o sistema deve ser utilizado de forma isolada e a única unidade
de processamento é a Raspberry Pi, algumas atitudes poderiam ser tomadas:
• Caso a tarefa seja apenas aquisição de sinais:
o Neste caso, o principal limitante é a execução do node
rosserial_python, que é responsável pela comunicação com a ESP32.
Verificou-se que o recebimento de mensagens com uma taxa
aproximada de 100 Hz consome entre 10% e 20% da CPU da
Raspberry Pi.
o Soluções possíveis são: utilizar o rosserial_server, que é
implementado em C++ e oferece performance muito melhor, mas não
permite a utilização de services e logs do ROS, ou a utilização de
outro interpretador Python como o Pypy, que permita melhor
performance.
• Caso haja processamento em tempo real:
o Além das preocupações anteriores, este caso implica ainda a análise
da performance dos outros nodes que realizam o processamento dos
dados.
o Os nodes imu_calibrator_node e imu_tf_differential podem ser
facilmente reimplementados em C++, de forma que teriam muito
menor impacto na performance do sistema.
93
o O node imu_filter_madgwick possui boa performance e pode ser
considerado um problema secundário, mas sua compilação utilizando
flags mais agressivas pode ser investigada para a melhoria de
performance.
o O node robot_localization, que implementa o filtro de Kalman possui
boa performance relativa à quantidade de operações que realiza. No
entanto, a presença de vários deles no sistema, assim como a
utilização de uma alta frequência de amostragem rapidamente supera
a capacidade de processamento da Raspberry.
6.5 Modularidade dos sensores
O módulo de aquisição desenvolvido na forma da ESP32 e seu shield representa
uma forma possível de adicionar mais sensores de diferentes tipos ao sistema. A
arquitetura utilizada permite que outros sensores sejam trivialmente adicionados,
bastando que o hardware seja adaptado para o suporte de novos sensores e um driver de
leitura deste sensor para o firmware seja desenvolvido.
A organização por tópicos e a assincronicidade da troca de mensagens oferecida
pelo ROS permitiria ainda que múltiplos objetos fossem estudados simultaneamente.
Um exemplo deste caso de uso seria a aquisição de sinais de múltiplos remadores
simultaneamente, em que múltiplas unidades de sensor poderiam ser utilizadas para
adquirir as informações relevantes do remo e a movimentação dos atletas.
94
7 Conclusões
O objetivo deste trabalho foi o desenvolvimento de um sistema de aquisição,
armazenamento e processamento de dados que permitisse a realização de experimentos
de biomecânica. Ademais, o sistema devia ser facilmente extensível com a adição de
outros tipos de sensores e algoritmos.
Considerando a configuração de sensores utilizada no escopo deste trabalho, os
resultados obtidos e apresentados demonstram a capacidade do sistema de adquirir,
armazenar e processar os dados relevantes, produzindo estimativas para variáveis que
não podiam ser diretamente medidas como orientação e velocidade.
A modularidade do sistema foi ainda exemplificada pelo desenvolvimento do
módulo da ESP32, que funciona como um dispositivo independente capaz de realizar a
aquisição de sinais cinemáticos e poderia ser adaptado para adquirir outros sinais
quaisquer sem que a arquitetura geral do sistema tivesse que ser modificada de forma
significativa.
Conclui-se que o sistema desenvolvido pode servir de ferramenta para a realização
de experimentos mais complexos no futuro. Um próximo passo possível seria a
utilização deste sistema para a realização de experimentos em situações mais próximas
das reais, como forma de identificar possíveis limitações para serem trabalhadas. Outros
pontos naturais de extensão são a adição de novos sensores, como de força, velocidade,
EMG e bioimpedância, que permitiriam a aquisição de um conjunto mais rico de
informações pelo experimento e se aproveitaria da infraestrutura fornecida para
orquestrar o gerenciamento da grande quantidade de informações heterogêneas.
95
8 Referências
[1] Open Source Robotics Foundation, “About ROS,” [Online]. Available:
http://www.ros.org/about-ros/. [Acesso em 24 Janeiro 2019].
[2] M. e. a. Quigley, “ROS: an open-source Robot Operating System,” em ICRA
workshop on open source software, Kobe, 2009.
[3] Open Source Robotics Foundation, “Nodes,” [Online]. Available:
http://wiki.ros.org/Nodes. [Acesso em 24 Janeiro 2019].
[4] Open Source Robotics Foundation, “Topics,” [Online]. Available:
http://wiki.ros.org/Topics. [Acesso em 24 Janeiro 2019].
[5] Open Source Robotics Foundation, “Services,” [Online]. Available:
http://wiki.ros.org/Services.
[6] Open Source Robotics Foundation, “Messages,” [Online]. Available:
http://wiki.ros.org/Messages. [Acesso em 24 Janeiro 2019].
[7] Open Source Robotics Foundation, “Master,” [Online]. Available:
http://wiki.ros.org/Master. [Acesso em 24 Janeiro 2019].
[8] Open Source Robotics Foundation, “rosserial,” [Online]. Available:
http://wiki.ros.org/rosserial. [Acesso em 26 Janeiro 2019].
[9] Open Source Robotics Foundation, “rosserial_python,” [Online]. Available:
http://wiki.ros.org/rosserial_python. [Acesso em 26 Janeiro 2019].
[10] Open Source Robotics Foundation, “rosserial_client,” [Online]. Available:
http://wiki.ros.org/rosserial_client. [Acesso em 26 Janeiro 2019].
[11] Open Source Robotics Foundation, “Names,” [Online]. Available:
http://wiki.ros.org/Names. [Acesso em 26 Janeiro 2019].
[12] Open Source Robotics Foundation, “Parameter Server,” [Online]. Available:
http://wiki.ros.org/Parameter%20Server. [Acesso em 24 Janeiro 2019].
[13] Open Source Robotics Foundation, “Bags,” [Online]. Available:
http://wiki.ros.org/Bags. [Acesso em 24 Janeiro 2019].
[14] T. Foote, “tf: The transform library,” em 2013 IEEE Conference on Technologies
for Practical Robot Applications (TePRA), Woburn, MA, USA, 2013.
[15] Open Source Robotics Foundation, “roslaunch,” [Online]. Available:
http://wiki.ros.org/roslaunch. [Acesso em 25 Janeiro 2019].
[16] C. d. Wikipédia, “Zero-configuration networking,” Wikimedia, [Online]. Available:
https://en.wikipedia.org/wiki/Zero-configuration_networking. [Acesso em 17 02
2019].
[17] “Free RTOS - Market Leading RTOS for embedded systems with Internet of
Things extensions,” [Online]. Available: https://www.freertos.org/. [Acesso em 23
Fevereiro 2019].
[18] J. Ferguson, “Calibration of Deterministic IMU Errors,” 2015. [Online]. Available:
96
https://commons.erau.edu/pr-honors-coe/2. [Acesso em 24 Janeiro 2019].
[19] B. Earl, “Calibrating Sensors,” Adafruit, 02 01 2019. [Online]. Available:
https://cdn-learn.adafruit.com/downloads/pdf/calibrating-sensors.pdf. [Acesso em
24 Janeiro 2019].
[20] S. Madgwick, “An efficient orientation filter for inertial and inertial/magnetic
sensor arrays,” 2010. [Online].
[21] A. Vitali, “Ellipsoid or sphere fitting for sensor calibration,” ST Microeletronics,
Outubro 2018. [Online]. Available:
https://www.st.com/resource/en/design_tip/dm00286302.pdf. [Acesso em 25
Janeiro 2019].
[22] W. G. e G. Bishop, “An Introduction to the Kalman Filter,” em SIGGRAPH 2001,
Los Angeles, CA, US, 2001.
[23] M. P. e V. Havlena, “Optimality tests and adaptive Kalman filter,” em 16th IFAC
Symposium on System Identification, Bruxelas, Bélgica, 2012.
[24] E. Wan e R. V. D. Merwe, “The unscented Kalman filter for nonlinear estimation,”
em Adaptive Systems for Signal Processing, Communications, and Control
Symposium, Lake Louise, Alberta, Canada, Canada , 2000 .
[25] W. Collaborators, “Single-board Computer,” [Online]. Available:
https://en.wikipedia.org/wiki/Single-board_computer. [Acesso em 24 Fevereiro
2019].
[26] Raspberry Foundation, “Raspberry Pi Hardware,” [Online]. Available:
https://www.raspberrypi.org/documentation/hardware/raspberrypi/README.md.
[Acesso em 24 Fevereiro 2019].
[27] Espressif Systems, “ESP32 Series Datasheet,” [Online]. Available:
https://www.espressif.com/sites/default/files/documentation/esp32_datasheet_en.pd
f. [Acesso em 17 02 2019].
[28] Analog Devices, “ADXL345 datasheet,” 2015. [Online]. Available:
https://www.analog.com/media/en/technical-documentation/data-
sheets/adxl345.pdf. [Acesso em 23 Fevereiro 2019].
[29] STMicroeletronics, “AN3393 Application Note,” Abril 2011. [Online]. Available:
https://www.elecrow.com/download/L3G4200_AN3393.pdf. [Acesso em 23
Fevereiro 2019].
[30] Honeywell, “3-Axis Digital Compass IC HMC5883L,” Fevereiro 2013. [Online].
[Acesso em 23 Fevereiro 2019].
[31] InvenSense, “MPU-9250 Product Specification,” 20 Junho 2016. [Online].
Available: https://www.invensense.com/wp-content/uploads/2015/02/PS-MPU-
9250A-01-v1.1.pdf. [Acesso em 23 Fevereiro 2019].
[32] AsahiKasei, “AK8963 3-axis electronic compass,” Outubro 2013. [Online].
Available: https://www.akm.com/akm/en/file/datasheet/AK8963C.pdf. [Acesso em
23 Fevereiro 2019].
[33] P. Bovbel, “REP 145,” 2 Fevereiro 2015. [Online]. Available:
http://www.ros.org/reps/rep-0145.html. [Acesso em 25 Janeiro 2019].
[34] A. Vitali, “6-Point Tumble Sensor Calibration,” Dezembro 2015. [Online].
Available: https://www.st.com/resource/en/design_tip/dm00253745.pdf. [Acesso
97
em 27 Janeiro 2019].
[35] “imu_filter_madgwick,” [Online]. Available:
http://wiki.ros.org/imu_filter_madgwick. [Acesso em 26 Janeiro 2019].
[36] W. Meeussen, “REP 105,” 27 Outubro 2010. [Online]. Available:
http://www.ros.org/reps/rep-0105.html. [Acesso em 27 Janeiro 2019].
[37] Raspberry Pi Foundation, “FAQs - Raspberry Pi,” [Online]. Available:
https://www.raspberrypi.org/documentation/faqs/. [Acesso em 23 Fevereiro 2019].
[38] Open Source Robotics Foundation, “rviz,” [Online]. Available:
http://wiki.ros.org/rviz. [Acesso em 26 Janeiro 2019].
[39] “mapviz,” [Online]. Available: http://wiki.ros.org/mapviz. [Acesso em 26 Janeiro
2019].
[40] T. Ozyagcilar, “Calibrating an eCompass in the Presence of Hard- and Soft-Iron
Interference,” Novembro 2015. [Online]. Available:
https://www.nxp.com/docs/en/application-note/AN4246.pdf. [Acesso em 17 02
2019].
[41] “robot_localization,” [Online]. Available: http://wiki.ros.org/robot_localization.
[42] T. MOORE e D. STOUCH, “A generalized extended kalman filter implementation
for the robot operating system,” em Intelligent Autonomous Systems 13, Padova,
Itália, 2014.
[43] SZN, “Relative rotation between quaternions,” 4 Junho 2016. [Online]. Available:
https://math.stackexchange.com/questions/615891/relative-rotation-between-
quaternions. [Acesso em 26 Janeiro 2019].
[44] P. Bovbel, “Conventions for IMU Sensor Drivers,” 2 Fevereiro 2015. [Online].
Available: http://www.ros.org/reps/rep-0145.html. [Acesso em 25 Janeiro 2019].
[45] Open Source Robotics Foundation, “Nodes,” [Online]. Available:
http://wiki.ros.org/Nodes. [Acesso em 24 Janeiro 2019].
98
9 Anexo A – Shields desenvolvidos
9.1 Shield da Raspberry Pi
O diagrama do projeto da placa de circuito impresso pode ser visto na Figura 45 e
Figura 46 e o esquemático na Figura 47. O sensor de GPS é conectado à Raspberry Pi
por meio de conexão serial RS-232, através do conector J3 do shield, ocupando a maior
parte da região direta da placa. Devido a orientação e posicionamento dos pinos de
comunicação serial da Raspberry Pi, não foi possível posicionar a placa breakout do
GPS de forma que a antena anexada a ela ficasse posicionada sobre a placa
desenvolvida. Em vez disso, a antena fica posicionada sobre as portas USB da
Raspberry Pi, que estão a uma altura similar.
Do lado esquerdo, ficam posicionados os pinos destinados à conexão de uma IMU,
pelo conector J5. Com o objetivo de suportar vários modelos de IMU, o conector possui
11 pinos, em vez dos 10 que a MPU9250 e a GY80 possuem. Quando a MPU9250 é
utilizada, o sensor deve ser afixado nos 10 pinos mais à esquerda e o conector J4 deve
ter o circuito fechado. Já quando a GY80 é usada, ela deve ser conectada aos 10 pinos
mais à direita, e o conector J4 deve ser deixado em aberto.
O conector J1 foi colocado para abrir a possibilidade de estender o barramento I2C
para uma outra placa caso fosse necessário.
99
Figura 45: Shield da Raspberry Pi. Parte superior da placa com a silhueta das placas
de breakout da IMU e GPS. O plano contínuo é o plano de terra da placa.
Figura 46: Shield da Raspberry Pi Parte inferior da placa, exibindo o roteamento das
trilhas e o plano de Vcc da placa.
100
9.2 Shield da ESP32
Este shield consiste numa placa de circuito impresso com dois conectores para a
ESP32 e um conector para as placas de Breakout. Esse shield é similar ao da Raspberry
Pi, se utilizando da mesma técnica para permitir a conexão de múltiplos sensores.
Não há suporte para a placa de GPS, uma vez que essa é fisicamente maior que a
placa da ESP32 e comprometeria o objetivo de fazer uma placa de pequenas dimensões
e sem partes móveis como a antena.
Figura 47: Esquemático do shield da Raspberry Pi.
101
A Figura 48 acima ilustra a face superior da placa, onde os sensores são afixados. A
sequência maior de pinos suporta a MPU9250 e a menor, o HMC5883L. O plano
funciona como plano de terra para o circuito.
A Figura 49 ilustra a face inferior da placa e a Figura 50 exibe o esquemático
elétrico desta.
Figura 48: Shield da ESP32 (Vista inferior).
102
Figura 50: Esquemático do Shield da ESP32.
Figura 49: Shield da ESP32 Face inferior, exibindo as trilhas e o plano de Vcc.
103
10 Anexo B – RowingCore
Este pacote não possui nenhum node, mas serve como um meta-pacote com a
função de abrigar os arquivos launch e os parâmetros utilizados pelo projeto. Os
diversos modos de operação disponibilizados têm a função de isolar partes do sistema,
facilitando os testes, e cobrir diferentes casos de uso como gravação, reprodução e
execução em tempo real de experimentos. Alguns dos casos de uso são:
• Leitura de gravação de um sensor IMU
• Leitura de um sensor e estimação de orientação
• Leitura de múltiplos sensores e estimação de suas orientações
• Dead reckoning utilizando um sensor IMU e filtro de Kalman
• Estimação de estado com um sensor IMU e GPS utilizando filtro de Kalman
• Visualização da posição em mapa
• Visualização 3D do sistema estimado
104
11 Anexo C – Ferramentas de
visualização
Ferramentas de visualização são fundamentais para a verificação do funcionamento
do sistema durante o seu desenvolvimento, uma vez que muitas das variáveis sendo
estimadas têm componentes espaciais cuja verificação utilizando apenas valores
numéricos é difícil.
O desenvolvimento de ferramentas de visualização dedicadas daria origem a
programas de utilidade limitada às necessidades deste projeto além das próprias
ferramentas de visualização estarem sujeitas a erros de programação.
A disponibilidade de ferramentas genéricas como as apresentadas aqui é
fundamental para permitir futuras expansões do sistema sem que seja necessário o
desenvolvimento de novas ferramentas auxiliares.
11.1.1 rviz
O rviz é uma ferramenta de visualização 3D que permite o monitoramento do
sistema através das mensagens recebidas [38]. Suporta a visualização de sistemas de
coordenadas publicados pelo TF, definição de objetos 3D associados a estes sistemas de
coordenadas, nuvens de pontos, informação de temperatura, dentre outros.
105
11.1.2 mapviz
O mapviz é um visualizador similar ao rviz com foco na visualização de dados 2D e
mapas [39].
Figura 51: Manipulador robótico exibido no rviz.
Figura 52: Trajetória e imagens de câmeras exibidas no mapviz.
106