aGotino - un goto con Arduino

Conoscete aGotino? No? Vabbè, ho appena inventato il nome!

Come seguito della prima puntata in cui ho descritto un inseguimento AR ecco l'evoluzione che, seppur ancora con tante migliorie in cantiere, sembra funzionare a dovere :cool:


Aggiornamento: le ultime novità e set comandi sono sempre disponibile sulla pagina di Github o leggendo gli ultimi post della discussione.


Cos'è

Un sistema goto, o quasi (la "a" sta per almost), basato su Arduino Nano (o Uno), un microcontrollore grande 1,5x4cm: qui sta una particolarità del progetto in quanto sfrutta in maniera furba le risorse e riesce ad essere molto compatto (ed economico).

Il "quasi goto" è per ora relativo, l'idea nasce con lo scopo di risolvere un problema: dopo aver puntato un oggetto noto e ben visibile, raggiungerne uno sconosciuto nelle vicinanze. Vi capita mai di chiedervi "chissà se riuscirò a vederlo con il mio telescopio e questo seeing" e poi "chissà se non l'ho visto perchè ho puntato da un'altra parte...”.

Ecco il risultato:

Allegato 40690

Funzionalità

Inseguimento in AR a velocità siderale (1x)
Due pulsanti, uno per avanzare (prima pressione) o indietreggiare (seconda pressione) in AR e l'altro in Dec (8x).
Tramite seriale (USB per ora) si può guidare inviando i seguenti comandi:

• ±RRRR±DDDD: muovi di RRRR' e DDDD' (primi di grado) in AR e Dec,
• sHHMMDD±DDMMSS: imposta (s = set) la posizione corrente. Esempio per Altair: 19h 51m 47s, +08° 52' 06" digitare s195147+085206
• gHHMMDD±DDMMSS: vai alla (g = goto) nuova posizione: Esempio per M11: 18h 51m 05s, -06° 16' 12" digitare g185105-061612
• gMnnn: vai all'oggetto Messier numero nnn
• -sleep disabilita il risparmio energetico (vedi oltre)
• +debug attiva la modalità debug mostrando molte più informazioni

Via USB si può ovviamente utilizzare un computer ma "sul campo" viene pratico un comune cellulare Android tramite cavo USB OTG (o adattatore, molti brand lo forniscono già nella scatola) e un’app come Serial USB Terminal.

Ecco come appare una sessione dal mio telefono in cui punto Altair (Alpha Aql) e mi muovo a M11.

Allegato 40691

Ovviamente la posizione raggiunta viene poi impostata come posizione corrente quindi si può continuare con i comandi “g”, avendo però cura di centrare ogni volta l’oggetto raggiunto nel caso non sia già perfettamente in centro.

Ecco una sessione da Shedar (alpha-Cas) a M103, M31 e poi Mirach (beta-And)

Citazione:

---

21:39:04.772 Connected to CH34x device
21:39:06.233 aGotino: READY and RUNNING
> s004031+563214
21:39:38.817 received: s004031+563214
21:39:38.817 Current Position Set
> gM103
21:40:06.640 received: gM103
21:40:06.640 Goto M103
21:40:06.640 *** moving...
21:40:18.066 *** ...done
> gM31
21:44:52.066 received: gM31
21:44:52.066 Goto M31
21:44:52.066 *** moving...
21:45:08.657 *** ...done
> g010944+353711
21:47:55.317 received: g010944+353711
21:47:55.317 Goto new RA/DEC
21:47:55.317 *** moving...
21:48:01.596 *** ...done

---

Lista della Spesa

Come nel progetto inseguimento AR, ma duplicate motore, driver, pulegge, cinghia e aggiungete un cavo telefonico RJ11 (a 4 fili) e due terminali femmina RJ11 per collegare il motore Dec al driver.

Allegato 40692

Questa volta ho costruito un telecomandino con una scatolina e due pulsanti, dettaglio:

Allegato 40693

Poi cavetteria quanto basta, connettori dupont e una crimpatrice (o una pinzetta se siete bravi) per costruire le varie connessioni, la cosa più tediosa del progetto: se qualcuno mi da idee buone su come farli meglio o è esperto di PBC si faccia avanti…

Allegato 40694

Il supporto per il motore Dec è una semplice piastrina zincata, ecco la foto (verniciata di nero):

Allegato 40695
Allegato 40696

Per il supporto motore AR, vedete il post per l’inseguimento AR

