Documentation: Correção do nome do orientador

Code/Analyzer.m

@@ -1,6 +1,6 @@
 close all; clc;
 hold on;
-title("desiredSpeed = 100m/s, threshold = 2m/s²");
+title("desiredSpeed = 1.0m/s");
 xlabel("Amostra (10ms)");
 ylabel("Aceleração (m/s²)")
 plot(encoderAccel);
@@ -11,7 +11,7 @@ ylabel("Velocidade referência (m/s)");
 plot(desiredSpeed1);
 ax.YAxis(1).Limits = [-15, 15];
 ax.YAxis(1).Color = [0, 0, 0];
-ax.YAxis(2).Limits = [-100, 100];
+ax.YAxis(2).Limits = [-1, 1];
 ax.YAxis(2).Color = [0, 0, 0];
 ax.XAxis.Limits = [0, 500];
 legend({'encoderAccel (m/s²)','imuAccel (m/s²)', 'desiredSpeed (m/s)'},'Location','southwest')

Code/pidTuner/AnalyzerPidTuner.m

@@ -0,0 +1,12 @@
+close all; clc;
+hold on;
+% title("desiredSppeed = 100");
+xlabel("Amostra (10ms)");
+ylabel("Velocidade (m/s)")
+plot(StepResponse3SClean);
+ax = gca;
+ax.YAxis(1).Limits = [0, 2];
+ax.YAxis(1).Color = [0, 0, 0];
+ax.XAxis.Limits = [0, 100];
+legend({'Velocidade (m/s)'},'Location','southwest')
+hold off;

Code/pidTuner/AnalyzerPidTuner2.m

@@ -0,0 +1,14 @@
+close all; clc;
+hold on;
+% title("desiredSppeed = 100");
+plot([0:0.01:2.67], StepResponse3SClean, "red");
+stepResponse = step(Differential3S, [0:0.01:2.67]);
+plot([0:0.01:2.67], stepResponse, "blue");
+xlabel("Tempo(s)");
+ylabel("Velocidade (m/s)")
+ax = gca;
+ax.YAxis(1).Limits = [0, 2];
+ax.YAxis(1).Color = [0, 0, 0];
+ax.XAxis.Limits = [0, 1];
+legend({'Velocidade medida (m/s)', 'Velocidade simulada (m/s)'},'Location','southwest')
+hold off;

Documentation/abntex2ime/conclusao.tex

@@ -1,5 +1,6 @@
 \chapter{Conclusão}
-\par Foi desenvolvido um \textit{firmware} capaz de ser portado para os três modelos de robô citados no capítulo \ref{chap:intro}, incluindo a otimização do controle PID para o robô de desenvolvimento.
+\label{chap:conclusao}
+\par Foi desenvolvido um \textit{firmware} capaz de ser portado para os três modelos de robô citados no capítulo \ref{chap:contexto}, incluindo a otimização do controle PID para o robô de desenvolvimento.
 \par Foram também desenvolvidas lógicas para detecção e correção de deslizamentos, testadas no robô de desenvolvimento com uma das rodas modificada para diminuição do coeficiente de atrito, o que evidencia a perda de direção provocada pelo deslizamento.
 
 \section{Perspectivas}
@@ -18,10 +19,10 @@
 \par Para que a detecção e a correção dos deslizamentos também seja possível em casos de arrancadas e frenagens em curvas, é necessário adaptar os cálculos para um problema bidimensional, onde deve ser considerada a aceleração angular do movimento, não apenas a tangente.
 
 \subsection{Integração ao robô da SSL (solução tridimensional)}
-\par Para integrar o projeto ao robô da SSL é necessário fazer adaptações no firmware, tendo em vista que o robô da SSL utiliza um microcontrolador de modelo diferente, porém do mesmo fabricante e da mesma família. Além disso, como o robô da SSL movimenta-se com rodas omnidirecionais, será necessário também adaptar os cálculos da dinâmica e da comparação, sendo necessário considerar também a aceleração normal do movimento, não só a angular e a tangente.
+\par Para integrar o projeto ao robô da SSL é necessário fazer adaptações no \textit{firmware}, tendo em vista que o robô da SSL utiliza um microcontrolador de modelo diferente, porém do mesmo fabricante e da mesma família. Além disso, como o robô da SSL movimenta-se com rodas omnidirecionais, será necessário também adaptar os cálculos da dinâmica e da comparação, sendo necessário considerar também a aceleração normal do movimento, não só a angular e a tangente.
 
 \subsection{Melhorias nos filtros}
-\par Os filtros passa-baixa aplicados às leituras do IMU e do encoder provocaram atrasos diferentes nas medições, o que levou a alguns falsos positivos na detecção do deslizamento. Uma possível melhoria é uma melhor implementação dos filtros que faça com que eles tenham atrasos semelhantes e, preferencialmente, menores do que os atuais.
+\par Os filtros passa-baixa aplicados às leituras do IMU e do \textit{encoder} provocaram atrasos diferentes nas medições, o que levou a alguns falsos positivos na detecção do deslizamento. Uma possível melhoria é uma melhor implementação dos filtros que faça com que eles tenham atrasos semelhantes e, preferencialmente, menores do que os atuais.
 
 \subsection{Implementação standalone no robô}
 \par Atualmente, A detecção e a correção do deslizamento estão implementados no programa de LabVIEW, executado no computador. A implementação das lógicas de detecção e correção, incluindo seus filtros, no robô, pode trazer reações mais rápidas do robô ao deslizamento, o que pode melhorar ainda mais os resultados das medidas corretivas.

Documentation/abntex2ime/contexto.tex

