ScreenView le retour...
Pour rappel, 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.
- Un mode "vision de nuit" est intégré d'origine pour les projets astro. :D
Le moteur graphique pour cette version « Ordi » s’appuie sur la bibliothèque OpenCV.
Et voici les premiers composants...
https://www.youtube.com/watch?v=hfqVudtfczA
Ainsi qu’une démo Raspberry PI/Mac...
Le projet OnStep SHC utilise Ephemeris...
Voilà qui fait plaisir! :)
Vous pouvez en découvrir plus dans cet article...
https://baheyeldin.com/astronomy/onstep-esp32-smart-hand-controller-shc.html
Point sur le projet...
Le boitier abritant la carte MKS a été repensé en positionnant les composants face à l’intérieur de la monture. Cela m’a permit de placer tous les connecteurs en bas mais aussi par la suite de dégager de l’espace pour le passage de l’encodeur de l’axe R.A...
La tension d’alimentation est maintenant régulée par un Pololu S18V20F12 12V Step-Up/Step-Down (récupération de mon tout premier proto) mis en boiter avec interrupteur...
Et pour finir j’ai revu le boitier du PI Zero du proto de viseur polaire en l’inclinant de 90° pour un accès plus pratique aux ports par le dessous...
Restera à voir le connecteur du câble du moteur de mise au point du CN-212 qui dans l’immédiat est encore câblé directement en interne sur la carte. Je pense partir sur du RJ-9 histoire d’avoir quelque chose de compact.
Encodeur pour l'axe R.A.
Le sushi c'est que rien n'est droit sur cette monture! Qu'à cela ne tienne: passage ne mode "haute couture » sous OpenSCAD...
C’est moi ou bien il a un petit côté Star Trek Enterprise ce cache? :D
Là où cela devient intéressant c'est que mon idée est d'essayer d'utiliser l'encodeur pour asservir la vitesse (et non la position) et, si cela marche, compenser les erreurs périodiques en amont de la vis sans fin (démultiplication du moteur et les deux engrenages de transmission). Cela permettrait de mettre au point un PEC double étage mêlant l'asservissement de vitesse en cascade avec une mémorisation PEC classique pour la vis sans fin. Vous me suivez?
Avancée de l'interface de JARVIS
Le format paysage me contraint à revoir complètement l'interface de navigation que j'avais imaginé pour l'écran de l'ancien prototype mais cela devrait être d'autant plus confortable à l'usage.
Le retour de ScreenView:
Ceux qui suivent le projet depuis un moment, auront sans doute noté que l’interface rappelle la librairie ScreenView que je vous avais présenté mi 2017. Et pour cause puisque c’est elle que j’utilise. Je l’ai adaptée pour supporter l’écran 4,3’’ sur Arduino Due. Et avant qu’on me pose la question: oui je pense la partager lorsqu’elle sera assez avancée et stabilisée. ;)
Articles connexes:
- Aperçu bibliothèque C++ ScreenView
- Aperçu bibliothèque C++ ScreenView (2)
Nom de code: EM-10 JARVIS
Pour faire court, on a deux options au niveau librairies:
- Adafruit_RA8875
- sumotoy/RA8875
J’ai tout d’abord testé la première mais impossible à l’usage de charger de nouvelles polices de caractère. C’est d’autant plus dommageable que la police par défaut est trop grande. On doit aussi constamment jongler manuellement entre mode texte et mode graphique ce qui est pénible.
J’ai donc opté pour celle de sumotoy. Tout allait pour le mieux jusqu’au moment où j’ai inséré ma carte micro SD pour m’attaquer à l’affichage de l’image de démarrage du projet. Et là catastrophe! Les performances s’écroulent et le tactile ne fonctionne plus. :/
Après moult lectures et notamment les discussions animées par sumotoy il semblerait bien que cet écran souffre du « MISO bug » découvert par Paul Stoffegen:
«There's another **hardware issue on MISO** that's a problem only if you are planning to use any other SPI devices together with RA8875 (example, the SD card holder!), Paul Stoffregen discover the MISO bug that it's not tristate»
https://github.com/sumotoy/RA8875/wiki/RA8875-chip-BUGS!
Bref! Il faut encore que j’investigue mais c’est moyen cool! Dans l’immédiat, j’ai décidé d’avancer malgré tout en intégrant mon image de boot en mémoire flash. Cela fonctionne, c’est relativement rapide côté affichage mais cela monopolise beaucoup de mémoire.
Alors bienvenue à JARVIS, le cerveau de mon projet...
Just A Rather Very Intelligent System... 🤪
Tony Stark: "Jarvis, where's my flight power?!"
Jarvis: "Working on It, sir. This is a prototype."
Amélioration de la librairie adafruit RA8875
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...
Enjoy folks! :)
L'écran tactile de mes rêves...
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)...
Contrôler la fréquence d'un Arduino...
Voici une manip que je trouve géniale et qui a été proposée par ChristopheFr sur le forum français d’arduino.cc. Son idée permet de contrôler très simplement la fréquence réelle de fonctionnement des cartes Arduino et compatibles. Et cela sans aucun matériel complexe! Il suffit de télécharger le logiciel gratuit Processing.
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
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.
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! :)
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.
Booster son code avec la librairie Arduino GPIO
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... ;)
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...
TeenAstro utilise la librairie Ephemeris
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/
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.
Aperçu bibliothèque C++ ScreenView (2)
- Captures réalisées avec la fonction de capture d’écran intégrée à ScreenView. -
Aperçu 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
Amélioration de l'écran tactile TFT 400x240
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
Test d'un écran tactile TFT 400x240
http://www.volumerate.com/product/450236
Par rapport au Kuman K60 2.8’’, j’aime:
- Ecran plus grand.
- Résolution de 400x240 contre 320x240 pour le Kuman.
- Meilleur contraste et meilleur angle de vue que le Kuman. On l’aperçoit sur la photo, le Kuman vire vite au bleuté dans les noirs dès qu’on est pas dans l’axe.
- Affichage plus rapide (environ 2x) que ce soit en dessin vectoriel ou lors du chargement de bitmaps depuis une carte micro SD.
- L’écran chauffe moins que le Kuman.
- On dispose d’une sonde de température LM75 intégrée.
- Malgré le gain en taille, ce modèle n’occulte pas les ports supérieurs du Mega...
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).
Sky Catalog dispo sur mon Github
Et pour en savoir plus c’est par ici…
http://em10-usd-arduino-takahashi.eliotis.com/librairies-arduino/skycatalog/index.html
Régulateur Foxnovo HOBBYWING 3A UBEC 5V
Nouvelle librairie SkyCatalog en cours de dev
Une fois les fichiers d’export générés, j’ai ensuite traité les données pour les transformer en une arborescence de fichiers et ne conserver que les données utiles. Ce travail devrait donner lieu à une nouvelle librairie Arduino baptisée SkyCatalog et complétant Ephemeris.
Arduino sous Xcode
A noter que si vous recherchez un template dédié pour la dernière version d’Xcode, jetez un oeil à embedXcode:
http://embedxcode.weebly.com
Pour ma part, j’ai préféré opter pour du configuré maison car embedXcode ne supporte que la dernière version 8 d’Xcode voire au mieux 7 au moment d’écrire ces lignes. J’avoue que j’en ai marre de cette marche forcée imposée par Apple pour pousser à migrer sur leur dernier système d’exploitation poussif à souhait.
Mais revenons à nos moutons. Plutôt que d’opter pour des makefiles, je me contente de piloter l’ide Arduino à partir d’Xcode 4 (OS X 10.7.5 oblige) et d’un projet custom. C’est plutôt aisé puisque l’IDE Arduino propose tout ce qu’il faut pour l’accès en ligne de commande. Voir la doc officielle…
https://github.com/arduino/Arduino/blob/master/build/shared/manpage.adoc
Je peux ainsi lancer la compilation et l’upload...
…tout en éditant mon projet avec « code completion » et toutes les joyeusetés qu’on attend d’un environnement de travail productif.
Pour l’affichage de la liaison série, j’ai opté pour CoolTerm que je pilote par AppleScript à partir d’Xcode (lancement, connexion/déconnexion, effacement, affichage en avant plan à la fin du transfert). L’ensemble est beaucoup plus robuste et agréable que la console du logiciel Arduino…
Bref c’est maintenant que du bonheur pour bosser! <3 <3 <3
Ephemeris fait des petits...
La raquette de commande est entièrement réalisée en matériaux de récupération. Pas mal non? :D
Plus d’infos sur le blog de Bram… :)
http://zoelen.net
Librairie RunLoop dispo sur mon Github
http://github.com/MarScaper/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
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++.
Test en grandeur réelle du coucher du Soleil
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…
Zoom sur la zone centrale de la photographie...
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
https://github.com/MarScaper/ephemeris/tree/master/examples/PolarisFinder
Abaque numérique pour le viseur polaire de l'EM10
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…
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…
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…
La classe à Dallas non?!? ;)
Système solaire embarqué et opérationnel! :)
Ephemeris dans le gestionnaire de bibliothèque Arduino
Librairie à télécharger ici…
http://github.com/MarScaper/ephemeris
Le matin vient de se lever...
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
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 ».
Librairie à télécharger ici…
http://github.com/MarScaper/ephemeris
VSOP87 exit pour les Arduinos de base (Uno, etc)
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.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"
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
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é.
L’idée est de faire quelque chose d’assez léger et adapté aux possibilités d’un Arduino.
Intégration du GPS dans le projet
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. :)
Ecran déporté de débogage via Bluetooth
Et voici le résultat en vidéo…
https://www.youtube.com/watch?v=Eh7B9osfDkk
Note pour plus tard: plus j’y pense et plus je me dis qu’à terme cela pourrait être assez classe d’avoir un petit écran d’abaque numérique pour le viseur polaire. On allume l’écran. On l’approche de la monture. Il se connecte en Bluetooth et à partir des informations GPS nous affiche automatiquement l’emplacement de la polaire dans le réticule.
Prototypage de la raquette de commande avec OpenSCAD
Pas assez parlant? Ok. Une connaissance de mon Fab lab ayant eu la bonne idée de m’initier à OpenSCAD, voici donc un début d’ébauche que je vais peaufiner avec le temps (le squelette en carton est ici représenté en bleu)…
A terme le but est de modéliser l’ensemble des pièces électroniques pour contrôler leur intégration et au final réaliser la raquette de commande avec une imprimante 3D.
Amélioration des performances de l'écran TFT
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. :)
Arduino Mega
Autre chose intéressante, alors qu’un Arduino Uno dispose d’un seul timer 16 bits matériel (Timer1) le Mega en a 4 (Timer1, Timer3, Timer4, Timer5). Après quelques essais, il s’avère que les timers matériels sont beaucoup plus précis pour la gestion des pulsations de moteurs pas à pas. Avec un Arduino Mega, on peut donc piloter les deux axes avec des timers matériels ce qui est idéal.
Note: attention aux Arduinos chinois. Le premier modèle à bas prix que j’avais commandé sur Ebay s’est avéré avoir des Timers au fonctionnement hasardeux. Ils fonctionnaient au premier chargement du programme et ensuite plus rien après un reset. Heureusement, pas de mauvaise surprise avec ce modèle SunFounder un peu plus cher (18€) commandé sur amazon.
Calculs des éphémérides planétaires
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.
Nouveau prototype nomade pour le dev...
Il suffit d’ouvrir le coffret, de le brancher et hop c’est parti pour les devs...
Le prototype en l’état est maintenant quasi complet et constitué des éléments opérationnels suivant:
- Arduino Mega.
- Ecran LCD 16x2.
- Buzzer.
- Led de mise en veille.
- Capteur de température/humidité DHT 11 (qui sera remplacé à terme par un DHT22 pour plus de précision).
- Puce GPS qui remplace l’ancienne horloge.
- Lecteur micro SD en remplacement du premier lecteur SD trop encombrant.
- Puce bluetooth pour la connection sans fil avec un ordi, un ipad ou un iPhone.
Voici une vue côté câblage interne...
Ecran TFT or not écran TFT?
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.
Les moins:
- 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.
Astuce: le remplacement de la librairie SD par la librairie SDFat permet un gain substantiel: l’usage de la mémoire Flash est plus réduit (environ 9% sur un Uno) ainsi que l’usage de la SRAM et les performances sont sensiblement améliorées.
Dans l’immédiat, je ne pense pas utiliser cet écran TFT pour la raquette de commande mais il pourrait être pratique pour concevoir une console de débogage déportée avec une connexion Bluetooth.
Détails de l'écran LCD 16x2
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).
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.
Début du prototype
Voici un aperçu du prototype destiné à valider les premiers composants du système de commande. Ok, c’est un peut « roots » mais l’essentiel est là...
En complément du kit, un lecteur de carte SD (situé à proximité de la télécommande sur la photo) a été ajouté pour le stockage de la base de donnée d’objets célestes.
Observations:
- Je pensais que l’afficheur LCD 16 caractères sur 2 lignes serait un peu juste mais c’est pas si mal.
- Le capteur d’humidité du kit est un DHT-11. Il fait le job mais sa précision de +-2°c n’est pas idéale. Prévoir de le remplacer par un DHT-22.
- Le lecteur de carte SD est un peu gros. Je vais le remplacer par un lecteur micro SD plus compact.
- L’Arduino Uno du prototype est déjà au taquet niveau entrées/sorties et la librairie du lecteur SD est assez gourmande en mémoire. Il va falloir passer à un Arduino Mega pour tenir la route.
Un kit Arduino comme base de travail
http://eud.dx.com/product/uno-learning-kit-for-arduino-with-ir-1602lcd-relay-temperature-humidity-clock-module-resistor-card-844424271
Attention: prévoir un délai d’un bon mois pour réception.
Listing du kit (in English sur le site):
1 x UNO main board
1 x 1602 screen
1 x Stepper motor driver board
1 x Temperature humidity module
1 x Clock module
1 x 1 relay module
1 x 400 holes breadboard
1 x Small breadboard
1 x Fixed board
1 x Battery box (6 x AA, 15cm-cable)
4 x Button switches
3 x Photoresistors
1 x Flame sensor
2 x Buzzers
1 x Temperature sensor
2 x Tilt switches
1 x IR receiver
1 x LED light
1 x Adjustable resistor
1 x 74HC595
1 x Remote controller
1 x 1-digit seven-segment display
1 x 4-digit seven-segment display
1 x 8x8 dot matrix
1 x 9g servo (25cm-cable)
1 x Stepper motor (23cm-cable)
10 x Jumper wires (10cm)
20 x Jumper wires (20cm)
10 x DuPont wires (20cm)
1 x USB cable (139cm)
8 x 220R resistors
5 x 1K resistors
5 x 10K resistors
5 x Red led
5 x Yellow led
5 x Blue led
1 x Resistor card
1 x 16 pin header
1 x Box
Les éléments qui me semblent les plus intéressants:
- Un contrôleur Arduino Uno pour commencer le prototype.
- Un écran LCD deux lignes pour l’affichage.
- Un capteur IR avec une télécommande plutôt bien adaptée pour nos besoins.
- Un buzzer pour les effets sonores (ex: signalement fin de pointage).
- Led pour la mise en veille.
- Horloge avec pile.
- Capteur d’humidité/température pour les mesures ambiantes.
- Capteur de température simple pour le miroir.
- Un moteur pas à pas et son circuit de puissance pour se faire les dents (utilisable pour se faire une mise au point électrique à terme?).
- Capteur d’inversion pour la position du télescope (détection du pointage Ouest ou Est).
- De quoi voir venir pour câbler le prototype et vérifier la faisabilité du projet.
Présentation du projet
- 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.
Librairie Ephemeris dispo sur mon 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. :)