Projet de "Lap counter"

Bonjour à tous,

Me revoilà sur le forum avec un nouveau projet: un compte tour pour du modélisme.

Je me suis pour l'instant lancé dans une configuration avec des diodes IR et un capteur IR démodulateur ce qui me permet de distinguer 6 utilisateurs différents suivant leur code d'émission (en gros comme si on appuyait sur 6 touches différentes d'une télécommande).

La détection se passe bien en utilisant la bibliothèque IR Remote. En descendant à 1ms d'interval entre 2 émissions le capteur reçoit bien les codes.

Mes questions sont les suivantes:

Pour la suite je compte ajouter un écran LCD pour "publier" les résultats et avoir un suivit de qui est le premier, les temps par tour et le nombre de tours pour un temps de course donné.

Le soucis c'est QUID de ce qui se passe si je suis en train de "publier" sur le lcd alors qu'un concurent passe sous le capteur?

Comment gérer au mieux le datalogging pour que ça prenne le moins de temps possible et ainsi éviter les non détections de passages?

Merci d'avance pour vos conseils

La solution la plus simple. Un arduino ne coûte pas cher donc séparer les fonctions dans 2 arduino.

Autrement, analyser le fonctionnement de la librairie IR Remote. Je crois qu'elle fonctionne sous interruption donc il n'y a peut être pas de problème.

Merci fdufnews pour les infos.

J'ai pensé effectivement a ajouter un arduino mais je ne vois vraiment pas comment faire la liaison de données entre les deux? Il faudrait que j'établisse une connexion entre les deux pour envoyer les données de l'un à l'autre et après que je traite les données reçues de l'autre côté? Mais j'en reviens au même problème non? Comment je fais pour continuer à recevoir les données sur le 2e arduino et à les publier en même temps?

Je ne m'y connais pas assez en programmation pour analyser la lib IR Remote. Je sais quelle utilise les interruptions pour fonctionner mais je n'en sais pas plus. Si ça utilise les interruptions ça veut dire que la fonction va prendre le pas sur le reste du programme quoi qu'il arrive?

john_lenfr: ... Le soucis c'est QUID de ce qui se passe si je suis en train de "publier" sur le lcd alors qu'un concurent passe sous le capteur?

Comment gérer au mieux le datalogging pour que ça prenne le moins de temps possible et ainsi éviter les non détections de passages?

Merci d'avance pour vos conseils

bonjour normalement irremote utilise une interruption lorsque tu sera sous int , ton affichage LCD sera ignoré

Salut Artouste comment vas tu?

Je vous met ci joint le début de mon programme.

Je n’ai pas encore implémenté la partie publication pour le récepteur.
Le principe est que plusieurs “émeteurs” se baladent et envoient leur signal en continu.
Dès q’ils passe sous le capteur ils sont détectés.

Ensuite je souhaite :
-enregistrer le nombre de tours parcourus depuis le début
-leur temps de parcours
-leur position dans la course

Pour cela, comment gérer la fonction irrecv.decode(&results) qui est pour l’instant intégrée dans un if uniquement.
Je veux dire, est ce que la fonction irrecv.decode(&results) est toujours active? ou bien c’est séquentiel par rapport au reste du programme?

J’ai du mal à voir comment organiser tout ça pour “gérer” au mieux les “colisions” qu’il pourrait y avoir entre le capteur et la publication des données.

v1.zip (2.04 KB)

john_lenfr: J'ai du mal à voir comment organiser tout ça pour "gérer" au mieux les "colisions" qu'il pourrait y avoir entre le capteur et la publication des données.

c'est quoi le taux de recurrence de passage (durée d'un tour pour un émetteur) ?

Le problème n'est pas la récurrence de passage, mais que plusieurs joueurs peuvent passer quasi en même temps sous le capteur (2 émetteurs par exemple). Pour la partie récurence je prévois une variable et un flag. Et en plus il ne faut pas que le programme soit en train de faire autre chose alors qu'un joueur passe sous le capteur au même moment, sinon son tour n'est pas pris en compte.

Remarque, je me pose peut être de faux problèmes car je n'ai pas testé mais bon j'aimerais éviter de découvrir ça par la suite.

Je comptais utiliser la fonction millis() pour faire des publications moins souvent que du "captage" mais m'est venu cette idée de conflit si je suis en train d'écrire sur le LCD et qu'un joueur passe comme par hasard sous le capteur en meme temps?

Bon apparemment je me poserais de faux problèmes car d'après des tests en utilisant Serial.print dans le main, ça continue de donner la priorité au capteur quand ça reçoit quelque chose et aucune donnée n'est coupée.

Je dois faire plus de tests une fois le lcd connecté avec le reste.

Affaire à suivre...

john_lenfr: Le problème n'est pas la récurrence de passage, mais que plusieurs joueurs peuvent passer quasi en même temps sous le capteur (2 émetteurs par exemple). ... Et en plus il ne faut pas que le programme soit en train de faire autre chose alors qu'un joueur passe sous le capteur au même moment, sinon son tour n'est pas pris en compte.

ton probleme n'est pas tant celui d'avoir un programme qui ferais autre chose (affichage LCD) , mais de gerer de la collision (superposition d'info IR) lorsqu'un flux IR est reçu par Irremote, la gestion de decodage est faite sous interruption, donc ton programme ne fera rien d'autre tant qu'il traitera du signal IR. par contre gerer de l'anticollision, ça c'est déjà plus compliqué. combien d'emetteurs possibles ? si le nombre n'est pas elevé peut etre voir à gerer de l'anticoliision en reflechissant à l'identifiant d'emetteur.

J’ai commencé un prototype pour tester ce week end:

A suivre …

ça fonctionne bien :grin:

https://www.youtube.com/watch?v=Hr12K1hpmRY

https://www.youtube.com/watch?v=oJ63BnOtILg

https://www.youtube.com/watch?v=R_0AgFiqPDw