klafyvel/drone-rigide
1
0
Fork 0
Code Issues Pull requests Releases Wiki Activity

Update compte_rendu.tex

Browse source
This commit is contained in:
joanne-ste 2019-04-09 16:12:58 +02:00
parent e940bedbd3
commit 8cd38259be
1 changed files with 55 additions and 5 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

60
compte_rendu/compte_rendu.tex
View file

@ -45,11 +45,13 @@ Jusqu'à présent, le drone était asservi à l'aide d'une cible présente dans
L'objectif de ce projet est donc de rendre l'asservissement du drone plus "rigide" et donc d'améliorer et de mieux exploiter l'utilisation de ce dernier.
\chapter{Déroulement du projet}
Le projet comportera les étapes suivantes :
Le projet comporte les étapes suivantes :
\begin{itemize}
\item Etape 1 : Prise en main de ROS et du drone présent à la smartroom;
\item Etape 2 : Réduction du bruit causé par le calcul de la position du drone par rapport à l'image
\item Etape 3 : Choix du correcteur et tests de ce dernier
\item Etape 3 : Choix du correcteur simple boucle
\item Etape 4 : Choix du correcteur double boucle
\item Etape 5 : Ecriture d'un guide de fonctionnement
\end{itemize}
\chapter{Modélisation du problème}
@ -108,7 +110,55 @@ Comme le traitement ne se fait pas directement sur le drone, il existe des retar
\section{Prise en main de ROS et du drone présent à la smartroom}
Pour la prise en main de ROS, nous avons suivi les étapes du tutoriel de M. Frezza-Buet. Cela nous a permis de comprendre comment fonctionne ROS et de pouvoir l'utiliser de manière basique et simple.\\
\section{Réduction du bruit causé par le calcul de la position du drone par rapport à l'image}
Nous avons constaté qu'une forte incertitude existait lors du calcul de la position du drone par rapport au panneau. En effet, celle-ci, même si le drone était immobile, bougeait beaucoup et faisait des "sauts". Il s'agissait d'un bruit de type de Poisson, difficile, voire impossible, à traiter en automatique pour obtenir un asservissement satisfaisant. En effet, le drone, avec ce bruit, aurait été asservi à ce dernier, rendant impossible l'obtention d'une position fixe.\\
Afin de régler ce problème, l'idée proposait a été de modifier l'algorithme en place. Ce dernier calcul la position des trois carrés bleus dans l'image renvoyé par le drone par les position H, R et L. Cette détermination se faisait par gngt, qui faisait beaucoup de bruit. Nous avons donc utilisé un nouveau script Python qui profite de la labellisation afin de déterminer la position des panneaux.\\
Ce script est donné dans le fichier "\textbf{find\_ targets.py}". Il permet, à partir d'un seuil RGB défini, de trouver les parties "bleues" de l'image. Une fois ces positions trouvées, on ne garde que les trois plus grandes parties et on en calcule le centre de masse. Les résultats obtenus sont plutôt satisfaisants.
Nous avons constaté qu'une forte incertitude existait lors du calcul de la position du drone par rapport au panneau. En effet, celle-ci, même si le drone était immobile, bougeait beaucoup et faisait des "sauts". Il s'agissait d'un bruit de type de Poisson, difficile, voire impossible, à traiter en automatique pour obtenir un asservissement satisfaisant. En effet, le drone, avec ce bruit, aurait été asservi à ce dernier, rendant impossible l'obtention d'une position fixe. Notre drone aurait fait de grands écarts par rapport à la position attendue.\\
Afin de régler ce problème, l'idée proposée a été de modifier l'algorithme en place. Ce dernier calcul la position des trois carrés bleus dans l'image renvoyée par le drone par les position H, R et L. Cette détermination se faisait par gngt, qui faisait beaucoup de bruit. Nous avons donc utilisé un nouveau script Python qui profite de la labellisation afin de déterminer la position des panneaux.\\
Dans cette partie, nous ne nous intéresserons qu'au script donné dans le fichier
\textbf{src$\backslash$detect\_targets$\backslash$script$\backslash$find\_targets.py}. Il permet, à partir d'un seuil RGB défini, de trouver les parties "bleues" de l'image. Une fois ces positions trouvées, on ne garde que les trois plus grandes parties et on en calcule le centre de masse. Les résultats obtenus sont plutôt satisfaisants.
\section{Premier asservissement sommaire}
Le premier asservissement qui a été réalisé n'utilisait qu'une seule boucle et asservissait la position du drone.\\
Pour ce premier asservissement sommaire, nous avons estimé la courbe de la réponse fréquentielle de notre drone afin d'en déduire le type de correcteur à utiliser.\\
Nous savons que selon l'axe z, le drone répond seulement en vitesse. On peut approximer sa réponse fréquence par une pente nulle en basse fréquence, puis une pente [-1] en haute fréquence. Afin d'asservir le drone, nous aurons donc besoin d'un correcteur de type proportionnel-intégrale
\[C(p)=K_p + \frac{K_i}{p}\]
Concernant les axes x et y, nous savons que le drone ne peut être correctement asservi en vitesse. En effet, le réglage de la vitesse et de l'accélération du drone se fait selon un angle d'inclinaison : le drone accélère en permanence s'il conserve le même angle ce qui ne permet pas le maintien d'une vitesse constante. La réponse fréquentielle selon ses axes est donc représentée par une pente de [-1] dans les basses fréquence et une pente de [-2] dans les hautes fréquences. Afin de corriger ces axes, nous allons donc utiliser une correction de type Proportionnelle-Dérivée :
\[C(p)=K_p+K_d p\]
\begin{figure}[h!]
\centering
\begin{tikzpicture}[auto, node distance=2cm,>=latex']
% We start by placing the blocks
\node [input, name=input] {};
\node [sum, right of=input, node distance=3cm] (sum) {};
\node [block, right of=sum] (controller) {$C_p(p)$};
\node [sum, right of=controller, node distance=3cm] (sum_speed) {};
\node [block, right of=sum_speed] (controller_speed) {$C_v(p)$};
\node [block, right of=controller_speed,
node distance=3cm] (system) {Drone};
\node [block, right of=system,
node distance=3cm] (integrate) {$\frac{1}{p}$};
\node [block, below of=controller_speed] (measurements_speed) {Mesure};
% We draw an edge between the controller and system block to
% calculate the coordinate u. We need it to place the measurement block.
\draw [->] (controller) -- node[pos=0.99] {$+$}
node [near end] {$u$} (sum_speed);
\node [output, right of=system, node distance=5cm] (output) {};
\node [block, below of=measurements_speed] (measurements) {Mesure};
% Once the nodes are placed, connecting them is easy.
\draw [draw,->] (input) -- node {position attendue +} (sum);
\draw [->] (sum) -- node {$\epsilon_p$} (controller);
\draw [->] (sum_speed) -- node {$\epsilon_v$} (controller_speed);
\draw [->] (controller_speed) -- node [name=x] {} (system);
\draw [->] (system) -- node [name=v] {} (integrate);
\draw [->] (measurements_speed) -| node[pos=0.99] {$-$}
node [near end] {mesure de la vitesse} (sum_speed);
\draw [->] (integrate) -- node [name=y] {position }(output);
\draw [->] (v) |- (measurements_speed);
\draw [->] (y) |- (measurements);
\draw [->] (measurements) -| node[pos=0.99] {$-$}
node [near end] {mesure de la position} (sum);
\end{tikzpicture}
\caption{Modélisation simple de l'asservissement}
\end{figure}
\section{Deuxième asservissement utilisant une double-boucle d'asservissement}
\section{Installation du module et utilisation de l'interface graphique}
Modules pour régler les seuils de couleur (on pourrait songer à utiliser des cibles rouges, à condition de modifier les seuils) et le correcteur : la valeur de la saturation en vitesse et en accélération peuvent se régler ainsi que les différentes valeurs du PID (il est toutefois déconseillé de modifier les valeurs, celles-ci ayant été adaptés au problème).
\end{document}