I robot autonomi sono sistemi complessi che richiedono l'interazione tra numerosi componenti eterogenei (software e hardware). I middleware robotici nascono come risposta all'aumento della complessità delle applicazioni robotiche e della vasta gamma di hardware. Sono progettati per promuovere l'integrazione di nuove tecnologie, semplificare la progettazione del software nascondendo la complessità della comunicazione di basso livello e l'eterogeneità dei sensori, migliorare la qualità del software, nonchè per ridurre i costi massimizzando la produzione. Questo articolo presenta una panoramica dei middleware robotici più utilizzati descrivendone le caratteristiche che motivano la scelta dell'uno rispetto all'altro. L'attenzione passa poi al Robot Operating System (ROS), il più utilizzato sia in ambito accademico che commerciale. L'obiettivo è assistere il lettore nella scelta del più adatto a seconda dalla specifica applicazione di studio.
Introduzione
Un middleware robotico è un livello di astrazione che risiede tra il sistema operativo (OS, Operating System) e le applicazioni software (come mostrato nella Figura 1). È progettato per gestire l'eterogeneità dell'hardware, migliorare la qualità dell'applicazione software, semplificare la progettazione del software e ridurre i costi di sviluppo. Allo sviluppatore è richiesto solo di costruire la logica o l'algoritmo come componente assestante, dopodiché il componente può essere combinato ed integrato con altri componenti già esistenti nell'infrastruttura software. Inoltre, se lo sviluppatore vuole modificare e migliorare il proprio componente, è sufficiente che sostituisca il componente attuale con il nuovo mantenendo l'intera struttura di comunicazione inalterata. Questo è possibile grazie all'integrazione di una struttura di programmazione orientata agli oggetti. Ciò consente di ridurre i tempi di sviluppo del software, concentrando l'attenzione sull'esperimento.
I principali vantaggi nell'utilizzo di middleware robotici sono da ricercare (i) nella modularità della struttura software; (ii) nell'astrazione dall'architettura hardware, e quindi di nascondere i dettagli specifici del dispositivo di basso livello consentendo di mantenere un'indipendenza dalla piattaforma fisica migliorando la portabilità del contributo software. I middleware sono scalabili ed aggiornabili, seguendo la crescita dei diversi componenti che li costituiscono. Ancora, sono facili da usare e manutenere, robusti, affidabili, efficienti, flessibili e supportano il parallelismo per la realizzazione di sistemi distribuiti. Infine, consentono la modifica dei file di configurazione del flusso di controllo e del flusso di dati in fase di esecuzione (a run time). Tutto ciò è reso possibile grazie alla possibilità di lavorare in real-time.
Definizioni e Software per Robots
Per poter parlare di software per robot, è necessario dapprima dare qualche definizione. Un middleware robotico è definito come "una classe di tecnologie software progettate per aiutare a gestire la complessità e l'eterogeneità insite in sistemi distribuiti". È definito come uno "strato di software sopra il sistema operativo ma sotto il programma applicativo, che fornisce un'astrazione di programmazione comune in un sistema distribuito". In questa sezione, vengono riportate le caratteristiche di diversi middleware per la robotica come Player, CLARAty, Miro, Orca e OPRoS, Webots, ROS, e OpenRTM.
Il progetto Player nasce presso l'Università del Sud California agli inizi degli anni 2000. Fondamentalmente, Player è un "archivio di dispositivi distribuiti server" per robot, sensori e attuatori. Un programma client comunica con Player, in esecuzione sul robot, utilizzando una connessione socket TCP separata per il trasferimento dei dati. Al contrario, l'architettura a strati accoppiati per l'autonomia robotica (CLARAty) nasce come tentativo della NASA, attraverso la collaborazione con il Jet Propulsion Laboratory del California Institute of Technology, Ames Research Center, Carnegie Mellon University e l'Università del Minnesota. Ancora, OpenRTMaist è una piattaforma software sviluppata dall'Istituto Nazionale di scienza industriale avanzata e tecnologia intelligente, e l'Istituto di ricerca sui sistemi americano. Infine, Miro è un middleware per la robotica orientata agli oggetti sviluppato dall'Università di Ulm, in Germania. Orca e OPRoS sono piattaforme aperte per Robotic Services, progettate dal programma di ricerca e sviluppo IT del Ministero dell'Economia e della Conoscenza della Corea. Nascono come framework aperti basati su componenti open-source. Webots è un pacchetto di simulazione robot commerciale per la prototipazione rapida e la simulazione di robot mobili. Infine, ROS (Robot Operating System) è un middleware robotico "peer-to-peer" abbastanza leggero, basato sullo scambio di messaggi attraverso nodi di una rete, utilizzando protocollo UDP.
Diamo adesso la definizione di Robot Toolkit: un kit di strumenti per robot, ovvero un insieme di strumenti software utilizzato dagli sviluppatori per fornire loro strutture volte a creare applicazioni robotiche. Tra questi si annovera CARMEN e Pyro, giusto per citarne qualcuno. Si tratta tipicamente di una raccolta open-source di software per il controllo di robot, scritti in diversi linguaggi di programmazione, tra cui C/C++/Python, che fornisce una serie di astrazioni atte a consentire agli sviluppatori di scrivere programmi robotici indipendenti dalla piattaforma di utilizzo.
Le piattaforme
Passiamo ora a descrivere le piattaforme middleware più note, spiegando le ragioni che dovrebbero portare alla scelta di una piuttosto che l'altra. L'architettura CLARAty ha due livelli distinti (come mostrato nella Figura 2): un livello funzionale (Functional layer) ed uno decisionale (Decision layer). Lo strato funzionale include una serie di componenti generici come "interfacce I/O digitali e analogiche, controllo e coordinazione del movimento, locomozione, manipolazione, visione, navigazione, mappatura, valutazione del terreno, pianificazione di percorso, stima, simulazione e comportamento del sistema". Inoltre, a questo livello, sono implementati algoritmi di controllo come la manipolazione basata su sensori, il tracciamento visivo del bersaglio e la navigazione basata sulla visione. Al contrario, il livello decisionale è un motore globale che ragiona sulle risorse di sistema, il suo stato, l'ambiente circostante ed i vincoli di missione. Il livello decisionale si occupa della pianificazione ma anche dell'attuazione delle attività. Inoltre, monitora l'esecuzione dell'intero processo verificando il rispetto dei vincoli di missione. La comunicazione tra i due layer è di tipo client-server utilizzando uno schema di comunicazione strutturato nella forma pubblicazione/sottoscrizione.
Webots è organizzato con un'interfaccia di controllo ad oggetti per robot. Gli oggetti corrispondono a dispositivi robotici come ruote differenziali, fotocamera, sensore di distanza, telemetro laser e accelerometro. Due meccanismi consentono di scambiare dati tra i diversi moduli: architettura a lavagna (blackboard architecture) e mutua esclusione (mutual exclusion) rispettivamente utilizzati per strutture dati di grandi e piccole dimensioni.
MIRO è costituito da tre strati (come mostrato nella Figura 3): dispositivi (devices), servizi (services) e i livelli di comunicazione (applications). Il livello del dispositivo, che dipende dalla piattaforma, fornisce astrazioni di interfaccia per l'hardware di basso livello (questo comprende dispositivi come sensori e attuatori). La CORBA Interface Definition Language (IDL) si occupa della comunicazione tra i diversi layer. Al contrario, il Miro Class Framework fornisce una serie di applicazioni, anche dette moduli, funzionali per il controllo di robot mobili, come i moduli per la mappatura, l'auto-localizzazione, la pianificazione di percorso, la registrazione e visualizzazione in ambiente di realtà virtuale.
Marie si compone di tre livelli: Application, Component e Core Layers. I livelli Applicazione/Componente forniscono alcuni strumenti per la creazione di applicazioni/componenti. Il Core Layer è costituito da strumenti di basso livello per la comunicazione, gestione dei dati e controllo I/O. Inoltre, Marie utilizza un file unità di controllo centralizzato denominato Mediator Design Pattern (MDP) per interagire con ciascuna applicazione in modo indipendente, come mostrato nella Figura 4. Marie usa quattro componenti funzionali per l'interazione e la comunicazione tra cui le applicazioni tramite un'unità di controllo centralizzata (CCU) basato su MDP: Application Adapter (AA), Adattatori di Comunicazione (CA, Communication Adapter), Communication Manager (CM) e Gestione Applicazioni (AM, Application Manager). L'AA è responsabile della comunicazione tra la CCU e le applicazioni.
Per l'integrazione con il sistema, ogni applicazione ha il proprio AA che si occupa di incapsulare la comunicazione attraverso meccanismi a servizi e file di configurazione. L'AC è responsabile della traduzione delle informazioni tra diversi protocolli e meccanismi di comunicazione consentendo il corretto scambio dei messaggi. I meccanismi più comuni di comunicazione sono Mailbox ("buffer di dati asincrono tra componenti"), SharedMap ("inoltra i dati in arrivo a più uscite"), Splitter ("un push-in/pull-out di strutture dati utilizzato per memorizzare gli stati del sistema a cui possono accedere molti componenti) e Switch (invia solo uno dei suoi ingressi alla porta di uscita). Il Communication Manager è responsabile per la creazione e la gestione dei collegamenti di comunicazione tra Adattatori per Applicazioni. Infine, l'AM è responsabile del controllo e la gestione dell'intero sistema, coordinando i vari stati. Si occupa, inoltre, di configurare e controllare tutti i componenti disponibili nel sistema.
ATTENZIONE: quello che hai appena letto è solo un estratto, l'Articolo Tecnico completo è composto da ben 2487 parole ed è riservato agli ABBONATI. Con l'Abbonamento avrai anche accesso a tutti gli altri Articoli Tecnici che potrai leggere in formato PDF per un anno. ABBONATI ORA, è semplice e sicuro.