CAPITOLO 4

L’HARDWARE E LA MECCANICA DEL SISTEMA

In questo capitolo il MANUS verrà analizzato dal punto di vista tecnologico-realizzativo : ci si soffermerà sulle proprietà meccaniche della struttura , così da integrare l’analisi cinematica svolta nel capitolo 1 ; sulle caratteristiche ed il funzionamento del computer-box , che hanno determinato la stesura del software di interfaccia e di pianificazione ; sulla comunicazione fra controllore e Personal Computer , che fa uso dello standard CAN . Le caratteristiche meccaniche riguardano l’ingombro dei bracci del robot , necessario a capire quali link vanno modellati per la previsione delle auto-collisioni , il sistema di attuazione e trasduzione , alcune considerazioni sulla cedevolezza dei giunti e sulle ripercussioni che questa ha nella precisione del controllo . Il computer-box sarà analizzato descrivendone l’hardware e le modalità di funzionamento : si vedrà come la semplicità dell’hardware si rifletta in una scarsa precisione del posizionamento e come fra modalità cartesiana e modalità di controllo diretto dei giunti solo la seconda si sia ritenuta idonea agli scopi di questo progetto . Infine verranno esposte le modalità di comunicazione fra PC e computer-box , la cui trattazione non può prescindere da una introduzione al bus CAN , Controller Area Network : un protocollo nato nel settore automotive che sta prendendo sempre più piede anche in applicazioni industriali e di servizio , come testimonia lo sviluppo del protocollo M3S su infrastruttura CAN [13] .

4.1 Il sistema MANUS

Il MANUS è un manipolatore a basso costo concepito intorno alla seconda metà degli anni ’80 da alcuni gruppi di ricerca operanti nell’ambito della robotica riabilitativa ed assistiva [8] , che hanno inteso progettare un robot facilmente integrabile su carrozzelle per disabili e che sia in grado di soddisfare le esigenze di un sistema per l’assistenza esposte nel paragrafo 1.3 . Nell’idea iniziale il MANUS doveva essere un supporto alla telemanipolazione , cioè un sistema meccanico comandato a vista dall’utente , e il massimo dell’autonomia prevista consisteva nel memorizzare su un Personal Computer un certo numero di movimenti corrispondenti ad altrettanti compiti significativi . Più di recente sono comparsi sistemi parzialmente autonomi basati sul MANUS , come si è avuto modo di osservare nella panoramica introduttiva del capitolo 1 , e in questo filone si pone anche il presente lavoro di tesi .

Figura 4.1 : L’utilizzo del Manus secondo l’idea originaria

La vendita del MANUS ai privati è iniziata a partire dagli anni ’90 ad opera della società olandese Exact Dynamics essenzialmente come sistema di telemanipolazione secondo il disegno originario : viene infatti venduto abbinato ad un joystick , un keypad o un programma di controllo su Personal Computer che permettono comandi di tipo start-stop a velocità costante . E’ comunque prevista , per i clienti che acquistano il MANUS con scopi di ricerca e sviluppo , la possibilità di accedere al codice sorgente del programma di controllo e modificarlo per sviluppare applicazioni più autonome .
In questa versione , che è quella disponibile presso il laboratorio di robotica avanzata del DIIGA , è presente un dispositivo esterno che permette di selezionare , attraverso degli interruttori , una delle seguenti modalità di funzionamento:

• controllo manuale, attraverso il joystick o il keypad . In questa modalità l’utente può ruotare ciascun giunto e spostarsi in uno dei due versi di ciascun asse dello spazio cartesiano , secondo una velocità prestabilita ed azionando un solo asse alla volta ;

• controllo trasparente, con un calcolatore che comunica con il box di controllo mediante bus CAN . In questa modalità è consentito agire sulla velocità dei giunti e degli assi cartesiani o controllare più di un giunto o un asse cartesiano alla volta . Per fare questo l’utente deve modificare il codice sorgente del programma di controllo , che nella versione originale ha le stesse funzionalità degli altri dispositivi di ingresso : la sola opzione aggiuntiva riguarda la possibilità di accedere al feedback di posizione del robot .

Figura 4.2 : Il controllore in dotazione e il dispositivo di selezione del funzionamento

Tanto nel comando da joystick che in quello trasparente vi sono due ulteriori modalità di funzionamento , da selezionare mediante una variabile di ingresso detta control box (cbox):

