Dans ce fil, je vais vous expliquer pas à pas la méthodologie qui m'a permis de comprendre pourquoi la distance affichée par la Suunto Ambit est systématiquement inférieure à ce que donne des logiciels comme SportTracks(2)/RubiTrack/.... (même Movescount) quand on réimporte la traces dans ces logiciels.
Pour ceux qui ne veulent pas se farcir toute ma prose voici en résumé les conclusions:
-la trace de l'Ambit en enregistrement 1s ressemble souvent à celle d'un ivrogne qui titube de droite à gauche, d'autant plus quand la réception satellite est mauvaise. SportTracks(2), bien que disposant de plein d'options de lissage, n'en a pas pour le calcul de distance, et additionne simplement la distance entre points. Du coup, il va systématiquement surestimer la distance réelle.
-l'Ambit, quant à elle, ne va retenir pour le calcul de la distance que des points distants d'au moins deux fois l'erreur de positionnement GPS, ce qui revient de facto à un lissage de trace. Pour un parcours relativement droit et en terrain découvert, la distance donnée par l'Ambit va être précise. Pour un trail en terrain dense et avec nombreux virages, où la distance entre deux points retenus peut aller jusqu'à 50m (!), elle donnera une distance sous estimée, car aura tendance à couper les virages.
-ni l'Ambit, ni SportTracks(2), ne prennent en compte la correction de pente dans le calcul de distance, la distance étant celle projetée sur l'horizontale. Sur un trail dont la pente moyenne ne dépasse pas 15%, cette correction sera inférieure à 1%. Sur un Kilomètre vertical avec une pente de 50%, il faudra ajouter 10% pour obtenir la distance parcourue sur le terrain.
Avant tout, je tiens à remercier "montant" d'avoir mis gracieusement à disposition un script python qui permet de convertir le fichier log au format xml en gpx. Ca m'a grandement facilité la tâche, merci
Je remercie également Guenael,Antoine26,paulotrail,cga2 et Romain de m'avoir fourni quelques traces au format xml, car je ne possède pas moi même ce bijou de technologie.
Et en dernier, je remercie Suunto d'avoir choisi le format xml pour ses log, lisible par n'importe quel éditeur de texte, et surtout d'avoir mis dedans toutes les informations imaginables. Bien mieux que le format .fit propriétaire de Garmin.
Egalement, je tiens à préciser que je ne m'intéresse ici qu'au calcul de la distance, et pas à celui du dénivelé, décrit formidablement par Flo2Cannes. Ceci étant dit, passons à la méthode.
1/D'où il suffit de savoir lire les fichiers xml
Bon, je ne vais pas me la péter, il m'a suffit de lire et d'interpréter le fichier log au format xml pour arriver à mes trouvailles. Bien d'autres ici savent le faire (montant, Antoine26, serge ....), il leur a juste manqué un chouia de méthode pour me devancer
Ce fichier log de l'Ambit commence par une section <header> (en-tête), qui contient en gros un résumé de la trace:
Entouré en rouge, la distance calculée par l'Ambit. Comment, nous allons voir ça de suite.
Après l'entête, on va trouver des <sample>, qui vont contenir les infos de chaque trace GPS (enregistrées chaque seconde pour les traces que je vais commenter): latitude, longitude, altitude (baro et GPS), ainsi que des paramètres calculés par l'Ambit: distance, vitesse, énergie, ...
Le premier <sample> après l'entête:
On peut voir que la distance calculée reste égale à 0 sur les deux premiers samples. En fait, elle reste égale à 0 jusqu'au 7ème sample, enregistré 7s après le départ de la trace, où elle passe à 16m:
Le plus probable, c'est que 16m est la distance entre le premier "fix gps", et celui obtenu après 7s. C'est à dire que l'Ambit ignore simplement un paquet de "fix gps" trop rapprochés. Pour confirmer cette hypothèse, et comprendre sur quel critère l'Ambit décide d'éliminer certains points, c'est là qu'un peu de méthode scientifique aide.
2/ Extraction des points GPS retenus par l'algorithme Suunto
Dans l'épisode précédent, on a vu que la distance calculée par l'Ambit ne changeait pas à chaque "fix gps", mais que de temps en temps. Pour comprendre plus en avant, on va donc simplement modifier un poil le script python de "montant", et lui faire écrire dans un fichier gpx que les points gps où la distance change (entouré en vert dans l'image précédente). On va donc se retrouver avec un fichier gpx qui va contenir nettement moins de points que le fichier original qui contient un point par seconde. On va également écrire en parallèle un fichier au format csv, qui sera plus simple pour continuer une analyse scientifique.
Ceux qui ont bénéficié de ces fichiers gpx "filtrés" en avant première savent déjà qu'en important ce fichier gpx dans SportTracks(2), on retrouve bien la distance calculée par l'Ambit (sauf à une exception près que j'ai fini par comprendre). Mais ça ne nous explique pas le pourquoi du comment.
Donc nous allons analyser ici un des fichiers csv (en fait xls) du TGV d'Antoine26 (dans l'épisode 1, c'était un fichier de Guénael). Voici le début du fichier, avec l'enregistrement des 45 premiers fix gps filtrés:
Les deux premières colonnes sont simples à comprendre (latitude et longitude en degrés).
La troisième colonne correspond à la distance entre les points N et N-1, calculée comme suit:
a = sin²((lat(N)-lat(N-1))/2) + cos(lat(N-1)).cos(lat(N)).sin²((long(N)-long(N-1))/2) (haversine)
c = 2.atan2(?a, ?(1?a))
d = R.c, où R est le rayon moyen de la terre = 6371km.
Pour ceux qui auraient des doutes, ça correspond à mieux que 10E-6 près à la distance à vol d'oiseau, projeté en horizontal, c'est à dire sans prendre en compte la différence d'altitude. C'est une précision importante pour la suite, car ça écarte mon hypothèse initiale que j'avais émise dans le fil Ambit noire.
La quatrième colonne donne la distance entre les deux points comme évaluée par l'Ambit, les deux colonnes suivantes les distances cumulées, puis EHPE et alti baro. La colonne avec le temps a sauté dans une manip de conversion d'image, elle servait à illustrer que chaque point correspondait à des intervalles de temps qui s'échelonne typiquement de 5 à 15s, mais pas toutes les secondes.
On peut voir que j'ai bien conservé les bon points GPS, car la distance calculée correspond à l'arrondi près à celle de l'Ambit. De temps en temps, l'écart entre mon calcul et Ambit dépasse l'arrondi au mètre, je pense que c'est du au fait que parfois, le bon fix GPS n'est pas toujours enregistré entre les deux samples où la distance Ambit change, va savoir, Charles.
Voici la fin du fichier, où on peut comparer ma distance cumulée avec celle de l'Ambit:
Ambit: 55.40 km
Cloclo (xml): 55.62 km
SportTracks(2) gpx 1s Ambit: 60.55 km
SportTracks(2) gpx filtré Cloclo: 55.68 km
Pour vous donner une idée de l'origine de la différence, voici une vue de la trace originale et filtrée affichée dans SportTracks(2) par dessus OpenStreetMap (l'originale ressemble à celle d'un ivrogne qui titube de gauche à droite, alors que la filtrée est bien plus lissée):
3/ Décryptage de l'algorithme de calcul de distance sur l'Ambit
Résumé de l'épisode précédent: on y a vu et démontré que Suunto n'utilise qu'une fraction des enregistrements GPS pour déterminer la distance totale d'un parcours. Sur quel algorithme se base Suunto sur le choix de ces points GPS, c'est ce que nous allons voir de suite.
Pour arriver à mes fins, je ma base sur le fichier xml que j'ai décrit dans 2/, où j'ai enregistré et calculé la distance entre les points retenus par Suunto, ainsi que le fameux EHPE. Non, ce n'est pas la dernière molécule dopante à la mode, mais simplement l'erreur de position associé à l'enregistrement GPS: Estimated Horizontal Position Error.
C'est là qu'il m'a fallu le seul soupçon de jugeotte, pour réaliser que la distance entre deux points retenus était corrélée à ce fameux EHPE. Voici le graphe montrant cette corrélation pour la trace du MMB de paulotrail:
On se rend immédiatement compte qu'il n'y a quasi pas de points dont la distance est inférieure à 2*EHPE. Donc mon postulat est que l'alogrithme Suunto est grosso merdo le suivant:
-je part du premier point GPS enregistré
-j'attends d'avoir un second point distant de plus de 2*EHPE du premier, et je calcule la distance avec le point précédent
-je boucle ainsi jusqu'à la fin de la trace.
Voilà, je m'arrête là pour l'instant, le secret de Suunto est dévoilé pour l'essentiel.
4/ Analyse de traces xml de Kikous et bugs Suunto
Passons aux travaux pratiques, à savoir l'application du filtre développé en 2/ à 13 traces gentiment fournies par quelques Kikoureurs. Voici le tableau des résultats:
Explications des colonnes:
-D Ambit: distance en km mesurée par l'Ambit
-D ST 1s: distance en km calculée par SportTracks(2) à partir du fichier original
-D CG 1s: distance en km calculée par Course Generator à partir du fichier original
-ST 1s/Ambit %: écart en % entre la distance calculée par l'Ambit et ST à partir du fichier original
-D ST filtré: distance en km calculée par SportTracks(2) à partir du fichier filtré
-D CG filtré: distance en km calculée par Course Generator à partir du fichier filtré
-ST filtré/Ambit %: écart en % entre la distance calculée par l'Ambit et ST à partir du fichier filtré
Petite précision: ici, j'ai désactivé la correction de pente prise en compte par défaut dans CG, en le flouant avec un fichier gpx où j'ai remplacé les valeurs d'altitude par 0 dans le champ <ele>.
Sur les 13 traces analysées, 11 ont d'emblée un écart entre la distance calculée par l'Ambit et ST à partir du fichier filtré de moins du %, même si l'écart entre l'Ambit et ST à partir du fichier original peut atteindre jusqu'à 23% pour la trace de Paulotrail dans les Bauges. Donc le filtrage marche nickel chrome ! Quand l'écart entre la distance calculée par l'Ambit et ST à partir du fichier original est inférieure à 5%, je dirai que ce que donne l'Ambit ne doit pas être loin de la vérité. Mais quand ça atteint 23%, l'Ambit doit surement un poil sous évaluer la distance, mais de combien? 1% 2% 5% ???
Mais deux traces posent problème:
-celle de cga2 du 01/07, où il manque de l'ordre 600m après filtrage. Une inspection de la trace dans le log xml révèle de suite le blème. L'Ambit n'a pas enregistré de fix gps pendant environ 5 minutes, pendant lesquelles le compteur de distance a pourtant tourné jusqu'à 618m. Il semble qu'il est possible de démarrer une trace sur l'Ambit même si la qualité de réception satellite est très mauvaise. D'ailleurs la première valeur EHPE loggée est de 52m !!! Voici la trace en question, cga2 m'a affirmé que c'est un aller/retour sur le même chemin. Même le premier fix gps est à 200m du bon endroit, ça se stabilise seulement au bout d'un certain temps ;-( D'ailleurs, sur ce fil sur le forum watchuseek, un gars a une trace qui a débuté à 6 km du départ réel !!!!!!
En corrigeant la distance du fichier gpx de ces 618m, on obtient un bon accord Ambit/ST filtré.
-la trace de Romain33-relief (reconnaissance du MMB si je ne me trompe):
Ici, le log xml montre qu'il y a un fix GPS au démarrage, mais au bout de 7s, plus d'enregistrement de rien du tout (même distance) pendant 3'29", où il y a un nouveau fix gps, mais la distance calculée par l'Ambit est toujours de 0, alors qu'il a parcouru 705m dans l'intervalle. Le plus probable, c'est qu'il y a peut-être eu un STOP après 7s, er de nouveau START après 3'29", mais l'Ambit a concaténé le petit morceau au reste de la trace, va savoir, Charles. Ce qui compte, c'est si on prend en compte de ces 705m, tout rentre dans l'ordre.
Edit suite à un commentaire de "montant":
Ces deux traces à "problème" sont du 30/06 et 01/07 2102, ce qui correspond à la date où une seconde additionnelle a été rajoutée à UTC:
http://en.wikipedia.org/wiki/Global_Pos ... ap_seconds
L''Ambit a pu être sensible à l'introduction de la "leap second" le 30 juin, mais dans ce cas, c'est parce qu'elle a mis du temps à assimiler le message inclus dans le train d'infos GPS qui donne l'écart entre le temps GPS et le temps UTC, et du coup à réinitialiser cet écart utile dans le calcul de la position.
Et dans ce cas, une différence de 1s correspond à environ 500 m sur le terrain.
5/ Fusespeed au secours du GPS
Comme vu en 4/, la trace de cga2 du 01/07 n'a pas de donnnées GPS enregistrée pendant les premières 5 minutes, car la qualité de réception satellite était trop mauvaise au démarrage. Un update hier soir du post sur le forum watchuseek avec une trace qui a commencée à 6 km du point de départ réel, et qui n'a retrouvé le bon chemin qu'au bout d'une heure permet d'expliquer ce qui s'est passé.
Suunto a bien vendu Fusespeed pour non seulement améliorer la précision de la mesure de vitesse, mais aussi pour pallier à une perte momentanée du signal GPS (genre sous les ponts), et comme l'accéléromètre est calibré en permanence sur le GPS, permet de continuer à calculer la distance dans ce cas. Très bien. En analysant le fichier xml (encore lui), le gars sur watchuseek s'est rendu compte que quand Fusespeed prend le pas sur le GPS, il n'y a évidemment pas d'enregistrement GPS (comme sur le début de trace de cga2), mais la distance est updatée toutes les secondes. Donc facile à voir dans le xml. Et effectivement, c'est le cas pour la trace du 01/07 de cga2.
Donc Suunto a pris le choix délibéré de pouvoir commencer l'enregistrement, même s'il n'y a pas de fix GPS au départ, en utilisant dans ce cas FuseSpeed. Le hic, c'est que:
1/FuseSpeed n'est pas calibré, car il n'y a encore eu de mesure GPS. Pas très grave, il doit prendre la dernière calibration de la séance précédente.
2/Pas d'enregistrement de la trace GPS comme dans le cas cga2, et au retour, on retouve une drôle de trace tronquée.
Je trouve que pour le prix de l'engin, c'est moyen. Suunto devrait au moins proposer dans le menu une option d'initialisation GPS plus longue, mais plus sure, pour les traileurs qui ne sont pas à 5 minutes près.
6/ Correction de pente pour le calcul de distance
Pour illustrer l'effet de la prise en compte de la pente dans le calcul de la distance (et ne plus avoir des distances projetées sur l'horizontale comme jusqu'ici), je m'appuie à nouveau sur les 13 traces discutées en 4/et moulinées avec l'excellent Course Generator de patrovite, qui inclue la correction de pente par défaut. Voici le tableau des résultats:
Explications des colonnes:
-D Ambit: distance en km mesurée par l'Ambit
-D+, D-: cumul de dénivelé en montée et en descente
-D CG 1s: distance en km calculée par Course Generator à partir du fichier original sans correction de pente (proj. hor., <ele>0</ele>)
-D CG filtré: distance en km calculée par Course Generator à partir du fichier filtré sans correction de pente (proj. hor., <ele>0</ele>)
-D CG cor pente: distance en km calculée par Course Generator à partir du fichier filtré avec correction de pente (par défaut dans CG)
-D CG 1s/Ambit %: écart en % entre la distance calculée par l'Ambit et CG à partir du fichier original (proj. hor.)
-Cor pente CG %: écart en % entre la distance calculée par CG à partir du fichier filtré avec et sans correction de pente
Pour que Course Generator donne des résultats fiables concernant la correction de pente, il faut lui entrer des données lissées en altitude. C'est le cas ici, car on part du fichier filtré, qui ne retient en moyenne qu'un point toutes les 7s, et en plus, j'ai bien évidemment utilisé l'alti baro qui a des variations bien plus douces que l'alti GPS. Les traces pour lesquelles la correction est la plus forte (jusqu'à 5%) sont évidemment celles où ça monte dré dans le pentu. Le TGV, c'est de la gnognotte à coté
.Ce qui m'avait induit sur une fausse piste au départ sur le fil de la black Suunto, c'est l'apparente corrélation entre le % de correction de la pente, et l'écart entre la distance Ambit/ST à partir de la trace originale (ici CG 1s). Mais en fait, c'est purement fortuit:
-aussi bien l'Ambit, que SportTracks, ou CG si je mets le champ <ele> à 0, calculent des distances projetées à l'horizontale
-la correction de pente est au moins 5 fois plus petite dans les cas étudiés que l'écart de distance mesurée par l'Ambit et SportTracks à partir du fichier avec enregistrement toutes les secondes, et ne suffit absolument pas à expliquer la différence Ambit/ST 1s
En fait, il se trouve que c'est en montagne, avec des vallées escarpées (ou en terrain arboré dense), que l'Ambit a la précision GPS la pire: effet de réflexion d'ondes mal filtrés, dégradation du signal GPS, ...
Pour les curieux, explication de la dernière colonne (Cor pente bis %): c'est basé sur l'hypothèse que le D+ et D- sont répartis en moyenne sur les 2/3 du parcours, et le 1/3 restant est plat. Du coup, la distance "réelle" (Dr), est obtenue à partir de la distance projetée sur l'horizontale (Dh), en appliquant le théorème de Pythagore:
Dr = Dh/3 + ?((D+ + D-)²+4/9*Dh²) et (Cor pente bis %) = (Dr/Dh-1)*100
Avec cette petite formule "ad hoc", vous pouvez calculer vous même la distance corrigée de la pente à mieux que le %, avec juste la distance mesurée par l'Ambit, et le D+ et D-.
Voilà, tout, tout, tout, vous savez tout sur le calcul de distance de l'Ambit.
au km 48, j'étais dans les clous avec l'Ambit au poignet par rapport aux indications de l'organisation. Si j'avais été au bout, vu ce qui c'était passé aux divers points de contrôle que j'ai ralliés, j'aurais trouvé les 58 km annoncés officiellement.
). Je me suis amusé à estimer la distance comme je l'ai fait dans mon fichier excel (simple somme des distances, sans lissage aucun), avec cette fois la trace originale avec l'enregistrement toutes les secondes. Et pour ton TGV, je trouve 60.31 km, contre 60.55 pour SportTracks. SportTracks a plein d'options de lissage, sauf pour le calcul de la distance.
) ... personne n'a remarqué ça ?
