[Projet] Un tableau de bord numérisé

je suis fan te ton projet :slight_smile:

mais je ne peux m'empécher de penser qu'il irait mieux dans une R25 ou une XM. série 1 bien entendu !

oui, mais justement, je trouve que ça cadre mieux dans une grosse berline comme la 25 ou la XM, qui en plus, l'une comme l'autre, étaient déja bardées d'électronique quelque peu... capricieuse ! Et ce genre de projet ça va bien avec les tableaux de bord "star trek" de l'époque, en plus :slight_smile:

ceci dit, je ne critique pas, hein :slight_smile: je donne juste mon avis

jespère :slight_smile:

je songe à faire un truc un peu similaire (mais bien plus simple) pour remplacer l'afficheur 2 lignes de l'ODB de ma XM, afin de faire qqch d'un peu plus interactif. Et si possible couplé à une gestion maison de la boite auto... mais c'est comme tout, plein d'idée et pas de temps...

Salut,

Je suis allé loin, en effet, puisque j'ai un premier proto qui fait bouger les aiguilles en fonction des potars qui simulent les capteurs... Mais là où je bloque, c'est qu'ayant changé de voiture, je n'ai plus besoin de capteurs, mais simplement de décoder une trame émis par port série, et surtout que je ne vais pas tarder à démonter mon moteur, donc encore plus en pause... Y'a aussi que j'ai choisi d'orienter le coeur du système vers une STM32F4 discovery, ça va m'obliger à me mettre à un nouveau proc, et l'apprentissage ne sera pas si facile.

Mon moteur est un F3N (1L7 injection multipoint) Pour ton J7T, il est de la mauvaise année, car c'est l'année de l'obligation de la norme ODB2. Je suis en train de travailler sur les versions d'avant, qui n'ont rien à voir. L'ancienne norme RENAULT était caractérisée par une grosse prise diagnostic 12 points "l'électrifil". Vois si tu as cette prise ou une plus petite pour le diagnostique. Dans le premier cas, je peux te dire comment récupérer les infos du calculateur et comment en décoder une partie (je n'ai pas encore tout trouvé, c'est un format propriétaire, donc gardé jalousement dans un coffre fort chez renault). Ce serait du coup bien plus facile de récupérer une valeur sur deux octets de cette trame de données, par exemple pour la vitesse moteur, la formule est tr/min = 15000000 / word(d6, d5).

Pour te donner une idée des infos, un screenshoot de mon soft en cours de développement :

et affichage des courbes lors d'un démarrage par exemple :

le tout est de voir quelle version tu as en sortie de ton calculateur.

Pour Bricofoy, il te suffit de trouver une doc sur ton odb (en général, le brochage est dans la revue technique), ce n'est que des signaux analogiques et des impulsions à mesurer. J'ai fait une étude sur un ODB de super5 avec le format des données et formules de conversion :

super5_-odb-_etude_technique_0.pdf

bonsoir supercinci
pour ma culture personnelle
ça se trouve facilement "en occasion" le débitmètre utilisé ?
quel ordre de "prix" ?
ça peut etre sympa dans certains cas de DIY si le cout n'est pas prohibitif

Super_Cinci:
Pour ton J7T, il est de la mauvaise année, car c'est l'année de l'obligation de la norme ODB2.

... d'un autre coté, l'ODB2 est il me semble relativement bien documenté, on trouve sur le net à peu près tout ce qu'il faut pour l'utiliser.

Bonjour,
Je n'ai toujours pas compris si on pouvait envoyer des commandes (par exemple le taux d'accélération) sur OBD2.
Je ne vois que des exemples de lectures d'informations, mais pas de commandes vers le véhicule...

Artouste:
bonsoir supercinci
pour ma culture personnelle
ça se trouve facilement "en occasion" le débitmètre utilisé ?
quel ordre de "prix" ?
ça peut etre sympa dans certains cas de DIY si le cout n'est pas prohibitif

Salut,

Le débitmètre se trouve dans toutes les casses, il faut regarder sur le tableau de bord de la voiture, s'il y a un ODB, enfin un truc qui affiche la conso, c'est le signe de la présence d'un débitmètre.

