Projet Tripmaster : cahier des charges

[priusfan]

@Thierryb
Dans chaque position du tableau can() il y a un octet stocké sur 2 caractères. .....
Si tu as plus de 2 hexa dans un can() c'est que les espaces intercalaires sont bouffés !

d'où la reflexion qui n'a rien à voir avec ta question (réflexion autour du débit d'une liaison bt):
On pourrait donc occuper deux fois moins de place, voire même trois fois car il peut y avoir un espace entre les séquences en hexa.... !

a) pour la paire d'octets hexa:
autant la convertir systématiquement, qu' elle soit utilisée ou non, lors de la réception de chaque trame.
càd mise en tableau d' entier systématique.
une valeur inacceptable invalidant la trame.

b) suppression des espaces:
dans le meilleur des cas, tu gagnes un peu moins d'un tiers 1/3 (prends une trame brute et compte les espaces que tu vires)
elle est souhaitable pour des raisons d'optimisation de débit.
elle ne facilite pas l'analyse de trame (truisme).
elle est utilisée par torque.
elle est utilisée dans les projet de guinness en java et le mien sous android.
avec les ELM327 ou assimilés, elle s'obtient avec le paramètre ats0 dans la chaine d'initialisation; cela ne marche pas avec les clones chinois.
je n'ai pas calculé l'incidence sur le débit, mais j'ai constaté une très sensible augmentation du nb de requêtes / sec en l'utilisant.

ps: normalement, à cette heure, je roupille, mais-là, j'étais descendu car j'avais soif....

 

[planétaire]

La plupart des paquets du bus CAN sont remarquablement bien synchronisés. Si je prends le PID 244 par exemple, j'ai une période moyenne de 24.57445 ms en été, avec un retard n'excédant pas 25 ms. Ce retard inclus le délai du bus USB et de mon programme Python/Ubuntu...

Si j'ai bien compris tu mesures le délai entre deux passages d'un pid et regarde son évolution au cours d'un trajet.
La mesure du temps de chaque passage que tu utilises est elle faite d'après l'horloge du PC ou bien est-ce que c'est le dongle qui te donne cette valeur ?

 

[thierryb]

planétaire, il semble que le premier Can, Can(0) peut avoir 3 caractères. Confirmes-tu ? Les suivants étant toujours de 2.

 

[thierryb]

a) pour la paire d'octets hexa:
autant la convertir systématiquement, qu' elle soit utilisée ou non, lors de la réception de chaque trame.
càd mise en tableau d' entier systématique.
une valeur inacceptable invalidant la trame.

C'est ce que j 'ai fait, j'ai rendu non valide les trames mal formées. On peut surement faire mieux, car surement certaines sont réformables, mais j'estime que cela devrait avoir peu d'impact.

 

[planétaire]

Petites réflexions pour avoir une liaison BT en passif

...
b) suppression des espaces:
dans le meilleur des cas, tu gagnes un peu moins d'un tiers 1/3 (prends une trame brute et compte les espaces que tu vires)...

Oui, mais ma réflexion allait jusqu'à insérer un intermédiaire entre le dongle et le BT. Chaque octet de donnée est actuellement émis par le dongle (elm, stn ou canusb) sous forme hexa et occupe donc en fait 2 octets, plus éventuellement l'espace intercalaire. Tout cela pour un seul octet...
Si un pic ou autre est interposé entre le dongle et l'émetteur BT on peut réduire d'un facteur presque 3 le volume d'infos dans la liaison BT. C'est plus compliqué, mais si cela permet d'utiliser un BT sans perte de trames tout en étant en passif.