1. controllo cartesiano : si ha quando il control-box è pari a 1 e l’utente può spostare la pinza in una delle direzioni dello spazio cartesiano e ruotarla per ottenere l’orientamento desiderato ;

2. controllo diretto sui giunti : si ha quando il control-box vale 4 e permette all’utente di comandare direttamente la rotazione dei sei giunti del robot di figura 4.3 . E’ la modalità che lascia maggiore libertà all’utente e permette di gestire completamente la cinematica del manipolatore senza sottostare alle semplificazioni del controllore che saranno esposte più avanti .

L’ingresso control-box può assumere anche altri valori , che corrispondono alla modalità di inizializzazione ( cbox=0 ) , alla modalità di chiusura del robot su se stesso ( procedura di fold-in , cbox=6 ) e a quella di apertura del MANUS dalla posizione di minimo ingombro ( procedura di fold-out , cbox=5 ) .

Figura 4.3 : Gli assi di rotazione nella modalità di controllo diretto dei giunti ( cbox 4 )

A causa della semplicità hardware del computer-box la modalità di controllo cartesiano presenta alcuni svantaggi , che hanno importanza marginale quando il robot viene utilizzato come telemanipolatore , ma che introducono pesanti limitazioni nelle applicazioni che necessitano di maggiore autonomia . Questi svantaggi sono descritti di seguito:

1. il controllore non distingue fra spostamento effettivo e spostamento desiderato . Se si impone al MANUS di muoversi lungo il primo asse cartesiano , la pinza non segue esattamente una traiettoria rettilinea a coordinata x costante ma presenta degli spostamenti non trascurabili lungo y e z . Il controllore trascura completamente queste deviazioni , che possono avere ampiezze anche di qualche centimetro , e assume di essersi mosso esattamente lungo una linea retta . Gli errori sulla posizione cartesiana si accumulano con gli spostamenti eseguiti e vegono riportate entro valori accettabili solo quando il MANUS viene chiuso con la procedura di fold-in e riaperto con quella di fold-out .

2. la cinematica del computer-box non considera la pinza . La posizione restituita è quella del centro del polso , che dipende da tre sole variabili di giunto come si è visto nel paragrafo 1.2.4 : è la soluzione adottata per ridurre la mole di calcoli e renderli alla portata di un microcontrollore . Per la telemanipolazione questa semplificazione non da luogo a svantaggi evidenti : se il centro del polso si muove lungo x , anche la pinza realizzerà in prima approssimazione uno spostamento simile . Nel caso del grasping automatico , invece , questa ipotesi costituisce una limitazione gravosa perché è necessario conoscere con esattezza la posizione della pinza .

3. lo spazio di lavoro è limitato : non è possibile assumere tutte le posizioni e gli orientamenti raggiungibili dal robot , ma solo un insieme ristretto per il quale il computer-box è in grado di effettuare l’inversione cinematica. Quando si arriva agli estremi di questo spazio di lavoro il controllore invia un segnale acustico per avvertire l’utente che è necessario passare al controllo diretto dei giunti .

4. Non è assicurato l’orientamento costante per la pinza : il controllo cartesiano viene definito in [7] come il funzionamento che permette di controllare uno alla volta gli assi x , y , z o le rotazioni degli angoli Roll , Pitch ,Yaw , mediante ingressi di tipo start/stop . Una simile definizione lascerebbe pensare che , mentre si modifica uno di questi angoli , gli altri restino costanti : in realtà il control-box aggiusta automaticamente le rotazioni delle variabili non controllate , quando queste non sono compatibili con il movimento richiesto .

Queste semplificazioni non permettono l’operazione di grasping autonomo che si intende realizzare in questa tesi , pertanto si è ritenuto opportuno controllare il MANUS direttamente sui giunti. Anche questa modalità di funzionamento presenta tuttavia dei limiti :

1. non è garantita la prevenzione delle collisioni fra i link del manipolatore , che è invece assicurata nel controllo cartesiano . La EXACT DYNAMICS non fornisce i set di angoli per cui queste collisioni avvengono e quindi deve essere predisposta una opportuna verifica da parte dal pianificatore : di questo aspetto si parlerà nel capitolo 5;

2. cedevolezza meccanica non rilevata dagli encoder . E’ una delle situazioni peggiori che si possono incontrare in controlli automatici , perché il controllore riceve un’informazione sbagliata sullo stato del sistema . Si è osservata più volte durante le prove sul MANUS , tutte le volte che il braccio ha subito uno spostamento non comandato dal controllore : più che un problema degli encoder si pensa quindi ad una mancata lettura degli stessi da parte del computer-box . Ad avvalorare questa tesi si è osservato un recupero delle letture esatte dopo un ciclo completo di chiusura e riapertura . Ciò non attenua comunque la gravità del problema , che può far fallire il grasping dell’oggetto e , soprattutto , provocare collisioni durante la procedura di fold-in causate dell’errata cognizione della traiettoria seguita .

