nedjem
Well-known member
Nell'ultimo mese e mezzo ho progettato e sviluppato un'app di telemetria per lo sci. Ve la racconto, magari a qualcuno interessa il processo. È roba da nerd dello sci e dello sviluppo software, siete avvisati.
Premessa: non è una roba finita e perfetta, è un progetto personale che ho portato avanti nei ritagli di tempo, con tutto quello che questo comporta. Errori, ripensamenti, soluzioni artigianali e qualche soddisfazione inaspettata.
Volevo trovare il modo per misurare in maniera oggettiva alcuni dati che mi permettessero di analizzare la sciata nella sua sostanza, più che nella sua forma.
Tutto è partito da una chat con Gemini e da un brainstorming sulla fattibilità: non avevo mai lavorato con sensori esterni e dovevo capire come impostare il tutto. Alla fine della conversazione ero ottimista sulla possibilità di arrivare a qualcosa di concreto e ho ordinato i sensori dalla Cina, due M5StickC Plus2, basati su ESP32* con IMU* integrata: 20 giorni di attesa. In futuro non escludo di poter assemblare qualcosa con un IMU migliore, ma non avendo una stampante 3d non saprei come creare il case, quindi ho preferito partire con qualcosa di già pronto. Non il massimo dal punto di vista tecnico, ma comodo per partire.
Invece di aspettare che i sensori arrivassero ho tirato fuori un ESP32 che ho comprato qualche anno fa per fare dei test e che di fatto ho messo nel cassetto poco dopo: la piattaforma é la stessa dei sensori, solo che questo non ha accelerometri e giroscopi. Ho quindi scritto un firmware* che simulasse dati di accelerometro e giroscopio con una sinusoide, così da poter iniziare a lavorare sulla connessione BLE* e sulla struttura dei pacchetti dati anche senza avere niente in mano. Dati falsi, ma utili per mettere insieme tutta la parte di comunicazione tra il sensore e l'app che ho iniziato a sviluppare in contemporanea.
Sull'app, sviluppata in C# con MAUI in modo da poter girare su Android e iOS, ho iniziato dai moduli di servizio: accoppiamento BLE, gestione delle connessioni, settings: roba noiosa ma necessaria.
La prima decisione importante è stata salvare i dati grezzi esattamente come escono dai sensori, senza nessuna elaborazione. Sembrava ovvio ma si è rivelata la cosa più utile che potessi fare: ogni volta che capivo che una formula doveva essere modificata potevo applicarla nuovamente agli stessi dati già registrati, senza dover rimettere gli scarponi e andare in pista. Questo ha velocizzato moltissimo lo sviluppo successivo. In questa fase ho iniziato a sviluppare il motore di analis dei dati, che doveva funzionare sia con dati live durante la sciata, sia a posteriori sui dati di log salvati. L'inserimento della sintesi vocale che legge i risultati alla fine di ogni curva é stata in realtà la parte più semplice del progetto.
Nel frattempo ho tirato su anche il backend: volevo che si potessero condividere le sessioni con il proprio allenatore, quindi mi servivano database, storage e hosting. Con un vincolo: spesa zero. Alla fine: Vercel, NeonDB e Cloudflare. Free tier di tutto. Funziona, almeno con il carico modesto che può generare un singolo utente. In futuro si vedrà.
Quando i sensori sono arrivati ho completato il firmware per leggere i dati reali e mi sono occupato della comunicazione tra i due dispositivi via ESP-NOW. Ho impostato una struttura master/slave: lo slave che comunica i propri dati tramite ESP-NOW al master, il master li impacchetta insieme ai propri e manda tutto allo smartphone tramite BLE. In questo modo lo smartphone gestisce un'unica connessione e ha meno problemi.Le batterie dei sensori sono minuscole quindi ho lavorato parecchio sul risparmio energetico: i sensori trasmettono solo durante una sessione attiva, altrimenti stanno fermi e non leggono neanche i dati da accelerometro e giroscopio, restando in attesa della prossima richiesta di connessione dall'app.
I primi test sul campo sono stati un po’ demoralizzanti ma istruttivi. I supporti in plastica in dotazione ai sensori erano troppo flessibili, e ho scoperto che anche una piccola vibrazione rispetto allo scarpone rovina i dati. Ho preso quindi un vecchio case da PC, ricavato due piastrine di alluminio, messo tutto insieme con biadesivo, neoprene e due cinghie da pacchi che ricordano un booster molto spartano e ho creato un sistema di ancoraggio artigianale ma stabile.
In questa fase ho scoperto che tutto il codice di riconoscimento delle curve che avevo scritto sui dati simulati non funzionava con i dati reali: troppo rumore, dai troppo sporchi. Ho dovuto buttare l'approccio basato sull'accelerometro e passare al giroscopio, molto più affidabile in questo contesto.
Il calcolo delle forze G è stato il passaggio più sofferto: sono tornato sul firmware più volte, ho cambiato scala di misura, frequenza di campionamento, filtri. L'ho risolto per tentativi più che per illuminazione. Anche il BLE mi ha fatto penare: connessioni fantasma, dati che sparivano senza errori visibili. L'app non si collegava più ai sensori e semplicemente non capivo perché. Mi é servito qualche ciclo di modifiche e test per trovare la stabilità necessaria.
Sul campo ho scoperto anche l'esistenza del drift dei giroscopi: in pratica anche da fermi accumulano errore e continuano a credere di essere in movimento. Ho aggiunto una procedura di calibrazione iniziale e poi anche quella automatica, che parte da sola quando il sistema capisce che sei stato fermo abbastanza a lungo, per esempio a inizio run quando aspetti la conferma vocale di poter partire.
La parte più bella è stata confrontarsi sulle metriche insieme al mio maestro e mentore. Mi ha spiegato come legge una curva in pista, cosa la rende efficace, dove si perde energia. Tradurre quella roba in formule è stata la parte più stimolante di tutto il progetto. È nato così il "performance index", un numero che prova a riassumere l'efficacia di ogni curva. È ancora grezzo, ma già dice cose interessanti.
Per ora la prima fase è chiusa e funzionante. Quest'estate continuo i test con i pattini in linea per vedere se possa essere utile anche anche lì.
Spero questo racconto possa essere interessante per qualcuno: se così fosse, e se ci fossero domande, sarò lieto di rispondere per quanto mi é possibile.
Nel prossimo post, se volete, vi racconto cosa ho capito dalle prime analisi fatte sui dati.
Intanto grazie per essere arrivati fino a qui.
* Riporto da un messaggio che ho scritto in seguito
Piccolo glossario per chi non conosce il contesto.
L'ESP32 é una piccola scheda programmabile. Ce ne sono di diversi formati e di diversa potenza: alcune sono grosse come una moneta da due euro, circa.
L'IMU é un componente elettronico che contiene accelerometro e giroscopio: l'accelerometro misura gli spostamenti nelle tre direzioni, il giroscopio misura le rotazioni, sempre sui 3 assi.
Il firmware é il "programma" che dice alla scheda come deve funzionare. Il dispositivo arriva "vuoto", non fa niente: bisogna dirgli cosa fare e se si vuole che comunichi con altri dispositivi bisogna dirgli come.
Il BLE è la sigla del Bluetooth Low Energy: una forma di connessione Bluetooth, ma un po' diversa da quella degli auricolari e delle casse perché non è necessario fare il pairing dal menu del telefono e per una serie di caratteristiche tecniche che è inutile elencare. Consuma "poco" ed è utile per lo scopo.
Spero che questo possa rendere più comprensibile il mio racconto.
Premessa: non è una roba finita e perfetta, è un progetto personale che ho portato avanti nei ritagli di tempo, con tutto quello che questo comporta. Errori, ripensamenti, soluzioni artigianali e qualche soddisfazione inaspettata.
Volevo trovare il modo per misurare in maniera oggettiva alcuni dati che mi permettessero di analizzare la sciata nella sua sostanza, più che nella sua forma.
Tutto è partito da una chat con Gemini e da un brainstorming sulla fattibilità: non avevo mai lavorato con sensori esterni e dovevo capire come impostare il tutto. Alla fine della conversazione ero ottimista sulla possibilità di arrivare a qualcosa di concreto e ho ordinato i sensori dalla Cina, due M5StickC Plus2, basati su ESP32* con IMU* integrata: 20 giorni di attesa. In futuro non escludo di poter assemblare qualcosa con un IMU migliore, ma non avendo una stampante 3d non saprei come creare il case, quindi ho preferito partire con qualcosa di già pronto. Non il massimo dal punto di vista tecnico, ma comodo per partire.
Invece di aspettare che i sensori arrivassero ho tirato fuori un ESP32 che ho comprato qualche anno fa per fare dei test e che di fatto ho messo nel cassetto poco dopo: la piattaforma é la stessa dei sensori, solo che questo non ha accelerometri e giroscopi. Ho quindi scritto un firmware* che simulasse dati di accelerometro e giroscopio con una sinusoide, così da poter iniziare a lavorare sulla connessione BLE* e sulla struttura dei pacchetti dati anche senza avere niente in mano. Dati falsi, ma utili per mettere insieme tutta la parte di comunicazione tra il sensore e l'app che ho iniziato a sviluppare in contemporanea.
Sull'app, sviluppata in C# con MAUI in modo da poter girare su Android e iOS, ho iniziato dai moduli di servizio: accoppiamento BLE, gestione delle connessioni, settings: roba noiosa ma necessaria.
La prima decisione importante è stata salvare i dati grezzi esattamente come escono dai sensori, senza nessuna elaborazione. Sembrava ovvio ma si è rivelata la cosa più utile che potessi fare: ogni volta che capivo che una formula doveva essere modificata potevo applicarla nuovamente agli stessi dati già registrati, senza dover rimettere gli scarponi e andare in pista. Questo ha velocizzato moltissimo lo sviluppo successivo. In questa fase ho iniziato a sviluppare il motore di analis dei dati, che doveva funzionare sia con dati live durante la sciata, sia a posteriori sui dati di log salvati. L'inserimento della sintesi vocale che legge i risultati alla fine di ogni curva é stata in realtà la parte più semplice del progetto.
Nel frattempo ho tirato su anche il backend: volevo che si potessero condividere le sessioni con il proprio allenatore, quindi mi servivano database, storage e hosting. Con un vincolo: spesa zero. Alla fine: Vercel, NeonDB e Cloudflare. Free tier di tutto. Funziona, almeno con il carico modesto che può generare un singolo utente. In futuro si vedrà.
Quando i sensori sono arrivati ho completato il firmware per leggere i dati reali e mi sono occupato della comunicazione tra i due dispositivi via ESP-NOW. Ho impostato una struttura master/slave: lo slave che comunica i propri dati tramite ESP-NOW al master, il master li impacchetta insieme ai propri e manda tutto allo smartphone tramite BLE. In questo modo lo smartphone gestisce un'unica connessione e ha meno problemi.Le batterie dei sensori sono minuscole quindi ho lavorato parecchio sul risparmio energetico: i sensori trasmettono solo durante una sessione attiva, altrimenti stanno fermi e non leggono neanche i dati da accelerometro e giroscopio, restando in attesa della prossima richiesta di connessione dall'app.
I primi test sul campo sono stati un po’ demoralizzanti ma istruttivi. I supporti in plastica in dotazione ai sensori erano troppo flessibili, e ho scoperto che anche una piccola vibrazione rispetto allo scarpone rovina i dati. Ho preso quindi un vecchio case da PC, ricavato due piastrine di alluminio, messo tutto insieme con biadesivo, neoprene e due cinghie da pacchi che ricordano un booster molto spartano e ho creato un sistema di ancoraggio artigianale ma stabile.
In questa fase ho scoperto che tutto il codice di riconoscimento delle curve che avevo scritto sui dati simulati non funzionava con i dati reali: troppo rumore, dai troppo sporchi. Ho dovuto buttare l'approccio basato sull'accelerometro e passare al giroscopio, molto più affidabile in questo contesto.
Il calcolo delle forze G è stato il passaggio più sofferto: sono tornato sul firmware più volte, ho cambiato scala di misura, frequenza di campionamento, filtri. L'ho risolto per tentativi più che per illuminazione. Anche il BLE mi ha fatto penare: connessioni fantasma, dati che sparivano senza errori visibili. L'app non si collegava più ai sensori e semplicemente non capivo perché. Mi é servito qualche ciclo di modifiche e test per trovare la stabilità necessaria.
Sul campo ho scoperto anche l'esistenza del drift dei giroscopi: in pratica anche da fermi accumulano errore e continuano a credere di essere in movimento. Ho aggiunto una procedura di calibrazione iniziale e poi anche quella automatica, che parte da sola quando il sistema capisce che sei stato fermo abbastanza a lungo, per esempio a inizio run quando aspetti la conferma vocale di poter partire.
La parte più bella è stata confrontarsi sulle metriche insieme al mio maestro e mentore. Mi ha spiegato come legge una curva in pista, cosa la rende efficace, dove si perde energia. Tradurre quella roba in formule è stata la parte più stimolante di tutto il progetto. È nato così il "performance index", un numero che prova a riassumere l'efficacia di ogni curva. È ancora grezzo, ma già dice cose interessanti.
Per ora la prima fase è chiusa e funzionante. Quest'estate continuo i test con i pattini in linea per vedere se possa essere utile anche anche lì.
Spero questo racconto possa essere interessante per qualcuno: se così fosse, e se ci fossero domande, sarò lieto di rispondere per quanto mi é possibile.
Nel prossimo post, se volete, vi racconto cosa ho capito dalle prime analisi fatte sui dati.
Intanto grazie per essere arrivati fino a qui.
* Riporto da un messaggio che ho scritto in seguito
Piccolo glossario per chi non conosce il contesto.
L'ESP32 é una piccola scheda programmabile. Ce ne sono di diversi formati e di diversa potenza: alcune sono grosse come una moneta da due euro, circa.
L'IMU é un componente elettronico che contiene accelerometro e giroscopio: l'accelerometro misura gli spostamenti nelle tre direzioni, il giroscopio misura le rotazioni, sempre sui 3 assi.
Il firmware é il "programma" che dice alla scheda come deve funzionare. Il dispositivo arriva "vuoto", non fa niente: bisogna dirgli cosa fare e se si vuole che comunichi con altri dispositivi bisogna dirgli come.
Il BLE è la sigla del Bluetooth Low Energy: una forma di connessione Bluetooth, ma un po' diversa da quella degli auricolari e delle casse perché non è necessario fare il pairing dal menu del telefono e per una serie di caratteristiche tecniche che è inutile elencare. Consuma "poco" ed è utile per lo scopo.
Spero che questo possa rendere più comprensibile il mio racconto.
Ultima modifica:
) nell'integrare criteri oggettivi nella valutazione e nella crescita tecnica di un atleta. L'idea non è sostituire l'allenatore, ma dargli degli strumenti.
