Costruire un dispositivo è la metà facile

0.54 m/s.

Questo è il numero sullo schermo dopo uno squat pesante. Sembra preciso. Due decimali, unità di misura e tutto il resto. Riagganci il bilanciere, guardi il telefono e decidi se aggiungere peso o fermare la serie.

Mi sono allenato con sensori VBT commerciali per anni. Ogni volta che guardavo quel numero, mi venivano le stesse domande. Da dove viene davvero? Quanto è accurato? E se non lo è sempre, come faccio a sapere quando fidarmi e quando no?

Nessuno mi ha mai dato una risposta. Il dispositivo misurava, l’app mostrava, e qualunque cosa succedesse in mezzo restava una scatola nera.

Così ho aperto la scatola. Poi me ne sono costruito una mia.

Questa è la storia di ODKI, un sensore open per l’allenamento basato sulla velocità (VBT). Non è un articolo sul firmware, anche se di firmware ce n’è. Parla delle decisioni dietro un prodotto: cosa costruire, cosa lasciare fuori, cosa regalare e cosa sto ancora imparando.

Perché un IMU, e perché quella è stata la parte facile

Ci sono due modi principali per misurare la velocità del bilanciere. I trasduttori di posizione lineare usano un cavo agganciato al bilanciere e misurano quanto e quanto velocemente si muove. I sensori inerziali stanno sul bilanciere e misurano accelerazione e rotazione.

Ho scelto l’IMU. Non perché sia la tecnica migliore sulla carta (i dispositivi a cavo restano generalmente il riferimento), ma perché l’hardware è semplice. Nessuna parte in movimento, nessun cavo, nessun meccanismo a molla. Un microcontrollore, un sensore, una batteria, qualche magnete.

Questa semplicità è esattamente ciò che la rende interessante. Quando l’hardware è facile, tutta la difficoltà si sposta sull’algoritmo. Chiunque può incollare un accelerometro a un bilanciere. La sfida è far sì che quei numeri significhino qualcosa.

E i sensori IMU hanno dei limiti. Li ho scoperti sulla mia pelle.

La seduta di squat che ha mandato in crisi i numeri

Se vuoi sapere come si comporta un sensore, usalo. Tanto. Così ho fatto squat. Serie dopo serie, ripetizione dopo ripetizione, guardando i numeri.

All’inizio sembrava tutto a posto. Poi ho notato una cosa: più la seduta andava avanti, meno accurati diventavano i dati. Non all’improvviso. Gradualmente. Ripetizione dopo ripetizione, i numeri si allontanavano dalla realtà.

Questo è il problema di fondo di ogni IMU. Per ottenere la velocità, integri l’accelerazione nel tempo. Qualsiasi piccolo errore nell’accelerazione, dovuto al bias del sensore, al rumore o a una stima imperfetta dell’orientamento, finisce integrato a sua volta. Gli errori integrati non si cancellano a vicenda. Si accumulano.

La soluzione classica è forzare la velocità a zero ogni volta che il sensore crede che il bilanciere sia fermo. Funziona, finché non funziona più. Quando questa immobilità viene rilevata nel momento sbagliato, il reset crea un salto nel segnale. Scambi un errore con un altro e lo nascondi dietro un numero che sembra pulito.

Quindi ho preso una decisione che ha plasmato tutto il firmware: la velocità non viene mai forzata a zero. Invece, i momenti in cui il bilanciere è davvero fermo vengono usati per misurare la deriva. Una volta nota la deriva, viene rimossa retroattivamente dalla ripetizione appena conclusa. Più complesso. Aggiunge un piccolo ritardo prima che il numero finale sia pronto. Ma il numero che vedi è corretto, non rattoppato.

Questo però non rispondeva ancora del tutto alla mia domanda iniziale. Nessun algoritmo è perfetto, e far finta del contrario è esattamente ciò che mi aveva fatto diffidare dei dispositivi che usavo prima. Quindi ogni ripetizione che ODKI riporta è accompagnata da un punteggio di qualità: una misura di quanto fossero puliti i dati che ci stanno dietro. Il sensore non ti dà solo un numero. Ti dice anche quanto quel numero merita la tua fiducia.

Questa è la risposta che cercavo fin dall’inizio. Per arrivarci, però, ho dovuto costruire tutto il dispositivo.

App ODKI che mostra la velocità per ripetizione e il punteggio di qualità lungo una serie.

Pubblicare tutto

L’algoritmo di ODKI è documentato passo per passo. Il protocollo Bluetooth è di dominio pubblico, quindi qualsiasi app può comunicare con il sensore. Il firmware e il progetto hardware sono disponibili: chiunque può leggerli e costruirli.

Mi chiedono se ho paura di essere copiato. Non ho mai avuto dubbi su questo.

La paura di essere copiati limita lo sviluppo molto più di quanto farebbe la copia stessa. Ti rende più lento, più riservato, più difensivo. Spendi energie a proteggere le idee invece che a migliorarle.

C’era anche una seconda ragione. Un sensore su un bilanciere sembra un oggetto semplice. Una scatoletta con una luce sopra. Pubblicare l’algoritmo è stato il modo più chiaro per mostrare quanta ingegneria c’è dietro qualcosa che sembra così semplice. Non devi fidarti della mia parola. Puoi leggertelo da solo.

