martedì 22 novembre 2011

Human Machine Interface, quando le macchine parlano e sentono

Nel post di oggi vorrei mostrarvi un progetto sperimentale di Interfaccia Utente, realizzato alcuni anni fa (nel 2004 ...come passa in fretta il tempo!). Tuttavia il progetto resta ancora attuale, salvo qualche aggiornamento nei singoli componenti che, troppo spesso, hanno un ciclo di vita piuttosto breve.

(click sull'immagine, per ingrandire)

Il tema fondamentale è ancora quello di come realizzare delle macchine che possano interagire in maniera efficace con l'utente e di come realizzare interfacce intuitive ed efficienti, ...in poche parole di come dosare le "palline" dello zucchero quando prendiamo il caffè alla "macchinetta" aziendale (operazione che in effetti richiede ...un minimo di esercizio! Vero?). Prima di scendere nei dettagli, guardiamo insieme il video che ho realizzato per Voi:


State ancora ballando al ritmo Techno di NeXus? Noooo? Nell'elettronica un pò di musica non guasta! Ok, i file MP3 li scarico prevalentemente da jamendo.com, attenendomi, strettamente, al tipo di licenza con cui l'Autore distribuisce i contenuti qui sul Pianeta Terra. A proposito, la licenza di questo blog è Creative Commons - BY - NC - SA, stesso discorso per i video sul canale YouTube "liberaelettronica".


Nel video abbiamo visto delle card colorate che vengono posizionate in prossimità di un avvolgimento. Si tratta di TAG RFID (Radio Frequency IDentification) il cui funzionamento è ben illustrato nella pagina Wikipedia che trovate qui. Display LCD e Tastiera 4x4, meritano forse minore attenzione, ma restano pur sempre un elemento fondamentale nell'interazione con la Macchina. L'applicazione prevedeva anche ingressi analogici a 12bit, ingressi digitali optoisolati e uscite digitali a transistor e relè.
Da notare che, nel circuito che vi propongo nella seguente figura, le macchine possono comunicare anche tra loro e, pertanto, utilizzare canali di comunicazione quali Reti GSM (telefoni cellulari) e Reti Intranet/Internet. Dovremo quindi provvedere a realizzare le dovute interfacce (nel nostro caso una porta seriale RS232 per il modem GSM e un Core Module XPORT per le connessioni Ethernet e TCP/IP).


Pubblicare tutto il codice ANSI C di questa applicazione risulterebbe eccessivamente pesante per il blog, ma è disponibile per coloro che me lo richiederanno via email.
Vi anticipo solo un frammento di codice per leggere dalla tastiera 4x4:

/* key pad 16 layout
    1   2   3   F
    4   5   6   E
    7   8   9   D
    A   0   B   C
*/

unsigned char keypad16_read(void) {

    unsigned char scan, tmp_scan, col, col_drive, ret_code;

    /* init column driver */
    col_drive = 0x0E;

    /* scan row by col (low=key pressed) */
    for (col=0; col<4; col++) {   

        /* set column (PG0,1,,3) */
        P2_reg &= 0xF0;
        P2_reg = P2_reg | (col_drive & 0x0F);
        P2 = P2_reg;

        /* read row (EXP0,1,,3) */
        scan = P3 & 0x3F;
        scan >>= 2;

        /* if key pressed and hold */
        if ((scan & 0x0F) < 0x0F){

            delay_ms(10);
            tmp_scan = P3 & 0x3F;
            tmp_scan >>=2;

            if (tmp_scan == scan) {
                /* compose scan code */
                scan = scan | (col_drive << 4);

                /* ASCII conversion */
                switch (~scan) {

                    case 0x88 : ret_code = '1'; break;
                    case 0x84 : ret_code = '2'; break;
                    case 0x82 : ret_code = '3'; break;
                    case 0x81 : ret_code = 'F'; break;
                    case 0x48 : ret_code = '4'; break;
                    case 0x44 : ret_code = '5'; break;
                    case 0x42 : ret_code = '6'; break;
                    case 0x41 : ret_code = 'E'; break;
                    case 0x28 : ret_code = '7'; break;
                    case 0x24 : ret_code = '8'; break;
                    case 0x22 : ret_code = '9'; break;
                    case 0x21 : ret_code = 'D'; break;
                    case 0x18 : ret_code = 'A'; break;
                    case 0x14 : ret_code = '0'; break;
                    case 0x12 : ret_code = 'B'; break;
                    case 0x11 : ret_code = 'C'; break;

                    default : ret_code = 0;
                }

                break; /* terminate for cicle */

            } else {
                /* key spike */
                ret_code = 0;
            }
        } else {
            /* no key pressed */
            ret_code = 0;
        }

        /* set column driver for the next column */
        col_drive <<= 1;
        col_drive |= 0x01;
    }

    return ret_code;
} 

Qui Pianeta Terra ...ove le macchine hanno un ruolo sempre crescente, a presto.

giovedì 17 novembre 2011

L'Elettronica Open Source

Oggi una novità per i lettori di Libera Elettronica!
Siamo, insieme, presenti su una delle comunità italiane più ampie dell'open source ...soprattutto per ciò che riguarda l'elettronica.


Non è merito mio, è merito Vostro!
Nel seguente link (http://it.emcelettronica.com/portuxg20-embedded-linux-getting-started) potete trovare il nostro primo articolo sull'utilizzo di un computer embedded Linux. Altri articoli seguiranno.



Qui Pianeta Terra, a presto!

venerdì 4 novembre 2011

Un Robot alla guida - Parte 3

Aggiungiamo ancora un tassello al nostro Autopilota/Navigatore; oggi parliamo del GPS (Global Positioning System), che è ormai abbastanza noto ai più anche grazie alle diffuse applicazioni in campo "consumer", prevalentemente nel settore automobilistico ...ma non solo.

(moderno ricevitore GPS con Antenna integrata ...un francobollo!)

Più in generale, dobbiamo immaginare il GPS (sistema estremamente complesso se esaminato dal punto di vista tecnico e nelle sue varie componenti o segmenti) come uno degli elementi principali di quelle applicazioni che prendono il nome di GNSS (Global Navigation Satellite System). Vorrei rimandare, per coloro che sono interessati ad un approfondimento tecnico, la descrizione di tutti i dettagli a documenti specializzati sull'argomento. Ne esistono tanti e alla fine dell'articolo vi riporterò la mia personale bibliografia ...può esservi utile.

(mappa 3D georeferenziata del basso Lazio)

Tra i vari componenti dei sistemi GNSS, di cui il GPS fa parte, è importante ricordare che dal 1 Ottobre 2009 è attivo in Europa il servizio EGNOS (European Geostationary Navigation Overlay Service). Tale servizio consente, mediante una complessa rete di Stazioni Terrestri e Ripetitori Satellitari Geosincroni, di implementare la cosiddetta "correzione differenziale" su scala geografica (...continentale appunto!).
In breve, possiamo riepilogare così, per punti, la recente storia del servzio di geolocalizzazione satellitare:
  • Il sistema GPS fu progettato agli inizi degli anni '70 dal US-DoD (Department of Defense, Stati Uniti) e divenne pienamente operativo, anche per uso civile, nel 1994. Il grado di accuratezza, in quegli anni, era un CEP (Circle of Equiprobalility) di circa 100 metri. Contemporaneamente e per gli stessi scopi bellici, l'URSS, realizzava il sistema GLONASS, concettualmente equivalente al GPS made in USA.
  • In data 1 Maggio 2000, il presidente degli Stati Uniti - Bill Clinton - decretò l'abolizione del SA (Selective Availability), un sottosistema che limitava la precisione del GPS per gli usi civili e, pertanto, il CEP passò da 100 m a 10-15 m.
  • In data 1 Ottobre 2009, l'Agenzia Spaziale Europea (ESA) iniziò la diffusione pubblica dell'Overlay EGNOS, portando il CEP a circa 2 m. (Nota: EGNOS è l'equivalente del sistema WASS operativo in Nord America).

(confronto tra mappa Google e mappa 3D
di un percorso GPS, andata e ritorno,
da/al Porto Turistico di San Felice Circeo)

Poche righe non possono certo condensare quaranta anni di evoluzione tecnologica, ma è interessante osservare come il servizio GNSS, costituito da GPS + EGNOS + GLONASS + (futuro GALILEO), condurrà l'accuratezza della localizzazione 3D, sul nostro caro Pianeta Terra, dalla grandezza del Metro a quella del Decimetro.
In questo scenario nuovi servizi potranno essere migliorati o, talvolta, inventati from scratch. Pensiamo, ad esempio, alla possibilità di tracciare la nostra posizione o quella di un Robot, su di una mappa e con la risoluzione del Centimetro!
Incredibile ...fino a pochi anni fa!!!

Ma come possiamo utilizzare un ricevitore GPS nelle nostre applicazioni "embedded"?
Semplice! Un moderno ricevitore (es. Garmin GPS 18x OEM), mediante una interfaccia UART (Universal Asyncronous Receiver Transmitter), ci invierà dei messaggi periodici nei quali è contenuta la nostra posizione sul geoide Terra, secondo il modello WGS-84.
Tali messaggi, definiti Sentenze, saranno codificate in accordo allo standard NMEA 0183 oppure in formato proprietario. I formati proprietari, ovviamente, variano da costruttore a costruttore (...sono in tanti ormai) e dovranno essere interpretati "manuali tecnici alla mano", mentre i formati standard risultano tutti normalizzati.
Nel seguente esempio Vi riporto la Sentenza GPRMC (Minimum Required - Type C) che rappresenta un comune denominatore per molti ricevitori OEM:

Sentenza RMC - 12 campi + Header $GPRMC + Trailer XX Hex Chk

$GPRMC,      Carattere di sincronismo '$' e denominazione GPRMC
171429,      Orario Fix [hhmmss]
A,           A=Fix valido, V=Warning (msg. non valido)
4113.5304,   Latitudine 41° 13.5304 secondi d'arco decimali
N,           N=Emisfero Nord, S=Emisfero Sud
01305.7166,  Longitudine 013° 05.7166 secondi d'arco decimali
E,           E=Quadrante Est, W=Quadrante Ovest
000.0,       Velocità in Nodi (Ground Speed!!!)
000.0,       Direzione Geografica (...non magnetica!!!)
200509,      Data Fix [ggmmhh]
001.8,       Deviazione magnetica rispetto a dir. geografica
E            Quadrante di deviazione magnetica
*7D          Checksum per verifica integrità messaggio

Questo messaggio, ad esempio, potrà essere ricevuto dal nostro microcomputer embedded, mediante una interfaccia RS232, RS422 o RS485, e consentirci, così, di elaborare la posizione del veicolo (automobile, aereo, imbarcazione, ...pedone, animale, robot!) in coordinate ECEF (Earth Fixed Earth Centered) o altro sistema di coordinate, se richieste.

(fare click per ingrandire)

Vediamo, ora, alcuni testi consigliati per approfondire l'argomento. Vi ricordo che per migliorare il grado di 'accuracy' nella determinazione della posizione è opportuno correlare l'output del sensore GPS con l'output del sensore inerziale-geomagnetico. Tale combinazione ci porterà alla realizzazione di un sensore GPS-INS (GPS-Inertial Navigation System) ...come è appunto il nostro Progetto Open di "Robot alla Guida".

Ecco i titoli:
  1. The Global Positioning System & Inertial Navigation - Farrel & Bath
  2. Strapdown Inertial Navigation Technology, Second Edition (Progress in Astronautics and Aeronautics) - Titterton & Weston
  3. Applied Mathematics in Integrated Navigation Systems, Third Edition - Rogers
  4. Quaternions and Rotation Sequences: A Primer with Applications to Orbits, Aerospace and Virtual Reality - Kuipers
Qui Pianeta Terra, un mondo reale ed un modello matematico, in cui orientarsi e navigare!

venerdì 28 ottobre 2011

Navighiamo in 3D

Cari Amici del blog, oggi desidero parlarvi delle Mappe Georeferenziate SRTM (Shuttle Radar Topography Mission). Il progetto SRTM è da considerare uno sforzo colossale, organizzato dalla NASA e da altre Agenzie spaziali (ASI compresa), finalizzato alla realizzazione di un Data Base in 3D dell'intera superficie del nostro Pianeta Terra.

 


Nella precedente immagine vedete graficamente in cosa consiste l'output del progetto SRTM: una miriade di file altimetrici, detti TILE, perfettamente georeferenziati, che riportano in formato numerico l'altezza sul livello del mare (S.l.m.) di ogni rilievo, collina, montagna (isole e isolette, comprese), sparse per il nostro globo terraqueo ...una vera e propria manna per chi è interessato alla realizzazione di un autopilota/navigatore che, scherzosamente, nei precedenti post ho definito come "Un Robot alla Guida".

Come possiamo utilizzare i file HGT del progetto SRTM3?
Procediamo per passi ...e guardiamo insieme le relative immagini!

1) Aggiungiamo il Mare

2) Aggiungiamo il Sole

3) Aggiungiamo una Foto Satellitare dell'area di interesse

