98 réponses à ce sujet

[Leon]

BOB4, les astuces, bidouilles et autres:

Aujourd'hui, pour vous divertir, je souhaite vous parler des petites astuces qui me sont très utiles sur BOB4.

1) 1 seule liaison radio. Dans quasiment tous les drones que j'ai pu voir sur le web, on utilise plusieurs liaisons radios: 1 liaison "radiocommande" classique (en PCM ou PPM) pour envoyer les ordres manuels, 1 liaison bluetooth ou ZigBee pour les données, et une liaison vidéo pour la vidéo (bien sur). Pour faire un drone aussi petit et aussi léger que le mien, il faut faire simple: j'ai choisi d'utiliser 1 seule liaison radio pour toutes les utilisations: contrôle manuel (par la radiocommande), programmation (je n'arrive pas encore à programmer à distance, mais j'y travaille), envoi d'ordres et de paramètres au drone, retour d'information du drone vers l'écran de la radiocommande ou vers le PC. Ca a nécessité de refaire toute l'électronique de la radiocommande, mais je ne regrète pas mon choix.

2) La sécurité. Les modules bluetooth que j'utilise sont capable, en plus de la liaison série, de gérer des "lignes de contrôle" normalement attribuées au port série (RI, DTR, DCD, DSR). J'ai détourné l'utilisation de ces connexions pour plusieurs choses, et surtout pour la réalisation de la 'protection'. 1 ligne est dédiée à l'activation de la puissance des moteurs et des servos. J'ai 1 switch sur la radiocommande qui est directement relié à une des lignes de contrôle. Ca permet d'activer/désactiver la puissance, en hardware, grâce à un 74HCT08, quel que soit l'état de la carte mère. En cas de perte de liaison radio, cette ligne tombe automatiquement côté récepteur, ce qui met automatiquement le drone en sécurité. J'utilise une autre ligne de contrôle pour sélectionner le mode d'utilisation de la liaison série (grâce à un multiplexeur numérique 74HC157): programmation/débuggage, ou utilisation 'normale' de dialogue avec la carte mère.

3) 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²).
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.
http://www.electronique-diffusion.fr/product_info.php?products_id=878


4) Des ampoules pour les tests: 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!


5) protections anti méli-mélo. J'ai placé des fils de nylons en bout des patins d'atterrissages, recourbés. Pourquoi? Parce que sans cet artifice, BOB4 pouvait se prendre les pieds dans les cordons, et là, c'est l'accident quasi assuré à cause du croche patte. Voir photo ci dessus.

6) Désactivation du filtre passe haut des gyros: Sparkfun a fait une grosse connerie sur tous quasiment tous ses gyros ou centrales inertielles analogiques. Ils ont placé un filtre hardware passe haut qui est normalement "optionnel", et qui empêche d'intégrer (interpréter) convenablement les vitesses de rotation. Avec un filtre passe haut, les angles déduits sont forcément faux! Malgré les plaintes là dessus sur les forums, Sparkfun persiste a persisté dans l'erreur sur ses nouveaux produits. Ils promettent de corriger ça. La solution, c'est de désactiver ce filtre hardware. Contrairement à ce qui est indiqué sur les forums Sparkfun, pas besoin de désouder de composant, ce qui est TRES difficile avec cette taille de composants. J'ai simplement cour-circuité les 3 condos des 3 filtres passe haut. Et ça marche. Le résultat est bien meilleur avec cette bidouille. Attention, l'opération est assez délicate, car c'est tout petit.


7) fixation de l'électronique par élastiques: Les 2 platines électroniques sont fixées de manières souples sur le train d'atterrissage, grâce à des élastiques. C'est pratique et utile. C'est léger, plus léger que des vis, c'est souple, et donc ça permet d'encaisser les chocs plus facimenement. Les atterrissages forcés sont (et seront) nombreux. En plus, ça permet de filtrer (un peu) les oscillations pour la centrale inertielle.

C'est tout pour aujourd'hui, la suite au prochain numéro!

Leon.

[Jan]

Merci Leon pour ces astuces qui seront utiles à ceux qui voudont bien te suivre dans cette aventure

[Dr.Calvin]

Magnifique, merci vous deux (BOB4 et toi ) et bravo !

[Leon]

Un petit état d'avancement des travaux de ces dernières semaines.

Ca avance très doucement, pas à la vitesse où je souhaiterai, mais au moins, ça avance.

Interprétation des gyros:
J'ai continué de mettre au point sous Matlab l'interprétation des 3 gyro. J'ai obtenu quelque chose de bien. J'ai porté les équations et paramètres obtenus directement sur le processeur du drone. Et à ma grande surprise, ça a fonctionné du premier coup! La puissance de calcul est là sur le drone (ARM7 70Mhz), et j'arrive sans problème à faire plus de 50 mesures/calculs par seconde. En vol, les capteurs se prennent vraiment beaucoup de vibrations, c'est assez gênant. J'ai bidouillé 2 ou 3 trucs très utiles pour la centrale inertielle: détection "drone posé au sol" (tous accéléros et gyro neutres) qui permet de connaitre précisément l'offset (erreur continue) des capteurs; quand les consignes de roulis ou de tangage sont neutres en vol, on fait tendre l'angle correspondant vers zéro. Ca permet de compenser les erreurs d'angle "long terme". Je considère tout ça au point, je pourrais difficilement faire mieux.

