Prove in ammettenza con Tunnel-Force-Assistance

Vediamo ora alcuni esempi che prevedono l’aggiunta del tunnel, utilizzando sia il controllo tempo dipendente che la versione tempo indipendente. Verranno qui applicate le logiche descritte in 3.3.2 e implementate come in 4.2.

Ammettenza con tunnel tempo indipendente

0 1 2 3 4 5 6 7 8 9 10 −0.8 −0.6 −0.4 −0.2 0 0.2 0.4 0.6 0.8

task visto sugli angoli di cardano

t [s]

[rad]

roll pitch yaw

Figura 4.23: Legge di moto adottata nella prima prova con controllo in ammettenza libero

Prendiamo come primo esempio il task di puro pitch. Come si vede in Fig.4.23, tale task coinvolge solo un gdl, roll e yaw sono definiti nulli. Il controllo in ammettenza con tunnel tempo indipendente, esaminerà la traiettoria ad ogni iterazione, cercando la posa più vicina a quella attuale. Verranno generati dei contributi solo nel caso di errori ortogonali oltre tolleranza, mentre l’errore tangenziale sarà sempre nullo per definizione di distanza minima. I parametri sui quali giocare sono l’ampiezza della banda di tolleranza e i parametri dinamici del sistema del secondo ordine ortogonale. Vediamo il comportamento che si ottiene con una banda di tolleranza di ampiezza calcolata come in (3.72), corrispondente a 5o_{, e sistema poco smorzato e cedevole. In Fig.4.24, il primo grafico rappresenta}

l’andamento dell’errore di orientamento tangenziale e ortogonale. Viene indicata tratteggiata l’ampiezza della banda di tolleranza. Le grandezze riportate in tale grafico risultano adimensionali, per la loro definizione si rimanda a 3.3.2.

4.3. Prove e risultati 117 0 2 4 6 8 10 12 14 16 −0.05 0 0.05 0.1 0.15 Errore di orientamento 0 2 4 6 8 10 12 14 16 −0.4 −0.2 0 0.2 0.4 [rad] Angoli fisiologici 0 2 4 6 8 10 12 14 16 −1 −0.5 0 0.5 1x 10

4 _{Coppie simulate generate tramite joystick}

tempo [s] coppie simulate δ_⊥ δ_// toll_ort roll pitch yaw

Figura 4.24: No dipendenza dal tempo, tolleranza ortogonale non nulla, sistema cedevole e poco smorzato

−0.1 −0.05 0 0.05 0.1 0.15 −0.2 −0.1 0 0.1 0.2 −0.1 −0.05 0 0.05 0.1 0.15 Pseudo traiettoria 2 0 0.01 0.02 0.03 0.04 0.05 0.06 0.07 0.08 0.09 0.1

azione del controllo ortogonale

4.3. Prove e risultati 118

La prima coppia viene generata sul pitch, come si può notare da Fig.4.24 osservando i colori del terzo grafico. La rotazione generata equivale ad uno spo- stamento lungo la traiettoria nello spazio delle rotazioni, riportata in Fig.3.22c; di conseguenza non viene generato alcun errore, e lo si evince osservando il primo grafico, dove vengono visualizzati la componente tangenziale e ortogonale dell’errore di orientamento. Questa prima fase corrisponde ad una configurazione del tipo in Fig.4.25 Successivamente viene applicata una coppia attorno all’asse di yaw. Si nota come l’errore ortogonale cresca fino a superare la tolleranza; quando viene rilasciata la coppia, il sistema si riporta in tolleranza con un transitorio di circa 3s e alcune oscillazioni. La situazione in cui ci troviamo prima che il controllo ci riporti in tolleranza, è del tipo mostrato in Fig.4.26.

−0.1 0 0.1 −0.2 0 0.2 −0.1 −0.05 0 0.05 0.1 0.15 Pseudo traiettoria 2 0 0.01 0.02 0.03 0.04 0.05 0.06 0.07 0.08 0.09 0.1

azione del controllo ortogonale

