2.ROS 2.1.ChecosaèROS?

2.1. Che cosa è ROS?

Il termine ROS sta per Robot Operating system [13], esso è un (meta-)sistema operativo per robot sviluppato principalmente da Willow Garage [14], ma con diverse istituzioni e privati che collaborano grazie al suo sistema di sviluppo federativo. ROS è open-source e rilasciato sotto licenza BSD (Berkeley Software Distribution).

ROS fornisce i comuni servizi offerti da un sistema operativo, tra cui l’astrazione hardware, il controllo dei dispositivi di basso livello, l’implementazione di funzionalità di uso comune, il passaggio di messaggi tra processi e la gestione dei pacchetti (Figura 2.1). Inoltre, ROS fornisce anche strumenti e librerie per sviluppare ed eseguire codice su più computer. ROS è simile per certi aspetti ad un ’robot framework", come Player [15], YARP [16], OROCOS [17], CARMEN [18], Orca [19], MOOS [20], e Microsoft Robotics Studio [21]. ROS non è un framework in tempo reale ma è possibile integrare in ROS codice in tempo reale.

Figura 2.2.: Distribuzioni ROS

ROS attualmente gira solo su piattaforme basate su Unix. Il software per ROS è stato testato principalmente sui sistemi Ubuntu e Mac OS X, anche se la comunità ROS ha contri-buito per il supporto per Fedora, Gentoo, Arch Linux e altre piattaforme Linux. E’ possibile installare ROS per Microsoft Windows, ma ancora non è stato ancora pienamente esplorato. In Figura 2.2 le distribuzioni di ROS attualmente disponibili.

2.2. Le caratteristiche di ROS

ROS è un framework distribuito di processi eseguibili, questi processi possono essere raggrup-pati in Packages e Stacks (raccolte di pacchetti che forniscono funzionalità di aggregazione). Stacks e Packages possono essere condivisi e attualmente distribuiti grazie ad un sistema di code repository (Figura 2.3). Questa struttura è stata scelta per sostenere il riutilizzo del codice sviluppato nel campo della ricerca e sviluppo in ambito robotico. Infatti essa consente di prendere decisioni autonome riguardo lo sviluppo e l’attuazione, rendendo facile l’integrazione di componenti differenti e consentendo la creazione di sistemi complessi. ROS ha diverse caratteristiche e obiettivi di progettazione [22]:

• peer-to-peer : i processi sono collegati in fase di esecuzione in una topologia peer-to-peer.

Per fare questo ROS deve offrire una sorta di meccanismo di ricerca per consentire ai processi di trovarsi l’un l’altro in fase di esecuzione, questo è fornito dal nodo Master. • Thin: ROS è stato progettato per essere il più leggero possibile, in modo che il codice scritto per ROS può essere utilizzato con altri software framework per robot. ROS inoltre si integra facilmente con gli altri software framework per robot: ROS è già stato integrato con OpenRAVE, OROCOS, e Player.

• Hardware independence: ROS è completamente indipendente dall’hardware, può essere usato con un gran numero di piattaforme robot e sensori.

• Language independence: il framework ROS è facile da implementare in qualsiasi lin-guaggio di programmazione moderno. Sono già implementati Python, C ++, e Lisp, e ci sono le librerie sperimentali in Java e Lua.

• Tools-based: nel tentativo di gestire la complessità di ROS, gli sviluppatori hanno optato per un design microkernel, dove vengono utilizzati un gran numero di piccoli strumenti che permettono di costruire e gestire i vari componenti ROS, piuttosto che la costruzione di un ambiente di sviluppo monolitico.

2.3. Le funzionalità di ROS

ROS si estende su tre livelli: il filesystem Level, il Computation Graph Level e il Community Level. In aggiunta a questi tre livelli, ROS definisce altri due tipi di nomi: Package Resource Names e Graph Resource Names, che sono discussi in seguito.

2.3.1. ROS Filesystem Level

Il concetto di filesystem level offre un organizzazione delle risorse di ROS sul disco:

• Package: sono l’unità principale per l’organizzazione del software all’interno di ROS. Un package può contenere i processi runtime ROS ( nodes ), una ROS - dependent library, un insieme di dati, files di configurazione, o qualsiasi cosa sia utilizzata in quel package

• Manifest (manifest.xml): offrono metadati relativi al package, come informazioni sulla sua licenza e sul le dipendenze ma anche informazioni riguardanti linguaggi specifici o i flags di compilazione.

• Stack: collezioni di package che offrono funzionalità per un determinato scopo globale. Gli Stacks sono anche del software ROS che viene rilasciato ed è associato ad un numero che ne indica la versione.

• Stack Manifest (stack.xml): offrono metadati relativi a un determinato stack, come le informazioni sulla licenza e le sue dipendenze su altri stack.

• Message (msg) type: Sono le descrizioni dei messaggi (immagazzina ti in my_packa-ge/msg/MyMessageType.msg , definiscono le strutture dati dei messaggi.

• Service (srv) type: Sono le descrizioni dei Servizi (immagazzinati in my_package/sr-v/MyServiceType.srv), definiscono le strutture dati di richiesta e risposta dei servizi i n ROS.

2.3.2. ROS Computation Graph Level

Il Computation Graph è la rete peer-to-peer dei processi ROS che elaborano dati collaboran-do insieme in modalità loosley coupled , ossi a vengono accoppiati in mocollaboran-do da non generare forme di interdipendenza tra loro. ROS implementa diversi stili di comunicazione:una co-municazione sincrona RPCstyle basata sui service, lo streaming asincrono di dati basata su topics (Figura 2.4) e la conservazione dei dati su un server (Parameter Server).

Figura 2.4.: ROS a tempo di esecuzione

I concetti base del Computation Graph sono i Nodes, il Master , i Parameter Server , i Messages , i Services , i Topics ed i Bags. Ciascuno di questi offre dati al Graph in modi diversi, che sono implementati nel ros_comm stack.

• Nodes: processi che eseguono calcoli. ROS è progettato per essere modulare in scala grana-fine; un sistema di controllo del robot di solito è composto da molti nodi. Per esempio, un nodo controlla un sensore laser, un nodo controlla i motori delle ruote, un nodo esegue la localizzazione, un nodo esegue la pianificazione di percorso, un nodo fornisce una visualizzazione grafica del sistema, e così via. Un sistema di controllo per robot di solito include molti processi, questi vengono scritti usando le ROS client library, come roscpp o rospy .

• Master : consente di registrare e ricercare nomi all’interno del Computation Graph. Senza il Master, i nodi non sarebbero a conoscenza della presenza, di scambiare messag gi e di invocare i servizi degli altri nodi.

• Parameter Server : è un dizionario condiviso e accessibile dai nodi, integrato e gestito dal Master. Il parameter server può essere utilizzato per memorizzare e recuperare parametri del sistema runtime, rendendoli disponibili a tutto il computation graph. I parametri vengono memorizzati in un namespace gerarchico, la risoluzione dei nomi e il recupero dei valori dei parametri è realizzato tramite funzionalità di alto livello dei client library.

• Messages: i nodi comunicano con gli altri attraverso lo scambio dei messaggi. Un messaggio è semplicemente una struttura dati che comprende diversi tipi di campi. Sono supportati sia tipi di dati standard (integer, floating point, boolean, etc.), che array di questi tipi di dati. I messaggi possono includere arbitrariamente sia array che strutture innestate (come le strutture in C).

• Topics: i messaggi sono instradati attraverso un sistema di trasporto con le semantiche di pubblicazione e sottoscrizione (Figura 2.5). Un node invia un messaggio per la pubblicarlo su un dato topic . Il topic è un nome che è usato per identificare il contenuto del messaggio. Un node che è interessato a un certo tipo di dati si sottoscriverà a quell’appropriato topic . Ci possono essere più publisher e subscirber concorrenti per un singolo topic , e un singolo processo può pubblicare e/o sotto scriversi a più topics . In generale, publisher e subscriber non sono consapevoli dell’esistenza degli altri. L’idea è di disaccoppiare la produzione dell’informazione da quella del suo consumo. Logicamente, è possibile considerare un topic come un bus di dati fortemente tipizzati. Ciascun bus ha un nome, e ognuno può collegarsi al bus per inviare o ricevere messaggi di quel particolare tipo.

Figura 2.5.: ROS basic concepts

Services: il modello di pubblicazione e sottoscrizione è un paradigma molto flessibile, ma la sua comunicazione molti a molti non è appropriata alle interazioni di request/-reply, che sono richieste spesso in un sistema distribuito. Il request/reply si realizza attraverso i services, che sono definiti con diverse strutture composte da un paio di messaggi: uno per la request e l’altro per il reply. Un nodo offre un servizio sotto un nome e un client usa il servizio inviando un messaggio di request e attendendo quello di reply. Le ROS client libraries generalmente presentano questa interazione al programmatore come se fosse una chiamata a procedura remota

• Bags: sono il meccanismo utilizzato da ROS per effettuare il logging delle comunica-zioni topic. Attraverso un normale processo di sottoscrizione è possibile associare un bag a uno o più topic. I messaggi scambiati saranno memorizzati automaticamente su file .bag in forma serializzata, in questo modo è possibile ad esempio memorizzare e analizzare successivamente i dati prodotti dai sensori del sistema.

Il ROS Master agisce come un nameservice nel ROS Computation Graph, infatti conserva le informazioni dei topics e dei services per i nodes. I nodi comunicano con il Master per riferirgli le loro informazioni di registrazione. Inoltre, poiché questi nodi comunicano con il Master, possono ricevere informazioni relative agli altri nodi che si sono registrati, in modo da creare una connessione con questi. Il Master effettuerà anche richiamate a questi nodi quando le informazioni di registrazione cambieranno, in modo tale da permettere di creare dinamicamente le connessioni non appena i nodi vengono eseguiti. Tuttavia i nodi si collega-no tra di loro in maniera diretta. Infatti, il Master offre solo informazioni di ricerca e opera in modo molto simile a un server DNS. I nodi che si sottoscrivono al topic richiederanno la connessione ai nodi che hanno pubblicato messaggi su quel topic e stabiliranno la connessione

con un concordato protocollo. Il protocollo più usato è chiamato TCPROS, che usa sockets standard TCP/IP.

Questo livello permette di dividere le operazioni in base ai nomi, i quali sono i mezzi principali con cui i sistemi più grandi e più complessi possono essere costruiti. I nomi hanno un ruolo molto importante in ROS: i nodes, i topics, i services e tutti i parametri hanno un nome che deve essere unico. Ogni ROS client library supporta la rimappatura dei nomi, il che significa che un programma compilato può essere riconfigurato in fase di esecuzione per operare all’interno del Computation Graph con un altro nome.

Ad esempio, per controllare un laser Hokuyo, è sufficiente avviare il driver nodo Hokuyo, che parla con il laser e pubblica i dati letti sul topic laser_msg. Per elaborare i dati, si può scrivere un nodo utilizzando laser_filters che sottoscrive i messaggi sul topic laser_msg. Dopo la sottoscrizione, il nostro filtro si avvia automaticamente ed inizia a ricevere i messaggi dal laser. Si noti come i due lati sono disaccoppiati. Infatti il nodo Hokuyo pubblica le scansioni, senza la conoscenza se qualcuno si è sottoscritto. Mentre il filtro non si sottoscrive al topic per leggere le scansioni, senza la conoscenza del fatto che qualcuno sta pubblicando su quel topic. I due nodi possono essere avviati, terminati, e riavviati, in qualsiasi ordine, senza indurre eventuali condizioni di errore.

Più tardi potremmo aggiungere un altro laser per il nostro robot, senza l’obbligo di ricon-figurare il nostro sistema. Tutto quello che dobbiamo fare è rimappare i nomi che vengono utilizzati.

2.3.3. ROS Community Level

I concetti principali del ROS Community Level sono le resources a bilitate d a diverse c ommunity per lo scambio di software e di conoscenza. Queste resources includono:

• Distributions: le ROS Distributions sono collezioni di versioni degli stack che si possono installare. Le Distribuzioni giocano un ruolo molto simile alle distribuzioni di Linux: rendono più facile installare una collezione di software e anche mantenere versioni coerenti attraverso un set di software.

• Repositories: ROS si basa su una rete di repository di codice, dove diverse istituzioni possono sviluppare e rilasciare i loro componenti software per robot.

• The ROS Wiki: è il forum principale per documentare le informazioni relative a ROS. E’ possibile registrarsi con un account e condividere le proprie documentazioni, offrire correzioni e aggiornamenti, scrivere tutorial , e molto altro ancora.

• Mailing Lists [23]: è il primo canale di comunicazione relativo ai nuovi aggiornamenti di ROS, ossia un forum per porre domande relative al software ROS.

• ROS Answers [24]: un sito di Domande e Risposte per rispondere a tutte le domande relative a ROS.

• Blog: il Willow Garage Blog [25] offre regolari aggiornamenti includendo foto e video.

2.3.4. Names

2.3.4.1. Graph Resource Names

Graph Resource Names rappresentano una struttura di nomi gerarchica che è usata per tutte le risorse in un ROS Computation Graph, come i nomi dei nodes, parametri, topics e

services. Questi nomi sono molto potenti in ROS, e sono fondamentali per costruire sistemi più grandi e complessi. E’ importantissimo capire, quindi, come questi nomi funzionano e come è possibile manipolarli. Prima di descrivere i nomi, ecco alcuni esempi:

• / (the global namespace) • /foo

• /stanford/robot/name • /wg/node1

Graph Resource Names rappresentano un importante meccanismo per offrire l’incapsula-mento in ROS. Ogni risorsa è definita all’interno di un namespace, che può condividere con molte altre risorse. In generale, le risorse possono creare altre risorse all’interno del proprio namespace e possono accedervi all’interno o al livello superiore del proprio namespace. I collegamenti possono essere stabiliti tra risorse che hanno namespace differenti, ma questo generalmente viene realizzato attraverso un codice di integrazione su entrambi i namespa-ce. Questo incapsulamento protegge differenti porzioni del sistema da attacchi di terzi e da accidentali errori dell’utente. I nomi sono risolti relativamente, infatti le risorse non hanno bisogno di essere consapevoli del namespace in cui si trovano. Questo semplifica la program-mazione poiché i nodi che lavorano insieme possono essere scritti come se fossero tutti nel top-level namespace. Quando questi Nodes sono integrati in un sistema più grande, possono essere posizionati in un livello basso del namespace che definisce la loro collezione di codice.

Valid Names

Un nome valido ha le seguenti caratteristiche:

1. Il primo carattere deve essere o un carattere dell’alfabeto ([a-zjA-Z]), tilde (~) or forward slash (/)

2. I caratteri che seguono possono essere alfanumerici ([0-9ja-zjA-Z]), underscores ( ), or forward slashes (/)

Eccezione: i nomi di base (descritti di seguito) non possono avere nè forward slash (/) nè tilde (~).

Resolving

Ci sono quattro tipi di Graph Resource Names: base, relative, global, e private che hanno la seguente sintassi:

• base

• relative/name • /global/name • ~private/name

Di default, la risoluzione del nome viene eseguita in modo relative al namespace del nodo. Per esempio, il nodo /wg/node1 ha come namespace /wg , quindi il nome node2 sarà risolto come /wg/node2 . I nomi che non presentano qualificatori del namespace sono dei nomi base. Questi sono una sottoclasse del nome relativo e hanno le stesse regole di risoluzione. Vengono usati spesso per inizializzare il nome dei nodi. I nomi che iniziano con ”/” sono global, vengono considerati pienamente risolti, anche se non dovrebbero essere usati perchè limitano

la portabilità del codice. I nomi che iniziano con " ~ " sono private. Questi convertono il nome del nodo in quello del namespace. Per esempio, il nodo node1 nel namespace /wg/ ha un namespace private rappresentato da /wg/node1. I nomi privati sono usati anche per passare parametri a specifici nodi via server.

Esempi di risoluzione dei nomi relativi:

• Se il nodo nodo2 nel namespace /wg accede allla risorsa foo, allora risolverà il nome /wg/foo

Esempi di risoluzione dei nomi globali:

• Se il nodo nodo2 nel namespace /wg/ accede alla risorsa /foo, allora risolverà al nome / foo.

Esempi di risoluzione dei nomi privati:

• Se il nodo nodo2 nel namespace /wg/ accede alla risorsa ~ foo, allora risolverà il nome /wg/node2/foo

Remapping

ROS offre anche funzionalità di rimappatura dei nomi quindi alcuni nomi all’interno di un ROS node possono essere rimappati quando il nodo viene lanciato da linea di comando o durante la sua esecuzione

2.3.4.2. Package Resource Names

Package Resource Names sono usati all’interno di ROS con i concetti del Filesystem Level per semplificare il processo di riferimento ai files e a diversi tipi di dati presenti sul disco. I Package Resource Names sono molto semplici, sono rappresentati dal nome della risorsa e dal nome del package a cui è riferita la risorsa. Per esempio, il nome std_msgs/String si riferisce al tipo di messaggio String contenuto nel package std_msgs .

Alcune dei files che possono essere riferiti attraverso i Package Resource Names sono: • Message (msg) types

• Service (srv) types • Node types

I Package Resource Names sono molto simili al percorso dei files, eccetto per il fatto che sono molto più brevi. Questo è dovuto al fatto che ROS riesce a localizzare i packages sul disco e creare altre assunzioni in base al loro contenuto. Per esempio, le descrizioni del messaggio sono sempre immagazzinate nella sottodirectory msg e hanno l’estensione .msg, quindi std_msgs/String è un’abbreviazione per il path/to/std_msgs/msg/String.msg .

Valid Names

I Package Resource Names hanno regole restrittive in quanto spesso usati in codici ge-nerate automaticamente. Per questa ragione, un package non può avere caratteri speciali diversi da un underscore, e devono iniziare con un carattere dell’alfabeto. Un nome valido ha le seguenti caratteristiche:

1. Il primo carattere deve essere un carattere dell’alfabeto ([a-zjA-Z])

2. I caratteri successivi possono essere alfanumerici ([0-9ja-zjA-Z]), underscores (_) op-pure forward slash (/)

2.4. Funzionalità di alto livello

ROS cerca di lasciare la maggior libertà possibile nella definizione dell’architettura da im-plementare nel sistema. Al crescere della dimensione del sistema da costruire è però utile disporre di meccanismi che realizzino in modo semplice funzionalità di più alto livello. Di seguito si riportano alcune di queste funzionalità offerte da ROS.

2.4.1. Che cosa è /tf?

Il package tf fornisce un framework distribuito basato su ROS per il calcolo di posizioni in sistemi di riferimento multipli che variano nel tempo. tf mantiene in particolare le relazioni tra sistemi di riferimento nel tempo, consentendo di trasformare punti, vettori, ecc, tra due qualsiasi sistemi di riferimento in ogni istante temporale. Può quindi essere utilizzato anche per il calcolo della cinematica diretta del robot rispetto un qualsiasi sistema di riferimento in un qualsiasi istante temporale.

Un sistema robotizzato di solito è composto da molti sistemi di riferimento che cambiano nel tempo, come una sistema di riferimento fisso, un base frame, un gripper frame, un head frame, etc. tf tiene traccia di tutti questi frame nel corso del tempo e permette di fare domande del tipo:

• Dove era il head frame rispetto al world frame 5 secondi fa?

• Qual è la posa dell’oggetto nel frame gripper rispetto alla base del robot? • Qual è l’attuale posa del frame base nel frame mappa?

tf può operare in un sistema distribuito. Siamo in grado di vedere nella seguente Figura 4.7 i frame del youBot KUKA in RViz (strumento di visualizzazione di ROS)

Figura 2.6.: Vissualizzazione dei frame del robot youBot su RViz

Quindi, al fine di ottenere informazioni circa la posizione della base del veicolo abbiamo bisogno di sottoscriversi ai topics offerti da tf che riceve e bufferizza tutte le coordinate dei frame che vengono trasmessi nel sistema.

2.4.2. Che cosa è navigation stack?

Lo stack di navigazione si compone di più nodi, i quali collaborano tra di loro, scambian-dosi informazioni sullo stato del robot, la sua posizione e la percezione dell’ambiente. In Figura 2.7 viene mostrata l’architettura ROS che ha il compito di pianificare il movimento della base mobile, evidenziando i nodi coinvolti nell’operazione: il modulo amcl fornisce i dati riguardo il posizionamento del robot; il map server si occupa di tener traccia della map-pa in cui il robot opera, aggiornando le informazioni riguardanti eventuali ostacoli; infine il nodo move base ha il compito di pianificare la traiettoria di movimento utilizzando i dati provenienti dal sensore Kinect e dal nodo amcl .

Lo stack di navigazione tiene traccia della posizione del robot utilizzando una rappresen-tazione di frame di coordinate che determinano l’orientamento e la posizione di un oggetto rispetto ad un frame statico. In questo modo è possibile avere costantemente una relazione tra il robot e la mappa dell’ambiente. Il robot utilizza una mappa statica, generata median-te median-telecontrollo, la quale viene aggiornata a seguito della ricezione dei dati provenienti dalla Kinect o dai sensori Laser.

Lo stack di navigazione è stato progettato per essere il più generale possibile, ma ci sono tre requisiti principali hardware che limitano il suo uso:

• Lo stack di navigazione è pensato sia per robot dotati di differenziali sulle ruote sia per robot olonomi. Si presuppone che la base mobile è controllata inviando comandi veloci-tà desiderata nella forma di: velociveloci-tà di avanzamento frontale, velociveloci-tà di avanzamento laterale e velocità di imbardata.

• Si richiede un laser (o sensore di visione come la Kinect) planare montato da qual-che parte sulla base mobile. Questo laser è usato per la costruzione di mappe e localizzazione.

• Lo stack di navigazione è stato sviluppato per robot quadrati, quindi le performance sarannò migliori su robot che sono quasi quadrati o circolari. Utilizzare lo stack di navigazione su robot di forme e dimensioni arbitrarie, ma può dare luogo a difficoltà in spazi ristretti, come il passaggio da una porta.

Lo stack di navigazione presuppone che il robot utilizza ROS e che pubblichi le informazioni sui sistemi di riferimento mediante lo stack tf. Inoltre, le informazioni provenienti dall’am-biente, registrate grazie ai sensori presenti a bordo del veicolo, vengono utilizzate dallo stack di navigazione per la costruzione della mappa. Lo stack di navigazione accetta solo due tipi di sensori: sensor_msgs/Laserscan o sensor_msgs/PointCloud. Inoltre, ROS richiede che le informazioni odometriche del robot debbano essere pubblicate mediante tf sul topic nav_msgs/odometria. Inoltre lo stack di navigazione può inviare comandi di velocità uti-lizzando un messaggio geometry_msgs/Twist espresso nella base mobile del robot sul topic "cmd_vel".

Tra le numerose funzioni offerte dai vari pacchetti che compongono lo stack possiamo trovare:

• SLAM (simultaneous localization and mapping) map building; • Navigazione autonoma su una mappa nota;

• Possibilità di inviare navigation goal; • Localizzazione;

• Pianificazione di percorso globale e locale; 2.4.2.1. Localizzazione

Una volta definito l’ambiente di lavoro è necessario stabilire dove si trova il robot sulla mappa, determinandone la posizione e orientamento della base. Il problema della localizzazione è uno dei più importanti sui robot mobili, a causa di fattori che possono presentarsi sotto diverse forme. Ad esempio un attuatore non perfettamente collegato ad una ruo ta genera un errore dovuto allo slittamento dell’asse prima che intervenga la frizione dei due oggetti per far muovere la ruota. Un altro errore quasi sempre presente è causato dalle approssimazioni nei calcoli causati dalle operazioni di differenziazione e integrazione, ed ancora l’utilizzo di dati quantizzati, e quindi non precisi, che con il passare del tempo incrementa l’errore di posizionamento.

Esistono tuttavia diverse soluzioni per risolvere questi problemi, ognuna con pregi e difetti, ed il sistema utilizzato varia di norma in base ai sensori disponibili sul robot e in base alle necessità di precisione richieste.

Lo stack di navigazione mette a disposizione l’algoritmo AMCL (Adaptive Monte Carlo Localization). Quest’ultimo è un sistema di localizzazione probabilistico per robot che si muovono su mappe 2D. Questo pacchetto implementa l’approccio Monte Carlo, che utilizza un filtro di particelle per determinare la posa del robot rispetto ad una mappa, utilizzando i dati provenienti dai sensori.

Per lo scopo dell’elaborato abbiamo, per il momento, bypassato il problema della localiz-zazione. Si ipotizza, infatti, che i dati odometrici ricevuti sono privi di errori. In particolare riceviamo la posizione del robot e dei frame usati dal simulatore V-Rep.

2.4.2.2. Mappa ostacoli

Il costmap è una struttura di dati che rappresenta luoghi sicuri oppure ostacoli per il robot mediante una griglia di celle. Solitamente, i valori delle celle sono binari, infatti si rappresenta lo spazio libero o luoghi in cui il robot sarebbe in collisione.

Il robot si muoverà attraverso la mappa utilizzando due tipi di navigazione: globale e/o locale. La navigazione globale viene utilizzata per creare percorsi verso obiettivi situati molto lontani rispetto alla posizione attuale del robot. Mentre la navigazione locale viene utilizzata per creare percorsi in luogi vicini al robot e per evitare gli ostacoli.

Il pacchetto costmap_2d utilizza i dati del sensore e le informazioni dalla mappa statica per costruire una griglia 2D o 3D dell’ambiente. Ci sono due modi principali per inizializzare la struttura costmap: mappa statica oppure mappa rolling_windows. Se la struttura dati costmap è settata come statica allora essa viene inizializzata con una mappa esterna fornita dall’utente. Mentre se la struttura dati costmap è settata a rolling_windows, allora la mappa si mantiene nel centro del robot mentre esso naviga nell’ambiente. In questo modo le informazioni degli ostacoli possono essere lette direttamente nel frame solidale al robot. La mappa costmap esegue ad ogni ciclo di aggiornamento ( alla frequenza specificata dal parametro update_frequency) le seguenti istruzioni:

• legge i dati disponibili provenienti dai sensori

• marca e cancella le celle sulla struttura dati costmap • assegna ad ogni cella i costi appropiati

• effettua il rigonfiamento degli ostacoli basandosi su un raggio di rigonfiamento specifi-cato dall’utente