Fabio Ruini’s blog

Sviluppi interessanti per quanto riguarda il mio sforzo di applicare l’algoritmo di flocking di Reynolds agli Swinglet. Innanzitutto ho fatto le ultime modifiche ed ultimato il simulatore di boids “tradizionale” che avevo iniziato a scrivere ieri pomeriggio. Il risultato direi che e’ soddisfacente. Ne ho approfittato per montare anche un breve video, prontamente uploadato su YouTube, dove si puo’ osservare il simulatore in azione. Qui sotto trovate l’embed del filmato (chiedo venia per la telecamera un po’ “flickering” per i primi minuti, ma si tratta di un annoso problema che ho con Irrlicht e che puntualmente mi si ripresenta) (ringrazio al tempo stesso i Mad Dog McRea per la colonna sonora).

Al link che segue, nel caso potesse interessarvi, trovate anche tutti i sorgenti del software in questione. Tenete presente che l’applicazione e’ un misto di C++/Cocoa, quindi potrebbe non compilare al primo colpo su sistemi Linux/Windows. Le modifiche da apportare per far funzionare il tutto dovrebbero comunque essere decisamente marginali. Altra nota importante: i path alle risorse esterne (texture, sfondi, ecc…) presenti in gui.cpp sono hard-codati per la mia macchina. Nel caso vogliate avventurarvi nella compilazione dovrete giocoforza mettere mano pure a questi e modificarli a seconda di dove avete piazzato i file in questione.

Detto cio’, ora e’ iniziata ufficialmente la fase di implementazione del comportamento di flocking reynoldiano sui MAVs che utilizziamo per gli esperimenti. Dopo aver speso un paio di orette sul simulatore sono riuscito, almeno a grandi linee, a rendere funzionante il tutto. Ora si tratta di affinare un po’ il codice, verificare che non vi siano MAI collisioni tra i vari aeroplanini e poi provarlo sul campo. Presumibilmente tra un paio di settimane, dato che la prossima dovrei essere in quel di Roteglia per qualche giorno di relax. Stay tuned.

PS: nel pomeriggio e’ anche arrivata la risposta ufficiale dell’ESA in merito all’interview di qualche settimana fa. Come previsto non e’ andata. Vedremo ormai di farcene una ragione…

Comments(0)

La nuova settimana inizia esattamente da dove avevamo lasciato quella appena trascorsa. Ovvero si riparte da Reynolds e dal suo algoritmo di flocking per boids. I tentativi abbozzati lo scorso venerdi’ di implementare questo tipo di algoritmo nel mio simulatore di MAVs non hanno dato esiti particolarmente incoraggianti. Cosi’ ho deciso di prendermi un po’ di tempo per scrivere un’applicazione dedicata esclusivamente all’implementazione di questo algoritmo, avendo come riferimento delle “particles” 3D prive di orientamento spaziale e libere di muoversi in qualunque direzione senza essere affette da una dinamica ben precisa.

Effettuando qualche ricerca sul forum di Irrlicht ho trovato un post scritto dall’utente randomMesh, dove presenta un progetto sviluppato con l’engine grafico in questione e basato appunto sui boids di Reynolds. Il progetto e’ ospitato su SourceForge.net ed e’ stato battezzato Katastrophe. L’implementazione dell’algoritmo di flocking si basa sull’interpretazione (in pseduo-codice) di Conrad Parker. Chi non avesse voglia di scaricare e compilare i sorgenti dell’applicazione, puo’ vederla in funzione dal video pubblicato su YouTube che vi propongo qui sotto.

Vediamo un po’ cosa verra’ fuori.

Comments(0)

Giornata all’insegna della procrastinazione quella di oggi. Il codice per i controller e’ stato sistemato ieri ed ora sono in attesa della prossima sessione di test per metterlo alla prova. Oggi, causa maltempo piuttosto serio, le prove sul campo sono saltate. Cosi’ ne ho approfittato per preparare qualche script Matlab da utilizzare per l’analisi automatica dei files di log generati dai MAVs (piu’ che altro script che si occupano di riformattare tutti i dati raccolti in una maniera piu’ organizzata e riutilizzabile), fare qualche modifica di poco conto al simulatore e provare a risolvere ancora una volta l’ormai annosa questione con la WNDA 3100 e piu’ in generale la compilazione del codice per i controller.

