Cerca nella community

Apro questo nuovo topic per introdurvi ad un progetto che abbiamo iniziato a sviluppare unitamente a @Valter1966 e @pivan e al quale ci piacerebbe coinvolgere altri AFOL di ItLUG e non solo. Penso ad esempio a persone come @alf, @fonderiadigitale, @bricksnspace ma sono sicuro che tra noi ci sono molti altri che potrebbero essere interessati ad avere una parte attiva nel progetto, ognuno con le proprie competenze, idee ed esperienze. Scopo del progetto è quello di colmare una lacuna di LEGO in tema di 'automazione/programmazione' di un diorama/circuito ferroviario. Nonostante il neonato Powered Up abbia introdotto il protocollo Bluetooth (che elimina una parte dei problemi del precedente sistema IR), non è in grado di soddisfare le esigenze di noi AFOL che vogliamo rendere più dinamici i nostri circuiti ferroviari. Sia chiaro: il nostro progetto non è certo una novità nel panorama AFOL. Sono stati moltissimi coloro che negli anni si sono ingegnati nell'automatizzare i diorami, soprattutto grazie alla facilità di programmazione offerta dalle ben note schede Arduino, ma ancora prima con gli RCX/NXT. La caratteristica principale del nostro progetto è la comunicazione Wireless tra i singoli elementi del sistema, rendendo più semplice implementare l'automazione anche su circuiti di grandi dimensioni senza la necessità di dover passare metri e metri di cavi per collegare sensori ed attuatori alla 'Control Unit' (capire meglio più avanti cos'è...) A questa caratteristica, si aggiunge lo sviluppo di componenti elettronici specifici, a basso impatto visivo, integrabili con i normali elementi LEGO. Ovviamente, per quanto cercheremo di sviluppare una cosa molto semplice da realizzare sul piano pratico (documentando passo per passo), non potrà comunque essere paragonato alla semplicità di accendere due dispositivi e fare il pairing tra loro (come il Powered Up, per intenderci...). Del resto, o ci si accontenta di usare un telecomando per fare andare un treno avanti/indietro regolandone la velocità, oppure ci si ingegna un pochino più del necessario per avere 2, 3 o 4 treni che circolano su un tracciato articolato, effettuando fermate programmate, azionando le barriere dei passaggi a livello primo del loro transito o attivando scambi per modificare il tracciato da percorrere. Questo nuovo topic nasce come prosecuzione di un discorso già avviato tempo fa e che vi invito a leggere come "background" informativo sui concetti relativi ad un automatismo ferroviario in ambito LEGO, benchè alcuni passaggi sono superati (soprattutto nella parte harware). ITS è fondamentalmente composto da sensori, attuatori e da una Control Unit. Sensori e attuatori parleranno con la Control Unit usando il protocollo MQTT per mezzo di un Broker MQTT (un sofware che agisce da centro di smistamento messaggio). Il protocollo MQTT è un protocollo di comunicazione molto diffuso in ambito IoT (Internet of Things). (Nota: non fatevi 'impressionare' da sigle/acronimi. È molto, molto più semplice di quanto vi possa apparire in una prima lettura.) Questo vuol dire che la Control Unit può essere realizzata i modi diversi ed integrarsi a sistemi già esistenti tipo ArduTrain (nel caso l'ideatore Luca Bellan decidesse di evolvere il suo sistema di controllo ferroviario implementando l'MQTT) anziché utilizzare componenti di terze tipo SBrick, EV3, NXT. Ricordate: lo scopo del progetto ITS è quello di sviluppare un sistema flessibile e facile da implementare, che offra un po' di dinamismo ad un diorama ferroviario LEGO, permettendo di espandersi con facilità verso "nuove frontiere". Come hardware di base per la Control Unit ci baseremo sulla scheda Raspberry 3B+ per il suo basso costo, le sue dimensioni, le sue caratteristiche (ecc. ecc.) tra cui il WiFi integrato (con la possibilità di funzionare da Access Point) e il Bluetooth (per parlare direttamente con i nuovi treni LEGO Powered UP, SBrick, Smartphone). L'hardware utilizzato per far girare la Control Unit non è in realtà così importante: in alternativa potrà essere utilizzato un qualsiasi PC portatile, purché ci sia un Access Point WiFi che faccia da "infrastruttura di rete". I software che useremo per questo progetto sono tutti Open Source e sono comunque sostituibili con altri simili, dato che si basano su protocolli e standard a loro volta aperti e largamente diffusi. Insomma: niente di proprietario/chiuso. Anche laddove scriveremo il nostro firmware specifico per l'harware sul quale svilupperemo i sensori/attuatori, il codice sarà comunque messo a disposizione di tutti anche perché, con il contributo di altri AFOL-Maker, potrà essere sicuramente migliorato/evoluto. Sensori ed attuatori, come già detto, dialogheranno con il protocollo MQTT su infrastruttura WiFI. Il cuore di questi dispositivi sarà il chip ESP8266 della EspressIf, diventato oramai molto diffuso, soprattutto nell'ambito della domotica. Il primo dispositivo che abbiamo avviato alla prototipizzazione è il sensore di prossimità che avrà il compito di rilevare il passaggio del treno davanti ai Check Point comunicandone tale passaggio alla Control Unit. Sarà quest'ultima, sulla base delle impostazioni impartite per lo specifico tracciato, ad inviare i comandi verso gli altri dispositivi che agiranno sui passaggi a livello, sugli scambi e sul motore del treno. Come primo attuatore, invece, partiremo dal controller del motore PF (hardware+software) e, parallelamente da quello per l'HUB Powered Up (software). Da quanto ho potuto vedere documentandomi sulla Rete, non sarà troppo difficile integrarsi anche con i dispositivi SBrick, BuWizz e PFx Brick. Avendo sotto mano un SBrick (grazie @ZioTitanok ) proverò inizialmente ad interfacciarmi con questo primo componente di terze parti, ma solo dopo aver sviluppato un prototipo del nostro attuatore (ad un costo nettamente inferiore rispetto ai vari "intelligent brick" già disponibili sul mercato). Sensori ed attuatori, da soli, non servono sostanzialmente a nulla se in mezzo a loro non c'è un 'cervello' ovvero il centro di controllo, quello che finora ho nominato com 'Control Unit', nell'ecosistema ITS - ItLUG Train System. La parte software che rappresenterà la C.U. potrà essere realizzata con qualsiasi linguaggio/piattaforma che sia in grado di interfacciarsi con un broker MQTT (praticamente tutti). Per semplicità e flessibilità, noi useremo Node Red (basato su Node.js, ovvero JavaScript), un ambiente di sviluppo visuale che ci permetterà di creare dei 'flussi' di messaggi, disegnando (nel vero senso della parola) la logica di controllo per i nostri circuiti ferroviari e potendola adattare 'all'istante', senza troppe complicazioni e con una rappresentazione chiara. Per farvi comprendere meglio, vi farò un esempio pratico, usando come base un circuito molto semplice: Su questo circuito sono posizionati 4 check point che identificano l'approssimarsi a dei punti 'nevralgici' del circuito. 1) La stazione/punto di partenza/punto di stop 2) e 3) Passaggi a livello 4) Scambio Il sensore che identifica questi check point è posizionato a bordo del treno (immaginiamolo all'inizio del convoglio). Il treno parte sempre da un punto prestabilito (la stazione) ed inizia a passare tra i vari check point... ad ogni passaggio, invia un messaggio MQTT che non fa altro che comunicare 'Sono transitato su un check point'.... Nient'altro! A bordo del treno, ovviamente, ci sarà anche un dispositivo 'attuatore' ovvero quello che, nella pratica, agirà sul motore. Cosa ci facciamo con i messaggi trasmessi dal treno ad ogni passaggio per un check point? Ecco che vi presento l'interfaccia della Control Unit, basata su Node Red: Quello rappresentato nell'immagine è un Workflow di messaggi. Ho separato il workflow in 3 aree: le prime due in alto, sono semplicissime: inviano un messaggio al treno, rispettivamente per avviare il motore e per fermarlo. L'invio del messaggio è determinato dal click sull'interfaccia grafica (il quadratino azzurrino, sul lato sx del primo box, per essere chiaro) ma può tranquillamente essere scatenato da un trigger esterno (un pulsante sullo smartphone, il caso più semplice). Il resto, rappresenta la logica vera e propria: Il primo box ('Sensore treno A') riceve il messaggio e lo passa a 'Conta Check Point', una funziona che non fa altro che contare in modo sequenziale il passaggio dei check point, resettando il contatore ogni volta che arriva al valore 4. Il 'Conta Check Point' passa il messaggio (contenente il numero del check point sul quale il treno è in transito) al blocco 'Smista Check Point': questo non fa altro che, in funzione del valore, smistare il flusso verso ulteriori blocchi... ognuno di questi ha un propria sotto-logica che, fondamentalmente, determina l'azione da intraprendere: azionare l'attuatore del passaggio a livello, anzichè dello scambio... oppure intervenire sull'attuatore che controlla il treno, fermando la corsa e facendola riprendere dopo 10 secondi... Nei prossimi giorni, entreremo nel dettaglio dei singoli componenti... (Nota: Tutto l'ambiente software relativo al Raspberry verrà messo a disposizione come 'file immagine' da replicare sulla vostra microSD, in modo da avere tutto già pronto, senza dover conoscenere i minimi dettagli della configurazione, benché gli stessi saranno comunque messi tutti a disposizione).