giovedì 9 aprile 2015

Android come tavoletta grafica

A seguito del precedente post ho visto con un po' di sorpresa che il tablet che mi e' stato prestato e' un Panasonic FZ-A1 che monta un digitalizzatore Wacom (per essere piu' precisi un Penabled, basato su tecnologia EMR e quindi in grado di avere la posizione del mouse anche se il pennino non poggia sullo schermo link)




Mi e' venuta cosi' l'idea di poterlo utilizzare, nonostante lo schermo rotto, come tavoletta grafica per disegnare....ovviamente qualcuno ci aveva gia' pensato e la soluzione e' stata GfxTablet 

GfxTablet e' costuita da una coppia di applicazioni, una client da montare sul tablet Android ed una server da montare su una macchina Linux. Il client cattura la posizione dello stilo sul tablet ed il livello di pressione e lo manda al server sul PC che converte i dati. La trasmissione avviene su protocollo UDP in porta 40118

L'applicazione Android e' stata ricompilata direttamente  partendo dai sorgenti cosi' come la parte server (su una macchina Ubuntu 14.10). In nessuno dei due casi ci sono stati particolari problemi di compilazione

A questo punto si lancia l'applicazione sui due dispositivi configurando sul client l'ip della macchina server e se tutto e' andato a buon fine si vedra' il cursore di XWindow muoversi come la penna sulla tavoletta.
(per verificare si digiti il comando xinput list e dovra' comparire un dispositivo Network Tablet)

Questo sistema puo' essere anche usato per disegnare con Gimp configurando opportunamente il device di input dal menu Modifica/Preferenze/Dispositivi di ingresso

Di seguito uno screencast per vedere piu' in dettaglio la fluidita' del sistema
Sul terminale in background c'e' l'applicazione networktablet che riceve di dati mentre in primo piano Gimp comandato dal tablet Android


L'aspetto utile e' che questo sistema funziona wireless.

Prendere il controllo di un tablet Android con schermo rotto

Mi e' stato prestato (per vedere se lo recuperavo in qualche modo) un tablet Android con lo schermo all'80% distrutto. Il digitalizzatore e tutto il resto funzionano correttamente



Cercare di interagire con il tablet in queste condizioni e' a dir poco proibitivo ma usando Droid at Screen si puo' replicare su computer via cavo Usb il display di Android
Ci sono un po' di limitazioni
1) il sistema deve essere settato in Debug Mode. Fortunatamente nel mio caso era gia' cosi' altrimenti si puo' via Adb forzare via recovery

Adb shell 
echo "persist.service.adb.enable=1" >>/system/build.prop 
echo "persist.service.debuggable=1" >>/system/build.prop 
echo "persist.sys.usb.config=mass_storage,adb" >>/system/build.prop" 
reboot

(sorgente


2) non c'e' un puntatore per cui si deve cliccare piu' o meno a caso sull'icona del tablet una volta presa la mira guardando l'immagine sul desktop

In questo modo si possono effettuare operazioni base (io per esempio sono riuscito ad agganciarlo al WiFi)

venerdì 3 aprile 2015

Cron fork crash

Un amico mi ha contattato perche' la sua macchina di acquisizione dati (Ubuntu 14.04 su una macchina DELL certificata Linux) nella notte ha crashato con reboot e perdita di dati
La macchina e' esposta con indirizzo pubblico su Internet ma non ha servizio Web (solo SSH ed altri sistemi di controllo remoto)

