Test di Project Tango Tablet per la geologia

Scansioni 3D effettuate con Tablet Project Tango ed RTAB-MAP con visualizzazione in MeshLab

L'aspetto interessante di utilizzare RTAB-MAP e' che non e' necessario utilizzare una ripresa statica da cavelletto ma si puo' muovere la camera perche' viene gestito il motion tracking. Questo permette di riprendere anche zone che possono risultare "in ombra" da una ripresa frontale

Prova 1 

Prova 2

Project Tango

Visto che il Progetto Tango di Google e' stato dismesso a Marzo 2018 i prezzi dei dispositivi Tango sono scesi ad un livello umano e mi sono preso un Project Tango Tablet Development Kit. In estrema sintesi si tratta di una tablet Android NVidia con processore Tegra K1 e 128 Giga di memoria dotato di sensori simili a quelli del Kinect per il calcolo della distanza degli oggetti inquadrati

Il nome in codice del tablet e' Yellowstone altrimenti conosciuto con la sigla NX-74751 (in Star Trek la nave USS Yellowstone ha il codice NX-74751) ed e' stato sviluppato internamente da Google presso Google's ATAP (Advanced Technology and Projects). Per sapere quale hardware c'e' dentro si rimanda a questo link

Attualmente la documentazione delle API di Tango sono sparite dal sito sviluppatori di Google ma sono sempre recuperabili su Archive.org mentre il codice di esempio e' stato spostato qui. Al momento non sono riuscito a trovare una immagine del firmware da poter scaricare
Il sensore di profondita' e' un OV4682 con una matrice di 320x180 pixels (risoluzione molto lontana dal Kinect) ed ha funzione anche di camera RGB. Ci sono inoltre una camera standard da 4 Megapixels piu' una camera fisheye da 120° ed una da 180° (in totale di sono 4 camere)

OS	Android™ 4.4 (KitKat®)
Screen	7.02” 1920x1200 HD IPS display (323 ppi)
	Scratch-resistant Corning® glass
Camera	1 MP front facing, fixed focus
	4 MP 2µm RGB-IR pixel sensor
Size	119.77 x 196.33 x 15.36 mm
Weight	0.82 lbs (370 g)
Battery	4960 mAH cell (2 x 2480 cells)
Processor	NVIDIA Tegra K1 with 192 CUDA cores
Network/Wireless	4G LTE¹
	Dual-band Wi-Fi (2.4GHz/5GHz) WiFi 802.11 a/b/g/n
	Bluetooth 4.0
	NFC (reader and peer to peer modes)
Memory	128 GB internal storage (actual formatted capacity will be less)
	4 GB RAM
Connectivity	Micro HDMI
	USB 3.0 host via dock connector²
	Micro SD card
	Nano SIM slot
Sensors	Motion tracking camera
	3D depth sensing
	Accelerometer
	Ambient light
	Barometer
	Compass
	aGPS
	Gyroscope
Audio Output	Dual stereo speakers
	3.5 mm audio connector (OMTP)

Viene riportato che il sensore della bussola non sia funzionante

Il tablet viene fornito con un dock che funziona da ricarica ed ha una porta USB. La porta USB serve solo per connettere eventuali USB drive o simili, non funziona come canale Adb. Inoltre il tablet e' talmente assetato di risorse che se si connette il solo cavo USB (e non l'alimentazione del dock, 12V 2A con connettore positivo al centro del jack) il dispositivo si scarica invece di caricarsi)

Alcune applicazioni gia' pronte risultano essere

• App Discovery Project Tango 
• Room Scanner
• RTAB-Map (permette esportazione in ply)
• Tango Scan View (converte i file OBJ in PLY)
• ADF Tools
• Tango Explorer
• Java Point Cloud Example (dagli esempi Java)

Scansione con RTAB-Map visualizzata con MeshLab

E' possibile ancora ricompilare gli esempi ma non sono riuscito a ricompilare questo progetto

Per ottenere i permessi di root si usa TangoRoot e ChainFireSU (io non sono riuscito ad eseguire il root perche' Android continua a dire che e' TangoRoot e' una applicazione pericolosa e non la mette in esecuzione)

I dati delle immagini di profondita' vengono immagazzinati di default in formato super compresso binario proprietario ADF che risulta poco documentato. In ogni caso ci sono applicazione di terze parti che esportano in formati piu' comuni come PLY. La directory di salvataggio dei file ADF e' mutata nel tempo ma in ogni caso sembra richiedere i permessi di root

Modello digitale del terreno con Google DayDream ed Unity

In questo post il metodo che ho usato per mostrare dati di modelli digitali del terreno con Unity ed il visore DayDream di Google

Il progetto che ho creato e'  di tipo Android. Nel Player Settings del progetto sotto XR Settings deve essere spuntato il supporto alla realta' virtuale e si aggiunge DayDream tra gli SDK. Sempre nel Player Settings si deve impostare in Other Settings un Minimum Level API a livello 24

Sicilia con Etna

Per prima cosa si crea il modello digitale.
L'immagine deve essere a scala di grigi, in cui il livello di grigio indica la quota sul livello del mare (nero equivale a livello piu' basso, spesso il livello del mare, il bianco e' la quota piu' alta)

