261 lines
25 KiB
TeX
261 lines
25 KiB
TeX
\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 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}.
|
|
|
|
\begin{figure}[!ht]
|
|
\centering
|
|
\includegraphics[width=0.75\textwidth]{img/BluePill.jpg}
|
|
\caption{Placa \textit{BluePill} com STM32F103C8T6}
|
|
\label{fig:BluePill}
|
|
\end{figure}
|
|
|
|
\par O STM32F103C8T6 possui as especificações técnicas da tabela \ref{tab:specsBluePill}
|
|
|
|
\begin{table}[ht]
|
|
\centering
|
|
\caption{Especificações do STM32F103F8T6}
|
|
\vspace{0.5cm}
|
|
\begin{tabular}{r|lr}
|
|
|
|
Componente & Especificação \\
|
|
\hline
|
|
Arquitetura & ARM Cortex M3 \\
|
|
Frequência de clock & 72MHz \\
|
|
Memória flash & 64kB \\
|
|
Memória RAM & 20kB \\
|
|
Tensão de operação & 3.3V \\
|
|
Timers & 4 \\
|
|
Periféricos SPI & 2 \\
|
|
Periféricos $I^2C$ & 2 \\
|
|
Periféricos UART & 3 \\
|
|
GPIOs & 37 \\
|
|
ADCs & 2 (10 canais)
|
|
|
|
\end{tabular}
|
|
\label{tab:specsBluePill}
|
|
\end{table}
|
|
|
|
\par Dos quatro timers do microcontrolador, um deles é utilizado para gerar os sinais PWM para alimentação dos motores, e dois são utilizados para leitura dos encoders, deixando um para interrupções à taxa de controle, o que permite que a programação seja feita orientada a interrupções.
|
|
\par Possui um controlador de interrupções que permite preempções, além de definição de prioridades de preempção e de despacho das rotinas de serviço de interrupção (ISRs).
|
|
\par O nível lógico de 3.3V torna o microcontrolador compatível com a maioria dos componentes e sensores encontrados no mercado, e com todos os presentes no robô de desenvolvimento, sem a necessidade de conversores de nível, o que permite taxas de comunicação maiores.
|
|
\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 \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.
|
|
\par Dessa forma, a ferramenta STM32Cube facilita este processo, pois permite a configuração e inicialização dos periféricos por uma interface gráfica, já adaptada às características e limitações de cada microcontrolador. Após a configuração, a ferramenta gera o código em $C$ da configuração e inicialização da biblioteca \textit{HAL}.
|
|
\par A interface de configuração do STM32Cube está na figura \ref{fig:STM32Cube}.
|
|
|
|
\begin{figure}[!ht]
|
|
\centering
|
|
\includegraphics[width=\textwidth]{img/STM32Cube.png}
|
|
\caption{Interface do STM32Cube}
|
|
\label{fig:STM32Cube}
|
|
\end{figure}
|
|
|
|
\subsection{Programação orientada a interrupções}
|
|
% 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}
|
|
\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}
|
|
\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:
|
|
\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}
|
|
|
|
\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}
|
|
\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: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}$.
|
|
\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.
|
|
\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]
|
|
\centering
|
|
\includegraphics[width=\textwidth]{img/pidTuner/1.png}
|
|
\caption{Ferramenta em LabVIEW capturando a resposta ao degrau do motor}
|
|
\label{fig:pidTuner1}
|
|
\end{figure}
|
|
|
|
\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.
|
|
|
|
\begin{figure}[!ht]
|
|
\centering
|
|
\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}
|
|
|
|
\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]
|
|
\centering
|
|
\includegraphics[width=\textwidth]{img/pidTuner/4.png}
|
|
\caption{Importação da resposta ao degrau no pidTuner}
|
|
\label{fig:pidTuner4}
|
|
\end{figure}
|
|
|
|
\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 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, 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}
|
|
\label{eqn:ftMotorRoboDesenvolvimento}
|
|
\end{equation}
|
|
\begin{equation}
|
|
K_p = 1108,7 \quad
|
|
T_p1 = 0,073597
|
|
\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}
|
|
\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.
|
|
|
|
\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
|
|
\includegraphics[width=\textwidth]{img/pidTuner/8.png}
|
|
\caption{Robô com PID otimizado}
|
|
\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.
|
|
|
|
\begin{figure}[!ht]
|
|
\centering
|
|
\includegraphics[width=0.75\textwidth]{img/FluxogramaSlipDetection-crop.pdf}
|
|
\caption{Fluxograma da detecção do deslizamento}
|
|
\label{fig:fluxogramaSlipDetection}
|
|
\end{figure}
|
|
|
|
\par A figura \ref{fig:fluxogramaSlipDetection} apresenta o fluxograma da detecção do deslizamento, implementada no programa em LabVIEW, junto com a interface gráfica.
|
|
\par Em primeiro momento, é coletada a entrada do operador do robô, sendo esta a velocidade de reverência desejada para o robô, chamada de $desiredSpeed$ no programa. Em seguida, $desiredSpeed$ e $slip$ são enviados para o robô pela comunicação UDP, e um pacote de \textit{feedback} é recebido, contendo a velocidade do robô medida pelo \textit{encoder}, chamada de $currentSpeed$ e a aceleração do chassi, medida pelo sensor IMU. $currentSpeed$ é então derivada, obtendo-se a aceleração $encoderAccel$, que é a aceleração da roda medida pelo \textit{encoder}. Além disso, a aceleração do chassi é filtrada também por filtro passa-baixa, obtendo-se $imuAccel$.
|
|
\par As acelerações são então comparadas e, caso sua diferença supere o valor de $threshold$ definido no programa, é considerado que o robô está em condição de deslizamento, e a variável $slip$ é definida como verdadeira e enviada para o robô junto com o próximo comando, para que o robô, sabendo de sua condição de deslizamento, tome as medidas corretivas cabíveis.
|
|
|
|
\section{Correção do deslizamento}
|
|
\par A solução corretiva adotada foi desabilitar o motor nos casos de deslizamento. Desabilitando o motor, seu torque será zerado e, portanto, o único torque aplicado sobre a roda será aquele realizado pela força de atrito. Assim, a roda voltará a ter aderência com o chão e o deslizamento será corrigido.
|
|
\par A ponte H utilizada no robô de desenvolvimento, com seu esquema elétrico simplificado na figura \ref{fig:schematicPonteH}, permite que cada terminal do motor seja conectado aos potenciais de terra, $VBAT$, ou deixar desconectado. Em condições normais, caso se queira rotação para a frente, o PWM do motor é controlado chaveando-se entre os MOSFETs $MAH$ e $MAL$, enquanto $MBH$ é mantido conduzindo e $MBL$ é mantido aberto. Para rotação reversa, é adotado o caso análogo. Em condições de deslizamento, todos os MOSFETs são mantidos em aberto, cessando a passagem de corrente pelo motor e, consequentemente, zerando seu torque.
|
|
|
|
\begin{figure}[!ht]
|
|
\centering
|
|
\includegraphics[width=0.75\textwidth]{img/SchematicPonteH-crop.pdf}
|
|
\caption{Esquema elétrico de uma ponte H semelhante à utilizada no robô}
|
|
\label{fig:schematicPonteH}
|
|
\end{figure} |