Raspcopter - Nouveau banc d'essai pour la configuration PID
par Florent Revest

Raspcopter - New PID Test Rig

Après les leçons tirées du dernier article, le Raspcopter dispose maintenant d'un tout nouveau banc d'essai. Cette fois la rotation est réellement bloquée sur un angle et le quadcopter ne peut plus s'élever. Il devient donc maintenant infiniment plus simple de régler les variables des PIDs qu'avant.

Ce nouveau banc d'essai est composé de deux tréteaux lestés soutenant un axe solide en métal autour duquel le drone et accroché et peut tourner.

On observe déjà des résultats beaucoup plus satisfaisants alors que les gains PID utilisés dans cette vidéo ont été grossierement choisis.

Commentaires

Raspcopter - Premiers tests de la configuration PID en vidéo
par Florent Revest

Raspcopter - First series of test-flights

Comme on a pu le voir, le système de vol du drone repose sur trois régulateurs PID distincts, un pour chaque angle. Or ces régulateurs doivent être réglés les uns après les autres et ce indépendamment et en toute sécurité avant de pouvoir espérer faire un vol à l'air libre. Pour régler ces valeurs il convient donc de bloquer les rotations possibles sur un seul angle. On réalise ceci en tenant le drone par une barre parallèle à un axe de rotation.

La première idée essayée a été d'utiliser deux cordes attachées à des barrières. Si cette idée a principalement débouché sur des échecs on peut tout de même relever quelques aspects intéressants et également en tirer des leçons. La vidéo ci-dessus présente une poignée de tests sur cette "base de travail"

Commençons par les points positifs : déjà on peut se réjouir du fait que le quadcopter décolle et ce dès 40 % de puissance des moteurs. Il semblerait donc que la puissance soit suffisante pour ajouter du poids supplémentaire (rappelons que la batterie du raspberry pi manque encore et que le drone est toujours relié par USB au sol...). Ces tests m'ont également permis de tester le drone et la station de contrôle dans la durée. Un onglet de l'interface au sol spécialement dédié au changement des valeurs PID à distance se révelle particulièrement utile maintenant.

Mais il y a également des points négatifs dans cette vidéo. Premièrement, l'amplitude de mouvement laissée au quadcopter ne le bloque pas réellement sur un angle donc si l'on travaille sur le roll on obtient des fluctuations du pitch et yaw qui rendent le travail difficile sinon impossible. De plus l'amplitude laissée en hauteur par les cordes pas assez tendues permet au quadcopter de s'élever à grande vitesse avant que le choc produit lorsque les cordes sont tendues rabatte violemment le drone vers le bas. (on voit particulièrement cet effet à 0:55).

Commentaires

Raspcopter - Premier crash
par Florent Revest

Mine de rien le projet Raspcopter avance, la base de code est même quasiment finie. Des fonctions de logging seraient à prévoir plus tard mais, ce n'est pas une priorité du tout, c'est même du luxe. Les articles plutôt techniques que j'ai pu écrire jusqu'à présent devraient donc maintenant faire place à une série d'articles davantage pratiques, visuels et grand public. Mais comme on s'en doute, le passage de la théorie à la pratique s'accompagne toujours de petits effets inattendus.

Qui dit premiers tests du drone dit immanquablement premiers crashs du drone. Et c'est exactement ce qui s'est produit dernièrement lorsque j'ai introduit un gain intégral non nul aux paramètres PID du quadcopter.

Le drone fonctionnait depuis plus d'une heure et demie, les variables intégrales qui contiennent la somme des erreurs d'angles dans le temps contenaient donc des valeurs gigantesques qui se sont soudainement retrouvées multipliées par un gain. Ceci a produit une vitesse de moteur maximale et le drone s'est immédiatement retourné avant de casser des hélices. Des investigations plus approfondies sur le comportement du gain intégral s'annoncent donc nécessaire.

Heureusement seules les hélices ont été endommagées, mais la commande de nouvelles pièces va faire prendre du retard au projet. J'ai donc pris cette fois le soin de commander 20 hélices pour avoir de l'avance sur les inévitables prochains crashs.

Commentaires

Raspcopter - Communication réseau
par Florent Revest

