Oggi è arrivato l’LCD da 16×2, e così ho potuto inscatolare il secondo dei miei due progettini estivi fatti con l’Arduino; come potete vedere in figura:
sullo sfondo c’è un lettore ad infrarossi, che ho accoppiato al telecomando (sulla sinistra) del mio vecchio impianto stereo; per interfacciarlo al PC, dato che francamente con LIRC non ne sono uscito, mi sono scritto 20 righe di Python e comando direttamente Amarok via DBus; presto aggiungerò qualche riga per comandare anche VLC, ed a quel punto direi che è fatta… il circuito ha praticamente solo il ricevitore IR (ed un LED, tanto per illuminare qualcosa), quindi lo sforzo è stato decisamente basso.
In primo piano, invece, c’è il buon Tweetino: è un po’ un peccato che lo schermo adatto a quel case sia necessariamente così piccolo, per il resto tutto funziona egregiamente; dopo aver risolto il bug della libreria Base64 ed uno stack overflow che mi era sfuggito, l’interfacciamento sulla rete non dà problemi ed i tweet vengono correttamente visualizzati (spesso abbreviati) sullo schermo. Devo ammettere che scrivere il software è stata la parte più divertente, e vedere il tutto funzionare correttamente è decisamente soddisfacente.
E questo è quanto: ormai l’estate è finita (anche se Qualcuno lassù ha evidentemente sbagliato ad impostare il termostato…), e devo ricominciare a fare cose serie; in realtà è rimasta una piccola ideuzza, ma per attuarla devo aspettare che mi arrivino alcuni componenti (tra cui un accelerometro, e non dico altro…). Nel caso, scriverò ulteriori aggiornamenti.
Perchè nessuno mi dice le cose importanti? I pin analog in dell’Arduino (A0-A5) sono in realtà GPIO, e si possono quindi usare anche come output! Questo cambia parecchio le cose, soprattutto nei circuiti con l’interfaccia ethernet e l’LCD, che da soli portano via 12 pin digitali…
L’evoluzione naturale, dopo aver giocato in lungo ed in largo con l’Arduino, è unire Processing al tutto e vedere cosa emerge… alcune seghe mentali sono già on their way, questo post si limita a mostrare come catturare un video su Linux (ed applicare un effetto real time, già che ci siamo).
Come mai un post dedicato, qualcuno si chiederà… bè, perchè se siete su Linux dovete fare qualche rapida ricerchina per poter catturare video da webcam direttamente da Processing, dato che la libreria di default funziona solo su Mac e Windows (testata peraltro da me su quest’ultimo, e va); per fortuna, qualche anima pia della community ha creato una seconda libreria che sfrutta l’amato (?) GStreamer e ci permette di sfruttare come si deve l’amato sistema operativo.
L’installazione è estremamente semplice, di fatto si tratta di estrarre l’archivio nella cartella libraries (a proposito: lo sapevate che tale cartella si può collocare, in Processing come in Arduino, dentro la cartella degli sketch? Estremamente comoda se condivisa su Dropbox tra computer diversi!), ed il gioco è fatto: tra gli esempi, appaiono ora anche quelli di GSVideo, pronti ad essere provati. Se avete un solo dispositivo video, quello verrà caricato di default, altrimenti dovreste specificare il device.
Se siete su sistemi a 64 bit, c’è da penare un filino: per prima cosa dovete sostituire la directory java dentro Processing con la versione del JDK a 64 bit (il default è solo a 32), o in alternativa fate un symlink alla directory del vostro sistema dove avete già il JDK, e successivamente bisogna sostituire le librerie OpenGL in modes/java/libraries/opengl/library/linux64 con quelle installate nel vostro sistema (per fare questo dovrete installare libjogl per Java (su Debian/Ubuntu c’è l’apposito pacchetto, suppongo ci sia anche sulle altre distro)), con alcuni pratici symlink. Far partire Processing con linux32 non è purtroppo sufficiente…
Riguardo il video: ho messo assieme l’esempio che renderizza la differenza tra due frame successivi con quello che salva il video su file, e mi sono ripreso con la webcam mentre suonavo; il video non contiene audio, dato che il punto era mostrare che GSVideo funziona, non tanto registrare le note suonate; verranno esempi più avanti in cui metterò assieme diverse cose, ora come ora va bene così.
Se siete interessati, il file lo potete trovare qui (l’ho nominato con estensione java, così che Gist lo riconoscesse con la sintassi giusta, ma in realtà è un file pde).
Postilla
Nella registrazione avevo impostato gli fps del file salvato a 25, ma mi sono reso conto che il valore reale si aggirava attorno a 15, ovvero il video finale era accelerato rispetto alla realtà; semmai a qualcuno servisse, ecco il comando per diminuire gli fps usando ffmpeg e yuvfps (con probabile perdita di qualità, ma se volete un lavoro fatto meglio fate qualche esperimento di cattura e verificate che gli fps in output siano corretti direttamente alla fonte, invece che rimediare in un secondo momento…):
Bè, si potrà dire quel che si vuole, ma di certo non si può non ammettere che Canonical si sta muovendo verso una direzione decisamente interessante… quantomeno nel differenziarsi dalla concorrenza!
Ecco disegnato lo schema elettrico del circuito di Tweetino: si tratta di fatto dei collegamenti standard per l’LCD, cui si aggiunge l’uso di una uscita PWM per regolare il contrasto (con le variazioni rese più “smooth” da un condensatore) e di un LED che segnala quando il programma sta aggiornando il tweet corrente da internet. Da notare che la scarsità di uscite dovuta alla scheda ethernet sull’Arduino Uno obbliga ad usare anche i pin 0 e 1, e di conseguenza a non poter più usare la connessione seriale nella versione finale del programma.
Appena arriva l’LCD 16×2, metto tutto nella scatola adatta e pubblico le foto finali!
I’ve just released the first version of Tweetino, a little sketch for the Arduino which downloads the latest tweets and displays them on an LCD.
The idea is quite simple: the application periodically polls the Twitter servers for getting the latest tweet for the given user, and then the text is shown on a screen; there is already a similar sketch in the new Ethernet libraries for Arduino IDE 1.0, but the difference here is that the connection to the servers uses OAuth, so it is able to get tweets from private accounts (and not just the public ones, like the other implementation cited before).
The code is hosted on Github, as usual, and it has to be filled with several details before being used, in particular it needs the token and access keys that a user can obtain from dev.twitter.com by registering a new application; in particular, the secret keys are to be stored in the EEPROM memory before launching the Tweetino application. Please refer to the README file for more details.
Remarks
First and foremost: I know that a good OAuth implementation should be developed in a separated library, instead of being entangled with the whole program, but the problem is that I’m testing everything on an Arduino Uno, which has just 2 KB of SRAM and OAuth requires some string manipulation, and there is not much space for it; moving everything in an external library requires some work which I have not done (yet), so for now just play around with the current code. Probably an Arduino Mega would help the development (having 8 KB of SRAM), but I don’t have any. Besides, trying to stick everything in just 2 KB has been quite fun.
Second, there is a known bug (sorry!): the Base64 library that I’m using sometimes returns a wrong value (at least with respect to the Erlang code implementation to which I am doing comparisons), and the request is refused by Twitter; given this fact (and the fact that I have no idea, for now, on the cause of the error), I have just added some code to repeat the request a few times in each cycle, in the hope that at least one of the calls behaves correctly. So, don’t expect some real time behavior!
Non so perchè mi ero perso questa cosa, ma è disponibile da maggio ormai la versione beta della 1.0 di Arduino IDE; i tarball si possono trovare qui, mentre il branch Git è qui.
Sì, so che è software non ancora stabile, ma a parte il fatto che questo non mi ha mai fermato, la cosa importante (almeno per me, oggi) è che il client DHCP funziona. Fino alla versione 0.22, infatti, era necessario utilizzare una libreria esterna che a me personalmente ha sempre dato problemi; in particolare, con Arduino Uno e l’Ethernet Shield di Adafruit, le richieste inviate al server DHCP sono malformate la maggior parte delle volte e la scheda non riesce a rispondere al DHCPOFFER, di fatto impedendo l’acquisizione di un indirizzo IP corretto.
Con la nuova versione dell’IDE, le librerie ethernet hanno (finalmente) incluso tutte le funzionalità di indirizzamento dinamico, e lo sketch di esempio per DHCP ha funzionato al primo colpo; questo mi basta a decidere di passare a questa versione (direi definitivamente, ma questo lo stabilirò solo dopo ulteriori test). Presto vi farò sapere quali seghe mentali esperimenti ho in ballo…
Ecco le slides della presentazione dell’articolo prodotto a partire dal mio lavoro di tesi magistrale; la conferenza in questione è TOOLS Europe 2011, tenutasi a Zurigo dal 28 al 30 giugno 2011.
Dopo il discorso di ieri di Richard Stallman, ho iniziato a pensare al software installato nel mio PC, e che uso abitualmente e negli ultimi tempi, e riporto qui la riflessione se sia veramente possibile abbandonare completamente il software proprietario e passare interamente a quello libero. Premetto che io non ho alcun problema nell’uso del software proprietario, quando funziona ovviamente, anche se preferisco il software libero se ho la possibilità di scegliere.
Ecco le parti proprietarie che ho installate nel PC in questo momento (tra parentesi ho indicato sia la motivazione dell’uso di quel software, sia se la sostituzione con alternativa free sia possibile):
driver ATI (supporto completo alla mia scheda video sul Dell): questi valgono solo per uno dei miei computer, e l’ultima volta che ho controllato non mi era possibile abbandonarli, dato che quelli free non supportavano il throttling della potenza (quindi temperatura a 70+ gradi); ammetto di non aver controllato l’ultima versione (FORSE NO, ma nel caso solo sul Dell)
Google Chrome (scelto in alternativa a Chromium dato che utilizzo molti servizi di Google, e suppongo questo garantisca una migliore integrazione): facilmente sostituibile con Chromium, non so effettivamente quali funzionalità perderei, ma non credo sarebbe una tragedia (in fondo ho usato per anni Firefox, alla peggio potrei tornare a quello) (SI)
Oracle JDK (miglior JDK per Java): qui bisognerebbe verificare, dato che utilizzo Java per lavoro e di conseguenza non so se OpenJDK sia compatibile per le funzionalità di cui io ho bisogno (FORSE SI)
Dropbox (comodo per condividere file tra i miei computer): software non essenziale alla mia esistenza, ma di nuovo lo utilizzo (tra le altre cose) per lavoro; potrei comunque accedervi dalla sola interfaccia grafica. Non esiste un’alternativa libera (SI)
Mono (software che uso da parecchio tempo, ed in cui ho salvati parecchi dati): utilizzo due software basati su C#, Tomboy e F-Spot; possono essere sostituiti con alternative basate su altri linguaggi (SI)
Flash Player (incluso in Chrome): la stragrande maggioranza del mio uso di Flash è per i video di Youtube, e dato il supporto di quest’ultimo ad HTML5, non dovrebbero esserci problemi a segarlo (SI)
I formati:
codec video: potrei anche rinunciare alla libdvdcss, e guardare i DVD in un lettore da tavolo, ma non so se potrei farlo anche con i DivX, dato che VCast non supporta formati liberi come OGG Theora; di fatto, queste sono le mie fonti principali di video (NO)
codec audio: l’abbandono dell’mp3 implicherebbe due cose, ovvero procurarsi un lettore con supporto ad OGG Vorbis (esistono, ma sono ben pochi) e non comprare più musica online, dato che praticamente tutti i rivenditori usano gli mp3. Certo, una volta acquistati si possono riconvertire, ma questo implicherebbe comunque sostenere il mercato degli mp3 stessi, cosa che resterebbe comunque sbagliata. Certo, potrei continuare a comprare CD, ad un prezzo superiore e in direzione contraria rispetto alla mia idea di passaggio completo al digitale (NO)
libri: epub è un formato libero, ma avrei comunque bisogno di un convertitore verso mobi per poter usare il Kindle, senza contare il fatto che i libri di Amazon sono protetti a loro volta da DRM (come gli epub italiani, peraltro). Certo, il problema di conversione si risolverebbe con un lettore tipo il Nook (che, detto per inciso, ha l’aria di essere spettacolare, anche meglio del Kindle), ma l’acquisto di epub con DRM sarebbe come acquistare mp3 per poi convertirli in ogg (NO)
Da questo elenco si deduce come il vero problema, oggi come oggi, sia sui formati multimediali più che sui programmi in sè (di fatto, ad oggi l’unico software che da informatico ho usato in versione proprietaria per la mancanza di alternative valide è Matlab). Questo in parte si potrebbe risolvere non appena le case editrici capiranno la cazzata del DRM e inizieranno a vendere epub aperti. A quel punto resterà la sola questione dell’audio.
Syvo3 