Figura 4.26: Movimento fuori tolleranza

Il vettore disegnato in verde corrisponde alla posa attuale, quello in rosso invece è il riferimento a distanza minima dall’orientamento attuale. Il vettore in blu rappresenta l’errore di orientamento, ovvero il vettore δ; si nota come questo sia pressochè ortogonale alla traiettoria.

4.3. Prove e risultati 119

Le prestazioni del controllo vengono determinate dai parametri di ammetten- za, tolleranza, rigidezza, massa e smorzamento dei sistemi del secondo ordine. Vediamo come cambia il comportamento del sistema al variare di tali parametri.

Come descritto in 4.2, non verranno riportati i valori di rigidezza, massa e smorzamento impiegati nelle varie prove, poichè, a causa dell’interazione con lo space mouse, tali valori sono fisicamente poco significativi.

0 5 10 15 −0.05 0 0.05 0.1 0.15 0.2 0.25 0.3 Ldm solo pitch rigidezza elevata tolleranza 5° smorzamento nullo 0 2 4 6 8 −0.02 0 0.02 0.04 0.06 0.08 Ldm solo pitch rigidezza ridotta tolleranza 0° smorzamento subcritico 0 5 10 15 −0.2 −0.1 0 0.1 0.2 0.3 Ldm pitch+yaw rigidezza ridotta tolleranza 0° smorzamento ipercritico 0 5 10 15 −0.05 0 0.05 0.1 0.15 time [s] (a) errore di orientamento 0 2 4 6 8 −0.01 0 0.01 0.02 0.03 0.04 time [s] (b) 0 5 10 15 −0.005 0 0.005 0.01 0.015 0.02 0.025 time [s] (c) roll pitch yaw

Figura 4.27: Prove qualitative al variare dei parametri dinamici

In Fig.4.27 vediamo il risultato di tre prove, ancora con attivo il tunnel controller tempo indipendente. Le prove (a) e (b) sono state eseguite mantenendo il task in Fig.3.22, che prevede unicamente il pitch. Nella prova (a) è stato modificato il sistema del secondo ordine ortogonale, alzando il valore della rigidezza e portando lo smorzamento a zero. Dato che il task è di puro pitch, la coppia di roll somministrata provoca un errore ortogonale. Questo viene compensato e l’errore torna in tolleranza al cessare della coppia, ma questa volta le oscillazioni sono a frequenza più elevata e non sono smorzate. Il valore di tolleranza è stato matenuto al livello della prova precedente, ovvero l’equivalente di 5o_{. Le oscillazioni non si portano subito attorno al limite di tolleranza a}

4.3. Prove e risultati 120

causa della dinamica intrinseca del joystick, il quale è a sua volta un sistema massa-molla-smorzatore.

Nella prova (b) la tolleranza è stata portata a 0, la rigidezza ridotta e lo smorzamento aumentato fino ad ottenere un comportamento subcritico. La reazione del sistema è notevolmente cambiata. La frequenza dell’oscillazione è diminuita e il transitorio termina in poco più di 2 secondi grazie al maggiore smorzamento. Sono stati applicati in questa prova, valori di coppia inferiori, di conseguenza l’ampiezza dello scostamento non è paragonabile a quella ottenuta nella prova (a).

La prova (c) vede l’impiego di un task composto, in particolare si è adottato il task in Fig.4.28 che vede due cicloidali in fase ma segno opposto su pitch e yaw. Inoltre lo smorzamento è stato ulteriormente aumentato fino ad ottenere un comportamento ipercritico. La tolleranza è stata lasciata invariata al valore nullo. Per capire meglio come si comporta il sistema, facciamo riferimento alla Fig.4.29. Come in precedenza il grafico superiore indica l’errore di orientamento, quello centrale i gdl del robot durante la rotazione, l’ultimo l’input da parte del joystick ovvero le coppie.

0 1 2 3 4 5 6 7 8 9 10 −0.8 −0.6 −0.4 −0.2 0 0.2 0.4 0.6 0.8

task visto sugli angoli di cardano

