I really understand this quite a lot better now, is it possible to get the wavefront planning to work with libstage as a standalone? It seems that it is not a "model", but is it possible with your "API" extensions?

Again, I really really appreciate all the help so far.


On 8/27/07, Reed Hedges <> wrote:
Franklin Dorbon wrote:
> I guess what I don't understand is, how one would be able to use
> player/stage as a simulator embedded in C code.  From what you say, I
> don't see what using libstage actually does.  I really just want to be
> able to run a simulation within existing code with the ability to
> stop/start/restart the simulation over and over again (optimizing a
> learning parameter for example).
> I really looked hard, but I found only very very minimal description on
> what exactly libstage as a standalone means/examples etc.

I see. If you want to use libstage directly, then you wouldn't use Player at
all.  libstage manages the simulation state and the GUI. Each time you call
stg_world_update(), each of the models that make up the simulated world are
updated depending on things like their current velocities.  libstage provides
some access through its public API to the world and these models.

I have mainly used the previous version of libstage (I'm not a main author by
the way, just one of the few who use libstage directly); the current version has
had changes to its API since then so I don't know that much about using it, but
I'm pretty familiar with how libstage works in general.

libstage is a bit lacking as a general use library, including documentation,
since it's mainly been used only by the Player plugin.   In using libstage I
made various modifications and additions to its API, I have patches to the older
version (2.0.0a), I haven't started using 2.0.1 yet.   I'd be interested in your
experiences using it so we can work on improving it in the future.

Here is the libstage 2.0.1 developer documentation:

Or you can generate it yourself locally with doxygen.

You can also look at at the Player plugin as an example, it's source files start
with the prefix p_ in the Stage source code.  E.g.  To see how that
code is using libstage, look for the libstage functions and structures it is
using, these functions and structure types all start with the stg_ prefix.

To access a model, obtain a stg_model_t* from the world object using
stg_world_model_name_lookup(). (The name is as given in the world file).  All of
the objects declared in the world file are models in the world, including
obstacles/maps, robots, the robots' devices, etc.

Use the stg_model_subscribe() and stg_model_unsubscribe() functions to indicate
that your program is using the models; a model is not updated if its
subscription count is 0.   See the  Worlds "module" in the documentation for
general world functions, or the Models "module" for model functions.

A model like "position" also has a "command" struct, which can make it do stuff
each update loop, like move.  Set a command with the stg_model_set_cmd()
function giving a pointer to the appropriate command struct for that model. For
example, stg_position_cmd_t for a position model.   Sometimes extra properties
are associated with models by name, (named properties). I don't know if there's
a list of any of those things yet.

I think you should be able to destroy and rececreate the world for each run of
your experiment. If you encounter any bugs or memory leaks doing that let us
know, since this is not how libstage has typically been used in the past.
Alternatively, you can just reset the state of your robots by moving them back
to their starting locations and reseting odometric pose perhaps or whatever else
needs to be reset.  You can pause/unpause the world (i.e. the clocks and
updates) with the world start/stop functions, I think.


This email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>
Playerstage-users mailing list