La semaine dernière : Atelier du 13 nov. 2019
C’était la journée de secours, celle qui était réservée en cas de difficultés. Elle tombe bien et va nous permettre d’avancer un peu plus. Ce sera une bonne journée.
Résumé de la semaine
J’ai bien avancé de mon côté avant cet atelier. En particulier, j’ai séparé la classe Pipes en deux qui héritent d’une classe abstraite.
Comme les comportements sont différents, il faut bien utiliser les 2 classes, suivant le comportement attendu :
- Le module
Controleutilise la classePipesControle; - Les autres modules doivent utiliser la classe
PipesModule.
J’ai ajouté un mécanisme d’enregistrement pour les modules auprès du contrôle qui fonctionne de la manière suivante.
Le contrôle se met en attente de l’enregistrement d’une liste de modules (précisée dans son constructeur). Chaque module doit transmettre une commande dans le tube du contrôle :
{ "source": nom du module, "verbe": "hello", "path": chemin du tube dans lequel le module assure la réception des commande }
A ce stade, les réponses ne sont pas mise en œuvre et donc le module n’a pas confirmation de son enregistrement.
Quand tous les modules attendus se sont enregistrés, le contrôle leur transmet la commande d’initialisation (voir les verbes après).
Init
Ce verbe doit être implémenté par chaque module et permet au contrôle de lui demander d’effectuer son initialisation. Il est transmis sous cette forme, sans paramètre supplémentaire :
{ "source": "control", "verbe": "init" }
Fin
Celui-ci indique au module qu’il doit s’arrêter proprement et libérer toutes ses ressources. Il n’est transmis par le contrôle que lorsque lui-même se termine. Il est de la forme :
{ "source": "control", "verbe": "fin" }
En séance
Nous nous sommes répartis en 2 groupes pour travailler sur le module de déplacement et sur le module de synthèse vocale.
L’équipe de la synthèse s’est inspirée du programme de démo utilisé lors de la séance de présentation et qui assurait la lecture de l’heure.
L’équipe a donc reprise et implémenté deux fonctions, assurant que le système se présente avec une phrase de bienvenue pendant l’initialisation, puis prononce une phrase passée en paramètre lors de la réception d’une commande “parler” :
{ "source": "control", "verbe": "parler", "phrase": phrase à prononcer }
De son côté, l’équipe assurant le déplacement à mis en place la communication avec l’Arduino en utilisant la librairie PySerial.
Nous avons aussi regardé la programmation de l’Arduino Nano depuis la Raspberry, puisqu’il est connecté en USB et donc visible depuis l’IDE Arduino utilisé localement.
TODO
Ben oui, il reste du travail sur ce robot. L’idéal reste toujours de la faire « bouger » pour la matinée de synthèse, c’est à dire lui faire parcourir un circuit pré-configuré et le faisant s’arrêter quand il rencontre un obstacle.
Pour cela il faut encore :
- Assurer la réception des ordres par la carte électronique (Arduino Nano), comme avancer, tourner, s’arrêter ou indiquer que pendant un déplacement on a rencontré un obstacle, être capable de reprendre le déplacement quand l’obstacle disparait ;
- Assurer la définition d’un circuit (dans le module de déplacement), soit par des points de passage dans un repère orthonormé, soit par des séquences d’ordres relatifs (avancer de 10m, tourner de 45° à droite, etc.).
- Configurer le module de contrôle pour qu’il organise les actions transmises aux modules, même de manière statique (annoncer son départ, faire le parcours, annoncer son arrivée, attendre un peu et recommencer, par exemple).