I sistemi robotici sono entità complesse. Questa affermazione va interpretata sia da un punto di vista di tipo matematico così come da un punto di vista puramente ingegneristico. Di fatto, la cinematica e la dinamica di sistemi robotici anche semplici sono tipicamente non lineari, e la loro modellizzazione, sia di tipo numerico che analitico, in genere implica espressioni o algoritmi risolutivi molto complessi. D'altro canto un robot standard a 6 gradi di libertà, seppure equipaggiato con semplici sensori, può richiedere la gestione di svariate decine di segnali, e in alcuni casi anche centinaia, con l'ovvio vincolo di dover effettuare una elaborazione in tempo reale dei dati acquisiti per poter calcolare gli appropriati segnali di controllo.

Il controllo dei robot sia da un punto di vista teorico che ingegneristico si colloca entro questi due estremi. Da un lato, la comprensione delle proprietà analitiche dei sistemi meccanici può portare a eleganti e sofisticati, sebbene complessi, algoritmi di controllo; dall'altro lato, nella moderna robotica è richiesta una integrazione, anche di tipo sofisticato, di tecnologie hardware e software allo scopo di assicurare il raggiungimento di alte prestazioni da parte del sistema. Perciò, come in molte altre attività dell'ingegneria, lo sviluppo di architetture e sistemi di controllo robotici di concezione moderna si basa sulla ricerca di un ragionevole compromesso fra requisiti di tipo algoritmico e disponibiltà tecniche (nella maggior parte dei casi imposte da vincoli economici e tecnologici).

Nel progetto di architetture di controllo robotico abbiamo due aspetti fondamentali da considerare: modularità e scalabilità. Queste due idee base conducono a ciò che conosciamo come il concetto delle architetture aperte ("open architectures").

Si consideri il diagramma di figura 1. Questo schema rappresenta una possibile architettura di riferimento per lo sviluppo di sistemi di controllo multi-robot. In realtà altri moduli e sottosistemi potrebbero essere presi in considerazione, come ad esempio l'interfaccia uomo-macchina. Questa architettura consente di implementare schemi di controllo per robot di tipo gerarchico [1]. MLC e LLC si riferiscono ai moduli di controllo dedicati al controllo a livello di task (controllo di medio livello, o MLC) ed a livello dei giunti (controllo di basso livello o LLC). L'utilizzo di una architettura basata su bus VME permette lo sviluppo di architetture di tipo multiprocessore.

Figura 1: Schema dell'architettura di controllo. Tipicamente i moduli di I/O possono essere associati a robot o sensori specifici (ad esempio video camere, sensori di forza, sensori di prossimità, ecc...) in modo da consentire implementazioni di scalabili.

Il progetto del software di controllo per sistemi di questo tipo può essere (e frequentemente lo è) un aspetto particolarmente critico, sia in termini di durata che a causa della mancanza di strumenti di programmazione di tipo dedicato..

In genere le varie connessioni dati presenti tra MLC e LLC sono relizzate attraverso "pipe" sincronizzate dal controller a livello di task. Segnali di Interrupt sono usati per avviare i vari moduli e definire i semafori locali, così assicurando la consistenza dei buffer dati in trasmissione/ricezione.

Abbiamo definito l'architettura di controllo con una singola scheda master (appartenente, secondo la filosofia illustrata poco sopra, al MLC) che opera come un dispatcher di messaggi. In tale maniera la sincronizzazione e la gestione dei conflitti nell'accesso al bus sono controllati in modo semplice. In alcuni casi possono essere richiesti anche calcolatori esterni. In tali casi si preferisce implementare canali dati attraverso LAN Ethernet usando strumenti di tipo Socket sebbene non sia possibile effettuare alcun tipo di sincronizzazione della comunicazione, che è di tipo intrinsecamente asincrono.

Le primitive base di comunicazione, così come i driver per le porte di I/O, sono state adattate e trasformate in blocchi SIMULINK. Perciò è possibile progettare i moduli di controllo necessari a livello grafico, mantenendo tutti i meccanismi di comunicazione (chiamate e routine di servizio di interrupt, gestione delle temporizzazioni e dei semafori) nascosti al programmatore. La figura 2 mostra una libreria di blocchi SIMULINK usati per implementare la comunicazione attraverso il bus, e alcuni dei driver usati correntemente per la gestione dei moduli di acquisizione dati.

