Autoconstruction de son cyclocomputer

Bonjour,

Etant dans l'incapacité la plus concrète d'apprécier la plupart des objets issus du commerce et sensés nous servir au quotidien, j'ai commencé récemment à m'attaquer à un objet qui est important dans mon quotidien cycliste: le cyclocomputer (existe-t-il un mot plus approprié en français?), il me permet d'apprécier ma forme et de me rendre compte des différences de vitesse engendrées par des changements de l'équipement de mon waw. J'utilise donc les données aussi bien en direct en roulant ainsi qu'après coup dans un tableur (vous l'auriez deviné, je n'aime pas le logiciel fourni par polar )

Dans mon vm j'ai donc installé un polar cs 400 depuis longtemps. D'abord sur un caisson de roue, il a déménagé ensuite sur ma pompe mountainmorph qui est installé transversallement juste devant mon nez sous la gouttière du waw. Pourquoi là? Parce que c'est assez petit comme machin et que cette distance convient mieux à mes yeux myopes. Et la pompe s'y prête bien justement car c'est le seul objet cylindrique dans le waw. Toutefois il reste un grand soucis d'ergonomie je trouve. Je roule souvent la nuit et on ne peut pas dire que l'éclairage du polar est très optimale, du reste, le capteur de cadence se trouve un peu éloigné maintenant (ce n'était pas le cas quand la montre était installé par-dessus la roue) et souvent je n'ai plus de connection avec celui-ci. Plus rarement j'ai le même soucis avec le capteur de vitesse.

A côté du polar se trouve un interval timer: il s'agît d'un chronomètre qui permet de programmer des séries d'intervalles et je l'utilise en parallel de mon polar dans lequel je ne règle qu'une fréquence haute et basse. C'est plus pratique je trouve que de paramétrer tout un exercice dans le polar même, qui s'avère ensuite impossible à suivre dans des conditions réelles sur la route. L'interval timer, légèrement plus ergonomique, peut facilement être mis en pause.

Je suis donc partie sur la base d'une carte arduino. J'avais une uno à la maison mais j'ai préféré prendre une arduino mega pour ce projet car elle à beaucoup plus de mémoire et me permettrait de développer tout sur des entrées réelles plutôt que de m'obliger à créer des ports émulés (c'est à dire transformer un port pwm p.ex en port sériel en l'inscrivant dans le code), dans un deuxième temps j'essayerai peut-être de tout refondre de sorte que je puisse utiliser une arduino uno. Voic donc la mega:


