Projet Tripmaster : cahier des charges

Oui, je suis d'accord avec Thierry, Artur, faut un truc simple.
Tes idées pourront être implantées dans la version 2014, à condition qu'on y travaille et qu'on le teste dès que le 2013 est fini. Et non 1 mois ou 15j avant le rallye 2014 où dans la précipitation et sans vrai débugage, on peut se planter.
Au fait, je vais installer PCM sur un 2eme PC de secours au cas où!
Où je retrouve la procédure ouù installer les dll et autres ? je ne me souviens plus.
 
Pour celui de 2014 si on s'y prends aussi tôt que maintenant ça pourrait le faire ... vu qu'ils envisagent de le déplacer à l'automne ... :cool:
 
Les rallyes de régularité à l’italienne. C’est ce qu’on a conclu après épluchage des road books des épreuves comme Sestrières.

Y a pas de ZR à proprement parler. Tout le secteur est une ZR dont la moyenne générale est d’habitude de 35 km/h. Il est divisé en tronçons dont les moyennes ne sont pas forcement égales à la générale.

Ils fournissent un road book façon rllye d’orientation ou ils marquent le point de passage (marqué Way Point dans mon tableau ci-après) la distance du tronçon la distance totale et le temps idéal de passage (la fin du tronçon est matérialisée par le pictogramme du changement de direction ou d’un point de passage : carrefour prendre à droite, pont continuer tout droit etc., fille de joie ne pas s’arrêter … ). Parfois ils donnent pas le temps de passage idéal mais la moyenne à tenir dans le tronçon. Bref, l’éun découle de l’autre donc à mon avis il faut vite (il se peut que le RB soit secret et donné au dernier moment) rentrer toues ces données dans un tableur pour recalculer.

Voilà à quoi pourrait ressembler le tableau.

Tps pass age Moyenne Moyenne
Way Point Odo partiel Odo total hh mm ss = secs Tronçon Générale
1 1 670 1 670 0 : 3 : 9 189 31,8 31,8
2 230 1 900 0 : 3 : 51 231 19,7 29,6
3 550 2 450 0 : 5 : 1 301 28,3 29,3
4 3 290 5 740 0 : 12 : 7 727 27,8 28,4
5 440 6 180 0 : 13 : 1 781 29,3 28,5
6 90 6 270 0 : 13 : 15 795 23,1 28,4
7 150 6 420 0 : 13 : 35 815 27,0 28,4
8 3 580 10 000 0 : 20 : 0 1200 33,5 30,0


Après, pour naviguer au mieux y a 2 choses qui nous intéressent.

1) la moyenne à tenir jusqu’au Way Point suivant. Donc notre outil à qui on aura donné un fichier contenant les points de passage avec leur distances et temps idéaux pour s’y présenter doit dès le passage d’un Way Point indiquer l’écart en secondes par rapport à la moynne idéale pour se présenter au Way Point suivant. Et ainsi de suite.

2) les écarts par rapport aux distances officiels (et la c’est la cagade je ne sais pas encore comment les ajuster, j’y cogite)

En prenant l’exemple de mon tableau :
Premier tronçon, pas de problème la moyenne à tenir est de 31,8 km/h.
La moyenne dans le 2e tronçon est de 19,7 km/h ce qui fait que la moyenne générale au passage de ce 2e Way Point doit être de 29,6 pour qu’on s’y présente pile. L’outils doit donc dès le passage d’un Way Point que le (co-)pilote aura indiqué par un TOP (ou autrement) recalculer la moyenne à tenir. Après y a le blème des écarts de distance. Si ils disent 1 670m et nous on a fait 1 690 il faut apporter une correction pour le tronçon suivant. Un autre problème c’est la fiabilité des distances données car si c’est comme celle que donne l’ACM pour les liaisons …

Voilà, je creuse, mais comme c’est pas pour tout de suite, on peu mettre de coté voire, demande aux modos, mettre dans un fil à part : Trip Master à l’italienne.
 
Ouais, on fait au plus simple. Ce qu'il y a déjà me va.

Si je pouvais avoir la distance GPS (au lieu de PID 230, que je n'utiliserai pas, dans la 4e colonne) ce serait la cérise sur le gateau (pas besoin de calculer l'écart entre le PID de la colonne 2 et celui de la 4e).

