From: Petter F. <pet...@ho...> - 2013-04-12 14:03:36
|
Hello I have been working for quite a long time now on a problem but with no success and I am getting a bit desperate.I hope there is someone on this list that could help me, I would be very grateful. I am trying to run the simulation with odometry/lasers at 50Hz and I have changed the following settings: interval_sim 20interval_real 20 #this one seems to no longer be usedupdate_interval 20 However the result is that I get a update frequency that varies between 40-100ms Am I missing something? I would be very grateful for your help. Best Regards --------------------------- Petter Forsberg |
From: Richard V. <va...@sf...> - 2013-04-12 16:34:58
|
Hi, You just need to set interval_sim 20 in Stage's worldfile and Stage will run the simulation with 50 steps per second and attempt to do this in real time. I just confirmed that this works for me with standalone Stage (i.e. without Player). If you want Stage to try to run faster than real time, do this in the top level of your worldfile: speedup X where X is the multiple of real time you want, or -1 to go as fast as it can. Can anyone with recent experience running Player/Stage at high frequencies comment on whether any Player configuration is needed? - rtv On Fri, Apr 12, 2013 at 7:03 AM, Petter Forsberg <pet...@ho...> wrote: > Hello > > I have been working for quite a long time now on a problem but with no > success and I am getting a bit desperate. > I hope there is someone on this list that could help me, I would be very > grateful. > > I am trying to run the simulation with odometry/lasers at 50Hz and I have > changed the following settings: > > interval_sim 20 > interval_real 20 #this one seems to no longer be used > update_interval 20 > > However the result is that I get a update frequency that varies between > 40-100ms > > Am I missing something? I would be very grateful for your help. > > Best Regards > > --------------------------- > Petter Forsberg > > ------------------------------------------------------------------------------ > Precog is a next-generation analytics platform capable of advanced > analytics on semi-structured data. The platform includes APIs for building > apps and a phenomenal toolset for data science. Developers can use > our toolset for easy data analysis & visualization. Get a free account! > http://www2.precog.com/precogplatform/slashdotnewsletter > _______________________________________________ > Playerstage-developers mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-developers > |
From: Rich M. <jp...@gm...> - 2013-04-13 00:00:24
|
On 04/12/2013 12:26 PM, Richard Vaughan wrote: > Hi, > > You just need to set > > interval_sim 20 > > in Stage's worldfile and Stage will run the simulation with 50 steps > per second and attempt to do this in real time. I just confirmed that > this works for me with standalone Stage (i.e. without Player). > > If you want Stage to try to run faster than real time, do this in the > top level of your worldfile: > > speedup X > > where X is the multiple of real time you want, or -1 to go as fast as it can. > > Can anyone with recent experience running Player/Stage at high > frequencies comment on whether any Player configuration is needed? > > - rtv > > > The Player interface should be able to keep up, but Stage's Player interface publishes data at a fixed rate, regardless of the step size or speedup. There was a thread on playerstage-users a little while ago about this: http://player-stage-gazebo.10965.n7.nabble.com/Update-rate-of-player-3-1-0-and-PUSH-PULL-td2960.html Rich |
From: Richard V. <rt...@au...> - 2013-04-13 00:32:19
|
I should fix this. — Sent from a mobile gadget On Fri, Apr 12, 2013 at 5:00 PM, Rich Mattes <jp...@gm...> wrote: > On 04/12/2013 12:26 PM, Richard Vaughan wrote: >> Hi, >> >> You just need to set >> >> interval_sim 20 >> >> in Stage's worldfile and Stage will run the simulation with 50 steps >> per second and attempt to do this in real time. I just confirmed that >> this works for me with standalone Stage (i.e. without Player). >> >> If you want Stage to try to run faster than real time, do this in the >> top level of your worldfile: >> >> speedup X >> >> where X is the multiple of real time you want, or -1 to go as fast as it can. >> >> Can anyone with recent experience running Player/Stage at high >> frequencies comment on whether any Player configuration is needed? >> >> - rtv >> >> >> > The Player interface should be able to keep up, but Stage's Player > interface publishes data at a fixed rate, regardless of the step size or > speedup. There was a thread on playerstage-users a little while ago > about this: > http://player-stage-gazebo.10965.n7.nabble.com/Update-rate-of-player-3-1-0-and-PUSH-PULL-td2960.html > Rich > ------------------------------------------------------------------------------ > Precog is a next-generation analytics platform capable of advanced > analytics on semi-structured data. The platform includes APIs for building > apps and a phenomenal toolset for data science. Developers can use > our toolset for easy data analysis & visualization. Get a free account! > http://www2.precog.com/precogplatform/slashdotnewsletter > _______________________________________________ > Playerstage-developers mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-developers |
From: Rich M. <jp...@gm...> - 2013-04-21 17:20:50
|
On 04/18/2013 08:13 AM, ulle wrote: > Hi > > I don't think the client buffer is overflowing since I have to wait for > Read() to execute. I tried to set the replace rules for all my proxies (i.e. > myRangerProxy.SetReplaceRule(true, -1, -1) ) but I see no change. > I have tried to use the ReadIfWaiting() function, but I only obtain the same > messages a hundred times or so before a new message is available. > Ok, good clarification regarding the log file, thanks. > > Just to make sure I got the repos right. I use > https://playerstage.svn.sourceforge.net/svnroot/playerstage/code/player/trunk > https://github.com/rtv/Stage.git > https://github.com/pauldreik/Stage.git (Some updated bumper functionalities > by Paul Dreik, a former coworker) > > Have any of you out there succeeded in obtaining measurements at around > 100Hz or faster? > > Regards, > Ulrik > I tried to reproduce your results using simple.{cfg,world}, trying to decipher from previous emails which settings were being used, and using the latest git master of Stage and svn trunk of Player. It looks like when I set Stage's interval_sim to 10 and the pioneer model's update_interval to 10, I do see dropouts in position2d timestamps received by the Position2dProxy using the sample program at the bottom of this mail. If I add client.SetDataMode(PLAYER_DATAMODE_PUSH), the dropouts go away. The difference between the two modes is explained in [1]. I was also able to set the speedup flag to -1 in the world file, and still didn't see dropouts from my sample program with Stage's realtime factor hovering around 3.5. Rich [1] http://playerstage.sourceforge.net/doc/Player-svn/player/group__libplayerc__datamodes.html Sample program: #include <libplayerc++/playerc++.h> using namespace PlayerCc; int main (int argc, char *argv[]) { PlayerClient robot("localhost", 6665); Position2dProxy pp(&robot, 0); // Setting the datamode to PUSH gets rid of dropouts robot.SetDataMode(PLAYER_DATAMODE_PUSH); while(!pp.IsValid()){ robot.Read(); } for(;;) { robot.ReadIfWaiting(); if (pp.IsFresh()) { pp.NotFresh(); std::cout << pp.GetDataTime() << ", " << robot.GetOverflowCount() << std::endl; } } } |
From: ulle <ulr...@et...> - 2013-04-23 08:15:12
|
The push mode did the trick! Thank you, Rich. I really appreciate it. I use Read() instead of ReadIfWaiting(). Using the latter it reads the same data like crazy before getting fresh data while Read() is called four or five times in my case before fresh data is available. I guess ReadIfWaiting() should read if there is a message in the queue, but I get the same data over and over again. Do I need to somehow remove data from the server after I have read it? Thanks again, /U -- View this message in context: http://player-stage-gazebo.10965.n7.nabble.com/Running-simulation-10Hz-tp18646p18706.html Sent from the playerstage-developers mailing list archive at Nabble.com. |
From: Rich M. <jp...@gm...> - 2013-04-23 21:10:25
|
On Tue, Apr 23, 2013 at 4:15 AM, ulle <ulr...@et...> wrote: > The push mode did the trick! > Thank you, Rich. I really appreciate it. > > I use Read() instead of ReadIfWaiting(). Using the latter it reads the same > data like crazy before getting fresh data while Read() is called four or > five times in my case before fresh data is available. I guess > ReadIfWaiting() should read if there is a message in the queue, but I get > the same data over and over again. Do I need to somehow remove data from > the > server after I have read it? > > Thanks again, > /U > > ReadIfWaiting() is a non-blocking read; it checks to see if the client has received any new information from the server since the last read. If it hasn't, the call comes back without doing anything. Read() blocks until at least one message is read from the Player server. You don't constantly receive the same data over again; you can think of the client libraries as buffers. Each client proxy stores the data from the latest message it has received from the Player server. Calls to Read() don't necessarily update every client proxy, as your client may not have received a new message since the last call to Read(). So those clients will continue to store the same data after a call to Read(). One way to check if a particular client proxy got a new message is by using the IsFresh()/NotFresh() set of calls in the PlayerC++ library. Each time that Read() *does* update a particular client, it sets that client's "Fresh" flag to true. After a call to read, you can check each of your proxies for the Fresh flag to see if there has been an update. Then you can call NotFresh() to reset the fresh flag and signify that the data is stale/you've already done something with it. The example program I sent in this thread uses this method to only print each message's timestamp once. Rich |
From: Rich M. <jp...@gm...> - 2013-04-18 00:52:54
|
On 04/17/2013 10:44 AM, ulle wrote: > Hi again > > I tried the writelog thing, and the data stored in the log file has updated > at 100Hz. But the data my client program obtains is only a small fraction of > that. > I measured the time my client program takes to wait for the data compared to > how long it takes to execute other stuff in my loop. My code takes usually > less than 1ms while the Read() function takes 50-300ms. Ok, so all of the messages are showing up in the log, meaning Player is at least getting all of them. However, the blocking behavior you see at the PlayerClient is troubling. Read() shouldn't take very long if there's a lot of data present, unless you're overflowing the client's buffers and getting out of whack. You might try setting the replace rule [1] for position2d or ranger messages so you're guaranteed not to overflow your message queue on the Player server. It may still result in dropped messages, but could help with Read(). You can also try ReadIfWaiting(), which is supposed to be non-blocking. > I provide a text file with a few debug outputs for three loops that include > elapsed time, odo and ranger data. Then the log data follows where I have > marked those instances corresponding to the debug outputs. > (For some reason the ranger data in the log consists of one correct line and > one line with 0.5 at all measurements.) If you look more closely, you'll see that there are actually two message types being sent out by Stage over the ranger interface: PLAYER_RANGER_DATA_RANGE (001) and PLAYER_RANGER_DATA_INTENS (003). Definitions for the ranger interface message types are at [2], and the readlog/writelog magic decoder ring is at [3]. [1] http://playerstage.sourceforge.net/doc/Player-svn/player/classPlayerCc_1_1PlayerClient.html#a496845414a96f05d3abb16a3a267b7e2 [2] http://playerstage.sourceforge.net/doc/Player-svn/player/group__interface__ranger.html [3] http://playerstage.sourceforge.net/doc/Player-svn/player/group__tutorial__datalog.html Rich |
From: ulle <ulr...@et...> - 2013-04-18 12:13:25
|
Hi I don't think the client buffer is overflowing since I have to wait for Read() to execute. I tried to set the replace rules for all my proxies (i.e. myRangerProxy.SetReplaceRule(true, -1, -1) ) but I see no change. I have tried to use the ReadIfWaiting() function, but I only obtain the same messages a hundred times or so before a new message is available. Ok, good clarification regarding the log file, thanks. Just to make sure I got the repos right. I use https://playerstage.svn.sourceforge.net/svnroot/playerstage/code/player/trunk https://github.com/rtv/Stage.git https://github.com/pauldreik/Stage.git (Some updated bumper functionalities by Paul Dreik, a former coworker) Have any of you out there succeeded in obtaining measurements at around 100Hz or faster? Regards, Ulrik -- View this message in context: http://player-stage-gazebo.10965.n7.nabble.com/Running-simulation-10Hz-tp18646p18674.html Sent from the playerstage-developers mailing list archive at Nabble.com. |
From: Richard V. <va...@sf...> - 2013-04-13 03:11:28
|
On Fri, Apr 12, 2013 at 5:03 PM, Richard Vaughan <rt...@au...> wrote: > I should fix this. Fixed it in git master. All models publish through Player at their natural update rate in simulation time. The Player and ROS interfaces still need work. I'll try to reserve some time for this soon. - rtv > On Fri, Apr 12, 2013 at 5:00 PM, Rich Mattes <jp...@gm...> wrote: >> >> On 04/12/2013 12:26 PM, Richard Vaughan wrote: >> > Hi, >> > >> > You just need to set >> > >> > interval_sim 20 >> > >> > in Stage's worldfile and Stage will run the simulation with 50 steps >> > per second and attempt to do this in real time. I just confirmed that >> > this works for me with standalone Stage (i.e. without Player). >> > >> > If you want Stage to try to run faster than real time, do this in the >> > top level of your worldfile: >> > >> > speedup X >> > >> > where X is the multiple of real time you want, or -1 to go as fast as it >> > can. >> > >> > Can anyone with recent experience running Player/Stage at high >> > frequencies comment on whether any Player configuration is needed? >> > >> > - rtv >> > >> > >> > >> The Player interface should be able to keep up, but Stage's Player >> interface publishes data at a fixed rate, regardless of the step size or >> speedup. There was a thread on playerstage-users a little while ago >> about this: >> >> http://player-stage-gazebo.10965.n7.nabble.com/Update-rate-of-player-3-1-0-and-PUSH-PULL-td2960.html >> >> Rich >> >> >> ------------------------------------------------------------------------------ >> Precog is a next-generation analytics platform capable of advanced >> analytics on semi-structured data. The platform includes APIs for building >> apps and a phenomenal toolset for data science. Developers can use >> our toolset for easy data analysis & visualization. Get a free account! >> http://www2.precog.com/precogplatform/slashdotnewsletter >> _______________________________________________ >> Playerstage-developers mailing list >> Pla...@li... >> https://lists.sourceforge.net/lists/listinfo/playerstage-developers > > |
From: ulle <ulr...@et...> - 2013-04-15 15:20:30
|
Hi! I work in the same project as p1r. Thanks for the fix, Richard. Now I can receive sensor updates every simulated 10ms, but only when I reduce the simulation speed substantially. In real time I still get somewhat irregular updates every 120-200ms. I have set interval_sim and update_interval to 10. If I set speedup to -1 the simulation runs at about half as slow as real time. I have a four-core cpu and none of them are working above 40% when running a simulation in real time. Rickard, you mention Player needs some work. Could you, or anyone else, point at some specific parts that I can have a look at? Right now I am stuck in playerclient.cc approximately at row 237 --- if (NULL==playerc_client_read(mClient)). I cant find the playerc_client_read function. Thanks, Ulle -- View this message in context: http://player-stage-gazebo.10965.n7.nabble.com/Running-simulation-10Hz-tp18646p18659.html Sent from the playerstage-developers mailing list archive at Nabble.com. |
From: Richard V. <va...@sf...> - 2013-04-15 17:28:09
|
I'll look into this! If you can send me your P/S setup to test with, that would help me make sure this works for you (.world, .cfg and a minimal Player client that shows the problem). I don't have a current Player workload to test with. update_interval is deprecated and replaced by speedup. - rtv On Mon, Apr 15, 2013 at 8:20 AM, ulle <ulr...@et...> wrote: > Hi! > > I work in the same project as p1r. > > Thanks for the fix, Richard. Now I can receive sensor updates every > simulated 10ms, but only when I reduce the simulation speed substantially. > In real time I still get somewhat irregular updates every 120-200ms. > > I have set interval_sim and update_interval to 10. If I set speedup to -1 > the simulation runs at about half as slow as real time. > > I have a four-core cpu and none of them are working above 40% when running a > simulation in real time. > > Rickard, you mention Player needs some work. Could you, or anyone else, > point at some specific parts that I can have a look at? Right now I am stuck > in playerclient.cc approximately at row 237 --- if > (NULL==playerc_client_read(mClient)). I cant find the playerc_client_read > function. > > Thanks, > Ulle > > > > -- > View this message in context: http://player-stage-gazebo.10965.n7.nabble.com/Running-simulation-10Hz-tp18646p18659.html > Sent from the playerstage-developers mailing list archive at Nabble.com. > > ------------------------------------------------------------------------------ > Precog is a next-generation analytics platform capable of advanced > analytics on semi-structured data. The platform includes APIs for building > apps and a phenomenal toolset for data science. Developers can use > our toolset for easy data analysis & visualization. Get a free account! > http://www2.precog.com/precogplatform/slashdotnewsletter > _______________________________________________ > Playerstage-developers mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-developers |
From: ulle <ulr...@et...> - 2013-04-16 14:00:27
|
I have to check with my superior before I can send you any setup files, sorry. The problem I mentioned occur when I start player with the .cfg-file first and then start the client program. I modified wander.cc a bit and when I start that directly from inside the .world-file (like in the simple.world example provided) both position and ranger updates run at 100Hz. I guess playerclient.cc is not used when I run the wander control function. Best regards, Ulle -- View this message in context: http://player-stage-gazebo.10965.n7.nabble.com/Running-simulation-10Hz-tp18646p18665.html Sent from the playerstage-developers mailing list archive at Nabble.com. |
From: Rich M. <jp...@gm...> - 2013-04-16 22:54:11
|
On 04/16/2013 10:00 AM, ulle wrote: > I have to check with my superior before I can send you any setup files, > sorry. > The problem I mentioned occur when I start player with the .cfg-file first > and then start the client program. > I modified wander.cc a bit and when I start that directly from inside the > .world-file (like in the simple.world example provided) both position and > ranger updates run at 100Hz. > I guess playerclient.cc is not used when I run the wander control function. > > Best regards, > Ulle If you use the "writelog" Player driver to capture all of the position2d and ranger messages from Stage do you see the updates at 100Hz? You may be processing messages too slowly and overflowing the message queue, (though usually you'll see a bunch of terminal output if that happens). Do you see all of the updates when you run Stage at or slower than realtime? Rich |
From: ulle <ulr...@et...> - 2013-04-17 14:44:55
|
Hi again I tried the writelog thing, and the data stored in the log file has updated at 100Hz. But the data my client program obtains is only a small fraction of that. I measured the time my client program takes to wait for the data compared to how long it takes to execute other stuff in my loop. My code takes usually less than 1ms while the Read() function takes 50-300ms. I provide a text file with a few debug outputs for three loops that include elapsed time, odo and ranger data. Then the log data follows where I have marked those instances corresponding to the debug outputs. (For some reason the ranger data in the log consists of one correct line and one line with 0.5 at all measurements.) robot.log <http://player-stage-gazebo.10965.n7.nabble.com/file/n18671/robot.log> Regards, Ulle -- View this message in context: http://player-stage-gazebo.10965.n7.nabble.com/Running-simulation-10Hz-tp18646p18671.html Sent from the playerstage-developers mailing list archive at Nabble.com. |