Jump to content
IGNORED

[ATS] Presentazione progetto


Recommended Posts

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:
CircuitoTreno.png

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:

Workflow.png

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

Link to post
Share on other sites
  • Replies 100
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

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

Oggi non ho tempo per fare un punto della situazione... ma ci tengo a mostrarvi, molto velocemente, il controller WiFi per i motori PF realizzato in casa in questi giorni 😉 VID_2019021

Il progetto sta andando avanti, e nel weekend vi fornirò le prime istruzioni per mettere in piedi il sistema di controllo. Al momento, ho configurato la 'Control Unit' per interfacciarsi ai nuovi hu

Posted Images

La scelta di MQTT ha diversi vantaggi: è uno standard diffusissimo, al punto che è usato anche in Google Home ed Amazon Alexa, sì, prima o poi potrete urlare "Alexa ferma il trenooooh!" prima di un devastante incidente di mattoncini; permette la diffusione di un "messaggio" a tutti i sistemi collegati anche con garanzia di consegna (comodissimo per sensori, semafori, scambi). In pratica è per dare comandi tipo: "avvisa tutti che il binario 2 della stazione è occupato", e i diretti interessati si regoleranno di conseguenza.

La scelta dell'ESP8266 riguarda dimensioni e costi, entrambi molto contenuti (è davvero arduo pensare ad un'alternativa diffusa ed economica). Per chi non la conoscesse, la definiremmo "una specie di Arduino col Wifi".

 

Link to post
Share on other sites

Immaginavo, @alf, che te avresti colto subito i vantaggi di questa implementazione.
Uso MQTT e gli ESP8266 per altri progetti, anche se da relativamente poco tempo, e subito ho pensato che fossero idonei per semplificare al massimo il discorso dell'automazione, in unione a Node Red.

Questo, è un altro esempio di Workflow, "disegnato" velocemente...

Descrive la logica di due treni che viaggiano, contemporaneamente e nella stessa direzione, sullo stesso tracciato.
In una situazione reale, prima o poi, i due treni si avvicineranno tra di loro, per via della differenza di resa dei motori, del peso del treno, dell'efficienza delle batterie.

Partono, all'85% della loro velocità massima, a distanza di 5 secondi uno d'altro.
(il secondo treno, immaginiamolo inizialmente posizionato su un binario secondario che si innesta al circuito principale)

Lungo tutto il tracciato, a distanza di circa 50cm l'uno d'altro, sono posizionati i checkpoint (cosa sono i checkpoint, nella pratica, lo vedremo in un prossimo post).

Ogni treno conteggia i checkpoint a partire dal punto di partenza.
Il primo treno (A), gira per conto suo, senza interessarsi di altro...
Per il secondo treno (B) la logica calcola la differenza tra il conteggio dei checkpoint, facendo in modo che sia possibilmente vicino a 3 (1,5 metri di distanza). Se questa differenza diminuisce, il treno B viene rallentato... se la differenza aumenta, il treno B viene spinto più velocemente... nella pratica, i due treni viaggeranno 'all'infinito' sul circuito senza mai 'toccarsi', mantenendo tra loro una distanza ben precisa...

Insomma, anche se sono giusto delle bozze di workflow, spero sia chiaro quanto sia potente e flessibile questo sistema...

blob.png

Link to post
Share on other sites

Ciao a tutti!

Come già detto sui social, mi aggiungo alla lista degli interessati e di quelli disposti a fare test.

Consideratemi della truppa anche se non sono un programmatore e finora mi sono dilettato soltanto con gli RCX, peraltro con discreti risultati grazie all'aiuto del mitico @Rudy

Credo sia giunto però il momento di voltare pagina, verso qualcosa che, anche se non LEGO, permetta di gestire varie funzioni in maniera affidabile ed economica.

Paolo.

 

 

 

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

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

Dilla tutta! Ringraziami per averti fatto scoprire Home Assistant: hai fatto il giro lungo ma alla fine sei tornato al LEGO. 😀
Seguo con interesse il progetto, pur non essendo un trenista, perché convinto che possa essere sfruttato per tante altre applicazioni LEGO.

Link to post
Share on other sites
3 ore fa, sky7176 ha scritto:

Per lavoro già utilizzo MQTT.

In che ambito lo utilizzi, @sky7176?

Una delle cose sulle quali dobbiamo ragionare, relativamente alla sezione MQTT è la composizione dei topic.

Ad esempio, c'è bisogno di un topic per il discovery dei dispositivi (utili a verificare che tutti siano 'connessi' al broker) e poi c'è bisogno dei topic relativi a sensori ed attuatori.

Ad esempio:

ITS/Discovery/(device) search

dove 'device' può essere: Sensori/Treni/PL/Scambi, al quale i singoli dispositivi interpellati rispondono con topic contenente un payload Json contenente nome/IP/Tipo:

ITS/Info/(device) payload_json

Un meccanismo del genere, permetterebbe di cercare ed identificare tutti i dispositivi connessi al broker e per avere delle informazioni minimali per la configurazione del workfkow.

Cosa ne pensi? Ti viene in mente qualche altra idea?

Link to post
Share on other sites
35 minuti fa, sky7176 ha scritto:

L'unica cosa è che esp32 consuma un botto.