Per fare il quadro della situazione riepilogo brevemente le “problematiche” software che sto affrontando quando si tratta di programmare i controller. Innanzitutto, il processore utilizzato sui mini-computer installati sui MAVs e’ un ARM. Il che implica che i controller, scritti in C++, devono essere compilati appunto per processori ARM. Essendo che il PC che utilizzo gira con un classico processore Intel si rende necessario il ricorso a tool di cross-compiling. Questi tool sono molto diffusi in ambiente Linux, meno su Mac, decisamente poco su Windows. Ragion per cui la ragazza con cui lavoro mi ha passato una copia di una sua macchina virtuale Linux che ho installato sul mio computer, con gia’ installati/configurati tutti gli strumenti necessari per il cross-compiling. Il problema e’ che Linux non e’ certo famoso per la portabilita’, cosi’ che la virtual machine in questione ha problemi da un punto di vista grafico (icone e font giganteschi e che si risettano in maniera random dopo mie modifiche, pezzi di desktop che di tanto in tanto spariscono, ecc…), non rendendola particolarmente confortevole per elaborare il codice. Ho provato ad installare ex-novo una nuova macchina virtuale Linux, sono riuscito ad installare i tool per il cross-compiling, ma mi sono poi arenato sulla configurazione dell’adattatore Wi-Fi che, pensavo, fosse un elemento fondamentale nel contesto dell’intero setup. Il trasferimento dei binari dal computer ai MAVs avviene infatti tramite connessione senza fili, sfruttando una rete Wi-Fi dedicata che ciascun MAV crea automaticamente al momento dell’accensione. Con l’adattatore ci si allaccia a questa rete, ci si connette via SSH al robot di turno e si trasferiscono i dati. Semplice e lineare. Il problema e’ che Linux in virtual machine via Parallels sembra non vedere in alcun modo l’adattatore wireless del Mac, cosi’ che e’ necessario utilizzare un dongle esterno. Su quest’ultima tematica oggi ho avuto la folgorazione. Perche’ non allacciarmi alla rete wireless da MacOS ed interagire con i robot via terminal? Ho fatto qualche prova e tutto e’ filato liscio. A patto che io crei la rete wireless prima di accendere i robot, altrimenti il Mac non mi lascia creare la rete in quanto ne vede gia’ una presente con il medesimo nome (devo controllare se creare la rete con comandi del terminale mi permetta o meno di girare attorno a questa issue). Il problema consiste comunque nel fatto che in laboratorio mi devo connettere ad Internet via wireless, non essendoci un socket Ethernet vicino alla mia scrivania. Quindi, nel momento in cui devo trasferire file, mi tocca staccare tutto, cambiare IP, ecc… e poi rifare il procedimento inverso una volta finito. Niente di insormontabile, ma comunque una discreta rogna. E comunque devo utilizzare sia MacOS che la macchina virtuale. Nel tentativo di risolvere la questione in maniera definitiva ho provato oggi ad installare i tool di cross-compiling su MacOS (seguendo le istruzioni trovate qui) (approfitto pure per segnalare quest’altra pagina, che contiene i codici ASCII di alcuni caratteri strani che spesso risultano essere utili), ma non sono riuscito nell’impresa, causa problemi di warnings being treated as errors in fase di compilazione che non sono stato in grado di risolvere neppure agendo manualmente sui Makefiles.

Morale della favola, ancora mi trovo a dover utilizzare la macchina virtuale Linux per il compiling, trasferire sorgenti e binari via Parallels, e poi attivare/disattivare/riconfigurare l’AirPort ogni qualvolta devo uploadare dei nuovi controller. Una situazione non certo terribile, ma che mi piacerebbe riuscire a risolvere eliminando del tutto (almeno) la necessita’ di utilizzare la virtual machine.

Comments(2)

Dopo un po’ di tempo a questa parte si torna a smanettare su Linux. Il motivo non e’ un improvviso ritorno di fiamma, quanto piuttosto il fatto che per compilare e trasferire il software del controller sugli swinglet e’ necessario (cross)compilare via Linux e poi collegarsi via SSH wireless al robot. E cosi’ ho rispolverato la mia macchina virtuale Ubuntu 10.4 installata sul mio Mac. Questo perche’ l’altra che ho installato, una Kubuntu pre-configurata dai ragazzi del laboratorio e pronta per l’uso, sul mio laptop funziona un po’ da schifo. Fa il suo dovere, ma la risoluzione dello schermo e la dimensione dei font svarionano a caso, e’ impossibile connettersi ad Internet (cosi’ che non posso neanche downloadare un editor di codice serio da utilizzare per le modifiche) ed il drag-and-drop dei files da/verso MacOS semplicemente non funziona (per trasferire files occorre cosi’ chiudere la VM e montare su Mac l’immagine del disco virtuale).