Les compas:
Là, c'est tout de suite moins glorieux. J'avais initialement choisi un compas 2D (HMC6352). Dès qu'on le penche de 10°, l'erreur sur l'angle est énorme.
J'ai donc investi dans un tri-capteur magnétique HMC5843 (comme un compas 3D, mais sans l'intelligence). J'ai eu énormément de problèmes avec. Tout d'abord, comme dit dans un autre post, j'ai du bidouiller la platine pour rajouter des condos pour pouvoir le faire fonctionner. Après ça, j'ai fait pas mal de tests, et je l'ai grillé! Si, si! Je ne pensais pas que c'était possible de griller un capteur avec quelques lignes de code.
J'explique: le capteur est équipé d'un mode TEST qui permet d'injecter un champ magnétique (généré par un courant) sur les 3 capteurs en même temps. Ce mode est utile pour détecter l'erreur de linéarité du capteur. Erreur de linéarité qui m'aparaissait non négligeable et que je voulais tester. Or, pour faire les mesures, je suis aussi obligé de régler le capteur dans une gamme de champ magnétique élevé (= gain faible), car le champ généré par la présence des moteurs est ~3 fois le champ magnétique terrestre! Il est bien précisé dans la notice que dans ces conditions (utilisation d'une plage large de champ) il ne faut pas rester longtemps en mode "TEST", car le courant de test est élevé, et ça fait chauffer les capteurs... ça les crame, oui! J'ai malheureusement un bug dans le logiciel qui m'a fait planter la communication juste au moment du test (loi de Murphy oblige), et le test s'est donc prolongé de nombreuses secondes, le temps que je m'en rende compte et que je coupe l'alimentation. Bilan? Le capteur est HS, il raconte toujours la même chose sur les 3 directions.
En parallèle de ça, comme si tout ces problèmes n'étaient pas suffisants, j'ai constaté que le champ magnétique varie avec la puissance des moteurs...

Le drone en lui même:
Je suis pour l'instant satisfait de cette "base de développement". C'est fiable, pratique, petit, ça vole assez bien malgré le sur-poids. C'est facile à utiliser. Pour l'instant, le hardware semble fiable: je n'ai eu AUCUN plantage du au hardware. Le fait d'échanger en direct des données avec Matlab est très très pratique pour débugger.
Après, j'avais prévu de pouvoir télécharger le programme du drone par la liaison Bluetooth. Mais ça ne fonctionne pas. Pourquoi? Parce que ces messieurs de Microsoft (la carte est sous "Microsoft .NET Micro Framework) n'ont pas prévu de pouvoir paramétrer la liaison série qui sert à la programmation, et n'ont pas prévu de contrôle de flux hardware dans la configuration "par défaut". Il est impossible de faire passer autant de données par une liaison bluetooth sans contrôle de flux hardware à 115kb/s! C'est pour l'instant mon plus gros regrêt.

La suite? Mettre un nouveau compas, interpréter les accéléro (ça va être chiant), les sonars, pour en déduire la position 3D du drone dans l'espace.

Bref, c'est un projet qui avance tout doucement... Mais au moins, ça avance, c'est l'essentiel. Il y a énormément de boulot qui m'attend avant d'espérer atteindre un résultat correct. La suite au prochain numéro.

Leon.

[Dr.Calvin]

Merci de ces détails "en temps réel", ton projet est tout simplement génial. Bravo, c'est impressionnant. J'espère créer des choses de la même trempe un jour. Tes posts sont très instructifs !

Peux-tu en dire plus sur les gyros ? Comment les as-tu interprétés en Matlab ? Je connais un peu ce langage (il est au programme de prépa), mais je n'ai pas encore eu l'occasion de le confronter à la programmation d'un robot.

Vivement le prochain numéro !

[Leon]

Je ne sais pas ce que tu cherches à savoir exactement.

Je ne programme pas le robot sous Matlab. Matlab m'a "seulement" servi à tester rapidement les calculs mathématiques nécessaires à l'interprétation des gyro. 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#, tu 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#.

Désormais, Matlab me sert uniquement d'interface graphique, pour afficher des courbes, une image 3D.

Après, si ta question était de savoir comment on interprète les données de gyro pour en déduire les "angles d'euler", la réponse est un peu plus complexe. En très gros, il faut intégrer (intégrale mathématique) les vitesses angulaires de chacun des axes, pour en déduire les angles. Mais il faut pondérer ça par des sinus, des cosinus des autres angles. Personnellement, j'utilise des équations simplifiées, approximées, qui ne permettent pas d'obtenir des angles exacts. Mais cette approximation est amplement suffisante dans les conditions de vol de mon drone: les angles de "roulis" et de "tangage" restent toujours faibles, ne dépassant jamais +/-40°.

Leon.

[Dr.Calvin]

Excuse-moi si je n'ai pas été claire, tu as tout-à-fait répondu à ma question qui comprenait ces deux aspects. Je m'étonnais que tu aies utilisé Matlab pour programmer le robot, et ta réponse à ce sujet ajoutée aux détails de tes posts précédents m'ont fait mieux comprendre l'utilité de Matlab.

