Sep 16, 2020
22 mins read
Cet article n’est pas une présentation du capteur Stryd, ni un descriptif de son utilisation. Il s’adresse à ceux qui connaissent la notion de puissance de course et qui possèdent un capteur Stryd. Il décrit le fonctionnement interne de l’application pour montres Garmin Flat Pace et un teste grandeur nature. Ce n’est pas un tutoriel, ni une documentation de ce champ de donnée.
Pour ceux qui cherchent un test détaillé du foot pod ou des informations pratiques sur la puissance, je les invite à lire l’article de NAKAN “Le Stryd testé de fond en comble” et son dossier sur la puissance.
Ca peut paraître être saugrenu, s’équiper d’un capteur de puissance à 200€ pour n’utiliser que la vitesse. Et pourtant, la première chose qui étonne est la précision de l’allure et de la distance que donne ce capteur1. C’est vrai qu’il ridiculise le GPS à tel point que celui-ci ne sert plus qu’à la navigation.
Mais, la raison principale de préférer l’allure à la puissance vient de la nature même de l’unité de mesure. Ça ne veut, à priori, rien dire que de courir à 250W ou à 300W. Il se peut même que le coureur qui court à 300W est plus lent que celui qui court à 250W car l’énergie à fournir pour maintenir une vitesse dépend en grande partie du poids de l’athlète et de son style de course.
La puissance est en directe relation avec l’effort fournie et elle ne varie pas, théoriquement, en fonction du terrain et des conditions météorologiques. Il n’en reste pas moins que l’interprétation de sa valeur nécessite une certaine expérience. Avec le temps, le coureur arrive à mettre en relation une allure de course avec une puissance donnée.
Seulement, cette mise en relation n’est pas toujours évidente et surtout peut à tout moment varier. Dans mon cas, j’en ai fait l’expérience après avoir perdu 2-3 kg pendant le confinement, la puissance a été recalculée avec comme effet que la correspondance que j’avais en tête n’était plus applicable.
Ceci dit, on pourrait me rétorquer, qu’il serait judicieux de me baser uniquement sur les zones de puissance et d’oublier l’allure qui de toute manière est volatile. Ce n’est pas aussi simple car:
Bref, on peut tourner les choses dans tous les sens, la puissance est géniale pour remplacer la vitesse pendant l’entraînement. Mais, sans connaitre la correspondance entre les deux, elle ne remplace pas sa mesure, elle la complète.
On se retrouve alors à tenir compte de 3 mesures différentes (la fréquence cardiaque, la vitesse et la puissance) et à compliquer l’analyse des courses au risque d’utiliser une usine à gaz pour l’interprétation. Ils suffit de voir ce que certaines plateformes d’analyse proposent: zones de puissance, d’allure et de fréquence cardiaque, leur évolution en fonction de la distance, les moyennes en fonction des distances courues, prédictions de la puissance et allure maximum en course… Bref, on finit par cumuler les graphiques et les tableaux et à perdre de vue l’essentiel.
Une solution est de remplacer la puissance de course par la vitesse équivalente sur une piste d’athlétisme en intérieur. Dans ce cas, il y a une correspondance linéaire entre la vitesse et la puissance. En gros, si courir à 200w correspond à 10km/h et 300w à 20km/h, alors 250w correspond à 15km/h. Il est d’ailleurs remarquable que tous les tests d’effort en laboratoire utilisent cette caractéristique de manière implicite. Pour déterminer les seuils lactiques, par exemple, on réalise une course sur tapis dont on impose la vitesse pour contrôler la puissance fournie par les muscles.
L’allure équivalente sur piste simplifie bien des choses. Dans le cas d’un entraînement basée sur les allures, on peut directement directement se baser sur elle pour la faire en côte (alors que la mesure instantanée est souvent difficilement interprétable). Mais, encore plus intéressant, lors d’une course, on peut l’utiliser pour savoir si on arrive à suivre l’allure fixée en gommant les aléas environnementaux.
Stryd propose un protocole pour déterminer la relation entre la puissance et la vitesse2. Cela demande d’effectuer sur piste des intervalles à différentes vitesses et ensuite de mesurer leurs puissances associées. On fait alors un joli tableau de correspondance et le tour est joué. Il faut bien sûr de temps en temps se coltiner la procédure pour mettre le tableau à jour. À la fin de l’opération, on obtient l’équivalent de la vitesse sur piste pour une valeur de puissance.
On peut estimer la VO2max avec un protocole (comme un test de Conconi qui donne la VMA et en déduire la valeur du VO2max) ou utiliser des algorithmes qui l’évaluent en continu par l’analyse des données de course (comme le fond beaucoup de montres). De la même manière, on peut faire appel à un algorithme qui calcule en temps réel la correspondance vitesse/puissance.
Nous allons voir comment ceci fonctionne avec les montres Garmin.
En général, peu de sociétés exposent le principe de leurs algorithmes sous couvert de protection de leur savoir faire. Et même parfois, c’est simplement pour cacher que leurs algorithmes sont vraiment pas d’une intelligence remarquable et relèvent plus de la petite cuisine. J’estime de mon côté que de comprendre le principe permet une meilleur utilisation.
Tout algorithme a un domaine d’application et connaitre son fonctionnement permet de s’y limiter correctement pour éviter les analyses fantaisistes.
L’explication que je vais tenter de faire n’exposera que les bases de manière à ne pas bombarder de formules mathématiques le coureur. Elle vise uniquement à permettre une utilisation optimale.
Avant de pouvoir faire une analyse, il est nécessaire de mesurer avec précision. Ceci peur sembler trivial mais ça ne l’est pas vraiment :
La vitesse mesurée par le GPS n’est tout d’abord pas aussi précise mais en plus elle souffre d’une certaine latence. Elle n’est pas déterminée après 2-3 secondes mais souvent au bout d’une vingtaine et, en plus, elle n’est pas instantanée mais moyennée sur cette période. Il est donc conseillé de changer dans les montres, qui le permettent (comme les Forerunner ou Fenix), la source de la vitesse et de la distance en donnant la priorité au capteur Stryd.
La technique employée pour prendre en compte les vitesses provenant aussi du GPS est d’utiliser le couple vitesse/puissance le plus stable pendant 5 secondes toutes les 25s. Cela permet de gérer les intervalles 30/30 très populaires tout en s’assurant que les mesures prises ne correspondent pas à la phase instable de l’accélération.
D’une manière très simpliste, la relation entre la puissance et la vitesse est purement linéaire:
$$ Vitesse = a \times Puissance$$
Néanmoins, ceci n’est vrai que si l’on considère juste la puissance utilisée pour le déplacement horizontal. Il y a aussi une partie non négligeable perdue de manière latérale ou verticale. Stryd parle de Form Power. Du coups, à cette formule on ajoute un paramètre constant de perte en la rendant affine:
$$ Vitesse = a \times Puissance + b$$
Comme la relation n’est pas à 100% affine et qu’une petite courbure peut exister, on encadre cette formule par une fonction convexe (ici une puissance supérieure à 1) et une fonction concave (la racine carrée):
$$ Vitesse = a \times Puissance + b + c \times Puissance \sqrt{Puissance} + d \times \sqrt{Puissance}$$
L’algorithme cherche donc à déterminer ces quatre paramètres et utilise ensuite cette formule pour en déduire la vitesse associée à la puissance.
Il est à noter que lorsque l’on marche, la puissance est tout à fait différente de celle de la course. Form Power devient bien plus faible et la puissance de manière générale l’est aussi. La formule de calcul de la vitesse ne peut donc pas être appliquée à la marche. De même, il faut suspendre l’apprentissage de l’algorithme lorsque le coureur marche.
C’est pour cette raison qu’un paramètre d’allure minimale en course (9:00 min/km) permet filtrer les phases de marche. Il peut être modifié en éditant les paramètres dans ConnectIQ.
Pour que l’apprentissage fonctionne, il faut que l’algorithme n’apprenne que les mesures lors de courses sur un terrain plat. On pourrait utiliser les dénivelés pour filtrer les valeurs mais la précision des capteurs barométriques est trop mauvaise pour des pentes faibles ou courtes et, de toute manière, le capteur n’est pas présent sur toutes les montres.
Pour cette raison, on exploite l’hypothèse que si on court plus vite sur une route plate, la puissance augmente. Cela peut paraitre trivial, mais dans une montée, on se retrouve dans le cas inverse: la puissance grimpe alors que la vitesse réelle diminue.
D’une manière simpliste, on estime que la vitesse dans ce cas doit suivre une courbe (avec e>0): $$ Vitesse = e \times Puissance + f$$
Nous considérons alors que la vitesse mesurée est entachée d’une erreur par la formule:
$$ Erreur = \lvert Vitesse - ( e \times Puissance + f ) \rvert$$
Les deux paramètres e et f sont alors appris lors de la course. Et, l’erreur calculée est utilisée pour donner un poids plus ou moins important à la mesure: plus qu’elle est faible, plus haute sera son impact sur la formule de calcul de l’allure sur piste.
L’estimation des paramètres est faite en utilisant l’algorithme des moindres carrées qui permet de minimiser la variance de manière optimale entre la courbe théorique et les mesures.
Comme il y a en tout 6 paramètres à estimer, il faut au moins 6 mesures. Donc, lors d’une première utilisation, il faut environ attendre 3 minutes avant de pouvoir avoir une première estimation de la vitesse sur piste. Puis, toutes les 25 secondes, l’algorithme se corrige pour coller au plus possible à l’ensemble des valeurs mesurées.
Il est à noter qu’à la fin d’un session, les paramètres sont enregistrés et que l’historique des six dernières heures de course est prise en compte (configurable par GarminIQ).
D’une manière générale, il est conseillé de faire un étalonnage pour éviter d’apprendre dès le début des valeurs incohérentes.
Le mieux est de procéder de la manière suivante:
La théorie est une chose, il reste à passer à la pratique et de faire un test en grandeur nature. Pour ça, il s’agit tout d’abord à procéder à une course d’étalonnage dans un environnement idéal (pas de vent, pas de dénivelés). Puis, on passe à un terrain avec des montées et des descentes prononcées ou avec des conditions de vents forts pour tester la pertinence du calcul.
Voici les 10 premières minutes de course lors d’une première utilisation sur une route sans dénivelés.
Pendant les premières minutes (partie A), aucunes données ne sont disponibles, l’estimation de l’allure sur piste est alors impossible. Garmin Connect affiche une courbe plate pour sa vitesse (couleur grise) ce qui, dans ce cas, signifie simplement qu’aucune valeur n’est enregistrée. Il faut compter deux minutes pour un premier calcul. Et on constate que les premières valeurs produites sont encore très instables. Bien que courant à une vitesse constante de 2.7 m/s, la vitesse estimée sur piste oscille de 2 m/s à 4.5 m/s. Il faut compter 5 minutes de course pour qu’elle se stabilise à des valeurs cohérentes.
Durant les 10 premières minutes, l’allure était constante et on constate que la vitesse sur piste finit par être presque identique à celle mesurée. Néanmoins, vers 8 minutes (marqueur B), il y avait une légère montée d’une dizaine de mètres où la puissance a augmenté sensiblement à une valeur inconnue pour l’algorithme (200w). La valeur calculée est de ce fait encore incohérente: la puissance augmente mais la vitesse sur piste diminue très sensiblement pour passer à 2.8 m/s à 2 m/s, une aberration.
Pour régler le problème, je décide de courir 30 secondes de manière soutenue (marqueur C). On constate alors que dans les premières secondes, l’algorithme débraille à nouveau et est incapable de calculer une vitesse mais au bout de 20s, apprenant le nouveau couple vitesse/puissance, il se corrige et produit alors une vitesse sensiblement équivalente (4.0 m/s contre 3.7 m/s).
Après 15 minutes, j’ai bifurqué sur un sentier boisé. Route très sinueuse, montées raides et courtes de 10m à 15m, descentes à pic, arbres couchés… La puissance et la vitesse instantanée ne sont plus fiable et mais rien de mieux pour tester les perturbations sur le calcul…
En sortie du bois, une légère pente courue à vitesse constante. La vitesse estimée sur le plat diminue et colle à la courbe de puissance. C’est en fait cohérent : courir en descente requiert moins d’effort que sur le plat, c’est un peu comme courir moins vite sur une piste.
Ensuite, une montée régulière et l’effet inverse est constatée: la vitesse estimée augment par rapport à la vitesse réelle ce qui est encore cohérent.
Pour finir, j’ai fait une étape de plusieurs minutes sur une route forestière pratiquement plate à une vitesse constante de 3.3 m/s. La vitesse estimée collait alors à la vitesse réelle, ce qui était aussi cohérent.
On peut aussi analyser les intervalles, présentés dans le tableau suivant.
Circuits | Temps de déplacement | Allure moyenne en déplacement | Pace on Flat Road | Lap Power |
---|---|---|---|---|
1 | 16:57 | 6:04 | 5:58 | 176 |
2 | 6:31 | 6:49 | 6:19 | 158 |
3 | 6:54.5 | 6:18 | 6:19 | 166 |
4 | 14:25 | 4:58 | 4:57 | 210 |
Le premier intervalle est utilisé pour l’apprentissage des premières mesures, on peut l’oublier.
Le deuxième correspond au sentier escarpé, la seule chose que l’on peut conclure est que l’allure réelle (6:49) est bien plus faible (6:19) que ce qu’elle aurait été sur une piste. Mais, il est impossible de savoir si elle était estimée avec précision tant le terrain était accidenté.
Le troisième intervalle correspond à la légère pente de montée puis de descente. L’allure sur piste est identique à celle de l’allure mesurée car celle de la montée, plus forte, est compensée par celle de la descente.
Le dernier intervalle correspond à la course sur le plat à une allure constante de 5:00. Ici, les deux allures sont identiques.
Après deux heures de courses en plaine, je me suis décidé de tester l’algorithme en montagne. C’est un environnement qui en soi est difficile pour principalement une raison: il y a un risque de dérèglement de l’algorithme. En effet, ce genre d’environnement n’est pas propice à l’étalonnage et l’algorithme peut par erreur désapprendre la configuration apprise précédemment.
De manière un peu caricaturale, en courant une montée puis une descente, la vitesse de montée est bien plus faible que celle de la descente. Par contre, la puissance se comporte de manière inverse: la montée requiert un effort important alors que la descente est presque de la roue libre. Le résultat pourrait être que l’algorithme assimile les hautes puissances à de faibles vitesses, ce qui serait un non-sens.
Le parcours choisi est le tour le l’Alambre qui est dérivé du trail du Mézenc. Pendant les premiers 500m, la montée empreinte un remonte-pente d’une piste de ski (circuit 1). C’est raide et à la limite d’être faisable en course, presque à faire uniquement en marchant. Puis, une succession de faux plats et de montées régulières qui restent agréables à courir (circuits 2 à 7). Les 500m premiers mètres de descente (circuit 8) sont techniques car le chemin en forêt, truffé de cailloux et de nids de poules, requiert un minimum d’attention. Pour finir, une longue descente sur route goudronnée (circuits 9 et 10).
Le premier point remarquable est que de manière générale la vitesse à plat reste cohérente. J’avais fait une course étalonnage avant suivi d’une course lente d’une heure. En gros, 20km de course en plaine sans vent avant d’attaquer la montagne. Arrivé en montagne, j’ai couru environ 70km et l’algorithme continuait à livrer des mesures qui étaient en accord avec les premières courses.
C’est à dire :
Donc, l’algorithme reste étalonné correctement et détecte correctement les sections plates pour se peaufiner en continue.
Voici les données circuits par circuits:
Circuits | Distance | Gain alt | Perte d’altitude | Allure moyenne en déplacement | Pace on Flat Road | Lap Power |
---|---|---|---|---|---|---|
1 | 0,56 | 53 | – | 8:23 | 5:09 | 197 |
2 | 0,21 | 16 | – | 7:49 | 5:50 | 179 |
3 | 0,54 | 1 | – | 6:04 | 5:53 | 178 |
4 | 0,78 | 56 | – | 7:22 | 5:14 | 194 |
5 | 0,44 | 12 | – | 6:08 | 6:20 | 169 |
6 | 0,94 | 15 | 11 | 6:12 | 6:05 | 174 |
7 | 2,07 | 69 | 5 | 6:44 | 5:50 | 179 |
8 | 0,91 | – | 53 | 6:09 | 7:15 | 154 |
9 | 1,35 | – | 65 | 5:58 | 6:20 | 169 |
10 | 1,29 | – | 86 | 5:36 | 6:43 | 163 |
11 | 0,07 | – | 3 | 6:16 | 7:27 | 149 |
Le premier circuit est particulier et difficile à interpréter. En fait, la pente est supérieure à 10% et le terrain est particulièrement escarpé. Je me suis retrouvé à courir sur la pointe des pieds car mon talon ne pouvais plus toucher le sol. Et, les irrégularités étaient telles qu’il était difficile de profiter du rebond pour maintenir l’allure. Du coups, je ne sais pas si la valeur de puissance calculée par le capteur Stryd correspond à la réalité ou si je ne me suis pas épuisé en perdant plus de puissance que sur route. Quoi qu’il en soit, mon impression était de fournir un effort bien au-delà de ma puissance critique (207w) alors que le capteur Stryd livrait une puissance bien inférieure. Bref, difficile de porter un jugement sur ce segment.
Le circuit 4 et 7, sont des montées régulières, les pentes sont certes différentes mais l’estimation de la vitesse sur piste était assez cohérente à l’effort ressenti:
Pour la portion plate (circuit 3), la vitesse sur circuit est très légèrement supérieure à la vitesse réelle. Il est difficile de savoir pourquoi. Peut-être la nature terrain (ici une piste caillouteuse et non une route goudronnée), le vent qui était latéral mais fort ou encore le fait qu’il ne soit pas tout à fait plat (le dénivelé reporté par ma montre Forerunner 245 n’es pas correct puisqu’elle ne dispose pas d’un altimètre barométrique) peuvent être à l’origine des différence. Mais, la valeur mesurée reste suffisamment proche de l’estimation pour être fidèle au ressenti.
La descente est particulièrement intéressante car je me suis retrouvé dans 3 situations tout à fait différentes :
L’impression générale sur ce qu’à livré l’estimation de l’allure sur piste est bonne. Le seul bémol concerne les pentes trop raides mais là, on peut se demander si on n’est pas à la limite de ce que le capteur Stryd est capable d’analyser et si on n’est simplement pas à la limite où il faudrait peut-être marcher et non plus courir.
Il n’est tout d’abord pas nécessaire de courir pendant des heures pour obtenir des valeurs de vitesses cohérentes. Néanmoins, il faut absolument courir les premières minutes sur une route sans dénivelés prononcés et surtout faire varier les vitesses de course pour que l’algorithme apprenne toutes les plages de vitesse.
Ensuite, les perturbations d’allures causées par terrain sont bien gérées et ne perturbent pas le calcul. On se retrouve ensuite avec une valeur qui correspond à ce qui est attendu: dès que l’on est sur une portion plate et sans vent, les allures mesurées et sur piste sont identiques. Par contre, en côte, l’écart se creuse et la vitesse sur piste devient largement supérieure à la vitesse réelle. Mais, surtout elle correspond à l’effort fournie sur piste, du moins tant que l’on reste dans des configurations de terrains adaptées à la course.
L’application n’est certes pas finie, l’algorithme est validé mais des corrections et des extensions pratiques sont encore à ajouter. Et puis, la puissance en course permet encore bien d’autres développements mais ce sera l’objet des applications futures…
L’article “Stryd, le capteur le plus précis du monde!” est très instructif et, en anglais, “GPS Accuracy of Garmin, Polar, and other Running Watches” contient une batterie de tests et de mesures. ↩︎
Voir l’article “How can I convert my pace based plan to a power plan?”. ↩︎
Partagez pour mieux faire connaître!