A cela le pic pourrait aussi filtrer tout ce qui prend de la place et ne sert pas (par exemple le pid 020 inutile). Voire ne transmettre que les octets de données utiles (donc moins de 8 parfois et pas le crc). Et là dessus ne transmettre que les pid qui ont changé de valeur (sauf pour la conso d'essence).

Dans une capture venant d'un elm327 avec les espaces une seconde occupe 43800 caractères. Sans les espaces 31000. En n'utilisant pas les héxa on arrive à environ 15500. En ne transmettant pas les inutiles ...
Bref avec 115200 b/s ou a un truc dans les 11500 octets/s et ça peut passer.

Mais il y a du boulot.

 

[planétaire]

planétaire, il semble que le premier Can, Can(0) peut avoir 3 caractères. Confirmes-tu ? Les suivants étant toujours de 2.

Oui, le can(0) c'est le code du pid qui est sur 12 bits (000 à FFF en héxa).
Il est très vite stocké dans une variable "id"

Pour info dans pcm 6xx il y a le décodage d'un elm avec espaces intercalaires et celui d'un canusb qui n'a pas d'espaces intercalaires (mais un octet, le 4ème, que n'émet pas l'elm, en plus pour donner la longueur de la réponse)

 

[thierryb]

Oui, le can(0) c'est le code du pid qui est sur 12 bits (000 à FFF en héxa).
Il est très vite stocké dans une variable "id"

Merci.
Il n'était pas toujours stocké. Quand il était malformé, donc plus long, il créait lui aussi une erreur.

 

[planétaire]

Je me demande si je n'ai pas dit une bétise. Ce ne serait pas 12 bits mais 11. Cela se stocke pareil sur 3 quartets mais 000 à 7FF.

 

[Less Polluter]

Waw, les mecs !
J'ai eu Steven et Georges au bout du fil (de rêve). A cour d'Oscars ils me demandaient des idées pour la suite de leurs blockbusters.
Je leur ai suggéré :
The Riders of the Lost PID
PID attacks
PID Wars
PIDception
PIDority repport
à moins qu'il ne préfèrent
The PIDist ... men who try to make'em speak ...

Vous me laissez sans voix ...

Ce matin j'étalonnais dans le parking l'odomètre pour voir les dérives en fonction de la façon dont on prend un virage (large, coupé etc.).
Error 6 n'a pas tardé.
En fait il est hyper important de figer une config stable dans les paramètres.
Eviter la recherche auto (je pense qu'il vaut mieux brancher l'ELM/ou autre toujours au même port USB).
Eviter le GPS car s'il est déclaré présent et n'y est pas ... patatras.

 

[planétaire]

...Eviter la recherche auto (je pense qu'il vaut mieux brancher l'ELM/ou autre toujours au même port USB). ...

D'après mes essais, on branche sur le port usb qu'on veut. Windaub attribue un N° de port com en fonction du contenu de la "rom" du dongle, comme une signature.
Donc un N° de port com par périphérique.
Sauf si on reconfigure ce périph, mais pas dans le cas des dongle odb, je pense.

J'ai "joué" avec des convertisseurs usb-ttl et quand je les reconfigurais et réécrivais donc un paramètre dans ce périph, son N° de port com changeait. Windob y va joyeusement de 1 en 1 et ne réutilise pas les trous.
Mais peu importe sur quel port usb on se connecte.

 

[kinetik]

Si j'ai bien compris tu mesures le délai entre deux passages d'un pid et regarde son évolution au cours d'un trajet.
La mesure du temps de chaque passage que tu utilises est elle faite d'après l'horloge du PC ou bien est-ce que c'est le dongle qui te donne cette valeur ?

Je trace la différence entre l'instant d'arrivée de la trame N (pendule du PC) et la quantité N*T, avec T fixe.

 

[planétaire]

J'ai pas bien saisi les N et N*T. Mais par contre tu te sert de l'horloge du Pc, donc de l'heure d'arrivée de l'info dans ton programme. A moins que tu utilises tactrix qui a probablement le même temps de transfert de l'info depuis le dongle vers le programme, sinon il y a des buffers entre le dongle et les variables de ton programme. Donc des délais qui dépendent des stratégies et de l'occupation du système d'exploitation.
Sais-tu chiffrer la valeur et la variabilité de ce délai ?

 

[thierryb]

planétaire, pourrais-tu déplacer votre conversation avec Kinétik dans un autre thread.

Bon, le nouvel exe plante imméditemment, je vais le corriger.
je n'avais pas prévu d'avoir une trame vide.

Par ailleurs, malgré la certitude que plus aucun mot ne dépasse 255, néanmoins j'obtiens des erreurs au moment de la combinaison de 2 mots, quand le premier mot dépasse 127. Je vais aussi corriger cela en faisant sauter la trame, car la donnée est incohérente.

 

[Less Polluter]

Bon, comme je ne sers à rien dans la traque du PID d’or je vais parler un peu IHM et fonctionnalités du TripMaster+

Mais d’abord ma vision des évos. Vous me dites si je dis des bêtises.

1) stabilisation du PCM (c’est en cours)

