Essaye de programmer en C (pas en C++) comme tu programmerais en Basic, sans te soucier des objets, pointer, fuite mémoire etc.
Puis, quand tu y auras pris goût, tu pourras voir les concepts plus compliqués.

C'est ce que je fais depuis pas mal d'années : pour mes bidouilles, je dois coder en C# et en C++, mais dans ces 2 langages, je code exactement comme en C, langage que je maitrise beaucoup mieux (et qui ressemble beaucoup au basic).

Et c'est sans utiliser les trucs dont je n'ai pas besoin en C : allocation dynamique de mémoire entre autre.

J'utilise la syntaxe C++ et C# quasiment uniquement pour des appels de librairies faites pour du C# et C++, donc trois fois rien.

 

Je n'ai jamais vraiment compris les concepts qui se cachent derrière les langages orientés objet, et ça ne m'intéresse pas trop, tant que j'arrive à coder ce que je veux. Mais j'avoue que parfois, quand je dois me plonger dans du code déjà écrit en C# ou C++, j'ai vraiment du mal... Beaucoup de mal.

Donc il serait bien que je me donne un coup de pied au cul pour franchir le pas... un jour peut-être!

 

Leon.

Bonjour à tous.

Moi c'est Leon, le papa de BOB4. On s'est tous vu à Caprica 3.



J'ai 2 remarques concernant le tri-copter de Websinra:

1) Je suppose que tu comptes piloter ton Drone en "manuel" pendant les phases de mise au point. Comment comptes-tu faire? Avec une télécommand de modélime? Avec autre chose? En tout cas, ça me semble indispensable. L'asservissement hélicoptère est quelque chose de vraiment compliqué à mettre au point.



2) rigidité: Ta structure est peu rigide, c'est certain. Tu dis que ça ne pose pas de problème, et que les vibrations sont raisonnables. Mais attention, une mécanique qui vieillit, des moteurs qui vieillissent, ça va augmenter considérablement les vibrations! Il faut vraiment penser à ça.



Leon.

Ok pour ta réponse.



Ton projet me fait vraiment penser à Vicacopter. Un tri-copter totalement autonome, fait à l'arrache, mais qui fonctionne bien.



Leon.

C'est vrai que c'est joli, comme réalisation. J'ai hate de le voir voler.
Mais attention à un truc: normalement, le faisceau de câble entre le régulateur et le moteur est capable d'émettre beaucoup de perturbations électromagnétiques. Dans la pratique, on essaye de regrouper au maximum les 3 fils, pour limiter les perturbations, voire carrément torsader le tout, ce qui atténue beaucoup les perturbations. Ici, c'est tout l'inverse: les 3 fils sont volontairement séparés pour l'esthétique. Est-ce que ça ne va pas perturber le signal radio? Perturber le compas s'il y en a un?

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.

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.

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.

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.

Je ne fais pas de site pour BOB4 pour l'instant. J'en ferais un quand j'aurais des résultats concrets de vol autonome, je ne vois pas l'intérêt d'en faire un avant. Pour les vidéos, j'en ai posté 2 ou 3 dans les posts précédents.

Pour ce qui est de mikrokopter, ce projet a un gros défaut... c'est que ça ne parle que l'Allemand! Und ich spreche nicht Deutch.

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.

Merci pour ton message.

Est-ce que tu as pensé à entourer l'électronique dans un bloc de mousse si jamais ca ne modifie pas trop le vol de l'engin ?

Pour la mousse, j'ai déjà commencé à en mettre à certains endroits. Le problèmes, c'est qu'il y a plusieurs parties saillantes qui se prennent les
chocs en premier et sur lesquels je ne peut pas mettre de mousse: les sonars (surtout celui du bas), le push de reset, et les connecteurs. J'ai enlevé le capuchon du push, et je vais changer quelques connecteurs pour mettre des coudés, mais pour le reste, c'est plus compliqué.
C'est en fait sur le sonar du bas que l'électronique a du s'appuyer pendant le crash, et autour de laquelle la carte s'est (légèrement) pliée!

Mais clairement, il faut que je protège ça bien avant de m'attaquer à l'asservissement!

Tu ne peux pas trouver un système qui prend le relais si la carte plante histoire de couper la direction et le faire atterrir ? J'imagine que tu y a pensé.
Je sais qu'il existe des systèmes en modélisme qui détectent les ordres de la radiocommande, en cas d'absence temporisée le système effectue un ordre de sauvegarde déterminé à l'avance.