Allegato 40697

Il “cuore” si presenta così e sta poi coperto dalla scatola nera della montatura

Allegato 40698

Schema elettrico

Allegato 40699

Rispetto all’altro progetto si nota come i driver ricevono un segnale comandato su i pin MSx (azzurro) per abilitare o disabilitare il microstepping in modo da potersi muovere più velocemente. Il motore Dec è inoltre comandato da un segnale per andare in risparmio energetico (viola). La scelta della disposizione permette di affiancare il microcontrollore ai due driver e far ponte con connettori dupont per tenerli insieme.

Allegato 40700

Software

Ecco il cuore del sistema che fa dialogare le varie parti in maniera sensata, spero :confused:

aGotino su GitHub

Credits

Il progetto OnStep è qualcosa di molto più elaborato con un bel forum e molte informazioni, mi ha dato spunti su quali motori e pulegge scegliere e sulla fattibilità
Il progetto AstroEq in cui ho trovato conferme su alcune scelte tecniche.
Epsilonphoto per averci provato (penso il progetto non si sia mai concluso) ed aver messo in rete i risultati raggiunti.
Un qualche post che non ritrovo in cui si ipotizza l’utilizzo di parte del tempo tra gli impulsi di un motore per far svolgere operazioni utili anziché stare in attesa.

Questo forum e gli utenti più attivi che hanno contribuito a far risvegliare una passione sopita per l'astronomia proiettandola ben oltre a dove l'avevo lasciata!

Limiti e sviluppi futuri

Porta ST4: non c’è! Ma c'è spazio per metterla e studiando come funziona non sembra troppo complicato aggiungerla, ma non facendo astrofoto e non avendo una cam guida non avrei modo di testarla

Database di Oggetti: al momento in memoria c’è il catalogo Messier (ne ho ancora da vedere...), in un modo furbo per sfruttare al massimo l'hardware ridotto (PROGMEM), penso che un migliaio di oggetti aggiuntivi ci stiano (tipo NGC e IC di mag fino a 10). Non ci sono i pianeti e dovrei implementare un calcolo delle effemeridi e conoscere la data per poterlo fare… mi sto documentando, in ogni caso si possono sempre inserire le coordinate che si trovano nei vari software.

Collegamento wireless: collegare un PC o il telefono tramite cavo è scomodo, ma si può facilmente implementare il supporto seriale via bluetooth (ho giò il modulino per arduino, 8euro) o wi-fi.

Supporto Applicazioni (Stellarium, Skysafari etc): L'ho tenuto per ultimo ma va probabilmente per primo: implementare un protocollo di comunicazione noto per permettere ai vari software di comunicare. Ho dato un occhiata al Meade LX200 e, con qualche limite, dovrei aggiungerlo a breve…

Ma è fantastico, bravissimo! Un progetto in stile minimalista e quindi pieno di ingegno, mi ricorda i tempi dello Z80/81 ...

Ciao!

Grazie ;) Eh si tutti bravi con giga di Ram e migliaia di Hertz :sneaky:

Qualche limite c'è, ad esempio Arduino (Nano o Uno) ha un oscillatore (ceramico) interno non precisissimo, mi sembra possa sbagliare fino a 18 secondi ogni ora. Ovviamente nessun impatto in visuale o durante gli spostamenti ma per foto con lunghe pose aggiungere un oscillatore a cristalli potrebbe dare risultati migliori. Ma a quel punto conta molto di più l'autoguida per compensare anche le inevitabili imprecisioni della meccanica della montatura.

Il software sviluppato è molto preciso, anche troppo gestendo il secondo di grado, utilizzando full steps e poi microsteps per rifinire ogni spostamento, considerando il tempo perso nel muoversi per poi recuperarlo in AR. Per ora manca la possibilità di specificare eventuali laschi nei cambi di direzione, quindi bisogna assicurarsi che le cinghie siano tensionate bene e che i movimenti micrometrici non abbiano giochi.

C'è un problema che devo valutare relativo al risparmio energetico: il motore in Dec viene spento e messo in “sleep” quando non usato, i motori passo passo infatti rimangono alimentati anche da fermi e tengono il “passo” con forza, consumando corrente. Purtroppo però il driver che uso resetta la posizione (home position) al momento del risveglio, questo crea una rotazione improvvisa fino a 4 step (meno di un primo). Non mi sembra crei problemi (e si può disabilitare il risparmio energetico mandare il comando “-sleep”), però mi piacerebbe capire se esistono driver così compatti senza tale problema...