@@ -0,0 +1,142 @@
+% ----------------------------------------------------------
+% Introdução (exemplo de capítulo sem numeração, mas presente no Sumário)
+% ----------------------------------------------------------
+\chapter{Contexto}
+\label{chap:contexto}
+\section{Projeto SVTRP}
+% ----------------------------------------------------------
+
+\begin{figure}[!ht]
+	\centering
+	\includegraphics[width=0.75\textwidth]{img/PrimeiroPrototipo.jpg}   
+	\caption{Primeiro protótipo de SVTRP do CTEx}
+	\label{fig:primeiroprototipo}
+\end{figure}
+
+\par Atualmente, já foi desenvolvido pelo CTEx o primeiro protótipo da plataforma de SVTRP, representado na figura \ref{fig:primeiroprototipo}, e o segundo protótipo ainda está em desenvolvimento. Dessa forma, foi decidido tomar o primeiro protótipo como base para o desenvolvimento do presente projeto de fim de curso.
+
+% Conferir dimensões com o pessoal do CTEx
+
+\begin{figure}[!ht]
+	\centering
+	\includegraphics[width=\textwidth]{img/DiagramaBlocosCTEx-crop.pdf}   
+	\caption{Diagrama de blocos do SVTRP do CTEx}
+	\label{fig:diagramablocosctex}
+\end{figure}
+
+\par A plataforma SVTRP do CTEx possui quatro rodas paralelas fixas, tornando-se, assim, uma plataforma de movimento diferencial. Todos os motores são alimentados por pontes H e possuem \textit{encoder} para medição de posição angular relativa, o que possibilita o controle de malha fechada da velocidade. Possui também um sensor inercial (IMU) de seis graus de liberdade (6-dof) contendo acelerômetro e giroscópio, mas que não contém bússola. Portanto, não é capaz de determinar sua orientação absoluta. Possui também um receptor GPS para determinação da posição global com precisão de alguns metros.
+\par O microcontrolador responsável pelo controle de velocidade e também pela comunicação com os sensores é o STM32F103 "BluePill". É um modelo barato e facilmente encontrado no mercado nacional, porém de capacidade computacional suficiente para controle PID em malha fechada de motores com escovas e para comunicação com os sensores.
+\par Além disso, o SVTRP do CTEx embarca um computador Jetson nano, responsável pela captação de imagens com as câmeras e pelo processamento do algoritmo de \textit{Simultaneous Location and Mapping} (SLAM).
+\par Todo o conjunto é alimentado por uma bateria de polímero de lítio (LiPo), com tensão regulada por um regulador chaveado de 3.3V.
+
+\par As especificações da plataforma do CTEx podem ser vistas na tabela \ref{tab:specssvtrp} e seu diagrama de blocos na figura \ref{fig:diagramablocosctex}.
+
+\begin{table}[ht]
+\centering
+\caption{Especificações do primeiro protótipo SVTRP}
+\vspace{0.5cm}
+\begin{tabular}{r|lr}
+ 
+Componente       & Especificação                  \\
+\hline
+Computador       & Nvidia Jetson Nano             \\
+Microcontrolador & STMicroelectronics STM32F103C8 \\
+Ponte H          & STMicroelectronics VNH2SP30    \\
+Sensor IMU       & InvenSense MPU6050             \\
+Sensor GPS       & u-blox NEO-6M-0-001            \\
+Motores          & Pololu 37Dx68L                       
+ 
+\end{tabular}
+\label{tab:specssvtrp}
+\end{table}
+
+\section{Robôs para a competição SSL da RoboCup}
+\par Devido às semelhanças mecânica e eletrônica entre os robôs de futebol de robôs categoria \textit{Small Size League} (SSL) do IME, representado na figura \ref{fig:ssl2018} e a plataforma de SVTRP do CTEx, e aos problemas semelhantes enfrentados por ambos, foi levantada a possibilidade de desenvolver uma solução que atenda ambas as plataformas robóticas. Assim, tanto os interesses da equipe de robótica do IME (RoboIME), quanto do CTEx, poderão ser atendidos pelo mesmo projeto.
+
+\begin{figure}[!ht]
+	\centering
+	\includegraphics[width=0.75\textwidth]{img/SSL2018.jpg}   
+	\caption{Robô de SSL do IME, sem carenagem}
+	\label{fig:ssl2018}
+\end{figure}
+\par A competição SSL é realizada anualmente no evento internacional RoboCup. Consiste em partidas de futebol entre equipes de robótica de diversas universidades. Nesta competição, as partidas são disputadas por um time de até seis robôs autônomos, que são controlados pelo computador da equipe (\textit{Team computer}), o qual não pode ser operado durante a execução do jogo. Sobre o campo existe uma câmera conectada a um computador (\textit{Vision computer}) responsável por processar as imagens e reconhecer os padrões de cores das carenagens dos robôs de ambos os times, assim como da bola. Estas informações são enviadas para os computadores de ambas as equipes, responsáveis por tomar as decisões e calcular as estratégias de jogo. Uma ilustração pode ser vista na figura \ref{fig:topologiassl}
+
+\begin{figure}[!ht]
+	\centering
+	\includegraphics[width=0.75\textwidth]{img/DiagramaSSL-crop.pdf}   
+	\caption{Topologia de uma partida de SSL}
+	\label{fig:topologiassl}
+\end{figure}
+
+
+
+\par O robô de SSL do IME foi desenvolvido visando atender ao regulamento \cite{SSLRules2023} da competição RoboCup 2023. Sendo assim, deve caber dentro de um cilindro com $180 mm$ de diâmetro e $150 mm$ de altura. Deve ser capaz de atingir velocidades de até 4m/s e de chutar a bola a uma velocidade de até $6,5 m/s$.
+\par Possui quatro rodas omnidirecionais, como a da figura \ref{fig:rodassl2018}, dispostas nos ângulos representados na figura \ref{fig:angulossl2018}. Sendo assim, é capaz de se movimentar em três graus de liberdade, chamados aqui de tangente, normal e angular, conforme a figura \ref{fig:cinematicassl}. As rodas dianteiras estão anguladas em $30^\circ$ em relação à direção do movimento tangente, enquanto as traseiras estão em um ângulo de $45^\circ$. Isso torna o movimento tangente mais preciso do que o movimento normal. As rodas são acopladas aos motores por uma redução de $4:1$, e possuem rodilhas dispostas de forma alternada, conforme a figura \ref{fig:rodilhassl2018}.
+
+\begin{figure}[!ht]
+	\centering
+	\includegraphics[width=0.75\textwidth]{img/RodaOmni.jpg}   
+	\caption{Roda omnidirecional do robô de SSL do IME}
+	\label{fig:rodassl2018}
+\end{figure}
+
+\begin{figure}[!ht]
+	\centering
+	\includegraphics[width=0.75\textwidth]{img/AngulosRodas.png}   
+	\caption{Disposição das rodas no robô de SSL}
+	\label{fig:angulossl2018}
+\end{figure}
+
+\begin{figure}[!ht]
+	\centering
+	\includegraphics[width=0.5\textwidth]{img/Cinematica.png}   
+	\caption{Cinemática do robô de SSL}
+	\label{fig:cinematicassl}
+\end{figure}
+
+\begin{figure}[!ht]
+	\centering
+	\includegraphics[width=0.75\textwidth]{img/RodilhaSSL2018.jpg}   
+	\caption{Rodilhas do robô de SSL do IME}
+	\label{fig:rodilhassl2018}
+\end{figure}
+
+\par Todos os motores são do tipo DC \textit{brushed} (com escovas), e possuem \textit{encoder} de 52 contagens por rotação (CPR) para medição de posição angular relativa. Assim, o robô emprega controle PID em malha fechada para a velocidade de cada uma das rodas, individualmente. São alimentados por uma ponte H da figura \ref{fig:ponteh2016} desenvolvida também pela equipe RoboIME \cite{TDPRoboIME2017}.
+
+\begin{figure}[!ht]
+	\centering
+	\includegraphics[width=0.75\textwidth]{img/PonteH2016.jpg}   
+	\caption{Pontes H RoboIME 2016}
+	\label{fig:ponteh2016}
+\end{figure}
+
+\begin{figure}[!ht]
+	\centering
+	\includegraphics[width=\textwidth]{img/DiagramaBlocosSSL2018-crop.pdf}   
+	\caption{Diagrama de blocos do Robô de SSL do IME}
+	\label{fig:diagramablocosssl2018}
+\end{figure}
+
+\par Conforme o diagrama da figura \ref{fig:diagramablocosssl2018}, o microcontrolador utilizado é um STM32F407VG, da mesma família daquele empregado no SVTRP do CTEx. Dessa forma, o \textit{firmware} desenvolvido para um dos robôs pode ser facilmente adaptado para o outro, sendo necessárias apenas pequenas alterações de compatibilidade. Para comunicação com o computador, o robô utiliza um rádio $2.4 GHz$ modelo Semtech SX1280, embarcado em um módulo Ebyte E28-2G4M27S. Este rádio é capaz de se comunicar a distâncias de centenas de metros em campo aberto, a taxas de até $1.3 Mbps$.
+\par Possui um sensor IMU com nove graus de liberdade (9-dof), contendo acelerômetro, giroscópio e magnetômetro. Portanto, é capaz de determinar sua orientação absoluta, porém incapaz de determinar posição absoluta sem ajuda de sistema de câmeras externo por não possuir GPS. 
+
+\begin{table}[ht]
+\centering
+\caption{Especificações do robô de SSL do IME}
+\vspace{0.5cm}
+\begin{tabular}{r|lr}
+ 
+Componente         & Especificação                  \\
+\hline
+Bateria            & LiPo 3S 2200mAh                \\
+Microcontrolador   & STMicroelectronics STM32F407VG \\
+Ponte H            & RoboIME 2016                   \\
+Módulo de chute    & RoboIME 2022                   \\
+Sensor IMU         & InvenSense MPU9250             \\
+Sensor de corrente & Texas Instruments INA169NA     \\
+Rádio              & Ebyte E28-2G4M27S              \\
+Motores            & Generic JGB37-520                       
+ 
+\end{tabular}
+\label{tab:specsssl2018}
+\end{table}

