Ricostruzione della traiettoria 3d di veicoli in intersezioni rotatorie

2011-11-25T15:43:11Z

AndreaRomanoni: /* Come ricostruire le traiettorie in 3D */

Ricostruzione della traiettoria 3d di veicoli in intersezioni rotatorie

2011-11-12T10:03:26Z

AndreaRomanoni:

Ricostruzione della traiettoria 3d di veicoli in intersezioni rotatorie

2011-11-12T10:03:05Z

AndreaRomanoni:

Talk:Ricostruzione della traiettoria 3d di veicoli in intersezioni rotatorie

2011-01-03T14:01:20Z

AndreaRomanoni: /* Matching tra video (SURF) */ new section

== Syncro in progress ==

Sto sviluppando la parte di sincronizzazione dei due video.
Con OpenCV apro i video e faccio scegliere all'utente un punto di ogni video per il quale poi memorizzo il segnale su un file.
Successivamente apro i file relativi ai diversi video, estraggo il segnale e calcolo la correlazione del segnale di tutti i video rispetto al primo calcolando per quale valore si ha la correlazione massima; da questo calcolo il ritardo tra i video

== Syncro-OpticalFlow ==

Prima di fare la sincronizzazione come discusso, ovvero analisi di segnale, bisogna stabilizzare l'immagine altrimenti il segnale varierà anche a causa del movimento della camera.

Per l'opticalFlow, tra un frame e l'altro bisogna calcolare la matrice di omografia, ma sto incontrando problemi con cv::findHomography. Infatti la matrice risultato non è quella corretta, o meglio differisce di moltissimo da quella calcolata con Matlab

[Risolto] il problema di findHomography: la matrice veniva calcolata correttamente, ma per visualizzare i risultati dovevo farli vedere come double invece che float. Devo ringraziare un certo Michal Kottman, che mi ha risposto prontamente nel gruppo yahoo di opencv (http://tech.groups.yahoo.com/group/OpenCV/message/76527?l=1)

== Sync in progress.... ==

Ieri sono riuscito ad allineare il video con la classe che mi ha dato Davide. Oggi allineo anche gli altri video e provo la sincronizzazione con la correlazione dei segnali del pixel. Provo anche a fare una correlazione tra i segnali di più pixel magari.

Ho allineato tutti i video ora li sincronizzo.

== Matching tra video (SURF) ==

probabilmente tutti i problemi di sincronizzazione sono dovuti al video stesso... quindi, sperando che sia questo il problema procedo cercando di fare matching tra i video con SURF.

Talk:Ricostruzione della traiettoria 3d di veicoli in intersezioni rotatorie

2010-12-30T09:29:04Z

AndreaRomanoni: /* Sync in progress.... */

Talk:Ricostruzione della traiettoria 3d di veicoli in intersezioni rotatorie

2010-12-28T09:02:08Z

AndreaRomanoni: /* Sync in progress.... */ new section

Talk:Ricostruzione della traiettoria 3d di veicoli in intersezioni rotatorie

2010-12-26T23:27:55Z

AndreaRomanoni: /* Syncro-OpticalFlow */

Talk:Ricostruzione della traiettoria 3d di veicoli in intersezioni rotatorie

2010-12-24T09:32:19Z

AndreaRomanoni: /* Syncro-OpticalFlow */

Talk:Ricostruzione della traiettoria 3d di veicoli in intersezioni rotatorie

2010-12-24T09:23:07Z

AndreaRomanoni: /* Syncro-OpticalFlow */ new section

Talk:Ricostruzione della traiettoria 3d di veicoli in intersezioni rotatorie

2010-12-21T07:21:06Z

AndreaRomanoni: Sincronizzazione dei video

Ricostruzione della traiettoria 3d di veicoli in intersezioni rotatorie

2010-12-17T19:49:42Z

AndreaRomanoni:

2010-08-16T20:59:45Z

AndreaRomanoni: /* Prova addEventPort di Orocos */

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)

== COmunicazione Espertio ==

secondo me dovremo fare:

- porta in lettura e scrittura per comunicare con command manager (che forse è meglio rinominare in joypadExpert o qualcosa di simile)
- porta in scrittura per motorExpert (non vorrei dire una cavolata ma è Brian che manda messaggi a motor expert giusto?)
- porta in lettura (e/o scrittura) verso odoExpert

