Discussion :

[Guesset]

Bonjour Positron,

...je joins une photo des résultats, photo où l'on aperçois les lancées positive et qui finissent par donner un brin de tension mais c'est tout !
Pièce jointe 671606

C'est quoi le signal du haut ? Il ne semble pas faire 20ms de période.

Tu peux donner le programme réellement envoyé sur la UNO et une photo du câblage ? Merci.

Tu sembles avoir un doute sur le téléchargement. Essaye avec un programme exemple type blink (led de la carte qui clignote) pour voir si la chaîne de production de code et de chargement fonctionne bien.

Salut.

[henderson]

Le fait de raisonner en degrés sur des servos, c'est logique donc c'est le référentiel pour passer les paramètres.
Rien de plus !
Peut-être qu'en arrière plan 180 correspondent à 255 ... ce dont on est sûr, par contre, c'est que ça correspondra à 2.5 ms !
Enfin ... sur des modèles arduino REV3 ... presque !

[Positron 2]

Re,

C'est quoi le signal du haut ? Il ne semble pas faire 20ms de période.

En effet il ne peut pas faire 20 ms, C'est le signal du capteur envoyé sur le 2 ( const unsigned interrupt_pin= 2; // <=> optical sensor) Il va de 0 à 15000 T/mn X 2 (tops/tour)
En bas c'est le signal récupéré sur la sortie 9 (const unsigned analog_pin= 9; // <=> V_out) les fameuses lancées positives à peine visibles
Je viens de contrôler mon Arduino avec un programme servo et il fonctionne très bien
Vous parlez en degrés, je vais peut-être dire une ânerie, ce sera pas la première ni la dernière j'espère ! ne vaudrait il pas mieux mesurer le temps entre deux tops, parce que le rapport durée du top et durée entre deux tops la durée est proportionnelle à la vitesse mais égale, je vais mettre un exemple pour bien me faire comprendre: le top fait 10 m/m entre deux top 100 m/m en tournant 10 fois plus vite, le top va faire 1 m/m et entre deux tops 10 m/m la durée reste proportionnelle l'un par rapport à l'autre,
Merci
Clt

[henderson]

On ne parle plus de la même chose !
On en est où exactement ?
La solution du problème ici est matériel !
Si on a deux régulateurs identiques et paramétrés à l'identique et deux moteurs identiques : montés en "Y" depuis le récepteur il n'y aurait plus de problème !
La mesure de la fréquence des hélices ainsi que le calage n'aurait plus lieu d'être !
Il ne resterait qu'à développer sur l'arduino l'effet DIR sur les GAZ pour l'un ou l'autre des deux moteurs, à partir des commandes en provenance du récepteur.
Les signaux en sortie du récepteur semblent être du même type que ceux employés pour les servos !
Donc les servos c'est la dernière étape : mise en forme des signaux de commande des moteurs vers les régulateurs, au format "servo" !

[henderson]

A titre perso j'ai fais une erreur en utilisant de la PWM "full scale", c'est à dire sur toute l'impulsion comme si j'avais à faire à un moteur CC avec un pont H.
Ici, on doit moduler une impulsion qui ne fait que 2 ms avec une bordure (le min) de 0.5 ms dans une période de 20 ms.
Or la bibliothèque Servo.h permet de régler très facilement ce problème ... c'est fait pour !

[Positron 2]

Re,

On ne parle plus de la même chose !

C'est vrai dans mon post précédant, je répondais à Guesset et Kaitlyn pour le programme de conversion Numérique analogique pour mon montage en analogique

On en est où exactement ?

On court deux lièvres à la fois !!
Toi, c'est le programme qui permet de faire tourner les moteurs en tenant compte de la différence des régulateurs, ça devient un peu brouillon je le reconnais

Si on a deux régulateurs identiques et paramétrés à l'identique et deux moteurs identiques : montés en "Y" depuis le récepteur

Ce n'est pas le cas et c'est pour ça que l'on rejoint Guesset et Kaitlyn pour trouver une solution de corriger les défauts

Il ne resterait qu'à développer sur l'arduino l'effet DIR sur les GAZ pour l'un ou l'autre des deux moteurs, à partir des commandes en provenance du récepteur.

Oui mais il faut tenir compte qu'il y a une différence dans les régulateurs, donc correction en tenant compte des signaux des capteurs

Les signaux en sortie du récepteur semblent être du même type que ceux employés pour les servos !

Absolument les mêmes

Donc les servos c'est la dernière étape : mise en forme des signaux de commande des moteurs vers les régulateurs, au format "servo" !

Exact.
Merci

[Guesset]