Il y a deux types de débitmètres, selon si c'est un moteur à carbu ou injection. Dans le premier cas, il se place juste à l'entrée d'essence du carburateur (deux durits), dans le second, il est sur l'entrée et la sortie du circuit de carburant (4 durits). C'est un truc pas bien gros qui se démonte facilement. Le plus dur étant de réussir à le placer sur le circuit de sa voiture, au bon endroit et dans le bon sens. Attention cependant à ne pas le confondre avec une électrovanne... selon les casses, ça sera 2€ ou 50€...

Un autre truc intéressant à récupérer, du coup, c'est le capteur de vitesse, sur les vieilles autos, il fait partiel du câble qui relie la boîte de vitesse au tableau de bord (récupérer le câble complet et la connectique). l'association des deux permet de refaire soi-même un calculateur de conso / autonomie.

@ 5_cylindres : il faut que tu trouves ta prise diag, son format nous renseignera tout de suite sur le protocole...

C'est sûr que l'OBD2 est plus facile, puisque c'est une norme européenne, donc accessible, mais je ne me suis encore jamais penché dessus (ça viendra, car j'ai la voiture de madame à diagnostiquer également, 1997 ODB2). En effet, l'ODB2 est bidirrectionnel, il peut recevoir des ordres, mais je ne sais pas (encore) comment...

etimou:
Bonjour,
Je n'ai toujours pas compris si on pouvait envoyer des commandes (par exemple le taux d'accélération) sur OBD2.
Je ne vois que des exemples de lectures d'informations, mais pas de commandes vers le véhicule...

pour ce que j'en sais, non.
par contre l'ODB2, c'est une norme qui définit le protocole de com, et certains messages, mais absolument pas la totalité, il existe d'autres commandes propriétaires propres à chaque fabricant pour dialoguer avec les calculateurs via le protocole et le bus ODB2. Parmis ces commandes, il est possible qu'il existe ce que tu cherche. le problème, c'est que par définition, c'est propriétaire, donc sans doc publique...

5_cylindres:
salut Super_Cinci

pour la prise diag de mon espace 2 : de mémoire il s'agit d'une grosse prise noire sous le capot, env. 4 à 5 cm de côté, avec 12 contacts disposés en 4 x 3, mais je ne peux confirmer car j'ai fixé un relais dessus pour le compresseur de clim et je n'ai aucun collier pour le raccrocher si je le démonte

C'est donc de première génération, celle sur laquelle je m'arrache les cheveux actuellement et je peux te donner tous les renseignements que j'ai. Si tu es patient, je suis en train de monter une doc sur ce que j'ai trouvé, une sorte de rapport d'étude.

5_cylindres:
sinon, pour rester sérieux, tu penses pouvoir en extraire des données exploitables pendant le fonctionnement ?

Si tu regardes les courbes sur fond noir dans mon post un peu plus haut, c'est un enregistrement que j'ai fait sur 25 secondes.
Comme c'est moi qui ai développé le soft, je suis capable de décoder ces courbes à vue... Mais pour le commun des mortels, ces courbes sont toutes cantonnées sur des valeurs entre 0 et 510 (0-255 x 2) et ne montrent que leur évolution dans le temps.
t = 0 : contact mis, moteur arrêté.
t = 5,5 s : j'actionne le démarreur (ce qui fait naturellement chuter la tension batterie en rouge), on voit le passage des compressions sur la pression du collecteur.
t = 6 s : le calculateur a repéré l'ordre des pistons et commence à injecter l'essence (en violet).
t = 7 s : Le moteur démarre, la pression collecteur chute à 400mb, l'alternateur passe en charge (la tension batterie grimpe à 14V), le moteur monte à environ 1800tr/min.
t = 8 s : La phase de démarrage est terminée, le calculateur passe alors en mode régulation de ralenti (courbe bleue : commande de vanne de ralenti).
t = 18,5 s : la courbe verte (entrées numériques) tombe à 0 parce que j'appuie sur l'accélérateur. Toutes les courbes suivent la montée en régime du moteur.
t = 20,5 s : je relâche l'accélérateur : le moteur retombe au relanti.
t = 23,5 s : je donne un grand coup d'accélérateur (la pression collecteur remonte, ce qui indique au calculateur qu'il faut réagir en injectant plus d'essence, plus d'avance allumage...)

Bref, J'ai en effet toutes les données que je veux. Sur cette portion de graphe, il y a 1500 trames de données environ (c'est assez précis?).

