Carte électronique et asservissement du drone¶

Modification de la carte¶

Une des missions de ce projet à été d'actualiser la carte de l'année dernière et de faire un schéma électronique de la carte sous KiCad. Cette carte est le cerveau du drone, en effet c'est elle qui contient toute l’électronique du drone.

Portage sous KiCad¶

Lors du projet de l'année précédente, une modélisation électronique a été réalisée sur OrCad. Or nous voulions pouvoir diffuser les schémas librement. Le problème vient du fait que OrCad est un logiciel propriétaire et payant et donc on ne pouvait pas distribuer nos schémas librement. Nos tuteurs nous donc imposé le logiciel KiCad. Ce logiciel a les mêmes fonctionnalités que OrCad, c'est à dire la schématisation de circuits imprimés, et la modélisation en 2 dimensions et 3 dimensions, mais sans les désavantages. En effet KiCad est libre, gratuit et permet la distribution car il est sous licence GNU GPL, de plus il est mis à jour régulièrement.

Pour porter le schéma électronique sous KiCad, nous avons dû nous familiariser avec ce logiciel qui est destiné à un usage professionnel. Pour cela nous avons consulté quelques tutoriels. Ensuite nous avons créé les représentations des différents modules qui ne sont pas dans la bibliothèque originale de KiCad pour créer notre propre bibliothèque de composants.

