Dall’analisi video agli allenamenti strutturati

L’ultimo passaggio è stato il più divertente.

Ho caricato un video di una mia nuotata in piscina, con riprese dalla superficie e sott’acqua frontali.

Claude non guarda il video in movimento come faremmo noi, ma ne ha estratto i fotogrammi e li ha analizzati uno per uno.

Il responso è stato onesto e utile.

Tra le cose positive: recupero del braccio con gomito alto e ritmo regolare.

Da migliorare:

  • una trazione spesso a braccio teso, che spinge l’acqua verso il fondo invece che indietro;
  • braccia che in allungo escono dalla linea delle spalle, probabilmente durante la respirazione;
  • molta aria all’entrata della mano;
  • la testa a tratti un po’ alta.

Claude ha anche indicato con chiarezza i limiti dell’analisi: risoluzione bassa e nessuna ripresa laterale, quindi niente giudizio sulla gambata.

Il tutto è finito in un documento Word con i fotogrammi commentati.

Poi siamo passati alla programmazione della settimana:

Scarico il lunedì, soglia il venerdì, aerobico lungo la domenica.

Ogni seduta include esercizi mirati ai difetti emersi dal video, come il remate, il nuoto a pugni chiusi, il braccio singolo e il catch-up con entrata sulla linea della spalla.

Le andature sono calcolate sul mio passo di soglia, circa 1:58 ogni 100 metri.

La parte che mi è piaciuta di più è stata la discussione.

Ho chiesto più volume: 2.000, 2.500 e 2.800 metri.

Poi ho chiesto perché alcune ripetute fossero in zona B2 e non B1.

Claude mi ha spiegato il ragionamento, cioè attivazione prima della serie centrale e richiamo di velocità a fine seduta, ma mi ha anche detto che B1 era una scelta altrettanto valida e più prudente.

Abbiamo cambiato, e alla fine ho avuto tre documenti Word, uno per seduta, da stampare e portare a bordo vasca.

Non è un sostituto di un allenatore in carne e ossa che ti guarda dal bordo, ma come strumento per ragionare sui propri dati e tenere il filo della programmazione funziona davvero bene.

Claude legge i miei allenamenti

Con il server MCP attivo, il collegamento tra Claude e intervals.icu è diventato reale.

Ho creato un Progetto su Claude dedicato al nuoto, che ho chiamato “AI-nuoto”, e ci ho caricato come riferimento lo storico delle mie sedute esportato da Final Surge, con la mia struttura abituale: sedute A, B e C e zone di intensità da A1 a C3.

La prova del nove è stata la domanda più semplice: “vedi i miei allenamenti?”.

Claude ha interrogato intervals.icu e in pochi secondi mi ha restituito il riepilogo delle ultime due settimane: le nuotate in piscina con il passo medio su 100 metri, le uscite in acque libere, le camminate, lo yoga, e l’andamento di fitness e fatica.

La cosa interessante non è tanto l’elenco, che vedo anche su intervals.icu, quanto la lettura.

Claude ha notato per esempio che in una sessione in mare avevo tenuto lo stesso passo della piscina, un buon segnale visto che in acque libere non ci sono virate e spinte dal muro.

Ha anche calcolato che il carico era moderato e che la mia forma era leggermente positiva, cioè ero riposato.

Da qui in poi i dati non sono più solo numeri da guardare: diventano la base per ragionare sulla programmazione.

Creare un server MCP per intervals.icu

Avere i dati su intervals.icu è utile, ma volevo fare un passo in più.

Poterli discutere con Claude, l’assistente di intelligenza artificiale di Anthropic, come farei con un allenatore.

Il problema è che un assistente AI, da solo, non ha accesso ai miei dati.

Qui entra in gioco MCP.

MCP, cioè Model Context Protocol, è uno standard aperto che permette di collegare un assistente AI a strumenti e servizi esterni. Un “server MCP” è un piccolo programma che fa da ponte.

