Capitolo 4 L’Hardware e la meccanica del sistema


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:

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 .


Figura 4.4 : la configurazione di minimo ingombro

Figura 4.5 La configurazione di massima estensione


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

Asse

Delta di incremento

Incremento minimo

Incremento massimo

Control-box 1 : controllo nello spazio cartesiano

X

0.022mm

0

127

Y

0.022mm

0

127

Z

0.022mm

0

127

Yaw

0.1°

0

10

Pitch

0.1°

0

10

Roll

0.1°

0

10

Pinza

0.1mm

0

15

Control-box 4 : controllo diretto dei giunti

Giunto 1

0.1°

0

10

Giunto 2

0.1°

0

10

Giunto 3

0.1°

0

10

Giunto 4

0.1°

0

10

Giunto 5

0.1°

0

10

Giunto 6

0.1°

0

10

Pinza

0.1mm

0

15


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:

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

Cablaggio wired-AND:

d=0

r=1

Cablaggio wired-OR :

d=1

r=0


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 :

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

Bytes nel DATA FIELD

Bits del DATA LENGHT CODE

DLC3

DLC2

DLC1

DLC0

0

D

D

D

D

1

D

D

D

R

2

D

D

R

D

3

D

D

R

R

4

D

R

D

D

5

D

R

D

R

6

D

R

R

D

7

D

R

R

R

8

R

D

D

D

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 :

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 :

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 :

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 :



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

Registro

Indirizzo

Registro

Indirizzo

Control Register

0x300

Test

0x309

Command Register

0x301

TX Identifier

0x30A

Status Register

0x302

TX RTR

0x30B

Interrupt Register

0x303

TX Bytes 1,..,8

0x30C,..,0x313

Acceptance Code

0x304

RX Identifier

0x314

Acceptance Mask

0x305

RX RTR

0x315

Bus Timing 0

0x306

RX Bytes 1,..,8

0x316,..,0x31D

Bus Timing 1

0x307

Clock Divider

0x31F

Output Control

0x308




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




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

Identificatore

DLC

Interpretazione del messaggio

Data Frames dal computer box al Personal Computer

0x350

8

Stato del sistema e posizione assi da 1 a 3

0x360

8

Posizione degli assi da 4 a 7

Remote Frames dal computer box al Personal Computer

0x37F

0

Interrogazione per un comando dal PC

Data Frames dal Personal Computer al computer box

0x370

0

Selezione del cbox 0 ( inizializzazione )

0x371

8

Selezione del cbox 1 e posizioni desiderate

0x374

8

Selezione del cbox 4 e posizioni desiderate

0x375

0

Selezione del cbox 5 (Fold out)

0x376

0

Selezione del cbox 6 (Fold in)


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

Tempo

TXRX

Descrizione del messaggio

20ms

Computer-boxPC

ID0x350 , stato del sistema e posizione assi

40ms

Computer-boxPC

ID0x360 , posizione assi

60ms

Computer-boxPC

ID0x37F , Remote Frame di richiesta comando

<80ms

PCComputer-box

Data Frame , ID0x371 e dati nulli : seleziona cbox 0

80ms

Computer-boxPC

ID0x350 , stato del sistema e posizione assi

100ms

Computer-boxPC

ID0x360 , posizione assi

120ms

Computer-boxPC

ID0x37F , Remote Frame di richiesta comando

<120ms

PCComputer-box

Data Frame , ID0x371 e 2° byte=1: muovi lungo x


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 :


ID

byte

siginificato

ID

byte

significato

Data Frames dal PC al computer-box

0x371

1

Movimento lift-unit

0x374

1

Movimento lift-unit

0x371

2

Velocità lungo x

0x374

2

Velocità giunto 1

0x371

3

Velocità lungo y

0x374

3

Velocità giunto 2

0x371

4

Velocità lungo z

0x374

4

Velocità giunto 3

0x371

5

Velocità angolo roll

0x374

5

Velocità giunto 4

0x371

6

Velocità angolo pitch

0x374

6

Velocità giunto 5

0x371

7

Velocità angolo yaw

0x374

7

Velocità giunto 6

0x371

8

Movimento pinza

0x374

8

Movimento Pinza

Data Frames dal computer-box al PC

0x350

1

Byte di stato

0x360

1

MSB posizione roll o

0x350

2

Messaggio di errore

0x360

2

LSB posizion roll o

0x350

3

MSB posizione x o

0x360

3

MSB posizione pitch o

0x350

4

LSB posizione x o

0x360

4

LSB posizione pitch o

0x350

5

MSB posizione y o

0x360

5

MSB posizione yaw o

0x350

6

LSB posizione y o

0x360

6

LSB posizione yaw o

0x350

7

MSB posizione z o

0x360

7

MSB posizione pinza

0x350

8

LSB posizione z o

0x360

8

LSB posizione pinza

73


Torna al sommario


Torna alla home page di Ingegneria-elettronica.com