4.1.1 La struttura meccanica

Nelle figure 4.3 e 4.4 sono indicate le dimensioni dei bracci del MANUS nelle configurazioni di minimo ingombro e in quella di massima estensione . La prima viene raggiunta al termine della procedura di fold-in è permettere di richiudere il robot entro un apposita valigia di che ne consente il trasporto . Nella seconda si toccano gli estremi dello spazio di lavoro che è approssimativamente una sfera di di raggio .

Buona parte dei punti di questo spazio di lavoro possono essere raggiunti con sufficiente destrezza, grazie all’ampiezza delle rotazioni : infatti tutti gli angoli , con la sola esclusione di , possono variare senza soluzione di continuità compiendo anche più di un giro. Questa importante caratteristica può essere ottenuta grazie al sistema di attuazione e trasduzione , che relega tutti i motori e gli encoder nella colonna alla base del MANUS e affida la trasmissione ad un complesso sistema di cinghie .

Figura 4.6 : L’ubicazione dei motori e degli encoder nella base del robot

Questa soluzione conferisce snellezza alla struttura meccanica , che pesa meno di 13Kg e può quindi essere attuata con motori in corrente continua di piccola potenza : l’alimentazione è a 24V DC e il consumo di corrente resta abitualmente sotto 1.5A , per una potenza inferiore ai 36W . La mobilità e la snellezza si pagano in termini di forze esercitate e di precisione del posizionamento : il MANUS non può sollevare pesi superiori ad 1.5Kg e il sistema di cinghie determina , per la presenza di giochi nella trasmissione ammessi dallo stesso costruttore [7] , il fenomeno della cedevolezza meccanica precedentemente esposto . Un’altra causa che concorre a peggiorare le precisione del controllo sono gli attriti : le coppie dei motori vengono calcolate con un’azione proporzionale-integrativa ( PI ) a partire dall’errore di velocità . Se la velocità richiesta è troppo bassa la coppia motrice non è in grado di vincere la coppia di attrito e non si osserva alcuno spostamento .

4.1.2 Il sistema di controllo

Il cuore del sistema di controllo è il microcontrollore Intel 80C186 , indicato dal costruttore come processore matematico , che si occupa di calcolare le coppie dei motori secondo un’azione proporzionale-integrativa a partire dall’errore di velocità . Realizza inoltre le trasformazioni cinematiche , seppure con le evidenti imprecisioni descritte in 4.1.1 . In questo paragrafo si intende giustificare la causa di queste approssimazioni : le operazioni di trasformazione cinematica vanno effettuate in un intervallo di 10ms , che è il tempo di campionamento del ciclo più interno descritto in figura 4.8. Il microcontrollore 80C186 si basa sul vecchio processore Intel 8086 , lo stesso montato sui primi Personal Computer , mentre la procedura di inversione della cinematica implementata dalla funzione cinematica_inversa_gradi.m riportata in appendice B è costituita da circa 350 righe di codice dense di funzioni trigonometriche dirette e inverse , prodotti matriciali , confronti , ecc.. . Anche un Personal Computer dotato di processore molto più veloce ed evoluto dell’8086 impiega più di 10ms per richiamare questa funzione , quindi è impensabile che il processore matematico del computer-box possa effettuare in tempo reale una simile trasformazione : per questo motivo la cinematica inversa implementata non è di tipo assoluto ma differenziale . La cinematica differenziale lega le velocità cartesiane alle velocità dei giunti mediante il prodotto per lo Jacobiano , pertanto questa soluzione permette di evitare la risoluzione di un complesso sistema di equazioni non lineari limitarsi ad un prodotto matriciale . Della semplificazione riguardante la cinematica diretta si è già parlato nel paragrafo precedente e la composizione di queste due trasformazioni da luogo allo schema di figura 4.7 .

Figura 4.7 : lo schema di controllo realizzato dal micro 80C186

L’interfacciamento del processore matematico con l’utente e con i driver dei motori è gestito da due microcontrollori Intel 80C592 , che funzionano come nodi di un bus CAN : uno viene detto processore di I/O verso l’utente e l’altro processore di I/O per il controllo.

La comunicazione fra processore di I/O verso l’utente e il Personal Computer avviene su una linea indicata dal costruttore come external CAN bus , al quale il PC accede mediante una scheda di interfaccia montata su slot ISA : i messaggi su questo bus vengono scambiati ogni 20ms .

La comunicazione fra processore di I/O per il controllo , i drivers dei motori e gli encoders avviene sul bus CAN interno ( internal CAN bus ) , che non è accessibile all’utente e che è caratterizzato da un tempo di campionamento di 10ms.

Figura 4.8 : lo schema complessivo del controllore

I messaggi che dal processore di I/O verso l’utente vanno al Personal Computer contengono informazioni sullo stato del robot e sulle posizioni , mentre i messaggi che vanno dal PC al computer-box contengono gli ingressi di controllo . Questi ingressi sono dei movimenti da realizzare entro il tempo di campionamento del bus CAN esterno : degli spostamenti in un intervallo di tempo fisso equivalgono a delle velocità , come è ovvio che sia dato che la cinematica inversa è di tipo differenziale . Queste velocità sono quantizzate secondo i valori minimi indicati in tabella 4.1.

Tabella 4.1 : Gli incrementi minimi e massimi per gli ingressi del MANUS

Nel prossimo paragrafo sarà mostrato come questi valori vengono introdotti nei bytes di un pacchetto CAN : per ora si intende sottolineare come un incremento minimo di 0.1° ogni 20ms corrisponda ad una velocità minima di 5°/sec , ovvero ad una quantizzazione molto grossolana . Inoltre la comunicazione fra PC e computer-box non è simmetrica : le posizioni vengono inviate ogni 20ms , mentre le velocità di ingresso possono essere modificate solo ogni 60ms . Queste caratteristiche hanno influito in maniera determinante sul controllo di posizione che è stato realizzato , soprattutto per quanto riguarda la precisione : non si è riusciti ad andare sotto un intervallo rispetto al valore desiderato .

4.2 Il bus CAN

_{Il protocollo CAN , Controller Area Network , è uno standard di comunicazione seriale di tipo broadcast che permette il controllo real-time distribuito con un elevato grado di sicurezza . E’ stato introdotto dalla Bosch nei primi anni ‘80 per applicazioni automotive , per consentire cioè la comunicazione fra i dispositivi elettronici montati sugli autoveicoli , ma oggi trova largo impiego anche in settori come l’automazione industriale e l’ingegneria assistiva . Si ricorda a questo proposito il protocollo CAN-based Multi Master Multi Slave ( M3S ) che è appositamente concepito per la comunicazione del disabile con ausili tecnici anche molto eterogenei fra loro come carrozzelle , manipolatori , joystick , controllori vocali [13] . Un primo motivo di questa diffusione trasversale è costituito dalle esigenze comuni nell’interfacciamento di dispositivi automotive , industriali , assistivi , che sono:}

• _{tempi di risposta rigidi : è una specifica fondamentale nel controllo di processo così come nelle applicazioni con interazione fra macchina e utente , tanto più se disabile : la tecnologia CAN prevede la possibilità di connettere un elevato numero di dispositivi al bus mantenendo stringenti vincoli temporali ;}

• _{semplicità e flessibilità del cablaggio: il CAN è un bus seriale tipicamente implementato su un doppino intrecciato . I nodi non hanno un indirizzo che li identifica e possono quindi essere aggiunti o rimossi senza dover riorganizzare l’intero sistema ;}

• _{alta immunità ai disturbi : lo standard ISO11898 raccomanda che i chips di interfaccia possano continuare a comunicare anche in condizioni estreme quali l’interruzione di uno dei due fili o il cortocircuito di uno di essi a massa ;}

• _{elevata affidabilità : la rilevazione degli errori e la richiesta di ritrasmissione viene gestita direttamente dall’hardware del nodo con cinque metodi diversi , due a livello di bit e tre a livello di messaggio . Complessivamente questi controlli portano la probabilità di errore non rilevato sotto 10}^-13 _;

• _{confinamento degli errori : ciascun nodo è in grado di rilevare il proprio malfunzionamento e di autoescludersi dalla comunicazione in caso di guasto permanente . Con questo meccanismo la tecnologia CAN mantiene la rigidità delle temporizzazioni , impedendo che un solo nodo metta in crisi l’intero sistema.}

_{L’altro motivo della grande diffusione del bus CAN è la crescente domanda di elettronica nel settore automobilistico , che ha favorito l’integrazione del protocollo su un numero crescente di circuiti : l’ampia gamma di trasmettitori , ricevitori , microcontrollori e tool di sviluppo che utilizzano la tecnologia CAN ha messo i progettisti di altri settori di fronte ad una tecnologia matura e standardizzata , a differenza di altre reti dove l’accordo fra le case produttrici è ancora lontano dall’essere raggiunto , come i bus di campo . I microcontrollori considerati in questa tesi sono gli 80C592 del computer-box e l’integrato Philips 82C200 che permette l’interfacciamento del PC al bus CAN tramite scheda ISA . Quest’ultimo circuito non è più in commercio e , per descriverne le funzioni , nel paragrafo 4.2.4 si farà riferimento al data-sheet del suo successore , l’SJA1000 , che mantiene la completa compatibilità con l’82C200 [12].}

4.2.1 Il bus CAN secondo il modello ISO-OSI

_{Con riferimento alla definizione dei livelli di una rete di comunicazione operata dall’ISO , International Standard Organization , col progetto OSI , Open System Interconnection , il bus CAN implementa il Livello fisico ( Physical Layer ) e il Livello Data Link ( Data Link Layer ) , cioè i due livelli più bassi della pila : si caratterizza quindi come un protocollo più vicino a un Bus di Campo che ad una rete informatica del tipo Ethernet .}

bus CAN

Figura 4.9 La pila di livelli ISO-OSI

_{Il Data Link Layer è a sua volta scisso in altri due livelli: l’Object Layer ed il Transfer Layer ; il primo si occupa della gestione dei messaggi da trasmettere , dell’interfaccia con l’Application Layer e del filtraggio dei messaggi ricevuti: nel bus CAN la trasmissione è di tipo broadcast , cioè tutti i nodi ricevono gli stessi pacchetti e in base all’identificatore scartano quelli non rilevanti ; il secondo definisce le modalità di trasferimento : formato dei messaggi , arbitraggio , segnalazione e correzione degli errori, esclusione dei nodi mal funzionanti, sincronizzazione e bit-timing.}

_{Le proprietà dell’Object Layer dipendono dall’hardware che lo implementa : in questa tesi si farà riferimento alle specifiche del controllore Philips SJA1000 , il successore dell’82C200 montato sulla scheda di interfaccia ISA-bus CAN . Le caratteristiche del Transfer Layer costituiscono invece il nucleo del protocollo CAN e sono rigidamente specificate [11].}

_{La definizione dell’Application Layer è lasciata al progettista, al quale spettano i dettagli dell’interfacciamento con l’utente ; in questo caso gli end-point sono il PC e il computer-box , quindi il significato dei messaggi scambiati è stato deciso dall’azienda produttrice e verrà descritto nel paragrafo 4.3.}

4.2.2 Il livello fisico

_{Secondo il modello ISO-OSI il livello fisico deve specificare il mezzo trasmissivo , la rappresentazione dei bit e i livelli del segnale . Nel bus CAN il mezzo trasmissivo è un singolo canale bidirezionale , che può essere differenziale o a cavo singolo e terra : solitamente si usa un doppino intrecciato , schermato o meno a seconda della rumorosità dell’ambiente . Per quanto riguarda la rappresentazione dei bit , il flusso è codificato con il metodo NRZ , Non Return to Zero , mentre i livelli sono specificati definendo un livello dominante ( d ) e un livello recessivo ( r ) . La traduzione di d ed r in livelli logici dipende dal cablaggio adottato e deve fare in modo che , in caso di trasmissione contemporanea di un bit dominante e di uno recessivo , la linea assuma il livello dominante .}

Tabella 4.2 : La corrispondenza fra livelli logici e livelli d ed r nel bus CAN

4.2.3 Il Transfer Layer

_{Secondo le specifiche CAN [11] il Transfer Layer definisce il formato dei messaggi , la gestione degli errori , l’arbitraggio in caso di trasmissioni contemporanee , il confinamento dei nodi mal funzionanti , la validazione dei messaggi , la sincronizzazione ed il bit-timing.}

_{Si hanno 4 possibili formati : Data Frame , Remote Frame , Error Frame e Overload Frame . Verranno ora spiegati i significati di ciascun possibile messaggio , soffermandosi in particolare sul Data Frame ( DF ) e il Remote Frame ( RF ) , perché i messaggi scambiati fra computer-box e 82C200 hanno questo formato .}

_{Il Data Frame è il pacchetto che trasmette i dati da un trasmettitore ( TX ) a tutti gli altri nodi , che si comportano come ricevitori ( RX ) e decidono se ritenerli rilevanti o scartarli . E’ composto di 7 campi , come mostrato in figura 4.10 :}

1. _{Start of Frame ( SOF ), costituito da un solo bit dominante e utilizzato per segnalare l’inizio del messaggio. Ha anche una funzione di sincronizzazione per tutti i nodi in ascolto che riconoscono l’inizio della trasmissione.}

2. _{Arbitration Field , costituito dall’identificatore ( ID ) più un bit RTR ( Remote Transmission Request ) che distingue fra Data Frame e Remote Frame : è dominante nel DF e recessivo nel RF ; in questo modo nel caso di contemporanea richiesta di un dato e trasmissione dello stesso quest’ultima ha la precedenza. L’identificatore è di 11 bit nel protocollo CAN 2.0A ( Standard CAN ) e di 29 bit nel CAN 2.0B ( Extended CAN ) .}

3. _{Control Field , costituito da 6 bit, di cui i primi 4 specificano la lunghezza del campo dati e costituiscono il Data Length Code ( DLC ) e gli altri 2 sono riservati per future espansioni del protocollo . La codifica dei bits del DLC è indicata in tabella 4.3}

Tabella 4.3 : la codifica dei bits per il Data Length Code nel Control Field

4. _{Data Field , che contiene i dati veri e propri , da un massimo di 8 bytes ad un minimo di 0 , inviati dal più significativo al meno significativo .}

5. _{CRC Field , costituito da 16 bits : i primi 15 costituiscono la sequenza di controllo ciclico della ridondanza effettuato sui bit dei campi precedenti , mentre l’ultimo è un bit recessivo di delimitazione. La ridondanza ciclica è un metodo per la rilevazione degli errori che consiste nel considerare la stringa di dati come un polinomio binario e nell’accodare una stringa di bit che lo renda divisibile per un polinomio generatore : è uno dei 5 metodi di rilevazione degli errori che rendono il protocollo CAN estremamente affidabile . Se il campo CRC non rivela errori , il nodo invia un bit recessivo nel campo ACK del Data Frame .}

6. _{ACK Field , costituito da un bit ACK Slot ed uno recessivo di delimitazione , detto ACK delimiter . Nel tempo di bit riservato all’ACK slot il trasmettitore interagisce con gli altri nodi : un ricevitore che riconosca un messaggio corretto sovrascrive il bit recessivo con uno dominante . Il trasmettitore si accorge così che almeno un nodo ha ricevuto correttamente i dati .}

7. _{End of Frame ( EOF ), costituito da 7 bits recessivi che indicano la fine del Frame.}

Figura 4.10 : La struttura di un Data Frame

_{Il Remote Frame è il messaggio inviato da un nodo che vuole forzare l’invio di un dato da parte di un altro : nell’identificatore viene specificato il tipo di dato e il trasmettitore interessato invia un Data Frame contenente l’informazione richiesta . La struttura di un Remote Frame è indicata in figura 4.11 ed è simile a quella di un Data Frame : i campi si riducono da 7 a 6 per l’assenza del Data Field e il bit RTR è recessivo anziché dominante .}

Figura 4.11: La struttura di un Remote Frame

_{L’Overload Frame viene inviato da un nodo che riconosce di essere busy e di non poter ricevere correttamente il Frame successivo : provoca la risposta con un Overload Frame da parte di tutti nodi in ricezione , ritardando così l’invio dei dati sulla linea . E’ sufficiente che un nodo invii un Overload Frame perché la comunicazione di tutti gli altri venga ritardata , quindi il protocollo CAN prevede un meccanismo di confinamento dei nodi più lenti , impedendo ad un end-point di inviare due Overload Frames successivi . La struttura è costituita da due campi , come mostrato in figura 4.12 :}

• _{Overload Flag , che consiste in 6 bit dominanti e può sovrascrivere un Interframe Space , cioè la sequenza di bit che intercorre fra due Remote Frame o Data Frame . La scrittura è ammessa entro i primi tre bit dell’Interframe Space , mentre dopo questo termine viene interpretata come lo Start of Frame di un DF o RF .}

• _{Overload Delimiter , costituito da 8 bit recessivi.}

Figura 4.12 : La struttura di un Overload Frame

_{L’Error Frame viene inviato se un nodo rivela un errore in un Remote Frame o in un Data Frame e può sovrascrivere i campi ACK e EOF di questi messaggi . Provoca la trasmissione di un Error Frame da parte di tutti gli altri nodi ed è composto di due campi , come mostrato in figura 4.12 :}

• _{Error Flag , costituito da 6 bit dominanti o recessivi : in caso di 6 bit dominanti si parla di Active Error Flag , mentre in caso di 6 bit recessivi si ha un Passive Error Flag ; gli Active Error Flag possono distruggere il traffico presente sul bus , impedendo la terminazione di un Data Frame o di un Remote Frame , mentre i Passive Error Flag non hanno questa facoltà .}

• _{Error Delimiter , costituito da 8 bit recessivi.}

Figura 4.13 : La struttura di un Error Frame

Ciascun nodo si pone nello stato attivo o in quello passivo in base ai valori di due contatori interni :

• _{il Receive Error Counter , che tiene conto degli errori rilevati dal nodo in ricezione .}

• _{il Transmit Error Counter , che tiene conto degli errori in trasmissione , rilevati dal nodo stesso o segnalati dagli altri con Error Frames .}

_{Se entrambi i contatori sono inferiori a 128 il nodo è nello stato Error Active , se almeno un contatore supera tale valore si pone nello stato Error Passive , mentre se almeno uno dei due raggiunge il valore di 256 il nodo si autoesclude dal bus ponendosi nella modalità bus off ; in questo stato l’endpoint è autorizzato solo a leggere i messaggi sul bus e ad attendere una sequenza di 11 bit recessivi consecutivi che ne permette il reintegro .}

_{Gli incrementi dei contatori per il confinamento dei guasti sono diversi a seconda della gravità dell’errore rilevato ; il protocollo definisce 5 tipi di errore fra loro mutuamente esclusivi : Bit Error , Stuff Error , Crc Error , Form Error e Acknowledgement Error ; primi due sono a livello di bit , gli altri a livello di messaggio . Per ciascun tipo di errore è definita una tecnica di rilevazione :}

• _{Monitoraggio : ciascun nodo confronta i bit che invia con quelli presenti sul bus e in caso di discordanza si attribuisce un Bit error ; fa eccezione a questo monitoraggio il campo identificatore di un Data Frame o di un Remote Frame : la presenza di un bit diverso da quello inviato viene interpretata come perdita dell’arbitraggio per la trasmissione e di conseguenza l’end-point si pone in modalità di ricezione .}

• _{Bit stuffing : è una tecnica che consiste nel trasmettere dopo ogni sequenza di 5 bit uguali un sesto bit complementare , che viene automaticamente ignorato dai nodi ricevitori . Viene utilizzata nei Data Frame e nei Remote Frame , mentre un Error Frame può violare questa regola . Se un ricevitore rileva 6 bit consecutivi dello stesso tipo si ha uno Stuff Erro r.}

• _{Controllo ciclico di ridondanza : ciascun nodo ricevitore calcola la sequenza CRC corrispondente al messaggio arrivato e la confronta con quella accodata dal trasmettitore . In caso di differenza fra le due sequenze si ha un CRC error.}

• _{Controllo dei Frame : se il ricevitore rileva che non sono state rispettate le 5 possibili strutture dei frame CAN definite in questo paragrafo genera un Form Error.}

• _{Acknowledgement bit : ciascun nodo che riceve correttamente un Data Frame o un Remote Frame invia un bit dominante nel bit-time del campo ACK . Se la sovrascrittura non avviene il bit ACK-Slot resta recessivo e il trasmettitore invia un messaggio di errore ; questa situazione si verifica solo se nessuno dei nodi in ascolto ha inviato correttamente il bit di ACK , perciò è piuttosto rara.}

4.2.4 L’Object Layer e il controllore 82C200

_{Le funzioni svolte dall’Object Layer dipendono dal particolare CAN Protocol Controller utilizzato ( CPC ) . In questo caso l’End-Point da controllare è l’interfaccia ISA-bus CAN mostrata in figura , che si basa sul controllore Philips PCA 82C200 , oggi non più in commercio e sostituito dal CPC SJA1000 , comunque compatibile col predecessore .}

Figura 4.14 : L’interfaccia ISA-bus CAN

_{Non si entrerà nel dettaglio del funzionamento della scheda , ma ci si soffermerà sul significato dei registri del CPC perché sono utilizzati dal programma driver di controllo e comunicazione col MANUS . Il PCA 82C200 permette di leggere e scrivere questi registri con un’operazione di memory-mapped I/O , cioè di lettura e scrittura in determinati indirizzi , come se si trattasse di normali locazioni di memoria . Gli indirizzi sono nella forma “ base + spiazzamento “ , con la base pari a 0x300 , come mostrato in tabella 4.4 .}

Tabella 4.4 : Gli indirizzi di lettura e scrittura dei registri del CPC 82C200

_{I registri più importanti utilizzati dal programma driver riportato in appendice A sono :}

• _{Control Register : definisce il comportamento del CAN Protocol Controller . Ciascuno degli 8 bit del registro possono essere settati o resettati per abilitare o disabilitare le funzioni corrispondenti , come la generazione di un Interrupt al termine di ogni ricezione e trasmissione o al verificarsi di un errore.}

• _{Command Register : i bit di questo registro comandano l’esecuzione di azioni come la richiesta di trasmissione , il rilascio del buffer di ricezione o l’aborto di una trasmissione . Ad esempio mediante l’istruzione C outp(0x301,0x01) si abilita l’invio del messaggio composto a partire dai registri TX Identifier , TX RTR e TX Bytes.}

• _{Status Register : appare al programma di controllo come una memoria di sola lettura , i cui bit contengono informazioni sullo stato del controller .}

• _{Interrupt Register : quando il Controller CAN genera un interrupt i bit di questo registro vanno letti per risalire all’evento che lo ha generato .}

• _{TX identifier1 e TX identifier2 : sono due registri in cui scrivere l’identificatore del messaggio da trasmettere , il Data Length Code e il bit RTR . Questo bit risiede nel registro TX Identifier 2 , quindi questo byte è anche indicato come TX RTR register.}

• _{TX bytes 1,..,8 : sono i registri in cui scrivere i bytes dei dati da trasmettere .}

• _{RX Identifier1 e RX Identifier2 : sono i registri in cui leggere l’identificatore , il Data Length Code e il bit RTR del messaggio ricevuto .}

• _{RX bytes 1,..,8 : sono i registri in cui vengono letti i bytes di dato del messaggio ricevuto .}

_{4.3 La comunicazione fra Personal Computer e MANUS}

_{In questo paragrafo verrà particolareggiata la teoria dei paragrafi precedenti alla comunicazione fra il CAN Protocol Controller 82C200 della scheda ISA e il processore di I/O verso l’utente del computer-box : si esporranno la struttura della rete , il formato dei messaggi , il significato da attribuire agli identificatori e ai dati . Il bus è composto da due soli nodi , il supporto fisico è bifilare non intrecciato con terminali a 9 pin , di cui solo 2 sono utilizzati . I messaggi scambiati sono per lo più Data-Frames con un solo Remote-Frame che viene inviato dal computer-box al Personal Computer per la richiesta di un comando . Il significato degli identificatori dei messaggi è illustrato in tabella 4.5 .}

Tabella 4.5 : I Data Frames e i Remote Frames scambiati fra PC e computer-box

_{I messaggi vengono scambiati secondo un protocollo rigido caratterizzato da una tempistica predefinita : il computer-box invia due Data Frames con identificatore 0x350 e 0x360 e un Remote Frame con identificatore 0x37F spaziati fra loro di 20ms ; al termine di questo intervallo di 60ms il Personal Computer ha tempo 20ms per inviare uno dei Data-Frames a sua disposizione , indicati in tabella 4.5 . Se , trascorso questo tempo , il CAN Protocol Controller non ha ancora risposto con alcun comando il computer-box continua ad eseguire i movimenti precedenti . Il manuale del costruttore [7] presenta come possibile esempio di comunicazione fra i due end-point quello descritto in tabella 4.6 .}

Tabella 4.6 : Un esempio di possibile comunicazione fra PC e Computer-box

_{Della rigidità di questa comunicazione è stato tenuto conto nello sviluppo del driver di comunicazione e controllo descritto nel paragrafo 5.1 : il numero e la complessità delle istruzioni eseguite fra l’arrivo del Remote Frame e l’invio del Data Frame di comando deve essere tale da consentire di rispettare questi tempi , per garantire la sicurezza dell’utente . Se il MANUS è in movimento e il computer-box non riceve alcun messaggio dal programma di controllo continua a mantenere le velocità comandate con l’ultimo Data-Frames , impedendo lo stop di emergenza .}

_{Per concludere , in tabella 4.7 è riportato il significato dei bytes di dato dei DF per i messaggi in entrambe le direzioni :}