Capitolo 5 Il Software del Sistema


CAPITOLO 5


IL SOFTWARE DEL SISTEMA









In questo capitolo verrà descritto il sistema realizzato dal punto di vista implementativo : prima verranno esposte le ipotesi di lavoro per l’integrazione fra base mobile e manipolatore , poi si entrerà nel dettaglio degli algoritmi che permettono la comunicazione , la pianificazione del moto e la previsione delle collisioni . Questi programmi , cooperando col programma di visione descritto nel capitolo 3 e col programma per il grasping del capitolo 4 , consentono di portare a termine il task manipolativo oggetto di questa tesi . Come anticipato nell’introduzione si sono utilizzati tre linguaggi di programmazione : l’algoritmo di comunicazione è scritto in linguaggio C , perché è ottenuto modificando il programma PCCAN.C fornito dal costruttore . Il pianificatore combina MATLAB e LABVIEW : l’uso del primo si è reso necessario per i motivi esposti nel capitolo 2 , quello del secondo per quanto detto nel capitolo 3 . In questo modo si è riusciti a combinare i vantaggi dei due ambienti di programmazione : il LABVIEW consente una gestione efficiente dell’hardware ( scheda di acquisizione ) e un’interfaccia user-friendly e il MATLAB realizza le elaborazioni matematiche che in linguaggio grafico sarebbe complicato eseguire . Infine il programma di prevenzione delle collisioni è stato realizzato interamente in MATLAB.

5.1 Le caratteristiche del manipolatore mobile


Le basi mobili presenti presso il laboratorio di robotica avanzata candidate ad essere integrate con il MANUS sono una carrozzina modello TGR Explorer , una piattaforma mobile LABMATE ed altri robot di recente produzione ; a seconda di quale verrà scelta si otterrà una delle due tipologie di manipolatori mobili presentate nel capitolo 1: postazione mobile autonoma o su carrozzella .

Figura 5.1 : La carrozzella motorizzata TGR Explorer

Figura 5.2 : Il robot mobile LABMATE


Esula tuttavia dall’oggetto di questa tesi scegliere una piattaforma specifica fra quelle presentate e realizzare fisicamente l’integrazione : trattandosi del primo lavoro presso il DIIGA ad utilizzare il MANUS , ci si è concentrati prevalentemente sul setup del sistema . L’integrazione con una base mobile ha costituito piuttosto una prospettiva in base alla quale pianificare il moto del MANUS e strutturare l’ambiente di lavoro , come verrà esposto più avanti. Facendo riferimento alla classificazione dei manipolatori mobili secondo i criteri del paragrafo 1.1 , in fase di pianificazione si è scelto di realizzare un sistema debolmente accoppiato ( loose cooperation ) . Questa soluzione , fra le due presentate , è quella che permette di astrarsi dalla particolare piattaforma adottata e realizzare un sistema compatibile con qualsiasi base mobile verrà scelta nei lavori futuri .

Figura 5.3 : I tre gradi di libertà di un robot mobile che si muove su un piano


La realizzazione del manipolatore mobile si basa sulla seguente considerazione , valida indipendentemente dalla particolare base mobile considerata : se il sistema si muove in un ambiente domestico privo di scalini o rampe , cioè su un piano a z costante , la base sarà dotata di 3 gradi di libertà , due di rotazione e uno di traslazione , ma in generale non potrà assumere tutte le configurazioni possibili per limitazioni dovute al modello cinematico . Ci si limitati a supporre che , data la posizione e l’orientamento iniziale indicati in figura 5.3 , la base sia in grado di effettuare rotazioni , di spostarsi in posizioni lungo l’asse ed in posizioni lungo . Non è stata imposta alcuna limitazione sulle posizioni assunte né sul loro numero , ed , che può essere anche nullo qualora si voglia passare da 3 a 2 gradi di libertà o anche ad un solo grado di libertà : gli algoritmi esposti nel paragrafo 5.3 sono validi quindi anche per basi vincolate a muoversi in una sola direzione.

Figura 5.4 : La quantizzazione dei gradi di libertà della base mobile


