GianCann

Mentre cercavo del materiale sulle minifigure LEGO, mi sono imbattuto in questo documento (una tesi del 2005) "THE LEGO BRICK IN THE BORDERZONE BETWEEN FORMS OF PROTECTION" Summary "This thesis is a case study on the attempts of the LEGO Group to achieve legal protection of the Basic LEGO Brick, i.e. the LEGO Group’s standard toy building brick with eight bosses on the upper surface. The objective is to illustrate the legal reasoning of different courts in a global perspective and find out how a company such as LEGO uses the courts and intellectual property rights for the purpose of attaining a certain desirable position on the market." Sono 105 pagine, e sicuramente non è una lettura "facile", ma sicuramente a qualcuno potrà essere utile per conoscere alcuni aspetti legali. Io me lo stampo e cercherò di leggerlo durante le vacanze estive Fonte orginale: Sito web dell'Università di Göteborg (Svezia) https://gupea.ub.gu.se/handle/2077/1938 THE LEGO BRICK IN THE BORDERZONE BETWEEN FORMS OF PROTECTION.pdf

Da Facebook:

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.

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 anticipato, ho fatto un primo test su strada del piccolo sistema di automazione che sto sviluppando per l'uso in un diorama cittadino con lo scopo di dare una "dinamicità" più realistica al circuito ferroviario e che non richieda necessariamente interventi esterni. Il circuito di test, molto semplice per motivi di tempo a disposizione, ha messo alla prova i 4 sensori LEGO e il software predisposto per il micro:bit. Faccio notare (dal video non è evidente) che tutto è alimentato dal pacco batterie 9V del sistema PF (in un successivo post, mostrerò lo schema delle connessioni utilizzate). Il treno parte dolcemente, arrivando alla velocità massima preimpostata passando per 3 step di incremento nell'arco di poco meno di 3 secondi. Il primo "hot point" che incontra è quello della "trasmissione dati": in questo test il micro:bit a bordo treno invia un messaggio contenente il numero "1" a tutti i micro:bit in ascolto sullo stesso canale. La possibilità di comunicare con altri micro:bit offre innumerevoli possibilità di interazione che illustrerò più avanti. Successivamente, ho inserito uno scambio ferroviario preceduto e seguito dagli hot point che disabilitano/abilitano i sensori. Lo scambio ferroviario, infatti, ha una rotaia che attraverso obliquamente le altre due parallele. Tale rotaia, essendo alla stessa altezza dei sensori di tocco, causerebbe l'attivazione "non voluta" dei sensori. Una volta riabilitati i sensori, il treno incontra l'hot point della regolazione della velocità: la prima volta che viene intercettato questo hot point il micro:bit diminuisce il parametro che modula la velocità del treno. Stiamo per entrare in curva (spesso i nostri treni deragliano nelle curve, se lanciati troppo veloci...) e quindi "rallentiamo" il treno per affrontarla in sicurezza. Immediatamente dopo l'hot point "velocità", il treno trova nuovamente un hot point per la disabilitazione dei sensori: in un precedente test avevo riscontrato il problema dell'attivazione dei sensori esterni durante la percorrenza delle curve e quindi, prima di affrontare la curva, disabilito i sensori. Noterete che nella curva opposta a quella "gestita" non c'è alcun hot point per disabilitare i sensori. Come mai? In realtà, non sempre il sensore che si trova interno alla curva viene effettivamente attivato (è questione di qualche frazione di mm in più o meno). E quindi non ho messo alcuna gestione della sospensione dei sensori, proprio per valutare l'attivazione "non voluta": in questo test, non è mai avvenuta Appena il treno esce dalla curva, tutti i sensori vengono riabilitati e a seguire viene subito intercettato il sensore del cambio velocità. Siccome ne era stato già trovato uno (che ha causato il rallentamento), quest'ultimo si occupa di ripristinare la velocità massima preimpostata... il treno "scatta" qui in avanti andando incontro all'ultimo hot point: il contagiri! Questo hot point stabilisce il punto in cui il treno deve decidere se fermarsi o semplicemente se conteggiare il passaggio. Ovviamente possiamo avere più hot point di questo tipo lungo il percorso e gestire la logica come più ci aggrada. Ad esempio, immaginiamo di avere 3 stazioni/fermate. Possiamo scegliere se fermarci ad ogni fermata (stile tramvia/metropolitana) oppure fermarsi a tutte le stazioni solo al primo giro e poi percorrere tutto io circuito senza più fermarsi per 2-3 giri. Nel test specifico, il treno si ferma ogni due giri per poi ripartire con l'intera sequenza. Insomma, questa prima prova su "rotaia" è andata piuttosto bene. Al di là della trasmissione radio, tutto ciò è comunque tutto fattibile anche con un vecchio RCX... peccato che il firmware sia così volatile (basta togliere le batterie per qualche secondo, e si oerde tutto) e che la programmazione dello stesso non è proprio alla portata di tutti, oltre allo sbattimento di dove far funzionare i driver USB/seriale per far funzionare l'IR Tower necessario alla programmazione (vero @Biffuz? ) Al momento, questo mio sistema presenta le seguenti criticità: 1) I sensori di tocco 879 non sono precisi/sensibili: ne ho una decina ed tra questi ho fatto varie prove prima di selezionare i 4 più sensibili (gli altri richiedevano una pressione più forte del pulsante, tale da non essere sempre attivati nei passaggi sugli hot point). Per aumentare la loro "sensibilità" aggiungo che i tile posizionati all'interno del binario non sono "incastrati" fino in fondo sugli stud, ma solo quanto basta a non farli muovere. 2) I sensori sono "ingombranti": occupano ognuno lo spazio di un brick 2x3 + 1 plate 2x3 (plate di collegamento più cavo elettrico). 3) È necessario gestire la disabilitazione dei sensori nelle curve e nel passaggio su scambi/incroci. 4) Tutta lo logica è sul treno. Questa è un vantaggio in termini di cablaggio (nessun filo lungo il circuito) ma è uno svantaggio in termini di uso del treno: finché si tratta di un treno merci, non ci sono grossi problemi in quanto basta inserire la carrozza di controllo lungo il convoglio... ma se si tratta di un treno passeggeri, bisogno mantenere il design e quindi averale una carrozza di controllo specifica per quel treno. Per quanto mi riguarda, visto il costo dei componenti elettronici, val la pena avere 2/3 carrozze specifiche per altrettanti treni, anziché doversi preoccupare di cablare il circuito ferroviario, con le complicazioni e brutture del caso. Il dubbio che ora mi assilla è quello dei sensori... devo testardamente proseguire con i sensori LEGO oppure passare ai più semplici, affidabili e versatili sensori reed? O, in alternativa, a sensori micro-switch a levetta? Nel frattempo che decido sul da farsi, proseguo con lo sviluppo del software: userò un secondo micro:bit per configurare alcuni parametri da remoto (velocità di base/numero di giri per la fermata/tempo di sosta) e per fermare/avviare il treno in caso di necessità.

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 )

