lunedì 20 novembre 2017

Piccoli passi


Posate un attimo lo sguardo su un orologio munito della lancetta contasecondi. Vedrete che essa ogni volta si ferma prima di passare al secondo successivo, compiendo salti di 6° ogni volta per poter compiere un giro ogni minuto.  Ora immaginate di farle fare un giro completo in un giorno intero: tra un salto e l'altro passerebbero ben 24 minuti, o 1440 secondi se preferite.
Se usassimo un tipico motore passo-passo con una risoluzione di 1,8° per passo le cose andrebbero decisamente meglio: un minuto verrebbe frazionato in 200 passettini e la nostra lancetta parrebbe molto più fluida nel suo movimento. se applicassimo il criterio precedente di farle fare un unico giro completo in un giorno otterremo salti ogni 432 secondi, ossia poco meno di uno ogni 7 minuti.molto meglio di prima, ma ancora insufficiente.
Il bello dei motori passo passo è che possono compiere anche dei passettini intermedi
tra un passo e l'altro:
modulando opportunamente i campi magnetici del motore si possono ottenere tanti piccoli micropassi che suddividono ulteriormente i passi necessari a compiere un giro completo. Questo è il compito delle schede driver del motore, che gestiscono ognuna a suo modo e secondo le proprie capacità la tensione di eccitazione dei magneti.
I microstep ottenibili dall'integrato TBH7128
Io ho scelto l'integrato TBH7128 per la sua capacita di suddividere fino a 128 volte (2^7) ogni singolo passo del motore; così posso disporre fino a 25600 micropassi per ogni singolo giro. Un giorno solare suddiviso in 25600 passi significa un passo ogni 3,375 secondi, quindi una velocità angolare di soli 50'' d'arco o giù di lì. L'unico grande svantaggio dei microstep è che essi riducono notevolmente la coppia disponibile, più i micropassi sono piccoli e minore sarà la forza magnetica che trattiene il rotore del motore; questa sarà una cosa da tenere ben presente nella messa a punto del mio progetto.
La formula empirica che lega la
distanza dall'equatore celeste
distanza dall'equatore celeste dal polo
in gradi e l'esposizione
in gradi e l'esposizione con una DSRL full frame.
Se seguite anche l'altro mio blog, alcuni anni fa ho illustrato una simpatica formuletta empirica (evito di spiegarvi tutta la matematica che vi è dietro) utile per stabilire il tempo di esposizione massimo utile affinché non si abbia l'effetto scia nel fotografare il cielo con una macchina fotografica fissa.
Questa ci dice che inquadrando l'equatore celeste (0° di declinazione) una esposizione con una focale di 500 mm non può essere superiore al secondo per evitare che una stella disegni una scia sul sensore fotografico di una DSRL full frame (se usate una Canon APS (crop 1,6) dovreste  usare 312 invece del 500 e 333 (crop 1,5) per una Nikon APS).
Pertanto, anche una risoluzione temporale di 3 secondi già degrada le immagini oltre il limite di esposizione suggerito; per questo ho scelto uno stepper con una demoltiplica 100:1  (in realtà sono 99,05 a 1). Questo mi consente di suddividere il singolo giro fino a 2560000 micropassi (i microstep sono ancora 25600 ma ne occorrono 100 per avere lo stesso scarto angolare), pari a una risoluzione temporale di 0,03 secondi, ossia di 0,5'' d'arco!
Purtroppo, a meno che non ci trasferissimo sulle Ande armi e bagagli, la turbolenza atmosferica in genere non ci consente di godere di un potere risolutivo migliore di un secondo d'arco e, più spesso, anche di due.
Dato il caso, posso tranquillamente limitarmi a eguagliare il potere risolutivo dettato dal seeing e stare lo stesso tranquillo limitando i micropassi a 2^6, ossia a 64 micropassi per ogni singolo passo, 12800 per ogni singolo giro, 1280000 con la demoltiplica 100:1. In più otterrei una coppia un po' più alta nel rendimento del motore.

A questo punto l'unica incognita che mi rimane è sapere se lo stepper da me scelto con il driver TBH7128 potrà darmi una coppia sufficiente a sostenere un paio di chilogrammi. Spero di sì ma anche questo è un problema che dovrò risolvere.
Cieli Sereni.