Bien sûr, mon soft décode les données en valeurs humaines en temps réel (voir la fenêtre avec les valeurs numériques, ça te montre les données que l'on peut extraire de la trame).

Il faut juste savoir qu'au coeur du calculateur, c'est un 68HC11, et qu'il n'émet de données que s'il a le temps (dans l'ordre des priorités, gérer l'injection et l'allumage, logique, les données diagnostiques ne sont pas importantes pour lui). Mais comme je l'ai dit, ça ne l'empêche pas d'envoyer des trames toutes les 9 ou 10ms dès qu'il n'a plus à gérer la régulation de ralenti... D'ailleurs, je viens de m'apercevoir qu'il a arrêté l'envoi de trames durant la phase de démarrage (6 < t < 7).

Bon, je suis en plein développement, et je viens de claquer mon joint de culasse, donc je n'ai pas pu faire l'enregistrement d'un trajet (ne serait-ce que le tour du pâté de maison...). Mais je pense que sur ta prise diag, tu trouveras assez d'infos pour ne pas avoir à mettre des capteurs partout...

Sur la R11, j'utilisais la vitesse de rotation du moteur, que je multipliais par un coéf (fonction du type de boîte de vitesse, différentiel, taille des pneus) pour trouver la vitesse en km/h. Comme en général, on ne régule la vitesse que sur route en 5°, mon LCD m'affichait 30 / 33km/h quand j'étais arrêté à un feu rouge... :wink: et ça marchait très bien! De plus, tu as dans la trame une info intéressante : le contact "pied levé", qui passe à false dès que tu touches l'accélérateur (donc à ce moment, ça désactive le régulateur, l'humain reprend le contrôle). Tu n'aurais besoin que de rajouter un capteur sur la pédale d'embrayage et piquer le signal sur le frein : dès que tu touches l'une des trois pédales, ça coupe la régulation.

Le capteur pour l'embrayage, il y a un logement sur le pédalier qui permet de mettre le même capteur que celui de la pédale de frein, que du bonheur...

Toute la réflexion sur le protocole est là : http://www.forum-super5.fr/index.php?showtopic=9508, depuis une bête question...

Super_Cinci:
...
Il y a deux types de débitmètres, selon si c'est un moteur à carbu ou injection. Dans le premier cas, il se place juste à l'entrée d'essence du carburateur (deux durits), dans le second, il est sur l'entrée et la sortie du circuit de carburant (4 durits). C'est un truc pas bien gros qui se démonte facilement. Le plus dur étant de réussir à le placer sur le circuit de sa voiture, au bon endroit et dans le bon sens. Attention cependant à ne pas le confondre avec une électrovanne... selon les casses, ça sera 2€ ou 50€...
...

bonjour supercinci
Si à l'occasion de tes peregrinations dans les "casses" tu tombe sur un ou deux debitmetre jusqu'à +/-une dizaine d'€ piece , tu me contacte ?

Artouste:
bonjour supercinci
Si à l'occasion de tes peregrinations dans les "casses" tu tombe sur un ou deux debitmetre jusqu'à +/-une dizaine d'€ piece , tu me contacte ?

je note. Je n'ai pas prévu de passage en casse prochainement, mais peut-être que je vais tenter d'aller glâner quelque calculateurs pour faire des tests.

il y avait des débimètres de ce genre sur les BX avec ODB (19GT, digit...) et je me suis aperçu que ces débimètres sont aussi employés... dans les machines à expresso ! j'en ai récupéré deux en démontant des machines à la déchetterie :slight_smile:

Pour ceux que ça intéresse voila la solution : Arduino Forum

elriri:
Pour ceux que ça intéresse voila la solution : Arduino Forum

La solution à quoi, je vois pas le rapport entre le filtre de Kalmann et le tableau de bord de superCinci ?

Salut la communauté,

Je reviens d'une semaine de vacances où je n'avais rien à faire de mes soirées une fois ma fille couchée. J'ai donc ressorti mon vieux projet (et oui, toujours d'actualité).

Après quelques changements de véhicule, il était temps de s'y remettre et de revoir certaines choses.

Comme je l'avais précisé, la nouvelle receveuse du gadget me simplifie grandement la tâche grâce à son calculateur d'injection qui me fournit en temps réel une trame de 37 octets sur l'état du moteur (température, rotation, capteurs, durée d'injection, avance allumage, défauts...). Il ne me reste donc plus grand chose à traiter : gestion de l'accélérateur (je remplace le câble par un potar et un servomoteur), vitesse en km/h, conso, quelques capteurs. Je me suis donc rabattu sur un MEGA2560.