Si crea un oggetto Terrain da GameObject/3D/Terrain con dimensioni pari a quelle del modello DEM
Si trascina l'immagine negli assets del progetto e si prende il file HeightmapfromTexture. Dalle proprieta' dell'immagine (a destra Advanced si deve spuntare Read/Write and Apply)
L'editor delle versioni moderne di Unity (Unity 3d 2017.2) non permettono di editare direttamente file JavaScript. Si copia quindi lo script in un editor e si aggiungono le seguenti linee (dove si dichiarano le variabili x ed y)

    var mapColors = heightmap.GetPixels();
    var map = new Color[w2 * w2];
    var y = 0.0;
    var x = 0.0;


 si salva il file e lo si trascina negli assets del progetto.

Si selezione negli assets l'immagine DEM importata e si clicca sul menu' in alto Terrain/HeightMapFromTexture

Per settare il livello di amplificazione delle quote si cambia il valore di Terrain Height nell'inspector

Il modello usato e' poco dettagliato 2048x2048 pixels

Una volta importato e settato il modello digitale si deve aggiungere il supporto DayDream a Unity.
Una volta scaricato il package Daydream per Unity e lo aggiunge al progetto con il menu Assets/Import Package/Custom/GoogleVRforUnity.unitypackage.

• Si aggiunge quindi alla Hierarchy il modulo GvrEditorEmulator
• Si crea quindi un GameObject (dal menu' in alto), Gameobject/Create Empty e si rinomina come Player
• Si trascina la camera e si inserisce nell'albero sotto l'oggetto Player
• Si aggiungono GvrControllerMain e GvrEventSystem
• Se il progetto include una canvas deve essere aggiunto GvrPointerGraphicsRaycaster da Add Component
• Si aggiunge GvrPointerPhysicsRaycaster alla Camera da Add component
• Si aggiunge GvrControllerPointer agganciandolo al Player

Riconoscimento automatico targhe automobilistiche

Ho letto sul giornale che i Vigili Urbani di Firenze hanno a disposizione un sistema automatico di lettura delle targhe automobilistiche in modo da interrogare poi un database della motorizzazione per elevare multe...mi sono chiesto...quanto e' complicato questo metodo??

Avevo letto che la libreria OpenCV permetteva di fare il riconoscimento automatico ma frugando ho trovato un prodotto gia' fatto ovvero OpenALPR,,vale la pena provarlo facendo una prova veloce

(ps. per motivi di privacy le targhe sono oscurate, fidatevi che i risultati sono corrispondenti alla realta')

Fornendo all'algoritmo questa foto

Si ha come risultato questa lista. Il primo candidato, quello con il punteggio piu' alto, corrisponde al vero numero di targa.

Non tutte le immagini forniscono dati corretti e per assurdo se si fotografa una targa in primissimo piano l'algoritmo fallisce miseramente

Piccoli artisti crescono

Mamma e babbo

Frecce Tricolori su Firenze 28 Marzo 2018

per cercare di fare partire il tempo la registrazione sbirciavo su un cellulare FlightRadar24 nella speranza che gli aerei delle Frecce avessero i transponder accesi....no...i militari a quanto pare non usano questo sistema ....in ogni caso ho avuto l'indicazione che la pattuglia era in zona quando un volo civile ha iniziato un circuito di attesa prima di entrare nell'area fiorentina

Immagini Raw su Gimp ed Android

Scattare una foto con un telefono cellulare e' semplice, scattare una foto con una resa cromatica soddisfacente non e' banale.

Per prima cosa si deve scattare una foto salvando i dati in formato Raw. Cio' non e' possibile con tutte le fotocamere dei telefoni (per quelli piu' costosi in genere si') e bisogna in ogni caso appoggiarci ad applicazioni esterne come AZ Camera (una delle poche che permette il salvataggio raw in modo gratuito). Lo scatto avra' una estensione .dng (il formato DNG non e' esattamente coincidente con il formato RAW ma per quello che seguira' non ci sono significative differenze) ed avra' la dimensione di qualche decina di Mb

Per avere dei colori fedeli si deve includere nell'immagine anche una tavola dei colori di riferimento come la CheckerColor di X-Rite. Si tratta di un oggetto molto costoso, sul centinaio di  euro al momento, che e' formato da 24 mattonelle di colore omogeneo e calibrato

Se si include la tavola di riferimento nell'immagine si puo' poi usare il software ColorChecker Camera Calibration che elabora l'immagine, trova il riferimento e crea un file .dcp di riferimento per la fotocamera (attenzione, se la foto e' sovraesposta il software non funziona)

A questo punto con il programma dpc2icc si puo' convertire il profilo camera in .icc, il formato desiderato da Gimp. (attenzione: per la conversione e' necessario inserire la temperatura di colore)

Di default Gimp non sa gestire i file raw ed e' necessario installare il pluging ufraw. Scaricando pero' questo pacchetto si trova Gimp con gia' incluso il pacchetto ufraw. Aprendo un file .dng si apre in automatico ufraw

Da qui si possono impostare le impostazioni della camera importando il file .icc. Premendo Ok l'immagine corretta viene quindi inviata a Gimp per le successive modifiche

A questo punto non e' finita....avere una foto cromaticamente calibrata non vuol dire che riusciamo a vederla a monitor con i colori giusti perche' anche il monitor (o lo schermo del telefono) deve essere calibrato mediante apposite applicazioni (tipo ColorTrue di X-Rite per Android) ed appositi dispositivi hardware chiamati colorimetri (tipo ColorMunki X-Rite del costo di un centinaio di euro)

In conclusione ottenere i colori corretti su PC o Android e' piuttosto costoso....