Classifica

JK Brickworks: Fisherman

Buongiorno a tutti, prima di iniziare la lunga galoppata dell'accoppiata carro / sovrastruttura ho completato i pochi elementi accessori che ne fanno parte. In particolare ecco come si presenta la cabina di comando della gru, che sarà collegata nella sezione laterale sinistra della sovrastruttura: I due motori che ne comandano i movimenti sono alloggiati, per ragioni di peso, all'interno della sovrastruttura, mentre un rotismo al suo interno fa in modo di replicare la rotazione della tavola rotante principale sullo snodo dietro la cabina, visto che sarebbe stato poco utile mantenere i due movimenti indipendenti. In fondo la cabina passa direttamente dalla posizione ripiegata dietro la sovrastruttura a quella di utilizzo a fianco ad essa, senza soluzione di continuità e non mi sembra che nelle operazioni di varo siano previste tappe intermedie. Questo, tra l'altro, fa risparmiare un motore e lenisce l'affollamento (sempre di motori) nella sovrastruttura. Qui di seguito, invece, due foto di gruppo dei nove assali divisi per categoria: 3 solo sterzanti (assi 1, 2 e 3), 2 fissi (assi 6 e 7) e 4 motori e sterzanti (assi 4, 5, 8 e 9). La peculiarità di questi ultimi è di avere i motori a valle del differenziale per evitare che tutta la coppia generata debba passare attraverso quel componente. Nonostante questa scelta la gru avrà comunque un albero motore per tutta la sua lunghezza, che muoverà anche un "motore" 8 cilindri posizionato all'altezza dell'asse 2. Detto questo, iniziamo a fare sul serio. Ecco come si presenta, al momento, la struttura del carro: Il modo di procedere è contointuitivo, ma funzionale, visto che le batterie ed i sistemi di comando elettrico sono in testa alla gru, appena dietro la cabina, mentre nella costruzione ho preferito iniziare dalla zona della tavola rotante. Anche se questo complica la gestione dell'impianto elettrico e necessita di dovere in qualche modo "immaginare" dove posizionare le innumerevoli prolunghe (ci sono 8 cavi solo nel passaggio tra carro e sovrastruttura) e quale tipologia usare (lunga o corta), l'assemblaggio viene velocizzato perché la sezione compresa tra gli assi 4 e 9 è perfettamente speculare rispetto alla stessa tavola rotante (esclusi di due terminali, ovviamente), quindi si può montare con la metà dei passaggi. Prima di chiudere due piccole note di colore. Gli assali sono senza ruote perché, tradizionalmente, nei set ufficiali si montano nell'ultimo step e non ho voluto fare un'eccezione. I quattro motori visibili in coda al carro in quella strana posizione serviranno a comandare gli stabilizzatori posteriori. Li ho dovuti piazzare in anticipo (ovviamente fuori posto) perché dopo sarebbe stato impossibile raggiungere le rispettive prolunghe al di sotto della tavola rotante. Il prossimo aggiornamento è fissato, salvo complicazioni, al completamento della sezione simmetrica, con relativa installazione dei quattro stabilizzatori, le cui sedi si cominciano ad intuire ai quattro angoli della tavola rotante. A presto, Fabio

Ecco i primi set dal sequel di The LEGO Movie! Per la prima volta una Minidoll e una Minifigure insieme nello stesso set e dei Duplo fatti di brick system!

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: Questo è un esempio di "codice", preso dallo stesso articolo: Questo, per intenderci meglio è il 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.... (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...)

Lo sticker non è così evidente. Nei rendering LEGO si vede lo spessore dello sticker senza contare che gli sticker applicati su più pezzi sono ‘illegal’. il fatto è che, come avete notato, sotto ci sono due plate: 1 plate 2x3 e 1 plate 2x2 che sostengono due pezzi larghi 1 stud. Di fianco si vede bene lo stacco come sotto nel giallo, ma non nel muso di UltraKatty! io ho pensato a vari pezzi, ma al momento considerata la costruzione mi viene proprio da pensare ad un nuovo brick. Chissà!