Da un lato parla con il servizio (in questo caso intervals.icu), dall’altro espone a Claude una serie di strumenti, come “leggi le attività”, “leggi i dati di benessere” o “aggiungi un evento al calendario”.

Per intervals.icu esiste un server MCP open source.

La configurazione ha richiesto questi passaggi:

  1. Installare i requisiti sul computer [Python e il gestore di pacchetti indicato nella documentazione del progetto].
  2. Scaricare il progetto e creare un file di configurazione con due dati: la chiave API personale, che si genera nelle impostazioni per sviluppatori di intervals.icu, e l’ID atleta.
  3. Registrare il server nella configurazione di Claude Desktop, così che Claude lo avvii e lo possa usare.

Un’avvertenza: la chiave API dà accesso ai propri dati, quindi va trattata come una password e non va mai condivisa o pubblicata.

Garmin e intervals.icu: far parlare l’orologio con la piattaforma di analisi

Da qualche tempo registro tutto con il mio Garmin fenix 7

Nuoto in piscina, acque libere, bici, camminate e perfino le sessioni di yoga.

Garmin Connect è comodo per avere un colpo d’occhio, ma quando si vuole capire davvero come sta andando l’allenamento serve qualcosa di più.

Per questo ho scelto intervals.icu, una piattaforma di analisi molto apprezzata da ciclisti, triatleti e nuotatori, che calcola carico di allenamento, fitness, fatica e forma nel tempo.

Il collegamento è semplice.

Dalle impostazioni di intervals.icu si apre la sezione delle connessioni, si sceglie Garmin Connect e si autorizza l’accesso con le proprie credenziali Garmin.

Da quel momento ogni attività registrata con l’orologio arriva automaticamente su intervals.icu pochi minuti dopo la sincronizzazione con il telefono. Vengono inoltre importati i dati di benessere, come frequenza a riposo, sonno e peso.

Il vantaggio è immediato.

Per ogni nuotata intervals.icu mostra distanza, passo, frequenza cardiaca, carico e il suo contributo alla curva di fitness.

Guardando le ultime settimane posso capire se sto accumulando fatica o se sono fresco, e tutto senza inserire un solo dato a mano.

Questo è il primo mattone. Nel prossimo articolo racconto come ho dato a un’intelligenza artificiale la possibilità di leggere questi dati.

Notate che in questa modalità non serve utilizzare strava.

Quando l’AI incontra i dati reali: da Garmin e Strava al mio coach AI

A questo punto AI-nuoto sapeva perfettamente cosa era stato programmato.

Ma non necessariamente cosa avevo fatto, ed è una differenza enorme.

Final Surge può dirmi che il 6 agosto erano previsti determinati metri e determinati lavori.

Ma se quel giorno ho nuotato 3.500 metri, oppure ne ho fatti 2.000, oppure non sono proprio entrato in acqua, un coach intelligente dovrebbe saperlo.

Nasce così una distinzione fondamentale del progetto:

PLANNED ≠ COMPLETED

Non volevo che AI-nuoto vedesse un allenamento nel calendario e concludesse automaticamente che fosse stato eseguito.

Serviva quindi un’altra fonte dati, ed entra in gioco Strava.

Il Garmin registra praticamente ogni mio allenamento.

La strada ideale sarebbe quindi:

Garmin → AI

ma l’accesso diretto ai dati Garmin tramite le API ufficiali non è la soluzione più semplice per un piccolo progetto personale.

Fortunatamente nel mio ecosistema esiste già un ottimo ponte, Strava !!!

Garmin Connect sincronizza automaticamente le attività con Strava. Strava dispone inoltre di API che permettono, previa autorizzazione OAuth, di interrogare le attività dell’atleta.

A questo punto il nerd ha definitivamente preso il sopravvento sul vacanziere.

Ho creato una piccola applicazione Strava chiamata, naturalmente, AI-nuoto.