Noi useremo l'ESP8266 che ha questa tabella dei "consumi":

20150112172151.jpg

L'ESP32, in effetti, consuma di più (fino a 240 mA).

Sicuramente, per gli eventi, in cui i treni girano di continuo, saranno necessarie le batterie ricaricabili oppure, come è mia intenzione fare, realizzare un "pick up" dai binari 9v.

Link to post
Share on other sites
5 ore fa, sky7176 ha scritto:

In un progetto che ho realizzato, un esp8266 che inviava una lettura di temp e umidità ogni 30 sec alimentato con power pack da 2000 mA funzionava x circa 2 giorni prima che il power pack si scaricasse.

Comunque la cosa mi stuzzica.

Andando in deep sleep?

 

8 ore fa, GianCann ha scritto:

In che ambito lo utilizzi, @sky7176?

Una delle cose sulle quali dobbiamo ragionare, relativamente alla sezione MQTT è la composizione dei topic.

Ad esempio, c'è bisogno di un topic per il discovery dei dispositivi (utili a verificare che tutti siano 'connessi' al broker) e poi c'è bisogno dei topic relativi a sensori ed attuatori.

Ad esempio:

ITS/Discovery/(device) search

dove 'device' può essere: Sensori/Treni/PL/Scambi, al quale i singoli dispositivi interpellati rispondono con topic contenente un payload Json contenente nome/IP/Tipo:

ITS/Info/(device) payload_json

Un meccanismo del genere, permetterebbe di cercare ed identificare tutti i dispositivi connessi al broker e per avere delle informazioni minimali per la configurazione del workfkow.

Cosa ne pensi? Ti viene in mente qualche altra idea?

La logica di stato di ogni device dovrebbe essere gestita da ogni client alla connessione e disconnessione. Che io sappia mosquitto (se usi quello, mqtt come protocollo non lo prevede) non lo implementa automaticamente. Sicuramente avere una rappresentazione json dello stato di ogni device quando interrogato (alias: richiesto esplicitamente  e solo per debug) potrebbe essere utile in diagnostica. Ma a quel punto sarebbe importante avere uno schema json il quanto più possibile uniforme tra i Device

 

Per la verità il broker ha una tabella di keepalive dove lo stato dei clienti viene mantenuto e in caso di disconnessione viene Attivato un meccanismo chiamato last will and testament (lwt) Che potresti usare per determinare i client Che 'spariscono'.

Personalmente preferirei avere una lista esplicita più che implicita, per cui meglio sempre fare in modo che il cliente pubblichi il suo stato nel subtopic apposta.

Link to post
Share on other sites
5 ore fa, fonderiadigitale ha scritto:

Ma a quel punto sarebbe importante avere uno schema json il quanto più possibile uniforme tra i Device

Assolutamente d'accordo anche se, oltre a nome, tipologia, versione del FW e indirizzo IP non mi vengono in mente altri dati da comunicare. Visto il tipo di applicazione, l'indirizzamento della rete e le impostazioni del broker MQTT saranno 'mandatory', almeno in una prima release dell'intero sistema.

Ti viene in mente altro?

5 ore fa, fonderiadigitale ha scritto:

Personalmente preferirei avere una lista esplicita più che implicita, per cui meglio sempre fare in modo che il cliente pubblichi il suo stato nel subtopic apposta

Il messaggio di welcome con il Last Will & Testament lo implementeremo sicuramente, ma un comando esplicito che ci può enumerare i dispositivi connessi (per tipologia, o tutti quelli "in ascolto") ci sarà sicuramente utile.

Link to post
Share on other sites

I miei 2 cents per gli eventuali perplessi...

La "gerarchia" dei topic MQTT non sarà tanto complicata, visto che ci sono poche categorie automatizzabili (interruttori, luci, motori, sensori). Stiamo parlando di diorami, mica della NASA...

