Il problema della velocit\u00e0 della barra: deriva e false pause<\/h2>\n
La precedente ottimizzazione di Spleeft, che ho descritto in l'articolo originale sulla scienza dei dati<\/a>, aveva una portata pi\u00f9 limitata. Mi sono concentrato principalmente sulla regolazione dei parametri di un algoritmo esistente e sull\u2019individuazione di combinazioni che ne migliorassero le prestazioni.<\/p>\n Quel lavoro \u00e8 stato prezioso, ma dopo aver dedicato pi\u00f9 tempo a testare Spleeft in contesti formativi reali, ho iniziato a intravedere un problema pi\u00f9 profondo.<\/p>\n La difficolt\u00e0 principale non consisteva semplicemente nel calcolare la velocit\u00e0.<\/p>\n Si trattava di capire quando un movimento aveva inizio, quando terminava e quando il dispositivo era davvero immobile.<\/p>\n Spleeft utilizza i dati dell'accelerometro. Per calcolare la velocit\u00e0, \u00e8 necessario integrare l'accelerazione nel tempo. Si tratta di un approccio matematicamente elegante, ma che comporta anche un problema inevitabile: anche una minima deviazione o un minimo errore nel segnale di accelerazione si accumula durante l'integrazione e si traduce in una deriva della velocit\u00e0.<\/p>\n Tale scostamento pu\u00f2 derivare da diverse cause:<\/p>\n L'ultimo punto \u00e8 particolarmente importante. Un'accelerazione prossima allo zero non significa sempre che la velocit\u00e0 sia pari a zero. Pu\u00f2 anche significare che la barra si sta muovendo a una velocit\u00e0 relativamente costante.<\/p>\n Therefore, the real challenge was not simply to find \u201cmore zeros\u201d.<\/p>\n Lo scopo era quello di trovare zeri migliori.<\/p>\n Lo zero \u00e8 un punto di riferimento che pu\u00f2 essere utilizzato per ricalibrare il segnale di velocit\u00e0 integrato. Se lo zero prima di una ripetizione \u00e8 errato, l'integrazione parte da un punto sbagliato. Se all'interno di una ripetizione si verifica uno zero errato, il movimento potrebbe essere interrotto o ricalibrato troppo presto.<\/p>\n\n\n Ci\u00f2 ha portato alla definizione di un nuovo principio per il progetto:<\/p>\n Per prima cosa, migliorare la qualit\u00e0 del rilevamento dello stato di riposo e della segmentazione delle ripetizioni. Successivamente, valutare la velocit\u00e0.<\/p>\n<\/blockquote>\n Il primo passo \u00e8 stato quello di procurarsi un dispositivo di riferimento da utilizzare insieme a Spleeft.<\/p>\n Un noto produttore di encoder lineari aveva lanciato sul mercato un dispositivo in grado di fornire non solo i dati relativi alla velocit\u00e0, ma anche i dati grezzi che potevano essere raccolti in un contesto di allenamento reale. Era esattamente ci\u00f2 di cui avevo bisogno.<\/p>\n Durante un ritiro con la nazionale spagnola di BMX a Parigi, ho raccolto un ampio set di dati mentre svolgevo diversi esercizi:<\/p>\n Le misurazioni sono state raccolte contemporaneamente:<\/p>\n Non si trattava di una serie di dati di laboratorio raccolti in condizioni perfettamente controllate. Era una scelta deliberata.<\/p>\n Volevo capire cosa succedesse quando il sistema veniva utilizzato negli ambienti in cui gli allenatori lo avrebbero effettivamente impiegato: con esercizi diversi, carichi diversi, pause diverse, strategie di movimento diverse e fonti di rumore diverse.<\/p>\n Il set di dati mi ha inoltre permesso di confrontare due tipi di misurazione molto diversi tra loro.<\/p>\n L'encoder misura il movimento lungo un percorso meccanico pi\u00f9 ben definito. L'Apple Watch o l'iPhone misurano le forze che agiscono sul dispositivo, sulla barra e, indirettamente, sull'atleta. Non rilevano esattamente lo stesso segnale.<\/p>\n Quella differenza \u00e8 diventata una delle lezioni pi\u00f9 importanti del progetto.<\/p>\n Prima di ottimizzare qualsiasi cosa, ho dovuto riprodurre l'algoritmo iOS esistente al di fuori dell'applicazione.<\/p>\n Sembra semplice, ma \u00e8 stata una delle parti pi\u00f9 importanti dell\u2019intero processo.<\/p>\n L'algoritmo di produzione gira in Swift su iPhone e Apple Watch. Il lavoro di ottimizzazione, tuttavia, \u00e8 stato molto pi\u00f9 semplice da svolgere in Python, dove ho potuto elaborare grandi set di dati, generare grafici e testare migliaia o milioni di combinazioni di parametri.<\/p>\n Il problema era che un'approssimazione in Python non sarebbe stata sufficiente.<\/p>\n Se la versione in Python si comportasse in modo diverso da quella in Swift, non starei ottimizzando Spleeft. Starei ottimizzando un algoritmo diverso.<\/p>\n Cos\u00ec ho sviluppato un simulatore in Python che riproduceva le principali fasi di elaborazione dell\u2019implementazione per iOS:<\/p>\n Ho quindi verificato il simulatore confrontandolo con l'output di Swift. L'obiettivo non era quello di ottenere un risultato simile, ma di assicurarmi che lo stesso segnale grezzo producesse le stesse ripetizioni e metriche praticamente identiche.<\/p>\n Solo dopo questa fase l'ottimizzazione avrebbe potuto assumere un senso.<\/p>\n La prima versione dell'algoritmo prevedeva gi\u00e0 la ricalibrazione a velocit\u00e0 zero, ma la sua logica era relativamente semplice.<\/p>\n Ha funzionato bene in situazioni controllate. Tuttavia, alcuni esercizi ne hanno messo in luce i punti deboli. La distensione su panca e lo stacco da terra si sono rivelati particolarmente impegnativi, poich\u00e9 il dispositivo pu\u00f2 subire movimenti aggiuntivi mentre l\u2019atleta stabilizza il bilanciere.<\/p>\n Ho iniziato a esaminare approcci alternativi per il rilevamento della velocit\u00e0 zero attingendo alla letteratura scientifica e alle applicazioni correlate nel campo della navigazione inerziale.<\/p>\n Tra le idee figuravano:<\/p>\n Non tutte le idee hanno funzionato.<\/p>\n Ad esempio, ho studiato un classificatore dello stato inerziale basato su un albero decisionale. Si \u00e8 trattato di un utile esperimento di data science, ma le sue prestazioni non erano abbastanza affidabili da giustificarne l\u2019utilizzo come criterio di esclusione definitivo nell\u2019algoritmo di produzione.<\/p>\n Si trattava di una distinzione importante.<\/p>\n Il progetto prevedeva esperimenti di apprendimento automatico e metodi di data science, ma la soluzione finale implementata non era un modello \u201cblack-box\u201d che si limitava a classificare ogni campione. Il processo di data science mi ha aiutato a comprendere il segnale, a identificare le modalit\u00e0 di guasto e a progettare una macchina a stati causali pi\u00f9 robusta.<\/p>\n Il sistema finale \u00e8 rimasto interpretabile.<\/p>\n Una volta che il simulatore e i possibili rivelatori erano disponibili, ho iniziato a eseguire ricerche sistematiche dei parametri.<\/p>\n Per ciascuna configurazione candidata, gli stessi segnali grezzi sono stati elaborati nuovamente. I parametri controllavano aspetti quali:<\/p>\n La ricerca non era finalizzata a individuare la configurazione con l'errore di velocit\u00e0 pi\u00f9 basso rispetto all'encoder.<\/p>\n Sarebbe stato troppo limitato.<\/p>\n L'obiettivo principale era quello di individuare la combinazione che consentisse di rilevare al meglio i periodi di velocit\u00e0 zero effettivi, evitando al contempo i falsi zeri durante il movimento attivo.<\/p>\n La valutazione si \u00e8 svolta secondo un processo a cascata:<\/p>\n Questo ordine \u00e8 importante.<\/p>\n Una ripetizione con una velocit\u00e0 vicina a quella dell'encoder non \u00e8 necessariamente una ripetizione misurata correttamente se il suo inizio o la sua fine sono stati definiti da uno zero falso.<\/p>\n I numeri rappresentavano solo una parte dei criteri con cui valutavo ogni esperimento. Tenevo visibili sia le registrazioni grezze che le tracce di velocit\u00e0 risultanti, poi le confrontavo con i movimenti che avevo osservato durante il mio allenamento e nelle prove con i miei atleti. Quando c\u2019era una pausa evidente, potevo verificare se l\u2019algoritmo riportasse la velocit\u00e0 a zero. Quando una ripetizione era ancora in movimento, riuscivo a individuare una correzione errata. Quei semplici controlli visivi spesso mi fornivano pi\u00f9 informazioni sulla modifica successiva da apportare rispetto a un altro punteggio di errore.<\/p>\n Uno dei principali miglioramenti dal punto di vista dell'architettura \u00e8 stato l'aggiunta di una macchina a stati per integrare il rilevamento dello zero.<\/p>\n L'algoritmo ora analizza il movimento come una sequenza di stati, anzich\u00e9 trattare ogni campione in modo indipendente.<\/p>\n In parole povere, passa attraverso fasi quali:<\/p>\n Questa struttura contribuisce a evitare che singoli eventi dei sensori modifichino immediatamente l'interpretazione della ripetizione.<\/p>\n Ad esempio, un breve periodo di bassa accelerazione durante il movimento di una barra non dovrebbe essere automaticamente interpretato come un momento di riposo. Il sistema necessita di ulteriori indicazioni: la direzione del segnale, la durata dell\u2019evento e il contesto pi\u00f9 ampio del movimento.<\/p>\n La macchina a stati mi ha inoltre permesso di separare due concetti che in precedenza erano troppo strettamente collegati:<\/p>\n Ci\u00f2 si \u00e8 rivelato particolarmente utile perch\u00e9 lo stato di movimento pu\u00f2 rimanere attivo anche quando l'accelerazione \u00e8 temporaneamente vicina allo zero.<\/p>\n Ho utilizzato l'encoder come riferimento esterno, ma non come verit\u00e0 assoluta.<\/p>\n For every repetition, I processed the encoder data using a comparable methodology rather than simply copying the metrics exported by its proprietary algorithm. This reduced the influence of differences between the encoder\u2019s internal processing and Spleeft\u2019s processing.<\/p>\n Anche allora, l'encoder veniva considerato un punto di riferimento, non uno standard assoluto.<\/p>\n I diversi dispositivi presentano filtri, ritardi, regole di rilevamento e vincoli meccanici diversi. Inoltre, il segnale esportato potrebbe non corrispondere esattamente al segnale utilizzato internamente per calcolare ciascuna metrica.<\/p>\n Ecco perch\u00e9 ho deciso di non definire il successo semplicemente come:<\/p>\n \u201cThe Spleeft value is close to the encoder value.\u201d<\/p>\n<\/blockquote>\n Ho cercato invece un algoritmo che fosse internamente coerente, in grado di rilevare correttamente le ripetizioni e che funzionasse in modo affidabile in diversi esercizi e in diverse condizioni di registrazione.<\/p>\n L'encoder mi ha aiutato a individuare gli errori e ad analizzare i casi pi\u00f9 complessi. Non ha sostituito il pensiero critico.<\/p>\n Dopo gli esperimenti di laboratorio, sono tornato ad analizzare i dati raccolti al di fuori delle sessioni controllate.<\/p>\n Alcuni dei file pi\u00f9 utili provenivano da utenti di Spleeft che avevano condiviso esempi di casi in cui l'applicazione aveva prodotto un risultato inaspettato.<\/p>\n Questi file erano preziosi perch\u00e9 contenevano i problemi che si presentano nella vita reale:<\/p>\n Ho applicato il nuovo algoritmo a questi set di dati storici e ne ho confrontato il comportamento con quello dell'implementazione precedente.<\/p>\n Questa fase ha contribuito a mettere in luce un principio importante: migliorare l\u2019algoritmo non significa renderlo pi\u00f9 complesso a tutti i costi. Significa rendere la logica pi\u00f9 adeguata alla realt\u00e0 fisica del sensore e dell\u2019esercizio.<\/p>\n Quell'esperienza ha anche contribuito a plasmare l'ultimo aggiornamento di Spleeft<\/a>. Le misurazioni dell'accelerometro presentano dei limiti<\/a>, anche dopo un'attenta ottimizzazione, quindi volevo che i coach potessero esaminare le registrazioni sottostanti e valutare se un risultato fosse attendibile nel proprio contesto.<\/p>\n Volevo inoltre testare il nuovo algoritmo su un vero Apple Watch, anzich\u00e9 affidarmi esclusivamente alle simulazioni in Python.<\/p>\n To keep the project aligned with Spleeft\u2019s original philosophy, I bought a second-hand Apple Watch SE for approximately \u20ac40. It was one of the least expensive models capable of running the application and processing the signal in real time.<\/p>\n\n\n Non si \u00e8 trattato solo di una prova pratica.<\/p>\n Spleeft \u00e8 sempre stato concepito partendo dall'idea che l'allenamento basato sulla velocit\u00e0 debba essere accessibile a tutti. Se un nuovo algoritmo funzionasse solo sui dispositivi pi\u00f9 costosi o in un ambiente di laboratorio perfetto, non sarebbe in linea con lo scopo del progetto.<\/p>\n Durante i test sul campo, ho messo a confronto due posizionamenti:<\/p>\n Questo ha dimostrato quanto possa essere importante il posizionamento dei sensori.<\/p>\n In deadlifts and bench press, the movement of the athlete\u2019s wrist can introduce additional noise. The athlete is holding and stabilising the bar, so the sensor is not only measuring the bar\u2019s vertical movement. It is also measuring small movements from the hand, wrist and body.<\/p>\n Appoggiando l'orologio direttamente sulla barra, il rumore si \u00e8 in parte attenuato.<\/p>\n Ci\u00f2 non significa che la posizione della barra sia sempre l'opzione migliore, n\u00e9 che quella del polso sia errata. Significa piuttosto che anche l'algoritmo ottimale deve tenere conto dei limiti dell'hardware e delle modalit\u00e0 di utilizzo del dispositivo.<\/p>\n Nessuna applicazione della scienza dei dati pu\u00f2 compensare completamente una configurazione di misurazione inadeguata.<\/p>\n Il nuovo algoritmo ha superato la fase beta. La vera prova del nove sar\u00e0 verificare la sua affidabilit\u00e0 in diversi esercizi, dispositivi e contesti di allenamento. Vorrei che fossero gli allenatori stessi a valutarlo.<\/p>\n Vorrei inoltre chiarire cosa si nasconde dietro quel numero: Spleeft utilizza i periodi di riposo rilevati per limitare la deriva della velocit\u00e0 e una macchina a stati per identificare le ripetizioni. Abbiamo verificato tali decisioni confrontandole con sessioni registrate e dispositivi esterni. Condivido l\u2019approccio mantenendo riservati i parametri esatti.<\/p>\n Questo progetto mi ha insegnato che un indicatore di velocit\u00e0 efficace non dipende solo da un algoritmo ingegnoso. Dipende dal sensore, dall\u2019esercizio, dalla qualit\u00e0 dei dati e dalle decisioni prese in ogni fase. L\u2019intelligenza artificiale mi ha aiutato a esplorare e sviluppare pi\u00f9 rapidamente, ma l\u2019esperienza di coaching \u00e8 stata fondamentale per stabilire quali fossero i problemi davvero rilevanti.<\/p>\n Spleeft \u00e8 ancora un progetto personale nato proprio da quella curiosit\u00e0. Continuer\u00f2 a testarlo durante gli allenamenti reali e a condividere ci\u00f2 che imparo.<\/p>\n \u00a0<\/p>","protected":false},"excerpt":{"rendered":" Come ho utilizzato i dati dell'Apple Watch, un encoder lineare e alcune registrazioni effettuate a Parigi per migliorare il rilevamento delle pause, la segmentazione delle ripetizioni e il monitoraggio della velocit\u00e0 della barra in Spleeft.<\/p>","protected":false},"author":1,"featured_media":11366,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"om_disable_all_campaigns":false,"_monsterinsights_skip_tracking":false,"footnotes":""},"categories":[142],"tags":[67,21],"class_list":["post-11367","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-case-studies","tag-apple-watch","tag-vbt"],"_links":{"self":[{"href":"https:\/\/spleeft.app\/it\/wp-json\/wp\/v2\/posts\/11367","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/spleeft.app\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/spleeft.app\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/spleeft.app\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/spleeft.app\/it\/wp-json\/wp\/v2\/comments?post=11367"}],"version-history":[{"count":4,"href":"https:\/\/spleeft.app\/it\/wp-json\/wp\/v2\/posts\/11367\/revisions"}],"predecessor-version":[{"id":11372,"href":"https:\/\/spleeft.app\/it\/wp-json\/wp\/v2\/posts\/11367\/revisions\/11372"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/spleeft.app\/it\/wp-json\/wp\/v2\/media\/11366"}],"wp:attachment":[{"href":"https:\/\/spleeft.app\/it\/wp-json\/wp\/v2\/media?parent=11367"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/spleeft.app\/it\/wp-json\/wp\/v2\/categories?post=11367"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/spleeft.app\/it\/wp-json\/wp\/v2\/tags?post=11367"}],"curies":[{"name":"parola chiave","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}\n
![\"Velocit\u00e0](\"https:\/\/spleeft.app\/wp-content\/uploads\/2026\/09\/deadlift-velocity-fixed-4-reps-1024x487.png\" "\\"\\"")
\n
Raccolta dei dati sulla velocit\u00e0 delle barre a Parigi<\/h2>\n
\n
![\"Raccolta](\"https:\/\/spleeft.app\/wp-content\/uploads\/2026\/09\/paris-data-collection-576x1024.jpg\" "\\"\\"")
\n
Riscrittura di Spleeft in Python<\/h2>\n
\n
Oltre il rilevatore di zero originale<\/h2>\n
\n
Cercare tra milioni di possibilit\u00e0<\/h2>\n
\n
\n
Una macchina a stati per il movimento<\/h2>\n
\n
\n
What the encoder could\u2014and could not\u2014tell me<\/h2>\n
\n
Test dell\u2019algoritmo con dati reali degli utenti<\/h2>\n
\n
Testing on a \u20ac40 Apple Watch SE<\/h2>\n
![\"Apple](\"https:\/\/spleeft.app\/wp-content\/uploads\/2026\/09\/apple-watch-encoder-on-bar-768x1024.jpg\" "\\"\\"")
\n
What changed in Spleeft\u2019s algorithm<\/h2>\n
Cosa ho imparato<\/h2>\n