Architettura di riferimento

Dato che nessuno ha ancora pubblicato l'architettura di riferimento scritta in aula martedì scorso propongo io lo schema.

Per quanto riguarda la lezione straordinaria della prossima settimana, nessuno ha espresso le proprie disponibilità e preferenze? Il gruppo dell'AVT-Guida Automatica dovrebbe essere diponibile per venerdì.

Interfacce con AVT-Sensori e AVT-Attuatori: prima versione

Abbiamo definito le interfacce per lo scambio di dati con i componenti AVT-Sensori e AVT-Attuatori.
Dovrebbe esserci tutto il necessario, ma e' possibile che ci sia sfuggito qualcosa. Doveste notare qualcosa che non funziona, segnalatelo per favore, cosi' possiamo correggerlo.
SENSORS_Buffer.java
ACTUATORS_Buffer.java

(versioni solo testo visualizzabili col browser: SENS - ACT)

Tipi di vetture, condizioni fondo stradale, e tipi di corsie diversi

Il professore/committente ha espresso la volontà che anche in una prima relase del prodotto si possa gestire la guida automatica per vetture di diverso tipo e in diverse condizioni stradali. Non ho visto ancora il simulatore e nemmeno le sue API(ho provato a installarlo una volta ma dava problemi con dll diversi da quelli esposti nell'apposito post) ma mi chiedevo come si possano realizzare i diversi tipi di condizioni stradali se non avendo dei sensori che indichino il tipo di strada.
Per i diversi tipi di vetture sapete se nel simulatore è previsto l'inserimento di parametri specifici?


Per le 3 corsie che abbiamo ipotizzato di avere noi del gruppo "SPS-Informatic" del sistema di guida automatica AVT, crediamo che sia giusto avere 3 tipi di corsie che effettuano funzioni diverse:
-destra->fermata
-centro->marcia
-sinistra->sorpasso
Se individuate dei conflitti con i vostri moduli fatecelo sapere
Grazie

Richiesta proroga consegna offerta

Ho mandato una e-mail ad Ambriola chiedendo se possibile di rimandare la consegna dell'offerta perchè lunedì abbiamo il secondo incontro con il committente e martedì dovremo consegnare l'offerta. Mi pare un po' inverosimile. Se qualcuno è della mia stessa opinione è pregato di farlo presente ad Ambriola. Ciao a tutti

Guida allo scaricamento della libreria GeneSim for Koala

Per scaricare la libreria GeneSim adattata al problema del movimento
di un veicolo puntate i browser all'indirizzo
http://sourceforge.net/project/showfiles.php?group_id=143699&package_id=226850 e
cliccate sull'unica release disponibile, GS4Koala-0.16b.1.zip.
Otterrete così un file zip da scompattare in una directory a piacere.
Nell'albero delle directory create dallo scompattamento entrate in
BinWin32, dove potete trovare un compilato per Windows chiamato GS_Driver.exe.
Avviate l'applicazione e portatevi su File > Load Interface,
quindi cercate il file Cars/Cars_ZiSuInt.xml.
Ora avrete un'interfaccia grafica per il test dello spostamento
del veicolo.
Per informazioni sul significato dei parametri settabili
leggete il ReadMe.txt nella root del decompresso.

Nota:
su alcuni sistemi potrebbero mancare alcune dll
necessarie per il funzionamento del programma di test.
Usando WinXP Professional SP2 l'unica dll mancante
per me è stata la MSVCR71D.dll, recuperabile all'indirizzo
http://www.dll-files.com/dllindex/dll-files.shtml?msvcr71d
Dovessero mancarvene altre, una ricerca su Google del nome
del file è generalmente sufficiente per trovarla.

Osservazioni:
dopo alcuni test ho dedotto che con questo simulatore fisico
NON è possibile:
- trovare un compromesso tra fattore di accelerazione e di
frenata in modo da mantenere la velocità costante;
- andare in testacoda: muovendosi a velocità elevata e sterzando
bruscamente riportando subito le ruote in posizione neutra,
la macchina smette quasi subito di girare.
Questo, perlomeno, con i settaggi di default.

Riunione tra i gruppi

La prima riunione tra i membri di tutti i gruppi è stata fissata per giovedì 6 marzo alle ore 14 davanti all'aula I.
Se per qualche motivo questa data non è compatibile con gli orari di tutti lasciate un commento a questo post che si prova a rimettersi daccordo.
P.s. non è indispensabile la presenza di tutti i membri del gruppo basta essere almeno 2/3 persone per gruppo

Pasquale Anatriello

Valutazione del raggio della curva sulla base dei dati rilevati dal sensore frontale

La figura mostra un esempio in scala di una macchina che si muove sulla corsia centrale di una strada a tre corsie (ognuna di due metri di larghezza) durante la fase di avvicinamento ad una curva. In ogni riga viene messo in evidenza l’avvicinamento del veicolo (identificato dal rettangolo) alla curva e il punto di incidenza del cono del sensore con il bordo della strada.



La tabella che segue mostra i dati potenzialmente rilevabili dal sensore frontale (approssimati) del veicolo durante la fase di avvicinamento per due curve rispettivamente di 50m e 100m di raggio. Nelle colonne sono riportate rispettivamente i valori della posizione del veicolo rispetto all’inizio della curva, la distanza rilevata dal sensore nel caso in cui incontri rispettivamente una curva di 100m o 50m, la distanza rilevata nel caso in cui ci fosse un ostacolo fisso che occupa l’intera carreggiata (o una curva a 90° perpendicolare al senso di marcia) e il coefficiente di inclinazione della curva calcolato come rapporto tra la distanza dall’inizio della curva e la distanza rilevata dal sensore dall’ostacolo. In questo modo a parità di distanza dalla curva un coefficiente molto vicino a 1 indicherà una curva molto dolce e con raggio di curvatura molto ampio mentre per valori prossimi allo zero la curva avrà raggio di curvatura molto stretto.

Attraverso questo meccanismo il veicolo dovrebbe riuscire a moderare la velocità in funzione del raggio della curva.

Distinzione tra moduli Guida Automatica e Interprete Sensori

Come richiesto dal prof Ambriola scrivo brevemente riguardo quest'argomento.
Nelle prime lezioni si era parlato del componente di controllo come di un modulo che che legge informazioni dai sensori e chiama i metodi degli attuatori.
Risulta preferibile dividere il componente di controllo in due moduli distinti. Usando la terminologia del post di Davide:
1. Interprete Sensori.
2. AVT Guida automatica.

Interprete sensori:
legge le informazioni dei sensori e crea un profilo dei bordi della pista. Ogni bordo viene approssimato con una spezzata poligonale. Per ognuno dei due bordi sarà quindi necessaria una struttura dati [ad esempio un Vector] contente le coordinate di un certo numero di vertici.
Le altre informazioni che deve ricostruire sono: la larghezza della strada , l'inclinazione della vettura e la distanza del baricentro da una delle due carreggiate.

AVT Guida Automatica:
Legge la struttura dati aggiornata dall'interprete sensori. Su queste informazioni fa dell'elaborazione [algoritmo di pathfinding] e chiama i metodi degli attuatori.

Questa divisione consente di trattare separatamente due problemi distinti:
1. la ricostruzione della posizione della vettura e dei bordi delle carreggiate.
2. l'intelligenza artificiale della vettura.
Nota: mi sembra che il modello dei sensori proposto dia input insufficienti per ricostruire le informazioni che servono alla guida automatica. Si potrebbe pensare di fornire alla guida automatica meno informazioni. Ho guardato, a tal proposito, alcuni articoli riguardanti l'ia in giochi di corse. Tutti le soluzioni descritte assumono, come minimo, che l'algoritmo conosca il profilo dei bordi della pista nei dintorni della vettura, la posizione e l'inclinazione della vettura stessa.
Credo che la soluzione migliore sia creare un modello in cui i sensori diano più informazioni di quelli attuali. Anche considerando che sistemi reali di guida automatica usano telecamere per ricostruire le infomazioni che servono.
Edit: nel caso in cui, invece, le specifiche non si possano modificare c'è la soluzione proposta dal prof Ambriola che mi pare ottima.
1. Il modulo di guida prende le informazioni da un'opportuna interfaccia del modello del mondo presente nel simulatore.
2. L'interprete dei sensori prende gli input dei sensori e ricostruisce un proprio modello del mondo.
3. Un altro modulo, chiamato Controllore, confronta istante per istante i due modelli e assegna un punteggio di corrispondenza.
4. Quando il punteggio di corispondenza supererà un certo valore di soglia il modulo di guida potrà provare ad usare il modello costruito dall'interprete dei sensori.

Proposta di suddivisione del progetto

Riguardo alla suddivisione del progetto nei 4 gruppi vorrei esprimere la mia opinione ed illustrare la mia proposta.

Penso sia più naturale assegnare ad ogni gruppo analisi, progettazione, implementazione e verifica di un intero sistema anziché di un sottoinsieme di componenti appartenenti a sistemi diversi. L'assegnazione non è immediata perché, mentre i gruppi sono quattro, i requisiti del committente indicano che i sistemi da realizzare sono (soltanto) due: AVT e Simulatore. Secondo me conviene scomporre questi ultimi e descrivere così quattro sottosistemi.

Attraverso un'analisi generale ho elaborato una possibile scomposizione che cercherò di illustrare di seguito.

Il primo passo di suddivisione riguarda la GUI. I sistemi AVT e Simulatore non realizzano moduli per l'interfaccia grafica, offrono solo un'interfaccia nativa con le operazioni per l'utente. I sistemi GUI (esterni) realizzano una “human interface” facendo da tramite tra la persona fisica e l'interfaccia nativa dei sistemi AVT e Simulatore. (Nota: dato che l'AVT deve essere installato in un veicolo fisico la GUI dell'AVT dovrebbe essere, più verosimilmente, un terminale con schermo lcd e pulsanti. In ambito di simulazione tuttavia la GUI dell'AVT è anch'essa simulata e può quindi essere inclusa nel sistema GUI del Simulatore, il quale è realizzato come interfaccia grafica per Java).

Il secondo passo di suddivisione riguarda l'AVT. I sistema AVT è diviso in due sottosistemi: il sistema di Guida automatica e l'Interprete dei sensori. La Guida automatica fornisce le funzionalità all'utente elaborando informazioni di stato e agendo sul veicolo (attuatori). L'Interprete dei sensori fornisce alla Guida automatica le informazioni di stato elaborando le informazioni dei sensori del veicolo. (Nota: questi due sottosistemi realizzano la stessa logica per l'AVT discussa in aula secondo la quale il controllore della guida poteva astrarre dalla natura e configurazione dei sensori e viceversa. Dato che durante l'analisi del dominio era emersa una certa criticità riguardo all'interpretazione dei sensori, sembra ragionevole introdurre questo sottositema).

A questo punto abbiamo 4 sistemi (AVT-Guida automatica, AVT-Interprete sensori, Simulatore, GUI), ognuno dei quali ha bisogno di una realizzazione separata ma collaborativa attuata dai 4 gruppi. Per meglio identificare le interazioni tra le 4 parti e per stabilire a quale gruppo assegnare quale sistema si dovrebbe fare un analisi preliminare dei singoli sistemi.

La mia personale analisi (molto generale) si riassume nei seguenti schemi.

AVT-Guida automatica - Casi d'uso:

AVT-Guida automatica – Diagramma robustezza:
AVT-Interprete sensori – Casi d'uso:

AVT-Interprete sensori – Diagramma robustezza:

Simulatore – Casi d'uso:

Simulatore – Diagramma robustezza:
Note sul Simulatore: le associazioni con gli attori AVT-Guida automatica, AVT-Interprete sensori e Simulatore veicolo hanno molteplicità pari al numero di veicoli presenti nella simulazione. Il sistema ricopre il ruolo dell'attore Attuatori per il sistema AVT-Interprete sensori, dell'attore Sensori e GUI AVT-Guida automatica per il sistema AVT-Guida automatica.

Per il sistema GUI non è fondamentale un'analisi, si possono considerare i casi d'uso standard delle interfacce grafiche per Java.

Da questa analisi dei sistemi deriva il seguente schema a componenti che illustra le interazioni tra i sottosistemi:
Le interfacce (contratti) individuate sono 6 ma i contratti da definire sono 5 (escludendo Interfaccia Simulatore veicolo già fornita dal già realizzato Simulatore veicolo). Tuttavia alcune di queste interfacce dipendo da altre: un sottoinsieme dell'Interfaccia Simulatore deve fornire le funzionalità dell'Interfaccia AVT-Guida automatica e l'Interfaccia Attuatori deve uniformarsi alle funzionalità offerte dall'Interfaccia Simulatore veicolo.

Una una vista strutturale d'uso conseguente è:

Dato che i moduli da realizzare sono 4, ad ognuno di questi può essere assegnato un gruppo, in questo modo:

• AVT-Guida automatica --> Gruppo 1
• AVT-Interprete sensori --> Gruppo 2
• Simulatore --> Gruppo 3
• GUI --> Gruppo 4

E' possibile anche immaginare, a questo punto, l'interazione e le dipendenze tra i gruppi di lavoro.

Il gruppo 1:

1. segue le richieste del committente, il quale definisce i requisiti per l'AVT e le funzionalità richieste dall'utente;
2. stabilisce quali funzionalità il proprio modulo intende richiedere all'Interprete dei sensori e agli Attuatori (cercando di uniformarsi all'interfaccia del Simulatore veicolo);
3. informa i gruppi 2 e 3 delle funzionalità delle quali intende richiedere l'implementazione, cioè, rispettivamente, acquisizione dello stato del veicolo e della strada, controllo degli attuatori;
4. informa i gruppi 3 e 4 delle funzionalità fornite dalla guida automatica (che bisogna rendere accessibili in ambiente grafico).

Il gruppo 2:

1. segue le richieste del gruppo 1 riguardo alle funzionalità di interpretazione dei sensori;
2. stabilisce quali funzionalità richiedere ai Sensori;
3. informa il gruppo 3 delle funzionalità sensoriali delle quali intende richiedere l'implementazione.

Il gruppo 3:

1. segue le richieste del committente, il quale definisce i requisiti per il Simulatore e le funzionalità richieste dall'utente;
2. segue le richieste dei gruppi 1 e 2 riguardo alle funzionalità di simulazione degli attuatori e dei sensori;
3. informa il gruppo 4 delle funzionalità fornite dal simulatore (che bisogna rendere accessibili in ambiente grafico).

Il gruppo 4:

1. considera le informazioni fornite dai gruppi 3 e 4 riguardo le funzionalità di interazione con l'utente.

Rappresentazione dei messaggi scambiati tra le parti del progetto:

Dato che i gruppi non sono bilanciati, proporrei questa assegnazione:

• Gruppo 1: 4 persone
• Gruppo 2: 3 persone
• Gruppo 3: 5 persone
• Gruppo 4: 4 persone

Concludendo:
Se dobbiamo dividerci il progetto tra tutti i gruppi io penso sia ragionevole organizzarci nel modo che ho illustrato.
Se invece la suddivisione risultasse troppo sbilanciata o se comunque l'interazione dei gruppi sembrasse troppo difficile da attuare, allora sarebbe preferibile rinunciare: istanziare 4 progetti paralleli e procedendo così come il corso aveva originariamente previsto.


Davide Cavagnuolo