Etape 7: Logiciel : le jeu sketch
Les différents modules dans le sketch :Programme d’installation :
Les éléments évidents sont configurés et initialisé : Serial monitor, GpsSerial pour le module GPS, le registre à décalage conduite Led, toutes les variables de jeu.
Au cours d’essais sur le terrain, le standard 1Hz GPS mise à jour de taux s’est avéré trop lent.
J’ai dû fouiller dans les notes d’application ST22 et maintenant envoyer un certain nombre de configurations binaires à la GPSmodule.
- Interface port série commence à 9600 bauds, puis 38400 baud rat est défini pour le module et l’interface Gps-Arduino
- Le taux de rafraîchissement GPS est porté à 8 Hz
- Le mode de navigation pédestre est réglé, adapter le filtrage interne du GPS
- Toutes les phrases inutiles de NMEA du GPS sont fermés, seulement GPBOD est conservé
À ma frustration, je n’étais pas en mesure d’afficher les messages GPS ACK et accusé de réception négatif, mais j’ai eu la preuve que mes messages sont wel reçu.
Bien qu’il soit possible, j’ai ne pas stocker les paramètres ci-dessus en permanence dans le GPS.
Manipulation de LED :
L’affichage led peut afficher plusieurs messages :
- Auto-test: voyants sont allumés, un par un, d’une manière lente, tandis que le module GPS tente d’obtenir un correctif.
- Recherche prochain waypoint : led correspondant avec le gisement relatif au point de cheminement est allumé
- waypoint trouvé OK: les leds exécuter 2 rapides mouvements de "vague mexicaine".
- NOK, waypoint, ne pas encore atteint : leds dites « non » en alternant les leds de-90 ° et de 90 °.
- Punished: série de 10 messages NOK rapides.
- Hourra, dernier point de cheminement trouvé & Game Over : série de vagues rapide mexicaines jusqu'à éteint.
Jeu de logique :
Au démarrage, l’auto-test apparaît, en attente d’une solution.
Lorsqu’un correctif est disponible, le mode de recherche est formée ; comme le joueur se déplace, le roulement pour le prochain waypoint est montré.
Après avoir appuyé sur le bouton OK, plusieurs situations sont possibles :
- la distance au point de cheminement est dans les limites et le dernier point de cheminement n’est pas atteint: OK s’affiche, le prochain waypoint est chargé et le mode de recherche initié
- la distance au point de cheminement est dans les limites et le dernier point de cheminement est atteint : Hourra est indiqué, le jeu est fini
- la distance est de nok et il s’agit de la première ou la deuxième erreur pour ce waypoint : après affichage NOK , la recherche se poursuit
- la distance est de nok pour la troisième fois : Punished apparaît, le waypoint précédent est chargé et le mode de recherche initié
Manipulation du GPS :
La plupart de l’interface pour le module GPS est géré par la bibliothèque de nmea.h
Trois sorties sont utilisées ici :
- position, gps.gprmc_course(), la direction du mouvement du joueur
- portant, gps.gprmc_course_to(latitude_Wp,longitude_Wp), la direction pour le waypoint
- distance, gps.gprmc_distance_to (latitude_Wp, longitude_Wp, MTR), la distance et le waypoint
Le gisement relatif, affiché à l’écran led, est calculée en soustrayant de sa position et mettre le résultat entre 0° et 180°.
Alors qu’une phrase NMEA est caractères décodés par le personnage de nmea.h, il ne doit pas être interrompu. à cet effet, cette action est incorporée dans un "while (! décodé)" boucle.
Manipulation de la mémoire :
Modules : getNextWaypoint, getPreviousWaypoint, entier et flotteur lire routines
getNextWaypoint calcule la prochaine forme de Waypoint adresse lien de waypoint actuel et retourne la latitude et la longitude du prochain waypoint. Il signale également la fin de la liste de waypoint lorsque atteint.
getPreviousWaypoint suit la chaîne de lien de waypoint, à partir du bas. Remarque que les waypoints en mémoire ne sont pas nécessairement consécutifs, comme le maître de jeu pourrait avoir supprimé ou inséré waypoints dans la liste.
Les routines de récupération pour les entiers et les flotteurs sont les mêmes que dans le croquis de menu.
Voir croquis ci-dessous.
