Visualizza Versione Completa : 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 (https://www.astronomia.com/forum/showthread.php?33752-Motorizzazione-AR-per-Eq5-Exos2-Eq3-etc-etc) 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 (https://github.com/mappite/aGotino/) 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:
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 (https://www.amazon.it/EasyULT-Adattatore-Maschio-Femmina-MacBook/dp/B086PCKHH2/ref=sr_1_5?__mk_it_IT=%C3%85M%C3%85%C5%BD%C3%95%C3 %91&dchild=1&keywords=usb+otg&qid=1603214105&sr=8-5) (o adattatore, molti brand lo forniscono già nella scatola) e un’app come Serial USB Terminal (https://play.google.com/store/apps/details?id=de.kai_morich.serial_usb_terminal&hl=it).
Ecco come appare una sessione dal mio telefono in cui punto Altair (Alpha Aql) e mi muovo a M11.
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)
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 (https://www.astronomia.com/forum/showthread.php?33752-Motorizzazione-AR-per-Eq5-Exos2-Eq3-etc-etc), 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.
40692
Questa volta ho costruito un telecomandino con una scatolina e due pulsanti, dettaglio:
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…
40694
Il supporto per il motore Dec è una semplice piastrina zincata, ecco la foto (verniciata di nero):
40695
40696
Per il supporto motore AR, vedete il post per l’inseguimento AR (https://www.astronomia.com/forum/showthread.php?33752-Motorizzazione-AR-per-Eq5-Exos2-Eq3-etc-etc)
40697
Il “cuore” si presenta così e sta poi coperto dalla scatola nera della montatura
40698
Schema elettrico
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.
40700
Software
Ecco il cuore del sistema che fa dialogare le varie parti in maniera sensata, spero :confused:
aGotino su GitHub (https://github.com/mappite/aGotino)
Credits
Il progetto OnStep (https://onstep.groups.io/g/main/wiki/3860) è 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 (https://www.astroeq.co.uk) in cui ho trovato conferme su alcune scelte tecniche.
Epsilonphoto (https://epsilonphoto.weebly.com/arduino--stellarium.html) 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…
Zoroastro
21-10-2020, 06:12
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 (https://heasarc.gsfc.nasa.gov/W3Browse/star-catalog/bsc5p.html) 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 (https://edu.kde.org/kstars/).
Il catalogo stampabile con i numeri: https://imgur.com/ImxgBDJ.png (https://www.mappite.org/stars/aGotino-StarList.pdf)
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
Lorenzogibson
28-10-2020, 08:38
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:
40840
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:
Zoroastro
02-11-2020, 07:55
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) (https://www.amazon.it/TOOGOO-Bluetooth-Wireless-seriale-Arduino/dp/B071G7W887/ref=sr_1_6?__mk_it_IT=%C3%85M%C3%85%C5%BD%C3%95%C3 %91&dchild=1&keywords=android+serial+bluetooth&qid=1604309534&sr=8-6), 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...
Zoroastro
02-11-2020, 10:12
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 (https://www.astronomia.com/forum/showthread.php?34354-Pilotare-in-WiFi-la-montatura-senza-spendere-200-euro-la-SCATOLA!).
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!
Lorenzogibson
04-11-2020, 15:15
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?
Zoroastro
04-11-2020, 17:18
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!.
Lorenzogibson
04-11-2020, 20:01
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.
... 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.
Lorenzogibson
05-11-2020, 17:41
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 (https://github.com/mappite/aGotino)
Adesso scomodo etruscastro per vedere se mi aggiorna il secondo post rimuovendo i vecchi links...
etruscastro
06-11-2020, 07:09
aGotino su GitHub (https://github.com/mappite/aGotino)
Adesso scomodo @etruscastro (https://www.astronomia.com/forum/member.php?u=41) per vedere se mi aggiorna il secondo post rimuovendo i vecchi links...
vuoi che ti modifico questa linea?:
Codice C Arduino aGotino.ino (https://mappite.org/stars/aGotino.ino)
Se puoi togliere tutti e tre i link e mettere solo quello a github. Grazie!
etruscastro
06-11-2020, 07:23
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
Lorenzogibson
09-11-2020, 11:38
Fantastico, il mio prossimo acquisto sarà sicuramente una exos2 senza goto
frignanoit
09-11-2020, 12:10
Se stai dietro al sito Display Items Bresser, ti può saltare fuori nuova a 260€ circa..
RobertoV
20-11-2020, 22:39
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 ;)
Red Hanuman
21-11-2020, 06:57
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!
Zoroastro
23-11-2020, 18:14
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 (https://www.indilib.org/devices/mounts/teenastro-mount.html) (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?
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
...'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?
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 è:
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/viewcontent.cgi?httpsredir=1&article=3384&context=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 :)
RobertoV
25-11-2020, 13:04
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...
RobertoV
28-11-2020, 22:38
Il “cuore” si presenta così e sta poi coperto dalla scatola nera della montatura...
Ciao,
da GitHub ho copiato il listato per aGotino, non trovo però il catalogo Meisser, dove posso trovarlo, immagino questo file debba essere nella stessa direttori del file Arduino.
Grazie per il tuo supporto
RobertoV
È il file catalogs.h che contiene i catologhi. Puoi guardare il commento in testa al file per dettagli.
Ieri ho aggiunto anche gli oggetti NGC fino alla mag 11 ;)
etruscastro
29-11-2020, 07:57
RobertoV presta attenzione agli "infiniti" quote che inserisci, sono vietati dal regolamento, i tuoi precedenti li ho modificati io!
RobertoV
29-11-2020, 08:16
grazie etruscastro, purtroppo però non ho capito il senso di: infiniti quote che inserisci, quindi potrei rifare l’errore, scusa ma non sono pratico dei forum, è l’unico al quale sono iscritto e ci sono da pochi giorni.
Red Hanuman
29-11-2020, 08:26
RobertoV , è esattamente quello che hai appena fatto. Non quotare il messaggio immediatamente superiore. Piuttosto, per richiamare l'attenzione dell'utente, usa il tag (@NickUtente).
etruscastro
29-11-2020, 08:35
esatto, e se devi quotare un post piuttosto lungo puoi anche "tagliarlo" e ridurlo solo ai termini tecnici che ti occorre evidenziare.
tutto molto semplice, abbiamo poche regole e vedrai che entro pochissimo sarai un utente TOP :)
RobertoV, per aggiungere un messaggio puoi far click sul pulsante "Rispondi alla discussione" in basso a sinistra, anzichè il tasto "Rispondi Citando" sotto a destra di ogni messaggio.
https://imgur.com/FFxRF0Wl.png
E se vuoi proprio richiamare un messaggio precedente con "Rispondi Citando", ricordati di modificarlo in modo da lasciare evidente solo la porzione a cui ti riferisci. Tutto ciò aumenta le leggibilità del forum. Per attirare l'attenzione di un utente anteponi il carattere "@" al nome, così che riceverà una notifica, ad esempio adesso chiedo una cosa ad Etruscastro.
etruscastro ti chiederei un'altra cortesia, visto che il progetto evolve sarebbe meglio mettere anche nel primo post una nota, prima della sezione Cos'è. Se possibile puoi aggiungere:
Edit: le ultime novità e set comandi sono sempre disponibile sulla pagina di Github (https://github.com/mappite/aGotino/) o leggendo gli ultimi post della discussione
Grazie
etruscastro
30-11-2020, 11:34
fatto! ;)
p.s. controlla sempre la formattazione è quella che mi chiedi...
RobertoV
30-11-2020, 12:33
grazie gspeed per il consiglio, vediamo se nella mia zucca c'è entrato come fare per evitare di prendermi rimproveri (ovviamente giustificati) dai moderatori.
Venendo invece alle cose interessanti, ho risolti tutti i problemini di copia dei codice aGotino per Arduino, lo so fa ridere, in pratica bisogna prestare attenzione a che il testo venga copiato in Ascii anziché Unicode, quindi ho caricato tutto sulla scheda Arduino Nano e dal terminale ho visto il primo messaggio incoraggiante: ...agotino ready :awesome: questa sera monto il motor driver e do fuoco alle polveri ;)
Grazie mille per tutto il lavoro che hai fatto e per quello che farai, cieli sereni
RobertoV
Lorenzogibson
30-11-2020, 12:33
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...
Ma in questo modo serve un computer portatile, o sbaglio? Quindi un po' di hardware va per forza aggiunto...
Secondo me, la cosa più comoda rimane quella di aggiungere un piccolo modulo Raspberry, con installati i software astronomici del caso, controllabile nativamente via wifi col telefonino o il tablet.
Almeno per me, che non ho un portatile Windows e che comunque troverei scomodo da abbinare alla montatura e poco portatile.
etruscastro grazie - come formattazione l'avrei forse messo in corsivo (lasciando "Edit:" or "Aggiornamento:") ma va bene anche così: lo scopo è non far sembrare che quanto c'è scritto nel primo post sia lo stato finale.
RobertoV benone, in bocca al lupo! Controllo quanto dici riguardo unicode/ascii, non ho cambiato alcun default sul setup dell'ide di arduino.
Lorenzogibson, per usare l'autoguida servirà un computer esterno, collegato in USB o, come scrivi, un RaspberryPI con software Indi o simili (sempre collegato ad aGotino via usb) a cui ti colleghi via wi-fi da pc/smartphone. Con "senza hardware aggiuntivo" intendevo senza aggiungere una porta ST4 ad aGotino - visto che oramai mi sembra lo standard sia phd2 che comanda in maniera autonoma via usb.
etruscastro
30-11-2020, 17:12
@etruscastro (https://www.astronomia.com/forum/member.php?u=41) grazie - come formattazione l'avrei forse messo in corsivo (lasciando "Edit:" or "Aggiornamento:") ma va bene anche così: lo scopo è non far sembrare che quanto c'è scritto nel primo post sia lo stato finale.
basta solo dirlo, sono io che ti chiedo come vuoi le modifiche! ;)
RobertoV
30-11-2020, 23:03
ciao gspeed,
dopo avere con successo programmato Arduino Nano (il firmware funziona a dovere e risponde ai comandi) ho completato anche la costruzione dell'hardware con i due stepper motor driver, sembra esserci un problema di rotazione del motore di AR.
Guardando bene le due specifiche, quella dello schema elettrico che hai fornito con il progetto aGotino 41316 e quella del motor driver DRV8825 41317, si nota una incongruenza nella connessione delle due bobine del motore Stepperonline 17HM15-0904S 41318 , potresti cortesemente verificare se effettivamente c'è una discrepanza?
Avendo a che fare con motori con magnete permanente, immagino la fase di eccitazione delle bobine non sia trascurabile.
Una verifica credo possa essere utile anche per altri che come me vogliono costruire aGotino.
Grazie per la pazienza e per i supporto, cieli sereni a tutti.
RobertoV
P.S. in merito alla questione del codice Ascii o Unicode, non intendevo dire che fosse un errore nel codice di aGotino ma volevo soltanto segnalare che la copia del codice dal browser richiede che questo venga fatto in Ascii perché il compilatore di Arduino non riconosce ad esempio la / se è in Unicode.
Roberto, un’incongruenza c’è nel componente (preso dalla libreria di Fritzing) che raffigura il driver: la numerazione dei pin per le bobine non corrisponde alla numerazione sulla scheda, numeri e lettere sono invertiti. Se segui la sequenza dei colori rappresentata (blu-rosso-giallo-verde) in figura dovrebbe funzionare. Ma Dec funziona? Sono analoghi se non erro. Fammi sapere!
RobertoV
01-12-2020, 07:55
Ciao gspeed, in effetti per chi acquista componenti diversi da quelli che hai previsto nel tuo progetto, come ho fatto io acquistando i motori da Amazon, può trovare qualche difficoltà, che ho risolto non seguendo la mappa colori ma le indicazioni di polarità nella specifica del costruttore del motore, come si vede nella foto che avevo allegato precedentemente.
Però nel mio caso, avendo bypassato la problematica della polarità delle bobine seguendo lo schema, il problema era di natura molto più banale, come sempre... :angel: il motore di AR tutto sommato ruotava quando andava in ricerca e faticava, assorbendo quasi 3A dall'alimentatore quando era in inseguimento.
Cos'era? il trimmer della corrente di limitazione appena spostato, come l'ho ruotato leggermente ha preso a funzionare a meraviglia assorbendo 800mA in inseguimento e 1-1,5A in ricerca! ;)
Questa sera monto tutto sul telescopio, grazie infinite e cieli sereni e senza Luna :D
RobertoV
Ciao gspeed, in effetti per chi acquista componenti diversi da quelli che hai previsto nel tuo progetto, come ho fatto io acquistando i motori da Amazon, può trovare qualche difficoltà, che ho risolto non seguendo la mappa colori ma le indicazioni di polarità nella specifica del costruttore del motore,...
Se non erro tu hai acquistato esattamente motore e driver come i miei, se non hai seguito i colori dei 4 fili dei motori come da schema elettrico, direi che l'eccitazione delle bobine sarà invertita e quindi AR andrà al contrario (poco male ma dovrai adattare il codice).
Riguardo il trimmer, in effetti non l'ho messo in evidenza nel primo post ma è da regolare in modo da non superare 1A (è scritto nel post della sola motorizzazione AR).
... attendo che tu finisca l'opera e poi semmai disturbiamo Etruscastro nel caso ci sia da aggiungere qualche indicazione importante in prima pagina!
RobertoV
03-12-2020, 07:10
ri-ciao gspeed,
come vedi anche il mio aGotino 41354 sta iniziando. prendere vita :sneaky: e lavorandoci su già mi frullavano delle idee in testa che vorrei condividere con te e con tutti quelli che credono in questo progetto e vogliono sperimentarlo, qui ho fatto un riassunto 41355
per ora è tutto, passo e chiudo
ciao
RobertoV
Ottimo, dai che nasce tra poco!
Grazie per i suggerimenti, di sicuro aggiungerò un comando "info" a breve per vedere i settaggi corretti.
Riguardo l'inclinometro, ottima idea, per quanto l'utente sappia sempre da che parte è il tubo di sicuro ci si dimentica di impostare il side of pier di tanto in tanto. La difficoltà sta nel dove metterlo in modo da rendere il cablaggio poco invasivo. Tra l'altro non serve neanche un inclinometro, basta un tilt sensor (http://giocarduino.altervista.org/e07-sensore-tilt.pdf) da pochi centesimi.
RobertoV
03-12-2020, 23:22
Ciao gspeed,
prima uscita con aGotino 41360 e secondo il principio che la fortuna è cieca e la sfiga ci vede benissimo :wub: entrambi motori ruotano a rovescio, quindi domani provvederò a invertire le bobine degli stepper e dovrebbe essere a posto, tempo permettendo domani sera mi aspetta qualche ora al freddo :angel:
Sia pure con le poche prove fatte, ti assicuro che sarebbe veramente necessario modificare la modalità di funzionamento dei bottoni (invece di fermare il movimento sul target il motore inverte la rotazione e non fai che rincorrere il posizionamento), anche l'inserimento diretto del valore di velocità è altrettanto fondamentale, altrimenti passi il tempo a digitare +speed...+speed... e poi -speed...-speed...
Per quanto riguarda le modifiche penso possa essere utile anche una piccola funzione per leggere la tensione della batteria, visto che Arduino ha diversi pin analogici a disposizione.
Spero che queste informazioni possano essere utili anche ad altri :rolleyes: cieli sereni ;)
RobertoV
P.S. ho visto che utilizzavi Stellarium per inviare comandi ad aGotino, puoi fornirci qualche ulteriore dettaglio su come fare?
Roberto, mi confermi che non hai collegato i fili dei motori seguendo i colori dello schema di aGotino, corretto? Perchè mi sarei aspettato che andassero nella direzione giusta. A meno che i motori non siano montati al contrario ma non mi sembra dalla foto (e non penso sia possibile, almeno non nella exos 2). Dovrei forse inserire un flag in modo da poter impostare la direzione via software.
Riguardo quanto dici sul comando +speed, non capisco come lo usi: questo comando serve per variare leggermente la velocità dei movimenti micrometrici, a bassi ingrandimenti mi è capitato di voler andare più veloce ma se devi muovere il telescopio su ampi spazi, stacchi le frizioni e lo muovi a mano. Nota che i movimenti micrometrici tramite i pulsanti servono per centrare l'oggetto che intendi guardare ma non aggiornano la posizione corrente. Questo non toglie che possa implementare quel che dici, per ora puoi facilmente aumentare il valore dell'incremento, nella funzione agoto() la linea:
int d = (s.charAt(0) == '+')?4:-4;
cambi i 4 (4x) con 8 o 12 per avere un incremento più sostanzioso. Se invece vuoi che per default la velocità sia maggiore, puoi cambiare l'8 in 12 o 16 nelle variabili all'inizio:
unsigned int RA_FAST_SPEED = 8; // speed at button press, times the sidereal speed
unsigned int DEC_FAST_SPEED = 8; // speed at button press
Sulla funzionalità del pulsante, io mi trovo bene così com'è - un click per una direzione, un altro click per quella opposta (o subito un paio di click a distanza di mezzo secondo), ma forse è perchè mi sono abituato.
Ho visto che hai montato il motore Dec con una sola vite, riesci a mantenerlo stabile? Io ho messo una piastrina e due viti (come da foto in prima pagina) altrimenti ruotava quel poco e la cinghia diventava lasca. Quando ruoti a mano la puleggia del motore in una e nell'altra direzione non ci deve essere gioco: la puleggia collegata alla montatura deve subito muoversi (o, direi, al più avere uno step di gioco).
In bocca al lupo per la prova di stasera!
P.S. ho visto che utilizzavi Stellarium per inviare comandi ad aGotino, puoi fornirci qualche ulteriore dettaglio su come fare?
Trovi tanti tutorial online su come configurare un telescopio su stellarium (https://www.google.com/search?q=collegare+stellarium+telescopio&oq=collegare+stellarium+telescopio&aqs=chrome..69i57j0i22i30i457.4552j0j1&sourceid=chrome&ie=UTF-8), usa l'ultima versione del software e come driver scegli LX200 e puoi funziona come da video in prima pagina (https://www.astronomia.com/forum/showthread.php?34605-aGotino-un-goto-con-Arduino&p=373576&viewfull=1#post373576) (i.e. opzioni sync&slew). All'inizio assume di essere puntato al nord (reale), dopo il collegamento cerca l'iconcina vicino alla polare.
RobertoV
04-12-2020, 12:46
ciao gspeed,
grazie per per il continuo supporto che mi stai dando e spero sia utile anche ad altri, vado con ordine:
1. l'inghippo sulla rotazione del motore credo sia dovuta la semplice fatto che io ho acquistato un motore simile al tuo, ma non dello stesso brand, e non escludo che questo possa avere gli avvolgimenti A e B invertiti rispetto al tuo. Mi sono anche studiato il datasheet della Texas rispetto ai segnali del modulino motor driver acquistato e tutto corrisponde.
41365
41366
Per questo credo possa essere utilissima una costante globale, modificabile solo da sorgente, per definire la configurazione di base di rotazione dei motori (penso a chi acquistasse un motore diverso, piuttosto che si ingegni a montarli in modo diverso) così che poi tutto il codice successivo funzioni sempre allo stesso modo per tutti.
Se fosse possibile magari mi risparmi di dover ri-smontare tutto per invertire i fili :angel:
2. comando speed, confermo, se usato per la centratura nell'oculare è perfetto così come è, siccome però tornerebbe molto utile per comandare a distanza anche i macro movimenti (penso a starmene al calduccio in casa :wub: e magari in futuro con un attuatore rotativo inserire e disinserire anche la maschera di bathinov :cool:) lo renderebbe un sistema remotabile.
3. montaggio motore DEC, confermo, è una soluzione per ora provvisoria, ero troppo curioso di provare :) la migliorerò.
Ciao a presto
Roberto
P.S. se ti esce senza troppo sforzo che ne dici di aggiungere al codice la lettura della tensione di batteria con un partitore resistivo... :rolleyes:
Quel che dici su i motori può certo capitare, ma dalla foto del datasheet che avevi messo mi sembra che siano proprio gli stepperonline identici ai miei, quindi rispettando i colori dello schema dovrebbe funzionare, in ogni caso aggiungo una variabile, vorrai mica che qualcuno in Australia si ritrovi a dover modificare il codice :D
Non riesco questo week-end, nel frattempo basta invertire HIGH e LOW in ogni riga in cui viene usato raDirPin o decDirPin.
Finalmente una serata decente, per quanto umida, ed ho potuto testare un paio di aggiornamenti
Nuovo comando +info per mostrare le impostazioni correnti
Due variabili RA_DIR e DEC_DIR possono essere impostate per invertire il senso di rotazione dei motori, nel caso siano stati montati al contrario (in alcune montature è possibile) o con cablaggi invertiti o, per AR, nel caso di un viaggetto nell'emisfero australe ;)
Cieli sereni!
Zoroastro
14-12-2020, 09:47
Gspeed ammiro molto quello che stai ottenendo, bravo!
RobertoV
14-12-2020, 20:33
ciao gspeed,
è proprio vero, chi la dura la vince! ho replicato il progetto di aGotino con successo, questo grazie al tuo prezioso e ben dettagliato lavoro. Ieri sera con mia somma meraviglia ho puntato il mio newton 150/750 con mirrorless Lumix G7 visivamente alpha di Pegaso e ho dato il comando a aGotino di andare su M31
41461
(e vabbè li forse ci sarei arrivato anche visivamente) poi ho digitato M33 e meraviglia delle meraviglie la galassia triangolo è apparsa quasi al centro dello schermo!
Lo so, questo scatto farà sorridere la maggior parte di voi, ma io sono entusiasmato da questo primo successo e mi faceva piacere condividerlo qui
41462
Inizialmente non riuscivo a puntare gli oggetti e non ne capivo la ragione, nonostante tutto sembrasse a posto, poi ho scoperto che gli ingranaggi sono arrivati non erano 16 denti come da progetto ma bensì 20 denti... modificato il calcolo secondo le istruzioni ben descritte nel sorgente e sono arrivato a ieri sera.
Ovviamente l'appetito vien mangiando quindi non ho resistito a puntare sulla "fucina delle stelle" la mitica M42
41465
anche questo scatto non è perfetto, ma si sa il miglioramento non ha mai fine. :D
Un saluto particolare a gspeed,mi auguro che altri possano ottenere grandi successi grazie a questo semplicissimo e economico progetto
RobertoV
Wow!!! :cool:
Complimenti, non mi intendo di astrofotografia ma sono di sicuro affascinanti! Anzi adesso me ne metto una come sfondo del desktop ;) Che tempo di esposizione hai usato?
Contentissimo che tutto ti funzioni! ... e per fortuna ti è venuto in mente di contare i denti :twisted:
RobertoV
17-12-2020, 12:17
Wow!!! :cool:
...dai @gspeed (https://www.astronomia.com/forum/member.php?u=16831), non ci crede nessuno che non ti intendi di astrofotografia, con il fantastico lavoro che hai fatto con aGotino :D
le foto sono prese ancora con esposizioni molto brevi, perché qualche piccolo problemino sulla qualità dell'inseguimento ancora c'è, sono 30 scatti da 8 secondi ISO 5000 con reflex Sony alpha 7, tubo newton 150/750, seeing regular.
Ciao a presto e cieli sereni
RobertoV
RobertoV
18-12-2020, 23:29
ciao gspeed,
ho fatto un po si misure, per capire come migliorare la precisione del puntamento del telescopio con aGotino.
Sulla base delle formule indicate nel listato, sappiamo che la puleggia a 16 denti deve compiere un giro completo in 239,34 secondi, che corrispondono a 3 minuti, 59 secondi e 34 decimi.
Detto questo ho fatto una semplicissima verifica, ho messo un riferimento sulla puleggia e verificato in quanto tempo compiva un giro completo, e ho dovuto impostare la variabile STEP_DELAY a 18805, corrispondenti a 53,17 Hz, anziché 18699, per far si che il giro impiegasse appunto 239 secondi virgola qualcosa, come vedi in figura
41525
questo credo sia dovuto a due fattori, la precisione del quarzo e il carico meccanico, visto che in configurazione microstepper il motore riduce la sua coppia a meno del 10%.
Pensi sia una tesi corretta? è possibile che dipenda dal valore dettato sulla costante STEP_DELAY influenzi sia il movimento in AR che quello in DEC? sto sbagliando in qualcosa?
Grazie per un tuo commento
RobertoV
...
ho fatto un po' di misure, per capire come migliorare la precisione del puntamento del telescopio con aGotino....
RobertoV - interessantissimo il test che hai fatto! La precisione del tracking (inseguimento) o del goto (puntamento) hanno fattori diversi.
Per il Goto è importante la meccanica e l'assenza di giochi, visto che aGotino conosce quanti (micro)steps fare per muovere il tubo di un grado (MICROSTEPS_PER_DEGREE) si fa i calcoli e muove i passi necessari. A livello software la precisione è altissima un microstep muove di 0,28 arcosecondi. Eventuali errori di puntamento sono quindi dovuti alla meccanica. Anche nel caso il motore si perdesse qualche (full) step considera che occorrono bel 6.66 full step per fare un primo (ma in una montatura ben bilanciata non dovrebbe succedere). Per i test che ho fatto mi son sempre trovato l'oggetto nel campo inquadrato, al centro o entro 10' dal centro quando le cinghie erano piuttosto lasche.
I movimenti di AR&DEC per il goto non sono quindi influenzati dal valore dello STEP_DELAY.
Per il Tracking si muove solo AR, ed il calcolo sello STEP_DELAY è quanto serve proprio per far avanzare di un microstep alla giusta frequenza. Arduino ha un oscillatore ceramico non precisissimo, il test che hai fatto tu indica un errore di circa l'1% - mi sembrava che l'errore fosse un po' meno: in ogni caso quanto hai fatto direi che corregge l'errore, anzi... se lo facessi più a valle arriveresti anche a correggere l'errore periodico. Correzione che vorrei implementare via software prima o poi (non mi sembra troppo complesso), o che comunque penso diventi superflua con l'autoguida - perché è chiaro che la differenza che hai trovato in visuale non ha alcun impatto. Sarebbe interessante calcolare che impatto ha in fotografia. Il tuo test l'hai fatto togliendo la cinghia? (quindi può essere influenzato dal resto della montatura?)
Nelle foto di M33 (l'ho come sfondo!) le stelle a centro campo mi sembrano perfettamente circolari: sarebbe interessante vedere cosa succede con pose più lunghe - considerando anche l'eventuale non perfetto allineamento polare della montatura: nel mio caso infatti pur avendo trafficato con il canocchiale polare per stazionare al meglio, ho notato una deriva in declinazione più che in AR.
Se non ho fatto male i conti, la differenza dell'1% porta ad uno scarto di 100 microstep nei 239,34 secondi, che equivale a 25 microstep al minuto e quindi circa 7 arcosecondi. Tanto? Poco? Dipende dalla focale e dai pixel del sensore, penso si possa calcolare quale è il tempo di esposizione massimo senza guida per stare dentro il margine d'errore... che comunque hai corretto ;)
RobertoV
20-12-2020, 22:24
grazie gspeed per le precisazioni chiare e puntuali.
Ho approfondito la questione del puntamento e ti confermo di avere effettivamente trovato un problema meccanico, infatti la vite senza fine ha un movimento destra-sinistra che può introdurre un errore nel GOTO
41554
mentre invece, quando è in inseguimento sull'asse AR questo aspetto diventa ovviamente ininfluente, quindi confermo la tua tesi.
Risolverlo è stato abbastanza semplice, si svita il dado e si tira quanto basta la vite centrale, poi si serra nuovamente il dado.
Per quanto concerne invece l'errore in AR non appena il tempo sarà clemente farò delle lunghe esposizioni per vedere l'influenza della sommatoria degli errori (quarzo, e microstep mancati)
Grazie ;)
RobertoV
RobertoV
26-12-2020, 10:58
ciao gspeed, innanzitutto buone feste a te e famiglia.
Ho installato sul mio vecchio Toshiba Satellite Lubuntu 20.04, risolvendo al 90% i problemi di velocità, rispetto a Windows 7 (lo consiglio vivamente a chiunque avesse un PC in affanno di risorse), ora aGotino risponde ai comandi di Stellarium tramite il controllo diretto e protocollo LX200, rimane però un disallineamento tra le coordinate dell'oggetto puntato e il puntamento di aGotino
41641
e questo errore si amplifica sempre più, mano a mano di faccio puntamenti consecutivi
41642
hai una qualche idea del perché questo possa avvenire? può esserci un legame con il comando side of pier? come fa Stellarium a conoscere la posizione del telescopio?
ciao e grazie per il tempo che vorrai dedicare a rispondere, magari potrà essere utile anche a altri.
RobertoV
Ricambio gli Auguri!
Che versione di stellarium usi? Se non erro c'è un bug nella versione 0.19.x (si aspettava uno spazio dove non doveva esserci) nel protocollo di comunicazione. Nella mia esperienza, meglio usare indi che è più stabile, in ogni caso, per risolvere il problema prova così:
Installa l'ultima versione di stellarium (0.20.3) tramite i comandi sotto (nel repository di ubuntu, di default c'è proprio la versione 0.19, il primo comando sotto abilita un repository alternativo)
sudo add-apt-repository ppa:stellarium/stellarium-releases
sudo apt-get install stellarium
Assicurati di usare l'ultima versione del codice di aGotino.
Se il problema persiste... fammi sapere che ti dico come attivare il file di log con cui vedere i dettagli di ciò che succede.
Dai, che stasera sembra esserci bel tempo ;)
RobertoV
26-12-2020, 21:15
...beato te gspeed, qui piove a dirotto da questa mattina :D
Stellarium versione 0.20.3 aggiornato, sistema operativo Lubuntu 20.04, telescopio controllato da Stellarium su porta USB (riconosciuta e funzionante), l'unica nota stonata è che di tanto in tanto il video "sfarfalla" e per ovviare debbo zoommare dentro/fuori e alcune volte si blocca, segno che qualche problema sul driver della scheda video qualche problema deve esserci...
Ciao
RobertoV
RobertoV benone!
Dopo settimane di maltempo o nebbie serali ieri sono riuscito a guardare qualcosa, purtroppo la luna quasi piena e il seeing pietoso (nonostante un'ottima trasparenza del cielo) non han permesso un gran che di osservazioni, ma ho testato alcuni aggiornamenti minori,ora disponibili su github, e sperimentato una modalità di controllo remoto :cool:
Aggiornamenti
E' possibile impostare un numero diverso tra AR e DEC di microstep e microstep per grado. Questo permette di usare driver e pulegge differenti nei due assi oppure adattare aGotino ad alcune montature (tipo la eq3-2) che hanno un rapporto della vite senza fine differente nei due assi.
Accelerazione nei movimenti micrometrici in DEC, oltre a rendere più facile centrare un oggetto, l'accelerazione dovrebbe ridurre lo scatto quando il motore si sveglia dal risparmio energetico (sleep).
Controllo remoto wi-fi tramite Android e scrcpy
È possibile grazie a scrcpy (https://github.com/Genymobile/scrcpy) (screencopy), un programma per linux/windows/mac che permette di interagire direttamente con lo schermo del cellulare ed utilizzarne quindi ogni applicazione. Occorre attivare la modalità sviluppatore di Android (dietro le quinte usa adb) e poi lanciare alcuni comandi dal PC/Mac, nel link sopra i dettagli, un po' macchinoso la prima volta ma funziona benone (e consuma poca batteria ricordandosi l'opzione -S per tener spento lo schermo).
Il cellulare, connesso ad aGotino via usb, l'ho poi attaccato all'oculare tramite un supporto (tipo questo (https://www.amazon.it/Itian-Adattatore-Smartphone-Monoculare-26-4-46-4mm/dp/B01H54WKI8/ref=sr_1_18?__mk_it_IT=%C3%85M%C3%85%C5%BD%C3%95%C 3%91&dchild=1&keywords=cellulare+oculare&qid=1609062559&sr=8-18)):
41662
41663
41664
Qui una foto fatta al cell qualche settimana fa (singolo scatto, 10 sec di esposizione). Direi che come foto ricordo van bene...
41665
Foto a parte, il controllo remoto da PC utilizzando un vecchio cellulare Android&scrcpy funziona benone, anche se sicuramente l'aggiunta di un modulo bluetooth sarebbe l'ideale... e qualcuno c'è molto vicino :whistling:
Ciao e complimenti per il progetto e per averlo condiviso in maniera così chiara e dettagliata. Ho intenzione di costruirlo anch'io che ho una EQ5 non GOTO e avrei una domanda: hai tarato la corrente per gli stepper? a che valore? io ho preso gli stessi motori che avevi suggerito nel link del tuo primo progetto, cioè i NEMA 17 17HM15-0904S che da specifiche hanno una "corrente nominale" di 0,9 A; su un tutorial trovato in rete leggo che di solito i costruttori indicano la corrente massima e che si dovrebbe regolare il driver per un 70/75% di questo valore, quindi: ipotizzando che i 0,9 A indicati dal costruttore come "corrente nominale" siano in realtà la corrente massima, tenendo il 75% dovremmo regolare la corrente a 0,9x0,75 = 0,675A. Secondo te è corretto? tu a quanto hai regolato i driver? Grazie e complimenti ancora per la tua realizzazione.
Enrico
walie62 - io ho limitato il driver a circa 1A e non mi si è folgorato ancora nulla :biggrin:
Scherzi a parte avevo visto tale limite su altre implementazioni (onestep/astroeq), e dubito che i motori possano arrivare a tale richiesta visto il poco sforzo/velocità che richiediamo: RobertoV ne sa sicuramente più di me sulla parte elettronica, magari ci può dare un migliore consiglio.
PS: come da regolamento dovresti presentarti nell'apposita sezione del forum prima di postare.
Valerio84
05-01-2021, 20:09
gspeed
Mi sono letto tutto il post...Che lavorone!
Anche se di software non ci capisco molto, hai spiegato tutto veramente bene.
Complimenti!
RobertoV
05-01-2021, 20:20
Ciao walie62 e grazie a gspeed per la cieca fiducia :rolleyes::angel: effettivamente una corrente al limite come quella di 1A è tutto sommato accettabile, l'unico effetto che potrai osservare è legato alle perdite per effetto joule negli avvolgimenti, che si ripercuoterà sul corpo del motore portando la temperatura a circa 60°C, però, visto che la temperatura ambiente durante l'esercizio sarà sempre bassa (se non gelida :wtf: nelle notti invernali :D) puoi stare tranquillo.
Concordo con gspeed sul fatto che è bene spingere con la corrente per avere una buona coppia, che ci permetterà di garantire al meglio l'inseguimento.
Ciao
Roberto
... è bene spingere con la corrente per avere una buona coppia, che ci permetterà di garantire al meglio l'inseguimento.
Però con una buona equilibriatura direi che lo sforzo necessario è sempre molto basso, mi chiedo se i nema 17 siano sovradimensionati per lo scopo (poi, per carità sono comunque piccoli).
I problemi che ho avuto nel goto ed per l'inseguimento sono stati più di natura meccanica - una puleggia che si è svitata, motore che non avevo fissato per bene ed è ruotato rendendo lasca la cinghia etc. Mi sembra che i motori abbiano fatto il loro lavoro anche quando il tubo era sbilanciato - ma magari son cose che si notano solo in fotografia!
Alcuni aggiornamenti
grazie a vari test di RobertoV è emerso, ed è stato risolto, un problema in come aGotino convertiva alcune Declinazioni negative portando un errore nel goto fino ad 1 grado verso tali oggetti
supporto bluetooth HC-05 (https://www.amazon.it/s?k=bluetooth+hc-05&__mk_it_IT=%C3%85M%C3%85%C5%BD%C3%95%C3%91&ref=nb_sb_noss) (BT Classic) e HC-06/HC-08 (https://www.amazon.it/s?k=bluetooth+hc-08&__mk_it_IT=%C3%85M%C3%85%C5%BD%C3%95%C3%91&ref=nb_sb_noss) (Bluetooth 4.0/BLE) - le connessioni sono ben spiegate nel post qui (https://www.astronomia.com/forum/showthread.php?35387-aGotino-amp-BLUETOOTH). Quindi con meno di 10euro aGotino funziona wireless tramite l'app Serial BT Terminal (https://play.google.com/store/apps/details?id=de.kai_morich.serial_bluetooth_terminal&hl=en_US&gl=US) o...
... (aggiungendo 6.99€) con SkySafari Plus!
SkySafari Plus (o anche il Pro ovviamente) può essere collegato via Bluetooth Classic direttamente o via cavo USB tramite un'app che funge da bridge USB-WiFi (tipo questa (https://play.google.com/store/apps/details?id=masar.bluetoothbridge.pro&hl=en_US&gl=US) - la stessa app è necessaria in caso di BLE).
Non ce l'ho fatta a non fare un piccolo video ;) (con tanto di meteora al 2:10 :shock:) .
https://www.youtube.com/watch?v=fBjxpKKCwJc
RobertoV
15-01-2021, 13:31
grande gspeed, ottimo lavoro come sempre.
Questa soluzione mi sembra molto più "confortevole" nel senso che potremmo comandare il telescopio tramite uno smartphone collegato in bluetooth in prossimità di aGotino e comandare lo smartphone tramite wifi, che permetterebbe di ovviare al limite della portata di una decina di metri del bluetooth?
e tu dirai, sì ma dov'è il "confortevole", ebbé, starcene seduti al calduccio sul divano a controllare il telescopio, mentre lasciamo il lavoro sporco e gelido allo smartphone :angel::cool:
Cieli sereni a tutti ;)
... eh ma io sono visualista quindi non mi pongo il problema, o meglio la soluzione del problema ;)
Penso non ci sia bisogno del Bluetooth per fare quello che dici grazie ad app come:
USB/WIFI/BT Bridge (https://play.google.com/store/apps/details?id=masar.bluetoothbridge.pro&hl=en_US&gl=US)
è possibile usare un telefono Android (collegato alla montatura via USB) come bridge Wifi. Nel PC crei una porta seriale connessa all'IP/porta del telefono e... les juex son faits!
E' stato più facile del previsto, questo vale per aGotino ma può funzionare con qualsiasi montatura che ha una USB che funziona da porta seriale (o una seriale che potete convertire a USB con cavo apposito, sempre che il telefono lo riconosca) e un telefono Android con adattatore USB OTG (https://www.amazon.it/POSUGEAR-Adattatore-Maschio-Compatibile-Pocophone/dp/B07Y4WXB7H/ref=sr_1_3_sspa?__mk_it_IT=%C3%85M%C3%85%C5%BD%C3% 95%C3%91&dchild=1&keywords=usb+otg&qid=1610899981&sr=8-3-spons&psc=1&spLa=ZW5jcnlwdGVkUXVhbGlmaWVyPUFPQVBUWjQ5RFVMMlUmZ W5jcnlwdGVkSWQ9QTA1OTc2Nzg4R05WOUQ3QkQyNzEmZW5jcnl wdGVkQWRJZD1BMDc1MTYxNTJGTkQ3UkE2NkFRMzAmd2lkZ2V0T mFtZT1zcF9hdGYmYWN0aW9uPWNsaWNrUmVkaXJlY3QmZG9Ob3R Mb2dDbGljaz10cnVl) (<10€)
Installare nel telefono un applicazione USB/WIFI bridge (io ho questa (https://play.google.com/store/apps/details?id=masar.bluetoothbridge.pro&hl=en_US&gl=US) 1.69€)
Collegare il telefono alla montatura tramite cavo USB&USB OTG, configurare l'app in modo da unire la porta USB ad un Server TCP nel telefono (opzioni come mostrate nel video aGotino SkySafari al 00:45).
Su Linux (penso sia possibile anche su Mac o Win) configurare una porta seriale virtuale collegata all'IP del Server TCP nel telefono (nel mio caso 192.168.1.74:5321):
socat -d PTY,link=/tmp/devscope0,raw,echo=0,waitslave tcp:192.168.1.74:5321
Con Stellarium, configurare la connessione alla porta /tmp/devscope0
41950
Et voilà, chi fa astrofotografia può andare al calduccio :thinking:
41951
Aggiornamento:
Supporto porta ST4 per autoguida
Grazie all'aiuto di RobertoV , che con l'oscilloscopio si è prima preso la briga di testare il comportamento degli output a fronte dei vari "pulse" di correzione e poi ha testato sul campo la funzionalità (utilizzando il cercatore come cam guida - qui il post (https://www.astronomia.com/forum/showthread.php?35852-Cannocchiale-guida-fai-da-te&p=383989&viewfull=1#post383989) ).
I pin A0,1,2,3 (Nord, Sud, Est, Ovest) si collegano direttamente alla porta ST4 della camera guida tramite RJ a 6 poli, dove 4 contatti sono per le direzioni e il quinto è la massa. Nel codice la variabile ST4_FACTOR permette di incrementare o diminuire la velocità della correzione (il nome è fuorviante... ciò che aumenta è il periodo degli impulsi quindi la frequenza diminuisce). Il valore di default (20) corregge a 0.5x, il range ammesso va da 10 (più veloce) a 30 (più lento)
Vi sono ancora di dettagli da approfondire, il codice per il supporto ST4 è per ora separato nel branch apposito: https://github.com/mappite/aGotino/tree/ST4
RobertoV
17-02-2021, 12:42
...se può essere utile questa è la colorazione normalizzata dei fili, nel caso troviate un connettore già cablato, l'ho verificata e nel mio caso era corretta.
42351
Ancora un grazie a @gspedd per questo fantastico progetto ;)
Huniseth
24-02-2021, 13:11
Dovrai brevettare il sistema - molto interessante tutto il procedimento.
RobertoV
02-05-2021, 17:09
ciao walie62, anche se con ritardo ho approfondito la questione relativa alla corrente dei motor driver DRV8825.
Effettivamente, la taratura della corrente è un argomento che deve essere valutato con molta attenzione, dico questo perché ho fatto delle misure con l'oscilloscopio e ho scoperto una cosa molto interessante, se il trimmer è regolato misurando la corrente continua assorbita dal driver non si può essere certi che la corrente nelle bobine degli stepper motor la corrente sia sinusoidale come deve essere, potrebbe saturare della parte alta e di conseguenza il motore in quel lasso di tempo si fermerebbe, qui puoi vedere la forma d'onda della corrente presa su una bobina con la corrente continua misurata di 1,1Adc
43536
mentre questa è la corrente dopo avere regolato il trimmer in modo che la corrente di picco (e non quella continua) impostata a 1A
43537
Mi rendo conto che non tutti hanno un oscilloscopio a disposizione, per questo il mio suggerimento è quello di non superare i 900mA nel caso in cui la corrente misurata sia quella in continua.
Questo test è stato condotto con una tensione di alimentazione di 15Vdc.
Cieli sereni a tutti
Roberto
...Mi rendo conto che non tutti hanno un oscilloscopio a disposizione, per questo il mio suggerimento è quello di non superare i 900mA nel caso in cui la corrente misurata sia quella in continua...
RobertoV visto che i motori assorbono al max 0.9A da specifiche il driver va regolato per poter fornire tale amperaggio e quindi a circa 0.5v (facendo ponte tra massa e il potenziometro del driver). Basta un semplice tester, non serve un oscilloscopio, ovvio che se non si regola la tensione vi sono comportamenti anomali, tra cui un gran rumore o al limite penso si possa danneggiare il motore!
RobertoV
12-05-2021, 12:44
Basta un semplice tester, non serve un oscilloscopio
ciao gspeed, anche quella della misura della tensione sul trimmer è comunque una misura ad anello aperto, perché il DRV8825 non conosce il valore dell'impedenza delle bobine dello stepper motor.
La TI a specifica dichiara per questo driver 3Apk, essendo la corrente che attraversa le bobine sinusoidale e considerando il fattore di cresta pari a radice di 2, significa che la corrente potrà avere un valore di 2,12Arms prima che il driver inizi a limitare e di conseguenza la corrente venga appiattita in cresta causando una distorsione della velocità angolare di rotazione del motore.
43623
Chi avrà la possibilità di usare un oscilloscopio potrà ottenere la massima prestazione in termini di coppia dello stepper motor, chi non ce l'ha potrà seguire il tuo consiglio, stando così in una zona di confort dove la rotazione del motore sarà certamente lineare
Cieli sereni a tutti
Roberto
Pastore1980
30-06-2021, 12:51
Ciao, ti rinnovo i miei complimenti anche qui per il progetto. Il tuo progetto mi ha spinto come ti dicevo nell'altra discussione a costruirmi un goto onstep, ma ho la tua stessa montatura e usato gli stessi motori del tuo progetto, usando però Arduino Mega 2556.
Siccome la problematica riguarda la montatura e i motori, te la scrivo qui.
Ho montato il NEMA17 in DEC, oltre che in AR, ma il motore mi batte nella leva della frizione quando passa di lì. E quindi non riesce a fare un giro completo la montatura in DEC. Credo da ONSTEP di poter impostare l'angolo in modo da evitare che usi quella "porzione di giro" e fermarsi prima (dovrò solo capire come :weeabooface:); non sono riuscito a fare diversamente...
Dalle foto non si capisce molto, e anche da qualche video online non sono riuscito a capire se è un problema di molti; te hai avuto lo stesso problema o il motore ci passa?
Grazie mille!
Ciao Pastore1980 e grazie per i complimenti. Non ho il problema di cui parli, se ho ben capito, ecco una foto fresca fresca (anzi calda calda visto che il telescopio è fuori).
Ci sono almeno 5mm di spazio. Nella seconda foto vedi bene come è montato.
https://uploads.tapatalk-cdn.com/20210630/cddf59860a5e67bcc6bdf74dc92d9325.jpg
https://uploads.tapatalk-cdn.com/20210630/8ee0e7f117fb223dbe7c67db488af7f3.jpg
Alcuni aggiornamenti:
Supporto comandi :Mx del protocollo LX200: ora i micromovimenti possono essere comandati da SkySafari/Stellarium&co (tramite le frecce) oltre che da i due bottoni fisici
Il codice per supportare la porta ST4 è integrato in quello principale, occorre togliere il commento alla linea #ifdef ST4 per abilitare la porta nei pin A0, A1, A2,A3 (North, South, East, West)
La direzione del moto in AR con il bottone fisico è invertita, prima va verso est e poi ovest in modo da avere la stessa direzione del tracking. Questo evita lo "shift" causato dai giochi delle pulegge, che altrimenti si nota in hi-res
In CN mi è stato riportato un miglioramento usando i driver TMC2208 (vs DRV8825), costano poco di più ma eliminano rumore e aumento la smoothness (come si dice?) grazie ai 256 microstep di inteprolazione. Su Agotino Github (https://github.com/mappite/aGotino) è spiegata la modifica allo schema.
Miglioramenti nel codice per renderlo più leggibile.
Non tante cose ma in effetti non ho bisogno di altro al momento. Magari un allineamento a due stelle per compensare errori nello stazionamento ma la precisione del Goto è al livello che mi serve (<5-10' entro 30°, quindi mi sta sempre nell'oculare) e per la fotografia penso sia meglio lasciar fare alle varie procedure offerte dai vari phd2/ekos etc.
Codice e dettagli su Agotino Github (https://github.com/mappite/aGotino)
Ciao. Mi sono perso con i settaggi del TMC2208.
Devo considerarli, al fine dei valori da indicare in Arduino, da 16 step o da 32?
Grazie
Non ho provato ad usarlo, ma direi da 16 se lo usi in "legacy mode" (così come spiegato nella pagine github): internamente interpola con ben 256 microsteps, ma Arduino lo comanda a 16.
Mi fai sapere se riesci?
Mi fai sapere se riesci?
Certo,stasera riprovo. Ho adattato il tutto ad un seben 114/1000 che dovrebbe essere montato su un eq3 standard. Il movimento era troppo veloce quasi il doppio ed ero in dubbio se il problema fossero gli step o il rapporto della ruota ar 130
Scusate mi intrometto un secondo visto che parlate dei TMC2208, sono davvero così silenziosi? vedo meraviglie nei video, io uso il driver tb6600(32microstep fino a 4.5A) e il nema17 dell'ar fa il classico ronzio,ma leggevo che dipende dal "rumore elettrico" che gli passa il driver.. Il tmc2208 dà un segnale pulito pertanto il motore è incredibilemte silenzioso.. immagino che questo si traduca anche in una minore vibrazione dello stesso. La cosa dei 256 microstep interpolati: diventano effettivi o semplicemente è un microstep 16 più preciso?
Non l'ho usato direttamente, puoi semmai chiedere su CloudyNights (https://www.cloudynights.com/topic/735800-agotino-a-simple-arduino-nano-goto/page-3) dove qualcuno li ha provati ed ha confermato la silenziosità. Io con il DRV8825 non ho problemi e il lieve ronzio quasi non lo sento e non mi da fastidio. Quelle volte che ho pensato potesse creare vibrazioni ho sempre fatto la prova spegnendo tutto e notando che i tremolii erano dovuti al seeing o al vento, quindi non sento la necessità di cambiarlo. Però se dovessi mettermi a creare una nuova soluzione proverei con il TMC, non tanto per il rumore ma perché risolverebbe quel piccolo scatto che si avverte in DEC quando la modalità sleep viene disattivata.
Da quel che ho capito leggendo le specifiche, il TMC2208 interpola sempre a 256 microstep: " The actual microstep resolution (MRES) becomes extrapolated to 256 microsteps for smoothest motor operation." (https://www.trinamic.com/fileadmin/assets/Products/ICs_Documents/TMC220x_TMC2224_datasheet_Rev1.09.pdf). Il fatto che lo si comandi a 16 microsteps nella configurazione "drop-in replacement" del A4988 (o DRV8825), ovviamente diminuisce la "precisione" nel go to: ma stiamo parlando di una precisione superflua, i.e. "sulla carta" per l'eq5 da 0.28 arcsec/microstep (con 1/32) raddoppia. Ma a chi serve una precisione che rimane comunque sotto l'arcosecondo? I giochi meccanici, allineamento polare non perfetto etc sicuramente impattano ben di più nel goto (direi di almeno un ordine di grandezza) per cui ai fini pratici non vedo aspetti negativi.
Grazie del link ora me lo studio, perchè sembrano davvero ottimi. ma hai ragione tu, ai livelli di moltiplica a cui lavoriamo è più una questione di rumore che di correzione degli errori del drive, tanto più nel mio caso, sono pratico di C ma novellino su arduino,sensori e motori, meglio affidarmi a componenti semplici che posso capire e tenermi le funzionalità avanzate per quando avrò più esperienza.
Partiamo dal presupposto che sono neofito. Se lancio il comando +1800+0000 dovrebbe spostarsi in ar di 30gradi ?
maschio quindi? ;) In ogni caso si, 1800 sono in primi di grado, quindi 30 gradi o 2 ore.
Occhio che 1800 è proprio il limite massimo di default nel goto (che può essere variato, variabile MAX_RANGE).
Ma starò sbagliando ho fatto 130x 3 ( rapporto puleggia) x 400 x 16 / 360= 6933 il delay non dovrebbe servire adesso.
Comando 1800 spostamento 10min circa.
Ho provato a mettere 256 steps risultato 110933
Microsteps_ra 16 spostamento circa 1h .
Con microsteps Ra 256 spostamento meno di 10min
Sicuro che hai il motore da 400step? Se con Microsteps_ra a 16 (come dovrebbe essere per il tuo driver) e al comando +1800+0000 si sposta di 1h è giusto la metà di quando dovrebbe spostarsi.
Sì é 0.9 gradi. Se fosse 200 si sposterebbe la metà credo. Forse ho capito. Ho collegato ms1 e ms2 del Ra al d2 e non al d9 (ho collegato ms1 e 2 del motore dec) forse va 1/8 mi ero discostato dalle info seguendo lo schema. Il dec impostato 1/16(d9) funziona
SI hai ragione, sarebbe stato il doppio, non la metà. Spero tu scopra presto l'inghippo!
Lo step ar va a 8. Ma devo collegare tutti gli MS1&MS2 al d9?
Si, dalla pagina github:
TMC2208 <-> Arduino
VIO <-> +5VDC
EN <-> GND
Do not connect NC, PDN, CLK (these would match with MS3, RES, SLP in DRV8825). MS1&MS2 stay connected to D9
Non cambia molto. Il TMC interpola sempre a 256. Cmq pare funzionare con dec impostato a 32 step e ar a 8 step. Avrò sbagliato qualcosa nei collegamenti.
Jach Blak
07-01-2022, 17:38
Salve a tutti, mi sono imbattuto in questa discussione un po' di tempo fa' ed ho capito subito che Agotino poteva essermi utile per quanto stafo pensando di fare; la mia idea prevede di realizzare una piccola montatura per supportare un puntatore laser e comandarla tramite Skysafari.
L'idea è di utilizzarla in osservatorio per far didattica: puntare velocemente gli oggetti per mostrarne la posizione in cielo agli ospiti... e perchè no, farla utilizzare direttamente agli ospiti stessi che si potrebbero cercare l'oggetto sul tablet e poi puntarci il laser in autonomia...
Per quanto riguarda la realizzazione della montatura la cosa è semplice, la disegno in 3D e la stampo, non necessità di alta precisione... anzi, preferisco una velocità di spostamento a scapito della precisione visto che non serve per osservare.
Il mio problema arriva con la programmazione: anni fa' ho imparato le basi di Arduino per comandare la tavola EQ del mio dobson, ma la cosa è stata veramente a "basso livello".... ora ho realizzato l'hardware ma quando sono andato a caricare lo sketch mi esce un errore relativo alla mancanza del file "catalog.h" ....:meh: cosa significa?!?! Scusate la domanda magari banale ma sono completamente fuori dal mio campo di competenza ;)
Ciao Jach son contento se il progetto risulta utile.
Il file catalog.h lo trovi nel repository github: https://github.com/mappite/aGotino. Lo scarichi some hai fatto con il codice C aGotino.ino e lo copi nella stessa cartella, l'IDE dovrebbe trovarlo durante la compilazione. Fammi sapere se qualcosa non va e in bocca al lupo con il tuo progetto.
Se realizzi una "mini" montatura per laser tramite stampante 3D, considera di aprire un thread qui su astronomia.com e pubblicare come hai fatto, sembra molto interessante!
Jach Blak
07-01-2022, 20:35
Ciao Jach son contento se il progetto risulta utile.
Il file catalog.h lo trovi nel repository github: https://github.com/mappite/aGotino. Lo scarichi some hai fatto con il codice C aGotino.ino e lo copi nella stessa cartella, l'IDE dovrebbe trovarlo durante la compilazione. Fammi sapere se qualcosa non va e in bocca al lupo con il tuo progetto.
Se realizzi una "mini" montatura per laser tramite stampante 3D, considera di aprire un thread qui su astronomia.com e pubblicare come hai fatto, sembra molto interessante!
Intanto grazie :-) ...un passo avanti l'ho fatto ma adesso mi da un errore per me incomprensibile:
"avrdude: stk500_recv(): programmer is not responding avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0xa6"
Altro dubbio ce l'ho sul modulo HC05: qualche anno fa ho collegato il mio puntamento passivo a skysafari montando un modulo hc05 ma ne ho provati diversi prima di trovare uno che funzionasse... ho sempre più dubbi :sad:
Zoroastro
07-01-2022, 20:51
Pensa che il puntatore laser robotico, magari con comandi vocali e spiegazioni parlate, è una mia vecchia idea, sempre per scopi ricreativi e didattici ... 😁
Jach Blak
07-01-2022, 21:02
Pensa che il puntatore laser robotico, magari con comandi vocali e spiegazioni parlate, è una mia vecchia idea, sempre per scopi ricreativi e didattici ... 😁
Comandi vocali e spiegazioni... non punto a tanto :D, anche perchè il contatto con le persone non lo voglio perdere. Intanto mi accontento di qualcosa di semplice, anche perchè per me non è comunque così semplice :confused:
Intanto grazie :-) ...un passo avanti l'ho fatto ma adesso mi da un errore per me incomprensibile:
"avrdude: stk500_recv(): programmer is not responding avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0xa6"
Bene, compila! L'errore vuol dire che il PC non riesce a collegarsi per trasferire il firmware, hai scelto la scheda/bootloader corretto? Controllerei se la porta / programmatore (ArduinoISP) siano quelle corrette e di non avere qualcosa collegato ai pin TX/RX di arduino,
ref.
https://forum.arduino.cc/t/errore-avrdude-stk500_recv-programmer-is-not-responding/137304
https://stackoverflow.com/questions/19765037/arduino-sketch-upload-issue-avrdude-stk500-recv-programmer-is-not-respondi
se usi Arduino Nano probabile questa sia quella giusta:
46434
Jach Blak
07-01-2022, 21:19
avere qualcosa collegato ai pin TX/RX di arduino,
46434
Eccola li... ho già collegato il modulo Bluetooth!!! L'impostazione di arduino e della porta sono corrette... Domattina ci riprovo
Intanto grazie
Jach Blak
08-01-2022, 17:29
Eccomi :-) compilato, caricato e collegato a Skysafari in Bluetooth... tutto bene. Non sono riuscito a far muovere i motori: uno era alimentato mentre l'altro no ma probabilmente è colpa dei cablaggi molto approssimativi delle piastre per prototipazione quindi oggi ho preparato tutto saldato per bene su una millefori; collegando tutto come da schema ho notato una cosa che prima mi era sfuggita. Sicuramente il motivo c'è ma per mia natura, quando vedo qualcosa che non mi convince chiedo sempre; perchè i due driver sono collegati in modo differente? Il pin SLP del DEC è collegato a D10 di Arduino mentre il relativo pin dell'asse RA è alimentato a +5V!!! Sicuramente data la mia conoscenza in materia non capirò nessuna spiegazione ma volevo solo una conferma prima di andare ad alimentare il tutto :-)
Ma no che la spiegazione è semplice: il pin SLP serve per mettere in sleep il driver e quindi consumare meno corrente, questo avviene quando è basso (0 volt), mentre se è alto (5v) allora il driver è attivo. In RA è sempre attivo, per l'inseguimento. In DEC è comandato dal pin 10 che di default lo attiva solo durante gli spostamenti.
Jach Blak
09-01-2022, 13:53
Ma no che la spiegazione è semplice: il pin SLP serve per mettere in sleep il driver e quindi consumare meno corrente, questo avviene quando è basso (0 volt), mentre se è alto (5v) allora il driver è attivo. In RA è sempre attivo, per l'inseguimento. In DEC è comandato dal pin 10 che di default lo attiva solo durante gli spostamenti.
In effetti la spiegazione è chiara :-) ...a dire il vero l'avevo anche letto nella discussione ma non avevo collegato il fatto.
Al momento ho fatto la schedina come da schema, stellarium si collega, skysafari si collega... nessuno dei due però fa muovere i motori!! a dire il vero nemmeno i pulsanti non li fanno muovere...
Va a finire che termino la montatura prima di riuscire a far muovere un solo motore :-(
Cristian v
03-03-2022, 09:35
Buongiorno gspeed, complimenti per il lavorone. Ho provato anch'io a cimentarmi nell' impresa, avendo un vecchio newton su montatura simile alla eq5 e mi sono arenato. Non sapendo niente di informatica non so come scaricare il codice aGotino da Github, per poi creare uno sketch sull' IDE di Arduino. Perchè se copio e incollo, mi da errore. Grazie e cieli sereni.
Cristian, una volta installato l'IDE di Arduino compila qualche sketch di prova per vedere se va tutto bene. Poi nella cartella Arduino crea la sotto cartella aGotino e copiaci i due file aGotino.ino e catalogs.h , per scaricarli puoi usare il link diretto all'archivio zip che contiene tutto: https://github.com/mappite/aGotino/archive/refs/heads/main.zip
Se hai errori, scrivi qui esattamente quali così capiamo che succede.
Cristian v
04-03-2022, 05:59
Ciao, sembra che abbia caricato sia agotino che il catalogo. Mi dava lo stesso errore di Jach Blak, ma poi seguendo il tuo consiglio di cambiare scheda, tutto ok. Ora quando avrò un po' di tempo utile, monterò tutto e vedrò cosa succederà. Intanto Grazie Tantissime, gspeed, buona giornata e cieli sereni!
Carmine Crocco
10-12-2022, 20:06
Buonasera, voglio innanzitutto fare i complimenti a gspeed per il progetto e ringraziarlo per averlo condiviso. Avendo completato la mia realizzazione di questo progetto utilizzando i driver TMC2225 (silenziosissimi), ho constatato una cosa che non riesco a spiegarmi e vorrei chiedere a qualcuno che ha usato driver TMC analoghi se può darmi una spiegazione. Dopo aver settato la vref secondo le prescrizioni ho inserito i driver nel circuito e cablato in modo da avere i 5v sui due pin MS, impostando quindi i microstep fisicamente ad 1/32 senza usare il protocollo UART, tuttavia facendo un po di test indoor ho constatato che lo spostamento degli assi AR e Dec era inferiore a quello comandato ed infine ho riscontrato che per ottenere lo spostamento corretto degli assi i valori delle costanti MICROSTEPS_PER_DEGREE dovevano essere impostati a 48000 in RA e 23111 in DEC, corrispondenti ad una impostazione del motore di 128 microstep anzichè 32, come mai?
49870
49871
49872
RobertoV
15-02-2023, 12:37
ciao Carmine,
i motori che usi sono da 0,9°? il rapporto delle pulegge? gli ingranaggi della montatura in AR e DEC sono uguali e sono 144? se hai cambiato almeno uno di questi parametri devi riaggiustare il calcolo nel firmware di aGotino (creato dal grande gspeed), io monto i driver DRV8825, nel complesso è un po' tutto rumoroso ma il mio osservatorio è remotizzato quindi per me il problema non esiste
Roberto
[...] Avendo completato la mia realizzazione di questo progetto utilizzando i driver TMC2225 (silenziosissimi), [...] ho constatato che lo spostamento degli assi AR e Dec era inferiore a quello comandato ed infine ho riscontrato che per ottenere lo spostamento corretto degli assi i valori delle costanti MICROSTEPS_PER_DEGREE dovevano essere impostati a 48000 in RA e 23111 in DEC, corrispondenti ad una impostazione del motore di 128 microstep anzichè 32, come mai? [...]
Carmine, grazie dei commenti. In effetti vedo che i driver TMC sembrano essere una questione aperta (anche sul thread di CloudyNights (https://www.cloudynights.com/topic/735800-agotino-a-simple-arduino-nano-goto/page-5)) e se non ho preso un abbaglio la ragione è che quando Agotino pensa di disabilitare i microstep (D2&D9 a LOW per DRV8825) in realtà da datasheet del TMC2225 (pag 4 (https://www.trinamic.com/fileadmin/assets/Products/ICs_Documents/TMC2225_Datasheet_Rev1.11.pdf)) i microstep vengono messi a 1/4 non a 1. Questo spiega perché hai dovuto quadruplicare il valore per avere gli spostamenti (slew) corretti - ti torna il ragionamento?
Ma hai fatto anche qualche test outdoor? Il tracking non dovrebbe funzionare a dovere.
Mi chiedo se la cosa giusta da fare sia introdurre un nuovo parametro (del tipo "MICROSTEP_FACTOR_WHEN_SLEWING") da impostare a 1 per DRV8825 a 4 per TMC2225, a 8 per il TMC2208...). Ci rifletto...
Nel frattempo, il buon RobertoV ha trovato un "bug" che previene il codice agotino di fare slew superiori a 46 gradi... a breve una fix.
Alcuni aggiornamenti al codice e al Readme in aGotino Github (https://github.com/mappite/aGotino):
Readme: aggiunta sezione Motor Driver con alcuni esempi per l'uso di drivers alternativi al DRV8825. Con quest'ultimo i microstep per step passano da 1 (cioè no microsteps) a 32 mentre con i driver TMC passano da un valore N a un valore M in base al modello e da come si è deciso di collegare i pin MS1&2 del driver: i microstep variano ma sono quindi sempre abilitati - questo ha generato alcuni problemi come descritto nei post precedenti.
Codice aggiornato con le variabili per specificare il numero di microsteps minimo e massimo al variare dello stato dei pin D2&D9 di Arduino
Corretto un overflow che si generava estendendo il range massimo ammesso per un movimento goto (variabile MAX_RANGE) oltre i 46 gradi - grazie a RobertoV per aver trovato l'errore e testato la soluzione.
Sembra vi siano dei problemi di connessione bluetooth con Stellarium Plus mobile (da PC mai avuti), sono in contatto con gli sviluppatori di Stellarium per avere lumi su come usano un comando del protocollo LX200 che genera un timeout - probabile a breve un piccolo aggiornamento.
Carmine Crocco
13-03-2023, 08:43
Ciao, essendosi presentati dei problemi di salute (risolti) in famiglia avevo messo da parte il progetto. La prima risposta è per RobertoV, al quale confermo che l'hardware da me utilizzato è quello del progetto originario ad esclusione dei driver TMC2225, la seconda è per gspeed al quale confermo che in effetti l'inseguimento non avveniva correttamente ed infatti mi ero ripromesso di sostituire i driver con i DRV8825. Ora, grazie alla grande generosità di gspeed che ha integrato il codice per risolvere il problema di quelli che come me hanno optato per altri driver, provvederò ad aggiornare il software e a testarlo quanto prima. Grazie e buona giornata a tutti.
Carmine, ottimo! Grazie, attendo tue nuove allora.
Nel frattempo, ho ricevuto un feedback dagli sviluppatori di Stellarium Plus (mobile) sul fatto che questo richiede (forse solo nelle ultime versioni) il supporto di un comando LX200 per sapere se c'è un goto in corso; quindi un piccolo update:
Supporto comando D# del protocollo LX200 per segnalare se il telescopio è in fase di goto o meno
Modificato la risposta al comando CM# (Stellarium PC nella modalità di connessione "diretta" si aspetta un "0#" dopo un sync, altrimenti si deve attendere una decina di secondi prima che mostri le nuove coordinate).
fabio7586
31-08-2023, 10:28
Ciao, mi spieghi come fai a fare il calcolo degli ingranaggi? O, ancora meglio, qualcosa da leggere? Sono interessato a costruire questo sistema per il mio dobson ed è l'unica cosa che mi blocca :(; Denti, dimensioni, rapporti... etc.. ingranaggi piccoli devono fare più giri per completarne uno e viceversa, ma come si calcolano con precisione, anche a partire dai motori?
Ti ringrazio
Buongiorno a tutti, spero di non essere troppo fuori con il tempo, visto che l'ultimo msg risale a 2 ani fa.
Mi rivolgo a GSPEED, ottimo progetto e ovviamente grazie per la condivisione.
posseggo arduino uno e vorrei utilizzarlo, mi confermi che e' compatibile con il codice che hai usato per il nano?
inoltre ti chiedo, ho notato, e spero di non essermi perso qualche passaggio, che hai inserito due soli pulsanti nel progetto AGOTINO quindi in modalita' manuale e' possibile gestire i movimenti di ar e dec in un solo senso? spero di non aver detto una fesseria........
Ti ringrazio
Mimmo59
... no non sei in ritardo, il mio aGotino funziona ancora ;) ma non ho più fatto aggiornamenti perché non ho bisogno di altro per come lo uso io.
Ti confermo che funziona con un nomale arduino, non c'è nessuna differenza tra il nano o lo standard a livello di chip.
Riguardo i due bottoni, funzionano in un ciclo: es. in declinazione un primo click si muove in un senso, secondo click cambia direzione, terzo click si ferma. Se dopo il primo click fai un doppio click quindi si fermerà.
La storia di aver solo due bottoni nasce perché... ne avevo solo due, ma poi ho trovato la soluzione pratica e semplice (fili in meno). Sarebbe comunque piuttosto semplice implementare 4 bottoni.
Cieli sereni!
... no non sei in ritardo, il mio aGotino funziona ancora ;) ma non ho più fatto aggiornamenti perché non ho bisogno di altro per come lo uso io.
Ciao ok, grazie, mi accingo ad acquistare il resto dei componenti. comunicherò i risultati del mio assmblaggio.
Bene, in bocca al lupo!
ciao gspeed, scusa ho cercato nei veri messaggi, ma non trovo il tipo di stepper che hai usato nel progetto, forse vanno bene qualsiasi motorino nema17???
Grazie
mimmo59 si ma per pochi euro in più suggerisco di prenderne uno da 0.9°/step (400 step per giro anziché 200), il mio è questo:
STEPPERONLINE Nema 17 Motore passo a passo Bipolar 0,9deg 36Ncm 0,9A 42 x 40 mm 4 fili per stampante 3D / DIY CNC https://amzn.eu/d/0et4a8SM
mimmo59 si ma per pochi euro in più suggerisco di prenderne uno da 0.9°/step (400 step per giro anziché 200), il mio è questo:
STEPPERONLINE Nema 17 Motore passo a passo Bipolar 0,9deg 36Ncm 0,9A 42 x 40 mm 4 fili per stampante 3D / DIY CNC https://amzn.eu/d/0et4a8SM
ok grazie, ma per la declinazione si puo usare un nema17 a 1,8° ??
Red Hanuman
24-06-2024, 19:20
@mimmo59 (https://www.astronomia.com/forum/member.php?u=68742) , non quotare il messaggio immediatamente precedente, è vietato da regolamento...
@mimmo59 , non quotare il messaggio immediatamente precedente, è vietato da regolamento...
ho risposto dopo 15 ore al msg, personalmente mi sembra un lasso di tempo congruo, e non immediatamente dopo. cmq cortesemente mi quantifichi in ore il tempo che deve intercorrere tra i msg???????
grazie
15 ore... mi sembra un lasso di tempo congruo, e non immediatamente dopo
Il tempo, si sa, è cosa relativa :biggrin:; ed in questo caso si tratta di spazio-tempo, dove con immediatamente è inteso il messaggio che viene subito dopo, dove un lettore della discussione non fa caso a quante ore siano passate tra un messaggio e l'altro, ma nota la ripetizione dello stesso messaggio fatta attraverso il quote.
Scusami la battuta ma spero di aver spiegato ciò che intende il regolamento.
Red Hanuman
25-06-2024, 05:49
ho risposto dopo 15 ore al msg, personalmente mi sembra un lasso di tempo congruo, e non immediatamente dopo. cmq cortesemente mi quantifichi in ore il tempo che deve intercorrere tra i msg???????
grazie
Non cominciamo con le polemiche... La cosa è vietata da regolamento, punto. Se hai necessità di attirare l'attenzione di un utente, usa il mention (@+nickname). E' più che sufficiente...:whistling:
etruscastro
25-06-2024, 06:54
cmq
e soprattutto no parole stile messaggistica sul forum, come da regolamento!
Mulder, ciao, grazie della spiegazione garbata, anche se mi lascia dei dubbi.
Caio @gspeed (https://www.astronomia.com/forum/member.php?u=16831), forse non l'ho visto il messaggio in cui parlavi delle pulegge cinghie, puoi dirmi che tipo hai usato?. la mia montatura se non ricordo male ha una riduzione di 144:1 che forse
è uguale alla eq5.
Grazie
mimmo59 non so che montatura hai, su github trovi i dettagli per le pulegge ed il resto dei componenti, le mie sono 40T-16T
https://github.com/mappite/aGotino
gspeed, grazie, cmq ho verificato anche la exos2 e la eq5 hanno 114:1 e anche la mia.
etruscastro
01-07-2024, 07:14
cmq
no parole con abbreviazione stile messaggio, gli altri li ho modificati io, prestate attenzione per cortesia, abbiamo poche regole ma ci teniamo a farle rispettare.
Ciao gspeed, nel programmare arduino nano, purtoppo mi da problemi........riporto qui sotto gli errori.
ho provato a cambiare nella com le varie velocita' ma nulla da fare.......help.
pero su arduino uno, non mi ha dato problemi, ha caricato subito.
Using Port : COM7
Using Programmer : arduino
Overriding Baud Rate : 115200
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0xbd
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0xbd
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0xbd
avrdude done. Thank you.
Caricamento non riuscito: errore durante il caricamento: exit status 1
scusate forse ho fatto un po di caos, comunque gspeed, ho faato la prova a caricare una versione datata di arduino ide, poi ho scelto la scheda arduino nano con processore atmega328P oldbootloader.......e il codice si e' caricato, ho ripetuto per 3 volte tutto ok, spero sia di aiuto ad altri.
ciao, gspeed RobertoV ho un dubbio sull'alimentazione del progetto, cioe' alimento il tutto a 12volt, oppure differenzio il nano a 5volt e i driver a 12volt?
grazie
mimmo59 va bene tutto a 12v, come da schema. Arduino nano li supporta con il pin VIN che è a monte di un regolatore di tensione.
Ciao gspeed, ho assemblato il tutto su bread bord, lo stepper ha un comportamento anomalo, accenna a girare ma poi si ferma. Agendo sui pulsanti qualche volta compie degli step.....che dici?? ho controllato e regolato la vref a 0,56 v.
Mimmo non saprei, ti consiglio di trovare un tutorial per provare solo a muovere il motore, tipo questo; https://themachineshop.uk/how-to-drive-a-nema17-stepper-motor-with-a-tmc2208-v3-and-an-arduino-uno/
Così con meno variabili in gioco puoi verificare se il problema è nelle connessioni, nel driver o nel motore.
gspeed ok, proverò come da tuo suggerimento. comuque il motore nema non ha problemi, perche provato con driver TB6600 e generatore d'impulsi custom, e funziona, probabilmente sara questione di connessioni o di driver drv8825. seguiranno risultati.
Gia che mi trovo, potresti darmi le connessioni per la seriale, in modo da usare l'app serial usb terminal
Grazie
Mimmo non saprei, ti consiglio di trovare un tutorial per provare solo a muovere il motore, tipo questo; https://themachineshop.uk/how-to-drive-a-nema17-stepper-motor-with-a-tmc2208-v3-and-an-arduino-uno/
Così con meno variabili in gioco puoi verificare se il problema è nelle connessioni, nel driver o nel motore.
Ciao, ho provato i drv8825 e lo stepper con arduino uno ed uno sketch leggero, funzionano entrambi.......incomincio a dedurre che il problema sia il nano.........sai mica la corrispondenza dei pin del nano con arduino uno......
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions Inc. All rights reserved.