Forum BMH

tako a écrit :pour ce qui est de la vitesse "sol" en agricole on utilise un radars, un calculateur compare la vitesse radars a celle des roues et donne le taux de patinage.
Sans vouloir casser la motivation il doit déjà exister des calculateurs de bord existant sur le marché. Chez garmin il existe des modules de convertion analogique /numerique
https://buy.garmin.com/shop/shop.do?cID=162
notament un debimetre
https://buy.garmin.com/shop/shop.do?cID ... 1#specsTab
mais il doit exiter d autre produit

Bien sûr qu'il existe déjà des calculateurs de bord sur le marché, on n'invente rien ici... (on est beaucoup trop cons pour cela ! )

Les bidules agricoles sont pour que les paysans alignent des sillons bien rectilignes, et optimisent leurs épandages de semis ou engrais à l'hectare: ils ont plein de fonctions qui ne nous servent à rien, et coutent des fortunes. (la clientèle paysanne est en général une "bonne" clientèle... )

Tiens, d'ailleurs, s'ils utilisent un GPS pour calculer les distances (pas un radar) c'est parce que le phénomène de patinage est prépondérant en traction agricole, quand on tire cinq socs et qu'on en pousse trois, et que le comptage des tours de roues ou de transmission ne signifie plus grand'chose.

Dans notre cas, le patinage reste faible en comparaison, même s'il est bien présent quand on roule dans le sable mou: sur plusieurs dizaines (centaines ?) de km, ça commence à avoir de l'importance, et peut te fiche dedans avec tes estimations de navigation.

Par contre, en agriculture, on ne roule pas dégonflé car on ne cultive rien dans le sable... Les pneus restent au contraire le plus rigide possible, voire gonflés à l'eau, et la traction n'est assurée que par des crampons les plus profond possibles: Un ticket pour se retrouver au fond d'un trou si on essaie ça dans le sable, on l'a tous expérimenté.

Aussi les calculateurs agricoles ne sont-ils beaucoup plus adaptés à notre usage que les programmateurs de machine à laver...

Il y a plein d'autres trucs disponibles sur le marché: Les calculateurs développés pour le rallye-raid offrent quelques fonctions utilisables, mais pas toutes celles qu'il faudrait pour nous qui ne faisons pas la course et qui n'avons pas d'assistance qui nous marque à la culotte. Et les tarifs proposés sont également cadrés sur une clientèle euh... aisée.

Bon, allez, je ne crois pas me tromper en affirmant que les voyageurs grand raid que nous sommes constituent une clientèle trop disparate et trop économe pour qu'une boite d'électronique s'emm... a commercialiser un calculateur comme on le voudrait.

D'où la démarche entreprise de nous fabriquer notre outil nous-mêmes, pisse qu'on en a les moyens.

Allez, courage, vous allez voir qu'on va y arriver !

Pour en revenir au débat du gonflage, ça peut paraitre idiot, mais si la circonférence d'un pneu est bien constante par construction (la bande de roulement n'est pas élastique), sa longueur ne joue pas de rôle dans le rapport entre nombre de tours de roue et distance parcourue: C'est le rayon effectif de la roue qui entre en jeu.

Prenons les cas extrèmes:
- Un pneu bien gonflé monté sur une jante, sans aucune charge; Quand il roule, la distance du centre de la jante au sol est égale au rayon de la roue, tout se passe comme si le bande de roulement de longueur constante était déroulée sur le sol longueur après longueur: on connait la distance parcourue en comptant le nombre de tours, le calcul est exact.

- La même roue, avec un pneu tellement dégonflé qu'il n'a plus qu'une hauteur de 0mm, complètement écrabouillé sous la jante: Tout se passe comme si la jante roulait seule sur le sol, la distance du centre de la jante au sol est cette fois égale au rayon de la jante.. Qui ne parcourt plus du tout la même distance au tour de roue: le calcul est complètement faussé, on croit parcourir une distance beaucoup plus grande que la réalité, on cherche l'oasis désespérément alors qu'elle est encore à 100 kilomètres...

A ce phénomène s'ajoute le patinage, et l'usure du pneu qui fait diminuer le diamètre de la roue "pour de vrai".

Si on ne devait rouler que dans le sable, on pourrait conclure que le comptage des tours n'est pas la bonne méthode, comme pour le tracteur qui patouille dans son champ, et on s'orienterait vers la solution GPS, pas plus compliquée au demeurant, juste un poil plus cher en matériels. (pas en installation).