4) Elaboriamo l'immagine con un Ombreggiatore 3D ...e il gioco è fatto!!!
(Click per ingrandire - Golfo di Napoli, Penisola sorrentina, Capri)

Nella precedente foto abbiamo visto il risultato in una delle tante possibili viste prospettiche. Ma andiamo più in dettaglio e vediamo, con la prossima foto, cosa ci offre il Data Base SRTM3 con la sua risoluzione di 3'' Arco per Pixel.

Questa non è un immagine del Paneta Luna, il nostro caro satellite naturale, ma rappresenta una mappa ombreggiata dei Campi Flegrei, ovvero un'area vulcanica che si estende dalla Collina di Posillipo (Napoli) al Golfo di Pozzuoli e che comprende numerosi Comuni, situati in questa meravigliosa area storico-paesaggistica, ricchi di panorami mozzafiato e reperti archeologici.

Nella prossima immagine, estendendo un pò lo sguardo verso Sud, vediamo...


 ...in primo piano i Campi Flegrei, poi, il monte Vesuvio e, poi, un tratto della Penisola sorrentina.
Qui il tutto si vede meglio salendo sugli appennini al confine con la Provincia di Avellino...

...e qui in vista aerea.


Per gli amanti del "codice C", riporto il listato di un semplice programma utilizzabile per convertire un file HGT in formato BMP, meglio "digeribile" dai nostri PC.

