Amélioration de la librairie adafruit RA8875

Pour ceux que cet écran RA8875 intéresse, j'ai publié sur mon github une version améliorée du code d'adafruit...
https://github.com/MarScaper/Adafruit_RA8875

Le tactile a été revu avec une fifo circulaire afin de réaliser une moyenne glissante pour limiter le bruit...
https://www.youtube.com/watch?v=gKrekKUhyoY

Enjoy folks! :)

Booster son code avec la librairie Arduino GPIO

Déjà évoqué sur mon blog, voici un aperçu chiffré du gain apporté par l’excellente librairie Arduino-GPIO...
arduino-gpio-library
On passe ainsi de 17,58us à 2,042us pour un changement d’état d’une sortie. Cela représente un gain de 8,6x! Et en plus l’écriture du code est allégée. Ce serait dommage de s’en priver. A vous de voir... ;)

Timer hardware ou les 55 cycles manquant...

Je ne sais pas pour vous mais c’est plus fort que moi: Quand quelque chose ne se passe pas comme prévu j’ai besoin de comprendre le « pourquoi? ». Lors de l’écriture de la librairie RunLoop pour Arduino, j’avais constaté à l’époque un décalage sur les timers hardware entre la période demandée par le programme et la périodicité réellement constatée en sortie avec l’analyseur logique.

runloop

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

50us-20khz


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! :)

Démo d'avancement du goto prédictif...

Ce n’est pas encore parfait mais on approche... :)


https://www.youtube.com/watch?v=CCw-PU-hffA

L'ATmega2560 de la MKS MINI au taquet...

Après avoir bien poussé les optimisations de code, voici un benchmark montrant les impulsions d’un des moteurs pas à pas poussées au maximum des capacités de la carte Arduino (le mode PWM permettrait d’aller encore plus loin mais sans aucun retour pour le comptage de pas donc incompatible avec les besoins du projet)...

arduino-moteur-pas-a-pas-frequence-max

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

accel-timer

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

Bien. Depuis quinze jours, j’ai effectué un gros gros taf sur la gestion des moteurs. J’ai repensé en profondeur l’algorithme s’occupant des interruptions timer. Illustration en vidéo... -Désolé pour la qualité du son. Mon PC n’aime pas la chaleur actuelle.-

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

Les choses commencent à devenir intéressantes. J’évoquais dans le précédant billet l’intérêt d’un micro contrôleur en terme de précision. L’avantage indéniable des moteurs pas à pas est comme leur nom l’indique « les pas ». En comptant chaque pas au niveau logiciel, on peut contrôler la position avec une grande précision. Mais cette force est aussi une faiblesse car qui dit contrôle dit responsabilité. On ne peut pas dire à un moteur pas à pas d’aller à un endroit précis, d’accélérer ou de décélérer de façon autonome en le branchant et en claquant des doigts. Tout doit être géré par le programme.

Reprenons l’exemple d’une accélération comme celle que j’utilise pour ma monture...

courbe-acceleration


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.

comptage des pas acceleration moteur


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

On me demande souvent pourquoi avoir choisi de développer sur plateforme Arduino MEGA? Après tout, on fait quoi avec 16MHz et 8Ko de SRAM!?! Un Raspberry PI serait hachement plus puissant!

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.

100x-sideral-speed


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 bibliothèque C++ ScreenView (2)

Quelques captures montrant l’avancement de ces derniers jours. J’ai essentiellement travaillé sur les différents types de boutons: simple, fléché, fléché avec cadre (voir capture de l’écran « Menu »). J’ai aussi enrichi le fonctionnement des éléments répondant au tactile (attribut activé/désactivé). Je pense intégrer le gamepad comme un élément de la librairie pour qui voudra créer une raquette de commande facilement.

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

Aperçu bibliothèque C++ ScreenView

Démo d'avancement de ma nouvelle bibliothèque C++ ScreenView...

Elle a pour but de faciliter la conception et la gestion d'interfaces graphiques avec un écran tactile sur Arduino. Elle sera compatible avec les écrans exploitant la librairie Adafruit.

