A gennaio 2010 Willow Garage ha rilasciato la versione 1.0 di ROS (Robot Operating System) sotto licenza BSD: un middleware che organizza il software di un robot come grafo di processi indipendenti che si scambiano messaggi. Il nome inganna. ROS non rimpiazza il sistema operativo sotto di sé: gira sopra Linux e mette a disposizione convenzioni di comunicazione, un sistema di build e un formato di pacchetto condiviso.

Contesto

Fino a metà degli anni 2000 ogni laboratorio di robotica si riscriveva la base software quasi da zero: driver dei sensori, stima della posa, pianificazione del moto, controllo degli attuatori. Il codice restava cucito addosso all’hardware specifico e al cablaggio del singolo robot, e portarlo su un’altra piattaforma voleva dire, in pratica, ricominciare daccapo.

ROS non è il primo tentativo di spezzare questo schema. Il progetto Player/Stage, distribuito dalla University of Southern California dal 2001, espone l’hardware del robot dietro un’interfaccia di rete con modello client/server, insieme al simulatore 2D Stage e al simulatore 3D Gazebo (Gerkey, Vaughan, Howard, ICAR 2003). CARMEN, sviluppato alla Carnegie Mellon (Montemerlo, Roy, Thrun, IROS 2003), offre un toolkit modulare per la navigazione. OROCOS (Bruyninckx, ICRA 2001) lavora sul controllo in tempo reale; YARP (Metta, Fitzpatrick, Natale, 2006) nasce per i robot umanoidi del progetto iCub. Di middleware, quindi, ce n’erano fin troppi: il problema era che proliferavano, ciascuno incompatibile con gli altri.

Architettura

L’unità di esecuzione in ROS è il nodo: un processo che fa una cosa sola e ben delimitata — leggere un laser scanner, fondere odometria e IMU (Inertial Measurement Unit), calcolare una traiettoria. Un sistema robotico diventa così un grafo di nodi, che possono girare sullo stesso calcolatore o su macchine diverse della stessa rete.

I nodi dialogano soprattutto via topic, con modello publish/subscribe. Un nodo pubblica messaggi su un topic con nome (per esempio /scan per i dati del laser); chi è interessato si iscrive a quel topic e li riceve, senza che chi pubblica e chi si iscrive si conoscano. La risoluzione dei nomi passa per un processo centrale, il master (roscore): publisher e subscriber si registrano presso il master, che li mette in contatto; da lì in poi lo stream di dati viaggia direttamente tra i due nodi via TCP, senza altri intermediari (Quigley et al., ICRA Workshop on Open Source Software, 2009).

Oltre ai topic, ROS prevede i servizi per le interazioni richiesta/risposta sincrone, e un parameter server centralizzato per la configurazione. I messaggi hanno un tipo dichiarato in file .msg: un generatore produce le strutture corrispondenti per C++, Python e Lisp, così un nodo C++ e un nodo Python si scambiano lo stesso messaggio senza adattatori scritti a mano.

L’astrazione dell’hardware sta tutta in questa convenzione sui tipi. Se due laser diversi pubblicano sensor_msgs/LaserScan sullo stesso topic, il nodo che costruisce la mappa funziona con entrambi senza toccarlo; allo stesso modo un nodo di navigazione può girare su robot fisicamente diversi, purché rispettino i formati attesi.

Il punto critico

La scelta che separa ROS dai middleware precedenti è il disaccoppiamento per nome di topic più tipo di messaggio, invece che per interfaccia di programmazione condivisa. In Player il client parla con un driver attraverso un’API per categoria di dispositivo; in ROS due nodi non condividono né codice né l’identità l’uno dell’altro: condividono solo la stringa del topic e lo schema del messaggio. L’accoppiamento scende così al minimo, e quel minimo lo verifichi a runtime — rostopic echo /scan mostra che cosa transita davvero su quel canale — mentre qualunque nodo diventa sostituibile con un altro che rispetti lo stesso contratto.

Il prezzo è che la struttura del sistema vive nei nomi a runtime, non in un’interfaccia statica sorvegliata dal compilatore. Un topic scritto male, un disallineamento di tipo o di unità tra publisher e subscriber non emerge in compilazione: i messaggi semplicemente non arrivano, oppure arrivano con la semantica sbagliata. Il debug passa per l’ispezione del grafo (rosnode, rxgraph) più che per il controllo dei tipi.

Strumenti

ROS 1.0 include rviz, un visualizzatore 3D che disegna in tempo reale i dati dei sensori, le mappe in costruzione, le trasformazioni tra sistemi di riferimento e lo stato delle articolazioni. La libreria tf tiene l’albero delle trasformazioni geometriche tra i frame del robot nel tempo: un problema ricorrente e facile da sbagliare quando lo si scrive a mano per ogni progetto.

Per sviluppare senza hardware fisico ROS si appoggia a Gazebo, il simulatore 3D con dinamica che arriva dalla famiglia Player/Stage: lo stesso eseguibile che girerebbe sul robot reale si iscrive ai topic prodotti dal mondo simulato. Il sistema di build (rosbuild, sopra CMake) gestisce le dipendenze tra pacchetti e la generazione dei messaggi; il formato di pacchetto e i manifest aiutano a ridistribuire il codice tra gruppi diversi.

Implicazioni

La licenza BSD è una scelta deliberata, e tutt’altro che secondaria: lascia usare il codice anche dentro prodotti chiusi, e abbassa l’attrito verso l’adozione industriale rispetto a una copyleft. Insieme al programma beta PR2, con cui Willow Garage vuole mettere robot di ricerca nelle mani di laboratori esterni, è la leva con cui prova a far convergere la comunità su una base comune invece che su tante basi incompatibili. Se la scommessa regge, un algoritmo pubblicato come pacchetto ROS diventa eseguibile da chiunque abbia un robot che pubblica i topic giusti, e il lavoro di un gruppo si somma a quello di un altro invece di ripartire da zero.

Limiti

ROS 1.0 è uscito da poco, e parecchie scelte restano da provare sul campo. Il modello dà per scontata una rete affidabile e a bassa latenza tra i nodi: non offre garanzie hard real-time né meccanismi nativi di tolleranza ai guasti, e il master centrale è un punto singolo la cui caduta blocca la risoluzione dei nomi (le connessioni già aperte proseguono, ma non se ne stabiliscono di nuove). Il trasporto TCP introduce una latenza variabile, poco adatta agli anelli di controllo più stretti, che di norma restano fuori dal grafo ROS. La portabilità vera, oggi, è soprattutto su Linux. E non è ancora chiaro se l’ecosistema raggiungerà la massa critica perché il riuso promesso diventi la regola e non l’eccezione: la storia dei middleware robotici precedenti — tutti validi sul piano tecnico, nessuno diventato uno standard — è il precedente da non dimenticare.

https://www.ros.org/news/2010/01/ros-10.html http://ai.stanford.edu/~ang/papers/icraoss09-ROS.pdf https://wiki.ros.org/ROS/Concepts https://playerstage.sourceforge.net/ https://www.noze.it/insights/ros-open-source/

Immagine di copertina: Il robot di ricerca PR2 di Willow Garage, con base mobile a ruote, due bracci e testa con sensori, esposto a un evento pubblico… — foto di Timothy Vollmer, CC BY 2.0 — https://commons.wikimedia.org/wiki/File:PR2_at_Maker_Faire.jpg