En fait de lunette astronomique, j’ai réalisé des adaptations en impression 3D me permettant d’y loger une barlow Powermate 3x et 5x...

https://www.thingiverse.com/thing:4562984

Le téléobjectif est lui même fixé via une embase d’adaptation (impression 3D en PETG) entre l’EM-10 et le collier pas Kodak...

Dès lors on dispose d’assez de tirage pour y monter oculaire et renvoi coudé. Il est également possible de faire de l’imagerie planétaire grâce à une focale résultante de respectivement 1200mm et 2000mm de focale. Et voici le résultat avec une AZI 290MC...

L’imagerie Lunaire n’est pas en reste avec la possibilité de réaliser des mosaïques intéressantes...

>>>Version plus grande ici<<<

L’imagerie en ciel profond reste tout aussi accessible directement au foyer via un adaptateur ASI/Canon créé sur mesure là aussi en impression 3D...

https://www.thingiverse.com/thing:4307480


>>>Version plus grande ici<<<

Et pour finir Neowise, avec en lieu et place de l’ASI, mon Canon 5D MkIII pour un plus grand champ photographique...

>>>Version plus grande ici<<<

Bref, de quoi se faire plaisir de 400mm à 2000mm de focale. :)

CN-212 F/12,4 / ASI290MC

Le rapprochement Vénus/Pléiades était mignon aussi...

>>>Version plus grande ici<<<
Canon 5D MkIII + Canon EF 400mm F/5,6

Prenez soin de vous et de vos proches. <3

Encore quelques finitions et ce piMac aura tout d’un grand! ;)

Installation de la caméra PI V2 8mp...

Pied bombé couleur alu...

Ecran tactile 7’’...

Toute ressemblance avec un iMac blanc des années 2000 serait bien évidement une totale non coïncidence. En atteste cette photo de famille... ;)

De là à en faire également une machine pour retrogamin(g) sous Recalbox, c’est tentant aussi... :D

Si le concept vous plait, les fichiers 3D sont disponibles sur mon thingiverse...
http://www.thingiverse.com/thing:3743598

La boussole de Safari et son aiguille me plait bien...

Je mélange le tout sous Sketch avec un soupçon de touche perso. Et voilà... :)

• Il sera très facile de limiter le champs de recherche des segments en bornant simplement les requêtes SQL sur leur longueur.
• Aucune conversion supplémentaire nécessaire afin de respecter des rapports d'échelle pour comparer les distances entre les étoiles.

- Mon EM-10 USD II de 1998 à côté de ma nouvelle flambant vieille EM-200b de 1991. -

Surtout si ma dernière version de boitier a été pensée d’entrée pour être compatible au millimètre près... ;)

La motorisation poussive de l’EM-200b devra être revue mais cela aussi est à l’ordre du jour très prochainement sur l’EM-10.

Le temps était clair mais trop turbulent pour shooter la Lune. J’en ai donc profité pour prendre quelques échantillons de test pour mon algorithme de détection d’image et comparer quelques images avec ma base de donnée. :)

Je suis parti sur une couverture de 20° de rayon autour du pôle céleste. Et pour un précision optimale, j’ai pris en compte au niveau des étoiles: leur dérive annuelle, la précession des équinoxes, la nutation et l'aberration annuelle. Aperçu en vidéo...
https://youtu.be/tSQcC8lHJrI

Lors d'une rotation de 90° les points de référence tournent en rond autour de l'axe mécanique d'ascension droite (l'axe qu'on aligne avec le pôle nord céleste). Si l'on trace la médiatrice de chaque segment, l'intersection des médiatrices nous montre le point de rotation. Ici on constate qu'il est un peu plus haut que le centre du capteur.

CQFD.

