Flymaster

#1

Juste une petite question/remarque : j’ai remarqué un truc bizarre quand je passe ma trace provenant de mon Flymaster B1 Nav. De temps en temps il me sort des varios furieux (+175m/s et peu de temps après du -192m/s par exemple) et du coup ça foire ma trace qui, lorsqu’on sélectionne le vario est forcément intégralement en rose. J’ai l’impression qu’il interprète un point comme une brusque baisse d’altitude puis un autre comme un retour subit à l’altitude “normale”.

Sur la trace ça donne un trou dans la sol puis un retour en vol… Ci joint une trace récente qui illustre bien mon propos (avec deux ou trois cassures nette en début de vol)

Est-ce que c’est un bug de la moulinette ? Je viens de regarder, il semble que la référence “altitude” soit l’alti GPS (qui est celle qui présente le bug) alors que l’altimètre “barométrique” lui semble fiable…

#2

J’ai aussi le même problème avec le B1Nav.
C’est pas vraiment un bug de la moulinette : elle prend l’alti GPS car tous les gps ne fournissent pas de trace avec alti baro.
Il n’y a pas de correction de ce qu’on lui donne en entrée, donc si c’est n’importe quoi, c’est mort.
Idéalement, il faudrait lisser (l’altitude, mais aussi les positions gps d’ailleurs) ; à l’époque, j’avais essayé, mais j’avais pas trouvé d’algo super fiable…

Encore un truc à améliorer sur la moulinette ! (qui commence un peu à dater…)

#3

Sinon, sans faire de lissage, il n’y aurait pas moyen de prendre l’altitude baro si elle existe, la GPS sinon, voire que ce soit configurable sur l’IHM?

Je suis sur le point de m’acheter un B1 nav, mais si l’export google marche moins bien que sur mon vieux garmin, ça serait dommage…

#4

Bonjour à tous,

Je viens de jeter un coup d’oeil à la trace de Frigorofix, le Flymaster enregistre bien l’altitude barométrique et l’altitude GPS.

En fait il faut avoir le choix au moment de la génération du KML entre altiude GPS et altitude barométrique.

Man’s a eu la gentillesse de me passer ses sources (:coucou: Mans). Losrque j’ai pris le code j’ai pris soin d’introduire les deux altitudes. Pour l’instant je n’ai “récupéré” que le code de calcul CFD, mais j’envisage un de ces jours de traiter la partie génération KML.

Bien souvent il n’y a qu’un point où cela a déconné, il suffit de l’éliminer. Perso j’utilise un Flytec, et bien plus gênant, il pose parfois un point avec une position aberrante. Genre tu voles à Planfait et sur le dessin de la trace y’a un gros trait qui passe par Brest !!! J’ai adopté une méthode plus “bourrine” que Man’s : quand la vitesse sol est supérieure à 110 km/h j’élimine le point. On pourrait éventuellement calculer le delta entre altitude GPS barométrique au fur et à mesure du décodage de la trace. Si on s’écarte trop de ce delta moyen, on ne tient pas compte du point.

Actuellement j’ai un système où je “marque” les points aberrants. A la fin du décodage, je renvoie le nombre de points aberrants et je demande à l’utilisateur s’il veut ou non les afficher.

Dire il n’y qu’à tenir compte que de l’altitude barométrique n’est pas non plus satisfaisant car si on a oublié de caler l’alti baro au décollage, on va se retrouver avec une trace qui “rentre” dans le sol de temps en temps…

#5

