https://airwiki.deib.polimi.it/api.php?action=feedcontributions&feedformat=atom&user=MichelePellegrini 2026-04-07T04:28:15Z User contributions MediaWiki 1.25.6 https://airwiki.deib.polimi.it/index.php?title=Talk:Porting_su_Orocos_di_alcuni_moduli_software_di_Lurch&diff=12170 2010-08-16T20:49:37Z

<p>MichelePellegrini: /* Comunicazione Brian-MotorExpert */ new section</p> <hr /> <div>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<br /> <br /> == Cosa dobbiamo ancora fare ==<br /> Ricapitolando le cose fatte fin'ora:<br /> <br /> - Interfaccia con la porta seriale;<br /> - JoystickExpert<br /> - configurazione di Eclipse per usare orocos senza gestire manualmente makefile<br /> <br /> <br /> Ora:<br /> <br /> - dobbiamo fare Brian<br /> - bisogna mettere a posto il fatto delle dead zone<br /> <br /> ci conviene dividere il lavoro.. per quanto riguarda il real time credo che un po' tutti i componente diventano real time con orocos<br /> <br /> <br /> (Andrea, 26 luglio)<br /> <br /> == Agenti - BrianExpert ==<br /> <br /> Secondo me, bisogna esplicitare il fatto che un thread debba essere svolto in modo real time.<br /> <br /> Bisogna individuare gli agenti da rendere real time.<br /> <br /> 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.<br /> <br /> (Michele, 26 luglio)<br /> <br /> == Deadzone e comunicazione agenti ==<br /> <br /> fatta la classe per la dead zone, ora bisogna solo applicarla;<br /> <br /> per Brian ho pensato che lo scambio di messaggi tra i vari agenti si può fare con le porte, cioè<br /> <br /> - uso readDataPort per ogni agente da cui arrivano messaggi <br /> - uso writeDataProt per ogni agente a cui mandare messaggi<br /> <br /> 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ì:<br /> <br /> 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 &quot;recenti&quot; quindi alcuni dati bufferizzati devono essere eliminati.<br /> <br /> <br /> (Andrea, 2 agosto)<br /> <br /> == Brian Expert ==<br /> <br /> 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().<br /> <br /> Nel loro BrianExpert.cpp ci sono anche molti rifermenti a tipi di messaggi che noi non useremo (ad esempio quelli dei sensori Hokuyo).<br /> <br /> Sto cercando di capire il funzionamento della funzione di configurazione addOptions().<br /> <br /> Ti mando per mail<br /> -una parte di codice relativa ad una prova su Orocos: Brian invia una stringa a MotorExpert come dicevi tu utilizzando le porte<br /> -una versione del loro BrianExpert.cpp cui ho aggiunto dei commenti su dove sono definite alcune funzioni e variabili e il loro significato.<br /> <br /> (Michele, 3 agosto)<br /> <br /> == Porte ed eventi (comunicazione tra esperti) ==<br /> <br /> 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<br /> <br /> Ho visto un po gli eventi e stavo pensando che:<br /> <br /> - gli agenti che devono inviare dati ad altri agenti possono usare le porte;<br /> - quando un agente deve invece reagire a qualcosa che è accaduto possiamo usare gli eventi.<br /> <br /> Penso che la maggior parte degli agenti comunichi qualche dato.<br /> <br /> (Andrea, 4 agosto)<br /> <br /> == Brian ==<br /> <br /> Anche secondo me è bene fare in Brian una porta per ogni agente con cui comunicare.<br /> Ho visto che in &quot;msg.h&quot; 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. <br /> <br /> Gli agenti si scambiano messaggi in formato XML.<br /> <br /> Ti avevo scritto della funzione addOptions(), utilizzata nell'inizializzazione di BrianExpert: tale funzione utilizza la libreria boost c++.<br /> <br /> 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:<br /> <br /> mCL[SONAR_QUALITY_DATA]=SonarExpert::bad_quality;<br /> ...<br /> mCL[HOKUYO_DATA_QUALITY_HEADER+names[0]]=HokuyoConfig::getInstance()-&gt;getMaxQuality();<br /> <br /> che richiederebbero di tradurre anche la classe HokuyoConfig e il sonarExpert!<br /> <br /> (Michele, 4 agosto)<br /> <br /> == COmunicazione Espertio ==<br /> <br /> secondo me dovremo fare:<br /> <br /> - porta in lettura e scrittura per comunicare con command manager (che forse è meglio rinominare in joypadExpert o qualcosa di simile)<br /> - porta in scrittura per motorExpert (non vorrei dire una cavolata ma è Brian che manda messaggi a motor expert giusto?)<br /> - porta in lettura (e/o scrittura) verso odoExpert<br /> <br /> 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<br /> <br /> 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<br /> <br /> (Andrea, 6 agosto)<br /> <br /> == Comunicazione Brian-MotorExpert ==<br /> <br /> Brian può anche ricevere i messaggi da motorExpert:<br /> <br /> //in BrianExpert.cpp<br /> ExecStatus BrianExpert::Execute(){<br /> ...<br /> if(ReceiveLastMessage(MSG_FROM_MOTION_BRIEF,buffer,false)&gt;0){<br /> InterfaceSetDatalex_memory((const char *)buffer,this);<br /> DBG(&quot;message from motion\n&quot;);<br /> }<br /> ...<br /> <br /> //in GestioneAgenti.cpp<br /> void GestioneAgenti::createMapMessageAgents(){<br /> //aggiungere per ogni tipo di messaggio gli agenti che lo possono produrre<br /> ...<br /> messageAgents[MSG_FROM_MOTION_BRIEF]=vector&lt;string&gt;();<br /> messageAgents[MSG_FROM_MOTION_BRIEF].push_back(motor_agent);<br /> <br /> Guardo anch'io la addEvent e poi ti faccio sapere!<br /> <br /> <br /> (Michele, 6 agosto)</div>

