can_usb eeePC

[priusfan]

la feuille excel citée précédemment provient du canview et pas du dispo de shadoko.

je suis en train de modifier graphcan pour inclure:
la position du "shifter"
les kW
le "fuelflow"
et surtout pour tenter de trouver l'affectation des données suivantes (mail de attila):

Exact torque values are not reported as far as I know, but need 
to be solicited. Which means you have to send a request on the 
CAN and wait for a response : 
1. Send to ID 0x7e2 : 02 21 c3 00 00 00 00 00 (len:8) 
2. you should get back on ID 0x7eA  : 10 27 61 c3 ?? ?? ?? ?? (len 8)  these are not relevant for torque
3. Now send to ID 0x7e2 :  30 00 00 00 00 00 00 00 (len 8) 
And you'll get the rest of the data 
ID 7ea   21 ?? ?? ?? ?? ?? ?? ?? 
ID 7ea   22 ?? ?? ?? ?? ?? ?? ?? 
ID 7ea   23 ?? ?? ?? ?? ?? ?? ?? 
ID 7ea   24 ?? ?? ?? ?? ?? ?? ?? 
ID 7ea   25 ?? ?? ?? ?? ?? ?? ?? 

In all those questions marks lies MG1 and MG2 RPM, torq, temp, inv temps as well as engine speed request and eng speed etc. 
Play with it and observe... ;-) 

Cheers, 

        Attila

j'ai pour le moment un gros pb de mise au point que j'espère résoudre d'ici 2 jours.
étape suivante : comparer sur un même trajet les données du canview avec celles que je vais récolter de façon à remplacer les points d'interrogation par les données significatives....
lorsque j'aurai avancé, je demanderai à attila de confirmer...
l'auteur du canview ne communiquera pas facilement ses recherches car il continue à vendre le canview et il ne va pas se tirer une balle dans le pied...

 

[priusfan]

et voilou, mon pb est débloqué.
le source actualisé est ici
le fichier de log contient 3 colonnes supplémentaires :
FuelInjector ; reste à trouver le coef pour avoir des L/H
Shifter ; à traduire en lettre
KW : kw moyen

par ailleurs, un autre fichier de log CAXxxxxxxxxx est généré simultanément (suivant les instructions de attila , cf post précédent).
il reste à le décoder......

 

[Mik&Toy]

J'ai déjà regardé tes modifications précédentes. Bel effort dans un pareil bazar !
Je vais tenter l'installation de ta nouvelle mouture.

pour les infos ID 7EA , ça devrait pouvoir se décoder comme les températures catalyseur. On pourrait d'abord les afficher et les interprèter ensuite.

Au sujet du glissement du temps, je vois toujours sur les tableaux des sauts d'une seconde toutes les 2 ou 3 minutes.

ps1: pour les choix "NON_ZAURUS" et "X11/XWIN" notre EEPC se situe dans quelle catégorie ?
et nous est-il permis d'activer et "USE_VOICE_ANNOUNCEMENT" et "SIMULATION" ?

ps2: je ne vois pas de nouvelles colonnes dans le " crache_log" du graphcan.c !

 

[priusfan]

.....
Il me semble possibe d'améliorer légèrement le calcul des moyennes en supprimant l'un des deux compteurs Nb_Volt et Nb_Amp , qui évoluent conjointement, et de simplifier le "if avec un "else".

ton module :
--------------------------------------------
Current = V;
if (V >= 0x800)
{
Current = 0x0FFF -(V & 0xFFF) ;
Cum_Amp -= Current;
}
if (V < 0x800)
Cum_Amp += Current;
++Nb_Volt;
++Nb_Amp;
Cum_Volt += B;
Cum_KW += Current * B;
--------------------------------------------
remplacé par :
--------------------------------------------
if (V >= 0x800)
{
Current = 0x0FFF -(V & 0xFFF) ;
Cum_Amp -= Current;
}
else
{
Current = V;
Cum_Amp += Current;
}
++Nb_Current;

Cum_Volt += B;
Cum_KW += Current * B;
--------------------------------------------

Je me demande aussi si l'utilisation de variables "long" ne serait pas préférable pour la précision, comme c'est le cas pour les calculs d'origine qui suivent :

CollCurr += (unsigned long) V;
CollVolt += (unsigned long) B;