Jusqu'à présent, les problématiques rencontrées lors du développement du Raspcopter concernaient uniquement le système de vol embarqué au RaspberryPi. Puis plus récemment nous avons vu la station de contrôle au sol du projet. Ces deux derniers projets sont donc déjà dotés de plusieurs fonctions de contrôle, mais sans aucun moyen interactif de communiquer l'un avec l'autre. L'enjeu de cet article est d'expliquer les choix de communication sol-quadcopter qui ont été faits ainsi que leur implémentation.

Ce que l'on veut

Tout d'abord il est important de rappeller l'objectif principal du projet : comprendre le fonctionnement du système de vol d'un quadcopter, les problématiques liées au réseau ne sont donc évidemment pas la priorité et la facilité de développement et de déploiement est recherchée en priorité. Pourtant, il ne faut pas faire de concessions :

Les commandes de vol restent des données critiques qui doivent nécessairement transiter de manière sûre et rapide. Lors d'un virage, une perte de paquets ou une latence trop importante ne pardonnent pas.

On cherche également une certaine modularité de manière à pouvoir contrôler davantage de choses que les simples commandes de vol.

Pour finir, le quadcopter étant probablement amené à voler loin de la station de contrôle au sol, il est nécessaire d'utiliser une communication de longue portée.

Ce que l'on a

À ce point, le RaspberryPi ne comporte plus qu'un port USB libre puisque le second est occupé par le Pololu Maestro et tous les GPIOs sauf l'i2c. Il faut donc trouver un moyen de communication exploitant ces ports.

Ne l'oublions pas, le RaspberryPi fonctionne sous Raspbian (ou tout du moins, une version hardfloat très allégée) et donc sous un système d'exploitation Linux complet. Notre quadcopter bénéficie donc de tous les avantages de ce dernier, particulièrement en matière de pilotes de périphériques. Le choix des méthodes de communication est donc considérablement élargi par rapport à un autre système d'exploitation comme ChibiOS RT, FreeRTOS ou RTEMS.

À l'autre bout de la communication, le quadcopter devrait échanger avec un PC portable tournant également sous une distribution Linux standard et/ou avec un smartphone Android.

Comment passer de l'un à l'autre

Plusieurs choix de méthodes se présentent à nous, en voici les principaux :

La première, la plus évidente car utilisée par la plupart des quadcopters "normaux" est une communication analogique depuis une télécommande standard de quadcopter. Ce choix est intéressant dans la mesure où il utilise du matériel habituel pour un quadcopter et que la portée est excellente, mais il n'offre aucune modularité puisqu'il ne possède généralement qu'un canal par angle de rotation et pas de moyen de faire transiter des données autres dans le sens inverse... De plus le traitement du signal analogique sur le Raspberry Pi serait une tâche énorme et ne semble pas facilement envisageable.

Une solution un peu plus haut niveau consisterait à utiliser un module de communication sans fil comme le XBee, ces petites puces devenues assez standards sont déjà beaucoup plus modulaires et faciles à implémenter. Elles offrent également des portées suffisantes pour un projet de drone. Cette solution semble donc assez optimale si ce n'est qu'elle nécessite l'achat de composants couteux sur le RPi comme sur le PC portable, sans parler du smartphone Android...

Finalement, la solution retenue se trouve déjà probablement tout autour de vous... c'est le Wifi. Les avantages sont très nombreux. Premièrement, et ce n'est pas négligeable : le coût. Mais également la facilité de développement et de déploiement. Ainsi que la modularité de la communication Wifi, en effet la possibilité de garder une liaison SSH en cas de pépin ou de pouvoir éventuellement plus tard créer un stream vidéo d'une webcam facilement est très attrayante. Mais des questions restent encore en suspend : quid de la portée du Wifi, de la présence d'un routeur, ainsi que de la rapidité et la sûreté des données ?

Le déploiement physique du réseau

Le Wifi permet de n'effectuer aucune modification matérielle au niveau du PC portable et du téléphone, en revanche le choix de la clef présente sur le Raspberry Pi est plus important. Par chance, un vieux mediacenter attendait sous la poussière de mon placard que quelqu'un vienne lui débrancher sa clef wifi USB longue portée. Une antenne est donc présente sur le quadcopter pour bénéficier d'une communication sur de longues distances. Un test de portée est peut-être à prévoir à l'avenir. Idéalement la clef devrait permettre la création d'un hostpot wifi sur le quadcopter lui-même, mais malheureusement cette fonctionnalité n'est pas supportée par le driver Linux du chipset utilisé par le Raspcopter.