Bonjour Positron,

En effet il ne peut pas faire 20 ms, C'est le signal du capteur envoyé sur le 2 ( const unsigned interrupt_pin= 2; // <=> optical sensor) Il va de 0 à 15000 T/mn X 2 (tops/tour)
En bas c'est le signal récupéré sur la sortie 9 (const unsigned analog_pin= 9; // <=> V_out) les fameuses lancées positives à peine visibles ...

Je ne suis pas sûr qu'il y ait un problème. La trace n'est pas très lisible mais en la nettoyant un peu on obtient ceci :

Je n'arrive toujours pas à avoir des images de taille raisonnable

Si 125 Hz représente 5% de la gamme des fréquences, alors en sortie, le 100%, soit 5 Volts de moyenne, représenterait alors une fréquence de 2,5 kHz (125 Hz*100/5).

La lisibilité serait déjà un peu meilleure à 1 ms par division avec une synchro sur CH2. La capture one shot peut être désactivée (tant pis pour CH1) pour avoir une trace CH2 plus lisse..

Je conseille d'augmenter la vitesse pour voir si les impulsions de sortie prennent un peu de largeur (donc une composante continue plus élevée).

Salut.

[Guesset]

Bonjour Henderson,

...Si on a deux régulateurs identiques et paramétrés à l'identique et deux moteurs identiques : montés en "Y" depuis le récepteur il n'y aurait plus de problème !
La mesure de la fréquence des hélices ainsi que le calage n'aurait plus lieu d'être !
Il ne resterait qu'à développer sur l'arduino l'effet DIR sur les GAZ pour l'un ou l'autre des deux moteurs, à partir des commandes en provenance du récepteur.
Les signaux en sortie du récepteur semblent être du même type que ceux employés pour les servos !
Donc les servos c'est la dernière étape : mise en forme des signaux de commande des moteurs vers les régulateurs, au format "servo" !

Oui si le problème n'existait pas, il serait résolu.

Mais Positron a détecté que les deux régulateurs n'étaient pas homogènes. Peut-être est-ce simplement un problème de paramétrage, mais l'hypothèse que les deux régulateurs soient livrés dans des états différents a été considérée comme fausse.

Les signaux de sorties du récepteur montrés sont du PWM.

La plupart des servos accepte du PWM avec des contraintes particulières sur les valeurs transmises. Mais le PWM n'est pas réservé à ce seul usage : un moteur, un son, une led etc ne sont pas des servos. La surcouche Servo ne fait pas de mise en forme des signaux (c'est le travail de la sortie PWM), elle restreint les valeurs codées en PWM pour limiter les ambiguïtés. À part ajouter une couche d'abstraction, je ne vois pas ce que cela apporte dans notre cas à moins que cela aide à prendre en compte l'effet de Dir sur les Gaz ?

Salut

[henderson]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
// Front montant :
Start = micros();
// Front descendant :
gaz = micros() - Start - 500;

En termes de µs, la variable gaz contient une valeur que l'on pourrait transmettre au régulateur via un objet Servo.
En sortie on aurait une impulsion : 500 + gaz, à l'image de ce que l'on a reçu

Le problème, Guesset, n'est pas de savoir ce que l'on peut faire avec un signal PWM, quand bien même planter des petits pois !
A titre perso, au niveau de mes synthés, je fais de la modulation de symétrie sur mes formes d'ondes (LFO ou VCA ou ... ===> SYM->VCO) donc ...

Ici, ce qui compte c'est le format :

0.5 ms bord min
2 ms largeur modulable
la durée restante sur les 20ms de la période sont "laissés" au dispositif pour réagir à la commande qu'il a reçu !

[Guesset]

Bonsoir Henderson,

Le problème, Guesset, n'est pas de savoir ce que l'on peut faire avec un signal PWM, quand bien même planter des petits pois !
...Ici, ce qui compte c'est le format : 0.5 ms bord min, 2 ms largeur modulable, la durée restante sur les 20ms de la période sont "laissés" au dispositif pour réagir à la commande qu'il a reçu !

Où se trouve l'information que c'est ce que les dispositifs (les régulateurs B20 a priori) attendent ? Un format quelque il soit doit être partagé. Sinon, autant planter des petits pois

Salut

[kaitlyn]

Salut,

@positron, voici un programme de test, sans l'entrée optique, mais uniquement la sortie 9. La LED intégrée à la carte doit également clignoter. Chaque 1000ms la largeur pwm sera modifiée, 5 tranches par pas de 1.

@henderson, peux-tu le vérifier aussi avec ta carte arduino, tout au moins confirmer que ça clignote ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
//config
const unsigned analog_pin= 9; // <-> V_out
 