J'aurais bien envie d'en faire plus, mais le risque de plantage m'en dissuade, pour le moment !

à la prochaine,
Michel

je mets ici ce message de michel car il peut inspirer d'autres personnes...

tes remarques sont bonnes...
dans les compteurs , un seul est utilisé au moment des calculs...
d'ailleurs quand tu parles de variables "long" ne serait pas préférable pour la précision, c'est beaucoup plus que cela car un dépassement de capacité provoquerait des résultats carrément aberrants.

j'en tiendrai compte lors de ma prochaine modif.

ps1: pour les choix "NON_ZAURUS" et "X11/XWIN" notre EEPC se situe dans quelle catégorie ?
et nous est-il permis d'activer et "USE_VOICE_ANNOUNCEMENT" et "SIMULATION" ?

le eeePC est NON_ZAURUS et tourne sous X11.
je crois que l'activation vocale n'est pas opérationnelle car dans ce pgm il est fait appel à un truc spécial pour lire des mp3. yapuka changer cela

la simulation est ok : il faut lancer graphcan avec l'option -o
npta : la simulation ne permet pas de relire un trajet mémorisé , mais seulement de générer un trajet aléatoire (et complètement irréaliste).

PS: je manipule le source de graphcan sous VisualStudio sur une machine sous XP et sur un grand écran, ensuite je le transfère par clé USB sur eeePC pour compilation.
pour info, l'impression de ce machin nécessite 84 pages...

 

[Mik&Toy]

Le comportement de la batterie de traction vu ici lors d'une mise en chauffe le matin

[/IMG]

Le thermique tourne (courbe en bas en violet), le véhicule étant à l'arrêt, pour "diverses choses", dont une petite charge de la batterie.

La notion de résistance interne est beaucoup plus complexe que prévu : à courant constant de charge d'environ 12 A (bleu foncé), la tension (vert fin) croît linéairement de manière rapide (226 à 236 V en moins de 1 minute), ce qui n'est lié directement ni à la variation de sa capacité (1% de SOC, en bleu), ni à une résistance interne constante (Fem calculée en orange).
Il y a des phénomènes chimiques qu'il serait intéressant de modéliser, à travers ces courbes, pour pouvoir caractériser chaque batterie.

Cette réaction particulière, palier de courant - forte rampe de tension, apparaît de ci de là, sur tous les enregistrements visionnés.

 

[Mik&Toy]

Le choc !

À te lire, Priusfan, mon coeur s'est arrêter de battre ! Ton au-revouar était déchirant !

Aussi pour me remettre de mes émotions, et pour saluer le retour de notre web-foundator Philou51, j'aimerais bien qu'il nous concocte une petite base d'échange de données pour les logs du GraphCan, enfin bien sûr, si il est d'accord et si il le voit faisable ! Qu'en pensez-vous ?

 

[priusfan]

en ce qui concerne les annonces vocales, je crois être sur une piste:
dans graphcan.c , les appels à mp doivent être remplacés par play.

j'ai testé en mode console play "xxxx.mp3" et cela marche.

les paramètres de play sont +simples : le nom du fichier à écouter et c'est tout.

@suivre

 

[priusfan]

ça y est , il parle .....
le source est ici

 

[Mik&Toy]

K2000

Je ne vois pas où tu l'as activée, la parole. t'as changé du code ? (je l'ai pas trouvée, la modif). ça cause en roulant ? (j'ai pas encore essayé). Ou c'est juste pour s'amuser à la maison ?

Et pour le clavier, y'a des trucs qu'on peut changer pendant le trajet, ou faire des snapshots ?

 

[priusfan]

toutes mes excuses, je n"ai pas mis le source actualisé au bon endroit.
cela sera fait ce soir.
je confirme que cela marche (au détriment de la stabilité?)

 

[priusfan]

un lien actualisé vers le source.
attention, il faudra le renommer en graphcan.c

 

[Mik&Toy]

Je me suis plongé dans le C++, depuis mon installation du gaphcan.

Ça m'a permis d'ajouter deux acquisitions du CAN, la vitesse des roues et l'accéléromètre (paramètres 23 et B1).

La vitesse des roues est très précise, au 1/100éme de km/h, 10 fois meilleure que la vitesse actuellement enregistrée et en plus 10 fois plus souvent (à 50 fps).

