Jump to content
Laz

LEGO PoweredUp! (aka power functions 2.0)

Post raccomandati

Tornando al discorso cavetto, non è ancora chiaro cosa deciderà di fare TLG

IMG_20190530_131101.jpg

È chiaro che il sistema PU è fortemente diverso, in termini di connettività, rispetto al PF e non solo per la forma fisica del connettore. C'è il rischio, infatti, che un utilizzo errato del cavetto possa danneggiare l'hub.

Al di là del cavetto di compatibilità PU/PF, sono curioso di sapere cosa se metteranno in vendita per un cavetto di prolunga, perché gli attuali 25 cm sono corti.

Condividi questo post


Link al post
Condividi su altri siti

Come ho già detto in qualche altro post io ho risolto a mio modo due problemi, il primo che riguarda le pile l’ho risolto collegando direttamente l’hub ad un trasformatore 9V, e il secondo che riguarda le prolunghe si è risolto di conseguenza allungando ed accorciando a piacimento il cavo che va all’hub. Certo in questa maniera (nel mio caso) mi tocca avere un hub per ogni MOC che voglio comandare però in assenza di altra soluzione per ora mi sono arrangiato così. 

Ultima modifica: da Toretto1981

Condividi questo post


Link al post
Condividi su altri siti

Intervista davvero molto interessante. Speriamo a questo punto che lo standalone diventi realtà al più presto. Grazie mille @Laz per questa intervista e per la traduzione (e grazie anche a chi altro se ne sia occupato ovviamente).

Condividi questo post


Link al post
Condividi su altri siti

Dall'intervista di @Iry e @Laz emergono alcuni aspetti interessanti, benché molte risposte sono un "vedremo in futuro".

Tra tutti, la modalità "standalone" che è quella sulla quale abbiamo discusso anche con @Pix in queste pagine: ovvero la possibilità di preimpostare (programmare) un comportamento di default su nostre specifiche istruzioni.

D'altra parte, sapevamo già (vedete uno dei miei precedenti post) che l'hardware ha le caratteristiche per supportare una funzionalità di "comportamento di default" e tutto dipende solo dal firmware e da come (e quando) TLG vorrà implementarlo.