enum PWM_conf {
    sleep_ms= 1000,
    slice_count= 5,
    step_count= 1,
};
 
void setup() {
    pinMode(analog_pin, OUTPUT);
    pinMode(LED_BUILTIN, OUTPUT);
}
 
void loop() {
    static bool toggle;
    for (int psc= slice_count, i= -psc; i < psc; i+= step_count) {
        analogWrite(analog_pin, (psc-(i<0?-1*i:i))*255/psc); // -> V_out
        digitalWrite(LED_BUILTIN, toggle=!toggle); // -> onboard led on/off
        delay(sleep_ms);
    }
}

Où se trouve l'information que c'est ce que les dispositifs (les régulateurs B20 a priori) attendent ?

@guesset, si tu lis le manuel de l'esc, il y a 100% de chance qu'il soit écrit qu'il faut brancher son entrée sur la sortie servo/gaz du récepteur. En modélisme, c'est un standard.
Ne te fie pas à la bibliothèque arduino. Les esc et servos mesurent la durée de l'impulsion, et plus ils sont sophistiqués, plus ils sont réactifs, rapides et précis. Bien sûr, il faut que le couple radio/récepteur suive et offre un signal de qualité.
Les 20ms, ce n'est pas tant la période, mais surtout la limite au delà de laquelle on considèrera avoir perdu le signal, ce qui déclenchera des mécanismes de sécurité, l'avion tournera en rond, la voiture s'arrêtera, l'hélico fera du surplace ...

[Guesset]

Bonjour kaitlyn,

...@guesset, si tu lis le manuel de l'esc, il y a 100% de chance qu'il soit écrit qu'il faut brancher son entrée sur la sortie servo/gaz du récepteur. En modélisme, c'est un standard.
Ne te fie pas à la bibliothèque arduino. Les esc et servos mesurent la durée de l'impulsion, et plus ils sont sophistiqués, plus ils sont réactifs, rapides et précis. Bien sûr, il faut que le couple radio/récepteur suive et offre un signal de qualité...

Je te remercie de ta réponse sur les branchements qui n'ont effectivement rien d'exceptionnel ("servo/fiche JR" est seulement le type de câble), mais le sujet principal était le format. D'où vient que les B20 s'attendent à 0.5 ms bord min et 2 ms largeur modulable ?