Non fatevi spaventare dal termine "domotica": basarsi su MQTT (per esempio il mosquitto per Linux) facilita parecchie cose altrimenti complicate da realizzare (come l'invio garantito di un messaggio di status). Un singolo server MQTT (per esempio basato su una Raspberry, magari quella piccoletta) può servire tutti gli apparati che via wifi o cavetto di rete riescono a raggiungerlo, anche se di diorami ferroviari diversi.

Certo, il wifi consuma più del BLE (Bluetooth Low Energy, usato ad esempio dagli sBrick) ma anche in questo caso i vantaggi (avere parecchi sistemi contemporaneamente in rete, la notevole velocità di trasmissione dei pacchetti via wifi, il non dover costruire tutta l'infrastruttura di scambio messaggi, costi decisamente abbordabili rispetto ad alcuni anni fa, ecc., e soprattutto il fatto che si può realizzare in modo non invasivo sui diorami già esistenti) superano gli svantaggi. La tabella dei consumi sopra indicata si riferisce al caso peggiore e al funzionamento a 3,3 volts.

Il deep sleep andrà magari sperimentato più avanti, quando tutto già funziona, per vedere in quali casi produce realmente un risparmio di energia sulle batterie.

Ma non lamentatevi dei consumi se avete ingegnerizzato maluccio i vostri (esempio: immaginate i consumi di un locomotore "leggero" che traina una vettura "pesante" anziché avere il pacco batterie "in asse" verticale col gruppo motore). Anzi, cominciate a progettare un treno 8-wide col pacco batterie grosso...

Link to post
Share on other sites

In ogni caso ai consumi del modulo si devono aggiungere i consumi dei carichi, che si dovrà decidere a che tensione alimentrarli.

Per mantenere una certa uniformità di tensioni, io rimarrei sui 9v.

Sicuramente avvantaggiati gli utilizzatori dei binari a 12v, possono "spillare" energia dai binari, per i PF altro discorso.

In ogni caso iniziamo a buttare sulla carta degli schemi di massima ed iniziamo a ragionarci su.

Io personalmente ho utilizzato come master sia un pc windows che una raspberry entrambi con Mosquitto, se usiamo red-node il passaggio tra i due ambienti hardware, al netto di uscite GPIO della raspberry, è indolore.

Giuseppe

Link to post
Share on other sites

Intanto vi anticipo qualche foto di una parte del materiale arrivato oggi 😉

IMG_20190129_152104.jpg

IMG_20190129_152125.jpg

IMG_20190129_152135.jpg

IMG_20190129_152245.jpg

IMG_20190129_152333.jpg

Il case l'ho acquistato ieri su Amazon, pagandolo 6,5 euro
E' disponibile nei seguenti colori: rosso, blu, nero, giallo, bianco.

Le dimensioni sono 8x11 stud, altezza 3 brick

Il clutch power è ottimo... solamente sul lato inferiore, lungo il bordo, c'è meno presa (ho provato mettendo un brick 1x4 lungo il bordo).
Per il resto, è perfetto! Il colore rosso è indistinguibile da quello LEGO.

Dentro ci ho messo un Raspberry 3, modello B+

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

La "gerarchia" dei topic MQTT non sarà tanto complicata, visto che ci sono poche categorie automatizzabili (interruttori, luci, motori, sensori). Stiamo parlando di diorami, mica della NASA...

Perfettamente d'accordo! Tra l'altro, proprio per questo motivo, non ci staremo in alcun modo a preoccupare di qualsiasi problematica inerente la sicurezza.

2 ore fa, alf ha scritto:

Il deep sleep andrà magari sperimentato più avanti, quando tutto già funziona, per vedere in quali casi produce realmente un risparmio di energia sulle batterie.

Il problema dei consumi (se di problema effettivamente si tratterà...) lo valuteremo in un secondo momento.
Dubito, del resto, che in questo tipo di applicazione potremo implementare le modalità sleep

1 ora fa, sky7176 ha scritto:

In ogni caso ai consumi del modulo si devono aggiungere i consumi dei carichi, che si dovrà decidere a che tensione alimentrarli.

Per mantenere una certa uniformità di tensioni, io rimarrei sui 9v.

Confermo. L'alimentazione sarà 9V

Confermo che il progetto sarà sviluppato, di base, su questo hardware:
- Raspberry 3 B+
- ESP8266 (ed altri componenti che illustrerò più avanti)

Per il software:
- Mosquitto (MQTT Broker)
- Node-Red
- Firmware specifico per ESP8266, basato sulla libreria PubSubClient, oltre a quelle specifiche per i sensori e per eventuali 'driver'

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

Sicuramente, per gli eventi, in cui i treni girano di continuo, saranno necessarie le batterie ricaricabili oppure, come è mia intenzione fare, realizzare un "pick up" dai binari 9v.

Prendere corrente dai 9v ci piace 🤤

Se hai bisogno di un beta tester eccomi

Grande!!!

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

I miei 2 cents per gli eventuali perplessi...

La "gerarchia" dei topic MQTT non sarà tanto complicata, visto che ci sono poche categorie automatizzabili (interruttori, luci, motori, sensori). Stiamo parlando di diorami, mica della NASA...

Non fatevi spaventare dal termine "domotica": basarsi su MQTT (per esempio il mosquitto per Linux) facilita parecchie cose altrimenti complicate da realizzare (come l'invio garantito di un messaggio di status). Un singolo server MQTT (per esempio basato su una Raspberry, magari quella piccoletta) può servire tutti gli apparati che via wifi o cavetto di rete riescono a raggiungerlo, anche se di diorami ferroviari diversi.

Certo, il wifi consuma più del BLE (Bluetooth Low Energy, usato ad esempio dagli sBrick) ma anche in questo caso i vantaggi (avere parecchi sistemi contemporaneamente in rete, la notevole velocità di trasmissione dei pacchetti via wifi, il non dover costruire tutta l'infrastruttura di scambio messaggi, costi decisamente abbordabili rispetto ad alcuni anni fa, ecc., e soprattutto il fatto che si può realizzare in modo non invasivo sui diorami già esistenti) superano gli svantaggi. La tabella dei consumi sopra indicata si riferisce al caso peggiore e al funzionamento a 3,3 volts.

Il deep sleep andrà magari sperimentato più avanti, quando tutto già funziona, per vedere in quali casi produce realmente un risparmio di energia sulle batterie.

Ma non lamentatevi dei consumi se avete ingegnerizzato maluccio i vostri (esempio: immaginate i consumi di un locomotore "leggero" che traina una vettura "pesante" anziché avere il pacco batterie "in asse" verticale col gruppo motore). Anzi, cominciate a progettare un treno 8-wide col pacco batterie grosso...

su un sistema live su cui passa piu di un treno non possiamo implementare il deep sleep, immagino.

ok tiro fuori una cosa su cui vorrei lavorare da parecchio tempo, e prima o poi lo faro' (tempo permettendo, quindi mai...)

Quello che sarebbe carino fare e' il pickup dai binari che carica un condensatore dal quale viene alimentato il motore e contemporaneamente (tramite un diodo per evitare il ritorno) caricare una batteria. non e' una cosa banale e va pensata bene. vorrei evitare il passthrough (ecco perche il diodo)

serve:

- alzare la corrente sul circuito da 9v a 11v o 12v

- un bridge rectifier per normalizzare la corrente presa dal circuito

- nel caso del condensatore, una batteria di supercaps (2.7 l'uno) in serie

- dato che i supercap non sono come le batterie, man mano che scaricano il voltaggio diventa 0, serve un DC/DC converter per mantenere l'andamento del treno..lineare

- un limitatore di corrente in carica sul cluster di supercaps.

 

niente di trascendentale, il piu e' fare dei test.

comunque non sono il primo ad averci pensato, per esempio questo e' un buon spunto:

 https://brickmodelrailroader.com/index.php/2017/03/20/supercapacitor-power-packs/

 

Link to post
Share on other sites
51 minutes ago, GianCann ha scritto:

Intanto vi anticipo qualche foto di una parte del materiale arrivato oggi 😉

(...)

Il case l'ho acquistato ieri su Amazon, pagandolo 6,5 euro
E' disponibile nei seguenti colori: rosso, blue, bero, giallo, bianco.

Le dimensioni sono 8x11 stud, altezza 3 brick

Il clutch power è ottimo... solamente sul lato inferiore, lungo il bordo, c'è meno presa (ho provato mettendo un brick 1x4 lungo il bordo).
Per il resto, è perfetto! Il colore rosso è indistinguibile da quello LEGO.

Dentro ci ho messo un Raspberry 3, modello B+

metti un dissipatore su quell'IC in mezzo se sta chiuso nel case di plastica:) o tieni sotto controllo la temperatura col crescere del carico. dubito che avrai problemi comunque.

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

Per il software:

- Mosquitto (MQTT Broker)
- Node-Red
- Firmware specifico per ESP8266, basato sulla libreria PubSubClient, oltre a quelle specifiche per i sensori e per eventuali 'driver'

Io propporei di aggiungere anche la libreria WiFiManager, permette di avere un webserver a bordo dell ESP8266 per configurazione iniziale, vedi SSID della rete WiFi, i canali dei topic ed altro.

Link to post
Share on other sites
41 minutes ago, Asterix ha scritto:

Prendere corrente dai 9v ci piace 🤤

Se hai bisogno di un beta tester eccomi

Beh, non c'è molto da fare... basta che guardi questo video e capirai che è sufficiente togliere il motore da dentro un vecchio motore 9v 😉

Aggiunto, per riferimento, anche questo post:
https://www.eurobricks.com/forum/index.php?/forums/topic/114218-tutorial-modifying-a-9v-train-motor/

23 minutes ago, sky7176 ha scritto:

Io propporei di aggiungere anche la libreria WiFiManager, permette di avere un webserver a bordo dell ESP8266 per configurazione iniziale, vedi SSID della rete WiFi, i canali dei topic ed altro.

Si, useremo anche la WiFiManager ovviamente.
Per rendere tutto più semplice, l'SSID, la password, l'IP del broker e le credenziali di accesso saranno comunque 'predefinite', ma l'idea di implementare un piccolo server web per cambiare alcuni parametri per personalizzare il proprio sistema potrà essere utile.

 @sky7176 se sei disponibile a collaborare attivamente, potresti iniziare a buttar giù uno sketch di base con l'implementazione della WiFi Manager per gestire i seguenti paramentri:
- SSID WiFi (valore predefinito: ITS-WiFi)
- Password (valore prefefinito: ITF-WiFi-Password)
- IP MQTT Broker (valore predefinito: 192.168.4.1)
- User MQTT Broker (valore predefinito: ITS-MQTT-User)
- Password MQTT Broker (valore predefinito: ITS-MQTT-Password)
- Nome dispositivo: (Valore predefinito ITS-chip id)

Fammi sapere 😉

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

Beh, non c'è molto da fare... basta che guardi questo video e capirai che è sufficiente togliere il motore da dentro un vecchio motore 9v 😉

Si, useremo anche la WiFiManager ovviamente.
Per rendere tutto più semplice, l'SSID, la password, l'IP del broker e le credenziali di accesso saranno comunque 'predefinite', ma l'idea di implementare un piccolo server web per cambiare alcuni parametri per personalizzare il proprio sistema potrà essere utile.

 @sky7176 se sei disponibile a collaborare attivamente, potresti iniziare a buttar giù uno sketch di base con l'implementazione della WiFi Manager per gestire i seguenti paramentri:
- SSID WiFi (valore predefinito: ITS-WiFi)
- Password (valore prefefinito: ITF-WiFi-Password)
- IP MQTT Broker (valore predefinito: 192.168.4.1)
- User MQTT Broker (valore predefinito: ITS-MQTT-User)
- Password MQTT Broker (valore predefinito: ITS-MQTT-Password)
- Nome dispositivo: (Valore predefinito ITS-chip id)

Fammi sapere 😉

Mi organizzo per lo sketch.

Indirizzo di default dei client 192.168.1.1

Giuseppe

Edited by sky7176
Link to post
Share on other sites

Nel frattempo che arrivino gli ESP-03, ieri ho preso su Amazon un paio di queste board di sviluppo basate sempre su ESP8266.
WhatsApp Image 2019-01-29 at 16.59.19 (1).jpeg

WhatsApp Image 2019-01-29 at 16.59.19.jpeg

Sostanzialmente è tipo una Wemos, con una breakout board che implementa il driver per 2 motori (anche se a noi ne servirà solo per uno).
Il prodotto è questo, acquistato su Amazon per 13,99 euro l'uno.
La comodità è che si può alimentare direttamente a 9V 😉

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

Nel frattempo che arrivino gli ESP-03, ieri ho preso su Amazon un paio di queste board di sviluppo basate sempre su ESP8266.
WhatsApp Image 2019-01-29 at 16.59.19 (1).jpeg

WhatsApp Image 2019-01-29 at 16.59.19.jpeg

Sostanzialmente è tipo una Wemos, con una breakout board che implementa il driver per 2 motori (anche se a noi ne servirà solo per uno).
Il prodotto è questo, acquistato su Amazon per 13,99 euro l'uno.
La comodità è che si può alimentare direttamente a 9V 😉

Se la cosa va in porto potremmo pensare di fare un ordine cululativo su aliexpress

Link to post
Share on other sites

Per il momento metto questi link qui, perchè ci torneranno utili più avanti:

SBrick-Framework: This is a python based interface for control SBrick devices.
https://github.com/BensonHsu/SBrick-Framework

SBrick Controller: Control your LEGO SBrick creations from the browser, using your keyboard!
https://github.com/zkiiito/node-sbrick-controller
https://community.risingstack.com/node-js-iot-project-home-explorer-rover-with-LEGO-sbrick-raspberry-pi/

A Node.js module to interface with LEGO Powered UP components.
https://github.com/nathankellenicki/node-poweredup

Link to post
Share on other sites
1 ora fa, GianCann ha scritto:

Sostanzialmente è tipo una Wemos, con una breakout board che implementa il driver per 2 motori (anche se a noi ne servirà solo per uno).

L'ho testata giusto per verificare che funzionasse. Semplice sketch: 2 secondi motore accesso a tutta velocità, 2 secondi spento... all'infinito

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

 

Le dimensioni sono 8x11 stud, altezza 3 brick

Il clutch power è ottimo... solamente sul lato inferiore, lungo il bordo, c'è meno presa (ho provato mettendo un brick 1x4 lungo il bordo).
Per il resto, è perfetto! Il colore rosso è indistinguibile da quello LEGO.

 

Seguo anch'io con interesse, anche se mi sento un pò a disagio essendo un integralista in fatto di LEGO.

E per quanto mi piaccia, per informazione, vedere ciò che fa la concorrenza (cloni legali e non) ho sempre gestito i miei sistemi LEGO solo con elementi LEGO in tutto e per tutto.

Il progetto mi affascina e stimola, al tempo stesso mi viene da recriminare sulle occasioni perse da LEGO in questo campo.

Devo dire che LEGO per molti sta diventando una piattaforma open source (intesa come sistema di gioco) su cui poi ognuno integra le proprie conoscenze e i propri materiali. Ho visto ottime realizzazioni con integrazione di motori, sensori e schede non LEGO. Molto interessanti alcuni esperimenti per l'utilizzo di motori elettrici più potenti.

Ci avviciniamo sempre di più al mondo del modellismo, con la ricerca di ciò che non è disponibile, attraverso l'uso di altre marche.

Detto ciò l'entusiasmo di @GianCann per il clutch power e il colore di oggetto con gli stud che non porta il marchio LEGO mi provoca reazioni allergiche alla @Laz davanti ai Leaks. (non dovevi marcarlo ITLUG, se non sta bene su sondaggi sul LEGO, figuriamoci su pezzi NON LEGO).

Quello che non ho capito nella spiegazione di Gianluca è come sensori e attuatori verranno alimentati.

Sarà tutto cablato? O l'alimentazione verrà portata attraverso i binari?

 

 

 

 

Link to post
Share on other sites
12 minutes ago, AirMauro ha scritto:

E per quanto mi piaccia, per informazione, vedere ciò che fa la concorrenza (cloni legali e non) ho sempre gestito i miei sistemi LEGO solo con elementi LEGO in tutto e per tutto.

Purtroppo, invece di andare avanti, LEGO è andata indietro sul campo dei treni. Basta vedere la foto di @Arrow di qualche post fa per capire cosa intendo 😉

13 minutes ago, AirMauro ha scritto:

Detto ciò l'entusiasmo di @GianCann per il clutch power e il colore di oggetto con gli stud che non porta il marchio LEGO mi provoca reazioni allergiche alla @Laz davanti ai Leaks. (non dovevi marcarlo ITLUG, se non sta bene su sondaggi sul LEGO, figuriamoci su pezzi NON LEGO).

😄 😄 😄 Ma secondo te, conoscendomi, pensi che quel tile sia stato messo lì a caso???? 😄 😄 😄

14 minutes ago, AirMauro ha scritto:

Quello che non ho capito nella spiegazione di Gianluca è come sensori e attuatori verranno alimentati.

La mia idea, avendo circa 700 binari 9V è quella di usarli come 'infrastruttura' per distribuire l'alimentazione, prelevandola da binari com il 5306c01 (hai capito ora perchè l'altro giorno, in chat, mi sono sorpreso del prezzo che ha raggiunto?).

Altrimenti, alimentazione a pile (LiPo, ricaricabili), tipo queste:
https://www.amazon.it/Crazepony-UK-Batteria-Batterie-Quadcopter-Multirotors/dp/B078H7WHWJ

Link to post
Share on other sites
il 29/1/2019 alle 19:15, GianCann ha scritto:

La mia idea, avendo circa 700 binari 9V è quella di usarli come 'infrastruttura' per distribuire l'alimentazione, prelevandola da binari com il 5306c01 (hai capito ora perchè l'altro giorno, in chat, mi sono sorpreso del prezzo che ha raggiunto?).

Questa secondo me è una pecca, o meglio, non punterei a "prelevare" la corrente dai binari 9V.
Per il semplice motivo che: in quanti abbiamo 9V per fare la TAV qui in ItLUG? in 10 AFOL? se va bene. Il problema che i binari a 9V sono nel mondo in un numero "finito". L'ultimo magazzino di LEGO svuotato penso sia stato nel 2009 quando li si trovavano "sciolti" all'interno del PSHOP. Ora come ora, la maggio parte degli AFOL e dei nuovi e futuri (prossimi ad uscire dalla dark age) saranno sommersi dei nuovi binari in "plastica".

Edited by Pix
Link to post
Share on other sites

La soluzione definitiva al problema di alimentazione dei treni è il pickup per binari 9V che ricarica una batteria che alimenta il treno.
Sembra Branduardi, lo so, ma è l'unico modo per avere dei tracciati lunghi a piacere usando binari PF e usando solo qua e la tracciati 9V per ricaricare, con o senza condensatori.

Qui avevo provato a riassumere diverse soluzioni per il pickup da 9V, alcune pulite, altre meno.

https://www.eurobricks.com/forum/index.php?/forums/topic/136753-power-pick-up-wheelset/&do=findComment&comment=3044948

Un certo @Arrow ha promesso di vendermi un motore e dei binari per fare dei test, ma vai a fidarti tu..... 😛

Quello che dice @Pix è vero per il futuro. Quello che vedo di solito nei diorami per ora (la mia esperienza è Lecco / Paredes / Skaerbaek / qualcosa in Toscana) è che  ci sono ancora binari a sufficienza ( @Arrow  @BOLTO@ ehmm... 🙂 ) per allestire un diorama quindi a breve la situazione sarà gestibile.

Alla lunga e per andare incontro all'AFOL che ha solo binari PF certo servirà una versione "2" o "3" di sensori e attuatori a bordo tracciato che dovrebbe avere incluso un circuito come il TP4056 disponibile in questo modulo per la gestione di una LiPo a 1 cella. Se alimentato bene, se no prende da batteria se esistente. Tutta l'elettronica in campo potrebbe essere pensata per funzionare a 3.3 come livelli e con una versione di caricabatterie migliore del TP4056 che è limitato a 8V in ingresso. 

Ultimo punto @GianCann: eresia per eresia, visto che ormai si andrà tutti all'inferno come suggerito da @AirMauro, fare dei pickup per i binari (5306c01) home made ?

Link to post
Share on other sites

Aggiornamento "lampo" sul progetto.

Ho configurato da zero un nuovo Raspberry 3 B+ configurandolo come Access Point.
Ho aggiunto/aggiornato tutto il necessario (software/librerie/ecc.) utili allo scopo del progetto (VNC, Node Red, Mosquitto, ecc.).

Ho scaricato e configurato tutto ciò che serve ad interagire con il nuovo HUB Powered Up LEGO.

Allo stato attuale, appena il Raspberry viene accesso esegue in background un nodo JS che tramite Bluetooth è continuamente in attesa di agganciare uno o più smart HUB.

È quindi sufficiente accendere lo smart HUB e dopo neanche un paio di secondi viene connesso al Raspberry pronto per essere "controllato" tramite gli opportuni comandi esposti dalla libreria https://github.com/MihaZelnik/PoweredUp-REST-API .

Ho poi creato un Workflow di test, implementando l'invio dei comandinda interfaccia Web e via MQTT.

Beh, che dire... funziona tutto alla perfezione 😉

In un paio di giorni conto di mettere a disposizione l'immagine della micro SD con tutto il sistema già pre-configurato, documentandovi i vari passaggi/configurazioni effettuate.

Vi anticipo una schermata del workflow di test preparato su Node Red e i comandi di controllo che ho velocemente "disegnato" su uno dei tanti client MQTT per Android.

IMG_20190131_124926.jpg

IMG_20190131_124847.jpg

Pertanto, al momento, il nuovo sistema Powered Up è integrato in ITS -ItLUG Train System. Appena ho modo di avere altri 2-3 Hub tra le mani, predispongo il Worlflow per l'identificazione univoca dei vari HUB.

Link to post
Share on other sites
14 ore fa, pivan ha scritto:

Ultimo punto @GianCann: eresia per eresia, visto che ormai si andrà tutti all'inferno come suggerito da @AirMauro, fare dei pickup per i binari (5306c01) home made ?

Sicuramente, visto il costo e la difficoltà di reperire i 5306c01 😉

Puoi iniziare a ragionarci e fare qualche prototipo.

Per rispondere meglio a @Pix: la mia idea di progetto (che forse non sono ancora riuscito a illustrarla con chiarezza) è quella di avere un sistema che sia utilizzabile sia con i 9v, sia con i PF, sia con i nuovi Powered UP.

Chi potrà disporre di binari 9v, sarà avvantaggiato dal fatto che potrà alimentare i vari dispositivi predisposti lungo il tracciato (passaggi a livelli/scambi) senza la necessità di cablare alcunché. Allo stesso tempo, potrà alimentare motori e sensori a bordo treno, con ricarica delle eventuali batterie (a seconda del tipo di motore utilizzato).

Chi avrà solo i binari RC, dovrà obbligatoriamente prevedere punti di alimentazione (con alimentatore o pacco batteria) nei nodi interessati da scambi o passaggi a livello. Parallelamente, a bordo treno, dovrà fare affidamento esclusivamente alle batterie, come già attualmente è obbligatorio fare...

Tuttavia, l'idea di @pivan di avere solo una piccola porzione di binari 9V allo scopo di creare un 'punto di ricarica' volante mi sembra molto interessante.

Link to post
Share on other sites
1 ora fa, GianCann ha scritto:

Sicuramente, visto il costo e la difficoltà di reperire i 5306c01 😉

Quindi i 5 Service Pack che ho me li devo tenere stretti? 🤔 ho visto ora il prezzo 🙈

Sono curioso di sapere quanto assorbono i vari moduli, per capire la dimensione, capacità e amperaggio delle batterie.

Link to post
Share on other sites

una delle idee malate che mi era venuta era di usare uno di questi cosi, avvitandoli dentro a un brick technic con il buco per lo stud.

in pratica hanno una sfera con la molla che puoi premere contro la parete laterale del binario.

appena arrivano ti dico.

l'idea e' simile a questa. chiaramente la vita senza testa, e il brick e' a livello del binario (1 plate sotto) per evitare di sbattere col carrello del treno

Screenshot 2019-01-31 at 13.54.58.png

Link to post
Share on other sites

Il progetto sta andando avanti, e nel weekend vi fornirò le prime istruzioni per mettere in piedi il sistema di controllo.
Al momento, ho configurato la 'Control Unit' per interfacciarsi ai nuovi hubs/motori PoweredUp (fino ad un massimo di 5 contemporaneamente, ovvero il massimo dei dispositivi BLE che la libreria bluetooth-hci-socket è in grado di gestire sul Raspberry).

Vi anticipo un paio di screenshot dal mio smartphone, con l'interfaccia di controllo per 4 treni che permette di controllare, da un'unica schermata, di impostare le singole velocità, le direzioni di ogni treno e di avviarli/fermarli tutti insieme.
Da un'altra schermata, invece, è possibile monitorare lo stato delle batterie oltre che spengere completamente i singoli hubs connessi, anzichè tutti contemporaneamente.
In questo modo è già possibile 'superare' i limiti dell'App LEGO originale, che permette il controllo di un solo treno.

ControlloTreni1.png

 

ControlloTreni2.png

Link to post
Share on other sites

Per semplificare al massimo l'implementazione di ITS - ItLUG Train System, sto preparando una "distribuzione" di Raspbian (il sistema operativo derivato da Linux Debian, specifico per Raspberry) con tutto già configurato e pronto all'uso.

In questo modo, chi volesse utilizzare ITS, non dovrà preoccuparsi di tutta la fase di installazione e configurazione del sistema operativo, di dover installare/rimuovere pacchetti necessari/non necessari e di doverli opportunamente configurare.

IN OGNI CASO, per chi volesse capire "how it works", sto preparando delle guide separate in 3 fasi: 1) Sistema operativo; 2) Configurazione software di sistema ITS; 3) installazione e configurazione librerie Powered UP e IR LEGO.