Pour le système de secours, il faut bien voir qu'un des gros risques d'un engin en intérieur, c'est de se prendre les pales dans un objet (mur, mobilier). les dégats peuvent être vraiment conséquent. Donc mettre une procédure de secours qui maintient, par exemple, les pales en mouvement pendant 1 ou 2 secondes le temps de l'atterrissage forcé mais contrôlé, je n'y crois pas. Il est plus sage, à mon avis, de tout couper. C'est ce que mon système actuel de sécurité fait.

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.

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.

Comme demandé, la (toute petite) vidéo... J'essayerai d'y penser par la suite. Je pense que tu as accès à Dailymotion.



Bon, il va falloir attendre pas mal pour avoir le premier vol en "autonome". Je ferais d'abord beaucoup d'essais avec l'hélico télécommandé, pour voir ce que disent les capteurs, et surtout où veut aller la bête.

Leon.

Merci pour ton apréciation, ça fait plaisir!

Leon.

Merci, c'est vraiment sympa d'avoir ce genre de retours, surtout de la part de connaisseurs!

La quantité de travail restante sur ce projet est vraiment importante... Mais je garde espoir.

Leon.

Ca avance, ça avance à petit pas.

Je bosse en ce moment sur la partie "centrale inertielle". C'est l'occasion de retrouver les Math que j'avais abandonné pendant 10 ans... Pas facile, mais ça fait du bien. Un peu de géométrie 3D, d'angles d'euler, de matrices de rotation. J'ai cherché à tout retrouver par moi même, et non à copier/coller du code, pour voir si mes neurones peuvent encore faire quelque chose.

Une vidéo rapide pour la route!


Sur cette vidéo, il n'y a que les gyros qui fonctionnent. J'ai pour l'instant énormément de mal à intégrer correctement les infos des 3 accéléros.

Je développe pour l'instant tout sous Matlab, l'hélico ne fait qu'envoyer ses informations pré-filtrées par Bluetooth au PC qui traite alors les infos. Une fois que ça sera bien mis au point sous Matlab, je porterais le tout sur l'hélico. J'arrive à faire 50 mesures par seconde sur l'hélico. En terme d'algo, je n'utilise pas le classique "filtre de kalman", mais je filtre les données en amont de leur interprétation.

Sinon, j'avais choisi une boussole 2D, et c'est une grossière erreur, ça ne peut pas fonctionner. Je vais devoir changer pour une boussole 3D, ce modèle:
http://www.sparkfun.com/commerce/product_info.php?products_id=9371

Une remarque importante sur la boussole: le champ magnétique créé par les 2 moteurs vers la boussole est très important, n'importe quelle boussole à aiguille est complètement désorientée, placée à ce niveau... et pourtant, une fois calibrée, la boussole électronique marche parfaitement... mais à plat uniquement (2D pas 3D)!

