Capteurs et
machine à états.

• Percevoir l’environnement avec plusieurs capteurs et les combiner.
• Concevoir un comportement comme un graphe d’états et le coder proprement.
• Tester le comportement en simulation avant le vrai robot.
• Faire cohabiter sécurité, comportement et télémétrie sans bloquer.

Matériel : le robot de la séance 27, capteur ultrason sur servo, 2 ou 3 capteurs infrarouges TCRT5000, éventuellement 2 capteurs de contact (bumpers).

Un balayage complet prend 5 × 140 ms = 0,7 s : le robot « voit » chaque direction moins de 2 fois par seconde. Trop lent pour foncer, suffisant à 15 cm/s. La mesure time_pulse_us bloque jusqu’à 20 ms : acceptable dans un cycle de 50 ms, mais c’est le maximum. Trois capteurs ultrason fixes (gauche, centre, droite) sont plus réactifs ; un vrai lidar (séance 19) fait 360° à 10 Hz. Le maj() non bloquant à deux états est déjà une petite machine à états.

Ultrason : médiane des 3 dernières mesures par secteur (tue les échos perdus). Ligne : la normalisation ci-dessus, plus une moyenne sur 2 lectures. Bumper : anti-rebond 20 ms (séance 22). Ce qui sort des capteurs doit être propre avant que la machine à états ne le voie ; sinon elle change d’état sur du bruit.

Le réflexomètre (séance 22), le radar ci-dessus, Mission Mars (victoire/défaite/en cours). Les FSM sont partout : feux tricolores, distributeurs, protocoles réseau, analyseurs de texte, et le cœur des jeux vidéo. En prépa, les automates finis sont un chapitre d’informatique théorique : ce sont les mêmes objets, étudiés mathématiquement.

Chaque état a une action simple et une ou plusieurs sorties clairement définies. Les transitions globales (bumper, batterie) sont vérifiées avant l’état courant : elles ont priorité. Une transition « temps écoulé » évite les états sans fin. Un compteur (« 3 obstacles en 5 s ») détecte les boucles infinies de comportement. Dessinez le diagramme avant de coder : si vous ne pouvez pas le dessiner, vous ne pouvez pas le déboguer.

La classe ne connaît ni PWM ni broche : elle transforme une perception en commande. On la teste avec des assert comme n’importe quelle fonction (séance 08). Le même fichier tourne sur le PC pour les tests, dans le simulateur, et sur le Pico. C’est le principe de la séance 16 (Robot / Capteur / Moteur), poussé au comportement.

Distance parcourue, collisions, couverture : trois métriques pour comparer des comportements objectivement, sur des dizaines de mondes et de graines aléatoires, en quelques secondes. Le naïf se coince : son capteur frontal voit le mur, il tourne sur place, mais son corps (7 cm de rayon) frotte la boîte pendant la rotation et il reste bloqué — des centaines de cycles en collision, 9 cases explorées. La FSM recule d’abord, puis tourne : zéro collision. Remplacez RAYON = 7.0 par 0.0 (un robot ponctuel) : le naïf s’en sort très bien. La largeur du robot est ce que les if ne voient pas. Modifiez la FSM (durée de recul, angle de rotation, seuil) et mesurez : c’est ainsi qu’on règle un robot, pas en le regardant tourner sur la table. Le lancer de rayon est un lidar simulé rudimentaire. (Exécutez d’abord la cellule précédente : les cellules d’une même page partagent leurs définitions, comme dans un notebook.)

Rodney Brooks (MIT, 1986) : plutôt qu’une FSM unique, des couches indépendantes, chacune un comportement complet, la plus prioritaire qui « a quelque chose à dire » l’emporte. On ajoute un comportement sans toucher aux autres. Ses robots-insectes ont révolutionné la robotique en montrant qu’un comportement intelligent émerge de réflexes simples empilés. Les aspirateurs robots fonctionnent ainsi. FSM et couches se combinent : chaque couche peut contenir une petite FSM.

Perception (radar non bloquant, bumpers), décision (FSM testée), action (classe Robot avec rampe et odométrie), télémétrie (protocole des séances 20 et 26), commandes PC, cadence fixe, arrêt garanti par finally, démarrage à l’arrêt. Sur le PC : le tableau de bord de la séance 26 affiche l’état de la FSM et la trace odométrique en temps réel. Quand quelque chose ne va pas : le journal, puis le simulateur avec la même perception.