Plus sérieusement, j’avance sur le pilotage de la caméra du Raspberry PI. Il existe bien le projet picamera en Python mais je souhaite quelque chose de plus performant, que ce soit au niveau des ressources CPU que mémoire, afin de tourner correctement à terme sur un PI Zéro. C’est donc le C/C++ que je privilégie. Et là les choses se gâtent sous Raspbian. Par exemple, la librairie de traitement d’image OpenCV propose bien le support de la cam mais uniquement en flux vidéo automatisé. A noter qu’il est possible de modifier certains paramètres via la méthode set (ex: CV_CAP_PROP_SATURATION) de la classe VideoCapture. Elle fait appel au driver V4L mais dans les faits c’est très limité. Impossible par exemple de régler l’exposition de ma caméra: « HIGHGUI ERROR: V4L: Property Exposure(15) not supported by device) ». Hors dans mon cas, il est nécessaire d’accéder à l’ensemble des pixels de l’image (mode « still ») avec une gestion manuelle de la caméra (exposition, balance des blancs, réglage du gain analogique, etc). Bref, pour arriver à mes fins, je suis donc contraint de coder une version modifiée à ma sauce de raspistillyuv.

Niveau IDE de développement il n’y a pas grand chose de potable à mon goût. J’ai donc décidé de faire comme sur Arduino et d’utiliser l’IDE Xcode sur mon Mac pour avoir un éditeur digne de ce nom (code completion, refactoring, recherches avancées, etc). La mise en oeuvre est un peu plus complexe car cela nécessite de mettre en place des scripts de compilation à distance via un canal SSH mais ça y est ça tourne... :)

Cerise sur le gâteau: XQuartz me permet d’avoir la fenêtre de l’application PI directement sur le Mac (le code s’exécute sur le PI mais l’interface graphique est déportée sur le PC). Je peux maintenant coder sur mon PI avec un minimum de confort! :)

Ma modélisation est dérivée du modèle de mynameishamish sur thingiverse et modifiée afin de pouvoir fixer le boitier à la monture...

Le prototype est maintenant opérationnel pour le développement logiciel. :)

Just A Rather Very Intelligent System... 🤪
Tony Stark: "Jarvis, where's my flight power?!"
Jarvis: "Working on It, sir. This is a prototype."

Le concept serait donc d’utiliser une caméra PI, un objectif CS et un Raspberry PI Zéro embarqué dans le corps de l’EM-10. Le tout pour un budget autour des 40€ d’après mes dernières estimations. :D

Encore un truc de plus à coder pour 2019! Bananier!!!!

L’adaptateur fait très bien le job. Par contre en faible flux, j’ai l’impression que la lumière de la led rouge à proximité du capteur arrive légèrement à passer (tâche blanchâtre en bord d’image à gauche) à travers le coffrage malgré la peinture noire. Je vais devoir repasser une seconde couche voire carrément peindre la led pour être tranquille.

L’intérêt? Et bien les capteurs avec monture CS sont plus chers. Une fois l’adaptateur réalisé, on peut par exemple utiliser cet objectif 25mm F/1.2 à moins de 7€ frais de port inclus...
1/3 "25mm CCTV Objectif vue 70 m 11 degrés F1.2 IR Fixe Iris CS Mont pour CCD de Sécurité caméra

L’objectif ce visse directement sur l’adaptateur...

L’adaptateur est équipé d’un coffrage du capteur pour l’isoler au mieux des lumières parasites (j’ai ensuite peint l’intérieur en noir mat bien évidement)...

On peut réutiliser les deux vis de l’objectif d’origine pour fixer le capteur et solidariser le pied de test...

Le passage de la nappe peut être placé en haut comme ici (le capteur est tête en bas) ou bien en bas (la nappe se glisse alors par le pied)...

L’ensemble a été pensé pour une impression zéro support...

Quel lien avec mon projet me direz vous? Et bien je réfléchi tranquillement à réaliser un viseur polaire numérique intégré à l’EM-10 avec un Raspberry PI Zéro et le tout à moindre frais (<50€). ;)

Le modèle 3D est dispo sur mon compte thingiverse...
https://www.thingiverse.com/thing:3277107
Enjoy folks!!!

https://www.ebay.com/itm/Serial-SPI-4-3-inch-TFT-LCD-Touch-Shield-for-Arduino-Due-MEGA-2560-Uno-w-Library-/291873847671

Sur la base de cette écran, mon idée est de réaliser une raquette de commande qui ressemble un peu à une console de jeux portable en format paysage. L’écran est piloté par un Arduino Due 32 bits ARM afin d’offrir plus de liberté qu’une carte Arduino MEGA. Avec 84Mhz et 96Ko de SRAM le Due est l’Arduino le plus puissant du moment. Je vais pouvoir faire des folies!

