GianCann

Un mix di LEGO, Arduino, Raspberry e pezzi custom stampati in 3D per realizzare questo microscopio digitale: In questo articolo c'è tutta la spiegazione del progetto: Build A Sophisticated Microscope Using LEGO, 3D Printing, Arduinos, and a Raspberry Pi

Isogawa se n'è inventata un'altra delle sue...

Si: http://sohobricks.com/catalog.html

Trovo questa scelta discutibile.

Ti serve semplicemente un "ponte raddrizzatore". Trovi un'ampia spiegazione qui: https://it.qwe.wiki/wiki/Diode_bridge

La manta pezzata e il trolley?

Penso che @Pix si riferisca a questo articolo: https://www.promobricks.de/LEGO-city-sommer-sets-2020/98577/

Cancellata persino l'Oktober Fest! Voglio dire... in Germania hanno avuto un numero di decessi nettamente inferiori rispetto a quelli del nostro Paese ed hanno un sistema sanitario con oltre 25.000 posti di terapia intensiva. È oramai dato quasi per scontato (a sentire le previsioni di esperti, e non di " mio cuggino che ha studiano medicina su Facebook in 24 ore") che in autunno ci sarà una seconda ondata massiccia di casi. I grandi eventi avranno vita difficile... https://www.oktoberfest.de/en/magazine/oktoberfest-news/2020/cancelled-corona-oktoberfest-2020-cannot-take-place Anche Firenze Rocks 2020 è sulla strada dell'annullamento, benché non ci sia stato ancora un comunicato ufficiale (replicavano la loro presenza i Guns'n'Roses ed era anche la volta dei RHCP!) Tra l'altro, mi accorgo solo ora che i mattoncini LEGO occupano una posizione di rilievo sulla Home Page di firenzerocks.it !!! Accanto a Axl Rose e John Frusciante (e Vasco Rossi), ecco a voi i... "Mattoncini LEGO in concerto!" Il motivo è spiegato qui:

A quanto pare, stanno dicendo che lamentele svariati AFOL hanno esternato (ed io sono tra questi, pubblicamente e privatamente) sono state ricevute dal team.

