diff --git a/Documentation/abntex2ime/conclusao.tex b/Documentation/abntex2ime/conclusao.tex index 7c1bb26..790d602 100644 --- a/Documentation/abntex2ime/conclusao.tex +++ b/Documentation/abntex2ime/conclusao.tex @@ -1,8 +1,16 @@ \chapter{Conclusão} -\par Foi desenvolvido um 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. +\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. \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{Próximos passos} +\section{Perspectivas} +% Como assim usar itemize? +\begin{itemize} +\item Integração ao robô do CTEx +\item Solução bidimensional +\item Integração ao robô da SSL (solução tridimensional) +\item Melhorias nos filtros +\item Implementação standalone no robô +\end{itemize} \subsection{Integração ao robô do CTEx} \par A integração ao robô do CTEx pode ser feita utilizando-se o mesmo firmware do robô de desenvolvimento, tendo em vista que ambos utilizam o mesmo microcontrolador, apenas adaptando para os diferentes pinos do microcontrolador que os componentes estão conectados. Além disso, deve-se repetir os passos tomados para a calibração das constantes do controle PID e da detecção de deslizamento. diff --git a/Documentation/abntex2ime/dados.tex b/Documentation/abntex2ime/dados.tex index 8a3e3c3..1dc3224 100644 --- a/Documentation/abntex2ime/dados.tex +++ b/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,Hebert,Antonio}{Simões,Azevedo,Carrilho}{Dr.ISAE,Ph.D.,Dr.Eng.}%{nomes}{sobrenomes}{títulos} 1+ +\orientadores{Alberto}{Simões}{Dr.ISAE}%{nomes}{sobrenomes}{títulos} 1+ % --- \local{Rio de Janeiro} \data{2023} diff --git a/Documentation/abntex2ime/intro.tex b/Documentation/abntex2ime/intro.tex index 0d0570c..ab3b7d1 100644 --- a/Documentation/abntex2ime/intro.tex +++ b/Documentation/abntex2ime/intro.tex @@ -3,8 +3,9 @@ % ---------------------------------------------------------- \chapter{Introdução} \label{chap:intro} +\section{Projeto SVTRP} % ---------------------------------------------------------- -\par O projeto do sistema de viaturas terrestres remotamente pilotadas (SVTRP) é um dos projetos estratégicos do exército desenvolvidos pelo Centro Tecnológico do Exército (CTEx), 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. \begin{figure}[!ht] \centering @@ -13,19 +14,8 @@ \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 deste projeto. +\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{Contexto} -\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} - -\subsection{Descrição do primeiro protótipo SVTRP} % Conferir dimensões com o pessoal do CTEx \begin{figure}[!ht] @@ -40,7 +30,7 @@ \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}. +\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 @@ -61,9 +51,16 @@ Motores & Pololu 37Dx68L \label{tab:specssvtrp} \end{table} -\subsection{Descrição da competição SSL da RoboCup} +\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. -\par A competição SSL é realizada anualmente do 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 (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 (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/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 @@ -72,25 +69,11 @@ Motores & Pololu 37Dx68L \label{fig:topologiassl} \end{figure} -\subsection{Descrição do robô de SSL} -\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 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/AngulosRodas.png} - \caption{Disposição das rodas no robô de SSL} - \label{fig:angulossl2018} -\end{figure} - \begin{figure}[!ht] \centering \includegraphics[width=0.75\textwidth]{img/RodaOmni.jpg} @@ -100,9 +83,9 @@ Motores & Pololu 37Dx68L \begin{figure}[!ht] \centering - \includegraphics[width=0.75\textwidth]{img/RodilhaSSL2018.jpg} - \caption{Rodilhas do robô de SSL do IME} - \label{fig:rodilhassl2018} + \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] @@ -112,6 +95,13 @@ Motores & Pololu 37Dx68L \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] @@ -121,7 +111,14 @@ Motores & Pololu 37Dx68L \label{fig:ponteh2016} \end{figure} -\par 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. +\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] @@ -145,7 +142,7 @@ Motores & Generic JGB37-520 \label{tab:specsssl2018} \end{table} -\subsection{Descrição do robô de desenvolvimento} +\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] @@ -162,7 +159,7 @@ 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. 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] @@ -180,9 +177,11 @@ Motores & Generic JGB37-520 \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 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 firmware que traduz a comunicação UART do microcontrolador principal em pacotes UDP 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 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 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 \begin{figure}[!ht] \centering diff --git a/Documentation/abntex2ime/main.pdf b/Documentation/abntex2ime/main.pdf index 54974a3..96733d8 100644 Binary files a/Documentation/abntex2ime/main.pdf and b/Documentation/abntex2ime/main.pdf differ diff --git a/Documentation/abntex2ime/problema.tex b/Documentation/abntex2ime/problema.tex index eadb983..5db4cbf 100644 --- a/Documentation/abntex2ime/problema.tex +++ b/Documentation/abntex2ime/problema.tex @@ -1,4 +1,6 @@ \chapter{Os problemas} +\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. @@ -14,4 +16,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. \par 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. \ No newline at end of file +\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. + +%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. \ No newline at end of file diff --git a/Documentation/abntex2ime/resultados.tex b/Documentation/abntex2ime/resultados.tex index 2e81086..eb7c444 100644 --- a/Documentation/abntex2ime/resultados.tex +++ b/Documentation/abntex2ime/resultados.tex @@ -36,7 +36,7 @@ \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} houveram 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 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} diff --git a/Documentation/abntex2ime/solucao.tex b/Documentation/abntex2ime/solucao.tex index 2a050b9..bce567a 100644 --- a/Documentation/abntex2ime/solucao.tex +++ b/Documentation/abntex2ime/solucao.tex @@ -1,14 +1,13 @@ -\chapter{Solução} -\section{Proposta} -\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. - +\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, que pode ser utilizado para comunicação com o 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ô. +\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 Firmware do STM32} -\par Foi desenvolvido um firmware para o microcontrolador STM32 doo robô de desenvolvimento. +\section{Desenvolvimento do \textit{Firmware} do STM32} +\par Foi desenvolvido um \textit{firmware} para o microcontrolador STM32 doo 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}. @@ -51,8 +50,8 @@ ADCs & 2 (10 canais) \par O núcleo ARM Cortex M3 possui um conjunto de instruções de complexidade intermediária para um microcontrolador. Possui instruções para divisão em hardware, porém não embarca unidade de ponto flutuante. Possui um registrador contador de clocks, o que permite medição de intervalos de tempo com precisão de $1/F_{clk}$, onde $f_{clk} = 72MHz$. Possui também unidade de debug, que pode auxiliar durante o processo de desenvolvimento do firmware. \subsection{Linguagens de programação} -\par Foram usadas as linguagens de programação $C$ e $C++$, devido à sua capacidade de acomodar o programa compilado em pequenas quantidades de memória RAM e flash, o que é uma característica dos microcontroladores. Além disso, as linguagens escolhidas permitem que o programa seja executado em tempos determinísticos, aumentando a precisão do sistema de controle. -\par A biblioteca \textit{HAL} da STMicroelectronics foi utilizada como camada de abstração para o hardware e os periféricos do microcontrolador, o que facilita o desenvolvimento tirando a necessidade de conhecer profundamente a estrutura do microcontrolador e o mapeamento de memória e de registradores. Além disso, o uso da biblioteca \textit{HAL} facilita o futuro port do firmware para outros microcontroladores da mesma família. +\par Foram usadas as linguagens de programação $C$ e $C++$, devido à sua capacidade de acomodar o programa compilado em pequenas quantidades de memória RAM e \textit{flash}, o que é uma característica dos microcontroladores. Além disso, as linguagens escolhidas permitem que o programa seja executado em tempos determinísticos, aumentando a precisão do sistema de controle. +\par A biblioteca \textit{HAL} da STMicroelectronics foi utilizada como camada de abstração para o \textit{hardware} e os periféricos do microcontrolador, o que facilita o desenvolvimento tirando a necessidade de conhecer profundamente a estrutura do microcontrolador e o mapeamento de memória e de registradores. Além disso, o uso da biblioteca \textit{HAL} facilita a futura portabilidade do \textit{firmware} para outros microcontroladores da mesma família. \subsection{Ferramenta STM32Cube} \par Em programação de microcontroladores, é necessário chamar as rotinas de inicialização dos periféricos. Porém, mesmo com o USO da biblioteca \textit{HAL}, seria necessário conhecer as capacidades e limitações do microcontrolador, para que não fosse feita uma inicialização não suportada, e para que as inicializações dos periféricos fossem feitas da forma correta. @@ -67,7 +66,8 @@ ADCs & 2 (10 canais) \end{figure} \subsection{Programação orientada a interrupções} -\par Foi utilizado um fluxo de programa chamado de programação orientada a interrupções, onde 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 é chamada 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 debug. +% Referência +\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 @@ -77,8 +77,9 @@ ADCs & 2 (10 canais) \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 do PWM. +\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. \begin{equation} @@ -86,21 +87,22 @@ ADCs & 2 (10 canais) \label{eqn:derivadaDiscreta} \end{equation} -\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 fio resolvido limitando-se o termo integral entre dois valores, determinados experimentalmente fazendo-se um balanço entre erro de estado estacionário e estabilidade do sistema. +% 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. +% 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. \section{Determinação das constantes do PID} -\par Tendo desenvolvido o firmware, é necessário agora determinar as constantes do controlador PID. Em versões anteriores do firmware, as constantes $kp$, $ki$ e $kd$ foram determinadas experimentalmente por métodos de 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 software descritas no capítulo \ref{chap:intro}. +\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}. \subsection{Identificação da planta} -\par Para a calibração de qualquer tipo de sistema de controle, é 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}$. +\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}$. \par Uma forma de encontrar $K_p$ e $T_{p1}$ é encontrar uma planta que, quando feita a simulação, tenha resposta ao degrau em malha aberta próxima à do sistema real. A ferramenta \textit{pidTuner} do \textit{Matlab} aliada ao \textit{Systems Identification Toolbox} é capaz de encontrar esta planta que se ajusta quando alimentada com a resposta ao degrau da planta real. - -\subsubsection{Captura da resposta ao degrau no LabVIEW} \par Assim, a primeira etapa para identificação da planta é capturar a resposta ao degrau do motor DC do robô de desenvolvimento, o que foi feito com a ferramenta em \textit{LabVIEW}, conforme a figura \ref{fig:pidTuner1} \begin{figure}[!ht] @@ -110,30 +112,15 @@ ADCs & 2 (10 canais) \label{fig:pidTuner1} \end{figure} -\subsubsection{Exportação para o Matlab} -\par Em seguida, os dados do gráfico \textit{Output} foram exportados para o \textit{Matlab}, conforme a figura \ref{fig:pidTuner2} -\par Após importar os dados no \textit{Matlab}, foram selecionadas apenas as colunas relevantes e apenas o intervalo de tempo que fazia com que a aplicação do degrau fosse no tempo $t = 0$, desconsiderando o intervalo antes do degrau ser aplicado e depois de ser aplicado o degrau de descida. -\par Os dados selecionados podem ser vistos na figura \ref{fig:pidTuner3}, onde a coluna \textit{AmplitudeSpeed0} é a velocidade atual da roda em $mm/s$ e a coluna \textit{AmplitudeDesiredSpeed0} é o degrau de tensão aplicado ao motor, normalizado, onde $0$ significa motor desligado (em curto) e $1$ significa a tensão total da bateria ($12.6V$) aplicada ao motor. Cada linha da tabela significa uma amostra, onde as amostras são captadas à frequência de $100Hz$, ou seja, em intervalos de $10ms$. -\par O vetor com as velocidades em função do tempo, chamado na tabela de \textit{AmplitudeSpeed0}, foi chamado no \textit{Workspace} do \textit{Matlab} de \textit{riseArray}. +\par Em seguida, os dados do gráfico \textit{Output} foram exportados para o \textit{Matlab}. Foram selecionados apenas os dados relevantes para identificação da planta e apenas o intervalo de tempo que fazia com que a aplicação do degrau fosse no tempo $t = 0$, desconsiderando o intervalo antes do degrau ser aplicado e depois de ser aplicado o degrau de descida. -\newpage - -\begin{multicols}{2} -\begin{figure}[H] +\begin{figure}[!ht] \centering - \includegraphics[width=\linewidth]{img/pidTuner/2.png} - \caption{Dados importados no Matlab} + \includegraphics[width=\linewidth]{img/placeholder.png} + \caption{Gráfico com dados importados no Matlab} \label{fig:pidTuner2} \end{figure} -\begin{figure}[H] - \centering - \includegraphics[width=\linewidth]{img/pidTuner/3.png} - \caption{Dados relevantes selecionados} - \label{fig:pidTuner3} -\end{figure} -\end{multicols} -\subsubsection{Importação da resposta ao degrau no \textit{pidTuner}} \par Foi então aberta a ferramenta \textit{pidTuner}, e utilizado o comando \textit{Import step response}, que abriu a janela da figura \ref{fig:pidTuner4}, onde foi possível importar o \textit{riseArray} gerado no passo anterior. Nesta mesma janela foram colocados os dados da entrada degrau, como amplitude de $1$ e tempo de amostragem de $0.01s$. \begin{figure}[!ht] @@ -143,25 +130,17 @@ ADCs & 2 (10 canais) \label{fig:pidTuner4} \end{figure} -\subsubsection{Simulação da planta e ajuste} -\par Em seguida, a ferramenta automatizada do \textit{Matlab} foi utilizada para encontrar por métodos numéricos iterativos uma planta que, quando simulada, melhor se ajusta à resposta ao degrau da planta a ser identificada. Na figura \ref{fig:pidTuner5}, a resposta ao degrau importada pode ser vista no gráfico à direita com linha verde, enquanto a resposta ao degrau da planta simulada pode ser vista em azul. Note que a resposta ao degrau importada é de um sistema discreto a tempo discreto. Assim, os valores de tempo e velocidade são discretos. - -\begin{figure}[!ht] - \centering - \includegraphics[width=\textwidth]{img/pidTuner/5.png} - \caption{Planta sendo identificada} - \label{fig:pidTuner5} -\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, conforme mostrado na figura \ref{fig:pidTuner6} 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 Em seguida, a ferramenta automatizada do \textit{Matlab} foi utilizada para encontrar por métodos numéricos iterativos uma planta que, quando simulada, melhor se ajusta à resposta ao degrau da planta a ser identificada. Na figura \ref{fig:pidTuner6}, a resposta ao degrau importada pode ser vista no gráfico à direita com linha verde, enquanto a resposta ao degrau da planta simulada pode ser vista em azul. Note que a resposta ao degrau importada é de um sistema discreto a tempo discreto. Assim, os valores de tempo e velocidade são discretos. \begin{figure}[!ht] \centering \includegraphics[width=\textwidth]{img/pidTuner/6.png} - \caption{Planta do motor do robô de desenvolvimento identificada} + \caption{Planta sendo identificada} \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$. + \begin{equation} \frac{v(s)}{dutyCycle(s)} = \frac{K_p}{1 + T_{p1}s} \label{eqn:ftMotorRoboDesenvolvimento} @@ -173,17 +152,10 @@ ADCs & 2 (10 canais) \end{equation} \subsection{Otimização do controle PID} -\par Tendo a função de transferência da planta, agora 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 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 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. -\begin{figure}[!ht] - \centering - \includegraphics[width=\textwidth]{img/pidTuner/7.png} - \caption{Controlador PID otimizado} - \label{fig:pidTuner7} -\end{figure} - -\par Na figura \ref{fig:pidTuner7}, vê-se a ferramenta mostrando a resposta ao degrau em malha fechada para o controlador PID desejado, além das constantes $kp$, $ki$ e $kd$ para o mesmo controlador. A resposta do robô de desenvolvimento com o controlador aplicado encontra-se na figura \ref{fig:pidTuner8} +\par Na figura \ref{fig:pidTuner8}, vê-se a ferramenta mostrando a resposta ao degrau em malha fechada para o controlador PID desejado, além das constantes $kp$, $ki$ e $kd$ para o mesmo controlador. Na mesma figura \ref{fig:pidTuner8} vê-se também a resposta do robô de desenvolvimento com o controlador aplicado. \ref{fig:pidTuner8} \begin{figure}[!ht] \centering @@ -192,7 +164,6 @@ ADCs & 2 (10 canais) \label{fig:pidTuner8} \end{figure} - \section{Identificação do deslizamento} \par Tendo o robô com controlador PID calibrado, o primeiro passo para resolver os problemas de deslizamento é identificar as condições que levam a deslizamento. Após extensas observações, foi decidido utilizar a comparação da aceleração das rodas, medida pela segunda derivada da posição dos encoders, com a aceleração do chassi do robô, medida pelo sensor acelerômetro do IMU. Sendo assim, considera-se que há deslizamento quando a diferença entre as acelerações é maior do que um certo valor limite. Caso o deslizamento seja identificado, serão adotadas as medidas corretivas a definir. diff --git a/Documentation/abntex2ime/teoria.tex b/Documentation/abntex2ime/teoria.tex index 5a7c825..09edd18 100644 --- a/Documentation/abntex2ime/teoria.tex +++ b/Documentation/abntex2ime/teoria.tex @@ -1,13 +1,15 @@ -\chapter{Teoria} +\chapter{Fundamentação teórica} \label{chap:teoria} -\section{Modelagem do motor DC} -\par O motor DC utilizado nos três robôs é do tipo com escovas (brushed) de ímã permanente. Uma representação gráfica desse tipo de motor pode ser vista na figura \ref{fig:diagramamotordc} +\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} \begin{figure}[!ht] \centering \includegraphics[width=\textwidth]{img/MotorDC-crop.pdf} - \caption{Representação gráfica de um motor DC. Tirado de \cite{Refdiagramamotordc}} + \caption{Representação gráfica de um motor DC. Fonte: \cite{Refdiagramamotordc}} \label{fig:diagramamotordc} \end{figure} @@ -24,13 +26,14 @@ e = K_e \cdot \dot{\theta}_m \end{equation} -\par Onde $e$ é a força eletromotriz induzida, $K_e$ é uma constante de proporcionalidade a ser determinada experimentalmente, chamada aqui de constante elétrica, e $\dot{\theta}$ é a velocidade angular do motor. +\noindent em que $e$ é a força eletromotriz induzida, $K_e$ é uma constante de proporcionalidade a ser determinada experimentalmente, chamada aqui de constante elétrica, e $\dot{\theta}$ é a velocidade angular do motor. \par Sendo assim, o motor DC pode ser modelado segundo o seguinte circuito elétrico e diagrama de corpo livre \cite{Franklin2019-dx}: +% Colocar Va com V maiúsculo \begin{figure}[!ht] \centering \includegraphics[width=\textwidth]{img/CircuitoMotorDC-crop.pdf} - \caption{Circuito equivalente e diagrama de corpo livre de um motor DC. Tirado de \cite{Franklin2019-dx}} + \caption{Circuito equivalente e diagrama de corpo livre de um motor DC. Fonte: \cite{Franklin2019-dx}} \label{fig:circuitomotordc} \end{figure} @@ -40,14 +43,15 @@ e = K_e \cdot \dot{\theta}_m \frac{\theta_m(s)}{V_a(s)} = \frac{K_t}{s [(Js + b)(Ls + R) + K_tK_e ]} \end{equation} -\par Onde $\theta_m$ é o ângulo do motor, $V_a$ é a tensão aplicada ao enrolamento, $K_t$ é a constante de torque do motor DC, $K_e$ é a constante elétrica, $J$ é o momento de inércia, $b$ é a constante de atrito viscoso, $L$ é a indutância do enrolamento e $R$ é a resistência do enrolamento. -\par Caso queiramos a função de transferência da velocidade, podemos calculá-la multiplicando a da posição por $s$, assim: +\noindent em que $\theta_m$ é o ângulo do motor, $V_a$ é a tensão aplicada ao enrolamento, $K_t$ é a constante de torque do motor DC, $K_e$ é a constante elétrica, $J$ é o momento de inércia, $b$ é a constante de atrito viscoso, $L$ é a indutância do enrolamento e $R$ é a resistência do enrolamento. +\par Caso queiramos a função de transferência da velocidade, que é a derivada da posição, podemos calculá-la multiplicando a função de transferência da posição por $s$, assim: \begin{equation} \frac{\dot{\theta}_m(s)}{V_a(s)} = \frac{K_t}{(Js + b)(Ls + R) + K_tK_e} \label{eqn:ftMotorDCCompleta} \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: \begin{equation} @@ -65,7 +69,7 @@ T_{p1} = \frac{RJ}{bR + K_tK_e} \end{equation} \par As constantes $K_p$ e $T_{p1}$ podem tanto ser calculadas matematicamente pelas equações acima quanto determinadas experimentalmente com o auxílio de uma bancada de testes e ferramentas computacionais. -\par Diante disso, percebe-se que o motor DC é aproximadamente um sistema linear invariante no tempo (LTI) de primeira ordem e, portanto, é atendido por toda a teoria de controle desenvolvida para esse tipo de sistema. +\par Diante disso, percebe-se que o motor DC pode ser modelado como um sistema linear invariante no tempo (LTI) de primeira ordem e, portanto, é atendido por toda a teoria de controle desenvolvida para esse tipo de sistema. \section{Controle PID} @@ -80,14 +84,15 @@ 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{DutyCycle}{Erro} = kp + \frac{ki}{s} + kd \cdot s +\frac{U(s)}{E(s)} = kp + \frac{ki}{s} + kd \cdot s \label{eqn:ftPIDIdeal} \end{equation} -\par Onde $kp$, $ki$ e $kd$ são constantes chamadas respectivamente de proporcional, integral e derivativa. 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 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 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 será o da figura \ref{fig:diagramaPIDRobo}. +\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}. \begin{figure}[!ht] \centering