Per quanto riguarda il cross-compiling verso piattaforma ARM, dopo qualche rogna (dovuta principalmente al fatto che mi ero scordato di scaricare via Synaptic gli headers del kernel per ARM) mi sembra di essere riuscito nell’impresa. Il tool che utilizzo e’ Cross Toolchains, sono riuscito ad installarlo correttamente e pare compilare senza problemi il codice del controller (che poi questo funzioni anche sul robot e’ cosa da verificare). Per la cronaca, l’installazione e’ consistita semplicemente nell’aggiungere il repository deb http://www.emdebian.org/debian/ lenny main e scaricare i pacchetti g++-4.3.arm.linux.gnueabi (con relative dipendenze) e linux-kernel-headers-arm-cross.

I problemi seri stanno emergendo invece per quanto riguarda la parte wireless, per via del dongle Netgear WNDA3100 che mi e’ stato “imposto” di utilizzare (per quanto, ragionando or ora sulla questione, non vedo la necessita’ di dover per forza adottare questa interfaccia… appena tornero’ in laboratorio domattina cerchero’ di vedere se e’ possibile evitarlo). Il problema deriva dal fatto che mentre questo dongle funziona benissimo sulla VM Kubuntu, non vuole invece saperne di mettersi in modo sulla (ben piu’ aggiornata) VM Ubuntu. Ho lavorato alla questione per diverse ore, senza riuscire a venirne a capo. I drivers che ho utilizzato (e provato a configurare/compilare/installare nelle maniere piu’ disparate) sono i compat wireless per chipset ar9170 disponibili su http://linuxwireless.org/en/users/Download/stable/. Rimangono valide alternative stile ndiswrapper, che vorrei pero’ cercare di non utilizzare.

Da segnalare il fatto che, alla ricerca di un aiuto, sono finito per installare un client IRC (al secolo Ircle) ed intavolare una discussione sul canale dedicato. Chattare su IRC, a circa dieci anni di distanza (se non di piu’) dall’ultima volta che l’avevo fatto, non ha prezzo. Memorabile, poi, quando uno degli utenti con cui stavo interagendo e che mi chiedeva di postare l’output di dmesg ha specificato di non copia/incollare direttamente sul canale, ma attraverso Pastebin.com. Le vecchie abitudini non muoiono mai…

Comments(0)

Ancora al lavoro sul codice del controller da testare sullo swinglet, oggi sono andato alla ricerca di qualche funzione che mi permettesse di estrarre valori secondo una distribuzione normale nella maniera computazionalmente piu’ efficiente possibile. Le soluzioni pronte per l’uso che ho trovato in giro per la rete (vedi un buon riassunto qui dentro) richiedevano la compilazione di un po’ di librerie da usarsi a mo’ di prerequisito e mi sono sembrate eccessive per il semplice uso che deve farne il sottoscritto. Una soluzione alternativa l’ho individuata seguendo questa interessante discussione. Soluzione che riguarda l’impiego, in luogo di una distribuzione normale, di una Triangular distribution. La distribuzione triangolare e’ una distribuzione di probabilita’ continua, con limiti inferiori e superiori a e b e moda c. I risultati che produce non sono ovviamente gli stessi di una distribuzione normale, ma nel caso in cui se ne usi una con valori a e b tali da renderla simmetrica, allora puo’ essere considerata un’approssimazione discretamente valida di una gaussiana.

Altro argomento toccato oggi e’ stato il GPS. Lo swinglet e’ dotato di ricevitore GPS, che nel mio caso verra’ utilizzato per emulare un sistema sensoriale nei vari MAVs. L’idea e’ quella di non utilizzare quindi informazioni posizionali “assolute”, ma andare per un approccio piu’ bio-inspirato, utilizzando queste informazioni per ricreare una sorta di sistema percettivo degli aeroplanini, il quale determinera’ poi il loro comportamento. Presupposto fondamentale per questo genere di applicazioni e’ poter accedere ai dati del GPS e trasformarli da gradi in qualcosa di piu’ maneggevole (come ad esempio metri). Questo e’ esattamente quello che fa il codice qui sotto, che ho trovato per Matlab ma che puo’ essere convertito in una frazione di secondo in un qualsiasi altro linguaggio. La funzione qui sotto riceve in input un vettore composto da due valori, a rappresentare rispettivamente longitudine e latitudine di un certo punto, e converte questi valori in metri.