Après recherches pour le microcontrôleur nous avons trouvé une bibliothèque de schématisation pour les composants Renesas sur le site internet de la forge des universités de Clermont-Ferrand (lien : https://forge.clermont-universite.fr/svn/p10ab04/trunk/carte_tel_receptrice/carte_receptrice/clock_oscillator_x014s/).
Une fois les composants réalisés séparément, nous avons réalisé la schématisation globale en associant les composants. Pour cela nous les avons disposés de manière à ce que la compréhension soit la plus aisée possible par rapport aux broches du microcontrôleur et pour que les connexions entre modules ne se croisent pas.

Le schéma électronique complet de la carte est fourni en annexe.

Actualisation de la carte¶

Une autre de nos missions était de mettre à jour la carte électronique et d'essayer d'optimiser son poids et sa consommation en énergie.

Pour réaliser notre nouvelle carte nous sommes donc partis de la version réalisée l'année d'avant qui était tout à fait fonctionnelle d'après les schémas réalisés. Nous l'avons donc reprise intégralement, à une modification près et non des moindres. En effet le module capable de gérer la position du drone n'était pas présent sur la carte. Ce module est une unité de mesure d'inertie (IMU) sur 6 axes, il est composé de trois gyromètres et trois accéléromètres. M. KAUFFMAN a donc commandé le module qui devait nous servir cette année. Or le modèle commandé disposait d'une connectique I²C. Le bus I²C est un bus créé par PHILIPS pour connecter simplement les composants à un microcontrôleur sur un port série.

Il nous a donc fallu revoir la liaison entre l'IMU et le microcontrôleur, pour cela il dispose de plusieurs ports prêts pour être directement utilisé avec un bus I²C. Nous avons donc choisi le port P7_0 qui est sur la broche numéro 30 du M32C pour la transmission de données et le port P7_1 qui est relié à la broche numéro 29 pour le signal d'horloge. De plus, l'IMU possède aussi trois broches pour les interruptions des gyromètres et des accéléromètres. Le microcontrôleur dispose de six broches pour utiliser les interruptions générées par les modules. Nous avons donc prévu de les relier au broches numéro 18, 19 et 20 du M32C qui sont respectivement les interruptions générées par INT2, INT1 et INT0. Pour finir, ce module dispose d'une alimentation électrique en courant continu sur 3,3 volts.

Les schémas ont été réalisés avec le nouvel IMU en revanche la carte n'a pas pu être fabriquée car le module attendu n'est arrivé que dans la dernière semaine de ce projet. L'optimisation n'a pas été effectuée, en effet les recherches pour optimiser le matériel auraient été trop longues. Nous avons préféré nous concentrer sur d'autres tâches plus importantes et indispensables au bon déroulement du projet.

Asservissements¶

Cette partie consiste à établir un code permettant de stabiliser le drone. Elle a été sous-divisée en trois autres axes de manière à décomposer le travail. Cette partie a pour but d'être intégrée au microcontrôleur et au simulateur. Elle constitue une partie centrale du projet permettant de simuler le comportement du drone dans un environnement virtuel, ainsi que la liaison entre un terminal Android, les moteurs et le sonar.

h3.Asservissement en altitude

Pour établir la première partie du code de stabilisation, nous avons dû travailler sur un tableur et simuler le comportement en z du drone en fonction de la force exercée. Pour simplifier cette première tâche, nous considérions que les quatre moteurs ne faisaient plus qu’un pour n’appliquer qu’une seule force. Les premières simulations grâce au tableur se portaient sur le décollage et la stabilisation.

Figure 5 : Décollage et asservissement du drone
Les données en y correspondent à l’altitude en mètre et les données en x correspondent au temps en millisecondes.

Dans cet exemple, notre but était de stabiliser le drone à une hauteur de un mètre. Nous avons pu réaliser ce schéma en prenant en compte un maximum de paramètres permettant une simulation la plus proche possible de la réalité :
• Masse du drone
• Consigne d'altitude (altitude visée) et altitude réel
• Différents coefficients (gain proportionnel, gain dérivée, alpha moteur)
• La force à appliquer à l'instant ∆t
• Accélération et vitesse à l'instant ∆t

En générant le code, nous avons voulu éviter une approche trop simpliste, consistant à effectuer une poussée maximum tant que la consigne d'altitude n'est pas atteinte, et à couper les gaz lorsque l'altitude est atteinte ou dépassée. Cette solution facile à réaliser aurait posé un réel problème. Nous aurions donc constaté un comportement difficile à maîtriser car il aurait effectué des oscillations. Nous aurions pu représenter ce comportement par la figure ci-dessous.

Figure 6 : Oscillation de l'altitude du drone avec une approche trop simpliste

Pour résoudre ce problème, nous avons mis en place un code utilisant des dérivées. Le calcul de la force à appliquer prend en compte, la différence entre la consigne d'altitude et l'altitude réelle, l'évolution de l'erreur, l'accélération ainsi que la vitesse à un moment ∆t. Cette nouvelle approche est représentée par la figure du décollage et de l’asservissement du drone (Figure 1).

La formule appliquée pour calculer la force à appliquer à un instant ∆t est celle-ci :

Force actuelle à appliquer = Force appliqué à l'instant t-1 * (Gain proportionnel * Différence entre la consigne d'altitude et l'altitude) + (Gain dérivé * Différence entre l'erreur d'altitude réel à t et l'erreur d'altitude à t-1)

Détail : On prend en considération la force appliquée précédemment et l'évolution de l'erreur d'altitude pour déterminer la force à appliquer.

Cette formule a pour but de diminuer la force appliquée au rapprochement de la consigne d’altitude et par conséquence, de limiter l'accélération. En limitant de plus en plus, l’accélération, on doit atteindre une erreur d’altitude (consigne d’altitude - altitude courante) à zéro en même temps que l’accélération deviendra nulle. Le drone s'élevant, va ralentir sa vitesse jusqu'à atteindre l'altitude visée. De cette manière, le drone va limiter sa montée en altitude au-dessus de l'altitude visée. Il n'aura plus qu'à appliquer une force plus ou moins constante (dans la théorie) pour compenser le poids (P = masse * 9,81) et le rendre immobile en altitude. La figure ci-dessous en est représentative.

Développement du code permettant d'utiliser le sonar¶

La mesure de l'altitude du drone a été confiée à un sonar. Un sonar est un capteur de distance. La distance est calculée par l’émission d'ultrasons, et en fonction du temps de réflexion sur un objet, on en déduit l’éloignement. Cependant, le capteur ne peut pas mesurer une distance supérieure à trois mètres, mais les distances mesurées sont très précises.

Pour incorporer ce matériel à la carte électronique, il a fallu développer le code associé. Ce code a été ajouté ensuite au code du microcontrôleur dans un handler cyclique (« fonction » en programmation temps réel), exécuté toutes les 20 millisecondes. Ainsi pour déclencher une mesure, il faut envoyer une impulsion de 10µs au sonar. Il faut donc configurer un temporisateur pour générer cette impulsion. De plus, puisque la mesure de distance fonctionne en fonction du temps, il nous a fallu utiliser un temporisateur capable de mesurer les largeurs d'impulsion. Nous avons donc paramétré le temporisateur TB0 en mode “mesure de largeur d'impulsion” (ou mode PWM).

Nous disposions également d’un second dispositif de calcul d’altitude permettant de prendre le relais au sonar lorsque le quadricoptère dépasserait une altitude de trois mètres. Il s’agit d’un capteur barométrique. Ce type de capteur fonctionne avec la pression atmosphérique, il n'est donc pas très précis car les variations de pression sont minimes sur une petite distance. Cela reste quand même suffisamment exploitable, car nous pouvons mesurer un changement d'environ 10 cm. Au-delà de trois mètres d’altitude, une variation de plus ou moins dix centimètres est négligeable pour l’utilisateur qui ne verra qu’une estimation. Le capteur a été mis en place sur la carte de l'année dernière. Sur les schémas réalisés cette année de la carte sous KiCad, l'implantation a été prévue sur le même port que sur la carte électronique précédente. En revanche en raison d'un manque de temps, le code pour que le microcontrôleur gère ce capteur n'a pas été implémenté.

Asservissement en x et y¶

La seconde partie concernant la stabilisation du drone consistait à rendre plus complet l'algorithme de manière à asservir en x et en y le drone. Cette partie a été facilement réalisable grâce à M. LAFFONT. Le code développé a été exclusivement intégré dans le moteur du simulateur pour deux raisons.

La première raison est qu'il nous était difficile de simuler le comportement du drone en x et en y dans un tableur. Pour cette raison, nous avons développé l'asservissement directement dans le simulateur car nous pouvions directement le tester.

La deuxième raison était par soucis de temps. En effet, cette partie a été développée dans les dernières semaines et nous savions que les algorithmes de stabilisation ne pourraient pas être compilés et chargés sur le microcontrôleur. Nous avons donc décidé de mettre la priorité sur cette partie pour pouvoir finaliser le simulateur. Nous avons pu dans les mêmes moments, associer les parties du simulateur, à savoir les modélisations 3D et le moteur physique (avec l'algorithme de stabilisation), le module Wi-Fi ainsi que l’application Android. Nous avons alors pu assister à un deuxième aboutissement dans le projet, à savoir que nous pouvions diriger le drone virtuel dans le simulateur grâce à un terminal Android, via une connexion sans fil.