2) ajout de petites fonctionnalités (toutes petites)

3) enlèvement des traitements qui ne nous servent pas sur la Zone de Régularité et qui pourraient s’avérer gourmands en ressources


Je commence par le point 3)

Je crois avoir remarqué que la gourmandise du programme fait passer notre verrue préférée en 50 roue du carrosse. Ce qui n’est déjà pas si mal, sans ça on avait une précision de 50 m grâce à l’odo journalier de la Prius.

La chose qui pose problème c’est l’affichage quelque peu saccadé. Quand en 1 seconde de temps on voit s’afficher une avance de 31 mètres suivi d’une de 21 puis de 41 pour une moyenne de 48km/h (en gros dans un laps d’une seconde on a perdu presqu’une 1 seconde pour en gagner aussitôt presque 2 …) ça fait que je commence à ne plus faire confiance à mon copilote ... Me demande ce qu’il raconte … Et lui qui m’engueule parceque je ne sui fais pas confiance (Enfin, depuis l’année dernière si. Il a dit tout droit j’ai fait tout droit. Puis marche arrière …)

Mais je pense que globalement, c’est juste, rien ne se perd, ce n’est ‘que’ du délai dans le traitement car la distance parcourue affichée par l’odo journalier et celui du PCM semblent correspondre au mètre près. Je revérifierai.


Point 2)

Préambule : si la prose qui suit n’est pas digeste passez au post suivant avec l’exemple d’écran et variables.

La partie Trip Master apparait/disparait grâce à l’appui sur la lettre T.
Le calcul est fait (même si sa fenêtre n’est pas affichée à l’écran) sur la base de la distance parcourue depuis le premier mètre parcouru après la mise à zéro du compteur kilométrique du PCM (par arrêt puis relance du PCM)

Premier problème : ça nous oblige d’être extrêmement réactifs au départ de la ZR pour que le calcul soit lancé le plus vite après le top de départ. En analysant les logs, j’ai pu constater des retards variables, allant de 0,5 sec à 1,5 sec (0,2 sec pour passer le pied du frein sur l’accélérateur, selon les enregs du PCM). Malheureusement, je ne suis pas certain que ce soit la vérité vrai car l’ordre d’écriture des logs n’est pas garanti 100% synchrone. Quand on voit que le levier de vitesses est encore signalé en ‘R’ alors qu’on s’est déjà arrêté (V = 0 km/h) et passée en marche avant (V > 0 croissante) …

Et je ne vous dis pas les sueurs froides quand on attend l’apparition magique du PCM après son arrêt. Apparaîtra t il avant le départ de la spéciale ou pas ? Error ou pas ? Figé ou bougeant ?

Donc je me suis dit que ce serait bien :
d’avoir un compteur kilométrique dédié au Trip Master qu’on puisse remettre à zéro à notre guise (dérivé de celui du PCM) sans avoir besoin de sortir du programme pour cela.
paramétrer le démarrage à une heure précise.