Après la Nintendo Switch voici la naissance de l’Astro Switch... ;)

La puce GPS de l’ancien prototype va être réimplantée dans la raquette...

Un aperçu de l’adaptation de l’abaque numérique de l’EM-10 calé sur les données de la puce GPS (lumière bleue à l’intérieur du boitier)...

Et la mosaïque issue de la séance... :)

Mosaïque de 8 clichés.
5D Mk III - CN 212 Takahashi à F/12,4 - Réducteur F/9.9 - EM-10 MKS
400 Iso - 8 x 900 images - 1/200s en vidéo Raw.
Zoom vidéo Magic Lantern 3x.
Lien vers la full: >>>> ici <<<<

Dans l’éditeur arduino, on copie/colle le sketch suivant et on l’upload sur la carte:

void setup()
{
Serial.begin(115200);
}

void loop()
{
static uint32_t t = micros();

while (micros() - t < 16000000);
t += 16000000;

Serial.write('1'); // envoi un octet sur le port série toutes les 16 secondes
}

Et dans l’éditeur Processing, on utilise le code suivant:
import processing.serial.*;
Serial Port;
int t1,t2;
void setup()
{
int i;
Port = new Serial(this, "COM7", 115200); // remplacez COM7 par le port occupé par l'Arduino, sinon bug!

t1 = millis();
while(true)
{
while(Port.available() > 0)
{
i = Port.read();
t2 = millis();
println(256000000 / (t2-t1) + "KHz"); // affiche la fréquence du quartz de l'Arduino en KHz toutes les 16 secondes (la première mesure n'est pas fiable).
t1 = t2;
}
delay(1);
  }
}
void draw()
{
}
C’est terminé! On lance l’exécution du code sur Processing et on patiente.

Testé chez moi avec la MKS MINI V2.0 Makerbase et une carte Arduino MEGA de chez SUNFOUNDER:
- La SUNFOUNDER tourne à 15996KHz (avec +-1 KHz de variation entre les mesures).
- La MKS MINI est parfaitement calibrée à 16000KHz.

J’ai ensuite testé en chauffant les cartes avec un sèche cheveux:

- La carte SUNFOUNDER perd quasi instantanément 10Khz et elle descend encore un peu pour se stabiliser autour des 15983Khz au bout de quelques minutes. - La MKS MINI ne bronche pas et reste parfaitement stable à 16000KHz. Voilà qui confirme la MKS MINI comme un excellent choix pour mon projet. Sa fréquence est conforme et elle ne souffre pas de dérive en fonction de la température ambiante. :) Moralité: attention aux cartes choisies pour un usage en astronomie. Si possible, vérifiez bien dans les specs qu’elles sont équipées de Quartz. Moi je me suis fait berner de visu avec la SUNFOUNDER qui est équipée de résonateurs céramiques en boitier métallique ressemblant à un boitier de Quartz (merci à al1fch pour l’info). Lien vers le topic original lancé par ChristopheFr: Mesurer la fréquence d'un Arduino avec Processing

Le problème c’est que toutes les librairies testées avaient le même décalage que moi: un peu plus de 3us!!! Cela peut paraitre ridicule vu de loin mais pour des fréquences dépassant le KHz, l’erreur est de plus en plus problématique si l’on a besoin de précision. Hors en astronomie, pour le pilotage des moteurs pas à pas, la précision est de rigueur. A l’époque, j’avais donc intégré ce décalage dans RunLoop en l’estimant de manière empirique autour des 3,3us.

Et voilà qu’aujourd’hui, je viens de tomber sur l’excellentissime blog de Bill Grundmann! Si vous lisez l’anglais, c’est par ici que cela se passe:

The overhead of Arduino Interrupts

Pour résumer: il a étudié le phénomène à l’oscilloscope et décortiqué le code assembleur de la librairie Arduino. Et effectivement, la levée d’interruption entraine un surcout de 55 cycles! Soit 55*0,0625 = 3,4375us précisément!!! Hors faute de le savoir, les librairies qu’on trouve sur le net n’en tiennent pas compte. Et bim!