Figura 2: La maschera corrispondente ai blocchi di comunicazione consente all'utente di definire canali con nome, il rispettivo tempo di campionamento e il numero di dati trasmessi. I driver per i moduli di I/O forniscono una simile interfaccia, ma sono più strettamente correlati con l'hardware di cui sono a supporto.

Gli strumenti e le metodologie descritte nel paragrafo precedente sono state usate per la prima volta per lo sviluppo dell'architettura di controllo del gripper idraulico AMADEUS (sviluppato presso l'università Herriot-Watt da Bruce Davies e Graham Robinson) [2], [5]. La figura 3 mostra la libreria di blocchi di utilità sviluppati nel corso della fase di progetto del sistema di controllo.

Le figure 4, 5 e 6 mostrano rispettivamente le modularità di progetto nel corso dello sviluppo del software di medio e basso livello.

Figura 3: La libreria di blocchi progettata e realizzata per il controllo del gripper AMADEUS.

Figura 4: modularità del progetto del controllo di medio livello.

Figura 5: i dettagli architetturali sono tenuti nascosti durante la fase di progetto.
Il software di controllo è sviluppato nell'ambito di un ambiente di simulazione che rende possibili semplici verifiche dei moduli sviluppati.

Figura 6: moduli di comunicazione ed I/O sono gestiti dal programmatore come porte di I/O.

I blocchi SIMULINK relativi alla comunicazione dati stabiliscono il corretto cammino dei dati lungo il bus VME (blocchi To LLC, From LLC, To MLC, From MLC, con ovvio significato dei nomi) e lungo un collegamento ethernet per la connessione di un modulo di interfaccia uomo-macchina (blocchi To HLC and From HLC) che è implementata su una workstation remota.

Lo stesso approccio al progetto del controllo è attualmente in uso per l'implementazione del sistema di controllo della DIST-HAND mostrata in figura 7.

Figura 7 : la DIST-HAND è un robot a 20 gradi di libertà per applicazioni di manipolazione fine.

In conclusione è interessante sottolineare come librerie di software C specifiche per il calcolo matriciale e per la valutazione della cinematica diretta finita e differenziale di un generico robot con un numero arbitrario di gradi di libertà, siano state sviluppate come strumenti di tipo custom [6], [7] e siano attualmente in fase di addatamento per poter essere utilizzate nell'ambito dell'ambiente SIMULINK.

Inoltre, uno strumento per la modellizzazione automatizzata della cinematica e della dinamica di robot con struttura meccanica arbitraria utilizzante uno strumento di manipolazione simbolica di equazioni è stato sviluppato congiuntamente con l'università di Pisa [8]. L'uscita del programma è un insieme di blocchi adatto per effettuare simulazioni con SIMULINK. L'estensione di questo strumento per applicazioni di controllo di tipo real-time è in fase di sviluppo.

Le applicazioni citate precedentemente sono state sviluppate con un uno strumento software che non prevede ancora la possibilità di una completa definizione della architettura di controllo, nel senso che la allocazione dei task sui vari processori viene svolta manualmente e non può essere definita a livello di schema di controllo. E' attualmente in fase di implementazione un tool che consentirà all'utente di definire uno schema di controllo multiprocessore, come quello esemplificato in figura 8.

Figura 8: schema di controllo multirobot-multiprocessore basato sull'utilizzo di SIMULINK

In questo schema il blocco mascherato contiene l'informazione relativa alla CPU su cui tale insieme di task deve essere allocato; sfruttando tale informazione il tool di sviluppo verifica quali siano i blocchi appartenenti a CPU diverse, e richiede all'utente di specificare quale tipo di comunicazione (fra quelle disponibili in una apposita libreria di blocchi, quali socket, code asincrone, ecc...) intenda utilizzare. In tal caso si ottiene automaticamente uno schema aggiornato secondo quanto contenuto in figura 9.

Figura 9: schema SIMULINK multiprocessore con meccanismi di comunicazione tra CPU esplicitati.

Completata la fase di design, il sistema automaticamente separerà lo schema complessivo nei vari sottoschemi, uno per ciascuna CPU, ricadendo nel caso applicativo (monoprocessore) incontrato già nelle situazioni precedenti.

Questo lavoro è stato parzialmente supportato dal progetto "AMADEUS Phase 2 - Advanced Manipulator for Deep Underwater Sampling" finanziato dalla Comunità Europea con contratto MAS3-CT95-0024.