Jump to content

Power Function & Micro:Bit - Un altro sistema per il controllo dei treni


Recommended Posts

Segnalo, per chi ama "smanettare" con i treni senza disdegnare l'uso di tecnologie non-LEGO, questo breve articolo-tutorial per il controllo automatizzato di un treno usando una piccola scheda programmabile (Micro:Bit) per la quale è stata implementata una libreria che si interfaccia con il sistema IR del Power Function.

https://www.hackster.io/philipp-henkel/lego-power-functions-ir-sender-for-micro-bit-aecc10

L'autore ha scritto un plug-in per MakeCode di Microsoft, un ambiente di sviluppo Open Source basato su una programmazione a blocchi (sulla falsa riga di Scratch e ambienti simili) e codice JavaScript pensato per avvicinare giovani studenti al mondo della programmazione  (mio figlio usa Scratch, ad esempio, in seconda media) .
Il Plug-In implementa in modo molto facile la comunicazione IR con i Power Function, aggiungendo a MakeCode le seguenti funzioni base:
blocks2_FCZGCqomrg.png?auto=compress%2Cf

 

Questo è un esempio di "codice", preso dallo stesso articolo:
pf_buttons_GTklWxB6AJ.png?auto=compress%

Questo, per intenderci meglio è il Micro:Bit:
A diagram of the BBC micro:bit

Fondamentalmente è una schedina programmabile che implementa il BT (magari qualcuno, nel prossimo futuro, è possibile che sviluppi la libreria BT per controllare il nuovissimo sistema Powered UP?), un accellerometro, un compasso, un sensore di luce, un sensore di temperatura e gli immancabili pin di I/O che una schedina del genere deve avere.
Dulcis in fundo, due pulsanti e una matrice 5x5 di microled completano il tutto...

Devo dire che questa cosa mi ha incuriosito e quindi.... 😄 😄 😄
blob.png
(per chi fosse interessato, l'articolo che ho acquistato è questo: BBC micro bit Go)

So benissimo che si sono soluzione più sofisticate basate su Arduino, ma questa mi pare una soluzione molto semplice da implementare.
Che ne pensate @alf e @fonderiadigitale?

Ah... ho visto che MakeCode c'è anche per l'EV3 (me ne occuperò, presto, in una nuovo post...)

Link to post
Share on other sites

Aggiungo un ulteriore dettaglio alla discussione...

Nell'esempio che accompagna l'articolo, viene mostrato come fermare il treno per un 'tot' di tempo in prossimità di una colonnina che emette una forte fonte di luce (usando le luci LED del sistema PF).
Ma non dimentichiamo che il Micro:bit dispone di un sensore magnetico e quindi può rilevare il cambiamento della forza magnetica. In parole povere, si potrebbe controllare il posizionamento del treno (e le sue eventuali fermate) anche con delle colonnine che hanno (in prossimità del passaggio del treno) i magneti LEGO:
Risultati immagini per lego magnet train

Il vantaggio, rispetto ad un fonte di luce, è che questi non richiedono una alimentazione esterna 😉
https://makecode.microbit.org/reference/input/magnetic-force

Link to post
Share on other sites

Nel mentre cercavo sulla Rete ulteriore documentazione su questa 'schedina', mi sono imbattuto sul blog di Michele Maffucci, docente e libero professionista, che ha trattato in modo molto chiaro (e da zero) l'uso e la programmazione del Micro:bit
In questa pagina, oltre ad un tutorial di 10 lezioni sul Micro:bit, ci sono molte altre risorse su questo "aggeggio".
Un gran bel lavoro ed esempio di divulgazione didattica!
Complimenti a Michele 😉

Link to post
Share on other sites

Nel frattempo che attendo l'arrivo del Micro:bit, sto cercando in rete altra documentazione per l'integrazione con il mondo LEGO.
Ecco un articolo dove viene interfacciato direttamente con un servo motore LEGO per realizzare un sistema di guida:
http://willitwork.co.uk/microbit-vs-lego-power-functions-servo

Nel precedente post mi son dimenticato di taggare @bricksnspace: Mario, penso che anche a te possa interessare questa discussione 😉

Link to post
Share on other sites

Personalmente mi sono concentrato sull'ecosistema di Arduino, che ha un patrimonio immenso di librerie e di sensori/attuatori.

Si programma in C/C++, ma per chi non è "studiato" con C/C++ esiste anche una versione di Scratch http://s4a.cat/ che permette di lavorare graficamente senza troppi mal di testa. Naturalmente, occorre avere sempre un'idea di cosa sia un programma 😁

Ho creato un semplice controllo per i treni a 9V che aveva come specifica il minore impatto possibile sugli elementi LEGO (lo trovate qui)

Per chi viene ad Albano questo fine settimana (26/27 maggio) porterò due prototipi: i treni PF automatici (dettagli qui) ed una battaglia fra cingolati (basati sul set 42065).

Entrambi sono su Arduino ed uso vari sensori (infrarosso, magnetico) per gestire il mondo esterno. Sono disponibile a fornire più dettagli a chi è interessato.

 

Link to post
Share on other sites
29 minuti fa, bricksnspace ha scritto:

Ho creato un semplice controllo per i treni a 9V che aveva come specifica il minore impatto possibile sugli elementi LEGO

Ciao Mario,
avevo già dato una veloce lettura al tuo articolo, ma mi ha sempre un po' frenato il troppo "dover cablare" del sistema Arduino.
Se forse ricordi, in passato in qualche vecchio thread dissi che "al di fuori dell'RCX, non voglio usare nulla😁😁😁
Ora, questo BBC Micro:Bit, mi sembra un buon compromesso tra semplicità di cablaggio (quasi nullo) e 'rigidità' dell'RCX.

Arduino offre sicuramente molto di più, ma troppo per quello che vorrei fare io ovvero qualcosa che impatta molto, molto poco con il sistema LEGO.

Immagino che tu conosca il progetto ArduTrain di Luca Bellan, che sta portando avanti dal alcuni mesi con ottimi risultati.

Link to post
Share on other sites
28 minuti fa, GianCann ha scritto:

...

Arduino offre sicuramente molto di più, ma troppo per quello che vorrei fare io ovvero qualcosa che impatta molto, molto poco con il sistema LEGO.

Immagino che tu conosca il progetto ArduTrain di Luca Bellan, che sta portando avanti dal alcuni mesi con ottimi risultati.

Beh, se il punto è non toccare niente nel sistema LEGO, si può modificare abbastanza semplicemente il sistema per i treni a 9V per i PF, utilizzando un Arduino Uno, un LED infrarosso ed un sensore di prossimità per far fermare il treno alla stazione e farlo ripartire dopo un tempo predeterminato, senza toccare nulla e collegando in tutto con cinque fili ed una resistenza.

Appena ho un momento ci faccio un articoletto.

Ardutrain è un progetto complesso ed articolato, e sicuramente come cablaggi è molto più "intricato".

Link to post
Share on other sites
34 minuti fa, bricksnspace ha scritto:

utilizzando un Arduino Uno, un LED infrarosso ed un sensore di prossimità

Quello che farò con Micro:bit, con la differenza che il sensore (magnetico) è già integrato "on board".

 

35 minuti fa, bricksnspace ha scritto:

Ardutrain è un progetto complesso ed articolato, e sicuramente come cablaggi è molto più "intricato".

Si, per i miei gusti si... ma riconosco che è un bel progetto per chi non si fa troppi problemi di "coscienza" nel mischiare LEGO/NON LEGO 😄

Link to post
Share on other sites

A seconda dei gusti, un sistema (Arduino, Micro:Bit, ecc.) ci sembrerà più simpatico degli altri perché personalmente considerato più facile da metter su, programmare, modificare. Nel mio caso, per controllare i treni, feci scelte alquanto costose (Huzzah Feather, ecc.)... solo perché avevo già delle board da riciclare. Se spendere venti euro in più evita settimane di frustrazioni in un campo non amichevole per tutti (elettronica, programmazione...), allora sono soldi spesi bene.

Il problema tecnico più fastidioso è la questione dell'alimentazione. Dal pacco batterie, a seconda del tipo, dello stato di carica, della corrente che viene estratta in quel momento, arrivano tensioni non proprio comodissime (da 6.3V a oltre 10V, quando i microcontroller tipicamente vogliono 3.3V o 5V).

A questo punto le discussioni finiranno su quanti compromessi si fanno, cioè se il gioco passa da "mattoncini" a "modellismo con elettronica, coperto di mattoncini". 

Link to post
Share on other sites

Con una settimana esatta di ritardo (grazie Poste!) ho finalmente tra le mani il mio primo Micro:bit 😉

Stasera smonterò un telecomando dei treni e proverò la libreria IR per interagire con i Power Function. Seguiranno aggiornamenti...IMG_20180531_153526.jpg

IMG_20180531_153656.jpg

IMG_20180531_153705.jpg

IMG_20180531_153712.jpg

IMG_20180531_153738.jpg

La confezione include un piccolo foglio illustrativo delle macro funzionalità, (rimandando al sito microbit.org per tutto il resto), il micro:bit, 2 batterie da 1,5V, un cavetti USB (lungo solo 10cm) e il portabatterie con connettore adatto per il micro.

Preso dalla curiosità, ho provato subito il modulo con un classico "Hello World!" (i programmatori capiranno) che scrolla sullo schermo alla pressione del pulsante 'A' 😄 😄 😄

Link to post
Share on other sites

Ieri sera ho fatto il mio primo esperimento "vero" esperimento dopo l'immancabile Hello World 😉

Ho testato la libreria IR di Phillip per pilotare 4 M-Motor collegati a 2 ricevitori configurati rispettivamente sul canale 1 e 2.

Dopo un'iniziale perdita di tempo dovuta ad un errore di connessione del diodo IR presente nella foto che accompagna l'articolo (e che già ho segnalato all'autore) sono riuscito a far accendere in sequenza, per poi spenderli tutti insieme, i 4 motori.

In realtà, se guardate bene il video, il primo motore non si spegne... sostanzialmente, l'invio troppo repentino di comandi IR non sempre viene correttamente recepito/interpretato da ricevitori.

Del resto, per l'impiego che ne voglio fare, non avrò bisogno di inviare più comandi IR senza una pausa di alcuni secondi l'uno dall'altro.

Il diodo l'ho dissaldato da un telecomando per treni (LEGO ovviamente) e l'ho poi saldato sulla PCB del micro:bit usando il Pin 0 (che è quello di default), ma può essere usato un qualsiasi altro pin di output semplicemente impostandolo nella routine "Start" del micro:bit. 

Il prossimo test sarà quello per valutare la sensibilità e l'impiego migliore tra due sensori: quello magnetico e quello di luce.

Successivamente, testerò l'impiego del sensore di luce del sistema RCX 😉

Link to post
Share on other sites

In questi giorni ho approfondito l'uso del micro:bit applicato al controllo dei treni LEGO facendo vari test/esperimenti che mi hanno dato modo di conoscere meglio questo "schedina", sia dal punto di vista hardware che software, e ho appurato che presenta le alcune "criticità" nell'applicazione specifica del campo "Automazione treni LEGO"

Faccio prima un paio di premesse, per meglio comprendere lo sviluppo di questo thread:

1) Di sistemi per il controllo di treni LEGO ne esistono a bizzeffe, da anni. Tra il più recenti, restando prettamente in ambito italiano, cito il progetto ArduTrain di Luca Bellan, basato su Arduino. Progetto molto bello ed interessante, ma che non mi stuzzica particolarmente per via dei troppi cablaggi necessari sul circuito.
Il mio scopo, infatti, è quello di realizzare qualcosa di molto più semplice, utilizzando il minor numero possibile di componenti esterni (ed usare al massimo i sensori, motori ed attuatori LEGO, anzichè di terze parti), che sia alla portata di tutti e che, in particolar modo, non abbia la necessità di riempire un diorama di cavi che parlano con un microcontroller centrale. Soprattutto quando il diorama è di grosse dimensioni, come nel caso di un diorama comunitario realizzato in occasione di un evento.

2) Dopo averci giocato un po', devo direi che la schedina BBC micro:bit è veramente un bel progetto didattico e mi chiedo (avendo due ragazzi in età scolastica) perché in Italia non ci sia un'iniziativa simile a quella della BBC in UK, a livello di programma scolastico. Tutto è lasciato alla sola, e quanto mai lodevole, iniziativa di singoli insegnati/professori. Peccato.
Come ho anticipato nell'apertura di questo post, nel campo di applicazione specifico del controllo dei treni LEGO, il micro: bit presenta qualche "criticità" che sulla carta non avevo considerato. Nonostante questo, continuo ad essere convinto nel proseguire a sviluppare il mio semplice sistema di controllo di 1-2 treni LEGO, basato su questa board 😉
Anche perché la semplicità di uso/programmazione di questa scheda è veramente alla portata di TUTTI, anche di coloro che non hanno mai scritto una riga di codice e consente quindi di far utilizzare/personalizzare il sistema a chiunque.

