From: Paul O. <new...@ki...> - 2009-05-16 19:29:19
|
Hello devels, I've found that playerc_client_set_replace_rule() function sends PLAYER_PLAYER_REQ_ADD_REPLACE_RULE request to given client in order to add replace rule. How can I send such a request from one (plugin) driver to some another driver from which I am subscribing interfaces? Paul |
From: Paul O. <new...@ki...> - 2009-05-18 22:24:07
|
Ok, let's ask it simpler: is it possible for a driver to set replace rule for subscribed interface of another driver? If so, how can I do that in my plugins code? Paul On Sat, 16 May 2009, Paul Osmialowski wrote: > Hello devels, > > I've found that playerc_client_set_replace_rule() function sends > PLAYER_PLAYER_REQ_ADD_REPLACE_RULE request to given client Of course, it should be 'request to given driver', silly mistake. > in order to add > replace rule. How can I send such a request from one (plugin) driver to > some another driver from which I am subscribing interfaces? > > Paul |
From: Matthew C. <the...@gm...> - 2009-05-19 01:04:15
|
this->InQueue->AddReplaceRule(int _host, int _robot, int _interf, int _index, int _type, int _subtype, int _replace); -1 is used as wild card. Check out message.h 2009/5/19 Paul Osmialowski <new...@ki...> > Ok, let's ask it simpler: is it possible for a driver to set replace rule > for subscribed interface of another driver? If so, how can I do that in > my plugins code? > > Paul > > On Sat, 16 May 2009, Paul Osmialowski wrote: > > > Hello devels, > > > > I've found that playerc_client_set_replace_rule() function sends > > PLAYER_PLAYER_REQ_ADD_REPLACE_RULE request to given client > Of course, it should be 'request to given driver', silly mistake. > > > in order to add > > replace rule. How can I send such a request from one (plugin) driver to > > some another driver from which I am subscribing interfaces? > > > > Paul > > > ------------------------------------------------------------------------------ > Crystal Reports - New Free Runtime and 30 Day Trial > Check out the new simplified licensing option that enables > unlimited royalty-free distribution of the report engine > for externally facing server and web deployment. > http://p.sf.net/sfu/businessobjects > _______________________________________________ > Playerstage-developers mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-developers > |
From: Paul O. <new...@ki...> - 2009-05-19 08:05:59
|
On Tue, 19 May 2009, Matthew Casey wrote: > this->InQueue->AddReplaceRule(int _host, int _robot, int _interf, int > _index, int _type, int _subtype, int _replace); > > -1 is used as wild card. Check out message.h This suggests I'm setting replace rule on in-queue of current driver, however, I hope that because host/robot/interf/index references remote device, AddReplaceRule() method will set things as I need it, however in whole queueing code I can't see a place where PLAYER_PLAYER_REQ_ADD_REPLACE_RULE constant is used. Paul > > 2009/5/19 Paul Osmialowski <new...@ki...> > >> Ok, let's ask it simpler: is it possible for a driver to set replace rule >> for subscribed interface of another driver? If so, how can I do that in >> my plugins code? >> >> Paul >> >> On Sat, 16 May 2009, Paul Osmialowski wrote: >> >>> Hello devels, >>> >>> I've found that playerc_client_set_replace_rule() function sends >>> PLAYER_PLAYER_REQ_ADD_REPLACE_RULE request to given client >> Of course, it should be 'request to given driver', silly mistake. >> >>> in order to add >>> replace rule. How can I send such a request from one (plugin) driver to >>> some another driver from which I am subscribing interfaces? >>> >>> Paul >> >> >> ------------------------------------------------------------------------------ >> Crystal Reports - New Free Runtime and 30 Day Trial >> Check out the new simplified licensing option that enables >> unlimited royalty-free distribution of the report engine >> for externally facing server and web deployment. >> http://p.sf.net/sfu/businessobjects >> _______________________________________________ >> Playerstage-developers mailing list >> Pla...@li... >> https://lists.sourceforge.net/lists/listinfo/playerstage-developers >> > |
From: gbiggs <gb...@ki...> - 2009-05-19 08:17:08
|
Paul Osmialowski wrote: > This suggests I'm setting replace rule on in-queue of current driver, That's exactly what it's doing. As I recall, that's the only queue there is between two drivers (Toby will know for sure). > however, I hope that because host/robot/interf/index references remote > device, AddReplaceRule() method will set things as I need it, however in You should set the host/robot/interf/index accordingly for the driver you're filtering messages from. If you set them all to -1, then you will filter any messages to the driver. If you set them to match the local server and the interface and index from the driver you're filtering from, you'll only filter from that driver. > whole queueing code I can't see a place where > PLAYER_PLAYER_REQ_ADD_REPLACE_RULE constant is used. > Paul That constant is a message type. It's only used between clients and the server and is used to tell the server to add a replace rule on the client's message queue from within libplayertcp/udp: client->queue->AddReplaceRule(-1,-1,req->interf, req->index, req->type, req->subtype, req->replace); Geoff |
From: Toby C. <tco...@pl...> - 2009-05-19 08:25:41
|
Unfortunately I cant give a simple answer to this one. I think there are issues with using this between servers. A couple of other issues with the remote driver module have been brought to my attention recently and I was hoping to get a chance to look into them some time this week. Basically whether it will work for you will depend on what you are actually trying to do. I am assuming you have a set up something like server A with driver B and server C with driver D. D is subscribing to B and you are wanting to set a replace rule on the data stream coming from B? In this case there is a virtual driver 'E' on server C which is the intermediatary. This has a client on server A (at the risk of confusions lets call the clean 'F'). If as I think you do, you want to set the replace rule for the queue on 'F' then I think currently you are out of luck. But I could be wrong. setting Pull/Push mode is even more confusing from memory. So to recap data messages flow something like this: B->(A)->F->(C)->E->(C)->D commands of course do the opposite. Toby 2009/5/19 Paul Osmialowski <new...@ki...> > > > On Tue, 19 May 2009, Matthew Casey wrote: > > > this->InQueue->AddReplaceRule(int _host, int _robot, int _interf, int > > _index, int _type, int _subtype, int _replace); > > > > -1 is used as wild card. Check out message.h > This suggests I'm setting replace rule on in-queue of current driver, > however, I hope that because host/robot/interf/index references remote > device, AddReplaceRule() method will set things as I need it, however in > whole queueing code I can't see a place where > PLAYER_PLAYER_REQ_ADD_REPLACE_RULE constant is used. > Paul > > > > > 2009/5/19 Paul Osmialowski <new...@ki...> > > > >> Ok, let's ask it simpler: is it possible for a driver to set replace > rule > >> for subscribed interface of another driver? If so, how can I do that in > >> my plugins code? > >> > >> Paul > >> > >> On Sat, 16 May 2009, Paul Osmialowski wrote: > >> > >>> Hello devels, > >>> > >>> I've found that playerc_client_set_replace_rule() function sends > >>> PLAYER_PLAYER_REQ_ADD_REPLACE_RULE request to given client > >> Of course, it should be 'request to given driver', silly mistake. > >> > >>> in order to add > >>> replace rule. How can I send such a request from one (plugin) driver to > >>> some another driver from which I am subscribing interfaces? > >>> > >>> Paul > >> > >> > >> > ------------------------------------------------------------------------------ > >> Crystal Reports - New Free Runtime and 30 Day Trial > >> Check out the new simplified licensing option that enables > >> unlimited royalty-free distribution of the report engine > >> for externally facing server and web deployment. > >> http://p.sf.net/sfu/businessobjects > >> _______________________________________________ > >> Playerstage-developers mailing list > >> Pla...@li... > >> https://lists.sourceforge.net/lists/listinfo/playerstage-developers > >> > > > > > ------------------------------------------------------------------------------ > Crystal Reports - New Free Runtime and 30 Day Trial > Check out the new simplified licensing option that enables > unlimited royalty-free distribution of the report engine > for externally facing server and web deployment. > http://p.sf.net/sfu/businessobjects > _______________________________________________ > Playerstage-developers mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-developers > -- This email is intended for the addressee only and may contain privileged and/or confidential information |
From: Paul O. <new...@ki...> - 2009-05-19 08:38:02
|
On Tue, 19 May 2009, Toby Collett wrote: > Unfortunately I cant give a simple answer to this one. I think there are > issues with using this between servers. A couple of other issues with the > remote driver module have been brought to my attention recently and I was > hoping to get a chance to look into them some time this week. > > Basically whether it will work for you will depend on what you are actually > trying to do. I am assuming you have a set up something like server A with > driver B and server C with driver D. D is subscribing to B and you are > wanting to set a replace rule on the data stream coming from B? Not exactly. Indeed, D is subscribing to B. Then D is doing PutMsg (for example B is p2os and D is sending velocity commands to subscribed position2d interface). I don't want these commands to be queued. I know how to do that from client side, however I can't see how it should be done if one driver talks to another. Paul |
From: Toby C. <tco...@pl...> - 2009-05-19 08:55:06
|
The queuing of commands is decided completely on the receiving driver end. There shouldn't be any difference between a client sending them and a driver AFAIK. Toby 2009/5/19 Paul Osmialowski <new...@ki...> > > > On Tue, 19 May 2009, Toby Collett wrote: > > > Unfortunately I cant give a simple answer to this one. I think there are > > issues with using this between servers. A couple of other issues with the > > remote driver module have been brought to my attention recently and I was > > hoping to get a chance to look into them some time this week. > > > > Basically whether it will work for you will depend on what you are > actually > > trying to do. I am assuming you have a set up something like server A > with > > driver B and server C with driver D. D is subscribing to B and you are > > wanting to set a replace rule on the data stream coming from B? > Not exactly. Indeed, D is subscribing to B. Then D is doing PutMsg (for > example B is p2os and D is sending velocity commands to subscribed > position2d interface). I don't want these commands to be queued. I know > how to do that from client side, however I can't see how it should be done > if one driver talks to another. > > Paul > > > > ------------------------------------------------------------------------------ > Crystal Reports - New Free Runtime and 30 Day Trial > Check out the new simplified licensing option that enables > unlimited royalty-free distribution of the report engine > for externally facing server and web deployment. > http://p.sf.net/sfu/businessobjects > _______________________________________________ > Playerstage-developers mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-developers > -- This email is intended for the addressee only and may contain privileged and/or confidential information |
From: Paul O. <new...@ki...> - 2009-05-19 11:04:39
|
On Tue, 19 May 2009, Toby Collett wrote: > The queuing of commands is decided completely on the receiving driver end. > There shouldn't be any difference between a client sending them and a driver > AFAIK. > > Toby > That's the point. In client side API there's playerc_client_set_replace_rule() function which sends PLAYER_PLAYER_REQ_ADD_REPLACE_RULE request while I can't see anything like that in driver side API. I'm thinking about sending this request directly, but I don't know yet on what object shall I call Request() method, I guess there's no client object on driver side, so there must be something else on which I can call Request() (or there's a method in driver API that do the thing better/safer). Paul > 2009/5/19 Paul Osmialowski <new...@ki...> > >> >> >> On Tue, 19 May 2009, Toby Collett wrote: >> >>> Unfortunately I cant give a simple answer to this one. I think there are >>> issues with using this between servers. A couple of other issues with the >>> remote driver module have been brought to my attention recently and I was >>> hoping to get a chance to look into them some time this week. >>> >>> Basically whether it will work for you will depend on what you are >> actually >>> trying to do. I am assuming you have a set up something like server A >> with >>> driver B and server C with driver D. D is subscribing to B and you are >>> wanting to set a replace rule on the data stream coming from B? >> Not exactly. Indeed, D is subscribing to B. Then D is doing PutMsg (for >> example B is p2os and D is sending velocity commands to subscribed >> position2d interface). I don't want these commands to be queued. I know >> how to do that from client side, however I can't see how it should be done >> if one driver talks to another. >> >> Paul >> >> >> >> ------------------------------------------------------------------------------ >> Crystal Reports - New Free Runtime and 30 Day Trial >> Check out the new simplified licensing option that enables >> unlimited royalty-free distribution of the report engine >> for externally facing server and web deployment. >> http://p.sf.net/sfu/businessobjects >> _______________________________________________ >> Playerstage-developers mailing list >> Pla...@li... >> https://lists.sourceforge.net/lists/listinfo/playerstage-developers >> > > > > -- > This email is intended for the addressee only and may contain privileged > and/or confidential information > |
From: Toby C. <tco...@pl...> - 2009-05-19 12:02:28
|
That request sets replace rules on the clients queue on the server, i.e. for data coming to the client. It should not affect commands coming from the client (i.e. velocity commands) as these are posted onto the driver queue. Toby 2009/5/19 Paul Osmialowski <new...@ki...> > > > On Tue, 19 May 2009, Toby Collett wrote: > > > The queuing of commands is decided completely on the receiving driver > end. > > There shouldn't be any difference between a client sending them and a > driver > > AFAIK. > > > > Toby > > > That's the point. In client side API there's > playerc_client_set_replace_rule() function which sends > PLAYER_PLAYER_REQ_ADD_REPLACE_RULE request while I can't see anything like > that in driver side API. I'm thinking about sending this request directly, > but I don't know yet on what object shall I call Request() method, I guess > there's no client object on driver side, so there must be something else > on which I can call Request() (or there's a method in driver API that do > the thing better/safer). > > Paul > > > 2009/5/19 Paul Osmialowski <new...@ki...> > > > >> > >> > >> On Tue, 19 May 2009, Toby Collett wrote: > >> > >>> Unfortunately I cant give a simple answer to this one. I think there > are > >>> issues with using this between servers. A couple of other issues with > the > >>> remote driver module have been brought to my attention recently and I > was > >>> hoping to get a chance to look into them some time this week. > >>> > >>> Basically whether it will work for you will depend on what you are > >> actually > >>> trying to do. I am assuming you have a set up something like server A > >> with > >>> driver B and server C with driver D. D is subscribing to B and you are > >>> wanting to set a replace rule on the data stream coming from B? > >> Not exactly. Indeed, D is subscribing to B. Then D is doing PutMsg (for > >> example B is p2os and D is sending velocity commands to subscribed > >> position2d interface). I don't want these commands to be queued. I know > >> how to do that from client side, however I can't see how it should be > done > >> if one driver talks to another. > >> > >> Paul > >> > >> > >> > >> > ------------------------------------------------------------------------------ > >> Crystal Reports - New Free Runtime and 30 Day Trial > >> Check out the new simplified licensing option that enables > >> unlimited royalty-free distribution of the report engine > >> for externally facing server and web deployment. > >> http://p.sf.net/sfu/businessobjects > >> _______________________________________________ > >> Playerstage-developers mailing list > >> Pla...@li... > >> https://lists.sourceforge.net/lists/listinfo/playerstage-developers > >> > > > > > > > > -- > > This email is intended for the addressee only and may contain privileged > > and/or confidential information > > > > > ------------------------------------------------------------------------------ > Crystal Reports - New Free Runtime and 30 Day Trial > Check out the new simplified licensing option that enables > unlimited royalty-free distribution of the report engine > for externally facing server and web deployment. > http://p.sf.net/sfu/businessobjects > _______________________________________________ > Playerstage-developers mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-developers > -- This email is intended for the addressee only and may contain privileged and/or confidential information |
From: Paul O. <new...@ki...> - 2009-05-19 12:08:47
|
On Tue, 19 May 2009, Toby Collett wrote: > That request sets replace rules on the clients queue on the server, i.e. for > data coming to the client. It should not affect commands coming from the > client (i.e. velocity commands) as these are posted onto the driver queue. > > Toby > That's the bad news. Now I need to know how to avoid command queues in both client and driver API. Paul > 2009/5/19 Paul Osmialowski <new...@ki...> > >> >> >> On Tue, 19 May 2009, Toby Collett wrote: >> >>> The queuing of commands is decided completely on the receiving driver >> end. >>> There shouldn't be any difference between a client sending them and a >> driver >>> AFAIK. >>> >>> Toby >>> >> That's the point. In client side API there's >> playerc_client_set_replace_rule() function which sends >> PLAYER_PLAYER_REQ_ADD_REPLACE_RULE request while I can't see anything like >> that in driver side API. I'm thinking about sending this request directly, >> but I don't know yet on what object shall I call Request() method, I guess >> there's no client object on driver side, so there must be something else >> on which I can call Request() (or there's a method in driver API that do >> the thing better/safer). >> >> Paul >> >>> 2009/5/19 Paul Osmialowski <new...@ki...> >>> >>>> >>>> >>>> On Tue, 19 May 2009, Toby Collett wrote: >>>> >>>>> Unfortunately I cant give a simple answer to this one. I think there >> are >>>>> issues with using this between servers. A couple of other issues with >> the >>>>> remote driver module have been brought to my attention recently and I >> was >>>>> hoping to get a chance to look into them some time this week. >>>>> >>>>> Basically whether it will work for you will depend on what you are >>>> actually >>>>> trying to do. I am assuming you have a set up something like server A >>>> with >>>>> driver B and server C with driver D. D is subscribing to B and you are >>>>> wanting to set a replace rule on the data stream coming from B? >>>> Not exactly. Indeed, D is subscribing to B. Then D is doing PutMsg (for >>>> example B is p2os and D is sending velocity commands to subscribed >>>> position2d interface). I don't want these commands to be queued. I know >>>> how to do that from client side, however I can't see how it should be >> done >>>> if one driver talks to another. >>>> >>>> Paul >>>> >>>> >>>> >>>> >> ------------------------------------------------------------------------------ >>>> Crystal Reports - New Free Runtime and 30 Day Trial >>>> Check out the new simplified licensing option that enables >>>> unlimited royalty-free distribution of the report engine >>>> for externally facing server and web deployment. >>>> http://p.sf.net/sfu/businessobjects >>>> _______________________________________________ >>>> Playerstage-developers mailing list >>>> Pla...@li... >>>> https://lists.sourceforge.net/lists/listinfo/playerstage-developers >>>> >>> >>> >>> >>> -- >>> This email is intended for the addressee only and may contain privileged >>> and/or confidential information >>> >> >> >> ------------------------------------------------------------------------------ >> Crystal Reports - New Free Runtime and 30 Day Trial >> Check out the new simplified licensing option that enables >> unlimited royalty-free distribution of the report engine >> for externally facing server and web deployment. >> http://p.sf.net/sfu/businessobjects >> _______________________________________________ >> Playerstage-developers mailing list >> Pla...@li... >> https://lists.sourceforge.net/lists/listinfo/playerstage-developers >> > > > > -- > This email is intended for the addressee only and may contain privileged > and/or confidential information > |
From: Toby C. <tco...@pl...> - 2009-05-19 15:56:38
|
The constructor for the driver specifies the replace rule for incoming commands as a boolean. I assume you can manipulate this on the drivers queue. The difference is that it is the recieving driver than controls the replace rules of commands to it, not the sender of the commands. 2009/5/19 Paul Osmialowski <new...@ki...> > > > On Tue, 19 May 2009, Toby Collett wrote: > > > That request sets replace rules on the clients queue on the server, i.e. > for > > data coming to the client. It should not affect commands coming from the > > client (i.e. velocity commands) as these are posted onto the driver > queue. > > > > Toby > > > That's the bad news. Now I need to know how to avoid command queues in > both client and driver API. > Paul > > > 2009/5/19 Paul Osmialowski <new...@ki...> > > > >> > >> > >> On Tue, 19 May 2009, Toby Collett wrote: > >> > >>> The queuing of commands is decided completely on the receiving driver > >> end. > >>> There shouldn't be any difference between a client sending them and a > >> driver > >>> AFAIK. > >>> > >>> Toby > >>> > >> That's the point. In client side API there's > >> playerc_client_set_replace_rule() function which sends > >> PLAYER_PLAYER_REQ_ADD_REPLACE_RULE request while I can't see anything > like > >> that in driver side API. I'm thinking about sending this request > directly, > >> but I don't know yet on what object shall I call Request() method, I > guess > >> there's no client object on driver side, so there must be something else > >> on which I can call Request() (or there's a method in driver API that do > >> the thing better/safer). > >> > >> Paul > >> > >>> 2009/5/19 Paul Osmialowski <new...@ki...> > >>> > >>>> > >>>> > >>>> On Tue, 19 May 2009, Toby Collett wrote: > >>>> > >>>>> Unfortunately I cant give a simple answer to this one. I think there > >> are > >>>>> issues with using this between servers. A couple of other issues with > >> the > >>>>> remote driver module have been brought to my attention recently and I > >> was > >>>>> hoping to get a chance to look into them some time this week. > >>>>> > >>>>> Basically whether it will work for you will depend on what you are > >>>> actually > >>>>> trying to do. I am assuming you have a set up something like server A > >>>> with > >>>>> driver B and server C with driver D. D is subscribing to B and you > are > >>>>> wanting to set a replace rule on the data stream coming from B? > >>>> Not exactly. Indeed, D is subscribing to B. Then D is doing PutMsg > (for > >>>> example B is p2os and D is sending velocity commands to subscribed > >>>> position2d interface). I don't want these commands to be queued. I > know > >>>> how to do that from client side, however I can't see how it should be > >> done > >>>> if one driver talks to another. > >>>> > >>>> Paul > >>>> > >>>> > >>>> > >>>> > >> > ------------------------------------------------------------------------------ > >>>> Crystal Reports - New Free Runtime and 30 Day Trial > >>>> Check out the new simplified licensing option that enables > >>>> unlimited royalty-free distribution of the report engine > >>>> for externally facing server and web deployment. > >>>> http://p.sf.net/sfu/businessobjects > >>>> _______________________________________________ > >>>> Playerstage-developers mailing list > >>>> Pla...@li... > >>>> https://lists.sourceforge.net/lists/listinfo/playerstage-developers > >>>> > >>> > >>> > >>> > >>> -- > >>> This email is intended for the addressee only and may contain > privileged > >>> and/or confidential information > >>> > >> > >> > >> > ------------------------------------------------------------------------------ > >> Crystal Reports - New Free Runtime and 30 Day Trial > >> Check out the new simplified licensing option that enables > >> unlimited royalty-free distribution of the report engine > >> for externally facing server and web deployment. > >> http://p.sf.net/sfu/businessobjects > >> _______________________________________________ > >> Playerstage-developers mailing list > >> Pla...@li... > >> https://lists.sourceforge.net/lists/listinfo/playerstage-developers > >> > > > > > > > > -- > > This email is intended for the addressee only and may contain privileged > > and/or confidential information > > > > > ------------------------------------------------------------------------------ > Crystal Reports - New Free Runtime and 30 Day Trial > Check out the new simplified licensing option that enables > unlimited royalty-free distribution of the report engine > for externally facing server and web deployment. > http://p.sf.net/sfu/businessobjects > _______________________________________________ > Playerstage-developers mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-developers > -- This email is intended for the addressee only and may contain privileged and/or confidential information |
From: Paul O. <new...@ki...> - 2009-05-19 16:14:40
|
Seems like I had wrong idea what playerc_client_set_replace_rule() does (I got wrong idea of "client queue on server" mentioned in client API manual). Looks like the only way to avoid queueing of commands is to rewrite a driver constructor, as I can see all drivers have queue length hardcoded. In my opinion, incoming queue lenght should be every driver parameter (as 'alwayson' and 'provides'). If someone does not wan queueing for given driver, it can be set to 1 in config file. Paul On Tue, 19 May 2009, Toby Collett wrote: > The constructor for the driver specifies the replace rule for incoming > commands as a boolean. I assume you can manipulate this on the drivers > queue. The difference is that it is the recieving driver than controls the > replace rules of commands to it, not the sender of the commands. > > 2009/5/19 Paul Osmialowski <new...@ki...> > >> >> >> On Tue, 19 May 2009, Toby Collett wrote: >> >>> That request sets replace rules on the clients queue on the server, i.e. >> for >>> data coming to the client. It should not affect commands coming from the >>> client (i.e. velocity commands) as these are posted onto the driver >> queue. >>> >>> Toby >>> >> That's the bad news. Now I need to know how to avoid command queues in >> both client and driver API. >> Paul >> >>> 2009/5/19 Paul Osmialowski <new...@ki...> >>> >>>> >>>> >>>> On Tue, 19 May 2009, Toby Collett wrote: >>>> >>>>> The queuing of commands is decided completely on the receiving driver >>>> end. >>>>> There shouldn't be any difference between a client sending them and a >>>> driver >>>>> AFAIK. >>>>> >>>>> Toby >>>>> >>>> That's the point. In client side API there's >>>> playerc_client_set_replace_rule() function which sends >>>> PLAYER_PLAYER_REQ_ADD_REPLACE_RULE request while I can't see anything >> like >>>> that in driver side API. I'm thinking about sending this request >> directly, >>>> but I don't know yet on what object shall I call Request() method, I >> guess >>>> there's no client object on driver side, so there must be something else >>>> on which I can call Request() (or there's a method in driver API that do >>>> the thing better/safer). >>>> >>>> Paul >>>> >>>>> 2009/5/19 Paul Osmialowski <new...@ki...> >>>>> >>>>>> >>>>>> >>>>>> On Tue, 19 May 2009, Toby Collett wrote: >>>>>> >>>>>>> Unfortunately I cant give a simple answer to this one. I think there >>>> are >>>>>>> issues with using this between servers. A couple of other issues with >>>> the >>>>>>> remote driver module have been brought to my attention recently and I >>>> was >>>>>>> hoping to get a chance to look into them some time this week. >>>>>>> >>>>>>> Basically whether it will work for you will depend on what you are >>>>>> actually >>>>>>> trying to do. I am assuming you have a set up something like server A >>>>>> with >>>>>>> driver B and server C with driver D. D is subscribing to B and you >> are >>>>>>> wanting to set a replace rule on the data stream coming from B? >>>>>> Not exactly. Indeed, D is subscribing to B. Then D is doing PutMsg >> (for >>>>>> example B is p2os and D is sending velocity commands to subscribed >>>>>> position2d interface). I don't want these commands to be queued. I >> know >>>>>> how to do that from client side, however I can't see how it should be >>>> done >>>>>> if one driver talks to another. >>>>>> >>>>>> Paul >>>>>> >>>>>> >>>>>> >>>>>> >>>> >> ------------------------------------------------------------------------------ >>>>>> Crystal Reports - New Free Runtime and 30 Day Trial >>>>>> Check out the new simplified licensing option that enables >>>>>> unlimited royalty-free distribution of the report engine >>>>>> for externally facing server and web deployment. >>>>>> http://p.sf.net/sfu/businessobjects >>>>>> _______________________________________________ >>>>>> Playerstage-developers mailing list >>>>>> Pla...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/playerstage-developers >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> This email is intended for the addressee only and may contain >> privileged >>>>> and/or confidential information >>>>> >>>> >>>> >>>> >> ------------------------------------------------------------------------------ >>>> Crystal Reports - New Free Runtime and 30 Day Trial >>>> Check out the new simplified licensing option that enables >>>> unlimited royalty-free distribution of the report engine >>>> for externally facing server and web deployment. >>>> http://p.sf.net/sfu/businessobjects >>>> _______________________________________________ >>>> Playerstage-developers mailing list >>>> Pla...@li... >>>> https://lists.sourceforge.net/lists/listinfo/playerstage-developers >>>> >>> >>> >>> >>> -- >>> This email is intended for the addressee only and may contain privileged >>> and/or confidential information >>> >> >> >> ------------------------------------------------------------------------------ >> Crystal Reports - New Free Runtime and 30 Day Trial >> Check out the new simplified licensing option that enables >> unlimited royalty-free distribution of the report engine >> for externally facing server and web deployment. >> http://p.sf.net/sfu/businessobjects >> _______________________________________________ >> Playerstage-developers mailing list >> Pla...@li... >> https://lists.sourceforge.net/lists/listinfo/playerstage-developers >> > > > > -- > This email is intended for the addressee only and may contain privileged > and/or confidential information > |
From: gbiggs <gb...@ki...> - 2009-05-19 23:30:49
|
Making the queue length an option wouldn't be too hard (I just had a look), but I'm not sure that would solve your problem. It would just result in the message queue rapidly overflowing without suitable replacement rules set (the ability to set such rules on remote drivers is the actual issue, as I understand it - it's easy to do if the driver is on the same server). What you *probably* want is to be able to set replacement rules for a driver's InQueue in the config file. This would also be quite easy to do, I think. If I get time, maybe I'll give it a go today. Geoff Paul Osmialowski wrote: > Seems like I had wrong idea what playerc_client_set_replace_rule() does > (I got wrong idea of "client queue on server" mentioned in client API > manual). Looks like the only way to avoid queueing of commands is to > rewrite a driver constructor, as I can see all drivers have queue length > hardcoded. In my opinion, incoming queue lenght should be every driver > parameter (as 'alwayson' and 'provides'). If someone does not wan queueing > for given driver, it can be set to 1 in config file. |
From: Toby C. <tco...@pl...> - 2009-05-20 05:14:49
|
The rationale (right or wrong) for the current setup is that whether you want to replace a command depends on the nature of the command not the client. For the pioneer velocity control, we always want the latest as applying a sequence of speed just ends up with the final speed. For something like a draw line command to graphics2d you always want all of the commands as they all may specify different lines. Toby 2009/5/20 gbiggs <gb...@ki...> > Making the queue length an option wouldn't be too hard (I just had a > look), but I'm not sure that would solve your problem. It would just > result in the message queue rapidly overflowing without suitable > replacement rules set (the ability to set such rules on remote drivers > is the actual issue, as I understand it - it's easy to do if the driver > is on the same server). > > What you *probably* want is to be able to set replacement rules for a > driver's InQueue in the config file. This would also be quite easy to > do, I think. If I get time, maybe I'll give it a go today. > > Geoff > > Paul Osmialowski wrote: > > Seems like I had wrong idea what playerc_client_set_replace_rule() does > > (I got wrong idea of "client queue on server" mentioned in client API > > manual). Looks like the only way to avoid queueing of commands is to > > rewrite a driver constructor, as I can see all drivers have queue length > > hardcoded. In my opinion, incoming queue lenght should be every driver > > parameter (as 'alwayson' and 'provides'). If someone does not wan > queueing > > for given driver, it can be set to 1 in config file. > > > > ------------------------------------------------------------------------------ > Crystal Reports - New Free Runtime and 30 Day Trial > Check out the new simplified licensing option that enables > unlimited royalty-free distribution of the report engine > for externally facing server and web deployment. > http://p.sf.net/sfu/businessobjects > _______________________________________________ > Playerstage-developers mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-developers > -- This email is intended for the addressee only and may contain privileged and/or confidential information |
From: Toby C. <tco...@pl...> - 2009-05-20 05:32:19
|
I think the issue here is that p2os needs to not replace by default because the arm driver component needs to get every command. On the other hand there is no need to queue incoming velocity commands as only the latest has real meaning. The solution is to patch the p2os driver to set the position2d/cmd set of incoming messages to replace->true and then submit a patch if this improves the behaviour you are seeing. Toby 2009/5/20 Toby Collett <tco...@pl...<tcollett%2Bp...@pl...> > > The rationale (right or wrong) for the current setup is that whether you > want to replace a command depends on the nature of the command not the > client. For the pioneer velocity control, we always want the latest as > applying a sequence of speed just ends up with the final speed. For > something like a draw line command to graphics2d you always want all of the > commands as they all may specify different lines. > > Toby > > 2009/5/20 gbiggs <gb...@ki...> > > Making the queue length an option wouldn't be too hard (I just had a >> look), but I'm not sure that would solve your problem. It would just >> result in the message queue rapidly overflowing without suitable >> replacement rules set (the ability to set such rules on remote drivers >> is the actual issue, as I understand it - it's easy to do if the driver >> is on the same server). >> >> What you *probably* want is to be able to set replacement rules for a >> driver's InQueue in the config file. This would also be quite easy to >> do, I think. If I get time, maybe I'll give it a go today. >> >> Geoff >> >> Paul Osmialowski wrote: >> > Seems like I had wrong idea what playerc_client_set_replace_rule() does >> > (I got wrong idea of "client queue on server" mentioned in client API >> > manual). Looks like the only way to avoid queueing of commands is to >> > rewrite a driver constructor, as I can see all drivers have queue length >> > hardcoded. In my opinion, incoming queue lenght should be every driver >> > parameter (as 'alwayson' and 'provides'). If someone does not wan >> queueing >> > for given driver, it can be set to 1 in config file. >> >> >> >> ------------------------------------------------------------------------------ >> Crystal Reports - New Free Runtime and 30 Day Trial >> Check out the new simplified licensing option that enables >> unlimited royalty-free distribution of the report engine >> for externally facing server and web deployment. >> http://p.sf.net/sfu/businessobjects >> _______________________________________________ >> Playerstage-developers mailing list >> Pla...@li... >> https://lists.sourceforge.net/lists/listinfo/playerstage-developers >> > > > > -- > This email is intended for the addressee only and may contain privileged > and/or confidential information > -- This email is intended for the addressee only and may contain privileged and/or confidential information |
From: Paul O. <new...@ki...> - 2009-05-20 06:28:30
|
On Wed, 20 May 2009, Toby Collett wrote: > I think the issue here is that p2os needs to not replace by default because > the arm driver component needs to get every command. On the other hand there > is no need to queue incoming velocity commands as only the latest has real > meaning. > > The solution is to patch the p2os driver to set the position2d/cmd set of > incoming messages to replace->true and then submit a patch if this improves > the behaviour you are seeing. > > Toby > Actually it involves more than just p2os driver: I have different robots in my fleet: p2dx, roomba, create, and custom made robots with their own plugin drivers, all of them provide position2d interface. We may think of patching their drivers one by one, or adding new configuration option (Geoff said its easy to do) or both. Worse question is how to achieve it for Stages pioneer and roomba models? Paul > 2009/5/20 Toby Collett > <tco...@pl...<tcollett%2Bp...@pl...> >> > >> The rationale (right or wrong) for the current setup is that whether you >> want to replace a command depends on the nature of the command not the >> client. For the pioneer velocity control, we always want the latest as >> applying a sequence of speed just ends up with the final speed. For >> something like a draw line command to graphics2d you always want all of the >> commands as they all may specify different lines. >> >> Toby >> >> 2009/5/20 gbiggs <gb...@ki...> >> >> Making the queue length an option wouldn't be too hard (I just had a >>> look), but I'm not sure that would solve your problem. It would just >>> result in the message queue rapidly overflowing without suitable >>> replacement rules set (the ability to set such rules on remote drivers >>> is the actual issue, as I understand it - it's easy to do if the driver >>> is on the same server). >>> >>> What you *probably* want is to be able to set replacement rules for a >>> driver's InQueue in the config file. This would also be quite easy to >>> do, I think. If I get time, maybe I'll give it a go today. >>> >>> Geoff >>> >>> Paul Osmialowski wrote: >>>> Seems like I had wrong idea what playerc_client_set_replace_rule() does >>>> (I got wrong idea of "client queue on server" mentioned in client API >>>> manual). Looks like the only way to avoid queueing of commands is to >>>> rewrite a driver constructor, as I can see all drivers have queue length >>>> hardcoded. In my opinion, incoming queue lenght should be every driver >>>> parameter (as 'alwayson' and 'provides'). If someone does not wan >>> queueing >>>> for given driver, it can be set to 1 in config file. >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Crystal Reports - New Free Runtime and 30 Day Trial >>> Check out the new simplified licensing option that enables >>> unlimited royalty-free distribution of the report engine >>> for externally facing server and web deployment. >>> http://p.sf.net/sfu/businessobjects >>> _______________________________________________ >>> Playerstage-developers mailing list >>> Pla...@li... >>> https://lists.sourceforge.net/lists/listinfo/playerstage-developers >>> >> >> >> >> -- >> This email is intended for the addressee only and may contain privileged >> and/or confidential information >> > > > > -- > This email is intended for the addressee only and may contain privileged > and/or confidential information > |
From: Toby C. <tco...@pl...> - 2009-05-20 06:37:25
|
What behaviour are you seeing that needs corrected, with stage it should process the velocity commands fast enough that you only see the latest anyway. Any driver that talks directly to hardware on each message may have noticable delays, these obviously only want to send the latest. 2009/5/20 Paul Osmialowski <new...@ki...> > > > On Wed, 20 May 2009, Toby Collett wrote: > > > I think the issue here is that p2os needs to not replace by default > because > > the arm driver component needs to get every command. On the other hand > there > > is no need to queue incoming velocity commands as only the latest has > real > > meaning. > > > > The solution is to patch the p2os driver to set the position2d/cmd set of > > incoming messages to replace->true and then submit a patch if this > improves > > the behaviour you are seeing. > > > > Toby > > > Actually it involves more than just p2os driver: I have different robots > in my fleet: p2dx, roomba, create, and custom made robots with their own > plugin drivers, all of them provide position2d interface. We may think of > patching their drivers one by one, or adding new configuration option > (Geoff said its easy to do) or both. Worse question is how to achieve it > for Stages pioneer and roomba models? > > Paul > > > 2009/5/20 Toby Collett > > <tco...@pl... <tcollett%2Bp...@pl...>< > tcollett%2Bp...@pl... <tcollett%252...@pl...>> > >> > > > >> The rationale (right or wrong) for the current setup is that whether you > >> want to replace a command depends on the nature of the command not the > >> client. For the pioneer velocity control, we always want the latest as > >> applying a sequence of speed just ends up with the final speed. For > >> something like a draw line command to graphics2d you always want all of > the > >> commands as they all may specify different lines. > >> > >> Toby > >> > >> 2009/5/20 gbiggs <gb...@ki...> > >> > >> Making the queue length an option wouldn't be too hard (I just had a > >>> look), but I'm not sure that would solve your problem. It would just > >>> result in the message queue rapidly overflowing without suitable > >>> replacement rules set (the ability to set such rules on remote drivers > >>> is the actual issue, as I understand it - it's easy to do if the driver > >>> is on the same server). > >>> > >>> What you *probably* want is to be able to set replacement rules for a > >>> driver's InQueue in the config file. This would also be quite easy to > >>> do, I think. If I get time, maybe I'll give it a go today. > >>> > >>> Geoff > >>> > >>> Paul Osmialowski wrote: > >>>> Seems like I had wrong idea what playerc_client_set_replace_rule() > does > >>>> (I got wrong idea of "client queue on server" mentioned in client API > >>>> manual). Looks like the only way to avoid queueing of commands is to > >>>> rewrite a driver constructor, as I can see all drivers have queue > length > >>>> hardcoded. In my opinion, incoming queue lenght should be every driver > >>>> parameter (as 'alwayson' and 'provides'). If someone does not wan > >>> queueing > >>>> for given driver, it can be set to 1 in config file. > >>> > >>> > >>> > >>> > ------------------------------------------------------------------------------ > >>> Crystal Reports - New Free Runtime and 30 Day Trial > >>> Check out the new simplified licensing option that enables > >>> unlimited royalty-free distribution of the report engine > >>> for externally facing server and web deployment. > >>> http://p.sf.net/sfu/businessobjects > >>> _______________________________________________ > >>> Playerstage-developers mailing list > >>> Pla...@li... > >>> https://lists.sourceforge.net/lists/listinfo/playerstage-developers > >>> > >> > >> > >> > >> -- > >> This email is intended for the addressee only and may contain privileged > >> and/or confidential information > >> > > > > > > > > -- > > This email is intended for the addressee only and may contain privileged > > and/or confidential information > > > > > ------------------------------------------------------------------------------ > Crystal Reports - New Free Runtime and 30 Day Trial > Check out the new simplified licensing option that enables > unlimited royalty-free distribution of the report engine > for externally facing server and web deployment. > http://p.sf.net/sfu/businessobjects > _______________________________________________ > Playerstage-developers mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-developers > -- This email is intended for the addressee only and may contain privileged and/or confidential information |
From: Paul O. <new...@ki...> - 2009-05-20 07:23:23
|
On Wed, 20 May 2009, Toby Collett wrote: > What behaviour are you seeing that needs corrected, with stage it should > process the velocity commands fast enough that you only see the latest > anyway. Any driver that talks directly to hardware on each message may have > noticable delays, these obviously only want to send the latest. I can't say it in one phrase, but let's try. For some time I'm working on improving my GlobalGoto plugin (replacement for vfh that focuses on achieving goal not on obstacle avoidance). What I've observed is that it happens (mostly on heavy loaded machines) that robot already is on the target and is still moving because stop command is far in the queue, this in turn confuses all higher layers of my some other driver that relies on GlobalGoto functionality (however I'm working on making it more tollerant). Queue can grow rapidly, GlobalGoto is an open loop controller which works in read->think->act loop, each loop turn results in PutMsg to position2d interface. Since GlobalGoto is simple piece of code, it can call PutMsg much faster than Stage can process incoming commands (despite the fact, I'm putting nanosleep wherever I can). When robot is stopped, GlobalGoto repeats to send stop velocity command for some grace time (this ensures it will be processed at some point of time). If there's no queues on position2d, it would be easier to avoid the situation described. Paul > > 2009/5/20 Paul Osmialowski <new...@ki...> > >> >> >> On Wed, 20 May 2009, Toby Collett wrote: >> >>> I think the issue here is that p2os needs to not replace by default >> because >>> the arm driver component needs to get every command. On the other hand >> there >>> is no need to queue incoming velocity commands as only the latest has >> real >>> meaning. >>> >>> The solution is to patch the p2os driver to set the position2d/cmd set of >>> incoming messages to replace->true and then submit a patch if this >> improves >>> the behaviour you are seeing. >>> >>> Toby >>> >> Actually it involves more than just p2os driver: I have different robots >> in my fleet: p2dx, roomba, create, and custom made robots with their own >> plugin drivers, all of them provide position2d interface. We may think of >> patching their drivers one by one, or adding new configuration option >> (Geoff said its easy to do) or both. Worse question is how to achieve it >> for Stages pioneer and roomba models? >> >> Paul >> >>> 2009/5/20 Toby Collett >>> <tco...@pl... <tcollett%2Bp...@pl...>< >> tcollett%2Bp...@pl... <tcollett%252...@pl...>> >>>> >>> >>>> The rationale (right or wrong) for the current setup is that whether you >>>> want to replace a command depends on the nature of the command not the >>>> client. For the pioneer velocity control, we always want the latest as >>>> applying a sequence of speed just ends up with the final speed. For >>>> something like a draw line command to graphics2d you always want all of >> the >>>> commands as they all may specify different lines. >>>> >>>> Toby >>>> >>>> 2009/5/20 gbiggs <gb...@ki...> >>>> >>>> Making the queue length an option wouldn't be too hard (I just had a >>>>> look), but I'm not sure that would solve your problem. It would just >>>>> result in the message queue rapidly overflowing without suitable >>>>> replacement rules set (the ability to set such rules on remote drivers >>>>> is the actual issue, as I understand it - it's easy to do if the driver >>>>> is on the same server). >>>>> >>>>> What you *probably* want is to be able to set replacement rules for a >>>>> driver's InQueue in the config file. This would also be quite easy to >>>>> do, I think. If I get time, maybe I'll give it a go today. >>>>> >>>>> Geoff >>>>> >>>>> Paul Osmialowski wrote: >>>>>> Seems like I had wrong idea what playerc_client_set_replace_rule() >> does >>>>>> (I got wrong idea of "client queue on server" mentioned in client API >>>>>> manual). Looks like the only way to avoid queueing of commands is to >>>>>> rewrite a driver constructor, as I can see all drivers have queue >> length >>>>>> hardcoded. In my opinion, incoming queue lenght should be every driver >>>>>> parameter (as 'alwayson' and 'provides'). If someone does not wan >>>>> queueing >>>>>> for given driver, it can be set to 1 in config file. >>>>> >>>>> >>>>> >>>>> >> ------------------------------------------------------------------------------ >>>>> Crystal Reports - New Free Runtime and 30 Day Trial >>>>> Check out the new simplified licensing option that enables >>>>> unlimited royalty-free distribution of the report engine >>>>> for externally facing server and web deployment. >>>>> http://p.sf.net/sfu/businessobjects >>>>> _______________________________________________ >>>>> Playerstage-developers mailing list >>>>> Pla...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/playerstage-developers >>>>> >>>> >>>> >>>> >>>> -- >>>> This email is intended for the addressee only and may contain privileged >>>> and/or confidential information >>>> >>> >>> >>> >>> -- >>> This email is intended for the addressee only and may contain privileged >>> and/or confidential information >>> >> >> >> ------------------------------------------------------------------------------ >> Crystal Reports - New Free Runtime and 30 Day Trial >> Check out the new simplified licensing option that enables >> unlimited royalty-free distribution of the report engine >> for externally facing server and web deployment. >> http://p.sf.net/sfu/businessobjects >> _______________________________________________ >> Playerstage-developers mailing list >> Pla...@li... >> https://lists.sourceforge.net/lists/listinfo/playerstage-developers >> > > > > -- > This email is intended for the addressee only and may contain privileged > and/or confidential information > |
From: Paul O. <new...@ki...> - 2009-05-20 07:25:56
|
> Queue can grow rapidly, GlobalGoto is an open loop > controller which works in read->think->act loop, each loop turn results in I meant closed loop controller of course. Sorry, I'm not native English speaker, such mistakes happens to me. Paul |
From: Toby C. <tco...@pl...> - 2009-05-20 08:24:05
|
Okay, probably it is good to focus on this specific example for the moment, resolve that and then see if it is the same problem everywhere. A few more questions: 1) Is GlocalGoto threaded or non threaded 2) Is global goto running in the same server as stage in your tests. My understanding of the code (which is not always 100% correct, of course) is as follows. Stage runs unthreaded, which means it updates in the main server thread. In theory when the server calls update for stage it processes all the messages that were on the stage incoming queue at that time. Which means if there are three velocity commands is should process them one after the other, which *should* lead to only the most recent being seen in the next stage update step. Obviously with the behaviour you describe this is not what is happening. Which means either something is more complicated in your setup, or something in my understanding is wrong. I am sure we can get to the bottom of this. Toby 2009/5/20 Paul Osmialowski <new...@ki...> > > > > Queue can grow rapidly, GlobalGoto is an open loop > > controller which works in read->think->act loop, each loop turn results > in > I meant closed loop controller of course. Sorry, I'm not native English > speaker, such mistakes happens to me. > > Paul > > > ------------------------------------------------------------------------------ > Crystal Reports - New Free Runtime and 30 Day Trial > Check out the new simplified licensing option that enables > unlimited royalty-free distribution of the report engine > for externally facing server and web deployment. > http://p.sf.net/sfu/businessobjects > _______________________________________________ > Playerstage-developers mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-developers > -- This email is intended for the addressee only and may contain privileged and/or confidential information |
From: Paul O. <new...@ki...> - 2009-05-20 08:55:19
|
On Wed, 20 May 2009, Toby Collett wrote: > Okay, probably it is good to focus on this specific example for the moment, > resolve that and then see if it is the same problem everywhere. > > A few more questions: > 1) Is GlocalGoto threaded or non threaded It is threaded and designed for the new SVN-trunk API. > 2) Is global goto running in the same server as stage in your tests. Typically it is two different Player instances running in the same machine. However, I'm also using it in one Player instance together with Stage, and also on different Player instances running on different machines (also differently loaded). > > My understanding of the code (which is not always 100% correct, of course) > is as follows. Stage runs unthreaded, which means it updates in the main > server thread. In theory when the server calls update for stage it processes > all the messages that were on the stage incoming queue at that time. Which > means if there are three velocity commands is should process them one after > the other, which *should* lead to only the most recent being seen in the > next stage update step. What I'm worrying about is what happens (in Stage) when one command is processed and at the same time few new commands arrived. Are they queued? If the command processing is finished, which new command is going to be processed: the first from the queue or the most recent arrived? For me it would be good if only the most recently arrived is processed (it does not mean that it would be good solution for everyone else, therefore I've suggested to add new option to configuration file, however I don't know what impact it would make on Stage). > > Obviously with the behaviour you describe this is not what is happening. > Which means either something is more complicated in your setup, or something > in my understanding is wrong. I'll do more investigation about it. In my simulation I'm running five robots at a time (so there are seven Player instances running: one for Stage, and five more - started by shell script - each with wavefront and GlobalGoto; then one more instance is started with some complex team controller which subscribes and sends goal requests to those five instances running wavefront with GlobalGoto). The reason why wavefront with GlobalGoto are in separate UNIX processes is simple: wavefront performs much better for a group of robots when started that way. As a result, some robots go to the target properly (and stop there) while other robots stop too far from the target which confuses wavefront badly which affects higher layers of whole thing (I suspect that either stop command from GlobalGoto arrived too late or it was too far in the queue; first case is not so likely as robots are moving rather slow). One more detail: GlobalGoto passes through stop velocity commands from wavefront to underlying robot device - this also stops and cancels GlobalGoto routine until new position command is issued by wavefront. > > I am sure we can get to the bottom of this. > > Toby > I hope so Paul > 2009/5/20 Paul Osmialowski <new...@ki...> > >> >> >>> Queue can grow rapidly, GlobalGoto is an open loop >>> controller which works in read->think->act loop, each loop turn results >> in >> I meant closed loop controller of course. Sorry, I'm not native English >> speaker, such mistakes happens to me. >> >> Paul >> >> >> ------------------------------------------------------------------------------ >> Crystal Reports - New Free Runtime and 30 Day Trial >> Check out the new simplified licensing option that enables >> unlimited royalty-free distribution of the report engine >> for externally facing server and web deployment. >> http://p.sf.net/sfu/businessobjects >> _______________________________________________ >> Playerstage-developers mailing list >> Pla...@li... >> https://lists.sourceforge.net/lists/listinfo/playerstage-developers >> > > > > -- > This email is intended for the addressee only and may contain privileged > and/or confidential information > |
From: Toby C. <tco...@pl...> - 2009-05-20 09:09:40
|
Okay, I think probably the culprit is the remote tcp driver (as this thread sort of started with). On the stage end it processmessages in fifo order (so three travel forwards followed by a stop, will end up with a stopped robot). The remote driver has an incoming queue where it will store the commands and then forward them to the stage player server. I believe that remote driver uses a blocking write to the socket, so possibly this where your delays are coming from? Are you able to try a slightly different setup for testing purposes where all the globalgoto drivers are in the same player server as stage, and leave the wavefront drivers in their own server. This will get rid of anything between global goto and the stage driver. If this behaves better then it suggests RemoteDriver is definately the culprit. Also if global goto is just a proportinal controler, have you considered making in unthreaded. In this way it could only send a command to the underlying velocity device if it recieved a new position update, or a new target. This is a seperate change though and it should not be needed for normal operation. Toby 2009/5/20 Paul Osmialowski <new...@ki...> > > > On Wed, 20 May 2009, Toby Collett wrote: > > > Okay, probably it is good to focus on this specific example for the > moment, > > resolve that and then see if it is the same problem everywhere. > > > > A few more questions: > > 1) Is GlocalGoto threaded or non threaded > > It is threaded and designed for the new SVN-trunk API. > > > 2) Is global goto running in the same server as stage in your tests. > > Typically it is two different Player instances running in the same > machine. However, I'm also using it in one Player instance together with > Stage, and also on different Player instances running on different > machines (also differently loaded). > > > > My understanding of the code (which is not always 100% correct, of > course) > > is as follows. Stage runs unthreaded, which means it updates in the main > > server thread. In theory when the server calls update for stage it > processes > > all the messages that were on the stage incoming queue at that time. > Which > > means if there are three velocity commands is should process them one > after > > the other, which *should* lead to only the most recent being seen in the > > next stage update step. > What I'm worrying about is what happens (in Stage) when one command is > processed and at the same time few new commands arrived. Are they queued? > If the command processing is finished, which new command is going to be > processed: the first from the queue or the most recent arrived? For me it > would be good if only the most recently arrived is processed (it does not > mean that it would be good solution for everyone else, therefore I've > suggested to add new option to configuration file, however I don't know > what impact it would make on Stage). > > > > Obviously with the behaviour you describe this is not what is happening. > > Which means either something is more complicated in your setup, or > something > > in my understanding is wrong. > I'll do more investigation about it. In my simulation I'm running five > robots at a time (so there are seven Player instances running: one for > Stage, and five more - started by shell script - each with > wavefront and GlobalGoto; then one more instance is started with some > complex team controller which subscribes and sends goal requests to those > five instances running wavefront with GlobalGoto). The reason why > wavefront with GlobalGoto are in separate UNIX processes is simple: > wavefront performs much better for a group of robots when started that way. > > As a result, some robots go to the target properly (and stop there) while > other robots stop too far from the target which confuses wavefront > badly which affects higher layers of whole thing (I suspect that either > stop command from GlobalGoto arrived too late or it was too far in the > queue; first case is not so likely as robots are moving rather slow). One > more detail: GlobalGoto passes through stop velocity commands from > wavefront to underlying robot device - this also stops and cancels > GlobalGoto routine until new position command is issued by wavefront. > > > > > I am sure we can get to the bottom of this. > > > > Toby > > > > I hope so > Paul > > > 2009/5/20 Paul Osmialowski <new...@ki...> > > > >> > >> > >>> Queue can grow rapidly, GlobalGoto is an open loop > >>> controller which works in read->think->act loop, each loop turn results > >> in > >> I meant closed loop controller of course. Sorry, I'm not native English > >> speaker, such mistakes happens to me. > >> > >> Paul > >> > >> > >> > ------------------------------------------------------------------------------ > >> Crystal Reports - New Free Runtime and 30 Day Trial > >> Check out the new simplified licensing option that enables > >> unlimited royalty-free distribution of the report engine > >> for externally facing server and web deployment. > >> http://p.sf.net/sfu/businessobjects > >> _______________________________________________ > >> Playerstage-developers mailing list > >> Pla...@li... > >> https://lists.sourceforge.net/lists/listinfo/playerstage-developers > >> > > > > > > > > -- > > This email is intended for the addressee only and may contain privileged > > and/or confidential information > > > > > ------------------------------------------------------------------------------ > Crystal Reports - New Free Runtime and 30 Day Trial > Check out the new simplified licensing option that enables > unlimited royalty-free distribution of the report engine > for externally facing server and web deployment. > http://p.sf.net/sfu/businessobjects > _______________________________________________ > Playerstage-developers mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-developers > -- This email is intended for the addressee only and may contain privileged and/or confidential information |
From: Paul O. <new...@ki...> - 2009-05-20 17:12:47
|
On Wed, 20 May 2009, Toby Collett wrote: > > Are you able to try a slightly different setup for testing purposes where > all the globalgoto drivers are in the same player server as stage, and leave > the wavefront drivers in their own server. This will get rid of anything > between global goto and the stage driver. If this behaves better then it > suggests RemoteDriver is definately the culprit. I've did it. No change. See this image: http://vlab.pjwstk.edu.pl/~vlabdemo/stage-globalgoto-trials.gif trials shows that two robot approached their targets properly, one more is on its (good) way. We can also see that another one robot missed the target. Why only one robot, why that robot, that's a mistery for me. I've checked debug messages, wavefront didn't have any additional targets to go, looks like globalgoto didn't stop its routine when robot was at the target (although I've checked once more, it should keep on sending stop command for 1.5sec after target is achieved). Finally robot stopped and wavefront directed it to its proper target (it is not always that nice from wavefront side). > > Also if global goto is just a proportinal controler, have you considered > making in unthreaded. In this way it could only send a command to the > underlying velocity device if it recieved a new position update, or a new > target. This is a seperate change though and it should not be needed for > normal operation. > Good point. Main() method of globalgoto calls this->InQueue->Wait(), so it does not necessary need to run in separate thread. I'm thinking about reimplementing this. However I doubt it would be good if all message procerssing drivers will be running in one (server) thread - parallel processing is better in most cases. Paul (possibly two or more days break. I'm too busy now) > Toby > > 2009/5/20 Paul Osmialowski <new...@ki...> > >> >> >> On Wed, 20 May 2009, Toby Collett wrote: >> >>> Okay, probably it is good to focus on this specific example for the >> moment, >>> resolve that and then see if it is the same problem everywhere. >>> >>> A few more questions: >>> 1) Is GlocalGoto threaded or non threaded >> >> It is threaded and designed for the new SVN-trunk API. >> >>> 2) Is global goto running in the same server as stage in your tests. >> >> Typically it is two different Player instances running in the same >> machine. However, I'm also using it in one Player instance together with >> Stage, and also on different Player instances running on different >> machines (also differently loaded). >>> >>> My understanding of the code (which is not always 100% correct, of >> course) >>> is as follows. Stage runs unthreaded, which means it updates in the main >>> server thread. In theory when the server calls update for stage it >> processes >>> all the messages that were on the stage incoming queue at that time. >> Which >>> means if there are three velocity commands is should process them one >> after >>> the other, which *should* lead to only the most recent being seen in the >>> next stage update step. >> What I'm worrying about is what happens (in Stage) when one command is >> processed and at the same time few new commands arrived. Are they queued? >> If the command processing is finished, which new command is going to be >> processed: the first from the queue or the most recent arrived? For me it >> would be good if only the most recently arrived is processed (it does not >> mean that it would be good solution for everyone else, therefore I've >> suggested to add new option to configuration file, however I don't know >> what impact it would make on Stage). >>> >>> Obviously with the behaviour you describe this is not what is happening. >>> Which means either something is more complicated in your setup, or >> something >>> in my understanding is wrong. >> I'll do more investigation about it. In my simulation I'm running five >> robots at a time (so there are seven Player instances running: one for >> Stage, and five more - started by shell script - each with >> wavefront and GlobalGoto; then one more instance is started with some >> complex team controller which subscribes and sends goal requests to those >> five instances running wavefront with GlobalGoto). The reason why >> wavefront with GlobalGoto are in separate UNIX processes is simple: >> wavefront performs much better for a group of robots when started that way. >> >> As a result, some robots go to the target properly (and stop there) while >> other robots stop too far from the target which confuses wavefront >> badly which affects higher layers of whole thing (I suspect that either >> stop command from GlobalGoto arrived too late or it was too far in the >> queue; first case is not so likely as robots are moving rather slow). One >> more detail: GlobalGoto passes through stop velocity commands from >> wavefront to underlying robot device - this also stops and cancels >> GlobalGoto routine until new position command is issued by wavefront. >> >>> >>> I am sure we can get to the bottom of this. >>> >>> Toby >>> >> >> I hope so >> Paul >> >>> 2009/5/20 Paul Osmialowski <new...@ki...> >>> >>>> >>>> >>>>> Queue can grow rapidly, GlobalGoto is an open loop >>>>> controller which works in read->think->act loop, each loop turn results >>>> in >>>> I meant closed loop controller of course. Sorry, I'm not native English >>>> speaker, such mistakes happens to me. >>>> >>>> Paul >>>> >>>> >>>> >> ------------------------------------------------------------------------------ >>>> Crystal Reports - New Free Runtime and 30 Day Trial >>>> Check out the new simplified licensing option that enables >>>> unlimited royalty-free distribution of the report engine >>>> for externally facing server and web deployment. >>>> http://p.sf.net/sfu/businessobjects >>>> _______________________________________________ >>>> Playerstage-developers mailing list >>>> Pla...@li... >>>> https://lists.sourceforge.net/lists/listinfo/playerstage-developers >>>> >>> >>> >>> >>> -- >>> This email is intended for the addressee only and may contain privileged >>> and/or confidential information >>> >> >> >> ------------------------------------------------------------------------------ >> Crystal Reports - New Free Runtime and 30 Day Trial >> Check out the new simplified licensing option that enables >> unlimited royalty-free distribution of the report engine >> for externally facing server and web deployment. >> http://p.sf.net/sfu/businessobjects >> _______________________________________________ >> Playerstage-developers mailing list >> Pla...@li... >> https://lists.sourceforge.net/lists/listinfo/playerstage-developers >> > > > > -- > This email is intended for the addressee only and may contain privileged > and/or confidential information > |
From: Paul O. <new...@ki...> - 2009-05-22 12:57:08
|
On Wed, 20 May 2009, Toby Collett wrote: > Also if global goto is just a proportinal controler, have you considered > making in unthreaded. In this way it could only send a command to the > underlying velocity device if it recieved a new position update, or a new > target. This is a seperate change though and it should not be needed for > normal operation. > > Toby > Hi Toby, It's amazing, doing GlobalGoto unthreaded driver solved my problem, at least during all the test I did at my (slow) home PC. Soon I'll try how it behaves on my killer high-end PC at work (for test completeness). New (unthreaded) version of globalgoto (now called globalgoto2) is here: http://king.net.pl/playercontrib/plugins/player2.2/globalgoto2-20090522.tar.gz Since it is not threaded driver, I suspect it can also be compiled with Player-2.1.x. Still I'm not convinced that this is the best way of solving communication problems. If we make all message-driven drivers unthreaded (see cameracompress and other heavy computing things), whole Player server will suffer from huge slowdown. Paul |