Documentation/abntex2ime/dados.tex

@@ -45,7 +45,7 @@
 \keywords{robot, ssl, control systems, embedded systems, unmanned vehicles, microcontrollers}
 % ---
 \autores{Gabriel Martins}{Lima}% {nome}{sobrenome} 1+
-\orientadores{Alberto}{Simões}{Dr.ISAE}%{nomes}{sobrenomes}{títulos} 1+
+\orientadores{Alberto}{ Mota Simões}{Dr.ISAE}%{nomes}{sobrenomes}{títulos} 1+
 % ---
 \local{Rio de Janeiro}
 \data{2023}

Documentation/abntex2ime/intro.tex

@@ -1,197 +1,21 @@
-% ----------------------------------------------------------
-% Introdução (exemplo de capítulo sem numeração, mas presente no Sumário)
-% ----------------------------------------------------------
 \chapter{Introdução}
 \label{chap:intro}
-\section{Projeto SVTRP}
-% ----------------------------------------------------------
-\par O projeto de um sistema de viaturas terrestres remotamente pilotadas (SVTRP) é um dos projetos estratégicos desenvolvidos pelo Centro Tecnológico do Exército (CTEx) para o exército brasileiro, que tem por objetivo construir um pequeno veículo para vigilância e mapeamento de ambientes hostis e desconhecidos.
+\par O projeto de um sistema de viaturas terrestres remotamente pilotadas (SVTRP) é um dos projetos estratégicos desenvolvidos pelo Centro Tecnológico do Exército (CTEx) para o exército brasileiro, que tem por objetivo construir um pequeno veículo para vigilância e mapeamento de ambientes hostis e desconhecidos. Nesse sentido, plataformas robóticas móveis terrestres, como o SVTRP do CTEx, requerem que a velocidade e aceleração das rodas sejam controladas com precisão, a fim de permitir um movimento preciso e facilitar a pilotagem pelo operador. Além disso, um controle preciso das velocidades e acelerações permite o funcionamento autônomo do robô, o que é essencial em ambientes onde a comunicação sem fio não é possível, ou que seu uso traria consequências negativas estratégicas.
+\par Dessa forma, uma maneira de garantir a precisão do movimento do robô é pelo uso de um controle de malha fechada para a velocidade das rodas, o que aproxima a velocidade de cada roda de uma velocidade de referência fornecida pelo operador ou pelo algoritmo de operação autônoma, o que garante que a trajetória do robô seja próxima àquela desejada. Por outro lado, um problema muito comum enfrentado por robôs controlados por malha fechada é a perda de direção nos casos de aceleração e frenagem quando uma das rodas perde a tração, causando uma derrapagem. Neste caso, ocorrerá uma perda de direção que não é tratada pelos sistemas de controle em malha fechada convencionais, sendo necessário um sistema de controle específico para evitar e corrigir as condições de derrapagem.
+\par Este projeto do CTEx é bastante semelhante aos robôs desenvolvidos pela equipe RoboIME para a competição RoboCup Small Size League (SSL), já que ambos utilizam motores DC com escovas para movimentação, utilizam microcontroladores da mesma família, circuitos de potência e alimentação similares e são de tamanhos e massas semelhantes. Sendo assim, propõe-se desenvolver uma metodologia de desenvolvimento e projeto de sistema de controle linear que possa ser aplicada em ambas as plataformas robóticas.
 
-\begin{figure}[!ht]
-	\centering
-	\includegraphics[width=0.75\textwidth]{img/PrimeiroPrototipo.jpg}   
-	\caption{Primeiro protótipo de SVTRP do CTEx}
-	\label{fig:primeiroprototipo}
-\end{figure}
+\par Este documento apresenta no capítulo \ref{chap:contexto} as características, especificações e limitações dos robôs a terem seus sistemas de controle desenvolvidos. Em seguida, o capítulo \ref{chap:teoria} mostra a teoria envolvida nos sistemas de controle, bem como as peculiaridades de sua implementação no \textit{hardware} dos robôs. O capítulo \ref{chap:problema} descreve os problemas enfrentados pelos robôs com sistemas de controle convencionais, bem como descreve melhor os objetivos deste trabalho. Posteriormente, o capítulo \ref{chap:solucao} mostra as soluções propostas para os problemas de deslizamento, além de uma metodologia para desenvolvimento e calibração do sistema de controle convencional melhor do que a utilizada atualmente. Por fim, no capítulo \ref{chap:resultados} são discutidos os resultados obtidos com a aplicação do sistema de detecção de deslizamentos bem como com as medidas corretivas.
 
-\par Atualmente, já foi desenvolvido pelo CTEx o primeiro protótipo da plataforma de SVTRP, representado na figura \ref{fig:primeiroprototipo}, e o segundo protótipo ainda está em desenvolvimento. Dessa forma, foi decidido tomar o primeiro protótipo como base para o desenvolvimento do presente projeto de fim de curso.
+\section{Objetivos do trabalho}
+\subsection{Objetivo geral}
+\par O presente trabalho de fim de curso tem por objetivo desenvolver uma metodologia para projeto de sistemas de controle para ambos os robôs capazes de resolver os problemas de perda de direção relacionados à perda de tração. Todo o material desenvolvido neste trabalho encontra-se no repositório em \cite{gitgmlima}
 