Un aggiornamento :biggrin:

Poter inserire le cifre AR&DEC per impostare le coordinate risulta estremamente flessibile ma... noioso! Ho pensato di caricare in memoria le stelle principali delle varie costellazioni in modo da richiamarle con un numero, tra queste stelle ci sono di sicuro tutte quelle che in visuale permettono di puntarci il telescopio facilmente. Non è stato semplice trovare la lista in coordinate Epoch 2000 ma alla fine il BSC5P - Bright Star Catalog pubblicato dalla nasa (tra mille e mille cataloghi) sembra essere il sorgente perfetto, unito ad un lookup dei nomi mantenuti nel progetto open source kStar.

Il catalogo stampabile con i numeri: https://imgur.com/ImxgBDJ.png

Ho poi esteso i comandi in modo da poter considerare entrambi i catalogi (Messier e Star List) sia per le operazioni di set (anzi il nome più appropriato è forse "sync", cioè dire al telescopio dov'è) che di goto, alla fine ecco la nuova lista di comandi:

• xSnnn: imposta (s = set) o vai (g = goto ) alla stella nnn. Esempio per Mirach (β-And): sS2 per impostarla come posizione corrente o gS2 per effettuare il goto
• xMnnn: imposta (s) o vai (g) all'oggetto messier nnn.
• xHHMMDD±DDMMSS: imposta (s) o vai (g) alle coordinate. Esempio per Altair: 19h 51m 47s, +08° 52' 06" digitare s195147+085206 o g195147+085206
• ±RRRR±DDDD: muovi di RRRR' e DDDD' (primi di grado) in AR e Dec,
• ±speed nuovo comando per aumentare o ridurre la velocità nei movimenti micrometrici in AR o DEC (8x per default)

Una sessione da Vega (Star 144) a M57 risulta quindi ora più compatta dovendo digitare solo sS144 e poi gM57:

http://imgur.com/FGXfZPj.png

Con questa aggiunta direi che per le mie esigenze attuali son soddisfatto, manca il catalogo NGC e il collegamento con software esterni: quest'ultimo più per il gusto di riuscirci che perché poi io lo utilizzi sul campo :rolleyes:

... umidità pazzesca ma cielo limpido con luna quasi piena, sicuramente non la sera ideale per osservare alcunché ma per far delle prove con questa soluzione di "augmented starhopping".

Son passato dal puntare a mano la facile Mirfak (α-Perseo S161) per un goto a M34, poi a Mirach (β-And o S2) e M31 - a 75x con il 10mm, a 0.69° di campo reale tutti gli oggetti stavano a centro campo senza bisogno di correzioni. Poi ho puntato manualmente Cappella (α-Auriga S18) e planato su M36 prima e poi M37 (che non avrei visto causa luna e umidità). A quel punto ho esagerato e osato con la barlow (169x) a 0.31° di campo reale e tornato indietro a M36 e Cappella: entrambi a centro campo. :biggrin:

Tutto ciò dopo un discreto allineamento equatoriale (intendo, la polare era dentro il crocicchio del cannocchiale polare, al centro ma non di certo al punto perfetto). Direi che come aspettative ci siamo :cool: Non so cosa succede se gli faccio fare tutta la volta celeste, ma non è certo per questo che è progettato (ma per curiosità prima o poi ci provo!).

Devo diminuire un po' le velocità e implementare una accelerazione e decelerazione migliore perché temo di stressare troppo le cinghie. Il problema del risparmio energetico, con il motore DEC che scatta in posizione di riposo fino a 4 steps (ne occorrono 6 per un primo di grado) non crea poi complicazioni, a meno di una piccola vibrazione iniziale l'errore indotto è in effetti minimo

Complimenti, veramente un ottimo lavoro, sei un genio

Grazie! Ma non esageriamo dai... a dire il vero sono un po' stupito che funzioni tutto :thinking:

Ecco un po' di cinema ;)

Supporto sync&slew tramite il protocollo Meade LX200 - mi ha dato qualche filo da torcere perché alcune implementazioni hanno lievi differenze e la velocità con cui alcuni software chiedono l'aggiornamento della posizione ha richiesto di ottimizzare come Arduino legge i dati dalla seriale.

Testato via INDI (driver LX200 Basic) con Cartes du Ciel, KStars e Stellarium e con quest'ultimo anche direttamente (visto che supporta il protocollo LX200 nativamente).

Un paio di screenshot:

Allegato 40840

Allegato 40841

E un piccolo video, mi fa un certo effetto vedere che funziona :cool:

https://youtu.be/PdkoGX5PcDA

Bene ora la a di aGotino direi che da "almost" può diventare un semplice "a" - A GOTo with arduINO :whistling:

Wow impressionante! Tutto sviluppato molto rapidamente poi.

Una domanda: ma non è equivalente a un tablet/smart con SkySafari o Stellarium + connessione WiFi all'hand control? Immagino che un vantaggio sia sostituire completamente l'Hand Control per chi non ce l'avesse, giusto?

In altre parole, in che situazione/configurazione del telescopio si applica?

Ciao!

grazie @Zoroastro - gli ultimi due week-end uggiosi hanno contribuito... ora spero di spendere più tempo ad osservare!

Il mio uso principale è: esco, faccio il solito allineamento alla polare e comincio ad osservare. Se c'è qualche oggetto ostico da visualizzare, o se voglio arrivarci senza spendere tempo, attacco il telefono all'USB e comando il telescopio come descritto sopra: gli dico dove sono (comando s) e dove andare (comando g) - piuttosto pratico, niente allineamenti a più stelle etc. perché avendo fatto una allineamento polare discreto poi i "salti" che chiedo sono abbastanza limitati (30° o molto meno), visto che qualche stella ben luminosa nella star list c'è sempre.

Quindi si, direi che rimpiazza l'hand control e la necessità di fare allineamenti e riallineamenti se giri il tubo (es. newton)

E poi volendo lo si comanda con stellarium o altri software che supportano il protocollo LX200, come mostrato nel post precedente: almeno via USB.
Non so però se da tablet/smartphone ci siano app che permettono di collegarti via USB/seriale direttamente: penso sia necessario aggiungere il supporto bluetooth. Basta il modulino apposito (vedi qui), che tra l'altro ho già: a livello software non cambia assolutamente nulla, una volta collegato il modulino ai 5v/massa e ai due pin TX/RX di Arduino si fa il pairing con il telefono e non vedo perché non dovrebbe funzionare "out of the box". Magari ci provo...

Citazione:

---

Originariamente Scritto da gspeed

Non so però se da tablet/smartphone ci siano app che permettono di collegarti via USB/seriale direttamente: penso sia necessario aggiungere il supporto bluetooth.

---

Infatti è così, non puoi collegare in filare direttamente uno smart/tablet alla RJ11 della montatura, io ho realizzato un ricevitore WiFi con uscita seriale che collego alla porta RJ11 dell'hand control, trovi la descrizione qui.

Poi basta settare IP e porta giusti in SkySafari, ovviamente col solito protocollo farlocco LX200, e puoi pilotare la montatura da tablet con connessione WiFi AP al modulo WiFi /convertitore UART. La differenza è che per collegarti alla porta AUX invece che alla RJ11 dell'Hand Control serve aggiungere un altro modulo che converte il segnale seriale.

Ciao!

@gspeed , @Zoroastro complimenti ad entrambi, i vostri progetti sono molto interessanti. Tornando al sistema agotino, sarebbe possibile utilizzarlo per autoguida a lunghe pose? Ad esempio con l'aggiunta di un modulo Raspberry con phd2? Ne ho letto su questo stesso forum, potrebbe essere una soluzione?

A naso direi che l'Arduino non serve se usi un Raspberry per pilotare la montatura, ad esempio caricandoci Indigo Sky o una delle suite basate su INDI (Astroberry, Stellarmate, NAFA Box etc). Con il Raspi puoi collegare una delle sue porte USB all'Hand Control con cavo USB-Seriale oppure USB-miniUSB.

Altra soluzione "cheap" è pilotare il WiFi del mio progettino con PC e ASCOM, o con PC/Linux ed Ekos oppure Indigo (funziona, testato da me).

Se non hai un HC invece l'Agotino è più adatto, a sentimento.

Ciao!.

Grazie mille, ma io intendevo che sarebbe interessante partire da una montatura senza motori, e trasformarla in una a inseguimento con autoguida, senza l'uso di PC. Mi piace molto la soluzione con Arduino, ma mi pare di capire che ancora non è predisposto per autoguida.

Citazione:

---

Originariamente Scritto da Lorenzogibson

... Tornando al sistema agotino, sarebbe possibile utilizzarlo per autoguida a lunghe pose? Ad esempio con l'aggiunta di un modulo Raspberry con phd2?...

---

Cavoli mi fai venir voglia di approfondire l'astrofotografia... chissà prima o poi. Facendo due calcoli aGotino nella configurazione proposta arriva a 53 microsteps/sec o 0,281 arcsec/microstep, da quel (poco) che so sono buoni valori per fare astrofotografia. Manca però la correzione dell'errore periodico (PEC) e l'autoguida - penso che quest'ultima renda meno importante la prima.

Per l'autoguida, pensavo che aggiungere una porta ST4 fosse la soluzione, e non mi sembra difficile da fare dopo aver studiato come funziona, visto che ho vari pin liberi. Ma ora che mi hai fatto approfondire phd2 ho capito che forse è roba vecchia: attacchi il pc (ad es. Raspberry PI) alla camera e ad Agotino con driver INDI, tutto via USB, php2 vedrà la montatura e potrebbe funzionare - dico potrebbe perché al momento penso manchi una piccola parte software: quali comandi (LX200) manderà phd2 ad aGotino per correggere il tiro? Dovrei assicurarmi che siano tra quelli supportati. Non ho una camera guida e non faccio foto ma mi sembra che phd2 abbia la possibilità di simularle... mi hai fatto venir voglia di provare.

Come ha accennato @Zoroastro, potenzialmente il Raspberry PI potrebbe sostituire anche il microcontrollore Arduino, collegandolo direttamente ai driver dei motori Nema via uscite GPIO della scheda - ma non penso ne valga la pena perché andrebbe programmato in "RTC" (real time clock) e non mi sembra nasca per quello. Le varie astro-distribuzioni Raspberry sono difatto dei piccoli PC con Linux e vari software pronti per l'astrofotografia: il controllo della montatura non avviene direttamente, ma interfacciando il Raspberry al microcontrollore della stessa o all'hand controller.
Potrei aver detto qualche inesattezza ma per ora questo è quel che ho compreso.

Anch'io fino ad ora non mi sono appassionato all'astrofotografia, ma l'idea di autocostruirsi il goto e l'autoguida, mi attira molto, anche per il notevole risparmio rispetto a soluzioni convenzionali. Mi piace molto anche l'idea di utilizzare piattaforme di software libero e di partecipare a gruppi di utenti indipendenti, con condivisione di dati e di esperienze.
Grazie ancora per il vostro impegno, spero di poter contribuire , magari con qualche idea pratica ( col software sono negato..)

Grazie @Lorenzogibson - ho dato un'occhiata più nel dettaglio a phd2 e in effetti tutto potrà funzionare ma occorre almeno riconoscere i comandi per il "pulse guide" che phd2 manda tramite i driver indi via seriale/usb, comandi :Mxyyy# o simili dove x indica i punti cardinali (n,s,w,e) e yyy sono i millisecondi dell'impulso. Al momento aGotino non li supporta (li ignora) ma basterà aggiornare il software in futuro per considerarli - interessante, pensavo vi fosse bisogno di aggiunte hardware per l'autoguida (st4), mentre a questo punto veramente le espansioni sono solo a livello di codice (il che rende tutto più semplice).

Riguardo il codice, ho aperto un Repository in GitHub, uno tra i siti di riferimento per progetti open source, questo sarà il posto in cui trovare gli ultimi aggiornamenti / comandi disponibili etc.

aGotino su GitHub

Adesso scomodo @etruscastro per vedere se mi aggiorna il secondo post rimuovendo i vecchi links...

Citazione:

---

Originariamente Scritto da gspeed

aGotino su GitHub

Adesso scomodo @etruscastro per vedere se mi aggiorna il secondo post rimuovendo i vecchi links...

---

vuoi che ti modifico questa linea?:

Citazione:

---

Originariamente Scritto da gspeed

Codice C Arduino

aGotino.ino

---

Se puoi togliere tutti e tre i link e mettere solo quello a github. Grazie!

controlla se va bene, altrimenti mandami tutto in pvt! ;)

