ROS 2: nodi, topic, servizi e azioni

Robot Operating System 2 (ROS 2) permette ai programmi eseguiti in modo indipendente di scambi dati tipizzati. Un driver della telecamera, un controllore dei motori, un pianificatore e un’interfaccia utente possono essere nodi separati collegati dal grafico ROS. La decisione progettuale importante non è soltanto il tipo di messaggio, ma stabilire se l’interazione sia un flusso, una breve richiesta o un obiettivo di lunga durata.

Questa guida è neutra rispetto alla distribuzione. Comandi e concetti di base sono stabili, ma i dettagli d’installazione e le versioni dei pacchetti devono seguire la documentazione della versione di ROS 2 che usi davvero.

Modellare una responsabilità per nodo

Un nodo è un partecipante al grafico ROS. Buoni confini tra nodi seguono le responsabilità: un driver lidar pubblica scansioni, un nodo di odometria stima il movimento e un navigatore accetta obiettivi. Evita di trasformare ogni funzione in un nodo: il sovraccosto di elaborazione e comunicazione è giustificato quando il confine migliora riuso, isolamento, distribuzione o proprietà.

I nomi rendono comprensibile il grafico. Usa nomi descrittivi per nodi e interfacce, come /front_lidar, /wheel_odometry e /cmd_vel. I namespace permettono a due robot di eseguire grafici equivalenti senza collisioni.

Prima di modificare un sistema in esecuzione, ispezionalo:

ros2 node list
ros2 node info /wheel_odometry
ros2 topic list -t
ros2 service list -t
ros2 action list -t

node info mostra pubblicatori, sottoscrittori, server e client dei servizi, oltre alle azioni collegate al nodo. È spesso il modo più rapido per individuare un’interfaccia mancante o con un nome errato.

Usa i topic per flussi continui

Un topic è una comunicazione asincrona in pubblicazione/sottoscrizione. I pubblicatori inviano messaggi tipizzati senza attendere una risposta diretta e un numero qualsiasi di sottoscrittori può riceverli. I topic sono adatti ai dati che cambiano nel tempo:

• immagini della telecamera e scansioni lidar;
• stati dei giunti e odometria delle ruote;
• stato della batteria;
• velocità comandata;
• eventi diagnostici.

Verifica un flusso dalla riga di comando:

ros2 topic echo /scan --once
ros2 topic hz /scan
ros2 topic info /scan --verbose

Il tipo di messaggio fa parte del contratto. I frame di coordinate, le unità, le marche temporali e la covarianza sono importanti quanto i nomi dei campi. Un sottoscrittore non può interpretare in sicurezza una posizione se non sa se il valore è in metri nel frame map o in millimetri nel frame di una telecamera.

Le impostazioni di qualità del servizio (QoS) influenzano la consegna. I flussi dei sensori spesso preferiscono dati recenti alla ritrasmissione di campioni obsoleti, mentre uno stato simile a una configurazione può richiedere un comportamento affidabile o transient-local. Un pubblicatore e un sottoscrittore con criteri QoS incompatibili possono comparire nel grafico senza scambiarsi alcun dato.

Usa i servizi per brevi richieste e risposte

Un client di servizio invia una richiesta e attende la risposta di un server. I servizi sono adatti a operazioni rapide con una risposta definita:

• leggere o aggiornare una configurazione;
• azzerare l’odometria;
• cancellare una mappa;
• chiedere se un componente è pronto.

Sono poco adatti a dati continui dei sensori o a una manovra che può richiedere secondi. Una chiamata sincrona che attende un’azione lenta del motore può bloccare il chiamante e non fornisce alcuna retroazione standard sull’avanzamento né la possibilità di annullamento.

Ispettiona e richiama un servizio con:

ros2 service type /reset_odometry
ros2 interface show example_interfaces/srv/Trigger
ros2 service call /reset_odometry example_interfaces/srv/Trigger "{}"

Il tipo esatto nell’ultimo comando deve corrispondere al server. Progetta le risposte in modo che comunichino sia il successo del trasporto sia lo stato significativo dell’operazione: ricevere una risposta non garantisce che l’azione hardware richiesta fosse possibile.

Usa le azioni per obiettivi di lunga durata

