Tout simple un chemin en fil de fer assez rigide, d'environ 150 cm , composé de difficultés en le déformant en angle ou spire, autour duquel faire passer une boucle sans toucher le fil. Chaque contact obligeant à recommencer. c'est un jeu prévu pour une prochaine fête familiale où 8 équipes seront amenées à trouver chacune un des différents indices dans un genre d'escape game. Cela nécessitant donc au moins 11 pistes sonores différentes à lire sur un Df playerMP3-Tf-16. (départ,faute,succes et les 8 indices)
Le code suivant fonctionne parfaitement, mais comporte une anomalie même avec détection sur front montant, de devoir bizaremment parfois rester en appui sur le bouton pour activer la lecture d'un morceau sélectionné. Ce qui n'est pas l'idéal, sachant que le court circuit provoqué par les fils s'entretouchant sera très furtif.
un appui long déclenche quant à lui quasi systématiquement, c'est pourquoi j'ai tenté passé par la mémorisation temporaire d'une variable. Ce qui ne fonctionne pas mieux.
J'ai pensé que peut être en utilisant softwareSerial, cela implique conflit avec la réactivité des boutons ou retardement au sein de la librairie du Df player.
Auriez-vous une autre solution à cette problématique ? Merci.`
#include <simpleBouton.h>
#include "SoftwareSerial.h"
#include "DFRobotDFPlayerMini.h"
simpleBouton faute = 5;
simpleBouton End = 4;
// contact entre spire et raquette boucle ( jeu inspiré de destination X sur M6)
bool memofaute = false; // si contact entre début et fin,faute déclenche alerte sonore indiquant devoir recommencer
bool memoEnd = false; // si contact fin sans avoir touché la boucle,End déclenche un message sonore indiquant avoir réussi
// un contact départ est prévu ainsi que de complémenter le code
static const uint8_t PIN_MP3_TX = 10;
static const uint8_t PIN_MP3_RX = 11;
SoftwareSerial softwareSerial(PIN_MP3_RX, PIN_MP3_TX);
DFRobotDFPlayerMini player;
void setup() {
pinMode(6, INPUT_PULLUP);
pinMode(5, INPUT_PULLUP);
pinMode(4, INPUT_PULLUP);
Serial.begin(9600);
softwareSerial.begin(9600);
}
void loop()
{ faute.actualiser();
End.actualiser();
if (player.begin(softwareSerial, true, false))
player.volume(10);
if (faute.vientDEtreEnfonce()) // bouton pour test, ultérieurement remplacé par contact entre la spire et la boucle de parcours
memofaute = true;
if (memofaute)
{ player.play(1); // tentative pour simuler appui long avec annulation temporisée de la variable
delay(200);
memofaute = false;
}
if (End.vientDEtreEnfonce()) // pas d'amélioration sans passer par une variable
player.play(4);
}
Autant je comprends que l'on veuille utiliser une librairie comme simpleBouton pour lire des boutons autant je ne comprends pas son usage pour lire un contact fugitif.
Pourquoi ne pas faire tout simplement un digitalRead(faute)
Pour créer une instance de simpleBouton il faut avant le setup() écrire le code suivant pour votre programme :
simpleBouton faute(5); //Cablage : pin---BP---GND
simpleBouton end(4); //Cablage : pin---BP---GND
dans la loop() pour détecter l'appui sur le bouton ou votre cas (jeu avec fil) :
faute.actualiser();
end.actualiser();
if (faute) {
code ...
}
if (end) {
code ...
}
—> A enlever…
Pour le reste je n'ai pas le temps de regarder
Bonne soirée.
PS : .vientDEtreEnfonce() détecte l'appui également .vientDEtreRelache() détecte le relâchement.
Utilisez en début de loop() comme vous l'avez fait .actualiser();
Merci pour vos réponses à tous trois. j'ai fait le test avec digitalRead également, ça n'a pas solutionné mon délai de réaction de départ lecture.
Mon code n'est pas parfait pour des puristes, mais il semble que je ne me suis pas bien fait comprendre. Effectivement, la prise en compte départ et faute sera à mixer avec le fait de finir sans toucher, une gaine d'isolation revêtue de papier alu disposés sur le départ et fin, reliés à l'arduino indépendamment en feront office.
Mon souci , bien qu'amélioré en usant de fichier Wave en place de MP3, dont la lecture démarre plus rapidement, c'est qu' un contact ne permet pas systématiquement un démarrage lecture dans les même délais.
Tantôt un titre démarre aussitôt le contact établi, tantôt, cela nécessite un appui plus long, donc non furtif comme ce sera quasi toujours le cas.
Un appui long, environ 500ms à 1 sec, est efficace à 100%.
D'où, comment faire d'un appui furtif, une commande nécessitant un appui long?
A moins que tout cela soit lié aux spécifités de ce module MP3-Tf-16P-V3
Cette partie devrait devrait se trouver dans le setup(). Sans oublier un else pour indiquer un éventuel problème d'initialisation.
Ici, tu réinitialises l'interface avec le lecteur à chaque itération de loop(). Cela doit prendre du temps.
Le DFPlayer répond à des commandes envoyées sur la voie série à 9600 bauds, soit environ 1ms par caractère et ensuite il lui faut un peu de temps pour analyser la commande reçue, accéder à la carte SD et lancer le MP3. Il faut donc bien compter 20 à 50ms pour que le son démarre . S’il est en train de jouer c’est sans doute encore plus lent.
Vous devriez envisager un buzzer piezo et des LED par exemple - ce serait quasi instantané.
La réponse de JML est a approfondir par différents tests que je vais tenter aujourd'hui, à savoir si un titre est en cours de lecture , l'activation d'un autre prend davantage de temps, ce dernier nécessaire à l'arrêt de l'antécédant. C'est peut être mon cas, et c'est tout à fait compréhensible.
Pour des leds ou affichage LCD en lieu de sons, c'est déjà fait pour les 6 autres jeux prévus, je souhaitais diversifier l'approche des différents jeux et en même temps me faire plaisir en bidouillant le tout.
Pour le jeu du "chemin de fer" avec MP3 je serai tenté quand même de mettre un buzzer et un bandeau LED en plus du lecteur de MP3
le code serait structuré ainsi :
SETUP:
- si la boucle ne touche pas le départ
➜ MP3 qui dit "Allez au départ et touchez le fil". leds rouges,
➜ Attente de la fin du MP3
➜ Attente que l'utilisateur touche le début du chemin de fer pour montrer qu'il est au départ.
- MP3 qui dit "PRET, Bonne chance". petit buzz distinctif,
➜ attente de la fin du MP3 et passage des LEDs à vert + petit buzz distinctif
LOOP
- si on touche le chemin de fer
➜ MP3 qui dit "Perdu — retournez au départ et touchez le fil".
➜ allumer rouge, buzz,
➜ attente de la fin du MP3 et que l'utilisateur touche le début du chemin de fer pour montrer qu'il est au départ.
➜ petit buzz distinctif, MP3 qui dit "PRET, Bonne chance".
➜ attente de la fin du MP3 et passage des LEDs à vert + petit buzz distinctif
- Si on touche le fil d'arrivée
➜ MP3 qui dit "Bravo vous avez gagné — Pour rejouer retournez au départ et touchez le fil".
➜ petit buzz distinctif, faire clignoter le Badeau
➜ attente de la fin du MP3 et que l'utilisateur touche le début du chemin de fer pour montrer qu'il est au départ.
➜ MP3 qui dit "PRET, Bonne chance". petit buzz distinctif
➜ attente de la fin du MP3 et passage des LEDs à vert + petit buzz distinctif
le buzz et l'animation des Leds donne un feedback instantané au joueur et on n'a pas l'impression que le MP3 est en retard. L'écriture de la commande envoyée au MP3 peut être non bloquante, donc on peut l'envoyer avant de faire le buzz et l'animation du bandeau, comme ça le temps du buzz et du signal visuel le lecteur MP3 aura eu le temps de décoder.
Il y a de nombreux bouts qui se répètent et la programmation par machine à états (cf mon tuto éventuellement) est bien adaptée pour cela.
fdufnews et JML , vos suggestions sont excellentes et très pertinentes, merci.
Concernant le déplacement du paramétrage player proposé par fdufnews dans le setup, ça a purement résolu le problème de réaction à l'appui bouton, elle est intantanée. Mon soucis initial semble résolu, à confirmer avec le dévellopement complet du code final si je n'y rajoute pas de conflit!
L'idée du buzzer de JML est séduisante, et pourquoi pas aussi des leds en plus, en cas notamment de défaillance du système player SD, ce qui est toujours possible, permettant au jeu de rester actif dans ce cas, juste en découplant le HP par switch ou prise débranchée. Le son étant là pour dynamiser ce jeu en perturbant quelque peu l'attention et l'adresse du joueur, petite difficulté supplémentaire.