Costruisci un robot ROS 2 che vede e raggiunge un marcatore

Cosa stai costruendo

Un robot posizionato in un punto qualsiasi di una stanza, che ruota finché non trova un marcatore stampato su una parete e lo raggiunge — fermandosi a mezzo metro di distanza, inquadrato rispetto alla faccia del marcatore anziché soltanto vicino.

Ogni altra costruzione di questo sito esegue un programma su un microcontrollore. Questa è un computer con ruote, il che cambia il tema del progetto. Le parti difficili non sono più temporizzazione e cablaggio; sono sapere dove si trovano le cose rispetto alle altre e mantenere coerenti tra loro più componenti software mentre sono tutti in esecuzione.

Perché questo robot ha bisogno di un computer

Un Arduino non può farlo, e il motivo merita di essere precisato. Non è la velocità bruta — è che un fotogramma della camera occupa un quarto di megabyte, il rilevamento ArUco richiede algebra lineare in virgola mobile e tutto deve avvenire mentre alle ruote vengono ancora comandati segnali a 50 Hz. È un lavoro per un sistema operativo con memoria e pianificazione reali.

In cambio di questo sistema Linux ottieni la possibilità di guardare dentro un robot in funzione. Ogni messaggio tra ogni parte è un topic a cui puoi iscriverti da un laptop. Quando il robot passa accanto al marcatore invece di raggiungerlo, non aggiungi istruzioni di stampa e riflashi: usi ros2 topic echo sulla posa e la osservi sbagliata in tempo reale.

La forma del grafo dei nodi

Cinque responsabilità, una per nodo:

Le interfacce sono ciò che rende utile strutturare il sistema in questo modo. Il controllore non tocca mai direttamente una camera o un motore: consuma una trasformazione e produce una Twist. Questo significa che puoi guidare lo stesso robot con il telecontrollo da tastiera, provare il controllore mediante una trasformazione finta senza alcun hardware e, in seguito, inserire uno stack di navigazione che pubblica lo stesso identico topic.

Leggi nodi, topic, servizi e azioni prima di disegnare la tua versione di quella tabella. L’errore più comune in questa fase è fare del controllore di aggancio un servizio: è un obiettivo di lunga durata che devi poter annullare, ed è esattamente a questo che servono le azioni.

Elenco dei componenti

Questo è il robot a due cervelli e l’elenco dei componenti lo riflette: un computer per la percezione e un microcontrollore per le cose che un computer non riesce a eseguire in modo affidabile.

Totale: circa $145–175. È di gran lunga il progetto più costoso del sito e la maggior parte del costo è il Pi.

L’alimentazione è il punto in cui questi robot falliscono, e il fallimento è costoso. Un brownout durante la scrittura su una scheda SD corrompe l’intera immagine di sistema. Usa un regolatore a commutazione con una portata ben superiore al consumo del Pi, non condividere mai la linea di alimentazione con i motori e controlla vcgencmd get_throttled: qualsiasi valore diverso da zero indica un’alimentazione insufficiente e una scheda corrotta in arrivo.

Misura i marcatori stampati. La soluzione della posa ArUco scala direttamente rispetto alla dimensione del marcatore che dichiari. Un marcatore stampato al 95% dalla funzione «adatta alla pagina» della stampante produce posi sbagliate del 5% a ogni distanza, senza che nulla nella catena di elaborazione te lo segnali.

Ordine di costruzione

1 — Fai funzionare ROS 2 e dimostra che la rete funziona. Segui installazione di ROS 2 su un Raspberry Pi. Non andare avanti finché ros2 topic echo sul laptop non mostra un topic pubblicato dal robot. La scoperta tramite Wi-Fi è la causa più probabile di una serata sprecata e vuoi che accada adesso anziché mentre esegui il debug della visione.

2 — Fai in modo che le ruote obbediscano a una Twist. Collega l’Arduino, gli encoder e il TB6612FNG, e costruisci il ponte cmd_vel. Traguardo: il telecontrollo da tastiera sul laptop guida il robot reale. Calibra qui la distanza tra le ruote — tutto ciò che segue la eredita.

3 — Calibra la camera. Correttamente, con un bersaglio reale, seguendo calibrazione della camera e posa ArUco. Una camera non calibrata produce pose che sembrano plausibili ma sono sbagliate di decine di percento ai bordi del fotogramma, il peggior modo di guasto disponibile.

4 — Pubblica il marcatore come trasformazione. Non come messaggio personalizzato con dentro una x e una y. La pubblicazione di camera_link → marker_7 in TF2 permette al controllore di chiedere «dove si trova il marcatore, in base_link?», e la risposta tiene conto esattamente di come è montata la camera, incluso il fatto che è inclinata, cosa che è.

5 — Avanza verso il marcatore. Un controllore proporzionale sull’angolo di puntamento: ruota verso di esso, avanza e fermati alla distanza prevista. Funziona e arriva a un angolo, che è il punto del passo successivo.