Un’azione modella un obiettivo che richiede tempo. Supporta l’accettazione dell’obiettivo, l’avanzamento periodico, un risultato finale e l’annullamento o la preemption. La navigazione verso una posa e il movimento di un braccio lungo una traiettoria sono azioni naturali.

L’interazione ha tre componenti semantiche:

• Obiettivo: ciò che il client desidera, per esempio una posa di destinazione.
• Avanzamento: avanzamento durante l’esecuzione, per esempio distanza rimanente.
• Risultato: esito finale ed eventuali dati restituiti.

I server delle azioni devono rispondere rapidamente all’annullamento e lasciare l’hardware in uno stato documentato. Un client deve gestire rifiuto, annullamento, interruzione e successo, invece di trattare ogni risultato finale come completamento.

Dalla riga di comando:

ros2 action info /navigate_to_pose
ros2 action send_goal /navigate_to_pose <action_type> '<goal_yaml>' --feedback

Sostituisci i segnaposto con il tipo e i campi indicati dal grafico in esecuzione. Usa il comando per ispezionare il comportamento, non come interfaccia di produzione codificata nel codice.

Scegli con una sola tabella decisionale

Un topic non è automaticamente «veloce» e un servizio non è automaticamente «affidabile». Temporizzazione e consegna dipendono da QoS, middleware, executor, carico di lavoro e rete. Scegli prima in base alla semantica dell’interazione.

Tutte e tre possono essere usate per un unico comportamento. Un nodo di navigazione sottoscrive topic di scansione e odometria, accetta un’azione di navigazione ed espone un breve servizio per cancellare una costmap. I confini restano chiari perché ogni interfaccia risponde a un tipo diverso di domanda.

Progetta un piccolo grafico per robot mobile

Considera un robot con trazione differenziale:

1. /encoder_driver pubblica i conteggi delle ruote.
2. /odometry sottoscrive i conteggi, pubblica /odom e trasmette odom → base_link.
3. /range_driver pubblica le misurazioni di distanza.
4. /safety_controller sottoscrive le distanze e limita /cmd_vel.
5. /navigator accetta un’azione di movimento e pubblica la velocità desiderata.

Non permettere a due nodi non correlati di comandare i motori senza un meccanismo di arbitraggio. Assegna a un solo componente la responsabilità del comando finale all’attuatore oppure rendi esplicita la regola di priorità.

Usa i tipi di messaggio standard ROS quando la loro semantica è adatta. Le interfacce personalizzate sono appropriate quando il contratto dei dati è realmente specifico del progetto, non soltanto quando vuoi rinominare campi esistenti.

Analizza il grafico strato per strato

Quando mancano dati:

1. Verifica che entrambi i nodi compaiano in ros2 node list.
2. Verifica nomi e tipi delle interfacce.
3. Ispeziona i conteggi di pubblicatori e sottoscrittori.
4. Confronta i criteri QoS.
5. Visualizza un messaggio e controlla marche temporali e frame ID.
6. Controlla i log e il carico degli executor.

Quando un’azione non termina, distingue tra «obiettivo non accettato», «server che ha smesso di produrre avanzamento» e «client che ha ignorato il risultato». Quando un servizio si blocca, verifica se la callback del server è bloccata in attesa di un lavoro che sarebbe dovuto essere un’azione.

Evita gli errori architetturali comuni

• Tutto usa un topic: i chiamanti non possono sapere se una richiesta singola è riuscita.
• Il movimento usa un servizio: a un lavoro lungo mancano le semantiche di avanzamento e annullamento.
• I dati dei sensori usano per impostazione predefinita una coda profonda e affidabile: i campioni obsoleti si accumulano quando l’elaborazione rallenta.
• Le convenzioni di frame e unità non sono documentate: anche i messaggi tipizzati restano ambigui semanticamente.
• Un enorme nodo possiede ogni sottosistema: diventa impossibile testare e isolare i guasti.
• Decine di piccoli nodi avvolgono funzioni ordinarie: il grafico diventa più complicato senza aggiungere confini utili.

Il Simulatore del braccio robotico fornisce un compito concreto simile a un’azione: richiedi una destinazione, osserva il movimento e segnala esiti irraggiungibili o vincolati. Continua con i frame di coordinate ROS 2 TF2 per mantenere coerente la geometria di ogni nodo.