L'obiettivo che mi son posto è il seguente: controllare 1-2 treni, su un circuito ferroviario variabile, dove possono essere presenti elementi "motorizzati" quali passaggi a livello (quanti se ne vuole), scambi (anche in questo caso, senza limiti preimpostati), un massimo di due stazioni/punti di stop e un controllo della velocità basato almeno su due step.
Unica direzione di marcia del treno: nel caso di due treni, viaggiano in modo alternato ovvero mentre uno circola, l'altro è a riposo. E viceversa.

Veniamo ora alla parte pratica e alle criticità che ho riscontrato durante i primissimi test:

1) Data la velocità di transito di un treno, sia il sensore magnetico, sia il sensore di luminosità che sono a bordo del micro:bit non sono sufficientemente affidabili nel rilevare il passaggio per gli "hot point" (stazione, passaggi a livello, scambi). In sostanza, non sono sufficientemente "reattivi" nel generare "l'impulso" del passaggio davanti all'attivatore (luce/magnete). Ho provato sia con un magnete LEGO 2x4 (la classica calamita da frigorifero), sia con 3 set di luci LED Power Function (6 luci in totale) e alla fine ho dovuto usare la potente "torcia" di uno smartphone per avere un risultato valido.
Questo implica che sono necessari sensori esterni al micro:bit, più sensibili ed efficaci (vedremo più avanti).

In questo video, uno dei vari test che ho fatto con il sensore di luce. Alla fine dovuto usare una forte fonte di luce (la torcia di uno smartphone) per ottenere un valido "delta" con la luce ambientale al fine di evitare 'falsi positivi'. In realtà, la documentazione del micro:bit specifica che il sensore funziona meglio se 'irradiato' da una luce dello stesso colore dei LED a bordo del micro:bit (sono gli stessi LED, infatti, il sensore vero e proprio). Mi riservo quindi di fare un test anche con un fonte luminosa rossa (userò un gruppo di LED), giusto per vedere se effettivamente c'è una migliore reazione. In ogni caso, resta il problema della velocità del treno e dei tempi di reazione del sensore. (Nel video, il treno si ferma ogni 3 passaggi davanti al sensore).
Nota: all'inizio, rilevo due volte il valore della luce ambientale premendo sul pulsante B del micro:bit (la prima volta il valore è sempre 255, non valido) da usare come valore base di riferimento, per identificare la successiva differenza di luminosità durante il passaggio dall'hot point.

2) La libreria IR che ho segnalato nel post di apertura di questo topic non si è rivelata altrettanto affidabile (problema da aggiungere alla già nota poca affidabilità del sistema IR LEGO): ogni tanto qualche comando viene "perso"... e non è una bella cosa se un passaggio a livello resta alzato al passaggio di un treno, o se un treno prosegue la sua corsa quando dovrebbe fermarsi in stazione.
Questo, purtroppo, obbliga a dover intervenire sul motore del treno in modo diverso dai comandi via IR, ovvero controllandolo direttamente dal micro:bit,tramite un driver PWM, oppure intervenendo sulla linea del circuito ferroviario a 9V.