Le système de vol devra donc se connecter lui-même à un émetteur Wifi au sol. Deux possibilités seront présente: soit le téléphone émettra un réseau tethering auquel se connecteront le quadcopter et le PC portable à la manière d'un réseau local, soit ce sera le PC portable qui émettra le wifi.

Sur les appareils au sol, un logiciel client sera responsable de maintenir la communication avec le serveur présent sur le quadcopter.

Les détails de la communication

Selon le modèle OSI, les couches basses du réseau sont déjà assurées. Mais en ce qui concerne le protocole, des choix sont encore à faire :

À commencer par trancher entre une base TCP ou UDP. Une communication TCP a l'avantage d'être très sûre (tous les paquets arrivent et dans l'ordre) mais plus lourde et lente qu'une UDP qui elle n'offre pas ces contrôles, mais est beaucoup plus rapide. Finalement, le meilleur des deux mondes a été retrouvé dans une bibliothèque réseau nommée ENet. Premièrement destinée au développement de jeux vidéos, cette bibliothèque implémente un protocole UDP, mais gardant les fonctionnalités majeures de TCP. Le résultat est donc un excellent compromis entre les deux.

La libenet est donc utilisée sur le quadcopter et les clients au sol pour supporter un protocole spécifique. Chaque paquet de ce protocole est composé d'un octet entête d'opcode qui définit l'opération à effectuer puis d'une longueur variable contenant les données à transférer. La liste des opcodes se trouve dans l'header de la classe Network du code disponible sur GitHub.

Par exemple la commande permettant de modifier les valeurs du contrôleur PID du quadcopter depuis le sol est nommée SET_PID_VALUES et correspond à l'opcode hexadécimal 0x04. Le paquet associé commencera donc par un octet (char) valant 4 puis 9 floats contenant les trois valeurs des trois PIDs.

Sources

Commentaires

Raspcopter - Station de contrôle au sol
par Florent Revest

Le réseau étant un bien gros morceau qui fait prendre pas mal de retard au projet sans résultats forcément visibles, aujourd'hui nous allons brièvement parler du logiciel PC de contrôle au sol. L'article n'a pas pour but d'être véritablement technique comme les précédents, mais seulement informatif.

Un outil pratique

Il existe déjà d'innombrable logiciels complets de stations de contrôle au sol de quadcopters, comme celui d'Ardupilot par exemple. Forker un de ces projets était possible mais finalement Raspcopter s'est doté de son propre logiciel client de vol.

Ce dernier est développé en C++ à l'aide du framework Qt, il est donc portable et facile à maintenir ou étendre.

Un contrôleur

Tout d'abord la première tache de cette station est d'agir en tant que contrôleur, c'est à dire de récolter les données d'un joystick. Ce dernier est un joystick de jeux vidéos standard acheté en magasin pour une dizaine d'euros. La lecture de ses données se fait directement par ioctl via l'API noyau générique de contrôle de joystick.

Un client réseau

Les données de ce joystick sont ensuite transférées au drone par le réseau via le réseau qui sera expliqué dans l'article suivant. Mais la station de contrôle est également capable de recevoir des données du quadcopter par le même moyen.

Des données de télémétrie

Les données recueillies depuis le quadcopter concernent principalement l'historique des positions angulaires du drone mais il est prévu à l'avenir de pouvoir également garder un oeil sur le pourcentage d'utilisation processeur et mémoire du Raspberry Pi.

Deux bibliothèques graphiques de tièrce partie très pratiques ont été utilisées pour l'affichage agréable des données télémétriques: AnalogWidgets et QCustomPlot. Grâce à ces dernières, il est possible de garder un oeil sur des cadrans et un graphique des données mesurées, et ce en temps réel directement depuis le sol. La station de contrôle implémente également une fonction d'export de ces données au format .csv, ouvrable par un tableur comme LibreOffice Calc pour des diagnostiques ultérieurs en cas de problème, ce qui ne nous le cachons pas arrivera très souvent.

Le code source

Comme le reste du projet, la station de contrôle est open-source et entièrement retrouvable sur GitHub dans le dossier laptop-client. N'hésitez pas à star le projet si vous le jugez utile. Et si vous avez des questions diverses et variées, n'oubliez pas que vous pouvez me contacter.

Commentaires

Raspcopter - Première vidéo
par Florent Revest

Maintenant que le Raspcopter contrôle ses moteurs, connait sa position angulaire et sait relier les deux, il y a enfin de quoi filmer quelque chose d'intéressant !

Raspcopter - Motors control

Commentaires

Raspcopter - Contrôle des moteurs
par Florent Revest

Le dernier article a doté le système de vol du Raspcopter d'un algorithme puissant d'autorégulation angulaire. Pourtant, un détail a été passé sous silence et non des moindres: le "Feedback" représenté en bas du schéma du contrôleur PID assurant la fonction de boucle fermée. Ce retour sur erreur est bien sûr la gestion des vitesses des moteurs, l'objet de l'article d'aujourd'hui.

Ce que l'on veut

Comme tout objet volant, notre petit drone doit bénéficier d'une force de poussée verticale suffisamment grande pour le libérer de la gravité. Cette force c'est notre vieil ami Newton qui nous la donne dans sa troisième loi des actions réciproques. Les hélices du quadcopter poussent l'air vers le bas et par réaction, le drone est poussé vers le haut c'est aussi simple que ça.

Mais le drone introduit une contrainte : ces hélices doivent être entraînées à une vitesse assez conséquente et par des moteurs assez légers. Un type de moteur répond à cette problématique, les moteurs "sans balais" ou plus couramment appelés brushless.

Leur principe de fonctionnement est assez simple, ci dessus vous pouvez observer trois bobines (légendées coils) alimentées électriquement les unes après les autres pour créer un champ magnétique qui mettra en mouvement l'aiment du centre, portant l'axe tenant l'hélice. Les moteurs du Raspcopter utilisent 12 bobines mais le principe reste fondé sur l'alternance de trois d'entre elles, c'est d'ailleurs pour cette raison qu'il suffit d'inverser deux fils au hasard pour modifier le sens de rotation du moteur.

Ce que l'on a

On souhaite contrôler ces moteurs depuis le Raspberry Pi avec le minimum de latence possible. Le Raspberry Pi dispose de plusieurs interfaces, principalement les GPIOs et l'USB. La première idée semblant la plus naturelle serait de contrôler les moteurs depuis les pins GPIOs mais c'est en fait impossible car la fréquence de changement de bobines ne serait jamais suffisante et l'énergie délivrée serait elle aussi bien trop faible.

Comment passer de l'un à l'autre ?

Pour cette raison, on fait toujours appel à des "ESCs" (electronic speed controlers) placés en amont de chaque moteur, ces circuits électroniques sont alimentés par deux câbles provenant de la batterie LiPo et reçoivent des données PWM (pulse width modulation, c'est à dire codées sur des longueurs de pulsations électriques) depuis trois fils, exactement de la même manière qu'un servomoteur. En sortie de ces contrôleurs, trois câbles sont soudés au moteur brushless et alternent l'alimentation des bobines comme vu précédement. L'ESC choisi est un modèle 20A UBEC de HobbyKing.

On simplifie déjà le problème, car envoyer un signal PWM depuis les GPIOs du Raspberry Pi n'est plus chose impossible, mais en générer quatre est déjà chose plus ardue. Certains projets utilisent directement les GPIOs mais n'y faisant pas totalement confiance j'ai préféré acheter un circuit externe de gestion de servomoteurs, le Pololu Micro Maestro qui déchargera la framboise d'une lourde tâche. Le choix du maestro s'est fait grace à sa connectique USB, mais Adafruit propose d'excellent circuits i2c faisant la même chose.

Le code gérant le Pololu Maestro est situé dans la classe Motors du code du système de vol hébergé sur GitHub et utilise la libusb pour gérer la vitesse de chaque moteur comme prévu par les spécifications de Pololu.

Sources

Commentaires

Raspcopter - Régulateur PID (Proportionnel Intégral Dérivé)
par Florent Revest

Au cours de l'article précédent nous avons entamé l'étude du système de vol d'un quadcopter. La première étape consistait à récupérer l'attitude c'est-à-dire la position angulaire du drone dans l'air. Il s'agit aujourd'hui d'exploiter ces mesures d'angles dans la perspective de stabiliser le quadcopter autour de valeurs spécifiées par la station de contrôle au sol.

Ce que l'on veut

S'il est vrai que le drone doit savoir rester parallèle au sol lorsqu'aucune commande du sol n'est reçue, il se doit également de savoir pivoter sur ses axes pour pouvoir se déplacer. Ces rotations sont spécifiées par la "station de contrôle au sol", un logiciel tournant sur un ordinateur portable et traitant les données d'un joystick. La position du joystick traduit un angle voulu qui est ensuite transportée par wifi et interprété par le Raspberry Pi.

On souhaiterait avoir un vol fluide malgré les changements brutaux de position du joystick, tout en gardant un contrôle sur la réponse des moteurs plus ou moins aggressive.

Ce que l'on a

Lorsque le quadcopter confronte les trois angles d'euler mesurés par l'accéléromètre comme vu dans l'article précédent et les angles voulus envoyés par la station au sol la différence entre ces deux données produit une erreur soudaine. Si les vitesses des moteurs sont changées en même temps que l'apparition de l'erreur, comme selon le signal carré du graphique ci-dessous. L'impulsion puissante et soudaine risque: au mieux de dépasser l'angle souhaité et de revenir en arrière indéfiniment créant une instabilité, au pire de renverser immédiatement le quadcopter. On comprend donc bien qu'il est nécessaire d'avoir un algorithme "lissant" cette transition.

Comment passer de l'un à l'autre ?

Ce problème est omniprésent en ingénieurie et nécessite l'utilisation d'un "régulateur", nous allons évoquer et utiliser le régulateur PID (pour Proportionnel, Intégral, Dérivé).

Dans le cadre de notre quadcopter, les mesures se faisant sur trois angles il est nécessaire d'utiliser trois régulateurs PID différents. Cet algorithme prend pour entrée la différence entre l'angle voulu et l'angle mesuré, par exemple lorsque la télécommande au sol n'envoie rien cette erreur correspond au défaut de parallélisme au sol. Des opérations mathématiques sont appliquées à ces trois erreurs et déterminent les vitesses à envoyer aux quatre moteurs.

Le régulateur PID est un algorithme qui prend en entrée une erreur. Il fait la somme d'une multiplication de cette erreur, d'une intégrale de cette erreur et d'une dérivée de cette erreur, puis renvoie une nouvelle valeur. C'est tout.

On perçoit vite les avantages de cet algorithme: tout d'abord il est très simple à comprendre et à implémenter. Mais il faut également savoir qu'il est extrêmement fiable, ce régulateur est le plus utilisé au monde et on le retrouve partout... jusque dans la chasse de vos toilettes !

Ce système est dit "en boucle fermée" car il s'auto régule : lorsque l'erreur d'angle est grande les moteurs concernés accélèrent et l'erreur se réduit. La sortie de l'algorithme influe donc sur son entrée.

Proportionnel

Le terme proportionnel s'obtient très simplement par la multiplication de l'erreur par une constante nommée "gain proportionnel". Plus le gain est grand plus la vitesse de réponse est rapide et risque d'être instable. Plus le gain est faible plus la vitesse de réponse est "molle" et risque d'être inefficace. Il s'agit de trouver une bonne valeur intermédiaire entre ces deux extrêmes.

Ici on voit qu'un gain proportionnel (Kp) trop grand résulte en un dépassement significatif de l'angle recherché (le signal de référence bleu).

Intégral

Contrairement à un simple système de contrôle proportionnel, le régulateur PID tient compte de l'historique des erreurs angulaires. Pour cela le terme intégral est introduit, il représente la somme de toutes les erreurs accumulées dans le temps multiplié par une constante "gain intégral" Ki.

Le gain intégral influe directement sur la hauteur (et par conséquent le nombre) de dépassement de la valeur cible. Un trop faible gain est problématique dans certaines situations comme lorsque le vent est trop fort. En revanche un gain trop grand provoque une oscillation autour de l'angle voulu.

Dérivé

Le terme dérivé est parfois nommé "l'accélérateur" puisqu'il permet de compresser dans le temps la réponse. Il s'obtient par la soustraction de l'erreur actuelle et de l'erreur précédente multipliée par le gain dérivé. Ce terme est cependant à prendre avec des pincettes, car il est très sensible au bruit de données.

Une fois n'est pas coutume, un graphique nous permet de mieux comprendre l'impact du gain.

Et après ?

Une fois le code du régulateur PID implémenté (la très simple classe PID disponible sur le code github) il s'agit de déterminer les trois gains de chaque régulateur. Comme chaque quadcopter a des caractéristiques particulières il n'existe pas de constantes PID universelles, cependant la détermination de ces valeurs ne relève pas non plus du hasard.

Tout d'abord, il faut noter qu'une méthode de détermination rapide, nommée "méthode de Ziegler et Nichols" existe et permet d'obtenir des Ki et Kd corrects à partir de la seule valeur de Kp. Les gains peuvent ensuite être ajustés en fonction des paramètres vus ci-dessus.

Par ailleurs, un quadcopter (contrairement à un tricopter ou hexacopter) est à peu de choses près symétrique, les constantes des PIDs pitch et roll sont donc similaires ce qui fait gagner du temps.

Pour finir, il est important de noter que pour des raisons de sécurité évidentes l'expérimentation de ces PIDs ne se fait jamais en conditions réelles en exterieur. En accrochant solidement le quadcopter à une barre parallèle à un axe de rotation on est en mesure de bloquer la rotation des autres angles et de travailler sur un seul PID à la fois.

Sources

Commentaires

Raspcopter - Réception de l'attitude
par Florent Revest

J'inaugure aujourd'hui la lignée d'articles techniques sur mon projet de Raspcopter en commençant comme promis par : l'attitude.

Ce que l'on veut

Si cela peut sembler naïf c'est pourtant vrai: la première mission d'un quadcopter est de ne pas tomber... Même lorsque les quatre moteurs tournent à vitesse égale et constante, le drone fini par vriller et tomber seul. Cette rotation naturelle est causée par l'imperfection du drone (centre de gravité déplacé par exemple) mais aussi et surtout par les diverses contraintes physiques du milieu (typiquement : le vent).

Il est donc indispensable de créer un système de vol dépendant de l'attitude du quadcopter, c'est-à-dire de sa position angulaire dans l'espace. Une citation Wikipedia vaut mieux qu'un long discours "L'attitude ou l'orientation, dans le domaine de l'astronautique, est la direction des axes d'un engin spatial par rapport à un trièdre de référence. Pendant le déplacement du véhicule spatial, il s'agit de contrôler les mouvements d'avant en arrière (tangage), de gauche à droite (roulis) et autour d'un axe vertical (lacet)."

On a donc besoin de trois angles d'Euler que l'on nomme en anglais : yaw, pitch et roll.

Ce que l'on a

De nombreux capteurs permettent d'obtenir l'attitude du système :

  • Les accéléromètres, mesurant l'accélération linéaire sur trois axes.
  • Les gyroscopes, fournissant une position angulaire relative sur les mêmes axes.
  • Les magnétomètres, mesurant le champ magnétique et permettant de déduire la position du nord à la manière d'une boussole.
  • Les récepteurs GPS, dont les satellites fournissent des coordonnées absolues en latitude et longitude et permettent d'obtenir une rotation.

Tous ont leurs avantages et inconvénients. Ils ne sont donc jamais utilisés seuls, toujours combinés. De par des contraintes d'argent et de temps, mon projet de Raspcopter ne fera usage dans un premier temps que des deux premiers capteurs. Le MPU6050 de Invensense les réunit en une seule puce, on parle alors d'IMU (Unité de mesure inertielle) à six degrés de liberté. Le MPU6050 est par ailleurs très peu cher et souvent utilisé par des quadcopters.

Cette puce se connecte via la norme i2c par quatre fils (SDA, SCL, Masse et 3.3v) aux pins GPIOs dédiés du Raspberry Pi. Il est donc premièrement nécessaire de lever les drivers i2c de la blacklist Raspbian de modprobe.

L'utilisation de ce capteur est relativement bien documentée et rendue aisée par le travail de Jeff Rowberg sur I2CDevLib. Il est donc facile de récupérer des valeurs d'accélération et de rotation.

Comment passer de l'un à l'autre ?

Le coeur du problème se trouve dans le passage des valeurs brutes du MPU6050 à des angles habituels. En effet les valeurs brutes ont trois problèmes :

  • premièrement, elles comportent du bruit c'est-à-dire que le signal n'est pas stable
  • deuxièmement, elles n'ont pas d'unité, ce sont des valeurs qui ne correspondent à rien de concret
  • pour finir, ces données d'accélération et de rotation ne sont pas combinées en trois angles comme nous le souhaitons.

Un filtre de Kalman est souvent utilisé pour stabiliser les valeurs, mais son implémentation est extrêmement complexe et couteuse en temps processeur.

Une solution bien plus légère et rapide serait de créer un filtre complémentaire, selon la formule:

Appliqué sur des angles roll (phi) et pitch (rhô) calculés par

Cette formule accorde beaucoup plus de poids aux valeurs du gyroscope qu'à celles de l'accéléromètre car elle tiend en compte le fait que les mesures du gyroscope sont stables sur le court terme mais ont un "drift" (un décalage qui se produit avec le temps) sur le long terme (c'est-à-dire qu'en retournant deux fois d'affilé un gyroscope il ne reviendra pas à la même valeur) et que les valeurs de l'accéléromètre qui mesurent énormément de forces en plus de la gravité ont beaucoup de bruit mais sont bien plus stables sur le long terme. Cette formule n'est pas totalement efficace non plus.

Le choix d'un filtre IMU de quadcopter doit souvent se faire entre ces deux dernières techniques. Mais la bonne nouvelle c'est que le MPU6050 possède une puce "DMP" (Digital Motion Processing) qui permet de filtrer ces valeurs hors du Raspberry Pi, donc en temps réel et de manière bien plus efficace que par un algorithme implémenté à la main. La mauvaise nouvelle c'est qu'Invensense protège jalousement le fonctionnement de cette puce au nom du secret industriel et refuse de documenter son fonctionnement.

C'est ici qu'intervient Noah Zerkin, un entrepreneur en réalité augmenté qui a obtenu des dumps mémoires par retroingénierie de la puce en fonctionnement DMP à partir de démos du constructeur. C'est sur son excellent travail, intégré à I2CDevLib que se base mon code.

Mon implémentation est située dans la classe Accelerometer du code du serveur L'initialisation du MPU6050 se fait dans le constructeur et les angles d'Euler s'obtiennent par la méthode getYawPitchRoll().

Problème des angles d'Euler

Un dernier problème reste présent : si les angles d'Euler décrivent toutes les possibilités de positions angulaires, ils ne sont pas à l'abri pour autant d'un "blocage de cardan" ou Gimbal Lock. Ce problème arrive lorsque deux axes du gyroscope pointent dans la même direction, le système perd alors un degré de liberté et poursuit un mouvement imprédictible. Ce problème qui semble anodin aurait pu faire tourner court la mission Apollo 11, mais on n'en retiendra qu'une citation de Michael Collins "Que diriez-vous de m'envoyer un quatrième cardan pour Noël ?"

La solution, lorsque l'on ne croit pas au père Noël, serait d'utiliser des Quaternions, des nombres hypercomplexes fait d'une combinaison linéaire de quatre paramètres, dont trois définissent un axe et le dernier définit une rotation autour de cet axe. La manipulation de cet ensemble dépassant mes compétences de terminal S je me contenterai de les convertir en angles d'Euler.

Et après ?

La première phase du système de contrôle, l'acquisition de données, est donc achevée avec succès. Les angles d'Euler : yaw pitch et roll doivent maintenant passer par un contrôleur PID afin de sortir des vitesses de moteurs. Ce sera l'objet du prochain article.

Sources

Commentaires

Raspcopter - Construction du cadre
par Florent Revest

Après deux mois d'attente insoutenable, le collis des pièces du quadcopter commandées chez HobbyKing a fini par être livré. J'ai commencé à monter le cadre X525 v3 avec les moteurs Brushless FC 28-22 Outrunner 1200kv. Je flasherai peut être les ESC 20A UBEC HobbyKing avec le célèbre firmware SimonK avant de les souder aux moteurs (cependant la procédure s'annonce délicate donc incertaine). Toute cette phase de montage qui est commune à tous les quadcopters et déjà amplement documentée, je ne la détaillerai donc pas sur ce blog.

En revanche, mon travail de programmation et de documentation concernera la conception du système de contrôle de vol intégré au Raspberry Pi. À commencer par la réception de "l'attitude" (la rotation dans l'espcace) du quadcopter en angles d'euler filtrés puis le contrôleur PID et la régulation des vitesses via le Pololu Maestro.

En attendant, voici la première photo du montage :

La plaque de plastique à droite sera directement fixée au X525 et servira de support au Raspberry Pi, au MPU6050 (l'acceleromètre) et au Pololu Maestro (interface avec les ESCs).

Pour toutes informations supplémentaires n'hésitez pas à me contacter ou à commenter.

P.S: La liste complète du matériel est entretenue au côté du code sur github: https://github.com/FlorentRevest/Raspcopter

Commentaires