Accueil

Hardware:
Software:
Développement:
Gallerie:
Comme je l’ai déjà dit, un tel projet est complexe, et nécessite de la rigueur. J’ai mis en place plusieurs astuces ou méthodes qui m’ont simplifiée la vie.

1) simuler matériellement les moteurs :

Pour les tests de l'électronique et du programme, mieux vaut éviter de faire tourner les moteurs. Ca les use, et surtout, c'est potentiellement dangereux s'ils ne sont pas maitrisés. Des pales, ça tourne vite... J'ai déjà détruit 2 pales en faisant un test sans prendre de précaution. Alors j'utilise tout simplement des ampoules 8V (ou plutôt 2 ampoules 4V en série pour chaque moteur) pour simuler les moteurs! C'est très simple, et très pratique. On visualise directement la puissance, pas besoin d'instrument de mesure!

2) Une alimentation externe :

J'utilise une alimentation externe. C'est super pour éviter de dépenser des batteries. Les batteries, ça se recharge en 1h, et ça se décharge en moins de 10 minutes de vol... Donc pas facile à gérer.

Je n'utilise pas les alimentations de labo, qui coutent trop cher, et qui sont trop encombrantes pour de telles puissance, mais une alimentation qui ressemblent à une alim de PC portable, capable de délivrer 50W sous 7 ou 8V. Attention, le cordon d'origine est trop rigide, et ça déstabilisait le petit drone. J'ai donc ajouté un cordon silicone (donc souple) d'1m, de section suffisante (0.75mm^2).

Ensuite, il n'est en général pas recommandé d'alimenter avec ce genre d'alim à découpage des systèmes qui fonctionnent par impulsions et dépourvus de filtrage adapté, ce qui est le cas des contrôleur de moteurs de modélisme. Effectivement, j'ai pu tester, les oscillations sur l'alimentation sont énormes à pleine puissance. J'ai donc rajouté 2 gros condos de 4700µF adaptés à la tension (c'est plus facile d'avoir des hautes capacités pour des faibles tensions), et ça va beaucoup mieux.

3) Matlab – essais d’algorithmes :

Pour mettre au point la partie « observateur », j’ai beaucoup utilisé Matlab. Pour interfacer Matlab avec la liaison série de la radiocommande, j’utilise la toolbox "Psycho-Toolbox".

Je peux dialoguer avec le Drone depuis Matlab. Par contre, difficile de faire du "temps réel" avec ça. Les temps de réponse sont de l’ordre de 100ms.

Matlab m'a servi à tester rapidement les calculs mathématiques nécessaires à l'interprétation des capteurs. Ca permet de visualiser le résultat rapidement, de faire des calculs complexes (calcul matriciel) en quelques lignes de code, de manipuler des grands tableaux. Comme j'ai cherché à tout retrouver les équations, les calculs par moi même, cette étape de "test" était très importante: ça permet de corriger rapidement une erreur de signe, d'ajuster les paramètres quasiment en temps réel, de visualiser le résultat sur des courbes, et même en 3D.

Une fois que j'ai obtenu un résultat correct, j'ai "porté" les équations et paramètres dans le microcontroleur de mon robot, programmé en C#. En C#, on ne peux pas faire de calcul matriciel, donc il faut d'abord détailler les équations "formelles" pour décomposer en opérations mathématiques simples (addition, multiplications, sin, cos...). Il vaut donc mieux se rassurer d'abord avec Matlab avant de se lancer dans le C#.

Malheureusement, vu les temps de réponse des échanges de données entre le drone et Matlab, je n’ai pas pu développer d’asservissement dans Matlab pour les porter ensuite sur la carte mère du drone. Il faudrait des échanges beaucoup plus rapides (quelques dizaines de millisecondes).

4) Matlab – analyse :