Alla luce di questi riscontri, ho quindi  cambiato strategia rispetto l'idea iniziale, gestendo gli hot point tramite gli switch meccanici dell'RCX (i sensori di tocco 879 di cui potete vedere l'interno in questo topic) connessi direttamente al micro:bit, e pilotare l'avanzamento/arresto/velocità del treno tramite intervento diretto sull'alimentazione del circuito ferroviario.
Del resto, io sono sempre stato più per il sistema dei treni a 9v che per quello PF 🙂

In questo primo test, ho usato un sensore di tocco posizionato lateralmente al treno, attivato da una "sporgenza" montata lungo il circuito. Nell'esperimento, conto il numero di giri (ovvero di passaggi davanti alla "sporgenza" e li trasmetto via radio ad un secondo micro:bit, che si occupa di visualizzarli sul sul display (parlerò più avanti, del discorso 'radio').

 

In quest'altro video, il dettaglio dell'azionamento del sensore di tocco:

Avendo la necessità di discriminare vari "hot point" lungo il circuito (e decidere come agire di conseguenza sul comportamento del treno) ho fatto alcuni tentativi e alla fine sono arrivato ad una soluzione più elegante e robusta di quella finora mostrata (e che ha delle criticità, come lo "spostamento" laterale del treno, quando tocca il sensore).
In pratica ho posizionato i sensori sul fondo di un carrello 😉

34533794_10214573866534228_6753601563450671104_o.jpg 34472461_10214573866214220_3915816748569329664_o.jpg 34466976_10214573865814210_8715302660145676288_o.jpg 34462657_10214573866974239_8643052664457789440_o.jpg 34476839_10214573321320598_2561329456643833856_o.jpg

34606716_10214573868294272_1376368870398361600_o.jpg 34579355_10214579260269068_5177963536415981568_o.jpg 34459176_10214573868654281_9139659933095034880_o.jpg 34692329_10214580948711278_2890941481915252736_o.jpg 34480476_10214580949111288_874966184875786240_o.jpg

In pratica sono 4 switch del sistema LEGO RCX montati verticalmente sotto un carrello (sono partito dal portacontainer del 7939) che possono essere attivati da una "sporgenza" costituita dagli "slope curved + tile", dislocata lungo il tracciato e posizionabile sui 4 stud interni ai due binari.
4 posizioni diverse, per 4 sensori, per altrettante 4 funzionalità differenti (vedremo più avanti, come utilizzarle).

A questo punto, prima di proseguire, è necessaria una spiegazione di come "immagino" questo mio sistema di controllo dei treni...

Lo farò per fasi, così come sto procedendo nella realtà.

Partiamo dallo scenario più semplice: un circuito chiuso, sul quale transita continuamente il treno e che si ferma periodicamente.
Effettuati 'n' giri, il treno deve fermarsi per 'x' secondi (simulando la fermata in stazione) e poi  riprendere il suo viaggio, ripetendo il loop.
In pratica, quello che già si vede nel video in cui provo il sensore di luce....

Per ottenere questo, ho bisogno di un solo hot point (nell'immediata vicinanza della stazione). Ad ogni passaggio, il "sensore 1" (uno dei 4) viene premuto e il software a bordo del micro:bit incrementa internamente un contatore. Arrivati ad un numero 'x' di giri (diciamo 3), il micro:bit agisce sul motore e ferma il treno.
Resta in attesa per 5 secondi (o quanto si vuole) e poi, azzerato il contatore di giri, agisce nuovamente sul motore,facendo ripartire l'intero ciclo.

Ma come agisco sul motore? Questo dipende dal tipo di circuito/motore al quale si vuole applicare il sistema.
Se uso un motore PF, alimentato dal pacco batteria LEGO (quello dei treni attuali, per intenderci), devo intervenire direttamente sul motore mediante un driver PWM (se voglio anche modulare la velocità) o più banalmente tramite un microrelè ON/OFF. In quest'ultimo caso dovrò prevedere un resistenza per limitare il voltaggio al fine di evitare che il treno vada troppo veloce (deragliando in curva).

Lo stesso principio lo posso applicare sull'alimentazione di un circuito 9V...
La domanda sorge spontanea: come posso agire sul circuito 9V da bordo treno? 🙂
Semplicemente con l'introduzione di un secondo micro:bit, posizionato vicino al regolatore 9V, che riceve via radio i comandi di azione dal micro:bit a bordo treno.
Pertanto, quando la logica del micro:bit a bordo treno deciderà quanto sarà arrivato il momento di fermare il treno e invece di agire direttamente sul motore trasmetterà un "messaggio" via radio all'altro micro:bit che, a sua volta, trasformerà questo messaggio in una determinata azione sul circuito di alimentazione (modulazione PWM oppure ON/OFF).

Uno dei vantaggi del sistema micro:bit, infatti, è quello di implementare un sistema di comunicazione via radio bidirezionale tra più micro:bit (anche diversificando i canali di "ascolto") talmente banale da usare che rende possibile creare un sistema di controllo distribuito, senza cablaggi lungo il circuito, rendendo tutto molto più pulito e versatile.
(nota: il micro:bit implementa anche il protocollo BLE, ma è mutualmente esclusivo con il protocollo radio proprietario del micro:bit. O di usa il BT, o si usa il sistema radio.)

Spero che fin qui sia tutto chiaro... in pratica, grazie ad uno switch a bordo treno, collegato al micro:bit, possiamo determinare quanti giri ha compiuto il nostro treno e agire di conseguenza sul treno stesso, facendolo viaggiare/fermare.

Ovviamente, nello scenario appena descritto, possiamo personalizzare alcuni aspetti come la direzione del treni (alla ripartenza, posso decidere di andare al contrario) o la variazione del numero di giri che determinano la fermata.

A cosa servono, ora gli altri 3 sensori?...
Lo spiegherò in un successivo post 😉

Nel trattempo, ieri mi sono arrivati ulteriori componenti elettronici per fare altri test: sensori reed (in caso i sensori di tocco 879 non si rileveranno affidabili), e i driver PWM a doppio canale (ognuno può pilotare 2 motori) DVR8833 e L9110S (ne ho presi due diversi, giusto per provarne nel caratteristiche e le dimensioni:
Da sinistra a destra: contatto reed, DVR8833, L9110S)
34745867_10214587343351140_3468464203537317888_o (1).jpg

Oggi pomeriggio conto di proseguire con un test reale dei 4 sensori direttamente sul circuito ferroviario e nei prossimi giorni vi riporterò gli ulteriori sviluppi.
Se avete idee, domande, suggerimenti e magari state lavorando anche voi su qualche progetto simile, vi invito ad intervenire per condividere esperienze e soluzioni 😉

 

Link to post
Share on other sites

Ieri pomeriggio ho fatto un test su "strada" del blocco sensori.
Test molto semplice: ad ogni giro, ferma il treno per 3 secondi e poi riparti, per un totale di 4 giri.
Ho iniziato a fare il test con un solo sensore (uno dei due più interni) e, nonostante abbia funzionato tutto, si è evidenziato un "errore di progettazione" dovuto al fatto che in fase di sviluppo ho lavorato sempre su un rettilino, senza considerare le curve 🙂
Questo il video del test (non prestato attenzione al cablaggio, ancora tutto molto "sperimentale")

Il problema si presenta in curva, in quanto vengono attivati i sensori più esterni (nel video il treno gira sempre per un verso, ma in un tracciato reale girerà in entrambe le direzioni).
Nelle foto che seguono, cerco di evidenziare il problema:
34907770_10214594391767346_9104530545177526272_o.jpg 34779060_10214594391047328_9162260102546194432_o.jpg 34822166_10214594390167306_7840971069572775936_o.jpg

Nella prima foto ho evidenziato in giallo il tracciato della rotaia e nelle successive due evidenzio il sensore di tocco che, in piena curva, si viene a trovare proprio nel centro della rotaia, con la conseguenza di essere azionato quando non è necessario 😞

34579355_10214579260269068_5177963536415981568_o.jpg.8ff3d859974d1695094f67419ad3ed6d.jpg

Sostanzialmente, quindi, questi due sensori più esterni non possono essere utilizzati con questa configurazione.
Ho quindi pensato di shiftare tutto di 1/2 stud e sacrificare un sensore, portandoli a 3, di cui uno avrà lo scopo di 'escludere' gli altri due quando necessario (ad esempio, durante il passaggio su uno scambio, per evitare 'falsi positivi').
Per ora ho fatto un test su LDD e sembrebbe "funzionare". Nel pomeriggio conto di ricostruire il carrello e vedere se questa soluzione bypassa il problema.
(i brick gialli rappresentano i sensori e i tracciati bianchi mostrano le linee di passaggio sui tile)
3sensori.png

Link to post
Share on other sites

A questo indirizzo potete vedere il software di test che ho utilizzato finora (lo potete tranquillamente visualizzare online, senza aver alcun editor sul vostro PC/smartphone)
Qui di seguito, invece, una spiegazione veloce del codice:
codice.png

- All'accensione (blocco "1") viene eseguito un countdown 3-2-1 e subito dopo vengono abilitati i sensori (a generare un rispettivo evento, associato ad ognuno di essi, se premuti).
Viene impostata una variabili "velocità" sul valore 700 e tale valore viene scritto sul Pin0 del micro:bit, impostando il periodo della modulazione PWM: in sostanza, sul Pin0 c'è collegato il modulo PWM che controlla il motore LEGO e quindi, in poche parole, il treno parte 🙂

Mentre il treno gira, arriverà al punto in cui un sensore toccherà il suo rispettivo "hot point"... faccendo riferimento al video del post precedente, sul circuito avevo posizionato un hot point per 'attivare' il sensore collegato al pin P15. Quindi, quando viene attivato quel sensore ecco cosa accade:
a) vengono momentaneamente disattivati tutti gli altri sensori
b) viene mostrato il n.3 sul display LED (a scopo di debug)
c) viene chiamata la funzione 'Pausa' (spiegata più avanti, ed eseguita parallelamente)
d) aspetto 1,5 secondi 
e) riattivo i sensori affinché possano generare nuovamente gli eventi

