From: <er...@li...> - 2012-09-25 11:18:16
|
Hello. I'm currently using a super-loop with FSMs for all the work. One of the FSMs manages player which is currently configured in pull mode. The update rate in this modality is quite jittery, but averaging at 10Hz: I get delays from 70 to 200ms, but usually get around 10 messages per second. Stage is running on the same machine, the superloop itself is not the culprit here (tried). What's holding it down is the read instruction. I thought it wasn't needed in PUSH, but if I omit the read it just displays non initialized data (at much higher speeds though). So ultimately what would be the difference between PUSH and PULL? I get it theoretically, but it doesn't appear to make much of a difference practically. Unless in push there should be a callback, or something. But if so I could not find it. I'm using the unmodified simple.cfg world. The robot is wandering autonomously and I'm just trying to fetch its position. As obvious I need a much higher update rate. Regards Claudio |
From: Rich M. <jp...@gm...> - 2012-09-26 01:41:07
|
On 09/25/2012 07:18 AM, er...@li... wrote: > Hello. > I'm currently using a super-loop with FSMs for all the work. > One of the FSMs manages player which is currently configured in pull mode. > > The update rate in this modality is quite jittery, but averaging at 10Hz: I > get delays from 70 to 200ms, but usually get around 10 messages per second. > Stage is running on the same machine, the superloop itself is not the culprit > here (tried). > What's holding it down is the read instruction. > I thought it wasn't needed in PUSH, but if I omit the read it just displays > non initialized data (at much higher speeds though). > > So ultimately what would be the difference between PUSH and PULL? > I get it theoretically, but it doesn't appear to make much of a difference > practically. > Unless in push there should be a callback, or something. But if so I could not > find it. > > I'm using the unmodified simple.cfg world. > The robot is wandering autonomously and I'm just trying to fetch its position. > As obvious I need a much higher update rate. > > Regards > Claudio > > The update rate for any driver is dictated by that driver. Player's internal message loop runs around 100Hz, so if you're seeing slower data rates it's because your driver is calling Publish() at a slower rate. In your case, the culprit is the default settings in Stage. Out of the box, Stage simulates in 100msec steps, meaning that data will never be generated at any finer resolution. The first step is to change the interval_sim to something smaller, see [1] for more details. The second issue is that the Player plugin in Stage (the part that acts as a Player driver) is also hard-coded to Publish() data from all simulated models at a time interval of 100msec. To change this, edit libstageplugin/p_driver.cc, and change the value assigned to publish_interval_msec. And, for what it's worth, the difference between PUSH and PULL mode is documented at [2]. Rich [1] http://rtv.github.com/Stage/group__world.html [2] http://playerstage.sourceforge.net/doc/Player-svn/player/group__libplayertcp.html |
From: Rich M. <jp...@gm...> - 2012-09-26 01:45:28
|
On 09/25/2012 09:41 PM, Rich Mattes wrote: > On 09/25/2012 07:18 AM, er...@li... wrote: >> Hello. >> I'm currently using a super-loop with FSMs for all the work. >> One of the FSMs manages player which is currently configured in pull >> mode. >> >> The update rate in this modality is quite jittery, but averaging at >> 10Hz: I >> get delays from 70 to 200ms, but usually get around 10 messages per >> second. >> Stage is running on the same machine, the superloop itself is not the >> culprit >> here (tried). >> What's holding it down is the read instruction. >> I thought it wasn't needed in PUSH, but if I omit the read it just >> displays >> non initialized data (at much higher speeds though). >> >> So ultimately what would be the difference between PUSH and PULL? >> I get it theoretically, but it doesn't appear to make much of a >> difference >> practically. >> Unless in push there should be a callback, or something. But if so I >> could not >> find it. >> >> I'm using the unmodified simple.cfg world. >> The robot is wandering autonomously and I'm just trying to fetch its >> position. >> As obvious I need a much higher update rate. >> >> Regards >> Claudio >> >> > > The update rate for any driver is dictated by that driver. Player's > internal message loop runs around 100Hz, so if you're seeing slower > data rates it's because your driver is calling Publish() at a slower > rate. In your case, the culprit is the default settings in Stage. Out > of the box, Stage simulates in 100msec steps, meaning that data will > never be generated at any finer resolution. The first step is to > change the interval_sim to something smaller, see [1] for more details. > > The second issue is that the Player plugin in Stage (the part that > acts as a Player driver) is also hard-coded to Publish() data from all > simulated models at a time interval of 100msec. To change this, edit > libstageplugin/p_driver.cc, and change the value assigned to > publish_interval_msec. > > And, for what it's worth, the difference between PUSH and PULL mode is > documented at [2]. > > Rich > > [1] http://rtv.github.com/Stage/group__world.html > [2] > http://playerstage.sourceforge.net/doc/Player-svn/player/group__libplayertcp.html Small addendum: You may also need to adjust the update rate for each individual model, in addition to the global "interval_sim" update rate. Each model contains its own update rate which can differ from the global update rate [3], and they also all default to 100msec, Rich [3] http://rtv.github.com/Stage/group__model.html |
From: Claudio C. <er...@li...> - 2012-09-26 07:48:17
|
So I have to recompile every model I use and it will stay hard coded. Bear with me for a moment:a fixed data rate may make sense when simulating, so I totally see such a parameter being part of stage and eventually be passed to player when it is used with stage. But if player is used for a real robot this doesn't make sense to me: shouldn't data rate follow the actual device data rate? (Like for a laser scanner) Claudio -- Sent from my LG Optimus 2x with K-9 Mail. Rich Mattes <jp...@gm...> wrote: >On 09/25/2012 09:41 PM, Rich Mattes wrote: >> On 09/25/2012 07:18 AM, er...@li... wrote: >>> Hello. >>> I'm currently using a super-loop with FSMs for all the work. >>> One of the FSMs manages player which is currently configured in pull > >>> mode. >>> >>> The update rate in this modality is quite jittery, but averaging at >>> 10Hz: I >>> get delays from 70 to 200ms, but usually get around 10 messages per >>> second. >>> Stage is running on the same machine, the superloop itself is not >the >>> culprit >>> here (tried). >>> What's holding it down is the read instruction. >>> I thought it wasn't needed in PUSH, but if I omit the read it just >>> displays >>> non initialized data (at much higher speeds though). >>> >>> So ultimately what would be the difference between PUSH and PULL? >>> I get it theoretically, but it doesn't appear to make much of a >>> difference >>> practically. >>> Unless in push there should be a callback, or something. But if so I > >>> could not >>> find it. >>> >>> I'm using the unmodified simple.cfg world. >>> The robot is wandering autonomously and I'm just trying to fetch its > >>> position. >>> As obvious I need a much higher update rate. >>> >>> Regards >>> Claudio >>> >>> >> >> The update rate for any driver is dictated by that driver. Player's >> internal message loop runs around 100Hz, so if you're seeing slower >> data rates it's because your driver is calling Publish() at a slower >> rate. In your case, the culprit is the default settings in Stage. >Out >> of the box, Stage simulates in 100msec steps, meaning that data will >> never be generated at any finer resolution. The first step is to >> change the interval_sim to something smaller, see [1] for more >details. >> >> The second issue is that the Player plugin in Stage (the part that >> acts as a Player driver) is also hard-coded to Publish() data from >all >> simulated models at a time interval of 100msec. To change this, edit > >> libstageplugin/p_driver.cc, and change the value assigned to >> publish_interval_msec. >> >> And, for what it's worth, the difference between PUSH and PULL mode >is >> documented at [2]. >> >> Rich >> >> [1] http://rtv.github.com/Stage/group__world.html >> [2] >> >http://playerstage.sourceforge.net/doc/Player-svn/player/group__libplayertcp.html > >Small addendum: You may also need to adjust the update rate for each >individual model, in addition to the global "interval_sim" update rate. > >Each model contains its own update rate which can differ from the >global >update rate [3], and they also all default to 100msec, > >Rich > >[3] http://rtv.github.com/Stage/group__model.html > > >------------------------------------------------------------------------------ >Live Security Virtual Conference >Exclusive live event will cover all the ways today's security and >threat landscape has changed and how IT managers can respond. >Discussions >will include endpoint security, mobile security and the latest in >malware >threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >_______________________________________________ >Playerstage-users mailing list >Pla...@li... >https://lists.sourceforge.net/lists/listinfo/playerstage-users |
From: Claudio C. <er...@li...> - 2012-09-26 09:12:08
|
Ok I modified the files in the stage source and am now able to get much higher data rates. I set both model and world updates to 10msec, but I'm not getting that rate. I'm getting about 50Hz instead of 100Hz. I suppose that maybe world has to run faster? I'll give it a try. Thanks Rich Claudio |