Mais comme on ne traverse pas le Sahara tous les matins, on peut dire que la méthode de comptage de tours est globalement adaptée à notre usage.

Allez, on s'y colle...

Voici pour ceux que ça intéresse le logigramme des fonctions tachymètre et odomètres:

imagik.fr

On utilise deux routines d'interruption, en plus du programme principal (en bas).

La première interruption est appelée par la réception d'un signal du capteur Hall (ce capteur donne un créneau à chaque passage d'un aimant solidaire d'un élément tournant)

La seconde interruption est appelée toutes les secondes par l'horloge interne du système, et se charge du calcul du tachymètre en km/h.

Le programme principal (ici représenté partiellement) traite un odomètre.

On récupère les deux variables (en vert) pour l'affichage.

Juste une idée... je suppose que l'affichage et le "filtrage" dépendent de ta seconde interruption d'une seconde ?

Est-ce que en cas de forte accélération (ou freinage) tu peux rafraichir à 0,2 - 0,4 ms l'affichage, et le stabilisé plus en cas de vitesse constante 1s ?

Bastien

L'interruption 1s fait le calcul du tachymètre, (ça compte le nombre d'impulsions Hall par unité de temps, donc ici pendant 1 seconde, et le convertit en km/h).

L'affichage est effectué par le programme principal, qui tourne quand les routines d'interruption le laissent tourner: Plus tu fais d'interruptions, moins le programme principal tourne vite.

En faisant le chronométrage du tachymètre plus rapidement, tu laisse moins de temps pour le rafraichissement de l'afficheur: tu calcules plus souvent, mais tu affiches plus lentement..
En d'autres termes, à quoi sert de faire un calcul plusieurs fois de suite si tu ne peux écrire son résultat qu'une fois ?

D'autre part, le comptage des impulsions perd en précision si tu diminue la période d'échantillonnage:

Mettons par exemple que ton capteur Hall te donne 10 impulsions par secondes à 10km/h: Le comptage est précis à +/- une impulsion, c'est à dire dans ce cas à +/- 1km/h.

Si tu réduit l'échantillonnage à 0.2s, tu vas compter 2 impulsions seulement au même régime, avec toujours la même précision de comptage à +/- 1 impulsion, et là ta précision dégringole à +/- 5km/h !!

Alors si tu réduis à 0.2 ou 0.4ms,(soit 0.0002s ou 0.0004s) tu vois ce qu'il reste...

Tout cela est donc une affaire de compromis, en plus de la persistance rétinienne qui dépend des personnes, et qui est de l'ordre de 50ms: Un rafraichissement trop rapide de l'affichage donne un truc illisible: un tachymètre ultra-rapide ne peut pas utiliser un affichage numérique, il faut un cadran et une aiguille.

Mais bon... notre truc, c'est pour équiper des poids-lourds de voyage, pour faire du calcul de consommation sur du moyen/long terme. Si vraiment une base de temps de 1 seconde pour le tachymètre est trop lente, (ce que je ne pense pas) on peut tenter de la réduire à 1/2 seconde, mais il faudra faire gaffe à ce qu'on fait avec le capteur Hall, et lui mettre deux cibles au lieu d'une afin de ne pas trop perdre en précision.

Bonjour

Je suis d'accord avec Nomade, la pression des pneus n'a pas d'incidence sur la précision du comptage kilomètrique. Ceci ne changera pas la nécessité d'une fonction et procédure d'étalonnage de la distance (et de la conso aussi).

Pour ceux qui ne sont pas convaincus : découpez une bande de papier de 2 cm de large et 21cm de long, collez les deux bouts de la bande sur 1 cm, il restera une bande de roulement de 20 cm. Faites une marque rouge quelque part en travers de la bande. Que vous fassiez rouler cette bande en y installant un bout de carton bien rond dans le milieu, ou un carton ovale, ou même carré, ou que vous la fassiez avancer comme une chenillette, (en exagérant pour la démonstration disons une chenillette de 2 cm de haut avec 8cm de long sur le sol) au passage du trait rouge la longueur parcourue sera la même dans tous les cas, donc en fait pour un tour de l'axe. La bande de papier n'est pas élastique pas plus que nos bandes de roulement de nos pneus. Pour qu'il y ait un écart il faudrait que la gente "patine" à l'intérieur du pneu. Il faut vraiment dégonfler beaucoup (moins de 1 kg) et que ça force dur pour avoir ce risque. En général ce patinage ne dure pas longtemps...