La funzione 'Pausa' si occupa di:
a) Controllare quante volte il treno è passato per l'hot point
b) Se i passaggi sono inferiori o uguali a 3, allora:
  b1) spenge il motore
  b2) preimposta la variabile velocità al valore 700 (a regime, altre funzioni potrebbero aver cambiato questo valore)
  b3) aspetta 3 secondi
  b4) riavvia il motore
c) se i passaggi sono superiori a 3, chiama la funzione "StopProcedura" che si occupa di fermare definitivamente il treno

Ho predisposto anche le funzione Aumenta e Rallenta, attivabili da altrettanti sensori, per aumentare o diminuire la velocità del treno durante la percorrenza del tracciato... immaginate, ad esempio, di voler lanciare alla massima velocità il treno durante un rettilineo lungo, e di volerla diminuire prima di entrare in una curva (per evitare deragliamenti) e di riaumentarla all'uscita della curva.
Oppure, semplicemente rallentare il treno prima di fermarlo definitivamente, simulando appunto un rallentamento prima dell'ingresso in stazione.

Ovviamente la logica di funzionamento è ampiamente adattabile... ad esempio, non sono effettivamente necessari due sensori per aumentare/diminuire la velocità del treno, ma ne è sufficiente uno...
- la prima volta che incontro l'hot point relativo al "sensore di velocità", farò in modo di diminuire la velocità
- la seconda volta che icontro un altro hot point, sempre relativo al "sensore di velocità", farà in modo di aumentarla
Mi basterà quindi mettere un primo hot point 30 cm prima dell'ingresso in curva e un secondo hot point all'uscita della stessa.
tracciato.png

 

Link to post
Share on other sites
6 ore fa, GianCann ha scritto:

Il problema si presenta in curva, in quanto vengono attivati i sensori più esterni 

E se provassi ad usare solo due sensori in corrispondenza dei 2 stud centrali per definire fino a 5 funzioni diverse? 

Non ho sotto mano i pezzi per fare un esempio, proverò quindi a descriverlo:

 

funzione 1 - tile su stud destro (sensore 1)

funzione 2 - tile su stud sinistro (sensore 2)

funzione 3 - tile su stud destro + tile disassato in lunghezza su stud sinistro (sensore 1 e con ritardo (qualche decimo?) sensore 2)

funzione 4 - tile su stud sinistro + tile disassato in lunghezza su stud destro (sensore 2 e con ritardo  (qualche decimo?) sensore 1)

funzione 5 tile su stud destro  e sinistro (sensore 1 e 2 in contmporanea)

le funzioni da 1 a 4 verrebbero eseguite con un po’ di ritardo, quei decimi necessari alla scheda per verificare la presenza o meno del tile disassato, ma il problema più grosso è ricordarsi di “invertire” i comandi per le funzioni 3 e 4 quando si dovesse far girare il treno in senso contrario...

Che dici, troppo complicato?

Edited by cborella
Non riesco proprio a capire com ho fatto a scrivere con caratteri di dimensioni diverse...
Link to post
Share on other sites
1 ora fa, cborella ha scritto:

Che dici, troppo complicato?

Sulla carta no, nella pratica si... per vari motivi, a partire dai tempi di elaborazione e dalla velocità del treno (che è variabile anche in funzione del suo peso).

E poi, c'è la questione del software: lo scopo è quello di lasciare il progetto molto semplice, ovvero basato sull'editor "grafico", in modo da consentirne un uso a chi non ha grosse conoscenze infiormatiche.

Il "software" che ho predisposto è di tipo "event driver", ovvero determinato da  eventi (i trigger generati dai sensori).

Per implementare la soluzione da te proposta (sostanzialmente una bit mask), è necessario fare un polling  continuo delle porte di input e gestire lo stato delle stesse anche in funzione della velocità del treno.

Per far questo andrebbe bypassato il DAL (il framework che astrae l'hardware dall'ambiente di programmazione "visuale") e scrivere il codice in C per ottimizzare il tutto... tra l'altro, andrebbero usati dei microcontrollori (Ardunino o simili) più performanti. Non dimentichiami che il micro:bit, in confronto, è un "giocattolino" 😉

Fattibile è fattibile, ma diventa una cosa troppo di nicchia e sopratutto molto delicata.

Il mio obiettivo è quello di fare una cosa semplice, robusta e soprattutto affidabile... vediamo, via via che faccio gli esperimenti, se riesci nell'impresa 😉

Link to post
Share on other sites

Nel frattempo ho modificato il codice (la versione aggiornata la potete vedere qui) e rispetto la precedente prevede:

1) Possibilità di impostare la velocità di base del treno. Il valore viene  salvato nella memoria del micro:bit e richiamata ad ogni accensione (il micro:bit ha un piccolo FileSystem di 30Kb, che 'sopravvive' tra uno spengimento e l'altro. Viene 'resettato' solo quando il micro:bit viene flashato con un nuovo programma).
2) Partenza "dolce": Ad ogni avvio del treno, la velocità del motore viene impostata progressivamente fino a raggiungere la velocità "massima" (quella impostata al punto 1) nell'arco di circa 2,5 secondi)
3) I sensori ora hanno le seguenti funzioni:
 S1: trasmette via radio un messaggio ad un altro micro:bit (in un prossimo post spiegherò a quale scopo);
 S2: cambia la velocità del treno. La prima volta che viene attivato diminuisce la velocità. La seconda volta che viene attivato, viene ripristinata la velocità normale;
 S3: Usato per contare i giri e stabilire quando fermare il treno (in questa versione, il treno si ferma ogni 3 "attivazioni del sensore", resta fermo per 3 secondi e poi riparte "dolcemente" (vedi punto 2). In un circuito semplice, si può pensare che il treno si fermi sempre al solito punto, ma in uno più grande, si può benissimo modificare la logica e farlo fermare, ad esempio, ad ogni tocco del sensore, nel caso in cui si volesse simulare la fermata in più stazioni presenti lungo il percorso;
S4: Usato per disabilitare i restanti sensori. Alla prima attivazione del sensore, tutti gli altri vengono 'spenti'. Alla seconda attivazione del sensore, i restati sensori vengono riattivati. Lo scopo è quello di inibire i sensori nelle curve (per evitare il problema citato nel post precedente), durante il passaggio sugli scambi, o comunque per tutte quelle situazione in cui il tracciato potrebbe attivare involontariamente i sensori.

Appena il micro:bit riceve l'alimentazione esegue le seguenti operazioni:
1) carica in memoria (dal file system) il valore della velocità. Se non trova questa impostazione, imposta il valore a 700 (e la salva sul file system)
2) mostra sul display il valore della velocità
3) mostra la lettera "R" (Ready)

A questo punto si può premere su uno dei due pulsanti del micro:bit, i quali hanno le seguenti funzioni:
Pulsante "B": Ad ogni pressione, aumenta di 50 punti il valore della velocità di crociera del treno fino al valore massimo 1000, dopodichè riparte da 400. Ad ogni cambio di valore, lo stesso viene memorizzato sul File System per essere riutilizzato alla successiva accensione;
Pulsante "A": Dopo un countdown di 3 secondi, avvia "dolcemente" il treno...

Allo stato attuale, non è implementato alcun sistema di "fine ciclo": il programma prosegue finché la batteria riesce ad alimentare il tutto.
E' necessario fermare il treno "a mano" 😉

In un prossimo post, spiegherò come fermare il treno da 'Remoto'

Link to post
Share on other sites

Primo vero test su strada... anzi, su rotaia 😄 😄 😄

Stamani ho avuto modo di fare un primo test abbastanza valido dal quale posso iniziare a trarre qualche conclusione per proseguire con lo sviluppo del progetto.

Rimando tutti i dettagli ad un successivo post (ora devo dedicarmi ad altro) e vi lascio con lo schema del circuito di test e il video. Dovrebbero già essere sufficientemente esplicativi.

IMG_20180610_092608-picsay.jpg

 

Link to post
Share on other sites

Ogni soluzione ha i suoi vantaggi e svantaggi. Credo che i confronti sulle varie soluzioni dovrebbero piuttosto vertere sui principali punti, e cioè:
1) cos'è che LEGO non fa e che si vorrebbe ottenere (la soluzione riguarda la giocabilità o l'automazione per le esposizioni?)
2) quanto è invasiva (cioè i mattoncini non devono essere una decorazione ferroviaria a un sistema elettronico)
3) quanto è costosa (include anche il "quanti anni durerà prima di essere costretti a convertire ad altro sistema per mancanza di ricambi": vale anche sul versante opposto, cioè riguardo ai motori LEGO...).

