DIY Drone projet

Bonjour à tous,

Depuis quelques temps, je regarde des vidéos et lis des blogs de personnes qui se lancent dans la conception de leur propre drone. A vrai dire je suis plutôt emballé à l’idée de m'en fabriquer un :slight_smile:

Cependant je suis complétement novice et une simple recherche sur google montre la complexité du choix des composants.
Si je résume j'ai besoin de:

  • 1 chassis
  • 4 moteurs pour un quadrocopter
  • 4 hélices
  • 4 ESC pour contrôler les moteurs
  • 1 contrôleur de vol
  • 1 batterie
  • 1 radiocommande
  • quincaillerie

Avant toute chose est ce que c'est intéressant d'utiliser une Arduino comme contrôleur de vol? Ou directement en acheter un dédié ?

Un des objectifs serait de prendre quelques vues aériennes avec une GoPro ou un modèle équivalent (raspberry Pi 3 & raspicam). Comment calculer la charge utile du drone ?

Merci d'avance et bonne journée,
Pm

bonjour,

Un des objectifs serait de prendre quelques vues aériennes avec une GoPro ou un modèle équivalent (raspberry Pi 3 & raspicam). Comment calculer la charge utile du drone ?

avant de te lancer la dedans pour de la prise de vue aérienne, une petite mise en garde, la règlementation change depuis l'année dernière, même si un texte a été repoussé en 2018

Les activités particulières de prises de vues aériennes par aéronefs circulant sans personne à bord (drones) s’exercent dans un cadre réglementaire très encadré et toute personne ne respectant pas cette réglementation est susceptible d’être poursuivie et risque jusqu’à 1 an de prison et 75 000 euros d’amende.

la charge utile est composée de tous les appareils embarqués, tu dois calculer la puissance des moteur et l'efficacité des hélices pour déterminer ce que tu peux embarquer.

pour la calculateur, mieux vaut prendre un appareil prévu, bas' sur ARM en principe, ca ne coute pas si cher comme le naza-m-v2 lite.

Bonjour,

Merci pour les références législatives. Effectivement ce genre d'utilisation peut vite engendrer des dérives.

Si quelqu'un à d'autre suggestions je suis preneur :slight_smile:

Merci et bonne journée,
Pm

De mon expérience, je peux dire ceci:

