can_usb eeePC

[ceif2001]

le percent.mp3 est particulièrement silencieux

Bonjour

Avec ce petit programme (à lancer dans le dossier voice_english ou voice_french) tu peux tester tous les sons.

cat play_all

#!/bin/csh
foreach i (`ls *.mp3`)
echo $i
play $i
end


Comme tu peux le voir le fichier Percent.mp3 n'est pas vide

Par contre sur mon EEEPC la lecture des sons courts (1.mp3, 10.mp3 ...) n'est pas vraiment de la HiFi, avec un léger son ajouté à la fin (et ce même avec le son d'origine en anglais ). 😢

Ce problème n'existe pas sur les sons plus longs ( DoorOpen.mp3, FuelAvailable.mp3 ... ) ou bien sur un autre PC Linux 😱

De toute façon cette fonction sonore reste quand même au niveau du gadget (et une adaptation pour le français du code est nécessaire (lecture de l'heure, miles restant ... ))

A+

Pierre

 

[ceif2001]

Voix en Français

Je viens de mettre à jour le fichier de voie en Français (avec les sons Heure et minute) à récupérer par :

(wget pierrebonneau.com/voice_french.tgz)

D'autre part j'ai également adapté le fichier graphcan.c pour une meilleure lecture de l'heure, à récupérer par :

(wget pierrebonneau.com/graphcan.c)

Voici le diff entre cette version et la dernière de priusfan
1751d1750
< V_HEURE, V_MINUTE,
1761c1760
< "FuelAvailable.mp3", "Miles.mp3", "Heure.mp3", "Minute.mp3"
---
> "FuelAvailable.mp3", "Miles.mp3"
1879d1877
< CallVoice(V_HEURE, 0);
1887,1888c1885
< CallVoice(V_10 + ct->tm_min, 0);
< CallVoice(V_MINUTE, 1);
---
> CallVoice(V_10 + ct->tm_min, 1);
1894,1895c1891
< CallVoice(V_1 + ct->tm_min - 1, 0);
< CallVoice(V_MINUTE, 1);
---
> CallVoice(V_1 + ct->tm_min - 1, 1);
1898,1899c1894
< CallVoice(V_20 + a - 2, 0);
< CallVoice(V_MINUTE, 1);
---
> CallVoice(V_20 + a - 2, 1);
1904,1905c1899
< CallVoice(V_1 + ct->tm_min - 1, 0);
< CallVoice(V_MINUTE, 1);
---
> CallVoice(V_1 + ct->tm_min - 1, 1);


A+

Pierre

 

[Mik&Toy]

@ Priusfan : À propos de « recompiler TOUT en exécutant sudo make clean »
j'ai observé un tas de warning durant la compil, venant des divers "tools".
Est-ce grave, docteur ?

@ Ceif2001: Si tu as d'autres sources pour des sons supplémentaires, je suis preneur.
Au départ, j'étais pas très fana des causettes en roulant, mais comme on ne peut pas regarder en permanence l'écran du EeePC, sur des évenements imprévus, ça serait bien qu'ils soient relatés en vocal. mais pas les "pour cent" !

 

[priusfan]

les warnings sont "normaux"

 

[Mik&Toy]

analyse CAN

La consommation d'essence vue par le CANmonitor installé sur l'EeePC:

Une lecture trés appliquée du code C du module "graphcan" permet d'en tirer les informations suivantes:
C'est le paramètre "0x348" intitulé "ICE Throttle" qui est utilisé pour calculer la consommation d'essence, conjointement au paramètre "0x3CA" "Speed".
Ces deux valeurs sont moyennées à chaque seconde puis servent au calcul de la consommation à la façon US :

. . . [ MPG (Mile Per Gallon) = ( Speed / Throttle ) x 10000 ]

l'unité de "Speed" est le km/h, la précision au km/h près. L'unité de "Throttle" n'est pas précisée dans les documents. Ce qui est dit, c'est qu'il est "RPM related" et pourrait correspondre au "requested RPM". Effectivement, son évolution suit de très près le régime du moteur thermique avec un facteur 10. (donc une précision de 1 pour 50.000)

Pour une meilleure approche en unités SI on peut transformer le calcul en

. . . [ Litre/100 km = 2.352 % de ( Throttle / Speed ) ] . . . (3.78~ / 1.61~ ) x ( 100 / 10000)

Il n'apparait pas d'autre information qui soit utilisée dans ce module pour caractériser la consommation de carburant.

nota: il n'y a pas que l'eau qui nous sépare des anglo-saxons, il y a aussi ce fameux facteur 2,352 qui sonne toujours deux fois, une fois pour les miles (1.61 km), et une fois pour les gallons (3.78 L), et puis cette idée d'inverser le rapport. A la mode actuellement , la barre des 50 MPG = 4.7 L/100km.

 

[Mik&Toy]

débit d'essence

Autre manière de voir le mécanisme de cette consommation :
par unité de temps plutôt que par unité de distance.
On élimine le facteur vitesse et il reste :

. . . [ Débit (en Litre/heure) = 2.352 ‰ de Régime (en tours/mn) ] . . . (*1)

et encore plus simple, la quantité d'essence injectée à chaque tour du moteur :

. . . [ Dose par tour = 39.2 µL (ou mm³) ] . . . (*2)

Ce mode de calcul utilisé dans le "Graphcan" pourrait signifier qu'à régime établi, la pompe d'injection fournit une quantité d'essence toujours la même, quel que soit le régime du moteur, de environ 20 µL par tour pour chaque cylindre.

calcul des coefficients:
*1: en considérant que le régime moteur exprimé en tr/mn équivaut au 1/10éme du paramètre "Throttle",
ce dernier exprimant la consigne de régime demandé par le calculateur de bord ("requested RPM").
*2 = (1/1000) x (2.352 / 3600) x 60 ... L > µL ... US > SI ... h > s ... tr/mn > tr/s

 

[ket]

Donc si:

Ce mode de calcul utilisé dans le "Graphcan" pourrait signifier qu'à régime établi, la pompe d'injection fournit une quantité d'essence toujours la même, quel que soit le régime du moteur, de environ 20 µL par tour pour chaque cylindre.

cela veut dire quantité d'essence proportionnelle aux nombre de tours, logique mais uniquement à régime établi.

Quid des accélérations, ou quant on roule sur son élan sans aucun appui sur la pédale de l'accélérateur ? j'avais alors à une vitesse d'environ 110 km/h.
une indication de 960 t/mn. et une conso. ( indiquée ) de 2,2 l/km. et j'avoue que cela me gène ( du moins intellectuellement - dans la compréhension de cette consommation ).

 

[Mik&Toy]

régime "respecté"

Par "régime établi" je veux dire, enfin c'est ce que j'imagine, à partir du moment où le moteur à atteint le régime demandé par le calculo. Pas un régime constant, donc. Ç'est à dire, dès que la consigne est atteinte, ce qui doit se faire dans des fractions de secondes pendant lesquelles tous les contrôles du moteur sont en recherche d'équilibre. Ça couvre amha les cas d'accélération et aussi de moteur tournant à l'arrêt du véhicule.

Il faut imaginer tout le mécanisme de régulation du thermique toujours à l'affût de la consigne calculo, qui doit être rafraîchie aux alentours de 50 fois par seconde.
Les milisecondes pendant lesquelles cette consomation n'est pas stable ne devraient donc pas beaucoup jouer pour le calcul, vu aussi qu'elles se situent de part et d'autre de la valeur fixée. (en 1 seconde un moteur tournant à 3000 tr/mn aura fait 50 tours).

Je pense aussi à l'action prépondérante de MG1 pour "aider" * le thermique à respecter la consigne, chose qui n'est naturellemnt pas envisageable sur un véhicule priustorique, et qui doit considérablement raccourcir le délai. (* le pousser au derrière, serait plus mon idée)

 

[Mik&Toy]

Il y a quand même qqch qui me trouble dans ce calcul, c'est qu'aux arrondis près, cette constante de 39.2, c'est quasiment (2pi)², comme ci j'aurai dû tomber sur une égalité à 1 (raisonnement rebouclé sur lui-même) mais que j'aurais inversé une division par 2pi avec une multiplication par 2pi. Pourtant, je n'ai pas utilisé de conversion de degrés en en radians.

Shadoko, à l'aide ! je trouve les conclusions de mon raisonnement pour le moins étrange !

 

[Mik&Toy]

re-programmation

Je continue l'analyse du module graphcan. J'ai repris goût à la programmation, bien que le langage C ne soit pas des plus conviviaux.

Et aux vu du manque patent d'organisation de ce codage, je me propose de le reprendre. Je vois trois parties (c'est le principe , il faut toujours trois parties !) :

1/ l'acquisiton des données provenant de l'interface CAN OBD,
2/ l'affichage à l'écran des données utiles au conducteur durant le parcours,
3/ l'enregistrement des données en fichiers logs pour analyse en différé.

Plus un 4 éme volet pour la simulation du système en l'absence de connexion CAN (et pas tout au hasard comme l'actuelle), et même un 5eme pour la relecture des logs à l'écran en différé.