6 — Avvicinati lungo la normale. Invece di sterzare verso il marcatore, calcola un punto di passaggio a una distanza prefissata dalla faccia del marcatore lungo la sua normale, recati lì e solo dopo avanza in linea retta. Questa è la differenza tra raggiungere l’aggancio e agganciarsi. È anche il punto in cui l’orientamento del marcatore, la parte della posa di cui non avevi bisogno fino ad ora, inizia a contare e in cui incontrerai l’ambiguità della posa.

7 — Racchiudilo in una macchina a stati. Ricerca, avvicinamento, allineamento, finale, completamento, più le transizioni in uscita da ciascuno quando il marcatore viene perso. Le macchine a stati finiti per il comportamento dei robot descrive la struttura; lo specifico aspetto di cui questo robot ha bisogno è un timeout per marcatore perso che torni alla ricerca anziché continuare dall’ultima posa nota.

Note hardware che contano

Monta la camera rigidamente, e misura il montaggio. Ogni posa calcolata dal robot è relativa alla camera e TF2 la trasforma in una posa relativa al robot mediante la trasformazione che tu dichiari da base_link a camera_link. Una camera su una staffa flessibile rende quella trasformazione dichiarata una menzogna che varia con l’accelerazione.

Inclina la camera verso il basso, e dichiaralo. Una camera puntata verso l’orizzonte perde il marcatore proprio quando il robot si avvicina. Dieci o quindici gradi verso il basso lo mantengono nell’inquadratura durante l’avvicinamento finale, e questa inclinazione va nella trasformazione statica, non in un fattore correttivo nel controllore.

Misura il marcatore con un calibro. La scala della posa è direttamente proporzionale alla dimensione del marcatore che comunichi al risolutore. Stampare al 96% perché la stampante ha adattato la scala rende ogni distanza sbagliata del 4%, in modo silenzioso e coerente.

Alimenta il Pi separatamente dai motori. Un motore in stallo abbassa la tensione di alimentazione e, dove un Arduino si riavvierebbe senza conseguenze, un Pi corrompe il proprio file system. Usa un regolatore separato oppure un pacco batteria separato: non è il posto in cui risparmiare un componente.

Tieni il nastro della camera lontano dai fili dei motori. È un collegamento ad alta velocità non schermato. Il rumore dei motori che si accoppia al nastro si manifesta come fotogrammi corrotti, che appaiono come rilevamenti che lampeggiano senza una ragione visibile.

Come appare un risultato buono

Due righe racchiudono la lezione dell’intero progetto.

La risoluzione non è gratuita e spesso una risoluzione maggiore è peggiore. Passare da 640×480 a 1080p costa 4–6× la potenza di elaborazione per circa 1.7× la portata di rilevamento. A meno che tu non abbia bisogno specifico di vedere un marcatore più lontano, il fotogramma più piccolo fornisce una risposta più rapida e aggiornata, e l’aggiornamento conta più della precisione in un ciclo di controllo.

La riga sulla latenza spiega l’esistenza della divisione a due cervelli. A 0.3 m/s, 100 ms di latenza visiva corrispondono a 3 cm di percorso; con una rotazione a 90°/s, a 9° di rotazione. Ogni misurazione visiva descrive dove il robot era. Chiudere direttamente su di essa un ciclo rapido lo farà oscillare. La struttura funzionante è quella usata da questo robot: l’Arduino esegue il ciclo rapido sugli encoder e la visione lo corregge lentamente, esattamente come quando si fondono GPS e odometria sul rover con punti di passaggio, e per la stessa identica ragione.

Rolling shutter, se il robot si muove mentre guarda

I moduli camera standard del Pi hanno un rolling shutter: le righe vengono esposte una dopo l’altra, quindi la parte superiore di un fotogramma viene catturata qualche millisecondo prima di quella inferiore. Da fermo, questo non è visibile. Con una rotazione a 90°/s, i quattro angoli di un marcatore ArUco sono stati catturati in quattro diverse orientazioni del robot, e la posa risolta da essi è sbagliata in un modo che la calibrazione non può correggere.

Se il robot deve eseguire la visione mentre si muove, serve il modulo Global Shutter. Se può permettersi di fermarsi, guardare e poi muoversi, il modulo più economico va benissimo, e fermarsi per guardare è una scelta progettuale legittima, non una soluzione provvisoria.

Quando va storto

Vale la pena notare la distribuzione in quella tabella prima di iniziare: quasi nulla riguarda la visione artificiale. Riguarda rete, sistemi di riferimento, unità e controllo, che è ciò che costruire un robot ROS 2 insegna davvero e il motivo per cui il percorso sui fondamenti di ROS 2 dedica il proprio tempo agli schemi di comunicazione e ai sistemi di riferimento anziché a OpenCV.

Se questo è un passo troppo avanti, il micromouse insegna mappatura e pianificazione su un microcontrollore senza Linux, mentre il robot controllato dal telefono copre la metà «i comandi arrivano tramite una rete» di questo problema con una frazione dei componenti.