TCC.tex

% Meta-monografia de exemplo genérico de uso da classe delaetex.cls
% Copyright (C) 2004..2016 Walter Fetter Lages <fetter@ece.ufrgs.br>
%
% This file was adapted from:
% Meta-monografia de exemplo genérico de uso da classe deletex.cls
% Copyright (C) 2004 Walter Fetter Lages <w.fetter@ieee.org>
%
% This is free software, distributed under the GNU GPL; please take
% a look in `deletex.cls' to see complete information on using, copying
% and redistributing these files
%
%\documentclass[repeatfields,openright,overleaf,nomicrotype]{tcc}
% LTeX: language=pt-BR
\documentclass[repeatfields,xlists,xpacks,oneside,yearsonly]{ufrgscca}

\graphicspath{{./img/}}
\usepackage{fancybox}
\usepackage{subcaption}
\addbibresource{TCC.bib}
\usepackage[disable]{todonotes}
\usepackage{tabularx}
\usepackage{float}
\setlength{\marginparwidth}{2cm}

\begin{document}

\maketitle

% dedicatória é opcional
%\notoc\chapter{Dedicatória} %não vai aparecer no sumário

% agradecimentos são opcionais
%\notoc\chapter{Agradecimentos}

% Agradeço ao \LaTeX\ por não ter vírus de macro\ldots

% resumo no idioma do documento
\begin{abstract}

    O presente trabalho apresenta um sistema de navegação autônoma,
    aplicado no robô móvel Twil. Aproveitando o desenvolvimento de
    trabalhos anteriores, este sistema foi estendido, com adição do
    mapeamento do espaço onde o robô se movimenta. O mapa criado é
    utilizado para aprimorar a estimativa de posição do robô, e para
    replanejar trajetos em tempo real, evitando colisões. Isto foi
    realizado com auxílio de ferramentas do ROS 2, como a biblioteca de
    navegação autônoma \textit{Navigation2} e pacotes que incorporam
    técnicas de mapeamento e localização simultâneas. O desempenho dos
    sistemas desenvolvidos foi avaliado através de testes em um ambiente
    simulado, com gráficos medindo a estimativa de posição, comparação do
    mapa obtido com o mapa real, e análise qualitativa do planejador de
    trajetórias.

\end{abstract}

% resumo no outro idioma
% como parâmetro devem ser passadas as palavras-chave
% no outro idioma, separadas por vírgulas
\begin{otherabstract}{Mobile robotics, autonomous navigation, simultaneous localization and mapping}

    This paper presents an autonomous navigation system, applied to the
    Twil mobile robot. Taking advantage of the development of previous
    works, this system was extended, with the addition of mapping of the
    space in which the robot navigates. The generated map is used to
    improve the robot's pose estimation, and to replan trajectories in
    real time, avoiding collisions. This was done with the aid of tools
    made for ROS 2, such as the \textit{Navigation2} navigation framework
    and packages that perform simultaneous mapping and localization. The
    performance of the developed systems was evaluated through tests in a
    simulated environment, with graphs measuring the estimated position,
    comparison of the obtained map with the real map, and qualitative
    analysis of the path planner.

\end{otherabstract}

% sumario
\setcounter{tocdepth}{3}

% lista de ilustrações
\listoffigures

% lista de tabelas
\listoftables
% lista de listagens (código fonte)
%\listofcodelist %% doesn't work on overleaf

% lista de abreviaturas e siglas
% o parametro deve ser a abreviatura mais longa
\begin{listofabbrv}{PPGEE}
    \item[BT] \textit{Behavior Tree} (árvore de Comportamento)
    \item[RGB-D] \textit{Red Green Blue - Depth} (vermelho verde azul -
    profundidade)
    \item[ROS] \textit{Robot Operating System} (sistema operacional de robôs)
    \item[SLAM] \textit{Simultaneous Localization and Mapping} (localização e
    mapeamento simultâneos)
    \item[UFRGS] Universidade Federal do Rio Grande do Sul
\end{listofabbrv}

% lista de símbolos é opcional
% \begin{listofsymbols}{$\alpha\beta\pi\omega$}
% \end{listofsymbols}

\tableofcontents

\chapter{Introdução}

A robótica deve seu maior sucesso à indústria de manufatura, onde são
utilizados principalmente robôs
manipuladores~\cite{IntroductionToMobileRobots}. Porém, esses robôs
têm como limitação sua mobilidade, incapazes de se movimentar pela
planta, restringindo suas tarefas a um espaço fixo. Um robô móvel,
por outro lado, é capaz de se mover pelo seu ambiente de trabalho,
aumentando a gama de tarefas que podem ser realizadas.

O mercado desta categoria de robô está em crescimento, como mostra a
Figura~\ref{fig:mercado_robo}. Estes robôs podem ser utilizados em
ambientes internos, como hospitais, fábricas ou em centros de
distribuição, como o Proteus, o primeiro robô autônomo da
Amazon~\cite{amazon_robot}. Eles têm como desafio a navegação em
espaços dinâmicos, muitas vezes compartilhados com humanos. Portanto,
é necessária a capacidade de perceber seu ambiente e replanejar sua
trajetória em tempo real, de modo a evitar colisões.

\todo[inline]{Laranja disse que esta parte ficou meio enrolada}

\begin{figure}[h]
    {
        \centering
        \caption{Mercado global de robôs autônomos de 2016 a 2021, com projeção até 2028.}
        \label{fig:mercado_robo}
        \includegraphics[width=0.75\textwidth]{mercado_robo}\\
    }
    {\sourcecitation{\textcite{robot_market}.}}
\end{figure}

É neste contexto que se insere o projeto atual.
Utilizando o robô Twil, representado na Figura \ref{fig:robo_rviz},
propõe-se um sistema de navegação autônomo com sensores
que mapeiam o ambiente em conjunto com algoritmos de planejamento
de trajetórias, permitindo a navegação sem colisões em ambientes previamente
desconhecidos ou dinâmicos.
\todo{tentar separar essa frase em duas}

\begin{figure}[H]
    {
        \centering
        \caption{Modelo do robô utilizado.}
        \label{fig:robo_rviz}
        \includegraphics[width=0.3\textwidth]{robo_rviz.png}\\
    }
    % {\sourcecitation{Autor.}}
\end{figure}

Este robô já foi utilizado em trabalhos de conclusão de curso
anteriores, como em \textcite{petry_tcc} e \textcite{rahul_tcc}.
Porém, devido ao avanço do campo da robótica, ferramentas utilizadas
nesses trabalhos foram substituídas por versões atualizadas. É o caso
do ROS 2, sucessor do ROS 1, que é uma coleção de bibliotecas e
ferramentas para desenvolvimento de robôs, e do \textit{Navigation
    2}, um pacote para implementar navegação autônoma em robôs móveis,
que substituí o \textit{Navigation Stack} do ROS 1. Estas novas
versões aprimoram certos aspectos, como a segurança no caso do ROS, e
utilizam técnicas mais modernas, como o uso de árvores de
comportamento no \textit{Navigation 2}.

Neste trabalho, é dado seguimento ao desenvolvimento anterior no
Twil, a partir da adição e configuração de novos sensores, como a
câmera RGB-D Intel RealSense D435 e uma unidade de medida
inercial~(IMU). A câmera é responsável pela a percepção do ambiente,
que cria um mapa do ambiente, usado tanto na estimativa de posição do
robô, quanto no planejamento de trajetórias. A IMU, por sua vez, é
utilizado como um sensor auxiliar, que aprimora a odometria do robô
através de dados de orientação e velocidade angular do robô.

Como o mapeamento está presente em dois sistemas, cada um com
diferentes requisitos, foram criados dois mapas diferentes, um para o
planejamento de trajetórias, em forma de mapa de custo, e outro para
a localização do robô.

\chapter{Revisão da Literatura}
\label{revisao}

Neste capítulo são apresentadas as ferramentas e os conceitos
empregados na navegação autônoma de um robô móvel, com foco nas
técnicas presentes neste trabalho.

\section{Robot Operating System 2 (ROS 2)}

O ROS 2 é a segunda geração do Robot Operating System, um
\textit{framework} para desenvolvimento de robôs. Ele foi
desenvolvido a partir do zero para atender as necessidades de robôs
modernos, com suporte para customização extensiva. O seu
\textit{middleware}, \textit{Data Distribution Service}~(DDS), também
é usado em sistemas de infraestrutura crítica, como aplicações
militares, aeroespaciais e financeiras. Este padrão confere ao ROS
segurança e suporte para comunicação em tempo
real~\cite{ROS2Article}.

Um assunto relevante a este trabalho são os padrões de comunicação do
ROS 2. Existem três tipos de comunicação no ROS 2: \textit{topics},
\textit{services} e \textit{actions}. \textit{Topics} são canais de
comunicação unidirecionais, em que um nó, chamado de
\textit{publisher}, publica uma mensagem e outros nós, os
\textit{subscribers}, podem se inscrever no tópico publicado para
receber essa mensagem. \textit{Services} são um mecanismo do tipo
\textit{remote procedure call}~(RPC), em que um nó faz uma chamada a
outro nó, que executa uma computação e retorna um resultado,
funcionando como um cliente e um servidor.

\textit{Actions}, são utilizados para tarefas de longa duração, com possibilidade de
cancelamento prematuro.
O cliente começa a execução enviando uma requisição para o servidor,
que retorna periodicamente o estado atual da tarefa.
No término, é enviado o resultado, podendo ser sucesso ou falha.
Um exemplo de uso é uma tarefa de navegação em que um \textit{action client}
envia uma requisição com um ponto de destino para um \textit{action server}
que responde com realimentação contínua da posição atual do robô e
com o resultado ao finalizar a tarefa.
Eles também são apropriados para utilização em árvores de comportamento.

\section{Estimativa de posição de um robô móvel}

A terminologia e convenção dos sistemas de coordenadas de um robô
móvel utilizado neste trabalho é definido pela norma REP
105~\cite{rep_105}. Essa especificação define quatro sistemas de
coordenadas: \texttt{earth}, \texttt{map}, \texttt{odom} e
\texttt{base\_link}. Logo, a posição da base do robô, chamada de
\texttt{base\_link}, é definida através das transformações entre
esses sistemas de coordenadas, como mostra a Figura
\ref{fig:rep_105}.

\begin{figure}[H]
    {
        \centering
        \caption{Relação entre os sistemas de coordenadas utilizados na localização de um robô móvel.}
        \label{fig:rep_105}
        \includegraphics[width=0.8\textwidth]{tf_rep_105.png}\\
    }
    {\sourcecitation{\textcite{rep_105}.}}
\end{figure}

O sistema de coordenadas chamado de \texttt{earth} serve como
referência global em aplicações com diversos mapas com interação de
robôs entre eles. Neste trabalho, o foco é em um único robô em um
único mapa, portanto, esse sistema de coordenadas não é utilizado.

Assim, a posição do robô móvel é definida através das transformadas
entre os sistemas de coordenadas \texttt{map}, \texttt{odom} e
\texttt{base\_link}. A transformada entre \texttt{map} e
\texttt{odom} é calculada pelo sistema de localização, enquanto que a
transformada entre \texttt{odom} e \texttt{base\_link} pelo sistema
de odometria.

\todo[inline]{
    tenho que referenciar extensivamente isso nas duas seçoes seguintes

    https://www.ece.ufrgs.br/~fetter/ele00070/mobrob/estimation.pdf}

\subsection{Odometria}

A odometria publica a pose do robô em relação ao sistema de
coordenadas \texttt{odom}. Essa posição pode divergir ao longo do
tempo, sem limites, porém deve ser contínua. Devido à essas
características, ela é útil para referência local, mas deve ser
complementada com outros sistemas para referência global.

Essa odometria é geralmente obtida através de sensores incrementais,
que estimam a posição e orientação do robô através da integração de
dados de velocidade ou aceleração e, portanto, acumulam erros ao
longo da distância percorrida, como é o caso de encoders das rodas.

Outros exemplos de fontes de odometria são Unidades de Medição
Inercial~(IMUs), que contém acelerômetros e giroscópios, e odometria
visual, que utilizam sensores óticos para estimar a velocidade do
robô através da diferença de dados sucessivos.

\todo[inline]{
    explicaçao de odometria visual usando ransac(que o rtabmap odom usa)
    que encontrei:

    doi: 10.1109/IMTIC.2018.8467263 }

\subsection{Localização}

O sistema de localização é responsável por publicar a transformada
entre os sistemas de coordenadas \texttt{map} e \texttt{odom}, que
serve como um ajuste do erro da odometria. A estimativa de posição do
robô em relação ao \texttt{map} não deve divergir ao longo do tempo
significativamente, porém, essa coordenada não é continua e a posição
do robô pode mudar de forma abrupta em relação a ela. Portanto, essa
estimativa não precisa ser publicada a uma frequência tão alta quanto
a odometria.

Logo, sensores absolutos são ideais para esses sistemas, já que não
sofrem com erros de acumulação. Porém, sensores desse tipo geralmente
exigem processamento sofisticado, ocasionando um longo tempo entre
estimativas. Percebe-se que essas duas características são
semelhantes ao requisitos da publicação da transformada entre
\texttt{map} e \texttt{odom}.

Uma técnica comumente usada é a comparação de um mapa, obtido
previamente, com dados de sensores óticos. A localização por Monte
Carlo é uma das aplicações mais comuns desse sistema. Nela, os
estados possíveis do robô são representados por partículas, criando
uma distribuição de probabilidade. Com os dados da odometria e do
sensor ótico, o estado possível do robô é atualizado, sendo a
partícula com maior probabilidade escolhida como a estimativa de
posição do robô.

Porém, em situações em que não há conhecimento prévio do ambiente, é
necessário usar técnicas que realizam o mapeamento durante o
deslocamento do robô.

\section{Localização e Mapeamento Simultâneo (SLAM)}

Quando não há um mapa do ambiente obtido a priori, é preciso
construir o mapa durante a navegação. Nesse caso, técnicas de
localização e mapeamento simultâneo~(SLAM) são usadas.

Resolver o problema de SLAM envolve a estimação da trajetória do robô
e do mapa do ambiente enquanto o robô se desloca. Ao longo da
movimentação do robô em poses sequencias desconhecidas $x_{1:t} = {
            x_1, x_2, ..., x_t }$ em uma mapa desconhecido $m$, são obtidas uma
sequência de odometrias $u_{1:t} = {u_1, u_2, ..., u_t}$ e
observações do ambiente $z_{1:t} = {z_1, z_2, ..., z_t}$. O problema
SLAM requer a obtenção da distribuição de probabilidades dada pela
Equação \ref{eq:slam_problem}, considerando que $x_0$ é a posição
inicial do robô~\cite{slam_tutorial_part_i}. Um modelo gráfico deste
problema, em forma de uma rede de Bayes dinâmica, está representado
na Figura \ref{fig:slam_algo}.
% citar o artigo tutorial slam

\begin{equation}
    \label{eq:slam_problem}
    p(x_{1:t}, m | z_{1:t}, u_{1:t}, x_0)
\end{equation}

\begin{figure}[h]
    {
        \centering
        \caption{Modelo gráfico do problema do SLAM.}
        \label{fig:slam_algo}
        \includegraphics[width=0.8\textwidth]{graphic_slam_representation.png}\\
    }
    {\sourcecitation{\textcite{slam_tutorial_part_i}.}}
\end{figure}

Na literatura, uma variedade de soluções para esse problema estão
disponíveis. Dentre eles, destaca-se o método baseado em um grafo de
poses. O estado da arte atual, em relação a precisão e a velocidade
da estimativa, de sistemas SLAM utilizam técnicas com base nesse
método~\cite{graph_slam_tutorial}.

\subsection{SLAM baseado em grafo de poses}

A aplicação do grafo de poses para mapeamento e localização
geralmente consiste em quatro etapas: extração dos dados dos
sensores; construção do grafo de poses; procura de candidatos a
fechamento de laço; e otimização do grafo.

A construção do grafo de poses é feita utilizando os dados extraídos
dos sensores de odometria e percepção. Cada nó deste grafo consiste
na posição estimada do robô, dada pela odometria, com as informações
obtidas pelo sensor ótico, comumente em forma de \textit{features} da
imagem.

Após a adição de um nó, é feita a procura de candidatos para o
fechamento de laço, comparando os dados deste nó com de nós
desconectados, ou seja, nós que não foram criados recentemente na
mesma rota. Desta forma, é possível detectar quando o robô retorna a
uma posição já visitada anteriormente.

Finalmente, levando em contas as restrições obtidas na construção do
grafo, é realizada a otimização do caminho obtido, de forma a
diminuir o erro da estimativa de posição.

\subsection{Aplicações do SLAM no ROS}

Entre pacotes que implementam o SLAM baseado em grafos se destacam o
SLAM Toolbox e o Cartographer~\cite{slam_toolbox_art}. Porém, o
Cartographer foi descontinuado pelo Google e não é mais atualizado. O
SLAM Toolbox, por outro lado, foi escolhido como o pacote padrão de
SLAM para o ROS 2~\cite{slam_toolbox_ros_standard}, e oferece
diversas melhoras em relação a sistemas de SLAM anteriores, como o
GMapping, Karto, Hector e o próprio Cartographer.

Estes pacotes utilizam representações bidimensionais do ambiente,
sendo sensores baseados em \textit{scan} LASER a fonte de dado mais
comum~\cite{SensorAndSLAM}. Porém, com o avanço da tecnologia,
sensores Red Green Blue - Depth~(RGB-D) e câmeras estéreo estão se
tornando mais acessíveis, influenciando o desenvolvimento de sistemas
de Visual~SLAM~(VSLAM). Dentre sistemas de VSLAM, destacam-se o
ORB-SLAM3, OpenVSLAM e RTABMap, que possuem suporte a câmeras RGB-D e
permitem modos de localização pura.

Neste modo, também presente no SLAM Toolbox, a localização é feita
com um mapa base, obtido anteriormente, e com o estado atual do
ambiente. Divergências entre o ambiente e o mapa base são tratados
como obstáculos temporários, e não modificam permanentemente o mapa
original.

Em \textcite{VSLAM}, é feita uma comparação entre sistemas VSLAM,
mostrando que o OpenVSLAM é o pacote mais adequado para maioria dos
casos. Dos pacotes citados neste artigo, apenas o RTABMap continua
sendo desenvolvido ativamente, com suporte às versões mais recentes
do ROS 2. Porém, novos sistemas de VSLAM promissores estão sendo
desenvolvidos, como o NVidia Isaac ROS VSLAM e o StellaROS, que é um
sucessor do OpenVSLAM.

\section{Fusão de dados de sensores}

Robôs modernos estão cada vez equipados com mais sensores,
ocasionando em mais de uma fonte de dado para a mesma informação. Um
caso relevante neste trabalho, é a odometria do robô, que pode ser
estimada por diversos tipos de sensores, como IMU ou encoders de
roda, cada um com características diferentes. Ao invés de utilizar
apenas um sensor para estimar a odometria, os dados desses sensores,
munidos da informação de covariância do mesmo, podem ser fundidos
obtendo uma estimativa mais precisa. O filtro de Kalman, introduzido
em \textcite{KalmanFilter}, é um estimador linear recursivo,
comumente utilizado para aplicações deste tipo.

Um exemplo de aplicação deste filtro para estimativa de posição no
ROS 2 é o pacote
\texttt{robot\_localization}~\cite{robot_localization_paper}. Ele
permite um grande número de entrada de dados de sensores, e tem
suporte para diversos sensores, através da utilização de diferentes
tipos de mensagens do ROS. Além disso, é possível configurar os dados
que serão utilizados de cada sensor, podendo excluir os que não são
relevantes ou confiáveis do resultado final.

\section{Mapas de custo}

Um mapa de custo é uma representação de ambiente composta por uma
grade de células que contém um valor, variando de desconhecido,
livre, ocupado ou custo inflado.

Tradicionalmente, esses dados são armazenadas em mapas monolíticos,
para utilização em planejamento de trajetórias. Essa implementação é
aplicada com sucesso para caminhos curtos, mas pode apresentar
dificuldade em lidar com ambientes dinâmicos
maiores~\cite{latombeRobotMotionPlanning}.

Uma solução para este problema são mapas de custo com camadas, que
separam o processamento de dados em camadas semanticamente
distintas~\cite{layered_costmaps}. Esta separação permite a
utilização de diferentes fontes de dados, possibilitando, por
exemplo, atualizar o mapa com dados de sensores, sem modificar o
original. Outras camadas podem ser configuradas para evitar certas
áreas, manter uma distância segura de obstáculos ou para respeitar
regras culturais, como manter-se a direita em corredores. A Figura
\ref{fig:mapa_camadas} mostra uma configuração possível de camadas de
mapas de custo.

\begin{figure}[h]
    {
        \centering
        \caption{Exemplo de configuração de camadas de um mapa de custo.}
        \label{fig:mapa_camadas}
        \includegraphics[width=0.5\textwidth]{mapa_camadas_trad.png}\\
    }
    {\sourcecitation{Adaptado de \textcite{layered_costmaps}.}}
\end{figure}

Entre essas camadas, três são essenciais para mapear ambientes
dinâmicos: a estática, a de obstáculos e a de inflação. A camada
estática tem o mapa base, que deve ter apenas obstáculos fixos, dessa
maneira, a trajetória planejada não será alterada em razão de objetos
inexistentes.

A camada de obstáculos é responsável por atualizar o mapa de custo
com obstáculos dinâmicos, através de dados de sensores óticos. Uma
opção dessa camada, é a camada \textit{voxel}, que utiliza uma
representação em três dimensões dos dados dos sensores, introduzida
em~\textcite{office_marathon}. Nesse caso, é utilizado um espaço
tridimensional, composto por blocos chamados de \textit{voxels}, que
indicam se o bloco está ocupado ou livre. Cada coluna deste campo é
então projetada em um mapa bidimensional, com o valor dependendo da
presença de \textit{voxels} ocupados na mesma. Isto permite ao robô
detectar obstáculos em diferentes alturas, atualizando o mapa apenas
para obstáculos que podem colidir com o robô.

A camada de inflação utiliza os dados das camadas abaixo dela para
criar uma zona de segurança entre os obstáculos. Essa zona tem
valores intermediários entre os valores de obstáculo e livre, criando
trajetórias seguras, mas que permitem que o robô passe próximo a
obstáculos, caso necessário.

\section{Navigation2}

O \textit{Navigation2}~(Nav2) é o sucessor do ROS \textit{navigation
    stack}, permitindo a realização de tarefas complexas em diversos
ambientes e classes de robôs cinemáticos. Baseando-se no legado do
\textit{navigation stack} do ROS 1, o Nav2 foi construído em cima do
ROS2, implementando técnicas mais modernas para ter um sistema
modular propício para ambientes dinâmicos, e com suporte a uma maior
variedade de sensores~\cite{Nav2}.

Uma árvore de comportamento é utilizada para orquestrar as tarefas de
navegação, ativando os servidores de controle, planejamento e
recuperação para navegação. Para executar nós de \textit{actions},
são normalmente utilizados \textit{Action servers} do ROS 2. Esta
árvore de comportamento pode ser configurada pelo usuário através de
um arquivo em XML, permitindo a descrição de comportamentos de
navegação únicos sem necessidade de programação.

Na arquitetura, pode-se notar a utilização de dois mapas de custo, um
local e outro global. O local, utilizado no servidor do controlador,
realiza o planejamento a curto prazo e prevenção de colisão, enquanto
o global, aplicado no servidor de planejamento, é usado
principalmente para planejamento a longo prazo.

\chapter{Metodologia}
\label{desenvolvimento}

O sistema de navegação do Twil foi desenvolvido utilizando a versão
Humble do ROS 2 e com auxílio de ferramentas suportadas por esta
versão. Dentre as ferramentas utilizadas, destacam-se o Gazebo,
utilizado para simulação do robô, e o \textit{Navigation2}, que
fornece diversas ferramentas para implementar e orquestrar um sistema
de navegação autônoma.

Os variados componentes do robô, como os sensores empregados neste
trabalho, foram implementados através de \textit{plugins} do Gazebo,
que comunicam o estado do robô durante a simulação através de tópicos
do ROS 2. A câmera RGB-D Intel RealSense D435, utilizada para o o
mapeamento do ambiente, foco deste trabalho, foi implementada dessa
forma.

O \textit{Navigation2} é encarregado de enviar comandos de velocidade
para o robô, para que ele chegue ao destino desejado de modo seguro,
evitando colisões. Sua arquitetura está representada na Figura
\ref{fig:nav2_arc}. As setas à esquerda da imagem representam as
entradas necessárias do sistema, como a estimativa de posição do
robô, representadas pela seta TF, em forma de transformadas sistemas
de coordenadas conforme o REP-105~\cite{rep_105}, além do mapa e dos
dados dos sensores, que são utilizados para o planejamento de
trajetórias.

\begin{figure}[H]
    {
        \centering
        \caption{Arquitetura do \textit{Navigation2}.}
        \label{fig:nav2_arc}
        \includegraphics[width=0.8\textwidth]{nav2_architecture_trad.png}\\
    }
    {\sourcecitation{Adaptado de \textcite{nav2_site}.}}
\end{figure}

O servidor do planejador é responsável pela criação de trajetórias
usando a representação do ambiente em forma de um mapa de custo.
Utilizando essa trajetória como referência, e comparando a estimativa
de posição do robô, o servidor do controlador gera comandos de
velocidade para o robô, que é a saída do \textit{Nav2}.

Antes do início deste trabalho, o Twil já estava configurado para
utilizar o \textit{Nav2}, porém sem utilizar dados da câmera e IMU.
Portanto, as trajetórias planejadas não eram atualizadas a fim de
evitar obstáculos, além de não haver sistema de localização, ou seja,
a transformada entre \texttt{map} e \texttt{odom} era estática, sem
ajuste da odometria implementada.

Em razão disso, foi adicionada a câmera RGB-D Intel RealSense D435 e
um IMU ao robô, e o sistema de navegação foi aprimorado com a
utilização desses sensores nos componentes de odometria, localização
e mapeamento.

Um diagrama simplificado da arquitetura do sistema desenvolvido neste
trabalho é mostrado na Figura \ref{fig:arq_trabalho}. O
desenvolvimento atual foi focado nos blocos em vermelho, que realizam
o mapeamento do ambiente, e blocos em verde, que estimam a posição do
robô. O bloco em azul, que representa as outras ferramentas do
\textit{Nav2}, e o controlador em marrom, que transforma os comandos
de velocidade em comandos para as rodas do robô, já estavam
configurados.

Os componentes de mapeamento criam duas representações do ambiente.
Um mapa criado é o utilizado no planejamento de trajetórias, em forma
de mapa de custo, onde foi adicionada uma camada para percepção de
obstáculos utilizando a câmera RGB-D. Além disso, foi realizada a
calibração da camada de inflação, para produzir caminhos mais
seguros. O segundo mapa é criado e utilizado pelos sistemas de
localização e mapeamento simultâneo~(SLAM), adicionados ao Twil.

Em verde, estão os componentes referentes à estimativa de posição do
robô, onde foram adicionados pacotes que realizam a odometria visual
e pacotes de SLAM. Também, aprimorou-se a odometria das rodas,
através da fusão de dados com o sensor IMU. Ademais, para realização
de testes, se manteve a opção de utilizar a transformada estática
entre \texttt{map} e \texttt{odom}, e foi adicionado um sistema de
odometria utilizando a posição exata do robô no Gazebo.

\begin{figure}[H]
    {
        \centering
        \caption{Arquitetura do simplificada do sistema desenvolvido.}
        \label{fig:arq_trabalho}
        \includegraphics[width=0.98\textwidth]{arquitetura_simplificadav4.png}\\
    }
    % {\sourcecitation{Autor.}}
\end{figure}

Nas seções seguintes, é apresentado o robô e o ambiente de testes
utilizado neste trabalho. Em seguida, é detalhado o desenvolvimento
dos sistemas necessários para a navegação autônoma do robô neste
ambiente. Finalmente, é descrita a coleta de dados para a análise dos
resultados, que é apresentada no próximo capítulo.

\section{Configuração do robô}

O modelo do robô está presente no pacote \texttt{twil\_description},
que contém os arquivos de descrição do robô no formato XACRO, que é
expandido para o formato URDF, utilizado pelo nodo
\texttt{robot\_state\_publisher}, que publica essa descrição em um
tópico. Esse modelo é utilizado no rviz para visualização do robô,
como representado na Figura \ref{fig:robo_rviz}, e no Gazebo, para
simulação. Os componentes físicos do robô, como sensores e atuadores,
são criados a partir de \textit{plugins} do Gazebo, também presentes
no arquivo de descrição.

Durante este trabalho, foram configurados dois novos componentes ao
robô, a câmera RGB-D Intel RealSense D435 e um IMU. A câmera está
presente nos sistemas de odometria, localização e mapeamento,
enquanto o IMU foi usado como suplemento ao sistemas de odometria,
fornecendo dados de orientação do robô para fusão de dados.

Para utilização da câmera, é necessário o pacote
\texttt{realsense-ros}~\cite{realsense_ros}, que contém o modelo da
câmera. O \textit{plugin} do Gazebo \texttt{camera\_plugin}, é
responsável pela publicação dos dados da câmera simulada. Cinco
tópicos são responsáveis por estes dados: dois tópicos publicam as
imagens não comprimidas, uma RGB e outra de profundidade; dois
tópicos com informações suplementares destas imagens; e um tópico com
a nuvem de pontos produzida pela câmera.

A adição do IMU foi feita utilizando o \textit{plugin}
\texttt{GazeboRosImuSensor}, que publica mensagens do tipo
\texttt{sensor\_msgs/Imu}. Essas mensagens contêm a orientação,
velocidade angular e aceleração linear do robô. Por si só, o IMU não
é confiável para estimar a posição do robô porque necessita integrar
a aceleração linear duas vezes para calcular a posição e, portanto, é
muito suscetível a erros de acumulação. Porém, os dados referentes a
orientação e velocidade angular, podem complementar as outras fontes
de odometria, através da fusão de dados. Para representar fisicamente
o IMU no robô, foi reutilizada a descrição de uma placa de circuito
impresso \textit{Eurocard}, que também representa outros componentes
do robô.

A atuação das rodas do robô, a partir dos comandos de velocidade
produzidos pelo \textit{Nav2}, é feita por controladores configurados
no pacote \texttt{twil\_bringup}. Diversos deles estão disponíveis
para uso com o Twil, porém o controlador
\textit{twist\_mrac\_controller}, do pacote
\texttt{linearizing\_controllers} foi o escolhido e integrado ao
\textit{Nav2} em trabalhos anteriores.

\section{Ambiente de simulação}

O sistema foi testado em uma simulação do prédio Centenário da Escola
de Engenharia da UFRGS, utilizando o Gazebo. No pacote
\texttt{ufrgs\_map} está incluído uma representação em formato PGM da
planta do prédio, mostrada na Figura \ref{fig:planta_centenario},
desenvolvida em~\textcite{petry_tcc}. Além da imagem da planta,
também está presente um arquivo de configuração em formato YAML, que
contém a resolução e a origem do mapa. Este arquivo ainda contém
parâmetros para utilização como mapa de custo, indicando a faixa de
valores para considerar uma célula como livre ou ocupada.

\begin{figure}[H]
    {
        \centering
        \caption{Planta do 1º andar do prédio Centenário da EE-UFRGS.}
        \label{fig:planta_centenario}
        \includegraphics[width=0.7\textwidth]{centenario_floor_plan.png}\\
    }
    {\sourcecitation{\textcite{petry_tcc}.}}
\end{figure}

O pacote \texttt{ufrgs\_gazebo} contém arquivos de mundos do Gazebo
para simulação. Ele, porém, estava desatualizado e não continha uma
representação completa do prédio Centenário. Utilizando o
\textit{Building Editor} do Gazebo, foi criado um modelo simplificado
do prédio em 3D, com base na sua planta, mostrado na Figura
\ref{fig:gazebo_centenario}.

\begin{figure}[h]
    {
        \centering
        \caption{Ambiente Gazebo com modelo do prédio Centenário da EE-UFRGS.}
        \label{fig:gazebo_centenario}
        \includegraphics[width=0.95\textwidth]{gazebo.png}\\
    }
    % {\sourcecitation{Autor.}}
\end{figure}

Não foram adicionados os obstáculos representados em cinza claro da
planta da Figura \ref{fig:planta_centenario}, que não são obstáculos
fixos. Para teste com obstáculos dinâmicos ou temporários são
adicionados novos objetos a este mundo durante a execução da
simulação no Gazebo.

\section{Estimativa de posição do robô}
\label{bib:estimativa_posicao}

A estimativa de posição é feita utilizando o sistemas de coordenadas
definido pela norma REP 105, conforme descrito na
Seção~\ref{bib:estimativa_posicao}. Portanto, a pose do robô é
estimada por dois sistemas, o de odometria e de localização.

\subsection{Odometria}
\label{met:odometria}

O sistema de odometria é responsável pela publicação da transformada
entre o sistema de coordenadas \texttt{odom} e \texttt{base\_link},
utilizando sensores incrementais.

Neste trabalho, foram utilizados e comparados três sistemas de
odometria, que além da transformada, também publicam mensagens do
tipo \texttt{nav\_msgs/Odometry} no tópico \texttt{/odom}. Antes
deste trabalho, a odometria era publicada apenas pelo controlador,
através do pacote \texttt{twist\_mrac\_controller}, utilizando dados
do encoder nas rodas para estimar a posição do robô. O cálculo da
posição é feito pelo pacote \texttt{arc\_odometry}, que utiliza o
modelo cinemático de um robô móvel de acionamento diferencial para
estimar a posição e orientação do robô a partir das rotação das
rodas. Para aprimorar a qualidade desta odometria, foi adicionado o
pacote \texttt{robot\_localization}, que realiza a fusão de dados da
odometria das rodas com os dados do IMU.

A fusão é realizada através de um filtro de Kalman estendido, onde
devem ser escolhidos quais dados dos sensores devem ser considerados.
Os criadores do pacote \texttt{robot\_localization} recomendam não
utilizar dados de posição da odometria das rodas. Dessa forma, a
posição é calculada pelo mesmo pacote a partir dos dados obtidos pela
fusão das velocidades fornecidas ao pacote. Quando são fornecidas
estimativas de posição, não é realizado o cálculo a partir da
velocidade, sendo usado apenas a fusão dos dados de posição.

Apesar disso, decidiu-se utilizar tanto a posição quanto a velocidade
na fusão de dados, que faz com que a pose publicada pelo pacote seja
igual a estimada pelo \texttt{arc\_odometry}, já que o IMU não
fornece dados de posição. Isso foi feito porque a velocidade obtida
pelo \texttt{arc\_odometry} é dada em referência ao sistema de
coordenadas global, ou seja, o \texttt{odom}, enquanto que o
\texttt{robot\_localization} espera que a velocidade seja em
referência a base do robô. Portanto, o \texttt{robot\_localization}
não é capaz de estimar corretamente a posição do robô com base na
velocidade publicada pelo \texttt{arc\_odometry} sem um nodo
adicional para conversão.

A velocidade angular e orientação, por outro lado, foram fundidas com
os dados do IMU, que fornece uma estimativa mais precisa destes
campos.

Como alternativa a este sistema, foi implementado um sistema de
odometria visual, publicado pelo executável \texttt{rgbd\_odometry}
do pacote \texttt{rtabmap\_odom}, que utiliza imagens da câmera RGB-D
com auxílio do sensor IMU para estimava da posição. Com a informação
de profundidade, são comparadas \textit{features} visuais entre
imagens consecutivas, a velocidade do robô é estimada com um
algoritmo baseado em \textit{Random Sample
    Consensus}~(RANSAC)~\cite{rtabmap_odom}.

É possível fundir os dados destes dois sistemas de odometria,
porém, optou-se primeiramente por mantê-los separados para realizar a comparação
do desempenho entre eles. Caso ambos sistemas tenham desempenhos satisfatórios,
a fusão de dados pode fornecer um resultado mais preciso.

Finalmente, para realização de testes, foi implementado um sistema de
odometria com a posição real do robô no Gazebo. O \textit{plugin}
P3D, publica uma mensagem do tipo \texttt{nav\_msgs/Odometry} com a
posição do robô em relação ao sistema de coordenadas \texttt{odom}.
Quando este sistema de odometria é selecionado, as informações do P3D
são retransmitidas no tópico \texttt{/odom} e o pacote
\texttt{odom\_to\_tf\_ros2} publica a transformada entre
\texttt{odom} e \texttt{base\_link} a partir destes dados.

Os sistemas de odometria utilizados estão resumidos na Tabela
\ref{tab:odometria}, onde é indicado o pacote, a fonte de dados e o
tipo de mensagem recebido por cada um.

\begin{table}[H]
    \begin{center}
        \caption{Sistemas de odometria}
        \label{tab:odometria}
        % a fonte de dados ficou "Rodas" na primeira linha porque encoder das rodas nao coube
        \small
        \begin{tabularx}{\linewidth}{c|c|c|c}
            Pacote utilizado                              & Fonte de dados          & Tópico                       & Tipo da mensagem                 \\
            \hline
            \multirow{2}{*}{\texttt{robot\_localization}} & Rodas                   & \texttt{/controller/odom}    & \texttt{nav\_msgs/Odometry}      \\
                                                          & IMU                     & \texttt{/sensor/imu}         & \texttt{sensor\_msgs/Imu}        \\
            \hline
            \multirow{5}{*}{\texttt{rtabmap\_odom}}       & \multirow{4}{*}{Câmera} & \texttt{/depth/image\_raw}   & \texttt{sensor\_msgs/Image}      \\
                                                          &                         & \texttt{/depth/camera\_info} & \texttt{sensor\_msgs/CameraInfo} \\
                                                          &                         & \texttt{/color/image\_raw}   & \texttt{sensor\_msgs/Image}      \\
                                                          &                         & \texttt{/color/camera\_info} & \texttt{sensor\_msgs/CameraInfo} \\
                                                          & IMU                     & \texttt{/sensor/imu}         & \texttt{sensor\_msgs/Imu}        \\
            \hline
            \texttt{odom\_to\_tf\_ros2}                   & Gazebo                  & \texttt{/fake\_odom}         & \texttt{nav\_msgs/Odometry}      \\
        \end{tabularx}
    \end{center}
    % {\sourcecitation{Autor}}
\end{table}

\subsection{Localização}
\label{met:localizacao}

O sistema de localização, por outro lado, publica esporadicamente a
transformada entre o sistema de coordenadas \texttt{map} e
\texttt{odom}, para ajustar os erros de divergência da odometria,
através de sensores absolutos.

Anteriormente, não era utilizado nenhum sensor para localização do
robô, e a transformada entre \texttt{map} e \texttt{odom} era
estática, causando divergência na estimativa de posição durante a
navegação. Este sistema foi mantido para testes, porém foram
implementados dois sistemas de localização baseados em localização e
mapeamento simultâneos~(SLAM), utilizando a câmera RGB-D Intel
RealSense D435, para melhorar a estimativa de posição do robô
publicada pela odometria.

Uma alternativa à sistemas SLAM é o \texttt{nav2\_amcl}, que utiliza
localização por Monte Carlo em um mapa construído previamente, que
poderia ser a planta do prédio, para estimar a posição do robô.
Porém, essa opção foi descartada, pois o robô deve ser capaz de
navegar em ambiente dinâmicos ou pouco conhecidos, onde um mapa
estático não seria adequado. Além disso, esse pacote só é compatível
com representações bidimensionais do ambiente, que causaria problemas
na detecção de objetos tridimensionais, como as escadas, agravando as
divergências que já existem entre o ambiente do Gazebo e a planta.

Os dois sistemas de SLAM utilizados foram o \texttt{slam\_toolbox} e
o \texttt{rtabmap\_slam}, resumidos na Tabela \ref{tab:localizacao}.

\begin{table}[H]
    \begin{center}
        \caption{Sistemas de localização}
        \label{tab:localizacao}
        \small
        \begin{tabularx}{\linewidth}{c|c|c|c}
            Pacote utilizado                        & Fonte de dados          & Tópico                       & Tipo de mensagem recebida        \\
            \hline
            \texttt{slam\_toolbox}                  & Câmera                  & \texttt{/depth/image\_scan}  & \texttt{sensor\_msgs/LaserScan}  \\
            \hline
            \multirow{4}{*}{\texttt{rtabmap\_slam}} & \multirow{4}{*}{Câmera} & \texttt{/depth/image\_raw}   & \texttt{sensor\_msgs/Image}      \\
                                                    &                         & \texttt{/depth/camera\_info} & \texttt{sensor\_msgs/CameraInfo} \\
                                                    &                         & \texttt{/color/image\_raw}   & \texttt{sensor\_msgs/Image}      \\
                                                    &                         & \texttt{/color/camera\_info} & \texttt{sensor\_msgs/CameraInfo} \\
        \end{tabularx}
    \end{center}
\end{table}

O \textit{slam\_toolbox}, realiza o SLAM em 2D e foi criado para
utilizar sensores a laser. Portanto, são esperadas mensagens do tipo
\texttt{sensor\_msgs/LaserScan} para percepção do ambiente neste
sistema. Como a câmera RGB-D não publica mensagens desse tipo, o
pacote \texttt{depthimage\_to\_laserscan} foi usado para converter a
imagem de profundidade da câmera na mensagem esperada, em forma de um
feixe de luz em duas dimensões localizado na altura da câmera. O
\textit{rtabmap}, por outro lado, realiza o SLAM em 3D e aproveita
todos os tópicos publicados pela câmera RGB-D, não necessitando de
conversão de mensagens.

Ambos sistemas publicam a transformada entre \texttt{map} e
\texttt{odom}, além da posição global do robô no tópico
\texttt{/pose}, em mensagens do tipo
\texttt{geometry\_msgs/PoseWithCovarianceStamped}, que são utilizadas
para comparação com a posição real e a estimada pela odometria.

Apesar de realizar o mapeamento do ambiente em tempo-real, esses
sistemas podem ser iniciados com informações de uma sessão prévia de
mapeamento, que pode aumentar a precisão da localização, caso o mapa
seja mais fiel que o construído. Porém, nos testes realizados, a
sessão de SLAM foi iniciada do zero, para simular um ambiente
desconhecido.

\section{Mapeamento}

O mapeamento é um aspecto essencial para a navegação autônoma. Ele é
utilizado tanto no planejador de trajetórias, para perceber e evitar
obstáculos dinâmicos, quanto no sistema de localização do robô, para
estimar a posição do robô no ambiente.
% O mesmo mapa poderia ser
% utilizado para ambos sistemas, porém, devido a diferentes
% necessidades de cada sistema, optou-se criar dois mapas do ambiente,
% o mapa de custo, para planejamento de trajetórias, e o mapa SLAM,
% utiliza para localização do robô.

Apesar do sistema de SLAM fornecer um mapa do ambiente, este mapa não
é utilizado no mapa de custo. Como este mapa não está completo desde
o início, não é possível planejar trajetórias para ambientes não
visitados previamente. Além disso, é preferível que o mapa da camada
estática tenha apenas obstáculos fixos, como paredes e escadas, e
utilizar a camada de obstáculos para obstáculos dinâmicos. Esta
separação permite que o mapa estático seja utilizado em diversas
sessões, porém com uma camada de obstáculos nova a cada sessão.
Ademais a camada de obstáculos pode ser configurada de forma
independente que o SLAM, podendo utilizar outros sensores ou
considerar uma altura de obstáculos diferente.

Portanto, foram criadas duas representações do ambiente, uma obtida
pelo SLAM, que é utilizada apenas para localização, e outra realizada
utilizando os \textit{plugins} do mapa de custo do Nav2, que é usado
no planejamento de trajetória.

\subsection{Mapeamento de custo}

O mapa de custo empregado no planejamento de trajetórias é composto
por três camadas: a camada estática, que possui uma representação
simples do ambiente, preferencialmente sem obstáculos temporários; a
camada de obstáculos ou \textit{voxel}, onde são utilizados dados dos
sensores óticos para atualizar o mapa com obstáculos percebidos; e a
camada de inflação, que cria um campo de custo ao redor dos
obstáculos.

A planta do prédio Centenário, representada na Figura
\ref{fig:planta_centenario}, foi utilizada como mapa estático. Ele
foi configurado para considerar apenas as cédulas em preto como
ocupadas, que equivalem a obstáculos fixos, como paredes e a escada.
As cédulas em cinza, que representam a obstáculos prováveis como
cadeiras e mesas, são consideradas livres, já que esses objetos devem
ser captados pelos dados dos sensores do robô.

A camada de obstáculos utiliza os dados da camera RGB-D para
atualizar o mapa. Existem dois \textit{plugins} que podem ser
aplicados para este fim, o \texttt{obstacle\_layer} e o
\texttt{voxel\_layer}. Ambos suportam mensagens do tipo
\texttt{PointCloud2}, que são publicadas pela câmera RGB-D, porém
empregam técnicas diferentes para atualizar o mapa. O
\texttt{obstacle\_layer} utiliza \textit{ray casting} em 2D para
determinar a posição dos obstáculos. O \texttt{voxel\_layer}, por
outro lado, cria um grade tri-dimensional, divido em blocos chamados
de \textit{voxels}, que podem estar ocupados ou livres.

Apesar do mapa de custo ser em 2D, a simulação e o mundo real podem
ter obstáculos de diferentes alturas, como mesas e cadeiras.
Portanto, é necessária a percepção em 3D do ambiente para evitar
colisões com estes obstáculos. Logo, foi utilizado o
\texttt{voxel\_layer} para atualizar o mapa de custo.

Para a configuração do \texttt{voxel\_layer}, é preciso definir a
resolução e o número de \textit{voxels} no eixo Z utilizados. A
câmera RGB-D Intel RealSense D435 do Twil está localizada a uma
altura de aproximadamente 1,37 metro do chão, que é a altura mínima
do gride de \textit{voxels}. O número máximo de \textit{voxels}
permitido pelo \textit{plugin} é 16. Tendo em vista estes dados, foi
definido um gride de \textit{voxels} com 15 \textit{voxels} de
resolução 0,1 metro, criando um gride de 1,5 metro de altura.
Portanto, são captados apenas obstáculos dentro deste campo, e
objetos em uma altura superior a 1,5 metro não são considerados. Isso
é importante para evitar a detecção de obstáculos que não são
relevantes para a navegação como, no caso do ambiente de simulação
utilizado, a moldura das portas.

A última camada, \texttt{inflation\_layer}, cria uma zona de
segurança ao redor dos objetos captados nas outras camadas, para
garantir uma distância segura ao planejar a trajetória. Em
\textcite{ros_tuning_guide}, recomenda-se que a camada de inflação
cubra um raio grande em volta de obstáculos com uma curva de
decaimento de inclinação baixa, para criar um campo que cubra a maior
parte do mapa de custo. Desta forma, são criadas trajetórias que
passam no meio de obstáculos, mantendo uma distância segura,
diminuindo o risco de possíveis colisões e realizando movimentos
suaves.

\subsection{Mapeamento SLAM}

O mapeamento realizado pelo sistemas SLAM é utilizado apenas para a
localização do robô pelo mesmo pacote que o criou. Foram criados dois
mapas, um por cada pacote de localização implementado,
\texttt{slam\_toolbox} e \texttt{rtabmap\_slam}, descritos na Seção
\ref{met:localizacao}.

Devido aos dados dos sensores à sua disposição, o
\texttt{slam\_toolbox} só é capaz de criar mapas em duas dimensões.
Porém, o \texttt{rtabmap\_slam} pode criar mapas em duas ou três
dimensões. Como o robô Twil não é capaz de se movimentar no eixo Z,
neste trabalho só serão comparados os mapas bidimensionais criados
por ambos pacotes.

\section{Testes e coleta de dados}
\label{met:testes}

Devido à independência entre o mapeamento de custos e os demais
sistemas desenvolvidos neste trabalho, foram realizados dois tipos de
testes diferentes. Para testar o mapeamento de custo, foram criadas
trajetórias com e sem obstáculos para testar o desempenho das camadas
de obstáculos e inflação. Já para conferir o funcionamento dos
sistemas de odometria, localização e mapeamento SLAM, utilizaram-se
arquivos de gravação de tópicos do ROS 2, chamados de
\textit{rosbags}.

Estes arquivos permitem a execução de diferentes ensaios usando os
mesmos dados de entrada. Outro benefício foi o alívio na exigência de
processamento do computador utilizado, já que não foi necessário
realizar a simulação do mundo real no Gazebo e a execução dos nodos
de localização simultaneamente.

Para a criação das \textit{rosbags}, foi feito um \textit{script} em
\textit{bash} que contém todos os tópicos necessários para a execução
dos sistemas de odometria e localização, além de tópicos auxiliares
para visualização do experimento e para análise dos resultados, como
a posição real do robô publicada no tópico \texttt{/ground\_truth},
pelo \textit{plugin} P3D do Gazebo. O tópico utilizado no sistema de
odometria perfeita criado por esse mesmo \textit{plugin} difere do
tópico \texttt{ground\_truth} porque a posição publicada na odometria
é em relação ao sistema de coordenadas \texttt{odom} e não a
referência global, ou seja, \texttt{map}, como é no \textit{ground
    truth}.

Os tópicos necessários para a execução dos sistemas de estimativa de
posição estão nas Tabelas \ref{tab:odometria} e
\ref{tab:localizacao}, apresentadas anteriormente. Porém, além dos
tópicos que são inscritos explicitamente na configuração do pacote,
os sistemas de odometria e localização, que incorporam a câmera
RGB-D, também necessitam da árvore de transformações da base do robô
à câmera, contida no tópico \texttt{/tf}. Portanto, esta informação
deve estar presente durante a execução dos testes.

Uma solução para disponibilizar esta transformada seria gravar o
tópico \texttt{/tf} durante a execução da simulação. Porém, isso não
é possível, porque esse tópico já possui as transformadas entre
\texttt{map}, \texttt{odom} e \texttt{base\_link}, o que causaria
conflitos com as transformadas publicadas pelos sistemas de odometria
e localização sendo testados. Logo, deverão ser executados novamente
os mesmos nodos que disponibilizam a posição da câmera em relação a
base do robô.

A transformação das juntas do robô são publicadas pelo
\texttt{robot\_state\_publisher}. Existem dois tipos de juntas entre
a base do robô e a câmera: estáticas, que têm sua informação definida
no arquivo de descrição do robô, e dinâmicas, que são publicadas pelo
\texttt{joint\_state\_broadcaster} no tópico \texttt{/joint\_states},
conforme as configurações definidas no \texttt{twil\_bringup}. O
executável \texttt{robot\_state\_publisher} lê as informações desse
tópico e do arquivo de descrição para publicar as transformadas entre
os componentes do robô no tópico \texttt{/tf}. Portanto, para evitar
a execução do Gazebo, esse tópico foi gravado no banco de dados, e
foi executado o \texttt{robot\_state\_publisher} com o arquivo de
descrição do robô, obtendo assim, o mesmo estado do robô durante a
execução da simulação utilizada para a gravação da \textit{rosbag}.

Para facilitar a execução deste publicador de transformadas do robô e
dos sistemas de odometria e localização, foi criado um arquivo de
inicialização com os nodos necessários para realizar os testes com as
entradas provenientes da \textit{rosbag}.

Além disso, optou-se por criar outro \textit{script} em \textit{bash}
para gravar os dados dos testes realizados para análise posterior. A
criação dos gráficos foi realizado em \textit{Python}, com a
biblioteca Matplotlib a partir dos dados das \textit{rosbags}
convertidos o formato csv.

Os gráficos foram construídos utilizando os dados de posição x e y
das mensagens do tipo \texttt{nav\_msgs/Odometry}, publicadas pelos
sistemas de odometria e pelo Gazebo com a posição estimada e real do
robô. Para o sistemas de localização, foram utilizados os dados de
posição x e y das mensagens do tipo
\texttt{geometry\_msgs/PoseWithCovarianceStamped}, que são referentes
a posição global do robô calculada por esses pacotes, ou seja, a
transformada entre \texttt{map}, \texttt{odom} e \texttt{base\_link}.

O erro da estimativa de posição foi calculado através da diferença
entre a posição real e a posição estimação, conforme a Equação
\ref{eq:erro_posicao}. Utilizando os dados dos testes, foi criado um
gráfico com esse erro longo da distância real percorrida pelo robô.

\begin{equation}
    \label{eq:erro_posicao}
    d_{erro} = \sqrt{(x_{real} - x_{estimado})^2 + (y_{real} - y_{estimado})^2}
\end{equation}

\chapter{Resultados}
\label{resultados}

Neste capítulo, são apresentados os resultados dos testes realizados,
separados em seções. Primeiramente é apresentado o efeito das camadas
do mapa de custo no planejamento de trajetórias. Em seguida, as
estimativas de posição do robô, produzidas pelos sistemas de
odometria, localização são comparadas com a posição real. Finalmente,
são mostrados os mapas criados pelos sistemas SLAM.

\section{Mapeamento de custo}

Este trabalho realizou modificações em duas das três camadas do mapa
de custo utilizadas, a camada de obstáculos e a camada de inflação. A
camada estática foi mantida, utilizando a planta do prédio Centenário
da Escola de Engenharia da UFRGS, como em trabalhos antigos.

% % LTeX: enable=false
A camada de inflação porém, foi ajustada para melhorar a qualidade
dos caminhos criados, de acordo com a recomendação de
\textcite{ros_tuning_guide}. A camada de inflação original criava uma
pequena zona de segurança ao redor dos obstáculos, com uma borda de
$0,35~\si{\meter}$ e com fator de decaimento de $3,0$. Representada
na Figura \ref{fig:inflation_low}. Para criar um campo de segurança
maior, capaz de cobrir corredores inteiros, foi ajustado a borda para
$2,0~\si{\meter}$. Em razão do aumento da borda, o fator de
decaimento precisou ser ajustado para $4,0$, porque a inclinação
original fazia com que certos corredores fossem evitados.
% % LTeX: enable=true

\begin{figure}[h]
    \caption{Trajetórias criadas com diferentes configurações da camada de inflação}
    \begin{subfigure}{0.5\linewidth}
        {
            \centering
            \caption{Mapa de custo com inflação baixa.}
            \label{fig:inflation_low}
            \includegraphics[width=0.98\textwidth, height=5.5cm]{costmap_not_inflated.png}\\
        }
        % {\sourcecitation{Autor}.}
    \end{subfigure}
    \begin{subfigure}{0.5\linewidth}
        {
            \centering
            \caption{Mapa de custo com inflação alta.}
            \label{fig:inflation_high}
            \includegraphics[width=0.98\textwidth, height=5.5cm]{costmap_inflated.png}\\
        }
        % {\sourcecitation{Autor}.}
    \end{subfigure}
\end{figure}

Finalmente, foi testada a camada de obstáculos adicionada neste
trabalho, que utiliza dados da câmera RGB-D para adicionar novos
obstáculos no mapa, mostrado na Figura \ref{fig:voxel_test}. Para
realizar esse teste, foi adicionada uma caixa ao mundo do Gazebo,
durante a simulação e então foi criada uma rota que passe por esse
obstáculo, como na Figura \ref{fig:voxel_before}. Ao se aproximar
desta caixa, ela é detectada pela nuvem de pontos da câmera,
representada como pontos brancos, e é adicionada ao mapa de custo,
como é visto na Figura \ref{fig:voxel_after}.

\begin{figure}[h]
    \caption{Mapeamento de obstáculos da camada \textit{voxel}}
    \label{fig:voxel_test}
    \begin{subfigure}{0.5\linewidth}
        {
            \centering
            \caption{Mapa de custo antes da detecção do obstáculo.}
            \label{fig:voxel_before}
            \includegraphics[width=0.98\textwidth]{costmap_voxel_before.png}\\
        }
        % {\sourcecitation{Autor}.}
    \end{subfigure}
    \begin{subfigure}{0.5\linewidth}
        {
            \centering
            \caption{Mapa de custo após a detecção do obstáculo.}
            \label{fig:voxel_after}
            \includegraphics[width=0.98\textwidth]{costmap_voxel_after.png}\\
        }
        % {\sourcecitation{Autor}.}
    \end{subfigure}
\end{figure}

Percebe-se nestas duas imagens que, caso fosse utilizada uma
representação plana do ambiente, através de um feixe bidimensional na
altura da câmera, que pode ser visto em amarelo nas
Figuras~\ref{fig:voxel_before}~e~\ref{fig:voxel_after}, o obstáculo
não seria percebido, e o robô colidiria com a caixa.

\section{Testes de odometria, localização e mapeamento SLAM}

O testes de odometria, localização e mapeamento SLAM foram realizados
na mesma \textit{rosbag}, como descrito na Seção \ref{met:testes},
permitindo dessa forma, a mesma entrada em cada sistema.

Na Figura \ref{fig:base_bag}, é mostrado o robô realizando a
trajetória de testes. As setas em vermelho representam a mensagem de
odometria do mesmo, onde é indicada a pose atual dele. A linha verde
indica a trajetória planejada do robô. O caminho realizado nesse
teste começa na origem, segue em direção à porta no canto superior
direto da sala, percorre o corredor e entra na primeira sala. É
possível comparar a percepção de diferentes ambientes nesse teste,
como em corredores estreitos e salas abertas. A distância total
percorrida foi de $13,08~\si{\meter}$.

\begin{figure}[h]
    {
        \centering
        \caption{Robô durante o teste realizado.}
        \label{fig:base_bag}
        \includegraphics[width=0.99\textwidth]{base_bag_sim_zoom.png}\\
    }
    % {\sourcecitation{Autor}.}
\end{figure}

Devido ao tamanho do banco de dados em razão da captura das imagens
da câmera, não foi possível realizar uma simulação longa, que
percorresse uma grande área do mapa e retornasse ao ponto inicial,
testando assim o fechamento de laço, que é um ponto importante no
mapeamento de sistemas SLAM.

\subsection{Odometria}

Após o fim da simulação e da captura de dados, foram executados os
sistemas de odometria na gravação gerada. Neste teste, utilizou-se a
transformada estática entre os sistemas de coordenadas \texttt{map} e
\texttt{odom}, para comparar a odometria das rodas e visual.

A partir dos dados obtidos, foram criados gráficos com as estimativas
da posição do robô nos eixos X e Y em relação a origem do sistema de
coordenadas \texttt{map} dos sistemas de odometria, comparados com a
posição real do robô, e gráficos com o erro de estimativa de posição
ao longo da distância percorrida.

Importante notar que os gráficos de erro de distância apresentam um
ruído aparente. Isso ocorre devido à diferença de frequência de
publicação das mensagens de posição real e estimativa de posição.
Entre a geração de uma estimativa e outra, o erro de distância
aumenta enquanto o robô move e a estimativa não é atualizada.

A odometria das rodas, mostrada na Figura
\ref{fig:controller_odom_result}, apresentou uma grande divergência
em relação a posição real do robô, com a curva da posição estimada
inclinada para a direita, em relação a curva da posição real, como
mostra a Figura \ref{fig:odom_controller}, indicando um erro na
estimativa da orientação do robô.

O erro de orientação é especialmente indesejado porque, quando é
causado, se transforma em erro de posição lateral e aumenta sem
limite~\cite{borenstein}. Na primeira parte do trajeto, da origem até
a primeira porta, a orientação estimada divergiu constantemente,
causando uma curva exponencial do erro, como é visto na Figura
\ref{fig:odom_controller_error}. Este erro continuou crescendo até o
final do trajeto, causando uma grande divergência na posição final,
com uma distância de $6,8~\si{\meter}$ entre a posição real e a
estimada.

\begin{figure}[H]
    \caption{Resultado da odometria das rodas.}
    \label{fig:controller_odom_result}
    \begin{subfigure}{0.5\linewidth}
        {
            \centering
            \caption{Posição estimada da odometria das rodas.}
            \label{fig:odom_controller}
            \includegraphics[width=0.98\linewidth]{odom-controlador-new.png}\\
        }
        % {\sourcecitation{Autor}.}
    \end{subfigure}
    \begin{subfigure}{0.5\linewidth}
        {
            \centering
            \caption{Erro de estimativa da odometria das rodas.}
            \label{fig:odom_controller_error}
            \includegraphics[width=0.98\linewidth]{odom-controlador-error-new.png}\\
        }
        % {\sourcecitation{Autor}.}
    \end{subfigure}
\end{figure}

Por outro lado, a odometria visual, mostrada na Figura
\ref{fig:visual_odom_result}, apresentou um resultado satisfatório.
No gráfico da posição estimada, da Figura \ref{fig:odom_visual},
mostra que ocorreu a mesma inclinação para a direita que a odometria
das rodas, porém menos acentuada. Em alguns pontos da trajetória no
corredor, a posição estimada coincide com a posição real. Porém, a
estimativa de posição nesses pontos pode ter ocorrido em momentos
diferentes ao da posição real, já que este gráfico não apresenta
informação do tempo. Deve ser então analisado o gráfico do erro de
estimativa, representado na Figura \ref{fig:odom_visual_error}, que
mostra aumento do erro de estimativa ao longo do trajeto do corredor,
expondo que os pontos de coincidência entre a posição real e a
estimada não foram publicados no mesmo instante.

O erro de estimativa dessa odometria atingiu um pico de
$0,8~\si{\meter}$ no final do corredor, diminuiu enquanto o robô
percorria a curva final, e finalmente aumentou novamente atingindo um
erro de $0,66~\si{\meter}$ no final do trajeto.

\begin{figure}[H]
    \caption{Resultado da odometria visual.}
    \label{fig:visual_odom_result}
    \begin{subfigure}{0.5\linewidth}
        {
            \centering
            \caption{Posição estimada da odometria visual.}
            \label{fig:odom_visual}
            \includegraphics[width=0.98\linewidth]{odom-visual-new.png}\\
        }
        % {\sourcecitation{Autor}.}
    \end{subfigure}
    \begin{subfigure}{0.5\linewidth}
        {
            \centering
            \caption{Erro de estimativa da odometria visual.}
            \label{fig:odom_visual_error}
            \includegraphics[width=0.98\linewidth]{odom-visual-error-new.png}\\
        }
        % {\sourcecitation{Autor}.}
    \end{subfigure}
\end{figure}

\subsection{Localização}

Como a odometria visual apresentou um resultado satisfatório, ela foi
utilizada em conjunto com os sistemas de localização, onde é testado
o ajuste dos erros de odometria pelo sistema de localização.
Portanto, foram criados novos gráficos, adicionando a posição global
estimada pelos sistemas de localização. Essa posição é obtida através
da transformada entre \texttt{map}, \texttt{odom} e
\texttt{base\_link}.

A Figura \ref{fig:rtabmap_slam_result} mostra o resultado do sistema
de localização do pacote \texttt{rtabmap\_slam}. A localização neste
caso aprimorou levemente a estimativa de posição, diminuindo o erro
para $0,63~\si{\meter}$ na final do trajeto. É possível perceber pelo
gráfico da Figura \ref{fig:localization_rtabmap_error} que a curva do
erro manteve a mesma forma da curva do erro da odometria visual.
Porém, houve menos ruído na estimativa de posição durante a curva,
como mostra a Figura \ref{fig:localization_rtabmap}.

\begin{figure}[H]
    \caption{Resultado do pacote \texttt{rtabmap\_slam}.}
    \label{fig:rtabmap_slam_result}
    \begin{subfigure}{0.5\linewidth}
        {
            \centering
            \caption{Posição estimada do \texttt{rtabmap\_slam}.}
            \label{fig:localization_rtabmap}
            \includegraphics[width=0.98\linewidth]{localization-rtabmap-new.png}\\
        }
        % {\sourcecitation{Autor}.}
    \end{subfigure}
    \begin{subfigure}{0.5\linewidth}
        {
            \centering
            \caption{Erro de estimativa do \texttt{rtabmap\_slam}.}
            \label{fig:localization_rtabmap_error}
            \includegraphics[width=0.98\linewidth]{localization-rtabmap-error-new.png}\\
        }
        % {\sourcecitation{Autor}.}
    \end{subfigure}
\end{figure}

O \texttt{slam\_toolbox}, que tem seu resultado representado na
Figura \ref{fig:slam_toolbox_result}, por outro lado, apresentou um
resultado mais preciso, diminuindo o erro de estimativa para
aproximadamente $0,37~\si{\meter}$ no final da trajetória. Isto
aconteceu, em grande parte, porque não houve o acumulo de erro
durante o trajeto do corredor, como mostra a Figura
\ref{fig:localization_slam_toolbox_error}, que havia acontecido na
odometria visual. A Figura \ref{fig:localization_slam_toolbox} mostra
que o ruído na estimativa de posição durante a curva foi atenuado da
mesma forma que o \texttt{rtabmap\_slam}.

\begin{figure}[H]
    \caption{Resultado do pacote \texttt{slam\_toolbox}.}
    \label{fig:slam_toolbox_result}
    \begin{subfigure}{0.5\linewidth}
        {
            \centering
            \caption{Posição estimada do \texttt{slam\_toolbox}.}
            \label{fig:localization_slam_toolbox}
            \includegraphics[width=0.98\linewidth]{localization-slam-toolbox-new.png}\\
        }
        % {\sourcecitation{Autor}.}
    \end{subfigure}
    \begin{subfigure}{0.5\linewidth}
        {
            \centering
            \caption{Erro de estimativa do \texttt{slam\_toolbox}.}
            \label{fig:localization_slam_toolbox_error}
            \includegraphics[width=0.98\linewidth]{localization-slam-toolbox-error-new.png}\\
        }
        % {\sourcecitation{Autor}.}
    \end{subfigure}
\end{figure}

Nota-se que, apesar de utilizar a mesma entrada em todas execuções da
simulação, a odometria visual apresentou resultados ligeiramente
diferentes em cada execução. Isso acontece porque a máquina utilizada
para a execução não possui capacidade de processamento suficiente
para realizar os cálculos necessários por estes pacotes na frequência
configurada. Na execução com o texttt{slam\_toolbox}, que exige alta
capacidade de processamento, esse problema foi mais evidente. Os
algoritmos de SLAM também não puderam ser executados na frequência
desejada. Portanto, em máquinas mais potentes, a estimativa de
posição pode ser mais precisa.

\subsection{Mapeamento SLAM}

Como mencionado anteriormente, os dois sistemas de localização
utilizados realizam o mapeamento simultaneamente com a localização.
Portanto, tanto o \texttt{slam\_toolbox}, quanto o
\texttt{rtabmap\_slam} geraram um mapa do ambiente durante a execução
da simulação. Estes mapas podem ser utilizados para novas sessões de
localização, ou em mapas de custo para planejamento de trajetória.

Na Figura \ref{fig:mapping_rtabmap}, é mostrado o mapa gerado pelo
\texttt{rtabmap\_slam}, que foi criado utilizando os dados
tridimensionais da câmera RGB-D, enquanto que na Figura
\ref{fig:mapping_slam_toolbox} é mostrado o mapa produzido pelo
\texttt{slam\_toolbox}, que usa um feixe de luz plano, obtido através
da conversão da imagem de profundidade da câmera. A representação do
ambiente no Gazebo foi sobreposta aos mapas para facilitar a
comparação. Nestes mapas, as áreas em branco são áreas livres, e as
áreas em preto são consideradas ocupadas, enquanto que as áreas em
cinza são desconhecidas.

\begin{figure}[H]
    {
        \centering
        \caption{Mapa construído pelo \texttt{rtabmap\_slam}.}
        \label{fig:mapping_rtabmap}
        \includegraphics[width=0.8\linewidth]{rtabmap_slam_map-compared.png}\\
    }
    % {\sourcecitation{Autor}.}
\end{figure}

\begin{figure}[H]
    {
        \centering
        \caption{Mapa construído pelo \texttt{slam\_toolbox}.}
        \label{fig:mapping_slam_toolbox}
        \includegraphics[width=0.6\linewidth]{slam_toolbox_map-compared.png}\\
    }
    % {\sourcecitation{Autor}.}
\end{figure}

É possível perceber diferenças na geração destes mapas devido ao
tipo de mensagem utilizado. O mapa gerado pelo \texttt{rtabmap\_slam}
elabora um representação mais detalhada da escada, percebendo-a desde
sua base, enquanto que o \texttt{slam\_toolbox} só mapeia a escada na
mesma altura da câmera, que é a altura da mensagem passada a ela.
Além disso, o \texttt{rtabmap\_slam} mapeou as molduras das portas,
que estão acima da altura da câmera. Este comportamento, porém,
pode ser modificado, já que não são obstáculos relevantes para a
navegação.

Outro diferença é no mapeamento do chão. Devido ao campo de visão da
câmera, não é captado o chão em frente ao robô, que portanto não é
mapeado pelo \texttt{rtabmap\_slam}. Por outro lado, como o
\texttt{slam\_toolbox} utiliza um feixe de luz em duas dimensões, é
considerado que todo espaço entre o robô e o primeiro obstáculo
detectado é livre, mapeando assim o chão não captado pela câmera. Em
situações em que não é detectado nenhum obstáculo dentro do limite da
câmera, como a área entre o final da trajetória do robô e a porta da
sala no canto superior direito da Figura
\ref{fig:mapping_slam_toolbox}, o chão não é mapeado.

Percebe-se, também, que o mapa gerado pelo \texttt{slam\_toolbox} é
mais fiel quanto a posição das paredes do ambiente real, já que o
mapa gerado pelo \texttt{rtabmap\_slam} possui uma inclinação que não
corresponde ao ambiente real. Isso é devido a estimativa da posição
do robô, apresentadas anteriormente, em que o \texttt{slam\_toolbox}
apresentou uma estimativa mais precisa.

\chapter{Discussão}
\label{discussao}

Os resultados obtidos mostram que a utilização da câmera no robô Twil
permite o mapeamento do ambiente em tempo-real, possibilitando a
navegação autônoma do robô em locais desconhecidos ou com obstáculos
dinâmicos. Isso foi realizado através da atualização do mapa de
custos usado pelo planejador de trajetórias. Com uma camada
\textit{voxel}, responsável por detectar obstáculos tridimensionais
no ambiente, e uma camada de inflação, que cria uma zona de segurança
ao redor dos obstáculos, o robô é capaz de evitar colisões. Este
sistema pode ser aprimorado com a utilização de outras camadas do
mapa de custo, como a camada \textit{Spatio Temporal Voxel
    Layer}~\cite{stlv_article}, que adiciona um decaimento temporal ao
obstáculos detectados, já que eles podem ser temporários.

Além disso, a câmera aprimorou a estimativa de posição do robô, que
permite o seguimento correto da trajetória planejada, recomendando-se
a combinação de odometria visual com o sistema de localização
\texttt{slam\_toolbox} para esta aplicação.

A escolha da odometria é feita em razão do desempenho superior da
odometria visual em relação a odometria das rodas. Porém, a odometria
das rodas apresentou um resultado pior do que o esperado, podendo ser
causado por erros na descrição do robô, o que pode ser ajustado. Além
disso, a odometria visual pode apresentar resultados inferiores em
ambientes reais, já que o teste em simulação é feito em condições
ideias, sem a presença de ruído.

Logo, em trabalhos futuros, recomenda-se ajustes no sistema de
odometria das rodas, para garantir uma estimativa mais precisa da
posição do robô. O erro de orientação apresentado neste estimativo é
grave, já que cria uma divergência sem limite. Para mitigar este
erro, é possível utilizar as informações de velocidade angular e
orientação do IMU presente no robô para calcular a estimativa de
posição.

Isto pode ser feito com o pacote \texttt{robot\_localization},
desfazendo-se dos dados da posição dada pela mensagem publicada pela
odometria das rodas. Desta forma, a posição do robô seria calculada
utilizando a velocidade linear das rodas e a orientação do IMU,
possibilitando a obtenção de uma estimativa com menor erro. Porém, a
velocidade publicada pela odometria das rodas deve ser modificada
para ser em relação a base do robô, como é esperado pelo
\texttt{robot\_localization}, e não em relação ao sistema de
coordenadas \texttt{odom}, como é publicada atualmente.

Com a odometria das rodas ajustada, ambos sistemas de odometria devem
ser comparados novamente. Em caso de desempenho semelhante,
recomenda-se a utilização da odometria das rodas por ser mais
simples, desta forma, exigindo menor complexidade de processamento.
Porém, caso a exigência computacional não seja um problema, ambas
estimativas podem ser utilizadas em conjunto, fundidas através de um
filtro de Kalman para obter uma pose mais precisa.

Em relação ao mapeamento, o pacote \texttt{rtabmap\_slam} criou um
mapa mais detalhado do ambiente, devido a utilização de dados
tridimensionais. Porém, isto não afetou o desempenho da navegação,
com o \texttt{slam\_toolbox} apresentando uma melhor estimativa de
posição. Portanto, caso seja desejado um mapa do ambiente mais
detalhado, recomenda-se a utilização do \texttt{rtabmap\_slam}, em
uma gravação, e não durante a navegação em tempo-real, da mesma forma
que foi feito neste trabalho.

Além disso, devem ser realizados testes de SLAM que percorram um
caminho que revisite áreas já vistas, para testar o fechamento de
laço. Não foi possível testar isto neste trabalho, porque a execução
da simulação em conjunto com os sistemas de odometria e localização
exigiu muita capacidade de processamento, e os arquivos de dados, que
permitem separar a execução destes sistemas, não são praticáveis em
trajetórias longas, devido ao armazenamento necessário.

\chapter{Conclusões}
\label{conclusao}

Este trabalho atingiu o objetivo proposto de mapear o ambiente para
navegação autônoma utilizando a câmera RGB-D do robô Twil, para
evitar colisões em ambientes dinâmicos ou pouco conhecidos. Isso foi
feito através da atualização do mapa de custo utilizado pelo
planejador de trajetórias, com a adição de uma camada \textit{voxel}
ao mapa de custo, responsável por detectar obstáculos tridimensionais
no ambiente. Além disso, a câmera aprimorou a estimativa de posição
do robô, que permite o seguimento correto da trajetória planejada,
recomendando-se a combinação de odometria visual com o sistema de
localização \texttt{slam\_toolbox}. Porém, a navegação foi testada
apenas em ambiente simulado, já que o sistema não foi implementado no
robô real.

Em trabalhos futuros, os componentes aqui desenvolvidos podem ser
aplicado no robô real. Para isso, o Gazebo deverá ser dispensado e os
dados deverão todos ser obtidos através do mundo real. Porém,
primeiramente devem ser realizados ajustes na odometria das rodas,
como detalhado anteriormente.

Ao implementar o sistema no robô real, é possível que seja necessária
uma recalibração dos sistemas de odometria e localização. Neste caso,
recomenda-se a utilização dos \textit{scripts} de gravação de
\textit{rosbags} produzidos neste trabalho para coleta e análise dos
dados para calibração, já que os tópicos publicados pelo robô real e
simulado devem ser os mesmos.

\printbibliography

%\begin{appendix}
%
%\end{appendix}
%
%
%\begin{annex}
%\end{annex}

\end{document}