Come abbiamo già accennato a maggio, le persone creano e utilizzano foto e video in molti modi diversi, quindi sosteniamo che sfruttarli meglio e farci ancora di più dovrebbe essere più semplice nell'ambito dei molti dispositivi e app che usiamo sempre. Ecco perché abbiamo prodotto l'API Google Photos Library, che offre la possibilità di creare esperienze di foto e video più intelligenti, veloci e utili all'interno dei tuoi prodotti.
Dopo un'anteprima di sviluppo ben accolta negli ultimi mesi, l'API Google Photos Library è ora disponibile per il pubblico. Se vuoi creare e testare la tua esperienza, inizia visitando la documentazione per sviluppatori. Puoi anche esprimere il tuo interesse aderendo al programma partner di Google Foto se stai pianificando un'integrazione più ampia.
Ecco una rapida panoramica dell'API Google Photos Library e come utilizzarla.
Sia che tu sia uno sviluppatore mobile, web o di backend, puoi utilizzare questa API REST per sfruttare il meglio di Google Foto e aiutare le persone a connettersi, caricare e condividere all'interno della tua app. Stiamo anche lanciando librerie client in diverse lingue che ti consentiranno di procedere più rapidamente.
Gli utenti devono autorizzare le richieste tramite l'API, in tal modo sono sempre al comando della situazione. Ecco cosa puoi aiutarli a fare:
Sfruttare il machine learning a vantaggio della tua app è semplice. Puoi utilizzare i filtri intelligenti, come le categorie di contenuti, per limitare o escludere determinati tipi di foto o video, e aiutare gli utenti a trovare più facilmente ciò che stanno cercando.
Ringraziamo tutti coloro che ci hanno fornito il loro feedback durante l'anteprima degli sviluppatori. Tutti i commenti ricevuti hanno contribuito a migliorare l'API. Sono disponibili le note sulla versione che accompagnano le nuove release della nostra API. Inoltre, se attualmente stai usando l'API Picasa Web Albums, ecco la guida alla migrazione che ti aiuterà a passare all'API Google Photos Library.
Recentemente ho fatto parte del fantastico team che ha lavorato all'app Android Google I/O 2018. È un'app complementare per conferenze che consente ai partecipanti e a chi si trova in remoto di cercare sessioni, creare programmi personalizzati e prenotare posti all'evento (se si ha la fortuna di essere lì!). Nell'app abbiamo sviluppato molte interessanti funzionalità animate che, a mio parere, hanno migliorato notevolmente l'esperienza utente. Il codice di questa app è appena stato reso open source e quindi vorrei segnalare alcuni dettagli e istanze di implementazione interessanti.
Ci sono 3 tipi di animazioni che abbiamo usato maggiormente nell'app:
Mi piacerebbe parlare più nel dettaglio di alcune di queste funzionalità.
Parte della funzione dell'app è creare entusiasmo e attesa per la conferenza. Pertanto, quest'anno abbiamo incluso un grande conto alla rovescia animato per marcare l'inizio della conferenza, visualizzato sia nella schermata di on-boarding sia nella sezione Info. È stata anche un'ottima opportunità per incorporare il marchio dell'evento nell'app dandole così più carattere.
Questa animazione è stata progettata da un motion designer e distribuita come serie di file JSON Lottie: ognuno di 1 secondo che mostra un numero animato in ingresso "in" e in uscita "out". Il formato Lottie ha semplificato il rilascio dei file in asset e ha persino offerto metodi convenienti come setMinAndMaxProgress che ci hanno permesso di riprodurre solo la prima o l'ultima metà di un'animazione (per mostrare un numero animato in ingresso o in uscita).
In generale è stato interessante gestire le varie animazioni del conto alla rovescia. Per ottenere questo obiettivo abbiamo creato una CountdownView personalizzata, che è un ConstraintLayout abbastanza complesso contenente diverse LottieAnimationViews. In questo caso abbiamo creato un delegato Kotlin per incapsulare l'avvio dell'animazione giusta. Ciò ci ha permesso di assegnare semplicemente un Int a ciascun delegato della cifra che doveva essere visualizzata e, a sua volta, il delegato eseguiva l'impostazione e l'avvio delle animazioni. Abbiamo esteso il delegato ObservableProperty per garantire che l'animazione fosse eseguita solo al variare della cifra. Quindi il nostro loop di animazione pubblicava un runnable ogni secondo (quando la visualizzazione era allegata) che calcolava la cifra da mostrare per ogni visualizzazione e poi aggiornava i delegati.
Una delle azioni chiave dell'app è consentire ai partecipanti di prenotarsi. Pertanto abbiamo messo questa azione in evidenza in un FAB nella schermata dei dettagli della sessione. Abbiamo ritenuto importante segnalare solamente che la sessione era stata riservata, una volta che l'operazione veniva completata correttamente sul backend (a differenza delle azioni meno importanti, come la valutazione di una sessione, per cui ottimisticamente l'UI veniva aggiornata subito). Ricevere una risposta dal backend poteva richiedere tempo quindi, per rendere il processo più dinamico, abbiamo creato un'icona animata per indicare che il processo è in corso e passare agevolmente al nuovo stato.
Il processo è complicato dal fatto che questa icona rappresenta diversi stati: la sessione che può essere prenotata, l'utente che può aver già prenotato, se la sessione è esaurita potrebbe essere disponibile una lista d'attesa o l’utente potrebbe essere già sulla lista d'attesa o, con l’avvicinarsi della sessione, le prenotazioni potrebbero non essere più disponibili. Ciò dà luogo a molte transizioni di stato da animare. Per semplificare queste transizioni, abbiamo deciso di passare sempre attraverso uno stato "in corso", ossia la clessidra animata mostrata sopra. Pertanto ogni transizione è costituita da una coppia di stati: stato 1 → in corso e in corso → stato 2. Questo approccio ha semplificato moltissimo le cose. Abbiamo creato ognuna di queste animazioni usando shapeshifter; vedi i file avd_state_to_state qui.
Per mostrare ciò, abbiamo utilizzato una visualizzazione personalizzata AnimatedStateListDrawable (ASLD). Se non hai mai usato ASLD, si tratta di una versione animata di StateListDrawable, come suggerisce il nome, che hai probabilmente già visto e consente, non solo di fornire diverse risorse drawable per stato ma anche transizioni tra stati (sotto forma di AnimatedVectorDrawable o AnimationDrawable). Ecco la risorsa drawable che definisce le immagini statiche e le transizioni in ingresso e uscita dello stato "in corso" per l'icona della prenotazione.
Abbiamo creato una visualizzazione personalizzata per supportare i nostri stati personalizzati. Le visualizzazioni offrono alcuni stati standard come Premuto o Selezionato. Analogamente, puoi definire il tuo stato e avere il Percorso di visualizzazione a tutte le risorse drawable mostrate. Abbiamo definito gli state_reservable, state_reserved ecc. Poi abbiamo creato un Enum dei diversi stati incapsulando lo stato della visualizzazione più eventuali attributi correlati, come la descrizione dei contenuti associati. La nostra logica business potrebbe semplicemente impostare il valore appropriato dall'Enum alla visualizzazione (tramite associazione dati) aggiornando lo stato della risorsa drawable che, a sua volta, ha avviato l'animazione tramite ASLD. La combinazione degli stati personalizzati e AnimatedStateListDrawable è stata un ottimo modo per implementare questo processo, mantenendo i diversi stati ai livelli dichiarativi e dando luogo a un codice di visualizzazione minimo.
Molte transizioni dello schermo funzionavano bene con le animazioni nelle finestre standard. La situazione era un po' diversa per la transizione nella schermata dei dettagli del relatore. Mostrava l'immagine dei relatori da entrambi i lati della transizione ed era una soluzione ideale per transizioni di elementi condivisi perché facilitava il cambio di contesto tra schermate.
Si tratta di una transizione di elementi condivisi standard che utilizza le classi ChangeBounds e ArcMotion della piattaforma su un ImageView.
L’aspetto più interessante è il modo in cui l'avvio di questa transizione si adattava al pattern Evento usato per la navigazione. In sostanza, questo pattern disaccoppia gli eventi di input (come l'azione di tocco di un relatore) dagli eventi di navigazione, incaricando ViewModel di rispondere all'input. In questo caso, il disaccoppiamento implicava che ViewModel esponesse un LiveData degli Eventi, che conosceva solo l'ID del relatore a cui indirizzarsi. L’inizializzazione di una transizione condivisa di elementi richiede la Visualizzazione condivisa che non avevamo a questo punto. Abbiamo risolto il problema memorizzando l'ID del relatore come tag sulla visualizzazione quando è associato, in modo che possa essere recuperato in un secondo momento per navigare verso una particolare schermata dei dettagli del relatore.
Una parte fondamentale dell'app per conferenze è filtrare gli eventi a cui siamo interessati. Ogni argomento viene associato a un colore per essere riconosciuto facilmente. Abbiamo anche ottenuto un ottimo design per il "chip" personalizzato da utilizzare per la selezione dei filtri.
Abbiamo preso in considerazione Chip di Material Components ma poi abbiamo optato per la nostra visualizzazione personalizzata che offriva un maggiore controllo sul display e sull'animazione tra i vari stati "selezionati". È stata implementata usando il disegno su canvas e uno StaticLayout per la visualizzazione del testo. La visualizzazione ha una singola proprietà di avanzamento [0-1] che indica la modalità selezionata-deselezionata. Per cambiare lo stato, il valore viene animato e la visualizzazione viene invalidata, consentendo al codice di rendering di interpolare linearmente le posizioni e le dimensioni degli elementi in base a ciò.
Inizialmente, durante l'implementazione, ho fatto in modo che la visualizzazione implementasse l'interfaccia Checkable e ho avviato l'animazione quando il metodo setChecked impostava un nuovo stato. Poiché si visualizzavano più filtri in un RecyclerView, ciò ha avuto lo sfortunato effetto di eseguire l'animazione se il filtro selezionato si spostava "out" e la visualizzazione veniva riassociata a un filtro non selezionato che si era spostato "in". Ops. Abbiamo quindi aggiunto un altro metodo per avviare l'animazione che ci permettesse di distinguere tra l'attivazione da clic e l'aggiornamento immediato quando si associavano nuovi dati alla visualizzazione.
Inoltre, quando abbiamo introdotto questa animazione toggle, abbiamo scoperto che si trattava di una procedura di janking, ovvero che comportava la perdita di fotogrammi. Era colpa del mio codice di animazione? Questi filtri sono visualizzati in un BottomSheet davanti alla schermata del programma principale della conferenza. Attivando un filtro, avviamo la logica del filtro da applicare al programma (e aggiorniamo il numero di eventi corrispondenti nel titolo del foglio del filtro). Dopo un'analisi approfondita di systrace abbiamo individuato il problema, ossia che quando i filtri venivano applicati, il ViewPager di RecyclerViews, che mostrava il programma diligentemente, si attivava e aggiornava in base ai dati appena forniti. Ciò determinava l'ingrandimento e l'associazione di diverse visualizzazioni. Tutto questo lavoro stava facendo saltare il budget dei fotogrammi... ma il programma di aggiornamento non era visibile perché era nascosto dal foglio del filtro. Abbiamo deciso di ritardare l'utilizzo del filtro vero e proprio fino a quando non veniva eseguita l'animazione, e quindi abbiamo rinunciato a una maggiore complessità di implementazione a favore di un'esperienza utente più fluida. Inizialmente ho implementato questa funzionalità usando PostDelayed ma ciò ha causato problemi durante i test dell'UI. Invece abbiamo cambiato il metodo che ha avviato l'animazione per accettare un lambda da eseguire alla fine. Ciò ci ha permesso di rispettare meglio le impostazioni di animazione dell'utente e testare correttamente l'esecuzione.
Nel complesso, penso che le animazioni abbiano davvero contribuito all'esperienza, al carattere, al branding e alla reattività dell'app. Speriamo che questo post abbia contribuito a spiegare sia il motivo sia il metodo utilizzati, e a fornirti buone indicazioni su come implementare le animazioni.
Animazione in un programma è stato originariamente pubblicato su Android Developers del blog Medium, utile per continuare la conversazione e offrire feedback su questa storia.
Attualmente Crashlytics elabora più di 3 miliardi di eventi al giorno per i nostri sviluppatori e li distilla in una serie di problemi strategici e actionable nel dashboard. Nel corso degli anni abbiamo ricevuto migliaia di richieste relative a come conoscere meglio i dati di arresto anomalo, ed è per questo che ora siamo particolarmente lieti di offrirti la possibilità di esportare i dati Firebase Crashlytics in BigQuery per un'analisi più approfondita!
Con pochi clic nel dashboard di Firebase Crashlytics puoi abilitare le esportazioni giornaliere di tutti i dati raw di arresto anomalo in base all'app o al progetto. Ciò include le tracce dello stack, i registri, le chiavi e qualsiasi altro dato di arresto anomalo.
Il dashboard Crashlytics conserva i dati per 90 giorni. Con BigQuery possiedi le politiche di conservazione e cancellazione che consentono al tuo team di monitorare più facilmente le tendenze dei dati di stabilità anno dopo anno.
BigQuery offre anche la possibilità di esportare dati in formato CSV, JSON e Avro. Ciò contribuirà a semplificare qualsiasi richiesta di estrazione dati GDPR che potresti ricevere.
Fino a ora, la visibilità nei report sugli arresti anomali tramite metadati personalizzati, come Experiment ID o un breadcrumb Analytics, è stata limitata, rendendo difficile l'identificazione delle varianti con minore stabilità in un esperimento o il livello di gioco con il maggior numero di arresti anomali. Ora, quando esporti i dati in BigQuery, è facile eseguire tutte le analisi approfondite che desideri per poi visualizzare il report con Data Studio o qualsiasi altro sistema aziendale utilizzato.
Ad esempio, supponi di configurare il tuo gioco Android in modo da poter registrare a quale livello avviene l'arresto anomalo con:
Crashlytics.setInt("current_level", 3);
Quando esporti i tuoi dati Crashlytics in BigQuery, puoi visualizzare la distribuzione degli arresti anomali per livello grazie a questa query:
#standardSQL SELECT COUNT(DISTINCT event_id) AS num_of_crashes, value FROM `projectId.crashlytics.package_name_ANDROID`, UNNEST(custom_keys) WHERE key = "current_level" GROUP BY key, value ORDER BY num_of_crashes DESC
Se sei già un utente Fabric, puoi accedere all'esportazione BigQuery e a tutte le altre funzionalità di Firebase, collegando la tua app al dashboard Fabric. Dai un'occhiata a questo link per scoprire ulteriori dettagli e consultare la documentazione.
Speriamo che questo miglioramento renda ancora più facile l'accesso ai dati dei tuoi report sugli arresti anomali e al debugging efficace della tua app! Come sempre, se hai domande, puoi trovarci su Twitter e su Stack Overflow. Buon debugging!
Pubblicato da Alex Wiltschko, Dan Moldovan, Wolff Dobson
Oggi vorremmo presentare la nuova funzionalità di TensorFlow chiamata "AutoGraph". AutoGraph converte il codice Python, tra cui il flusso di controllo, print() e altre funzionalità native di Python, in puro codice grafico TensorFlow.
Scrivere il codice TensorFlow senza utilizzare Eager Execution significa eseguire un po' di metaprogrammazione, ossia scrivere un programma che crea un grafico che a sua volta viene eseguito successivamente. Ciò può creare confusione, specialmente per gli sviluppatori nuovi. In particolare in alcune situazioni difficili che riguardano i modelli più complessi, come quelli che usano if e while o quelli che hanno effetti collaterali come print() o accettano input strutturati.
Abbiamo davvero bisogno di grafici? I grafici consentono tutti i tipi di ottimizzazioni, come la rimozione di espressioni secondarie comuni e la fusione dei kernel. Inoltre, semplificano l'addestramento distribuito e l'implementazione in tutti i tipi di ambienti, poiché formano un modello di calcolo indipendente dalla piattaforma. Questo è particolarmente importante per l'addestramento distribuito su GPU o TPU multiple o per la distribuzione del modello su altre piattaforme, come IoT o mobile tramite TensorFlow Lite.
Ecco un esempio semplice di un'operazione che forse potresti aggiungere al tuo grafico:
def huber_loss(a): if tf.abs(a) <= delta: loss = a * a / 2 else: loss = delta * (tf.abs(a) - delta / 2) return loss
Con Eager Execution, l'esempio "funzionerà abbastanza bene" ma le operazioni potrebbero essere lente a causa dei costi generali dell'interprete Python o delle opportunità mancate di ottimizzazione dei programmi.
Per prepararci all'esecuzione del grafico, bisogna riscrivere il codice usando costrutti come tf.cond(), ma ciò può rivelarsi oneroso e difficile da implementare. AutoGraph può effettuare automaticamente questa conversione mantenendo la facilità di programmazione Eager e sfruttando al tempo stesso i vantaggi prestazionali dell'esecuzione basata su grafici.
Nell'esempio possiamo assegnare autograph.convert() alla nostra funzione in modo che AutoGraph generi automaticamente il codice pronto per il grafico.
Utilizzando AutoGraph, il codice:
@autograph.convert() def huber_loss(a): if tf.abs(a) <= delta: loss = a * a / 2 else: loss = delta * (tf.abs(a) - delta / 2) return loss
diventa questo codice in fase di esecuzione a causa dell'elemento Decorator.
def tf__huber_loss(a): with tf.name_scope('huber_loss'): def if_true(): with tf.name_scope('if_true'): loss = a * a / 2 return loss, def if_false(): with tf.name_scope('if_false'): loss = delta * (tf.abs(a) - delta / 2) return loss, loss = ag__.utils.run_cond(tf.less_equal(tf.abs(a), delta), if_true, if_false) return loss
Puoi quindi chiamare il tuo codice come se fosse un op TensorFlow:
with tf.Graph().as_default(): x_tensor = tf.constant(9.0) # The converted function works like a regular op: tensors in, tensors out. huber_loss_tensor = huber_loss(x_tensor) with tf.Session() as sess: print('TensorFlow result: %2.2f\n' % sess.run(huber_loss_tensor))
È da notare che AutoGraph colma il divario tra Eager Execution e i grafici. Prende il codice Python in stile Eager e lo converte in codice che genera grafici.
AutoGraph non è una semplice raccolta di macro utili: è uno strumento che usa la trasformazione del codice sorgente per consentire di sovrascrivere qualsiasi parte del linguaggio Python, inclusi controllo del flusso, applicazione della funzione, assegnazione, generazione di codice boilerplate e refactoring di Python idiomatico, per semplificare la trasformazione in grafici.
Una delle problematiche dei compilatori è la leggibilità dei messaggi di errore. A tal fine, AutoGraph è impostato per creare messaggi di errore e tracce di stack che rivelano la fonte dell'errore nel codice sorgente originale piuttosto che mostrare solo riferimenti al codice generato.
Come può aiutarti AutoGraph? Ecco alcuni esempi di codice che ora puoi trasformare direttamente in codice di grafico senza alcuna modifica. Per scoprire come funziona, consulta il nostro notebook in Colab o in GitHub.
Qui vediamo la Congettura Collatz che usa loop e rami. Nota che, per cambiare, al posto dell'elemento Decorator usiamo la funzione di AutoGraph .to_graph() che lo trasforma in grafico.
def collatz(a): counter = 0 while a != 1: if a % 2 == 0: a = a // 2 else: a = 3 * a + 1 counter = counter + 1 return counter graph_mode_collatz = autograph.to_graph(collatz) # The code is human-readable, too print(autograph.to_code(collatz)) collatz_tensor = graph_mode_collatz(tf.constant(n))
AutoGraph può supportare flussi di controllo annidati arbitrari, come ad esempio:
def f(n): if n >= 0: while n < 5: n += 1 print(n) return n
AutoGraph consente di aggiungere elementi agli array all'interno dei loop. Per eseguire questa operazione, usiamo gli helper di AutoGraph, set_element_type e stack.
def f(n): z = [] # We ask you to tell us the element dtype of the list autograph.set_element_type(z, tf.int32) for i in range(n): z.append(i) # when you're done with the list, stack it # (this is just like np.stack) return autograph.stack(z)
Supportiamo anche costrutti come break, continue e persino print e assert. Terminata la conversione, l'assert Python di questo snippet viene convertito in un grafico che utilizza l'appropriato tf.Assert.
def f(x): assert x != 0, 'Do not pass zero!' return x * x
Aggiungere facilmente ai grafici i loop, controllare il flusso e altro, significa che spostare il ciclo di addestramento nel grafico è semplice. Possiamo vederne un esempio in questo notebook dove prendiamo un ciclo di addestramento RNN e lo eseguiamo con una singola chiamata sess.run(). Questa operazione potrebbe essere utile quando è necessario passare l'intero loop di addestramento all'acceleratore, piuttosto che gestire l'addestramento tramite un controller della CPU.
AutoGraph offre nuovi modi di pensare alla creazione e all'addestramento dei modelli. Non vediamo l'ora di aggiungere ulteriori funzionalità ad AutoGraph in base ai suggerimenti della community degli sviluppatori, quindi ti preghiamo di segnalarci qualsiasi problema!
Eager execution è di facile utilizzo ma i grafici possono essere più veloci. Sebbene il benchmarking sia complesso (e dipende sia dall'applicazione che dalla configurazione hardware), in questo semplice esempio vediamo un significativo aumento della velocità quando passiamo dal codice Eager a quello AutoGraph, che fa grande uso di if e while.
In definitiva, AutoGraph consente di utilizzare i modelli dinamici e con controllo del flusso sull'hardware dell'acceleratore, come GPU e TPU Cloud, necessari quando addestriamo modelli di grandi dimensioni su molti dati.
Siamo agli inizi del processo di esplorazione delle prestazioni, quindi segnalaci qualsiasi problema se trovi un costrutto grafico che funziona più lentamente del previsto.
Anche se utilizzi Eager Execution, puoi comunque sfruttare l'esecuzione di grafici per alcune parti del codice tramite tf.contrib.eager.defun. Ciò richiede l'utilizzo di grafici TensorFlow ops come tf.cond(). In futuro AutoGraph sarà perfettamente integrato con defun per consentire la creazione del codice di grafico in puro Python stile Eager. Una volta completata l'implementazione, potrai utilizzare AutoGraph per accelerare gli hotspot trasformando selettivamente il codice Eager in frammenti di grafici.
AutoGraph è uno strumento che consente di creare facilmente modelli intuitivi e complessi, eseguibili senza difficoltà nei grafici TensorFlow. Per ora questo è uno strumento sperimentale in contrib, ma prevediamo di spostarlo presto nel core TensorFlow.
Raccontaci la tua esperienza con AutoGraph. Segnalaci qualsiasi problema e, se hai feedback, suggerimenti o idee, invia i tuoi messaggi al gruppo degli sviluppatori TensorFlow.
Ringraziamenti
Vogliamo ringraziare in modo particolare Andrew Johnson, Bart van Merriënboer, Zachary Nado e Alex Passos per il contributo fondamentale. E anche ringraziare i nostri colleghi: Akshay Agrawal, Mark Daoust, Josh Levenberg, Dougal Maclaurin, Rajat Monga, Mahima Pushkarna, Alexey Radul, D. Sculley e Asim Shankar.
In questa serie “Two Minute Actions”, prendiamo un’idea e spieghiamo il procedimento per implementarla come Action per l’Assistente Google utilizzando le potenti funzionalità di Actions on Google.
Non lasciar finire l'estate senza aver provato l’audio a esecuzione prolungata in spiaggia. Puoi farlo ascoltando ore di audio sul tuo altoparlante smart.
Abbiamo bisogno di un modo per riprodurre l'audio a esecuzione più prolungata sugli altoparlanti smart. Actions on Google ha un lettore multimediale che consente di riprodurre i file audio.
Per il contenuto puoi trovare migliaia di suoni gratuiti nella libreria audio di Actions. Ti consigliamo di provare alcuni dei suoni ambientali. Quindi, puoi combinare queste tracce audio per renderle lunghe abbastanza utilizzando un editor audio gratuito come Audacity o una utility come SoX. Queste tracce possono essere ospitate online con servizi come Cloud Storage for Firebase.
Se desideri creare una playlist di tracce audio, il lettore multimediale di Actions on Google ha una funzione particolare che richiama un callback dopo il completamento della riproduzione utilizzando l’intento ‘actions.intent.MEDIA_STATUS’. Puoi usarlo per invocare un altro giocatore e riprodurre la traccia successiva nell'elenco.
Per attivare l'Action, un utente può semplicemente richiamarla per nome. Ancora meglio, l'Assistente Google ha recentemente aggiunto una nuova funzionalità che consente agli utenti di pianificare le routine. È facile progettare la tua Action con un intento di attivazione che viene richiamato quando l'utente esegue la sua routine. Vai alla Console Actions per configurare l'azione e ricevere suggerimenti automatici di routine.
Un buon punto di partenza per l’Action è la creazione di una delle nostre Actions di esempio. Basta fare clic su questo link e in un minuto otterrai un agente Dialogflow funzionante con codice di fulfillment per riprodurre i file multimediali che puoi estendere per realizzare questa Action.
Ulteriori informazioni? Vai a vedere la community Actions on Google per discutere Actions con gli sviluppatori. Partecipa al programma community degli sivluppatori di Actions on Google per guadagnare 200 $ mensili in credito Google Cloud e una t-shirt dell’Assistente, quando pubblichi la tua prima app.
Pubblicato da Abe Haskins (Twitter, Github)
In questo articolo parleremo dell'utilizzo di Unity3D e TensorFlow per addestrare l'intelligenza artificiale a svolgere un semplice compito in-game: fare canestro. Il codice sorgente completo è disponibile su Github ma se hai delle domande, puoi contattarmi su Twitter.
Esiste un gioco in cui i giocatori hanno un obiettivo principale: mettere la palla nel canestro. Non sembra così difficile, ma quando il sangue pompa nelle vene, il cuore va a mille e la folla fa il tifo, beh, allora tirare bene è tutta un'altra storia. Sto parlando del classico gioco americano della pallacanestro? No, non ne ho mai sentito parlare. Mi riferisco al classico videogioco arcade NBA Jam di Midway.
Se hai già giocato a NBA Jam o a qualsiasi gioco a cui si ispira (inclusa la lega NBA vera e propria, che credo sia arrivata dopo NBA Jam), allora sai che la meccanica per tirare una palla dal punto di vista del giocatore è abbastanza semplice: tenere premuto e rilasciare il pulsante di tiro con un tempismo perfetto. Ti sei mai chiesto come si svolga questo tiro dal punto di vista del gioco? Come venga scelto l'arco effettuato dalla palla? Quanto sia difficile tirare la palla? Come faccia il computer a sapere da quale angolo tirare?
Se sei una persona intelligente, portata per la matematica, potresti trovare le risposte giuste usando semplicemente carta e penna, tuttavia l'autore di questo post è stato rimandato in algebra alle medie, quindi per lui le risposte da "cervellone" sono fuori questione. Dovrà risolvere il problema in modo diverso.
Invece di prendere la via più semplice, veloce ed efficiente per i calcoli su come eseguire un tiro, andremo a vedere quanto sia profonda la tana del coniglio, impareremo un po' di semplice TensorFlow e proveremo a fare questi benedetti canestri.
Ecco cosa ci serve per iniziare questo progetto.
Se non sei un esperto di queste tecnologie, non ti preoccupare (neanch'io lo sono!). Farò del mio meglio per spiegare come le diverse parti s'integrano tra di loro. Uno degli svantaggi di usare tante tecnologie diverse è il non poter spiegare tutto nel dettaglio, ma tenterò di offrire risorse educative supplementari!
Non cercherò di ricreare questo progetto passo per passo, quindi suggerisco di utilizzare il codice sorgente disponibile su Github e seguire la mia spiegazione.
Nota: è necessario scaricare un'importazione del pacchetto di asset Unity ML-Agents per Tensorflow da utilizzare in C#. Se ricevi il messaggio di errore che Tensorflow non viene rilevato in Unity, assicurati di seguire le istruzioni nei documenti sull'installazione di Unity per TensorflowSharp.
Per farla semplice, il risultato che ci interessa sarà incredibilmente semplice. Vogliamo sapere con quale forza Y dobbiamo eseguire il tiro se il giocatore è a distanza X dal canestro. Ecco fatto! Non proveremo a centrare la palla o niente del genere. Stiamo solo cercando di capire con quale forza deve lanciare la palla per fare canestro.
Se sei interessato a come realizzare AI più complesse in Unity, consulta ML-Agents, un progetto molto più completo di Unity. I metodi che spiegherò sono ideati per essere semplici, accessibili e non necessariamente indicativi delle best practice (sto imparando anch'io!).
La mia conoscenza di TensorFlow, del machine learning e della matematica è limitata. Quindi prendi tutto con relatività e ricorda che siamo qui per divertirci.
Abbiamo già parlato della parte importante del nostro obiettivo: fare canestro. Per tirare la palla nel canestro, ci vuole un canestro e... una palla. Ed è qui che entra in gioco Unity.
Se non conosci bene Unity, sappi che è un motore di gioco che consente di creare giochi 2D e 3D per tutte le piattaforme. Include built in fisica, modellazione 3D di base e un'eccezionale runtime di scripting Mono che permette di scrivere il gioco in C#.
Non sono un artista, ma ho preso dei blocchi e messo insieme questa scena.
Ovviamente il blocco rosso è il nostro giocatore. I canestri sono stati impostati con dei trigger invisibili per rilevare quando un oggetto (la palla) passa attraverso il canestro.
Nell'editor di Unity puoi vedere i trigger invisibili delineati in verde. Noterai che ce ne sono due perché in questo modo possiamo assicurarci di contare solo i canestri in cui la palla cade dall'alto verso il basso.
Osservando il metodo OnTriggerEnter in /Assets/BallController.cs (lo script che di ogni istanza della palla), noterai che questi due trigger vengono usati insieme.
private void OnTriggerEnter(Collider other) { if (other.name == "TriggerTop") { hasTriggeredTop = true; } else if (other.name == "TriggerBottom") { if (hasTriggeredTop && !hasBeenScored) { GetComponent().material = MaterialBallScored; Debug.Log(String.Format("{0}, {1}, {2}", SuccessCount++, Distance, Force.y)); } hasBeenScored = true; } }
Questa funzione esegue alcune operazioni. In primo luogo, assicura che venga colpito sia il trigger in alto che quello in basso, poi modifica il materiale della palla per mostrare visualmente che è entrata nel canestro e infine registra le due variabili chiave che ci interessano, la distanza e la forza y.
Apri /Assets/BallSpawnerController.cs. Questo è uno script situato nel tiratore che lancia le palle e tenta di fare canestro. Dai un'occhiata a questo snippet nella parte finale del metodo DoShoot().
var ball = Instantiate(PrefabBall, transform.position, Quaternion.identity); var bc = ball.GetComponent(); bc.Force = new Vector3( dir.x * arch * closeness, force, dir.y * arch * closeness ); bc.Distance = dist;
Il codice crea la nuova istanza di una palla, quindi imposta la forza con cui la tireremo e la distanza dall'obiettivo (in modo che possiamo registrarlo più facilmente in seguito, come indicato nell'ultimo snippet).
Se /Assets/BallController.cs è ancora aperto, puoi vedere il metodo Start(). Questo codice viene richiamato quando creiamo una nuova palla.
void Start () { var scaledForce = Vector3.Scale(Scaler, Force); GetComponent().AddForce(scaledForce); StartCoroutine(DoDespawn(30)); }
In altre parole, creiamo una nuova palla, le diamo un po' di forza e poi la distruggiamo automaticamente dopo 30 secondi perché altrimenti avremmo troppe palle da gestire.
Proviamo a eseguire tutto questo e vediamo come si comporta il nostro tiratore d'eccezione. Premi il pulsante ▶️ (Play) nell'editor di Unity per vedere cosa succede.
Il nostro giocatore, che chiameremo affettuosamente "Red", è quasi pronto per affrontare Steph Curry.
E allora perché è una tale schiappa? La risposta si trova nella riga in Assets/BallController.cs che indica la forza fluttuante = 0,2 f. Questa riga afferma che ogni tiro deve essere esattamente lo stesso. Unity prende il concetto di "esattamente lo stesso" letteralmente. Lo stesso oggetto, con la stessa forza, ripetuto all'infinito che rimbalza sempre allo stesso modo. OK.
Ovviamente non è ciò che vogliamo. Non impareremo mai a fare canestro come Lebron se non proviamo nulla di nuovo, quindi introduciamo qualche altro elemento.
Per introdurre del rumore casuale basta attribuire alla forza un valore casuale.
float force = Random.Range(0f, 1f);
Questo varia i tiri così possiamo vedere cosa succede quando facciamo canestro, anche se ci vuole tempo per fare centro.
Red è un po' stupido, può fare canestro ma solo per caso. Va bene però, perché ogni tiro nel canestro è un punto dati che possiamo usare, come vedremo fra poco.
Ma non vogliamo poter tirare solo da una posizione. Vogliamo che Red faccia canestro (quando è fortunato abbastanza) da qualsiasi distanza. In Assets/BallSpawnController.cs, trova queste righe ed elimina il commento MoveToRandomDistance().
yield return new WaitForSeconds(0.3f); // MoveToRandomDistance();
Se lo eseguiamo, vedremo Red saltare di contentezza in campo dopo ogni tiro.
Questa combinazione di movimenti casuali e forze casuali produce un risultato fantastico: i dati. Nella console Unity vedrai i dati registrati per ogni tiro ogni volta che viene fatto canestro.
Ogni tiro riuscito registra il numero di tiri riusciti fino a quel momento, la distanza dal canestro e la forza richiesta per fare canestro. È un processo un po' lento, bisogna ammetterlo. Torna al punto dove abbiamo aggiunto la chiamata MoveToRandomDistance() e modifica 0,3 f (ritardo di 300 millisecondi per tiro) a 0,05 f (ritardo di 50 millisecondi).
yield return new WaitForSeconds(0.05f); MoveToRandomDistance();
Premi Play e guarda quante palle entrano nel canestro.
Ecco, questo è un buon regime di addestramento! Puoi notare dal contatore sullo sfondo che il 6,4% dei tiri va in porto. Certo, non è Steph Curry. Ma parlando di addestramento, stiamo davvero imparando qualcosa da questo? Dov'è TensorFlow? Perché ci interessa? Beh, questo è il passo successivo. Ora siamo pronti a utilizzare i dati ottenuti da Unity e creare un modello per prevedere la forza richiesta.
Controllo dei dati in Fogli Google
Prima di immergerci in TensorFlow, vorrei dare un'occhiata ai dati, quindi lasciamo Unity fino a quando Red non avrà fatto circa 50 canestri. Nella directory principale del progetto Unity puoi vedere il nuovo file successful_shots.csv. Questa è la raw dump di Unity di ogni canestro che abbiamo fatto! Ho impostato Unity in modo che la esporti per analizzarla facilmente in un foglio di calcolo.
Il file .csv include solo tre righe: indice, distanza e forza. Ho importato questo file in Fogli Google e creato un Scatterplot con una trendline che ci permetterà di vedere la distribuzione dei dati.
Wow! Guarda. Davvero, guarda qui! Lo ammetto, all'inizio neanch'io ero sicuro di cosa volesse dire, quindi analizziamo il grafico più nel dettaglio.
Mostra una serie di punti lungo l'asse Y in base alla forza del tiro e lungo l'asse X in base alla distanza da cui è stato effettuato il tiro. Osserviamo una correlazione molto chiara tra la forza richiesta e la distanza da cui viene effettuato il tiro (con alcune eccezioni casuali di rimbalzi strani).
Ciò si traduce in "TensorFlow sarà perfetto per eseguire questo compito".
Sebbene questo caso d'uso sia semplice, uno dei grandi vantaggi offerti da TensorFlow è che consente di creare un modello più complesso, se lo volessimo, usando un codice simile. Ad esempio, in un gioco completo potremmo includere funzionalità come la posizione degli altri giocatori e le statistiche sulla frequenza con cui hanno bloccato i tiri in passato, per decidere se il nostro giocatore debba tirare o passare la palla.
Creazione del modello TensorFlow.js
Apri il file tsjs/index.js nel tuo editor preferito. Questo file non è correlato a Unity, è solo uno script per addestrare il modello in base ai dati in successful_shots.csv.
Ecco l'intero metodo che addestra e salva il nostro modello.
(async () => { /* Load our csv file and get it into a properly shaped array of pairs likes... [ [distanceA, forceB], [distanceB, forceB], ... ] */ var pairs = getPairsFromCSV(); console.log(pairs); /* Train the model using the data. */ var model = tf.sequential(); model.add(tf.layers.dense({units: 1, inputShape: [1]})); model.compile({loss: 'meanSquaredError', optimizer: 'sgd'}); const xs = tf.tensor1d(pairs.map((p) => p[0] / 100)); const ys = tf.tensor1d(pairs.map((p) => p[1])); console.log(`Training ${pairs.length}...`); await model.fit(xs, ys, {epochs: 100}); await model.save("file://../Assets/shots_model"); })();
Come noterai, non c'è molto da fare. Basta caricare i dati dal file.csv e creare una serie di punti X e Y (molto simile al Foglio Google precedente!). Chiediamo al modello di "adattarsi" a questi dati. Dopodiché lo salviamo per utilizzarlo successivamente.
Purtroppo TensorFlowSharp non si aspetta un modello nel formato in cui Tensorflow.js può salvarlo. Quindi dobbiamo fare qualche magia per eseguire il pull del modello in Unity. A questo scopo ho incluso alcune utilities. Il processo generale consiste nel tradurre il modello dal formato TensorFlow.js a quello Keras da cui possiamo creare un checkpoint per unirlo alla definizione Protobuf Graph per ottenere una definizione Frozen Graph che possiamo spostare in Unity.
Se invece vuoi giocare subito, puoi saltare questi passaggi ed eseguire solo tsjs/build.sh. Se non ci sono problemi, effettuerà automaticamente tutte le operazioni e includerà il modello bloccato in Unity.
All'interno di Unity, possiamo sfruttare GetForceFromTensorFlow() in Assets/BallSpawnController.cs per vedere con cosa interagisce il modello.
float GetForceFromTensorFlow(float distance) { var runner = session.GetRunner (); runner.AddInput ( graph["shots_input"][0], new float[1,1]{{distance}} ); runner.Fetch (graph ["shots/BiasAdd"] [0]); float[,] recurrent_tensor = runner.Run () [0].GetValue () as float[,]; var force = recurrent_tensor[0, 0] / 10; Debug.Log(String.Format("{0}, {1}", distance, force)); return force; }
Quando crei la definizione del grafico, stai definendo un sistema complesso a più passaggi. Nel nostro caso abbiamo definito il modello come singolo livello denso (con un livello di input implicito), ossia che prende un singolo input e restituisce un output.
Quando utilizzi model.predict in TensorFlow.js, questo fornirà automaticamente il tuo input al corretto nodo del grafico e fornirà l'output dal nodo corretto dopo aver completato il calcolo. Tuttavia TensorFlowSharp funziona in modo diverso e ci richiede di interagire direttamente con i nodi del grafico tramite il loro nome.
Quindi si tratta di ottenere i dati di input nel formato previsto dal grafico e inviare l'output a Red.
Usando il sistema appena descritto, ho creato alcune varianti del modello. Ecco Red che tira usando un modello addestrato su solo 500 canestri centrati.
Riesce a fare canestro 10 volte di più! Cosa succederebbe se addestrassimo Red per un paio d'ore e facessimo 10.000 o 100.000 canestri? Il nostro gioco migliorerebbe sicuramente! Ma lascio a te questa parte.
Ti consiglio di andare a vedere il codice sorgente su Github e di inviarmi un tweet se riesci a superare una percentuale di successo del 60% (spoiler: superare il 60% è decisamente possibile, basta tornare indietro alla prima gif per vedere come puoi addestrare bene Red!).
"La tecnologia alla base dell'add-on serverless di GKE ha permesso di concentrarci solo sulla logica aziendale anziché sulle attività di natura generale, quali ad esempio, build/implementazione, scalabilità automatica, monitoraggio e osservabilità". Ram Gopinathan, Principal Technology Architect, T- Mobile