Pertanto si potrà scegliere se partire da zero, senza saper nulla di cosa "c'è sotto", focalizzando la proporia attenzione esclusivamente sull'utilizzo con i treni, oppure aggiungere il necessario al proprio sistema Raspberry, Linux o Windows (il sistema è, in teoria, cross-platform).

Ieri ho fatto una prima release della distribuzione Raspbian-ITS, di cui mostro qualche schermata durante la fase di setup e a desktop "ready to go".

Ricordatevi che, a parte la fase di installazione, successivamente non sarà necessario utilizzare monitor/tastiera/mouse per l'utilizzo di ITS, ma sarà sufficiente uno smartphone.

A questo punto cerchiamo alcuni beta-tester per testare il setup della "distro" i cui requisiti (al momento) sono:

- Possedere un Raspberry 3 B+;

- Possere una microSD (vuota) da 8 Gb in su;

- Possedere almeno un motore ed un hub "Powered Up".

Se qualcuno possiede questi requisiti, può contattarmi tramite il sistema di messaggistica privata del forum.

Nota: le guide 'Fai da te' arriveranno a breve.

IMG_20190202_195441.jpg

IMG_20190202_195509.jpg

IMG_20190202_201040.jpg

Link to post
Share on other sites

ATTENZIONE: Dopo una serie di valutazioni, ho deciso di cambiare nome al progetto che, da oggi, sarà identificato come ATS -AFOL Train System (for LEGO trains).