-% Conferir dimensões com o pessoal do CTEx
-
-\begin{figure}[!ht]
-	\centering
-	\includegraphics[width=\textwidth]{img/DiagramaBlocosCTEx-crop.pdf}   
-	\caption{Diagrama de blocos do SVTRP do CTEx}
-	\label{fig:diagramablocosctex}
-\end{figure}
-
-\par A plataforma SVTRP do CTEx possui quatro rodas paralelas fixas, tornando-se, assim, uma plataforma de movimento diferencial. Todos os motores são alimentados por pontes H e possuem encoder para medição de posição angular relativa, o que possibilita o controle de malha fechada da velocidade. Possui também um sensor inercial (IMU) de seis graus de liberdade (6-dof) contendo acelerômetro e giroscópio, mas que não contém bússola. Portanto, não é capaz de determinar sua orientação absoluta. Possui também um receptor GPS para determinação da posição global com precisão de alguns metros.
-\par O microcontrolador responsável pelo controle de velocidade e também pela comunicação com os sensores é o STM32F103 "BluePill". É um modelo barato e facilmente encontrado no mercado nacional, porém de capacidade computacional suficiente para controle PID em malha fechada de motores com escovas e para comunicação com os sensores.
-\par Além disso, o SVTRP do CTEx embarca um computador Jetson nano, responsável pela captação de imagens com as câmeras e pelo processamento do algoritmo de Simultaneous Location and Mapping (SLAM).
-\par Todo o conjunto é alimentado por uma bateria de polímero de lítio (LiPo), com tensão regulada por um regulador chaveado de 3.3V.
-
-\par As especificações da plataforma do CTEx podem ser vistas na tabela \ref{tab:specssvtrp} e seu diagrama de blocos na figura \ref{fig:diagramablocosctex}.
-
-\begin{table}[ht]
-\centering
-\caption{Especificações do primeiro protótipo SVTRP}
-\vspace{0.5cm}
-\begin{tabular}{r|lr}
- 
-Componente       & Especificação                  \\
-\hline
-Computador       & Nvidia Jetson Nano             \\
-Microcontrolador & STMicroelectronics STM32F103C8 \\
-Ponte H          & STMicroelectronics VNH2SP30    \\
-Sensor IMU       & InvenSense MPU6050             \\
-Sensor GPS       & u-blox NEO-6M-0-001            \\
-Motores          & Pololu 37Dx68L                       
- 
-\end{tabular}
-\label{tab:specssvtrp}
-\end{table}
-
-\section{Robôs para a competição SSL da RoboCup}
-\par Devido às semelhanças mecânica e eletrônica entre os robôs de futebol de robôs categoria Small Size League (SSL) do IME, representado na figura \ref{fig:ssl2018} e a plataforma de SVTRP do CTEx, e aos problemas semelhantes enfrentados por ambos, foi levantada a possibilidade de desenvolver uma solução que atenda ambas as plataformas robóticas. Assim, tanto os interesses da equipe de robótica do IME (RoboIME), quanto do CTEx, poderão ser atendidos pelo mesmo projeto.
-
-\begin{figure}[!ht]
-	\centering
-	\includegraphics[width=0.75\textwidth]{img/SSL2018.jpg}   
-	\caption{Robô de SSL do IME, sem carenagem}
-	\label{fig:ssl2018}
-\end{figure}
-\par A competição SSL é realizada anualmente no evento internacional RoboCup. Consiste em partidas de futebol entre equipes de robótica de diversas universidades. Nesta competição, as partidas são disputadas por um time de até seis robôs autônomos, que são controlados pelo computador da equipe (\textit{Team computer}), o qual não pode ser operado durante a execução do jogo. Sobre o campo existe uma câmera conectada a um computador (\textit{Vision computer}) responsável por processar as imagens e reconhecer os padrões de cores das carenagens dos robôs de ambos os times, assim como da bola. Estas informações são enviadas para os computadores de ambas as equipes, responsáveis por tomar as decisões e calcular as estratégias de jogo. Uma ilustração pode ser vista na figura \ref{fig:topologiassl}
-
-\begin{figure}[!ht]
-	\centering
-	\includegraphics[width=0.75\textwidth]{img/DiagramaSSL-crop.pdf}   
-	\caption{Topologia de uma partida de SSL}
-	\label{fig:topologiassl}
-\end{figure}
-
-
-
-\par O robô de SSL do IME foi desenvolvido visando atender ao regulamento \cite{SSLRules2023} da competição RoboCup 2023. Sendo assim, deve caber dentro de um cilindro com 180mm de diâmetro e 150mm de altura. Deve ser capaz de atingir velocidades de até 4m/s e de chutar a bola a uma velocidade de até 6,5m/s.
-\par Possui quatro rodas omnidirecionais, como a da figura \ref{fig:rodassl2018}, dispostas nos ângulos representados na figura \ref{fig:angulossl2018}. Sendo assim, é capaz de se movimentar em três graus de liberdade, chamados aqui de tangente, normal e angular, conforme a figura \ref{fig:cinematicassl}. As rodas dianteiras estão anguladas em 30 graus em relação à direção do movimento tangente, enquanto as traseiras estão em um ângulo de 45 graus. Isso torna o movimento tangente mais preciso do que o movimento normal. As rodas são acopladas aos motores por uma redução de 4:1, e possuem rodilhas dispostas de forma alternada, conforme a figura \ref{fig:rodilhassl2018}.
-
-\begin{figure}[!ht]
-	\centering
-	\includegraphics[width=0.75\textwidth]{img/RodaOmni.jpg}   
-	\caption{Roda omnidirecional do robô de SSL do IME}
-	\label{fig:rodassl2018}
-\end{figure}
-
-\begin{figure}[!ht]
-	\centering
-	\includegraphics[width=0.75\textwidth]{img/AngulosRodas.png}   
-	\caption{Disposição das rodas no robô de SSL}
-	\label{fig:angulossl2018}
-\end{figure}
-
-\begin{figure}[!ht]
-	\centering
-	\includegraphics[width=0.5\textwidth]{img/Cinematica.png}   
-	\caption{Cinemática do robô de SSL}
-	\label{fig:cinematicassl}
-\end{figure}
-
-\begin{figure}[!ht]
-	\centering
-	\includegraphics[width=0.75\textwidth]{img/RodilhaSSL2018.jpg}   
-	\caption{Rodilhas do robô de SSL do IME}
-	\label{fig:rodilhassl2018}
-\end{figure}
-
-\par Todos os motores são do tipo DC brushed (com escovas), e possuem encoder de 52 contagens por rotação (CPR) para medição de posição angular relativa. Assim, o robô emprega controle PID em malha fechada para a velocidade de cada uma das rodas, individualmente. São alimentados por uma ponte H da figura \ref{fig:ponteh2016} desenvolvida também pela equipe RoboIME \cite{TDPRoboIME2017}.
-
-\begin{figure}[!ht]
-	\centering
-	\includegraphics[width=0.75\textwidth]{img/PonteH2016.jpg}   
-	\caption{Pontes H RoboIME 2016}
-	\label{fig:ponteh2016}
-\end{figure}
-
-\begin{figure}[!ht]
-	\centering
-	\includegraphics[width=\textwidth]{img/DiagramaBlocosSSL2018-crop.pdf}   
-	\caption{Diagrama de blocos do Robô de SSL do IME}
-	\label{fig:diagramablocosssl2018}
-\end{figure}
-
-\par Conforme o diagrama da figura \ref{fig:diagramablocosssl2018}, o microcontrolador utilizado é um STM32F407VG, da mesma família daquele empregado no SVTRP do CTEx. Dessa forma, o firmware desenvolvido para um dos robôs pode ser facilmente adaptado para o outro, sendo necessárias apenas pequenas alterações de compatibilidade. Para comunicação com o computador, o robô utiliza um rádio 2.4GHz modelo Semtech SX1280, embarcado em um módulo Ebyte E28-2G4M27S. Este rádio é capaz de se comunicar a distâncias de centenas de metros em campo aberto, a taxas de até 1,3Mbps.
-\par Possui um sensor IMU com nove graus de liberdade (9-dof), contendo acelerômetro, giroscópio e magnetômetro. Portanto, é capaz de determinar sua orientação absoluta, porém incapaz de determinar posição absoluta sem ajuda de sistema de câmeras externo por não possuir GPS. 
-
-\begin{table}[ht]
-\centering
-\caption{Especificações do robô de SSL do IME}
-\vspace{0.5cm}
-\begin{tabular}{r|lr}
- 
-Componente         & Especificação                  \\
-\hline
-Bateria            & LiPo 3S 2200mAh                \\
-Microcontrolador   & STMicroelectronics STM32F407VG \\
-Ponte H            & RoboIME 2016                   \\
-Módulo de chute    & RoboIME 2022                   \\
-Sensor IMU         & InvenSense MPU9250             \\
-Sensor de corrente & Texas Instruments INA169NA     \\
-Rádio              & Ebyte E28-2G4M27S              \\
-Motores            & Generic JGB37-520                       
- 
-\end{tabular}
-\label{tab:specsssl2018}
-\end{table}
-
-\section{Robô de desenvolvimento}
-\par Devido à maior dificuldade de acesso no dia-a-dia ao robô SVTRP do CTEx e à maior complexidade do robô de SSL devido às rodas omnidirecionais, foi decidido construir um novo robô visando a modularidade e simplicidade da dinâmica. Dessa forma, foi construído o robô da figura \ref{fig:robodev}, cujo diagrama de blocos está representado na figura \ref{fig:diagramablocosrobodev}
-
-\begin{figure}[!ht]
-	\centering
-	\includegraphics[width=0.75\textwidth]{img/RoboDesenvolvimento.jpg}   
-	\caption{Robô de desenvolvimento visto de frente}
-	\label{fig:robodev}
-\end{figure}
-
-\begin{figure}[!ht]
-	\centering
-	\includegraphics[width=\textwidth]{img/DiagramaBlocosDev-crop.pdf}   
-	\caption{Diagrama de blocos do Robô de desenvolvimento}
-	\label{fig:diagramablocosrobodev}
-\end{figure}
-
-\par Este robô é movimentado por motores semelhantes àqueles do robô de SSL, possuindo encoder de 52 CPR, porém com redução de 1:30, devido às rodas maiores. Sua cinemática é diferencial, semelhante à do SVTRP do CTEx, porém possui apenas duas rodas tracionadas e uma roda "boba" para apoio, que pode ser vista na figura \ref{fig:robodev2}. As rodas tracionadas foram escolhidas de forma que deslizem caso seja aplicado pelo motor um torque elevado, e o motor foi escolhido para ser capaz de aplicar torque que leve as rodas ao deslizamento.
-\par Para possibilitar a modularidade e o experimento com diferentes sensores, motores e microcontroladores, foi decidido colocar sobre o robô uma protoboard, sustentada por uma base projetada em software CAD e manufaturada em impressora 3D, conforme figuras \ref{fig:basesolidworks} e \ref{fig:baserobo}.
-
-\begin{figure}[!ht]
-	\centering
-	\includegraphics[width=0.75\textwidth]{img/RoboDesenvolvimento2.jpg}   
-	\caption{Robô de desenvolvimento visto de trás}
-	\label{fig:robodev2}
-\end{figure}
-
-\begin{figure}[!ht]
-	\centering
-	\includegraphics[width=0.75\textwidth]{img/BaseSolidWorks.jpg}   
-	\caption{Base modelada no software CAD SolidWorks}
-	\label{fig:basesolidworks}
-\end{figure}
-
-\begin{figure}[!ht]
-	\centering
-	\includegraphics[width=0.75\textwidth]{img/BaseRobo.jpg}   
-	\caption{Base impressa e montada no robô}
-	\label{fig:baserobo}
-\end{figure}
-
-\par Possui um sensor IMU 9-dof igual ao do robô de SSL, instalado no centro do robô, pontes H com sensores de corrente integrados, de forma que a corrente que entra em cada motor leve a uma tensão proporcional, que pode ser lida por um conversor analógico-digital (ADC) do microcontrolador.
-\par O microcontrolador principal escolhido foi o STM32F103C8 "BluePill", o mesmo do SVTRP do CTEx, pois este possui características e especificações suficientes para o desenvolvimento do projeto e, por ser o mesmo do SVTRP do CTEx, faz com que fique mais simples de instalar o \textit{firmware} desenvolvido no SVTRP do CTEx posteriormente.
-\par Para o comando, telemetria e coleta de dados, foi decidido utilizar um módulo ESP8266, capaz de se conectar a uma rede WiFi. Para o ESP8266 foi desenvolvido um \textit{firmware} que traduz a comunicação UART do microcontrolador principal em pacotes UDP \textit{multicast} e vice-versa.
-\par Para auxílio no desenvolvimento, foi desenvolvida uma interface gráfica em LabVIEW que se comunica com o robô por UDP \textit{multicast}. Esta interface envia para o robô os comandos de velocidade desejada, da mesma forma como é feito no robô de SSL, e pode receber de volta os dados de telemetria desejados, como velocidade e aceleração das rodas medidas pelos encoders, acelerações medidas pelo IMU, corrente consumida pelos motores e tensão atual da bateria. A interface está representada na figura \ref{fig:interfacelabview}
-\par Nesta interface, podem ser vistos gráficos das velocidades e acelerações em função do tempo, preenchidos em tempo real. Pode ser utilizada também para enviar comandos de velocidade desejada para o robô a partir de entradas do operador ou de rotinas de testes automáticos.
-
-\begin{figure}[!ht]
-	\centering
-	\includegraphics[width=\textwidth]{img/FrontPanelLabVIEW-crop.pdf}   
-	\caption{Interface gráfica no LabVIEW}
-	\label{fig:interfacelabview}
-\end{figure}
+\subsection{Objetivos específicos}
+\begin{itemize}
+\item Análise de ambos os modelos de robô citados
+\item Construção de um robô para desenvolvimento
+\item Projeto e calibração de sistema de controle convencional
+\item Desenvolvimento de algoritmo para detecção de deslizamento
+\item Desenvolvimento de medida corretiva para casos de deslizamento
+\item Implementação no \textit{hardware}
+\end{itemize}

