Vai al contenuto
GianCann

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...)

Condividi questo messaggio


Link al messaggio
Condividi su altri siti

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

Condividi questo messaggio


Link al messaggio
Condividi su altri siti

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 😉

Condividi questo messaggio


Link al messaggio
Condividi su altri siti

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 😉

Condividi questo messaggio


Link al messaggio
Condividi su altri siti

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.

 

Condividi questo messaggio


Link al messaggio
Condividi su altri siti
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.

Condividi questo messaggio


Link al messaggio
Condividi su altri siti
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".

Condividi questo messaggio


Link al messaggio
Condividi su altri siti
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 😄

Condividi questo messaggio


Link al messaggio
Condividi su altri siti

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". 

Condividi questo messaggio


Link al messaggio
Condividi su altri siti

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' 😄 😄 😄

Condividi questo messaggio


Link al messaggio
Condividi su altri siti

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 😉

Condividi questo messaggio


Link al messaggio
Condividi su altri siti

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 😉

 

Condividi questo messaggio


Link al messaggio
Condividi su altri siti

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

Condividi questo messaggio


Link al messaggio
Condividi su altri siti

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

 

Condividi questo messaggio


Link al messaggio
Condividi su altri siti
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?

Modificato da cborella
Non riesco proprio a capire com ho fatto a scrivere con caratteri di dimensioni diverse...

Condividi questo messaggio


Link al messaggio
Condividi su altri siti
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 😉

Condividi questo messaggio


Link al messaggio
Condividi su altri siti

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'

Condividi questo messaggio


Link al messaggio
Condividi su altri siti

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

 

Condividi questo messaggio


Link al messaggio
Condividi su altri siti

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à).

Condividi questo messaggio


Link al messaggio
Condividi su altri siti
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 😄 😄 😄 )

Condividi questo messaggio


Link al messaggio
Condividi su altri siti
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à.

Condividi questo messaggio


Link al messaggio
Condividi su altri siti
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 😎

Condividi questo messaggio


Link al messaggio
Condividi su altri siti

Come dici tu @GianCann è molto home-made come progetto. A questo punto non capisco perché non utilizzare sensori touch o sensori di prossimità custom e non LEGO, visto che costerebbero di meno e sono più affidabili di quelli di TLG in fatto di risposta e precisione. 

Condividi questo messaggio


Link al messaggio
Condividi su altri siti

Crea un account o accedi per commentare

Devi essere un utente per poter lasciare un commento

Crea un account

Registrati per un nuovo account nella nostra comunità. è facile!

Registra un nuovo account

Accedi

Hai già un account? Accedi qui.

Accedi ora

  • Navigazione recente   0 utenti

    Non ci sono utenti registrati da visualizzare in questa pagina.

×