ce genre de chose est prise en compte par certain softs (je sais, je boucle).
En l’occurence, avec ogr, tu peux charger une trace GPX (en bonus, ça gère les différentes projections si besoin). Ensuite, la simplification des géométries (ici une ligne) est prise en compte de base (par ex: http://gispython.org/shapely/docs/1.2/manual.html méthode ‘simplify’, en bonus il y un lien vers une publication qui présente un algo possible). Facilement adaptable à la moulinette utilisée sur leonardo (dont le code est dispo: https://github.com/twpayne/igc2kmz ).

Sinon, j’ai vu que la CFD avait maintenant une moulinette pour déterminer quelle “forme” déclarer pour la CFD (sans doute basé sur du code de Tom Payne et xcplanner).

#6

:coucou: Marc… On est dans les échanges de liens aujourd’hui !!! Quand tu parles d’ogr tu fais allusion à http://www.gdal.org/ogr/ ? Tu utilises cette librairie pour ta moulinette à espace aériens ?

As tu un lien pour le calcul CFD sur le site de la fédé, je ne l’ai pas vu … Pour info, j’avais jeté un coup d’oeil au source de Tom ( juste un coup d’oeil car je ne connais pas grand chose à python ). Pour le calcul CFD, il se servait d’un code en C qui sert également de base à Leonardo si je ne me trompe. Le problème de ce code est qu’il n’avait que les circuits OLC. Dixit mes quelques copains grands chasseurs de km CFD, le calcul de Man’s était souvent plus pertinent de quelques points.

Mes excuses pour ce petit HS :mrgreen:

#7

:coucou: :coucou:
Oui, je parle bien de GDAL/OGR, et c’est ce que j’utilise pour la moulinette d’espace aérien. J’ai mis du temps à comprendre, mais une fois que tu comprends, ça ouvre des portes et tu gagnes du temps (simplification, tri, union, intersections, projections, etc). Le soucis, c’est que je manque de temps… Mais les possibilités sont énormes, il faut juste du temps et de la motivation, mais ce domaine bouillonne d’outils en tout genre pour faire tout et n’importe quoi, c’est dur de se focaliser quand on est curieux…

Pour la CFD, je n’ai pas de lien vers du code, j’ai découvert ça en déclarant la semaine dernière. Maintenant, on balance la trace GPS, une instance de xcplanner affiche la trace et le formulaire de déclaration propose la “forme” qui va bien. Peut être qu’il s’agissait du hasard dans mon cas et que le “triangle plat” était le premier de la liste (j’avais pas pensé à ça en fait). Pour l’instant, igc2kmz ne fait aucun calcul pour déterminer quelle forme rapporte plus de point. Le bout de C présent dans le code n’est pas important, j’ai d’ailleurs oublié son intérêt… Mais Tom m’avait dit qu’il n’était pas pertinent (ça tombe bien, je ne le distribue pas dans les packages ubuntu que je fais de son outil).

#8

Merci pour la réponse rapide… Pour gdal, effectivement j’avais trouvé la doc un peu dure sous la dent :mrgreen: je vais réessayer.

Pour le site de la CFD, ce n’était pas précisément pour le code mais juste pour comparer leur évaluation avec l’algo de Man’s. Je me doutais que cela devait se passer au moment de la déclaration

#9

Salut tout le monde,

pour marc comme pour moi, c’est un manque de temps, mais pour différentes raisons (gamins…), et le temps libre que j’ai, j’essaye de le passer surtout à voler…
sinon, c’est clair qu’il y aurait plein d’améliorations à faire sur la moulinette (qui était un temps proposée sur la CFD, mais ce qu’ils ont fait maintenant me va très bien, je trouve ça super, mais je ne sais pas quel algo ils utilisent). J’espérais que celle de Tom qui est bien mieux allait prendre la relève, mais bien qu’elle soit sur Leonardo (ainsi que la moulinette v1), elle n’est pas aussi accessible que la mienne qui est en libre accès sur Parawing. Mine de rien, elle date de 4 ans maintenant…

#10

C’est vrai que faire un simple formulaire où tu balances un trace et qui te répond avec le kmz fait par la moulinette de Tom est sur ma liste depuis… longtemps :frowning:

#11

Bonjour,

Desole pour le flood mais qq’un pourait il me donner les dimensions hors tout du Flymaster B1 Nav, Longueur/largeur/epaisseur. Pas moyen de trouver ces infos pourtant basique.
Merci, j’arrete de :floodstop:

Bonne fin de journee

#12

fabrizio, pose plutot ta question sur le fil du B1 Nav, ici, ce n’est pas tout à fait le sujet

Pour y revenir (au sujet), j’ai l’impression que Gipsy, un plugin de Firefox qui permet de récupérer sa trace depuis son GPS effectue une précorrection pour éviter les désagréments mentionnés par frigo.
En tout cas, il permet de couper les parties inutiles avant et après le vol automatiquement, et ça, c’est top ! :slight_smile:

Il permet aussi de déclarer direct au xcontest (j’ai vu qu’il y avait un rapprochement avec la fédé, il manquerait plus que ça déclare automatiquement les vols à la cfd et ce serait parfait ! :wink: )

EDIT : Bon, je viens de tester avec ta trace Frigo, fausse alerte (mais c’est pas mal quand même, je pense que je vais utiliser ça plutot que gpsdump pour récupérer mes traces maintenant).

#13

145x90x22

#14

Bonjour à tous,

Merci pour le lien… super intéressant ce module. Par contre il y qq chose qui m’épate dans le fait d’enlever des points sur une trace. Je n’ai pas trop le temps d’expérimenter Gipsy et peut être n’ai je pas bien compris le fonctionnement.

En théorie une trace IGC est validée par un code de sécurité au moment de l’enregistrement. Je ne sais pas comment travaille le Flymaster, mais j’imagine que cela doit être sensiblement identique au Flytec. Lorsque le vol est terminé, le Flytec calcule et incorpore ce code qui garantit la véracité de la trace (record de type G).

Si on enlève des points, le code généré à l’enregistrement de la trace n’est plus bon. Il existe apparement des logiciels qui recalculent le record G pour s’assurer de la non modification de la trace.

Bon, cela dit dans des challenges amicaux comme la CFD, ou le XContest peut être que la trace n’a pas besoin d’être “validée”…

#15

Le soft qui récupère la trace doit être validé par la FAI, cf http://wxc.fai.org/module.php?id=10&date=20110323
Ce qui est curieux, c’est qu’il n’y a pas Gipsy, et je viens de faire une déclaration sur le xcolc, et ça a marché.
Après, il y a une différence entre le xcolc et le wxolc, c’est peut-etre pour ça, mais c’est bizarre, car le wxolc agrège les résultats de différents olc, dont la cfd…

EDIT : j’avais mal vu sur le lien que je donne, Gipsy y est bien, code xpg

#16

Le “code” de sécurité tel qu’il est utilisé ici, c’est complètement pipeau… C’est rajouté par le soft de décharge (gpsdump) ou le gps lui même. Après, le fournisseur (flymaster, gpsdump, etc) doit donner un outils qui “vérifie” que ce champs est correct.

C’est complètement bancal, et niveau sécurité, c’est 0. Ca fait juste chier les gens qui veulent déclarer autrement qu’avec les outils prévus.

#17

Il faudrait nous en dire plus.

Le fait que des logiciels d’extraction de traces comme GPSdump puissent ajouter ce code rend son usage possible avec de vieux GPS, donc non rédhibitoire pour participer à l’OLC, WXC ou autres.
Si c’est codé directement par un GPS, il y a une garantie sur la trace fournie.
J’imagine que ce code est généré avec une clé FAI et une clé “constructeur” équivalent au protocole clés privé et public.

#18

Dans le principe, je comprend l’idée. En pratique, ça ne vaut rien niveau sécurité. Ca ralenti les personnes qui souhaiteraient tricher, mais rien de plus.

Le fait que GPSdump puisse signer une trace par exemple, ça ne vaut rien, car je peux injecter n’importe quelle trace à GPSdump, qui me la signera sans broncher (il utilise une connexion série, y’a rien de plus simple pour bidouiller).

Ensuite, si GPSdump signe une trace, il y a de forte chance que la clé de chiffrement et l’algo soient fournis avec le logiciel :mrgreen: Donc un peu de temps pour regarder comment ça se passe dedans et on peut extraire ces infos, qui permettront de signer n’importe quoi.

Enfin, dernier niveau, la vérification par la FAI. En fait, la FAI ne se soucis pas du “comment” chaque fournisseur signe. Chaque fournisseur fournit à la FAI un programme qui à partir d’une trace va répondre “oui” ou “non”: aucun prérequis sur le comment. Si un fournisseur (gpsdump ou autre) implante son truc avec les pieds, ça va rendre la tâche simple aux tricheurs.

Tom Payne (encore lui!) en a déjà parlé sur pgf et il a fait un proto qui est basé sur la crypto à clé publique (http://www.paraglidingforum.com/viewtopic.php?p=195555 https://github.com/twpayne/g-record ). Mais comme il le dit, il y a un moment où il faut donner la clé de chiffrement avec le programme qui va signer les traces: niveau sécurité, c’est 0. Quelqu’un d’un poil motivé trouvera très rapidement le moyen d’abuser la chose.

Pour faire un parallèle, c’est la même chose que souhaitent les majors du cinéma/musique: assurer que si quelqu’un achète un DVD/Blueray/CD, il ne pourra pas le copier. Pour ça, il faut construire un chemin complètement sécurisé depuis le matériel jusqu’au logiciel. A partir du moment où tu (utilisateurs) peut regarder ce qu’il se passe, c’est perdu (pour eux). L’histoire récente a plein d’exemple d’échec (DeCSS, Blueray, DRM, …). Et vu comment ça dépote sur les sites de téléchargement de films et musiques, je crois qu’ils ont pas encore trouvé de solution qui fonctionne :clown:

A part en imposant une config matérielle et logicielle, ça va être difficile de garder cette méthode (genre le GPS de la marque X, connecté à un ordi avec Windows 7 via un port machin chose, en utilisant le logiciel truc, le tout sur une machine qui possède la matériel nécessaire (rare: http://en.wikipedia.org/wiki/Trusted_Platform_Module )).

J’avais même penser proposer ça en stage pour des étudiants, car très bon exercice (rétro-ingénierie de logiciel, extraction d’info “cachée”, etc). Pas eu le temps pour l’instant, mais cet été peut être.

#19

:pouce: Marc , tu as formulé de manière magistrale ce que je pensais… Pour GPSDump, il n’y a même pas besoin de passer par une bidouille série, il lit une trace IGC qui figure sur le disque. Rien n’empêche de bidouiller la trace qui est un simple fichier texte, de la lire ensuite dans GPSDump et de valider.

#20

Merci Marc,

C’est clair que le choix de la FAI est très amateur.
Naïvement, je pensais qu’ils utilisaient des couples de clés privés /publics attribués à chaque fournisseur, ce qui impliquerait d’avoir une complicité chez le fabricant de son GPS pour fausser sa trace.

Et la protection via des softs externes comme GPSdump ou gipsy n’a que pour but de pouvoir utiliser les traces sur les OLC,…