Jump to content

Tutta l'attività

Questo flusso si aggiorna automaticamente     

  1. Ieri
  2. Settimana scorsa
  3. Ho deciso di cambiare nome a PU Trains, trasformandolo in ATS SmartApp dato che, via via, l'App sta diventando una sorta di mini sistema ATS ed ho già pensato anche a come integrarlo, in un prossimo futuro, con il "fratello maggiore". Ad oggi, ATS SmartApp può controllare fino a 4 Smart Hub PU e fino a 8 device connessi alle rispettive porte. Può funzionare in modalità manuale, controllando l'output di motori e luci, oppure in modalità "sequencer" ovvero eseguendo una lista di comandi che prevedono anche la lettura dello stato di uno o più sensori Boost (distanza/colore) al fine di determinare le azioni da intraprendere. Al momento non abbiamo molte informazioni al riguardo, ma sappiamo che il nuovo set STEAM Spike (che usa la stessa "architettura" Powered Up) prevede l'espansione del sistema mediante sensori personalizzati. In un prossimo futuro, quindi, hardware e firmware dello Smart Hub ci consentiranno di integrare sensori magnetici, di tocco e, non di meno RFID. Torniamo ora alla descrizione della funzionalità di ATS Smart Hub. Al momento, la funzionalità manuale di controllo dei motori prevede che il motore (non importa di quale tipo) sia connesso alla *Porta A* dello Smart Hub e che il sensore o la luce LED siano connessi alla *Porta B*. Nella modalità Sequencer invece ci sarà la massima versatilità di configurazione, nel senso che sarà possibile utilizzare qualsiasi porta/device. Ad esempio, si potrà configurare uno Smart Hub con due sensori di colore/distanza, che agisce semplicemente da "rilevatore di passaggio/posizione" e, parallelamente, configurare un altro Smart Hub con 2 distinti motori che (ad esempio) agiscono su un passaggio a livello e uno scambio, o su due scambi. Gli altri due Smart Hub potranno invece comandare motore+luci di due distinti treni. La novità del sequencer è l'introduzione del comando SENS[hub] (dove 'hub' è il numero dell'hub al quale è connesso il sensore) che blocca l'esecuzione della sequenza fintanto che non viene rilevato un ostacolo. È configurato per rilevare un ostacolo a 3-4 cm. Ovviamente tenete a mente che la velocità di "rilevamento" non è particolarmente alta quindi, a secondo che utilizziate il sensore a bordo treno, o lungo il tracciato ferroviario, dovete realizzare un opportuno "ostacolo". Nella prossima release, troverete anche SCOL[hub][color] ovvero la possibilità di attendere il rilevamento di un determinato colore. Vi faccio un esempio "pratico" di cosa si può fare con il sequencer... Prendete due treni, ognuno dotato di un Hub con motore sulla Porta A e sensore di distanza sulla Porta B. Per semplificare la spiegazione, assumiamo che i treni siano posizionati su due tracciati ferroviari indipendenti. Il sensore è montato perpendicolarmente rispetto alla direzione di marcia del treno. Lateralmente ad entrambi i tracciati c'è un "ostacolo" costituito da un muretto di brick alto abbastanza per entrare nel raggio di azione del sensore. Usiamo questa sequenza: GF190 WAIT2 SENS1 STOP1 GF290 WAIT2 SENS2 STOP2 GF190: Avvia il motore collegato alla Porta A dell'Hub 1, al 90% di velocità. WAIT2: Aspetta due secondi prima di eseguire il successivo comando SENS1: Aspetta che il sensore (collegato alla Porta B dell'Hub 1) sia "attivato" da un ostacolo. STOP1: Ferma il motore dell'Hub 1 GF275: Avvia il motore collegato alla Porta A dell'Hub 2, al 75% di velocità. WAIT2: Aspetta due secondi prima di eseguire il successivo comando SENS2: Aspetta che il sensore (collegato alla Porta B dell'Hub 2) sia "attivato" da un ostacolo. STOP2: Ferma il motore dell'Hub 2 Se questa sequenza viene eseguita in loop (altra novità di questa versione dell'App: una sequenza può essere eseguita una sola volta, oppure in loop) avremo il risultato che il primo treno parte e percorre il circuito fino al punto di stop. A quel punto si ferma, e parte il secondo treno che, a sua volta, percorre il circuito fino al suo punto di stop. Dopodiché si ferma, e riparte il primo treno. Se ci riflettete bene, ci sono svariate configurazioni che possono essere combinate tra loro al fine di ottenere un movimento più dinamico dei treni anziché il solito treno che circola all'infinito senza sosta. Gli unici veri limiti con i quali potremmo avere a che fare sono: - La durata delle batterie - La lunghezza dei cavi dei motori/sensori - Il numero di dispositivi BLE (Bluetooth Low Energy) collegabili allo smartphone Android che funzionerà da "Centrale di controllo". Infatti, come ho già detto in un post precedente, alcuni smartphone, non sono in grado di connettersi a più di 3 dispositivi BLE. Il mio Huawei P20 Lite è uno di questi, mentre il Samsung di mia moglie (pagato meno della metà del mio P20) ne supporta tranquillamente 4 (e forse anche 1 o 2 in più). Cosa manca, oggi, ad ATS SmartApp e che implemeterò nei prossimi giorni? - Identificazione della versione del firmware; - Visualizzazione dello stato delle batterie, con eventuali avvisi in caso di scarsa energia e l'interruzione della sequenza di comandi (se attiva); - Modifica del nome dello Smart Hub (così come si può fare dall'App ufficiale LEGO); - Lo spegnimento istantaneo di tutti gli Smart Hub connessi; - L'accoppiamento di due motori identici sullo stesso Smart Hub (per funzionare come fossero un solo motore con doppia potenza) con la possibilità di settare le direzioni per singolo motore; - L'accoppiamento di due Smart Hub, come fossero un solo Smart Hub (utile per pilotare treni con due motori posizionati nella motrice di testa e di coda); - L'esecuzione di suoni (sullo smartphone) in base a determinati eventi; - Il controllo remoto dell'App da un altro smartphone (per controllare più App parallele su grandi diorami). - Loop e flussi condizionali personalizzati nello script editor del sequencer. Vi ricordo che ATS SmartApp è utile anche al di fuori dell'ambito "ferroviario", ovvero in qualsiasi MOC dove avete bisogno di una gestione più complessa del semplice "motore che gira continuamente". La versione aggiornata potete scaricarla dal link presente nel primo messaggio di questa discussione
  4. 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
  5. Greenlamia

    Studio

    Io uso pc e ce l'ho... probabilmente hai ragione, la scheda grafica non è rilevata o supportata... strano però, in quel caso mi aspetterei di vedere l'opzione ma non poterla selezionare piuttosto....
  6. ravescat

    Studio

    Non è che per caso uno usa la versione Mac e l'altro quella per PC? Nella versione PC confermo che nemmeno da me c'è
  7. pivan

    Studio

    ........se ti dico che non c'è....!
  8. Concordo... e poi dai se li guardate bene non potete dire che il vecchio era meglio.
  9. Anni luce meglio il nuovo Yoda. Adoro la possibilità del cambio di espressione. Da avere
  10. 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:
  11. Arrow

    Studio

    File - Render Image A sx hai la costruzione, punti a dx col mouse e scorri in basso. Device - Render using CPU GPU
  12. pivan

    Studio

    mi faresti quando hai tempo una screenshot dell'opzione? Non la trovo nel pannello e secondo me è la conferma che la mia scheda video (una vechia radeon hd7700) non è supportata..grazie!
  13. Ecco spiegata l'espressione del divino maestro Yogurt... era presente alla riunione al momento della decisione del prezzo di vendita
  14. Anche una semplice polybag può riservare interessanti soprese...
  15. Rumors parlano di 99,99 euro, ma un set da 1771 pezzi, con licenza Star Wars, dubito potrà costare meno di 140/160 euro. Soprattutto se "etichettato" UCS.
  16. Confronto tra i due: trovo interessanti entrambi le versioni ma, se dovessi scegliere, preferisco la prima edizione. Fortunatamente non ho il problema di dover scegliere Vecchio UCS Nuovo UCS
  17. Inquietante.. Sembra in gremlins, se lo bagni si duplica?
  18. 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.
  19. "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.
  20. Gozer

    LEGO è meglio di LEPIN?

    @Laz , @GianCann o chi altro ha notizie del lancio del lead user lab? Passato da 21 giorni il primo agosto sono troppo curioso di vedere questa nuova piattaforma
  21. Interessante. Non c'è nessuna NDA, quindi, da parte di TLG. L'ipotesi che possano essere dipendenti LEGO è effettivamente plausibile. Prima o poi, a questo punto, si verrà a sapere... certo sarebbe veramente singolare come situazione, nel caso venisse confermata l'ipotesi avanzata dai due ambassador.
  22. Hasan ha scritto qualcosa a riguardo sulla LAN. Lo riporto sotto. E un paio di altri ambassador sono giunti subito alla molto semplice e probabile conclusione: chi ha inviato i progetti è un dipendente LEGO. Il che è ovviamente vietato. Although questions haven't directly come in via LAN, I can understand there are some questions about the recent archival of the two LEGO Ideas 10K Club submissions Japanese Tea Gardens and Gravity Falls Mystery Shack. It's incredibly rare that we make the decision to remove submissions that have achieved the 10,000 supporter milestone and to not allow them through to the review stage. Unfortunately, after a thorough evaluation we made the tough decision (because we can clearly see that both models are incredibly well built) that in these two cases we had to do this as the submissions did not comply with our Terms of Service. We couldn't, in respect to the LEGO Ideas community, move the submissions into the review stage as well as award prizes, whether the main prize or the consolation prize, to the members in question. Although we know that you're all very interested in knowing the specific underlying reasons for why we decided to archive them, this is not information that I can share with you out of respect for the privacy of the members in question. Should the members in question choose to share the reason for the archival of their submissions, then they are welcome to do so
  23. La GETCOO ha annunciato ufficialmente che il progetto verrà lanciato ad ottobre, tramite la piattaforma Kickstarter.
  24. Ciao! No,studio.io che io sappia non supporta questa funzione... Ti conviene tenere i disegni come riferimento, magari sovrapposti a una griglia che simuli gli stud, stampata o su pc è indifferente...
  1. Carica più attività
×
×
  • Crea nuovo...