Facendo riferimento allo schema a blocchi di figura 1.1 sono stati implementati il supervisore ed il pianificatore del MANUS , mentre per quanto riguarda il pianificatore della base mobile ci si limita a calcolare la posizione e l’orientamento secondo i criteri che saranno esposti più avanti . La quantificazione dello spazio delle configurazioni permette di realizzare il supervisore come un algoritmo di ricerca nello spazio delle soluzioni : per ogni possibile configurazione assunta dalla base , il supervisore richiama offline il pianificatore del MANUS , calcola la traiettoria e per essa determina la distanza fra i link a rischio di collisione , restituendo quella a minimo rischio . I dettagli di questo calcolo saranno approfonditi nel paragrafo 5.2. La traiettoria priva di collisioni viene poi inviata al pianificatore del MANUS per eseguire il movimento . I valori di utilizzati per testare gli algoritmi sono indicati in tabella 5.1.


Tabella 5.1 : : Gli spostamenti ipotizzati per la base mobile rispetto alla posizione iniziale

Spostamenti lungo l’asse x ( )

+40cm

+20cm

0

-20cm

-20cm

Spostamenti lungo l’asse y ( )

+40cm

+20cm

0

-20cm

-40cm

Rotazioni attorno all’asse del robot mobile (

-90°

0

+90°

+180°


Per quanto riguarda la strutturazione dell’ambiente di lavoro del robot si è cercato di formulare ipotesi che non comportino negli sviluppi futuri il ricorso a sistemi di localizzazione assoluta : dalla figura 5.4 si può notare che gli spostamenti sono sempre espressi rispetto al sistema solidale alla base piuttosto che in un sistema di riferimento fisso.

Inoltre , laddove si è resa necessaria un’informazione aggiuntiva per ricavare la profondità da una sola immagine , si è fatto in modo che questa coincidesse con la coordinata z del sistema di riferimento fisso e non con le coordinate x o y , che avrebbero ugualmente necessitato di sistemi di localizzazione assoluta .



5.2 Il driver per il computer-box


Sebbene non si tratti di un driver in senso stretto , con le caratteristiche che contraddistinguono i drivers degli odierni dispositivi periferici , si è deciso di chiamare in questo modo il programma che si occupa della comunicazione fra PC e MANUS , perché presenta alcune caratteristiche che lo accomunano a questo genere di programmi . Una di queste è la necessità di offrire un’interfaccia trasparente ai programmi di livello superiore , che consenta loro di astrarsi dai dettagli implementativi del dispositivo controllato : si è così permesso al pianificatore di limitarsi a fornire la posizione da raggiungere , senza doversi curare delle caratteristiche del computer-box descritte nel capitolo precedente .

Inoltre fra i programmi descritti nell’introduzione del capitolo , driver.c è quello che si spinge più a basso livello verso l’Hardware del sistema ed è l’unico fra questi per il quale va valutata la compatibilità con il sistema operativo , in modo da garantire la portabilità del codice per gli sviluppi futuri . L’esito di questa valutazione permette di affermare che driver.c è completamente compatibile con il DOS e con sistemi operativi che, come Windows 98 , permettono di richiamare applicazioni compilate in DOS . La possibilità di compilare invece il codice direttamente in Windows 98 , o in altri sistemi operativi come LINUX , è legata al compilatore scelto e ai file di intestazione accettati . E’ stato necessario utilizzare headers come conio.h e winbase.h che non rientrano nel C standard e possono quindi non essere accettati da alcuni compilatori ; come conseguenza si potrebbe non disporre di funzioni fondamentali come inp( ) e outp( ) per la lettura e scrittura sui registri del PCA 82C200 , della funzione kbhit( ) per l’interazione con l’utente , o ancora della funzione sleep( ) che riduce l’occupazione della CPU quando il driver è in attesa dei comandi da LABVIEW . La sostituzione di queste funzioni con alcune definite ad hoc ha permesso di compilare i file sorgenti driver_linux.c e dr_win98.c , che presentano però funzionalità limitate rispetto a driver.c : il primo è una semplice versione LINUX del programma di telemanipolazione originario ; il secondo può creare problemi nella commutazione fra controllo dell’utente e controllo da LABVIEW , per l’elevata occupazione della CPU durante questo passaggio critico .


Figura 5.5 : La schermata iniziale del programma driver.exe


L’interfaccia utente del driver si presenta come in figura 5.5 e mantiene la compatibilità col programma PCCAN a partire dal quale è stato ottenuto . Conserva infatti la capacità di svolgere le funzioni originarie :

Rispetto al PCCAN sono però state introdotte alcune importanti funzioni:

Queste estensioni del programma sono indispensabili se si vuole conferire al MANUS un certo livello di autonomia ed evitare il continuo ricorso all’interazione con l’utente , come è invece necessario utilizzando il PCCAN .


Figura 5.6 La Flow Chart del programma driver.exe


Il principio di funzionamento del programma è semplice e riprende il paradigma di comunicazione fra computer-box e Can Protocol Controller mostrato in tabella 4.6 . Nel diagramma di flusso presentato in figura 5.6 si nota la presenza di due cicli : uno più interno , sincronizzato in modo rigido dall’arrivo dei Data Frames dal computer box , che termina con l’arrivo del Remote Frame di richiesta degli ingressi ; uno più esterno , che comprende il calcolo delle velocità in base al funzionamento selezionato : controllo cartesiano o sui giunti , controllo di posizione o modalità start/stop , spostamenti comandati dall’utente o da applicazioni esterne. La selezione di questi modalità avviene attraverso dei flags , che sono definiti come variabili globali e vengono modificati dalle funzioni del programma . I significati e i valori assunti dai flags sono riportati in tabella 5.2.

Tabella 5.2 : I flag utilizzati per selezionare la modalità di funzionamento

Variabile Flag

Significato

Valori

Azione associata

Cbox

Selezione del Cbox

0

Inizializzazione

1

Controllo Cartesiano

4

Controllo sui giunti

5

Procedura Fold In

6

Procedura Fold Out

Flag_controllo

_remoto

Selezione sorgente degli ingressi

0

Ingressi forniti da prompt dall’utente

1

Ingressi forniti da una applicazione esterna

Flag_assi[1]

Controllo di posizione per l’asse x o il giunto 1

0

Modifica la velocità in base alla posizione

1

Lascia la velocità invariata

Flag_assi[2]

Controllo di posizione per l’asse y o il giunto 2

0

Modifica la velocità in base alla posizione

1

Lascia la velocità invariata

Flag_assi[3]

Controllo di posizione per l’asse z o il giunto 3

0

Modifica la velocità in base alla posizione

1

Lascia la velocità invariata

Flag_assi[4]

Controllo di posizione per l’angolo yaw o il giunto 4

0

Modifica la velocità in base alla posizione

1

Lascia la velocità invariata

Flag_assi[5]

Controllo di posizione per l’angolo roll o il giunto 5

0

Modifica la velocità in base alla posizione

1

Lascia la velocità invariata

Flag_assi[6]

Controllo di posizione per l’angolo pitch o il giunto 6

0

Modifica la velocità in base alla posizione

1

Lascia la velocità invariata


La conversione posizione desiderata – velocità di controllo avviene in due fasi , come illustrato in figura 5.7 : una prima fase in cui la posizione è lontana da quella desiderata e l’avvicinamento è ottenuto a velocità più sostenuta e una seconda in cui viene raggiunta la posizione desiderata mantenendo una velocità ridotta per un tempo noto . La velocità iniziale è fissata ad inizio programma definendo le quantità DES_CART_MAX , per il controllo cartesiano , e DES_JOINT_MAX , per il controllo diretto dei giunti . Prendendo rispettivamente 10 unità e 2 unità si ha :

e

;

Nella seconda fase l’avvicinamento avviene a velocità ridotta per posizionare al meglio la pinza . Le costanti DES_CART_MIN o DES_JOINT_MIN vengono mantenute per un numero di cicli tale che :


.


Se la differenza non è un multiplo della velocità minima , l’ultima iterazione del ciclo avviene ad una velocità pari allo spostamento mancante ; una volta raggiunta la posizione desiderata vengono annullate la velocità e il flag di controllo .


Figura 5.7 : Il principio adottato per il posizionamento


Nella modalità cartesiana la velocità minima va scelta come compromesso fra due esigenze contrastanti : da una parte la precisione del posizionamento , che richiederebbe di adottare il limite minimo consentito dalla quantificazione , dall’altra la necessità di vincere le coppie di attrito ; per quanto detto nel paragrafo 4.1.2 se la velocità inviata è troppo piccola la coppia motrice del motore potrebbe essere inferiore alle coppie di attrito e non dare luogo ad alcun spostamento . Dopo alcune prove si è osservato che un buon compromesso si ha scegliendo:


Si tratta di una velocità piuttosto vicina al limite minimo consentito dal computer-box , che da luogo a buone prestazioni per il controllo di posizione se il motore è già in movimento dalla fase precedente . Se invece si parte direttamente dalla seconda fase , DES_CART_MIN determina una coppia di spunto che può essere inferiore all’attrito . Si tratta di pochi casi sporadici , che si verificano quando la posizione richiesta è vicina a quella attuale : in questa situazione è consigliabile prima allontanarsi dal valore desiderato per arrivarvi poi con il motore già in movimento.

Nella modalità di controllo diretto dei giunti questo problema non si pone , perché il limite minimo posto dalla quantizzazione delle velocità angolari è già grande . Prendendo infatti il quanto minimo di velocità si ha:

che da luogo a coppie certamente in grado di vincere l’attrito ma non adatte ad un posizionamento preciso . Per questo motivo il programma garantisce il raggiungimento di una posizione entro un intervallo di dal valore desiderato , anche se il più delle volte si riesce a posizionarsi con un errore di .

Resta da chiarire come il programma legga gli ingressi dalle applicazioni esterne e fornisca loro lo stato del sistema : questo aspetto verrà trattato nel paragrafo 5.3 trattando il pianificatore del moto.


5.3 La prevenzione delle collisioni


La prevenzione delle collisioni del sistema si basa sulla funzione collision_free.m , riportata in appendice B . Per realizzarla si è studiato l’ingombro dei bracci del MANUS , così da comprendere quali coppie di link sono soggette a rischio di collisione . Assumendo una forma cilindrica per i primi 4 link e approssimando la pinza parallelepipedale , l’ingombro è noto quando si conoscano le altezze ed i raggi dei cilindri e la lunghezza e la larghezza del parallelepipedo . I raggi sono stati approssimati per eccesso onde mantenere un certo margine di sicurezza nel calcolo delle distanze .

Tabella 5.3 : L’ingombro dei link del MANUS

Link

Lunghezza

Raggio

0

470mm

80mm

1

210mm

50mm

2

400mm

40mm

4

320mm

30mm

6

160mm

30mm*






Considerando i valori riportati in tabella 5.3 si è concluso che le collisioni sono possibili solo fra la pinza ( indicata come link 6 ) ed i link 0 , link 1 , link 2. Si è inoltre reso necessario prevenire le collisioni con l’unità di sollevamento che sostiene il MANUS : per seguire un approccio più generale si è scelto di considerare la lift unit come un qualsiasi oggetto dell’ambiente e prevenire quindi le collisioni anche con eventuali ostacoli nello spazio di lavoro del robot di cui siano noti ingombro e posizione . La modellazione degli ostacoli avviene tramite una matrice di punti salvata nel database ostacoli_ambiente.mat , che viene caricato all’avvio della funzione .




Figura 5.8 : La numerazione dei link del MANUS in fase di collision-avoidance


La numerazione dei bracci a cui si fa riferimento è quella riportata in figura 5.8 , dalla quale si può osservare che l’occupazione dei link non è deducibile a partire dai soli parametri di Denavit-Hartenberg . Infatti il secondo e terzo giunto del MANUS realizzano quello che in letteratura è noto come robot 2R , cioè una struttura di posizionamento su un piano mediante due giunti rotoidali ad assi paralleli : il contributo allo spostamento dovuto a questa struttura non dipende dall’ascissa dei giunti lungo i due assi . Il modello cinematico assume una per questi due giunti una posizione che semplifica la matrice di trasformazione cinematica , ma che non coincide con l’ubicazione reale : di questo fatto si è dovuto tener conto in fase di costruzione dei cilindri , altrimenti in luogo del link1 e del link 2 si avrebbe avuto un unico cilindro con l’asse sulla congiungente del giunto 2 e del giunto 3 , come mostrato in figura 5.8 .

Data una triaiettoria , specificata attraverso i valori assunti dalle variabili di giunto , la funzione collision_free.m calcola i punti dello spazio occupati dei cilindri in corrispondenza di ciascuna configurazione assunta dal robot . Sulla superficie di questi cilindri vengono poi presi a campione un certo numero di punti , selezionabile dall’utente attraverso l’ingresso n della funzione . Questo parametro rappresenta il numero di punti equidistanti presi lungo l’asse del cilindro : fissati questi punti , restano determinate altrettante sezioni rette e le circonferenze in esse contenute vengono a loro volta campionate con n punti . Pertanto una volta fissato n , per ciascun cilindro vengono presi punti , come mostrato in figura 5.9 nel caso di n=3 .

Figura 5.9 : La scelta dei punti per il campionamento del cilindro


A partire dai link così campionati , per ciascun punto della traiettoria la funzione considera le coppie di bracci a rischio di collisione e ne calcola la distanza minima , restituendo un vettore con la struttura indicata in tabella 5.4.


Tabella 5.4 : La struttura dell’uscita della funzione collision_free.m

Colonne

1

2

3

4

5

6

7

8

9

10


Il significato dei parametri restituiti è il seguente:


In figura 5.10 è rappresentato l’esempio di una traiettoria costituita da 5 configurazioni successive assunte dal robot : una posizione iniziale , una finale e tre posizioni interpolate. L’asse dei link viene campionato con 10 punti , per cui ciascun cilindro è costituito da 100 elementi , e il minimo viene toccato in corrispondenza della configurazione finale , come opportunamente segnalato dall’algoritmo.

Figure 5.10 a,b,c,d,e : il calcolo delle distanze per una traiettoria con 5 punti interpolati


La scelta di campionare l’asse con 10 punti non è casuale : si è infatti osservato che valori soddisfacenti per il parametro n , che non facciano crescere eccessivamente il tempo di calcolo e al tempo stesso permettano di monitorare tutte le regioni del cilindro , sono nell’intorno di questo valore . In figura 5.11 vengono confrontati tempi di calcolo e distanze minime per n che varia in un range e si può osservare proprio come , per n=10 , si raggiunga un buon compromesso fra queste due esigenze.

Figura 5.11 a,b : le distanze minime ed i tempi di calcolo in funzione del numero di punti sui cilindri


5.4 La pianificazione del moto


La pianificazione del moto è realizzata mediante le funzioni pianificatore_collision_free_mobile.m e pianificatore_collision_free.m , richiamate e coordinate dal VI di LABVIEW pianificatore_manipolatore_mobile.vi , il cui pannello di controllo è mostrato in figura 5.12 . Il VI provvede anche a interfacciare le funzioni col MANUS , secondo le modalità che verranno descritte nel paragrafo 5.5 .


Figura 5.12 : Il pannello di controllo del pianificatore


Facendo riferimento allo schema di controllo di un manipolatore mobile debolmente accoppiato presentato nel paragrafo 1.1 , le due funzioni possono essere identificate rispettivamente con il pianificatore del manipolatore e il pianificatore del manipolatore mobile complessivo . I parametri ricevuti in ingresso dal pianificatore del MANUS sono:

A partire da queste grandezze vengono svolte le seguenti operazioni:

  1. inversione della cinematica per il punto finale

  2. interpolazione della traiettoria

  3. calcolo della distanza minima fra i link per ciascuna possibile traiettoria.

  4. scelta della traiettoria migliore

La cinematica inversa è stata calcolata analiticamente mediante il procedimento descritto nel paragrafo 1.2.4 e implementata nella funzione cinematica_inversa_gradi.m , riportata in appendice B : fornisce le variabili di giunto direttamente in gradi e nel range utilizzato dal programma di controllo . Il driver fornisce infatti le variabili di giunto entro gli intervalli descritti in tabella 5.5 : l’anomalia per la terza variabile è dovuta al feedback del computer-box , che restituisce la somma in luogo dell’angolo , e si è provveduto via software ad effettuare la conversione . La limitazione su è invece dovuta alla meccanica del sistema che è stata esposta nel capitolo precedente.


Tabella 5.5 : I range delle variabili di giunto

Variabile

min

Max

-180°

180°

-180°

180°

-270°

90°

-180°

180°

0

145°

-180°

180


L’interpolazione della traiettoria è di tipo punto-punto nello spazio dei giunti con polinomio cubico ed è implementata dalla funzione interp_cubica.m . Questa funzione assume per le singole variabili di giunto l’andamento :



in cui i coefficienti sono calcolati imponendo che



Prestazioni migliori si otterrebbero inviando direttamente al computer box le derivate : questa soluzione è però impedita dalla quantizzazione grossolana con cui le velocità sono rappresentate dal sistema di controllo del MANUS . Per lo stesso motivo le velocità iniziali e finali non saranno esattamente nulle , ma si è comunque osservato che se i punti interpolanti sono in numero sufficiente l’inizio e la fine del movimento sono smooth , vicini cioè alle condizioni ideali e .

Se il problema cinematico inverso ammette più soluzioni esiste una traiettoria possibile per ciascuna di esse : il pianificatore invoca la funzione collision_free.m e sceglie quale fra queste da luogo al minimo rischio di collisione , cioè alla massima distanza fra i link . Si tratta di una sorta di ottimizzazione ottenuta con un indice max-min : detto il numero di traiettorie scaturito dall’inversione della cinematica , il numero di link del MANUS a rischio di collisione ed il numero di punti di interpolazione della traiettoria , il pianificatore cerca gli indici , , per i quali si ha


.


La quantità è la distanza fra il link ed il link all’istante della -esima traiettoria . L’uscita della funzione è costituita da una matrice contenente le variabili di giunto per la traiettoria prescelta , i valori della distanza ottima , gli indici e e l’istante per cui questa viene raggiunta , secondo la struttura indicata in tabella 5.6.


Tabella 5.6 : La struttura della matrice restituita dal pianificatore del manipolatore


Colonne

1

2

3

4

5

6

7

8

9

10

11

Righe

1

2

3

/

/

/

4

/

/

/

..

/

/

/

/

m

/

/

/

/



Il pianificatore del manipolatore mobile complessivo opera alla stessa maniera , scegliendo però fra un numero maggiore di traiettorie : teoricamente la stessa procedura andrebbe ripetuta per tutte quelle che hanno origine dai possibili spostamenti della base descritti nel paragrafo 5.1 . Queste traiettorie diventano però troppo numerore al crescere di :

,


dove è il numero di soluzioni della cinematica inversa per la k-sima combinazione fra spostamenti e rotazioni della base. Con i valori di del paragrafo 2.3.1 e supponendo di avere 2 soluzioni per ciascuna configurazione ( si è osservato che solitamente o non ci sono soluzioni o ce ne sono 4 ) , la ricerca andrebbe effettuata fra traiettorie possibili . Si capisce che un simile approccio comporta una lunga attesa prima della pianificazione vera e propria , pertanto si è scelto di far terminare l’algoritmo quando si trova un percorso con distanza minima sopra una soglia opportuna , che viene specificata dall’utente . L’uscita della funzione pianificatore_collision_free_mobile.m riprende la struttura dell’uscita del pianificatore del MANUS e aggiunge in fondo alla riga 3 gli spostamenti richiesti per la base , come mostrato in tabella 5.7 .


Tabella 5.7 : l’uscita del pianificatore per il manipolatore mobile


Colonne

1

2

3

4

5

6

7

8

9

10

11

Righe

1

2

3

4

/

/

/

..

/

/

/

/

m

/

/

/

/


Il programma di pianificazione complessivo è costituito dai blocchi evidenziati in figura 5.13 , dove in blu sono rappresentate le parti realizzate in LABVIEW e in rosso quelle in MATLAB . La funzione pianificatore_collision_free_mobile.m viene eseguita in MATLAB ed interfacciata al LABVIEW mediante un apposito VI detto MATLAB Script Node : si è inteso sottolineare questo fatto rappresentandola come una scritta rossa ( la funzione ) su un blocco blu ( il VI ) . A monte dello script vi sono l’interfaccia con il driver e il sistema di visione , dal quale arrivano la posizione e l’orientamento per il grasping . A valle vi è un ulteriore blocco di interfaccia che invia le posizioni desiderate al programma driver.

Figura 5.13 : i blocchi che costituiscono il pianificatore del manipolatore mobile


Il funzionamento del programma prevede tre fasi:

  1. una fase di inizializzazione in cui vengono lette la posizione iniziale e quella finale e viene preso possesso del driver , secondo le modalità che verranno dettagliate nel prossimo paragrafo ;

  2. una fase di calcolo offline della traiettoria ottima secondo la procedura sopra descritta , al termine della quale il MATLAB invia al LABVIEW la matrice di pianificazione di tabella 5.7 ;

  3. una fase di pianificazione vera e propria , in cui le variabili di giunto vengono estratte e poste in ingresso al robot secondo la temporizzazione prevista.

Al termine della fase 2 e prima di iniziare a controllare il MANUS , il programma segnala con una finestra di dialogo gli spostamenti calcolati per la base mobile , come mostrato in figura 5.14 .


Figura 5.14 : La comunicazione degli spostamenti della base


L’utente sposterà quindi il sostegno del MANUS in accordo con queste indicazioni e premerà OK nella finestra , in modo da avviare la pianificazione . Per agevolare queste operazioni è stata predisposta sul piano di appoggio del robot una griglia con dei quadrati di 10cm di lato , come mostrato in figura 5.15 . E’ ovvio che in futuro la procedura manuale verrà sostituita da un’interfaccia fra il pianificatore e la base mobile , attraverso la quale comandare gli spostamenti calcolati.


Figura 5.15 : La griglia che simula gli spostamenti della base mobile


In figura 5.16 si può osservare un dettaglio del diagramma , relativo al blocco di temporizzazione , che evidenzia come il calcolo della traiettoria ottima avvenga offline : il timer per la sincronizzazione della traiettoria è ottenuto infatti come differenza fra il timer del calcolatore e il valore da questo assunto ad inizio programma .


Figura 5.16 : La parte del VI che gestisce la temporizzazione


Per concludere , si tiene a precisare come il ricorso a LABVIEW per il pianificatore sia dettato principalmente dalle esigenze del sistema di visione . Infatti , come esposto nel capitolo 2 , l’uso di una telecamera analogica ha determinato il ricorso alla scheda di acquisizione IMAQ 1408 e quindi l’utilizzo del software National Instruments . Se negli sviluppi futuri si riuscirà ad utilizzare una webcam di dimensioni ridotte o un scheda di acquisizione gestibile da MATLAB , si potrà interfacciare direttamente pianificatore_collision_free_mobile.m al driver . Si tratta di modifiche marginali , perché le modalità di comunicazione del driver con le applicazioni esterne sono molto generali e necessitano solo di accedere ad un file di testo . La modifica più consistente sarebbe casomai la costruzione in MATLAB di una Graphical User Interface , GUI , che riproduca almeno in parte l’usabilità dei pannelli di controllo in LABVIEW : si è detto nel paragrafo 1.3 che questo è un requisito importante in robotica assistiva .


5.5 L’interfacciamento fra pianificatore e driver


Per le esigenze di sicurezza richieste dalla presenza di un utente disabile , il passaggio dal controllo diretto tramite driver al controllo automatico gestito da LABVIEW deve essere preventivamente acconsentito dall’operatore . La sequenza di azioni che permettono la commutazione fra le due modalità è la seguente:

  1. Run del Virtual Instrument Pianificatore_manipolatore_mobile.vi . La finestra mostrata in figura 5.17 avverte di eseguire il file driver.exe e di settare la modalità di controllo esterno .

Figura 5.17 : La finestra che guida l’utente nel processo di commutazione del controllore


  1. Run del driver e scelta dell’opzione “controllo da LABVIEW” tramite il tasto ‘k’ ; il programma apre il file C:/Attesa_l.txt e ne legge il primo carattere per verificare la presenza del pianificatore . Se riconosce il valore ‘1’ gli cede il controllo, altrimenti chiude il file e lo riapre ciclicamente ogni 2 secondi , a meno che l’utente non decida di riprendere il controllo premendo un tasto . Questa operazione diventa critica se si utilizzano compilatori che , come Borland-C++ , non supportano l’API di Windows Sleep . Senza questa funzione il ciclo di apertura , lettura e richiusura del file avviene a velocità così sostenute da occupare intensamente la CPU e non lasciare al LABVIEW la possibilità di accedere alla risorsa.

Figura 5.18 : Il driver in attesa della risposta da LABVIEW


  1. Scelta dell’opzione OK nella finestra di dialogo del VI di figura 5.17 . A seguito di questa azione il Pianificatore scrive il valore ‘1’ nel file C:/Attesa_l.txt , legge le posizioni iniziali del robot da C:/datic2lv.txt e le riscrive immediatamente in C:/datilv2c.txt . Il primo file è utilizzato dal driver per comunicare il feedback di posizione al pianificatore , mentre il secondo è utilizzato dal pianificatore per inviare i comandi al driver . Riscrivendo nel file dei comandi le posizioni da quello di feedback si fa in modo che , durante la fase di calcolo della traiettoria , il MANUS resti fermo sulla posizione iniziale .


A questo punto il driver riconosce la presenza del MANUS e gli passa il comando dei giunti : quando il calcolo della traiettoria è terminato le posizioni desiderate vengono via via scritte nel file C:/datilv2c.txt secondo i tempi prestabiliti , consentendo al MANUS di portarsi di volta in volta nelle posizioni indicate e realizzare il compito di grasping .



112


Torna al sommario


Torna alla home page di Ingegneria-elettronica.com