Un confine però l’ho tracciato: il progetto è source-available, non completamente open source. Studenti, maker e appassionati possono costruirsene uno gratis, oppure comprarne uno a un prezzo ragionevole. Quello che non volevo era che un’azienda prendesse il lavoro e lo rivendesse. Apertura per chi vuole imparare, sì. Un reparto R&D gratuito per la linea di prodotti di qualcun altro, no.

Un prezzo pensato per due persone

ODKI costa 129 euro, case incluso. Quel numero nasce da un calcolo: materiali più il tempo che serve per costruirne uno.

Questo mi ha portato a un principio di progettazione che non pensavo potesse contare così tanto. Durante la fase di progettazione, cercavo sempre la soluzione che mi permettesse di costruire un’unità nel minor tempo possibile, con il minimo sforzo. Meno componenti. Meno passaggi. Niente di complicato.

Alla fine, questa scelta aiuta due persone insieme. Aiuta me, perché il tempo di assemblaggio è un costo. E aiuta chiunque voglia costruirsene uno a casa: meno componenti e meno passaggi significa che anche chi non ha un background in elettronica può seguire il processo senza perdersi. Il supporto magnetico è un buon esempio: tre magneti, niente cinghie, niente clip. Pochi secondi per agganciarlo al bilanciere.

Progettare pensando all’utente è un consiglio standard. Progettare pensando a chi dovrà montarlo alle undici di sera è meno comune. Ripaga.

Cosa ho scelto di non costruire ancora

Questa è la parte che raramente finisce nei racconti sui progetti.

ODKI non riconosce la tua tecnica di esecuzione. Non sa distinguere uno squat buono da uno cattivo. L’app non ha un database, nessuna gestione dei dati a lungo termine, nessuna elaborazione dello storico di allenamento. Sono tutte funzionalità che voglio aggiungere. Sono tutte nella roadmap.

Ma non ora.

In questo momento sono concentrato su una cosa sola: l’algoritmo che traccia le fasi di un’alzata. Quando inizia la ripetizione, quando il bilanciere cambia direzione, quando finisce. Tutto il resto si basa su questo. Se il rilevamento delle fasi è sbagliato, anche il riconoscimento della tecnica sarà sbagliato. Un bellissimo database si limiterebbe a conservare numeri sbagliati in modo molto ordinato.

È tentante aggiungere funzionalità. Ognuna di esse fa sembrare una demo più bella. Ma un prodotto con dieci funzionalità a metà è peggio di un prodotto con tre che funzionano davvero. Per ora, quindi, ODKI fa le cose essenziali e le fa bene.

La stessa logica ha guidato l’app. Ho iniziato su Android, perché lo sviluppo nativo Android era la strada più diretta per me. Poi sono passato a Flutter, così ho un’unica base di codice per Android e iOS. L’app iOS è ora in fase di test.

Cosa mi stanno insegnando i tester

ODKI è in fase di test con utenti reali. È qui che il progetto è diventato davvero una lezione di umiltà.

Il feedback non riguarda mai le cose su cui ho passato più tempo. Nessuno ha commentato la correzione della deriva. Le persone parlano dell’interfaccia, e di cosa vorrebbero che facesse.

Una richiesta recente: una soglia di velocità. Impostare una velocità minima del bilanciere, e quando le ripetizioni scendono sotto quella soglia, l’app dice di fermare la serie. È un’idea centrale nell’allenamento basato sulla velocità, ed è arrivata da un utente, non da me. Ed è esattamente per questo che metti un prodotto nelle mani di altre persone.

I test mi hanno anche mostrato dove l’algoritmo ancora fallisce. Il caso più evidente: quando il bilanciere viene lasciato cadere a terra alla fine di uno stacco da terra. L’impatto confonde il rilevamento della ripetizione, perché il firmware non filtra ancora uno shock di quel tipo. Nelle mie sedute di squat non l’avrei mai scoperto. Gli utenti reali sollevano in modo diverso da come te li immagini.

La vera ragione per cui esiste questo progetto

So come costruire un prodotto. Dammi un problema e arriverò a un dispositivo funzionante. Quello su cui ho molta meno esperienza è tutto ciò che viene dopo: definire il prezzo, posizionarlo, decidere per chi è pensato, decidere a cosa dire no, ascoltare utenti interessati a cose completamente diverse dalle tue.

ODKI è il modo in cui sto imparando quella parte. Il sensore era la metà facile.

Dove va questo progetto da qui

Il firmware ora risponde alla domanda da cui sono partito. Puoi vedere da dove viene il numero, e puoi vedere quanto fidartene.

Le prossime domande non hanno una scheda tecnica. Chi ne ha più bisogno? Cosa sarebbe disposto a pagare? Quali funzionalità della roadmap contano davvero, e quali sembrano belle solo in una demo?

Non ho ancora quelle risposte. Ma il modo più veloce per trovarle è lo stesso degli squat: usalo, misuralo, e non nascondere le parti che non funzionano.

Il sensore, l’algoritmo e tutto quello che c’è dietro sono su odki.tech.