Il venerdì mattina saremo lì dalle 8.00, il lavoro da fare sarà molto visto i tempi molto ristretti che abbiamo il giovedì.

Se notate attentamente, sullo slope curved laterale (quello DBG) si nota abbastanza bene la presenza di uno sticker...

Si hai ragione sul piede ho sbagliato a scrivere il numero, è un 2. Poi io aperti non ne ho mai visti, sai com'è.

Grazie @Fabio per condividere qui sul forum l'avanzamento dei lavori. So benissimo che questa tua "documentazione" richiede tempo, ma è molto utile a tutti gli utenti del forum. Spero possa essere di spunto ed ispirazione per altri AFOL, e veder sempre di più la descrizione dettagliata di MOC, anche nelle fasi costruttive. Facebook, purtroppo, ha "assorbito" molta della conversazione che si teneva sui forum (e non è un problema solo di questo forum/tema) ma, per la sua struttura non pensata per lunghe e dettagliate conversazioni, fa si che tutto venga "dimenticato" nell'arco di pochi giorni... e, progetti come il tuo, non possono/devono essere dimenticati Direi, tra l'altro, che a conclusione del tuo progetto, possa esser messo in piedi un bell'articolo per il sito.

Per ora non sono uscite mi pare...

Come ogni edizione ci prendiamo qualche giorno per recuperare un po di forze, ma eccoci qui a fare i doverosi ringraziamenti a tutti coloro che sono venuti a trovarci nel weekend scorso e siamo davvero molto felici di aver visto parecchi amici AFOL che hanno fatto molta strada anche per trascorrere solo un paio d'ore assieme. Ringrazio @Batta87ve @bomber @LORE84 @OMINO46 @Antonello 1976 che nei mesi precedenti hanno collaborato per organizzare i dettagli di ogni cosa e che venerdì si sono presentati subito al mattino per preparare la location e comunque tutti gli espositori che a fine evento hanno sistemato la propria zona e molti alcuni si sono fermati per sistemare i tavoli e panchine. Quest'anno abbiamo aggiunto 3 giochi riservati agli espositori e siamo davvero soddisfatti perchè pensavamo di far fatica a raggiungere la quota di partecipazione che invece si è sempre riempita in poco tempo. Stiamo mettendo assieme un po di foto, così da poterle metterle nel topic fatto da Francesco. Che ne dite...ci si rivede a BorgoBrick 2016?? Grazie ancora a tutti

Ciao a tutti, questo e' il mio attuale circuito GBC, quello che esporrei a Borgobricks (in caso la mia iscrizione venga accettata). I moduli sono tutti basati su idee arcinote ma sono tutti (ri)progettati da me (non ho seguito istruzioni insomma). Alcuni sono piu' affidabili di altri ma in generale il circuito gira abbastanza pulito senza troppi interventi Purtroppo non ho i pezzi e soprattutto il tempo per fare i moduli con colori coordinati, per cui sono tutti rainbow ma vabbe' Spero di riuscire a fare altri due moduli, uno e' già in lavorazione, poi mi piacerebbe fare un modulo con EV3, magari un contatore di palline. Che ve ne pare? PS scusate il casino del tavolo da lavoro