Les capteurs de la centrale ne sont vraiment pas précis (fortes variations de l'offset), normal vu leur prix, je vais devoir ruser pour me satisfaire de leurs performances.

Leon.

Merci à tous pour vos retours!

actuellement tu le fait deja tourner "à travers" la carte mere et stabilisé? ou alors tous les capteurs sont vraiment encore dans le flou?

Les ordres sont issus de la radiocommande, passent par la liaison Bluetooth, sont interprétés par la carte mère, et vont vers les servos et moteurs. Donc oui, ça passe bien par la carte mère, mais elle fait une simple recopie bête et méchante. Un programme de quelques lignes seulement, sans aucune lecture des capteurs. Je n'ai rien développé de plus.

C'est pas trop lourd toute l'électronique ajoutée?

Le devis poids est vraiment très tendu. 260g, comme je l'ai annoncé, en partant d'une base de 215g. J'ai rajouté 55g d'électronique, et enlevé 10g de décorations inutiles. J'ai cherché à faire léger un peu partout. Par exemple, l'épaisseur des PCB a été choisie en 0.8mm contre 1.5 en standard, pour gagner quasiment 15g.

Il t'a coûté combien le free2move ?

Je l'ai acheté chez Lextronic, comme 90% du matériel utilisé. Regarde les tarifs chez eux, ça va de 25 à 40€. Et pour ne pas faillir à ma réputation, j'ai évidemment choisi le plus cher.

Alors est ce que c'est assez stable à ton gout ?
On pourrait avoir une vidéo genre en stationnaire où tu le taquinerais ?

Oui, c'est très stable. En fait, je l'ai pas mal fait voler avant de le transformer. Quand à la vidéo, j'attend d'avoir fait mes premiers algos. Pour l'instant, il ressemble à n'importe quel hélico bi rotor dont tu peux trouver des centaines de vidéos sur le web.

Leon.

Bonjour à tous,

C'est super leon c'est du bon boulot,

en lisant les specificités de ton robot, je me demandai si tu ne devrais pas y incorporer des capteures de chaleurs qui detecte la temperature du corps humain afin qu'il ne puisse se diriger vers quelqu'un par erreur ou bug dans le programme quand il sera autonome, ces petites helices ca tourne quand meme tres vite...

la securité que tu as mis s'active si je comprend bien quand la cm est a court de jut ou perte de liaison, cependant elle securise contre les interferences micro-ondes autres bluetooth etc.. ?

En fait, j'ai pas mal récupéré d'informations sur les drones existants. Tous préconisent de traiter les cas que j'ai traité: plantage du pilote automatique, ou perte de la liaison radio.

Ce sont les actions à réaliser qui diffèrent entre un drone d'intérieur et un drone d'extérieur. Pour un drone d'intérieur, 90% des gens choisissent de stopper net les hélices. L'hélico tombera au sol, avec un peu de dégat... En extérieur, par contre, en cas de plantage, il faut privilégier la reprise manuelle, car l'avion ou l'hélico vole plus haut, plus loin, et dans des endroits pas forcément protégés.

Pour le plantage de la carte, je ne me protège pas seulement des cas de batterie faible pour la carte mère. Ca me protège surtout des bugs qu'il y a déjà eu, et qu'il y aura encore et encore pendant la phase de développement.

Pour la protection par détection de chaleur, je n'y crois pas: trop compliqué pour la petite taille de l'engin. Je n'ai vu ça sur aucun drone d'intérieur.

Aujourd'hui, j'arrive à un niveau de sécurité que j'estime équivalent à n'importe quel hélico radiocommandé. Je ne me protègerai jamais, par exemple, de quelqu'un qui a réussi à pirater ma liaison bluetooth. Je ne pense pas que ce soit nécessaire.

Leon.

Merci pour vos appréciations à tous les deux, ça me fait très plaisir. Et désolé pour le retard dans la réponse, j'aime bien prendre des vacances "déconnectées", sans internet-mail-téléphone.

j'ai toujours quelques problèmes à rester motivé face à certain problèmes qui me bloquaient dans mes projets, je respecte d'autant plus ceux qui arrivent à fournir un travail constant à leur projet.

La motivation est (avec le manque de temps) le principal problème de ce genre de projet. Il est en effet très facile de se démotiver, ou de travailler sur ce que l'on sait bien faire quand on rencontre une difficulté. C'est une des clefs de la réussite d'un tel projet. Si j'arrive au bout (c'est loin d'être gagné), je ferais un post/une page sur les conditions de réussite d'un projet amateur complexe.

Pour le poids de la bête je dit respect : faut le faire pour tout faire tenir dedans, et plus en ce souciant des problèmes de centre de gravité...

Pour le poids, il y a plusieurs facteurs déterminant. J'ai choisi de mettre le minimum de fils, de cordons, de connecteurs possibles, en comparaison des drones que j'ai pu voir. Ensuite, l'utilisation de CMS sur 2 faces fait gagner énormément sur les dimensions des PCB, et donc sur le poids. Enfin, j'ai choisi des composants légers autant que possible: les sonars, le capteur inertiel sont parmis les plus légers du marché.

Pour le centre de gravité, je ne me suis pas trop cassé la tête: j'ai juste placé l'électronique rajoutée en dessous, bien centrée, c'est tout. Cette configuration rajoute d'ailleurs encore un peu plus de stabilité sur cet engin déjà très stable.

J'ai vu que tu utilisais Matlab pour afficher tes données et faire des tests. J'utilise aussi Matlab, ça fait gagner pas mal de temps pour faire du débug, mais je me demandais comment tu fait pour transmettre tes données à Matlab en temps réel ? il y a des boites à outils pour ça peut être ? Comme je suis en train de travailler sur l'asservissement de mon robot en ce moment ça pourrait m'être très pratique

Oui, Matlab est très pratique. J'utilise une ancienne version héritée de mes années d'études (les licenses "école"). J'ai récupéré une toolbox gratuite qui permet d'interfacer plusieurs choses, dont le port série que j'utilise pour BOB4.
http://psychtoolbox.org/wikka.php?wakka=HomePage
Attention, je n'ai pas réussi à faire du temps réel avec ça, je ne pense pas que j'y arriverai. C'est lent, et la lenteur est connue apparemment. Je serais incapable de boucler un asservissement avec ça. L'asservissement tournera donc impérativement sur la carte du drone.

En fait, je traite les données quand elles arrivent jusqu'à Matlab. Elles arrivent par paquet, ce qui fait que je traite 5 pas de calcul d'affilée, puis attend, puis traite 5 pas, etc... Pas optimisé, mais bon...

Je pense que je vais utiliser aussi Matlab pour faire l'IHM (interface homme machine) "sur PC" du drone.

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.

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.

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.

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.

Bob3 et moi-même Leon avons le plaisir de vous annoncer la naissance de

BOB4 !


Album photo complet

Bob 4 est un petit oiseau (hélico) de 260g seulement, qui ne sait pas encore voler autrement que guidé par son papa (=moi). Il a pour vocation de devenir un drone autonome d'intérieur. Après 5 mois de réflexions et de gestation, le voici enfin arrivé. Pour l’instant, il ne sait rien faire. Je lui ai juste appris à suivre les ordres donnés par la télécommande. Ca montre qu’il est bien vivant, que tout fonctionne. Pour l’instant, malgré la présence de nombreux capteurs, il ne voit pas, ne sent pas. Le pauvre… Nous sommes donc au tout début de l’apprentissage de BOB4, de sa programmation, ce qui s’annonce long mais passionnant ! L’objectif est bien de lui apprendre à voler de manière 100% autonome dans un environnement intérieur. C’est ambitieux, j’assume !

Vous voulez en savoir plus ? Alors en vrac :
Base d’hélicoptère bi-rotors LAMA V3 de chez E-Sky dépouillée des éléments décoratifs.
Train d’atterrissage fait maison avec des tiges en carbone pour rehausser l’oiseau et y loger l’électronique.
Module « 3 en 1 » de gestion des moteurs de chez E-Sky (mixer + gyro + variateur)
Carte mère « Embedded Master » de chez GHI-Electronics (ARM7TDMI + 8Mo RAM + 4Mo Flash) fonctionnant sous Microsoft .Net Micro-Framework.
Liaison radio : bi-directionnelle BlueTooth avec 2 modules Free2Move de forte puissance.
4 sonars SRF02
1 centrale inertielle 6 degrés de libertés de chez Sparkfun.
1 boussole électronique HMC6352
1 LED « haute luminosité » de 100mW, pour le fun.

1 alimentation externe 7V 50W pour débugger sans avoir à attendre la recharge des batteries. J’ai du rajouter des gros condos de filtrage sur cette alim, car PWM et alim à découpage ça ne fait pas bon ménage…

Les 2 PCB de BOB4 ont été dessinés par moi-même sous Eagle (version démo, sans routage automatique), et réalisés loin d’ici en Bulgarie chez Olimex, une entreprise que je recommande vivement. Verni épargne double face, trous métallisés, que du bon pour un tarif raisonnable.

L’électronique de l’émetteur radio (radiocommande) a été entièrement remplacée, pour y mettre un module bluetooth, un écran LCD 4x16 caractères, un microcontroleur programmé par mes soins, une liaison série (RS232) vers un PC, et quelques interrupteurs supplémentaires. Le tout fait maison dans le pur style Wrapping des ateliers Leon & Co. L’objectif est d’avoir une seule et unique liaison radio pour toutes les données, que ce soit la programmation, l’envoi de consignes (texte), la commande manuelle, le retour d’informations (vers l’écran de la radio ou vers le PC).

L’électronique de la télécommande et de l’hélico intègre une sécurité vitale : avec 1 switch de la télécommande, je peux couper la puissance quelle que soit l’état de la carte mère, même totalement plantée. De même, la puissance se coupe en cas de perte de la liaison radio.

A bientôt j’espère pour vous informer des progrès de mon bébé !

Leon.