GianCann

Ottima descrizione di tutto il processo. Ringrazio nuovamente il designer @pivan (secondo me si starà auto-maledicendo ripensando allo scorso novembre quando mi portò la primissima bozza "toccabile" del box) e il "service di stampa" @ZioTitanok Mi riservo di fare alcune prove pratiche per poi fornire le mie impressioni. Nel frattempo @Pix dovrebbe riuscire a stampare il box anche in ABS. Magari, avendolo anche lui tra le mani (non fraintendete!) potrà fare le sue osservazioni tecniche vista la sua esperienza nella progettazione tecnica.

Il PLA grigio preso da filoprint.it è molto, molto simile al DBG LEGO! Il Clutch Power, inoltre, è fenomenale!

@Pix, i file sono già disponibili sul Repository GitHub di ATS, folder 3D_Print Stamani sono state fatte le prime prove da alcuni "AFOL-makers" ( @ZioTitanok e @ilmanciobo) Qualche insuccesso iniziale... Che, con qualche aggiustamento si sono trasformati un qualcosa di interessante. Sicuramente ci sono margini di miglioramento sui quali lavorerà il designer @pivan dopo che riceverà i feedback sul prodotto "tangibile"

Laurens ha pubblicato la RoadMap di PyBricks! Pybricks 1.0 was all about bringing Pybricks MicroPython to EV3. This came out early 2019. It's super exciting to see people using this actively. An epic number of users! According to Visual Studio Code, anyway. If you're one of those, click on this post so we know you're here! Pybricks 2.0 was all about improving the EV3 experience. To make it absolutely solid, tested, fully-featured, and FLL-ready. It's ready now ( ), and should be available in the latest ev3dev build soon. Hopefully LEGO will update their official derivative version soon too. Pybricks 3.0 will add support for Powered Up! Newly supported hubs / programmable LEGO BOOST MoveHub: MoveHub() LEGO Powered Up City Hub: CityHub() LEGO Technic Control+ Hub: CPlusHub() Newly supported motors / sensors: BOOST Color and Distance Sensor BOOST Interactive Motor Technic Control+ Motors (L, XL) SPIKE Prime Motors (M, L) SPIKE Prime Sensors (Color/Ultrasonic/Force) Go fully open source Pybricks Code: Cross-platform editor for Powered Up. No install required! Lets you install Pybricks MicroPython firmware Lets you run Pybricks MicroPython scripts Windows / Mac / Linux / Android / ChromeOS By default, a script runs from memory: This is super quick and easy , but you have to be connected to start the program . Use this to test & develop your script. Optionally, a script can be included when you update the firmware: This is slow to download , but your script stays ! Use this when you're happy with your program (or if you have unlimited patience) Start your script with the button. No Bluetooth connection required. Take your hub anywhere! You have to send us footage if you send it into space Pybricks 4.0/5.0 will be ... ? In other words, what might we do one day, in a galaxy far away, but certainly not right now? This is all super cool too, but it's better to stay focused on making the essentials really good first. Support for internal sensors like accelerometer and IMU. Support for older (NXT) and newer hubs (Mario) Support for LEGO SPIKE Prime Powered Up hub-to-hub communication Powered Up remote handset support Improvements to EV3 Visual Studio Code extension There are also a few things that are just not possible due to hardware limitations: Support for WeDo 2.0: Unless we missed something, this firmware can't be updated. So you can't install Pybricks. Most of the hubs have sufficient flash and RAM capability for Pybricks. But the BOOST Move Hub has less than half of what the others have. So, not all new features beyond 3.0 will come to the BOOST Move Hub. Other than that, the sky is the limit!

La moda l'ha lanciata sicuramente JBricks, ma Isogawa è quello che più di tutti la sta "espolorando" con fantasia

Il video delle 7 linee rosse mi mancava Ottimo lavoro: sono sicuro che @ZioTitanok ci farà assistere alla "diretta live" della prima stampa, vero?

Chissà se farà la stessa fine dell'annunciata collaborazione LEGO & IKEA Oramai sono passati due anni (il mese prossimo) dal primo annuncio, e uno dalla presentazione del (solo) nome della linea "BYGGLEK". Chissà se quest'anno la vedremo nella realtà (il lancio era previsto "nel corso del 2020").

