Calcul de pente (instantanée) incohérent
Bonjour,
Le sujet a été évoqué par Thierry C. dans d'autres discussions, à savoir des calculs de pente apparement (manifestement) aberrants sur certaines traces enregistrées.
Je n'utilise pas habituellement cette fonctionnalité (ni dans Land, ni en instantané sur le GPS), mais j'ai voulu voir par curiosité.
En préambule, il faut dire que je n'utilise le GPS que pour de la randonnée en général. En randonnée, la pente reste inférieure à (très environ) 50%, mais ponctuellement, en particulier en montagne, elle peut être bien supérieure (passages raides, équipés de cables, type via-ferrata, ...). Mais dans ce cas, si la pente est très élevée, cela s'accompagne obligatoirement d'une variation d'altitude qui doit être visible sur la trace enregistrée.
J'ai donc regardé ce que montre les graphiques comparés avec l'altitude et la pente produits par Land. Et j'ai constaté des pentes indiquées à plus de 100%, jusqu'à 200% (jamais plus, ce doit être une limite logicielle pour que ça plafonne très exactement à +/-200%), qui ne correspondaient pas à des changements d'altitude.
J'ai isolé deux cas différents, avec deux explications différentes.
Premier cas :
Dans un autre fil, je détaille une anomalie rencontrée sur le GPS Twonav Cross lorsqu'on manipule les boutons : cela produit une impulsion anormale sur l'altitude enregistrée (surpression interne sur le capteur barométrique).
Dans cette situation, cette impulsion d'altitude s'accompagne d'une impulsion équivalente de la pente, le qu'on peut le voir sur ce graphique :
La corrélation est évidente, et somme toute "logique". Une correction de la courbe d'altitude efface/effacerait par la même la variation anormale de pente.
Deuxième cas :
Dans ce cas, je trouve une variation de pente, sans anomalie concernant l'altitude, tel qu'on peut le voir ici :
La trace semble normale (ne pas faire attention à l'aspect "flouté" de la trace, c'est ma version macOS de Land qui bugue sur l'affichage pour cause non support du 3D et d'antialiasing depuis la dernière version de macOS).
Alors quoi ?
Ben non... la trace n'est pas "normale", il faut zoomer énormément dessus pour s'en rendre compte (ou bien analyser points par points le fichier TRK) :
On voit le niveau de zooming en bas à droite de la capture. En fait, à l'endroit de l'indication de pente aberrante, la trace présente un "twist" (qui ne correspond qu'à quelques points seulement). Cela peut être du à une perte temporaire de qualité de réception, mais aussi à un rapide tour sur moi-même pour parler à quelqu'un tout en marchant, à un dépôt du sac à terre le temps de faire autre chose, ...
Ce qui est certain, c'est que Land indique un changement de pente monstrueux sans variation d'altitude, ce n'est pas normal ! De toute évidence, l'algorithme de calcul de pente a des difficultés à gérer les changements brusques de direction. Je ne montre pas d'autres captures d'écrans, mais sur cette seule trace, j'ai une bonne dizaines de cas identiques, croyez-moi. Et donc des statistiques concernant la trace brute erronées.
C'est bien un problème du à Land (en fait, le même souci existe sur le firmware des GPS qui indique aussi des pentes à 200%, même si on n'a pas le graphique correspondant sur le GPS). Pour s'en convaincre, voir cette trace :
Même souci, et la source n'est pas un fichier TwoNav .TRK, mais un fichier NMEA provenant d'un smartphone. C'est donc bien la traitement logiciel de la trace par Land qui est en défaut, mais pas l'enregistrement lui-même. Ici, en zoomant sur la trace, on obtient également un twist, auquel on ne faut pas attention sur une vision plus macroscopique du tracé :
En conclusion (forcément provisoire et partielle), je dirais :
- il n'y a pas de problème matériel avec ces pentes anormales, c'est "juste" un problème logiciel (c'est déjà ça !) ;
- cela montre, si on n'en était pas encore convaincu, les limites des statistiques temps réels faites sur les enregistrement par le GPS, elles sont forcément entachées d'erreur dues à des relevés moins précis. En particulier, les valeurs maximales et minimales de certains paramètres sont forcément inexactes !
- cela montre qu'il est nécessaire pour une exploitation cohérente des traces de les "nettoyer" de tout ce qui est aberrant, hors cohérence avec la géographie du lieu ou la physiologie et les capacités physiques de l'utilisateur.
- il est inadapté de réaliser certaines statistiques, mesures, ..., a des fréquences étrangères aux conditions physiques : même si on enregistre à une fréquence élevée (1hz, un point par seconde), il est/serait nécessaire que le firmware en amont effectue un filtrage pour supprimer le bruit du paramètre mesuré. Et le traitement logiciel doit/devrait avoir des vérifications de cohérence : afficher une pente à 200% quand l'altitude de varie pas, cela devrait provoquer une élimination de la mesure jugée non-conforme par exemple.
Voilà... encore une proposition d'amélioration et de travail que je fais aux développeurs TwoNav,
Bien cordialement,
-
Bonjour,
La pente n'est pas une donnée "capteur" GPS, c'est un paramètre calculé, le tout est de comprendre à partir de quelle donnée brute (hauteur / Distance) ou (Vz/Vh) a ce stade je n'ai pas la réponse, mes tentatives de reproduire le profil de pente visualisé par Land n'ont pas encore aboutie.
Parmi les observations, coté Land c'est répétitif un même trajet réalisé plusieurs fois produit le même défaut de pente. Par contre un trajet similaire (qui passe par les mêmes chemins) enregistré par un autre GPS ou importé sur un site ne produit pas l'erreur de pente, la pente est correcte. Ce qui laisse supposer que l'erreur n'est pas imputable a Land.. A creuser.
Sur l'image ci dessous, a droite les trajets (Zoom sur le passage de la butte). En bas le profil vertical (Z/T) pour les séparer, partie gauche le profil du GPX importé la pente ne présente pas d'anomalie elle reste dans la fourchette 0/15% a droite le profil GPS TwoNav / Land ou la pente est "folle" !
Cdlt
-
Bonjour,
Voila le lien vers deux traces (GPX) l'une enregistrée par un GPS TwoNav (la bosse est franchie 4 fois), l'autre importée sur internet (via fichier enligne de Land...) est datée de 2012, cette dernière trace passe la "bosse" une fois et emprunte la même ascension.
cdlt
-
Apres synchro des deux fichiers et Zoom sur UNE ascension.
- Gros écart de cadence d'enregistrement,
Mais..
- Sur le GPX venu du net la pentes est "cohérente",
- Sur le GPX "TwoNav" des pics "fous" sur la pente qui viennent rejoindre "hors de leurs phases fofolles" la pente qui semble "normale".
Pour cadrer le sujet, la pente présente un intérêt en cyclisme, VTT, et en RAID pour optimiser un trajet afin de gérer l'effort, et éviter de se mettre dans le rouge inutilement (Dans un Raid cela fait partie de la stratégie de course).
Cdlt
-
Bonjour,
Messieurs,
Vous utilisez trop de mots savants, trop d'abréviations non connues par la plupart des personnes,
Qui sait reproduire vos beaux graphiques Excel ? Qui sait vraiment utiliser les graphiques de Land (réglages et lecture) ?
Qui, même dans votre proche entourage, comprend du premier coup "enregistrement à 1Hz" ? Est-ce que ce réglage apparait sous ce libellé dans les paramètres des nouveaux GPS ?
Ne vous étonnez pas si peu de personnes tentent vos tests.
Cordialement
-
Bonjour,
@twonavlandiste
Que vient faire Excel la-dedans ? Tous les graphiques de cette page proviennent de Land !
Bon, voici un extrait, de Land aussi :
Celui, compte-rendu "propriétés" de la trace affiché par Land, accessible trivialement à tous, si on a juste la curiosité de l'ouvrir.
Moi, j'y lis en particulier des pentes à +/-200%.
Je me dis que c'est curieux, et je cherche juste à comprendre le pourquoi (j'ai travaillé 35 ans au CNRS, on ne se refait pas ... ;-), voilà tout !Il y a des gens, nombreux autour de moi, qui à la fin d'une rando annoncent fièrement avoir fait plus de 1000m de dénivelé alors que c'est très manifestement impossible vu le terrain où nous étions. Nos enregistreurs GNSS sont des appareil dont il faut savoir lire et comprendre les résultats au risque de mal les interpréter. Après, on est curieux ou pas... C'est mal ?
Bon, accessoirement, ça sert aussi à améliorer les matériels et logiciels grâce aux retours fait aux développeurs et constructeurs, pour le bien de tous.
Vous n'êtes pas bien entendu obligé de tenter nos tests, mais de là à critiquer qu'on les fasse en qu'on les partage, je ne comprends pas bien... A savoir la foultitude de personnes qui lisent ces messages, et ne participent pas aux conversations. Certains en tirent profit, pas d'autres, cela gêne qui ?
Cordialement,
PS : "1Hz", cela veut dire un échantillon par seconde, en plus court, je pensais, à tort donc, cette notion acquise depuis le collège...
-
@TC
Sur le GPX "TwoNav" des pics "fous" sur la pente qui viennent rejoindre "hors de leurs phases fofolles" la pente qui semble "normale".
Voici un détail de la trace "GPS TwoNav Trace 2021" :
A échelle macroscopique, effectivement, la trace semble normale, mais elle présente bien un "twist" comme je le montre en introduction de cette discussion : le mauvais calcul de pente vient de là, un bug de l'algorithme dans ce genre de succession de points. Cela ne le fait pas sur la trace en provenance d'Internet, car elle est lissée. En fait, 200% semble être la limite affichée, mais je soupçonne un "overflow" de calcul quelquepart.
Cdlt,
-
Sur mon PC je ne vais pas au delà de 2700% , la fausse "petite boucle" est invisible, ainsi que l'écart de trajectoire !
Ajout..
Incompréhensible, les données GPS semblent correct, la réception satellite bonne, pleine vue du ciel !
Quel algo est utilisé pour calculer la pente?
Si ont passe ces données (Dans Excel ..Désolé pour ceux qui ne lisent pas Excel couramment ou exceptionnellement!) on ne reproduit pas la courbe de pente.
Un "œil" avertit pourra observer que parfois en descente Land indique une pente positive (déjà remonté au SAV) ..
-
Incompréhensible, les données GPS semblent correct, la réception satellite bonne, pleine vue du ciel !
Ce n'est pas comme je le disais un problème de points de trace, mais un problème logiciel pur.
Quel algo est utilisé pour calculer la pente?
Pas le temps à l'instant, je vais préparer une réponse détaillée un peu plus tard.
Avec des maths... forcément...Cdlt,
-
Bonjour,
PS : "1Hz", cela veut dire un échantillon par seconde, en plus court, je pensais, à tort donc, cette notion acquise depuis le collège...
Posez la question à votre entourage....
Voilà typiquement une phrase qui va faire fuir ceux qui voudraient vous aider à chercher: être pris pour des gens "qui n'ont pas inventé l'eau tiède".
Pour Excel, cela allait venir...
EDIT:
Vous n'êtes pas bien entendu obligé de tenter nos tests, mais de là à critiquer qu'on les fasse en qu'on les partage, je ne comprends pas bien...
Je ne critique pas vos tests. Dans un autre post, vous vous étonniez que personne "n'embrayait" vos tests.
Je dis juste que, vu vos niveaux, soit ils sont mal compris, soit les personnes hésitent à se "mesurer" à vous.
Cordialement
-
suite
Concrètement, la dernière génération de GPS est pourvue d'accéléromètres, comment sont utilisés ces capteurs c'est le flou, ils pourraient être employé pour obtenir une pente fiable. Chez TwoNav aucune info comme si c'était inutilisé, chez Garmin c'est un peu (pas beaucoup!) documenté.
Cela dit dans le flux des données qui sortent du GPS, ca se limite à la position, l'altitude, le temps, et le nombre de satellites. Tout le reste est inévitablement recalculé par Land
<trkseg>
<trkpt lat="50.379530" lon="3.475743">
<ele>33.3</ele>
<time>2021-09-30T11:53:00.000Z</time>
<sat>12</sat>
</trkpt>Pour le "fun" la trace de référence avec le bug, exportée sur un site et réimportée dans Land, le sous échantillonnage fait disparaitre le défaut. Idem si la trace d'origine est visualisée par un autre outil. C'est de toute évidence notre ami Land qui dans ses dernières versions est bugé.
De toute évidence il manque un ingénieur qualité chez TwoNav ou celui en poste passe sa vie sur la plage a Barcelone.
Mon petit doigt m'a laissé entendre qu'il y avait du changement, on verra avec le prochain GPS..
CDLT
-
Clic Gauche une évolution post 7.7.2 ?
Au départ vous avez écrit Clic droit.....
Clic gauche oui !
Rouge; pente, Bleu: altitude trace
Je ne sais pas si cela apporte en lisibilité..... je cafouile avec les couleurs.... je ne comprends pas les changements de couleurs lors de clics sur les échelles de gauche.
Rouge; pente, altitude trace: maintenant violette ????
Vert clair: altitude, Kaki: pente
-
Concrètement, la dernière génération de GPS est pourvue d'accéléromètres, comment sont utilisés ces capteurs c'est le flou, ils pourraient être employé pour obtenir une pente fiable.
J'ai montré que le problème est mis en évidence avec une trace enregistrée en NMEA sur un smartphone. La solution ne réside pas dans le prélèvement de données, c'est "juste" un bug logiciel dans le calcul de pente.
La cause, je ne sais pas, mais plutôt qu'une modification d'algorithme post version 7 de Land, je pencherais plutôt pour une instabilité conceptuelle du codage de cet algorithme, qui serait apparue avec les changements de plateforme d'exécution et/ou des bibliothèques (mathématiques, graphiques, ...) systèmes utilisées. Je ne peux pas tester avec une version7.x, sur macOS, il me faut obligatoirement une version 64bits pour que ça tourne (mal, mais c'est une autre histoire).
On a déjà eu l'occasion de constater cela avec d'autres bugs, le drame qui n'est pas spécifique à TwoNav, mais assez répandu désormais parmi tous les éditeurs de logiciels, c'est de ne plus faire de tests de non régression corrects avant de sortir une nouvelle version d'un logiciel donné.
Cdlt,
-
Petite analyse "simpliste" obtenue avec Google Sheets (L'Excel gratuit).
Le principe est d'utiliser, pour calculer la pente, les données brutes issues du GPS, c'est possible pour l'altitude, pour la distance (on pourrait la recalculer a partir de la position) c'est celle calculée par Land, les deux graphes ne font pas ressortir d'anomalie aux endroits ou Land en a créer !
Ce qui laisse supposer que les données issues du GPS sont OK et que le défaut se situe bien au niveau de l'algo..
En bleu la pente calculée par Land
- En rouge calcul de pente simple Dénivelé / Distance filtré sur 10 secondes,
- En jaune le même calcul filtré sur 5 s
A une époque il y avait un réglage dans un paramétrage ou l'on pouvait définir le pas de calcul de la pente, je ne trouve plus cet ajustement.
Le diagramme montre qu'avec un filtrage sur 10 secondes, l'amplitude de la pente reste dans le bon domaine.
Cdlt
-
Le diagramme montre qu'avec un filtrage sur 10 secondes, l'amplitude de la pente reste dans le bon domaine.
C'est ce que suggère au début de ce fil, tout comme pour le problème des anomalies concernant la mesure barométrique d'altitude : je propose, un peu au pif mais pas trop, un filtre passe-bas à 0.1Hz, c'est à dire sur 10 secondes (désolé pour le terme "passe-bas à 0.1Hz", mais c'est comme cela que ça se nomme...).
Cdlt,
-
Bonjour à tous,
Pour répondre à Laurent, j'ai effectivement testé une trace de Thierry: ...2021.gpx
Il y a bien une pente max et une pente min dans les propriétés: max = 14.7% min = -18.2%
Je n'ai rien remarqué d'anormal sur cette trace.Pour le calcul de la pente, le paramètre important dans Land, est "Trace/Distance calcul de pente". (dans mon cas il est réglé à 50m).
En choisissant une autre valeur, on obtient d'autres min max et des graphiques différents.
En choisissant 1m par exemple - ce qui est bien sûr aberrant - j'obtiens max=+82,9% et min=40%@Bernard P. et @Thierry C. Quelle valeur avez-vous pour ce paramètre dans vos traces ?
Cordialement
-
Quelle valeur avez-vous pour ce paramètre dans vos traces ?
5m, la valeur par défaut. Pour un trajet pédestre avec des petites montées et descentes, ce n'est pas anormal.
Mais reste à savoir en fait comment est utilisée cette valeur. Est-ce la fenêtre de moyenne sur la distance horizontale ou bien le dénivelé minimal pour entreprendre un recalcul ?La taille des "twist" sur les traces ci-dessus est en général de moins de 2m, voire moins.
Please sign in to leave a comment.
Comments
60 comments