Après avoir corrigé un problème de détection sur le capteur infra-rouge droit (ArduinoCar ne faisait que des détections à gauche), j'ai re-téléchargé le programme sur Arduino.
Malgré cette correction ma voiture persiste à croire qu'elle a des obstacles devant elle et forcément passe son temps en marche arrière.
C'est ennuyant... encore plus à cause d'un défaut de conception majeur qui provoque une décharge rapide de mes accus.
Il est donc difficile de débugger mon programme longtemps... encore plus parce que la voiture prend le large... difficile à suivre avec le cable USB qui lui est pourtant nécessaire pour voir les messages de Debug.
J'ai donc décidé de corriger ce défaut de conception afin de m'aider a débugger mes problèmes.
Erreur de conception
L'erreur de conception est la suivante: "je n'ai pas de bouton start/stop".
En effet, le programme démarre directement dès la mise sous tension d'Arduino (pour une durée de 60 sec).
A la fin du programme, si je veux recommencer, il me faut appuyer sur le bouton "reset" d'Arduino.
Mais en quoi est-ce une erreur de conception?
- Parce qu'il ne faut pas oublier de mettre le circuit de puissance sous tension... sinon, c'est l'alimentation d'Arduino qui se décharge dans le circuit de puissance.
- Dès que je branche le cable USB pour faire du debuging, Arduino est mis sous tension et le programme démarre immédiatement.
En plus de m'imposer la mise sous tension du circuit de puissance (sinon c'est le régulateur d'Arduino qui alimente l'étage de puissance... à éviter donc!), je peux difficilement placer ArduinoCar dans certaines conditions initiales.
C'est un problème ergonomique du point de vue de la mise au point/Debugging.
Il n'est pas facile de faire le monitoring du programme (via le port série) lorsque l'étage des moteurs (avancer/reculer) est alimenté.
Imaginez-vous courir avec votre pc portable derrière votre véhicule entrain de circuler dans le salon au bout du câble USB. Difficile de lire les messages de Log qui passent à l'écran!
Amélioration de la conception
Pin 7: Marche/Arret - Bouton Pull Down
Je vais donc ajouter un bouton marche/arrêt (pull-down) pour commander le démarrage , l'arrêt et le redémarrage du programme.
Une fois le bouton pressé, la Led de contôle (voir plus loin) s'allumera (ou s'éteindra selon l'état), le programme démarre 3 secondes plus tard.
Pin 8: Debug Start/Stop - Bouton Pull Down
Bouton qui va activer ou désactiver le mode de debug.
En mode débug, les fonctions marche et arret ne commandent plus les pins de sorties des moteurs de propulsion. Autrement dit, la voiture ni n'avancera, ni ne reculera.
Cela pourrait être pratique pour faire du monitoring avec un PC.
En sortant du mode debug, le programme s'arrête (état asEnd).
Pin 9: Led de contrôle
Indique l'état du programme Arduino.
- Éteinte: Véhicule en attente de mise en marche.
- Allumée continu: Programme en court de démarrage (1 sec) ou en cours d'exécution (pendant 60 sec)
- Allumée clignotante: idem allumage continu mais en mode Debuging (pas de commande effective de la propulsion avant/arrière, juste une commande logique).
Voici le complément de montage aux précédents schéma déjà publiés.
 |
| Ajout des boutons start/stop, debug/no-debug et de la led de contrôle. |
 |
| Etage de puissance (voir cet article, mais aussi celui-ci) |
 |
| Des yeux pour ArduinoCar (voir cet article) |
 |
| Bornier moteurs (voir cet article) |
Nouveaux états
Il faudra également compléter la liste des états affichés dans le précédent article "Premier essai avec les détecteur infrarouge".
Il faut en effet tenir compte des conditions de démarrage et d'arrêt comme par exemple attendre que l'utilisateur presse le bouton "start" :-) .
Le nouveau diagramme d'état est disponible un peu plus loin.
Modification d'état existant:
L'état asInitialized a été modifié et ne correspond plus à la description faite dans l'article "Premier essai avec les detecteur infrarouge".
asInitialized:
La machine à état fini reste dans l'état asInitialized jusqu'au moment ou le bouton start/stop est pressé.
Il passe ensuite dans l'état asWaitToGo.
Nouveaux états:
En plus des états décrits dans les précédents articles (et toujours utilisés), la machine à état fini se voit agrémentée de nouveaux états pour supporter les nouvelles fonctionnalités.
asWaitToGo:
Etat intermédiaire destiné à installer un temps de pause de deux secondes entre le moment ou l'utilisateur démarre le programme (utilisateur presse le bouton start depuis l'état asInitialized) et le démarrage effectif du programme (mise en mouvement du véhicule correspondant à l'état asMove).
asWaitToGo attends deux secondes et passe automatiquement à l'état asMove.
asToggleDebug:
Etat atteignable uniquement depuis asInitialized (donc aussi longtemps que le bouton start n'est pas pressé).
Sa seule action est d'inverser la variable debugState pour ensuite revenir à l'état asInitialized.
Avant de retourner à l'état asInitialized, le programme prend le contrôle de la LED pour indiquer, sans équivoque possible, l'état de la variable debugState (voir diagramme ci-dessous)
asToggleDebugOnRunning:
Tout comme pour asToggleDebug, la seule action de l'état est d'inverser la variable debugState et de prendre le contrôle de la LED pour indiquer, sans équivoque possible, l'état de la variable debugState (voir diagramme ci-dessous).
Seulement, asToggleDebugOnRunning est atteignable uniquement depuis les états asWaitToGo (avant que le programme ne démarre réellement) ou asMove (en attente de détection d'obstacle pendant la marche du véhicule).
Note: Il n'est donc pas possible d'activer le mode Debug pendant que le véhicule est en phase d'évitement.
Ensuite le programme retourner à l'état asEnd (donc arrêt moteur) avant transition vers asInitialized (ce qui revient à une pseudo initialization et un redémarrage du programme dès que l'utilisateur presse le bouton start).
Le nouveau diagramme d'états:
Vous constaterez sans mal que la machine à état fini est sensiblement plus complexe que la précédente version.
 |
| Cliquer pour agrandir |
Une nouvelle version logiciel
Cette nouvelle version logiciel inclus les modifications nécessaire à l'intégration des améliorations de conception.
Les classes PushButton et MonoLed (voir article précédent "Inclusion des librairies LedTools et ButtonTools") sont respectivement utilisées pour pour détecter la pression des boutons et faire clignoter la Led (lorsque cela s'applique) de façon non bloquante.
Le code contient également la correction concernant la détection infra-rouge défaillante à droite...
Par contre, la correction du comportement anormal fera, lui, l'objet d'un autre article.
Code Source: a venir