Le départ se passe de la façon suivante. On arrive sur la zone avant le départ. Y a 3 ou 4 concurrents devant nous donc on sait à quelle heure précisément on partira. On paramètre donc l’heure du départ ( hh:mm:ss )
Une fois arrivé dans les starting blocs (dans la Zone de départ où l’on reste env 45 sec avant d’être lâchés) la voiture ne bouge plus et on remet à zéro le compteur kilométrique du TripMaster.
Ensuite qu’on parte comme Loeb ou molo, voire avec du retard, ça n’aura plus d’importance puisque TripMaster calculera sur la base de la distance parcourue à partir d’un moment précis et non du moment où la voiture a bougé d’au moins 1 mètre (où autre distance, je ne sais pas exactement).

Ce qui est bien dans PCM TripMaster, si si, y a plein de bonne choses, toutes celles dont on ne parle pas et qui ont le mérite d’exister, c’est qu’on peut modifier la vitesse moyenne en cours de son fonctionnement et il recalcule tout comme si de rien n’était.
Quel intérêt ? Normalement aucun sauf que parfois on a besoin d’apporter une correction et on est trop contents de pouvoir le faire en vol.

Donc j’aimerais bien qu’on puisse faire pareil avec l’heure du départ. De fois qu’on se soit trompés et nous en soient aperçus après le départ.

L’action du bouton R à Z de l’ODO Trip Master : ben ça continue de calculer à partir de l’heure de départ en cours en prenant les nouvelles valeurs de l’ODO.
2e effet kiss cool de cette fonction :
on arrive sur la zone avec l’heure de départ réglée
TripMaster affiche l’écart par rapport à cette heure et la valeur de l’ODO
On met l’ODO à ZERO
Trip Master affiche notre avance, puisqu’on n’est pas encore censés être partis, qui vaut le compte à rebours du départ (cool pour voir si notre horloge est synchro avec celle servant à nous faire partir)


Dernière fonctionnalité, un BOUTON ROUGE de RàZ GLOBAL qui met l’ODO à ZERO et l’heure à l’heure du moment où on a appuyé dessus. En gros un bouton de départ instantané. Ca peut servir.


Je vous fais tout à l’heure un petit Print Screen du nouvel Ecran et l’algo qui va avec.

 

[Less Polluter]

Données externes dont aura besoin le module Trip Master

Valeur de l’ODOMETRE du PCM (appelé ci après ODO_PCM)
L’heure système

Données internes du module Trip Master

ODO_TM (odomètre courant propre à Trip Master) = ODO_PCM – ODO_TM_1
ODO_TM_1 = valeur de ODO_PCM à l’instant de la mise à zéro du ODO_TM par bouton jaune (= ODO_PCM au début du pgm)

Heure_Depart_TM
= heure système au lancement du programme (affichée dans la fenêtre de saisie corrigible à tout moment)
= heure système si appui sur bouton RàZ Général (bouton rouge) (affichée dans la fenêtre de saisie corrigible à tout moment)
= saisie (corrigible à tout moment) dans la fenêtre

MOY_TM (moyenne TripMaster à tenir) – saisie (init à 48,00 km/h) - donnée actuellement présente

AVANCE_M (avance en mètres) calculée - donnée actuellement présente
AVANCE_T (avance en temps) calculée - donnée actuellement présente
RETARD_M (retard en mètres) calculée - donnée actuellement présente
RETARD_T ‘retard en secondes) calculée - donnée actuellement présente
_____________________________________________________________

Il me vient une idée.
Ce serrait bien un bouton (vert ?) Départ ZR Imminent
Quand on doit partir par exemple à 10h38 (toujours à l’heure :minute pile, donc 00 sec) on n’entre dans la zone de départ qu’au plus tôt 59 secondes avant (sinon pénalité !!!)
Donc une fois qu’on y est on appuie sur la bouton vert :
L’heure se met à la minute suivante pile
L’ODO_TM se met à ZERO

