Modification du CR et CR reu_2 avec M. Frezza-Buet
This commit is contained in:
parent
2a4b9952fe
commit
d35787c7e2
4 changed files with 24 additions and 48 deletions
Binary file not shown.
|
@ -29,31 +29,15 @@
|
|||
|
||||
\chapter{Introduction}
|
||||
|
||||
Le campus de Metz de CentraleSupélec dispose
|
||||
|
||||
Les quadricoptères Bebop 2 (Parrot) dont nous disposons sur le campus sont des drones
|
||||
« nerveux », au sens où ils sont capables d’effectuer des mouvements rapides (changements de
|
||||
direction brusques, accélérations et freinages brutaux).
|
||||
Piloter ces drones en intérieur est délicat, il faut y aller doucement pour éviter de percuter un mur,
|
||||
d’autant plus que les turbulences générées par le drone lui-même le perturbent quand on est en
|
||||
intérieur. Or y aller doucement revient à sous-exploiter les capacités de ces drones.
|
||||
La solution sur laquelle nous travaillons se base sur un asservissement visuel du drone. Le drone
|
||||
détecte une cible dans l’image (cf démo que vous avez peut-être vue), et peut déduire de la forme de
|
||||
cette cible dans l’image sa position par rapport à la cible. L’idée est de contrôler le drone pour qu’il
|
||||
se place en face de la cible, à une distance fixée. Ainsi, si l’on bouge la cible (on l’avance, on la
|
||||
tourne), le drone se déplace pour toujours lui faire face, à la bonne distance.
|
||||
Aujourd’hui, cette démo est opérationnelle, mais le contrôleur est « prudent », le drone bouge assez
|
||||
lentement pour faire face à la cible quand celle-ci est déplacée par un opérateur. L’objet du projet
|
||||
est d’appliquer des techniques d’automatique pour rendre cet asservissement le plus « rigide »
|
||||
possible, comme si une barre invisible rigide liait le drone à la cible.
|
||||
La prise en main du drone, la perception de la cible sur les images, se feront à partir d’un projet
|
||||
existant, sous ROS/Linux (le projet est l’occasion d’apprendre à utiliser cet environnement
|
||||
robotique standard). L’étude réalisée consistera à travailler sur la qualité de l’asservissement en
|
||||
appliquant une approche automatique du problème.
|
||||
Les développements se feront sous ROS/Linux, en python (ou C++ si vous le souhaitez). La finalité
|
||||
du projet dépasse le cadre de cette démo, puisque le contrôle « rigide » du drone selon un critère
|
||||
visuel est également souhaitable pour la navigation dans les couloirs, dans les escaliers, sujets qui
|
||||
sont à l’étude dans d’autres projets qui se focalisent sur le traitement d’image plus que sur une
|
||||
approche rigoureuse de l’asservissement.
|
||||
Le campus de Metz de CentraleSupélec dispose de drones appelés les quadricoptères Bebop 2 (Parrot). Ces derniers sont capables de réaliser des mouvements brusques ce qui rend leur pilotage complexe. Il faut donc manipuler ces derniers avec précautions, ce qui revient à sous-exploiter leurs capacités.\\
|
||||
Jusqu'à présent, le drone était asservi à l'aide d'une cible présente dans son champ visuel. Le drone suivait la cible (bleu) et se positionnait en face de cette dernière. Toutefois, le drone se déplaçait lentement et se montrait prudent. De plus, une fois face à la cible, le drone n'était pas stable. Il oscillait verticalement face à la cible.\\
|
||||
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 :
|
||||
\begin{itemize}
|
||||
\item Etape 1 : Prise en main de ROS et du drone présent à la smartroom;
|
||||
\item Etape 2 : Mesures et établissement de la fonction de transfert du drone nous permettant d'estimer le meilleur correcteur à appliquer
|
||||
\item Etape 3 : Choix du correcteur et tests de ce dernier
|
||||
\end{itemize}
|
||||
\end{document}
|
||||
|
|
BIN
reunions/reu_2/cr_reu_7_fevrier.pdf
Normal file
BIN
reunions/reu_2/cr_reu_7_fevrier.pdf
Normal file
Binary file not shown.
|
@ -1,4 +1,6 @@
|
|||
\documentclass[a4paper]{article}
|
||||
\usepackage[utf8]{inputenc}
|
||||
\usepackage[T1]{fontenc}
|
||||
\usepackage{geometry} % Required for adjusting page dimensions
|
||||
|
||||
\geometry{
|
||||
|
@ -12,40 +14,30 @@
|
|||
}
|
||||
|
||||
%opening
|
||||
\title{Compte rendu de la réunion du Jeudi 7 Janvier 2019}
|
||||
\title{Compte rendu de la réunion du Jeudi 7 Février 2019}
|
||||
\author{Présents : Hervé Frezza-Buet, Joanne Steiner, Hugo Levy-Falk}
|
||||
\date{}
|
||||
|
||||
\begin{document}
|
||||
|
||||
\maketitle
|
||||
M. Frezza-Buet nous a reçu dans son bureau pour afin
|
||||
M. Frezza-Buet nous a reçu dans son bureau afin de discuter des problèmes d'asservissements que nous avons évoqué avec M. Gutzwiller au préalable ainsi que pour nous expliquer le fonctionnement du drone.
|
||||
|
||||
\section{Asservissement}
|
||||
\section{Mesures}
|
||||
|
||||
Nous utiliserons probablement un correcteur PID pour l'asservissement. Une des principales difficulté consiste à caractériser le comportement du drone, en particulier en ce qui concerne le diagramme de Bode en phase. Il nous faut caractériser la réaction du drone, mais également de la mesure. Nous avons établi une liste de questions auxquelles répondre dans la suite.
|
||||
Nous avons accès à la position du drone par rapport à la cible en x et en y. Nous avons également accès à un angle donné par la caméra (qui est à calibrer) qui nous permet d'obtenir la position du drone dans l'espace.\\
|
||||
|
||||
\begin{itemize}
|
||||
\item Combien de boucles d'asservissement la régulation du drone comporte-t-elle ?
|
||||
\item Ces boucles sont-elles indépendantes ?
|
||||
\item Si non, comment les rendre indépendantes ?
|
||||
\item Pour les rendre indépendantes, nous avons besoin de savoir quelles mesures sont à notre disposition.
|
||||
\item Les communications réseau induisent des retards aléatoires. Comment gérer l'arrivée de données obsolètes ?
|
||||
\item L'absence de données ?
|
||||
\item Plus généralement comment les prendre en compte dans la régulation afin de ne pas risquer d'avoir un système instable ? \footnote{M. Gutzwiller nous a fait remarquer à ce propos l'existence de la correction P I Retard, qui semble à première vue adaptée à ce problème.} On pourra se rendre compte de l'existence d'un retard pur dans la boucle si la pente à l'origine du diagramme de phase n'est pas nulle.
|
||||
\item La fréquence d'échantillonnage des mesures est-elle constante ?
|
||||
\item Si non, comment le prendre en compte dans l'asservissement ou la rendre constante ?
|
||||
\item L'influence de la discrétisation est-elle importante sur la stabilité ici ?
|
||||
\end{itemize}
|
||||
En intérieur, nous allons pouvoir prendre en compte uniquement l'accélération, sans prendre en compte les frottements, ces derniers étant négligeables.\\
|
||||
|
||||
Dans un premier temps on fera probablement l'hypothèse de la linéarité du système autour d'un point de fonctionnement. Si le temps le permet il pourra être intéressant de se pencher sur l'aspect non linéaire du problème.
|
||||
Concernant la fréquence d'échantillonnage, cette dernière est d'environ 10Hz. Toutefois, lorsqu'il faut réaliser des mesures, elle s'estime plutôt aux alentours de 5Hz. Il nous faudra donc choisir une fréquence d'échantillonnage de cet ordre pour nos calculs.\\
|
||||
|
||||
De plus, M. Frezza-Buet nous a conseillé de voir, sur son Github, demo-teleop et de nous intéresser, en particulier, au noeud safe\_drone\_teleop.
|
||||
|
||||
\section{Commande du drone}
|
||||
La commande du drone s'effectue par le réglagle des couples appliqués sur les moteurs (il y en a 4 en tout) qui permettent de gérer la position et la vitesse du drone. Nous avons alors accès aux vitesses selon les trois axes Vx, Vy et Vz, ainsi qu'à la rotation selon z, Rz. Les commandes selon les axes X et Y sont faites en accélérations, tandis qu'elles sont linéaires selon Z. M. Frezza-Buet nous a indiqué de nous intéressé au module bebop-autonomy afin de gérer le drone à l'aide d'un joystick.\\
|
||||
|
||||
\section{Déroulement du projet}
|
||||
|
||||
M. Gutzwiller souhaite des réunions régulières, idéalement toutes les 2 séances de projet, ces réunions devront être planifiées par nous. Un compte rendu envoyé par mail devra suivre chaque réunion.
|
||||
|
||||
Le rapport doit être avancé en temps réel et envoyé par mail avant chaque réunion. Il faut également donner un ordre du jour avec les questions à aborder pour chaque réunion.
|
||||
|
||||
La dernière séance de projet est le 29/05/2019, la semaine suivante semble adaptée pour planifier la soutenance. Elle prendra la forme d'une présentation orale supportée par un diaporama.
|
||||
Pour la suite, il va donc falloir que nous finissions de prendre en main ROS. Ensuite, nous allons commencer à réaliser les mesures sur le drone dans l'objectif d'établir la réponse fréquentiel de ce dernier. M. Frezza-Buet nous a suggéré de procéder par identification en estimant la forme de la fonction de transfert du drone (inconnue pour le moment) et en adaptant les paramètres de cette dernière. Une fois ceci fait, nous allons pouvoir nous intéresser au meilleur moyen d'asservir le drone afin de le corriger.
|
||||
|
||||
\end{document}
|
||||
|
|
Loading…
Reference in a new issue