Pour ce qui est des gyros, je te demandais effectivement le principe, tu me l'as donné en gros et je vais me renseigner par ailleurs, car je me doute bien que c'est assez coton (peut-être vais-je même l'apprendre via mon cursus...)

[Leon]

Quelques news.

Tout d'abod, l'astuce du jour: pour voir comment se comportait l'estimation d'angle en vol, j'ai tout d'abord essayé de piloter l'engin tout en regardant l'écran du PC... très scabreux comme exercice, j'en ai conclu que c'était impossible (ou alors que je n'étais pas doué, ce qui revient au même). Le cerveau est tiraillé entre piloter un truc virtuel qu'on voit sur l'écran et piloter le drone réel. Bref, c'est le crach quasi assuré!
Comment faire? Et bien regardez la vidéo ci dessous: je filme mon drone avec une webcam, et je capture avec CAMSTUDIO les 2 vues: la vue de la webcam et la vue Matlab. Comme ça, je n'ai pas besoin de regarder l'écran du PC quand je pilote le drone; je peux rejouer calmement le truc, voir comment ça s'est comporté.

http://heli.bot.free.fr/demo_screencapture.avi
(aussi sur Dailymotion pour Néo et les autres, mais la qualité est vraiment merdique: )

J'avais pensé à plus compliqué: développer un truc sous matlab pour y récupérer le flux vidéo et le flux de données. J'aurais ainsi pu faire du post-traitement sans problème en rejouant la scène avec la vidéo. Ca serait génial, mais trop long à développer!
Un autre amateur avait développé un truc intéressant pour son drone à lui, qui revient à peu près au même: utiliser le canal son d'un magnétoscope pour y enregistrer les données séries envoyées par le drone en plus de l'image, et pouvoir rejouer vidéo + données calmement sur son PC.
http://serge.laforest.free.fr/drone/drone.htm

Ensuite, l'état d'avancement:
Ca progresse toujours lentement, mais j'ai le temps... J'ai ajouté un carrénage à base d'une bouteille de coca découpée. Je ne sais pas si je garderai ça, l'objectif étant d'améliorer l'écoulement de l'air. J'ai ajouté des fusibles réarmables (polyswitch) sur les moteurs, c'est une sécurité indispensable: si les moteurs se bloquent (suite à un crash, pales contre terre) et que je n'arrive plus à couper la puissance, ça peut sauver le drone, l'éviter de bruler!

Ensuite, j'ai testé et retesté les gyro en vol, et contrairement à ce que je disais plus haut, je ne me suis pas contenté du résultat obtenu initialement (post du 25 juillet): ça oscille beaucoup, ça dérive. Oui, j'en suis encore à l'interprétation des gyro, alors qu'il me reste aussi à traiter les accéléro, les capteurs magnétiques, les sonars... bref, ça risque d'être long.

En fait, en vol, il y a beaucoup de vibrations, les mesures sont très bruitées. J'ai donc du filtrer un maximum dans le logiciel. Comment faire? Tout d'abord, il faut multiplier la fréquence des mesures. J'arrive à faire 120 mesures accéléro et gyro par seconde (6 données à mesurer à chaque fois) comtre 50 initialement et 60 mesures de capteur magnétique par seconde. Pas mal, non? Je filtre toutes ces mesures avec des filtre passe bas (1° ordre) de temps de réponse ~100ms. C'est le filtre numérique le plus simple possible. Une fois filtrées, les informations sont beaucoup plus exploitables, moins bruitées, et conservent une dynamique suffisante pour suivre les mouvements du drone.

Mais la puissance de calcul est insuffisante pour traiter 120 fois par seconde tous les calculs de trigo (et compagnie) nécessaire à la détermination des angles. Alors je ne fait ces calculs gourmands que 20 fois par seconde à partir des infos filtrées, ce qui est bien suffisant.
Avec ces modifs, le résultat en vol est désormais satisfaisant, la preuve sur la vidéo.

Je dois désormais m'attaquer (à nouveau) à la boussole 3D, ce qui n'est pas non plus une mince affaire.

Leon.

[Inounx]

Salut Léon,

Quelques news.

Tout d'abod, l'astuce du jour: pour voir comment se comportait l'estimation d'angle en vol, j'ai tout d'abord essayé de piloter l'engin tout en regardant l'écran du PC... très scabreux comme exercice, j'en ai conclu que c'était impossible (ou alors que je n'étais pas doué, ce qui revient au même). Le cerveau est tiraillé entre piloter un truc virtuel qu'on voit sur l'écran et piloter le drone réel. Bref, c'est le crach quasi assuré!
Comment faire? Et bien regardez la vidéo ci dessous: je filme mon drone avec une webcam, et je capture avec CAMSTUDIO les 2 vues: la vue de la webcam et la vue Matlab. Comme ça, je n'ai pas besoin de regarder l'écran du PC quand je pilote le drone; je peux rejouer calmement le truc, voir comment ça s'est comporté.

http://heli.bot.free.fr/demo_screencapture.avi
(aussi sur Dailymotion pour Néo et les autres, mais la qualité est vraiment merdique: )

pas mal ta technique ! effectivement ça a l'air bien pratique, et puis comme tu le dit ça te laisse le temps après d'étudier minutieusement la vidéo pour faire du débug. Tu utilises toujours ta toolbox Matlab qui recupère des données par le port série ? comme tu m'avais dit que c'était plutôt lent, et que le temps de réaction dans la vidéo a l'air tout a fait correct je me demandais si c'était le même outil.
D'ailleurs BOB4 a l'air assez péchu ^^ même avec son packetage ont voit qu'il reste réactif !

Ensuite, j'ai testé et retesté les gyro en vol, et contrairement à ce que je disais plus haut, je ne me suis pas contenté du résultat obtenu initialement (post du 25 juillet): ça oscille beaucoup, ça dérive. Oui, j'en suis encore à l'interprétation des gyro, alors qu'il me reste aussi à traiter les accéléro, les capteurs magnétiques, les sonars... bref, ça risque d'être long.

En fait, en vol, il y a beaucoup de vibrations, les mesures sont très bruitées. J'ai donc du filtrer un maximum dans le logiciel. Comment faire? Tout d'abord, il faut multiplier la fréquence des mesures. J'arrive à faire 120 mesures accéléro et gyro par seconde (6 données à mesurer à chaque fois) comtre 50 initialement et 60 mesures de capteur magnétique par seconde. Pas mal, non? Je filtre toutes ces mesures avec des filtre passe bas (1° ordre) de temps de réponse ~100ms. C'est le filtre numérique le plus simple possible. Une fois filtrées, les informations sont beaucoup plus exploitables, moins bruitées, et conservent une dynamique suffisante pour suivre les mouvements du drone.

Mais la puissance de calcul est insuffisante pour traiter 120 fois par seconde tous les calculs de trigo (et compagnie) nécessaire à la détermination des angles. Alors je ne fait ces calculs gourmands que 20 fois par seconde à partir des infos filtrées, ce qui est bien suffisant.
Avec ces modifs, le résultat en vol est désormais satisfaisant, la preuve sur la vidéo.

Je dois désormais m'attaquer (à nouveau) à la boussole 3D, ce qui n'est pas non plus une mince affaire.

Toutes les mesures que tu effectues (120x par seconde pour les gyro et accelero, 60x par seconde pour magneto, etc...) sont effectuées par la même carte, ta carte embedded master module ? ou par les modules capteurs directement ?
A l'occasion si tu as un moment je serais intéressé par un retour d'expérience sur cette carte embarquant un .NET micro framework. J'avoue que je suis assez sceptique sur le C# pour réaliser de telles applications, mais n'ayant jamais eu l'occasion de tester...
Tu penses que cette carte suffira pour piloter ton drone entièrement, et ce de manière autonome ?

Je crois que c'est tout pour les questions ^^, en tout cas bonne continuation et merci pour tout ces détails qui pourront être utiles à plus d'un je pense.

[Leon]

Salut Inounx,

pas mal ta technique ! effectivement ça a l'air bien pratique, et puis comme tu le dit ça te laisse le temps après d'étudier minutieusement la vidéo pour faire du débug. Tu utilises toujours ta toolbox Matlab qui recupère des données par le port série ? comme tu m'avais dit que c'était plutôt lent, et que le temps de réaction dans la vidéo a l'air tout a fait correct je me demandais si c'était le même outil.

Oui, j'utilise toujours la toolbox "psychtoolbox". Les temps de réponse sont suffisants faire de la visualisation comme je le fait. J'ai (je pense) des temps de retard de plusieurs centaines de ms. Donc ça n'est pas du tout "temps réel". Je ne pourrais pas développer un asservissement dans Matlab dans ces conditions. Si je voulais vraiment avoir un truc "temps réel" avec lequel je puisse faire tourner l'asservissement sur le PC, il faudrait des temps de réponse bien plus faibles, de l'ordre de quelques ms.

Toutes les mesures que tu effectues (120x par seconde pour les gyro et accelero, 60x par seconde pour magneto, etc...) sont effectuées par la même carte, ta carte embedded master module ? ou par les modules capteurs directement ?

Oui, les 120 mesures par seconde sont réalisées par cette carte Embedded Master.

A l'occasion si tu as un moment je serais intéressé par un retour d'expérience sur cette carte embarquant un .NET micro framework. J'avoue que je suis assez sceptique sur le C# pour réaliser de telles applications, mais n'ayant jamais eu l'occasion de tester...
Tu penses que cette carte suffira pour piloter ton drone entièrement, et ce de manière autonome ?

C'est le ".NET Micro Framework" qui est assez peu adapté à ce genre d'application "temps réel" (plus que le C#). C'est un peu "masochiste" de ma part d'avoir choisi ça, mais j'assume! Pourquoi ce choix? Plusieurs raisons: parce que j'avais envie de découvrir ce "framework", et que c'est tombé sur cette application. Et puis j'imagine aussi un jour développer une couche "haut niveau" pour le(s) drone(s), peut-être interfacer un modem GPRS, échanger des données en HTTP avec un serveur... si j'en fait un drone d'extérieur. Je ne le ferais peut-être jamais, je ne sais pas...

Est-ce que la puissance de calcul sera suffisante? Oui, certainement. D'expérience, en automatique, la partie "observateur" (estimation de la position et orientation) est la partie la plus gourmande en ressource. On peut donc dire que je teste en ce moment même la plus grosse partie de la puissance demandée. L'asservissement pur, la loi de commande (PID) ça demande moins de ressource. J'ai un peu plus peur sur l'aspect "précision des timings": pour calculer une dérivée temporelle par exemple, dans le PID, il faut être assez précis.

Les premières constatations sont assez contrastées sur ce ".NET Micro Framework".
Tout d'abord, avoir un vrai environnement de développement, c'est très appréciable. C'est facile à prendre en main. On a un débugger intégré, on est assez guidé, l'interface "visual C#" est bien faite... Note que je n'ai pas beaucoup d'expérience en programmation, alors j'apprécie facilement.

Dans le moins bien, il y a tout d'abord le temps d'accès aux périphériques: c'est lent! 1ms pour faire une lecture I2C de quelques octets, c'est beaucoup. Ensuite, il y a des limitations inexplicables. Comme dit plus haut, on ne peut pas régler les paramètres de la liaison série servant au débug. Donc je ne peux pas faire passer cette liaison de débug par bluetooth! Je suis obligé de brancher/débrancher BOB4 à chaque reprogrammation. De base, les calculs mathématique (trigo) sont arrondis! C'est idiot! "Pour être plus rapide" dit Microsoft. J'ai du récupérer une vraie librairie de calcul mathématique, vu mon application.
Et puis on a vraiment l'impression que ça a été développé pour des informaticiens, et par des informaticiens, sans prendre en compte les contraintes de l'électronique. Comme dit plus haut, ne pas pouvoir dialoguer en même temps avec 2 périphériques I2C, c'est une idiotie. Dans le même ordre d'idée, on n'a pas accès à tous les paramétrages nécessaire de tous les périphériques. J'ai du par exemple bidouiller dans les registres du microcontroleur pour faire ce que je voulais avec le module PWM.

Leon.

[Leon]

J'ai donc bossé ce week-end (pluvieux) sur l'interprétation des données du capteur magnétique 3D. Pas facile...
Voici mes remarques sur le sujet:

1) Le champ magnetique généré par les moteurs est vraiment gênant. En fait, j'ai mis des moteurs plus puissants que ceux d'origine, et le champ magnétiaue généré est tout simplement énorme. Mais le plus gênant, c'est que ce champ magnétique varie avec la puissance des moteurs. La variation est relativement faible en soi, mais ça provoque des variations d'angle de ~20°. Si je mettais des moteurs brushless, je serais sans doute moins embêté, mais c'est assez contraire avec mon esprit de simplicité. Pourquoi des brushless seraient moins gênants? Le champs magnétique généré par un moteur courant continu, dont l'aimant permanant est fixe, est toujours dans la même direction. Au contraire, pour le brushless, ce champ tourne. Donc en moyenne, le champ généré par un brushless devrait être moins important. Mais ce n'est qu'une supposition, je n'ai pas testé.

2) Comment interpréter des données du compas 3D? En fait, il est impératif de connaitre au préalable l'inclinaison de l'engin dans les 2 sens (roulis et tangage). L'idée est de "remettre droit" le vecteur champ magnétique mesuré, en appliquant au vecteur "champ magnétique" les 2 rotations nécessaires: rotation roulis et rotation tangage. Il faut donc avoir des informations "angle roulis" et "angle tangage" fiables, ce qui est mon cas. Ces 2 informations sont déterminées à partir des gyroscopes. Une fois ce vecteur remis "à plat", on garde uniquement la projection sur le plan horizontal, et on en déduit l'orientation 2D du champ magnétique. Ca fonctionne infiniment mieux que le compas 2D! C'est maintenant robuste à une inclinaison dans les 2 sens.

3) Attention: il se vend (à prix d'or) des compas 3D soit disant compensés en inclinaison. 2 exemples: HMC6343 (160€) et OceanServer(250€). Ces capteurs utilisent des accéléromètres 2D pour déduire l'inclinaison. Or, ces accéléromètres ne peuvent déterminer l'inclinaison réelle que si l'objet est STATIQUE, immobile! Ca n'est ABSOLUMENT PAS ADAPTE à un engin volant, ni à un véhicule 4x4 par exemple. Je pense que Psykokwak confirmera, suite à l'utilisation qu'il en a fait sur son Arobot V3. Impossible d'obtenir une information fiable en dynamique. Un engin volant ne peut se baser que sur ses capteurs gyroscopiques pour déterminer ses inclinaisons.
Alors à quoi servent ces compas 3D? Pour les systèmes de visée utilisés en statique, notamment: jumelles, lunettes; ou alors pour les bateaux qui n'ont pas d'accélérations trop bruptales.

La suite? Maintenant que le travail sur les angles est bien avancé, je vais travailler sur la position 3D de l'engin, en interprétant les données des 3 accéléromètres et des 4 sonars. Je sais déjà que ça ne sera pas simple, car les accéléros sont assez bruités.

Leon.

[Leon]

Bonjour à tous!

Ca progresse doucement... Je travaille actuellement sur une estimation de la position 3D du drone à l'aide des accéléros et des sonars. Voici un premier résultat, largement perfectible, il y a encore pas mal d'abérations, et il arrive fréquemment que l'estimation dérive. C'est loin d'être parfait, mais j'y travaille!
La Vidéo!

En fait, ce projet va beaucoup plus loin que je ne le pensais. C'est vraiment complexe, intéressant, passionnant! Confronter des trucs théoriques à la réalité, je trouve ça assez magique! Je viens de rentrer dans une phase assez prenante de mon projet, où il faut penser le code, se mettre dans la peau des calculs. Et puis il y a une quantité impressionnante de paramètres à ajuster, c'est vraiment complexe. Je n'ai pas compté, mais il doit déjà y avoir une cinquantaine de paramètres! Ca nécessite de tester, ajuster, re-tester, re-ajuster, etc... Je pense que ce projet va me rendre fou... si ça n'est pas déjà fait.

Revenons à l'estimation de position. Comment ça marche? Il faut tout d'abord remettre les accélération 3D des 3 accéléro dans le repère absolu. 3 transformations 3D à faire avec 3 matrices de rotation. Mais avant ça, il faut des accélérations dont l'offset (erreur constante) est bien corrigée. C'est primordial, et vraiment pas facile à faire. La correction elle même doit se faire en prenant en compte la gravité, l'orientation du robot en roulis et tangage.

Après, on soustrait la gravité à l'accélération dans le repère absolu, et on intègre (intégrale mathématique) pour obtenir les vecteurs vitesse. Encore une fois, la vitesse doit être corrigée, car elle peut dériver très rapidement. Je la recale avec les mesures des sonars, si elle sont disponibles, et si elles ne sont pas dispo (drone mal orienté pour la mesure), j'applique un filtre passe haut. Enfin, on intègre ça pour obtenir des positions 3D.

Mais les sonars dans tout ça? Eh bien à chaque fois qu'on a une mesure sonar crédible, on s'en sert pour recaler vitesse et position dans la direction de la mesure. Déjà, on ne recale pas de 100%, mais de ~30% de l'erreur constatée, pour être robuste aux petites erreurs. Avec 30%, ça converge bien rapidement, sans introduire trop de bruit. Si on corrigait de 100%, ça créerait trop d'oscillations, de bruit.
Qu'est-ce qu'une mesure crédible? Une mesure qui est faite avec un mur (ou plancher) à peu près perpendiculaire (tolérance de 17° dans les 2 directions par rapport à ce plan), pas trop faible ni trop élevée (=impossible), cohérente avec l'estimation de position actuelle.

Pour résumer, tout se passe comme si j'utilisais les accéléro pour renseigner la partie "haute fréquence" des déplacements, et les sonars pour les basses fréquences. Les sonars permettent une estimation de position précise, mais peu souvent actualisée, surtout quand on doit "rejeter" de nombreuses mesures inexploitables (orientation pas bonne, objet devant le sonar). A l'opposé, les accéléros permettent une bonne estimation du mouvement sur de courtes durées (2 secondes maxi), mais ça n'est pas du tout précis sur le long terme. Il faut donc "fusionner" plusieurs sources d'informations de qualité différentes.

Par contre, j'ai encore énormément de problèmes avec le capteur magnétique, il est trop perturbé. Il faut impérativement que je trouve une solution.

La suite au prochain numéro...

Leon.

[galactus]

tout ça est très prometteur

félicitations

[Inounx]

Salut Léon,

ça avance toujours bien à ce que je vois. C'est un gros morceau la reconstitution de la position 3D de ton bestiau par rapport à toutes tes mesures capteurs mais je vois que tu t'accroches ^^
Tu pourrais indiquer une estimation du temps que tu passes sur ton projet si ça te dérange pas ? c'est que quand on arrive sur un forum on voit beaucoup de projets, et souvent on ne regarde que le résultat et on se dit "ah ben tient c'est cool ça j'aimerais bien faire pareil" mais sans trop se rendre compte de tout le boulot qu'il y a à fournir derrière.

Mais les sonars dans tout ça? Eh bien à chaque fois qu'on a une mesure sonar crédible, on s'en sert pour recaler vitesse et position dans la direction de la mesure. Déjà, on ne recale pas de 100%, mais de ~30% de l'erreur constatée, pour être robuste aux petites erreurs. Avec 30%, ça converge bien rapidement, sans introduire trop de bruit. Si on corrigait de 100%, ça créerait trop d'oscillations, de bruit.
Qu'est-ce qu'une mesure crédible? Une mesure qui est faite avec un mur (ou plancher) à peu près perpendiculaire (tolérance de 17° dans les 2 directions par rapport à ce plan), pas trop faible ni trop élevée (=impossible), cohérente avec l'estimation de position actuelle.

Pour résumer, tout se passe comme si j'utilisais les accéléro pour renseigner la partie "haute fréquence" des déplacements, et les sonars pour les basses fréquences. Les sonars permettent une estimation de position précise, mais peu souvent actualisée, surtout quand on doit "rejeter" de nombreuses mesures inexploitables (orientation pas bonne, objet devant le sonar). A l'opposé, les accéléros permettent une bonne estimation du mouvement sur de courtes durées (2 secondes maxi), mais ça n'est pas du tout précis sur le long terme. Il faut donc "fusionner" plusieurs sources d'informations de qualité différentes.

Par rapport à la localisation avec tes capteurs US, tu dit que tu les utilise pour corriger la position et la vitesse : j'imagine que ton drone n'a pas pas de carte de ton logement avec les dimensions précises, donc je suppose que tu déduis la vitesse avec deux mesures US et l'heure de chaque mesure et que tu intègre ensuite pour la position. La tolérance de 17° tu l'applique par rapport à l'orientation de ton hélico calculée avec tes gyros ?

C'est marrant pour les auto pilots d'avion ou autres drones d'extérieur c'est le même principe que celui que tu utilises, à la seule différence que c'est un GPS qui permet de recalculer la position "basse fréquence".

Par contre, j'ai encore énormément de problèmes avec le capteur magnétique, il est trop perturbé. Il faut impérativement que je trouve une solution.

J'imagine que c'est le moteur brushless qui pourrit les mesures ? Surtout que vu la proximité de l'ensemble ça va pas être évident...

[Leon]

Tu pourrais indiquer une estimation du temps que tu passes sur ton projet si ça te dérange pas ? c'est que quand on arrive sur un forum on voit beaucoup de projets, et souvent on ne regarde que le résultat et on se dit "ah ben tient c'est cool ça j'aimerais bien faire pareil" mais sans trop se rendre compte de tout le boulot qu'il y a à fournir derrière.

J'essaye de ne pas compter! C'est une passion, et quand on aime, on ne compte pas. Difficile à estimer, mais environ 4h en moyenne par semaine, depuis 7 mois maintenant. Des fois je bosse en soirée, des fois je dédie des 1/2 journées ou journées entières (~6h) à BOB4. Sans compter le temps de réflexion sur le sujet (le jour et la nuit). Déjà plus de 100h certainement! Et c'est très loin d'être fini, je n'en suis certainement pas encore à la moitié. Sachant que je fais en parallèle ~4h de sport par semaine (même assiduité), c'est pas toujours facile à gérer.

Par rapport à la localisation avec tes capteurs US, tu dit que tu les utilise pour corriger la position et la vitesse : j'imagine que ton drone n'a pas pas de carte de ton logement avec les dimensions précises, donc je suppose que tu déduis la vitesse avec deux mesures US et l'heure de chaque mesure et que tu intègre ensuite pour la position.

Non, je n'intègre pas la vitesse déduite des sonars.
A terme, mon drone devra connaitre une carte précise de l'environnement, rentrée à la main. J'ai déjà bien réfléchi à la méthode, la modélisation. Il faut que le drone connaisse tous les murs dont il a besoin, leur position, et surtout les parties planes et dépourvues d'obstacles (meubles) avec lesquelles il peut se recaller EN POSITION. Il faudra donc avoir à quasiment tout instant 2 murs perpendiculaires visibles et propres. J'aurais peut-être droit à 1 ou 2 secondes de vol sans mur pour recaller, mais pas plus. Je devrais déplacer des meubles...
Pour l'instant, je lui ai juste localisé le mur du fond et la baie vitrée que tu vois dans la vidéo, sans délimitation. En vol, je ne doit pour l'instant pas m'écarter de cette zone.

La tolérance de 17° tu l'applique par rapport à l'orientation de ton hélico calculée avec tes gyros ?

La tolérance de 17° est bien déterminée l'orientation 3D estimée à l'aide des gyro ET MAGNETO.

J'imagine que c'est le moteur brushless qui pourrit les mesures ? Surtout que vu la proximité de l'ensemble ça va pas être évident...

Ce sont des moteurs "brushed" (à charbons) et non "brushless". Oui, c'est bien eux qui perturbent. Comme dit un peu plus haut (ici), je vais faire un test avec des moteurs brushless qu'on va me prêter, voir si c'est mieux. En parallèle, je vais essayer de déporter le capteur au bout d'un tube carbone que j'ai récupéré... Mais je n'aime pas trop cette solution, ça n'est pas propre, et le risque de casse augmentera considérablement.

Leon.

[raoullevert]

Juste un mot : chapeau bas.

Autrement, ca n'existe pas des capteurs à défilement, comme pour les souris laser ou infrarouges, mais pour une portée plus importante ?
Il existe un modèle d'auto-pilote qui fonctionne un peu comme ça : centrale inertielle + capteur de défilement pour rester en place.
pour la petite histoire : La première version ne disposait pas de ce capteur, et l'hélico avait tendance à se faire la malle tranquillement jusqu'à ce que les batteries soient mortes :-).

[Leon]

J'ai un peu cherché, mais je n'ai rien trouvé sur le genre de capteur que tu proposes. En fait, je pense que c'est simplement une caméra, avec un soft un peu évolué derrière. Exactement comme dans l'AR-Drone.

C'est sur que ça m'aiderai énormément d'avoir un truc comme ça tout fait.

Leon.

[raoullevert]

Oui tout à fait, c'est une simple caméra avec un soft. En fait dans le principe, une souris optique fonctionne comme ça.
Une caméra et une source laser oscillante (pour éviter les interférences). La caméra à une résolution très faible, mais un fort grossissement, histoire de gagner en précision. Ensuite un dsp se charge de calculer la vitesse et le sens de défilement.
Vu comme ça, c'est simple. Quelques soucis quand même :
-- si la vitesse de déplacement est rapide, et si le rafraichissement de la camera (FPS) est faible => mauvaise detection
-- si le support est uniforme, on ne pas peut détecter le mouvement.

Pour un hélico, il faut gérer en plus l'altitude. Quand l'hélico est haut, la vitesse de défilement apparente du sol est plus petite que quand il est au ras du sol, pour la même vitesse helico/sol. Tant que l'helico n'a pas de grandes variations d'altitude, c'est assez négligeable.

Je vais réfléchir à un pti programme... avec python et opencv pour commencer.
Par contre, il va falloir une certaine puissance de calcul embarquée...

Edit : comme promis, une première ébauche en python

#!/usr/bin/python
# -*- coding: cp1252 -*-
import cv

cv.NamedWindow("sortie", 1)             # Création de la fenetre
capture = cv.CreateCameraCapture(1)     # Selection de la caméra
#Chez moi : cam(0) = caméra intégrée du PC.
#Cam(1) = webcam USB. 

if (not capture):
   print("Ouverture du flux vidéo impossible !\n")

tailleX, tailleY = 100,100    #Définition de l'image qui servira aux calculs
sortie = cv.CreateMat(tailleX,tailleY, cv.CV_8UC3)       # image couleur 
sortieNB = cv.CreateMat(tailleX,tailleY, cv.CV_8UC1)     # image N&B
old_sortieNB = cv.CreateMat(tailleX,tailleY, cv.CV_8UC1)  # image N&B

velx = cv.CreateMat(tailleX,tailleY, cv.CV_32FC1) #Matrices des vitesses
vely = cv.CreateMat(tailleX,tailleY, cv.CV_32FC1) #selon X et Y 

while (1):
    #on capture une premiere image, on la reduit et on la passe en Noir&Blanc
    #-> old_sortieNB : premiere image réduite N&B
    image = cv.QueryFrame(capture)
    cv.Resize(image, sortie)
    cv.CvtColor(sortie, old_sortieNB, cv.CV_RGB2GRAY)
    
    #idem : on capture une deuxième image, on la reduit et on la passe en Noir&Blanc
    #-> sortieNB : deuxième image réduite N&B  
    image = cv.QueryFrame(capture)
    cv.Resize(image, sortie)
    cv.CvtColor(sortie, sortieNB, cv.CV_RGB2GRAY)
    #Calcul des vitesses par flowOptique (velx et vely)
    cv.CalcOpticalFlowLK(old_sortieNB, sortieNB, (15,15), velx, vely)
    #On fait une moyenne de chaque matrice pour avoir une vitesse globale
    #C'est pas la meuilleur des méthodes, mais c'est la plus simple

    ScrollX = cv.Avg(velx)[0] * 50 #Vitesse en X
    ScrollY = cv.Avg(vely)[0] * 50 #Vitesse en Y

    cv.Line (image, (150,150) ,
             (150+ScrollX, 150+ScrollY),
             cv.RGB(255,0,0) ) #On trace un vecteur de vitesse sur l'image
 
    cv.ShowImage("sortie",image) #Et on affiche tout ça 
      
    if cv.WaitKey(10) == 27:  #Appuyer sur ESC = quitter.
       cv.DestroyWindow("sortie") #on ferme la fenetre
       break
    

[Leon]

Apparemment, plusieurs personnes ont réussi à utiliser un capteur de souris optique pour faire ce que tu proposes: déterminer le déplacement à l'aide d'un capteur filmant le sol.
http://www.diydrones.com/profiles/blogs/quad-position-hold-with-mouse

Je vais tester ça prochainement, voir si c'est réellement exploitable. J'ai notamment un peu peur de l'imprécision, et je ne suis pas certain que ça fonctionne sur toutes les surfaces.

Leon.

[Leon]

Bonjour à tous,
Ca faisait quelques temps que je n'avais pas donné de nouvelles de BOB4.
Ca avance moins vite en ce moment, j'ai d'autres occupations. Je pense pouvoir dédier un peu plus de temps dans les prochaines semaines.
Les news:

Crash:
Tout d'abord, BOB4 a subi un bon gros crash. Comment ça s'est passé? Je testais l'estimation de position en pilotant le drone à la radiocommande. D'un coup, il s'est mis à ne plus répondre à mes ordres.
J'ai eu le temps de voir que la LED ne clignottait plus, ce qui signifie que le programme ne tourne plus, carte mère plantée. Dans ce cas, les consignes aux servos et aux moteurs restent figées. Comme BOB4 se dirigeait inexorablement vers un mur à l'autre bout de la pièce, j'ai coupé la puissance à l'aide de la sécurité de la radiocommande, et j'ai courru pour essayer de le rattrapper dans sa chute... en vain. Il a fait une chute libre de 2m de haut.
Résultat? train d'aterrissage cassé. Le train ne protégeait donc plus l'électronique, qui a pris cher! La carte mère s'est légèrement pliée, le module Bluetooth est sorti de son logement, des pistes ont été arrachées. J'ai réparé ça dans la foulée, ça m'a fait perdre plusieurs heures.
A ce jour, je n'ai aucune explication sur le bug qui s'est produit.
Ca m'a fait réfléchir. Et si ça avait été plus grave? Si toute l'électronique avait été détruite? Je me suis dit que je reconstruirait tout! Vu le temps déjà investi dans la conception, la programmation, la mise au point, ça serait dommage de tout perdre.

Le compas magnétique:
Comme vous l'avez certainement lu dans les posts précédents, le compas était très fortement perturbé par les moteurs, surtout quand ils sont à pleine puissance. J'ai fait un test rapide avec des moteurs Brushless, qui n'a rien montré de concluant: les perturbations sont tout aussi fortes.
Alors j'ai décidé de déporter le compas magnétique au bout d'un tube en carbone. Cette solution n'est pas hyper satisfaisante, car ça rajoute un élément fragile, qui peut se casser assez facilement... Mais en revanche, la précision est bien meilleure!

Sur cette photo, vous voyez également le mini cordon USB qui reste à poste. Ca permet de connecter rapidement BOB4 au PC, pour reprogrammer le drone.

Simulation et data logger:
Pour pouvoir enregistrer des "logs" précis et rapide, j'ai développé des bout de code assez simple, mais super utile. La liaison radio a un débit insuffisant (38.4kb/s) pour transmettre toutes les données dynamiques en temps réel (toutes les 50ms). La solution est d'enregistrer toutes ces données dans la RAM de BOB4. Je les transfert vers le PC une fois le vol terminé.
Et à quoi ça sert? Avec toutes les données dynamiques, je peux estimer le comportement de l'hélico par rapport aux consignes. Ca me permet de faire une "modélisation simplifiée" de la dynamique de BOB4. Cette modélisation servira par la suite à pré-régler l'asservissement. C'est à mon avis illusoire de vouloir régler un PID sur un tel engin volant en partant de 0 et en tatonnant. Les risques de casse de matériel sont beaucoup trop grands!
La modélisation est assez simple. Il s'agit en fait de 4 modèles 1D complètement indépendants, correspondant à chacune des 4 commandes de la radio:

• dynamique verticale par rapport à la commande des gaz
• dynamique longitudinale par rapport à la commande cyclique de tangage
• dynamique latérale par rapport à la commande cyclique de roulis
• dynamiques de l'angle de lacet par rapport à la commande de lacet.

Bien sur, j'exploite le tout sous Matlab. Il faut essayer de piloter l'hélico en faisant des "échelons" assez amples avec les manches. C'est comme ça qu'on déduit le plus facilement les caractéristique de la dynamique étudiée.
Ci dessous un exemple de la dynamique verticale. En bleu, c'est l'estimation mesurée, et en rouge, c'est la modélisation. "Consigne", c'est la position de la manette des gaz, qui est l'entrée unique de la modélisation. Vous voyez que ça n'est pas hyper précis, mais je pense que c'est amplement suffisant, pas besoin de chercher la petite bête, c'est juste fait pour faire un "pré-réglage" de l'asservissement.


Leon.