Talk:Porting su Orocos di alcuni moduli software di Lurch

Dobbiamo sistemare la deadzone per l'esperto del joystick, poi dobbiamo decidere come passare a brian le coppie nome valore per il controllore fuzzy. Potremmo usare un dataflow per questo, invece un insieme di porte per ogni esperto con il quale deve dialogare brian

Cosa dobbiamo ancora fare

Ricapitolando le cose fatte fin'ora:

- Interfaccia con la porta seriale; - JoystickExpert - configurazione di Eclipse per usare orocos senza gestire manualmente makefile

Ora:

- dobbiamo fare Brian - bisogna mettere a posto il fatto delle dead zone

ci conviene dividere il lavoro.. per quanto riguarda il real time credo che un po' tutti i componente diventano real time con orocos

(Andrea, 26 luglio)

Agenti - BrianExpert

Secondo me, bisogna esplicitare il fatto che un thread debba essere svolto in modo real time.

Bisogna individuare gli agenti da rendere real time.

Sto ripassando il codice relativo a Brian e in particolare la lista di coppie nome-valore in input al controllore fuzzy e la lista con le variabili di uscita.

(Michele, 26 luglio)

Deadzone e comunicazione agenti

fatta la classe per la dead zone, ora bisogna solo applicarla;

per Brian ho pensato che lo scambio di messaggi tra i vari agenti si può fare con le porte, cioè

- uso readDataPort per ogni agente da cui arrivano messaggi - uso writeDataProt per ogni agente a cui mandare messaggi

quindi ho creato la classe commandManagerFake per usarla per sperimentare la modifica che riguarda la comunicazione tra command manager e brian. Infatti ora facciamo leggere a brian la velocità del robot solo tramite un metodo, per fare invece una cosa più generale conviene fare anche questo con le porte, magari fare così:

CommandManager task periodico che mette sulla porta (magari bufferizzata) il rho e teta che legge dalla seriale; Brian legge dalla porta quando ne ha bisogno (forse con la porta bufferizzata è più un casino perchè bisogna fare in modo che brian legga dati "recenti" quindi alcuni dati bufferizzati devono essere eliminati.

(Andrea, 2 agosto)

Brian Expert

Sto traducendo l'agente BrianExpert secondo lo schema su cui si basa Orocos: configureHook(), startHook(), updateHook() ecc. Ho visto che anche loro avevano fatto qualcosa di simile per ogni agente - funzioni Initialize(), Execute() e EndWork().

Nel loro BrianExpert.cpp ci sono anche molti rifermenti a tipi di messaggi che noi non useremo (ad esempio quelli dei sensori Hokuyo).

Sto cercando di capire il funzionamento della funzione di configurazione addOptions().

Ti mando per mail -una parte di codice relativa ad una prova su Orocos: Brian invia una stringa a MotorExpert come dicevi tu utilizzando le porte -una versione del loro BrianExpert.cpp cui ho aggiunto dei commenti su dove sono definite alcune funzioni e variabili e il loro significato.

(Michele, 3 agosto)

Porte ed eventi (comunicazione tra esperti)

Cosa facciamo? Una porta sola in brian e mandiamo i vari messaggi oppure una porta per ogni tipo di agente? Io propenderei per la seconda così si semplifica molto il lavoro di comprendere da chi arriva il messaggio

Ho visto un po gli eventi e stavo pensando che:

- gli agenti che devono inviare dati ad altri agenti possono usare le porte; - quando un agente deve invece reagire a qualcosa che è accaduto possiamo usare gli eventi.

Penso che la maggior parte degli agenti comunichi qualche dato.

(Andrea, 4 agosto)

Brian

Anche secondo me è bene fare in Brian una porta per ogni agente con cui comunicare. Ho visto che in "msg.h" sono definiti i vari tipi di messaggio. Nel nostro caso Brian si limita a comunicare con motorExpert e odoExpert; quindi dovremo mettere in Brian due porte di comuncazione.

Gli agenti si scambiano messaggi in formato XML.

Ti avevo scritto della funzione addOptions(), utilizzata nell'inizializzazione di BrianExpert: tale funzione utilizza la libreria boost c++.

Non è così semplice riuscire a separare la nostra parte da tradurre dal resto del codice. Ad esempio, in Brian.cpp ci sono queste due righe di codice relative alla famosa lista di coppie nome-valore:

mCL[SONAR_QUALITY_DATA]=SonarExpert::bad_quality; ... mCL[HOKUYO_DATA_QUALITY_HEADER+names[0]]=HokuyoConfig::getInstance()->getMaxQuality();

che richiederebbero di tradurre anche la classe HokuyoConfig e il sonarExpert!

(Michele, 4 agosto)