J’ai donc le plaisir de vous annoncer que je viens d’en profiter pour affiner encore un peu plus le code de RunLoop et de le publier sur mon github. Un test à 20Khz, montre maintenant une périodicité quasi parfaite à +-40ns près d’après l’analyseur logique (hors avec ses 12MS/s max on est dans la limite de précision d’échantillonnage donc même pas sûr que la variation résiduelle soit réelle).

Note: en toute logique, le phénomène constaté n’est présent que pour des timers hardware levant une interruption au niveau logiciel. Je ne pense pas qu’un usage en PWM soit concerné.

Veni, vidi, vici et big up à Bill! :)

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.

Si comme moi vous êtes amateur du système FS2 conçu et commercialisé par Astro Electronic, l’hommage ne vous aura pas échappé... :)

Personnellement, j’utilise encore un FS2 sur la monture ZX4 Trassud supportant mon Mewlon 250. Bien que vieillissant, il est reste très agréable à l’usage... :)

Donc pour faire simple, TeenAstro c’est le FS3 que beaucoup ont longtemps attendu. En se basant sur une version modifiée du code du projet OnStep, Charles s’est lancé dans l’aventure de créer un kit reprenant le concept de simplicité et d’efficacité du FS2 mais mis au goût du jour.

Et pour les calculs d’éphémérides et conversions astronomiques c’est ma librairie Ephemeris qui s’y colle. Cela fait plaisir de la voir utilisée sur un beau projet comme ça! :)

Vous pouvez découvrir tous les détails et avancées de TeenAstro dans cette discussion initiée par Charles sur le forum webastro.net...
https://www.webastro.net/forums/topic/158652-teenastro-une-variante-onstep-en-kit/

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.

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.

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?

I = Vref / 0.8.

Documentation Makerbase:



Traduction:
« 1. Algorithme actuel du driver 4988: i = vref /0.8.
Vref par défaut est environ 0.8v.
Le courant par défaut est 1.0A. Le courant maximal est 2.0A.  »

Source: https://github.com/makerbase-mks/Datasheet/blob/master/Chinese%20datasheet/MKS%20MINI%20V2.0%20数据手册.pdf

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.

Jolly 3D printing torture test / 0,2mm par couche.

Autant le dire tout de suite, la documentation papier est juste totalement insuffisante. il faut s’armer de patience et de tutos vidéo glanés sur YouTube pour s’en sortir sans trop de soucis.

Le montage en lui même n’est pas trop complexe pour peu de bien prendre son temps.

Et voilà la bête terminée...

Moment de vérité: le premier print…

J’avoue que pour une première je suis assez bluffé.

Plus qu’à prendre le temps d’apprivoiser la bête et d’améliorer sa structure.

En attendant son arrivée de Chine, autant lui préparer son vivarium… :)

- Captures réalisées avec la fonction de capture d’écran intégrée à ScreenView. -

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 <<<<

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

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

Un coup de Dremel plus tard, on récupère l’accès aux entrées/sorties A6 à A15 et 14 à 21…

Côté PCB, pas de problème pour la découpe puisque aucune piste ne passe par là. Il faut juste faire attention à ne pas toucher l’écran avec la mini scie circulaire du Dremel.

L’amélioration est très intéressante car on récupère l’accès à 18 entrées/sorties! Dans mon cas, l’accès aux liaisons séries 1, 2 et 3 va être tout particulièrement utile. Je vais ainsi pouvoir connecter la puce GPS et la puce Bluetooth en hardware. :)

Et pour finir un aperçu du prototype actuel démonté et placé sur un support bricolé et décoré avec ma fille (on ne voit pas bien sur la photo mais il y a des planètes et des étoiles dessinées)…

Pour rappel, le lien vers l’écran TFT 240x400 (7,31€):
http://www.volumerate.com/product/open-smart-touch-screen-expansion-shield-w-touch-pen-for-arduino-450238

Maj du 25/06 : le nouvel écran permet aussi l’accès au buffer d’affichage contrairement au Kuman. Il m’est ainsi possible de faire des captures d’écran en bmp sur la carte micro SD… :)

Ebauche de viseur polaire (mode nuit à gauche et mode jour à droite).

Librairie Genesis Gamepad...

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…

• 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.

• 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.

• Vref: tension de référence du potentiomètre.
• Imax: tension maximale globale.
• Rcs: résistance de référence = 0,2 ohm pour les StepStick.