Per rimanere in tema vi segnalo poi questa simpatica paginetta, all’interno della quale e’ possibile specificare delle coordinate random e poi visualizzare, tramite l’engine di Google Maps, dove il punto corrispondente alle coordinate immesse si trova. Simpatico.

Comments(0)

Ricordo ancora quei giorni come fossero ieri. Sono tra i pochi ricordi nitidi che ho dei tempi delle superiori. 26 (o giu’ di li’) studenti accampati in uno dei laboratori di informatica. Seduti in maniera ordinata lungo i banchi che in piu’ file scorrevano al centro della stanza e circondati da cassoni ronzanti, spinti dai primi processori Pentium, collegati ai loro rigorosi monitor CRT da 14 o 15 pollici e soprattutto connessi attraverso una bella rete a bus (l’Ethernet ancora doveva affermarsi, mentre il Wi-Fi era un miraggio). Curioso se pensiamo che questi ricordi risalgono soltanto a poco piu’ di 10 anni fa.

26 studenti in una stanza, dicevo. Pronti per il tradizionale (uno ogni due/tre settimane ci toccava) compito in classe di informatica. Che pero’ si svolgeva con modalita’ anni ‘70. Vietato utilizzare i computer. In compenso plichi formato famiglia di fogli a protocollo a disposizione di tutti. I primi quindici/venti minuti passavano con la professoressa che dettava le specifiche. Che erano sempre qualcosa di improponibile. Il resto delle due ore (talvolta tre) lo si passava invece con la testa chinata sul banco, scrivendo (letteralmente) codice fino all’ultimo secondo disponibile. Codice che doveva essere corretto al 100% (ogni errore di sintassi un punto in meno, figurarsi quelli concettuali) ed anche indentato alla perfezione. In maniera tale che, quando ci si trovava ad avere a che fare con tre o quattro cicli annidati, una pagina ti partiva solo per scrivere un paio di istruzioni. Ma la parte piu’ divertente era ovviamente il debug. Matita e gomma. E via a provare decine combinazioni dei parametri piu’ implausibili per verificare che tutto funzionasse a dovere. Ovviamente, quando all’ultimo anno sono entrati in gioco i puntatori, le fasi di debug si sono trasformate in una sorta di seduta spiritica.

Perche’ questo lungo incipit? Semplicemente perche’ oggi ho passato un giorno come quelli descritti qui sopra. Non perche’ fossi impegnato con qualche esame o compito in classe, ma piuttosto perche’ ho iniziato a scrivere il codice da caricare sullo swinglet per i primi esperimenti di flocking. E’ una sensazione strana, dopo essersi abituati a lavorare sempre e solo in simulazione, quella di digitare istruzioni che non si possono compilare sulla propria. E tantomeno debuggare. Si procede un po’ alla cieca, prestando enorme attenzione ad ogni passaggio e sperando che non ci sia dimenticati niente. E per quanto riguarda il debug? Beh, sono tornate fuori la gomma e la matita…

Comments(0)

Dopo aver trasformato il mio simulatore di flocking in un’applicazione Cocoa/Objective C (il che ha comportato semplicemente il creare un nuovo progetto XCode e rinominare alcuni files da .mm a .cpp), oggi ho approfittato di questo cambiamento per implementare una barra dei menu personalizzata per la mia applicazione.

Irrlicht, all’interno della distribuzione, mette molto cortesemente a disposizione un file .nib, uno dei formati utilizzati da Interface Builder, contenente una barra dei menu piuttosto standard, ma comunque piu’ che adatta ai miei scopi. Utilizzando il software di Apple sono riuscito a personalizzare questa barra in maniera molto rapida ed intuitiva, mentre per integrarla al mio software e’ stato sufficiente aggiungere il file .nib modificato nella sezione “Groups & Files” del progetto Xcode.