Cette précision permet de la dériver pour obtenir l'accélération du véhicule, et de l'intégrer pour obtenir la distance. les valeurs obtenues de cette manière diffèrent des résultats précédents, de 2/3km/h en moins pour la vitesse, env. 5% en moins pour la distance.

Le capteur accéléromètre, comme il fallait le prévoir additionne les accélérations et les inclinaisons. Si on soustrait la valeur obtenue par dérivation de la vitesse des roues, il reste la pente, avec une précision d'environ 1%.

Passionnant tout ça ! Je continue …

 

[Palm35]

La vitesse des roues est très précise, au 1/100éme de km/h, 10 fois meilleure que la vitesse actuellement enregistrée et en plus 10 fois plus souvent (à 50 fps).…

Waouh...
Et comme je le disais à Priusfan, il doit bien y avoir un paramétre de distance associée aux roues, non ?
Dans un tunnel, l'antenne GPS ne reçoit plus, et donc c'est le paramétre envoyé par les roues qui renseigne de combien de métre on a avancé.

Donc, si on peut récupérer la vitesse au 1/100eme de km/h et la distance, on peut fabriquer/programmer un ch'ti programme qui sera la rolls pour les rallye de régularité comme par hasard celui de Monte Carlo....

 

[priusfan]

Je me suis plongé dans le C++, depuis mon installation du gaphcan....
Passionnant tout ça ! Je continue …

bravo !!!
as tu testé la version que j'ai publié ??
elle parle et elle collecte d'autres infos (suivant conseils de attila) qu'il faudra bien éclaircir...

un détail : ce programme est en C ( pas vraiment de ++)

 

[priusfan]