Si c'est effectivement spécifié dans la doc cela ne me pose pas de problème, mais je ne l'ai pas vu. Et il n'y a pas de réel standard. Reste à regarder la sortie du récepteur dans les différents cas, 0% 50% et 100% pour voir s'il utilise toute la plage PWM (je pense que non, l'absence de front doit signaler un problème, ce qui serait plutôt intéressant pour le traitement Arduino).

Salut

[Positron 2]

Salut,

@positron, voici un programme de test, sans l'entrée optique, mais uniquement la sortie 9. La LED intégrée à la carte doit également clignoter. Chaque 1000ms la largeur pwm sera modifiée, 5 tranches par pas de 1.

Tout fonctionne comme prévu, la led clignote toutes les secondes et la tension en 9 va de 0 à 5 V et revient à 0V par tranche de 1 V
A plus , merci

[Positron 2]

Salut,

Dernière modification du code le 08/11/2025 à 10h17.

Avec cette version, je n'ai plus de signal en 9, pas de tension non plus !

[henderson]

Bonsoir Henderson,



Où se trouve l'information que c'est ce que les dispositifs (les régulateurs B20 a priori) attendent ? Un format quelque il soit doit être partagé. Sinon, autant planter des petits pois

Salut

Bêtement parce que ce type de dispositif fait exactement la même chose que nous : mesurer la durée de l'impulsion pour en extraire l'ordre à exécuter.
Le régulateur fixe la fréquence de son "barillet à phases" à partir de cette valeur, selon ses règles à lui et tenant compte d'une vélocité.
Cette vélocité est fixée par paramètre via la carte du régulateur : hard, normal, soft (fast, normal, slow)
L'utilisateur peut en principe choisir sur l'émetteur de travailler en mode acrobatique, normal ou débutant.
Donc passer de la vitesse actuelle à la vitesse demandée peut se faire par paliers temporels (vitesse + tempo) dont le nombre dépend de la vélocité fixée.
Le problème initial se situe très probablement à ce niveau là !

Au niveau commandes du type servo, sur arduino REV3 on est loin de la théorie :
min = 544 µs
max = 2400 µs

Sur une REV4 (que je ne connais pas, juste survolé un peu) la précision serait beaucoup plus grande.

Si les deux régulateurs étaient parfaitement appairés, le problème dans sa globalité ne serait résolu qu'une fois parvenu à appliquer DIR sur les GAZ de G ou D !
Et surtout en parvenant à transmettre l'information avec le bon format : Servo et non "full scale".
Le "full scale" est le mode opératoire pour les moteurs CC avec un pont H qui permet le hachage de la tension.
Et dans ce contexte, on peut avoir :
- un 0 continu (arrêt moteur)
- une impulsion de hachage (vitesse variable)
- un 1 continu (moteur pleine vitesse)

[henderson]

Des fois que ça pourrait être utile :

https://www.firediy.fr/article/calib...ino-drone-ch-3

[Positron 2]

Re,

Le "full scale" est le mode opératoire pour les moteurs CC avec un pont H qui permet le hachage de la tension.

Au départ, je pensais mettre des moteurs continu aussi j'ai fait rentrer deux modules BDESC-S10E-RTR mais les moteurs ne tournaient pas à la même vitesse, sur un même canal, ce n'est pas prévu pour ça, il faut une tachy et une boucle pour les maitriser, c'est comme ça que je me suis dirigé vers des Bruchless !!

[Guesset]

Bonjour Henderson,

Bêtement parce que ce type de dispositif fait exactement la même chose que nous : mesurer la durée de l'impulsion pour en extraire l'ordre à exécuter...

Ce que tu écris s'applique exactement au PWM brut sans surcouche Servo ou autres. Quand je décode le PWM entrant, je me moque de l'usage qui s'ensuivra. C'est une logique en couches, le décodage PWM est le niveau 1. Je ne vois pas pourquoi le niveau 2 serait Servo pour le régime moteur (pour la direction cela peut se discuter si la même commande doit aussi commander les gouvernes donc des servos).

...Donc passer de la vitesse actuelle à la vitesse demandée peut se faire par paliers temporels (vitesse + tempo) dont le nombre dépend de la vélocité fixée.
Le problème initial se situe très probablement à ce niveau là !

Cette hypothèse, que je partage depuis #23, suppose que les deux régulateurs sont arrivés avec des paramétrages différents.

Salut

[henderson]

L"usage d'une classe servo n'est motivé que par le seul souci de simplification.

Pour commencer : la fréquence du PWM varie d'un groupe de broches à l'autre et n'est pas fixée à 50Hz par défaut :
Sur la Uno, la fréquence est de 490Hz sur les broches 3, 9, 10 et 11 et de 980Hz sur les broches 5 et 6.
Bien !
Par contre, si on utilise la classe Servo, tout sera parfaitement réglé au moment où l'on attache un pin de sortie à l'objet servo !
On aura du 50 Hz sans avoir à faire quoi que ce soit d'autre !
Parce qu'en matière de code ... ça peut aussi devenir très compliqué si on se met à tout réinventer !

Ensuite, on peut avoir deux approches distinctes en matière de paramètres de commande au niveau servo :
soit par degré : de 0 à 180, c'est l'approche par défaut
soit par µs pour une meilleure précision.
On restera ainsi toujours dans les clous au niveau du format du signal de sortie :
500µs + modulation de 0 à 2000µs dans une période de 20ms, le signal n'excédant pas 2.5 ms !
Bref ...

Ceci peut aider aussi, mais c'est du ferroviaire :
https://www.locoduino.org/spip.php?article47

[Guesset]

Bonjour henderson,

L'usage d'une classe servo n'est motivé que par le seul souci de simplification...

C'est ce que je pressentais. C'est vrai que jouer avec les prescalers entre autres n'est pas immédiat et peut avoir des effets de bord.

Cependant, je ne comprends pas le chrono : "500µs + modulation de 0 à 2000µs dans une période de 20ms, le signal n'excédant pas 2.5 ms". Si 20 ms est la durée d'une trame PWM, chaque pas représente environ 78 µs. 2000 µs ne représente alors que 25 pas environ et une variation équivalente à 0.5V sur 5 V.

J'ai jeté un œil au lien qui est une sympathique initiation au PWM. J'ai remarqué une assertion sur la luminosité linéaire d'une LED en fonction du rapport cyclique. C'est à la fois vrai et faux. C'est vrai physiquement, mais faux physiologiquement, car notre vision n'est pas linéaire. Quand on procède linéairement comme le feu pulsant, on a la perception d'une croissance rapide de la luminosité au début puis d'un ralentissement de l'accroissement vers le max. Cela est dû au gamma de l'œil qui fait que la luminosité moyenne n'est pas à 50% mais à 18%.

Salut