Ora, l’unico problema sorgeva dal fatto che la finestrella “About”, l’unica che realmente mi interessava andare a modificare, non figurava da nessuna parte. Semplicemente, utilizzando quel file .nib, viene generata in real-time attingendo dalle informazioni contenute in info.plist (icona del programma, informazioni di versione, ecc…). Dopo un po’ di googlamenti vari ho scoperto la procedura da seguire e che, contrariamente a quanto suggeriscono diversi siti, non richiede la stesura di neppure una singola riga di codice ma puo’ essere svolta interamente all’interno di Interface Builder. Tutto cio’ che e’ necessario e’ creare un nuovo “Panel” all’interno del proprio file .nib, customizzarlo a piacimento ed infine “linkarlo” alla voce di menu desiderata (nel nostro caso “About MAVs Flocking Simulator). Per farlo, e’ necessario selezionare la voce di menu voluta, aprire l’inspector di Interface Builder, attivare il tab dei link (icona blu) ed alla voce “Sent actions” trascinare il segno + verso il pannello appena creato e selezionare come azione “orderFront”. Tutto qui.

Per ottimizzare un po’ il comportamento dell’applicazione e renderlo diciamo “standard”, suggerisco di utilizzare i settaggi che trovate nell’immagine qui di sotto per quanto riguarda il pannello.

Questo il risultato finale.

Per chi volesse approfondire un po’ la questione chiudo il post con un po’ di link a riguardo:

• la guida di Apple ad Interface Builder (invero non una delle migliori documentazioni che abbiano mai prodotto) [link];
• implementare un semplice menu [link];
• trafficare con le finestre [link];
• formattare il testo nelle finestre generate automaticamente [link].

Comments(0)

Finalmente ci siamo. Da qualche minuto e’ disponibile per il download l’iPhone OS 4, altresi’ ribattezzato iOS4, vale a dire la nuova major release del sistema operativo per iPhone.

L’update, per chi non lo sapesse, e’ gratuito per tutti i possessori di iPhone 3G e 3Gs, nonche’ gli iPod Touch di seconda e terza generazione. Le funzionalita’ introdotte con l’aggiornamento variano in funzione dell’apparecchio per il quale si effettua l’update. Una tabella riepilogativa potete trovarla a questo link. Maggiori informazioni riguardo alle funzioni introdotte potete invece ottenerli da quest’altra pagina, oppure guardando il keynote di Jobs durante la scorsa WWDC 2010 di San Francisco.

Nel mio caso (iPhone 3G) il download ammonta 292.1MB e la velocita’, pur none eccelsa, sembra al momento accettabile. Nel giro di una mezzoretta dovrebbe essere tutto pronto per l’installazione. Dita rigorosamente incrociate nella speranza vada tutto bene.

UPDATE: aggiornamento decisamente lunghino, ma andato a buon fine. Purtroppo, sul mio 3G le novita’ non sono moltissime e comunque meno evidenti di quanto mi aspettassi (a questo link potete trovare un riepilogo). Ottime le folders, che permettono di mettere ordine tra le proprie apps, ma sgradevoli da un punto di vista meramente estetico. Nota piu’ che positiva, invece, per iBooks: un’applicazione che mi ha davvero stupito.

Comments(0)

Su Punto Informatico e’ apparso questa mattina un interessante articoletto a firma di Alfonso Maruccia, che vi ripropongo qui di seguito. Il tema trattato e’ quello della realta’ aumentata (augmented reality per gli amici), gia’ toccato diverse volte in questo blog, in un’implementazione di stampo militare.

Realtà aumentata sul campo di battaglia
Un’azienda statunitense sostiene di avere in cantiere la tecnologia AR definitiva. Capace di trasformare ogni soldato in una fonte e un client di informazioni utili alla gestione coordinata dei pericoli presenti sul campo di battaglia

In teoria la prospettiva di avere simili tecnologie a disposizione di ogni squadra di fanteria in tempi brevi alletta i militari e l’agenzia DARPA, che non a caso ha fornito i fondi per le ricerche di Tanagram Partners. Nella pratica l’azienda statunitense pianifica di realizzare una “app” per iPhone che dimostri il funzionamento della tecnologia entro il primo quarto del 2011, e tutti i componenti funzionanti (inclusi sistema client-server, casco e client HMD) entro la fine dell’anno prossimo.