/* SRTM Tile to BMP simple program */

#include <stdio.h>
union t_height {
    unsigned char in_chr[2];
    short height;
} t_height;
/* image buffer */
char buffer[1200][1200][3];

int main() {
    /* file pointer */
    FILE * fdin;
    FILE * fdout;
    /* array index */
    int x,y;
    /* color components */   
    char color_r;
    char color_g;
    char color_b;
    /* other */
    int min = 0;
    int max = 0;

    char bmp_header[] = {
        0x42, 0x4D, 0x36, 0xEB, 0x41, 0x00, 0x00, 0x00,
        0x00, 0x00, 0x36, 0x00, 0x00, 0x00, 0x28, 0x00,
        0x00, 0x00, 0xB0, 0x04, 0x00, 0x00, 0xB0, 0x04,
        0x00, 0x00, 0x01, 0x00, 0x18, 0x00, 0x00, 0x00,
        0x00, 0x00, 0x00, 0xEB, 0x41, 0x00, 0x00, 0x00,
        0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
        0x00, 0x00, 0x00, 0x00, 0x00, 0x00   
    };
   
    /* open SRTM tile file */
    fdin = fopen("N40E014.hgt", "r");
    if(fdin != NULL) {
        printf("Input file opened.\n");
    } else {
        exit(0);
    }   
    /* transcondig loop */   
    for(y=0; y<1200; y++) {
        for(x=0; x<1200; x++) {
            t_height.in_chr[1] = fgetc(fdin);
            t_height.in_chr[0] = fgetc(fdin);

            /* set color pixel */
            if (t_height.height == 0) {
                color_r = 0;
                color_g = 0;
                color_b = 128;
            } else if (t_height.height > 0) {
                color_r = t_height.height / 7;
                color_g = color_r;
                color_b = color_r;
            }
            buffer[x][y][0] = color_r; //red
            buffer[x][y][1] = color_g; //green
            buffer[x][y][2] = color_b; //blu      
            /* update min, max */
            if (t_height.height > max) {
                max = t_height.height;
            }
            if (t_height.height < min) {
                min = t_height.height;
            }                      
        }
        /* discard pixel 1201 */
        t_height.in_chr[1] = fgetc(fdin);
        t_height.in_chr[0] = fgetc(fdin);
    }   
    /* close .hgt files */
    fclose(fdin);
    /* open BMP file */
    fdout = fopen("SRTM.bmp", "w");
    if(fdout) printf("Output file opened.\n");
    /* write BMP 1200x1200 header */
    for(x=0; x<54; x++) {
        fputc(bmp_header[x], fdout);
    }
    /* write image buffer to BMP data area */
    for(y=1199; y>=0; y--) {
        for(x=0; x<1200; x++) {
            fputc(buffer [x][y][2], fdout); //blu
            fputc(buffer [x][y][1], fdout); //green
            fputc(buffer [x][y][0], fdout); //red
        }
    }   
    fclose(fdout);
    /* message */
    printf("Min: %d  Max: %d\n", min, max);
    printf("Conversion complete.\n");
    /* terminate program */
    return 0;
}