La praticità/facilità dipende dalle personali opinioni e capacità del singolo. Anche la questione dei costi è tutto sommato un discorso personale (c'è chi è disposto a investire più di te, c'è chi ha già a casa pezzi riciclabili, ecc.: se apri una startup 😎 dovrai essere molto convincente, perché tanti di noi un sistema per automatizzare il circuitino ferroviario l'hanno già trovato... per esempio, io stesso ritengo interessante la soluzione col Micro:Bit, ma non abbastanza da farmi mandare in pensione il sistema con gli Sbrick e i tag RFID che ho allestito già).

Link to post
Share on other sites
7 ore fa, alf ha scritto:

Ogni soluzione ha i suoi vantaggi e svantaggi.

Concordo. Non credo ce ne sia una migliore dell'altra e tutto dipende dagli obiettivi e dagli scenari applicativi.

7 ore fa, alf ha scritto:

1) cos'è che LEGO non fa e che si vorrebbe ottenere

Un sistema come quello che sto realizzando io 😄 😄 😄
Dei tile/tag RFID da posizionare lungo il percorso (ognuno con una sua funzione identificabile da una stampa) e un ricevitore/pacco batteria che può funzionare in due modalità
1) Libera: Mi collego via telecomando/smartphone, e piloto il treno così come si fa ora...
2) Programmata: Il treno parte e segue le azioni in base ai tag che trova sul percorso. E le azioni potrebbero banalmente essere rallenta/accellera, ferma per 5 secondi e riparti

Pensa poi ad un sistema di "espansione", con passaggi a livello e scambi motorizzati, ognuno con il suo tile/tag dedicato.
E una semplice App, come quella del Boot, per "amalgamare" il tutto.

Voglio dire... oggi come oggi, è una cosa semplicissima da realizzare.

Diamine, tirano fuori decine se non centinaia di pezzi nuovi ogni anno (pensiamo solo alle minifig collezionabili o a quelle in licenza) e non posso investire in un "sistema" ferroviario un pochino (non di tanto) più intellingente?
E non parlo per noi AFOL (che come si vede dai tanti progetti "proprietari", sappiamo cavarcela) ma proprio per il target principale del loro business: i bambini.

L' sBrick è un bel progetto e forse LEGO poteva 'schioccare' le dita, acquistarlo ed integrarlo come suo prodotto... non era una cosa così impossibile da fare.
E invece, sono usciti fuori con il Boot ed ora con questo Power Up che, nonostante si integrino tra di loro (come ci ha anticipato @Piru Brick) resta comunque un sistema poco espandibile, sicuramente dispendioso e probabilmente poco versatile (ma aspetto di poterlo toccare dal vivo, per avere un giudizio più ragionato).

8 ore fa, alf ha scritto:

per esempio, io stesso ritengo interessante la soluzione col Micro:Bit, ma non abbastanza da farmi mandare in pensione il sistema con gli Sbrick e i tag RFID che ho allestito già

Quando hai tempo, che ne diresti di aprire un topic e illustrarci anche il tuo progetto? 😉

 

10 ore fa, Pix ha scritto:

Beh se vuoi far concorrenza all'sBrick possiamo parlarne 😂 ...apriamo una Startup...i fornitori li ho 😎

Non credo di poter far concorrenza all'sBrick, ma sono sicuro che questo progetto basato sul micro:bit (e la sua veramente semplice modalità di programmazione) possa aver un certo successo, rispetto a soluzione più "articolate".
Una cosa è certa: per ora sono ancora in fase di prototipizzazione e quindi è tutto un po' "casalingo": appena avrò fatto la quadra, farò produrre una scheda di break-out specifica per micro:bit + power function in modo da ridurre cablaggi e facilitare l'inserimento nell'ambiente LEGO.

P.S. Qualcuno ha già fatto un case per il micro:bit compatibile LEGO 😉 
https://core-electronics.com.au/micro-bit-enclosure.html
(mi toccherà fare un ordine in Australia 😄 😄 😄 )

Link to post
Share on other sites
il 10/6/2018 alle 10:00, GianCann ha scritto:

Rimando tutti i dettagli ad un successivo post

Come anticipato, ho fatto un primo test su strada del piccolo sistema di automazione che sto sviluppando per l'uso in un diorama cittadino con lo scopo di dare una "dinamicità" più realistica al circuito ferroviario e che non richieda necessariamente interventi esterni.

Il circuito di test, molto semplice per motivi di tempo a disposizione, ha messo alla prova i 4 sensori LEGO e il software predisposto per il micro:bit.

Faccio notare (dal video non è evidente) che tutto è alimentato dal pacco batterie 9V del sistema PF (in un successivo post, mostrerò lo schema delle connessioni utilizzate).

Il treno parte dolcemente, arrivando alla velocità massima preimpostata passando per 3 step di incremento nell'arco di poco meno di 3 secondi.

Il primo "hot point" che incontra è quello della "trasmissione dati": in questo test il micro:bit a bordo treno invia un messaggio contenente il numero "1" a tutti i micro:bit in ascolto sullo stesso canale. La possibilità di comunicare con altri micro:bit offre innumerevoli possibilità di interazione che illustrerò più avanti.

Successivamente, ho inserito uno scambio ferroviario preceduto e seguito dagli hot point che disabilitano/abilitano i sensori.

Lo scambio ferroviario, infatti, ha una rotaia che attraverso obliquamente le altre due parallele. Tale rotaia, essendo alla stessa altezza dei sensori di tocco, causerebbe l'attivazione "non voluta" dei sensori.

Una volta riabilitati i sensori, il treno incontra l'hot point della regolazione della velocità: la prima volta che viene intercettato questo hot point il micro:bit diminuisce il parametro che modula la velocità del treno. Stiamo per entrare in curva (spesso i nostri treni deragliano nelle curve, se lanciati troppo veloci...) e quindi "rallentiamo" il treno per affrontarla in sicurezza.

Immediatamente dopo l'hot point "velocità", il treno trova nuovamente un hot point per la disabilitazione dei sensori: in un precedente test avevo riscontrato il problema dell'attivazione dei sensori esterni durante la percorrenza delle curve e quindi, prima di affrontare la curva, disabilito i sensori.

Noterete che nella curva opposta a quella "gestita" non c'è alcun hot point per disabilitare i sensori. Come mai?

In realtà, non sempre il sensore che si trova interno alla curva viene effettivamente attivato (è questione di qualche frazione di mm in più o meno).

E quindi non ho messo alcuna gestione della sospensione dei sensori, proprio per valutare l'attivazione "non voluta": in questo test, non è mai avvenuta 🙂

Appena il treno esce dalla curva, tutti i sensori vengono riabilitati e a seguire viene subito intercettato il sensore del cambio velocità. Siccome ne era stato già trovato uno (che ha causato il rallentamento), quest'ultimo si occupa di ripristinare la velocità massima preimpostata... il treno "scatta" qui in avanti andando incontro all'ultimo hot point: il contagiri!

Questo hot point stabilisce il punto in cui il treno deve decidere se fermarsi o semplicemente se conteggiare il passaggio. Ovviamente possiamo avere più hot point di questo tipo lungo il percorso e gestire la logica come più ci aggrada.

Ad esempio, immaginiamo di avere 3 stazioni/fermate. Possiamo scegliere se fermarci ad ogni fermata (stile tramvia/metropolitana) oppure fermarsi a tutte le stazioni solo al primo giro e poi percorrere tutto io circuito senza più fermarsi per 2-3 giri.

Nel test specifico, il treno si ferma ogni due giri per poi ripartire con l'intera sequenza.

Insomma, questa prima prova su "rotaia" è andata piuttosto bene. Al di là della trasmissione radio, tutto ciò è comunque tutto fattibile anche con un vecchio RCX... peccato che il firmware sia così volatile (basta togliere le batterie per qualche secondo, e si oerde tutto) e che la programmazione dello stesso non è proprio alla portata di tutti, oltre allo sbattimento di dove far funzionare i driver USB/seriale per far funzionare l'IR Tower necessario alla programmazione (vero @Biffuz? 😄 )

Al momento, questo mio sistema presenta le seguenti criticità:

1) I sensori di tocco 879 non sono precisi/sensibili: ne ho una decina ed tra questi ho fatto varie prove prima di selezionare i 4 più sensibili (gli altri richiedevano una pressione più forte del pulsante, tale da non essere sempre attivati nei passaggi sugli hot point).

