Démo d'avancement du goto prédictif...
L'ATmega2560 de la MKS MINI au taquet...
Interprétation de la mesure à l’analyseur logique:
Le code exécuté dans l’interruption en elle même prend 3,375us (remise à zéro du compteur du timer comprise) avec une périodicité d’à peine 8us soit plus de 123 000 impulsions par seconde!!! On arrive ici à la limite extrême en se limitant à un seul moteur. En prenant un peu de marge cela signifie qu’en déplacement bi moteurs (A.D. et déclinaison en simultané) pour du goto on peut sans complexe espérer atteindre les 50Khz avec encore un peu de temps CPU pour le reste du programme.
Pour atteindre de telles performances, le code des interruptions moteur a été réduit à sa plus simple expression (comptage de pas + envoi impulsion moteur). Toutes les fonctions d’écriture -digitalWrite()- ont été optimisées avec l’excellente librairie Arduino-GPIO. Enfin, la gestion des accélérations/décélérations, changement de direction, activation/désactivation moteur, ont été dévolues à un timer dédié servant de « modulateur de fréquence » comme le montre cette capture...
Les avantages:
- Le fonctionnement des moteurs à vitesse constante est très peu gourmand en temps processeur.
- Cela ouvre la porte pour faire sans souci du goto en microstepping 1/16 là où d’autres projets sont contraints de basculer à la volée en 1/2 pas voire même en fullstep pour tenir la cadence.
- L’intégration du rattrapage de jeu et la correction d’erreur périodique pourront se faire au niveau du timer d’accélération sans impacter les performances des interruptions moteur.
Démo gestion des moteurs pas à pas du télescope
https://www.youtube.com/watch?v=dwV1hC2yCYI
Le résultat est sans appel en terme de performances mais aussi de simplicité de code. L’ajout du rattrapage de jeu et la modulation de fréquence pour la correction d’erreur périodique devrait être une partie de plaisir par la suite. :)
Dans l’immédiat, je travaille maintenant sur le goto car j’en ai besoin pour d’autres projets. Mon idée serait de ne pas compter les pas à la volée en regardant si on est pas trop loin mais plutôt de créer un modèle mathématique permettant de déterminer le temps de déplacement nécessaire à la milliseconde près pour chaque axe. L’idée est séduisante sur le papier mais dans les faits cela demande beaucoup de précision.
Affaire à suivre...
Contrôle de l'accélération et estimation des pas pour le goto
Reprenons l’exemple d’une accélération comme celle que j’utilise pour ma monture...
Dans la réalité, pour obtenir un tel résultat, je dois progressivement augmenter la fréquence des pas moteur de 0 à 100% de la vitesse souhaitée. Le graphique ci-dessous montre des paliers de 0.1s d’accélération pour passer de 0 à 400Hz (vitesse solaire de ma monture avec micro stepping de 1/16) en 2 secondes.
Astuce: Après avoir étudié la question, j’ai fait le choix sur Arduino d’utiliser le Timer 0 pour gérer les accélérations/décélérations/inversions de mes moteurs. Il faut savoir que ce timer matériel est notamment utilisé par les fonctions delay(), millis() et micros() sur Arduino. On peut néanmoins l’utiliser pour peu de ne pas modifier sa fréquence (calée à 1ms ) en le programmant pour lever une seconde interruption sur la même base de temps...
// Timer0 is already used for millis() - we'll just interrupt somewhere
// in the middle and call the "Compare A" function below
OCRA = 0xAF;
TIMSK |= _BV(OCIE0A);
Le nombre de timers matériels étant très limités sur une carte Arduino (seulement 4 timers sur Uno et 6 timers sur les cartes MEGA) c’est donc un luxe non négligeable de ne pas en monopoliser un juste pour le timing des variations de vitesse. Sur ma MKS MINI, il me reste donc 5 timers matériels soit la possibilité de piloter les 4 drivers de moteur pas à pas avec une grande précision.
A la fin de mon accélération, j’aurais donc théoriquement parcouru la somme des pas des paliers de mon graphique soit... 201 pas. Et le goto dans tout cela? Et bien le comptage de pas c’est la base bien sûr car comme dans la vie: pour savoir où l’on va, il faut savoir d’où l’on vient! -je suis d’humeur littéraire aujourd’hui. Profitez, c’est cadeau.- On peut donc évaluer de façon assez précise, au niveau logiciel, le temps nécessaire pour atteindre un point donné et s’épargner l’achat de couteux encodeurs de position.
Aujourd'hui c'est optimisation...
Et bien oui mais non. Il n’y a pas que la puissance qui compte. Un Arduino ne fait pas grand chose mais il le fait bien. C’est un véritable environnement temps réel. Bien maîtrisé, il est capable de piloter des entrées/sorties avec une régularité et une finesse que n’atteindra jamais un puissant PC qui lui est certes très performant mais qui doit faire beaucoup de choses à la fois (sans même qu’on le sache).
Dans le cadre de moteurs pas à pas par exemple, la régularité est primordiale. La capture ci-dessous montre les pulsations de chaque pas moteur en ascension droite et déclinaison sur mon projet. La précision obtenue est supérieure à la micro seconde.
Voilà c’était la pensée du jour. Je retourne à mon optimisation de code pour grappiller de précieux cycles d’horloge. Au passage, si vous codez sur Arduino de manière un peu avancée, je vous recommande de tester l’excellente librairie Arduino-GPIO de Mikael Patel: https://github.com/mikaelpatel/Arduino-GPIO. Elle permet de remplacer notamment les fonctions digitalRead() et digitalWrite() de la librairie Arduino par des accès hyper optimisés.
Saturne et Mars au CN-212
CN-212 à F/D 12,4 + Barlow 2x + 5D MKIII. Shoot en mode vidéo RAW Magic Lantern et zoom 3x. Traitement avec MLVToMovie, AS2 et Registax 6.
D’ailleurs pour rappel, si vous êtes sur Mac, sachez que j’ai mis à dispo des versions Mac d’AS2, Registax 6 et même Iris...
http://mlvtomov.eliotis.com/goodies/index.html
MKS MINI sous les étoiles
Aperçu de la courbe d’accélération de type sinusoïdale...
Comme le montre le graphique, on obtient un démarrage et un arrêt très doux offrant un bon amortissement de l’inertie du télescope. Pour plus d’infos, voir cet ancien billet: Accélération/décélération: Sinus or not Sinus?
MKS MINI aux commandes...
https://www.youtube.com/watch?v=ckrY5U3mfkkLe projet a bien évolué depuis ses débuts. Simplifions, simplifions, simplifions! Reste à intégrer une led d’éclairage pour le viseur polaire, prévoir une connectique pour le câble de la motorisation de la mise au point et ajouter la deuxième connectique DB-9 pour la future télécommande tactile. A partir de là on sera pas mal niveau matériel côté monture.
Test motorisation mise au point du CN-212
Motorisation de la molette de mise au point du CN-212
- ne pas toucher au tube: le système ne doit nécessiter aucun perçage.
- facile à monter/démonter en quelques secondes et sans outils dans le noir en cas de besoin.
- on doit pouvoir continuer à utiliser la molette en manuel.
- cela ne doit pas dénaturer le télescope. :)
On mélange tout ça avec OpenSCAD et -quelques prototypes plus tard- abracadabra...
Le concept est simple. La platine est solidarisée via le porte oculaire. Et un manchon, ajouré pour accueillir l’axe moteur, vient s’enficher sur la molette de mise au point.
Le tour est joué...
Voilà qui devrait être parfait pour boucler la boucle en complément du contrôle de la monture.
C'est reparti... :)
Donc on récapitule:
- revoir l’électronique de la monture pour qu’elle soit plus simple à concevoir et pourquoi pas encore moins chère?
- déporter l’écran dans une raquette déportée.
- prévoir de piloter la mise au point.
Ok on en est donc là ou presque puisque j’ai déjà avancé sur la question vous vous en doutez. :) Concernant l’électronique, je pense avoir trouvé mon bonheur avec une carte pour imprimante 3D que je vais hacker pour mon usage: la MKS Mini V2.0 Makerbase.
Elle a tout pour me plaire:
- basée sur un Arduino MEGA dans la continuité de mon projet.
- dimensions relativement compactes.
- 4 drivers 4988 afin de piloter à la fois les deux moteurs pas à pas du télescope et potentiellement deux autres périphériques.
- technologie éprouvée puisque dérivée de la Mks standard équipant nombre d’imprimantes 3D DIY.
- tout petit prix: à peine plus de 20€ avec les frais de port sur aliexpress.com.
Il n’en fallait pas plus pour me lancer sur cette piste!
Je vous présente donc mon nouveau prototype déjà installé en bonne place sur ma monture (merci l’impression 3D)... :)
La manette SEGA a été conservée et j’ai prévu un second port DB9 pour la raquette de contrôle qui exploitera l’ancienne carte Arduino équipée de l’écran tactile. Ce dernier s’occupera de l’intelligence (base de donnée, GPS, GOTO, abaque polaire) et la carte Mks s’occupera des moteurs et du PEC.
Carte postale étoilée depuis le col de Gleize
Platine d'adaptation EM10/trépied Meade
A partir de là, le modèle 3D a été réalisé par mes soins sous OpenSCAD en prenant les cotations au pied à coulisse sur la monture et le trépied…
Puis la fabrication a été laissée au bon soin d’un ami disposant d’une imprimante 3D (25h d’impression tout de même! Merci Richard! :) )…
Avancement de l’impression...
Et voici la platine finale mise en place sur le trépied Meade...
Installation de la monture: comme papa dans maman… :)
Pas de doute, ça a de la gueule… :)
Reste à prévoir la tige filetée de remplacement de l’écarteur d’origine. Elle viendra solidariser la monture avec le trépied en passant par le trou central du dessous.
Si cette platine vous intéresse, j’ai mis le STL à disposition sur thingiverse.com…
>>>> Adapter for Takahashi Mount with Meade Field Tripod <<<<
Un nouveau pied, c'est le pied!
Merci au passage à mon copain Fabrice qui m’en a fait cadeau! Un trépied massif flambant neuf dans son emballage cela ne se refuse pas! :D
Premier ciel pour l'EM-10 Arduino Takahashi
Mise en place des moteurs au fond du logement de la monture...
Le prototype à l’oeuvre sous les étoiles...
Le bon vieux CN-212 semble apprécier son nouvel habit lumière… ;)
En prime une vidéo de démonstration…
https://www.youtube.com/watch?v=LHpEZYp4NEY
La monture prend vie...
Voici les premières captures officielles…
Et une mini vidéo…
https://www.youtube.com/watch?v=h8L5rXhS2R0
La maquette de travail ressemble à ceci...
Avancée du cablage du proto V1...
- perçage de quelques trous dans le support afin de passer des serre-câbles et fixer le câble de la manette.
- fixation du Arduino avec des visseries qui vont bien.
- coup de cutter sur l’Arduino Mega afin de couper la liaison vers le polyfuse (alimentation 5v) de l’entrée USB.
- repiquage de l’alimentation 5v sur le régulateur UBEC du circuit de puissance.
- câblage d’un interrupteur marche/arrêt.
Pour le proto, je préfère garder un cordon d’alimentation et le repiquer sur le régulateur 5v plutôt que de câbler le arduino directement dessus. Je peux ainsi travailler sur le Arduino en le branchant à une simple alim 5v (vu qu’il n’y a plus d’alimentation par USB) sans alimenter les moteurs lorsque ce n’est pas nécessaire aux développements.
Installation d'un Arduino Mega et d'un LCD
Sega c'est plus fort que Taka...
Pour les amateurs du genre, le code est dispo sur mon github. Plus de détails ici…
L'analyseur de précision de moteur pas à pas est au taquet!
A titre d’illustration, voici les graphiques X/Y de l’évolution de la position de l’étoile noire centrale (cerclée en rouge dans l’analyseur) sur une période de rotation complète de la mire…
L’effet de sinusoïde est ici tout simplement lié au fait que mon « étoile noire » n’est pas parfaitement centrée sur l’axe moteur. Lors d’une rotation complète, elle oscille donc en horizontale et verticale car elle tourne autour de l’axe avec une amplitude max de l’ordre de 3,5 pixels si on ne prend pas en compte la dérive (le pied photo qui se tasse légèrement notamment en vertical sur le second graph). 3,5 pixels, c’est ridicule me direz vous et cela donne un très bon ordre de grandeur de la précision atteinte. On peut estimer le bruit résiduel à environ 0,05 pixel à peine!
Une fois toutes les positions des mires précisément analysées sur un peu plus d’une période, l’idée est d’analyser la variation de la position angulaire des mires externes par rapport à la vitesse de référence théorique (25Hz soit en sortie d’axe moteur 0,75° de déplacement chaque seconde). Et voici le résultat brute pour mon moteur…
Erratique? Pas tant que cela et même loin s’en faut. Pour s’en convaincre, exportons les données vers l’analyseur d’erreur périodique PECPrep…
Et là: magie du spectacle. L’analyse de fréquence détecte et supprime toutes les fréquences. L’erreur résiduelle relève de l’encéphalogramme plat… :)
Notre signal mesuré est donc parfaitement reproductible. Cerise sur le gâteau, reprenons la table d’engrenages que j’avais calculé il y a quelques semaines…
En y regardant de plus près, presque toutes les fréquences proposées par PECPrep sont clairement identifiables à la seconde près par rapport à ma table…
Voilà qui valide on ne peut mieux le concept de l’analyseur!
Dans les faits, l’analyseur va être un outil particulièrement précieux pour la mise au point de l’algorithme de correction d’erreur périodique avec le Arduino. Je pourrais ainsi contrôler la qualité du correcteur sur des données réelles sans sortir de chez moi. :D
Idéalement, il serait même intéressant de pouvoir faire cela en temps réel et non sur une séquence vidéo enregistrée. A méditer pour les prochaines nuits blanches…
Dans le colimateur de l'analyseur...
Encore quelques détails à améliorer mais cela valide l’analyseur de précision. Le concept fonctionne pas mal. Dommage que le 5D Mk III monte très vite en température et génère un bruit de lecture marqué même à 100Iso. Cela limite la précision des mesures. Avec une vraie CCD le principe deviendrait redoutable.
L'analyseur de moteur pas à pas livre ses premiers chiffres...
- Période de rotation de la sortie moteur: 7,98min (7min 59s) soit 9,98min/dent au niveau de la vis roue dentée de 144 dents)
- Fréquence des pas moteur: 25,063Hz en Fullstep.
- Vitesse angulaire du télescope (tenant compte de la démultiplication supplémentaire de 0,8 et de la roue dentée de 144 dents): 15,04’’/s.
Conclusion rapide: ça cartonne! La vitesse sidérale est quasi parfaite.
Seule ombre au tableau pour le banc d’essai, les vibrations du moteur viennent noyer la précision de mesure sidérale instantanée…
Ce qui me fait dire que ce n’est pas du bruit lié à l’analyse c’est que, quand on y regarde de plus près, ce fameux « bruit » est identique pour chacune des 4 mires périphériques. Je pense que le passage en micropas 1/16 avec la nouvelle électronique devrait solutionner cette incertitude.
Chose intéressante tout de même, le repère centrale rouge semble moins impacté. Du fait de son léger décentrage, ses positions x/y génèrent une légère sinusoïde qui semble laisser entrevoir les « crans » d’une sous période...
Avec un peu de chance, il s’agit de la fameuse sous période d’environ 1,28m que j’ai imputé à l’engrenage 4 de la démultiplication.
Enquête à suivre.
Ebauche d'analyseur de précision de moteur pas à pas
Le moteur et sa mire sont mis en place sur un meuble avec un éclairage…
Dans l’axe à quelques mètres, je mets l’appareil photo en mode vidéo RAW sous Magic Lantern. Je réalise une vidéo sur un peu plus d’un tour complet d’engrenage (période de 8min dans mon cas).
La vidéo RAW MLV est ensuite transférée sur le Mac et convertie en mov sans perte avec le logiciel MLVToMovie que j’ai codé il y a quelques temps pour faire de l’imagerie planétaire.
Reste à analyser la vidéo. J’ai travaillé aujourd’hui sur le suivi des « étoiles noires «. - Ouha!!! Ca claque dit comme ça!!! :D - Il reste à extrapoler les données pour déterminer la vitesse de rotation à un instant t.
L’ébauche du logiciel en action avec incrustation en « presque » réalité augmentée…
La suite au prochain épisode. Je vais faire dormir un peu les neurones pour ce soir.
Platine de test de précision de moteur pas à pas
Voici le résultat...
Le concept est totalement inspiré d’une expérience menée par DBlatte (Christophe), pour caractériser la précision de ses moteurs pas à pas, et présentée sur le forum d’astrosurf…
De la précision des moteurs pas à pas
Reste à y coller une mire d’étoiles, mettre en place un setup de prise de vue et le traitement des données qui va bien derrière. :)
Accélération/décélération: Sinus or not Sinus?
Soit t un nombre réel compris entre [0,1] représentant le temps d’accélération.
La réponse f(t) est un nombre réel compris entre [0,1] qui représente la vitesse du moteur en pourcentage.
Le graphique ci-après montre:
- Une accélération linéaire.
- Une accélération sinusoïdale parfaite.
- Une accélération sinusoïdale partielle.
La vitesse par accélération linéaire vaut:
f(t) = t
C’est la forme la plus simple. L’accélération est une simple fonction linéaire sur toute la plage. L’accélération est donc constante…
La vitesse par accélération sinusoïdale complète vaut:
f(t) = (sin(t*pi-pi*0.5)+1)*0.5
L’accélération est douce au départ, maximale en 0,5 et vient se radoucir sur la fin...
La vitesse par accélération sinusoïdale partielle vaut:
f(t) = sin(((2*t+1)*pi-pi)*0.25)
L’accélération est maximale au départ et vient se radoucir ensuite...
L’idéal va être des les mettre en oeuvre sur le terrain pour voir le ressenti en terme de confort d’utilisation.