Projet Tripmaster : cahier des charges

Sinon, concernant la correspondance entre l’odomètre de la Prius par rapport à celui du PCM je poursuis mes mesures :

hier : Prius 6500m PCM 6518m

aujourd'hui : Prius 9100m PCM 9109m

Aujourd'hui la dérive est apparue assez rapidement. Elle est montée à env 7 mètres durant les 3,5 premiers kilomètres parcourus dans Paris. Ensuite c'était le périphe et tronçons plutôt roulants.
 
3e série de mesures.
ODO Prius 7100 m à travers Paris. ODO PCM 7109m
Au bout de 2 km ODO PCM était déjà à +5m (circulation hachée)
Au km 5 à +7m (circulation plus fluide).

4e série de mesures.
ODO Prius 1800m ODO PCM :
@900m +3m
@1200m +5m (plus d'arrêts)
@1700m et 1800m +10m !!! (je m'arrêtais tous les 100m)

Donc, cela peut être lié aux basses vitesses ou alors le décalage se fait à chaque arrêt / ré-démarrage.
Mais des 2 : ODO Prius et ODO PCM, le quel ment ?

Dites les gars : la variable ODO du PCM a de l'inertie ?
Ou bien c'est l'ODO de la Prius qui s'arrête trop tôt ou démarre trop tard ? Feignasse va !!!

J'ai remarqué aussi la chose suivante :
Je ne mets pas l'ODO de la Prius à zéro mais roule doucement et pile dès que je vois qu'il change de centaines de mètres. J'allume PCM. Il doit donc y avoir un petit décalage, d'1 mètre ou 2 (ODB PCM en retard). Puis je démarre. Et 100m plus loin à l'arrêt suivant ils ont déjà été parfaitement synchro !
 
As-tu pu corréler ces mesures avec un système GPS ?
 
Comment calcule-t-on une distance à l'aide d'un programme informatique ?

PCm calcule la distance d'après la vitesse qu'il reçoit avec une résolution de 0,01 km/h.
Cette vitesse vient du pid 0B4.
Il utilise ensuite l'horloge du pc pour calculer la distance parcourue.

Actuellement, (pour éviter de cumuler des erreurs d'arrondi), le rythme de calcul de la distance est donné par un autre pid, le 3CA. Ce dernier est plus lent que le 0B4. Ce 3CA est comme un métronome.

Il est possible de déplacer ce calcul de distance dans le 0B4 et donc d'ajouter plus souvent des distances plus faibles.

On travaille sur des temps très brefs. On suppose donc qu'entre deux réceptions de la vitesse celle-ci est constante. C'est une légère approximation, aussi bien lorsqu'elle augmente que lorsqu'elle diminue. Par optimisme naturel, le développeur a supposé que les micro-erreurs lors d'une accélération sont compensées par celles lors des ralentissements. On s'approche d'un calcul d'intégrale, la masse d'une prius combinée à la puissance disons raisonnable de ses moteurs et freins (décélérations de l'ordre d'1G) ne peuvent générer des variations rapides à cette échelle.

@parkerbol, le gps n'est pas précis, surtout en présence d'obstacles comme les immeubles. Du moins quand on a le niveau d'exigence des rallymen.
 
Je suis prêt à coder toutes les façons de calculer la distance, je laisse à Kinetik et Planétaire le soin de me donner les formules.
Mais si Kinetik a une formule dont il est sur, alors je peux changer la formule dans PCM, et me contenter d'en programmer qu'une.

Par ailleurs, je vais m'entraîner pour le rallye à respecter une vitesse moyenne sur mon parcours de référence, j'en profiterai pour mesurer la reproductibilité de la mesure de la distance par PCM.
 
Petit point du front :
Je deviens hyper super ... sticieux.
Il va me falloir un grrri grrri.
PCM en version 6,17 marchait impeccablement jusqu'ici (je ne touchais surtout à rien sur la machine, elle ne faisait que ça) et là, depuis que je lui ai branché le GPS ou autre manips il lui arrive de partir en Error 6.

Bon, ben qu'à c'la ne tienne, Etienne, j'ai aussitôt démarré la version 6,17b au vol, celle modifiée par Thierryb. Pas d'error en cours d'utilisation. Pour l'instant. Par contre à chaque fois que je termine le programme il sort en "Error d'exécution 9, indice en dehors de la plage". Cela me pose pas plus de problème que cela, surtout que relancé le programme fonctionne.

Il me semble avoir vu que l'odo PCM défile de manière plus fluide et régulière. Celui de la version 6,17 avait tendance à "s'oublier" de temps en temps puis se mettre à jour à grand pas des 7 double mètres.

Ce n'est pas une critique, juste un constat. Le prog fait énormément de calculs, son but premier n'est pas d'afficher l'odomètre. C'est pour quoi on a souhaité une version optimisé pour ça.

Pour ce qui est des dérives ODO Prius / ODO PCM. Je continue de surveiller ça. Il me semble que ce décalage se crée au moment d'arrêt (peut-être démarrage, plus difficile à constater). Et ce serait env 3 m d'un coup.

On a tous constaté que lors de l'arrêt de la voiture, au moment où l'on est déjà immobile, le tachymètre de la Prius indique toujours une vitesse de l'ordre de de 8, 5 ou 3 km/h. Le tachymètre ne passe à 0 km/h qu'environ 1 sec après l'arrêt complet du véhicule.

Il se peut donc que le décalage vienne de là. Tout comme le tachymètre le PCM reçoit l'information de vitesse non nulle alors que la voiture est déjà arrêtée.

Comme dans les ZR on est pas censés nous arrêter il se peut qu'il n'y ait pas de décalage.

Pour en apprendre plus je vais faire le test sur une route de plusieurs km. 1er passage sans arrêt, 2e avec plusieurs arrêts.
.
 
Less Polluter à dit:
....Comme dans les ZR on est pas censés nous arrêter il se peut qu'il n'y ait pas de décalage.
Cliquez pour agrandir...
Normalement !
Mais n'oublie pas les aléas de la course, et si tu te retrouves derrière un autochtone/tracteur sur une ZR, tu devras vraisemblablement t'arrêter.
Pas grave, en ce moment je teste PCM en ville et je suis obligé de m'arrêter à chaque feu rouge.
C'est une bonne simulation pour tester le débogage de notre ami thierryb.

Autre question qui n'a rien a voir.
Est il possible avec un scangauge, de se programmer un odomètre précis ?
(en renseignant bien dans le scangauge, les gauges qui vont bien)
cela me permettrait de voir la différence avec l'odomètre de la Prius, et on pourrait même faire des ZR rien qu'avec cet odométre.
On utilise un programme où on entre la vitesse moyenne à faire, et on a un 'cadenceur' qui bipe tous les 100m.
Moins pratique le que le Tripmaster automatique de PCM, mais c'est le principe même du tripmaster
 
Je peux peut être te faire un bip avec pcm.
 
Je confirme, la version du post 77 est stable pour faire du tripmaster ou non, car les instabilités ne venaient pas de la partie tripmaster.
 
Cool.

Je me disais aussi qu'un petit beep ça existait y a 30 ans déjà, sur les PC XT ... (Ascii 7 si mes souvenirs sont bons) :cool: Mais paramétrable SVP, car supporter ça d'office ...

Sinon j'ai poursuivi mes investigations qui confirment que ces décalages naissent principalement lors des arrêts ou roulage à très faible vitesse.

"Long run" de 2 000m avec arrêt à 1000 m. 1001m puis 2002m sur l'ODO PCM
Run avec des arrêts pratiquement tous les 100m : 101, 202, 303 puis 1907m.
Run au même endroit sans arrêt : 901m

Run E.T. (maison ...) tant que ça roulait, pas trop de décalage. Puis sur la fin j'arrive à 9 514 m (au lieu de 9 600 sur ODO Prius évidemment). 200m plutôt avant que je ne traîne dans le parking il n'y avait que 10 de plus sur ODO PCM.

Allez, pour finir encore 100m à très faible allure dans le parking : 9 623. Eh oui PCM a trouvé 9m supplémentaires en seulement 100m !!!

La raison ? Pour moi clairement l'ODO PCM n'est pas alimenté de la même façon que celui de la Prius.

Quand je roulais très très doucement dans le parking à des vitesses inférieures à 2 km/h le Tachymètre de la Prius ne se fatiguait plus en indiquant un 0 magistral. "Pourtant elle tournait", le véhicule avançait l'ODO et le Tachy PCM avec.

Lequel est juste alors ? En fait ni l'un ni l'autre ! :jap:

Donc il se peut que :
- dans la phase d'arrêt du véhicule l'ODO PCM soit suralimenté par le tachymètre de la Prius qui n'est pas encore à 0 alors que la voiture est arrêtée.
- lorsque le véhicule roule à très faible allure, moins de 2 km/h l'ODO de la Prius n'est plus alimenté car le Tachy est à 0.

Voilà.
 
Palm35 à dit:
Autre question qui n'a rien a voir.
Est il possible avec un scangauge, de se programmer un odomètre précis ?
(en renseignant bien dans le scangauge, les gauges qui vont bien)
cela me permettrait de voir la différence avec l'odomètre de la Prius
Cliquez pour agrandir...

Oui, on peut programmer dans scanmonitor l'affichage d'un l'odomètre qui donne le cm. Mais il reviendra à zéro tous les 655,36 mètres. Peu intéressant je pense.

Il y a aussi un odomètre précis caché dans l'ODB. On accède au menu en gardant Display appuyé tout en allumant 3 fois les phares ou les feux de croisement. Ce menu fait apparaitre un capteur voiture qui donne un comptage d'impulsions. Il y a environ 2.55 impulsions par mètre, probablement 1/5 tour de roue. C'est un compteur modulo 10000, soit un peu moins de 4 km. Bien que presser reset affiche 0, l'impulsion qui suit 9999 ne montre pas 0, mais montre encore 9999. Mais la suivante montre 1.
 
Kinetic, que nous proposes tu pour avoir un odomètre précis dans pcm ?
 
less, je pense que ce que tu veux faire est trop compliqué. Je pense que ce qui est raisonnable est d'avoir un bouton départ que tu cliques au moment du départ, c'est à dire ton bouton RAZ all, et qui enregistre ton temps et ta position zéro. Tu cliques, puis tu parts.

Tu as peu de chance d'avoir la même seconde sur l'ordinateur et sur l'écran de départ. Donc ta façon d'envisager bouton ZR me fait craindre qu'il sera peu utile. Par contre vois tu l'horloge et les départs des voitures devant toi ? dans ce cas, je pourrais te mettre 3 boutons H-3H-2 et H-1 qui te permettrait de calibrer le temps 3, 2 ou 1 minute avant le départ, RAZ All serait alors un H-0.

Et comme il te faut avancer jusqu'à la zone de départ, je comprends l'utilité d'un bouton RaZ de l'odo ; encore que nous pourrions mettre l'odo à zéro à t=0. Mais je préfére ta solution dans ce cas, car tu as effectivement du temps pour remette l'odo à O.

Enfin, je ne vais pas trop l'utilité de modifier ton temps 0 une fois que tu es parti. Comment le connaitre à la seconde ?
 
Cela peut paraître trop compliqué mais je t'assure, c'est l'expérience qui parle.

L'utilisation du bouton "RàZ All" ( = "démarrage immédiat") induira nécessairement un décalage par rapport au top départ officiel du à notre temps de réaction. Certes il sera moindre que dans le cas du démarrage actuel commandé par les roues où il faut :
au top départ enlever le pied du frein,
presser l'accélérateur
et ce n'est qu'ensuite, au bout d'un certain temps, très incertain, en fonction de l'accélération, que le décompte commence.

Donc dès le départ on prend de la dérive dont on ne connait pas la valeur. Ca peut-être 0,5 sec, 1 sec ou 1,5 sec. Avec une seconde en moyenne sur 6 ZR avec 4 mesures dans chacune on se prend 24 sec de pénalité rien qu'à cause de cela. C'est plus que ce que les meilleurs engrangent dans tout le rallye.

Certes, le bouton RàZ All permet d'être bien plus précis que le démarrage actuel. Si on s'est loupé on peut même partir avec 5 sec de retard il suffira par la suite d'en tenir compte. Mais c'est pas commode.

Pour quoi j'estime le démarrage commandé par l'horloge du système intéressant ?

L'horloge officielle du rallye est réglée sur l'horloge officielle France Telecom et Monaco Telecom. On peut donc la connaitre à l'avance et régler nos ordinateurs en fonction (et vérifier en cours du rallye car à chaque point de départ il y en a une). Certes il y a 2 sources d'inexactitude :
- je conçois qu'il soit très difficile de régler l'horloge de l'ordinateur au millionième de seconde près mais la demi seconde est du domaine du réel (et on verra bien qu'il y a le décalage et l'ordre de grandeur)
- les horloges système des ordinateurs ne sont pas si précises que ça, il y a forcement de la dérive naturelle mais, j'espère, imperceptible sur 2 jours.

Pour s'assurer de l'exactitude du reglage de l'horloge système on a une solution "on board" (pas la peine d'appeler sans cesse FT) : en passant par le menu caché de la Prius on peut visualiser l'horloge des satellites servant au système GPS. Et là je crois que c'est hyper précis. Si je ne m'abuse ce sont des horloges atomiques ou calées sur elles. C'est la base même de leur fonctionnement. Maintenant, il a y peut-être un gap de temps entre la réception du signal et l'affichage de l'heure dans le menu caché du système GPS ?

Le décalage me parait donc inévitable mais s'il est stable et on en connait la valeur à 0.5 sec près ce sera déjà très très bien.

Pour quoi vouloir pouvoir modifier l'heure de départ en cours de route ?
Eh bien il peut nous arriver que nos doigts fourchent ou qu'on ait pas eu le temps de le faire correctement, où qu'on se soit simplement trompés. J'ai déjà fait un faux départ qui nous a fait partir avec un décalage inconnu. On l'a estimé au pif mais ce fut un peu galère. Le doigt, ou la souris qui fourche ça arrive dans un environnement qui bouge. Il se peut aussi qu'une fois dans les "starting blocks" on s’aperçoive que les horloges du système et des organisateurs soient décalées. On pourrait corriger. On peut aussi juste en tenir compte.

Je ne sais pas si j'ai bien compris ton idée des boutons : démarrage à H-3', H-2' et H-1'.
Si H-1' signifie H - 60 secondes à partir du moment où l'on appuie sur le bouton cela ne servira à rien. A 60 secondes du départ on rentre seulement dans la zone de démarrage donc on ne voit pas bien l'horloge des organisateurs. Encore moins à H-2 etc .
Si H-1' signifie démarrage dès que l'horloge du système affiche la minute suivante, oui. Ca rejoint mon idée. Ajouter H-2 et H-3 n'a pas trop d'intérêt dans la mesure ou l'on a presque 1 minute pour appuyer sur H-1. Normalement on aura le temps.

Je ne sais pas si j'étais clair.

Si le réglage du départ par la saisie de l'heure dans une zone modifiable même en cours de la spéciale parait difficile tant pis. "RàZ" All et " H-1' " rendront déjà d'excellents services.

Après tout vaut peut-être mieux consacrer plus de temps à s'assurer que la mesure de la distance soit la plus précise possible et encore plus, donner la priorité à l'affichage des informations TripMaster pour que les évolutions des écarts soient plus fluides.

kinetic : merci pour le tuyau. je vais faire mumuse avec dès que possible.
 
ok, je vais respecter tes specs
 
Waw, quelle force de persuasion !
Plus sérieusement, j'espère que je me suis juste fait mieux comprendre.

Ceci dit, si la mise en place de l'heure modifiable doit être galère ce n'est pas nécessaire.

Je viens de faire une petite simu, pour l'instant à la main, qui démontre l'importance de mettre toutes la puissance de la machine sur le calcul de la moyenne et écarts.

Demain je vais le faire avec les données récupérées des logs des spéciales.
 
Message personnel

@Thierryb. Au cas où tu ne l'aurais pas déjà vu, les variables DureeTrajet et DistanceTot sont partagées dans Pcm à la fois pour les calculs/affichages de distance durée normaux mais aussi pour les calculs de la partie Trip.
Donc si tu dois démarrer le trip après (si présence d'1 bouton Raz_Trip), il faut utiliser d'autres variables spécifiques au Trip.

La DureeTrajet est calculée dès qu'on commence à rouler et donc pas au lancement de Pcm. De même cette durée est interrompue dès qu'on arrête de rouler. Si ce n'est qu'un simple arrêt en cours de trajet (stop par ex) la durée totale va inclure cet arrêt. Si on est arrivé à destination la durée de l'arrêt final n'est ainsi pas comptée. Sauf si on a la mauvaise idée de bouger un peu la Prius à l'arrivée, il considèrera alors que ce n'était qu'un arrêt en cours de trajet.

On voit très bien ce fonctionnement lors d'un arrêt en cours de trajet. Au début de l'arrêt on a une vitesse moyenne, conso moyenne etc qui ne bougeront pas pendant l'arrêt.
Dès qu'on bouge un peu cette valeur va "sauter" en tenant compte de la duréee totale roulage+arrêt.
Ce mécanisme est dû au fait que Pcm ne peut pas savoir, quand on s'arrête, si c'est l'arrivée ou un simple arrêt en cours de route.

Ceci prouve que les différents développeurs (au moins 3 et maintenant 4. Thierryb penses à ajouter ton pseudo dans le titre) qui ont oeuvré à la réalisation de ce produit free ( si j'ai bien tout compris) ont des limites qui se situent entre le présent et les futur.

Je limite donc mon message ici

A+ tard ;-)
 
Merci planétaire, effectivement j'avais vu. Le plus surprenant dans ton programme, c'est l'unité de ta distance, qui vaut 3600 unités pour 1 mètre.

Less, ce qui m'a convaincu, c'est d'une part que tu ne vois pas l'horloge officielle avant que tu sois dans la zone de départ, et d'autre part mes essais avec l'horloge parlante. Si ton pc est synchronisé avec internet, alors l'écart est très faible, je pense plus ou moins 2 secondes. Je vais peut-être ajouté 2 boutons +0,5 -0,5 qui vont permettre d'ajuster l'heure dans tripmaster par pas de demi-seconde avec l'heure du pc.

Ce qui m'inquiète beaucoup, c'est que les meilleurs arrivent à avoir moins d'une seconde de décalage à chaque pointage, et donc tout le long du trajet, c'est impressionnant, presque surréaliste. C'est pour cela que je propose ces 2 boutons, même si je serai très surpris de réussir à tenir la précision. Mais je vais m'entrainer pour voir ce que cela donne.

A quel moment nous donnent-ils la moyenne à réaliser sur la ZR ?
Il existe des zones d'étalonnage, quel était l'écart que tu as pu mesurer avec PCM à chaque fois ?
As-tu calculé toi-même à la main la moyenne que tu devais faire finalement pour prendre en compte l'étalonnage ?
 
thierryb à dit:
Kinetic, que nous proposes tu pour avoir un odomètre précis dans pcm ?
Cliquez pour agrandir...

J'ai apporté des informations nouvelles sur la nature des informations qui circulent sur le bus CAN, et en particulier que l'ECU responsable de la mesure des vitesses des roues, et qui ne mesure bien sûr que la rotation des roues, est amené à changer son paramètre circonférence des roues au cours du trajet.

J'ai aussi incité à intégrer les données d'un odomètre déjà présent sur le bus, ce qui déchargerait le programme de nombreux calculs.

J'ai proposé une technique pour mesurer le déplacement lorsque le véhicule va très lentement.

Je n'ai pas les codes source de PCM. Bien que pas enthousiasmé à l'idée de coder du Visual Basic sous Windows, je veux bien mettre y mettre le nez.
 
thierryb à dit:
......
A quel moment nous donnent-ils la moyenne à réaliser sur la ZR ?
....
As-tu calculé toi-même à la main la moyenne que tu devais faire finalement pour prendre en compte l'étalonnage ?
Cliquez pour agrandir...
Pas bien, Thierry, pas bien ....
Tu es pris en flagrant délit de non connaissance du règlement...:oops:
Article 20.1 :
La liste des vitesses moyennes pour les secteurs de tests de régularité sera remise lors des vérifications administratives...

Sinon, oui, on se calcule nous même nos vitesses moyennes après l'étalonnage.
On fat donc une règle de 3 par rapport à la vitesse moyenne de l'organisateur.

Imprègne toi bien du règlement, car même si on l'a lu plusieurs fois, on ne le connait toujours pas assez....
 
Dernière édition:
Va pas faire peur aux nouveaux palmito ! Chacun son truc. Lui il regarde pour l’outil toi t’es officiellement préposé maitriser le règlement. Après tout on est une équipe ou pas ? :cool:

Oui, la règle de 3. J'ajuste la moyenne en fonction de la différence entre la distance officielle de la zone d'étalonnage et ce que je relève avec TripMaster.

Pour ce qui est des gars qui font des sans fautes. Ben nous on pourrait le faire aussi si on travaillait à l’ancienne. Ca se trouve ils n’ont pas d’outils aussi perfectionnés que nous. Ce qui joue en leur faveur s'est l'expérience. Les ZR correspondent aux spéciales WRC et surtout du Rallye Monte Carlo Historique qui se déroule selon le même principe, la régularité. Donc s'ils les connaissent, les ont mesurées il suffit plutôt de savoir qu'à tel ou tel endroit la distance est de tant et par conséquence, vu la moyenne imposée on doit s'y présenter à tel moment. Le copilote pointe, chrono en main, le tableau des distances et temps de passage à tel ou tel endroit.

Je me méfie des "horloges parlantes" sur internet. Je les ai regardées de près et elles ont du décalage. Minimum 1 seconde facilement 3 voire 5. D'ailleurs c'est facile à constater. En mettant différents sites qui les affichent elles ne sont pas synchrones entre elles. Je me fierai donc volontiers à l'horloge du système GPS, facile à comparer avec l'horloge de l'organisateur. Dès lors on peut voir, à 0,5 sec (ton copilote fait le top de l'horloge de l'organisateur pendant que tu regardes celle du GPS, puis tu règles l'ordi - on verra l'horloge bien avant le départ des ZR, par exemple au départ de l'étape de concentration, à Annecy ou Clermont)
 
exact Less, pour l'instant je me concentre sur notre logiciel, et c'est bien si l'on m'aide à connaitre le règlement. Nous sommes une équipe.

Pour info, ça avance pas mal. J'espère avoir quelque chose dans la journée. Le bouton ZR marche. J'ai un décompte en seconde et en metre. Puis un retard, car dans mon lit, le compteur n'avance pas. Je peux changer la vitesse attendue, et même si elle est vide ou nulle, il n'y a pas d'erreur.

Encore quelques babioles, et cela devrait être opérationnel- Quelques faciles, la remise à zéro de l'odo et la remise à zéro totale. Et une qui est plus difficile et va m'amuser : modifier à la main la date de départ.

PS: maintenant c'est mis à jour tous les 1/10 de secondes ; désolé, c'est trop compliqué pour le ralentir.
 
kinetik à dit:
J'ai apporté des informations nouvelles sur la nature des informations qui circulent sur le bus CAN, et en particulier que l'ECU responsable de la mesure des vitesses des roues, et qui ne mesure bien sûr que la rotation des roues, est amené à changer son paramètre circonférence des roues au cours du trajet.

J'ai aussi incité à intégrer les données d'un odomètre déjà présent sur le bus, ce qui déchargerait le programme de nombreux calculs.

J'ai proposé une technique pour mesurer le déplacement lorsque le véhicule va très lentement.

Je n'ai pas les codes source de PCM. Bien que pas enthousiasmé à l'idée de coder du Visual Basic sous Windows, je veux bien mettre y mettre le nez.
Cliquez pour agrandir...

Kinetik, exact, tout est déjà écrit et je ne te demande pas de coder. Je veux juste que tu résumes en mettant les différentes façons de la plus efficace à la moins efficace.
 
thierryb à dit:
Kinetik, exact, tout est déjà écrit et je ne te demande pas de coder. Je veux juste que tu résumes en mettant les différentes façons de la plus efficace à la moins efficace.
Cliquez pour agrandir...

Pour résumer
- codez le PID 230. Ça vous enlèvera bien des soucis, et ça ne peut pas être moins bien que les PID 0B1, 0B3, 0B4.
- si se pose le problème des vitesses lentes, utilisez en même temps le PID 244 qui donne la somme des deux vitesses de rotation des roues avant.
 
Identifiez-vous ou inscrivez-vous pour participer.
Pages vues depuis le 20 Oct 2005: 313,236,720
Retour
Haut Bas