Documentation: Melhorias sugeridas pela banca

Documentation/abntex2ime/intro.tex

@@ -148,7 +148,7 @@ Motores            & Generic JGB37-520
 \begin{figure}[!ht]
 	\centering
 	\includegraphics[width=0.75\textwidth]{img/RoboDesenvolvimento.jpg}   
-	\caption{Robô de desenvolvimento}
+	\caption{Robô de desenvolvimento visto de frente}
 	\label{fig:robodev}
 \end{figure}
 
@@ -159,9 +159,16 @@ Motores            & Generic JGB37-520
 	\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. 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 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}   
@@ -180,8 +187,7 @@ Motores            & Generic JGB37-520
 \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}
-
-%Descrever a interface
+\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

Documentation/abntex2ime/refs.bib

@@ -580,4 +580,20 @@
     url = {https://www.nagwa.com/en/explainers/246108560531/},
     note = {27 set. de 2023},
     year = {2023}
+}
+
+@misc{gitgmlima,
+    Organization = {Gabriel Lima},
+    title = {Repositório para o projeto de fim de curso de graduação IME 2023},
+    url = {https://git.gmlima.com/Gabriel/PFC},
+    note = {11 out. de 2023},
+    year = {2023}
+}
+
+@misc{mpu9250,
+    Organization = {Hideaki Tai},
+    title = {Arduino library for MPU9250 Nine-Axis (Gyro + Accelerometer + Compass) MEMS MotionTracking™ Device},
+    url = {https://github.com/hideakitai/MPU9250},
+    note = {7 abr. de 2022},
+    year = {2022}
 }

Documentation/abntex2ime/solucao.tex

@@ -1,7 +1,4 @@
 \chapter{Projeto do sistema de controle anti-derrapagem}
-% Fundir com 1.3
-\section{Desenvolvimento da interface gráfica}
-\par Conforme citado no capítulo \ref{chap:intro}, foi desenvolvida uma interface gráfica em LabVIEW para auxílio no desenvolvimento. O LabVIEW foi escolhido pela sua facilidade de desenvolvimento de sistemas com interface gráfica para análise de sistemas em tempo real. A comunicação da interface em LabVIEW poderia ser feita tanto por protocolo UART, quanto por USB, quanto por UDP.
 % Link do git
 \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ô.
@@ -70,31 +67,43 @@ ADCs					& 2 (10 canais)
 \par Foi utilizado um fluxo de programa chamado de programação orientada a interrupções, em que toda a lógica do programa acontece dentro de uma rotina de serviço de interrupção (ISR), que é chamada em intervalos de tempo fixados por um timer. A frequência com que essa ISR chama-se taxa ou frequência de controle, pois cada iteração do sistema de controle do robô, um sistema a tempo discreto, ocorre em uma chamada da ISR. A única restrição para este tipo de programação é que cada execução da ISR deve ser finalizada antes da próxima chamada, o que pode ser verificado por meio de ferramentas de \textit{debug}.
 
 \subsection{Implementação da leitura do encoder}
-%%Colocar fórmulas e figuras
-\par Encoders de quadratura, como os presentes nos motores do robô de desenvolvimento, podem ter sua posição lida por um timer do microcontrolador, onde cada variação na posição do motor leva a um incremento ou decremento do valor do timer, a depender da direção do movimento. Esta metodologia possui duas importantes limitações.
-\par A primeira limitação se deve o fato de o encoder ter um número finito de contagens por rotação. No caso do robô de desenvolvimento, são 52 contagens. Assim, o valor do timer só incrementa ou decrementa a cada uma variação de $1/52$ rotações, sendo impossível medir variações angulares menores. Assim, as variações angulares entre duas iterações da ISR de controle serão quantizadas.
+\label{subsection:pidImpl}
+\par \textit{Encoders} de quadratura magnéticos, como os presentes nos motores do robô de desenvolvimento são dispositivos capazes de capturar a posição de um motor relativa à sua posição inicial. para isto, possuem dois sensores de efeito $hall$, posicionados próximos a um disco solidário ao eixo do motor, com magnetizações que variam entre norte e sul, conforme representação na figura \ref{fig:EncoderSensors}.
+\par Quando o motor gira, os \textit{encoders} geram duas ondas quadradas de mesma frequência, mesma amplitude, porém fases diferentes. A frequência da onda gerada é proporcional à velocidade angular do motor em que o \textit{encoder} está acoplado, enquanto a diferença de fase pode ser de $+90^\circ$ ou $-90^\circ$, a depender da direção do movimento do motor. A medição da onda quadrada gerada por um encoder do robô de desenvolvimento pode ser vista na captura de tela do osciloscópio na figura \ref{fig:EncoderOscilloscope}.
+
+\begin{figure}[!ht]
+	\centering
+	\includegraphics[width=0.5\textwidth]{img/EncoderSensors.png}   
+	\caption{Representa;áo dos sensores no disco do encoder}
+	\label{fig:EncoderSensors}
+\end{figure}
+\begin{figure}[!ht]
+	\centering
+	\includegraphics[width=0.75\textwidth]{img/EncoderOscilloscope.png}   
+	\caption{Leitura do encoder no osciloscópio}
+	\label{fig:EncoderOscilloscope}
+\end{figure}
+
+\par O encoder pode ter sua posição lida por um \textit{timer} do microcontrolador, onde cada variação na posição do motor, capturada pelas bordas de subida e descida das ondas da figura \ref{fig:EncoderOscilloscope}, leva a um incremento ou decremento do valor do \textit{timer}, a depender da direção do movimento. Esta metodologia possui duas importantes limitações.
+\par A primeira limitação se deve o fato de o \textit{encoder} ter um número finito de contagens por rotação. No caso do robô de desenvolvimento, são 52 contagens. Assim, o valor do \textit{timer} só incrementa ou decrementa a cada uma variação de $1/52$ rotações, sendo impossível medir variações angulares menores. Assim, as variações angulares entre duas iterações da ISR de controle serão quantizadas.
 \par A segunda limitação é que a velocidade do motor é lida fazendo-se a divisão entre a variação da posição entre duas iterações da ISR e o período de controle. Assim, caso seja aumentada a taxa de controle, o erro de quantização relacionado à primeira limitação irá aumentar, levando a medidas de velocidade menos precisas.
 
 \subsection{Implementação do controlador PID}
-\label{subsection:pidImpl}
 \par O controlador PID foi implementado em uma função do $C++$, que tem como entrada a velocidade linear desejada para a roda e como saída o ciclo de trabalho (duty cycle) do PWM.
 \par Para implementação de controladores PID a sistemas reais, há dois problemas:
-% Referência
-\par O primeiro, é que o termo derivativo do controlador PID ideal, representado na equação \ref{eqn:ftPIDIdeal}, requer que o sistema não seja causal e, portanto, não pode ser implementado fisicamente. Este problema pode ser resolvido em um sistema discreto calculando-se o termo derivativo segundo a equação \ref{eqn:derivadaDiscreta}, o que traz um termo derivativo calculado com meia amostra de atraso e, portanto, podendo ser calculado em um sistema causal.
+\par O primeiro, é que o termo derivativo do controlador PID ideal, representado na equação \ref{eqn:ftPIDIdeal}, requer que o sistema não seja causal e, portanto, não pode ser implementado fisicamente, conforme \cite{Franklin2019-dx}. Este problema pode ser resolvido em um sistema discreto calculando-se o termo derivativo segundo a equação \ref{eqn:derivadaDiscreta}, o que traz um termo derivativo calculado com meia amostra de atraso e, portanto, podendo ser calculado em um sistema causal.
 
 \begin{equation}
 	dError = \frac{erro - erroAnterior}{deltaT}
 	\label{eqn:derivadaDiscreta}
 \end{equation}
 
-% Referência
-\par O segundo problema é que a teoria dos controladores PID ideais considera que o motor pode realizar torque infinito, visto que a saída do cálculo do PID da equação \ref{eqn:ftPIDIdeal} pode ir de $-\infty$ a $\infty$, não considerando a limitação do duty cycle de ir de $-1$ a $1$. Dessa forma, em situações onde o duty cycle calculado pelo PID estiver fora dos limites físicos, o cálculo do termo integral pode ser prejudicado por tais inconsistências com o sistema ideal, o que deixa o sistema instável. Este problema foi resolvido limitando-se por saturação o termo integral entre dois valores, determinados experimentalmente fazendo-se um balanço entre erro de estado estacionário e estabilidade do sistema.
+\par O segundo problema é que, segundo \cite{Franklin2019-dx}, a teoria dos controladores PID ideais considera que o motor pode realizar torque infinito, visto que a saída do cálculo do PID da equação \ref{eqn:ftPIDIdeal} pode ir de $-\infty$ a $\infty$, não considerando a limitação do duty cycle de ir de $-1$ a $1$. Dessa forma, em situações onde o duty cycle calculado pelo PID estiver fora dos limites físicos, o cálculo do termo integral pode ser prejudicado por tais inconsistências com o sistema ideal, o que deixa o sistema instável. Este problema foi resolvido limitando-se por saturação o termo integral entre dois valores, determinados experimentalmente fazendo-se um balanço entre erro de estado estacionário e estabilidade do sistema.
 % Como foi determinado o 100Hz
 \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}
-% Referência da biblioteca
-\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. Foi decidido adaptar uma biblioteca feita para Arduino, tendo em vista sua simplicidade de adaptação e de uso.
+\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.
 
 \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.
@@ -116,8 +125,8 @@ ADCs					& 2 (10 canais)
 
 \begin{figure}[!ht]
 	\centering
-	\includegraphics[width=\linewidth]{img/placeholder.png}   
-	\caption{Gráfico com dados importados no Matlab}
+	\includegraphics[width=0.75\linewidth]{img/pidTuner/StepResponseOpenLoop-crop.pdf}   
+	\caption{Gráfico com a resposta ao degrau importada no Matlab}
 	\label{fig:pidTuner2}
 \end{figure}
 
@@ -126,7 +135,7 @@ ADCs					& 2 (10 canais)
 \begin{figure}[!ht]
 	\centering
 	\includegraphics[width=\textwidth]{img/pidTuner/4.png}   
-	\caption{Importação da resposta ao degrau}
+	\caption{Importação da resposta ao degrau no pidTuner}
 	\label{fig:pidTuner4}
 \end{figure}
 
@@ -139,7 +148,7 @@ ADCs					& 2 (10 canais)
 	\label{fig:pidTuner6}
 \end{figure}
 
-\par Assim, foi encontrada a planta cuja resposta ao degrau melhor se ajusta à da planta a ser identificada. Sua respectiva função de transferência, bem como os valores de $Kp$ e $Tp1$, podem ser vistas na ferramenta e nas equações \ref{eqn:ftMotorRoboDesenvolvimento} e \ref{eqn:KpTp1}, onde $v(s)$ é a velocidade linear da roda em $mm/s$ e $dutyCycle$ é o ciclo de trabalho do \textit{PWM} aplicado ao motor, normalizado entre $-1$ e $1$.
+\par Assim, foi encontrada a planta cuja resposta ao degrau melhor se ajusta à da planta a ser identificada, o que pode ser validado pela figura \ref{fig:pidTuner7}. Sua respectiva função de transferência, bem como os valores de $Kp$ e $Tp1$, podem ser vistas na ferramenta e nas equações \ref{eqn:ftMotorRoboDesenvolvimento} e \ref{eqn:KpTp1}, onde $v(s)$ é a velocidade linear da roda em $mm/s$ e $dutyCycle$ é o ciclo de trabalho do \textit{PWM} aplicado ao motor, normalizado entre $-1$ e $1$.
 
 \begin{equation}
 	\frac{v(s)}{dutyCycle(s)} = \frac{K_p}{1 + T_{p1}s}
@@ -151,6 +160,13 @@ ADCs					& 2 (10 canais)
 	\label{eqn:KpTp1}
 \end{equation}
 
+\begin{figure}[!ht]
+	\centering
+	\includegraphics[width=0.75\textwidth]{img/pidTuner/StepResponseOpenLoopSimulation-crop.pdf}   
+	\caption{Comparação em malha aberta da planta simulada com a resposta medida.}
+	\label{fig:pidTuner7}
+\end{figure}
+
 \subsection{Otimização do controle PID}
 \par Tendo obtido a função de transferência da planta, encontrar as constantes $kp$, $ki$ e $kd$ do controle PID torna-se um problema de otimização, com determinadas restrições. O controle deve ser otimizado para ter o menor \textit{overshoot}, menores tempos de subida e de acomodação, e menor erro de estado estacionário. Porém, deve respeitar a limitação de não ultrapassar os máximos de $dutyCycle$ dos motores ($-1$ a $1$). Além disso, como o robô é um sistema discreto, e a calibração do PID é feita neste caso por aproximação de um sistema contínuo, a largura de banda do controlador tem que ser tal que esta aproximação seja satisfatória.
 \par Por determinações experimentais, observou-se que a largura de banda do controlador deve ser maior que a frequência de corte da mecânica do motor, observando-se o sistema de função de transferência \ref{eqn:ftMotorRoboDesenvolvimento} como sendo um filtro passa-baixas de primeira ordem. Além disso, a largura de banda deve ser muito menor do que a taxa de controle de $100Hz$, para que a aproximação do sistema discreto para um sistema contínuo ainda seja válida. Desta forma, observou-se que a largura de banda de $5Hz$ para o controlador PID satisfaz ambos os requisitos.

Documentation/abntex2ime/teoria.tex

@@ -84,7 +84,6 @@ T_{p1} = \frac{RJ}{bR + K_tK_e}
 
 \par Em um sistema contínuo a tempo contínuo ideal, a função de transferência do controlador PID será a da equação \ref{eqn:ftPIDIdeal}
 
-% Usar letras para duty cycle e erro
 \begin{equation}
 \frac{U(s)}{E(s)} = kp + \frac{ki}{s} + kd \cdot s
 \label{eqn:ftPIDIdeal}