Documentation/abntex2ime/main.tex

@@ -244,8 +244,8 @@
 % ELEMENTOS TEXTUAIS
 % ----------------------------------------------------------
 \textual
-
-\input{intro}
+\input{Intro}
+\input{contexto}
 \input{teoria}
 \input{problema}
 \input{solucao}

Documentation/abntex2ime/pre-texto.tex

@@ -62,7 +62,7 @@ E, por fim, a todos os que sempre torceram pelo meu melhor e acreditaram que um
  \begin{otherlanguage*}{english}
 %  \linespread{1.3}
 \SingleSpacing
- In mobile robotic platfoms powered by DC motors controlled by PID, it's common that sudden changes to desired speed cause slipping, which leads to trajectory loss. This project presents a solution to detect slip conditions and presents corrective measures that minimize trajectory loss. The solution consists in comparing the wheel acceleration with the chassis acceleration and, if inconsistencies are detected, the motor torque is reduced in order to regain the grip. The project was validated by measuring the trajectory deviation of a robot with wheels with different friction coefficients.
+ In mobile robotic platforms powered by DC motors controlled by PID, it's common that sudden changes to desired speed cause slipping, which leads to trajectory loss. This project presents a solution to detect slip conditions and presents corrective measures that minimize trajectory loss. The solution consists in comparing the wheel acceleration with the chassis acceleration and, if inconsistencies are detected, the motor torque is reduced in order to regain the grip. The project was validated by measuring the trajectory deviation of a robot with wheels with different friction coefficients.
    \vspace{\onelineskip}
  
    \noindent 

Documentation/abntex2ime/problema.tex

@@ -1,9 +1,10 @@
 \chapter{Os problemas}
+\label{chap:problema}
 \par De posse da fundamentação conceitual, parte-se então para a descrição dos problemas a serem resolvidos pelo presente trabalho.
 
 \section{Futebol de robôs SSL}
 \par Em disputas de futebol de robôs SSL, a agilidade dos robôs é muito importante, pois o time que tiver os robôs mais ágeis terá vantagem em situações de disputa de bola e de dribles. Eletronicamente, essa agilidade está ligada à dinâmica do sistema de controle, pois robôs com dinâmica mais rápida tendem a alcançar seus objetivos de posição e velocidade mais rapidamente.
-\par Além disso, a precisão do movimento do robô é um fator de grande importância nas finalizações e nos passes, pois é o que determina se o chute será a gol e se o passe vai ser recebido pelo outro robô. No sistema de controle, a precisão está relacionada com o erro de estado estacionário e com o overshoot.
+\par Além disso, a precisão do movimento do robô é um fator de grande importância nas finalizações e nos passes, pois é o que determina se o chute será a gol e se o passe vai ser recebido pelo outro robô. No sistema de controle, a precisão está relacionada com o erro de estado estacionário e com o \textit{overshoot}.
 \par Sendo assim, a boa escolha dos componentes e motores e a boa calibração do controlador PID são duas etapas de grande importância no desenvolvimento do robô e na preparação para a competição.
 
 \section{Deslizamento e perda de direção}
@@ -16,7 +17,7 @@
 \par Caso sejam utilizadas rodas com aderência intermediária, Ocorre o deslizamento em algumas ocasiões e o capotamento em outras, o que mostra a insuficiência da otimização da aderência das rodas na solução dos dois problemas.
 
 \section{Atrasos no processamento da câmera}