Primo vero test su strada... anzi, su rotaia Stamani ho avuto modo di fare un primo test abbastanza valido dal quale posso iniziare a trarre qualche conclusione per proseguire con lo sviluppo del progetto. Rimando tutti i dettagli ad un successivo post (ora devo dedicarmi ad altro) e vi lascio con lo schema del circuito di test e il video. Dovrebbero già essere sufficientemente esplicativi.

Nel frattempo ho modificato il codice (la versione aggiornata la potete vedere qui) e rispetto la precedente prevede: 1) Possibilità di impostare la velocità di base del treno. Il valore viene salvato nella memoria del micro:bit e richiamata ad ogni accensione (il micro:bit ha un piccolo FileSystem di 30Kb, che 'sopravvive' tra uno spengimento e l'altro. Viene 'resettato' solo quando il micro:bit viene flashato con un nuovo programma). 2) Partenza "dolce": Ad ogni avvio del treno, la velocità del motore viene impostata progressivamente fino a raggiungere la velocità "massima" (quella impostata al punto 1) nell'arco di circa 2,5 secondi) 3) I sensori ora hanno le seguenti funzioni: S1: trasmette via radio un messaggio ad un altro micro:bit (in un prossimo post spiegherò a quale scopo); S2: cambia la velocità del treno. La prima volta che viene attivato diminuisce la velocità. La seconda volta che viene attivato, viene ripristinata la velocità normale; S3: Usato per contare i giri e stabilire quando fermare il treno (in questa versione, il treno si ferma ogni 3 "attivazioni del sensore", resta fermo per 3 secondi e poi riparte "dolcemente" (vedi punto 2). In un circuito semplice, si può pensare che il treno si fermi sempre al solito punto, ma in uno più grande, si può benissimo modificare la logica e farlo fermare, ad esempio, ad ogni tocco del sensore, nel caso in cui si volesse simulare la fermata in più stazioni presenti lungo il percorso; S4: Usato per disabilitare i restanti sensori. Alla prima attivazione del sensore, tutti gli altri vengono 'spenti'. Alla seconda attivazione del sensore, i restati sensori vengono riattivati. Lo scopo è quello di inibire i sensori nelle curve (per evitare il problema citato nel post precedente), durante il passaggio sugli scambi, o comunque per tutte quelle situazione in cui il tracciato potrebbe attivare involontariamente i sensori. Appena il micro:bit riceve l'alimentazione esegue le seguenti operazioni: 1) carica in memoria (dal file system) il valore della velocità. Se non trova questa impostazione, imposta il valore a 700 (e la salva sul file system) 2) mostra sul display il valore della velocità 3) mostra la lettera "R" (Ready) A questo punto si può premere su uno dei due pulsanti del micro:bit, i quali hanno le seguenti funzioni: Pulsante "B": Ad ogni pressione, aumenta di 50 punti il valore della velocità di crociera del treno fino al valore massimo 1000, dopodichè riparte da 400. Ad ogni cambio di valore, lo stesso viene memorizzato sul File System per essere riutilizzato alla successiva accensione; Pulsante "A": Dopo un countdown di 3 secondi, avvia "dolcemente" il treno... Allo stato attuale, non è implementato alcun sistema di "fine ciclo": il programma prosegue finché la batteria riesce ad alimentare il tutto. E' necessario fermare il treno "a mano" In un prossimo post, spiegherò come fermare il treno da 'Remoto'

Sulla carta no, nella pratica si... per vari motivi, a partire dai tempi di elaborazione e dalla velocità del treno (che è variabile anche in funzione del suo peso). E poi, c'è la questione del software: lo scopo è quello di lasciare il progetto molto semplice, ovvero basato sull'editor "grafico", in modo da consentirne un uso a chi non ha grosse conoscenze infiormatiche. Il "software" che ho predisposto è di tipo "event driver", ovvero determinato da eventi (i trigger generati dai sensori). Per implementare la soluzione da te proposta (sostanzialmente una bit mask), è necessario fare un polling continuo delle porte di input e gestire lo stato delle stesse anche in funzione della velocità del treno. Per far questo andrebbe bypassato il DAL (il framework che astrae l'hardware dall'ambiente di programmazione "visuale") e scrivere il codice in C per ottimizzare il tutto... tra l'altro, andrebbero usati dei microcontrollori (Ardunino o simili) più performanti. Non dimentichiami che il micro:bit, in confronto, è un "giocattolino" Fattibile è fattibile, ma diventa una cosa troppo di nicchia e sopratutto molto delicata. Il mio obiettivo è quello di fare una cosa semplice, robusta e soprattutto affidabile... vediamo, via via che faccio gli esperimenti, se riesci nell'impresa

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

Ero curioso di vedere com'è fatto internamente un sensore di tocco 879 (quello del Minstorms RCS, per intenderci). Condivido con voi queste foto, giusto per un eventuale futuro riferimento. (Nota bene: nella foto si vedono le due alette metalicche che sono 'discostate' dalla parete di plastica a loro vicina: le ho 'distanziate' io, in un esperimento per valutare la possibilità di aumentare la 'sensibilità' del pulsante stesso).

Fatto

L'unico che comprerei, se fosse in vendita. Bell'idea... te la "copierò" per metterla nella mia vetrinetta delle "cose belle del mondo LEGO"

Avevo già visto in passato, questo utilizzo dei plate round. Tra l'altro, sicuramente non sono utilizzati fin in fondo... comunque, ci vuole una gran pazienza a metterli uno sopra l'altro

Grazie @Piru Brick per l'aggiornamento Come ti ho anticipato al telefono, restano i dubbi per la portata limitata riscontrata da Sariel (e anche da Lluis Gilbert di HispaBricks Magazine): 4 metri per un dispositivo del genere sono molto pochi. Inoltre, in ottica "controllo treni", il fatto che il receiver sia un tutt'uno con il pacco batteria, senza la possibilità di alimentazione esterna, ne limita un po' l'uso in occasione di eventi espositivi (a meno di non usare quintali di batterie o sostituire, periodicamente, quelle ricaricabili). Per ora, resto ancora un po' dubbioso sul sistema: quando lo avremo tra le mani, ne capire meglio (forse) le potenzialità. Vedremo, inoltre, su quanti smart device sarà supportata l'App... e soprattutto, quando uscirà

Hai provato a parlare con qualcuno di "umano" al call center?

Un nuovo video di Sariel approfondisce il nuovo sistema la cui nota dolente e la bassa portata (circa 4 metri) della trasmissione radio. HispaBricks magazine ha invece svelato come accoppiare un telecomando/ricevitore e far coesistere più sistemi nello stesso ambiente: 1) Per "accoppiare" telecomando e ricevitore è sufficiente accenderli contemporaneamente premendo sui riapettivi pulsati di accensione per alcuni secondi 2) Una volta accoppiati, è possibile cambiare il canale premendo più volte sul pulsante di accensione del ricevitore: il led cambiare di colore (ad indicare il canale) e parallelamente il trasmettitore agganciato si commuta sullo stesso canale di trasmissione, evidenziato sempre dal cambiamento di colore del led. 3) Ad ogni riaccensione, il ricevitore "ricorda" il telecomando associato. 4) I canali sono 4. 5) Il ricevitore ha un comportamento diverso a secondo se vi è collegato un motore "treno" o un motore WeDo (in sostanza, quest'ultimo funziona solo se il pulsante del telecomando è continuamente premuto e non c'è variazione di velocità. 6) Io pacco batteria+ricevitore ha le stesse dimensioni del precedente pacco batteria (quindi si risparmia lo spazio del ricevitore IR, come era già chiaro) e prevede solo 4 batterie, anziché le 6 precedenti. Per quanto mi riguarda, allo stato attuale sono molto deluso da questo nuovo sistema.