Analizzata l'automazione di un treno con motore PF e pacco batteria a bordo del convoglio, vediamo ora come pilotare un circuito con motore 9V introducendo ulteriori componenti al nostro sistema: passaggi a livello e scambi. La comodità del sistema RC/PF è soprattutto quella di far percorrere contemporaneamente sullo stesso tracciato più treni (anche in direzioni opposte) e l'uso dei binari "flex" che offrono qualche vantaggio in più nella geometria di un circuito (anche se spesso e volentieri sono utilizzati in modo osceno ) Altro punto a favore è quello di poter disegnare tracciati impossibili da realizzare con il sistema 9V per via dei cortocircuiti elettrici che si verrebbero a creare (pensate ad un loop che rientra sullo stesso binario). Lo svantaggio del sistema RC, in occasione di un evento espositivo, è quello del consumo di batterie (in parte bypassabile con le batterie ricaricabili) e del sistema di controllo IR, non sempre affidabile. In un grande diorama city con un circuito ferroviario, solitamente, ci sono sempre almeno 2/3 treni che girano in continuazione. Per questo motivo, ho sempre preferito utilizzare i binari 9V e relativi motori e nell'arco degli anni ho accumulato un discreto numero di binari/scambi/motori di questo tipo. È quindi sempre stata mia intenzione automatizzare questo tipo di sistema oer renderlo più "dinamico". Ribadisco che sulla rete/youtube e su questo stesso forum, esistono vari progetti/esempi e documentazione sull'argomento e che il mio progetto è "uno dei tanti" con la differenza che si basa su un microcontrollore semplice da programmare/cablare. Come detto in uno dei post precedenti, il mio cruccio è quello di non vedere fili elettrici in giro per il diorama Per quanto si possa tentare di nasconderli, son sempre evidenti... E poi, cambiando ogni volta il layout di un diorama, cambia anche il circuito ferroviario e le distanze tra scambi/passaggi a livello/stazioni. Per tale motivo, quando vidi che il micro:bit integrava un semplice sistema di comunicazione radio, ho ritenuto che fosse il candidato ottimale per lo scenario "distribuito" che avevo in mente. In linea generale, i sistemi di controllo dei treni basati su Arduino/Raspberry, prevedono un sistema "centrale" (Arduini, appunto) che dirama sensori ed attuatori lungo in circuito e ne controlla lo stato e le azioni in funzione del passaggio dei treni. La mia idea, invece, è quella di un sistema distribuito, dove esistono più micro:bit sparsi per il circuito (ognuno con una/due funzioni specifiche di cui occuparsi) e connesso via radio con i restanti micro:bit, agendo in base a comandi scambiati tra di loro. Ecco lo schema che sto realizzando: Ovviamente il circuito è qui rappresentato come un "ovale" ma nella realtà, il disegno sarà più articolato e può prevedere più moduli (PL/Scambi/Stazioni). La posizione dei PL e degli scambi è assolutamente indicativa. Nello schema ho indicato anche i vari "hot point" che mi serviranno per controllare la posizione del treno e/o le funzioni da attivare. Il funzionamento che voglio ottenere è semplice: alternare due treni nella percorrenza del circuito, azionando le sbarre dei passaggi a livello prima del loro transito. Altra caratteristica, e la possibilità di modificare la velocità come visto per il circuito in versione PF. L'alternanza dei treni è ottenuta tramite parcheggio di uno dei due su un binario di "servizio" che viene abilitato/disabilitato mediante uno scambio. Gli scambi, infatti, funzionano anche da "interruttori di corrente" e permettono di isolare una parte del circuito. Per molto di voi questo concetto è abbastanza chiaro, ma lo ripeto a beneficio di chi non conosce bene il sistema 9V: Uno scambio può avere due posizioni: P0 (aperto) e P1 (chiuso). Nella posizione P0, è come se lo scambio non esistesse... il treno transita regolarmente sulla parte di binario dritto dello scambio (a prescindere dalla direzione di marcia). Nella posizione P1, il treno in ingresso sullo scambio (ovvero in arrivo dalla parte "corta" dello scambio) viene deviato sul lato destro (o sinistro). Il transito del treno proveniente dal senso opposto di ingresso dello scambio non è in alcun modo influenzato dalla posizione della levetta e dalla parte di arrivo. Quando lo scambio è in posizione P0, la tensione sulla deviazione viene scollegata e il tronco del binario è quindi non alimentato (sempreché non ci sia qualche altro punto di alimentazione sul tronco deviato). Sfrutterò quindi questa caratteristica per interrompere la corsa di un treno, nel momento in cui avrà "ingaggiato" interamente il binario di servizio. (continua appena posso)