Perfetto grazie!

Ho aggiunto un breve video che mostra come uso aGotino, starhopping quanto basta e quando serve punto un oggetto ben visibile e prendo l'aiutino da casa :whistling:

https://youtu.be/YF_J7_7lyB4

Fantastico, il mio prossimo acquisto sarà sicuramente una exos2 senza goto

Se stai dietro al sito Display Items Bresser, ti può saltare fuori nuova a 260€ circa..

Ciao a tuti,
mi sono appena iscritto per commentare il progetto di motorizzazione AR e scorrendo ho scoperto anche il progetto aGotino, innanzitutto lavoro fantastico e grazie per la condivisione a gspeed, mi metterò a testa bassa per "copiare" questo progetto e se sarà utile potrò contribuire disegnando i particolari plastici con Solidworks così che chi vorrà potrà farsi stampare i pezzi "quasi" industriali.
Mi servirà un aiuto per il software, io sono fermo al Pascal... :rolleyes::angel:
Come dicevo sono nuovo e spero di non avere fatto casini nel citare i nomi, grazie ancora.
RobertoV ;)

@RobertoV , prima di postare è gradita una presentazione nella sezione dedicata...:whistling:

Grazie @RobertoV! Per il software chiedi pure e certo non sarebbe male aver dei modelli 3D per i supporti [emoji1303]