Scusate se rispondo solo ora, ma questi ultimi giorni sono stati un po' complessi in termini lavorativi (...anche stamani sto andando a lavoro per completare un'attività collegata alla predisposizione della "Fase 2"). Purtroppo, dopo uno start veloce, ho un po' trascurato ATS per vari motivi ma ora è arrivato il momento di riprendere il mano in progetto anche in virtù dell'interesse di @BOLTO@ e di @Wise, nuovo utente del forum che mi ha scritto in questi giorni per collaborare al progetto. Anche @lucanatali è interessato ad ATS. Riprenderei il discorso da dove ci eravamo fermati con @pivan e @sky7176, pubblicando su GitHub il firmware (per l'ESP8266) al quale eravamo arrivati qualche mese fa. Non è completo al 100%, se non ricordo male, ma era già ad un ottimo punto. Proporrei anche una "videoconferenza", da effettuarsi in settimana, per fare un punto della situazione e, magari, assegnarci dei compiti. Chiederei anche a @Valter1966 di riprogettare la PCB sulla base dei 30 ESP-03 che ho acquistato in Cina, in modo da distribuire 2-3 prototipi a testa di quello che potrebbe essere il "core" hardware per i sensori / attuatori. Un primo obiettivo potrebbe essere quello di completare la documentazione di ATS al fine di fornire un punto base di partenza per chiunque voglia sfruttare questa idea, per poi poterla adottare alle proprie esigenze. Se state seguendo anche il topic su Pybricks, saprete che ci sono interessanti prospettive future. Proprio ieri sera ho cablato un sensore Powered Up che funziona anche con l'App e con il firmware originale. Devo solo rendere presentabile/comprensibile il codice e pubblicarlo su GitHub. Insomma, riprendiamo le fila di ATS, la cui filosofia è quella di voler essere un sistema di base aperto e personalizzabile a piacere.

Ci sono riuscito!!! È stato meno semplice di quanto avevo previsto inizialmente, in particolare perché ho usato un hardware troppo "evoluto" e non ho tenuto conto di alcuni aspetti legati ai due core dell'ESP32. Alla fine, grazie analizzatore logico arrivato ieri, sono piante piano risalito ai vari problemi che non permettevano al mio sensore di essere riconosciuto dall'Hub LEGO. In un prossimo post illustrerò una applicazione pratica

Tickets do not include parking (if you drove somewhere, you are doing it wrong).

Quello non è un inganno, ma è l'uso di una feature che era stata prevista in fase di progettazione. Non è stata una funzionalità resa pubblica da subito ma, ora che ho studiato a fondo il sensore di colore, è ben chiaro che la possibilità che lo stesso potesse funzionare come trasmettitore IR è stata progettata appositamente. E, senza dubbio, per poter interagire con il sistema LPF1 (mi chiedo solo perché non lo abbiano detto subito...) Detto questo, è una cosa differente rispetto a quello che voglio fare io: interagire con l'App ufficiale e su con un hub con firmware originale. E, dato che questi, ad oggi, non contemplano la possibilità di utilizzare un sensore di input che non sia un sensore di colore o un motore tachimetrico, l'unico modo è quello di far finta di essere uno di questi

Il weekend di Pasqua l'ho dedicato non solo a mangiare, ma anche a riprendere in mano un discorso che avevo iniziato ad esplorare la scorsa estate (vedi qui e qui) ma che, senza la necessaria documentazione e l'opportuna strumentazione per fare reverse engineering, era rimasto in stand-by. Parlo della possibilità di espandere il sistema Powered Up con sensori personalizzati rispetto a quelli ufficiali LEGO. Come ho già spiegato in questo post, il firmware Pybricks già consente di fare questo (supporta anche i sensori dello Spike Prime), basandosi sul protocollo LEGO UART Messaging Protocol (LUMP). LEGO, ha introdotto questo protocollo (proprietario) con il Mindstorms EV3 e non esiste documentazione dettagliata dello stesso se non questo scarno documento risalente al 2013 e questo articolo che cerca di dettagliare meglio alcune aspetti di quel documento. Questo protocollo, da quanto è emerso dal reverse engineering effettuato sulle comunicazioni sensori<>hub del sistema Powered Up (Spike Prime incluso) è stato ulteriormente esteso al fine (si presume) di integrare sensori più evoluti (come lo è già il sensore di Colore/Distanza, in effetti) e, chissà, ulteriori funzionalità future... Ma se con Pybricks è sufficientemente semplice implementare un sensore personalizzato, come si può integrare un sensore (ad esempio, sensore di tocco o magnetico) su un hub con firmware originale usando l'App ufficiale LEGO? Ci sono due possibilità: 1) LEGO implementa questa possibilità, documentandola dettagliatamente. 2) Ingannare l'hub (e l'App) LEGO. Per la prima opzione, direi che il proverbio "campa cavallo che l'erba cresce" è più che calzante... Non resta quindi che ingegnarsi qualcosa e procedere con l'opzione 2 Pertanto, se al momento l'unico sensore esterno funzionante con gli smart hub è il sensore di colore, cosa possiamo fare? Semplice... realizzare un sensore che faccia finta di essere un verso sensore di colore prodotto da LEGO! La differenza sarà solo nell'informazione che invieremo all'hub: invece di comunicare lo specifico colore rilevato (sono 10 i colori codificati nell'App e riconosciuti dal sensore), comunicheremo il valore di un colore in funzione di un trigger esterno (pulsante/contatto magnetico/qualsiasi cosa). All'interno dell'App, invece, continueremo ad utilizzare il blocco "Rileva colore" sapendo però che al colore nero corrisponde la chiusura di un contatto e al colore rosso la chiusura di un altro, e così via. In realtà, il numero di trigger gestibili è più grande se consideriamo un altro parametro che il sensore originale può rilevare/comunicare: la distanza di un oggetto. Dato che 10 trigger sono più che sufficienti (anche per realizzare una sorta di sensore analogico) mi soffermerò alla sola gestione dei colori... falsi! Piccola nota: poc'anzi ho evidenziato che il sensore di colore è l'unico sensore attualmente supportato dai tre smart hub Powered Up (il Move, il City e il Technic). Questa affermazione è in realtà incompleta, dato che anche i tachimetrici sono visti (anche) come sensori in virtù del fatto che comunicano i dati sulla posizione/rotazione dell'albero. Ma come si può realizzare un sensore che simula (quanto meno nella parte di comunicazione) il sensore LEGO? Innanzitutto è necessario conoscere nel dettaglio cosa comunica il sensore LEGO e come reagisce ai comandi inviati dall'hub. Ho quindi preso un sensore, ho tagliato il cavo e l'ho collegato ad un microcontrollore (ESP32, flashato con firmware MicroPython) ed ho cercato di "simulare" un hub LEGO inviando le sole comunicazioni necessarie ad attivare il sensore e ricevere i dati. Il risultato è stato questo: accendere un LED di colore corrispondente al colore del brick analizzato dal sensore. Sostanzialmente ho fatto finta di essere uno smart hub ed ho loggato tutto lo stream di byte trasmesso dal sensore. Non è stato semplice arrivare a questo risultato dato che l'avere a disposizione la scarna ed incompleta documentazione sul protocollo LEGO non era sufficiente a far funzionare il tutto. Ho quindi dovuto studiare la timeline della trasmissione seriale (non avendo ancora un analizzatore logico, mi sono fatto catturare i dati da Philo Hurbain, che ha aveva già studiato il protocollo) e incrociando dati e informazioni, pian piano sono riuscito a venirne a capo! Non di meno, ho avuto uno scambio di opinioni e approfondimenti con David Lechner (uno degli sviluppatori di Pybricks, nonché gestore del progetto ev3dev) che, dall'alto della sua esperienza/conoscenza, mi ha confermato alcune mie supposizioni. È stata una piccola-grande soddisfazione e, non di meno, un'attività di studio-ricerca che mi ha impegnato parecchio e mi ha consentito di comprendere meglio alcuni aspetti tecnici che, finora, non mi era capitato di approfondire. Tenete conto che, nel momento in cui saranno rilasciati i sorgenti del firmware Pybricks (prima o poi saranno resi pubblici) tutto sarà molto più "semplice e chiaro", dato che gli sviluppatori hanno già affrontato tutti questi aspetti. Però, al momento, questi sorgenti non sono pubblici e non potevo neanche prentendere che David mi spiegasse tutto il protocollo nei minimi particolari... Chi volesse dare un'occhiata al codice Micropython che ho usato per leggere il sensore, può vederlo qui ( @fonderiadigitale che ne dici?) Noa: non è un codice perfetto e neanche mi interessava che lo fosse dato che lo scopo di questo "programma" è temporaneo e finalizzato solo a studiare i dati dal sensore. Ieri sera, dopo che gli ho mostrato ciò che ero riuscito ad ottenere, David ha reso pubblica la sua documentazione sul protocollo LUMP ed è sicuramente più chiara e completa di quella finora disponibile. Ora sono pronto per il "next level", ovvero creare il sensore finto! A tale scopo, userò sempre un microcontrollore ESP32 con MicroPython a bordo. Vediamo se riuscirò veramente ad ingannare l'hub LEGO

Puoi spiegarmi i passaggi, che provo a replicare?

Mi mostri uno screenshot del programma che stai testando?

Che intendi esattamente? Puoi spiegarmi meglio, in modo da cercare di replicare il problema? Bella domanda! Ho chiesto al team di sviluppo del firmware se mi fanno sapere qualcosa. Il PM mi ha risposto che questo tipo di test lo fa un'altra sezione e che la settimana prossima mi metterà in contatto con loro (vedremo se è vero...)

Proseguono i test... una delle cose che mi sarebbero piaciute da parte di LEGO, per quanto riguarda il sistema Powered Up, era la documentazione del protocollo "wired" cioè quello dei sensori/motori collegati. E la conseguente possibilità di gestire eventuali sensori personalizzati. Anche perché ero (erroneamente) convinto che Powered Up implementasse un nuovo protocollo. Invece, grazie a Pybricks, scopro che i sensori (anche quelli dello Spike, ovviamente) usano lo stesso protocollo denominato "LEGO Uart messaging protocol" già "decodificato" da tempo (perché LEGO, sia mai che rilasci documentazione completa ed aggiornata...) ed usato dai tempi dell'EV3 anche se sembrerebbe lo abbiamo evoluto aggiungendo alcune caratteristiche ancora sotto la lente di ingrandimento di chi sta facendo reverse engineering. Sono quindi partito da questa scarna documentazione, studiando alcuni esempi basati appunto sull'EV3 https://sourceforge.net/p/lejos/wiki/UART Sensor Protocol/ Capita la logica del protocollo e avendo un esempio già funzionante in MicroPython per Micro:bit, ho riadattato il codice in C++ ed ho usato un ESP8266 per simulare un sensore che invia continuamente una serie di dati (fittizzi, al momento). Ebbene, funziona Nota: l'ESP è alimentato direttamente dalli Smart Hub Ho usato la classe LUMPDevice di Pybricks che funziona egregiamente benché ho suggerito agli sviluppatori alcuni miglioramenti che verranno valutati sulla base della poca memoria disponibile sul Move Hub (sugli altri Hub c'è più possibilità, dato che hanno una memoria più ampia). Comunque, oltre alla LUMPDevice ci sarà anche una più generica UARTDevice e non sarà necessario adattarsi alla logica del protocollo LUMP rendendo tutto molto più semplice. Chi volesse dare un'occhiata al codice C++, lo può trovare qui: https://pastebin.com/6TiK6Sr8 tenendo a mente che è uno sketch "nudo e crudo" senza alcuna ottimizzazione. Questo, invece, il codice usato sul Move Hub, con Pybricks: mySensor=LUMPDevice(Port.D) for a in range(1000): print(mySensor.read(0)) wait(200)

Esplorando i metodi delle varie classi finora implementate in Pybricks, ieri sera ho fatto qualche test con run_until_stalled della classe Motor. Questo metodo permette di avviare un motore (di tipo tachimetrico) specificando la velocità di rotazione in gradi al secondo. Il metodo è sincrono e restituisce l'angolo di rotazione nel momento in cui l'albero motore va in stallo ovvero incontra un ostacolo. leftMotor = Motor(Port.A) pos = leftMotor.run_until_stalled(100,Stop.COAST,30) 100 = velocità di rotazione espressa in gradi al secondo Stop.COAST = la tipologia di stop che deve effettuare il motore, nel momento di stallo 30 = rappresenta il duty_limit, ovvero la forza di torzione (utile per non sforzare meccanismi con rapporti elevati) Quando il motore avrà raggiunto il punto di stallo, in pos avrò l'angolo di rotazione percorso dal motore rispetto al punto 0. I motori tachimetrici supportati dal sistema Powered Up sono questi: (nella foto non è mostrato il Move Hub, i cui due motori interni sono comunque tachimetrici) Conoscere il range di azione di un motore è fondamentale quando si deve inizializzare un meccanismo che agisce in un raggio di azione limitato meccanicamente (ad esempio: lo sterzo di un veicolo, il controllo di uno scambio ferroviario, un GBC). Quando avviamo il nostro meccanismo/programma, non è assodato che la posizione dell'albero motore sia nota o predefinita. Grazie a run_until_stalled, quindi, all'avvio del programma possiamo eseguire la seguente procedura: 1) Azionare (con run_until_stalled) il motore in senso antiorario finché non arrivi al punto di stallo 2) Impostare il primo punto di stallo come "Posizione 0" temporanea, usando il metodo reset_angle della classe Motor. 3) Azionare il motore in senso orario finché non arrivi al nuovo punto di stallo, usando nuovamente run_until_stalled. 4) Rilevare l'angolo di rotazione effettuato dal motore a partire dal punto '0' temporaneo impostato al punto 2) (ammettiamo di ottenre il valore 180) 5) Dividere per due il valore ottenuto (risultato: 90) ottenendo l'angolo di riferimento di metà range di azione. Questo valore sarà memorizzato in una variabile, per uso successivo. 6) Ruotare in senso antiorario l'albero motore sulla base di del valore ottenuto al punto 5). Per fare questo, si userà il metodo run_angle della classe Motor. Questo metodo posiziona l'albero motore sull'angolo passato come parametro, facendo riferimento allo zero assoluto impostato al passo 2). Invocando run_angle(360,90), quindi, l'albero motore ruoterà in senso antiorario (ricordate: il motore era fermo alla posizione 180°, e deve ruotare in senso antiorario per arrivare alla posizione 90°). Il valore 360 rappresenta la velocità di rotazione, ovvero 360° al secondo. 7) Impostare nuovamente la posizione 0 (con reset_angle) che, questa volta, sarà la posizione centrale definitiva. A questo punto, azionando il motore con run_angle usando +/- 90° possono muovere il motore in un verso o nell'altro, e tornare sempre alla posizione 0 con run_angle(360,0) Questo è il codice completo per trovare la posizione centrale, se il motore è limitato nel suo raggio di azione con dei meccanismi di blocco dell'alberlo motore myMotor = Motor(Port.A) pos = myMotor.run_until_stalled(-100,Stop.COAST,30) myMotor.reset_angle(0) pos = myMotor.run_until_stalled(100,Stop.COAST,30) pos = pos / 2 myMotor.run_target(360,pos) myMotor.reset_angle(0) In questo video, un esempio pratico dell'uso di run_until_stalled: una volta determinato il centro tra le due plate gialle, il motore si muove da un lato all'altro, senza raggiungere i limiti fisici del raggio di azione. Notare come l'albero del motore, prima dell'avvio del programma, non sia nella posizione centrale che verrà successivamente determinata. Vi ricordo che la documentazione di Pybricks è disponibile su https://docs.pybricks.com/en/latest/

