I'm working on a new Stage engine that'll follow the configuration model
Brian describes (based on discussions nicely summarised by Andrew's
now-legendary ASCII art). By exposing Player to the user we gain a lot
more in great Player-based features than we lose in Stage ease-of-use.
There should be some new software to try out in the next few weeks.
On Mon, 7 Jul 2003, brian gerkey wrote:
> On Mon, 7 Jul 2003, Reed Hedges wrote:
> > Quoting brian gerkey <bgerkey@...>:
> > > each entry in that list has its own robot name and port.
> > > When you're using real hardware, they'll all be the same.
> > Ah, OK, thanks.
> > I have one more question: how do I pass the stuff in the stage world file
> > through to my device? In CreateStageDevices in player/server/main.cc, I catch
> > my SERVICE_ADV_CODE specially in the switch, and just create the normal player
> > device, instead of the stage-specific device (this is what MCom and UDPbroadcast
> > and maybe others seem to do). Do I need to go trough the stage world file and
> > use ConfigFile::AddProperty to add my configuration items? How do I access the
> > World file form that function?
> hi Reed,
> You've just discovered a persistent problem with the current Player/Stage
> model, one that we've been thinking about for some time. The problem derives
> from using a single configuration file (i.e., Stage's .world file) to setup
> both Player and Stage.
> In a nutshell:
> The simulator configuration file (e.g., Stage's .world file) is the right
> place to specify everything necessary to define the simulated world. For
> example, you define the different robots to be simulated, including the
> geometrical and hierarchical relationships of their components. For
> Gazebo, you might also define their masses, textures, etc.
> The simulator's configuration file is NOT the right place to define
> Player-specific things, like which interface your simulated robot wheelbase
> will present, or how your communication infrastructure will work.
> Instead, you should also write a Player configuration file, which defines all
> of these things, effectively creating a mapping from Player devices to
> sensors and actuators in the simulator. Then you have the "new" model that
> Andrew has so eloquently explained with his ASCII art: start the simulator
> with its config file, then start Player with its config file, and point it at
> the simulator.
> Besides being cleaner and more intuitive, this model also allows for a
> non-Player interface to the simulators (not use Player? shocking!).
> Unfortunately for you, this new model is currently unavailable for Stage
> (it's working with Gazebo). So for now you'll have to be very clever
> and/or do something ugly, like manually add default values for your driver
> to the configFile object in that switch in main.cc. You might have
> noticed that the udpbroadcast driver does this, always setting the
> hostname to "127.255.255.255".
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> Playerstage-developers mailing list
Richard Vaughan / HRL Laboratories / vaughan@... / +1 310.317.5689