MichelePellegrini https://airwiki.deib.polimi.it/index.php?title=Talk:Porting_su_Orocos_di_alcuni_moduli_software_di_Lurch&diff=12168 2010-08-16T20:43:22Z

<p>MichelePellegrini: /* Brian */ new section</p> <hr /> <div>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<br /> <br /> == Cosa dobbiamo ancora fare ==<br /> Ricapitolando le cose fatte fin'ora:<br /> <br /> - Interfaccia con la porta seriale;<br /> - JoystickExpert<br /> - configurazione di Eclipse per usare orocos senza gestire manualmente makefile<br /> <br /> <br /> Ora:<br /> <br /> - dobbiamo fare Brian<br /> - bisogna mettere a posto il fatto delle dead zone<br /> <br /> ci conviene dividere il lavoro.. per quanto riguarda il real time credo che un po' tutti i componente diventano real time con orocos<br /> <br /> <br /> (Andrea, 26 luglio)<br /> <br /> == Agenti - BrianExpert ==<br /> <br /> Secondo me, bisogna esplicitare il fatto che un thread debba essere svolto in modo real time.<br /> <br /> Bisogna individuare gli agenti da rendere real time.<br /> <br /> 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.<br /> <br /> (Michele, 26 luglio)<br /> <br /> == Deadzone e comunicazione agenti ==<br /> <br /> fatta la classe per la dead zone, ora bisogna solo applicarla;<br /> <br /> per Brian ho pensato che lo scambio di messaggi tra i vari agenti si può fare con le porte, cioè<br /> <br /> - uso readDataPort per ogni agente da cui arrivano messaggi <br /> - uso writeDataProt per ogni agente a cui mandare messaggi<br /> <br /> 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ì:<br /> <br /> 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 &quot;recenti&quot; quindi alcuni dati bufferizzati devono essere eliminati.<br /> <br /> <br /> (Andrea, 2 agosto)<br /> <br /> == Brian Expert ==<br /> <br /> 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().<br /> <br /> Nel loro BrianExpert.cpp ci sono anche molti rifermenti a tipi di messaggi che noi non useremo (ad esempio quelli dei sensori Hokuyo).<br /> <br /> Sto cercando di capire il funzionamento della funzione di configurazione addOptions().<br /> <br /> Ti mando per mail<br /> -una parte di codice relativa ad una prova su Orocos: Brian invia una stringa a MotorExpert come dicevi tu utilizzando le porte<br /> -una versione del loro BrianExpert.cpp cui ho aggiunto dei commenti su dove sono definite alcune funzioni e variabili e il loro significato.<br /> <br /> (Michele, 3 agosto)<br /> <br /> == Porte ed eventi (comunicazione tra esperti) ==<br /> <br /> 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<br /> <br /> Ho visto un po gli eventi e stavo pensando che:<br /> <br /> - gli agenti che devono inviare dati ad altri agenti possono usare le porte;<br /> - quando un agente deve invece reagire a qualcosa che è accaduto possiamo usare gli eventi.<br /> <br /> Penso che la maggior parte degli agenti comunichi qualche dato.<br /> <br /> (Andrea, 4 agosto)<br /> <br /> == Brian ==<br /> <br /> Anche secondo me è bene fare in Brian una porta per ogni agente con cui comunicare.<br /> Ho visto che in &quot;msg.h&quot; 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. <br /> <br /> Gli agenti si scambiano messaggi in formato XML.<br /> <br /> Ti avevo scritto della funzione addOptions(), utilizzata nell'inizializzazione di BrianExpert: tale funzione utilizza la libreria boost c++.<br /> <br /> 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:<br /> <br /> mCL[SONAR_QUALITY_DATA]=SonarExpert::bad_quality;<br /> ...<br /> mCL[HOKUYO_DATA_QUALITY_HEADER+names[0]]=HokuyoConfig::getInstance()-&gt;getMaxQuality();<br /> <br /> che richiederebbero di tradurre anche la classe HokuyoConfig e il sonarExpert!<br /> <br /> (Michele, 4 agosto)</div>