Ho appena sistemato un bug... non da poco: sapete cos'è il Side of Pier? No? Neppure io lo sapevo ma leggendo alcune note tecniche su phd2 saltava fuori, visto che phd2 si aspetta che la montatura lo comunichi per poter mandare gli impulsi guida in modo corretto.

La terrazza da cui osservo è libera verso Est, da Nord a Sud e tutti i miei test li ho fatti con il telescopio a Ovest della montatura, puntando verso Est: ecco il Side of Pier rappresenta la posizione del tubo rispetto alla montatura.

Due giorni fa in prima serata, punto M15 (con luna) ma visto che ho un tetto verso ovest per guadagnare mezzo metro, faccio il "salto del meridiano" e porto il tubo a Est. Imposto M15 come posizione corrente (s M15), mando il comando per andare su M2 (g M2) e il tubo va verso Nord anzichè verso Sud :shock:

Qualche istante di smarrimento ma poi connetto le cose: perché, se cambia il Side of Pier, il motore Dec deve invertire le direzioni!!!! Come ho fatto a non pensarci prima... :mad:

I sistemi guida goto commerciali prevedono l'allineamento a più stelle e poi non ti permettono di allentare le frizioni e muovere il telescopio come vuoi: questo obbliga a dover usare il goto per ogni movimento ma permette loro di sapere sempre in quale lato del meridiano si trova il telescopio e quindi possono gestire il motore Dec in modo appropriato.