t [s]

[rad]

roll pitch yaw

4.3. Prove e risultati 121 0 2 4 6 8 10 12 14 16 −0.01 0 0.01 0.02 0.03 Errore di orientamento 0 2 4 6 8 10 12 14 16 −0.2 0 0.2 0.4 0.6 [rad] Angoli fisiologici 0 2 4 6 8 10 12 14 16 −5000 0 5000 10000

Coppie simulate generate tramite joystick

tempo [s] coppie simulate δ_⊥ δ_// toll_ort roll pitch yaw joy x axis joy y axis joy z axis

Figura 4.29: Dettaglio prova su task complesso

Osserviamo in primo luogo l’area evidenziata con il tratteggio nero in Fig.4.29. Nel terzo grafico si può notare che dall’esterno viene applicata solo una coppia negativa sul gdl di yaw. Il task di riferimento comprende lo yaw ma non ci troviamo più nel caso monoassiale: se osserviamo il primo grafico, pur essendo lo yaw "autorizzato" dal riferimento, viene generato un errore ortogonale. Questo a causa del fatto che contemporaneamente allo yaw, il task richiede un pich in fase e segno opposto. Se si osserva il secondo grafico, si nota che l’effetto dell’errore generato dal controllore ortogonale, è proprio quello di aggiungere nel pitch in verso opposto, anche se sull’asse Ytf l’utente esterno non sta applicando coppia.

4.3. Prove e risultati 122 −0.1 _−0.05 0 _0.05 0.1 _0.15 −0.2 −0.1 0 0.1 0.2 −0.1 −0.05 0 0.05 0.1 0.15

Figura 4.30: Plot dinamico della prova con task complesso

In Fig.4.30 il corrispondente plot dinamico sulla traiettoria nello spazio delle rotazioni. E’ evidente la differenza con Fig.4.25, mentre in quel caso muoverci con solo pitch portava a muoversi sulla pseudo traiettoria, nella prova (c) muoversi con solo yaw porta ad allontanarci dal riferimento. Questo a causa della curvatura non nulla della traiettoria e del fatto che rotazioni monoassiali sono invece rettilinee nello spazio delle rotazioni.

Tornando alla Fig.4.29, notiamo infine la sezione evidenziata dalle freccie blu. A circa metà della simulazione viene esercitata una coppia attorno all’asse di roll. Questo porta a muoversi esattamenente ortogonali alla traiettoria poichè tale gdl non è contemplato nel task; l’errore generato viene compensato e la tolleranza nulla riporta il roll a zero. Grazie allo smorzamento elevato, questa volta il transitorio è minimo e non ci sono oscillazioni apprezzabili.

4.3. Prove e risultati 123

Tunnel con controllo assistivo tangenziale

Da ultimo alcune prove utilizzando il controllo assistivo in direzione tan- genziale. Ciò equivale all’impiego del tunnel controller nella variante tempo dipendente 3.3.2. La selezione del riferimento sulla triettoria non avviene più ricercando il punto a distanza minima, bensì fissato un istante di riferimento, ad ogni ciclo viene estratta la posa prevista dalla Ldm disegnata. In questo modo l’errore di orientamento potrà assumere una direzione qualsiasi facendo entrare in gioco la tolleranza tangenziale.

Vediamo, in primo luogo, il caso descritto nella sezione 3.3.2, con task di puro pitch in Fig.4.23, tolleranza ortogonale e tangenziale uniformi equivalenti a 5o _e

nessuna coppia applicata dall’esterno.

0 2 4 6 8 10 −0.2 −0.1 0 0.1 0.2 Errore di orientamento 0 2 4 6 8 10 −1 0 1 [rad]

Angoli fisiologici e riferimenti

0 2 4 6 8 10

−1 0

1x 10

4

Coppie simulate generate tramite joystick

coppie _simulate 0 2 4 6 8 10 −0.02 −0.01 0 0.01 0.02

Rotazioni generate dal tunnel controller

tempo [s]

[rad]

δ_⊥ δ_//

