Oggi vorrei parlare di GPS.
Il GPS è un sistema di posizionamento globale basato su BLA BLA BLA…
Lasciamo le spiegazioni base a Wikipedia: https://it.wikipedia.org/wiki/Sistema_di_posizionamento_globale
Il GPS è la tecnologia che sta alla base del progetto OpenLapTimer, per questo motivo ve ne parlo.
Se ancora non conoscete il progetto, sul nostro blog c’è un articolo che lo racconta:
Alla base della scelta del GPS come tecnologia per creare un lap timer ci sono i suoi vantaggi:
- Consente di acquisire le posizioni fisiche ad intervalli regolari molto vicini, consentendo di ricreare le diverse traiettorie
- Permette di racchiudere in un unico dispositivo tutto quello che serve, eliminando le torrette emettitrici dei normali lap timer a infrarossi, che spesso si rischia di dimenticare in pista 🙂
Il sensore GPS ad intervalli regolari aggiorna la propria posizione rilevata dal satellite ed invia alla periferica a cui è collegato dei messaggi contenenti dati come:
- latitudine
- longitudine
- altitudine
- velocità istantanea
- bontà del segnale
- …
Un aspetto fondamentale per misurare l’efficacia di un buon GPS è la sua frequenza di aggiornamento, ovvero quante volte in un secondo riesce ad aggiornare la posizione rilevata. Nello specifico di applicazioni motorsport (date le alte velocità) è consigliabile avere una frequenza di aggiornamento di almeno 10hz (10 volte in un secondo) per ottenere dei buoni dati. Il rischio è ovviamente di avere posizioni rilevate molto distanti tra loro che andrebbero a falsare la vera strada percorsa.
La scelta per OpenLapTimer
Ho scelto un prodotto Adafruit, azienda di New York che realizza breakout su molti circuiti / sensori facilitando la fase di prototipazione dei prodotti.
Adafruit Ultimate GPS Breakout – 66 channel w/10 Hz updates – Version 3
La scelta si è basata su un ottimo rapporto prezzo/prestazioni e con i suoi 10hz di aggiornamento garantisce le performance ideali nel campo motorsport. Inoltre è dotato di un’interfaccia di collegamento seriale, il che consente una facile lettura delle informazioni che produce.
Protocollo dei dati
Il protocollo di comunicazione è l’NMEA 0183 (https://it.wikipedia.org/wiki/NMEA_0183), il quale definisce una serie di messaggi, ognuno dei quali con una struttura ben precisa contenenti alcune delle informazioni citate prima.
Ad esempio il messaggio $GPRMC (Reccomanded Minimum sentence)
$GPRMC,123519,A,4807.038,N,01131.000,E,022.4,084.4,230394,003.1,W*6A
contiene i dati minimi raccomandati come:
- la data di fix,
- lo stato del dispositivo (A active),
- latitudine,
- longitudine,
- la velocità,
- la data attuale
L’interfaccia seriale permette non solo di leggere i messaggi ricevuti dal GPS, ma al contempo di inviare dei comandi di impostazione.
I comandi che riceve il GPS possono impostare:
- frequenza di aggiornamento (1hz, 5hz, 10hz)
- quali tipi di messaggio vogliamo ricevere (RMC, GGA, GSV …)
- altre configurazioni
Calcolo riconoscimento traguardo
La terra è tonda (anche se qualcuno non ne è proprio convinto xD), latitudine e longitudine rappresentano le coordinate di un punto su di una sfera! Questo comporta una complicazione nel calcolo delle distanze percorse: va calcolata la lunghezza dell’arco tra due punti su di una sfera, non una semplice retta.
Nella particolare situazione in cui ci troviamo, ovvero registrare le posizioni GPS durante una corsa su un circuito, il tutto si svolge in un’area ristretta, quindi abbiamo introdotto l’assunzione che la terra fosse piatta (anche se in realtà è tonda! o no.. xD) semplificando di molto i calcoli come fossero su un piano cartesiano. Questa assunzione semplifica i calcoli rendendoli più semplici, quindi più rapidi, il che se consideriamo che devono essere eseguiti 10 volte al secondo, su di una piattaforma embedded, non è affatto male.
Ora abbiamo le posizioni GPS, sappiamo come calcolare le distanze come se fossimo in piano, ma come facciamo a capire se abbiamo attraversato il traguardo?
La nostra soluzione è la seguente:
Conoscendo la linea del traguardo descritta da due punti GPS (questi dati vengono impostati selezionando la pista in cui ci si trova), otteniamo un segmento
Ad ogni nuova posizione ricevuta dal sensore GPS si andrà a verificare se il segmento costruito dal nuovo punto e dal punto noto precedente va ad intersecare il segmento del traguardo.
Se c’è intersezione abbiamo tagliato il traguardo, altrimenti no
Semplice, no?
Con questa tecnica è impossibile che il passaggio sul traguardo non venga riconosciuto, anche se i punti sono tra loro molto lontani o molto vicini. Inoltre in questo modo è possibile anche determinare il punto GPS virtuale che si trova esattamente sul traguardo e, grazie alla velocità rilevata, andare a calcolare quanto tempo (di quel tratto) va assegnato al giro appena terminato e quanto invece va assegnato al giro appena iniziato, aumentando la precisione della rilevazione cronometrica.
Tutto questo sulla carta funziona.. Ma nel mondo reale? Beh, abbiamo in programma dei test per verificarne l’efficacia in comparazione con altri sistemi: staremo a vedere 🙂
Vi aggiorneremo con i risultati dei test invernali.