Vado ora ad approfondire velocemente, fornendo al tempo stesso un po’ di link utili, l’articolo di cui sopra. La Tanagram Partners e’ un’azienda con sede a Chicago, attiva in cinque macro-aree differenti, e che vanta rapporti che sembrano essere piuttosto stretti sia con l’esercito USA, sia con altre grandi realta’ industriali. Il sistema di cui parla Punto Informatico si chiama iARM, acronimo che sta per Intelligent Augmented Reality Model. La descrizione che la stessa societa’ fornisce del prodotto/servizio che stanno progettando e’ un po’ piu’ tecnica rispetto al semplice riassunto che ci ha fatto Maruccia:

This system, named iARM (Intelligent Augmented Reality Model), encompasses an open source operating system supporting geolocation and triangulation, together with data services that integrate voice, video and image for facial/object recognition and pattern analysis. It is supported by a hardware platform integrating a computer processor, encrypted wireless, camera/video and visual display.

iARM shows the potential to enhance communication and information sharing at the squad, platoon and even headquarters levels, while actually reducing cognitive load through data visualization. It is supported by a natural user interface (NUI) relying on simple movements by soldiers to update the system’s collective knowledge base. No mouse or external device is needed. The NUI’s hybrid input approach combines gesture, voice and context to create a very intuitive experience to foster quick learning and fast, simple updating of data in real-time. The result is a non-intrusive system that can be quickly assimilated into the routine of the infantryman and squad.

Benche’ il grant che la Tanagram Partners ha ricevuto per portare avanti questo lavoro risalga ormai ad un anno fa, una prima presentazione pubblica di stampo accademico e’ stata fatta solo di recente, ad opera del CEO Joseph Juhnke durante ARE 2010 (Augmented Reality Event), una due-giorni di conferenza che si e’ tenuta il 2 e 3 giugno scorsi a Santa Clara, California. Il progetto e’ ancora alle fasi preliminari ma, al di la’ degli innumerevoli problemi tecnici che inevitabilmente ostacolano una vision cosi’ ambiziosa, si preannuncia interessante. Chi fosse interessato a seguire gli sviluppi puo’ farlo sul blog ufficiale dedicato a iARM, all’interno del quale e’ possibile scaricare anche il dettagliato mid-term report redatto a febbraio dagli uomini della Tangram.

L’idea, ad ogni modo, non pare essere una novita’ in senso assoluto. L’F-35, aereo destinato a rivestire un ruolo decisamente importante nella flotta della US Air Force (e’ in programma l’acquisto di 2,433 velivoli di questo tipo), e’ gia’ fornito con un avanzatissimo casco collegato ai vari computer di bordo. Tra le varie funzioni offerte (come ad esempio proteggere il pilota dai dazzlers), vi e’ anche quella di fornire informazioni di situational awareness, visualizzandole in tempo reale direttamente sulla parte anteriore dell’helmet. Un po’ di dettagli a riguardo potete trovarli in due link di Gizmodo: questo e quest’altro. Su YouTube e’ infine presente un video (decisamente) promozionale, che merita comunque una visione. A voi:

Certo che e’ sempre piu’ una figata nascere top gun…

Comments(0)

Nel post odierno una veloce comunicazione di servizio per chi fosse alla ricerca di un bel pezzo di software, ottenibile gratuitamente ed in maniera del tutto legale. La Digiarty Software ha infatti lanciato una promozione (non chiedetemi il motivo) che permette, per la giornata odierna, di scaricare gratuitamente WinX HD Video Converter for Mac (software e licenza di utilizzo).

Come recita la descrizione presente sulla pagina ufficiale del prodotto, WinX HD Video Converter for Mac, as a professional Mac HD converter software, provides the perfect solution to convert Blu-ray videos and videos from HDTV and HD camcorders, like JVC, Panasonic, Sony and Cannon to other formats. This HD converter for Mac supports converting Multi-track HD video M2TS, MKV, AVCHD, HDTV BDAV and MPEG-TS video movies. It can also convert video files to the video formats that playable on both portable and console players, such as iPad, iPod, iPhone, Apple TV, PS3, PSP, Xbox, Zune, PDA, Blackberry, Nokia, Android, Zen, etc. So you could watch the videos as your will.

Insomma, se di tanto in tanto trafficate con dei video o magari volete semplicemente esportarvi qualche film sull’iPhone, non lasciatevi fuggire questo software.

Comments(1)