-\par Outra possibilidade de solução para os desvios de trajetória causados pelos deslizamentos seria utilizar uma segunda malha de controle, colocando pontos da trajetória desejada como entradas de referência e a posição atual do robô como saída. Neste caso, o sensoriamento da posição atual do robô deve ser feito pela câmera colocada acima do campo. Porém, leituras realizadas por esta câmera possuem um atraso causado pela soma de pequenos atrasos oriundos de diversas fontes, como codificação de vídeo dentro da câmera, transferências por cabo USB, processamento dos pacotes USB pelo driver da câmera, processamento da imagem recebida para identificação da posição do robô, filtragens de ruídos no posicionamento e atrasos na transmissão da informação para o computador da equipe por rede Ethernet. A soma destes atrasos inviabiliza o uso de controle em malha fechada utilizando a câmera, pois a taxa de controle neste caso teria que ser muito baixa, o que levaria a uma dinâmica muito lenta e, portanto, pouco competitiva.
+\par Outra possibilidade de solução para os desvios de trajetória causados pelos deslizamentos seria utilizar uma segunda malha de controle, colocando pontos da trajetória desejada como entradas de referência e a posição atual do robô como saída. Neste caso, o sensoriamento da posição atual do robô deve ser feito pela câmera colocada acima do campo. Porém, leituras realizadas por esta câmera possuem um atraso causado pela soma de pequenos atrasos oriundos de diversas fontes, como codificação de vídeo dentro da câmera, transferências por cabo USB, processamento dos pacotes USB pelo \textit{driver} da câmera, processamento da imagem recebida para identificação da posição do robô, filtragens de ruídos no posicionamento e atrasos na transmissão da informação para o computador da equipe por rede Ethernet. A soma destes atrasos inviabiliza o uso de controle em malha fechada utilizando a câmera, pois a taxa de controle neste caso teria que ser muito baixa, o que levaria a uma dinâmica muito lenta e, portanto, pouco competitiva.
 
 %Titulo da seção?
 \par Diante dos problemas apresentados, nota-se que apenas correções mecânicas não serão suficientes para obter-se um resultado satisfatório, visto que não há ponto de equilíbrio entre o deslizamento e o capotamento para todas as situações de jogo. Além disso, nota-se que aplicar controle de malha fechada apenas com a câmera levará o robô a uma dinâmica muito lenta. Dessa forma, enxerga-se a necessidade de aprimorar o sistema de controle do robô, sem o uso de sensores externos.

Documentation/abntex2ime/resultados.tex

@@ -1,42 +1,43 @@
 \chapter{Resultados}
+\label{chap:resultados}
 \section{Identificação do deslizamento}
 \par Nos gráficos \ref{fig:acc0.2}, \ref{fig:acc0.3}, \ref{fig:acc0.5}, \ref{fig:acc0.7} e \ref{fig:acc1.0} temos as medidas das acelerações da roda e do chassi, bem como suas comparações. Nos experimentos, o robô começa em repouso, com velocidade $v0 = 0.0m/s$, em seguida é aplicado um degrau de velocidade de referência, com amplitudes variando entre $vf = 0.2m/s$ e $vf = 1.0m/s$. Em um terceiro momento, a velocidade de referência é novamente zerada, levando a uma frenagem do robô.
-\par No gráfico \textit{Encoder accel}, é medida a aceleração da roda pela segunda derivada da medida de posição do encoder. No gráfico \textit{IMU accel} temos a aceleração do chassi, medida pelo sensor IMU. Nos gráficos \textit{Difference} e \textit{Ratio} temos o módulo da diferença e a razão entre as acelerações do IMU e do encoder.
+\par No gráfico \textit{encoderAccel}, é medida a aceleração da roda pela segunda derivada da medida de posição do \textit{encoder}. No gráfico \textit{imuAccel} temos a aceleração do chassi, medida pelo sensor IMU. No gráfico \textit{desiredSpeed} temos a velocidade de referência para o robô, indicando quando o degrau de velocidade foi aplicado ao controlador.
 
 \begin{figure}[!ht]
 	\centering
-	\includegraphics[width=\textwidth]{img/Accelerations/v0 = 0.0, vf = 0.2, fc = 5.0.png}   
+	\includegraphics[width=0.75\textwidth]{img/Accelerations/desiredSpeed = 0.2-crop.pdf}   
 	\caption{v0 = 0.0, vf = 0.2}
 	\label{fig:acc0.2}
 \end{figure}
 \begin{figure}[!ht]
 	\centering
-	\includegraphics[width=\textwidth]{img/Accelerations/v0 = 0.0, vf = 0.3, fc = 5.0.png}   
+	\includegraphics[width=0.75\textwidth]{img/Accelerations/desiredSpeed = 0.3-crop.pdf}   
 	\caption{v0 = 0.0, vf = 0.3}
 	\label{fig:acc0.3}
 \end{figure}
-\par Nos experimento dos gráficos \ref{fig:acc0.2} e \ref{fig:acc0.3}, foram aplicados degraus de pequena amplitude, o que não levou a deslizamento. Isto pode ser evidenciado pela semelhança entre os gráficos de aceleração pelo encoder e pelo IMU que, a menos de ruídos nas medições, mediram os mesmos valores de aceleração, mostrando que o movimento da roda está solidário ao movimento do chassi, o que evidencia o não deslizamento.
+\par Nos experimentos dos gráficos \ref{fig:acc0.2} e \ref{fig:acc0.3}, foram aplicados degraus de pequena amplitude, o que não levou a deslizamento. Isto pode ser evidenciado pela semelhança entre os gráficos de aceleração pelo \textit{encoder} e pelo IMU que, a menos de ruídos nas medições, mediram os mesmos valores de aceleração, mostrando que o movimento da roda está solidário ao movimento do chassi, o que evidencia o não deslizamento.
 
 \begin{figure}[!ht]
 	\centering
-	\includegraphics[width=\textwidth]{img/Accelerations/v0 = 0.0, vf = 0.5, fc = 5.0.png}   
+	\includegraphics[width=0.75\textwidth]{img/Accelerations/desiredSpeed = 0.5-crop.pdf}   
 	\caption{v0 = 0.0, vf = 0.5}
 	\label{fig:acc0.5}
 \end{figure}
 \begin{figure}[!ht]
 	\centering
-	\includegraphics[width=\textwidth]{img/Accelerations/v0 = 0.0, vf = 0.7, fc = 5.0.png}   
+	\includegraphics[width=0.75\textwidth]{img/Accelerations/desiredSpeed = 0.7-crop.pdf}   
 	\caption{v0 = 0.0, vf = 0.7}
 	\label{fig:acc0.7}
 \end{figure}
 \begin{figure}[!ht]
 	\centering
-	\includegraphics[width=\textwidth]{img/Accelerations/v0 = 0.0, vf = 1.0, fc = 5.0.png}   
+	\includegraphics[width=0.75\textwidth]{img/Accelerations/desiredSpeed = 1.0-crop.pdf}   
 	\caption{v0 = 0.0, vf = 1.0}
 	\label{fig:acc1.0}
 \end{figure}
 
-\par Nos experimentos dos gráficos \ref{fig:acc0.5}, \ref{fig:acc0.7} e \ref{fig:acc1.0} houve deslizamentos. Tais deslizamentos podem ser vistos pelas diferenças entre os gráficos de aceleração das rodas, medidas pelo encoder, e do chassi, medidas pelo IMU. Pode-se observar que para os três experimentos a aceleração do chassi não passou de um valor limite, em torno de $3m/s^2$ e $4m/s^2$, determinado pela máxima força de atrito entre as rodas e o chão. Enquanto isso, os gráficos de aceleração das rodas chegaram a valores maiores, limitados apenas pela força máxima do motor, que é maior do que o máximo do atrito.
+\par Nos experimentos dos gráficos \ref{fig:acc0.5}, \ref{fig:acc0.7} e \ref{fig:acc1.0} houve deslizamentos. Tais deslizamentos podem ser vistos pelas diferenças entre os gráficos de aceleração das rodas, medidas pelo \textit{encoder}, e do chassi, medidas pelo IMU. Pode-se observar que para os três experimentos a aceleração do chassi não passou de um valor limite, em torno de $3m/s^2$ e $4m/s^2$, determinado pela máxima força de atrito entre as rodas e o chão. Enquanto isso, os gráficos de aceleração das rodas chegaram a valores maiores, limitados apenas pela força máxima do motor, que é maior do que o máximo do atrito.
 \par Desta forma, a fim de compensar pelas imprecisões dos sensores e aplicar correção apenas aos deslizamentos mais severos, pode-se decidir por tomar as medidas corretivas caso a diferença entre as acelerações da roda e do chassi supere $5m/s^2$.
 
 \section{Correção do deslizamento}

