Robot per labirinto di linee con memoria del percorso LSRB

Un robot seguilinea segue. Un risolutore di labirinto di linee decide. È tutto il salto che compie questo progetto, ed è più grande di quanto sembri: il robot smette di essere un ciclo di controllo con ruote e diventa qualcosa che esplora un ambiente mai visto, ricorda ciò che ha trovato e agisce su quella memoria.

Il trucco è che nulla di tutto questo sostituisce il robot seguilinea: si trova sopra un robot seguilinea. Sotto, lo stesso array a riflessione e lo stesso ciclo PID mantengono il robot centrato sul nastro, senza sapere nulla di labirinti. Sopra, uno strato decisionale sottile osserva i momenti in cui la linea si ramifica, classifica il tipo di bivo, sceglie una direzione e scrive un carattere. Questa separazione rende gestibile il progetto ed è la stessa divisione a due strati che i robot reali usano ovunque.

Quindi l’ordine di costruzione conta più del solito. Ottieni prima un semplice seguimento della linea davvero stabile—regolato nel simulatore, poi su un ovale grande di nastro reale—e solo dopo aggiungi i bivi. Salta questa disciplina e ogni problema meccanico, ogni deriva di calibrazione, ogni ruota disallineata di 2 mm si presenterà travestito da bug di risoluzione del labirinto.

Percorri l’albero tecnologico qui sotto dall’alto verso il basso. Ogni nodo si sblocca quando i suoi prerequisiti sono completi e i progressi vengono salvati su questo dispositivo, così puoi costruire il robot durante un fine settimana senza perdere il punto.

Lista dei componenti

Totale: circa $35–45. L’array a 8 canali è l’unico componente su cui non conviene risparmiare, e il motivo è preciso: un robot rileva un ramo a sinistra notando che i sensori più esterni a sinistra sono diventati scuri mentre il centro è ancora sulla linea. Un array appena più largo del nastro non può fisicamente vederlo, quindi il rilevamento dei bivi diventa una supposizione, per quanto buono sia il codice.

Perché l’array deve essere più largo della linea

   left branch                    array (8 channels, ~60 mm wide)
   ────────────────┐          [ x x x . . . . . ]   outer left dark -> a branch
                   │
   ════════════════╪═══════   [ . . . x x . . . ]   centre still on the line
                   │

Regola pratica: l’array dovrebbe essere almeno tre volte la larghezza del nastro. Per un nastro da 19 mm sono circa 60 mm, che è esattamente ciò che ottieni con un array a 8 canali e passo 8 mm. Più stretto e il robot non potrà distinguere «la linea ha curvato bruscamente» da «la linea si è ramificata», che è la decisione centrale su cui poggia tutto il progetto.

Costruiscilo in traguardi

L’ordine di costruzione conta più che in qualsiasi altro progetto di questo sito. Un risolutore di labirinto è un robot seguilinea con uno strato decisionale, e ogni guasto meccanico o di calibrazione del seguilinea riappare travestito da bug di risoluzione del labirinto.

Il traguardo 1 non è negoziabile. «Segue per lo più la linea» diventa «ogni tanto inventa un bivo», e passerai una serata a fare debug della semplificazione del percorso per un guasto che in realtà è una ruota disallineata di 2 mm.

Il traguardo 2 è quello che le persone saltano. Un risolutore esegue centinaia di svolte per ogni corsa, e una svolta che è sempre 5° corta si accumula finché il robot esce completamente dalla linea. È esattamente qui che compare il gioco del riduttore: un errore che cambia segno con la direzione è meccanico, non un problema di regolazione.

La divisione a due strati, nel codice

Vale la pena vedere esplicitamente la separazione che rende gestibile questo progetto:

             ┌─────────────────────────────────────┐
   decision  │  classify junction -> choose turn   │   runs only at junctions
     layer   │  record a character -> simplify     │   knows nothing about PWM
             └──────────────────┬──────────────────┘
                                │ "turn left" / "keep going"
             ┌──────────────────▼──────────────────┐
   following │  read array -> position -> PID      │   runs every loop, ~200 Hz
     layer   │  -> left and right wheel speeds     │   knows nothing about mazes
             └─────────────────────────────────────┘

Lo strato inferiore non impara mai che cos’è un labirinto. Lo strato superiore non tocca mai un motore. Quando qualcosa va storto, quel confine ti dice in quale metà cercare e, se non riesci a dire in quale metà vive un bug, gli strati non sono separati correttamente.

Che aspetto ha un buon risultato

L’accuratezza dei bivi è davvero tutto o nulla, e questo sorprende le persone. Un bivo mal letto corrompe la stringa registrata, il semplificatore produce quindi un percorso dall’aspetto valido ma sbagliato e la corsa di ritorno entra con sicurezza in un muro. Non esiste un credito parziale: per questo l’esplorazione procede lentamente e nella corsa di ritorno recuperi il tempo.

Risoluzione dei problemi

Da dove proseguire

Aggiungi gli encoder e gira in base alla distanza, non al tempo. Le svolte a tempo sono la principale fonte di inaffidabilità di un primo risolutore di labirinto, perché il tempo necessario cambia con la tensione della batteria e con la superficie. Le svolte basate su encoder no.

Passa a un labirinto con muri, il micromouse, che sostituisce il nastro con muri e la regola LSRB con flood fill. È il passo genuinamente più grande: LSRB è un’euristica che segue le pareti e trova un percorso, mentre flood fill calcola quello più breve e riorganizza il piano quando scopre nuovi muri.

Ottimizza la corsa di ritorno. Una volta noto il percorso non restano decisioni da prendere, quindi il robot può accelerare sui rettilinei e rallentare solo per le curve. Un profilo di movimento sul percorso noto è la sede dei drammatici miglioramenti di tempo, spesso dimezzando la corsa di ritorno.