Dans mon polar j'utilise les fonctions suivantes tout le temps:
- Vitesse, distance, etc (cad reed-switch sur la roue)
- Cadence (reed-switch sur le pédalier)
- Fréquence cardiaque (+ conso énergétique moyenne et totale, même si ce n'est pas précis, ça permet toujours de comparer)
- Enregistrement et transfert sur pc
J'utilise un peu moins:
- calcul du dénivelé (par différence de pression barométrique), mes parcours de vélotaf ne varie pas beaucoup, je connais donc.
- Température
Ensuite, il y a les fonctions du chronomètre qui se partage entre mes deux appareils actuels:
- Temps de parcours sur le polar, ainsi que datage d'un parcours lors de l'enregistrement (un peu comme le n° de série, c'est ce qui permet de différencier les parcours)
- chronomètre en fractions sur l'interval-timer.

Pour Arduino il y a tout en tas de matériel périphérique à trouver, en plus ce n'est souvent pas très cher:

Un écran-lcd: j'ai une 16 x 2 (16 caractères, 2 lignes) il est prévu d'utiliser une 20 x 2


Les reed-switch étaient faciles à trouver: j'ai contacté Adam de ebikes qui m'en a envoyé deux:


Le capteur du rythme cardiaque existe sous une forme prèsque utilisable chez sparkfun, c'est ce qu'il y avait le plus cher (60 dollars) ensemble avec l'arduino mega lui-même:


Enregistrement sur carte mini-sd:

L'achat de cette carte était une erreur par contre: côté face il y a un tiroir pour une carte sd ce qui est beaucoup trop volumineux. Je trouverai une mini-sd seul plus tard.

Calcul de dénivelé: par un simple sensor à pression barométrique


J'ai bien encore un sensor de T° qui traîne quelque part pour terminer la part interaction avec le monde réel.

Ensuite, afin de disposer de la date et l'heure il me fallait une rtc (real time clock), alimenté par une pile bouton lithium:


Et finalement, en bonus, j'ai encore un 'shunt' cad un sensor de courant qui me permettra de me tenir au courant de l'état de charge de ma LiFePo de 12V8Ah. C'est important car je roule souvent la nuit et actuellement je tiens l'utilisation manuellement à jour.

Peut-être que dans une version finale je vampiriserais le shunt de mon ca que je n'utilise plus.

Ensemble celà donne ceci:

Commençons par l'écran:


Ceci devrait plus au moins correspondre à la vision de ma première page (j'en prévoit 3 ou 4):
Elle comprend dans l'ordre vitesse en haut et vitesse moyenne en bas, cadence en haut et cadence moyenne en bas, fréquence cardiaque et fréquence moyenne en bas (on voit bien que j'étais assis à mon bureau ) puis finalement il y a des secondes qui défilent en témoin du bon fonctionnement du rtc. En réalité il me faudrait un écran plus grand pour pouvoir afficher le temps sur 7 digits (H:MM:SS) ou cinq (MM:SS puis au bout d'une heure HH:MM)
Les vitesse et cadence sont à zero parce que je dois bouger l'aimant manuellement devant les switch. J'ai donc du arrêter pour faire la photo.
Concernant les moyennes, ils ne s'arrêtent pas tout à fait quand il n'y plus de signal des interrupts de la vitesse/cadence, mais continuent néanmoins à bouger un peu: Il y a un délai d'une seconde après chaque boucle du code, ce délai est soustrait du temps total mais il ne tient pas compte du temps qu'il faut pour faire passer la boucle à travers le processeur, il me faudrait donc l'affiner un peu si je peux. (le calcul du temps se fait à priori en millisecondes et il faudrait que je regarde comment faire pour y ajouter du temps en microsecondes pour tenir compte de la boucle) Disons que actuellement ça passe bien pour les feux rouges mais pas pour la pause casse-croute...

Le filtrage sur les entrées des reed-switch à été fait sur la base d'un petit schéma comme ceci:

C'est bien plus commode et robuste que d'aller coder un filtre. D'ailleurs, les reed-switch sont mis sur des interrupts et c'est mieux d'éviter d'avoir trop de code dans les interrupt-handlers. Actuellement il n'y a que l'indexation des tours (pédales ou roues) et ça marche très bien.

Voilà pour la base. Il me faut encore (il reste environs 89% des choses à faire ):
- Prévoir l'interaction depuis mon vm, actuellement je change dans le code quand il faut mais je n'ai pas forcement mon ordinateur avec moi dans mon vm bien-sûr.
- Pour ce faire je pensais créer éventuellement une quatrième page qui demanderais de mettre à jour les paramètres un à un.
- Et l'intégration de deux boutons pour faire défiler les pages ou encore atteindre la page de config.
- J'aurais donc 3 pages utilitaires: celle décrit en haut, une deuxième avec seulement la fc, cadence et l'intervaltimer, une troisième avec les totaux et les max.
- Coder l'enregistrement sur carte mini-sd.
- Et surtout refondre le code en maximisant l'utilisation de fonctions et de bibliothèques, car là, contrairement à l'impression que donne le visionnage de la photo de l'ensemble, niveau code c'est un peu chaotique.
- last but not least: intégrer tout ça dans un ou deux boîtiers.

Merci pour ce partage, une grande tentation
J'ai des questions :
J'ai du mal à comprendre a quoi va servir le polar cs 400 ? c'est seulement une interface entre le capteur de fréquence cardiaque et la carte arduino ou il servira a autre chose ?
Les capteurs reed, je suppose, servent à mesurer la fréquence d'une roue et du pédalier, c'est bien le cas ?
Quelle sera la source d'énergie de toute cette électronique ? As-tu une idée de sa consommation ?

J'allais poser les questions classiques : Pooling ou interruption?
et demander un schéma recençant les sources d'événements, la boucle principale et un WCET.

O'Leave a écrit:

a quoi va servir le polar cs 400

A rien en fait. S'il se trouve sur la photo c'est juste parce que je l'utilise maintenant et ça permet de se rendre compte de la taille de l'ensemble par apport au polar. En fait, il se trouve que par hasard, le hrmi (la carte avec le récepteur de fréquence cardique) fonctionne avec ma ceinture polar. Du coup au début je vais pouvoir garder le cs 400 juste à titre de contrôle tout en disposant de lectures séparés pour l'ensemble des paramètres.
Voici la config actuel:

O'Leave a écrit:

Les capteurs reed, je suppose, servent à mesurer la fréquence d'une roue et du pédalier, c'est bien le cas ?

Oui. Voir réponse à Jean-Lou plus bas.

O'Leave a écrit:

Quelle sera la source d'énergie de toute cette électronique ? As-tu une idée de sa consommation ?

L'accu de mes phares, j'ai une LiFePo de 12V8Ah sur lequel j'ai déjà un convertisseur >> 6V qui alimenta les deux supernova. Pour la conso j'espère justement qu'avec le sensor de puissance la conso se verra. A priori ça ne tire pas des masses mais c'est en continue bien-sûr.

Jean-Lou a écrit:

Pooling ou interruption

Les deux. Pooling pour à peu près tout qui rend des valeurs de façon constante, puis interrupt sur les reed. L'arrivée de leurs valeurs est vraiment trop aléatoire pour l'intégrer dans une boucle. Puis c'est énormement plus simple.
La subroutine pour un interrupt ressemble à peu près à ça:

Citation :

void interruptSpeed (){
indexV ++
}

Et la boucle principale ne fait que d'appeler des subroutines:

Citation :

void loop(){
Speed();
Cadence();
Heartrate();
Clock();
Delay(1000);
}

Chaque subroutine contient ce qu'il faut pour aller chercher les valeurs adéquates, calculer ce qu'il faut puis le code concernant l'affichage.
Le but est de garder la même forme mais en créant un niveau supplémentaire: Je peux créer une boucle principale où chaque pression sur un bouton appelle une autre subroutine qui correspond à une page. Le mieux est d'utiliser switch case pour ça je crois. Ensuite le subroutines qui correspondent à une page appellent d'autres comme celle d'en-haut p.ex

Ca devrait donner ça:

Citation :

void loop(){
switch (var){
case 1:
page1();
break;
case 2:
page2();
break;
etc

puis plus bas

Citation :

void page1(){
Speed();
Cadence();
Heartrate();
Clock();
Delay(1000);
}

Et ainsi de suite pour les autres pages.
De là, avec ces niveaux différents, l'intérêt de maximiser l'utilisation de bibliothèques et subroutines. Et là je découvre aussi...

Pour le temps d'exécution je ne sais pas trop, il y a le delai d'une seconde bien sûr, puis la plupart des fonctions retournent des valeurs, quelque soit le nombre de fois que l'on interroge les ports concernés. Donc finalement il ne reste que les deux reed qui sont de nature lente: 20 milliseconde au minimum pour un tour de roue et beaucoup plus pour la cadence: jusqu'à deux secondes p.ex pour faire de la muscu (35 tours par minute environs), de là l'importance de les envoyer sur des interrupt.

Désolé, je n'ai pas de schéma!

Tu devrais également poster ici :

http://arduino.cc/forum/index.php/board,33.0.html

C'est la partie francophone du forum arduino et elle est bien active

merci pour toutes ces réponses,
je peux vous proposer des stagiaires de M1 pour faire le boulot (hard/soft) mais pas avant janvier 2013 maintenant.

yoplait a écrit:

Tu devrais également poster ici :

Je crois aussi que ça devient inévitable

Jean-Lou a écrit:

je peux vous proposer des stagiaires de M1 pour faire le boulot

Super, merci beaucoup. En janvier 2013 j'espère être en phase d'optimisation avec espérons-le une centaine d'heures de roulage.

Merci pour les infos et l'archi logicielle qui parait simple et efficace.

Avec plaisir. Je continuerai de publier de temps en temps au fur et à mesure de l'avancement du bidule.