info vitesse distance.
tous les GPS intégrés (y compris celui de la prius ) utilisent une info fournie par un générateur d'impulsion connecté aux roues.
ils comportent tous également un capteur de vitesse angulaire , couramment appelé gyroscope; cet équipement permet de continuer à localiser le véhicule même en absence de données satellite.c'est intéressant dans les tunnels sinueux avec des embranchements.
en général ,le GPS se (re)calibre régulièrement automatiquement en comparant la vitesse réelle (qu'il calcule) et la fréquence de ces impulsions.
ci-joint une petite citation de attila qui a également utilisé cette info des roues

Bonjour François,

I also played with GPS ( driven from my PSP ) and combine with
tire rotation from the Prius to have more accurate data...

 

[Mik&Toy]

Je joint ici les parties de code à ajouter (aux bons endroits) au module grapcan.c pour la récup des infos vitesses roues et accéléro.

ps: je pense qu'avec des mesures de cette précision, on peut étalonner la résistance à l'avancement du véhicule, en utilisant le mode "N", par exemple à l'approche d'une barrière de péage, si la route est horizontale, et sans vent bien sûr.

 

[shadoko]

....
La vitesse des roues est très précise, au 1/100éme de km/h, 10 fois meilleure que la vitesse actuellement enregistrée et en plus 10 fois plus souvent (à 50 fps).
....

Petite nuance : tu peux fort bien avoir la vitesse de rotation des roues avec un grande précision (au pouïème de chouia de radian par seconde), mais ça ne te donne pas pour autant une vitesse de la voiture au 1/100ème de km/h, vu que celle-ci dépend du diamètre des roues, qui lui-même dépend de l'usure des pneus, du gonflage... et tout cela donne des variations bien supérieures au 1/100ème de km/h aux vitesses usuelles !

Les pneus des Prius ont un diamètre de 62 cm environ ; une usure de 1 mm provoque déjà une erreur relative de 1/310 alors que 1/100ème de km/h à 50 km/h représente une erreur relative de 1/5000...

 

[Mik&Toy]

Je m'y attendais !

Mais toutes les mesures de vitesse et de distance à bord de la Prius viennent de cette acquisition. A moins d'utiliser une reconnaissance optique du défilement de la route, comme les souris optiques, il va bien falloir qu'on s'en accomode.
Et puis il doit y avoir aussi un léger dérapage de la gomme des pneus à l'effort.

Donc un étalonnage fréquent avec un chrono et des bornes kilomètriques, par exemple.

 

[priusfan]

propal info distance / vitesse
utiliser l'information des roues arrières
elles sont moins chargées: donc se déforment moins
elles ne sont pas soumises au couple moteur: moins de glissement
elles sont moins sollicitées pour le freinage: moins de glissement

utilisation complète de l'écran du eeePC

l'écran du eeePC est de 800 x 480
le programme utilise 640 x 480
on peut récupérer une bande de 160 à droite de la manière suivante:
dans ui.h modifier WIDTH et le passer de 640 à 800
recompiler TOUT en exécutant successivement (si nécessaire précédé de sudo):
make clean
make
make install
cela fait de la place pour visualiser d'autres paramètres.

tests de mycanscan sur autre plateforme

cet ensemble de programmes a été installé sur une de mes machines sous ubuntu , tout se compile et s'exécute normalement.

 

[Palm35]

T'es vraiment un pro de Linux, priusfan....

 

[Mik&Toy]

Question au GPS'istes :
La distance produite par les relevés GPS tient-elle compte de l'allongement du parcours lié aux dénivelés, ou se base t'elle seulement sur les coordonnées projetées ?

@Priusfan:
Ta modif de largeur d'écran, c'est du solide. C'est tout de suite plus confortable en 800 qu'en 640 !
J'en ai profité pour concocter un cadran à aiguilles, genre tachy-compte-tours. Il permet d'afficher 4 valeurs à la fois, sur deux aiguilles et sur deux arcs de cercles. photo et code vont suivre.

 

[ceif2001]

Dossier des voix en Français

Bonsoir,

Je viens de mettre le dossier des voix en Français.

Vous pouvez les récupérer par la commande :
wget pierrebonneau.com/voice_french.tgz

Puis un petit tar zxvf voice_french.tgz dans le dossier graphcan pour l'installer ainsi qu'une compilation pour l'utiliser .

J'ai personnellement renommé l'ancien dossier voice en voice_english et donc en changeant le lien symbolique voice vers voice_french ou voice_english on peut choisir la langue ( mais je n'ai pas fait le Mandarin )



A+

Pierre

 

[priusfan]

le percent.mp3 est particulièrement silencieux

 

[Mik&Toy]

@ Palm35:
« … si on peut récupérer la vitesse au 1/100eme de km/h et la distance, on peut fabriquer/programmer un ch'ti programme … »

J'imagine quelque chose comme ça avec l'EeePC et le graphcan:
1/ on fait le repèrage du circuit en marquant des jalons (temps, distance, vitesse) dans un fichier (par appui sur une touche), ou bien on le prépare d'après la carte.
2/ on rectifie le fichier à l'étape.
3/on le relit pendant la course : on fait apparaitre sur une ligne à l'écran la position réelle et la position prévue (fantôme) et on s'arrange pour les faire coller !
Mais c'est peut-être bien un truc comme çà que les Pros utilisent.

 

[Palm35]

Oui et non.
D'abord, pour nous, il est impossible de faire un repérage.
Ensuite, il y a deux choses différentes:
-1° suivre le parcours sans se tromper de route
-2° rouler à une vitesse moyenne spécifiée lors des Zones de Régularité (ZR)

Pour le 1, le copilote de DmH utilisait Autoroute express avec l'itinéraire déjà tracé à partir du roadbook. Le GPS de la Prius ou un autre en plus peuvent s'en charger

Pour le 2°, il faudrait un programme qui permette:
-l'étalonnage de la Prius: on met à zéro sur l'eeePC la distance, on roule entre les deux marques d'étalonnage de la route et on regarde la distance donnée par le eeePC. On ajuste ensuite la valeur trouvée par l'eeePC (à partir des capteurs de vitesse des roues qui nous "donne" la distance) par rapport à la distance donnée par l'organisation deu rallye.

-Ensuite, on 'devrait' trouver au minimum dans ce programme:
-la vitesse de régularité imposée (que l'on rentre nous même !)
-la vitesse moyenne
-la vitesse instantanée
-un chrono (qu'on démarre au moment du 'top départ')
-la distance parcourue depuis le top départ
-et enfin une fenêtre qui nous donnerait le 'gap', à savoir si on est en avance ou en retard et de combien de secondes.

Ca c'est le minimum...
Ensuite on peut rajouter pleins d'autres options intéressantes (que je vous détaillerais plus tard)....

Et quand le programme fontionnera bien on pourra le vendre....

Un peu comme ce programme....