Thanks all for the feedback about SDL, and particularly to Paul for
all his work. Here are my thoughts so far.
FAQ candidate: Why is a Stage a library and Player plugin, and not a
Stage used to be a standalone app that talked to a Player (if
present) using shared memory. The redesign as a plugin allowed me to
eliminate a lot of code - now there is no Stage-specific code in
Player at all, permitting independent releases. It was also a great
sanity check for the plugin model - if it works for Stage it should
be good for most other uses. I fixed a few problems with the plugin
design along the way.
Also, Stage is not much use as a standalone app. You have to be able
to talk to the robots somehow, so you need a robot interface. Player
is a great interface, and it comes with lots of meta-drivers , e.g.
VFH, AMCL. The Stage package is useful standalone as a C library -
you use the Stage native API to talk to robots. In this mode your
controller binary contains all of Stage, giving you the best
performance with no IPC overhead. Of course, it's easy to wrap
libstage with another IPC API to create your own app.
Much more interesting scientifically is that Player clients on real
robots can run copies of Stage in their heads to rehearse actions
[ http://www.cs.sfu.ca/~vaughan/doc/vaughan_sab06.pdf ]. That is the
most important reason why I made Stage a library and a plugin.
This leads me to something Brian and I have talked about. The Player
project could specify a very simple robot C API, which it would use
internally. Stage could present this API. It could look like a
minimal version of libplayerc:
p_laser_get_data( player_device_t* dev, player_laser_data_t* data );
p_laser_set_cmd( player_device_t* dev, player_laser_data_t* data );
p_laser_request( player_device_t* dev, player_laser_req_t* req,
player_laser_reply_t** reply );
If this API was standardized, Player client code could be compiled
against libplayerc like now, or libplayercore, or libstage/libgazebo.
Various middleware layers could be added or skipped without changing
client code. I plan to write a version of this into Stage anyway,
which will be used by libstageplugin and my own standalone apps. We
can see how that goes and talk later about whether it gets used
Oh, and the Qt suggestion - Qt is a nice framework. I get the feeling
that SDL is lighter weight, and it is native C (Qt is C++). Moving
away from BSD sockets for Player is a big step, as is adding an
unusual dependency like SDL, so we should take care. Getting easy
access to OpenGL and the sound hardware in a platform independent way
is going to be very important for me. Paul has done a lot of work on
SDL already, and a proof of concept like that is worth a lot in my book.
Also, I think it's time we ran on Windows right out of the box. And
that means shipping Windows binaries. There, I said it.
On 3-Jun-07, at 11:04 AM, Paul Osmialowski wrote:
> On Sun, 3 Jun 2007, Sidney Cadot wrote:
>>>> Did you consider porting Stage to Qt instead?
>>> Isn't Qt too heavy?
>> That depends on what you mean by "heavy". And "too". ;-)
>>> If Stage is still considered to be plugin for
>>> Player we must remember that Player itself must be fully scalable
>>> (so it
>>> should be able to run on full-blown PC as well as on low-memory
>>> PDA's even
>>> they don't run Qtopia).
>> I don't see why this would be desirable. I do not see how running
>> simulations on a PDA could be useful in the real world. (though it
>> would be
> I didn't mean that Stage should be able to work on PDA's (however, it
> would be nice to have this), I only remarked that currently Stage
> Player and Player should be able to run everywhere. Personally I
> don't see
> nothing wrong in Stage being Player's plugin. Also I think it would be
> desirable to have possibility of running Stage simulation plugin
> with no
> visual output (for example, deliberative planners may use Stage
> to test proposed plan before execution on the real devices, there's no
> need to have GUI companion during this). SDL may be helpful also in
> case, since there's no need to initialize all subsystems in main()
> function, they can be initialized as they're needed (for example,
> subsystem would be initialized only when Stage with GUI is used,
> otherwise, Player as an SDL app is still capable to be started in
> shell session).
>> The real advantage of a Qt version would be that you'd have a good-
>> version running on the Unix, Mac, and Windows versions, without
>> going via
>> non-native X emulation on the Mac/Windows platforms. Plus
>> (important, IMHO:)
>> Qt is a joy to program in.
> I don't know how it is done on MacOSX or things like Photon/QNX,
> but on
> Windows SDL doesn't use X emulation. No Cygwin is needed for that
>> On a related note: I do not personally consider it such great idea
>> that the
>> simulator is a 'player' plugin - quite the contrary. If Stage is
>> going to be
>> redesigned anyway, I would advocate to separate it further from
>> the "player"
>> app; basically, to have it as a fully independent application. I am
>> interested to discuss the merits of both approaches, and I think
>> that would
>> be a clever thing to do before embarking on a redesign.
>> The main problem with the current approach is that most GUI
>> assume responsibility for the main event loop. This is conflicts
>> deeply with
>> the current setup where "player" is in charge of the main thread.
>> Cheerio, Sidney
>> This SF.net email is sponsored by DB2 Express
>> Download DB2 Express C - the FREE version of DB2 express and take
>> control of your XML. No limits. Just data. Click to get it now.
>> Playerstage-developers mailing list
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> Playerstage-developers mailing list