sabato 18 novembre 2017

Astroinseguitore versione 3.0


Mannaggia a me!
Il mio progetto è in uno stato fluttuante, in  un continuo divenire. È questo che lo rende ai miei occhi, e spero anche vostri, interessante.
Ho deciso di abbandonare il display grafico LCD12864 delle stampanti 3D: troppo luminoso e di scarsa risoluzione per i miei propositi.  Grazie ad esso però ho potuto scrivere e testare tanto buon codice che sto riutilizzando nella versione 3.0.


Questo è il display LCD: ottimi l'encoder e il buzzer, ma la grafica è bruttina  e soprattutto lo schermo è troppo luminoso per essere usato al buio.



Per questo ho finito per scegliere un display grafico OLED con capacità touchscreen: niente encoder rotativi per scegliere le opzioni ma un pratico tocco di dita è più che sufficiente per il medesimo scopo.
In più posso usare colori che meno feriscono gli occhi e usufruire di una grafica decisamente migliore per le funzioni di centratura della montatura equatoriale.
Il buzzerino tornerà anche qui, è troppo simpatico e utile per non essere compreso nel progetto.
Qui l'Arduino Nano che pilota un motore
NEMA17 da 200 step/giro uguale al definitivo
con demoltiplica 1:100.
In realtà la corrente assorbita sarà nettamente
inferiore:appena 10-11 mA a regime.
Come ho detto all'inizio, questo è un progetto in divenire, cioè non è pianificato e in costante evoluzione. Così ho deciso di demandare la gestione del motore a un altro Arduino, il Nano, con unicamente questo scopo per non sovraccaricare il processore con altri calcoli (dai miei test solo una istruzione Serial.print() porta via 0,26 millisecondi) e ottenere — non è facile — così la massima precisione di inseguimento. Per questo nello sketch del motore non sarà prevista alcuna libreria se non quelle che Arduino usa per il suo corretto funzionamento: 2466 byte di programma e 210 di RAM sono più che sufficienti, a meno che non pensi qualcos'altro, è ovvio!

Per ora non è tutto, ma cercate di farvelo bastare per ora, Alla prossima e Cieli Sereni.

domenica 24 settembre 2017

GPS (seconda parte)

Ora che ci sono note alcune informazioni riguardanti la lettura dei dati GPS con Arduino.

Per questo ho scritto un breve programmino che cattura tutta la stringa in uscita dal modulo GPS e la rielabora grossolanamente restituendo sulla monitor seriale tutti i dati estratti.
Il codice è pubblicato sul mio repository sulla piattaforma GitHub all'indirizzo:

https://github.com/UmbyWanKenobi/GPS-example/blob/master/gps_hardware.ino

a cui potete fare riferimento per il codice, che è ben commentato (almeno lo spero).
La sottostringa da me usata è la GPGA, la quale fornisce i principali dati riguardanti lo stato della connessione ( FIX ) corrente, la correzione del dato orario di rilevamento, le informazioni minime GPS e lo stato dei satelliti.

 $ GPGGA, 123519,4807.038, N, 01.131,000, E, 1,08,0.9,545.4, M, 46,9, M ,, * 47
14
Dove:
     Il sistema di posizionamento globale di GGA corregge i dati
     123519 Correzione prese alle 12:35:19 UTC
     4807.038, N Latitudine 48 deg 07.038 'N
     01131.000, E Longitude 11 deg 31.000 'E
     1 qualità del Fix: 0 = non valido
                               1 = riparazione GPS (SPS)
                               2 = correzione DGPS
                               3 = correzione PPS
          4 = cinematica in tempo reale (1)
          5 = Real-Time Kinematic flottante (1)
                               6 = stima (calcolo morto) 
          7 = modalità di immissione manuale
          8 = Modalità di simulazione
     08 Numero di satelliti in fase di tracciamento
     0.9 Diluizione orizzontale della posizione
     545.4, M Altitudine, metri, al di sopra del livello del mare medio
     46.9, M Altezza di geoide (livello medio del mare) sopra WGS84
                      ellissoide
     (campo vuoto) in secondi dall'ultimo aggiornamento DGPS
     (campo vuoto) Numero ID della stazione DGPS
     * 47 i dati di checksum, sempre inizia con *