Che sia una questione di tempo, alla fine, lo ammettono anche loro: prima o poi qualcuno scoprirà il modo di sostituire il firmware (così come già accaduto per l'EV3) e quindi, tanto vale che siano loro ad integrare questa funzionalità.

È anche comprensibile la scelta di un connettore proprietario che non consenta problematiche di alcun tipo (connettendo dispositivi non compatibili) e, soprattutto, che sia "compliant" con le geometrie/dimensioni del "Sistema LEGO".

Mi lascia un po' sorpreso il fatto che non abbiano già pensato ad un cavo di PROLUNGA (non parlo di quello di conversione) utile soprattutto in alcuni scenari, tra cui i treni "pesanti". Quantomeno, dall'intervista, sembrerebbe che non abbiano valutato la possibilità di connettere due "train motor" a distanza...

Sulle dimensioni del PU Hub, in effetti, non hanno torto: tutto è stabilito principalmente delle batterie. Aver integrato i connettori all'interno  per una questione di design e di funzionalità, "ruba" senz'altro spazio ma rende tutto più compatto ed evita la presenza di un componente aggiuntivo (come l'IR Receiver).

Veniamo al nodo principale: il cavo di conversione. Le problematiche a cui loro accennano (richieste di conversione per varie funzionalità) e la filosofia che se loro devono far qualcosa, deve poter far tutto, mi lascia un po' perplesso.

Nel 99% dei casi, il cavo di conversione servirebbe solamente per poter integrare i motori già esistenti. Nel sistema PF, infatti, non esistono sensori o altri oggetti "intelligenti" che richiedo chissà quale logica di interfacciamento con protocolli o livelli di tensione diversi.

Dato che, come hanno confermato, ci stanno ragionando, mi auguro che tra qualche mese (spero non anni) si possa vedere qualcosa... nel frattempo, ho acquistato 3 luci LED PU solamente allo scopo di avere cavo+connettore e realizzarmi in casa il mio "PU to PF Cable" 😉

Altra chicca interessante che emerge dall'intervista, è la possibilità di pilotare il CONTROL+ dal telecomando PU. La domanda che mi pongo è, a questo punto, come diavolo farà a controllare 4 porte avendo solo 2 attuatori? Si potranno connettere due telecomandi ad un CONTROL+?

Sono stati un po' "fumosi" sulla possibilità di controllare due (o più) HUB dall'App. La cosa non mi quadra, dato che il nuovo 42100 usa due CONTROL+ e quindi tale possibilità dovrebbe essere già pronta.

Probabilmente è solo una questione di come implementare la gestione di più HUB dalla sezione "progettazione" dell'App.

Problema che hanno risolto diversamente all'interno dell'App specifica di controllo delle funzionalità del 42100 che, da quel che si vede nel video di Zusammecomesichiama pare essere veramente una figata 😉

Una cosa è certa: le potenzialità del nuovo ecosistema Powered Up sono molte. C'è da aspettare, adeguarsi e sperare che soddisfino almeno una parte delle esigenze di noi AFOL.

La disponibilità che il team PU ha dato (tramite la LAN) di ricevere i nostri feedback è un aspetto importantissimo. Speriamo se ne vedano i frutti nei mesi a venire...

Condividi questo post


Link al post
Condividi su altri siti

Io spero che davvero implementino il lato Treno, ma dalle domande di @Laz e dalle loro risposte sembrerebbe di si, ma ho visto molto il discorso improntato su quello. @Laz sembrerebbe che dopo tanti anni han preso a cuore il tema treni, che sensazione hai avuto di persona?

Condividi questo post


Link al post
Condividi su altri siti

Sembravano sinceramente interessati, anzi, sembrava il loro interesse principale, in realtà

Forse non sono del tutto esperti sui treni (come sulla questione dei due motori), ma sembravano molto interessati a diventarlo.

Condividi questo post


Link al post
Condividi su altri siti

Nei giorni scorsi è stata rilasciato un nuovo aggiornamento dell'App PU che implementa un nuovo pannello di controllo per pilotare con due slider altrettanti motori:

PUPcontroller-1024x640.png

Sostanzialmente, è un'interfaccia grafica che implementa due slider (a sx e dx), 3 pulsanti (con le icone di un volante, semaforo, e di una serie di curve) e, per finire, due indicatori numerici.

Questi componenti visuali (non modificabili dal punto di vista del layout grafico, così come non modificabile è anche lo sfondo grafico) sono mappabili ad altrettanti blocchi di programmazione.

E, soprattutto, sono pensati principalmente per pilotare una macchinina, benché possiamo usarli anche per altri scopi.

Per default, quanto si crea un nuovo progetto e si aggiunge anche "l'interfaccia visuale", vengono creati appunto i blocchi di programmazione standard per pilotate un mezzo con due motori tramite i quali si gestisce la direzionalità (è molto simile al funzionamento dell'App della Batmobile PU)

PUPcontrollerInside1-1024x640.png

Notate la nuova tab colore... "teal".

Cliccando sulla nuova tab compaiono i nuovi blocchi specifici del layout grafico.

Screenshot_20190623-075542.jpg

Da sx a dx:

1 e 2: Controller slider (forniscono il valore dello slider in funzione della loro posizione)

3, 4, 5: trigger per i rispettivi 3 pulsanti

6, 7: restituiscono il valore visualizzato rispettivamente nei due "indicatori numerici" (identificati dagli indici "1" e "2")

8,9: impostano, da programma, il valore dei due slider (1 e 2)

10,11: impostano, da programma, il valore dei due indicatori numerici (1 e 2)

Ho notato che gli slider si auto-resettano nel momento in cui viene sollevato il dito dallo schermo... comportamento correrro, ma che potrebbe non essere ideale in alcune situazioni.

In un prossimo post (lo farò nel pomeriggio) entrerò nel dettaglio di come usare questi nuovi componenti.

Nel frattempo, vi evidenzio una spiegazione veloce del "codice" di default, zommando sugli stessi:

Vista complessiva:

PUPcontrollerInside1-1024x640.png

Gestione motori:

Screenshot_20190623-075542.jpg

Gestione indicatori numerici:

Screenshot_20190623-075557.jpg

Azionamento suoni dai rispettivi 3 pulsanti di comando:

Screenshot_20190623-075618.jpg

Condividi questo post


Link al post
Condividi su altri siti

Come promesso, seppur con un po' di ritardo, spiego più in dettaglio come usare la nuova funzionalità 'Remote Controller'.
In questa immagine ho 'fuso' la barra dei blocchi di programmazione con l'interfaccia del Remote Controller ed ho aggiunto delle frecce per indicare il rapporto di funzionamento:
blob.png

- I blocchi 1 e 2 restituiscono il valore dei rispettivi Slider 1 e Slider 2. Il valore che possono assumere gli slider è +100/-100 con autoreset al valore di default 0. In sostanza, se si trascina lo slider fino ad un certo valore, e si alza il dito, lo slider torna immediatamente a 0.
Più avanti mostrerò come modificare questo comportamento tramite un workaround, benché non sia perfetto al 100%.

Il loro uso è banalissimo. Nell'immagine qui sotto si può notare come la velocitià dei due motori connessi alle rispettive porte A e B venga controllata dal valore dei rispettivi Slider. Il blocco +/- serve ad invertire il senso di rotazione di uno dei due motori, presupponendo che gli stessi siano montati in modo speculare (tipico, in una macchinina)

blob.png

- I blocchi 3, 4 e 5 sono i trigger corrispondenti alle 3 icone-pulsanti centrali. Devono essere utilizzati in combo con il blocco "Esegui quando la condizione è vera". L'esempio qui sotto è chiarissimo: "Esegui il suono Clacson, tipo 6, quando viene premuto il pulsante con l'icona di un volante"

blob.png

- I blocchi 6 e 7, restituisco semplicemente il valore che è attualmente visualizzato nei rispetti 'Visualizzatori numerici 1-2' che sono posizionati al centro del controller. Allo stesso tempo, tali indicatori possono essere valorizzati con l'uso dei blocchi 10 e 11

In questa immagine si può notare come collegare la visualizzazione 'istantanea' del valore di uno slider, mostrandolo su uno dei due indicatori.

blob.png

- Infine, i blocchi 8 e 9 permettono di impostare, da 'programma' il valore/posizione dei rispettivi slider.
Ed è proprio grazie a questi blocchi, e all'uso di una variabile intermedia, che sono riuscito a modificare il comportamento dello slider consentendo un "trascina e blocca" su un particolare valore. Ho usato il seguente codice:
Screenshot_20190625-070403 (1).jpg

E' composto da due loop infiniti:
- quello superiore memorizza il valore dello slider 1 nella variabile 'a'. Con il valore contenuto nella stessa variabile, imposto il valore del slider. In linea di massima, questo consente di bloccare lo slider su un determinato valore. Nella realtà, bisogna attendere qualche frazione di secondo sul valore preferito per consentire al codice di funzionare.

- Il loop inferiore, invece, non fa altro che impostare la velocità del motore e uno dei due visualizzatori numeri sul valore memorizzato nella variabile 'a' in modo tale da avere non solo un'azione sul motore vero e proprio, ma anche una indicazione a schermo del valore memorizzato nella variabile 'a' ovvero il valore dello slider.

Mi rincuora il fatto che Yoshihito Isogawa abbia confermato, con un suo video, la mia stessa soluzione.

Come si può vedere, quindi, la nuova funzionalità 'Controller' è molto semplice da utilizzare e può servire soprattutto per la gestione di veicoli... si può senz'altro utilizzare anche per altri scopi ma finché non implementeranno il supporto multi-hub, resta un po' fine a se stessa. Speriamo anche che in un prossimo aggiornamento possano consentire un minimo di personalizzazione della grafica del controller...

Per ultimo, vi segnalo questa curiosità che, probabilmente, è un bug dell'App.
In alcune situazioni (ancora non ho determinato con esattezza quali) sulla barra dei blocchi appaiono 3 ulteriori blocchi di programmazione che, nella sostanza, fanno poco e nulla... semplicemente, se attivati, simulano l'effetto ottico della pressione di uno dei 3 pulsanti:
Nessuna descrizione della foto disponibile.

Se qualcosa non dovesse essere chiaro, chiedete pure 😉

Condividi questo post


Link al post
Condividi su altri siti

Chiedo una cosa: siccome ho uno smartphone Lumia che non voglio cambiare finché non muore di morte naturale (con buona pace di whatsapp e altre app) e quindi non mi faranno mai l'app, è in programma anche un modo per controllare i PU da pc come per i mindstorms? (scusate se è già stato detto ma non ho visto i video e le 5 pagine)

Condividi questo post


Link al post
Condividi su altri siti

Oggi ho giocato un po' con:

Mit App Inventor 2
un'estensione BLE per questa piattaforma
- Il protocollo Bluetooth del Powered Up
- 3 Hub Powered Up e altrettanti motori connessi alle porte A dei rispettivi Hub

Risultato: ne è uscita un'App per controllare fino a 3 treni dallo stesso smarphone 😄 😄😄

Ovviamente è un'accozzaglia di App, senza alcun controllo di errori/gestione delle disconnessioni e, fondamentalmente, mi interessava svilupparla solo per verificare la possibilità di collegare più Hub ad uno smartphone per poterli controllare contemporaneamente... e la cosa, ovviamente, funziona!

Per chi fosse interessato a crearsi qualcosa di 'personalizzato', può partire da questo articolo di Jorge Pereira.

Appena rendo un minimo presentabili (e soprattutto più solida l'App) la metterò a disposizione sul forum.

Screenshot_20190810-192612.thumb.jpg.7d15c1289fc8ef706029f1e5e8c26fc1.jpg

Edit: ho ri-aggiunto la foto che per qualche motivo non si vedeva...

Ultima modifica: da GianCann

Condividi questo post


Link al post
Condividi su altri siti

Stamani ho chattato un po' con il responsabile del firmware del Powered Up perché ritengo di aver scovato un possibile bug nella procedura di upgrade del firmware stesso... nel frattempo, mi sono venute in mente altre idee su come potrebbe essere sviluppato l'ecosistema PU (anche per superare alcuni limiti attuali) affinché diventi tutto più duttile e versatile per il mondo AFOL. Vediamo se qualcuna di queste verrà implementata 😉

Nel frattempo continuo con le mie sperimentazioni 🙂

Come al solito, il materiale per sperimentare non è mai abbastanza: oggi avevo bisogno di un secondo sensore di colore/distanza (magari anche un terzo) ma benché posseggo già diversi componenti, mi manca proprio quello che mi sarebbe stato più utile per gli esperimenti odierni 😞

IMG_20190818_145234.thumb.jpg.19f494b4d41653a54984a50239b60666.jpg

 

Condividi questo post


Link al post
Condividi su altri siti

In realtà non mi ha detto nulla di interessante o che già non sapessi. Sono io che gli ho evidenziato un problema in fase di upgrade del firmware che ho già riscontrato su 3 Hub (complessivamente ne ho 9) e che io sono riuscito a bypassare avendo, fortunatamente, più hub "vergini" da aggiornare. Approfondiranno la mia segnalazione...

Per il resto, spero di riuscire ad entrare tra i beta tester delle nuove versioni del firmware e dell'App.

Nel frattempo ho "esploso" l'Apk dell'App LEGO ed ho trovato i binari delle varie release del firmware:

IMG_20190819_071044.thumb.jpg.508b4a3baf8b0a08f250c7651f243a7a.jpg

La cosa interessante è la dimensione: poco più di 70Kb.

A questi, se non ho interpretato male quel poco di documentazione del protocollo LPW rilasciato a dicembre da LEGO, vanno aggiunti quelli dello stack radio.

In ogni caso, avanzano comunque "parecchi" Kb a disposizione per salvare nella memoria del dispositivo alcune sequenze di comandi definite dall'utente.

Il pulsante verde, in base allo stato del dispositivo e al modo/volte che viene premuti, può essere benissimo utilizzato per far entrare lo smart hub in modalità "autonoma" e lanciare l'esecuzione dei comandi precaricati.

Questo permetterebbe di usare lo smart hub senza necessità di uno smartphone o del suo controller manuale (il PU Remote).

Chiaramente, più di semplici sequenze temporali e/o controllate dallo stato di un sensore di colore/distanza non si può fare...

Per cose più articolate, sarà necessario comunque un "Gestore" esterno che sia in grado di pilotare più hub parallelamente.

La mia App PU Trains già implementa una funzionalità di sequencer multi-hub ed ho pensato che vale la pena estrapolare questa funzionalità in un'App separata e più specifica, nell'attesa di una futura versione dell'App ufficiale che implementi il multi-hub.

Preparate i vostri hub, motori e sensori per provarla a breve 😉

Condividi questo post


Link al post
Condividi su altri siti

"Spulciando" la documentazione del LEGO Wireless Protocol (aka LWP) c'è una parte della stessa che fa ben sperare per il futuro...

È quella che riguarda la possibilità di creare una rete di device (HUB) con uno tra essi che funzioni da 'master'.

https://LEGO.github.io/LEGO-ble-wireless-protocol-docs/index.html#h-w-network-commands

Infatti, *tutti* i comandi previsti dal LWP hanno un 'parametro' Hub ID (un byte, per ora necessariamente da impostare sul valore 0x00) che viene così descritto:

Hub identifier is needed when a Hub is connected as a bridge to a network formerly build without a SMART DEVICE. E.g. HUB A is connected to HUB B and HUB C is added. After a while the SMART DEVICE is connected to the network. HUB A is now acting as a Central for B and C while acting as a Peripheral to the SMART DEVICE. Data from B and C will be routed through HUB A.

Questa possibilità è molto utile, perché permette di espandere il numero di device collegabili ad uno smartphone (che, come ho già spiegato in precedenza, possono appunto avere dei limiti sul numero di HUB contemporanei).

Da ieri è in vendita in nuovo treno Disney e quindi è plausibile che a giorni venga rilasciata anche una nuova versione dell'App, sperando che la stessa includa nuove feature anche dal punto di vista del firmware.

Condividi questo post


Link al post
Condividi su altri siti
3 ore fa, GianCann ha scritto:

Da ieri è in vendita in nuovo treno Disney e quindi è plausibile che a giorni venga rilasciata anche una nuova versione dell'App, sperando che la stessa includa nuove feature anche dal punto di vista del firmware

CVD, sull'Apple Store è già disponibile da poche ore. Sul Google Play Store ancora nulla...

Sfortunatamente, questa nuova versione include solo il profilo del treno Disney, ma nessun aggiornamento del firmware dello Smart Hub.

Condividi questo post


Link al post
Condividi su altri siti

Nel proseguire la sperimentazione con il sistema Powered Up, finchè LEGO non deciderà di rilasciare ulteriori informazioni/documentazioni, bisogna lavorare di 'reverse engineering'.

Pertanto, dato che l'unico sensore "intelligente" è quello del Boost, ho deciso di aprirne uno, per analizzare l'elettronica e riuscire a capire se c'è modo di creare un sensore 'custom'. Nella documentazione del protocollo LPW, infatti, c'è una comando 'WriteDirect' che permette di inviare byte direttamente all'hardware connesso ad una delle due porte. Questo significa che (al 90%) c'è un comunicazione seriale che avviene tramite i pin 5-6 del connettore PU. Nei prossimi giorni proverò a fare qualche test con un adattatore seriale, benché dubito di riuscire a far nulla di buono, perchè c'è sicuramente un meccanismo di identificazione di un dispositivo dotato di seriale e un conseguente protocollo di handshaking...

Nel frattempo, allego alcune immagini per i più curiosi:

IMG_20190823_080958.thumb.jpg.e0f511879426d27af69599db9b759e32.jpg

IMG_20190823_075907.thumb.jpg.deb98843124b624fad1b81fc5adc3b06.jpg

Condividi questo post


Link al post
Condividi su altri siti

Ieri pomeriggio ho speso un'oretta per sperimentare qualcosa con un collegamento seriale.

Prima di mettermi al lavoro, ho scambiato qualche messaggio con Joege Pereira: già in passato aveva provato a "sniffare" la comunicazione seriale tra il Boost Move Hub e il sensore di distanza WeDo 2.0, oltre che con il motore esterno del Boost.

Sfortunatamente, com'era del resto prevedibile, senza la documentazione del protocollo wired è praticamente impossibile riuscire a scambiare dati via seriale. Speravo almeno di riuscire a scrivere qualche byte dall'Hub alla seriale utilizzando il comando WriteDirect, ma non c'è stato verso 😞

Però, almeno una cosa son riuscita a "portarla a casa"... ovvero essere in grado di intercettare un contatto aperto/chiuso e quindi avere la base per realizzare un sensore di tocco/switch magnetico (che poi è proprio il primo tipo di sensore che avevo in mente di realizzare).

Il tutto si basa sui messaggi di notifica che lo Smart Hub invia sul canale Bluetooth quando un dispositivo viene connesso/rimosso dalle porte dell'Hub.

Questa feature è interessante perché permette al sistema PU di adattarsi "dinamicamente" ai dispositivi che vengono collegati/disconnessi anche mentre l'Hub è accesso e di notificare questi cambiamenti ad una eventuale App o comunque ad un altro dispositivo smart (in futuro, se LEGO prosegue lo sviluppo in tal senso, sarà possibile avere reti di Hub interconnessi).

Ma come faccio a simulare il collegamento/disconnessione di un dispositivo e far scatenare i relativi messaggi? 

La risposta è molto banale: basta collegare tra di loro i pin 3 (gnd) e 5 (rx) del cavetto PU interponendo una resistenza (io ne ho utilizzata una da 220 ohm).

Se questo collegamento dura più di 400/500ms, lo Smart Hub genera l'evento "Dispositivo connesso". Quando il collegamento viene interrotto, viene generato il messaggio "dispositivo disconnesso".

Tenete conto che entrambi i messaggi contengono delle informazioni utili: hanno un byte che identifica qual'è la porta interessata dalla connessione/disconnessione e, soprattutto, il messaggio di "dispositivo connesso" include un byte che identifica il tipo di dispositivo... e il tipo di dispositivo viene modificato proprio grazie al valore della resistenza interposta tra i due pin.

È sufficiente intercettare e gestire questi due messaggi per implementare un sensore On/Off.

Sicuramente non è la miglior soluzione possibile, ma finché LEGO non rilascerà la documentazione (e la rilascerà, senza dubbio...) non si può fare molto altro.

Appena ho risolto il problema del "timing" della chiusura del contatto (devo fare un piccolo circuitino che a fronte di un micro contatto generi un impulso più lungo) entrerò nel dettaglio con lo schema e video di questo workaround.

P.S. Ovviamente ho provato a chiedere a LEGO se fosse stato possibile avere qualche informazione in più/piccola anticipazione sul protocollo wired. La risposta era scontata... ma ci ho comunque provato 😉

Condividi questo post


Link al post
Condividi su altri siti

Crea un account o accedi per commentare

Devi essere un utente registrato per postare un commento

Crea un account

Iscriviti per un nuovo account nella nostra community. È facile!

Registra un nuovo account

Accedi

Hai un account? Accedi .

Accedi ora

  • Visualizzato ora da   0 utenti

    Nessun utente registrato su questa pagina.

×
×
  • Crea nuovo...