toll_{ort, tan}

∆ roll

∆ pitch

∆ yaw

Figura 4.31: Prima prova con controllo assistivo in direzione tangenziale

Osservando Fig.4.31, nel terzo grafico vediamo che le coppie applicate dall’esterno sono nulle. Ciò equivale al caso di paziente completamente neutrale

4.3. Prove e risultati 124

sulla macchina. Nel primo grafico notiamo che l’errore ortogonale rimane nullo mentre quello tangenziale comincia a salire fin dai primi istanti. Questo perchè, come spiegato in 3.3.2, partiamo da un punto sulla traiettoria e, al passare del tempo, il riferimento si allontana dalla nostra posa seguendo la traiettoria rettilinea. Quando l’errore di orientamento tangenziale esce dalla tolleranza, si nota che nell’ultimo grafico si attiva il controllore del tunnel. L’azione generata dal controllo costituisce la forza assistiva che tende a farci seguire la legge di moto imposta. Pur rimanendo nulle le coppie applicate dall’esterno, il controllo agisce per riportare l’errore tangenziale in tolleranza facendo crescere il pitch. Nel secondo grafico si vede in viola il riferimento e in verde il pitch effettivo, risultante dall’azione del controllo. Il robot si muove con ritardo ma è chiaro il tentativo del tunnel controller di seguire la Ldm. Come evidenziato dalle linee verticali tratteggiate, ogni volta che l’errore rientra in tolleranza, il controllore smette di agire, infatti il robot rimane fermo. Questo è in linea con il principio del’AAN esposto in 1.3. 0 5 10 15 20 −0.2 −0.1 0 0.1 0.2 Errore di orientamento 0 5 10 15 20 −1 −0.5 0 0.5 1 [rad]

Angoli fisiologici e riferimenti

0 5 10 15 20

−5000 0 5000 10000

Coppie simulate generate tramite joystick

coppie simulate

0 5 10 15 20

−0.02 0 0.02

Rotazioni generate dal tunnel controller

tempo [s] [rad] roll pitch yaw joy x axis joy y axis joy z axis 1 2 3 2.2 2.1 2.2 3.2 3.1 2.2

4.3. Prove e risultati 125

L’aderenza del controllo a tali principi è ancora più chiara nella seconda prova effettuata con tunnel tempo dipendente. Con riferimento alla Fig.4.32, la prova è stata divisa in tre sezioni per facilitarne la lettura. Vediamo le singole sezioni nel dettaglio:

1. Nella prima sezione si può apprezzare un comportamento del tutto identico alla prima prova. Non vengono imposte coppie dall’esterno e il controllo agisce per mantenere l’errore in tolleranza. Le considerazioni sono le stesse fatte in precedenza.

2. Nella seconda sezione avviene il grosso cambiamento rispetto alla prova precedente:

2.1. L’utente comincia ad esercitare coppia sul pitch cercando di inseguire il riferimento, aiutato dalla visione in tempo reale della propria prestazione. Se confrontiamo il secondo e il terzo grafico, si nota che la coppia esterna è tale da spegnere completamente il tunnel controller. L’azione dell’utente, malgrado non produca un risultato perfetto, consente all’errore di rimanere sempre in tolleranza per un tratto di circa 5s; il controllo lascia campo libero e smette di dare assistenza.

2.2. Verso la fine della sezione 2, si nota che la spinta esterna perde di concentrazione sul pitch; interviene una piccola coppia sul roll che fa deviare l’asse di rotazione. L’errore ortogonale rimane in tolleranza e il controllo non interviene, ma tale disassamento è sufficiente a far aumentare il ritardo, costringendo il controllo tangenziale ad una lieve correzione.

3. Nell’ultima sezione si vedono ancora coppie esterne non nulle, ma questa volta le prestazioni dell’utente sono notevolmente peggiorate:

3.1. All’inizione della terza sezione, si nota come il task obbiettivo cominci a tornare verso lo zero diminuendo il pitch. La coppia esercitata dall’utente è in completa antitesi con la richiesta. L’errore tangenziale cresce molto rapidamente uscendo di tolleranza. Il controllo reagisce