Documentation/abntex2ime/solucao.tex

@@ -1,10 +1,64 @@
-\chapter{Projeto do sistema de controle anti-derrapagem}
-% Link do git
+\chapter{Projeto do controle anti-derrapagem}
+\label{chap:solucao}
+\section{Robô de desenvolvimento}
+\par Devido à maior dificuldade de acesso no dia-a-dia ao robô SVTRP do CTEx e à maior complexidade do robô de SSL devido às rodas omnidirecionais, foi decidido construir um novo robô visando a modularidade e simplicidade da dinâmica. Dessa forma, foi construído o robô da figura \ref{fig:robodev}, cujo diagrama de blocos está representado na figura \ref{fig:diagramablocosrobodev}
+
+\begin{figure}[!ht]
+	\centering
+	\includegraphics[width=0.75\textwidth]{img/RoboDesenvolvimento.jpg}   
+	\caption{Robô de desenvolvimento visto de frente}
+	\label{fig:robodev}
+\end{figure}
+
+\begin{figure}[!ht]
+	\centering
+	\includegraphics[width=\textwidth]{img/DiagramaBlocosDev-crop.pdf}   
+	\caption{Diagrama de blocos do Robô de desenvolvimento}
+	\label{fig:diagramablocosrobodev}
+\end{figure}
+
+\par Este robô é movimentado por motores semelhantes àqueles do robô de SSL, possuindo encoder de 52 CPR, porém com redução de 1:30, devido às rodas maiores. Sua cinemática é diferencial, semelhante à do SVTRP do CTEx, porém possui apenas duas rodas tracionadas e uma roda "boba" para apoio, que pode ser vista na figura \ref{fig:robodev2}. As rodas tracionadas foram escolhidas de forma que deslizem caso seja aplicado pelo motor um torque elevado, e o motor foi escolhido para ser capaz de aplicar torque que leve as rodas ao deslizamento.
+\par Para possibilitar a modularidade e o experimento com diferentes sensores, motores e microcontroladores, foi decidido colocar sobre o robô uma protoboard, sustentada por uma base projetada em software CAD e manufaturada em impressora 3D, conforme figuras \ref{fig:basesolidworks} e \ref{fig:baserobo}.
+
+\begin{figure}[!ht]
+	\centering
+	\includegraphics[width=0.75\textwidth]{img/RoboDesenvolvimento2.jpg}   
+	\caption{Robô de desenvolvimento visto de trás}
+	\label{fig:robodev2}
+\end{figure}
+
+\begin{figure}[!ht]
+	\centering
+	\includegraphics[width=0.75\textwidth]{img/BaseSolidWorks.jpg}   
+	\caption{Base modelada no software CAD SolidWorks}
+	\label{fig:basesolidworks}
+\end{figure}
+
+\begin{figure}[!ht]
+	\centering
+	\includegraphics[width=0.75\textwidth]{img/BaseRobo.jpg}   
+	\caption{Base impressa e montada no robô}
+	\label{fig:baserobo}
+\end{figure}
+
+\par Possui um sensor IMU 9-dof igual ao do robô de SSL, instalado no centro do robô, pontes H com sensores de corrente integrados, de forma que a corrente que entra em cada motor leve a uma tensão proporcional, que pode ser lida por um conversor analógico-digital (ADC) do microcontrolador.
+\par O microcontrolador principal escolhido foi o STM32F103C8 "BluePill", o mesmo do SVTRP do CTEx, pois este possui características e especificações suficientes para o desenvolvimento do projeto e, por ser o mesmo do SVTRP do CTEx, faz com que fique mais simples de instalar o \textit{firmware} desenvolvido no SVTRP do CTEx posteriormente.
+\par Para o comando, telemetria e coleta de dados, foi decidido utilizar um módulo ESP8266, capaz de se conectar a uma rede WiFi. Para o ESP8266 foi desenvolvido um \textit{firmware} que traduz a comunicação UART do microcontrolador principal em pacotes UDP \textit{multicast} e vice-versa.
+\par Para auxílio no desenvolvimento, foi desenvolvida uma interface gráfica em LabVIEW que se comunica com o robô por UDP \textit{multicast}. Esta interface envia para o robô os comandos de velocidade desejada, da mesma forma como é feito no robô de SSL, e pode receber de volta os dados de telemetria desejados, como velocidade e aceleração das rodas medidas pelos encoders, acelerações medidas pelo IMU, corrente consumida pelos motores e tensão atual da bateria. A interface está representada na figura \ref{fig:interfacelabview}
+\par Nesta interface, podem ser vistos gráficos das velocidades e acelerações em função do tempo, preenchidos em tempo real. Pode ser utilizada também para enviar comandos de velocidade desejada para o robô a partir de entradas do operador ou de rotinas de testes automáticos.
+
+\begin{figure}[!ht]
+	\centering
+	\includegraphics[width=\textwidth]{img/FrontPanelLabVIEW-crop.pdf}   
+	\caption{Interface gráfica no LabVIEW}
+	\label{fig:interfacelabview}
+\end{figure}
+
 \section{Comunicação entre STM32 e GUI}
 \par Devido à necessidade de realizar a comunicação entre o robô e o computador sem que cabos prejudiquem as medições e o funcionamento, foi adotado o protocolo UDP, por ser possível o uso de comunicação WiFi. Para tal, foi implantado no robô um microcontrolador ESP8266, que possui um periférico UART, o qual pode ser utilizado para comunicação com o microcontrolador principal STM32, e um periférico WiFi, que pode ser utilizado para comunicação com o computador. Foi desenvolvido um firmware em $C++$ para o ESP8266 que converte os pacotes enviados por UART em pacotes UDP e vice-versa. Os pacotes UDP são transmitidos e recebidos por multicast, o que permitiria que fossem utilizados múltiplas interfaces gráficas para telemetria do robô.
 
 \section{Desenvolvimento do \textit{Firmware} do STM32}
-\par Foi desenvolvido um \textit{firmware} para o microcontrolador STM32 doo robô de desenvolvimento.
+\par Foi desenvolvido um \textit{firmware} para o microcontrolador STM32 do robô de desenvolvimento.
 \subsection{Recursos e características do microcontrolador}
 \par O microcontrolador do robô de desenvolvimento é o STM32F103C8T6, embarcado em uma placa \textit{BluePill}, amplamente encontrada no mercado nacional. A placa \textit{BluePill} pode ser vista na figura \ref{fig:BluePill}.
 
@@ -74,7 +128,7 @@ ADCs					& 2 (10 canais)
 \begin{figure}[!ht]
 	\centering
 	\includegraphics[width=0.5\textwidth]{img/EncoderSensors.png}   
-	\caption{Representa;áo dos sensores no disco do encoder}
+	\caption{Representação dos sensores no disco do encoder}
 	\label{fig:EncoderSensors}
 \end{figure}
 \begin{figure}[!ht]
