Destiné avant tout à fournir le positionnement, le GPS permet aussi d'obtenir des indications sur la vitesse.
Il faut savoir qu'il existe deux techniques pour obtenir la vitesse par GPS :Nous nous plaçons donc clairement dans le point 2 du paragraphe précédent, ce qui a les conséquences suivantes :
L'objectif de GPSAR étant de délivrer une restition de l'action aussi fidèle que possible, nous trouverions dommage de nous limiter à des vitesses moyennes par tronçons. S'en tenir à ces vitesses moyennes aurait pour première conséquence une restitution "en escalier" dans le graphe des vitesses, pour le moins inhestétique, et pour seconde conséquence de ne pas proposer la vitesse instantanée la plus probable à un instant donné. Pour s'en convaincre, prenons un exemple simple. Le relevé GPX nous donne :
Question : quelle était la vitesse instantanée à t=9 secondes ?
Réponse : nul ne sait ! Mathématiquement, elle peut être de 100000 m/s sans aucun problème, le tout étant que l'intégrale de la vitesse sur ce segment corresponde à la VMoy. Pragmatiquement, si l'on considère des mouvements fluides (accélération faibles), on serait tenté de répondre "une valeur entre 0.5 et 5 mètres par secondes". En termes de probabilités, on serait tenté de donner, à vue de nez, quelque chose comme 3 ou 4 m/s comme meilleure réponse.
Tout dépend en fait de la fluidité de la vitesse d'une part, et de la façon dont le récepteur choisit les moments où il enregistre la position (ceci est à son entière discrétion). Si l'on maîtrise à peu près le premier paramètre (nous supposons que les relevés utilisés par GPSAR rendent compte d'activités sportives à accélarations modérées), il faut étudier comment se comporte le récepteur GPS vis-à-vis de ces enregistrements. Comme pour nous il restera à tout jamais une boîte noire, voici le banc d'essai que je propose :
J'ai mené l'expérience en roulant 2 minutes à vitesses variées (accélérations, virages). Voici le résultat sous forme graphique :
Les graphiques parlent d'eux même : Vinst1, en jaune, est la meilleure interpolation (parmi celles proposées). Elle est basée sur l'heuristique suivante : la vitesse moyenne sur un segment et la vitesse instantanée au milieu de ce segment sont égales.
Les valeurs de vitesse instantanée affichées par GPSAR à coté du mobile correspondent au calcul Vinst1, celle qui est le plus satisfaisante en moyenne, tandis que le graphe se contente de Vinst2 (cf. illustration ci-dessous, où l'on constate deux valeurs affichées différentes). Pourquoi ? Tout simplement parce qu'en l'état actuel de l'implantation en Java, les graphes (altimètre et tachymètre) héritent d'une même classe qui affiche une valeur correspondant à chaque trackpoint, et relie deux valeurs consécutives par un segment (interpolation). Or, si à un trackpoint donné correspond bien une altitude enregistrée par le GPS, il est faux de croire qu'il lui correspond aussi une vitesse moyenne ! N'oublions pas que la vitesse moyenne est calculée par nos soins d'après différence de position entre DEUX TRACKPOINTS : elle donc attachée ni à l'un, ni à l'autre (du reste, Vinst1 suppose que ce vitesse moyenne est la vitesse du point placé temporellement entre ces deux trackpoints...). Cela étant, une version ultérieure de GPSAR devra enrichir la classe de Graphes afin d'autoriser ce type d'interpolation.
En fait, il y a pire encore dans GPSAR ! La restitution dynamique, quant à elle, s'appuie sur la vitesse moyenne sur segment, pour des raisons évidentes de simplicité, c'est-à-dire que le mobile se déplace à allure constante sur chacun des tronçons. Là encore, une version ultérieure devra permettre une restitution dynamique conforme à la Vinst affichée (intégrer dx=v.dt).
Note : cette expérimentation mériterait d'être faite dans les règles de l'art, notamment avec une acquisition des vitesses en continu (et non au magnétophone !), et d'autre types d'interpolations pourraient être envisagés (tenant compte des spécificités d'enregistrements GPS constatées). Si vous avez l'occasion de faire plancher un étudiant dessus lors d'un projet (mesures physiques ?), le résultat m'interesserait.
Il est important de bien distinguer les deux types de calcul de vitesse via GPS.
Il faut savoir qu'en cas de perte de capture d'un nombre suffisant de satellites par le récepteur GPS, l'une et l'autre de ces vitesses peuvent être gravement erronées. Tout utilisateur de GPS s'interessant à la performance sportive (notamment les véliplanchistes et leur VMax ou leur VMoy sur 500m) doit donc s'assurer que le récepteur reste bien loggé sur les satellites (bien placer le récepteur, de sorte qu'il ait le champ de vision satellitaire le plus vaste possible), doit réinitialiser l'enregistrement VMax le plus souvent possible (après chaque run, après lecture), et ne jamais tenir compte, en aucun cas, d'une valeur Vmax si elle est lue après une mise sous l'eau de l'appareil (après une chute). Par ailleurs, il est conseillé de faire des recoupements entre Vmax lues en direct et resitution dynamique ultérieure via GPSAR ou autre logiciel. Généralement, la Vmax est d'environ 1 ou 1,5 noeuds au-dessus de la VMoy du segment correspondant (l'écart étant d'autant plus important que la durée du segment est grande). Enfin, le bon sens et l'habitude permettent de limiter les erreurs : si, dans des conditions données, on fait un "run" à plus d'un ou deux noeuds de tous ses autres runs, c'est très suspect ! Si, au contraire, on fait plusieurs runs dans le même noeud, il y a peu de chance que le gps se trompe toujours de façon quasi-identique...
Il semblerait (vu la DTD de GPX) que certains récepteurs enregistrent le nombre de satellites "vus" par le gps à chaque trackpoint. C'est là un moyen intéressant de "valider" une performance. Malheureusement, ce n'est pas le cas des récepteurs bas de gamme actuels, en tout cas de l'Etrex.
Certains récepteurs disposent d'un altimètre (basé sur la mesure de pression via un baromètre), donnant lieu à une restitution précise de l'altitude (sous réserve d'étalonage préalable, je suppose). Le développement de GPSAR étant fait, actuellement, autour de récepteurs bas de gamme (Etrex en l'occurrence), j'aborderai ici le calcul de l'altitude fait par le gps via les satellites : il faut savoir qu'à partir de 4 satellites perçus, le gps peut déduire, en plus de la latitude et de la longitude (qui en nécessitent 3), l'altitude. Cependant, la précision de cette dernière est assez faible, et très variable. Pour le constater, il suffit d'observer le relevé gps lors d'une navigation en mer : une fois stabilisé (car la première minutes donne lieu à des écarts supérieurs à 50 m), on constate généralement des variations d'altitude d'environ 10 mètres.
GPSAR fournit un calcul des denivelés positifs et négatifs. Cependant, compte tenu du manque de précision de la donnée altitude fournie par le gps, un petit aménagement logiciel est opéré pour tenter de limiter les erreurs. En effet, un calcul inconditionnel amènerait, même pour une évolution à altitude constante, à des cumuls croissants (plusieurs centaines de mètres de dénivelé sur eau plate !). Voici donc le procédé actuellement retenu :
Le présupposé à ce calcul est le suivant : Si le récepteur reste à altitude constante, on peut supposer que la valeur non nulle sur un segment sera a priori compensée par une valeur opposée sur l'un ou l'autre de ses segments voisins.
On perd donc les variations faibles mais réelles, et par ailleurs on n'évacue pas les erreurs lorsque celles-ci sont importantes. Néanmoins, l'amélioration constatée est sensible. Un test en montagne lors d'une randonnée d'environ 4000 mètres de dénivelé positif et négatif (parcours en boucle) donne lieu à une erreur de "seulement" 300 mètres, donc inférieure à 8%.