Ho a disposizione uno Spike Prime e quindi non potevo non provare i sensori su Pybricks. Vi faccio notare che, ad oggi, questi sensori non sono supportati dall'App LEGO. Sono test molto semplici il cui scopo è stato solo quello di verificare che funzionassero. Molto interessante il sensore di tocco che, a differenza dei suoi predecessori per RCX/NXT/EV3, fornisce (anche) un valore di pressione in una scala da 1 a 100. Sensore di tocco: Sensore a ultrasuoni; Sensore di colore: in realtà, non ho usato il sensore come tale, ma come led animato (al suo interno sono presenti 3 led, controllabili indipendentemente).

Il nostro governo ha finora predisposto delle misure economiche mai viste prima d'ora (e, nonostante questo, non saranno sufficienti). Pensare che da qui a 6-8 mesi si possa tornare a fare eventi dove si aggregano un numero elevato di persone, con il conseguente elevato rischio di riscatenare la diffusione e con la possibilità di ritornare nuovamente in una situazione di lockdown (con tutto ciò che ne conseguerebbe, sia dal punto sanitario che da quello economico) è veramente utopistico. @AirMauro penso possa fare un proiezione più chiara di quello che ci aspetta in futuro, visto i suoi studi/preparazione sull'argomento.

Ma va'???