La quota di geoide, più propriamente detta quota ortometrica, è l'elevazione del punto sulla superficie terrestre rispetto alla superficie del livello medio del mare.
Se manca l'altezza del geoide l'altitudine indicata potrebbe essere non corretta. Alcune implementazioni non standard riportano l'altitudine rispetto all'ellissoide anziché all'altitudine geoidale. Alcune unità non presentano affatto le altitudini negative. 
Le altre sottostringhe riportano altri dati in cui alcuni campi sono ripetuti oltre a altre funzioni come la velocità di spostamento, la deriva del Nord magnetico e la data, Alcuni campi sono riservati e altri semplicemente vengono ignorati da alcuni chip come questo (il MEO 6M), per esempio quello relativo alla deriva magnetica che invece potrebbe essere utile per la calibrazione delle bussole elettroniche.
Ora cercherò un chip che fornisce anche questa informazione e magari che generi l'interrupt per la sincronizzazione dell'orologio interno di Arduino. Sarebbe fantastico!


Cieli sereni

(1) Indice per gli algoritmi di alta precisione per la navigazione. l?RTK è una tecnica che migliora l'accuratezza delle misurazioni della posizione GPS, tuttavia è anche una delle più difficili da comprendere e da implementare.

Il GPS (prima parte)


Il GY-GPS6MV1 è un prototipo basato
sul chip NEO-6M-0-001
Salve di nuovo.
Questo mio progetto è un po' come la Novella dello Stento, un modo di dire toscano per indicare una cosa lenta e lunghissima. Il motivo è il solito: prima di parlare di qualcosa voglio essere sicuro di conoscere l'argomento, altrimenti il mio rimane un discorso vuoto e privo di qualsiasi valore. È in pratica il noto processo di riproducibilità di un esperimento tanto caro alla scienza e che ci ha insegnato Galileo Galilei.
Uno degli elementi da me richiesti per questo progetto è il conoscere precisamente la posizione sulla superficie terrestre, soprattutto la latitudine, necessaria per il corretto puntamento al Polo Celeste. In origine doveva essere un sistema equatoriale GoTo, ossia che conoscendo il nord magnetico e la latitudine dei motori passo-passo avrebbero dovuto automaticamente allineare la montatura di inseguimento. Poi alcune difficoltà per la creazione della parte riguardante la meccanica di precisione — non ho gli strumenti, l'officina e soprattutto la preparazione necessaria — mi hanno costretto a ripensare il progetto optando per uno stazionamento manuale, ma comunque sempre aiutato dall'elettronica.
Quindi, salvo altri ripensamenti, la parte elettronica rimane sostanziamente la stessa, invece di guidare i motori di stazionamento ho dei led che indicano quando lo stazionamento è corretto. Pertanto mi occorre sapere l.'esatta latitudine per il puntamento polare, e per questo viene in soccorso il sistema GPS che tutti conosciamo, non starò qui a ripetere cosa esso sia con esattezza.
Non è difficile conoscere — oggi — le nostre coordinate assolute, basta un qualsiasi smartrphone anche da 100 euro, e con Arduino ancora molto meno. Magari è necessario arrabattarsi un po', ma vi assicuro che la soddisfazione è infinita. Ci sono modulini molto economici basati sul chip NEO-6 (qui il datasheet completo) che hanno anche una comoda antenna passiva (il piccolo parallelepipedo bianco) collegato attraverso una piccolissima presa coassiale di tipo Hirose U.FL, specifico per i segnali a radiofrequenza superiori ai 6 GHz. Per i miei esperimenti dentro casa ho dovuto sostituire la sua antennina con una attiva esterna da auto col relativo adattatore, ma all'esterno conto di riusarla.
Comunque nella pratica — anche qui non sto a ripetere il meccanismo alla base dello schema GPS — il modulino, una volta che si è agganciato ai satelliti, il Fix, restituisce una stringa di caratteri, solo apparentemente confusi, contenenti tutte le informazioni a noi necessarie per conoscere la nostra posizione: latitudine, longitudine, ora (in UTC), la data e l'altezza dal livello del mare stimata.
Nella prossima puntata vi spiego come leggere questa stringa.

lunedì 4 settembre 2017