J’utilise aussi Matlab pour afficher des résultats. Que ce soient des courbes, ou la représentation 2D ou 3D du drone, les vecteurs d’accélération, de champ magnétique. Matlab est un outil très pratique pour réaliser ce genre d’exercice.

5) Visualisation :

On l’a vu, une des difficultés est de ne pas pouvoir regarder simultanément le drone pour le piloter, et l’écran de PC pour voir les données en temps réel.
Pour résoudre ce problème, j’utilise CAMSTUDIO qui permet de faire des captures vidéo d’écran. Je filme le drone avec une webcam, et je mets à côté la fenêtre Matlab qui affiche les données. CAMSTUDIO enregistre les 2 fenêtres (Matlab et webcam).
C’est très pratique pour analyser après coup, calmement, comment s’est comporté le logiciel.

6) Logs en RAM :

L’envoi de données vers le PC en temps réel n’est effectuée que 5 fois par secondes. Dans tous les cas, je ne peux pas atteindre le débit nécessaire pour envoyer toutes les données à la fréquence de calcul (20 fois par seconde).
J’ai donc développé quelque chose de très simple, mais de très utile : pendant le vol, j’enregistre (20 fois par seconde) les paramètres intéressants dans la mémoire RAM embarquée du drone. Je peux sélectionner les paramètres à enregistrer en fonction de ce que je suis en train de développer.
La récupération des données se fait toujours par la liaison Bluetooth, mais « hors ligne », une fois le vol terminé. La récupération est encore une fois entièrement réalisée dans Matlab.
Visualiser ces informations actualisées très fréquemment est essentiel pour comprendre le comportement du logiciel embarqué.

7) Simulation 1D :

Vouloir régler un PID d’un engin volant en partant de zéro, et à tâtons, c’est complètement utopique. C’est impossible à mon avis. Donc il faut pré-régler l’asservissement. J’utilise pour cela 3 simulations simplifiées à 1 dimension
  • comportement en Z (altitude) en fonction de la commande des gaz
  • comportement en lacet en fonction de la commande de lacet
  • comportement en longitudinal (respectivement latéral) en fonction de la commande du pas cyclique de tangage (respectivement de roulis)
Pour faire coller l’asservissement à la réalité, je me base sur des logs où je réalise des échelons les plus francs possibles avec la commande que je dois simuler. La réponse à un échelon est en effet la méthode la plus simple pour faire de l’identification de paramètre.

Dans ces simulations, je peux introduire du bruit et du retard, pour tester la robustesse de l’asservissement.

Une fois la simulation suffisamment représentative (pas besoin d’être parfait), j’y injecte un PID, que je vais régler jusqu’à trouver quelque chose de correct. Ca sera le pré-réglage que je met alors sur le drone. Il faut alors régler à nouveau sur le drone.

8) Asservissements partiels :

Il est complètement illusoire de penser asservir et paramétrer en une seule fois les 4 commandes (gaz, cyclique-roulis, cyclique-tangage, lacet). Il faut impérativement décomposer. Il faut donc prévoir d’asservir 1, 2, 3, ou 4 de ces commandes. Le reste des commandes doit alors rester manuel. Personnellement, j’ai travaillé dans l’ordre suivant, qui me semblait logique :
  • asservissement lacet
  • asservissement gaz
  • asservissement cyclique (roulis et/ou tangage)

9) Modification des paramètres "en live":

Comme je l'ai déjà dit, le réglage des paramètres prend beaucoup de temps. Et il y en a beaucoup. Pour ne pas perdre de temps à compiler, télécharger et rebooter à chaque fois qu'on teste un jeu de paramètre, j'ai développé une fonction qui permet de modifier ces paramètres "en live" depuis le PC par la liaison bluetooth, sans nécessité de rebooter. J'envoie la commande, le nom du paramètre à modifier, et sa nouvelle valeur. Pour des raisons de sécurité, cette fonction n'est accessible que si le drone est posé au sol.
Leon | 28/08/2011
ze.bot_arob_free.fr