Per aumentare la loro "sensibilità" aggiungo che i tile posizionati all'interno del binario non sono "incastrati" fino in fondo sugli stud, ma solo quanto basta a non farli muovere.

2) I sensori sono "ingombranti": occupano ognuno lo spazio di un brick 2x3 + 1 plate 2x3 (plate di collegamento più cavo elettrico).

3) È necessario gestire la disabilitazione dei sensori nelle curve e nel passaggio su scambi/incroci.

4) Tutta lo logica è sul treno. Questa è un vantaggio in termini di cablaggio (nessun filo lungo il circuito) ma è uno svantaggio in termini di uso del treno: finché si tratta di un treno merci, non ci sono grossi problemi in quanto basta inserire la carrozza di controllo lungo il convoglio... ma se si tratta di un treno passeggeri, bisogno mantenere il design e quindi averale una carrozza di controllo specifica per quel treno.

Per quanto mi riguarda, visto il costo dei componenti elettronici, val la pena avere 2/3 carrozze specifiche per altrettanti treni, anziché doversi preoccupare di cablare il circuito ferroviario, con le complicazioni e brutture del caso.

Il dubbio che ora mi assilla è quello dei sensori... devo testardamente proseguire con i sensori LEGO oppure passare ai più semplici, affidabili e versatili sensori reed? O, in alternativa, a sensori micro-switch a levetta?

Nel frattempo che decido sul da farsi, proseguo con lo sviluppo del software: userò un secondo micro:bit per configurare alcuni parametri da remoto (velocità di base/numero di giri per la fermata/tempo di sosta) e per fermare/avviare il treno in caso di necessità.

Link to post
Share on other sites
21 ore fa, alf ha scritto:

...ma non abbastanza da farmi mandare in pensione il sistema con gli Sbrick e i tag RFID che ho allestito già).

Essendo pro-sBrick e beta tester di quest'ultimo, sono interessato a ciò che hai fatto 😎

Link to post
Share on other sites
4 minuti fa, Pix ha scritto:

A questo punto non capisco perché non utilizzare sensori touch o sensori di prossimità custom e non LEGO

In effetti è solo per una questione di principio... cercar di minimizzare al massimo i componenti esterni anche se, d'altra parte, già utilizzare il micro:bit e "tagliare" i cavi PF/9V per fare i collegamenti manda "a quel paese" la 'questione di principio' 😞
Probabilmente farò uso dei reed (5 sensori li ho pagati  € 7,99 su Amazon ed ho pure speso troppo...) e compatterò il tutto, lasciando comunque la logica degli hot-point.

Maledetta LEGO: cosa diamine ti costava fare un sistema più intelligente per giocare con i tuoi treni? 😄 😄 😄

Link to post
Share on other sites
5 minuti fa, GianCann ha scritto:

...Maledetta LEGO: cosa diamine ti costava fare un sistema più intelligente per giocare con i tuoi treni? 😄 😄 😄

Si sono dimostrati degli assoluti incompetenti.
E' questo quel che succede quando non hai concorrenza alla spalle, e chi lavora in ambienti dove "se non ti aggiorni perdi clienti" sa di cosa parlo.
Gli bastava comprare la Vengit e importare l'sBrick.

Spiace perché TLG era precursore dell'automazione con i 12V, da lì è stato solo un declino.

Detto questo, anche l'NXT era ed è pieno di difetti, per sistemarlo e produrre l'EV3 hanno dovuto far partecipare gli AFOL al progetto (vedi Daniele...). Perché non fare la stessa cosa con i treni? comunque ora sono un pò OT... 😐

Link to post
Share on other sites
22 minuti fa, Pix ha scritto:

Spiace perché TLG era precursore dell'automazione con i 12V, da lì è stato solo un declino

In effetti, ogni volta che vedo un sistema 12V, mi chiedo come mai LEGO abbia abbandonato questa strada 🙂
Se avessero portato avanti quell'idea, con le tecnologie odierne, sai cosa avrebbero potuto fare?
E invece ci ritroviamo con il Boost e con un telecomando Bluetooth con portata di 4 metri. Complimenti TLG!

Comunque, dobbiamo farcene una ragione ed arraggiarci: se vogliamo restare prettamente legati al mondo LEGO abbiamo RCX/NXT/EV3, ognuno con i suoi limiti e le sue complicazioni.
E se devo "adattare" loro, tanto vale realizzarsi una soluzione personalizzata e più semplice da gestire.

Link to post
Share on other sites

Tornando a parlare del progetto basato sul micro:bit, vediamo ora quali sono i componenti necessari per implementarlo.

Partiamo dalla versione PF, ovvero con motore alimentato dal pacco batterie LEGO a 9V.