Nei prossimi post vedremo come utilizzare le Mappe SRTM nel nostro navigatore fai-da-te e vedremo anche come utilizzare il file-system Linux in abbinamento al Displey TFT a colori.

Qui Pianeta Terra ...in 3D, a presto.

sabato 22 ottobre 2011

Un Robot alla guida - Parte 2

Continuando con la nostra rassegna delle applicazioni robotiche dedicate alla guida dei veicoli (il precedente post lo travate qui), oggi esamineremo le potenzialità dei Sistemi Embedded nel controllo dell'assetto e della posizione, di uno Yacht ad alte prestazioni.

(prototipo del microcomputer di bordo)

Nella figura seguente viene rappresentata l'architettura del sistema di controllo con alcuni organi meccanici ...o meglio idrodinamici, coinvolti nella catena di controllo.
Come già descritto nei precedenti post, il sistema è basato su di una serie di sensori (giroscopi, accelerometri, magnetometri, misuratori di pressione, GPS, ecc.) e ha per obiettivo la stima dell'assetto (angoli euleriani) e della posizione sul geoide terrestre (sistema Earth Centered Earth Fixed - ECEF) secondo il modello WGS-84, e la conseguente regolazione degli organi attuatori (fin, flap, drive, rudder, thruster, ecc.).
Lo scopo è quello di migliorare la stabilità ed il comfort, e di agevolare la navigazione.