MichelePellegrini https://airwiki.deib.polimi.it/index.php?title=Talk:Porting_su_Orocos_di_alcuni_moduli_software_di_Lurch&diff=12153 2010-08-16T20:25:33Z

<p>MichelePellegrini: /* Brian Expert */ new section</p> <hr /> <div>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<br /> <br /> == Cosa dobbiamo ancora fare ==<br /> Dopo aver fatto l'esperto del joystick e la parte che si interfaccia con la porta seriale, ora<br /> <br /> - dobbiamo fare Brian<br /> - bisogna mettere a posto il fatto delle dead zone<br /> <br /> ci conviene dividere il lavoro.. per quanto riguarda il real time credo che un po' tutti i componente diventano real time con orocos<br /> <br /> == Agenti - BrianExpert ==<br /> <br /> Secondo me, bisogna esplicitare il fatto che un thread debba essere svolto in modo real time.<br /> <br /> Bisogna individuare gli agenti da rendere real time.<br /> <br /> 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.<br /> <br /> == Deadzone e comunicazione agenti ==<br /> <br /> fatta la classe per la dead zone, ora bisogna solo applicarla;<br /> <br /> per Brian ho pensato che lo scambio di messaggi tra i vari agenti si può fare con le porte, cioè<br /> <br /> - uso readDataPort per ogni agente da cui arrivano messaggi - uso writeDataProt per ogni agente a cui mandare messaggi<br /> <br /> 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ì:<br /> <br /> 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 &quot;recenti&quot; quindi alcuni dati bufferizzati devono essere eliminati.<br /> <br /> == Brian Expert ==<br /> <br /> 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().<br /> <br /> Nel loro BrianExpert.cpp ci sono anche molti rifermenti a tipi di messaggi che noi non useremo (ad esempio quelli dei sensori Hokuyo).<br /> <br /> Sto cercando di capire il funzionamento della funzione di configurazione addOptions().<br /> <br /> Ti mando per mail<br /> -una parte di codice relativa ad una prova su Orocos: Brian invia una stringa a MotorExpert come dicevi tu utilizzando le porte<br /> -una versione del loro BrianExpert.cpp cui ho aggiunto dei commenti su dove sono definite alcune funzioni e variabili e il loro significato.</div>

MichelePellegrini https://airwiki.deib.polimi.it/index.php?title=Talk:Porting_su_Orocos_di_alcuni_moduli_software_di_Lurch&diff=12151 2010-08-16T20:21:47Z