Le calcul étant tout le temps opérationnel il apparait dans la fenêtre une avance (secondes et mètres) diminuant au fur et à mesure qu’on s’approche de l’heure de départ. Un compte à rebours !!!


Je vous laisse gérer les DIV by 0, hein

 

[Less Polluter]

Ah oui, pendant que j’y suis. Mais c’est évo + 1.

Ce qu serait intéressant c’est de pouvoir choisir la/les roue(s) de mesure de distance.
Je suis convaincu que seule roue arrière droit c’est ce qu’il y a de mieux pour éviter les trop grosses dérives dues au coupage des virages doux à gauche et l’élargissement par extérieur dans les épingles à droite. M’enfin, c’est mon avis.

Si on pouvait paramétrer :
ARD
ARG
Moyenne des 2 AR
Moyenne des 4

 

[Less Polluter]

Les logs

Si ça bouffe trop de ressources tant pis mais pour une analyse ultérieure je garderais bien :

--- minimum tripmastérial ----
heure système
time stamp
distance
vitesse instantanée

--- si possible -----
coordonnée GPS (si ça fout pas tout par terre)

---- éventuellement aussi -----
% accélérateur
% frein
Position levier vitesses

--- lux extra plus --------
% SOC
Temp thermique
Temp Batterie
Conso

 

[kinetik]

J'ai pas bien saisi les N et N*T. Mais par contre tu te sert de l'horloge du Pc, donc de l'heure d'arrivée de l'info dans ton programme. A moins que tu utilises tactrix qui a probablement le même temps de transfert de l'info depuis le dongle vers le programme, sinon il y a des buffers entre le dongle et les variables de ton programme. Donc des délais qui dépendent des stratégies et de l'occupation du système d'exploitation.
Sais-tu chiffrer la valeur et la variabilité de ce délai ?

Je poursuis ici, on y est pas si mal, et ça concerne tout à fait le problème de tripmaster il me semble. Mais je te suis ailleurs si tu veux.

Dans l'exemple

je lis les paquets de l'obdlink et leur attribue au moyen de l'horloge du PC l'instant d'arrivée "t". Je leur attribue aussi un numéro d'arrivée "n". Au final, j'ai deux tableaux de même taille "N", nommés "t" et "n". Je définis un intervalle moyen, qui vaut disons "dt = (t[N-1] - t[0])/(N-1)" et je trace "t - n*dt" fonction de "t". Il n'y a aucun point en dehors de l'épure.

J'observe alors que les paquets arrivent de manière parfaitement cadencée, avec un retard maximal global de 25 ms. Ce retard comprend les délais du système d'exploitation de l'ordinateur.

 

[kinetik]

Ah oui, pendant que j’y suis. Mais c’est évo + 1.

Ce qu serait intéressant c’est de pouvoir choisir la/les roue(s) de mesure de distance.
Je suis convaincu que seule roue arrière droit c’est ce qu’il y a de mieux pour éviter les trop grosses dérives dues au coupage des virages doux à gauche et l’élargissement par extérieur dans les épingles à droite. M’enfin, c’est mon avis.

Si on pouvait paramétrer :
ARD
ARG
Moyenne des 2 AR
Moyenne des 4

Attention le bus CAN ne transmet pas la vitesse des roues en tours, mais le produit des tours par une circonférence QUI VARIE au cours du trajet. En outre, rien n'est transmis lorsque la vitesse est très faible. Dans ce cas, il faut prendre en compte MG2. Si ton rallye n'est jamais une course de lenteur extrème, ce n'est pas grave. Si tu fais de la marche arrière, l'odomètre continue d'ajouter au lieu de retrancher. Est-ce grave ?

Pour les roues arrières, on a le cm de résolution 40 fois par seconde en lisant le PID 230. Mais on peut le lire moins souvent sans perdre d'information.