Je suis pour des fonctions simples autour des consos et les distances qui vont avec. Pour le reste il me semble que nous serons sans doute tous équipés de GPS couplés à un quelconque ordi. Je n'aime pas mettre tous mes oeufs dans le même panier.

L'electronique ne doit pas poser de probléme,visiblement il y a des experts ici.
Pour le choix du débitmètre, s'il y a aussi des experts ce qui suit est inutile. Les lois de la dynamique des fluides sont très complexes et je sais par expérience que ça finit toujours au labo par les essais d'un prototype grandeur nature et par un certains nombre de bidouillages, essais de différents modéles, tatonnements pour arriver au bon choix, quelle que soit la performance du bureau d'étude. Les constructeurs automobile ayant déjà résolu le problème, ce doit être du côté de cette filière technologique qu'il faut chercher la solution (si elle nous est accessible... ou un petit tour chez un casseur... )

Cordialement
Yves

yves ... a quelques mots près... le représentant Michelin m'a répondu pareil (pour la bande de roulement en fonction de la pression) ... donc +1
olive

Ah ben ça alors...

Vous avez raison ! car il faut effectivement pousser plus loin le raisonnement pour ne pas se planter:

D'un côté le diamètre efficace de la roue est inférieur au diamètre qu'elle a lorsqu'elle n'est pas déformée, et c'est bel et bien ce diamètre qui compte dans la formule de l'espace parcouru Pi x D.
du point de contact avec le sol.

