Contents — find the section you need
ROS 2 non è il robot in sé. È una base per eseguire un driver per la telecamera, l'autolocalizzazione, la pianificazione del percorso e il controllo dei motori come programmi (nodi) separati, combinandoli attraverso messaggistica e comunicazione standardizzate. È possibile iniziare con un singolo file Python nella fase di prototipo e scalare fino a C++, esecuzione in tempo reale, più computer e monitoraggio della sicurezza per un prodotto finito. Ciò che conta non è memorizzare le API, ma progettare chi possiede i dati, la tempistica, l'affidabilità e lo stato sicuro allo spegnimento.
Immagine: Robot, Wikimedia Commons (CC BY-SA 4.0). Il logo identifica il middleware e non garantisce una particolare distribuzione o configurazione DDS.
Riepilogo di 30 secondi
- Un nodo è un processo con una sola responsabilità, un argomento rappresenta un flusso continuo, un servizio rappresenta una breve richiesta/risposta e un'azione rappresenta un'attività lunga con feedback intermedio. - La comunicazione di ROS 2 avviene tramite DDS e la QoS (affidabilità, cronologia, profondità, durabilità, scadenza) può essere scelta per ogni endpoint. Sensori e controllo non devono necessariamente utilizzare le stesse impostazioni.
TF2 gestisce una struttura ad albero di frame di coordinate insieme al tempo. Se si confondono i frame map, odom, base_link e quelli dei sensori, il robot si dirigerà verso il posto sbagliato anche se la percezione è corretta.
Su hardware reale, è necessario aggiungere la gestione del ciclo di vita, i watchdog, la separazione dei privilegi, la registrazione dei log e i meccanismi di sicurezza per le interruzioni di rete. Lavorare in simulazione non è una prova di sicurezza.
È fondamentale correggere fin dall'inizio una release con supporto a lungo termine come ROS 2 Jazzy, insieme a una combinazione di DDS, sistema operativo e driver compatibili, e creare un ambiente di lavoro riproducibile.
1. Panoramica generale di ROS 2
Figura 1 — In ROS 2, i nodi si scoprono e comunicano tra loro tramite DDS.
Non solo i nomi degli argomenti, ma anche QoS, tipo, tempo e sistema di coordinate sono tutti considerati parte del contratto. Un grafo ROS 2 può essere configurato in fase di esecuzione. Un nodo telecamera pubblica le immagini, un nodo di percezione le riceve e un nodo di controllo elabora i risultati, inclusa l'autolocalizzazione, e pubblica i comandi di velocità. Anche se si sposta un nodo su un computer diverso, lo stesso grafo rimane valido a condizione che il rilevamento e la serializzazione DDS funzionino correttamente.2. Scelta della primitiva di comunicazione corretta
| Tipo | Dove viene utilizzata | Esempio | Considerazioni di progettazione |
|---|---|---|---|
| Argomento | Flusso continuo, molti-a-molti | /scan , /camera/image |
QoS, larghezza di banda, latenza, dropout |
| Servizio | Richiesta e risposta brevi | /reset_odometry |
Timeout, rientranza |
| Azione | Attività di lunga durata con avanzamento | Navigazione, presa | Annullamento, interruzione sicura |
Parametro | Configurazione a tempo di avvio o a bassa frequenza | Guadagni, nomi dei frame | Tipo, permessi di modifica, riproducibilità |
Un messaggio di argomento dovrebbe contenere non solo il valore, ma anche header.stamp e frame_id. Se il timestamp dell'immagine e il timestamp dell'IMU non sono sincronizzati, l'algoritmo può comunque calcolare un risultato, ma stimerà in modo errato il movimento. La ritrasmissione delle immagini della telecamera con affidabilità può saturare la larghezza di banda, quindi è necessario scegliere la QoS in base alle caratteristiche di ciascun sensore.
3. QoS come "Contratto di comunicazione"
Le impostazioni QoS minime da verificare in ROS 2 sono Affidabilità (Best Effort/Affidabile), Durabilità (Volatile/Transitorio Locale), Cronologia (Mantieni l'ultimo/Mantieni tutto), Profondità, Scadenza e Vivacità. Un LiDAR ad alta velocità potrebbe essere adatto a Best Effort, che scarta i pacchetti obsoleti, mentre i comandi di velocità, che non tollerano la perdita di messaggi, dovrebbero utilizzare Reliable con un Deadline breve.
Se il QoS del Publisher e del Subscriber non sono compatibili, non comunicheranno nemmeno con lo stesso nome di argomento. Verificate le impostazioni effettive con ros2 topic info -v /scan invece di affidarvi ciecamente alle impostazioni predefinite del driver del sensore. Quando attraversate una rete, testate contemporaneamente MTU, ritrasmissione Wi-Fi, restrizioni multicast e sincronizzazione dell'ora.
4. TF2 e Tempo
La posizione di un robot è espressa come una trasformazione tra sistemi di coordinate. Un albero tipico ha la seguente struttura:
map ──(SLAM/Localization)──> odom ──(odometry)──> base_link
├── base_laser
├── imu_link
└── camera_link
map è il sistema di riferimento globale a lungo termine, odom è l'odometria a breve termine e base_link è il sistema di riferimento del veicolo. SLAM corregge map → odom, mentre la stima della ruota/IMU aggiorna odom → base_link ad alta frequenza. TF2 memorizza le trasformazioni con timestamp e le interpola al tempo di acquisizione di ciascun sensore.
Standardizzare i sistemi di coordinate come destrorsi ed esplicitare la differenza tra il sistema di riferimento ottico (z avanti, x destra, y basso) e il sistema di riferimento del veicolo (x avanti, y sinistra, z alto). Correggere le trasformazioni statiche con static_transform_publisher e non pubblicare una trasformazione dinamica come statica. Un ciclo o più genitori nell'albero TF sono un errore di progettazione.
5. Pacchetti e flusso di implementazione
Un nodo Python ROS 2 minimo ha questo aspetto.
import rclpy
from rclpy.node import Node
from std_msgs.msg import Float32
class Speed(Node):
def __init__(self):
super().__init__('speed_node')
self.pub = self.create_publisher(Float32, '/speed', 10)
self.timer = self.create_timer(0.02, self.tick) # 50 Hz
def tick(self):
msg = Float32(); msg.data = 0.2
self.pub.publish(msg)
rclpy.init(); node = Speed(); rclpy.spin(node)
Su hardware reale, non inviare comandi di velocità direttamente al motore: interponi un nodo a monte, un limitatore di velocità, un arresto di emergenza e un sistema di monitoraggio hardware. Anche quando utilizzi rclcpp di C++, verifica i gruppi di callback, l'Executor, l'allocazione della memoria e il comportamento in tempo reale.
Dividi l'area di lavoro in src, build, install e log e risolvi le dipendenze con rosdep. Blocca il sistema operativo, il DDS e il compilatore con Docker o un container di sviluppo e integra ros2 doctor, ros2 node list, ros2 topic hz e tf2_tools sia nella CI che nella diagnostica di campo.
6. Ciclo di vita e sicurezza
I sensori e gli attuatori non dovrebbero necessariamente accettare comandi all'istante in cui vengono accesi. Le transizioni di stato del nodo del ciclo di vita — Non configurato → Inattivo → Attivo → Finalizzato — separano l'inizializzazione del driver, la calibrazione, i controlli di comunicazione e l'autorizzazione dell'output. Quando un watchdog perde il suo heartbeat, azzera il comando di velocità e apri anche il freno o il relè sul lato hardware.
Per quanto riguarda la sicurezza, la comunicazione dei messaggi di ROS 2 da sola non soddisfa gli standard di sicurezza funzionale. Verificare l'ambito di applicazione delle norme IEC 61508/ISO 26262/ISO 13849 e standard simili, e separare le funzioni di sicurezza in un sistema di monitoraggio, una MCU certificata e un pulsante di arresto di emergenza fisico. Quando ci si connette a una rete, adottare chiavi e certificati SROS 2, DDS Security, controllo degli accessi e audit dei log.
7. Ecosistema e ricerca attuali
Nav2 integra autolocalizzazione, mappatura, pianificazione del percorso e controllo tramite azioni e gestione del ciclo di vita, mentre ros2_control standardizza il confine tra hardware e controller. MoveIt 2 gestisce la cinematica del manipolatore, il controllo delle collisioni e la pianificazione della traiettoria. La simulazione in Gazebo o Webots e la riproduzione dei log dei sensori con rosbag2 consentono di eseguire test di regressione senza arrestare il robot reale.
La ricerca sta progredendo sulla comunicazione a copia zero, sulle pipeline di immagini tipizzate che utilizzano GPU/NPU, sugli esecutori deterministici, sull'apprendimento distribuito e sulla robotica cloud che va oltre DDS. Quando si adotta una nuova funzionalità, è importante testare non solo i benchmark, ma anche le interruzioni di rete, gli sfasamenti temporali, i riavvii dei processi, le interruzioni dei sensori e la lunghezza non corretta dei messaggi.
Riepilogo
ROS 2 trasforma un robot da un insieme di componenti in un sistema distribuito riutilizzabile. Progettando in anticipo le responsabilità dei nodi, la QoS degli argomenti, le coordinate e la temporizzazione di TF2, il ciclo di vita e gli stati sicuri, l'intero sistema rimarrà robusto anche quando si sostituiscono gli algoritmi.
La connettività tra i nodi garantisce il corretto funzionamento?
Anche timestamp, frame, QoS e velocità devono corrispondere.
La ricezione dei dati non implica che siano utilizzabili per il controllo.
Commenti
Accedi per continuare.
Nessun dato disponibile.