Poi ho configurato una Action nel mio GPT utilizzando OAuth e le API Strava, inizialmente esclusivamente in lettura (Nessuna possibilità di modificare o pubblicare attività).

Solo leggere ciò che serve al coach

Le prime operazioni sono volutamente semplici:

  • getAuthenticatedAthlete
  • getRecentActivities
  • getActivityDetails

Dopo qualche passaggio tra Client ID, Client Secret, callback URL e OAuth, è arrivato il momento del test.

AI-nuoto ha interrogato e Strava ha risposto recuperando realmente le mie attività recenti, riconoscendo tra queste i miei allenamenti di nuoto.

A quel punto il progetto ha cambiato natura:  Planned + Completed.

AI-nuoto dispone di due prospettive differenti.

Da una parte: Final Surge → cosa era previsto

Dall’altra: Garmin → Strava → cosa è realmente successo

E in mezzo: Profilo atleta → chi sta facendo quegli allenamenti

L’AI può quindi iniziare a ragionare su qualcosa di molto più interessante:

Previsto → Eseguito → Differenza → Decisione successiva

L’architettura concettuale è diventata:

Final Surge → Planned
↓
Knowledge Base

Garmin → Garmin Connect → Strava API → Completed
↓
AI-nuoto

Profilo atleta → Context
↓
Analisi → prossimo allenamento

Ed è qui che, secondo me, l’AI applicata allo sport comincia davvero a diventare interessante dato che l’obiettivo del progetto non è costruire una macchina che dica: “Oggi fai 10×100 A2 recupero 15 secondi” (un normale LLM può già generare qualcosa del genere in pochi secondi).

Quello che sto cercando di costruire è un sistema capace di rispondere prima ad altre domande:

  1. Cosa ho fatto nelle ultime settimane?
  2. Cosa era previsto?
  3. Cosa ho realmente completato?
  4. Qual è stata la progressione?
  5. Quali stimoli ho già ricevuto?
  6. Qual è il mio obiettivo attuale?

E soltanto dopo:

  • Cosa avrebbe senso fare adesso?

È una differenza sostanziale.

L’AI non diventa interessante quando genera più velocemente una scheda.

Diventa interessante quando dispone del contesto necessario per prendere una decisione migliore.

Il vero progetto è trasformare dati in contesto

Alla fine dei miei primi due giorni di ferie mi sono reso conto che AI-nuoto è in realtà un piccolo laboratorio su qualcosa di molto più grande.

Abbiamo già moltissimi dati personali e professionali distribuiti in applicazioni differenti, il problema è che ogni componente conosce soltanto un pezzo della storia.

L’AI può diventare lo strato capace di collegare questi pezzi

Nel mio piccolo esperimento:

  • Final Surge conosce il programma.
  • Garmin conosce il gesto eseguito.
  • Strava rende accessibile l’attività.
  • La Knowledge conserva la storia.
  • Il profilo fornisce il contesto.
  • L’AI mette tutto in relazione.

La sequenza che mi interessa è quindi:

DATA → KNOWLEDGE → CONTEXT → DECISION

E probabilmente è questo l’aspetto che continuerò a esplorare.

Perché, da nerd appassionato di tecnologia e di lunghe nuotate in acque libere, c’è qualcosa di particolarmente affascinante nell’idea che anni di vasche, chilometri, test, gare e allenamenti non rimangano semplicemente righe archiviate dentro qualche applicazione.

Possono diventare memoria utilizzabile.

E una memoria utilizzabile può diventare contesto e il contesto diventa analisi.

E l’analisi, può aiutarmi a fare una cosa molto semplice:

Nuotare meglio e più veloce!


Nei prossimi articoli: Garmin, Strava e AI: come trasformare i dati reali dell’allenamento in informazioni utilizzabili da un agente AI.