I complimenti vanno in maggior parte a @sky7176 che ha scritto buona parte del codice. Io gli ho giusto indicato le funzionalità che avrebbe dovuto avere il controller. Tieni conto che il la versione attuale del firmware ha queste caratteristiche: 1) Gestisce un solo motore (conto già domani di aggiungere il secondo) 2) È aggiornabile via OTA (quindi, una volta effettuato il primo upload via seriale, si può aggiornare tramite WiFi) 3) Oltre che con MQTT, è controllabile via comandi HTTP. 4) Utilizza il file system SPIFFS (1 MB) per memorizzare alcune pagine HTML per mostrate le info sul chip e per procedere con l'upload di un nuovo firmware (e per impostare alcuni parametri. 5) Buona parte del firmware (WiFi/MQTT/OTA/Configurazione) sarà utilizzata per il Controller Sensore (se guardi nel codice, c'è una variabile "ControlType" che servirà proprio a selezionare la modalità di funzionamento). Su quest'ultimo punto c'è da valutare se lavorare con due firmware separati oppure uno unico, magari scrivendo una classe Controller che implementa entrambe le funzionalità. Per quanto riguarda la gestione dei motori, penso che sia più opportuno ragionare in termini di Porte e non di Motori, come ora. Un po' come l'Hub Powered Up: "Port A" e "Port B". Porte sulle quali ci si potrà collegare un motore, un LED, un servo o un qualsiasi altro dispositivo pilotabile in PWM. Altra cosa da aggiungere è la modalità Combo: due motori controllati contemporaneamente come se fosse uno solo, per movimentare treni più pesanti. Se avete altri suggerimenti/idee, fatevi sotto!

Vorrei precisare meglio questo aspetto... le due opzioni sono per chi vuole un prodotto finito, e di dimensioni contenute. C'è una terza opzione che è quella di tralasciare il discorso dimensione/estetica del package e realizzare quindi un circuito "volante" o con un package che non sia "LEGO System Compatible"

Nella folder ESP8266_to_PF_MQTT del repository di ATS, @pivan ha pubblicato uno sketch, già testato con ESP8266, per gestire via MQTT anche i ricevitori IR Power Function 1.0. WhatsApp Video 2020-05-04 at 00.06.19.mp4

Laurens mi ha "sbugiardato" E' tutto basato sul timing: i due hub dispongono di due distinti programmi con tempestiche di esecuzione precise e vengono lanciati nello stesso momento... quindi, in un video che dura 50 secondi, in sincronismo funziona alla perfezione La comunicazione tra hub sarà una cosa che arriverà parecchio più avanti.

Ok, la mia tesi non è valida: accade solo se la head presenta un disegno... Anzi, ruotando la testa in modo che le caratteristiche della faccia siano laterali, si notano ulteriori difetti del modello:

Ce l'hai una minifigure sottomano? Osservala... io ce l'ho, ma non riesco a fotografare il 'difetto' con lo smartphone.

Potete partire da queste grafiche in formato SVG: http://jpgerdeman.github.io//minifig-svg-decals/ Su Google, cercando con "LEGO decal" si trovano un sacco di immagini dalle quali partire. Anche se non sono in vettoriale, basta uno dei tanti programmi (io uso Inkscape) per vettorizzarle. Questo è un esempio: a destra c'è un'immagine .jpg dal quale ho ottenuto la vettorizzazione (a sinistra). A quel punto, si può procedere con le varie modifiche...