Il existe des cartes contenant 4 variateurs sur la même carte. L'avantage est de limiter le câblage, et sur une petite machine c'est un vrai avantage. L'inconvénient est qu'un contrôleur qui grille impose de changer toute la carte (ce qui m'est arrivé avant que je ne passe à une carte 4 en 1, justement).

Tant que tu restes sur un programme qui ne gère que le mixage des voies d'entrée (gaz, lacet, roulis, tangage) vers les voies de sorties (moteurs en asymétrie pour roulis et tangage, tous ensemble pour les gaz, et croisés pour le lacet), c'est assez facile à programmer, du moins en théorie. Intégrer un capteur 6DOF est une autre histoire, encore que l'on trouve des tutoriels assez explicite pour parvenir à ses fins.

Dans la pratique, il est impossible (mais j'ai oublié pour quelle raison) d'utiliser de manière fiable la fonction pulseIn() pour acquérir le signal d'entrée venant d'un récepteur RC et la librairie servo pour générer les sorties. Si je me souviens bien il y a un conflit au niveau des interruptions utilisées en interne par Arduino. Sur le programme que j'avais fait, j'utilisais une interruption sur INT0 pour mesurer le temps passé entre deux interruptions et peupler un tableau contenant la dernière valeur reçue pour chaque voie.
Et une interruption utilisant le Timer1 pour générer le signal de sortie sur le port PORT B, soit les broches 8 à 13, ce qui fait 6 voies, ça permet d'avoir les quatre moteurs plus deux autres voies. On peut bien sûr étendre le code pour utiliser un autre port. Je m'étais inspiré de cet article.

En fonctionnement ça tournait bien, à un "détail" près: j'avais un temps de latence d'au moins une demie seconde entre une action sur mon émetteur (Futaba FF6, un vieux machin) et une réaction visible. Comme je n'ai fait que peu d'essais en intérieur, je pense que cette latence vient d'avantage de l'effet de sol et des turbulences engendrées par le petit volume que par le programme, puisqu'il est assez léger et est loin, je crois, de saturer le processeur.

Maintenant, mon avis sur la question: si c'est pour le plaisir de relever un défi et de trouver des solutions en développant, ça ne coûtera rien et ça peut apporter beaucoup de savoir faire. Si c'est pour voler de manière rapide et efficace, il vaut mieux partir sur une solution existante. D'autant que partir de zéro rend difficile de savoir si un problème vient du programme, des solutions techniques adaptées, etc.

Je joins le code tel qu'il était lorsque je suis passé à autre chose, donc sans aucune garantie sur son fonctionnement: j'ai stoppé de bosser dessus du jour au lendemain, donc il y a peut-être des choses dont j'ai commencé la modification et que j'ai laissé an plan.

PS: soyez indulgent pour le code. Je commençais tout juste à programmer, il y a des choses qui me font bondir et que je ne ferais sûrement pas pareil maintenant! Par exemple un delay() dans la boucle principale. :slight_smile:

Recepteur_v0_4.ino (11.1 KB)

Merci beaucoup pour les conseils et le code. Je vais regarder ca.

De ce que j'ai pu lire, beaucoup s'orientent vers des kits à assembler. Cependant est-ce que pour ces contrôleurs plug&play il y a possibilité de modifier le code?
C'est la raison pour laquelle je pensais à l'Arduino pour gérer le contrôle ce qui laisse la liberté d'ajouter d'autre fonctionnalité :slight_smile:
Est ce qu'il y a des biblios fonctionnelles ?

Concernant la charge utile de l'appareil j'aimerai embarquer une goPro. Avec vous quelques conseils sur le gabarit et la motorisation qui pourrait correspondre?

Bon weekend,
Pm

Question motorisation des 2206 avec hélices 7 pouces ou 2208 à plus faible KV avec hélices 8 à 9 pouces voir plus conviennent très bien.
Pour le pas des hélices faut mieux tourner plus grand et moins de pas, genre pas dépasser un pas de 3 par exemple: 7x2.5 ou 8x2.5 ça marche bien.

Pour le lipo un 3000 à 4000mAh en 3 à 4s serait bien pour du statio et translations lentes/rapides, à noter qu'avec mon 2200mAh 4s et des moteurs 2206 hélices 6" ça tiens dans les 5 à 6 minutes en voltige (ralenti moteur plein gaz etc... ce qui consomme pas mal).

Pour l'envergure du drone pour un format quadri ce serait 400 à 500mm d'entre axe moteurs.

tu peux t'inspirer de ce site pour choisir moteur,e tc...

Il y a en effet certaines solutions de contrôleur qui sont open source, à base d'arduino. On peut donc les modifier, cela dit ce sont souvent des projets assez dense, et y apporter des modifications implique d'apprendre l'architecture du code, les interrelations entre les différentes parties, ça peut donc demander beaucoup de temps.

Pas mal le site en lien infobarquee, je ne connaissais pas.

Une autre possibilité qui n'est pas souvent évoquée mais qui fonctionne bien pour en avoir vu voler:

La vidéo est un peu mdr mais si cela peut te donner quelques idées.

Une question qu'il faut se poser: As-tu déjà pratiqué l'aéromodélisme? Si non, alors en premier lieu il faut aller voir un club près de chez toi pour prendre des renseignements de vive voix, et surtout se rendre compte de ce qu'est cette discipline et de ce qu'elle implique niveau sécurité (voir blessures en cas de non respect de sécurité élémentaire).

Si oui et que tu as déjà conscience de tout cela (lieux de vols, fréquences, puissances d'émissions, protection des personnes des biens et des animaux, heures de vols, nuisances sonores, licence d'aéromodélisme affiliée à un club, assurance en cas de crash, risques divers, etc...), alors tu peux te lancer :slight_smile:

La question qui reste (si oui à la première), faire le pas de programmer un contrôleur de vol soit même (carte arduino uno par exemple), ou acheter du tout fait?

Si tu décides de programmer toi même, alors il faut vraiment commencer par d'une part se documenter (documentation arduino, mais aussi documentation sur le vol d'un aéronef type hélico/quadri, des principes du gyroscope, etc...), pour cela il y a les livres, les moustachus (aéromodélistes et pilotes grandeur), internet, et autodidacte pourquoi pas (?), ensuite effectuer des tests basiques, à savoir commencer par faire bouger un servo-moteur avec un gyroscope.

Une première approche consiste à récupérer la valeur d'un axe (accélération x y ou z) d'un gyroscope en degrés par seconde (si on suis une logique), de modifier l'échelle de cette valeur pour la passer en micro-secondes, c'est à dire la largeur d'impulsion (signal pwm) qu'il faut envoyer au servo-moteur.

Imagine un gyroscope comme le mpu6050 (très utilisé encore aujourd'hui) dont on récupère l'axe d'accélération x, une fonction mathématique permettant de faire des courbes (en l'occurence dans l'exemple c'est juste un changement d'échelle), et un servo-moteur lambda (acceptant des ordres de 1000 à 2000 micro-seconde à la fréquence de 50Hz), la ligne correspondrait dans l'idéal à ça:

tonServo.us (courbe (-2000, tonGyroscope.x, 2000, 1000, 2000);

tonGyroscope.x c'est la valeur en degrés par seconde renvoyé par le gyro (le mini/maxi possible avec le mpu6050)
tonServo.us est une fonction pour envoyer le pwm en micro-seconde au servo-moteur
et courbe sert à faire en sorte que l'intervalle -2000 à 2000 degrés par seconde renvoyé par le gyro se retrouve dans un intervalle 1000 à 2000 micro-secondes (valeur acceptées par le servo).

Si tu veux un détail de la fonction courbe (on sait jamais):

float courbe (const float POSITION_START, const float POSITION_CURRENT, const float POSITION_END, const float INTERPOLATION_START, const float INTERPOLATION_END)
{
	float value = 0;
	
	if ((POSITION_START < POSITION_END && POSITION_CURRENT <= POSITION_START) || (POSITION_START > POSITION_END && POSITION_CURRENT >= POSITION_START))
	{
		value = INTERPOLATION_START;
	}
	else if ((POSITION_START < POSITION_END && POSITION_CURRENT >= POSITION_END) || (POSITION_START > POSITION_END && POSITION_CURRENT <= POSITION_END))
	{
		value = INTERPOLATION_END;
	}
	else
	{
		if (INTERPOLATION_END > INTERPOLATION_START)
		{
			value = INTERPOLATION_START + ((INTERPOLATION_END - INTERPOLATION_START) * ((POSITION_CURRENT - POSITION_START) / (POSITION_END - POSITION_START)));
		}
		else
		{
			value = INTERPOLATION_START - ((INTERPOLATION_START - INTERPOLATION_END) * ((POSITION_CURRENT - POSITION_START) / (POSITION_END - POSITION_START)));
		}
	}
	
	return value;
}

Maintenant que cette logique est comprise, que ton servo bouge au max quand le gyroscope détecte une accélération de 2000 degrés par seconde et au min quand il détecte -2000 degrés par seconde, il faut comprendre ce que sont les gains dans un tel système asservi.

Un exemple très simple consiste à modifier les valeurs min max (butées) de 2000 et - 2000 degrés par seconde:

tonServo.us (courbe (-1000, tonGyroscope.x, 1000, 1000, 2000);

Ici, j'ai passé -2000°/s à -1000°/s, et 2000°/s à 1000°/s, j'ai donc rajouté 50% de gains.

Ce qui à pour conséquence de rendre le système 50% plus sensible (50% plus réactif à une accélération), à ceci il faut comprendre que dès que le gyro détecte 1000°/s en positif ou en négatif, le servo se déplace au min ou max. Ou en prévision de ton développement de drone, cela signifie que l'hélicoptère est plus verrouillé sur son axe x (généralement l'axe de tangage).

On peut donc déjà inclure les gains sur l'axe x:

const float GAIN_X = 50;
float gainX = 0;

gainX = courbe (0, GAIN_X, 100, 2000, 0);

tonServo.us (courbe (-gainX, tonGyroscope.x, gainX, 1000, 2000);

Ici GAIN_X est le paramètre de réglage du gain allant de 0% à 100%, gainX est un changement d'échelle respectivement de 2000°/s pour un gain de 0% à 0°/s pour un gain de 100%.

Une fois que tu as bien compris ce principe, il faut ajouter la consigne du pilote sur cet axe x (on a dit tangage).
Tu peux utiliser du matos perso pour le pilotage mais j'imagine que tu vas utiliser une radiocommande et récepteur rc standards pour piloter, donc la fonction qui va récupérer le signal pwm de l'axe de tangage vennant de ton récepteur de modélisme standard renverra des valeurs en largeur d'impulsion donc en micro-seconde (si on respecte la logique).

Je pense que comme la majorité des radiocommandes du commerce, l'intervalle sera comme celle d'un servo-moteur standard à savoir 1000 à 2000 micro-seconde.

Le but du jeu est d'utiliser cet ordre (valeur lue de 1000us à 2000us) et de modifier cet intervalle pour le passer en degrés par seconde afin d'induire un décalage (offset) dans la consigne par rapport aux valeurs retournées par le gyroscope. Ce qui signifie qu'au lieu que le gyroscope suive une valeur neutre de 0°/s, et stabilise l'ensemble à cette valeur, il devra stabiliser l'hélicoptère à une autre valeur (si l'ordre du pilote indique de faire pivoter l'hélicoptère sur l'axe de tangage à 25°/s, le système fera tout pour stabiliser la machine à 25°/s au lieu de 0°/s).

L'exemple devient alors ceci:

const float GAIN_X = 50;
float gainX = 0;
float offsetX = 0;

gainX = courbe (0, GAIN_X, 100, 2000, 0);

offsetX = courbe (1000, pilotageTangage.us, 2000, -45, 45);
tonServo.us (courbe (-gainX, tonGyroscope.x + offsetX, gainX, 1000, 2000);

Le nouveau venu est pilotageTangage.us, la valeur pwm en micro-secondes renvoyée par le récepteur de modélisme standard. Cette valeur est changée en -45°/s à 45°/s, puis injectée comme offset à la valeur renvoyée du gyroscope.

-45°/s à 45°/s sont les débattements min max, cela signifie que ton servo-moteur ou à posteriori ton drone (quadrihélicoptère) pivotera sur lui même à 45°/s quand tu penchera ton manche de tangage au max (si bien entendu les gains sont bien réglés).

Une fois que tu es arrivé à cette étape on pourra voir la suite si tu veux, à savoir qu'un servo-moteur seul ce n'est pas 4 moteurs (il faut dispatcher les ordres à des couples de moteurs), ensuite pour qu'un hélico soit bien verrouillé sur ses axe il doit disposer pour effectuer ses corrections du maximum de débattements disponibles (gaz au ralenti jusqu'à pleins gaz), quel que soit si ton manche de gaz à la radiocommande (le collectif) soit à gaz mini ou gaz maxi.

Cela implique donc de gérer les corrections aux moteurs de façon dissymétrique lorsque le manche de gaz n'est pas parfaitement au neutre (comprendre à cela que quand les moteurs sont déjà au gaz ralenti, on ne peut pas leur demander de ralentir encore plus, et inversement quand on est déjà à plein gaz).

Ensuite il faudra induire des gains variables en fonction de la position du manche de gaz (le gain diminue un peu plus on va vers plein gaz du fait du rendement des hélices qui augmente).

Et chose que j'ai rajouté sur le mien mais qui n'est pas nécessaire en prise de vue aérienne (c'est surtout en voltige au final mais je préfère te l'indiquer ça fait une info de plus), c'est le gain qui augmente en fonction d'un ordre au cyclique, et qui persiste un peu (quelques 10ènes de millisecondes tout au plus) ce qui verrouille plus l'hélico durant les ordres vifs au cyclique.

Il faudra rajouter aussi pour ton projet la gestion d'un horizon artificiel, très pratique pour de la prise de vue aérienne stabilisée. Un internaute m'avait demandé cet horizon (j'en avais pas le besoin personnel), j'avais donc développé et testé en ce sens une nouvelle version de mon algorithme avec horizon, parfaitement fonctionnelle et validée. Quand tu sera rendu à cette étape je pourrais t'expliquer si tu le souhaites.

Maintenant si tu décides de ne pas programmer tout ça toi même, par expérience de mes collègues modélistes qui sont parti de matos tout fait (moi je suis pas un bon exemple étant parti de zéro), question matériel comme je l'ai un peu évoqué, si je reprends ta liste:

  • 1 chassis format 450 (+1 nacelle gopro stabilisée?)
  • 4 moteurs 2206, 2208, 2212 (ou plus gros mais ça tire déjà pas mal de charge, à noter qu'un petit 2206 avec la bonne hélice tire 330g à 50% de gaz, ça fait 1.32Kg avec 4 moteurs)
  • 4 hélices 7 à 9 pouces de diamètre
  • 4 ESC pour contrôler les moteurs de 18A à 30A (selon les moteurs)
  • 1 contrôleur de vol (DJI = très chère leur mer**, et beaucoup de crashs à leur actif) la MultiWii est vraiment pas mal, mais c'est moins accessible que du réellement tout fait, par contre y a beaucoup de forums de discussion sur le sujet (à voir le pour et le contre).
  • 1 batterie 3/4s (voir 6s si vraiment gros moteurs) en 3000 à 4000mAh (turnigy est une bonne marque très accessible niveau tarifs que j'utilise depuis des années sur hélicos de voltige 3d)
  • 1 radiocommande 6 voies (prévoir voies proportionnelles en + pour pilotage nacelle) Futaba?/Graupner?/Hitec?/ ou certaines marques alternatives moins onéreuses, voir ici dans la liste: https://hobbyking.com/en_us/radios-receivers-1/complete-systems.html
  • quincaillerie = vis (généralement M3) écrous freins, frein filet, rondelles, fils awg12 à awg 18 pour partie puissance, et plus petits pour partie commande (rallonges de servo par exemple), étain et fer à souder, gaine thermo diamètre 2 à 10 (ou 15mm max), colliers plastique pour fixer tout ce qui est câblage, esc, etc...

1 contrôleur de vol (DJI = très chère leur mer**, et beaucoup de crashs à leur actif) la MultiWii est vraiment pas mal, mais c'est moins accessible que du réellement tout fait, par contre y a beaucoup de forums de discussion sur le sujet (à voir le pour et le contre).

chacun ses gouts, un naza MV2 est assez stable avec le firm 4.02
je viens d'acheter un phantom 1.2 5.8ghz d'occase et refais toutes les soudures d'alim.
testé et assez stable.
niveau prix ca se tient, ardupilot est cher quand même.

tout dépend des moyens, du type de drone (photo/vidéo, racer, etc...)

Ça je me doutais bien de la réponse, sauf que l'ayant bien testé en intérieur et en extérieur quand je bossais dans une boutique de modélisme, je peux te dire que comparé à d'autres machines c'est juste une arnaque extraordinaire ce truc ! Pour dire qu'il vole bien faut soit pas savoir piloter (voler en automatique), soit n'avoir jamais testé autre chose, soit avoir des actions chez dji...

Et le prix est complètement hallucinant ! C'est le "drone" le plus cher du marché pour ce que c'est il me semble à l'heure actuelle, surtout le rapport qualité/prix. C'est un peu comme apple, il est blanc, tu payes la marque et c'est tout. L'intérieur est super mal foutu, je ne sais pas si c'est encore le cas sur les versions 3 ou 4 car je ne les aient pas ouvertes.

Dans certaines translations les réactions en vol sont vraiment nul à chier, je ne sais pas comment ils ont programmé leur truc mais ça fait peur. Et l'époque des nombreux updates de leur firmware avec les appels clients qui ont crashés pour cause de bug, ça donne quand même pas très envie.

De tout ce qui existe sur le marché c'est vraiment le choix le plus exécrable qui soit, choix à déconseiller totalement, mais la publicité (magazine/internet et journal du 20h + documentaires sur les drones) faisant son travail, et les marges complètement énormes sur ce produit font que les magasins les affichent en tête de liste, et les gens achètent évidement.

Pour ardupilot, oui c'est très cher, mais si tu fais allusion à mon évocation de MultiWii, c'est pas de ça que je parlais, ce sont les cartes qui ont lancés les drones et qui découlent des premières réunions annuelles universitaires (concours de robotique à base de quadrihélicoptères) sur le sujet il y a 15 à 20 ans: http://flyduino.net/Multikopter-FC-Multiwii_1

Carte qui n'a d’ailleurs conservé que le nom car aujourd'hui ce sont plus les accéléromètres de la Wiimote qui sont utilisés mais le mpu6050, et plus le 328p mais plutôt le 32u4.

Pour dire qu'il vole bien faut soit pas savoir piloter (voler en automatique), soit n'avoir jamais testé autre chose, soit avoir des actions chez dji...

faut pas être aussi sectaire que ca.
le SAV est a chi... , mais si tu mets les mains dedans, ca le fait.
après tu peux faire toi même ton drone, mais ca demande énormément de boulot, c'est comme lorsque tu fais ton pc toi même.
il faut faire un choix, soit du tout prêt sans prise de tête, soit tu mets le prix et tu sais ce que tu as.

pour ardupilot, je trouve ca cher pour de l'open source
après si tu rajoute le fpv et tout ce qui va avec, ca revient plus cher qu'un dji, sans compter la radio 6-8-12- voies et plus.

donc le cas qui concerne ce post est de savoir ce qu'il veut faire avec le drone, en fonction de ca, on peut orienter vers telle ou telle solution.

mon prochain drone sera un tout fait pour la simple et bonne raison que ca prend du temps pour rédiger tous les documents pour l'agrémentation dgac en s1-2-3
mais je réfléchis en même temps pour un maison, chassis carbon, etc... et pouvant soulever 5-10kg
ca ne sera pas le même prix, ni la même utilisation.

mais ça demande énormément de boulot

Ah bon ? C'est bizarre d'après la team "mauvaise foi" et toute la clic (et j'en passe) le travail que j'ai fourni (module et tous les projets qui y sont associé) ne serait qu'une vulgaire foutaise nul à chie*... bref passons.

ardupilot

Encore une fois il n'est pas question d'ardupilot, mais d'une carte à moins de 30€ avec le programme multiwii open source c'est à dire un programme tout fait à base d'arduino dans lequel (normalement si on fait pas le con) ne demande aucune retouche pour être parfaitement fonctionnel.

De plus comme je l'ai dit historiquement ce sont les inventeurs de la formule actuelle type quadri, donc ils ont peut être 15/20 ans d’expérience.

donc le cas qui concerne ce post est de savoir ce qu'il veut faire avec le drone

citation:

Un des objectifs serait de prendre quelques vues aériennes avec une GoPro ou un modèle équivalent

l'agrémentation dgac en s1-2-3

Ça je comprend pas contre y a pas de soucis.

Pour en revenir, autre que DJI que je déconseille fortement (prix, comportement en vol, composants à bord à l'image de l'iphone c'est à dire 150€ de composants mais prix public > 800€, etc...), de tout ce que j'ai pu tester chez miniplanes/droneshop/fxmodel (c'est la même boite), je conseille vivement le blade 350qx, prix largement inférieurs à dji, comportement en vol vraiment supérieur, pour dire je faisais des flips en mode manuel sous le porche du hangar miniplanes sans soucis.

Voir ici un article sur ce modèle: https://www.helicomicro.com/2013/07/10/blade-350qx/

Toujours est t'il que les 350qx de chez blade n'ont rien à voir avec la concurrence en terme de comportement, sauf éventuellement par rapport aux quadris de chez align (que je n'ai pas testé) mais qui au vue de ce que fait la marque en terme d'hélicos de voltige 3d, ne doit pas avoir raté son quadri j'imagine... (et puis les vidéos en témoignent). Par contre le prix est plus cher qu'un blade.

Faut voir le pour et le contre de tout ça, mais aillant testé beaucoup de produits type quadri je peux témoigner.

Ensuite, question qualité de la programmation et du comportement en vol de l'algorithme, même si c'est déjà pas mal, blade, align, ou pas, ça n'équivaut de ce que j'ai testé (curieusement ou malheureusement j'en sais rien) pas encore au niveau de l'algorithme que j'ai développé pour le petit 328p (pourtant cet algorithme est simple), c'est donc à se demander ce que font les constructeurs qui pourtant ont souvent une armée de petits programmeurs chinois ingénieurs.

Explication: peut être qu'en complexifiant leur code tout devient archi lourd... (GPS, + gestion de ceci, + gestion de cela), bref c'est pas très épuré au final. Et les performances moteurs/hélices/esc doivent y faire aussi surtout sur des versions RTF...

Ou peut être que malgré le 328p et ses petits 16Mhz que j'utilise, ce serait plusieurs points qui apportent en comportement en vol sur le mien, points que j'évoque sur mon site mais à ajouter à cela des choses importantes: faire tourner les contrôleurs de moteur brushless à 1000Hz, et pas de couche d'abstraction qui ralenti tout (c'est directement du c++ sans mer** derrière). Ajouté à cela un algorithme simple, donc ça s’exécute vite, et forcément en vol ça réagit vite (pas besoin de calcul aérodynamique compliqué).

Après y a des solutions encore plus performantes à base de microcontrôleur 32 bits STM32F4 par exemple qui tourne jusqu'à 180MHz (http://neuron.eznov.com/), l'auteur m'a affirmé que sa boucle de calcul s’exécute en un peu moins d'1ms (ce qui forcément participe au verrouillage du quadri en vol), mais la on joue pas dans la même cour comparé à un 328p 8 bits 16Mhz. Donc est ce que gagner 2ms ou 3ms vaut le coût sachant que leur module coûte quand même assez cher...

Dans la pratique, il est impossible (mais j'ai oublié pour quelle raison) d'utiliser de manière fiable la fonction pulseIn() pour acquérir le signal d'entrée venant d'un récepteur RC et la librairie servo pour générer les sorties. Si je me souviens bien il y a un conflit au niveau des interruptions utilisées en interne par Arduino. Sur le programme que j'avais fait, j'utilisais une interruption sur INT0 pour mesurer le temps passé entre deux interruptions et peupler un tableau contenant la dernière valeur reçue pour chaque voie.
Et une interruption utilisant le Timer1 pour générer le signal de sortie sur le port PORT B, soit les broches 8 à 13, ce qui fait 6 voies, ça permet d'avoir les quatre moteurs plus deux autres voies. On peut bien sûr étendre le code pour utiliser un autre port. Je m'étais inspiré de cet article.

En fonctionnement ça tournait bien, à un "détail" près: j'avais un temps de latence d'au moins une demie seconde entre une action sur mon émetteur (Futaba FF6, un vieux machin) et une réaction visible. Comme je n'ai fait que peu d'essais en intérieur, je pense que cette latence vient d'avantage de l'effet de sol et des turbulences engendrées par le petit volume que par le programme, puisqu'il est assez léger et est loin, je crois, de saturer le processeur.

Non c'est sûrement pas les turbulences ou effets de sol (j'ai jamais constaté de latence sur le mien).

Ce qu'il faut c'est utiliser les PCINT0 1 et 2 (Pin Change Interrupt) du 328p, et il n'y aura pas de soucis ça réagira dans les 20ms (le 50Hz du pwm provenant de récepteurs de modélisme standards).

Ensuite si tu veux que sa réagisse plus vite que 20ms, il faut soit un récepteur rc standard qui envoie un pwm avec plus de 50Hz, ou une solution type s-bus (qui est en fait du USART), ou bien encore fabriquer ta propre radiocommande et se passer tout simplement du pwm (genre communiquer en spi avec l'émetteur/récepteur). Mais honnêtement en 50Hz j'arrive personnellement pas à ressentir de latence même en voltige assez poussée, donc à priori y a pas de soucis avec ce bon vieux pwm 50hz...

sylvainmahe:
Non c'est sûrement pas les turbulences ou effets de sol (j'ai jamais constaté de latence sur le mien).

Ce qu'il faut c'est utiliser les PCINT0 1 et 2 (Pin Change Interrupt) du 328p, et il n'y aura pas de soucis ça réagira dans les 20ms (le 50Hz du pwm provenant de récepteurs de modélisme standards).

Ensuite si tu veux que sa réagisse plus vite que 20ms, il faut soit un récepteur rc standard qui envoie un pwm avec plus de 50Hz, ou une solution type s-bus (qui est en fait du USART), ou bien encore fabriquer ta propre radiocommande et se passer tout simplement du pwm (genre communiquer en spi avec l'émetteur/récepteur). Mais honnêtement en 50Hz j'arrive personnellement pas à ressentir de latence même en voltige assez poussée, donc à priori y a pas de soucis avec ce bon vieux pwm 50hz...

Merci pour les précisions!

Pour lire le signal d'entrée, c'est ce que je fais. J'ai ouvert mon récepteur (celui qui va, ou plutôt allait, avec la FF6), pour pouvoir lire le signal avant le shift register. Ce signal est envoyé sur l'INT0, qui le "décortique" et le rebalance sur chaque voie: détection du début du train d'impulsion, et mémorisation de la voie en cours. Voir le fichier attaché à ma première intervention sur ce post.

J'avais pensé à faire ma propre radio, ou en tout cas la modifier, notamment parce que je ne suis même pas sûr que les fréquences utilisés par mes deux émetteurs (Futaba FF6 et Hitec Focus 4) soient encore autorisées.
Pour la question du temps de latence, il faudrait surtout que je me replonge dans mon code, que je le nettoie et le reformate avec le bénéfice de ce que j'ai appris depuis deux ans, et surtout que je fasse des essais en extérieur...

Ce signal est envoyé sur l'INT0

Alors c'est ça que je ne comprend pas du coup? :slight_smile: Peut être c'est avec ça que tu perds du temps?

Dans le principe, avec les pin change interrupt il faut faire un test pour savoir de quelle pin il s'agit, mais mise à part ça (pour ma part) je ne me sert pas de INT0.

En gros un front montant est attendu sur telle pin ce qui déclenche une interruption, quand cela arrive la mesure du temps est prise, et la prochaine interruption sur la même pin est le front descendant. Une fois que la mesure est prise via le front descendant, le système passe à la pin suivante.

Bien sûr j'ai mis un système de timeout par sécurité (dont on peut choisir le délai) si jamais un fil du pwm se déconnecte, ou bien qu'une voie du récepteur rc de modélisme bug, ça passe automatiquement à l'analyse de la pin suivante (de la voie suivante).

Généralement les récepteurs de modélisme standards n'ont pas 36 timers dans leur microcontrôleur, ils envoient donc leur pwm légèrement décalé de voies en voies à la fréquence de 50Hz. Donc si on veut éviter de perdre du temps dans la lecture, c'est une bonne idée de lire les voies pwm dans le même ordre (par exemple voie 1, puis voie 2, etc...) pour suivre la séquence décalée du pwm et éviter d'en louper une et de devoir refaire des tours de boucle pour rien.

Une autre idée que j'ai pensé pour gagner du temps, étant donné que le 328p dispose de 3 ports (PCINT0 1 et 2), c'est de dispatcher les connections (récepteur standard vers 328p) sur ces 3 ports. Par exemple les gaz sur une pin de PCINT0, le tangage sur une pin de PCINT1, etc...

C'est quelque chose que je n'ai pas fait parce que ça fonctionne déjà tellement bien, mais pourquoi pas un jour je m'amuserais à coder une petite amélioration de ma classe pwmRead de mon projet...

il faudrait surtout que je me replonge dans mon code, que je le nettoie et le reformate avec le bénéfice de ce que j'ai appris depuis deux ans, et surtout que je fasse des essais en extérieur...

Je le pense en effet, depuis 2 ans tu as du gagner énormément en assurance et en compétence de programmation, ce serait certainement très intéressant de repartir sur un tel projet !

sylvainmahe:
Alors c'est ça que je ne comprend pas du coup? :slight_smile: Peut être c'est avec ça que tu perds du temps?

C'est ma faute: j'ai lu ton intervention trop vite. j'avais cru lire que tu parlais des INT0 et 1, et pas des PCINT0, 1 et 2.
En fait, le raisonnement était le suivant. Puisque le récepteur décode un train d'impulsion pour l'envoyer vers les différentes voies, autant lire ce train d'impulsion tel quel, plutôt que de lire chacune des voies. Donc je mesure le temps entre deux impulsions. S'il est supérieur à ce que peut être la longueur d'une impulsion pour une voie, alors je considère que je suis en fin de train, et je me prépare donc à lire la voie 1. Ensuite, à chaque impulsion je mémorise la durée, l'attribue à la voir courante, incrémente le numéro de voie et entame la mesure suivante.

faire ainsi était motivé par deux points: économiser du câblage. Tous ces câbles, ça me fatigue, et c'est couramment une source de bug. Déjà que je me plante régulièrement avec un seul câble que je ne branche pas au bon endroit... Et à l'époque où j'ai écris ce code, je n'avais pas parcouru les documentations Atmel, donc, je n'avais simplement pas percuté qu'il y avait des interruptions sur toutes les broches, ni que ça pourrait servir. Si je devais me replonger dedans, c'est probablement ce que je ferais. Il me semble en effet plus facile d'attribuer une broche à une entrée et de savoir laquelle a déclenché l'interruption, que de faire ce que j'ai fait... :wink:

Ok je comprends, c'est une bonne idée du coup de tout rassembler sur un fil :wink:
En fait tu as fait ton s-bus perso en quelque sorte...

Par contre il suffit qu'une voie mer** dans ce type de système et ça risque de décaler tout non? Genre mettre le tangage sur le roulis, etc... Mais bon pour que ça déconne, faut admettre qu'on est déjà mal barré donc bon, tout ça est relatif finalement...

En revanche, faut être sûr que dans les récepteurs modernes d'aujourd'hui il n'y a pas 2 oscillateurs qui s'occupent du pwm (2 trames de 50Hz), mais mise à part ça c'est une bonne alternative ton idée.

Après question câblage ça peut être propre aussi avec plusieurs câbles, sans être trop trop le bordel.

En fait je n'ai pas eu l'idée tout seul! J'avais trouvé un tutoriel qui expliquait comment utiliser le train d'impulsion (qui est disponible brut sur certains récepteurs), et un autre qui expliquait que ce train d'impulsion est souvent simplement dispatché vers les différentes voies avec un shift register. Il se trouve que sur le mien c'était le cas, ça ma semblé être plus pratique. D'ailleurs, c'est drôle, j'ai découvert au passage que mon récepteur, qui est un 4 voies, reçoit en fait 8 voies et n'en rend disponible que la moitié sur les broches. :slight_smile:

Pour la question du décalage, je l'ai gérée comme ça: puisqu'on mesure la longueur de chaque impulsion, il est assez facile de faire en sorte que si elle dépasse une durée déterminée (5, ou 10ms), on considère être en fin de train d'impulsion, et donc considérer la suivante comme le top départ pour les 6 voies. En fait je suppose que c'est exactement ce que fait le récepteur lui-même, mais avec des composants au lieu du code.
et ensuite un compteur les passe à 0 les unes après les autres, en fonction de la valeur de sortie.
L'autre avantage d'utiliser le train d'impulsion brut, c'est que ça permet de garder pas mal de choix pour les broches de sortie. Il se trouve que l'Atmega 328, les sorties correspondant au PORT B sont contiguës (8 à 13). Comme la manipulation directe du port m'a semblé préférable au classique digitalWrite(), cela permet d'utiliser directement le numéro de la voie comme valeur de bit shift. Toutes les voies passent à 1 en même temps, elles sont triées par ordre de longueur d'impulsion croissante, et une interruption les passe à 0 quand le bon "délai" est écoulé. Ca rend à la fois le câblage plus facile, puisque les 6 première voies sont côte à côte sur la carte, et la programmation plus facile que s'il fallait affecter un port et un rang à chaque voie, et gérer plusieurs ports dans la routine d'interruption.

Il y a un autre avantage potentiel qui découle de la manière dont sont gérées les voies en sortie, qui passent toutes à 1 en même temps, puis à 0 au fur et à mesure: puisque la longueur d'une impulsion pour une voie est d'environ 3ms au maximum, cela permet de potentiellement augmenter la fréquence de sortie. Les servos et les variateurs sont prévus pour fonctionner avec un signal d'entrée autour de 50 Hz, mais on peut dans une certaine mesure changer cette fréquence dans un sens ou l'autre. Du coup si les valeurs provenant de l'émetteur arrivent toujours à la même fréquence, en revanche ça laisse de la marge pour augmenter la fréquence des corrections provenant des gyroscopes!

C'est malin, maintenant j'ai envie de ressortir le projet du placard! Avec tout ce que j'ai déjà en cours... :slight_smile: