Hi Ye Chuan:
Some general responses to your questions:
1) Player's default PUSH mode will write data at a more-or-less constant
rate, and it is the client's reponsibility to keep up. You really cant
afford to go away for a few seconds to think about things, then come back
and read new data. There are two problems: 1. the data is queued (by the
TCP stack) so the data you read may be several seconds out-of-date, and 2.
if the server writes faster than the client reads, the TCP queues will
overflow and you will get corrupt data.
If you have a slow decision-making process, you might want to consider
running this in a separate thread while the main thread is reading data
from the server. You will still have to consider that your decisions may
be out-of-date by the time you make them, of course. One trick I use is
to stop the robot when this happens, to let the processing thread catch
2) When controlling multiple robots from a single client, you have two
choices: 1. run a single thread per client (I dont recommend this), or 2.
use one of the multi-client libraries (not well documented,
unfortunately). The mult-client libraries use the poll() statement for
monitoring multiple sockets, which is the "correct" way to do this in
3) The answer to your question 3 is: yes :-)
On Sat, 28 Feb 2004 yyechuan@... wrote:
> 1. I noticed that Stage will continue executing the last action received from
> Player if it does not receive new ones (please correct me if i'm wrong). So if
> my MakeDecisionForAll() function takes a relatively long time (e.g. 1-2 secs
> real time) to compute the next set of actions as compared to Stage's cycle (0.1
> sec), my control program will be out-of-sync with Stage i.e. the robots will
> have moved further than requested. Besides making -v (for Stage) very small so
> that the 'extra' distance covered is small, are there any other methods to
> resolve this issue? Also, should I use the 'PULL_NEW' mode of reading here
> instead of the default 'PUSH_NEW'?
> 2. I also noticed that by increasing -u for Stage, the time needed to complete
> a Read() in 'PULL_NEW' mode also increases. Is that supposed to be the case? If
> yes, why is it so?
> 3. In my case, I' m using 1 process to control all 4 robots (a centralized
> approach). Will there be any difference if I adopt a distributed approach i.e.
> 1 control process per robot, each with its own sense, think, act cycle? Which
> approach is preferred to ensure better synchronisation between Player and Stage?
> Thanks and rgds,
> Ye Chuan
Andrew Howard email: ahoward@...
Department of Computer Science http: www-robotics.usc.edu/~ahoward
University of Southern California phone: 1 (213) 740 6416
Los Angeles, CA, U.S.A. 90089-0781 fax: 1 (213) 821 5696
<< Insert pithy saying here >>>