Comunicazione di basso livello

Dietro la semplice interfaccia della comunicazione tramite service, topic e pa-rameter server si cela un meccanismo comunicativo di basso livello pi`u complesso,

Figura 2.2: Schema di funzionamento di un service

basato sui protocolli XMLRPC, TCPROS e UDPROS.

• Implementazione di service: lo schema di funzionamento di un service `e riportato in figura 2.2, si articola in alcuni passi e comporta l’uso dei protocolli XMLRPC e TCP:

0. Il nodo provider richiede a ROS, attraverso l’apposita funzionalit`a del client library, di fornire il generico servizio srv. La richiesta determina la chiamata a procedura remota verso il Master tramite protocollo XMLR-PC, con la specifica dell’URI TCP di ascolto del nodo provider e il nome del service fornito.

1. Un nodo client che voglia usufruire del service si rivolge al Master con una richiesta di lookup del service srv, ricevendo come risposta l’URI del nodo provider.

2. Dopo aver stabilito una connessione TCPROS con il service provider e lo scambio di un Connection Header, il client invia il messaggio reqest in forma serializzata

3. Nel nodo provider sar`a richiamata la funzione di callback a gestione del service e una volta predisposto il messaggio di risposta, questo sar`a comu-nicato al nodo client in forma serializzata tramite lo stesso canale TCP precedentemente predisposto.

Secondo lo schema presentato il Master viene contattato ad ogni nuova richie-sta del service, anche se proveniente da un nodo client che ha effettuato

pre-2.4 Comunicazione in ROS 43

cedenti richieste. Ci`o viene effettuato per garantire fault-tolerance in quanto l’URI del nodo provider potrebbe cambiare. Ci`o potrebbe accadere a seguito di un crash del provider stesso o a causa dell’ingresso in ROS di un nuovo nodo provider, che determina la terminazione immediata del vecchio nodo. In presenza di frequenti chiamate ad un service, o in generale quando l’overhead determinato dal processo di lookup `e eccessivo, `e possibile mantenere una con-nessione persistente verso il service provider che consenta di inviare richieste multiple sulla stessa connessione. Questa forma `e rischiosa poich`e non fornisce nessuna garanzia di fault-tolerance.

• Implementazione di topic: il meccanismo che sta dietro al funzionamento della comunicazione tramite topic, riportato in figura 2.3, `e pi`u complesso.

0. Il nodo publisher comunica a ROS la sua intenzione di pubblicare mes-saggi nel topic bar. Le funzionalit`a del client library intraprendono una comunicazione verso il Master via XMLRPC attraverso la quale il nodo si registra come publisher per il topic specifico, indicando l’URI del proprio server XMLRPC.

1. Il nodo subscriber comunica a ROS la sua intenzione di sottoscrivere il topic bar. Le API del client library inviano tale richiesta verso il Master. 2. Il Master, avendo gi`a almeno un publisher per il topic richiesto, rispon-de al nodo comunicandogli l’URI rispon-del publisher. In caso di successive registrazioni di nuovi publisher, il Master ricontatter`a tutti i subscriber comunicandogli l’URI.

3. Il nodo subscriber contatta il publisher via XMLRPC per richiedere una connessione al topic e specifica la lista dei protocolli di trasporto suppor-tati (ROSTCP o ROSUDP).

4. Il publisher sceglie il protocollo da utilizzare e lo comunica al subscriber, assieme all’URI da raggiungere per l’eventuale connessione (TCPROS). 5. Il nodo subscriber effettua, nel caso pi`u comune di utilizzo del protocollo

ROSTCP, una connessione verso l’URI del publisher comunicata.

6. I prossimi messaggi pubblicati da publisher raggiungeranno il subscriber attraverso il canale aperto.

Si osservi che una volta stabilita la connessione non `e pi`u richiesto il coin-volgimento del Master che in nessun momento `e coinvolto nel flusso di dati scambiati nel topic.

Figura 2.3: Schema di funzionamento di un topic

• Parameter Server: le richieste rivolte al parameter server sono implementate direttamente attraverso chiamate XMLRPC verso il Master.

Di seguito si descrivono i protocolli di basso livello utilizzati nella comunicazione tra nodi e Master.

2.4.3.1 TCPROS

E’ il protocollo di gran lunga pi`u utilizzato in ROS. Viene utilizzato per tra-smissione di messaggi request e response tra client e service provider ed `e uno dei protocolli utilizzabili per le comunicazioni di messaggi topic, assieme a UDPROS. Come si evince dal nome TCPROS utilizza comuni socket TCP/IP come protocol-lo di trasporto, specificando un header di pi`u alto livello contenente alcuni campi specifici per ROS:

• callerid: nome del nodo che sta inviando i dati • topic: nome del topic in fase di sottoscrizione • service: nome del service che si sta chiamando

• md5sum: digest md5 del file msg o srv che definisce il formato dei messag-gi scambiati (calcolato sul file orimessag-ginale dopo la rimozione dei commenti, la rimozione degli spazi, riordinamento della struttura del file)

2.4 Comunicazione in ROS 45

Figura 2.4: Schema di funzionamento di XMLRPC

• persistent: specifica che la connessione per la chiamata a servizio dovr`a essere persistente

• tcp nodelay • latching

2.4.3.2 UDPROS

UDPROS `e basato sul protocollo UDP. L’uso di UDPROS `e conveniente quando `e da privilegiarsi una comunicazione a bassa latenza, seppur non del tutto affidabile, come lo streaming audio. Un’altra condizione in cui UDPROS pu`o essere conve-niente `e il presenza di un livello fisico poco affidabile, come connessioni wireless, che rende inefficace TCP. Infine l’utilizzo di UDPROS pu`o essere conveniente in presen-za di subscriber multipli al medesimo topic che siano raggruppati nella medesima sottorete, nel qual una comunicazione condivisa via broadcast UDP pu`o risultare pi`u efficiente. Anche UDPROS aggiunge al datagramma UDP un ulteriore header che specifica dettagli della comunicazione ROS.

2.4.3.3 XMLRPC

XMLRPC `e una specifica, a cui corrispondono molteplici implementazioni, di un protocollo per remote procedure calling che utilizza HTTP protocollo di trasporto e XML come codifica (figura 2.4). I vantaggi apportati da XMLRPC sono la relativa leggerezza rispetto altri protocolli come SOAP, e l’essenza stateless. I client library di ROS implementano proprie versioni del protocollo, ad esempio roscpp utilizza il package xmlrpcpp, tuttavia come visto le funzionalit`a dei client library consentono

di mascherare totalmente l’interazione con il master, nascondendo tutti i meccanismi di comunicazione a basso livello.