Ok, ti basta seguire questo topic Tra oggi e domani vedo di aggiornarlo con gli ultimi test e con l'obiettivo che intendo raggiungere

Per quanto riguarda il diorama comunitario, è mia intenzione portare un sistema di controllo dei treni che sto pian piano sviluppando. L'evento di Lecco potrebbe essere l'occasione giusta per fare un test reale nello scenario di un evento. Ci sarà un circuito a 9v?

Ieri sera ho fatto il mio primo esperimento "vero" esperimento dopo l'immancabile Hello World Ho testato la libreria IR di Phillip per pilotare 4 M-Motor collegati a 2 ricevitori configurati rispettivamente sul canale 1 e 2. Dopo un'iniziale perdita di tempo dovuta ad un errore di connessione del diodo IR presente nella foto che accompagna l'articolo (e che già ho segnalato all'autore) sono riuscito a far accendere in sequenza, per poi spenderli tutti insieme, i 4 motori. In realtà, se guardate bene il video, il primo motore non si spegne... sostanzialmente, l'invio troppo repentino di comandi IR non sempre viene correttamente recepito/interpretato da ricevitori. Del resto, per l'impiego che ne voglio fare, non avrò bisogno di inviare più comandi IR senza una pausa di alcuni secondi l'uno dall'altro. Il diodo l'ho dissaldato da un telecomando per treni (LEGO ovviamente) e l'ho poi saldato sulla PCB del micro:bit usando il Pin 0 (che è quello di default), ma può essere usato un qualsiasi altro pin di output semplicemente impostandolo nella routine "Start" del micro:bit. Il prossimo test sarà quello per valutare la sensibilità e l'impiego migliore tra due sensori: quello magnetico e quello di luce. Successivamente, testerò l'impiego del sensore di luce del sistema RCX

Lo hai scritto mentre sono alla Coop, davanti allo scaffale LEGO. Ho giocato tanto da bambino con BJ, ma non ricordo costasse così tanto... Sono davanti a quel tizio vestito da cane: 34,90 euro... 70.000 lire... Allucinante..

Visivamente, vien da pensare che un telecomando può controllare un solo ricevitore alla volta...