Pour le point 1, la difficulté provient des cadences très variables de présentaton des paramètres sur l'interface CAN. Il y aussi le fait que beaucoup d'entre elles ne nous sont pas connues - pour le moment - comme le débit d'essence aux injecteurs.

Pour l'affichage, il va falloir trouver des modes d'affichages plus lisibles et plus jolis que les "bar-graph (cadrans et autres), et surtout des chiffres plus nets. Et rendre indépendants les calculs pour l'affichage (3 ou 4 fois par seconde) et ceux pour les enregistrements à la seconde.

Pour le point 3, il est évident que l'ajout des logs de Priusfan représente une avancée majeure par rapport au module d'origine. Reste à savoir quelle marge le EeePC nous laisse actuellement pour ajouter d'autres paramètres.
Et aussi d'autre types d'enregistrements comme les statisitiques. La version d'origine doit nécéssairement être refaite de fond en comble.

Et aussi reprendre tous les joyeux mélanges d'unités et de passage des miles aux kilomètres et des gallons aux litres, plus tous les croisements possibles et pas toujours viables.

Et penser à la demande des rallyemen pour tenir la cadence sur les spéciales !

Donc je m'y attelle.

 

[Palm35]

Vaste programme ! (c'est le cas de le dire !)
Y'a du boulot pour tout réécrire, et surtout, tout débugguer....

Pense aussi à l'évolution des eeePC, et à leur futur écran 9 pouces..
Faudrait donc que le programme détecte si c'est du 7" ou du 9" ...
En tout cas, voilà un projet super passionnant...

Merci à toi de t'y atteler...

 

[Mik&Toy]

On est déjà passé sur l'EeePC actuel de 640 à 800 en largeur d'écran. Je ne vois que du bonus à avoir un écran plus grand. Et je lorgne aussi du coté des écrans programmables à connecter par USB (chez Lextronic et d'autres) pour présenter des infos en plus devant le volant. Comme les comptes-tours dans le temps !

 

[Palm35]

J'ai vu, puisque je suis attentivement cette discussion, que vous étiez passé de 640 à800.
Par contre, je ne connais pas du tout ces écrans programmables USB.
Mais pour avoir les infos, faut bien installer le programme quelque part !
C'est dans le moniteur ?
Quel OS ?

 

[Mik&Toy]

Ce sont des matériels dont j'ai déjà parlé dans ce message.

Reste à savoir si l'EeePC peut les prendre en plus du CANUSB et du GPS !
Mes mesures actuelles de perf effectuées au travers du graphcan me laissent craindre que non.
Il va falloir envisager un deuxième EeePC ! Ils seraient très bien ensemble, connectés par leur WiFi !

J'ai aussi trouvé un localisateur-enregistreur GPS sur carte SD, en kit chez Conrad, qui serait en mesure de ressortir le trajet après le parcours.

 

[Mik&Toy]

test de charge

Je viens d'ajouter un bout de code pour évaluer la charge actuelle du programme "graphcan".
Je teste en fait le temps pris par les calculs et les affichages de l'ensemble des routines "update" par rapport à la seconde.
J'ai mis toutes les routines à la queue leu leu, après les avoir désactivées aux endroits où elles figurent d'origine, et j'utilise comme timer la réception de la donnée "courant batterie" cadencée aux alentours de 60 par seconde.
Les infos sont disponibles en colonnes supplémentaires dans le fichier de log "Can ....xls". Ça bouchonne ! Je vais analyser ça de plus près.

Qelques petits aménagements supplémentaires pour ranger les fichiers "logs" et "stats" dans des sous répertoires de "/mycanscan" (/graphlogs et /graphstats), et donner des noms fixes aux fichiers générés lors d'une simulation.

Tous les ajouts de graphiques et de calculs que j'ai pu essayer jusqu'ici ralentissent considérablement le programme, jusqu'à faire disparaitre partiellement l'affichage. Il faut écrire en linéaire pour "passer". Pas de sous-programmes avec paramètres d'appel, ou alors les mettre dans un module à part. Ce que je vais essayer.

J'ai testé aussi le bi-linguisme en roulant. ça fonctionne mais pas dans cette version.

Le source ici.

 

[Mik&Toy]

évolution

En réponse à la chasse aux petites voitures vertes, j'ai ajouté dans une version modifiée du graphcan, un totalisateur des énergies dépensées et récupérées par la batterie.
Il accumule séparement (chaque seconde) la recharge batterie avec le thermique et sans (freinage régénératif) ainsi que la décharge avec thermique tournant lors des arrêts du véhicule, et sans le thermique, c.à.d. en mode EV (demandé ou obtenu en glide). Plus une évaluation de pertes ohmiques dans la batterie.

Je suis en train de le tester et de voir quels paramètres sont les plus significatifs pour détecter ces changements de mode.
Et je vais y ajouter un autre totalisateur sur les durées de parcours en roue libre, et préciser celles ou MG2 est utilisé en générateur a haute vitesse.

Il me semble que l'affichage de ce type d'information est plus intéressant et moins contraignant à observer en roulant. Le reste se faisant par dépouillement des logs à la maison.

 

[priusfan]

Enhanced Toyota Engine Module List

liste des infos prévues par le CAN

bon appétit...
il ne reste plus qu' à trouver comment les récupérer

 

[Mik&Toy]

Quelques réflexions et propositions sur le Graphcan :

1/ Les quelques tentatives que j'ai faites de modifier le programme graphcan actuel afin d'augmenter le nombre de paramètres récupérés et le nombre d'affichages temps réel se sont soldées par une saturation visible (disparition de certains pavés d'affichage, ralentissement du nombre d'acquisitions par secondes des paramètres les plus rapides).

2/ La validité de la mesure de la consommation d'essence reste à prouver vu qu'elle n'utilise qu'un paramètre (intitulé "Throttle") qui suit comme son ombre (ou le précède) le régime de rotation du thermique. Quid de l'info ODB ?

3/ Une spécification plus ambitieuse de cet "appareil de mesure" devrait être de pouvoir récupérer la totalité des paramètres disponibles qui défilent à la sortie du bus CAN, et de pouvoir les enregistrer tels quels, à leur cadence respective, sans effectuer les moyennes actuelles à la seconde qui masquent des transitions et des corrélations significatives.

4/ L' affichage en temps réel des paramètres devrait pouvoir être sélectionné parmi plusieurs écrans prédéfinis, à l'image de l'écran de bord actuel, en utilisant un écran tactile.

5/ le mode vocal devrait pouvoir diffuser des sons et sonorités permettant de repèrer rapidement les modes de fonctionnement les plus intéressants pour une conduite économique, comme le mode "glide", ou le freinage régénératif, sans avoir à constamment surveiller l'affichage.

6/ L'idéal serait bien sûr, que tout cela soit fourni gracieusement par le constructeur dans le prochain modèle de Prius.

ps: ci-joint deux dernières tentatives infructueuses qui promettaient pourtant en simulation !

 

[priusfan]

consommation exacte

bingo

la solution existe, il s'agit de cela : http://www.crxmpg.com/supermid.html

le principe est de piquer l'info de l'injection à coté de la boite à fusible.

je suis en contact avec yoshi.
le programme canmonitor dont il vient de m'envoyer le source pour le canusb utilise ce dispositif et permet d'afficher la conso réelle.

yoshi est connu sous le pseudo de ken1784 sur priuschat.
je le contacte demain pour détails de son dispositif.
je mettrai ici le lien de son site (j'ai du mal à le retrouver !!! et de toute façon c'est en japonais massif...)

 

[Mik&Toy]

Il semblerait bien que le paramètre CAN0x520 dénomé FuelInjector transmette - d'après un document Toyota concernant les moteurs thermiques et les paramètres OBD - la durée d'ouverture des électrovannes (en milisecondes, avec sûrement une échelle ad hoc pour coller dans un 16bit).

En considérant la pression de la pompe d'injection comme constante, on peut en déduire le volume d'essence injecté à chaque tour du moteur.

Il ne reste plus qu'à multiplier cette valeur par la vitesse de rotation pour obtenir un débit horaire, puis la diviser par la vitesse du véhicule pour un débit kilomètrique. le tout avec un coefficient qui tienne compte des unités un peu disparates de cm³/tr, de tr/mn et de km/h.

Si on confronte cette méthode à celle utilisant le débit d'air en entrée du thermique, on va finir par y arriver, à coincer la goute d'essence !

 

[Mik&Toy]

information trouvée dans le document Prius out of gas

Fuel pressure can vary while driving if there is a volume or flow restriction, so we drove the car hard with a cold engine, since high load with a cold engine requires the highest volume of fuel.

Ce qui veut dire que la pression n'est pas constante, et que si il y a un contrôle ECU pour la faire varier, il devrait y avoir une mesure de cette modulation.

 

[croco78]

Après avoir relu l'article, je pense que l'auteur a voulu dire que la pression est constante sauf s'il y a des problèmes d'alimentation en carburant: réservoir vide, filtre bouché, pompe défaillante...

Donc en première approximation, la consommation est proportionnelle au temps d'ouverture des injecteurs.

 

[Mik&Toy]

Tu as sûrement raison, enfin je l'espère bien !

 

[priusfan]

j'aurais bientôt qqs éléments de réponse.

je travaille (en pointillés) sur l'utilisation des codes complémentaires accessibles sur la prise diag.
http://en.wikipedia.org/wiki/OBD-II_PIDs

je suis trés optimiste sur leur récupération , en complément de ceux spécifiques à la prius.

 

[Mik&Toy]

Je ne vois pas dans toutes ces pages de code la moindre apparition d'une info concernant l'injection de carbuant. Ce devrait être d'après la terminologie OBD un PID commeçant en P02 ou P12 (powertrain generic/specific injection).

Dans l'article cité précédemment "Prius out of gas", l'auteur s'interroge sur la possibilité que pourrait exploiter Toy de récupérer le pic de tension en retour à la fermeture de l'injecteur comme indication du bon fonctionnement du solénoïde. donc un PID possible, mais rien à l'horizon !