@@ -103,11 +157,11 @@ ADCs					& 2 (10 canais)
 \par Além disso, foi necessário determinar uma taxa de controle que permitisse uma alta largura de banda para o sistema sem ter problemas com os erros de quantização citados na seção \ref{subsection:pidImpl}. Dessa forma, foi determinado experimentalmente que a taxa de $100Hz$ leva a um bom equilíbrio.
 
 \subsection{Implementação do sensor IMU}
-\par Conforme mencionado no capítulo \ref{chap:intro}, foi implementado no robô um sensor IMU 9-DOF. O sensor se comunica com o microcontrolador por protocolo SPI, que possui periférico dedicado no microcontrolador. Após a análise das possibilidades de desenvolvimento de biblioteca para a interface entre o sensor IMU e o microcontrolador STM32, foi decidido adaptar uma biblioteca feita para Arduino \cite{mpu9250}, tendo em vista sua simplicidade de adaptação e de uso, frente à grande dificuldade de desenvolvimento de uma biblioteca do zero para este sensor e à má qualidade das bibliotecas para STM32 encontradas na internet.
+\par Conforme mencionado no capítulo \ref{chap:contexto}, foi implementado no robô um sensor IMU 9-DOF. O sensor se comunica com o microcontrolador por protocolo SPI, que possui periférico dedicado no microcontrolador. Após a análise das possibilidades de desenvolvimento de biblioteca para a interface entre o sensor IMU e o microcontrolador STM32, foi decidido adaptar uma biblioteca feita para Arduino \cite{mpu9250}, tendo em vista sua simplicidade de adaptação e de uso, frente à grande dificuldade de desenvolvimento de uma biblioteca do zero para este sensor e à má qualidade das bibliotecas para STM32 encontradas na internet.
 
 \section{Determinação das constantes do PID}
 \par Tendo desenvolvido o \textit{firmware}, é necessário agora determinar as constantes do controlador PID. Em versões anteriores do \textit{firmware}, as constantes $kp$, $ki$ e $kd$ foram determinadas experimentalmente por tentativa e erro. Os resultados não eram satisfatórios e levavam o robô a um movimento impreciso, sobretudo no tocante a erro de estado estacionário e overshoot.
-\par Foi então aplicada uma nova técnica de calibração do controle PID utilizando a ferramenta \textit{pidTuner} do \textit{Matlab}, em conjunto com as ferramentas de \textit{software} descritas no capítulo \ref{chap:intro}.
+\par Foi então aplicada uma nova técnica de calibração do controle PID utilizando a ferramenta \textit{pidTuner} do \textit{Matlab}, em conjunto com as ferramentas de \textit{software} descritas no capítulo \ref{chap:contexto}.
 
 \subsection{Identificação da planta}
 \par Para a calibração de sistemas de controle por projeto baseado em modelo, é necessário identificar a planta, por uma função de transferência ou representação em espaço de estados. Para este projeto, foi decidido utilizar a função de transferência. Conforme descrito no capítulo \ref{chap:teoria}, a função de transferência do motor DC do robô de desenvolvimento é da forma da equação \ref{eqn:ftMotorDC}. Assim, a identificação da planta se resume a encontrar os valores de $K_p$ e $T_{p1}$.
@@ -160,6 +214,7 @@ ADCs					& 2 (10 canais)
 	\label{eqn:KpTp1}
 \end{equation}
 
+% Colocar também comparação de malha fechada
 \begin{figure}[!ht]
 	\centering
 	\includegraphics[width=0.75\textwidth]{img/pidTuner/StepResponseOpenLoopSimulation-crop.pdf}   

Documentation/abntex2ime/teoria.tex

@@ -4,7 +4,7 @@
 \par Neste capítulo será abordada a teoria utilizada para o desenvolvimento do projeto, além das considerações e simplificações adotadas na aplicação desta teoria aos casos particulares presentes no escopo do projeto. Serão também mencionadas as dificuldades e limitações de implementação prática desta teoria.
 
 \section{Modelagem de um motor DC}
-\par O motor DC utilizado nos três robôs é do tipo com escovas (\textit{brushed}) de ímã permanente. Uma representação gráfica desse tipo de motor pode ser vista na figura \ref{fig:diagramamotordc}
+\par O motor DC utilizado nos robôs é do tipo com escovas (\textit{brushed}) de ímã permanente. Uma representação gráfica desse tipo de motor pode ser vista na figura \ref{fig:diagramamotordc}
 
 \begin{figure}[!ht]
 	\centering
@@ -52,7 +52,7 @@ e = K_e \cdot \dot{\theta}_m
 \end{equation}
 
 % XL é desprezível para omega típicos?
-\par Na maioria dos motores DC comerciais, inclusive nos utilizados nos deste trabalho, o efeito da indutância é muito pequeno quando comparado com o efeito do momento de inércia. Assim, a função de transferência \ref{eqn:ftMotorDCCompleta} pode ser simplificada \cite{Franklin2019-dx} para:
+\par Na maioria dos motores DC comerciais, inclusive nos utilizados neste trabalho, o efeito da indutância é muito pequeno quando comparado com o efeito do momento de inércia, para as frequências típicas de operação. Assim, a função de transferência \ref{eqn:ftMotorDCCompleta} pode ser simplificada \cite{Franklin2019-dx} para:
 
 \begin{equation}
 \frac{\dot{\theta}_m(s)}{V_a(s)} = \frac{K_p}{1 + T_{p1}s}
@@ -91,11 +91,11 @@ T_{p1} = \frac{RJ}{bR + K_tK_e}
 
 \par Onde $kp$, $ki$ e $kd$ são constantes chamadas respectivamente de proporcional, integral e derivativa, $U(s)$ é a saída do controlador PID e $E(s)$ é o sinal de erro que entra no controlador PID. Influenciam diretamente no comportamento do controlador PID e, portanto, do sistema de controle do robô de forma geral. Encontrar os melhores valores para estas constantes torna-se então um trabalho de otimização que pode ser auxiliado por métodos como os de Ziegler-Nichols \cite{Franklin2019-dx}.
 \par Contudo, esta função de transferência representa um controlador não-causal e, portanto, não pode ser aplicada diretamente a sistemas reais. Sendo assim, é necessário realizar adaptações ao implementar nos robôs.
-\par No robô de desenvolvimento, a planta pode ser entendida como sendo o conjunto que engloba a ponte H e o motor, enquanto as forças externas aplicadas ao motor serão vistas como perturbações $W(t)$ no sistema. Além disso, existem ainda perturbações $V(t)$ causadas por imprecisões dos sensores utilizados. O controlador PID e os cálculos dos sinais de referência e de erro serão implementados no \textit{firmware} do microcontrolador, o que faz com que o robô precise ser um sistema discreto a tempo discreto. Dessa forma, o diagrama de blocos do sistema de controle do robô de desenvolvimento é o da figura \ref{fig:diagramaPIDRobo}.
+\par Nos robô deste trabalho, a planta pode ser entendida como sendo o conjunto que engloba a ponte H e o motor, enquanto as forças externas aplicadas ao motor serão vistas como perturbações $W(t)$ no sistema. Além disso, existem ainda perturbações $V(t)$ causadas por imprecisões dos sensores utilizados. O controlador PID e os cálculos dos sinais de referência e de erro serão implementados no \textit{firmware} do microcontrolador, o que faz com que o robô precise ser um sistema discreto a tempo discreto. Dessa forma, o diagrama de blocos do sistema de controle dos robôs deste trabalho é o da figura \ref{fig:diagramaPIDRobo}.
 
 \begin{figure}[!ht]
 	\centering
 	\includegraphics[width=\textwidth]{img/DiagramaPIDRobo-crop.pdf}   
-	\caption{Diagrama de blocos do controle do robô de desenvolvimento}
+	\caption{Diagrama de blocos do controle dos robôs}
 	\label{fig:diagramaPIDRobo}
 \end{figure}