Il display grafico 12864 RepRap


Un progetto ambizioso quanto il mio non poteva non prevedere uno schermo per visualizzare in tempo reale i dati della sessione di scatto. Per questo nella prima versione era previsto uno schermo  LCD da 20 caratteri per 4 righe pilotato attraverso lo schema seriale I2C (2 soli pin più l'alimentazione).
Poi ho visto in giro le schede delle stampanti 3D, spesso pilotate da semplici Arduino. I loro schermi sono anch'essi monocromatici LCD, ma sono più grandi e consentono una grafica piuttosto primitiva, stile anni '80 dei primi videogiochi, ma assai accattivanti. In più hanno incorporato un pulsante di stop, un buzzerino per l'allarme e un selettore rotativo, il che mi eviterebbe il fastidio di dover usare 5 pin per una tastiera a membrana 4x1 di cui avrei usato soltanto tre pulsanti. In più essa contiene uno slot SD per leggere e scrivere dati, e mi sarebbe molto utile poter registrare le condizioni delle future sessioni per scopi scientifici.

La differenza che distingue giocare e fare scienza sta nel raccogliere i dati.


I collegamenti elettrici 

Lo schema elettrico del display grafico RepRap 12864 (http://reprap.org/mediawiki/images/5/51/RRD_FULL_GRAPHIC_SMART_CONTROLER_SCHEMATIC.pdf)

La disposizione dei contatti nel connettore
a disposizione del display grafico
RepRap 12864 uscita EXP1
Purtroppo il display grafico è progettato per funzionare con lo scudo studiato per pilotare le stampanti 3D, quindi usare tale apparato per altri progetti è un pelino più complicato ma non impossibile: con lo schema è possibile risalire alla disposizione dei controlli per tutte le funzioni che mette a disposizione. Questo è il primigenio spirito hacker!
I piedini dello scudo display nello standard SPI (Serial Peripheral Interface):
--                #include "U8glib.h"
--                #define E_SCLK 8
--                #define RW_SID 9
--               #define CS_RS 10
--                U8GLIB_ST7920_128X64_1X u8g ( E_SCLK, RW_SID, CS_RS ); 
in quest'ordine nello sketch.

Per ora è tutto, restate sintonizzati.

domenica 3 settembre 2017

Il mio astroinseguitore

Un paio di anni fa ero partito con l'idea di costruire una tavoletta equatoriale, una di quelle che gli anglofoni chiamano barn door tracker. L'aggeggio consiste in due tavolette imperniate su un asse posto in parallelo all'asse terrestre, in pratica punta verso la Stella Polare, e quella che sostiene la camera ruota in senso opposto alla Terra con la medesima velocità simulando così il movimento della volta celeste.
Io ho deciso di andare oltre ed eliminare tutti i calcoli trigonometrici necessari affinché la spinta della tavola sia costante e col vantaggio di una struttura molto più piccola ed equilibrata: un semplice motorino passo passo con un planetario 100:1 che mi consente spostamenti angolari (step) ampi soltanto 0,018 gradi: un 17HS19-1684S-PG100.

Per pilotare il motore mi avarrò di una scheda spinta da un TBH7128 (al lato lo schema) comandata da un Arduino Mega, corredata da una bussola magnetica e da un GPS per adiuvare lo stazionamento della struttura (puntamento al Polo).
In più il tempo di esposizione sarà controllato da un sensore di luce sensibile da 0,000118 a 88000 Lux: il TSL2591 abbastanza sensibile quindi da impedire all'inquinamento luminoso di sporcare il sensore di una qualsiasi DSRL.
Questo per ora è quanto. Piuttosto ambizioso come progetto, no?



Errata corrige: L'immagine relativa al driver THB7128 aveva sbagliati i riferimenti della piedinatura. Questi ora sono corretti e aggiunto alcune didascalie interessanti.

venerdì 18 agosto 2017

Fuori UNO!

E vai!
Il test del CNY 75B come optoisolatore per la DSRL è andato benissimo. Appena avrò tempo farò lo schema elettrico e lo pubblicherò.
Interessante è notare che come fonte  di energia per i test ho usato un vecchio Arduino UNO clone ormai briccato da da tempo. Anche se inutilizzabile, si è reso utile anche così!