(fare click per ingrandire)

Perché utilizzare un sistema robotico quando possiamo manovrare manualmente i singoli organi? Alcune risposte proverò a fornirle nel seguente elenco:

  • Le condizioni del vento e delle correnti, mutano in continuazione, per non parlare della posizione dei nostri ospiti e del loro bagaglio. Dopo aver perfettamente "trimmato" l'assetto e  le eliche, ci ritroveremo a dover continuamente "correggere", mediante i joystick presenti in plancia, le nostre impostazioni.
  • Il bilanciamento dinamico del rollio, sia in condizioni di navigazione e sia "all'ancora" è impossibile da ottenere manualmente (non siete mica dei robot!) e occorre, quindi, un automatismo.
  • Le imbarcazioni navigano lungo rotte iso-magnetiche o mediante Way Point georeferenziati ...non è il caso di procedere "a occhio", meglio andare dritti che a zig-zag. Oltretutto si arriva prima e si consuma meno carburante!
  • Anche le manovre in porto, con vento al traverso, risultano particolarmente complesse. Meglio sarebbe avere un controllo automatico di Heading e Posizione, magari con il prezioso ausilio delle eliche di manovra.
  • Un Computer Embedded provvederà anche a completare tutti i controlli pre e post missione. Avete controllato le Vs. dotazioni di sicurezza. Si? Ok, prima di tutto la sicurezza!
Se vi state chiedendo in quali casi occorre un "robot alla guida", ecco alcuni esempi ...per immagini.
 (fare click per ingrandire, ne vale la pena!)

Bene, il dimostratore è stato completato, è un progetto Open ed è a Vs. disposizione ...pronto a raggiungervi nella sua valigetta Flight Case.


Qui Pianeta Terra, il cui 70% è coperto dai mari, a presto.