<p>MichelePellegrini: /* Agenti - BrianExpert */</p> <hr /> <div>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<br /> <br /> == Cosa dobbiamo ancora fare ==<br /> Dopo aver fatto l'esperto del joystick e la parte che si interfaccia con la porta seriale, ora<br /> <br /> - dobbiamo fare Brian<br /> - bisogna mettere a posto il fatto delle dead zone<br /> <br /> ci conviene dividere il lavoro.. per quanto riguarda il real time credo che un po' tutti i componente diventano real time con orocos<br /> <br /> == Agenti - BrianExpert ==<br /> <br /> Secondo me, bisogna esplicitare il fatto che un thread debba essere svolto in modo real time.<br /> <br /> Bisogna individuare gli agenti da rendere real time.<br /> <br /> 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.<br /> <br /> == Agenti - BrianExpert ==<br /> <br /> Secondo me, bisogna esplicitare il fatto che un thread debba essere svolto in modo real time.<br /> <br /> Bisogna individuare gli agenti da rendere real time.<br /> <br /> 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.</div>

MichelePellegrini https://airwiki.deib.polimi.it/index.php?title=Talk:Porting_su_Orocos_di_alcuni_moduli_software_di_Lurch&diff=12150 2010-08-16T20:20:54Z

<p>MichelePellegrini: /* Agenti - BrianExpert */ new section</p> <hr /> <div>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<br /> <br /> == Cosa dobbiamo ancora fare ==<br /> Dopo aver fatto l'esperto del joystick e la parte che si interfaccia con la porta seriale, ora<br /> <br /> - dobbiamo fare Brian<br /> - bisogna mettere a posto il fatto delle dead zone<br /> <br /> ci conviene dividere il lavoro.. per quanto riguarda il real time credo che un po' tutti i componente diventano real time con orocos<br /> <br /> == Aggiornamenti (Deadzone e comunicazione agenti) ==<br /> <br /> fatta la classe per la dead zone, ora bisogna solo applicarla;<br /> <br /> per Brian ho pensato che lo scambio di messaggi tra i vari agenti si può fare con le porte, cioè<br /> <br /> - uso readDataPort per ogni agente da cui arrivano messaggi <br /> - uso writeDataProt per ogni agente a cui mandare messaggi<br /> <br /> 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ì:<br /> <br /> 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 &quot;recenti&quot; quindi alcuni dati bufferizzati devono essere eliminati.<br /> <br /> == Agenti - BrianExpert ==<br /> <br /> Secondo me, bisogna esplicitare il fatto che un thread debba essere svolto in modo real time.<br /> <br /> Bisogna individuare gli agenti da rendere real time.<br /> <br /> 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.</div>

MichelePellegrini https://airwiki.deib.polimi.it/index.php?title=User:MichelePellegrini&diff=11677 2010-05-11T13:44:30Z

<p>MichelePellegrini: </p> <hr /> <div>{{Student<br /> |category=Student<br /> |firstname=Michele<br /> |lastname=Pellegrini<br /> |photo=Picture0001.jpg<br /> |email=michelejuventus@libero.it<br /> |advisor=MatteoMatteucci; SimoneCeriani;<br /> |status=active<br /> }}</div>

MichelePellegrini https://airwiki.deib.polimi.it/index.php?title=File:Picture0001.jpg&diff=11676 2010-05-11T13:44:24Z

<p>MichelePellegrini: </p> <hr /> <div></div>

MichelePellegrini https://airwiki.deib.polimi.it/index.php?title=User:MichelePellegrini&diff=11204 2010-04-13T12:46:47Z

<p>MichelePellegrini: New page: {{Student |category=Student |firstname=Michele |lastname=Pellegrini |email=michelejuventus@libero.it |advisor=MatteoMatteucci; SimoneCeriani; |status=active }}</p> <hr /> <div>{{Student<br /> |category=Student<br /> |firstname=Michele<br /> |lastname=Pellegrini<br /> |email=michelejuventus@libero.it<br /> |advisor=MatteoMatteucci; SimoneCeriani; <br /> |status=active<br /> }}</div>

MichelePellegrini