No. Dice che ha il dubbio. Oggi non lo avrebbe perché, per quanto possa essere immenso, l'universo *deve* per forza avere dei perimetri se paragonato all'idiozia umana i cui confini superano qualsiasi legge matematico-fisica. Anche quelle che ancora oggi non conosciamo.

Lo diceva solo perché non esistevano ancora i social, a quei tempi... altrimenti, un paragone del genere non lo avrebbe mai fatto: l'infinità dell'universo è una bazzecola rispetto a quella della stupidità umana.

In questo post vi parlo dell’altra grossa novità introdotta con la versione 3.1.0 dell’App LEGO Powered Up (Android e iOSil supporto alla trasmissione del protocollo IR LEGO LPF1 e, quindi, della possibilità di integrare il ‘vecchio’ (ma ancora vivo e vegeto) ecosistema LEGO Power Function 1.0 (LPF1). (ndr: Sarei veramente curioso di scoprire se questa nuova feature sia stata ‘stimolata’ dal video pubblicato da Pybricks qualche settimana fa, oppure fosse qualcosa di già pianificato e rilasciato, guarda caso, proprio a ruota rispetto lo spoiler di Pybricks (mi piace pensare che la prima ipotesi sia quella più plausibile). Soprattutto per il modo ‘frettoloso’ e un po’ spartano con il quale è implementata e, non di meno, per il fatto che non hanno pubblicato da nessuna parte la documentazione. A parte questo, quella di integrare il supporto IR nell’App ufficiale è stata una bella cosa benché, come vedrete più avanti, soffre di alcuni limiti. La documentazione del protocollo IR LEGO è stata rilasciata tempo fa e, nell’arco degli anni, abbiamo visto molteplici implementazioni di questo protocollo, da Arduino ad Android (per quei telefoni che sono dotati di IR Blaster). Basta un diodo LED IR, pilotato secondo le specifiche del protocollo, per replicare i due telecomandi IR LEGO. Dato che all'interno del sensore di colore/distanza/luminosità del sistema Powered Up è presente anche un diodo IR, per gli sviluppatori LEGO (e per i ragazzi di PyBricks) è stato abbastanza “semplice” implementare questo il protocollo di comunicazione anche nel sistema PU. I vantaggi sono tre: 1) quello di estendere il numero di motori/luci controllabili dall’App… si può arrivare ad un totale di 8 motori/luci LPF1 (con 4 ricevitori); 2) la possibilità di controllare il sistema LPF1 secondo una logica di programmazione; 3) integrare insieme PU e LFP1 (cosa che molti AFOL chiesero sin dall’inizio, seppur con qualche differenza) Vediamo ora come funziona questa integrazione… per comodità, utilizzerò i video di Racing Brick, integrandoli con alcuni miei screenshot dell’App. Sostanzialmente, nella versione 3.1.0 hanno introdotto due nuovi “blocchi” relativi al sensore IR. Il primo (a sx), serve ad impostare il sensore di colore/luce in modo da funzionare come ‘trasmettitore’ IR. Richiede due paramentri: - la porta alla quale è connesso il sensore che vogliamo usare come trasmettitore (A,B per Move e City Hub, A,B,C,D per il Technic Hub) - Il valore fisso 7, che specifica la modalità di trasmissione IR (tutte le modalità di supportate dal sensore, sono disponibili in questo log) Il secondo blocco (a dx), invece, è quello che ci permetterà di inviare i comandi specificando la porta alla quale è connesso il sensore, il canale di trasmissione (sono 4), l’uscita del ricevitore IR sulla quale vogliamo intervenire (sono 2, la rossa e la blue) e, infine, il tipo di azione che vogliamo intraprendere (impostare la velocità nel due diversi sensi di rotazione, con 7 step di velocità ognuno, fermare il motore di ‘botto’, fermare il motore in modo libero). In questa foto, un dettaglio del ricevitore IR: Nello specifico, i valori utilizzabili sono: - Primo parametro: porta alla quale è connesso il sensore di colore: A,B per Move e City Hub, A,B,C,D per il Technic Hub - Secondo parametro: canale di trasmissione, con queste combinazioni valore/canale 0=1, 1=2, 2=3, 3=4 - Terzo parametro: uscita del ricevitore IR sulla quale si vuole agire, dove 4=Rossa, 5=Blu - Quarto parametro: tipo di comando da inviare, secondo questo schema: 0 = Stop (break) 1,2,3,4,5,6,7 = rotazione in senso orario, dove 1 è la velocità minima, e 7 quella massima 8 = Stop (float) 9,A,B,C,D,E,F = rotazione in senso antiorario, dove 9 è la velocità massima, e F quella minima In questo video, c'è un esempio reale sull'utilizzo di questi blocchi: C’è da sottolineare che l’App è stata rilasciata oramai da due settimane e che quel “Find more info on our website” non ha avuto, ad oggi, alcun seguito: nessuna documentazione/spiegazione ufficiale da parte di LEGO è attualmente disponibile su come utilizzare questa nuova funzionalità… Quindi, le informazioni su come utilizzare questi blocchi sono state desunte dalla community con una serie di tentativi basati sulla documentazione del protocollo IR che, nell’arco di poco, hanno consentito di sfruttare subito questa nuova feature. Una cosa certamente non alla portata di tutti… anche il modo con cui sono stati predisposti questi blocchi lascia qualche interrogativo. Infatti chi mastica un po’ di programmazione, ed ha avuto a che fare con il protocollo IR di LEGO, noterà che manca un ulteriore valore: il checksum. Questo vuol dire che il checksum è automaticamente calcolato dal firmware a bordo dello smart hub (cosa buona e intelligente). Però, se gli sviluppatori si sono preoccupati di togliere questa incombenza agli utilizzatori, perché non hanno gestito diversamente i parametri di ingresso? Perché, ad esempio, non usare direttamente i valori 1,2,3,4 per specificare il canale di trasmissione, anziché usare 0,1,2,3 creando un po' di confusione? Perchè non hanno codificato il colore della porta di uscita del ricevitore IR (rossa e blu), così come hanno fatto per i pulsanti del telecomando, anzichè utilizzare i valori 4 e 5? Stesso discorso vale per i comandi da inviare. Perché, infine, implementare uno specifico blocco per impostare il sensore sulla modalità IR? (avrebbero potuto gestire questa cosa direttamente nel firmware). Le possibilità sono due: hanno implementato questa cosa “in fretta e furia” (senza rilasciare, contestualmente, la relativa documentazione), oppure prevedono di estendere l’uso anche oltre il sistema LPF1 (ad esempio, per interagire con l’EV3?). Chissà… Come considerazione personale, devo dire che il sistema Powered Up non è ‘curato’ come mi sarei aspettato da una azienda che ha come moto “Only the Best is Good Enough”. Il sistema PU è una ‘semi-rivoluzione’ nel mondo LEGO, ma la documentazione (scarsa, nel migliore dei casi e mancante, nella stragrande maggioranza) fa si che pochissimi AFOL ne abbiano scoperto le potenzialità. Tornando a parlare della funzionalità IR, dal punto di vista tecnico, c’è da dire che “non tutto quel che luccica è oro…”. Racing Brick ha effettuato dei test molto approfonditi che hanno evidenziato alcune limitazioni relative a tempi di risposta, distanza e raggio di azione nel pilotare LPF1 tramite il sistema Powered Up. Questo video, è particolarmente esplicativo: https://www.youtube.com/watch?v=Eb4gkKNtS0E C’è però da dire che, seppure questa integrazione non permetterà di controllare adeguatamente una macchina come quella del video, potrà essere abbastanza utile nel controllo di un layout ferroviario con treni che montano il sistema LPF1. Sulla carta, si potrebbe arrivare a controllare sino a 8 treni LPF1, oppure una qualsiasi combinazione tra treni e scambi, fino ad arrivare a 8. Infatti è possibile impostare due ricevitori sullo stesso canale, e configurare rispettivamente i motori sul canale rosso e su quello blu. Per ovviare al problema di copertura del raggio IR, ho provato a costruire una 'torretta di irradiazione' a 360°. Certo, è un po' dispendiosa considerando che è necessario un Technical Hub e ben 4 sensori... Al di là di tutto, l'integrazione del supporto IR all'interno del sistema PU è senz'altro un'ottima cosa. Nei prossimi giorni, vi mostrerò alcuni esempi pratici, soprattutto per controllare i treni e per rendere il codice più "leggibile", come in questo sketch che ho realizzato per fare alcuni test: Nello specifico, le due sezioni superiori servono ad avviare e a fermare il motore sulla porta Rossa e quelli sotto, a controllare allo stesso modo il motore sulla porta blu (notate le bandierine rosse e blu, e le icone che rappresentano le azioni sui motori). Se avete qualche dubbio, chiedete pure! EDIT 21 maggio 2020: aggiungo il link a questo articolo > https://reptile-addict.nl/wp/2020/05/21/sent-LEGO-power-function-ir-commands-with-LEGO-powered-up-and-boost/