Bonjour les amis,
Toujours dans le but d’expérimenter avec Arduino je me suis engagé dans un petit projet « amusant » qui comme trop souvent semble élémentaire au début et finit par vous ruiner le moral : Réaliser une maquette de bateau et le barrer automatiquement. C’est un projet relativement élémentaire qui dans sa structure de base comporte :
Un compas magnétique dont je sais lire l’orientation magnétique entre 0 et 360°.
Un Servomoteur dont je sais positionner le palonnier à ma convenance.
Un potentiomètre avec un bouton flèche que je peux orienter sur une échelle circulaire comprise entre 0 et 360° et qui définit à Arduino le CAP DÉSIRÉ.
L’idée de base est élémentaire, du moins si c’est un bateau à moteur et non un voilier qui peut se « planter face au vent ». Donc pour simplifier, je donne une consigne de CAP sur le bouton, par exemple 33°. La procédure qui utilise la boussole retourne 225°. Il suffit de faire tourner mon bateau jusqu’à ce que la route soit égale au CAP consigné. (En fait j’introduis une zone neutre pour ne pas que le moteur ne passe son temps à surcompenser, mais oublions)
MON PROBLÈME : Il m’est extrêmement facile d’imposer à la barre une déviation qui va en diminuant au fur et à mesure que l’écart de route s’amenuise.
MAIS … La logique la plus immédiate impose de faire tourner mon « navire » du coté angulaire le plus faible. JE N’ARRIVE PAS A TROUVER UN ALGORITHME qui déduit le sens de rotation (A bâbord ou à tribord) en fonction de la consigne de CAP et la ROUTE actuelle.
ATTENTION : Surtout ne répondez pas trop rapidement. Le problème semble élémentaire, mais ça fait plusieurs heures que je triture mes méninges sans parvenir à une solution … qui fonctionne dans tous les cas vous l’avez deviné.
Quékun aurait-il une idée ?
Exemples CAP 300, ROUTE 25 : Barrer à gauche.
CAP 186, ROUTE 20 : Barrer à droite etc.
Et ça doit fonctionner pour toutes les combinaisons possibles.
P.S : Si mon bateau est un voilier, pour les virements face au vent et les instabilités de route au vent arrière je me débrouillerai. ?
Chacun va pouvoir faire des nombreuses hypothèses, mais c'est d'une solution dont j'ai besoin.
Il faut prendre un crayon, un papier, une bonne dose de patience et scibouiller des idées. Puis, avec un jeu d'essai bien fourni on teste "tous les cas". Quand on pense avoir trouvé, on "crie VICTOIRE", mais attention, il y a des combinaisons "redoutables" auxquelles nous n'avons pas pensé. GRRRRRR !
Passer de -180° à +180° ne change pas le problème, car les soustractions donnent en relatif des écarts équivalents avec les mêmes problèmes de frontière.
J'ai exploré entre autre les 32 possibilités de quadrans pour le CAP et la ROUTE, il y a à chaque fois des combinaisons qui ne sont pas bonnes.
Bref, c'est assez GNARF GNARF GNARF comme problème élémentaire.
..:
c'est une autre façon de calculer le modulo de deux nombres ...
Oui, disons que c'est une écriture plus « microcontrolleur-friendly ».
Ceci dit je pense qu'une implémentation «naïve» de ta formule serait erronée (en supposant que les symboles [ et ] signifie "valeur absolue") : elle renverra le même résultat pour (Cap=300, Route=25) et (Cap=25, Route=300)
@deux-petits-points :
Mmmm, oui, mais si mes souvenirs sont corrects en C le signe d'un modulo est celui du dividende. Du coup tu as toujours le problème du cas où Route > Cap, non ?
..:
sinon, ta formulation est parfaitement correcte et fonctionne de plus avec des entiers non signés, ce qui la rend totalement efficace et universelle (bien choisir la taille des entiers, néanmoins, uint16_t minimum)
Oui c'est ce que je voulais dire plus haut en parlant d'implémentation "naïve" de ta formule : bien qu'elle soit mathématiquement correcte, sa transposition en code C "telle quelle" comporte de nombreuses chausse-trappes pas toujours faciles à identifier.
De toute façon je n'aime pas utiliser les modulo, en particulier avec des valeurs signées : les implémentations varient d'un langage à l'autre et c'est toujours la croix et la bannière pour y retrouver ses petits
Bonsoir,
Moi aussi ça me semblait élémentaire. Pour un projet similaire et plus facile car sur le plancher des vaches: (une double brosse vibrante guidée aussi en suivant un compas )
La gestion du cap dans la zone du zéro m'a pas mal occupé, je voulais une formule universelle sur les 360°.
J'en ai été réduit à me contenter d'un cap virtuel lorsqu'on approche du zéro ou de 360, ( si la route est entre 270° et 90° alors on ajoute 180, puis modulo, au cap et à la route). Ainsi on compare facilement pour rectifier à gauche ou à droite, car on est loin de la frontière 360/0.
ça marche bien si la route suivie ne s'éloigne pas trop du cap. Mais n'est guère satisfaisant si la route est loin du cap, au-delà de 120° d'écart par exemple, l'un des 2 (même virtuel) peut s'approcher de la frontière! (et là, ça craint pour la comparaison! ). Dans le cas d'un voilier les écarts peuvent être brutaux et importants, (bascule du vent, risée, houle,...) et là ça impose encore une gestion particulière pour remettre la route dans la zone du cap.
Enfin, pour moi aussi, si formule universelle et magique il existe, ça m'intéresse!
nulentout:
… La logique la plus immédiate impose de faire tourner mon « navire » du coté angulaire le plus faible.
Si c'est un voilier devant franchir le lit du vent pour corriger sa route, l'angle le plus petit n'est pas toujours la meilleure solution.
Est-ce un quillard? un catamaran? le premier aime bien virer face au vent, le second lof pour lof, chacun y gardant la meilleure motricité.
PS: Un retour du cap et de la route, en direct, rend bien des services pour la mise au point.
Bonjour les amis,
Hé bé, il en a engendré une conversation mon post !
Je vais tenter de répondre aux messages les plus significatifs, ce qui ne veut pas placer pour autant les autres dans le chapitre des inutiles. Tous sont des pistes de réflexion ... Merci à vous.
Mon quatrième message semble ne pas tenir compte de celui qui précède. (Celui de Newbie) C’est le hasard du chronomètre : Quand j’ai rédigé mon texte, son post c’est intercalé … il m’a coifé sur le poteau.
J’avais bien pensé à une solution de ce genre, mais les frontières « agassives » comme 180° ou 0°/360° veillent en permanence pour venir bousculer les formules simples.
« Je n'ai aucun besoin d'explorer 32 quadrants (qui ne peuvent exister qu'au nombre de quatre, soit dit en passant) … »
Oui, merci, mais je m’en doutais un peu !
Quand je précise que j’ai exploré les 32 quadrants, j’aurais dû écrire : Quand j’ai exploré une combinatoire de 32 cas relatifs à la position du CAP et de la ROUTE sur les quatre quadrants de la rose des vents, ma phrase aurait été certainement plus précise. Comme quoi souvent c’est la forme qui devient plus importante que le fond.
Reste qu’explorer cette combinatoire n’est pas suffisant puisqu’il faut aussi vérifier la compatibilité de l’algorithme développé avec les frontières qui souvent constituent des cas particuliers épineux.
« je me contente d'un peu d'arithmétique de base ... ce qui devrait être à la portée de quelqu'un qui parle aussi bien des fréquences de battement ».
Par cette phrase ton propos devient franchement discourtois, tu n’en sortiras pas grandi !
Pour ce qui est des fréquences de battement, mes propos ne sont pas que livresques, vous pouvez faire confiance à mon verbiage. J’ai réalisé ma première station radio à 20 ans et j’ai titillé les ondes courtes durant 40 ans. (De façon légale, je suis radioamateur) Alors les problèmes d’harmoniques ont été un souci permanent … je me suis réalisé ondemètre à absorption, un grid-dip ou un TOSmètre calibrateur à quartz, oscilloscope ...
Une réponse plus « opérationnelle aurait été :
Tiens, teste cette séquence que j’ai expérimentée sur mon Arduino et qui semble donner satisfaction …
haifger, effectivement ta formulation est « naturelle », c’est la première à laquelle j’ai cru naïvement. Mais déjà CAP-ROUTE peut devenir négatif alors que l’écart angulaire est faible. Si je Positive en inversant le calcul, je trouve bien l’amplitude de l’écart, mais le résultat ne permet pas de déduire de quel coté se trouve le plus court chemin. Les cas critiques sont Plein Nord avec deux valeurs renvoyés par la boussole, plein SUD pour certains calculs, les frontières quand on procède par zones, par exemple par l’analyse combinatoire des quadrants …
Carolyne, Non, aucun problème avec les angles. Que ce soit la boussole (Mon capteur magnétique), le potentiomètre ou le pilotage du servomoteur, de la zone neutre, de la compensation en dérive, dans tous les cas je manipule des entiers ramenés entre 0 et 360. (Au passage on voit que pour le plein NORD on a deux valeurs qui se superposent donc deux cas à prendre en compte)
papybricol
Le fait que dans mon hypothèse la maquette pilotée sera un voilier complique considérablement le traitement. Quillard ou catamaran ne modifie pas fondamentalement la donne, sauf éventuellement pour le portant où le catamaran sera plus stable sur sa route. Mais la faible inertie d’une maquette ne lui permet pas de passer le vent, surtout si ce dernier est faible et qu’elle se déplace lentement. Si sur le plan d’eau il y a du clapot et qu’en outre les changements de vent deviennent importants en direction ou en grandeur, barrer devient « joyeux ».
Ceci dit, je vais botter en touche pour cet l’aspect « face au vent » des choses, car il faudrait que je munisse mon bricolage d’une girouette … et dans ce cas je perdrais la notion de « petit projet ». Comme j’ai encore d’autres technologies à expérimenter, je ne désire pas y passer des semaines. Pour résoudre ce problème, un inverseur me permet de passer en pilotage manuel, car dans tous les cas un humain doit toujours pouvoir prendre la main sur un automatisme.
papybricol
« PS: Un retour du cap et de la route, en direct, rend bien des services pour la mise au point. »
Si tu fais allusion à la possibilité de lister en permanence les paramètres vitaux sur la ligne série USB, c’est chez moi un pléonasme. Par contre, comme la ligne série ralentit dramatiquement la boucle de base (Main loop) j’ai souvent un inverseur ou un B.P. que j’utilise pour valider ou non le listage.
OUFFFFFF ?
Perso j'avais même trouvé une autre solution qui fonctionnait, mais au final c'est un poil plus chargé que celle de Haifger (j'ai testé sur papier car j'y croyait pas et ça marche) donc inutile
Par contre juste une parenthèse : je vois pas trop (sur le plan mathématique j'entends) ce que viens fiare le modulo dans l'histoire ? Sur wikipedia j'ai quand même appri sdes truc au passage puisque basiquement pour moi modulo pas c'était modulo, le reste d'une division euclidienne. Mais faut croire que non mais j'ai quand même pas vu la relation en trigo et modulo
nulentout:
haifger, effectivement ta formulation est « naturelle », c’est la première à laquelle j’ai cru naïvement. Mais déjà CAP-ROUTE peut devenir négatif alors que l’écart angulaire est faible. Si je Positive en inversant le calcul, je trouve bien l’amplitude de l’écart, mais le résultat ne permet pas de déduire de quel coté se trouve le plus court chemin.
Non, si tu regarde bien ma proposition, (CAP-ROUTE) ne peux jamais être négatif. C'est le but des deux premières lignes du pseudo-code :
Si Cap < Route
Cap += 360
Si (Cap - Route) > 180 :
barre à gauche
Sinon
barre à droite
nulentout:
Les cas critiques sont Plein Nord avec deux valeurs renvoyés par la boussole, plein SUD pour certains calculs, les frontières quand on procède par zones, par exemple par l’analyse combinatoire des quadrants …
Ça c'est une erreur de ta part dans le traitement des données de la boussole. J'avais bien précisé que ma proposition était valide pour 0 <= (Cap, Route) < 360, c'est-à-dire 0 inclus mais 360 exclus. Si ta boussole peut renvoyer deux valeurs différentes pour un même CAP, tu dois pré-traiter ces données avant de les injecter dans « l'algorithme ».
Pour faire simple, Modulo, c'est le reste d'une division.
Exemple Modulo (13:4) = 1.
Avec les entiers c'est "simple", mais si l'on commence à prendre des réels, codés en binaire avec un compilateur spécifique, autant dire que la journée commence mal !
Je ne crois pas que cette fonction existe en C, c'est dommage car elle me serait bien utile de temps en temps.
On peut toujours coder avec une formule qui calcule ce reste, il suffit d'enlever au nombre de départ la partie entière de sa division multipliée par le divideur (Et oui ) mais avec le piège des nombres signés et non signés dans le langage d’Arduino qui accepte de mélanger joyeusement tout ça, j’ai été confronté à pas mal de surprises dans ce domaine.
nulentout:
Pour faire simple, Modulo, c'est le reste d'une division.
Exemple Modulo (13:4) = 1.
Avec les entiers c'est "simple", mais si l'on commence à prendre des réels, codés en binaire avec un compilateur spécifique, autant dire que la journée commence mal !
Je ne crois pas que cette fonction existe en C, c'est dommage car elle me serait bien utile de temps en temps.
Cette fonction existe et s'appelle fmod(). Elle prend à elle seule 336 octets de mémoire programme...
pour le modulo oui j'ai bien compris et je savais ce que c'était. Ce que je ne comprend pas, et je le redis, c'est sur le plan mathématique appliqué à ce problème. Puisque qu'un cap ne peut être supérieur à 360, le modulo d'une une différence de deux cap renverra simplement la différence de ces deux angles puisque le dividende est forcement inferieur ou égale au diviseur. Schématisé :
Je précise encore une fois qu'ici que ma question ne porte pas sur l'application en prog de modulo, mais son application mathématique dans le problème. Je ne vois pas en quoi le reste d'une division résout le problème
B@tto:
pour le modulo oui j'ai bien compris et je savais ce que c'était. Ce que je ne comprend pas, et je le redis, c'est sur le plan mathématique appliqué à ce problème. Puisque qu'un cap ne peut être supérieur à 360, le modulo d'une une différence de deux cap renverra simplement la différence de ces deux angles puisque le dividende est forcement inferieur ou égale au diviseur. Schématisé :
Je précise encore une fois qu'ici que ma question ne porte pas sur l'application en prog de modulo, mais son application mathématique dans le problème. Je ne vois pas en quoi le reste d'une division résout le problème
C'est une question d'implémentation du modulo en fait. Ta remarque fonctionne en C(99) parce que dans ce langage le signe du résultat est celui du dividende.
En Python par exemple, où le signe du résultat de modulo est le signe du diviseur, on obtient des résultats du genre :
(25 - 300) % 360 = (-275) % 360 = 85
Et là ton égalité ne tient plus.
C'est ce qui me faisait dire qu'une implémentation "naïve" de la proposition de @deux-petits-points ne fonctionnerait pas, alors qu'elle fonctionne à tous les coups en Python (par exemple).
Bonjour les Amis,
"je me contente d'un peu d'arithmétique de base ... ce qui devrait être à la portée de quelqu'un qui parle aussi bien des fréquences de battement"
J'ai franchement du mal à y voir un compliment, mais ce n'est qu'un incident d'interprétation.
Oublions, c'est sans importance ... Le bénéfice du doute doit prévaloir.
Dans tout ce qui précède, il y a beaucoup de détails que je n'ai pas encore eu le loisir de tester. Quoi qu'il en soit, je vous tiendrais au courant, mais quand j'aurais abouti, c'est à dire que ça fonctionnera sur Arduino.
Pour la fonction Modulo j'ai également trouvé l'opérateur % qui semble fonctionner, mais je ne l'ai testé que sur des cas simples.
Pour ce qui est du coté où il faut tourner, sur le papier j'ai une solution qui semble acceptable. Elle n'implique que huit test et résulte d'une analyse combinatoire sur les quadrants. Je vais donc la vérifier sur Arduino, car souvent quand on code, ça "décode !".
Bien entendu, je vais également tester les solutions proposées ci-avant, car si certaines fonctionnent, elles seront plus élégantes que huit tests en cascade.
Oui, le fait d'un 360° et un 0° sont retournés par la boussole pour un même CAP n'est absolument pas une difficulté, je l'ai cité comme exemple de cas de "frontière" qui engendre une particularité. Mais son opposé de 180° présente également des surprises pour certains traitements que j'avais envisagés et testés.
mais j'ai quand même pas vu la relation en trigo et modulo