aGotino è un sistema goto "ibrido", e qui sta la sua praticità: non è necessario fare allineamenti, si può far girare il tubo come si vuole (starhopping) e al momento opportuno, quando serve, si punta un oggetto conosciuto e ci si fa trasportare alla destinazione. Quindi non può sapere quale sia il "side of pier"... ma un astrofilo, anche alle prime armi lo sa!

Tutta questa pappardella per dire che:
aGotino assume per default che il telescopio sia a Ovest della montatura (i.e. di solito puntato verso Est)
per cambiare lato, si può:

• premere per 1 secondo entrambi i pulsanti
• inviare il comando +side

Quando si cambia il Side of Pier, i motori si spengono per 3 secondi mentre il led rosso rimane acceso per l'Est e lampeggia due volte tornando all'Ovest.

Cieli sereni e direzioni giuste!

Il side of pier è un'informazione critica e il protocollo ASCOM purtroppo lo gestisce talvolta male (errato). Già che ci sono ti segnalo il bel progetto analogo TeenAstro, basato sul concetto dell'FS2:

https://groups.io/g/TeenAstro/wiki/8988

Ciao!

Grazie - quel progetto l'avevo visto via Indi, e pensavo proprio di rendere compatibile aGotino con il loro driver Indi (o quello AP), visto che non ha senso inventare qualcosa di nuovo... vedremo.

questo progetto è fantastico!!

mi ha sempre appassionato l'ambiente arduino, durante il lockdown ci ho costruito un piccolo miniscavatore con i motori step, ma questa cosa dell'interfaccia con lo smartphone è molto interessante, e anche il discorso del database oggetti.