4.3. Prove e risultati 126

alla spinta in verso errato fino a bilanciarla, impedendo che l’utente si allontani in modo incontrollato dal task.

3.2. Non appena la spinta errata diminuisce, l’orientamento viene ripor- tato verso i limiti di tolleranza e si nota un rapido riallineamento del pitch sulla legge di moto assegnata. La sostanziale differenza con il caso di ammettenza libera, consiste nella forza di contrasto che il robot fornisce in risposta all’azione errata da parte dell’utente, tale da limitare molto l’ampiezza della deriva. Ovviamente le prestazio- ni legate a questo comportamento sono fortemente dipendenti dai parametri del controllo.

Variazione dinamica della banda di tolleranza

Attraverso il manual switch DYNAMIC TUNNEL, è possibile attivare la variazione real-time dei due parametri che definiscono la forma del volume di tolleranza. Attivando questa possibilità viene consentito all’utente di incremen- tare o diminuire le due variabili toll-tan e toll-ort tramite input da tastiera. Incrementi e decrementi avvengono in modo discreto di uno step prefissato premendo quattro pulsanti mappati, due per ciascuna variabile e corrispondenti al + e −. Questo è realizzato tramite una Matlab S-function in grado di ricevere input da qualsiasi tasto della tastiera, generando un’onda quadra di ampiezza diversa a seconda del tasto selezionato. Entrambe le tolleranze possono variare all’interno di un range prefissato, corrispondente a un errore di orientamento rispetto al target compreso tra 0.1o e 15o, per ciascuna direzione, con step di variazione ad ogni input pari un decimo di grado. Vediamo un esempio di tale variazione in tempo reale, con il solo scopo di illustrare cosa accade nel caso di tolleranza non costante durante la terapia.

4.3. Prove e risultati 127 0 5 10 15 20 25 30 −1 −0.5 0 0.5 1 [rad] Angoli fisiologici roll pitch yaw 0 5 10 15 20 25 30 −1 0 1x 10

4 _{Coppie simulate generate tramite joystick}

coppie simulate 0 5 10 15 20 25 30 0 0.05 0.1 0.15 0.2

Soglie di tolleranza del tunnel

tempo [s] toll

tan

toll_ort

Figura 4.33: Prova con tolleranze variabili in real-time

E’ ben visibile in Fig.4.33 come al variare del livello di tolleranza tangen- ziale, cambi il ritardo con cui il controllo reagisce all’errore di orientamento. Come per la prima prova eseguita, non sono state esercitate coppie esterne, per permettere di visualizzare al meglio la variazione di comportamento del controllo.

Capitolo 5

Architettura del software di

controllo

Quanto descritto nei capitoli precedenti, costituisce lo studio e il test in ambito simulato, delle strategie di controllo del robot, sviluppate a partire dai desiderata in campo riabilitativo. Per poter implementare le logiche progettate sul prototipo PkAnkle, è stato necessario in primo luogo dotarlo di una archi- tettura software di base, creare una efficiente infrastruttura di comunicazione e risolvere tutte le necessità del controllo realizzando gli strumenti appositi. Il tutto cercando di realizzare un codice C++ modulare, facile da espanderee e trasportare, il cui funzionamento fosse efficiente e sicuro. Su queste basi sono state in seguito implementate le logiche descritte.

5.1

Scelte progettuali di base

Nella progettazione del software sono stati seguiti alcuni principi cardine. In primo luogo la volontà di rendere il codice modulare, espandibile, facilmente manutenibile, riutilizzabile e facilmente trasportabile tra diversi dispositivi. Oltre a questo si voleva ottimizzare lo scambio di informazioni ad alto livello, consentendo di leggere informazioni e inviare comandi da qualunque dispositivo, semplificando i meccanismi di scambio dei dati.

Tutti questi desiderata hanno trovato risposta in due macro scelte progettuali, dalle quali è dipeso tutto il successivo sviluppo del software: