Fondamenti di ROS 2: nodi, frame e visione robotica
Puoi strutturare un robot come nodi ROS 2, scegliere correttamente tra topic, servizi e azioni e collocare le osservazioni di una telecamera nell'albero dei frame del robot.
Tutto il resto di questo sito gira su un microcontrollore: un programma, un ciclo, controllo totale. ROS 2 è il sistema a cui passi quando un robot supera questi limiti, quando ha una telecamera, un pianificatore e uno stack di driver che devono funzionare contemporaneamente, scritti da persone diverse e riavviabili indipendentemente.
Il prezzo è un insieme di nuove idee. La prima è che un robot ROS 2 non è un programma, ma un grafo di nodi che comunica. Gran parte della confusione iniziale deriva dalla scelta sbagliata tra i quattro modi di comunicare, quindi da qui parte il percorso: topic per i flussi, servizi per le richieste rapide e azioni per i lavori lunghi che potresti dover annullare.
Poi c’è TF2, la parte che sconfitta silenziosamente le persone. Un robot è un albero di frame di coordinate: la base, le ruote e ogni sensore. Quasi ogni bug reale è una trasformazione mancante, obsoleta o collegata al genitore sbagliato. Una volta che i frame hanno senso, una telecamera calibrata diventa semplicemente un altro nodo che pubblica una posa in quell’albero: è così che la visione si collega al resto del robot.
Prima di iniziare
Devi essere a tuo agio con la riga di comando Linux e saper leggere Python o C++. Un Raspberry Pi è di solito il bersaglio, ma tutto ciò che precede i nodi hardware funziona su un portatile. Prevedi che la sola configurazione richieda una serata: ROS 2 è un sistema distribuito e si comporta come tale dal primo comando.
Che cosa saprai fare
- Scegliere correttamente tra topic, servizio e azione, invece di trasformare tutto in topic e scoprirne in seguito i limiti.
- Costruire un albero di frame TF2 che trasformi un punto dal frame di un sensore a quello del robot e eseguire il debug quando una trasformazione manca.
- Calibrare una telecamera, ottenere la posa di un marcatore e comprendere a cosa sono relativi i valori.
- Convertire un twist
cmd_velnelle velocità delle ruote sinistra e destra, con saturazione che preserva l’arco comandato.
Dove le persone si bloccano
I nodi non si vedono. L’individuazione in ROS 2 è automatica finché non lo è più. Due
macchine con valori diversi di ROS_DOMAIN_ID sono invisibili l’una all’altra e il Wi-Fi che blocca
il multicast interrompe del tutto l’individuazione mentre ogni nodo segnala perfettamente il proprio stato.
QoS non corrispondenti. Un publisher che offre best-effort e un subscriber che richiede reliable non si collegheranno mai e, purtroppo, nessuno dei due registra un errore. Il topic trasporta semplicemente nulla. I dati dei sensori sono la causa usuale, perché i driver dei sensori usano spesso best-effort per impostazione predefinita.
Dimenticare di attivare l’ambiente dello workspace. Un nuovo terminale non conosce i tuoi pacchetti
finché non lo attivi, quindi ros2 run segnala come mancante un pacchetto che esiste.
Un frame con due genitori. TF2 è un albero. Pubblicare lo stesso frame figlio da due sorgenti gli assegna due genitori e le ricerche iniziano a fallire in modo intermittente a seconda dei tempi: uno dei bug ROS più difficili da individuare, perché funziona quasi sempre.
Marche temporali e ID dei frame vuoti. Un messaggio il cui header non ha frame_id non può essere
trasformato e uno la cui marca temporale è zero non si allineerà a nulla. Entrambi superano senza
lamentarsi il controllo dei tipi e falliscono solo quando qualcosa tenta di usarli insieme.
Che cosa serve
| Componente | Perché serve a questo percorso | Note |
|---|---|---|
| Una riga di comando Linux che padroneggi | ROS 2 è un sistema pensato prima per Linux e gli strumenti danno per scontato questo ambiente | Ubuntu corrisponde ai binari ufficiali; qualsiasi altra scelta implica compilare |
| Python o C++ | Il codice dei nodi si scrive in uno dei due | Python si impara più in fretta; C++ si usa per i nodi critici per le prestazioni |
| Una macchina con uno schermo vero | Il debug di un sistema distribuito via SSH è inutilmente doloroso | Un portatile è un bersaglio di apprendimento migliore di un Pi senza schermo |
| Un Raspberry Pi (solo per i nodi hardware) | Serve solo quando il robot trasporta il proprio computer | Pi 4 o superiore; un Pi Zero deluderà |
| Una telecamera (solo per il nodo di visione) | L’ultimo nodo del percorso | Un modulo Pi Camera o qualsiasi webcam UVC |
| Una serata per la configurazione | Non è uno scherzo: fa parte del percorso | L’installazione è davvero il primo passo difficile |
Perché il percorso segue quest’ordine
I modelli di comunicazione vengono prima perché scegliere male costa caro in seguito. I quattro modi con cui comunicano i nodi ROS 2 non sono interscambiabili e l’errore tipico di chi inizia è trasformare tutto in topic, per scoprire trecento righe dopo che servivano annullamento e avanzamento e che stai reimplementando a mano le azioni. Dieci minuti per scegliere tra topic, servizio e azione evitano di riscrivere tutto.
TF2 viene secondo perché è la parte che sconfitta silenziosamente le persone. Quando più nodi pubblicano dati sul mondo fisico, ciascuno intende «3 metri» rispetto a qualcosa di diverso: la telecamera, la base o la mappa. TF2 collega questi riferimenti e la maggior parte dei bug ROS reali è una trasformazione mancante, obsoleta o collegata al genitore sbagliato. Impararlo come argomento, prima che serva, costa molto meno che incontrarlo come un inspiegabile errore di ricerca.
La calibrazione della telecamera viene terza perché dipende interamente dal secondo punto. La posa di un marcatore non significa nulla se non sai a cosa è relativa. Quando i frame hanno senso, una telecamera calibrata è semplicemente un altro nodo che pubblica una posa nell’albero e la visione non è più un caso particolare.
Il nodo di locomozione chiude il percorso perché è dove ROS incontra l’hardware di cui parla tutto il resto di questo sito.
Un twist cmd_vel è l’interfaccia standard parlata da ogni componente di navigazione ROS e convertirlo nelle velocità
delle ruote sinistra e destra, con saturazione che preserva l’arco comandato invece di deformarlo, è il ponte tra
il mondo ROS e quello dei motori.
Checkpoint: come sapere che una tappa è stata superata
| Tappa | Controllo | Esito positivo |
|---|---|---|
| Installazione | ros2 topic list in un nuovo terminale |
Funziona dopo aver attivato l’ambiente e sai perché fallisce prima di eseguirlo |
| Due nodi | Esegui talker e listener su due macchine | I messaggi arrivano e sai indicare l’ID del dominio che condividono |
| Topic o servizio | Scrivi uno di ciascuno per gli stessi dati | Sai spiegare in una frase perché ogni modello è adatto al suo lavoro |
| Azioni | Avvia un’azione lunga e annullala a metà | Si interrompe in modo pulito e hai ricevuto aggiornamenti durante l’esecuzione |
| QoS | Disallinea deliberatamente l’affidabilità su un topic | Trasporta silenziosamente nulla: ora riconosci il sintomo |
| Albero TF2 | Esegui ros2 run tf2_tools view_frames |
Un solo albero, una sola radice, nessun frame con due genitori |
| Ricerca di una trasformazione | Trasforma un punto dal frame di un sensore nel frame della base | Il numero è corretto e puoi verificarlo con un metro |
| Trasformazioni obsolete | Arresta un publisher di trasformazioni durante una ricerca | Ottieni un errore di estrapolazione: ora il guasto ha un nome |
| Calibrazione della telecamera | Calibra e controlla l’errore di riproiezione | Molto inferiore a un pixel; un valore elevato indica una serie di scatti scadente |
| Posa di un marcatore | Posiziona un marcatore a una distanza misurata e leggi la sua posa | Coincide con la misura e sai dire in quale frame si trova |
cmd_vel |
Pubblica un twist con componenti lineari e angolari | Entrambe le ruote girano correttamente e, saturando una, l’altra viene ridimensionata per preservare l’arco |
Dove termina questo percorso
Questo percorso costruisce le fondamenta sotto un robot ROS 2: come comunicano i nodi, come si relazionano i frame e come un sensore e un sistema di locomozione si uniscono al grafo. Si ferma deliberatamente prima dei grandi sottosistemi che danno tutto questo per scontato.
Non copre lo stack Nav2, la risposta standard alla navigazione autonoma in ROS 2, che è di per sé
un sistema consistente: costmap, alberi comportamentali, pianificatori e controllori, tutti configurati
anziché scritti. Nav2 presuppone un albero TF funzionante e un’interfaccia cmd_vel, ossia esattamente
ciò che questo percorso ti fornisce.
Non copre URDF e descrizione del robot, il formato XML che comunica al resto di ROS la forma del tuo robot. Qui tutto pubblica trasformazioni manualmente; URDF è il modo per smettere di farlo.
Non copre la simulazione in Gazebo, nella quale avviene in realtà gran parte dello sviluppo ROS serio, né ros2_control, il livello standard di astrazione dell’hardware per i sistemi di locomozione reali.
E non copre il comportamento in tempo reale. ROS 2 è costruito su DDS ed è molto più adatto di quanto fosse ROS 1, ma una macchina Linux che esegue un nodo Python non è un sistema di controllo in tempo reale. I cicli rapidi, come il bilanciamento, il controllo della corrente o qualsiasi operazione a kilohertz, appartengono ancora a un microcontrollore, con ROS 2 al di sopra. Questa divisione è l’architettura normale di un robot serio, non un compromesso.
Percorso di apprendimento
Il percorso
Segui i nodi in ordine: ognuno sblocca il successivo una volta completato. I tuoi progressi vengono salvati su questo dispositivo.
0 / 5 completati
Domande comuni
Domande frequenti
Quando un robot deve passare da Arduino a ROS 2?
Quando un solo ciclo non basta più. Un microcontrollore che esegue un unico programma è l'architettura giusta per un seguilinea, un risolutore di labirinto o qualsiasi cosa il cui comportamento completo rientri in un solo ciclo di controllo. Per questi compiti è davvero migliore di ROS 2, perché è deterministico e puoi tenerlo interamente in testa. ROS 2 giustifica la propria complessità quando un robot deve eseguire contemporaneamente più attività a frequenze diverse, come una catena di elaborazione della telecamera, un pianificatore o uno stack di driver, scritte in momenti differenti e riavviabili indipendentemente. Il costo è un sistema distribuito, che si comporta come tale fin dal primo comando.
Topic, servizio o azione: come scelgo in ROS 2?
Abbina il modello di comunicazione al lavoro. Un topic è un flusso senza risposta: dati dei sensori, odometria, comandi di velocità o qualsiasi cosa pubblicata in continuo quando conta solo il valore più recente. Un servizio è una richiesta e una risposta rapide, usata per operazioni che terminano in pochi millisecondi, come interrogare un parametro o commutare una modalità. Un'azione serve per lavori lunghi per cui vuoi ricevere avanzamento o che devi poter annullare, come raggiungere una destinazione o chiudere una pinza su un oggetto. L'errore più comune all'inizio è trasformare tutto in topic e poi costruire a mano la semantica di richiesta-risposta.
Perché i miei nodi ROS 2 non si vedono?
Tre cause coprono quasi tutti i casi. Valori diversi di ROS_DOMAIN_ID rendono due macchine completamente invisibili l'una all'altra, anche se entrambe segnalano perfettamente il proprio stato. Le reti Wi-Fi che bloccano il multicast interrompono del tutto il protocollo di individuazione, ed è per questo che i nodi si trovano spesso su Ethernet e non tramite il punto di accesso dell'ufficio. E un QoS non corrispondente, con un publisher che offre best-effort e un subscriber che richiede reliable, impedisce la connessione senza che nessuno dei due registri un errore. Controlla prima l'ID del dominio: non costa nulla ed è la causa più comune.
Che cos'è TF2 e perché le trasformazioni continuano a non funzionare?
TF2 mantiene l'albero dei frame di coordinate di un robot, dalla base alle ruote e a ogni sensore, così puoi chiedere dove si trova un punto nel frame della telecamera rispetto al frame del robot. Le ricerche falliscono per tre motivi ricorrenti. Un frame con due genitori rompe l'albero e, poiché il fallimento dipende soltanto da quale publisher arriva prima, funziona quasi sempre. Un frame_id vuoto nell'intestazione di un messaggio significa che il messaggio non può essere trasformato. E una marca temporale a zero o obsoleta significa che la trasformazione esiste, ma non nel momento richiesto. Tutti e tre superano senza lamentarsi il controllo dei tipi.
Mi serve un Raspberry Pi per imparare ROS 2?
No. Tutto tranne i nodi driver dell'hardware funziona perfettamente su un portatile, che è anche un posto migliore per imparare: compilazioni più rapide, uno schermo reale e nessun rischio che la corruzione di una scheda SD ti costi una serata. Un Pi diventa necessario quando vuoi che il robot trasporti il proprio computer. Se lo usi, prevedi che il Pi sarà il collo di bottiglia: una catena di elaborazione della telecamera e un pianificatore insieme troveranno presto i limiti di un Pi 4.
Perché ros2 run dice che il mio pacchetto non esiste quando è chiaramente presente?
Non hai attivato l'ambiente dello workspace in quel terminale. Ogni nuovo terminale non conosce i pacchetti compilati finché non attivi lo script di installazione che imposta l'ambiente, e ROS segnala il risultato come pacchetto mancante anziché come ambiente non attivato. È il piccolo problema di ROS 2 più comune, colpisce ripetutamente tutti e la soluzione standard è attivarlo dal profilo della shell, con la precisazione che così il problema viene nascosto quando hai davvero due workspace.