Presque toutes les mesures seront traitées par interruptions, ce qui veut dire que loop() sera vide (enfin presque). Voici la liste des INTs que j'ai déjà prévues :

ISR (PCINT0_vect) : gestion d'un clavier matriciel 4x5, les touches sont bufferisées dans un FIFO.
ISR (USART3_RX_vect) : réception de la trame de données série du calculateur d'injection, les données remplissent un tableau de 37 bytes.
ISR (TIMER4_OVF_vect) et ISR (TIMER4_ICP_vect) : calcul de la vitesse en km/h et incrément des compteurs kilométriques
ISR (TIMER5_ICP_vect) : calcul de la consommation (xx,x l/100)
ISR (ADC_vect) : numérisation automatique de 8 entrées analogiques renseignant un tableau de 8 word
ISR (WDT_vect) : timer de déclenchement à intervalles réguliers (256ms) pour le régulateur de vitesse

Bref, l'idée est que toutes les variables de données se mettent à jour automatiquement, il suffit alors de les lire quand on en a besoin, c'est tout... De même, j'aurai 3 sorties servomoteur gérées directement par les sorties hard PWM du timer1, genre un simple OCR1A = valeur; suffit à changer la position du servomoteur. Pour les deux écrans du TDB, j'utilise USART 1 et 2 pour leur envoyer les données à afficher.

Tout ça est bien gentil, mais j'ai eu la chance d'ouvrir le wiring.c et d'y découvrir toute une initialisation barbare des timers, ainsi que de l'ADC. j'ai donc viré tout ça, histoire que le core arduino ne me configure pas les ressources de traviol pour rien (de même pour les fonctions delay(), micros()..., je les ai virées). Je configure le tout directement par les registres, en lisant le datasheet de l'AVR. J'ai aussi viré la gestion de l'USART3 pour pouvoir récupérer l'INT correspondante. J'ai aussi vu quelque part (dans le main.c je crois) qu'entre deux exécutions de loop(), il y avait un "doSerialEvents();", ce qui ne me plait pas trop, il faut que je vois ce que c'est et le virer également au besoin.
Ne serait-ce que pour la conversion analogique numérique, analogRead() prend un temps fou, car elle lance une numérisation et attend les 104µs de la conversion pour obtenir le résultat. Il faut savoir que 104µs représentent 1664 instructions (oh le beau nombre!), et que tout ça, c'est perdu dans un while(...){rien;}. sur 8 conversions à la suite, ça nous fait à peu près 13 500 instructions de perdues. Il faut quand même savoir que le CAN est indépendant, et qu'il fait les conversions tout seul dans son coin sans utiliser le CPU. J'utilise donc l'INT du CAN, déclenchée une fois la conversion terminée, et qui relance elle-même une nouvelle conversion puis rend la main au programme. Ca prend à peine 30 instructions contre les 1700 du core arduino. On apprend beaucoup en déchiffrant les datasheets...

Je pense gérer moi-même la gestion des ports série par la suite, car décidément, l'équipe arduino ne s'est pas trop occupée des temps de traitement...

Restera à voir si les interruptions ne se bouffent pas trop les unes-les-autres, que ça me laisse un peu de temps processeur pour le traitement...

A suivre!

Effectivement, pour l'instant, j'ai fait mes premières brides de code avec PSPad, un éditeur miltulangage (très pratique en PHP qui propose une coloration syntaxique bien plus claire qu'arduino, et qui a l'avantage de lister toutes les fonctions et #define d'un fichier pour se retrouver et naviguer plus vite. On peut lui associer un (des) compilateur(s), il faudrait essayer.

sinon, j'ai monté une platine avec une dizaine de potars et 24 inters, une alim 12V + 5V, et en plus un UNO qui génère la trame "XR25" (trame série du calculateur d'injection) avec de nombreuses données qui bougent (vitesse moteur, durée d'injection, avance allumage, dépression admission...), et quelques signaux d'impulsions (vitesse véhicule, débitmètre...). J'ai donc un banc d'essai (complet?) pour le développement sur le 2560, car ce n'est pas facile de développer un truc en conduisant.

Bonjour monsieur Super_Cinci,

je suis impressionné par votre projet. Je compte effectuer la même chose pour une voiture de course.

J'ai juste une question à vous poser : comment avez-vous récupérer le signal du capteur PMH sans perturber ce signal qui va jusqu'au calculateur.

Dans l'attente de vous lire,

Romain.