Il riferimento diretto a ItLUG viene rimosso per non urtare la sensibilità dei soci "puristi" ( @AirMauro docet) e per evitare qualsiasi equivoco con la filosofia di fondazione di ItLUG considerato che, per forza di cose, il sistema è basato su una parte di componenti elettronici di terze parti e non è escluso, più avanti nel tempo, che vengano persino prodotti "involucri plastici" compatibili con il sistema ad incastro LEGO.

Il cambio del nome farà slittare di un paio di giorni il rilascio delle guide di configurazione e la disponibilità del download della distribuzione Raspbian-ATS, per via della sostituzione dei riferimenti a ItLUG/ITS che ho utilizzato finora (incluso l'utilizzo del logo nelle schermate di setup/sfondo del desktop, del sistema operativo).

 

Link to post
Share on other sites
il 30/1/2019 alle 23:06, pivan ha scritto:

 

Ultimo punto @GianCann: eresia per eresia, visto che ormai si andrà tutti all'inferno come suggerito da @AirMauro, fare dei pickup per i binari (5306c01) home made ?

Domanda: ma quelli che facevano i mattoncini compatibili in grado di portare corrente da negare nei diorami... li avete considerati?

Edited by AirMauro
Link to post
Share on other sites
  • 2 weeks later...

Dato che il progetto si basa su componenti Wireless (che possono essere a bordo del treno o dislocati lungo il tragitto) sappiamo che il problema di fondo è, fondamentalmente... come alimentarli?

Per provare sul campo l'opzione "alimentazione a batteria" ho acquistato un kit di 5 batterie LiPo 3,7v 750mAh per droni, con relativo carica batteria. Nello specifico, questo è il prodotto che ho acquistato: https://www.amazon.it/gp/product/B014QVT608

61aScb361dL._SX679_.jpg

Ho poi creato un semplice sistema di test simulando il funzionamento di un sensore "tipo", ovvero inviando un messaggio MQTT tramite WiFi con una frequenza di un messaggio ogni secondo. Nella pratica, sui nostri diorami ferroviari, la frequenza di invio dei messaggi è sicuramente inferiore, ovvero un messaggio ogni 3-5 secondi, in alcuni casi anche 7-10 (dipende ovviamente dalle dimensioni del tracciato e da quanti checkpoint vogliamo monitorare).

IMG_20190212_063427.jpg

La batteria utilizzata ha dimensioni abbastanza contenute (25 x 41 x 9 mm) e in questa foto potete vedere il paragone con una moneta da 5 centesimi.

IMG_20190212_080546.jpg

Ho interrotto il test dopo 12 ore di funzionamento ininterrotto (l'ho poi ripreso, e la batteria è durata altri 35 minuti). 12 ore, con una sola batteria, sono più che sufficienti per un qualsiasi scenario relativo ad un diorama comunitario.

IMG_20190212_064435.jpg

Anzi, considerato il costo di queste batterie, e il tempo di ricarica (molto veloce) ho acquistato un secondo kit di batterie, questa volta da 150mAh (che quindi avranno una durata presunta di circa 2,5 ore) ma con dimensioni nettamente inferiori: 26 x 18 x 6 mm. Probabilmente si riesce a "chiuderle" in un box LEGO delle dimensioni 6x4x2 stud/brick.

Il sensore potrà comunque essere alimentato anche direttamente dal pacco batteria PF o dallo smart HUB Powered Up. In quest'ultimo caso, sarà necessario procedere all'acquisto di un set di luci "Powered Up" (9,99 euro sullo S@H) perché è attualmente l'unico sistema per ottenere il nuovo connettore specifico per questo sistema.

Oggi mi consegneranno le batterie da 150mAh e farò nuovamente il test, magari con una frequenza di trasmissione più vicina ad un caso reale (1 messaggio ogni 3 secondi). 

Parallelamente ho testato anche un micro-servo lineare in cui mi ero imbattuto durante le varie ricerche di componenti. Sulla carta sembrava il componente ideale per gestire io movimento degli scambi ferroviari LEGO ma, alla prova pratica, si è rivelato inadeguato. Peccato, perché le sue ridotte dimensioni erano ideali per realizzare una micromotorizzazione.

Volendo restare in ambito LEGO, c'è sempre la possibilità di reperire i mitici micro-motor 9v 2x2, benché il loro prezzo, inclusi i 2 plate speciali si aggirare sui 25 euro l'uno 😞 In alternativa, restano i motori 9v "vecchio tipo" (quelli 4x4x3) e i più ingombranti PF 9v M-Motor. Oppure, si torna a parlare di componenti esterni, quindi i classici servo da modellismo, come quelli che usa 4D Brix nei suoi componenti di automazione.

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