Disons que cela permettrait de confronter immédiatement ce que j'ai relevé en recos et la réalité du terrain (utile pour l'édition suivante où ça se trouve les recos ne seraient plus nécessaires si on s'appercevait qu'eux aussi au lieu de se faire ch... plaisir à tout parcourir avant ont délocalisé cette tâche, puis que c'est la mode, dans l'espace).

Fichier log peut ne contenir que les données au moement du TOP : temps écoulé, distance PID colonne 2 (donc PCM) écart par rapport à la moyenne officielle (+ distance et la coordonné GPS si y a), Vitesse instant.
 
Si je pouvais avoir la distance GPS (au lieu de PID 230, que je n'utiliserai pas, dans la 4e colonne) ce serait la cérise sur le gateau (pas besoin de calculer l'écart entre le PID de la colonne 2 et celui de la 4e).

Disons que cela permettrait de confronter immédiatement ce que j'ai relevé en recos et la réalité du terrain (utile pour l'édition suivante où ça se trouve les recos ne seraient plus nécessaires si on s'appercevait qu'eux aussi au lieu de se faire ch... plaisir à tout parcourir avant ont délocalisé cette tâche, puis que c'est la mode, dans l'espace).

Peux-tu expliquer plus ?
 
Au fait, je vais installer PCM sur un 2eme PC de secours au cas où!
Où je retrouve la procédure ouù installer les dll et autres ? je ne me souviens plus.

Normalement, il n'y a rien à installer.
Sauf si tu es en seven 64 bits. Il doit y avoir une thread dans cette partie du forum.
Et si tu est en Windows 8, je n'ai pas encore réussi.
Si tu as un problème, fait moi une copie d'écran, en me donnant le contexte.
 
Fichier log peut ne contenir que les données au moement du TOP : temps écoulé, distance PID colonne 2 (donc PCM) écart par rapport à la moyenne officielle (+ distance et la coordonné GPS si y a), Vitesse instant.

J'attaque les logs à la fin.
 
Exemple en chiffres:
Secteur 8 départ à 10h00, distance 500km, temps imparti 5h00
J'aurai à l'écran :

Heure de départ : 10:00:00
Temps imparti : 05:00:00
Distance : 500,00 km
Vitesse moyenne 50.00 km/h
Heure pointage : 15:00:00
Temps restant : 04:17:22
Calcul Avance ou Retard 00:01:35 ou 00:02:01 (vert en avance et rouge en retard ou "+" pour avance et "-" pour un retard)
Moyenne à effectuer suite au retard : elle sera alors supérieure à 50.00Km/h pour mon exemple



Les données en bleu sont calculés automatiquement

Finalement, c'est utile d'implémenter cette fonction, car palm35 serait arrivé avec 5h de retard. Il aurait du rouler à 100km/h et pas 50. 8)8)8):-D:-D:-D

Je ne trouvais pas le bug dans mon programme
 
Peux-tu expliquer plus ?
La distance GPS :

En fait je me suis dit qu'en branchat une antenne GPS et collectant ce qu'elle envoi comme coordonnées y'aurait moyen de calculer la distance qu'on a parcourue.

Sauf que, et là je viens de me rendre compte de la bêtise de ma demande. C'est plus compliqué que cela, donc certainement pour une autre fois.
Si on calcule la distance au fur et à mesure de l'avancement du véhicule ça ne nous sert pas à grand chose car elle sera grosso m...odo la même qui est donnée par les Pid PCM ou 230.

En fait l'emploi du GPS serait intéressant que si on avait introduit au préalable en paramètre un fichier contenant les relévés GPS du tracé. Fait lors des recos ou choppé chez un fournisseur de carto : Google IGN etc.

A partir de la il faudrait déployer les trésors de triangulation pour faire coincider notre position avec un point du tracé à partir duquel on pourrait calculer la distance parcourue depuis le debut. Pas la notre mais celle des cartos.
 
Bien, tu commences à comprendre. C'est pour cela que je voulais que tu réflechisses.
En fait, nous pourrions faire quelques relevés de points sur le parcours, avec leurs coordonnées, et leur distance "officielle". Nous pourrions ensuite à chaque passage devant un tel point recalibrer notre distance calculée par PCM ou 230.
Ainsi, à ces points nous serions sur de notre avance ou retard, entre deux de tels points, cela serait basé sur les roues, mais que depuis le dernier point.
Les points pourraient avoir des noms (repères), et le copilote choisirait en le prochain point de passage. Si pour une raison ou une autre, le prochain point prévu ne déclenche pas le calibrage (mauvaise reception GPS), le copilote pourrait le toper lui-même, ou s'ils l'a raté aussi, alors sélectionner le point de repère suivant.
 