Qui entreremo più nel tecnico: API, OAuth, GPT Actions, Planned vs Completed e architettura dell’integrazione, senza perdere di vista la domanda fondamentale: quali dati servono davvero a un’AI per capire come ci stiamo allenando?

Kubernetes: I componenti

Nei precedenti articoli abbiamo visto alcuni dettagli di come è costruita l’architettura di Kubernetes.

Oggi verranno descritti i meccanismi di funzionamento del motore kubernetes indicando il nome di  ogni componente; per rimanere fedeli al paragone del motore dell’autovettura, parleremo degli alberi a camme, valvole, bronzine, … che afferiscono al Cloud Native

Nota1: Non verrà trattata l’installazione di k8s in Datacenter, Cloud e Laboratorio, la rete ha già messo a disposizione  esaustivi tutorial.

Per i familiarizzare con k8s vi consiglio di utilizzare Minikube (Piattaforma Linux)  Docker Desktop (piattaforma Windows & Mac).

Iniziamo!

Kubernetes Master:  E’ il nodo principale del cluster sul quale girano tre processi vitali per l’esistenza del cluster.

  • kube-apiserver
  • kube-controller-manager
  • kube-scheduler

Nel master node è inoltre presente il DataBase etcd, che memorizza tutte le configurazioni create nel cluster.

I nodi che si fanno carico di far girare le applicazioni e quindi i servizi sono detti worker node. I processi presenti sui worker node sono:

  • Kubelet
  • kube-proxy

kubelet :Un agente che è eseguito su ogni nodo del cluster. Si assicura che i container siano eseguiti in un pod.

Kube-Proxy:  Ha la responsabilità di gestire il networking, dalle regole di Routing a quelle di di Load Balancing.

Nota 2: K8s cercherà di utilizzare tutte le librerie disponibili a livello di  sistema operativo.

kubectl: E’ Il client ufficiale di Kubernetes (CLI) attraverso il quale è possibile gestire il cluster (Kube-apiserver) utilizzando le API.

Alcuni semplici esempi di comandi kubectl sono:

  • kubectl version (indica la versione di k8s installata)
  • kubectl get nodes (scopre il numero di nodi del  cluster)
  • kubectl describe nodes nodes-1 (mostra lo stato di salute del nodo, la piattafoma sulla quale k8s sta girando (Google, AWS, ….) e le risorse assegnate (CPU,RAM)).

Container Runtime: E’ la base sulla quale poggia la tecnologia k8s.

kubernetes supporta diverse runtime tra le quali ricordiamo, container-d, cri-o, rktlet.

Nota 3: La runtime Docker è stata deprecata a favore di quelle che utilizzano le interfacce CRI; le immagini Docker continueranno comunque a funzionare nel  cluster.

Gli oggetti base di Kubernetes sono:

  • Pod
  • Servizi
  • Volumi
  • Namespace

I controller forniscono funzionalità aggiuntive e sono:

  • ReplicaSet
  • Deployment
  • StatefulSet
  • DaemonSet
  • Job

Tra i Deployment è indispensabile menzionare  Kube-DNS che fornisce i servizi di risoluzione dei nomi. Dalla versione kubernetes 1.2 la denominazione è cambiata in Core-dns.

Add-On: servono a configurare ulteriori funzionalità del cluster e sono collocati all’interno del name space kube-system (come Kube-Proxy, Kube-DNS, kube-Dashboard)

Gli Add-on sono categorizzati in base al loro utilizzo:

  • Add-on di Netwok policy. (Ad esempio l’add-on NSX-T si preoccupa della comunicazione tra l’ambiente K8s e VMware)
  • Add-on Infrastrutturali (Ad esempio KubeVirt che consente la connessione con le architetture virtuali)
  • Add-on di Visualizzazione e Controllo (Ad esempio Dashboard un’interfaccia web per  K8s).

Per la messa in esercizio, gli Add-on utilizzano i controller DaemonSet e Deployment.

L’immagine di figura 1 riepiloga quanto appena esposto.

Figura 1