De l'autre côté la bande de roulement est indéformable, l'image de la chenillette est parfaite pour se gourer: les galets tournent beaucoup plus vite que la chenille, un peu comme un hamster dans sa cage. Mais dans le cas d'un pneu, il y a les flancs, qu'il ne faut pas oublier... (si si, c'est important, les flancs... )
Ils rendent la bande de roulement solidaire de la jante, et comme ils ne sont pas élastiques, ils travaillent en cisaillement et forcent la bande de roulement à avancer tout de même pour qu'elle reste alignée avec la jante, et l'espace parcouru réel redevient égal à la longueur de la bande de roulement. Toc.

Je ne vous raconte pas les efforts subits dans ce cas par les flancs du pneu, on comprend pourquoi il y a échauffement au point d'éclater lorsqu'on roule sous-gonflé à grande vitesse.

Ainsi, la constatation faite en roulant dans du sable mou que l'odomètre devient optimiste n'est à mettre au compte que du patinage, et l'erreur est loin d'être négligeable sur de longues distances.

Eh ben... Non!

J'avais raison, incroyable, non ?
On va même présenter la chose de façon différente, pour donner plus de piquant: Je parie 2000 € , que dis-je, 5000 € que la pression de gonflage influence bien le nombre de tours de roues, pour les raisons que j'ai décrites précédemment.

Voilà qui devrait intéresser le représentant Michelin, non ?

ça y est, un premier prototype fonctionne en simulation, avec un affichage numérique à 4 digits à LEDs.

C'est au moment de réfléchir à l'interface homme-machine que ça coince:

Avec les fonctions qui sont traitées, on a pas moins de 14 affichages, avec un total de 5 unités différentes: litres - l/h - l/100 - km - km/h.

En faisant le tour des moyens techniques d'interface, (c'est à dire des instruments qui permettent à l'opérateur de sélectionner telle ou telle fonction, et de lire le résultat et son unité sans laquelle une valeur numérique ne signifie pas grand chose) on se retrouve vite avec un truc illisible, ou alors avec un gros panneau indicateur lumineux de 14 (15) cases plus gros que l'afficheur numérique...

Il n'y a pas trente-six solutions, si l'on veut garder un truc quelque peu esthétique, il nous faut changer de mode d'affichage pour pouvoir indiquer la fonction et l'unité en même temps que la valeur numérique...

Et là le choix est vite fait, les afficheurs LCD graphiques sont les plus adaptés, et à condition de ne pas vouloir un truc grand comme un téléviseur de salon, le budget restera raisonnable: une cinquantaine d'€ pour un écran de dimensions 45X30mm environ.

alors ???

Alors ... qu'en pensez-vous ?

On peut rester avec l'option de l'afficheur à 4 digits (+ point décimal) à LED, du style des radio-reveils d'antan, et que je préfère pour des raisons de simplicité et de robustesse.

Mais dans ce cas, l'interface homme-machine est complexe, et se présentera sous la forme d'un tableau de 15 cases, un peu comme les verrines d'alarmes des anciens tableaux de bord d'avion ou de bateau:

On sélectionne une fonction à l'aide de 4 boutons de navigation, qui allument la case concernée, et dans laquelle on peut alors lire le nom de la fonction, et l'unité du résultat. L'afficheur à 4 digits donne la valeur calculée.

C'est gros et encombrant, car chaque case doit faire un minimum de 20X30mm pour être lisible, donc ça ferait un panneau de 150mm x 80mm environ avec les boutons et l'afficheur;

Et un peu plus de travail manuel à base de profilés d'aluminium pour réaliser le cadre du panneau et les séparations entre les cases.


OU on utilise un afficheur graphique, qui présente l'avantage d'une réduction de taille car en fait cela revient à une seule case du tableau précédent, qui sert pour toutes les autres.

Et si on augment un peu la taille de cet afficheur graphique, on peut même y regrouper l'afficheur à 4 digits.

Notre zinzin se présenterait alors comme un boitier de taille réduite, environ 80x50x40, avec en face avant un afficheur graphique de 40x30 et un "joystick" pour naviguer dans les fonctions.

Cette solution est la plus simple à mettre en oeuvre (bon, ça donne un peu plus de boulot de codage pour la mise en oeuvre de l'afficheur graphique, mais ça se fait...) mais aux dépends du coût des matériels.

Par contre, si l'on compte le temps de main d'oeuvre de réalisation du tableau en alu, qui normalement sera réalisé par chacun de nous, (pas compliqué), c'est pas sûr que le coût global augmente de beaucoup.

Salut Maximillian,
Ca se précise on dirait, tu saurais nous donner une approximation du coût final du montage que tu proposes (afficheur LCD+ joystick) ?

On doit pouvoir s'en tirer à moins de 400€, avec un boitier en aluminium. Là chacun pourra décider de la finition qu'il préfère, un bon boitier en plastique ferait aussi l'affaire.

Ceux qui sont intéressés peuvent déjà acheter les débitmètres, le fournisseur le plus pratique qui distribue ceux de la marque dont j'ai parlé est... Conrad!

https://www.conrad.fr (ref 150391-62): il en faut 2, ils coutent 30 cacahuètes pièce.

L'afficheur LCD que je vais utiliser est visible ici: http://www.ezoled.com/ (EZL-176), mais attendez que j'ai fini la mise au point avant de vous le procurer.

J'espère que les Coréens ne vont pas se chamailler, because le fournisseur de µC est de là-bas...

la taille de l'afficheur me fait un peu peur, me serais je trompé de référence, y a t'il un rétro éclairage ( à la session by night du rasso on a du tété quelques litrons de gazouz )? c'est vrai qu'un affichage digit ça fait old school, quelle taille prendraient les indications sur cette écran ??
je reviens vite fais sur la question de distance parcourue, je m'interesse de plus en plus à la navigation au road-book, et une chose est sûre, dans des conditions comme celles du rasso picard, tout tombe a l'eau question distance puisque nos roues faisaient 6 tours pour parcourir 1 mètre, quelque soit le trip embraqué, suivre le road book là ça devient du sport...la remise à zéro sera t elle par impulsion ou avec un potar de manière a pouvoir se retiré 300 mètres, par exemple lorsque l'on s'est trompé d'orientation, revenir au point précèdent ??
votre projet m'intéresse énormément, pressé de voir le prototype

Cet afficheur parait petit, mais cette dimension est à priori suffisante dans notre cas car on ne va afficher que peu de trucs: En gros, une valeur numérique à 4 chiffres, en en plus petit l'unité (km/h, litres ...) et une ligne qui précisera la fonction: km/h dernière heure, odo 1, autonomie, etc...

Je vais essayer de toutes manières, et si ce machin ne permet pas une vision claire à 1m, on changera pour plus grand, mais les tarifs augmentent vite avec la taille: on passe 100€ pour un monochrome deux fois plus grand.

Une autre solution serait de prendre un afficheur alpha-numérique, qui ne peut écrire que des nombres ou des lettres, mais ils présentent l'inconvénient d'avoir des caractères un peu petits pour notre truc.


Il y a bien sûr un rétro-éclairage, mais pour une meilleure vision (et moins de fatigue visuelle) on restera avec des caractères de couleur sur fond noir.

Pour ce qui est du patinages des roues, on est d'accord, ça fausse tout...
La seule solution dans un tel cas est d'utiliser un module GPS comme on en a déjà parlé, je vais essayer ce développement quand celui-ci sera terminé.

Pour la remise à zéro des odomètres, pour l'instant c'est du "tout ou rien", on appuie et paf, on a zéro.

Mais on peut imaginer un odomètre plus complexe, qui compte ou décompte au choix, afin de solutionner le cas dont tu parles:

Si on doit rebrousser chemin, on sélectionne "décomptage", qui décompte jusqu'au point où l'on reprend le bon chemin, et on sélectionne ensuite "comptage"... Facile.

Je vais faire une picture du proto actuel ce soir, mais pas d'affolements, ce n'est encore qu'un proto...

voilà un aperçu du calculateur actuel, dans sa version de développement du programme:

imagik.fr

Le µC est monté sur le support visible à gauche, et raconte sa vie à l'afficheur numérique à 4 digits également à gauche, par une liaison série I2C. (l'afficheur est aveuglé par le flash, il est normalement très visible)

C'est une platine d'essais à tout faire, qui comporte des ramifications qui ne nous seront pas utiles dans notre cas, et qui permet grâce à son port série de programmer le µC et de le tester/débugger.

Ensuite, on réalisera le circuit imprimé d'un premier proto quand tout sera figé (afficheur, joystick, barrières galvaniques etc...) sur lequel on transfèrera le µC.

Et on sera bons pour un essai sur véhicule et déverminage des derniers défauts.

Le développement nécessaire au nouvel afficheur a pris plus de temps que prévu, mais globalement ça prend tournure:



La photo est un peu floue, mais on distingue le nouvel afficheur en bas à droite, réglé sur l'écran qui donne les consommations instantanées, horaire et sur les cent derniers kilomètres. (le comptage de débit et la fréquence de vitesse sont bien sûr simulées)

A gauche, c'est un clavier provisoire car je n'ai pas encore reçu le joystick, mais bon, il faut que le fournisseur remette un peu d'ordre dans son stock après le tsunami...

voici à quoi ressemble l'un des capteurs de débits, tel qu'ils sont livrés:



Toujours flou, car pas de flash ni de pied, désolé...

On voit le capteur avec une pièce de monnaie pour donner l'échelle, le connecteur en pièces à sertir et la buse de réduction de débit, inutile pour nous.

Voilà une photo un peu moins mauvaise de l'affichage réglé sur les odomètres:

Salut Maxime, cool ça avance bien !

Pour héberger les images, mets les directement sur le forum, c'est plus durable et c'est plus simple aussi
@+
dimitri

Je ne sais pas ce que les zotorités fabriquent par chez moi, mais les hébergement de photos fonctionnent de plus en plus mal... je vais surtout faire des photos meilleures dès que possible avant de les héberger sur le forum.

Le tracé du circuit imprimé du prototype est presque terminé, il me faut juste un détail pour le finaliser:

On a dit qu'on utiliserait le capteur de niveau du réservoir à carburant d'origine du véhicule. (on pourra par la suite prévoir de le remplacer par une sonde capacitive plus fiable, mais pour le début, on va faire simple;

De façon à dessiner l'étage d'amplification du signal de ce capteur, il faudrait une petite contribution de ceux qui sont intéressés par ce truc:

Sur leur véhicule, il faudrait mesurer le signal donné par le capteur de la façon suivante:

- Noter la quantité de carburant
- Débrancher le fil du capteur, sur le réservoir.
- Brancher un ohmmètre entre la borne du capteur et sa borne de masse juste à côté, et relever la valeur mesurée.

Si possible, renouveler l'opération pour plusieurs points, comme par exemple juste avant de faire le plein, et une autre mesure après l'avoir fait.

On verra alors si les valeurs de chacun se recoupent ou sont voisines les unes des autres, ce qui serait l'idéal, ou alors si il y a une grande dispersion de valeurs.