L'ecran est pret.
Less a perdu 2 lignes de TOP.
Il ne reste plus qu'à coder.
Cela ne devrait pas être long, car les calculs sont simples.

Plus long que prévu, les calculs de date avec vb, c'est à apprivoiser.
Maintenant, cela devrait être bon.
Donc c'est pour après le repas (pris un peu tard).
A bientot
 
Bien, tu commences à comprendre. C'est pour cela que je voulais que tu réflechisses.
En fait c'était déjà réfléchit et c’est pour ça que je l’ai pas mis dans les specs pensant en parler après avoir peaufiné. L’idée a toujours été celle là. Sauf que là je me suis un peu emballé en essayant imaginer un truc le plus flexible possible pour la suite.
 
Bien. Dans ce cas, nous sommes en phase.
Si j'ai le temps, je te le ferai pour la 2013.
Et je te préparerai des fichiers GPS en utilisant Google Maps

Bien, voici la version 621d

lien supprimé, car il existe une version plus stable plus bas

Elle implémente la demande de palm35.
J'ai enlevé 2 lignes de top. Pauvre less.
Il faut que je l'essaie sur route.
J'essaierai aussi l'acquisition GPS pour voir si je ne l'ai pas cassée.

Ensuite, j'attaque l'ecriture du fichier de log allegé.
Etes-vous d'accord pour que je n'enregistre que les données au moment des "top" (cela inclus les autres boutons RAZ, ZR, Odo) , ou voulez vous que je maintienne les logs actuels en ajoutant une colonne "bouton" qui est le nom du bouton appuyé au moment de l'écriture de l'ancienne ligne ?
En fait tout dépend de comment cela se passe avec cette nouvelle version. Si vous la trouvez fluide, je peux me contenter d'ajouter une colonne "bouton". Si vous ne la trouvez pas assez fluide, il faut que je l'allège, et le plus sur est le fichier de log. Deux façons possible pour le fichier de log : n'ecrire que toutes les secondes, ou toutes les dizaines de secondes. L'autre façon, ecrire lors d'un appui sur bouton.
 
Dernière édition:
Entèrement d'accord avec toi.

Quant aux logs il est évident que si ça doit ralentir le traitement principal (pire, lui faire louper des infos qui se traduiraient par des inexactitudes induisant des dérives aléatoires) c'est à éviter.

J'aurais tenndence à dire que ce qui serait le mieux c'est de laisser à chachun le choix de l'importance des logs à travers un paramètre.

1 on logue tout (avec le témoin du bouton appyé)
2 on logue toutes les n secondes (avec le témoin du bouton appyé)
n = 1 me parait le plus logique dans l'optique d'exploitation ultérieure des résultats
3 on ne logue que lorsqu'un des boutons sont appyés (ZR / RAZ /TOP et Palm :D )

Je vais tester àa illico.

Le fichier .INI est stocké sous quel nom et où ?
 
Essai à vide (ELM pas branché) et petits problèmes (j'sui sur que c'est à cause de palm ... :D )


Lancement du prog
apui sur RAZ
(y a 10 qui est apparue dans la zone après la virgule du correcteur +/- , je crains ne pas saisir pour quoi et ce que ça fait)

appui sur "Moy" à gauche du libéllé 'Ecart' ou "Odo" => plantage
Ereur d'exécution '340'
L'élement du groupe des controles '7' n'existe pas
Programme 'dégage'