I sintomi dal syslog sono una serie di errori
-----------------------------------------------------
Mar 10 06:38:01 apollo CRON[2745]: (apollo) CMD (/home/apollo/xxxxxxxxx)
Mar 10 06:38:01 apollo CRON[28701]: (apollo) MAIL (mailed 1 byte of output; but got status 0x00ff, #012)
Mar 10 06:34:01 apollo CRON[16435]: (apollo) CMD (/home/apollo/xxxxxx)
Mar 10 06:39:01 apollo CRON[18558]: (CRON) error (can't fork)
Mar 10 06:39:01 apollo CRON[16435]: (CRON) error (can't fork)
-----------------------------------------------------

con l'ultimo messaggio prima di fare reboot
-----------------------------------------------------
Mar 10 08:49:27 apollo xinetd[27808]: service telnet: too many consecutive fork failures
Mar 10 09:22:16 apollo xinetd[27808]: telnet: fork failed: Cannot allocate memory (errno = 12)
Mar 10 09:22:36 apollo xinetd[27808]: message repeated 4 times: [ telnet: fork failed: Cannot allocate memory (errno = 12)]
Mar 10 09:22:36 apollo xinetd[27808]: service telnet: too many consecutive fork failures
-----------------------------------------------------

mi viene detto che e' stato installato il servizio telnet perche' la macchina non era piu' raggiungibile via SSH (insieme a telnet erano stati installati ShellInABox, Vino e NoMachine)
Nei log erano presenti connessioni da tutto il mondo su telnet

-----------------------------------------------------
Mar 10 05:32:40 apollo in.telnetd[28701]: connect from xx.xxx.x.xxx (xx.xxxx.x.xxx)
-----------------------------------------------------

il primo consiglio e' stato quello di spengere tutti i servizi non necessari, in particolare telnet (al giorno d'oggi e' sostanzialemente obsoleta)

Il mattino dopo la macchina presentava un normale traffico di rete solo sulla rete interna ma nella notte era andata di nuovo in crash con un ultimo messaggio
-----------------------------------------------------
Mar 11 03:34:01 apollo cron[1163]: (CRON) error (can't fork)
-----------------------------------------------------
di nuovo un crash su un fork

a questo punto e' partita la ricerca sul colpevole. La macchina lavorava al 5% della CPU con la Swap libera quindi in condizioni sostanzialmente ottimali ed eseguiva uno script una volta al minuto che elabora dei dati acquisiti e invia i risultati ad un'altra macchina. Lo script era costituito da diverse fasi la somma dei tempi di ciascun passo era nettamente inferiore ad un minuto, non era quindi possibile la sovrapposizione di piu' lavori in cron che potessero generare una fork bomb

Guardando meglio e' emerso pero' che l'ultimo passo copiava i dati sulla macchina remota mediante un comando rsync un solo file (peraltro sempre dello stesso nome) ed e' stato visto che la directory di arrivo era costituita da una moltitudine di file. Il numero dei file nel server di arrivo rendevano rsync molto lenta e cio' creava il sovrapporsi dei cron ogni minuto per arrivare a saturare le risorse acccumulandosi lavoro con il tempo

Sostituito il comando rsync con scp la macchina ha ripreso a lavorare senza interruzioni



HTML Dom Parser in PHP

In questo post viene descritto come estrarre i dati da una pagina HTML. Cio' mi e' stato richiesto perche' una ditta offre un servizio di pubblicazione dati (peraltro forniti con licenza Common Creative) in formato CSV solo a seguito di autenticazione mediante un Captcha impedendo di fatto il download automatico

I medesimi dati sono pero' pubblicati anche all'interno di una tabella di una pagina HTML piuttosto complessa. Per "catturare" i dati si puo' analizzare il Document Object Method HTML (DOM) mediante la libreria Simple HTML Dom (http://simplehtmldom.sourceforge.net/) che indicizza i tag e permette di creare per esempio degli array php a partire da tag table

una volta importata la pagina html (anche da un link web oltre che file) nell'esempio sottostante e' stata selezionata la seconda tabella presente nel codice (linea evidenziata in giallo). Il contenuto della tabella e' salvato nell'array rowData

--------------------------------------------------------
<?php
require('simple_html_dom.php');
$html = file_get_html('http://xxxxxxx');

$table = $html->find('table', 2);
$rowData = array();

foreach($table->find('tr') as $row) {
    $flight = array();
    foreach($row->find('td') as $cell) {
        $flight[] = $cell->plaintext;
    }
    $rowData[] = $flight;
}
--------------------------------------------------------

La libreria funziona anche su pagine html non perfettamente formattate (per esempio con tag aperti e non chiusi)

giovedì 2 aprile 2015

Ubuntu 14.10 su Lenovo X201

Avendo fretta di mettere in servizio un Lenovo X201 ho installato su questa macchina Ubuntu al posto della mia solita Debian sperando di non aver problemi..vana speranza.

Al riavvio della macchina non funzionava il touchpad mentre era possibile muovere il mouse mediante il trackpad (il piccolo joystick rosso al centro della tastiera tipico delle macchine IBM/Lenovo)




la soluzione e' stata inserire i seguenti comandi
modprobe -r psmouse 
modprobe psmouse proto=imps

la soluzione definitiva e' quella di creare un file /etc/modprobe.d/psmouse.conf con all'interno
options psmouse proto=imps
un altro problema veramente fastidioso e' che la tastiera, nonostante in fase di installazione fosse stata indicata la lingua italiana, era rimasta settata in inglese/americano. So scrivere su una tastiera muta americana ma e' veramente difficile ricordarsi la posizione di tutti i caratteri speciali (tipo apice inverso)


Con un po' di settaggi sono riuscito a settare in italiano GNOME ma nel momento in cui aprivo una shell di terminale la tastiera ritornava in inglese. Questo problema si e' risolto da solo a seguito di un aggiornamento automatico ma mi ha perseguitato per febbraio e marzo 

Google Maps vs Openlayers

Ho praticamente sempre usato Google Maps per fornire informazioni geografiche via Web ma ultimamente mi e' stato richiesto che


  1. Fosse possibile avere un evento mouseover quando il cursore passa su marker in modo da avere le informazioni senza necessariamente cliccare
  2. Usare gif animate come icone dei marker
  3. L'aggiornamento dei dati via KML doveva essere in tempo reale
Ho quindi dovuto affrontare Openlayers come piattaforma alternativa


Di seguito un medesimo file kml con due vestizioni differenti in Openlayers e GMaps
Openlayers
Google Maps
Un po' di indicazioni di confronto
  • GoogleMaps non permette di fornire dati realtime quando si usano i KML. Di fatto i layer Kml vengono gestiti dai server di Google ed hanno un tempo di cache variabile anche superiore ai 15 minuti; con Openlayers invece la pubblicazione e' completamente gestita in proprio senza nessun ritardo
  • GoogleMaps non ha un evento mouseover quando si usano i kml. In Openlayers la funzione puo' essere programmata
  • GoogleMaps ha una comodo InfoWindow mente fornire informazioni contestuali con Openlayers e' piu' complicato e ci si appoggia a JQuery
  • Openlayers permette marker con gif animate mentre le animazioni su GMaps viene effettuata mediante trucchi e non in modo diretto
  • Openlayer non ha una base cartografica fissa, vengono usate varie sorgenti dati, e non esiste un layer di foto da satellite con dettaglio comparabile con quello di GMaps
  • Scrivere applicazioni per GMaps e' piu' semplice per gli esempi e la compattezza dei comandi. La corrispondente applicazione di Openlayer risulta essere un po' piu' complessa


Openlayers basato su http://openlayers.org/en/v3.4.0/examples/kml-earthquakes.html





giovedì 26 marzo 2015

Kinect v1 vs Kinect v2

Un po' di considerazioni sulla differenza tra Kinect 1 e Kinect2



Le maggiori differenze sono a livello dell'immagine RGB, passata da 640x480 a 1920x1080, ed IR, molto migliorata perche' e' presente in K2 un illuminatore infrarosso che rende la scena leggibile anche nel buio completo.

Per quanto riguarda il sensore di profondita' in K2 la matrice e' passata da 320x240 a 514x424 ma a causa dell'aumento dell'angolo di vista la densita' di punti per grado angolare e' solo passata da 5x5 pixel/grado a 7x7 pixel grado. Rimangono i problemi di acquisire la profondita' su oggetti molto scuri o di materiali particolari per cui la scena di profondita' puo' presentare dei buchi

Per prova ho ripreso in profondita' questi due oggetti, in particolare ero interessato a vedere se Kinect 2 riesce a vedere meglio i pulsanti del telecomando



Questa e' la visione di profondita' di K1 


mentre questa e' la visione di profondita' di K2

Non ci sono sensibili miglioramenti a parte il fatto che K2 produce una mappa piu' smussata perche' registra anche i decimi di millimetro