class SuiveurLigne:
    def __init__(self): self.etat = "SUIVRE"; self.derniere_pos = 0.0; self.t_perdu = None
    def decider(self, pos, valeurs, t):
        if pos is None:
            if self.etat == "SUIVRE":
                self.etat = "PERDU_GAUCHE" if self.derniere_pos < 0 else "PERDU_DROITE"; self.t_perdu = t
            if t - self.t_perdu > 3: self.etat = "ARRET"
        else:
            if all(v > 0.7 for v in valeurs): self.etat = "ARRET"          # croisement / ligne d'arrivée
            else: self.etat = "SUIVRE"; self.derniere_pos = pos
        if self.etat == "SUIVRE":   return 0.4, -0.8 * pos                  # ligne à droite (pos>0) → tourner à droite (w<0)
        if self.etat == "PERDU_GAUCHE":  return 0.0, 0.5
        if self.etat == "PERDU_DROITE":  return 0.0, -0.5
        return 0.0, 0.0

Le terme −0.8 × pos est un correcteur proportionnel ; à grande vitesse, le robot oscille autour de la ligne et finit par la perdre dans les virages. La séance 29 (PID) règle ce problème. Le signe de w dépend de votre convention (séance 27 : w > 0 tourne à gauche).

class Carte:
    def __init__(self, larg, haut, res=20):
        self.res = res; self.nx, self.ny = larg // res + 1, haut // res + 1
        self.libre = [[0] * self.nx for _ in range(self.ny)]; self.occ = [[0] * self.nx for _ in range(self.ny)]
    def observer(self, x, y, angle, d, portee=150):
        for r in range(0, int(d if d else portee), self.res // 2):
            cx, cy = int((x + r * math.cos(angle)) // self.res), int((y + r * math.sin(angle)) // self.res)
            if 0 <= cx < self.nx and 0 <= cy < self.ny: self.libre[cy][cx] += 1
        if d:
            cx, cy = int((x + d * math.cos(angle)) // self.res), int((y + d * math.sin(angle)) // self.res)
            if 0 <= cx < self.nx and 0 <= cy < self.ny: self.occ[cy][cx] += 3
    def etat(self, cx, cy):
        l, o = self.libre[cy][cx], self.occ[cy][cx]
        return "?" if l + o < 2 else ("#" if o > l else ".")

C’est la base du SLAM (cartographie et localisation simultanées) — sauf qu’ici la position vient de l’odométrie parfaite du simulateur ; sur le vrai robot, l’erreur d’odométrie (séance 27) brouille la carte, et il faut corriger la position avec la carte : c’est le vrai SLAM, un sujet de recherche jusqu’aux années 2010, aujourd’hui dans tous les aspirateurs.

import itertools
ETATS = ["EXPLORER", "RECULER", "TOURNER", "BLOQUE", "ARRET"]
PERCEPTIONS = list(itertools.product([10, 50, None], [True, False], [50, 5], ["gauche", "droite"]))   # devant, bumper, batterie, côté dégagé

def transition(etat, percep, depuis, obstacles):
    c = Comportement(); c.etat = etat; c.t_etat = 0.0; c.obstacles_recents = [0.0] * obstacles
    devant, bumper, batterie, cote = percep
    p = dict(devant=devant, bumper=bumper, batterie=batterie, cap=math.radians(90) if depuis > 1 else 0.0,
             gauche=80 if cote == "gauche" else 20, droite=20 if cote == "gauche" else 80)
    v, w = c.decider(p, depuis)
    return c.etat, v

graphe = {e: set() for e in ETATS}; violations = []
for e in ETATS:
    for p in PERCEPTIONS:
        for depuis in (0.1, 2.0):
            for obstacles in (0, 3):
                e2, v = transition(e, p, depuis, obstacles)
                graphe[e].add(e2)
                if p[1] and v > 0: violations.append((e, p, e2, v))
print({e: sorted(s) for e, s in graphe.items()})
print("violations bumper → v>0 :", violations[:3], "…" if len(violations) > 3 else "")

Vous trouverez que l’état TOURNER avec bumper pressé continue de pivoter (v = 0, w ≠ 0) — conforme —, mais qu’EXPLORER avec bumper pressé passe à RECULER dès le cycle courant : la propriété tient. Si elle ne tenait pas, le vérificateur donnerait le contre-exemple exact. Le model checking fait cela sur des millions d’états avec des outils (SPIN, TLA+, UPPAAL) et prouve des propriétés comme « jamais deux feux verts en même temps ». C’est une branche de l’informatique théorique enseignée en master, née des automates de prépa.