Dans les grandes lignes la bibliothèque permettra:
- Mise à dispo de composants graphiques de base (label, boutton, slider, image BMP 16 bits et 24 bits, conteneurs, etc).
- Agencement hiérarchique des composants graphiques.
- Rafraichissement optimisé pour ne mettre à jour que les zones modifiées.
- Le tactile de la bibliothèque d'Adafruit a été amélioré pour gérer le touch down, touch move et touch up.
- Possibilité de réaliser des captures d'écran en bmp vers carte micro SD (pratique pour faire de la doc).
- Un mode "vision de nuit" est intégré d'origine pour les projets astro. :D

Compter un peu plus de 7€ pour l'écran 400x240 sur volumerate.com. De quoi relayer dans un tiroir les écrans LCD 16x2. :D

La monture prend vie...

Les briques commencent à s’emboiter petit à petit pour faire prendre vie à la monture. La conception de l’interface graphique devrait ainsi à terme donner le jour à une nouvelle librairie Arduino baptisée ScreenView et destinée à la gestion de l’affichage.

Voici les premières captures officielles…
polaris gamepad

Et une mini vidéo…

https://www.youtube.com/watch?v=h8L5rXhS2R0

La maquette de travail ressemble à ceci...
screenshots-gui-arduino-em10-taka

Accélération/décélération: Sinus or not Sinus?

Maintenant que je dispose d’une manette de contrôle digne de ce nom, je vais pouvoir travailler sur les phases d’accélération. Dans l’immédiat, j’ai retenu trois modes d’accélération à étudier.

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.

accel

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…
accel-lin

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...
accel-sin1

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...
accel-sin2

L’idéal va être des les mettre en oeuvre sur le terrain pour voir le ressenti en terme de confort d’utilisation.

L'analyseur de moteur pas à pas livre ses premiers chiffres...

Les premiers chiffres de l’analyseur commencent à tomber et c’est plutôt très encourageant sur les premiers jeux de test avec l’électronique USD d’origine en vitesse sidérale. Sur une échantillonnage de 10 minutes à 30 img/s, les estimations de l’algorithme sont:
  • 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.
analyseur-de-precision
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…
Capture d’écran 2017-05-27 à 14.55.42
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...
Capture d’écran 2017-05-27 à 14.56.03
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.

Sky Catalog dispo sur mon Github

Et voilà pour Sky Catalog. La librairie C++ est dispo sur mon Github avec encore un joli logo d’illustration pour le plaisir...
SkyCatalog
Et pour en savoir plus c’est par ici…
http://em10-usd-arduino-takahashi.eliotis.com/librairies-arduino/skycatalog/index.html

Librairie RunLoop dispo sur mon Github

Le premier jet de la librairie C++ RunLoop est dispo sur github...
http://github.com/MarScaper/runloop

Logo RunLoop

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.

Run Loop Library: une boite à outil pour Arduino

Dans la continuité des développements pour mon projet d’astronomie, j’ai décidé de mettre au point une nouvelle librairie pour me faciliter la tâche et je l’espère celle d’autres Ardui-bidoulleurs.

RunLoopClassHierarchy
Dénommée RunLoop, elle permettra:
  • 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++.
Plus de détails à venir prochainement avec la publication du code sur mon Github. :)

Test en grandeur réelle du coucher du Soleil

Et c’est parti pour un tour à Guidel plage pendant les vacances pour observer le coucher de soleil en bord de mer. Février? Vous avez bien dit Février?!? Tiens! Des phoques sur des planches! Y sont fous ces Bretons… ;)
sunset arduino ephemeris

L’estimation avec Ephemeris était de 18m42m17s. Manque de bol des nuages en bord d’horizon ont limité la précision de la mesure. Dernier rayon photographié à 18h41m12s…
sunset arduino ephemeris

Zoom sur la zone centrale de la photographie...
sunset arduino ephemeris
Il nous reste à vue d’oeil un « demi soleil » à une 1 minute et 5s du dernier rayon estimé. On est vraiment pas mal du tout niveau précision si l’on fait abstraction des nuages. :)

PolarisFinder dispo dans Ephemeris

PolarisFinder (version simplifiée sans GPS ni Bluetooth) est maintenant intégré dans les exemples de la librairie Ephemeris sur mon Github…