Dans le cadre de mes moteurs pas à pas unipolaires 6 fils (24 pas / 1v / 2 ohms), nous laissons les fils communs (fils rouge) non connectés pour utiliser les moteurs en mode bipolaires...

L’intensité en fullstep biphasé est de 0,354A (70% d’Imax) par bobine.

En appliquant les formules, cela nous donne:
Imax =1,4141*0,354
Imax = 0,500A -> le max que peuvent supporter les bobines de mes moteurs en unipolaire.
et par richochet:
Vref = 8*0,354*0,2
Vref = 0,801v

Il suffit donc de régler Vref à 0,8v (Attention: ce calcul peut être différent en fonction de la résistance Rcs du driver utilisé: StepStick, Pololu, etc).

Seule ombre au tableau, le moteur dispose d’un peu moins de couple en fullstep. Je préfère néanmoins rester sur ce réglage et réduire la vitesse max à 40x/45x la vitesse sidérale au lieu de 50x (la perte de couple se fait sentir et le moteur débraye au bout d’un moment en charge à 50x). En contrepartie, cela me permet de basculer en micropas ce qui donne beaucoup plus de fluidité et moins de vibrations aux moteurs.

Le moteur entièrement clos avec sa démultiplication. Un léger coup de Dremel a été nécessaire pour désolidariser les pattes de la démultiplication…

Démultiplication retirée. On aperçoit le capot du carter…

Retrait du capot. Au milieu, le moyeu en place. C'est en fait un simple aimant qui va tourner en fonction des phases.

Moyeu retiré. On aperçoit 6 petites ailettes qui servent de "ressort" et évitent ainsi que le moyeu ne frotte sur le fond du carter lorsqu'il tourne...

Et voici les petites plaques en métal des phases du moteur. C'est elles qui vont se polariser lorsque le courant passe dans les bobines (parties blanches)…

Sur le principe, cela fonctionne comme ceci…

Moteur a six pas et quatre phases soit 24 pas complets (Source: wikipedia).

Bilan: tout est en parfait état côté moteur. Reste à voir si je peux lui faire une attelle avec un nouvel engrenage en impression 3D pour la pièce cassée de la démultiplication pour le rendre à nouveau opérationnel.

Je constate que cette sous période est confirmée par des mesures de Christophe Demeautis avec une autre EM10 USD sur son site. Ce serait donc un phénomène récurrent avec le modèle USD...

La périodicité est un indice important. Une telle période est incompatible avec les engrenages externes (pignons moteur et pignon roue dentée) car elle est bien trop rapide. Il faut donc s’y coller côté démultiplication.

Partie un peu fastidieuse: le comptage des dents de chaque engrenage et des arbres. Pour me simplifier la tâche, j’ai opté pour de la photo macro de chaque engrenage. Voici un photo montage (engrenage masqués ajoutés en transparence) avec le comptage des dents…

Calcul de contrôle avec le logiciel Soulver pour 500 rotations (logiciel très pratique pour poser ce genre de calculs):

rotation_engrenage_moteur = 500 // 500 rotations

// Mouvement de dents
engrenage_moteur = rotation_engrenage_moteur × 10 // = 5 000 dents
engrenage_1 = engrenage_moteur/30 × 10 // = 1 666,6666666667 dents
engrenage_2 = engrenage_1/40 × 10 // = 416,6666666667 dents
engrenage_3 = engrenage_2/40 × 18 // = 187,5 dents
engrenage_4 = engrenage_3/30 × 10 // = 62,5 dents
engrenage_5 = engrenage_4/25 × 20 // = 50 dents

// Rotations des engrenages
rotation_engrenage_1 = engrenage_moteur/30 // = 166,6666666667 rotations
rotation_engrenage_2 = engrenage_1/40 // = 41,6666666667 rotations
rotation_engrenage_3 = engrenage_2/40 // = 10,4166666667 rotations
rotation_engrenage_4 = engrenage_3/30 // = 6,25 rotations
rotation_engrenage_5 = engrenage_4/25 // = 2,5 rotations
rotation_engrenage_6 = engrenage_5/50 // = 1 rotation

L’arbre moteur doit donc bien faire 500 tours pour un seul tour en sortie soit une démultiplication de 1/500. On est bon par rapport aux spécifications constructeur.

Reste à déterminer la périodicité de chaque engrenage pour recoupement avec l’erreur périodique de la monture. Il faut alors extrapoler sur 10min (période complète de la vis sans fin à vitesse solaire de référence). Avant toute chose, il nous faut le nombre de pas effectués en 10min soit: 25Hz*60*10 = 15 000 pas. Etant donné que nous somme en vitesse sidérale pour les mesures d’EP, le nombre de pas est en fait un peu plus élevé si l’on veut être précis: 15 041,068733 soit un ratio de 1,002738 que nous appliqueront en fin de calcul.

pas = 15000 // 15000 pas pour un tour de vis sans fin (si tout va bien ;) )
pas_moteur = 24 // Nombre de pas du moteur pour un tour complet
rotation_engrenage_moteur = pas/pas_moteur // = 625 rotations

// Mouvement de dents
engrenage_moteur = rotation_engrenage_moteur × 10 // = 6 250 dents
engrenage_1 = engrenage_moteur/30 × 10 // = 2 083,3333333333 dents
engrenage_2 = engrenage_1/40 × 10 // = 520,8333333333 dents
engrenage_3 = engrenage_2/40 × 18 // = 234,375 dents
engrenage_4 = engrenage_3/30 × 10 // = 78,125 dents
engrenage_5 = engrenage_4/25 × 20 // = 62,5 dents
engrenage_sortie_moteur = engrenage_5/50 × 36 // 45 dents

// Rotations des engrenages
rotation_engrenage_1 = engrenage_moteur/30 // = 208,3333333333 rotations
rotation_engrenage_2 = engrenage_1/40 // = 52,0833333333 rotations
rotation_engrenage_3 = engrenage_2/40 // = 13,0208333333 rotations
rotation_engrenage_4 = engrenage_3/30 // = 7,8125 rotations
rotation_engrenage_5 = engrenage_4/25 // = 3,125 rotations
rotation_engrenage_6 = engrenage_5/50 // = 1,25 rotations

rotation_vis_sans_fin = rotation_engrenage_6 × 36/45 // = 1 rotation de la vis sans fin (Oufff!!! On est bon!)

Nous voici à l’heure du bilan. Avec 7,8125 rotations (soit 7,83389 rotations rapporté à la vitesse sidérale) notre coupable semble tout indiqué: c’est l’engrenage 4 le fautif (gear_4 sur la photo) à la jonction entre engrenage alliage et engrenage plastique. La bonne nouvelle, c’est que nous avons maintenant une connaissance très précise de la sous période: 10 min / 7,8125 rotations / 1,002738=1,276506min. La moins bonne, c’est que cette erreur n’est pas sous multiple de l’erreur périodique principale ce qui va la rendre plus délicate à intégrer dans la correction PEC. Mais dans notre malheur, il y a une bonne chose à y regarder de plus près: 15000/7,8125 = 1920 pas. En d’autres termes: la sous période se reproduit tous les 1920 pas entiers.

Pour terminer, voici l’extrapolation de toutes les périodes incluant rotation complète des engrenages (effet potentiel de voilage) et les changements de dents (effet potentiel d’erreur d’usinage des dents)…

Veni, vidi, vici pour cette étape. :D

La librairie est compatible avec le gestionnaire de librairie de l’IDE Arduino et fournie avec quelques exemples d’usage. Et en voici une illustration concrète dans le projet:

Buzzer, led, télécommande infra rouge, écran LCD et GPS fonctionnant de concert.

• la facilitation des traitements parallèles via un « run loop » (une boucle d’exécution) à multi-niveaux hiérarchiques.
• la gestion des timers logiciels.
• la gestion de tous les timers matériels du Arduino (dont les 3,4,5 dispo uniquement sur le Mega).
• les notifications asynchrones via paradigme de délégation.
• une gestion 100% C++.

Coordinates of Solar system objects (10/4/2014 19:21:0)
_____________________________________
Sun
R.A: 01h17m00s.65
Dec: 08d08'00".12
Azi: 292.30d
Alt: -8.08d
Rise: 5h10m16.53s
Set: 18h34m40.20s
Dist: 1.002 AU
Diam: 31.93'
_____________________________________

Coordinates of Solar system objects (10/4/2014 19:21:0)
_______________
Earth's Moon
R.A: 09h56m34s.76
Dec: 07d40'11".96
Azi: 154.47°
Alt: 46.27°
Dist: 401178.68 Km
Diam: 30.13'
_______________

Librairie à télécharger ici…
http://github.com/MarScaper/ephemeris

Coordinates for Mars (10/04/2014 19:21:00)
R.A: 13h10m55s.10
Dec: -4d54'45".09
Azi: 111.50°
Alt: 11.62°
Dist: 0.62 AU
Diam: 15.13"

L’idée est de faire quelque chose d’assez léger et adapté aux possibilités d’un Arduino.

• 2 Ohms.
• 1 Volt.
• 24 pas.
• démultiplication de 1/500.

• Librairie SD de base remplacée par SDFat qui offre de meilleurs performances.
• Modification de la méthode pushColor() de la classe Adafruit_TFT afin de permettre l’usage d’un buffer de pixels supérieur à 256. On peut ainsi allouer toute la largeur d’une image plein écran de 320 pixels.
• Les fichiers bitmap 24 bits sont remplacés par de vrais fichiers bmp 16 Bits. On évite ainsi tout besoin de conversion pour l’écran 16 bits.
• Les fichiers bmp sont aussi préalablement retournés haut/bas du fait de l’origine inversée entre le format bmp et l’écran. Ainsi on peut se déplacer linéairement lors de la lecture (pas besoin de seek).

J’ai donc maintenant de quoi m’amuser pour calculer les éphémérides (Soleil, Lune, planètes) avec mon Arduino. L’application des formules proposées par Jean Meeus n’est pas très complexe en soit pour peu d’être méthodique car chaque étape des calculs est bien détaillée. Là où cela se complique un peu c’est qu’il va falloir jongler avec un microcontrôleur « simple précision » hors certains calculs nécessitent une précision plus importante.

https://www.amazon.fr/gp/product/B01C3RDFN6/ref=oh_aui_detailpage_o02_s00?ie=UTF8&psc=1

L’écran offre une résolution de 320x240 en 16bits (65535 couleurs). Au dos on trouve un lecteur de carte micro SD. Et pour le tactile c’est du résistif on ne peut plus commun. Alors autant le dire tout de suite, pour 14€ ce shield est une plagia pur et simple du produit proposé par Adafruit…
2.8" TFT TOUCH SHIELD FOR ARDUINO WITH RESISTIVE TOUCH SCREEN
D’ailleurs, Kuman fournit le code source du driver sur demande uniquement par mail. Et pour cause, c’est une version à peine modifiée du code proposé par Adafruit. Sacrés chinois!!!



Les plus:

• Shield plug & play.
• Pas cher.
• Lecteur de carte SD intégré.
• Qualité d’écran très correcte notamment en mode portrait.

• Performance d’affichage assez limitées.
• Utilise quasiment toutes les connections d’un Arduino Uno.
• Angle de vue optimisé pour un affichage portrait ce qui devient désagréable visuellement si on préfère un usage en mode paysage.
• L’usage en simultané des librairies pour l’affichage, le tactile et la carte SD consomme quasi entièrement les 32Ko de stockage. L’usage d’un Arduino Mega n’est donc pas du luxe.

Le module est piloté via la librairie TinyGPS ou TinyGPS++. Et vous savez quoi? Ca le fait carrément! Latitude/Longitude/Altitude et bien sûr horloge interne synchronisée par satellite. Voilà qui va remplacer avantageusement l’horloge avec pile bouton de mon kit de base. :)

Niveau connectique, c’est on ne peut plus basique: deux pins d’alimentations (VCC et GND) et deux pins de communications (Tx/Rx) pour la communication série des infos de la puce GPS vers le Arduino.

Seul petit bémol, le module ne maintient pas l’horloge interne en cas de coupure prolongée.

Voici la modélisation 3D sous OpenSCAD…

• Calibration plus précise de la vitesse sidérale.
• Rattrapage automatique du backslash sur la déclinaison.
• Correction d'erreur périodique par modulation de fréquence.
• Interface d'autoguidage modernisée (genre protocole LX200).
• Goto relatif.
• Etc.