Tornando a parlare del progetto basato sul micro:bit, vediamo ora quali sono i componenti necessari per implementarlo. Partiamo dalla versione PF, ovvero con motore alimentato dal pacco batterie LEGO a 9V. - Pacco batteria 9v (pile AAA) - Motore treno PF - Sensori di tocco RCX 879 (x4) - (in alternativa, è possibile utilizzare le varianti 879c02 / 879c03 / 879c04 o il modello 2974c01) - Microcontrollore micro:bit (€ 18,99 su Amazon.it, oppure € 21,67 completo di cavetto USB e pacco batteria 2x stilo AAA, con connettore adattore al micro:bit) - Regolatore di tensione MP1584EN (€ 1,5 l'uno - su Amazon.it vendono un bundle da 6 pezzi a € 8,99) - driver PWM per motori DC DVR8833 (€ 3,3 l'uno - su Amazon.it vengono un bundle da 3 pezzi, a € 8,99) - Cavetti PF/9v 8886 (€ 3,99 l'uno) Se si ha dimestichezza con saldatore e stagno, i collegamenti possono essere effettuati (con un po' di attenzione) direttamente sul micro:bit. Altrimenti, alla lista della spesa, è necessario aggiungere una schedina di break-out dove innestare il micro:bit ed accedere ai pin di I/O in modo più comodo. Dato che il mio progetto finale prevede l'uso di più micro:bit per gestire scambi e passaggi a livello, ho acquistato più schede di break-out, diverse tra loro per dimensioni/caratteristiche. Ecco quelle che ho preso (dalla più piccola, alla più grande): - SparkFun micro:bit breakout (pagata circa € 6,30 su Robot Italy) - MakerHawk BBC micro:bit breakout (€12,99 su Amazon.it) - Micro: bit Breakout Board (Octopus: bit) (€15,99 su Amazon.it) Nota: L'ultima è più costosa, ma ha delle caratteristiche in più, come la conversione 3.3v/5v per collegarsi anche a sensori che richiedono obbligatoriamente la tensione 9v e un connettore che per ogni pin replica anche i pin VCC/GND per semplificare la connessione ai vari sensori. D'altra parte, il lato negativo è la dimensione più grossa rispetto le altre. Su AliExpress c'è un modello di scheda di breakount abbastanza compatta, con la linea di connettori a 3 pin (VCC/GND/PINx) e, soprattutto, compatibile con i pin technic LEGO. A parte un modello di scheda di break-out (la prima dell'elenco), ho acquistato tutto il materiale su Amazon.it spendendo sicuramente di più rispetto ad altri canali. Su AliExpress ad esempio, se non si ha fretta, si può risparmiare sicuramente qualcosa... Dato che avevo voglia di sperimentare subito, mi son dovuto adeguare ai prezzi Amazon con il vantaggio di ricevere i vari componenti in un tempo variabile da 1 a 3 giorni. Come si evince dall'elenco, sono necessari ulteriori due componenti elettronici, oltre al micro:bit. Il micro:bit lavora a 3.3v e può essere alimentato direttamente da due batterie AA collegate all'ingresso di alimentazione 3.3v oppure tramite un cavetto USB (5v). Io ho voluto alimentarlo direttamente dal pacco batterie LEGO e quindi ho pensato di usare un regolatore variabile già pronto (per chi mastica di elettronica, può banalmente usare un LM7803 ed un paio di condensatori). Nulla vieta comunque di usare un portabatterie per 2 stilo ed alimentare separatamente il micro (vedremo nello sviluppo del progetto che userò anche questa soluzione). L'altro componente esterno al micro:bit è un driver PWM per motori in tensione continua (come i PF/9v LEGO). Questa schedina deve essere alimentata con la tensione di lavoro del motore (quindi 9v) e collegata al micro:bit tramite 2 fili: uno connesso alla massa (GND), l'altro al pin di uscita che useremo per pilotare la velocità del motore. Anche i due fili che alimentano il motore vanno collegati a questa schedina. Sostanzialmente (senza entrare troppo nei tecnicismi del sistema PWM), questa scheda riceve un "segnale" a 3.3v modulato dal micro:bit e lo trasforma in un segnale modulato a 9v per alimentare il motore. In base alla modulazione, viene banalmente variata la velocità del motore. Questo componente è essenziale (a prescindere dall'uso della scheda di logica, che sia micro:bit, Arduino o altro). Lo schema elettrico è il seguente. Per collegare tutti i componenti tra loro abbiamo più possibilità e tutto dipende da quanto vogliamo che sia pulito e/o modulabile/riusabile il nostro sistema. Molto dipende anche dai sensori che si vogliono utilizzare (il sensore 879 richiede il cavetto esterno tipo 9v, ma esiste anche in versione con cavo integrato 2974c01 -2x4 stud-, ma il suo costo non è irrisorio). Per collegare pacco batteria/motore e sensori di tocco al resto dei componenti io ho utilizzato alcuni cavetti 8886 che ho appositamente tagliato Il cavo 8886, oltre a essere una prolunga per il sistema PF, ha infatti anche la funzione di adattatore con il vecchio sistema 9V. (esiste anche la versione 8871, lungo 50cm) Come si vede dalla foto, il sistema PF prevede 4 cavi. Normalmente, i due fili esterni portano la tensione 9V ai vari dispositivi collegati in cascata, mentre i due interni (identificati dalle sigle C1 e C2) controllano il motore collegato. Applicando la tensione 9v su questi due cavi interni, in base alla polarità applicata sugli stessi (GND-9V o 9V-GND) si inverte il senso di rotazione del motore. Tagliando 4 cavi 8886 ho potuto collegare i sensori 879 (usando la parte del cavo con connettore 9V) al micro:bit. Con 2 delle restati "metà parti" dei cavi tagliati (lato connettore PF), ho potuto collegare il pacco batteria alle schede elettroniche (usando i due fili esterni) e il motore alla scheda DVR8833 (usando i due fili interni). Per un approfondimento sullo schema del cavetto PF vi rimando all'articolo LEGO PF Wire Hacking. Questo schema, ripeto, è relativo alla versione PF. Ora sto lavorando alla versione 9v, che prevede l'uso di due micro:bit, meno cablaggi a bordo treno, e l'uso di sensori "reed" in alternativa ai sensori di tocco 879. ...al prossimo aggiornamento Se avete domande o dubbi, son a disposizione.