Si, ma la qualità del rendering non è "photoreal". Sono sempre più convinto che non si tratti di difetto ma di una corrispondenza con il reale. L'effetto, tra l'altro, cambia molto anche a seconda delle impostazioni della luce (e dell'angolazione) della minifigure:

Confermo il "difetto"* (vedi nota a fondo pagina): D'altra parte, si nota anche in progettazione che c'è qualcosa di strano (diversa tonalità di giallo) Il problema, inoltre, è più evidente su alcune 'facce', ovvero è in funzione dell'area grafica occupata. ...siamo sicuri che sia un difetto e non una estremizzazione della realtà? (del resto, la modalità è Photoreal): prendi una minifigure e osservala attentamente. Quell'ombra la puoi notare anche su un oggetto reale, a secondo dell'angolo di osservazione.

Nel frattempo, ieri sera hanno pubblicato un nuovo video dove viene evidenziata la comunicazione tra due Hub:

Si, giusto.

Ammetto che anch'io mi son stufato di vedere le varie repliche-copia di quelle di Isogawa, ma non si può nascondere che in alcune c'è della vera creatività. Colgo l'occasione per segnalare la più piccola versione (solo 12 pezzi):

Ultimamente ho interloquito spesso e volentieri con Philo Hurbain, un AFOL francese abbastanza noto nella community mondiale per il disegno di svariati pezzi per LDraw e per lo studio approfondito di tutti gli elementi elettrici/elettronici prodotti da LEGO. Philo, inoltre, è anche uno degli altri 5 AFOL che oltre a me stanno testando le primissime versioni del firmware Pybricks. È una persona che abbina creatività e tecnica, e questi due moduli GBC sviluppati in questa settimana per il contest organizzato da FreeLUG, ne sono una dimostrazione Istruzioni disponibili qui: https://rebrickable.com/mocs/MOC-41488/Philoo/table-top-small-ball-contraption/#info e qui: https://rebrickable.com/mocs/MOC-41070/Philoo/sysiphus-pyramid/?inventory=1#info

Si, in effetti hai ragione: potrebbe essere una valida alternativa.

Per chi fosse interessato ad un controller WiFi per pilotare i motori LEGO, ma non è in grado di costruirselo in autonomia, può optare per due strade: 1) Acquistare il controller della 4DBrix, al costo di 32 euro l'uno; 2) Attendere che finiamo la progettazione del nostro controller. A quel punto, potremo fare una evantuale valutazione sul costo "vivo". Nel caso di scelta dell'opzione 1), sappiate comunque che il firmware di ATS potrà girare benissimo anche sul tale controller, benché differenzierà per il fatto che ha solo una porta per il motore. Se siete curiosi di vedere com'è fatto al suo interno, ecco alcune foto: Hanno usato direttamente una dev-board D1 Mini che ha lo svantaggio di avere delle dimensioni più generose, ma ha il vantaggio di avere l'interfaccia seriale-USB per poterlo aggiornare con più facilità. Sul controller ATS dopo il primo flash (con un banale adattatore USB-TTL) gli aggiornamenti potranno essere fatti direttamente via OTA (via WiFi, insomma...) Come driver del motore hanno optato per un mono-canale L9110Hne quindi, come ho già anticipato, può pilotate un solo motore. Hanno però previsto un pin di uscita (più la tensione) per controllare qualcosa di esterno... anche con la (sola) trasmissione di dati in formato seriale. Sinceramente, non ne vedo una grande utilità ma chi è smanettone può immaginare possibili integrazioni con dispositivi non wireless. Io ne ho acquistati due, più per la curiosità di vedere come erano stati realizzati... ritengo che non siano male, ma io nostro "prodotto" sarà migliore Concludo con le foto di dettaglio del connettore, anch'esso stampato in 3D (in due parti, poi incollate tra loro dopo aver inserito il cavo):

Dallo schema, alla pratica Ecco i dettagli del primo prototipo che ho realizzato qualche mese fa e che ho leggermente rivisto in questi ultimi giorni. È un prototipo i cui componenti sono saldati tra loro senza una PCB di supporto, usando direttamente le break-out board usate per gli "esperimenti". Questi sono i componenti: Un cavetto 8886, un ESP8285 (identico all'8266 come caratteristiche, ma con un package più piccolo), un regolatore AMS1117 e, infine, il driver 8833. Ecco il dettaglio delle 3 schede: Inizialmente, l'AMS1117 l'ho usato sulla sua PCB che, tra condensatori e spessore della PCB stessa è quasi più massiccio dell'ESP8285. Successivamente ho deciso di ottimizzare l'ingombro è l'ho dissaldato dalla sua scheda, posizionandolo direttamente sul retro della PCB del driver. Ecco alcune foto di dettaglio: Come si nota dalle immagini, il cavetto 8886 l'ho reciso proprio su bordo ed ho saldato sulla parte sottostante un cavetto a due poli che va ovviamente sull'uscita del driver. Ho poi realizzato un "piccolo" case con brick & plate: E questo è il risultato finale: Ovviamente, le dimensioni non sono propriamente contenute, dato che il tutto è un 4x5, alto 2 brick e 2 plate, più un ulteriore plate per il connettore. Questo è il confronto con un SBrick Plus (a sinistra) e il controller WiFi della 4DBrix (a destra): In realtà, la versione definitiva (che, tra l'altro, prevede due uscite anziché una) sarà molto più simile allo SBrick. Ecco qui il raffronto con il primissimo prototipo di case, progettato da @pivan all'interno del quale andrà la stessa elettronica, ma con una PCB progettata da @Valter1966 sul quale i componenti troveranno una posizione più decente: Alla fine, il "prodotto" che uscirà fuori sarà un box 4x4x2 (quanto lo Sbrick) che avrà già integrate le due porte di uscita. Ecco un raffronto tra il prototipo realizzato con i brick e la versione 3D printed (non prestate caso alla qualità di stampa che, in questo caso, è grezza):

Negativa per quale motivo? Per l'attrito?

Laurens mi ha appena comunicato che hanno integrato nel firmware la possibilità di caricare un programma di default nella memoria dell'Hub. Inoltre, anche l'editor di codice è stato ulteriormente migliorato e reso più semplice nella gestione dell'Hub. Al momento ancora non hanno rilasciato la nuova versione, ma penso sia ormai questione di giorni...