- Pacco batteria 9v (pile AAA)
- Motore treno PF
- Sensori di tocco RCX 879 (x4) - (in alternativa, è possibile utilizzare le varianti 879c02 / 879c03 / 879c04 o il modello 2974c01
- Microcontrollore micro:bit (€ 18,99 su Amazon.it, oppure € 21,67 completo di cavetto USB e pacco batteria 2x stilo AAA, con connettore adattore al micro:bit)
- Regolatore di tensione MP1584EN (€ 1,5 l'uno - su Amazon.it vendono un bundle da 6 pezzi a € 8,99)
- driver PWM per motori DC DVR8833 (€ 3,3 l'uno - su Amazon.it vengono un bundle da 3 pezzi, a € 8,99)
- Cavetti PF/9v 8886 (€ 3,99 l'uno)

Se si ha dimestichezza con saldatore e stagno, i collegamenti possono essere effettuati (con un po' di attenzione) direttamente sul micro:bit. Altrimenti, alla lista della spesa, è necessario aggiungere una schedina di break-out dove innestare il micro:bit ed accedere ai pin di I/O in modo più comodo.

Dato che il mio progetto finale prevede l'uso di più micro:bit per gestire scambi e passaggi a livello, ho acquistato più schede di break-out, diverse tra loro per dimensioni/caratteristiche.
Ecco quelle che ho preso (dalla più piccola, alla più grande):
- SparkFun micro:bit breakout (pagata  circa € 6,30 su Robot Italy)
MakerHawk BBC micro:bit breakout (€12,99 su Amazon.it)
Micro: bit Breakout Board (Octopus: bit) (€15,99 su Amazon.it)

Nota: L'ultima è più costosa, ma ha delle caratteristiche in più, come la conversione 3.3v/5v per collegarsi anche a sensori che richiedono obbligatoriamente la tensione 9v e un connettore che per ogni pin replica anche i pin VCC/GND per semplificare la connessione ai vari sensori. D'altra parte, il lato negativo è la dimensione più grossa rispetto le altre.
Su AliExpress c'è un modello di scheda di breakount abbastanza compatta, con la linea di connettori a 3 pin (VCC/GND/PINx) e, soprattutto, compatibile con i pin technic LEGO.

A parte un modello di scheda di break-out (la prima dell'elenco), ho acquistato tutto il materiale su Amazon.it spendendo sicuramente di più rispetto ad altri canali.
Su AliExpress ad esempio, se non si ha fretta, si può risparmiare sicuramente qualcosa...
Dato che avevo voglia di sperimentare subito, mi son dovuto adeguare ai prezzi Amazon con il vantaggio di ricevere i vari componenti in un tempo variabile da 1 a 3 giorni.

Come si evince dall'elenco, sono necessari ulteriori due componenti elettronici, oltre al micro:bit.

Il micro:bit lavora a 3.3v e può essere alimentato direttamente da due batterie AA collegate all'ingresso di alimentazione 3.3v oppure tramite un cavetto USB (5v).
Io ho voluto alimentarlo direttamente dal pacco batterie LEGO e quindi ho pensato di usare un regolatore variabile già pronto (per chi mastica di elettronica, può banalmente usare un LM7803 ed un paio di condensatori). Nulla vieta comunque di usare un portabatterie per 2 stilo ed alimentare separatamente il micro (vedremo nello sviluppo del progetto che userò anche questa soluzione).

L'altro componente esterno al micro:bit è un driver PWM per motori in tensione continua (come i PF/9v LEGO).
Questa schedina deve essere alimentata con la tensione di lavoro del motore (quindi 9v) e collegata al micro:bit tramite 2 fili: uno connesso alla massa (GND), l'altro al pin di uscita che useremo per pilotare la velocità del motore.
Anche i due fili che alimentano il motore vanno collegati a questa schedina.

Sostanzialmente (senza entrare troppo nei tecnicismi del sistema PWM), questa scheda riceve un "segnale" a 3.3v modulato dal micro:bit e lo trasforma in un segnale modulato a 9v per alimentare il motore.
In base alla modulazione, viene banalmente variata la velocità del motore.
Questo componente è essenziale (a prescindere dall'uso della scheda di logica, che sia micro:bit, Arduino o altro).

Lo schema elettrico è il seguente.

Collegamento elettrico.png

Per collegare tutti i componenti tra loro abbiamo più possibilità e tutto dipende da quanto vogliamo che sia pulito e/o modulabile/riusabile il nostro sistema.
Molto dipende anche dai sensori che si vogliono utilizzare (il sensore 879 richiede il cavetto esterno tipo 9v, ma esiste anche in versione con cavo integrato 2974c01 -2x4 stud-, ma il suo costo non è irrisorio).

Per collegare pacco batteria/motore e sensori di tocco al resto dei componenti io ho utilizzato alcuni cavetti 8886 che ho appositamente tagliato 😞
Il cavo 8886, oltre a essere una prolunga per il sistema PF, ha infatti anche la funzione di adattatore con il vecchio sistema 9V.
(esiste anche la versione 8871, lungo 50cm)

8886_1.jpg

Come si vede dalla foto, il sistema PF prevede 4 cavi.
Normalmente, i due fili esterni portano la tensione 9V ai vari dispositivi collegati in cascata, mentre i due interni (identificati dalle sigle C1 e C2) controllano il motore collegato.
Applicando la tensione 9v su questi due cavi interni, in base alla polarità applicata sugli stessi (GND-9V o 9V-GND) si inverte il senso di rotazione del motore.

connettore.png

Tagliando 4 cavi 8886 ho potuto collegare i sensori 879 (usando la parte del cavo con connettore 9V) al micro:bit.
Con 2 delle restati "metà parti" dei cavi tagliati (lato connettore PF), ho potuto collegare il pacco batteria alle schede elettroniche (usando i due fili esterni) e il motore alla scheda DVR8833 (usando i due fili interni).

Per un approfondimento sullo schema del cavetto PF vi rimando all'articolo LEGO PF Wire Hacking.

Questo schema, ripeto, è relativo alla versione PF.

Ora sto lavorando alla versione 9v, che prevede l'uso di due micro:bit, meno cablaggi a bordo treno, e l'uso di sensori "reed" in alternativa ai sensori di tocco 879.
...al prossimo aggiornamento 😉

Se avete domande o dubbi, son a disposizione.

Link to post
Share on other sites

Analizzata l'automazione di un treno con motore PF e pacco batteria a bordo del convoglio, vediamo ora come pilotare un circuito con motore 9V introducendo ulteriori componenti al nostro sistema: passaggi a livello e scambi.

La comodità del sistema RC/PF è soprattutto quella di far percorrere contemporaneamente sullo stesso tracciato più treni (anche in direzioni opposte) e l'uso dei binari "flex" che offrono qualche vantaggio in più nella geometria di un circuito (anche se spesso e volentieri sono utilizzati in modo osceno 😄 )
Altro punto a favore è quello di poter disegnare tracciati impossibili da realizzare con il sistema 9V per via dei cortocircuiti elettrici che si verrebbero a creare (pensate ad un loop che rientra sullo stesso binario).

Lo svantaggio del sistema RC, in occasione di un evento espositivo, è quello del consumo di batterie (in parte bypassabile con le batterie ricaricabili) e del sistema di controllo IR, non sempre affidabile.

In un grande diorama city con un circuito ferroviario, solitamente, ci sono sempre almeno 2/3 treni che girano in continuazione.

Per questo motivo, ho sempre preferito utilizzare i binari 9V e relativi motori e nell'arco degli anni ho accumulato un discreto numero di binari/scambi/motori di questo tipo.

È quindi sempre stata mia intenzione automatizzare questo tipo di sistema oer renderlo più "dinamico". Ribadisco che sulla rete/youtube e su questo stesso forum, esistono vari progetti/esempi e documentazione sull'argomento e che il mio progetto è "uno dei tanti" con la differenza che si basa su un microcontrollore semplice da programmare/cablare.

Come detto in uno dei post precedenti, il mio cruccio è quello di non vedere fili elettrici in giro per il diorama 🙂
Per quanto si possa tentare di nasconderli, son sempre evidenti...
E poi, cambiando ogni volta il layout di un diorama, cambia anche il circuito ferroviario e le  distanze tra scambi/passaggi a livello/stazioni.

Per tale motivo, quando vidi che il micro:bit integrava un semplice sistema di comunicazione radio, ho ritenuto che fosse il candidato ottimale per lo scenario "distribuito" che avevo in mente.

In linea generale, i sistemi di controllo dei treni basati su Arduino/Raspberry, prevedono un sistema "centrale" (Arduini, appunto) che dirama sensori ed attuatori lungo in circuito e ne controlla lo stato e le azioni in funzione del passaggio dei treni.

La mia idea, invece, è quella di un sistema distribuito, dove esistono più micro:bit sparsi per il circuito (ognuno con una/due funzioni specifiche di cui occuparsi) e connesso via radio con i restanti micro:bit, agendo in base a comandi scambiati tra di loro.

Ecco lo schema che sto realizzando:

Diorama 9V-v2-new-2.png

Ovviamente il circuito è qui rappresentato come un "ovale" ma nella realtà, il disegno sarà più articolato e può prevedere più moduli (PL/Scambi/Stazioni). La posizione dei PL e degli scambi è assolutamente indicativa. Nello schema ho indicato anche i vari "hot point" che mi serviranno per controllare la posizione del treno e/o le funzioni da attivare.

Il funzionamento che voglio ottenere è semplice: alternare due treni nella percorrenza del circuito, azionando le sbarre dei passaggi a livello prima del loro transito.
Altra caratteristica, e la possibilità di modificare la velocità come visto per il circuito in versione PF.

L'alternanza dei treni è ottenuta tramite parcheggio di uno dei due su un binario di "servizio" che viene abilitato/disabilitato mediante uno scambio.

Gli scambi, infatti, funzionano anche da "interruttori di corrente" e permettono di isolare una parte del circuito.

Per molto di voi questo concetto è abbastanza chiaro, ma lo ripeto a beneficio di chi non conosce bene il sistema 9V:
Uno scambio può avere due posizioni: P0 (aperto) e P1 (chiuso).
Nella posizione P0, è come se lo scambio non esistesse... il treno transita regolarmente sulla parte di binario dritto dello scambio (a prescindere dalla direzione di marcia).

Binario2.png

Nella posizione P1, il treno in ingresso sullo scambio (ovvero in arrivo dalla parte "corta" dello scambio) viene deviato sul lato destro (o sinistro).
Il transito del treno proveniente dal senso opposto di ingresso dello scambio non è in alcun modo influenzato dalla posizione della levetta e dalla parte di arrivo.

Binario1.png

Quando lo scambio è in posizione P0, la tensione sulla deviazione viene scollegata e il tronco del binario è quindi non alimentato (sempreché non ci sia qualche altro punto di alimentazione sul tronco deviato).

Sfrutterò quindi questa caratteristica per interrompere la corsa di un treno, nel momento in cui avrà "ingaggiato" interamente il binario di servizio.

(continua appena posso)

Link to post
Share on other sites
  • 2 weeks later...
  • 3 months later...
  • 3 months later...

Ho ripreso in mano il progetto di automazione dei treni...

Dopo un periodo di 'riflessione', di documentazione e di esperienza 'domotica', ho deciso di adottare un sistema diverso per la rilevazione della posizione del treno lungo un circuito, e delle relative azioni da intraprendere.

Come ho già spiegato in precedenza, il problema principale che si deve affrontare nell'automazione di un grosso diorama è quello del cablaggio dei sensori/attuatori (check point, passaggi a livello, e scambi). Ho già illustrato che Micro:bit implementa un sistema di comunicazione radio che permette di superare questo scoglio, se non fosse per il fatto che tale 'chip' ha comunque delle dimensioni generose che lo rendono complicato da 'mimetizzare', oltre al fatto che ha un costo non bassissimo e che, moltiplicato per 'n' sensori, lo rende complessivamente antieconomico. Dato che nelle ultime settimane mi sono occupato anche di 'domotica', ho avuto modo di utilizzare per prima la 'dev board' D1 Mini, e poi direttamente l'ESP8266, un microprocessore che implementa lo stack wifi, diverse porte di I/O, la compatibilità con la maggior parte delle librerie Arduino e, soprattutto, una vasta community di sviluppatori.

Teneteconto che questo chip è praticamente utilizzato in qualsiasi prodotto di domotica WiFi (e quindi è anche largamente 'testato'). Ecco quindi che ho pensato di realizzare dei piccoli nodi 'Check-point' basati su questo chip, al quale ho affiancato un sensore di prossimità miniaturizzato (ADPS-9030 tipo quelli usati negli smartphone che fanno spengere il display quando si avvicina il dispositivo all'orecchio) e l'immancabile step-down per portare l'alimentazione a 3,3v richiesta dal microchip. Ognuno di questi componenti è montato sulla sua PCB da sviluppo ma, se fossero assemblati su una PCB realizzata ad-hoc, tutto potrebbe stare in uno spazio di 1x2,5 cm circa, considerando anche la presenza dell'antenna wireless disegnata sulla PCB stessa. L'alimentazione per questi check point la vorrei prendere direttamente dalla linea 9V dei binari che offrono una 'Infrastruttura di alimentazione' lungo tutto il percorso del diorama. I componenti mi sono arrivati in questi giorni, e sono in procinto di assemblarli in un primo prototipo per effettuare alcune prove sul campo.

Parallelamente, ho preso contatti con Luca Bellan, ovvero con lo sviluppatore di ArduTrain: l'idea è quella di unire le forze ed evolvere ArduTrain in una versione Wireless e quindi molto più semplice e comoda da implementare, virtualmente senza limiti di espansione. Non solo, l'idea è quella di basare il protocollo di comunicazione tra nodi/treni e 'Control Center' su MQTT, rendendo aperto il sistema a future implementazioni/espansioni ("Ehi Google, fai partire il treno passeggeri...")

I singoli nodi, dotati ognuno di uno specifico identificativo, saranno posizionabili in qualsiasi punto del diorama, ovvero laddove intendiamo rilevare la posizione di un treno o attuare l'apertura/chiusura di un PL/scambio. Il Control Center resterebbe basato su Raspberry 3, che grazie al Bluetooth integrato potrà pilotare anche i nuovi hub LEGO.

Nellafoto, i 3 componenti che comporranno il nodo 'Check point'. Ho messo una moneta da 50 cent per meglio comprendere le dimensioni che, ripeto, sono comunque generose per via delle PCB di cui si potrebbe fare a meno in caso di assemblaggio personalizzato. Da sx a dx: - Sensore di prossimità ADPS 9930 - ESP8285 (è un ESP8266+1 Mb Flash) - Step down 3.3v

IMG_20190110_145312.jpg

Link to post
Share on other sites
  • 2 weeks later...
1 ora fa, GianCann ha scritto:

@Valter1966 mi daresti una mano a disegnare una PCB compatta per questo sensore-attuatore-WiFi?

Ciao

Dopo l'avviso di Renato stavo giusto dando un'occhiata.

Non ho mai usato l'ESP8266 però ho trovato uno schema completo di PCB su adafruit dal quale si potrebbe partire:

https://www.adafruit.com/product/2471

Mentre per l'APDS9930 nessun problema, lo uso già sui miei nano e micro sumo, però funziona con l'I2C (SDA SCL su arduino). Sei sicuro che ci sia questa opzione sull'ESP8266?

Ti allego lo schema in PDF di ESP8266 e APDS9960 (è praticamente uguale al 9930, io li uso entrambi)

La tua previsione di 1x2,5cm mi sembra davvero ottimistica, perchè il solo modulo ESP8266 misura 16x24mm e per poterlo posizionare sul PCB serve come minimo una basetta da 18x24mm. L'antenna penso non si possa modificare. Sul lato "Bottom" ci starebbe tutto il resto (APDS9930 e regolatore 3V) con dei pad a saldatura superficiale per i fili. Non ci sarebbero fori per il fissaggio.

Considera anche che il montaggio del sensore APDS9930 non è molto agevole e non si può fare con un normale saldatore.

Non c'è nessun problema per farti il progettino (ovviamente FREE) e poi girarti i files Gerber per la produzione in Cina. Con 2$, spedizione esclusa, ti fanno 10 schede 10x10cm. Ci starebbero 20 tue schedine che per 10 fa ben 200 pz !!!!! (L'unica scocciatura è che dovranno essere ritagliate una ad una, ma con PCB spessore 0,6mm o 0,8mm è facile)

https://jlcpcb.com/

Però sarebbe meglio procedere con:

1 - Montaggio da parte tua del prototipo con giusto il necessario (anche usando le schedine della foto), così da definire lo schema elettrico e fare i primi test software.

2 - Mandare a me lo schema definitivo, poi in un paio di sere ti preparo il tutto.

Buona serata

Adafruit HUZZAH ESP8266 Basic Breakout.pdf

SparkFun_APDS-9960_RGB_and_Gesture_Sensor-v10.pdf

Edited by Valter1966
.
Link to post
Share on other sites

@GianCann su D1mini & ESP trovi un alleato (anche se l'ho usato sempre e solo con Arduino IDE per ora quindi con dei limiti)

Vedi se ti possono tornare utili questi link che provano a portare il protocollo dei modellisti (DCC) su ESP.


http://www.trainboard.com/highball/index.php?threads/dcc-wifi-controller-on-an-esp8266-07.111489/
http://trainelectronics.com/WiFi-esp8266/Setup/

Link to post
Share on other sites

@Valter1966 ho visto la tua email. Appena possibile ci sentiamo via telefono. Considera che non ho pensato di dirti che potremmo usare l'ESP-01, che è più stretto, visto che espone meno pin di I/O dell'8266. Ho solo il dubbio dubbio che si possano rimappare SDA/SCL sulle 4 GPIO esposte.

@pivan ho messo mano sull'8266 (e, più in generale sull'atmega328P) da un paio di mesi, e sto rinfrescando le nozioni di elettronica risalenti al 1990 🙂

Sto usando gli 8266 (è un bel "gioiellino") più che altro per semplici attività di domotica 'wireless' ed ho pensato che si possano sfruttare anche nell'ambito dell'automazione dei treni LEGO, impattando il meno possibile sui diorami. Il massima, sarebbe quello di riuscire a realizzare un sensore WiFi che possa entrare nel brick 2x4 di un sensore di luce LEGO (maledizione: ne avrò 5-6, ma non riesco a trovarne uno per smontarlo e vedere gli ingombri.

Ora mi leggo gli articoli che mi hai indicato...

Link to post
Share on other sites

Ok! Hai già fatto una scelta di campo sulla programmazione? 
Nel senso, rimani ad alto livello con Arduino in modo da riusare molto dell'esistente pur con i suoi limiti, o vuoi scendere a basso livello?
O magari "salire" ipotizzando scratch?
https://github.com/pgillich/ESP4S2

intanto sto guardando quello che avevi visto tu MakeCode perchè ne stanno facendo una versione beta dove pare ti puoi definire le tue board......... 😉 ora vedo se si riesce a fargli supportare un ESP

https://maker.makecode.com/

 

Link to post
Share on other sites

Ritengo che sia più comodo lavorare a 'livello" Arduino per via della moltitudine di materiale/librerie pronte all'uso, senza la necessità di dover mettersi a studiare datasheet/protocolli. Alla fine, non serve un sistema ad altissima precisione/velocità.

All'inizio ero partito con MakeCode/Micro:Bit più che altro per coinvolgere mio figlio di 13 anni che a scuola usano (direi raramente) Scratch.

Poi, visto che al momento ha altri interessi, ed io altre necessità, sono passato all'ESP8266 e Arduino.

(Off Topic: sto seguendo lo sviluppo del firmware Tasmota, per ESP8266. Ieri sono arrivati a 3 milioni di download dei sorgenti... Se già non lo conosci, dagli un'occhiata. Ho anche chiesto un paio di banali implementazioni per un supporto migliore alla comunicazione seriale, per usare i display 'intelligenti' Nextion).

Link to post
Share on other sites

@Valter1966

Pin definition: The ESP2866 doesn't actually have any hardware I2C pins - those labeled on the Thing are the default, but you can actually use any two pins as SDA and SCL. Calling Wire.begin() will assume pins 2 and 14 are SDA and SCL, but you can manually set them to any other pin by calling Wire.begin([SDA], [SCL]).

In pratica, si dovrebbe poter usare anche GPIO0 e GPIO2, benché GPIO0 è la GPIO che determina il tipo boot dell'8266 (Flash boot/Programming Boot)

Link to post
Share on other sites
21 minuti fa, GianCann ha scritto:

@Valter1966

In pratica, si dovrebbe poter usare anche GPIO0 e GPIO2, benché GPIO0 è la GPIO che determina il tipo boot dell'8266 (Flash boot/Programming Boot)

OK, però la schedina misura 14,3x24,8 mentre il brick 2x4 all'interno circa 13,2x29,2.

Nessun  problema con la lunghezza, ma in larghezza non ci sta, e dalle foto dell'ESP-01 non mi sembra che si possa "fresare" mezzo millimetro per parte
 

 

Edited by Valter1966
Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...