ho una domanda, qualche volta qui sul forum si legge qualche messaggio ( qualcuno l'ho scritto anche io ;) ) che accenna all'inseguimento di corpi celesti non prettamente naturali, quali satelliti, l'iss per esempio...e sempre si fa riferimento a montature motorizzate da prezzi stratosferici...

sarebbe possibile implementare un inseguimento di una traiettoria così veloce e mutevole in un'applicazione del genere con arduino?

Citazione:

---

Originariamente Scritto da gspeed

Grazie @RobertoV! Per il software chiedi pure e certo non sarebbe male aver dei modelli 3D per i supporti [emoji1303]

---

sì, sarebbe bello aprire magari una piccola collaborazione, anche io potrei contribuire per la progettazione in ambiente modellazione solida, io uso inventor, ma alla fine per la stampa 3d si salva sempre tutto in stl quindi va bene uguale

magari se riesci a fare dei piccoli disegni quotati quando hai tempo, perchè avendo dei disegni con le parti da stampare con le quote si può tradurre il tutto in file pronti per la stampa, altrimenti, non avendo il progetto sottomano fisicamente, non è possibile

Citazione:

---

Originariamente Scritto da DavideP

...'inseguimento di corpi celesti non prettamente naturali, quali satelliti, l'iss per esempio...e sempre si fa riferimento a montature motorizzate da prezzi stratosferici...

sarebbe possibile implementare un inseguimento di una traiettoria così veloce e mutevole in un'applicazione del genere con arduino?

---

Interessante! Direi che il limite non è Arduino e i motori stepper ma la montatura che prende il volo. Quanto impiega l'iss a fare un passaggio da orizzonte a orizzonte?

Citazione:

---

Originariamente Scritto da gspeed

Quanto impiega l'iss a fare un passaggio da orizzonte a orizzonte?

---

Dipende dalla traiettoria, da 5 min circa a quasi 7 min circa

Pensavo fosse più veloce! Mi sembra fattibile, ma si muove solo in AR o ha una traiettoria diversa? Se solo AR e riusciamo a sapere esattamente quanti secondi impiega a fare un giro completo si può calcolare come comandare gli impulsi del motore, e poi si può implementare facilmente un comando per impostare una velocità di tracking diversa da quella siderale.

Il calcolo per la siderale è:

Citazione:

---

MICROSTEPS_PER_DEGREE 12800 // = WormRatio*OtherRatio*StepsPerRevolution*Microsteps/360
// = number of motor microsteps to rotate the scope by 1 degree

STEP_DELAY 18699 // = (86164/360)/(MicroSteps per Degree)*1000000
// = microseconds to advance a microstep
// 86164 is the number of secs for earth 360deg rotation (23h56m04s)

---

è il numero 86164 che va cambiato...

Non sono pratico, qui trovi una lettura interessante (ma parecchio impegnativa)
https://digitalcommons.usu.edu/cgi/v...ntext=smallsat

Interessante si, ma mi sembra sia per qualcosa di più complesso: tracciare un satellite a partire da una camera che lo riprende... direi che magari ci pensiam tra qualche anno :)

Citazione:

---

Originariamente Scritto da gspeed

Conoscete aGotino? No? Vabbè, ho appena inventato il nome!...

---

Complimenti gspeed! :shock: ottimo lavoro, sicuramente utile a tutti gli smanettoni come me :angel:
Ho fatto la lista della spesa tutta su Amazon, per semplicità, maggiori tutele e certezze sulle date di spedizione. Ho speso per la configurazione completa AR DEC 120 euri, di certo non diventerà un Synscan ma non costa neanche 400 euri... lì ho trovato anche il motore stepper da 0,9 gradi/passo 25,6 euro/cad.

Sull'onda di questo bellissimo progetto perchè non pensare di implementare anche una guida assistita, con un cannocchiale in parallelo la telescopio principale e una telecamera (molto croppata) da puntare su una stella, per usarla per riconoscere il movimento e correggere aGotino nella guida? così si potrebbero fare prose di ore :rolleyes:

Ciao
RobertoV

Ottimo Roberto ;) Comprando dai vari siti linkati in prima pagina si risparmia qualcosa, ma la praticità di Amazon è altra cosa!

Il supporto per autoguida non sembra troppo difficile da implementare, la via più semplice (senza hardware aggiuntivo) è quella di riconoscere i comandi "pulse guide" di qualche driver INDI (come dicevamo sopra, TeenAstro or AstroPhysics senza inventarne di nuovi) così che phd2 possa guidare correttamente. Vedrò di aggiungere la parte software, ma non facedo astrofotografia e non avendo camera guida non avrò modo di testarlo...