Voici le code :

1- On lit une première fois les deux premiers octets du PID 230 comme entier 16 bits non signé, qu'on converti en entier signé 32 bits ou en flottant.
2- On initialise l'odomètre.
et on boucle :
3- On lit les deux premiers octets du PID 230 qu'on convertit
4- On calcule la différence entre les deux mesures du PID 230, que j'appelle incrément.
5- Si l'incrément est négatif, on ajoute 65536.0
6- On ajoute l'incrément à l'odomètre.
7- On boucle en 3.

L'odomètre est grossièrement en cm.

 

[Less Polluter]

Ouais, ce serait cool d'avoir une mesure archi fine et fiable.

Je me pose des questions. L'année dernière en allant au Rallye j'ai étalonné l'odomètre (compteur journalier) de la Prius sur env 200km (relevés tous les 10 km, voire plus souvent, et j'ai vu qu'il y avait aussi des bornes mal placées, pas exactement à 1 km). Résultat, la Prius tirait 2 m plus court au km que la distance selon les bornes autoroutières.

Mais je n'ai pas étalonnée l'odomètre PCM. Donc suite à la réflexion plus haut je l'ai fait ce soir. Et là ... sur 6500 m pile à l’odomètre de la Prius, PCM m'en a compté 6518 ... (dérive constante validée sur plusieurs points de passage, relevée au moment ou l'ODO de la Prius basculait - je m'arrangeais que ce soit à faible vitesse ou l'arrêt).

Que l'odo PCM ne soit pas exactement identique à celui de la Prius ne me pose pas de problème particulier. Mais est-il exact ? La dérive (ici 0.28%) est-elle constante sur de très longues distances ?
Ne loupe-t-on pas quelque chose ?

 

[thierryb]

Voici une version qui devrait être plus stable, mais non testée. Je teste aujourd'hui.

lien enlevé, voir le post 77

Voici ce que j'ai fait :
certains paramètres sont déclarés comme des Integer, mais sont calculés en utilisant 2 mots de 8 bits
param = mot1 * 256 + mot2
cela marche en général bien, car dans la réalité le mot1 est tout le temps inférieur ou égal à 127
mais parfois, pour les raisons de mauvaise communication évoquées plus haut, le mot1 est supérieur ou égal à 128, et la, ça explose
j'ai donc sauté ce calcul quand le programme trouvait dans cette situation
il manquera une donnée, mais c'est moins grave que planter.

 

[planétaire]

Bien vu, thierryb.

C'est d'ailleurs pour cela que, mais pour un usage normal donc avec des données correctes, certaines variables sont déclarées de type double, voire que certains calculs sont découpés sur plusieurs lignes.

 

[thierryb]

Effectivement, j'ai vu que dans certains cas tu utilisais le type Long et pas le type Integer.

 

[Palm35]

Voici une version qui devrait être plus stable, mais non testée. Je teste aujourd'hui.

https://docs.google.com/open?id=0B_Oh2yu8mH9pUDFJUUFtMUVRY0NpM2FIa1JXdk54UQ

je viens de récupérer ma Prius après révision des 107000 km (6ans) et changement de la batterie 12V par précaution.
J'ai testé ta version:
J'ai une erreur:
Run Time error '9'
Subscript out of range.

cela ne s'est pas produit en roulant mais dans ces conditions:
J'arrête la Prius, coupe le moteur, laisse le PC avec PCM tournant dessus, j'attends quelques minutes et Paf !
Peut être est ce normal car aucune infos arrivait à PCM étant donné que tout était coupé (sauf le PC et OBDLink ?)

 

[Less Polluter]

Je crois que PCM n'aime pas bosser pour rien. J'ai déjà remarqué qu'il ne lui plaisait pas que la voiture soit arrêtée avant lui. En somme c'est la même logique que lorsqu'il y a un faux contact sur le port USB évoqué plus haut par planétaire.