In effetti, ogni volta che vedo un sistema 12V, mi chiedo come mai LEGO abbia abbandonato questa strada Se avessero portato avanti quell'idea, con le tecnologie odierne, sai cosa avrebbero potuto fare? E invece ci ritroviamo con il Boost e con un telecomando Bluetooth con portata di 4 metri. Complimenti TLG! Comunque, dobbiamo farcene una ragione ed arraggiarci: se vogliamo restare prettamente legati al mondo LEGO abbiamo RCX/NXT/EV3, ognuno con i suoi limiti e le sue complicazioni. E se devo "adattare" loro, tanto vale realizzarsi una soluzione personalizzata e più semplice da gestire.

Si sono dimostrati degli assoluti incompetenti. E' questo quel che succede quando non hai concorrenza alla spalle, e chi lavora in ambienti dove "se non ti aggiorni perdi clienti" sa di cosa parlo. Gli bastava comprare la Vengit e importare l'sBrick. Spiace perché TLG era precursore dell'automazione con i 12V, da lì è stato solo un declino. Detto questo, anche l'NXT era ed è pieno di difetti, per sistemarlo e produrre l'EV3 hanno dovuto far partecipare gli AFOL al progetto (vedi Daniele...). Perché non fare la stessa cosa con i treni? comunque ora sono un pò OT...

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

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.

Concordo. Non credo ce ne sia una migliore dell'altra e tutto dipende dagli obiettivi e dagli scenari applicativi. 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). Quando hai tempo, che ne diresti di aprire un topic e illustrarci anche il tuo progetto? 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 )

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

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

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

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.

Ciao a tutti, sto cercando l'autore di questa MOC, la chitarra MF, qualcuno lo conosce? La foto è presa dall'evento CARTOOMICS del 2017 Grazie in anticipo