From: brian g. <ge...@ro...> - 2003-08-15 17:02:27
|
hi, On Thu, 14 Aug 2003 yye...@ds... wrote: > I am currently using Player version 1.3.2 and Stage version 1.3. I have the > following questions: > 1. I need to run a batch job in Player. Also I want to be able to stop one run > and start the next run from within my source code. See below for an example of > Currently, my Reset() function looks like this > void Reset(PositionProxy* pPose, TruthProxy* pTruth){ > //stop the robot > pPose->SetSpeed(0,0); > > //reset the robot > pPose->ResetOdometry(); > > //'teleport' the robot to its starting position of [1,0,0] > pTruth->SetPose(1,0,0); > } > However, it does not seem to work. So how should I go about implementing the > Reset() function? What do you mean that it doesn't work? What happens or doesn't happen? An alternative method to run batch jobs is to write a script that starts and stops Stage and your client program(s) accordingly. I know that many people (including myself) have done this. You can get arbitrarily fancy with such a script, for example adding a cron job that periodically restarts your batch in case it died for some reason. > > 2. For 2 consecutive runs in batch mode, is it possible for the behaviour of > the robot to be different across runs, even though the decision logic is the > same (i.e. the simulation results are non-determinstic)? If yes, what are the > possible causes of this phenomenon? > Since the simulator runs in a separate process, decoupled from the control program, it is certainly possible that you could get different results in consecutive runs because of subtle timing and load conditions. If this is a problem for you, you could try slowing down the simulator; I haven't thought it through, but I think that that would help. > 3. What is the default data sending mode in the PlayerClient class? (note:The 4 > possible modes are > PLAYER_DATAMODE_PUSH_ALL,PLAYER_DATAMODE_PULL_ALL,PLAYER_DATAMODE_PUSH_NEW, > PLAYER_DATAMODE_PULL_NEW) > Under what circumstances should I use the other data sending modes? > The default is PLAYER_DATAMODE_PUSH_NEW, which periodically sends only new sensor data (remember that you can change the frequency). It's a nice combination of ease of use and efficiency; almost everyone should use it. The only use of PLAYER_DATAMODE_PUSH_ALL is for a client application that doesn't cache previous sensor data, but instead processes all data in place. In such a case, the client might want to receive all sensor data in each frame, even if some is repeated. You should use the PULL modes when your client runs very slowly and/or aperiodically, such that data might back up on the socket if the PUSH modes were used. > 4. Assume that I have the following definition in my .world file > define myRobot position(player() laser() truth()) > When I set the 'pose' attribute for myRobot e.g. > myRobot(name "robot1" port 6665 pose[1 1 0]) > am I setting the x, y, theta values of the truth device to 1,1,0 respectively > as well? > That certainly should be the case. Have you found otherwise? brian. |