Nel nostro caso tra i nodi connessi alla rete abbiamo tre azionamenti ed è necessario che questi agiscano con sincronismo, altrimenti l’output cinematico risulterebbe diverso da quello atteso. Il protocollo EtherCAT gestisce il sincro- nismo tramite l’allineamento accurato dei clock distribuiti: dal momento che la comunicazione si avvale di una struttura logica ad anello(Fig. 2.20), ogni nodo della rete può misurare la differenza temporale tra il passaggio di arrivo e quello di ritorno di un frame. Il clock principale, avvalendosi di tali misurazioni, può determinare il ritardo di propagazione di ogni singolo slave in modo semplice ed accurato. I clocks distribuiti sono corretti in base a questo valore.
2.4
COE: CAN Over EtherCAT
La rete etherCAT supporta diversi tipi di protocolli di comunicazione in modo da adattarsi al singolo sistema adottato dalle case produttrici dei dispositivi slave. Nel nostro caso i tre driver della Elmo utilizzano il protocollo CANopen DSP402. Il protocollo di comunicazione EtherCAT è in grado di supportare CANopen, fornendo gli stessi meccanismi di comunicazione: object Dictionary, PDO "Process Data Objects" e SDO "Service Data Objects"[25]. Ci si è avvalsi di un pacchetto ROS che contiene tutte le librerie e funzionalità per interpretare i dati provenienti dai driver e gestire la comunicazione in entrambi i sensi. Il principio base con cui funziona il protocollo CANopen è quello di inviare e ricevere "word", ovvero serie di bit interpretabili secondo mappe specifiche definite dalla casa dell’azionamento. La comunicazione via SDO serve per modificare i parametri caratteristici di un dispositivo slave, ad esempio nel caso dei nostri motori valori caratteristici dei controllori, valori di saturazione per la velocità e molti altri. La comunicazione via PDO serve invece per ricevere (RPDO) e trasmettere (TPDO) infomazioni; nel primo caso si tratta di conoscere interamente o parzialmente lo stato del dispositivo, nel secondo caso vogliamo modificare lo stato stesso tramite specifici comandi.
Ci si è avvalsi delle librerie interne ITIA-COE-UTILS. Tali librerie contengono mappe e algoritmi necessari all’interpretazione e modifica BitWise2delle stringhe
2.4. COE: CAN Over EtherCAT 31
relative ai driver della Elmo. Senza scendere eccessivamente nel dettaglio, i due oggetti con cui possiamo interagire sono la StatusWord, ricevuta attraverso RPDO e interpretata attraverso specifiche maschere stato dipendenti, e la
ControlWord, attraverso la quale costruiamo tutti i comandi da inviare al driver
motore attraverso TPDO. E’ inoltre possibile impostare i parametri del driver via SDO.
Capitolo 3
Algoritmi di controllo
3.1
Controlli sviluppati e terapie neuroriabili-
tative
Le logiche che verranno descritte possono essere impiegate per la costruzione di un gran numero di esercizi differenti, come differenti sono i risultati ottenibili da ognuna. Ognuna di esse si rivolge ad un particolare ambito o metodo di trattamento.
I controlli in posizione costituiscono la base di tutte le terapie catalogate come passive. Si tratta di esercizi duranti i quali l’esecuzione del task assegnato al robot è scarsamente o del tutto non condizionata dall’interazione con il paziente. E’ possibile elaborare terapie che prevedano l’interazione, ad esempio con segnali generati dal paziente come l’EMG, ma la caratteristica saliente rimane che, in fase di esecuzione, è il robot a muovere il paziente, facendogli eseguire i movimenti stabiliti. Un esempio ormai affermato di terapia passiva è il CPM "Continuous Passive Motion", ovvero l’esecuzione ripetuta in modo ciclico di un determinato movimento, impiegata per la riabilitazione post-operatoria delle articolazioni, per favorire il recupero della mobilità e dell’ampiezza del movimento. L’applicazione del CPM a pazienti con deficit neuromotori post- ictus, in particolare sulla spalla [45], ha dimostrato di migliorare la stabilità dell’articolazione durante il movimento.
3.1. Controlli sviluppati e terapie neuroriabilitative 34
Per quanto riguarda i controlli per terapie attive, gli algoritmi di control- lo challenge-based (1.3) sono rivolti alla necessità di allenare un movimento, magari funzionale ad una attività quotidiana, in un ambiente che in qualche misura rende il compito più difficile al paziente. La regolazione della resistenza offerta dal robot consente di personalizzare le caratteristiche di tale ambiente. Si è scelto di realizzare questo tipo di logica attraverso un controllo in am- mettenza. La prima variante che verrà descritta è realizzata senza vincoli di orientamento: il paziente potrà quindi muoversi liberamente in tutto il proprio range di movimento. Tale caratteristica fa si che questa logica non sia adatta per la rieducazione della coordinazione neuromotoria in soggetti con disfunzioni post-ictus. Diversamente può rivelarsi una risorsa molto utile in fasi avanzate della terapia, quando tale coordinazione è stata già parzialmente recuperata, o in casi in cui la disfunzione sia di altro tipo. Inoltre tale tipo di controllo in ammettenza costituirà la base per la versione innovativa.
Diversamente, la seconda logica in ammettenza implementata prevede l’assisten- za lungo un task rotativo assegnato, impiegando diverse modalità di interazione. Questo viene realizzato utilizzando il principio della Tunnel-Force-Assistance. Tale tipo si controllo nasce con l’intento di assistere l’individuo nel realizzare un movimento vicino a quello assegnato, anche laddove le capacità neuro-motorie del paziente non lo consentano, preservando però la completa autonomia e iniziativa del movimento. Tale variante risulta quindi più adatta alla definizione di terapie per il recupero neuro-motorio, in tutti quei casi in cui la coordinazione tra volontà di movimento, impulsi nervosi, attivazione muscolare e movimento è alterata da un deficit. Occorrerà, tuttavia, uno studio approfondito per determi- nare le reali prestazioni di questa variante del controllo in campo riabilitativo.