PolarisFinder
https://github.com/MarScaper/ephemeris/tree/master/examples/PolarisFinder

Abaque numérique pour le viseur polaire de l'EM10

Je me souviens très bien de cette nuit de mi-août 1998 où je mettais à l’oeuvre pour la première fois ma flambant neuve EM10. Avec cette monture et le CN-212, j’allais enfin pouvoir passer dans un autre monde: celui de l’astrophotographie et de l’indispensable alignement polaire (aussi appelé « mise en station ») qui va avec.

La monture, équipée d’usine d’un viseur polaire, était accompagnée d’un abaque en carton permettant de déterminer facilement l’endroit où placer l’étoile polaire en fonction du jour et de l’heure…
abaque carton
Après près de 20 ans de bons et loyaux services à coup de lampe rouge dans l’obscurité j’ai décidé de lui fabriquer un successeur numérique digne de ce nom!

Le concept est simple: un arduino, un écran TFT et un puce Bluetooth. Dès que l’on approche l’ensemble à quelques centimètres de la raquette de commande, la liaison Bluetooth s’établie automatiquement et les infos (localisation sur la Terre, date, heure, altitude) du module GPS de la raquette sont rapatriées. Le Arduino calcule alors le positionnement de la polaire et affiche l’abaque numérique. Et voici le résultat à côté du logiciel Polaris Finder proposé par Optique Unterlinden sur PC…
polaris-arduino-em10

Pour le calcul de l’angle de l’étoile polaire c’est on ne peut plus simple: j’utilise ma librairie Ephemeris. La longitude est celle du lieu d’observation et par contre pour la latitude on se place au pole Nord c’est à dire à +90°. Notre pôle céleste est alors parfaitement au dessus de notre tête et la polaire va réaliser sa ronde autour durant la nuit. Connaissant ses coordonnées équatoriales, on calcule ses coordonnées horizontales avec la librairie ce qui nous donne son angle en azimut. Le tour est joué.

En langage programmeur cela donne quelque chose comme ces quelques lignes…

code polaris

La classe à Dallas non?!? ;)

Système solaire embarqué et opérationnel! :)

La boucle est bouclée, Ephemeris est maintenant intégrée au projet EM10 USD Arduino. Les coordonnées du lieu et l’altitude sont initialisées avec la puce GPS. Ici pour le test, les données sont calculées par le arduino de la raquette puis envoyées à ma console Bluetooth de debogage. C’est une affaire qui roule… :)

bluetooth console arduino systeme solaire

Ephemeris dans le gestionnaire de bibliothèque Arduino

Tout est dans le titre de ce billet: le code d’Ephemeris est maintenant compatible avec le gestionnaire de bibliothèque pour une intégration facile dans d’autres projets Arduino.
ephemeris_library_embeded_in_library_manager

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

Le matin vient de se lever...

Dernière finitions sur la librairie Ephemeris pour mon Arduino avec la gestion des heures de lever/coucher des astres de notre système solaire. Voilà qui est fait. De quoi allumer l’arrosage automatique lorsque le Soleil se couche enfin si le télescope est pas dehors hein!?! ;)

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


Et cela fonctionne pour le Soleil, Mercure, Venus, notre Lune, Mars, Jupiter, Saturne, Uranus, Neptune et avec en bonus une méthode publique permettant d’estimer l’heure de lever/coucher de n’importe quel astre pour peu de connaitre ses coordonnées en ascension droite (ex: galaxies, etc).

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

Fly me to the Moon avec Ephemeris

Voilà qui est fait. La librairie Ephemeris intègre les calculs des coordonnées de notre bon vieux satellite. :)

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


Les calculs sont basés sur les termes périodiques ELP2000 mis en forme dans le fichier d’entête « ELP2000.h ».

ephemeris_include_graph_2

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

Librairie Ephemeris dispo sur mon Github

Le premier jet de ma librairie C++ Ephemeris est dispo sur github...
http://github.com/MarScaper/ephemeris

Elle est conçue avant tout pour le Arduino Mega mais codée pour rester multiplateforme. On peut ainsi obtenir les coordonnées équatoriales (R.A/Dec), les coordonnées horizontales (Alt/Az), la distance en AU et le diamètre apparent des planètes du système solaire ainsi que du Soleil pour une date et un lieu donné.

Il ne manque que la Lune que j'attaque dans la foulée. :)

VSOP87 exit pour les Arduinos de base (Uno, etc)

Le codage de la librairie Ephemeris avance bien et la précision de calcul devrait s’avérer largement suffisante pour le pointage automatique du télescope.

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"

Seule ombre au tableau, la théorie VSOP87, malgré qu’elle soit tronquée, demande un peu plus de 29Ko rien que pour le stockage des thermes permettant le calcul des coordonnées héliocentriques. Exit donc la compatibilité avec les Arduinos de base en l’état. De même, le stockage des données dans la mémoire flash (PROGMEM) est impératif pour le Arduino Mega car ses 8Ko de SRAM sont insuffisant.

Bien sûr on pourrait trouver des subterfuges si c’était vraiment nécessaire:
- utiliser la méthode de calcul de base présentée dans l’ouvrage mais elle est peu précise car elle ne tient pas compte des interaction entre les planètes.
- stocker les termes VSOP87 dans des fichiers sur une carte SD avec accès à la volée.
- stocker les termes VSOP87 dans une mémoire flash annexe en utilisant la librairie SPIFlash.

Dans mon cas, je vais me borner à mon besoin. Autant exploiter le Arduino Mega.

Conception de la librairie Ephemeris pour Arduino

J’avance actuellement sur le codage de la librairie Ephemeris. Elle sera dévolue aux calculs des éphémérides pour le Arduino afin de permettre le pointage automatique des astres du système solaire.

arduino-ephemeris-library

Les algorithmes sont développés sur la base de l’ouvrage de Jean Meeus et découpés en une classe C++ Calendar pour les calculs de dates et une classe C++ Ephemeris pour ce qui concerne les calculs d’éphémérides à proprement parlé.

ephemeris_8ino__incl


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

Calculs des éphémérides planétaires

Après une quête peu fructueuse sur le net à la recherche d’une librairie pour Arduino, je décide de m’y coller pour mon projet. L’ouvrage de référence en la matière est « Calculs astronomiques à l’usage des amateurs» par Jean Meeus. Un très bel ouvrage concret édité par la SAF pour seulement 13€. C’est une initiative à saluer car il est rare de trouver des ouvrages spécialisés aussi abordables.

calculs_astronomiques_jea_meeus

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.

Intégration du GPS dans le projet

Voilà qui est fait. L’horloge a été remplacée par la puce GPS et c’est opérationnel. Lors du démarrage, la raquette se met en attente des satellites jusqu’à localisation. On peut éventuellement shunter cette étape en appuyant sur n’importe quelle touche de la télécommande infra rouge.
screenshot-lcd-gps
Et pour le fun, je me suis même amusé à animer les ondes qui émanent de l’icône de localisation pendant qu’on patiente. :)

Amélioration des performances de l'écran TFT

Pour le fun je me suis amusé à améliorer les performances d’affichage de l’écran TFT. Le résultat en vidéo...

https://www.youtube.com/watch?v=Tjh4EQe2xGI

Optimisation:

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

Au final les performances sont améliorées d’un facteur 3x pour de l’affichage bitmap. :)

Détails de l'écran LCD 16x2

Voici quelques captures d’écran du LCD agrémenté d’un début d’iconographie maison. En plus des caractères standards ont peut ainsi créer jusqu’à 8 caractères spéciaux en simultané donc je me suis amusé un peu :).

De haut en bas, l’affichage des coordonnées en ascension droite et déclinaison avec pour le fun à gauche un icône de mire de pointage et en fonction de la vitesse de suivie: des étoiles (vitesse sidérale), un croissant de Lune (vitesse Lunaire), un soleil (vitesse solaire).
ecran-lcd-16x2

J’ai prévu dans la foulée d’agrémenter l’électronique d’un capteur de température interne pour le miroir, d’un capteur de température externe et d’un capteur d’humidité. Les capteurs de température seront tout particulièrement utiles pour le contrôle de la mise en température du télescope.
Sondes em 10