4 IMPLEMENTAZIONE
4.1 Strumenti utilizzati
L’implementazione del modello dinamico della barca a vela è stata effettuata grazie all’ambiente di sviluppo Matlab-Simulink, diventato ormai un punto di riferimento nell’implementazione e analisi di sistemi di controllo di complessi sistemi fisici. In questo paragrafo è introdotto il sistema di sviluppo XVR con cui è stato creato lo scenario virtuale della simulazione. Inoltre è stato descritto il preesistente progetto INDICA di cui è stata utilizzata l’infrastruttura hardware per la trasmissione degli stimoli generati dal modello dinamico della barca a vela.
4.1.1 Ambiente di sviluppo XVR
La visualizzazione è stata implementata mediante l’ambiente di sviluppo XVR messo a punto dal gruppo VR-Media afferente al laboratorio PERCRO [12],[13],[79]. XVR è un ambiente di sviluppo integrato per la creazione di applicazioni di realtà virtuale. Attraverso un’architettura modulare e un linguaggio di scripting modulare, applicazioni XVR possono essere inserite sia in pagine web con contenuti multimediali avanzati sia in più complesse applicazioni di realtà virtuale come i sistemi di proiezione stereo e gli HMD, acronimo per Head Mounted Displays. Originariamente ideato per fornire strumenti per lo sviluppo di contenuti multimediali avanzati, XVR ha esteso il suo campo di utilizzo verso applicazioni che usano l’interazione con l’utente. Accanto a strumenti dedicati allo gestione per sviluppo web, XVR consente di utilizzare una grande varietà di dispositivi per la realtà virtuale ed utilizza i più moderni algoritmi per la visualizzazione in tempo reale di complessi modelli tridimensionali. Un oggetto XVR si presenta come uno plugin ActiveX per Internet Explorer. Al primo accesso ad una pagina contenente un oggetto XVR viene richiesta l’installazione del plugin e dopo l’installazione viene visualizzata la specifica applicazione presente nel sito richiesto. Il maggior punto di forza di questo nuovo software è la compattezza delle applicazioni sviluppate; inoltre la possibilità di creare scenari mediante un linguaggio di programmazione rende virtualmente illimitate le possibilità di applicazione. XVR è attualmente utilizzato in numerosi progetti fra cui la visualizzazione tridimensionale di terreni, applicazioni di Cultural Heritage fra cui un esplorazione virtuale del Camposanto Monumentale e Piazza dei Miracoli a Pisa. Inoltre sono molte le applicazioni di intrattenimento e di educazione svolte in collaborazione con scuole del circondario pisano. In fig. 4-1 sono presenti degli screenshot di varie applicazioni sviluppate con XVR.
Fig. 4-1, Applicazione del software di sviluppo XVR
Un elenco non certamente esaustivo delle caratteristiche di questo potente e versatile strumento di sviluppo sono:
• Motore grafico basato su OpenGL
• Linguaggio di script con supporto alla programmazione OpenGL a basso livello • Supporto al Pixel e Vertex shaders
• Compilatore integrato nell’ambiente di sviluppo • Possibilità di introdurre moduli esterni a run-time
• Utilizzo del motore fisico Tokamak(TM) per riprodurre effetti dinamici in tempo reale
• Interazione con pagine HTML mediante l’utilizzo di Javascript or VBScript • Supporto a video AVI includendo DivX e MPEG
• Supporto a numerosi formati audio
• Supporto audio tridimensionale mediante Direct Audio o OpenAL • Gestione delle periferiche di ingresso mediante DirectInput • Supporto a connessioni remote utilizzando i protocolli TCP e UDP
Descrizione del linguaggio di scripting S3D
L’ambiente di sviluppo ha un layout tipico: mentre sulla parte sinistra dello schermo sono presenti le risorse del progetto corrente, nella parte destra si ha un editor di testo per lo sviluppo del codice. Il linguaggio utilizzato è il S3D, un linguaggio di scripting classico ma con numerose funzioni aggiuntive per creazione e gestione di complessi scenari virtuali. In un applicativo XVR sono sempre presenti 6 funzioni fondamentali che vengono automaticamente introdotte dal wizard durante la creazione di un nuovo progetto, come mostrato in fig. 4-2.
Fig. 4-2, Funzioni generate dallo wizard di XVR Tali funzioni sono:
• Funzione OnDownload() • Funzione OnInit() • Funzione OnFrame()
• Funzione OnUpdate() • Funzione OnEvent() • Funzione OnExit()
La funzione OnDownload() viene eseguita all’inizio e permette di caricare tutti i file necessari all’applicazione. La funzione OnInit() contiene il codice di inizializzazione delle diverse variabili. La funzione OnFrame() contiene il codice per la vera e propria visualizzazione della grafica. La funzione OnTimer() viene eseguita indipendentemente dalla funzione OnFrame() ed in essa deve essere inserito il codice che deve essere indipendente dal processo di rendering. E’ possibile specificare la frequenza di esecuzione sia della funzione OnFrame() sia della funzione OnTimer(). La funzione OnEvent() è indipendente dalla funzione OnFrame() che dalla funzione OnTimer() ed è eseguita quando l’applicazione riceve un messaggio la cui sorgente può essere interna od esterna. La funzione OnExit() è richiamata quando l’applicazione termina.
Oltre alle basilari funzioni matematiche e dichiarazioni di variabili, XVR definisce una serie di classi e nuove funzionalità orientate alla grafica tridimensionale di cui nella Fig. 4-3 è presente uno schema riassuntivo. Verranno presentate nel seguito le principali classi utilizzate all’interno del lavoro di tesi e per una completa trattazione si rimanda a [77]. Le principali funzioni per la gestione della grafica sono Scene e Camera che permettono di settare le principali proprietà della scena e del punto di vista dell’applicazione. La classe CVmLight fornisce le funzionalità relative all’illuminazione. I modelli tridimensionali vengono gestiti dalla classe CVmMesh introducendo metodi per la gestione delle proprietà geometriche dell’oggetto, mentre la classe CVmObject introduce la manipolazione dei sistemi di riferimento e delle trasformazioni geometriche. Inoltre l’aspetto degli oggetti è gestito dalle classi CVmMaterial e CVmTexture. Le classi CVmAvatar e CVmCharacter sono molto utili per l’utilizzo di complesse gerarchie di oggetti fornendo la disponibilità di manipolazione del singolo componente. Sono naturalmente presenti le classi che permettono di introdurre l’utilizzo di suoni nelle applicazioni sviluppate. In particolare le classi CVmMidi, CVmAvi e CVmMp3 forniscono il supporto per aggiungere suoni, musica e parlato alle applicazioni, mentre CVmAWav fornisce funzionalità di effetti sonori tridimensionali. Un altro importante gruppo di classi è dedicato all’interazione con l’utente e alla comunicazione. Sono infatti presenti le classi CVmMouse e CVmJoystick che permettono la comunicazione con le periferiche mouse e joystick e un’ulteriore serie di funzione per la lettura della tastiera.
L’introduzione delle precedenti classi permette naturalmente una programmazione ad alto livello ma sono disponibili anche una serie di funzionalità per la programmazione a basso livello grazie ad un completo adattamento delle funzioni OpenGL che possono essere inserite all’interno del codice.
Fig. 4-3, Funzioni e classi di XVR
L’ambiente di sviluppo è inoltre correlato di due strumenti utili in fase di implementazione della specifica applicazione. Il primo è un esportare di modelli tridimensionali per 3DStudio Max. Tale plugin permette l’esportazione di oggetti tridimensionali creati in 3DStudio nel formato AAM che viene utilizzato all’interno di XVR. L’esportazione di una scena o di un singolo oggetto all’interno del programma apre una finestra di dialogo analoga a quella mostrata in fig. 4-4.
E’ possibile quindi selezionare delle opzioni che permettono di esportare l’oggetto selezionato in modo adatto alle varie esigenze. Per una completa trattazione delle opzioni disponibili e la descrizione del formato grafico AAM si rimanda a [10] e [11].
Il secondo strumento in corredo a XVR è un visualizzatore di oggetti nel formato AAM di cui in fig. 4-5 è presente uno screenshot.
Fig. 4-5, Visualizzatore di oggetti nel formato AAM
4.1.2 Simulatore INDICA
INDICA è un simulatore della guida per carrello elevatori e l’addestramento dei carrellisti. Uno studio preliminare ha evidenziato la forte incidenza degli incidenti alla guida nell’ambito degli infortuni in ambiente di lavoro. L’addestramento di persone all’interno di un simulatore permette in totale sicurezza di trovare o indurre situazioni che ne possano determinarne il ribaltamento e in questo modo insegnare all’utente ad evitare tali situazioni di pericolo. Per realizzare una totale immersione dell’operatore nell’Ambiente Virtuale e rendere quindi la simulazione più realistica, oltre al feedback in forza generato con i comandi primari, è necessario replicare sull’operatore anche tutte le forze di natura inerziale (realizzando quella che viene definita retroazione inerziale o feedback vestibolare) con le quali è possibile far avvertire all’operatore quegli stimoli che esso percepirebbe se si trovasse alla guida di un veicolo reale durante le fasi di accelerazione, di sterzata e durante un ribaltamento causato da errata manovra. Un’immagine del simulatore indica è presente in fig. 4-6. Nel seguito è presente una breve descrizione del progetto INDICA e per una completa documentazione si rimanda alla bibliografia [6][7][37].
Schema generale
Uno schema generale dell’infrastruttura del simulatore INDICA è rappresentato in fig. 4-7 ed è formato dai seguenti componenti:
Fig. 4-6, Il simulatore INDICA
• un cockpit o mock-up in cui è replicato l’abitacolo di un tipico carrello elevatore su cui l’utente siede ed effettua le tipiche operazioni di guida( accelerare, frenare, svoltare, azionare le forche, accendere le luci di segnalazione, etc)
• piattaforma di Stewart: robot a cinematica parallela che consente di muovere il mock-up e quindi l’operatore nello spazio secondo i sei gradi di libertà;
• un sistema grafico ed audio: consente la visualizzazione dello scenario esterno in cui il carrello si muove e la retroazione audio;
• un hardware per il controllo: un calcolatore che permette di gestire in tempo reale tutti i processi
Abitacolo e comandi primari
L’abitacolo è ottenuto mediante la cabina di un vero carrello e contiene tutte le interfacce dei comandi primari In Fig. 4-8 è mostrata una foto dell’abitacolo utilizzato in cui è possibile vedere lo sterzo, il pedale di accelerazione, il freno e la serie di leverismi a ritorno di forza che permettono la movimentazione delle forche presenti nella parte anteriore del muletto.
Fig. 4-8, Abitacolo e comandi primari Piattaforma di Stewart
La movimentazione del mock-up è effettuata grazie ad una piattaforma di Stewart. L’utilizzo di tale piattaforma nei simulatori dinamici è necessaria per garantire ottime caratteristiche di precisione, elevato rapporto carico/peso ed elevata rigidezza strutturale.
IL sistema di movimentazione consente di muovere oggetti nello spazio secondo i 6 g.d.l. assicurando una elevata rigidezza del sistema, ottime accelerazioni e precisione di posizionamento. L’hardware meccanico è composto da:
• Frame di base • Piattaforma mobile • 6 attuatori lineari • 12 giunti universali
La piattaforma scelta per realizzare il simulatore è la piattaforma di Stewart della MOOG modello 6DOF2000E. Essa ha un carico massimo di 1000 Kg e può raggiungere la velocità di 30 deg/s in roll e pitch e 40 deg/s in yaw, 0.4 m/s in direzione di heave e 0.3 m/s in direzione di surge e sway. Per quanto riguarda le accelerazioni la piattaforma è in grado di raggiungere 500 deg/s² in Roll and Pitch, 400 deg/s² in Yaw, 0.5g in Heave and 0.6g in Surge and Sway.
Sistema di visualizzazione grafica e riproduzione audio
Per poter offrire all’operatore un’ampia visuale, sono stati installati a bordo del simulatore 2 proiettori DLP in grado di generare l’intero scenario. E’ stata utilizzata la tecnica della retroproiezione con schermi a bordo e visualizzazione mono per simulare sia la vista frontale che posteriore. Il simulatore è dotato di un impianto di diffusione audio per la riproduzione degli effetti sonori tipici dell’ambiente di lavoro
Tramite l’ambiente di sviluppo XVR è stato creato uno scenario virtuale in cui la simulazione ha luogo e di cui in fig. 4-11 è mostrato un’immagine.
Fig. 4-11, Scenario virtuale creato tramite XVR
Hardware per il controllo
Un hardware per il controllo: un calcolatore che permette di gestire in tempo reale tutti i processi software che sovrintendono l’intero sistema.
Il sistema prevede la presenza di due calcolatori:
• PC Stewart ( PcS ): unità di calcolo per la gestione ed il controllo della PKM. In particolare sul calcolatore risiede il software di controllo del movimento (algoritmi di cinematica inversa) che consente alla piattaforma di Stewart di inseguire la traiettoria impostata dal modulo di Washout filter. Inoltre PcS è in grado di bloccare la simulazione qualora venisse richiesta alla piattaforma di eseguire una traiettoria che la porti in punti di singolarità e in generale in tutti i casi in cui si verifichi una emergenza: caduta della tensione di alimentazione al sistema, azionamento del pulsante di stop di emergenza. In tali condizioni il PcS prende il controllo incondizionato della piattaforma bloccandola istantaneamente nella posizione raggiunta. L’operatore che sovraintende alla simulazione può in un secondo tempo segnalare al PcS di riportare la piattaforma nella posizione di riposo.
• PC di Architettura ( PcA ): unità di calcolo per la gestire in tempo reale di tutti i processi software necessari per l’esecuzione della simulazione.
4.2 Definizione delle specifiche per il funzionamento
In fig. 4-12 è presente l’architettura generale del sistema.
Fig. 4-12, Architettura generale del sistema
Gli ingressi del modello dinamico della vela sono i segnali provenienti dal mock-up della piattaforma e la loro integrazione è descritta nella sezione 4.7. Le condizioni ambientali che descrivono il contesto in cui la simulazione avviene quali la condizione del vento e del moto ondoso sono regolabili nella simulazione attraverso l’interfaccia descritta nella sezione 4.6. Del modello dinamico vero è proprio, nel quale agiscono le forze e i momenti descritti nella sezione 3.5, è presentata l’implementazione sotto forma di schemi Simulink descritta nella sezione 4.3. Lo scenario virtuale, descritto nella sezione 4.5, riceve la posizione e l’orientazione dell’imbarcazione e provvede a una corretta visualizzazione dell’evolversi della simulazione. Nella sezione 4.4 viene descritto il controllo vero e proprio della piattaforma effettuato in base agli stimoli che il sottosistema di retroazione vestibolare calcola in base alle accelerazioni lineari e angolari ricevute dal modello matematico.
In fig. 4-13 è mostrato lo schema simulink che gestisce tutto il sistema e, naturalmente, ha una struttura analoga a quella presente nello schema in fig. 4-12. Gli ingressi dalla piattaforma sono utilizzati dal modello dinamico per il calcolo delle accelerazioni subite dal timoniere. Tali accelerazioni sono utilizzate dal blocco di retroazione vestibolare per fornire le posizioni da inseguire per l’end-effector della piattaforma di Stewart. La risoluzione dell’equazioni della cinematica inversa sono effettuate nel sottosistema Controllo Piattaforma. Tutto il sistema è monitorato dalla logica di controllo implementata tramite una macchina agli stati finiti che prende in ingresso lo stato del modello matematico della barca a vela e della piattaforma e restituisce i comandi che stabiliscono i vari stati della simulazione.
Fig. 4-13, Modello Simulink dell'infrastruttura generale del sistema
4.2.1 Integrazione con il modello matematico
Per quanto riguarda l’integrazione del modello matematico con il programma di visualizzazione è stato utilizzato il metodo della memoria condivisa per la comunicazione dei due processi. Come schematizzato in fig. 4-14, mediante una s-function inserita nel modello matematico sono stati scritti in una zona di memoria messa a disposizione del sistema operativo, una serie di informazioni necessarie alla sincronizzazione dell’ambiente virtuale con lo stato della navigazione nei vari istanti. Tali valori vengono letti dal programma di grafica è utilizzati per una corretta visualizzazione della navigazione.
Le simulazioni effettuate in ambiente Simulink hanno avuto due diversi scenari contraddistinti dall’utilizzo o meno della compilazione del modello mediante il Real-Time Workshop di Matlab. Il suo utilizzo, che crea un file eseguibile che può essere avviato al di fuori dell’ambiente di sviluppo simulink, ha contribuito enormemente alla fluidità con cui la piattaforma forniva le sensazioni di movimento all’utente. Come schematizzato in fig. 4-15, è stato utilizzato il metodo della memoria condivisa per la comunicazione delle informazioni al programma di visualizzazione.
Fig. 4-14, Integrazione con il modello matematico senza l'utilizzo del Real-time Workshop
Fig. 4-15, Schema dell'integrazione del modello matematico con Real-Time Workshop
4.3 Schematizzazione Simulink
In questo paragrafo è presentata l’implementazione delle varie componenti del modello dinamico della barca a vela utilizzando il software di sviluppo Simulink inserito in Matlab. Una rappresentazione di tutti i sottosistemi presenti nello schema generale implementato è presentata in fig. 4-16 e in fig. 4-17 dove, per motivi di spazio, uno schema analogo illustra la struttura del sottosistema per la generazione delle forze e dei momenti. Il numero elevato dei sottosistemi è risultato da una precisa volontà di sviluppare un modello che fosse estremamente versatile e per rendere trasparente la funzione dei vari sottosistemi. Nei futuri sviluppi del simulatore sarà quindi possibile modificare solamente le parti interessate senza che l’intera struttura debba essere riprogettata.
Per una maggior chiarezza nella figura sono state evidenziate le componenti del modello che sono dedicate all’interfacciamento con la piattaforma mobile e al suo controllo. Una descrizione di questa parte è presente in altre sezioni del presente documento.
Fig. 4-16, Schematizzazione dell'intero modello matematico della barca vela
Nelle pagine seguenti verranno descritti i più significativi sottosistemi simulink relativi al solo modello matematico della vela, il cui schema simulink è presente in fig. 4-18. I controlli dell’abitacolo della piattaforma mobile costituiscono i comandi che l’utente può dare durante la simulazione. La posizione del volante (timone), dei leveraggi (vele) e di altri pulsanti (motore fuori bordo) presenti nel mock-up sono processati dal blocco “Ingressi” che trasformerà tali segnali nell’angolo del timone della barca a vela, negli angoli di posizione della velatura e nella potenza del motore eventualmente utilizzabile durante la navigazione. Questa serie di segnali all’interno di tutto lo schema verranno definiti come “Com_umani”. In uscita dal blocco “Ingressi” sono inoltre presenti i dati relativi all’imbarcazione che verrà simulata e le condizioni ambientali nelle quali la simulazione avrà luogo. Nel blocco “Forze e Momenti” sono calcolate tutte le forze e i momenti che si generano durante la simulazione in base ai comandi umani, condizioni ambientali, tipo di barca e assetto del moto della barca stessa. Nel blocco “Integrazione” le forze e i momenti vengono semplicemente suddivisi e smistati in base alla loro retta di azione o intorno a quale asse agiscono. Le 3 forze risultanti e i 3 momenti risultanti sono gli ingressi del blocco “Equazioni del moto” nel quale vengono calcolate le nuove velocità ed accelerazioni dell’imbarcazione nel sistema di riferimento solidale ad essa secondo lo
schema di formule descritte in sezione 3.2. Nel blocco “Equazioni del moto” vengono calcolate le posizioni e le orientazioni nel sistema di riferimento fisso rispetto alla barca e tali informazioni vengono inviate nel blocco “Modulo di visualizzazione“ da dove verranno inviate, insieme alle altre informazioni illustrate, al programma di grafica.
Fig. 4-17, Schematizzazione del sottosistema relativo alla generazione di forze e momenti
Le uscite di questo modello generale sono le accelerazioni lineari e angolari che il timoniere avverte durante la navigazione. Tali accelerazioni saranno utilizzate dalla parte di controllo della piattaforma mobile per replicare effettivamente le sensazioni che l’utente percepisce sul proprio apparato vestibolare durante la simulazione.
Fig. 4-18, Schema Simulink del modello matematico di una barca a vela
In fig. 4-19 è illustrato in dettaglio il blocco “Ingressi”. Mediante una lettura in memoria condivisa operata dalla s-function ingressi_vela_sfun, vengono lette le informazioni impostate nella interfaccia utente precedentemente descritta. Informazioni sul vento, sul moto ondoso e la possibilità di utilizzare la regolazione automatica della velatura vengono smistate attraverso selettori nei blocchi “Comandi Umani”, “Caratteristiche ambientali” e “Caratteristiche imbarcazioni”. Il primo elabora le informazioni che arrivano dalla piattaforma mobile e li trasforma nei comandi che l’utente può fornire durante la simulazione. Il secondo non fa altro che assemblare in un unico segnale i vari agenti ambientali che influenzeranno la simulazione.
Dal terzo blocco è possibile settare le caratteristiche dell’imbarcazione: attraverso delle look-up table è possibile selezionare una delle 50 imbarcazioni descritte all’interno del DSYHS, le caratteristiche del timone, le caratteristiche della deriva e le caratteristiche della velatura.
Uno degli ingressi al blocco “Comandi umani” è il segnale autovele che discrimina se usare o meno la regolazione automatica della velatura. Se tale opzione è settata, le manovre sulle vele sono automatiche e la procedura prevede di porre fiocco, randa e spinnaker in modo tale che la loro posizione massimizzi la forza aerodinamica propulsiva. L’angolo con cui sono poste le vele dipende dalle curve caratteristiche dei coefficienti di portanza e resistenza e dalla direzione del vento apparente. In base a quest’ultimo viene imposta alle vele un angolazione tale che le pone in una posizione ottimale lasciando all’utente la possibilità di concentrarsi sulla navigazione.
In fig. 4-20 è illustrato in dettaglio il blocco “Forze e Momenti”. Per una maggiore modularità del modello, le forze in gioco sono state calcolate dividendo in ulteriori sottoblocchi a seconda del tipo di forza si faceva riferimento. Lo schema è stato quindi suddiviso in “Forze idrodinamiche”, “Forze aerodinamiche” e “Forze Gravitazionali e di Galleggiamento”. I tre blocchi hanno in ingresso le stesse informazioni, e le forze generate sono inviate in ingresso al blocco “Momenti” per il calcolo dei momenti.
Fig. 4-20, Schema Simulink del blocco "Forze e momenti"
La complessità della produzione delle forze idrodinamiche ha reso necessaria un’ulteriore suddivisione di tale blocco considerando l’elemento strutturale causa della particolare forza calcolata. Nelle s-function relative a tale sottosistema sono state implementate le espressioni dalla (4) alla (42) descritte nella sezione 3.5.1. Con riferimento alla fig. 4-21, si hanno, quindi, il blocco “Resistenza scafo”, “Resistenza deriva”, “Resistenza timone”, “Resistenza onde” e “Forza di scarroccio”.
Fig. 4-21, Schema Simulink del blocco "Forze idrodinamiche"
Il sottosistema per il calcolo della resistenza idrodinamica prodotta dallo scafo è mostrato in fig. 4-22. Nella s-function relativa a tale sottosistema sono state implementate le espressioni dalla (4) alla (7) e dalla (13) alla (15) descritte nella sezione 3.5.1.
Fig. 4-22, Schema Simulink del blocco "Resistenza scafo"
Gli ingressi di tale schema sono le caratteristiche dell’imbarcazione e l’assetto che l’imbarcazione ha in ogni istante. Per il calcolo della resistenza all’avanzamento sono infatti necessarie informazioni sulla struttura dell’imbarcazione e informazioni sulla sua velocità e orientazione. In particolare, in base al numero di Froude, calcolato nell’apposito blocco, sono individuati i coefficienti necessari per il calcolo della resistenza di forma e la resistenza aggiuntiva quando la barca naviga sbandata. Inoltre, in base all’angolo di sbandamento (heel), sono selezionati i coefficienti per il calcolo dell’area bagnata quando
la barca naviga con un certo angolo di rollio. In letteratura [53] sono disponibili tali coefficienti solamente per certi valori di numero di Froude e angolo di sbandamento. Per permettere una continuità nel calcolo di tali coefficienti si sono utilizzati algoritmi di interpolazione messi a disposizione delle look-up table di Matlab. Le informazioni necessarie sono gli ingressi di una s-function in cui è stato implementato il vero e proprio codice per il calcolo della resistenza di avanzamento dello scafo, sia nella direzione di moto che in direzione perpendicolare ad esso.
In fig. 4-23 è mostrato lo schema del blocco "Resistenza deriva" relativo solamente allo sviluppo di una certa resistenza all’avanzamento prodotto dalla deriva, mentre del calcolo della resistenza e della portanza idrodinamica ad essa associata si occupa il blocco “Forza di scarroccio”. Anche in questo schema è utilizzata una look-up table per la determinazione dei coefficienti necessari per il calcolo della resistenza di forma della deriva in base alla velocità dell’imbarcazione. Nella s-function relativa a tale sottosistema sono state implementate le espressioni dalla (8) alla (10) e l’espressione (16) descritte nella sezione 3.5.1.
Fig. 4-23, Schema Simulink del blocco "Resistenza deriva"
Le forze prodotte dal timone sono calcolate tramite la s-function mostrata in fig. 4-24. Oltre alle informazioni di assetto dell’imbarcazione e alle sue caratteristiche, il calcolo delle forze prodotte dal timone necessita dell’angolo del timone che l’utente può impostare.
Fig. 4-24, Schema Simulink del blocco "Resistenza timone"
Oltre alla resistenza all’avanzamento, sono calcolate le forze che il timone produce quando il timoniere vuol cambiare rotta.
Il sottosistema per il calcolo della forze dovute all’interazione con il moto ondoso è mostrato in fig. 4-25. Sono naturalmente necessarie le informazioni riguardanti la direzione di provenienza del moto ondoso in relazione alla rotta attuale dell’imbarcazione. Un blocco apposito, quindi, calcola l’angolo di incontro per determinare i coefficienti necessari per la formulazione della resistenza aggiuntiva che la barca subisce quando è investita da una
serie di onde in accordo su quanto illustrato in [34]. Nella s-function vengono svolti i calcoli necessari per determinare le forze che il profilo dell’onda genera sullo scafo in accordo con quanto spiegato nel modello di moto ondoso utilizzato.
Fig. 4-25, Schema Simulink del blocco "Resistenza onde"
La determinazione della portanza idrodinamica e della resistenza idrodinamica dovute allo scarroccio e dal rollio sono eseguite nel sottosistema illustrato in fig. 4-26. In base all’angolo di sbandamento sono calcolati i coefficienti necessari per il calcolo dell’effettivo pescaggio della deriva per prendere in considerazione gli effetti dell’avvicinamento delle appendici al bordo libero dell’acqua. Nella s-function relativa a tale sottosistema sono state implementate le espressioni dalla (17) alla (31) descritte nella sezione 3.5.1.3.
Fig. 4-26, Schema Simulink del blocco "Forze di scarroccio"
Sono calcolati quindi portanza e resistenza idrodinamica lungo i rispettivi assi di applicazione in base all’angolo di scarroccio, alla velocità di rollio, alla forza laterale idrodinamica e alla forza sbandante.
Le forze prodotte dalla velatura sono calcolate nel sottosistema “Forze Aerodinamiche” mostrato in fig. 4-27. In tale schema è inserito un modulo a parte per i calcoli relativi al vento apparente e all’andatura in cui la barca sta navigando. In uscita da tale blocco si
hanno 5 valori che rappresentano intensità e direzione del vento apparente e gli angoli di incidenza della velatura. Questi ultimi sono utilizzati per la determinazione dei coefficienti di portanza e resistenza aerodinamici ed a loro volta usati dalla s-function dove risiede il codice per il calcolo della forza propulsiva e della forza aerodinamica di sbandamento. In uscita dallo schema è inoltre disponibile la posizione del punto di applicazione di tali forze necessaria per il calcolo dei momenti generati dalla velatura. Nella s-function relativa a tale sottosistema sono state implementate le espressioni dalla (43) alla (61) descritte nella sezione 3.5.2.
Fig. 4-27, Schema Simulink del blocco "Forze aerodinamiche"
Le forze relative alla statica dell’imbarcazione vengono calcolate nello schema “Forze gravitazionali e di galleggiamento”. Le caratteristiche strutturali della barca sono necessarie per il calcolo della forza peso e della forza di Archimede come prevede la classica condizione di equilibrio a barca ferma.
Infine il calcolo dei momenti dell’intero sistema è effettuato all’interno del blocco “Momenti” mostrato in fig. 4-29. Sono necessari naturalmente il valore delle forze, precedentemente calcolate, ma anche le caratteristiche strutturali dell’imbarcazione e l’attuale assetto, in particolare l’angolo di rollio e di beccheggio.
Sono inoltre visibili in figura alcuni dei bracci necessari e fra essi si notano le coordinate del punto di applicazione delle forze aerodinamiche rispetto al centro di gravità, i bracci delle forze dovute alle onde e il braccio per il calcolo del momento raddrizzante dovuto alla forma stessa dello scafo. Quest’ultimo è calcolato, in base all’angolo di sbandamento,attraverso una look-up table in cui sono inseriti i dati della curva di stabilità della imbarcazione.
Fig. 4-29, Schema Simulink del blocco "Momenti" In fig. 4-30 è rappresentato lo schema relativo alle equazioni del moto.
In questo blocco vengono eseguite le integrazioni numeriche per il calcolo delle nuove velocità e posizioni. In base alle forze e ai momenti, precedentemente calcolati, nel sottosistema “Equazioni del moto” sono risolte le equazioni della dinamica dell’intero sistema e in uscita da tale blocco si hanno le nuove velocità lineari e velocità angolari nel sistema di riferimento solidale all’imbarcazione. Viene inoltre reso disponibile il vettore delle accelerazioni del centro di gravità che, opportunamente modificato, sarà inviato al washout filter per il controllo della piattaforma mobile. La posizione e l’orientazione della barca, necessarie al programma di grafica per la visualizzazione dello scenario virtuale, sono calcolate nel sottosistema “MobileÆFisso” nel quale vengono eseguite le opportune operazioni per passare dal sistema di riferimento solidale all’imbarcazione al sistema di riferimento fisso.
4.4 Sviluppo Controllo
In fig. 4-31 è rappresentata parte dell’architettura generale del simulatore in cui sono evidenziate le parti relative al controllo. Il modello dinamico della barca a vela fornisce le accelerazioni angolari e lineari di cui ha bisogno il Washout Filter (WF) per fornire le posizioni che l’end-effector della piattaforma deve inseguire. La risoluzione della cinematica inversa della piattaforma di Stewart è eseguita nel blocco “Controllo Piattaforma”. E’ necessaria una logica di controllo che monitorizzi gli stati del modello matematico e della piattaforma per fornire gli adeguati comandi durante le varie condizioni di funzionamento.
Fig. 4-31, Parte relativa al controllo dell’architettura generale
Il Washout Filter è il modulo software che ha il compito di elaborare la traiettoria e la strategia di movimento della piattaforma mobile del simulatore al fine di riprodurre sull’operatore le stesse sensazioni inerziali che percepirebbe durante le reali manovre di guida. Dal punto di vista dell’operatore questo implica stimolarne gli organi vestibolari posizionati all’interno delle orecchie e predisposti alla percezione delle accelerazioni lineari ( otoliti ) e delle velocità angolari ( canali semicircolari ). Per ovviare a questo e ridurre le corse ed il work-space necessario a replicare con sufficiente realismo la guida del veicolo, si ricorre ad un “trucco”, ingannando l’operatore con una semplice rotazione della
piattaforma (angolo di tilt). In questo modo gli organi vestibolari dell’operatore percepiranno parte della forza peso dovuta alla massa stessa dell’operatore come una forza dovuta invece ad accelerazione. Pertanto compito dello WF è di sfruttare il vettore gravità ruotando la piattaforma in modo da ottenere in prossimità della testa dell’operatore proprio quella componente del vettore gravità pari all’accelerazione lineare che deve essere simulata. Il progetto di un WF è un’operazione complessa e il suo sviluppo deve essere dedicato al particolare simulatore dinamico da implementare. Nel lavoro di tesi è stato utilizzato il WF utilizzato per il progetto INDICA e la definizione di un WF dedicato ad un simulatore di vela sarà oggetto di futuri sviluppi.
Particolare attenzione è stata posta nella messa a punto della logica di controllo per poter eseguire la simulazione in totale sicurezza per l’utente. Lo stato fisico della piattaforma viene costantemente monitorato per evitare che malfunzionamenti o eccessivi sollecitazioni alla struttura possano danneggiare sia l’utente che la struttura stessa.
La logica di controllo è stata implementata in ambiente simulink tramite una macchina a stati finiti (State flow) di cui in fig. 4-32 è presente la struttura principale.
Fig. 4-32, Macchina a stati finiti dedicata alla logica del controllo
Lo stato del modello matematico monitorato dalla logica di controllo riguarda l’angolo di rollio e di beccheggio che non possono superare un angolo pari a 0.5 radianti, condizione che porterebbe la piattaforma mobile ad un’eccessiva inclinazione.
Gli stati principali in cui la piattaforma si può trovare sono quello di RUN che identifica la condizione in cui la simulazione vera e propria sta avendo luogo e lo stato di IDLE in cui la piattaforma è pronta a ricevere i segnali dall’utente che determinano l’inizio della simulazione.
Il comando della logica di controllo al modello matematico è rappresentato dalla variabile “simPBM_start” che, inizializzata a 0, viene settata quando la piattaforma è pronta per
iniziare la simulazione. Nel caso che l’utente interrompa la simulazione, tale variabile viene portata a 0; ciò impone un reset totale dello scenario, e l’imbarcazione viene riportata nella posizione di partenza.
4.5 Sviluppo Ambiente Virtuale
In questa sezione vengono presentati i passi per lo sviluppo della grafica del simulatore. In particolare nella prima parte sono presentati i modelli tridimensionali utilizzati nella creazione dello scenario virtuale mentre nella seconda parte lo schema del codice all’interno del sistema di sviluppo XVR.
4.5.1 Modelli tridimensionali
Il modello grafico dell’imbarcazione è stato ricavato da un modello esistente di una barca a vela gareggiante nell’ America’s Cup. Sono state necessarie tuttavia una serie di modifiche per una più funzionale manipolazione del modello all’interno dell’ambiente di sviluppo XVR. Mediante il programma di grafica tridimensionale 3D Studio Max 7.0, sono state effettuate alcune modifiche riguardanti le varie componenti che costituiscono il modello grafico.
Fig. 4-33 Manipolazione del modello grafico tramite 3D Studio Max 7.0
Una prima modifica ha riguardato la duplicazione della velatura. L’operazione è stata necessaria in quanto nel modello base erano presenti solamente le componenti del fiocco e della randa con la concavità da una singola parte. Mediante una operazione di mirroring è stato possibile aggiungere al modello le componenti speculari per la randa e per il fiocco. Sono state poi raggruppate le varie componenti per similitudine dal punto di vista strutturale e funzionale. I gruppi creati sono:
• Scafo (comprensivo di deriva) • Randa destra
• Randa sinistra • Fiocco destro • Fiocco sinistro • Spinnaker • Timone • Barra
Per ogni gruppo è stato quindi definito un asse di rotazione e un pivot point . Ad esempio per i due gruppi della randa è stato definito l’asse di rotazione coincidente con l’albero dell’imbarcazione mentre per il fiocco coincidente con lo strallo di prua. Tale operazione è stata necessaria per agevolare la gestione delle manovre sulle vele limitando i relativi gradi di libertà al solo valore dell’angolo fra la corda della vela e l’asse di mezzeria dell’imbarcazione.
Il modello grafico così modificato è stato esportato nel formato AAM tramite l’utilità fornita con il sistema di sviluppo. Una visualizzazione dell’oggetto esportato è presente in fig. 4-34
Fig. 4-34, Visualizzazione del modello grafico della barca a vela esportato da 3D Studio Max Il modello è stato esportato come un oggetto di tipo CVmCharacter e ciò ha permesso una gestione di tipo gerarchico dell’intero modello fornendo la disponibilità di manipolazione del singolo componente.
Per rendere più realistica la simulazione si è poi provveduto ad inserire la barca a vela all’interno di uno scenario virtuale con un layout tipico di un porto sul mare aperto. In rete sono disponibili numerosi scenari di porti con molti particolari, ma la maggior parte di essi sono a pagamento. E’ stata scelta una strada alternativa consistente nella creazione di uno scenario personalizzato creato tramite il software di sviluppo per un noto gioco di simulazione come Virtual Sailor. Tale gioco fornisce, oltre gli scenari predefiniti, un’interfaccia per la creazione di nuovi scenari dando la possibilità di scegliere fra diversi modelli di fari, edifici e poter definire la linea di costa in modo arbitrario. E’ stato creato un semplice scenario di un porto marino comprensivo di faro, banchine, edifici sulla
terraferma e una linea di costa che attraverso uno stretto passaggio permette l’accesso a mare aperto. E’ stata però necessaria una serie di conversioni di formato per una corretta visualizzazione all’interno dell’ambiente di sviluppo XVR. Il formato dello scenario prodotto dal software di sviluppo di Virtual Sailor crea un file nel formato compatibile con le Microsoft DirectX e ciò ha reso necessaria la conversione in un formato compatibile con 3D Studio Max, per poi a sua volta essere convertito nel formato AAM. Una serie di programmi per la conversione di format tridimensionali è oggi presente sul mercato. Fra di essi un convertitore molto usato e ricco di opzioni per la conversione è Polytrans della Okino Software. Importando lo scenario creato con estensione DirectX (estensione del file .x) è stato convertito nel formato base di 3D Studio Max (estensione del file .3ds). Uno screenshot del programma Polytrans con il modello del porto da esportare è visualizzato in fig. 4-35.
Fig. 4-35, Scenario visualizzato nel software di conversione 3D Polytrans
Il porto virtuale è stato poi convertito dal formato 3D Studio Max al formato AAM sempre attraverso l’utilità di esportazione del formato AAM. Il porto virtuale mostrato con il visualizzatore di oggetti AAM è rappresentato in fig. 4-36.
Fig. 4-36, Visualizzazione del porto virtuale tramite il visualizzatore AAM
Lo scenario virtuale è stato poi completato con l’aggiunta di un cielo consistente in una semisfera a cui, tramite 3D Studio Max, è stato applicata una mesh di un tipico cielo con sole e nuvole. L’esportazione ha creato l’oggetto mostrato in fig. 4-37.
Fig. 4-37, Visualizzazione del cielo
Infine si presenta in fig. 4-38 un’idea dello scenario complessivo che è stato creato partendo dai vari componenti appena descritti rimandando alla prossima sezione la spiegazione in dettaglio del codice necessario per tale visualizzazione.
Fig. 4-38, Immagine dello scenario virtuale 4.5.2 Sviluppo del codice XVR
Uno schema del codice implementato nell’ambito dell’ambiente di sviluppo XVR è mostrato in fig. 39 mentre uno screenshot dell’ambiente di sviluppo è presente in fig. 4-40.
Con riferimento alla prima figura, le funzioni nei box gialli sono quelle che il wizard di XVR crea automaticamente e la loro funzione è stata descritta precedentemente.
In OnDownload() sono stati caricati tutti file necessari alla visualizzazione dello scenario virtuale. Oltre ai file AAM riguardanti il modello tridimensionale dell’imbarcazione, del porto e del cielo sono state memorizzate le varie texture per il processo di rendering dei modelli stessi e i suoni in formato wave che verranno riprodotti durante la simulazione. In OnInit() sono presenti tutte le inizializzazioni delle variabili presenti nel codice. In particolare si sono poste le luci della scena coincidenti con il sole presente nel modello del cielo e, mediante i costruttori delle classi definiti nel linguaggio S3D, i vari oggetti a cui nel codice si farà riferimento quali la barca, il porto e il cielo. In questa sezione viene creato il puntatore alla memoria condivisa da cui il codice leggerà i nuovi dati provenienti dal modello dinamico.
La funzione OnFrame() contiene il codice per la vera e propria visualizzazione della grafica ed è possibile specificare la frequenza di esecuzione di tale funzione. E’ impostazione comune definire tale frequenza come quella massima ottenibile dalla scheda grafica presente sull’elaboratore. La funzione OnTimer() viene eseguita indipendentemente dalla funzione OnFrame() ed in essa va inserito il codice che deve essere indipendente dal processo di rendering. Anche per tale funzione è possibile determinare la frequenza di esecuzione ed è stata impostata con la frequenza con cui i dati della posizione e dell’assetto vengono aggiornati dal modello dinamico. Le funzioni nei box verdi sono ulteriori funzioni definite per suddividere concettualmente il codice in blocchi funzionali.
Fig. 4-39 Schema del codice XVR
La funzione LeggiMemoria() ha il compito di leggere i dati dalla memoria condivisa e salvarli in un vettore reso visibile a tutte le funzioni presenti nel codice. In base ai valori letti in memoria condivisa, la funzione AggiornaGrafica() provvede ad aggiornare la nuova posizione e assetto raggiunte dall’imbarcazione. In particolare i dati che il modello dinamico trasmette alla grafica possono essere suddivisi nei seguenti gruppi:
• Posizione (x, y, z)
• Orientazione (rollio, beccheggio, angolo di virata) • Comandi umani (regolazione vele, timone)
• Informazioni ambientali : vento • Informazioni ambientali : onde
Mediante l’utilizzo della funzione membro SetPosition(x,y,z) è possibile traslare il centro del modello grafico, coincidente con il centro di gravità dell’imbarcazione, nei nuovi valori provenienti dal modello dinamico. Inoltre la nuova orientazione descritta dagli angoli di rollio, beccheggio e dall’angolo di virata vengono imposte tramite una serie di 3 funzioni membro del tipo SetRotation(angolo, asse) , la cui applicazione provoca una rotazione di un angolo “angolo” intorno all’asse specificato. Per una più corretta definizione di tali funzioni si rimanda all’help in linea dell’ambiente di sviluppo [77] .
L’esportazione del modello come tipo Character ha permesso la manipolazione dell’oggetto come una gerarchia di oggetti e ha fornito la disponibilità di modifica del singolo componente. In particolare mediante le funzioni membro della classe CVmCharacter ComponentSetRotation(id_comp,angolo,asse) è stato possibile applicare una rotazione di un angolo “angolo” rispetto all’asse “asse” alla sola componente indicata da “id_comp”. Con tale tecnica sono state applicate le posizioni aggiornate del fiocco, della randa, dello spinnaker, del timone e della barra del timone. Nella fig. 4-41 è presente una schermata dello scenario virtuale in cui è possibile notare la rotazione delle componenti relative alla randa e al fiocco dell’angolo imposto dall’utente o dalla regolazione automatica della velatura.
Come già accennato è stato necessario fornire al modello grafico dell’imbarcazione una velatura sia per una condizione di navigazione con mure a dritta che in una condizione di mure a sinistra. Per discriminare la posizione corretta della velatura è necessaria la direzione del vento apparente rispetto alla barca e grazie a tale valore è possibile abilitare o disabilitare una o l’altra visualizzazione della velatura. Grazie alle funzioni membro ComponentHide(id_comp) e ComponentUnHide(id_comp) è possibile nascondere o rendere visibile la componente identificata con “id_comp”. In fig. 4-42, a differenza della precedente, è possibile notare che il lato sottovento è quello di dritta, le vele si dispongono con le mura a sinistra e vengono visualizzate solamente le componenti effettivamente presenti in una analoga situazione reale.
Fig. 4-42, Cambio di mure nella regolazione delle vele
Nella precedente figura è visibile inoltre il triangolo del vento. Nella simulazione, non essendo possibile fornire all’utente un’indicazione reale della direzione del vento, è stato necessario aggiungere delle informazioni di tipo grafico per sopperire a questa mancanza. La funzione TriangoloVento() gestisce e rappresenta questo tipo di informazioni. Sia la direzione che l’intensità del vento sono specificabili dall’interfaccia utente precedentemente descritta, e tali informazioni sono state scritte in memoria condivisa in modo che la grafica possa visualizzare anche questo tipo di informazioni. Il vento apparente è stato rappresentato tramite una freccia blu la cui direzione coincide con la direzione da cui il vento sembra arrivare da una persona a bordo dell’imbarcazione, mentre la lunghezza è proporzionale all’intensità. La freccia rossa indica il vettore rappresentativo del vento reale ed infine la freccia nera rappresenta la velocità effettiva della barca a vela. Un’altra serie di informazioni presenti nella memoria condivisa sono riguardanti la visualizzazione del moto ondoso ed in particolare il codice XVR utilizza le informazioni relative all’altezza dell’onda, al suo periodo, alla sua direzione e il tempo di simulazione. E’ stato deciso un’implementazione del moto ondoso relativamente semplice a causa dei vincoli di tempo reale collegato alla simulazione. In particolare è stata creata una griglia bidimensionale di linee coincidente con la linea di galleggiamento. Ad ogni maglia della griglia è stato associato, tramite funzioni base OpenGL, una texture che rappresentasse una porzione di moto ondoso. Naturalmente, dovendo essere replicata e affiancata a se stessa, è stata scelta un’immagine che permettesse di evitare antiestetiche viste del mare nella sua interezza. La figura scelta è mostrata in fig. 4-43
Fig. 4-43, Texture scelta per la visualizzazione del moto ondoso
Ad ogni nodo della griglia è stato poi associata una funzione per simulare il movimento del mare. La scelta è ricaduta sulla seguente funzione
) sin cos cos( ) , , ( ς ω µ µ ς t x y = A ⋅t−k⋅x⋅ −k⋅y⋅
dove ς(t,x,y) rappresenta l’altezza z del nodo identificato tramite la coppia (x,y), ω è la frequenza dell’onda, µè la direzione da cui provengono i fronti dell’onda mentre t è il tempo di simulazione del modello dinamico. All’interno del codice è possibile stabilire la grandezza della griglia e la risoluzione delle maglie dei nodi. Non è possibile, però, creare una griglia indefinitamente grande poiché l’applicazione della precedente equazione ad un gran numero di nodi causa un rallentamento delle presentazioni di rendering soprattutto utilizzando schede grafiche non eccessivamente performanti. Per ovviare a questo problema è stata creata una griglia le cui dimensioni sono state stabilite come compromesso tra prestazioni e funzionalità a cui è applicata la precedente equazione. Tuttavia l’utente non si accorge del comportamento di tale griglia poiché viene spostata contestualmente al movimento dell’imbarcazione. All’esterno della griglia movente è stata aggiunta una griglia fissa a cui non vengono applicate le trasformazioni dovute al moto ondoso. Una vista dall’alto dello scenario virtuale chiarifica meglio i concetti precedentemente esposti.
Fig. 4-44, Griglia fissa e griglia mobile per la visualizzazione del moto ondoso
Il “trucco” utilizzato ha migliorato molto le performance di rendering permettendo una visualizzazione fluida dell’intero scenario. Inoltre, come si vede dalla seguente figura, dal tipico punto di osservazione del timoniere di una barca a vela la differenza fra le due griglie non è praticamente visibile.
Fig. 4-45, Scenario dal punto di vista del timoniere
Infine il modello grafico della barca durante un moto ondoso proveniente da prua con onde alte 30 cm.
La possibilità di cambiare il punto di vista dello scenario è gestito dalla funzione CameraMove(). Un controllo base della camera viene inserito automaticamente dal wizard di progetto del software XVR e consiste nella gestione del mouse come interfaccia per il movimento di tale telecamera. I movimenti possibili consistono in
• Cambiamento dell’ orientazione della telecamera, mantenendo costante la posizione (tramite il tasto sinistro)
• Cambiamento della posizione della telecamera, mantenendo costante l’orientazione (tramite il tasto destro)
• Cambiamento della sola altezza della telecamera, mantenendo costante l’orientazione (pressione su entrambi tasti del mouse)
Combinando i vari comandi si può avere un completo controllo del punto di vista dello scenario virtuale.
In aggiunta a questi comandi di default è stata aggiunta la possibilità di altri punti di vista, in cui la telecamera rimane fissa sulla barca a vela e muovendosi di conseguenza. Sono stati aggiunti le seguenti modalità:
• Visione da poppa (tasto POV del joystick in posizione 180°) • Visione da dritta (tasto POV del joystick in posizione 90°) • Visione da sinistra (tasto POV del joystick in posizione 270°) • Visione dall’alto (tasto POV del joystick in posizione 0°) • Visione dal pozzetto (tasto n°1 del joystick)
In fig. 4-47 è mostrato lo scenario virtuale dai vari punti di vista appena descritti.
Attraverso la funzione Suoni() è stato gestito un semplice feedback audio per l’utente all’interno della cabina di guida in cui sono riprodotti i tipici suoni udibili all’interno di un porto.
La funzione Collisioni() gestisce la possibilità della collisione fra l’imbarcazione e lo scenario. Il software XVR non fornisce direttamente gli strumenti per rilevare la collisione fra più oggetti, tuttavia mediante la funzione membro IsColliding() è possibile determinare se un segmento sia o meno in collisione con un elemento dello scenario. Come mostrato in fig. 4-48, dal centro di gravità della barca è stata fatta partire una stella di 12 segmenti di una lunghezza tale da inglobare l’oggetto barca nella sua interezza.
Fig. 4-48, Stella di segmenti per il rilevamento delle collisioni
Durante la navigazione se uno solo dei segmenti entra in contatto con un elemento dello scenario, viene visualizzato un messaggio di errore e viene riprodotto un suono tipico di un urto. Per quanto riguarda la simulazione del modello dinamico, nel momento della collisione non viene eseguita nessuna operazione e tale task è lasciato ad ulteriori sviluppi dell’integrazione con la piattaforma mobile.
Un esempio di collisione dell’imbarcazione sulla banchina del porto è mostrato in fig. 4-49.
4.6 Modellazione dell’interfaccia utente
L’interfaccia utente utilizzata per impostare gli agenti ambientali in cui avrà luogo la simulazione è mostrata in fig. 4-50. Si tratta di una semplice MFC dialog based sviluppata tramite il Microsoft Visual Studio 8 Express Edition. L’interfaccia è suddivisa logicamente in sezioni nelle quali possono essere settate informazioni riguardanti vento e moto ondoso. E’ inoltre possibile se utilizzare o meno la regolazione automatica della velatura. Attraverso delle barre orizzontali è possibile selezionare il valore desiderato che viene contemporaneamente visualizzato nella casella di testo adiacente alla barra orizzontale. I dati regolabili relativi al vento sono:
• Intensità del vento in un intervallo compreso tra 0 m s e 15 m s
• Direzione di provenienza del vento compresa fra 0° e 360° I dati regolabili relativi al moto ondoso sono:
• Altezza delle onde in un intervallo compreso tra 0 me 1 m
• Periodo medio delle onde in un intervallo compreso tra 2 sec e 5 sec
• Direzione della provenienza delle onde in un intervallo compreso tra -180° e 180°
I dati regolabili relativi alla regolazione avanzata delle vele sono: • Selezione o meno della regolazione automatica della velatura
• Coefficiente di terzarolo (reef) in un intervallo compreso tra 0 % e 100 %
• Coefficiente di regolazione della curvatura delle vele in un intervallo compreso tra 0 % e 100 %
Durante le simulazioni effettuate nella fase di test e sviluppo del modello matematico, è stato utilizzato un joystick per permettere l’immissione dei comandi umani quali comandi sul timone e regolazione delle vele. Il joystick utilizzato è il Wingman Force 3D della Logitech in possesso di un numero sufficiente di comandi di controllo per i numerosi possibili ingressi da parte dell’utente. L’utilizzo dei pulsanti e delle leve disponibili sul joystick sono stati associati a specifici comandi di navigazione e le corrispondenze create sono presenti in tabella 4-1 e raffigurate in fig. 4-51.
Comando del joystick Comando di navigazione della vela Pulsante # 1 Visuale del timoniere
Pulsante # 2 Lascare la randa
Pulsante # 3 Cazzare la randa
Pulsante # 4 Lascare il fiocco
Pulsante # 5 Cazzare il fiocco
Pulsante # 6 -
Pulsante # 7 -
Rotazione intorno all’asse X Regolazione del timone Rotazione intorno all’asse Y Regolazione potenza del motore
Leva Throttle Regolazione intensità vento POV (Point of View)
In particolare 0° 90° 180° 270°
Cambio della posizione della telecamera nello scenario virtuale
Visione dall’alto Visione da dritta Visione da inseguimento
Visione da sinistra
Tab. 4-1 Corrispondenze fra comandi del joystick e comandi disponibili all’utente durante la navigazione
Cazzare il fiocco Lascare il fiocco Cazzare la randa Visuale del timoniere Lascare la randa Cambio del punto di vista Controllo del timone Regolazione del motore Regolazione intensità vento
L’utilizzo del simulatore del progetto INDICA ha reso necessaria una serie di compromessi per poter utilizzare i comandi tipici di un muletto elevatore durante la simulazione della navigazione su una barca a vela. In fig. 4-52 è mostrato l’abitacolo del muletto e l’associazione effettuata fra i comandi disponibili e il loro effettivo utilizzo all’interno della simulazione di navigazione. Nel prossimo paragrafo è descritta in dettaglio l’integrazione effettuata, mentre in tabella 4-2 sono riassunte tali corrispondenze.
Comandi nell’abitacolo del muletto
Comando di navigazione della vela
Volante Regolazione del timone della barca Chiave di accensione Avviamento della simulazione
Switch Accensione/spegnimento motore
Leva 1 Regolazione propulsione del motore
Leva 2 Regolazione randa
Leva 3 Regolazione fiocco
Tab. 4-2 Corrispondenze fra comandi dell’abitacolo del muletto e comandi disponibili all’utente durante la navigazione Regolazione fiocco Regolazione randa Regolazione motore Regolazione timone Accensione/ spegnimento motore Pulsante di emergenza Avvio simulazione
Fig. 4-52, Associazione dei comandi dell’abitacolo con i comandi gestibili dall'utente durante la navigazione
4.7 Integrazione con motion platform
L’infrastruttura hardware del progetto INDICA prevede la lettura di tutti i segnali provenienti dall’abitacolo tramite una s-function. Sono presenti 2 segnali analogici e 15 segnali digitali.
• Leva di sollevamento in avanti • Acceleratore
I segnali digitali sono raggruppabili in tre categorie: ¾ Segnali del pilota
¾ Segnali della navigazione ¾ Segnali delle leve
I segnali relativi al pilota sono: • Freno di stazionamento • Avvisatore acustico (beep) • Chiave
• Sedile
I segnali relativi alla navigazione sono: • Acceleratore
• Marcia avanti • Marcia indietro • Freno
• Fine-corsa sterzo
I segnali relativi ai leveraggi sono: • Leva sollevamento indietro • Leva brandeggio avanti • Leva brandeggio indietro • Leva presa avanti
• Leva presa indietro
• Leva movimentazione avanti • Leva movimentazione indietro
In fig. 4-53 è presente lo schema simulink relativo all’acquisizione dei segnali in cui è stata utilizzata la s-function “cock” per la lettura dei segnali appena descritti. Come descritto nella precedente sezione la leva di brandeggio e la leva di presa sono state associate alla regolazione della randa e del fiocco. L’architettura hardware della piattaforma prevede che tali leve siano sensorizzate tramite 2 fine corsa che ne rilevano il movimento in avanti o indietro. Per ridurre il numero dei segnali da portare a valle di questo blocco di acquisizione comandi è stato inserito il sottosistema “Modifica segnali logici delle leve” che fornisce un segnale pari a -1 se la vela viene cazzata e +1 se la vela viene lascata. In fig. 4-54 e fig. 4-55 sono presenti gli schemi simulink relativi al trattamento dei segnali dall’abitacolo precedentemente acquisiti. Dal gruppo dei segnali relativi al pilota è selezionato il freno di stazionamento per l’accensione e lo spegnimento del motore di cui la barca a vela virtuale è dotata. Il segnale di fine corsa del volante è utilizzato dal sottosistema “Encoder” per fornire un valore nell’intervallo
[ ]
−1,1 in cui gli estremi rappresentano l’angolo massimo di timone a dritta e a sinistra mentre il valore 0è associato ad un angolo nullo sul timone. La leva di sollevamento è stata utilizzata per fornire in percentuale la potenza del motore con la convenzione che con la leva in posizione terminale in avanti si è associato un valore di +100%della potenza del motore e con la leva in posizione terminale verso l’utente si è associato un valore di −100%. E’ presente inoltre una semplice macchina a stati finiti che è finalizzata alla inizializzazionedelle variabili “chiave” e “sedile”, rispettivamente utilizzate per determinare l’inizio della simulazione e rilevare la corretta posizione dell’utente all’interno dell’abitacolo.
Fig. 4-53, Acquisizione dei segnali provenienti dall’abitacolo
In fig. 4-55 viene effettuato l’ultimo stadio dell’integrazione dei segnali provenienti dall’abitacolo e viene creato il segnale “Comandi Umani” che verrà utilizzato dal modello matematico. Tale segnale viene così costruito:
• Timone: Il valore nell’intervallo
[ ]
−1,1 viene prima fatto passare attraverso un blocco “dead zone” per eliminare incertezze di lettura del sensore dello sterzo intorno al valore nullo. Il valore così ottenuto viene poi fatto passare per un guadagno che permette di assegnare un valore del timone in un intervallo fra 45° e + 45°.• Coefficiente di terzarolo (reef): Tale valore viene letto direttamente dalla memoria condivisa su cui scrive l’interfaccia grafica precedentemente descritta. • Coefficiente di regolazione della curvatura delle vele (flat): Tale valore viene
letto direttamente dalla memoria condivisa su cui scrive l’interfaccia grafica precedentemente descritta.
• Randa: Nella s-function viene calcolato il nuovo valore dell’angolo della randa considerando la seguente espressione:randanew =randaold +0.05⋅∆randa. Il nuovo valore della randa viene calcolato tramite aggiornamento del vecchio valore con un valore pari a −0.05 o +0.05 a seconda dell’azione effettuato sulla leva di brandeggio. Tale valore è sembrato essere un buon compromesso per la velocità con cui la vela veniva cazzata o lascata.
• Fiocco: Nella s-function viene calcolato il nuovo valore dell’angolo della randa considerando la seguente espressione: fiocconew = fioccoold +∆fiocco. Il nuovo
valore del fiocco viene calcolato tramite aggiornamento del vecchio valore con un valore pari a −0.05 o +0.05 a seconda dell’azione effettuato sulla leva di presa. Tale valore è sembrato essere un buon compromesso per la velocità con cui la vela veniva cazzata o lascata.
• Presenza spinnaker: Tale valore viene messo a 1 se lo spinnaker viene inserito o manualmente o in base alle regole descritte nella regolazione automatica delle vele. • Spinnaker: Nella s-function viene calcolato il nuovo valore dell’angolo della randa
considerando la seguente espressione: spinnnew =spinnold +∆spinn. Il nuovo valore dello spinnaker viene calcolato tramite aggiornamento del vecchio valore con un valore pari a −0.05 o +0.05 a seconda dell’azione effettuato sulla leva di movimentazione. Tale valore è sembrato essere un buon compromesso per la velocità con cui la vela veniva cazzata o lascata.
• Motore: Il pulsante freno di stazionamento discrimina se il motore è acceso o spento. A motore spento (codificato con un valore di -10000) la barca a vela usa il proprio piano velico come propulsione. A motore acceso, la barca a vela è spinta da un motore la cui potenza è gestibile tramite la leva analogica di sollevamento.
Fig. 4-55, Ultimo stadio dell’acquisizione dei segnali dall’abitacolo
La logica di controllo della simulazione prevede la visualizzazione in grafica dei messaggi che informano l’utente su operazioni da effettuare o sullo stato della simulazione stessa. I messaggi previsti sono inviati tramite memoria condivisa al programma di grafica e sono:
• Ruotare lo sterzo a destra: Messaggio visualizzato all’inizio della simulazione stessa per inizializzare lo sterzo
• Girare la chiave: Messaggio visualizzato per invitare l’utente a dar inizio alla simulazione
• Attendere...: Messaggio visualizzato subito dopo la partenza della simulazione durante il quale la piattaforma dalla posizione di parking raggiunge la posizione dello spazio di lavoro in cui inizia la simulazione
• Timeout: Messaggio visualizzato a seguito di un eccessivo ritardo nell’acquisizione di comandi da parte dell’utente
• Attenzione!!! Provocato un angolo di rollio o beccheggio eccessivo: Messaggio visualizzato a seguito di un eccessivo angolo di rollio o beccheggio imposto dal modello matematico alla piattaforma
• Chiave in posizione non corretta: Messaggio visualizzato quando la chiave non si trova in posizione corretta
• Errore della piattaforma: Messaggio visualizzato a seguito di un errore hardware della piattaforma o si è raggiunta una condizione di non sicurezza per l’utente (cancelletto aperto, cinture slacciate,ecc.)
In fig. 4-56 è presente una schermata dello scenario virtuale con la quale il sistema attende da parte dell’utente il segnale per avviare la simulazione.
