From: Jaime V. M. <jai...@en...> - 2004-09-28 07:27:26
|
(Using player 1.5, c++ client lib 1.5). Hi, 1) With "int SetFrequency(unsigned short freq)" you can change the rate at which your client receives data from the server. If I set it faster than the slower sensor (laser), I simply use old data from the sensor. Is that right? 2) Does PlayerClient.Read() block on reading from server? i.e. if I do a Read(), does it wait until it has received a whole NEW data set (SYNC packet) from server, which is then made available to sensor proxies? or if the freq. is faster than client is receiving new data, it simply provides OLD data to proxies? or ...? 3) Also, if I don't set them in my client, what are the default params for comm's values such as Freq, or txfer data mode (PLAYER_DATAMODE_PUSH_ALL, PLAYER_DATAMODE_PULL_ALL , etc), etc ...? 4) < ...this will be the new rate at which your client receives data (when in continuous mode)...> Is "continuous mode" set with PLAYER_DATAMODE_PUSH_ALL ? Thanks Jaime P.S. In case it matters: I got a C++ player client reading laser and odometry from a Pioneer, plus a stereo-headset collecting 3D data, all embedded into one client. |
From: Brian G. <ge...@ai...> - 2004-09-28 14:33:58
|
On Tue, 28 Sep 2004, Jaime Valls Miro wrote: > (Using player 1.5, c++ client lib 1.5). > > 1) With "int SetFrequency(unsigned short freq)" you can change the rate at which your client > receives data from the server. If I set it faster than the slower sensor (laser), I simply use old > data from the sensor. Is that right? Essentially, yes. Assuming that you're using the default data delivery mode (PUSH_NEW), then the server never repeats any data. So if you set it faster than the rate at which a given device produces data, then you will not get new data for that device as a result of each Read(). You can determine whether you got new data by caching and comparing against the data timestamp: http://sourceforge.net/mailarchive/message.php?msg_id=9596069 > 2) Does PlayerClient.Read() block on reading from server? Yes. > i.e. if I do a Read(), does it wait until > it has received a whole NEW data set (SYNC packet) from server, which is then made available to > sensor proxies? Yes, it blocks until receipt of a SYNC packet. > or if the freq. is faster than client is receiving new data, it simply provides OLD > data to proxies? or ...? As explained above, you may not receive new data for every device in every round. In that case, the proxy is not updated, so it still contains the old data. > 3) Also, if I don't set them in my client, what are the default params for comm's values such as > Freq, or txfer data mode (PLAYER_DATAMODE_PUSH_ALL, PLAYER_DATAMODE_PULL_ALL , etc), etc ...? The default mode is PUSH_NEW and the frequency is 10Hz. > 4) < ...this will be the new rate at which your client receives data (when in continuous mode)...> > Is "continuous mode" set with PLAYER_DATAMODE_PUSH_ALL ? "continuous" refers to either of the PUSH modes, as opposed to "request/reply", which refers to either of the PULL modes. brian. -- Brian P. Gerkey ge...@ai... Stanford AI Lab http://ai.stanford.edu/~gerkey |
From: Jaime V. M. <jai...@en...> - 2004-09-29 06:34:52
|
Hi Brian, Thanks for your reply. Very helpful. A couple of thoughts derived from your responses and some further reading of Player: Brian Gerkey wrote: > On Tue, 28 Sep 2004, Jaime Valls Miro wrote: > > > (Using player 1.5, c++ client lib 1.5). > > > > 1) With "int SetFrequency(unsigned short freq)" you can change the rate at which your client > > receives data from the server. If I set it faster than the slower sensor (laser), I simply use old > > data from the sensor. Is that right? > > Essentially, yes. Assuming that you're using the default data delivery > mode (PUSH_NEW), then the server never repeats any data. So if you > set it faster than the rate at which a given device produces data, then > you will not get new data for that device as a result of each Read(). > You can determine whether you got new data by caching and comparing > against the data timestamp: > > http://sourceforge.net/mailarchive/message.php?msg_id=9596069 > > > 2) Does PlayerClient.Read() block on reading from server? > > Yes. > If it blocks, I'd expect to see new data at some point in my client independently of the PlayerClient.Rate() I set. Yet I am seeing empty data clients (odometry from pioneer) when Rate is set somewhat fast (30 or 40Hz+), and is not blocking as the loop is constantly executed. Think of: while(1) { ... do some other stuff (slowish btw) ... read() buffer_client_data() ... } write_buffered_data_to_file With slow freqs (<5Hz) I see meaningful data, all ok. Otherwise, data is just all 0's. I'd expect to see some client data values at some point, repeated in between blocking Read()'s as they might not have been filled with new data due to the high Rate(). I guess where I am going is that if Rate() is higher than the physical system (and player) can provide data to PlayerClient()'s, if it is blocking I would expect to not stick to that rate and probably provide data at a slower rate. But what I am seeing is my while(1){...} code executed at the same rate, only no data is being provided to Client proxies. > > > i.e. if I do a Read(), does it wait until > > it has received a whole NEW data set (SYNC packet) from server, which is then made available to > > sensor proxies? > > Yes, it blocks until receipt of a SYNC packet. > > > or if the freq. is faster than client is receiving new data, it simply provides OLD > > data to proxies? or ...? > > As explained above, you may not receive new data for every device in every > round. In that case, the proxy is not updated, so it still contains the > old data. > in C++ client lib, since the "state" of the class is defined by the latest data ((odom) xpos, ypos, etc, (laser) scan[], etc ...), isn't PUSH_ALL redundant? I mean, with PUSH_NEW, after a Read() you always have available to your client proxy either the latest data just received, or you still have some older one from a previous Read(). Which is the same data PUSH_ALL would provide. Unless I am missing something, they do the same (in C++ client lib which is the one I am getting familiar, don't know about others), and saves data exchanged and bandwith. Ta Jaime |
From: Brian G. <ge...@ai...> - 2004-09-29 18:00:22
|
On Wed, 29 Sep 2004, Jaime Valls Miro wrote: > in C++ client lib, since the "state" of the class is defined by the latest data ((odom) xpos, ypos, etc, > (laser) scan[], etc ...), isn't PUSH_ALL redundant? I mean, with PUSH_NEW, after a Read() you always > have available to your client proxy either the latest data just received, or you still have some older > one from a previous Read(). Which is the same data PUSH_ALL would provide. Unless I am missing > something, they do the same (in C++ client lib which is the one I am getting familiar, don't know about > others), and saves data exchanged and bandwith. PUSH_ALL isn't redundant; it's just inefficient. PUSH_ALL sends all current data, whether it's new or not (by "new" I mean your client hasn't yet receied it) at the requested rate. PUSH_NEW only sends new data. So, if your client lib caches the latest data (like the C++ client lib does in its proxies), then the modes look the same to the client program. But under the hood, PUSH_ALL is unnecessarily sending a lot of repeated data on the socket, which can be a significant drag, especially in a noisy wireless environment. The only reason to use PUSH_ALL is if your client lib doesn't cache old data in proxies, but pretty much all client libs do this. brian. -- Brian P. Gerkey ge...@ai... Stanford AI Lab http://ai.stanford.edu/~gerkey |
From: Reed H. <re...@ac...> - 2004-09-29 19:02:35
|
Brian Gerkey wrote: > The only reason to use PUSH_ALL is if your > client lib doesn't cache old data in proxies, but pretty much all client > libs do this. Or, also in the currently-theoretical realm, the network transport is not reliable. Reed |
From: Jaime V. M. <jai...@en...> - 2004-09-29 07:11:50
|
Hi Brian, Actually, further to the email I sent not long ago, I run some more tests and sort of answered my own first question: > > > (Using player 1.5, c++ client lib 1.5). > > > > > > 1) With "int SetFrequency(unsigned short freq)" you can change the rate at which your client > > > receives data from the server. If I set it faster than the slower sensor (laser), I simply use old > > > data from the sensor. Is that right? > > > > Essentially, yes. Assuming that you're using the default data delivery > > mode (PUSH_NEW), then the server never repeats any data. So if you > > set it faster than the rate at which a given device produces data, then > > you will not get new data for that device as a result of each Read(). > > You can determine whether you got new data by caching and comparing > > against the data timestamp: > > > > http://sourceforge.net/mailarchive/message.php?msg_id=9596069 > > > > > 2) Does PlayerClient.Read() block on reading from server? > > > > Yes. > > > > If it blocks, I'd expect to see new data at some point in my client independently of the > PlayerClient.Rate() I set. Yet I am seeing empty data clients (odometry from pioneer) when Rate is set > somewhat fast (30 or 40Hz+), and is not blocking as the loop is constantly executed. Think of: > > while(1) > { > ... > do some other stuff (slowish btw) > ... > read() > buffer_client_data() > ... > } > write_buffered_data_to_file > > With slow freqs (<5Hz) I see meaningful data, all ok. Otherwise, data is just all 0's. I'd expect to see > some client data values at some point, repeated in between blocking Read()'s as they might not have been > filled with new data due to the high Rate(). > I guess where I am going is that if Rate() is higher than the physical system (and player) can provide > data to PlayerClient()'s, if it is blocking I would expect to not stick to that rate and probably > provide data at a slower rate. But what I am seeing is my while(1){...} code executed at the same rate, > only no data is being provided to Client proxies. > I am actually seeing exactly what I described above as what I should see: if Rate() is high, Read() returns at some points because player server will eventually send the Sync packet in trying to keep up with the Rate() demanded, only there will be no new data, and therefore I see the same (old) data values stored in my device proxies. Also, player will do its best to keep up with the demanded Rate(), althought that can not be guaranteed if is set higher than physically possible when accounting for any other processing the client might be doing in in the loop. It makes sense. I guess the lesson is that PLAYER_DATAMODE_PUSH_NEW will "try" and provide new data, if there is any, which will very much depend on the Rate() you set, but in trying to stick to the Rate() demanded of it by the PlayerClient, it will move on (and send a SYNC) if no data is availble. These are my findings, thought I'd share them, in case somebody is scratching the head over the same issues. I've seen some posting related player and timing issues lately. Ta Jaime |
From: Brian G. <ge...@ai...> - 2004-09-29 18:44:25
|
On Wed, 29 Sep 2004, Jaime Valls Miro wrote: > I am actually seeing exactly what I described above as what I should see: if Rate() is high, Read() returns > at some points because player server will eventually send the Sync packet in trying to keep up with the > Rate() demanded, only there will be no new data, and therefore I see the same (old) data values stored in my > device proxies. Also, player will do its best to keep up with the demanded Rate(), althought that can not be > guaranteed if is set higher than physically possible when accounting for any other processing the client > might be doing in in the loop. It makes sense. > I guess the lesson is that PLAYER_DATAMODE_PUSH_NEW will "try" and provide new data, if there is any, which > will very much depend on the Rate() you set, but in trying to stick to the Rate() demanded of it by the > PlayerClient, it will move on (and send a SYNC) if no data is availble. > These are my findings, thought I'd share them, in case somebody is scratching the head over the same issues. > I've seen some posting related player and timing issues lately. That's pretty much correct, although I want to clarify one thing. Player, the server, will "try" to deliver data at the requested rate, and it is not guaranteed to acheive the rate. But the reason that it might not achieve that rate is not related to your client. Player won't necessarily achieve a high data rate because of timer limitations in the OS. For example, in Linux 2.4, the shortest possible sleep time is 10ms, so Player can't deliver data faster than 100Hz. If your client does a lot of processing, or is otherwise slow to read data from the server, that's BAD. Data will back up on the socket, filling the send and receive buffers, and at some point Player will start complaining on the console about "leftover bytes". Player handles the socket properly, so that you won't get any malformed packets, but your client will potentially have to wade through a lot of stale data before getting new data. If this happens in a loop that is controlling a robot, the result will almost certainly be the robot running into a wall. You *must* keep up with the server's data rate. If your client runs aperiodically, then try the PULL_NEW mode, in which you request a round data when you're ready to process it. You may miss intervening data, but no data will backup on the socket. As a postcript to all this, I recently rewrote the main loop of the server in such a way that it can deliver data (nearly) arbitrarily fast, independent of OS timer limitations. It's in CVS now and will be in the next release. brian. -- Brian P. Gerkey ge...@ai... Stanford AI Lab http://ai.stanford.edu/~gerkey |
From: Jaime V. M. <jai...@en...> - 2004-09-30 01:14:05
|
Hi Brian Reading your posting has made me realised of a fundamental concept which I did not quite grasp from reading the documentation of Player. Pls confirm if I am right: "int SetFrequency(unsigned short freq) You can change the rate at which your client receives data from the server with this method." PLUS SetFrequency() is ALSO the rate at which Player reads data from the physical devices. I had assumed the frequency at which data is read from devices into buffers was dictated by the capabilities of the device, not SetFrequency(), and SetFrequency() would only relate Player<->PLayerClient and Proxies. That will explain what your posting highlights, and why PlayerClient.Read() at high frequencies will provide the backlog of data from the buffers that I am seeing. Experiments are certainly backing up this explanation. If I am correct I promise I'll conclude this thread once and for all ;-) Many ta's for your help. Jaime Brian Gerkey wrote: > On Wed, 29 Sep 2004, Jaime Valls Miro wrote: > > > I am actually seeing exactly what I described above as what I should see: if Rate() is high, Read() returns > > at some points because player server will eventually send the Sync packet in trying to keep up with the > > Rate() demanded, only there will be no new data, and therefore I see the same (old) data values stored in my > > device proxies. Also, player will do its best to keep up with the demanded Rate(), althought that can not be > > guaranteed if is set higher than physically possible when accounting for any other processing the client > > might be doing in in the loop. It makes sense. > > I guess the lesson is that PLAYER_DATAMODE_PUSH_NEW will "try" and provide new data, if there is any, which > > will very much depend on the Rate() you set, but in trying to stick to the Rate() demanded of it by the > > PlayerClient, it will move on (and send a SYNC) if no data is availble. > > These are my findings, thought I'd share them, in case somebody is scratching the head over the same issues. > > I've seen some posting related player and timing issues lately. > > That's pretty much correct, although I want to clarify one thing. > Player, the server, will "try" to deliver data at the requested rate, > and it is not guaranteed to acheive the rate. But the reason that it > might not achieve that rate is not related to your client. Player won't > necessarily achieve a high data rate because of timer limitations in > the OS. For example, in Linux 2.4, the shortest possible sleep time is > 10ms, so Player can't deliver data faster than 100Hz. > > If your client does a lot of processing, or is otherwise slow to read > data from the server, that's BAD. Data will back up on the socket, > filling the send and receive buffers, and at some point Player will start > complaining on the console about "leftover bytes". Player handles the > socket properly, so that you won't get any malformed packets, but your > client will potentially have to wade through a lot of stale data before > getting new data. If this happens in a loop that is controlling a robot, > the result will almost certainly be the robot running into a wall. > > You *must* keep up with the server's data rate. If your client runs > aperiodically, then try the PULL_NEW mode, in which you request a round > data when you're ready to process it. You may miss intervening data, but > no data will backup on the socket. > > As a postcript to all this, I recently rewrote the main loop of the > server in such a way that it can deliver data (nearly) arbitrarily fast, > independent of OS timer limitations. It's in CVS now and will be > in the next release. > > brian. > > -- > Brian P. Gerkey ge...@ai... > Stanford AI Lab http://ai.stanford.edu/~gerkey > > ------------------------------------------------------- > This SF.net email is sponsored by: IT Product Guide on ITManagersJournal > Use IT products in your business? Tell us what you think of them. Give us > Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more > http://productguide.itmanagersjournal.com/guidepromo.tmpl > _______________________________________________ > Playerstage-users mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-users |
From: Brian G. <ge...@ai...> - 2004-09-30 04:11:05
|
On Thu, 30 Sep 2004, Jaime Valls Miro wrote: > Reading your posting has made me realised of a fundamental concept which I did not quite grasp from reading the > documentation of Player. Pls confirm if I am right: > "int SetFrequency(unsigned short freq) > You can change the rate at which your client receives data from the server with this method." Right. > PLUS SetFrequency() is ALSO the rate at which Player reads data from the physical devices. Wrong. > I had assumed the frequency at which data is read from devices into buffers was dictated by the capabilities of > the device, not SetFrequency(), and SetFrequency() would only relate Player<->PLayerClient and Proxies. Exactly right. > That will explain what your posting highlights, and why PlayerClient.Read() at high frequencies will provide the > backlog of data from the buffers that I am seeing. Experiments are certainly backing up this explanation. Sorry if I gave you the wrong idea. All I meant to say is that you need to call Read() at least as fast as the rate you requested via SetFrequency(). The server is delivering data at the fixed, requested rate, so if you Read() slower, then data is coming down the socket faster than you're consuming it, so it will start to back up. brian. -- Brian P. Gerkey ge...@ai... Stanford AI Lab http://ai.stanford.edu/~gerkey |