Relancement
appui sur ZR (rien dans la zone +/-)
quand je bidouille les zones siasissables en vert fluo (en l'occurance distance)
Erreur d'exécution '6'
Dépassement capacité
(j'ai juste effacé le 5 de 500.00 ce qui a donné 00.00)
 
Non, y avait pas ça avant .... :(
 
Moi, j'ai appuyé sur la touche R (en fait quand on appuie sur une touche parce que j'ai eu aussi le même truc en appuyant sur T ou O)
runtime error 13
type mismatch
Cela ferme le fichier quand on dit OK à l'erreur.
Du coup faut retaper toutes les donnes du secteur :heure Dep, Tps et Dist.
Cela pourrait pas rester dans l'ini ?
(et en vert fluo, j'ai du mal à les voir. Alors si en plus y a du soleil...)
 
Eh, t'as pas l'impression que ça marche moins bien depuis tes modifs ... :grin:
 
Je le fais en stand alone, j'ai pas branché mon ELM327 ou CANUSB (je sais plus lequel j'ai !)
 
Je vais le brancher mais je ne crois pas que cela change quoi que ce soit.
 
HeHe, vous êtes tombés sur des bugs que j'ai aussi trouvé pendant l'essai.
Voici la même version avec pas mal corrections.
C'est la même que la 621d avec des bugs en moins : la 621e

lien supprimé, car il existe une version plus stable plus bas


J'ai aussi foncé l'affichage en vert, car effectivement, c'était illisible.

Normalement, vous ne devriez pas avoir celles que vous avez trouvé.
Je n'ai pas testé encore avec le GPS branché. Ce sera pour demain.
 
Dernière édition:
Essai à vide (ELM pas branché) et petits problèmes (j'sui sur que c'est à cause de palm ... :D )


Lancement du prog
apui sur RAZ
(y a 10 qui est apparue dans la zone après la virgule du correcteur +/- , je crains ne pas saisir pour quoi et ce que ça fait)
Le 10 n'est pas prévu. Je vais corriger cela. La 621e peut aussi faire un 10. Normalement, c'est un entier entre 0 et 9. Le décalage en dixième de seconde entre la seconde de l'horloge parlante et la seconde du PC
appui sur "Moy" à gauche du libéllé 'Ecart' ou "Odo" => plantage
Ereur d'exécution '340'
L'élement du groupe des controles '7' n'existe pas
Programme 'dégage'
Corrigé dans la 621e
C'est du à la suppression des deux derniers tops
Relancement
appui sur ZR (rien dans la zone +/-)
quand je bidouille les zones siasissables en vert fluo (en l'occurance distance)
Erreur d'exécution '6'
Dépassement capacité
(j'ai juste effacé le 5 de 500.00 ce qui a donné 00.00)
Et là c'est du à une division par 0 quand la distance à faire est nulle.
C'est aussi corrigé dans la 621e
 
Moi, j'ai appuyé sur la touche R (en fait quand on appuie sur une touche parce que j'ai eu aussi le même truc en appuyant sur T ou O)
runtime error 13
type mismatch
Je n'ai pas testé les touches, mais uniquement cliquer sur les boutons.
Je vais vérifier les touches.
Cela ferme le fichier quand on dit OK à l'erreur.
Du coup faut retaper toutes les donnes du secteur :heure Dep, Tps et Dist.
Cela pourrait pas rester dans l'ini ?
(et en vert fluo, j'ai du mal à les voir. Alors si en plus y a du soleil...)
Le ini ne stocke à la fin, que si le logiciel ne plante pas.
Par ailleurs, je n'ai pas prévu de stocker ces données.
Je vais déjà essayer de le rendre plus robuste.
Ensuite, si vous insistez, je stockerai les infos dans le .ini, et j'irai les chercher au démarrage du programme.
Mais si le programme ne plante pas, cela devrait être inutile.

Le vert a été corrigé dans la 621e
 
Vous voyez, il est nécessaire que vous vérifiez en condition, avec vos odblink, et vos gps, et vos PCs, sur vos voitures, avec différentes valeurs.
 
J'ai corrigé le bug du 10 pour les dixièmes de secondes.

Les seules touches possibles sont :
- T : qui affiche ou non l'ecran tripmaster
je pourrais la désactiver car elle ne sert plus à rien puisque l'autre ecran est vide
- Z : pour ZR
- P : pour panic, donc RAZ
- M : pour le top
je pourrais en ajouter une pour la touche Odo si vous voulez.

Je rappelle que si vous voulez utiliser ces touches, il ne faut pas avoir le curseur dans une zone de saisie.

Si maintenant tu a eu un problème avec le R, c'est que surement tu as du écrire un R dans une zone que je n'ai pas contrôlé. Je vais essayer de controler leur resistance à l'entrer de caractère.
 
Pages vues depuis le 20 Oct 2005: 313,231,291
Retour
Haut Bas