forse noi non dobbiamo preoccuparci più di tanto di quello, forse possiamo usare la configurazione con l'XML delle proprietà per riuscire a gestire quelle cose.. oppure teniamo la configurazione come è nel codice

Ho un grosso problema.. non riesco a far funzionare le porte aggiunte con addEvent() come invece dovrebbero funzionare, ovvero appena arriva un dato dovrebbe essere eseguito l'updateHook().. tu hai per caso provato

(Andrea, 6 agosto)

== Comunicazione Brian-MotorExpert ==

Brian può anche ricevere i messaggi da motorExpert:

//in BrianExpert.cpp
ExecStatus BrianExpert::Execute(){
...
if(ReceiveLastMessage(MSG_FROM_MOTION_BRIEF,buffer,false)>0){
InterfaceSetDatalex_memory((const char *)buffer,this);
DBG("message from motion\n");
}
...

//in GestioneAgenti.cpp
void GestioneAgenti::createMapMessageAgents(){
//aggiungere per ogni tipo di messaggio gli agenti che lo possono produrre
...
messageAgents[MSG_FROM_MOTION_BRIEF]=vector<string>();
messageAgents[MSG_FROM_MOTION_BRIEF].push_back(motor_agent);

Guardo anch'io la addEvent e poi ti faccio sapere!

La parte del controllore fuzzy è più ampia del previsto: sempre in BrianExpert viene richiamato il costruttore MrBrian, che è definito in lurch-control/brian/src/brian.cpp. E quest'ultimo file a sua volta richiama tante altri file della stessa cartella.

(Michele, 6 agosto)

Pensando sempre a come potremmmo fare per le porte e gli eventi, forse potremmo dedicare le porte ad ogni esperto come dicevamo, poi dove vengono usati i messaggi noi usiamo gli eventi (che usano il publish subscribe).. sarebbe bello riuscire ad usare le addEventPort, ma non so come mai faccio fatica a farle andare. ho dato un occhi a odometry expert e sembra abbastanza simile a joypad expert perchè legge i dati da una porta seriale.

per MrBrian ho visto, è un programma che ha fatto restelli

(Andrea, 6 agosto)

== Prova addEventPort di Orocos ==

Sembra proprio che una volta ricevuto il messaggio sulla porta, non venga richiamata la funzione updateHook(); oggi riprovo ancora!
Sì come dicevi tu potremmo usare entrambi: messaggi attraverso le porte (quando è necessario comunicare dei dati) e gli eventi
Quindi andre cosa dici copio il programma di Restelli? Tanto non ha a che fare con i thread, non manda messaggi e quindi in teoria va bene così com'è!

Ho utilizzato la addEventPort sul vecchio codice che ti avevo mandato l'ultima volta.
In pratica ci sono due task:
-Brian periodicamente scrive "sono Brian" e invia una stringa all'esperto motore
- l'esperto motore appena riceve il dato sulla porta richiama l'updateHook(), scrivendo così "sono Motor Expert".

Quindi andre cosa dici copio il programma di Restelli? Tanto non ha a che fare con i thread, non manda messaggi e quindi in teoria va bene così com'è!

(Michele, 7 agosto)

Oggi ho finalmente capito (grazie al codice che mi hai mandato) come mai non funziona.. o meglio ho capito che funziona solo se usiamo una bufferPort e prima di fare la connectPorts bisogna chiamare la configure dei task (probabilmente dovuto ad un BUG di Orocos).

Si direi che dobbiamo includere nel nostro progetto il programma MrBrian di Restelli

Possiamo istanziare un Task attraverso una classe come launch nel main oppure all'interno del task dove serve, ad esempio command manager possiamo istanziarlo in brian oppure il Launch. Secondo te cosa conviene fare? Secondo me è meglio creare i task nel main in modo da dare una migliore visione di insieme.

Poi ho visto che alla fine odoExpert è simile al joypadExpert perchè deve comunicare con la scheda dell odometria

(Andrea, 8 agosto)

Sì anche secondo me è meglio far partire tutti gli agenti all'inizio nel main: tanto non ne abbiamo tanti!

(Michele, 9 agosto)

Talk:Porting su Orocos di alcuni moduli software di Lurch

2010-08-16T20:58:59Z

AndreaRomanoni: /* Prova addEventPort di Orocos */

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)

== COmunicazione Espertio ==

secondo me dovremo fare:

- porta in lettura e scrittura per comunicare con command manager (che forse è meglio rinominare in joypadExpert o qualcosa di simile)
- porta in scrittura per motorExpert (non vorrei dire una cavolata ma è Brian che manda messaggi a motor expert giusto?)
- porta in lettura (e/o scrittura) verso odoExpert

forse noi non dobbiamo preoccuparci più di tanto di quello, forse possiamo usare la configurazione con l'XML delle proprietà per riuscire a gestire quelle cose.. oppure teniamo la configurazione come è nel codice

Ho un grosso problema.. non riesco a far funzionare le porte aggiunte con addEvent() come invece dovrebbero funzionare, ovvero appena arriva un dato dovrebbe essere eseguito l'updateHook().. tu hai per caso provato

(Andrea, 6 agosto)

== Comunicazione Brian-MotorExpert ==

Brian può anche ricevere i messaggi da motorExpert:

//in BrianExpert.cpp
ExecStatus BrianExpert::Execute(){
...
if(ReceiveLastMessage(MSG_FROM_MOTION_BRIEF,buffer,false)>0){
InterfaceSetDatalex_memory((const char *)buffer,this);
DBG("message from motion\n");
}
...

//in GestioneAgenti.cpp
void GestioneAgenti::createMapMessageAgents(){
//aggiungere per ogni tipo di messaggio gli agenti che lo possono produrre
...
messageAgents[MSG_FROM_MOTION_BRIEF]=vector<string>();
messageAgents[MSG_FROM_MOTION_BRIEF].push_back(motor_agent);

Guardo anch'io la addEvent e poi ti faccio sapere!

La parte del controllore fuzzy è più ampia del previsto: sempre in BrianExpert viene richiamato il costruttore MrBrian, che è definito in lurch-control/brian/src/brian.cpp. E quest'ultimo file a sua volta richiama tante altri file della stessa cartella.

(Michele, 6 agosto)

Pensando sempre a come potremmmo fare per le porte e gli eventi, forse potremmo dedicare le porte ad ogni esperto come dicevamo, poi dove vengono usati i messaggi noi usiamo gli eventi (che usano il publish subscribe).. sarebbe bello riuscire ad usare le addEventPort, ma non so come mai faccio fatica a farle andare. ho dato un occhi a odometry expert e sembra abbastanza simile a joypad expert perchè legge i dati da una porta seriale.

per MrBrian ho visto, è un programma che ha fatto restelli

(Andrea, 6 agosto)

== Prova addEventPort di Orocos ==

Sembra proprio che una volta ricevuto il messaggio sulla porta, non venga richiamata la funzione updateHook(); oggi riprovo ancora!
Sì come dicevi tu potremmo usare entrambi: messaggi attraverso le porte (quando è necessario comunicare dei dati) e gli eventi
Quindi andre cosa dici copio il programma di Restelli? Tanto non ha a che fare con i thread, non manda messaggi e quindi in teoria va bene così com'è!

Ho utilizzato la addEventPort sul vecchio codice che ti avevo mandato l'ultima volta.
In pratica ci sono due task:
-Brian periodicamente scrive "sono Brian" e invia una stringa all'esperto motore
- l'esperto motore appena riceve il dato sulla porta richiama l'updateHook(), scrivendo così "sono Motor Expert".

Quindi andre cosa dici copio il programma di Restelli? Tanto non ha a che fare con i thread, non manda messaggi e quindi in teoria va bene così com'è!

(Michele, 7 agosto)

Oggi ho finalmente capito (grazie al codice che mi hai mandato) come mai non funziona.. o meglio ho capito che funziona solo se usiamo una bufferPort e prima di fare la connectPorts bisogna chiamare la configure dei task (probabilmente dovuto ad un BUG di Orocos).

Si direi che dobbiamo includere nel nostro progetto il programma MrBrian di Restelli

Possiamo istanziare un Task attraverso una classe come launch nel main oppure all'interno del task dove serve, ad esempio command manager possiamo istanziarlo in brian oppure il Launch. Secondo te cosa conviene fare? Secondo me è meglio creare i task nel main in modo da dare una migliore visione di insieme.

Poi ho visto che alla fine odoExpert è simile al joypadExpert perchè deve comunicare con la scheda dell odometria

(Andrea, 8 agosto)

Talk:Porting su Orocos di alcuni moduli software di Lurch

2010-08-16T20:58:15Z

AndreaRomanoni: /* Prova addEventPort di Orocos */ new section

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)

== COmunicazione Espertio ==

secondo me dovremo fare:

- porta in lettura e scrittura per comunicare con command manager (che forse è meglio rinominare in joypadExpert o qualcosa di simile)
- porta in scrittura per motorExpert (non vorrei dire una cavolata ma è Brian che manda messaggi a motor expert giusto?)
- porta in lettura (e/o scrittura) verso odoExpert

forse noi non dobbiamo preoccuparci più di tanto di quello, forse possiamo usare la configurazione con l'XML delle proprietà per riuscire a gestire quelle cose.. oppure teniamo la configurazione come è nel codice

Ho un grosso problema.. non riesco a far funzionare le porte aggiunte con addEvent() come invece dovrebbero funzionare, ovvero appena arriva un dato dovrebbe essere eseguito l'updateHook().. tu hai per caso provato

(Andrea, 6 agosto)

== Comunicazione Brian-MotorExpert ==

Brian può anche ricevere i messaggi da motorExpert:

//in BrianExpert.cpp
ExecStatus BrianExpert::Execute(){
...
if(ReceiveLastMessage(MSG_FROM_MOTION_BRIEF,buffer,false)>0){
InterfaceSetDatalex_memory((const char *)buffer,this);
DBG("message from motion\n");
}
...

//in GestioneAgenti.cpp
void GestioneAgenti::createMapMessageAgents(){
//aggiungere per ogni tipo di messaggio gli agenti che lo possono produrre
...
messageAgents[MSG_FROM_MOTION_BRIEF]=vector<string>();
messageAgents[MSG_FROM_MOTION_BRIEF].push_back(motor_agent);

Guardo anch'io la addEvent e poi ti faccio sapere!

La parte del controllore fuzzy è più ampia del previsto: sempre in BrianExpert viene richiamato il costruttore MrBrian, che è definito in lurch-control/brian/src/brian.cpp. E quest'ultimo file a sua volta richiama tante altri file della stessa cartella.

(Michele, 6 agosto)

Pensando sempre a come potremmmo fare per le porte e gli eventi, forse potremmo dedicare le porte ad ogni esperto come dicevamo, poi dove vengono usati i messaggi noi usiamo gli eventi (che usano il publish subscribe).. sarebbe bello riuscire ad usare le addEventPort, ma non so come mai faccio fatica a farle andare. ho dato un occhi a odometry expert e sembra abbastanza simile a joypad expert perchè legge i dati da una porta seriale.

per MrBrian ho visto, è un programma che ha fatto restelli

(Andrea, 6 agosto)

== Prova addEventPort di Orocos ==

Sembra proprio che una volta ricevuto il messaggio sulla porta, non venga richiamata la funzione updateHook(); oggi riprovo ancora!
Sì come dicevi tu potremmo usare entrambi: messaggi attraverso le porte (quando è necessario comunicare dei dati) e gli eventi
Quindi andre cosa dici copio il programma di Restelli? Tanto non ha a che fare con i thread, non manda messaggi e quindi in teoria va bene così com'è!

Ho utilizzato la addEventPort sul vecchio codice che ti avevo mandato l'ultima volta.
In pratica ci sono due task:
-Brian periodicamente scrive "sono Brian" e invia una stringa all'esperto motore
- l'esperto motore appena riceve il dato sulla porta richiama l'updateHook(), scrivendo così "sono Motor Expert".

Quindi andre cosa dici copio il programma di Restelli? Tanto non ha a che fare con i thread, non manda messaggi e quindi in teoria va bene così com'è!

(Michele, 7 agosto)

Oggi ho finalmente capito (grazie al codice che mi hai mandato) come mai non funziona.. o meglio ho capito che funziona solo se usiamo una bufferPort e prima di fare la connectPorts bisogna chiamare la configure dei task (probabilmente dovuto ad un BUG di Orocos).

Si direi che lo dobbiamo includere nel nostro progetto il programma MrBrian di Restelli

una domanda.. Possiamo istanziare un Task attraverso una classe come launch nel main oppure all'interno del task dove serve, ad esempio command manager possiamo istanziarlo in brian oppure il Launch. Secondo te cosa conviene fare? Secondo me è meglio creare i task nel main in modo da dare una migliore visione di insieme.

Poi ho visto che alla fine odoExpert è simile al joypadExpert perchè deve comunicare con la scheda dell odometria

(Andrea, 8 agosto)