From: Paul O. <new...@ki...> - 2007-05-18 11:09:02
|
Hi all, Some time ago I've proposed at playerstage-users that Player/Stage should be built on SDL/SDL_net to make it more portable. It was some time after I've ported libplayerc (1.6.5), playerv and videoplayer to MinGW. At that time, the only problem i had to resolve was sockets usage (BSD vs Winsock). Then new Player was released. This time porting became much harder due to usage of xdr serialization. I had to write my own implementation based on glibc code with usage of SDL endian-related functions. Also I used SDL_net to replace BSD sockets in libplayerc. Finally I've extracted these libraries from Player tree: - libplayerxdr - libplayerjpeg - libplayerc - rtk2 Then I tried to compile playerv and videoplayer using these libraries for both Linux and Windows (using MinGW crosscompiler to build Windows binaries). It wasn't easy, due to some nonportable nasties in Player code. In my opinion, Player code should be cleaned a bit in some future. Some noticable flaws are: 1. Usage of different naming styles for integer types (ie u_char, u_int, uint, u_long and so on instead of uint8_t, uint32_t and so on). I suggest to use only one naming style, the one proposed by stdint.h (or SDL_types.h, but it may be not that nice). No other styles are available in MinGW, and I guess there are more development enviroments that would suffer from that. 2. No return values in some int-type functions - it causes a warning only, but it looks ugly anyway. 3. Some others I don't remember now My SDL port has unfortunately some caveats too: 1. I didn't know what to do with ___FLOAT_WORD_ORDER in XDR serialization, finally I've set it to SDL_BYTEORDER in replace/endian.h and it should work for most popular CPU's, but users of exotic architectures should be warned that it may not work properly. 2. It still depends on things that may not be 100% portable, but I guess they're available *almost* everywhere. These are: - gettimeofday() from sys/time.h - stdint.h (yep, SDL offers SDL_types.h instead) - sys/param.h (for PATH_MAX only, I guess) - limits.h (for *_MAX, LASTUNSIGNED and so on, I guess) - zlib - libjpeg - g_usleep from glib in client programs (normally it was nanosleep() which seem to be the safest sleep function in the world, unfortunately not available on MinGW, Solaris and some other systems). Probably SDL offers sufficient replacement for these things, but I didn't feel that it's necessery to work them out. Whole source tree (with Windows DLL's included) is available here: http://king.net.pl/playercontrib/SDL it contains Makefiles that I've prepared. I also have crosscompilation MinGW tree for x86 Linux suitable to unpack in user's home directory, but it's 38MB big .bz2 image so I don't have any suitable place to publish it. It contains SDL, SDL_net, SDL GUIlib, glib2, gtk2, zlib, libjpeg, pango, atk, cairo, expat, fontconfig, fteetype, gettext, lcms, libart, libexif, libpng, libiconv, tiff, xpm_nox and libxml2. I hope someone will make use of my job. I guess it may be the very first step to SDL-based Player which would be the most portable robotic software. SDL would cover topics like networking, endianness, threads, types convention, shared libraries loading and very limited access to the hardware (audio and joystick for now, other hardware access would be still system-dependent). This woluld lead to native Player (and Stage!) compilation for sysyems like M$ Windows (many of the students here hate Cygwin, that makes Player hard to use during the classes!). I guess it won't be an easy task since Player uses more libraries that may cause portability problems: gsl, boost (wasn't good old C++ with good old STL enough?), opencv, libgnomecanvas and so on. Cheers, Paul |
From: Reed H. <re...@mo...> - 2007-05-18 13:15:30
|
SDL might be a good overall solution but there are other options for some of the specific problems, in case we don't want to require SDL (yet another dependency!): > At that > time, the only problem i had to resolve was sockets usage (BSD vs > Winsock). Then new Player was released. This time porting became much > harder due to usage of xdr serialization. I had to write my own > implementation based on glibc code with usage of SDL endian-related > functions. Also I used SDL_net to replace BSD sockets in libplayerc. I've never had major problems using sockets in general on MinGW using winsock2 (there are several variants on the winsock lib I think, I link to libws2_32.) Never tried building Player though. What about XDR makes it harder? > - gettimeofday() from sys/time.h Here's a replacement for MinGW, can be substituted using autoconf. There's a more accurate time function available in the Windows SDK winmm.lib library, but you might need Visual C installed to get that library. #include "replace.h" #if HAVE_SYS_TIMEB_H #include <sys/timeb.h> #else #error gettimeofday replacement needs sys/timeb.h #endif /* Sets tv with seconds and microseconds, but microseconds only has milisecond accuracy on windows. Timezone is not set but it's deprecated and nobody uses it anymore. */ int gettimeofday(struct timeval* tv, struct timezone* tz) { #if HAVE__FTIME // from autoconf check for the _ftime function struct _timeb timebuff; _ftime(&timebuff); tv->tv_sec = timebuff.time; tv->tv_usec = (timebuff.millitm) * 1000.0; return 0; #else #error The replacement for gettimeofday() needs the windows _ftime function #endif } > - stdint.h (yep, SDL offers SDL_types.h instead) > - sys/param.h (for PATH_MAX only, I guess) > - limits.h (for *_MAX, LASTUNSIGNED and so on, I guess) > - zlib This is small and could be included with the player source. Or you can get it here: http://www.gimp.org/~tml/gimp/win32/ > - libjpeg Also available at http://www.gimp.org/~tml/gimp/win32/ > - g_usleep from glib in client programs (normally it was nanosleep() which > seem to be the safest sleep function in the world, unfortunately not > available on MinGW, Solaris and some other systems). I use this on Windows. Like gettimeofday, not as accurate, but it's fine if it doesn't matter exactly how long you need to sleep for. /* A *much* less accurate version of usleep. It may only have accuracy of a few hundred ms. */ int usleep(unsigned long usec) { #ifdef HAVE_WIN32_SLEEP // from autoconf check for Sleep() function # warning using Win32 Sleep() function. Sleep(usec/1000.0); #else # ifdef HAVE__SLEEP // from autoconf check for _sleep() function. # warning Using private Win32 _sleep function. _sleep(usec / 1000.0); # else # error the usleep() replacement requires the Windows _sleep() or Sleep() function! # endif #endif } Reed |
From: Paul O. <new...@ki...> - 2007-05-18 14:49:33
|
On Fri, 18 May 2007, Reed Hedges wrote: > > SDL might be a good overall solution but there are other options for some of the > specific problems, in case we don't want to require SDL (yet another dependency!): > Well I did't say to add another dependency, rather to use SDL in order to remove (some) other dependencies. >> - g_usleep from glib in client programs (normally it was nanosleep() which >> seem to be the safest sleep function in the world, unfortunately not >> available on MinGW, Solaris and some other systems). > > I use this on Windows. Like gettimeofday, not as accurate, but it's fine if it > doesn't matter exactly how long you need to sleep for. Again, my point is that there are several replacements for free-world functions in MinGW, but we wouldn't have problems like this one (with g_usleep) if we only rewrite whole thing using SDL (which itself also offers portable sleeping function). We could gain one code for all systems. Paul |
From: Paul O. <new...@ki...> - 2007-05-18 14:56:03
|
> I've never had major problems using sockets in general on MinGW using winsock2 > (there are several variants on the winsock lib I think, I link to libws2_32.) Yup, neither me, but this time I wanted to prepare source code that compiles everywhere. My happy users now have client library that does not need whole Player to be installed and compiles everywhere. > Never tried building Player though. What about XDR makes it harder? The bigest one: There's no sunrpc (and therefore XDR) for MinGW! I had to rewrite it myself using as much of the code taken from glibc sources as possible. Thanks for function replacements code! Paul |
From: Brian G. <br...@ge...> - 2007-05-22 17:05:11
|
On May 18, 2007, at 5:08 AM, Paul Osmialowski wrote: > Also I used SDL_net to replace BSD sockets in libplayerc. > Finally I've extracted these libraries from Player tree: > - libplayerxdr > - libplayerjpeg > - libplayerc > - rtk2 > Then I tried to compile playerv and videoplayer using these > libraries for > both Linux and Windows (using MinGW crosscompiler to build Windows > binaries). hi Paul, I just tested and was able to build your SDL-based player package on Mac OS X, as well (with a couple of Makefile changes). This sounds promising, and I'm interested to learn more about SDL. I'll look into the changes that you made and see what we can do with it. brian. |
From: Paul O. <new...@ki...> - 2007-05-22 22:12:11
|
Brian Gerkey napisał(a): > On May 18, 2007, at 5:08 AM, Paul Osmialowski wrote: > >> Also I used SDL_net to replace BSD sockets in libplayerc. >> Finally I've extracted these libraries from Player tree: >> - libplayerxdr >> - libplayerjpeg >> - libplayerc >> - rtk2 >> Then I tried to compile playerv and videoplayer using these >> libraries for >> both Linux and Windows (using MinGW crosscompiler to build Windows >> binaries). > > hi Paul, > > I just tested and was able to build your SDL-based player package on > Mac OS X, as well (with a couple of Makefile changes). This sounds > promising, and I'm interested to learn more about SDL. hi Brian, Well, Makefiles are the weakest part of it, as autotools should be used for it. Finally I've found a good place for my MinGW+glib2+gtk2+SDL+SDL_net+SDL_GUIlib crosscompilation image. It is here: http://vlab.pjwstk.edu.pl/~vlabdemo/mingw/mingw-xgcc-20070517.tar.bz2 It was built on FC6 so I'm not sure if it's able to work on older Linuxes. This image should be unpacked into user's home directory. Cheers, Paul > > I'll look into the changes that you made and see what we can do with it. > > brian. > > ------------------------------------------------------------------------- > 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. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Playerstage-developers mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-developers |
From: Richard v. <va...@cs...> - 2007-06-02 01:52:00
|
I too, am looking at SDL. It looks like it might help with my plans for Stage-3.0. This would *require* Player to build as an SDL app (using the SDL runtime requires replacing the main() function). Having looked at SDL today, and Paul's summary email (but not yet his code), this is something I'd like to look into more. Any comments from anyone with SDL experience? Richard/ On 22-May-07, at 10:04 AM, Brian Gerkey wrote: > > On May 18, 2007, at 5:08 AM, Paul Osmialowski wrote: > >> Also I used SDL_net to replace BSD sockets in libplayerc. >> Finally I've extracted these libraries from Player tree: >> - libplayerxdr >> - libplayerjpeg >> - libplayerc >> - rtk2 >> Then I tried to compile playerv and videoplayer using these >> libraries for >> both Linux and Windows (using MinGW crosscompiler to build Windows >> binaries). > > hi Paul, > > I just tested and was able to build your SDL-based player package on > Mac OS X, as well (with a couple of Makefile changes). This sounds > promising, and I'm interested to learn more about SDL. > > I'll look into the changes that you made and see what we can do > with it. > > brian. > > ---------------------------------------------------------------------- > --- > 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. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Playerstage-developers mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-developers |
From: Sidney C. <sid...@ji...> - 2007-06-02 22:45:58
|
Hi Richard > I too, am looking at SDL. It looks like it might help with my plans > for Stage-3.0. Did you consider porting Stage to Qt instead? Cheerio, Sidney |
From: Paul O. <new...@ki...> - 2007-06-03 09:48:26
|
On Sun, 3 Jun 2007, Sidney Cadot wrote: > Hi Richard > >> I too, am looking at SDL. It looks like it might help with my plans >> for Stage-3.0. > > Did you consider porting Stage to Qt instead? > > Cheerio, > > Sidney Isn't Qt too heavy? 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 if they don't run Qtopia). SDL is known to work everywhere (people play SDL games on their PDA's) and it doesn't seem to be that heavy. I would rather drop glib/gtk dependency and use SDL-based GUI similar to those used in openttd project (http://www.openttd.org/screens.php) and prepare librtk3 that make use of it. Also I would like to suggest not to use dynamic containers from glib in C++ code and use those offered by STL templates instead. I guess all C++ compilers nowadays provide STL headers. Cheers, Paul > > > > ------------------------------------------------------------------------- > 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. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Playerstage-developers mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-developers > |
From: Sidney C. <sid...@ji...> - 2007-06-03 15:53:11
|
> > Did you consider porting Stage to Qt instead? > > > > Cheerio, > > > > Sidney > 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 if > they don't run Qtopia). I don't see why this would be desirable. I do not see how running Stage simulations on a PDA could be useful in the real world. (though it would be cute). The real advantage of a Qt version would be that you'd have a good-looking 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. 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 frameworks 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 |
From: Paul O. <new...@ki...> - 2007-06-03 18:05:04
|
On Sun, 3 Jun 2007, Sidney Cadot wrote: >>> Did you consider porting Stage to Qt instead? >>> >>> Cheerio, >>> >>> Sidney > >> 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 > if >> they don't run Qtopia). > > I don't see why this would be desirable. I do not see how running Stage > simulations on a PDA could be useful in the real world. (though it would be > cute). 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 needs 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 simulation 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 this case, since there's no need to initialize all subsystems in main() function, they can be initialized as they're needed (for example, Video subsystem would be initialized only when Stage with GUI is used, otherwise, Player as an SDL app is still capable to be started in remote shell session). > > The real advantage of a Qt version would be that you'd have a good-looking > 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 either. > > 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 frameworks > 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. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Playerstage-developers mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-developers > |
From: Sidney C. <sid...@ji...> - 2007-06-03 18:53:14
|
Hi, > 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 needs > Player and Player should be able to run everywhere. Ok. I agree that having 'player' run on lowly systems is a must (after all, it also has to run on embedded robot controllers), but the ability to use a 'simulation' plugin on such systems is more a nice-to-have than anything else. > Personally I don't see nothing wrong in Stage being Player's plugin. At least in the current design of Stage, there is not a proper distinction between the "model" part of Stage (i.e., the simulator proper) and the "view/controller" part (i.e., the GUI). In a proper design, having the "model" part as a Player plugin is an option (although I see serious issues there, too), however IMHO the "view/controller" part should _definitely_ not be inside a plugin. All GUI frameworks that I am aware of want control of the main event loop, and this clashes bigtime with a gui-as-a-plugin player (because 'player' wants the same control of the event loop). > 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 simulation. > to test proposed plan before execution on the real devices, there's no > need to have GUI companion during this). While this is definitely an interesting application, I can only see this work if there is an API to instantiate a "simulation" instance at runtime (by a player client) -- if only for the simple reason that the timeline of speculative execution is different from the timeline of the "real world". This is a different discussion altogether from the GUI framework selection, though. > SDL may be helpful also in this > case, since there's no need to initialize all subsystems in main() > function, they can be initialized as they're needed (for example, Video > subsystem would be initialized only when Stage with GUI is used, > otherwise, Player as an SDL app is still capable to be started in > remote shell session). I figure that this is not a unique feature of SDL. Realistically, I think there are four contenders that could offer a cross-platform GUI framework: (1) wxWidgets: not my favorite by any stretch of the imagination, but it has a BSD license. I have some experience with it and on the whole, I think it is rather bad. The code base and programming model are messy. (2) Qt: my personal favorite. It has commercial-grade documentation and quality assurance, but it is basically GPL (which may be a bit of a problem, although for Player/Stage it seems a good choice). Its signals-and-slots programming model is awesome. (3) SDL: Don't know a lot about it, other than that it is pretty good at what it does. The main disadvantage that I can see is that it focusses on providing raw access to the screen and other hardware, while it does not emphasize integration in the platform's native GUI (correct me if I am wrong here). I am sure you can put up a window, but can you make an application that looks/feels like a native app? With proper dialogs etc.? What does the programming model look like? (4) GTK: I think it is not very nice to work with. And it doesn't port well to Windows/OSX. Now my take on this is that it would be time well spent to formulate a couple of requirements for a new Stage, then grade all options w.r.t. the requirements. It's a boring job and it's more exciting to just jump head-in, but this would definitely help to get all advantages/disadvantages of the different options in focus. > 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 either. I am pretty sure SDL works natively on the Mac, too. I wonder first and foremost how difficult it is to make a GUI-app that "feels good" on Windows and OSX. I have seen zero examples of GUI programs made in either wxWidgets or GTK, that work properly on the Mac, Linux, and Windows. For Qt, there is at least Opera and Skype. Cheerio, Sidney |
From: Richard v. <va...@cs...> - 2007-06-03 19:14:29
|
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 standalone app? Engineering reasons: 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. Research reason: 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. Future development: 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 elsewhere. 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. Richard/ 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? >>>> >>>> Cheerio, >>>> >>>> Sidney >> >>> 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 >> if >>> they don't run Qtopia). >> >> I don't see why this would be desirable. I do not see how running >> Stage >> simulations on a PDA could be useful in the real world. (though it >> would be >> cute). > > 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 > needs > 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 > simulation > 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 > this > case, since there's no need to initialize all subsystems in main() > function, they can be initialized as they're needed (for example, > Video > subsystem would be initialized only when Stage with GUI is used, > otherwise, Player as an SDL app is still capable to be started in > remote > shell session). > >> >> The real advantage of a Qt version would be that you'd have a good- >> looking >> 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 > either. > >> >> 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 >> frameworks >> 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. >> http://sourceforge.net/powerbar/db2/ >> _______________________________________________ >> Playerstage-developers mailing list >> Pla...@li... >> https://lists.sourceforge.net/lists/listinfo/playerstage-developers >> > > ---------------------------------------------------------------------- > --- > 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. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Playerstage-developers mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-developers |
From: Sidney C. <sid...@ji...> - 2007-06-03 23:03:26
|
Hi Richard, > FAQ candidate: Why is a Stage a library and Player plugin, and not a > standalone app? > 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. I will agree that good case can be made for the simulator proper to be implemented as a Player driver. A driver, after all, is nothing more than a piece of software that provides any number of interfaces to something that is an (actual or simulated) piece of hardware, and this is true for the simulator. Having the simulator GUI run from within a plugin, though, makes me cringe a bit -- it is at least an unusual design. Perhaps it would be possible to split the GUI and simulation functionalities. > 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. I like the idea of libstage (the simulator part) as a library; but I would prefer that the GUI part be less entwined. The Stage world needs models, their behavior and their polygon representations (for all the raytracing), but the rendering (using GTK primitives) seems a bit out of place. I'd rather see a possibility to implement different backend renderers next to each other: GTK, SDL, Qt, OpenGL, ... With callbacks in place to interact with the world models from the keyboard/mouse using the diverse rendering backends. > 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++). Yes, Qt is probably heavier weight, is C++ (which, I too, have mixed feeling about), and worst of all, it takes control of your build process (using "qmake" and the moc preprocessor). You do get a lot in return for that though. The bottom line: you wouldn't want to subjugate Qt to Player/Stage; rather (and this is an important point): the Player/Stage API should be good enough to make it possible to write a Qt-based app to control a simulation, in much the same way that the current GTK GUI works (from a users PoV). Similarly, you should be able to write a GLUT-app that does this, and an SDL version, and a GTK-version, ... That means there needs to be a properly defined interface between the simulator and the GUI. > Moving away from BSD sockets for Player is a big step, as is adding an > unusual dependency like SDL, so we should take care. I think it would be unfortunate to make a forced dependency on SDL. > Getting easy access to OpenGL and the sound hardware in a platform independent way > is going to be very important for me. This I don't understand. The way I look at it, OpenGL would be just another backend renderer that could be hooked up to the simulator. A backend could also support sound. But why the emphasis on SDL, or OpenGL - shouldn't the focus be on making the Stage architecture support /any/ backend, rather than any specific one? > Paul has done a lot of work on SDL already, and a proof of concept like that is worth a lot in my book. I would love to have a look at it. > 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. No argument there. I would be happy if I could compile even just Player in MinGW, so that I could run up our robot swarm control app in Windows for demo purposes -- oddly enough, the guys with the wallets tend to be more impressed with windows-based demos. Go figure. Cheerio, Sidney |
From: Richard v. <va...@cs...> - 2007-06-03 19:32:54
|
On 3-Jun-07, at 11:53 AM, Sidney Cadot wrote: > > In a proper design, having the "model" part as a Player plugin is > an option > (although I see serious issues there, too), however IMHO the > "view/controller" part should _definitely_ not be inside a plugin. > All GUI > frameworks that I am aware of want control of the main event loop, > and this > clashes bigtime with a gui-as-a-plugin player (because 'player' > wants the > same control of the event loop). Player/Stage (i.e. Player with the Stage plugin) already works this way. Most users don't see any "clashing bigtime". Most frameworks, including GTK+, allow event polling inside a custom main loop. GLUT is a naughty exception. I think FreeGLUT solves that problem. SDL allows custom main loops. >> 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 > simulation. >> to test proposed plan before execution on the real devices, >> there's no >> need to have GUI companion during this). > > While this is definitely an interesting application, I can only see > this > work if there is an API to instantiate a "simulation" instance at > runtime > (by a player client) -- if only for the simple reason that the > timeline of > speculative execution is different from the timeline of the "real > world". You can already do this by spawning new instances of Player/Stage. Your code can generate cfg and world files as needed. Don't forget about all the work the OS can do for you. However, an internal API for doing this is part of the plan, as writing text files is pretty ugly. Richard/ |
From: Sidney C. <sid...@ji...> - 2007-06-03 23:11:02
|
Hi Richard, > Player/Stage (i.e. Player with the Stage plugin) already works this > way. Most users don't see any "clashing bigtime". That's true, from a user's perspective it is all fine and dandy. I am talking from a software designer's perspective, though; then, having a GUI controlled from a plugin is pretty funky. > Most frameworks, > including GTK+, allow event polling inside a custom main loop. GLUT > is a naughty exception. I think FreeGLUT solves that problem. SDL > allows custom main loops. Yes, all these frameworks /allow/ that, but that doesn't make it the right thing to do. In general, I think it is a mistake for /any/ piece of software (be it a GUI toolkit or a robot control framework) to assume it is in control of the master thread. > > While this is definitely an interesting application, I can only see > > this work if there is an API to instantiate a "simulation" instance at > > runtime (by a player client) -- if only for the simple reason that the > > timeline of speculative execution is different from the timeline of the "real > > world". > > You can already do this by spawning new instances of Player/Stage. > Your code can generate cfg and world files as needed. Don't forget > about all the work the OS can do for you. I hope you agree that's not the most elegant way of doing things. > However, an internal API for doing this is part of the plan, as > writing text files is pretty ugly. Phew :) Cheerio, Sidney |
From: Geoffrey B. <g....@au...> - 2007-06-03 21:53:13
|
I think a misconception may need to be cleared up here. To my knowledge, SDL (Simple Direct*Media* Layer) does not provide a cross-platform GUI framework. It is designed to provide cross-platform access to the sorts of OS-specific facilities that games need: graphics rendering, sound output, input polling, etc. Not windows, buttons, menus and so forth. So it can't be compared with Qt, GTK and similar. Personally, I think the ideal solution would be to use SDL for all the media stuff and Qt for the windowing stuff, but that's just because I have experience with and am quite fond of both. Using SDL for the player server and client libraries to abstract away OS-specific issues around networking and timing would also be nice, but we need to consider if it will give an unwarranted library dependancy, given that it's not that difficult a job to abstract away such facilities that we need ourselves (I've done it more times than I really wanted to already in other projects, commercial and not). One way to avoid the dependancy on SDL, at least on the server side, could be to provide a libplayersdl alternative to libplayertcp, and only support that for the Windows release. Geoff Sidney Cadot wrote: > Realistically, I think there are four contenders that could offer a > cross-platform GUI framework: ... > (3) SDL: Don't know a lot about it, other than that it is pretty good at > what it does. The main disadvantage that I can see is that it focusses on > providing raw access to the screen and other hardware, while it does not > emphasize integration in the platform's native GUI (correct me if I am wrong > here). I am sure you can put up a window, but can you make an application > that looks/feels like a native app? With proper dialogs etc.? What does the > programming model look like? -- Robotics research group, University of Auckland http://www.ece.auckland.ac.nz/~gbig005/ |
From: Sidney C. <sid...@ji...> - 2007-06-03 23:20:21
|
Hi Geoff, > I think a misconception may need to be cleared up here. To my > knowledge, SDL (Simple Direct*Media* Layer) does not provide a cross-platform GUI > framework. It is designed to provide cross-platform access to the sorts > of OS-specific facilities that games need: graphics rendering, sound > output, input polling, etc. Not windows, buttons, menus and so forth. > So it can't be compared with Qt, GTK and similar. That's what I am worried about. The simulator /will/ need a menu bar, and all that stuff. > Personally, I think the ideal solution would be to use SDL for all the > media stuff and Qt for the windowing stuff, but that's just because I > have experience with and am quite fond of both. Out of curiosity: what functionality do you like about SDL that you cannot get out of Qt? The only thing I could think of is sound. Cheerio, Sidney |
From: Toby C. <tco...@pl...> - 2007-06-03 23:40:53
|
This has got a little sidetracked from where it started, which was using SDL to make the player *core* more portable. There is currently a very clear separation of UI code and server code in player. Slightly less so in stage, but still some. SDL was proposed as a way of making the sockets layer more portable, while I think this is an important goal (This is currently tagged for player 2.2, which should be much closer than 2.1 is to 2.0), I have not had trouble in the past getting sockets code to run on both windows and linux, from memory there is one extra call in windows to initialise the sockets and then they behave in the same manner. In theory porting the player core and client libraries to native win32 (without minGW?) should not be difficult. The hardest part would be getting the build process working nicely, and this has been done before in many projects. The player drivers and utilities are a different kettle of fish, but it would be easy enough to pick the low hanging fruit from these and disable the others for the windows build. With respect to Qt, it may be suitable for some aspects of the player project, but I personally would not want it in the core libraries. Also with respect to Qt's build process, yes you need moc, but you dont need qmake, in fact even in Qt oriented projects I have undertaken I tend to shy away from qmake as it is fairly limiting in your build targets (or alternatively my understanding is limiting of my use, same result either way :). Gtk is easy enough to get running in windows, there are windows binaries for it available, so there is really no need to reimplement the existing UI's to get a windows port running. So what we need is a windows user to take on board the windows port (which if we agree to SDL in the core is already underway) and to have all the changes merged into player head so that their are not two versions to maintain. Toby Sidney Cadot wrote: > Hi Geoff, > > >> I think a misconception may need to be cleared up here. To my >> knowledge, SDL (Simple Direct*Media* Layer) does not provide a >> > cross-platform GUI > >> framework. It is designed to provide cross-platform access to the sorts >> of OS-specific facilities that games need: graphics rendering, sound >> output, input polling, etc. Not windows, buttons, menus and so forth. >> So it can't be compared with Qt, GTK and similar. >> > > That's what I am worried about. The simulator /will/ need a menu bar, and > all that stuff. > > >> Personally, I think the ideal solution would be to use SDL for all the >> media stuff and Qt for the windowing stuff, but that's just because I >> have experience with and am quite fond of both. >> > > Out of curiosity: what functionality do you like about SDL that you cannot > get out of Qt? The only thing I could think of is sound. > > 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. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Playerstage-developers mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-developers > > |
From: Geoffrey B. <g....@au...> - 2007-06-04 00:01:15
|
I'm in favour of not needing to depend on SDL for the player core if at all possible. It may provide portability (and do so very well), but less dependancies is usually better if you don't need that much from the library. As I mentioned earlier, and as Toby said, portable sockets is not that hard to write. Toby is correct in that there is only some extra initialisation for Windows and then they behave the same. Going back to the very first post, other problems mentioned were the need for an XDR library (SDL won't help us here), endian-related issues (hton* and ntoh* seem to do the job just fine, and it wouldn't be hard to write functions to do other primitive data types, of which there are a very limited number). The timer is easy enough to abstract away and Windows does have a high-resolution timer available as part of the Win32 API. Threading is a bit more difficult, but I have twice in the past written threading systems that work on both Windows and Linux; the calls are named differently but the fundamentals are the same. Basically, I agree with Toby in that the hardest part of providing a Windows binary is, in fact, the build system. A port of autotools is available for Windows (http://gnuwin32.sourceforge.net/packages/autotools.htm), although I haven't used it so I don't know how good it is. We could also provide a Visual C project, if we want to make things really easy for people. They're not very hard to setup. Geoff Toby Collett wrote: > This has got a little sidetracked from where it started, which was using > SDL to make the player *core* more portable. There is currently a very > clear separation of UI code and server code in player. Slightly less so > in stage, but still some. > > SDL was proposed as a way of making the sockets layer more portable, > while I think this is an important goal (This is currently tagged for > player 2.2, which should be much closer than 2.1 is to 2.0), I have not > had trouble in the past getting sockets code to run on both windows and > linux, from memory there is one extra call in windows to initialise the > sockets and then they behave in the same manner. > > In theory porting the player core and client libraries to native win32 > (without minGW?) should not be difficult. The hardest part would be > getting the build process working nicely, and this has been done before > in many projects. The player drivers and utilities are a different > kettle of fish, but it would be easy enough to pick the low hanging > fruit from these and disable the others for the windows build. > > With respect to Qt, it may be suitable for some aspects of the player > project, but I personally would not want it in the core libraries. Also > with respect to Qt's build process, yes you need moc, but you dont need > qmake, in fact even in Qt oriented projects I have undertaken I tend to > shy away from qmake as it is fairly limiting in your build targets (or > alternatively my understanding is limiting of my use, same result either > way :). Gtk is easy enough to get running in windows, there are windows > binaries for it available, so there is really no need to reimplement the > existing UI's to get a windows port running. > > So what we need is a windows user to take on board the windows port > (which if we agree to SDL in the core is already underway) and to have > all the changes merged into player head so that their are not two > versions to maintain. > > Toby -- Robotics research group, University of Auckland http://www.ece.auckland.ac.nz/~gbig005/ |
From: Jack O'Q. <jac...@gm...> - 2007-06-04 01:50:24
|
On 6/3/07, Geoffrey Biggs <g....@au...> wrote: > Basically, I agree with Toby in that the hardest part of providing a > Windows binary is, in fact, the build system. A port of autotools is > available for Windows > (http://gnuwin32.sourceforge.net/packages/autotools.htm), although I > haven't used it so I don't know how good it is. We could also provide a > Visual C project, if we want to make things really easy for people. > They're not very hard to setup. SCONS is probably worth a look (http://www.scons.org/). I have not used it myself but people whose judgment I respect are using it for large open-source projects. It is implemented in python, and claims to have good support for Linux, Unix, OS X, and Windows. It appears to be fairly stable and mature at this point, and a *lot* cleaner than the automake tools. The SCONS equivalent of a Makefile is a SConstruct file, which is written in Python. -- joq |
From: Radu B. R. <ru...@cs...> - 2007-06-04 08:19:42
|
Toby Collett wrote: > This has got a little sidetracked from where it started, which was using > SDL to make the player *core* more portable. There is currently a very > clear separation of UI code and server code in player. Slightly less so > in stage, but still some. Toby, we'd also have to think about the drivers (which is sort of one of the main reasons people dive into Player). I'm afraid that some of them will just not work in Win without major modifications. :-/ There are a bunch of libraries we are dependent on, especially when it comes to exotic drivers. Cheers, Radu. -- | Radu Bogdan Rusu | http://rbrusu.com/ | http://www9.cs.tum.edu/people/rusu/ | Intelligent Autonomous Systems | Technische Universitaet Muenchen |
From: Richard v. <va...@cs...> - 2007-06-03 23:51:24
|
On 3-Jun-07, at 4:03 PM, Sidney Cadot wrote: >> Getting easy access to OpenGL and the sound hardware in a platform > independent way >> is going to be very important for me. > > This I don't understand. The way I look at it, OpenGL would be just > another > backend renderer that could be hooked up to the simulator. A > backend could > also support sound. But why the emphasis on SDL, or OpenGL - > shouldn't the > focus be on making the Stage architecture support /any/ backend, > rather than > any specific one? My experimental branch uses OpenGL to render geometry to produce robot sensor data. When hardware accelerated this could be very fast. Two more points - Stage used to be decoupled from its GUI back in the day (Arena & XS). This introduced significant overhead in IPC, and, more significantly in practice it meant that drawing stuff to aid debugging (I mean, who gets coordinate systems right first time?) was asynchronous and didn't play nice in the debugger. It is **really** useful to be able to draw geometry synchronously when developing models, let alone the Stage engine. Eventually Stage will just talk graphics3D and Player's driver will handle the rendering - want a different backend? use a different driver. Richard/ |
From: Toby C. <tco...@pl...> - 2007-06-04 00:27:46
|
Geoffrey Biggs wrote: > I'm in favour of not needing to depend on SDL for the player core if at > all possible. It may provide portability (and do so very well), but less > dependancies is usually better if you don't need that much from the > library. > > As I mentioned earlier, and as Toby said, portable sockets is not that > hard to write. Toby is correct in that there is only some extra > initialisation for Windows and then they behave the same. Going back to > the very first post, other problems mentioned were the need for an XDR > library (SDL won't help us here), endian-related issues (hton* and ntoh* > seem to do the job just fine, and it wouldn't be hard to write functions > to do other primitive data types, of which there are a very limited > number). The timer is easy enough to abstract away and Windows does > have a high-resolution timer available as part of the Win32 API. > Threading is a bit more difficult, but I have twice in the past written > threading systems that work on both Windows and Linux; the calls are > named differently but the fundamentals are the same. > There is a pthreads port for windows, it has worked fine for me in the past. If we are distributing windows binaries then less people will need to build from scratch anyway, making it easy to build against player rather than player itself should be the focus (and maybe some automated nightly builds?) > Basically, I agree with Toby in that the hardest part of providing a > Windows binary is, in fact, the build system. A port of autotools is > available for Windows > (http://gnuwin32.sourceforge.net/packages/autotools.htm), although I > haven't used it so I don't know how good it is. We could also provide a > Visual C project, if we want to make things really easy for people. > They're not very hard to setup. > > Geoff > > Toby Collett wrote: > >> This has got a little sidetracked from where it started, which was using >> SDL to make the player *core* more portable. There is currently a very >> clear separation of UI code and server code in player. Slightly less so >> in stage, but still some. >> >> SDL was proposed as a way of making the sockets layer more portable, >> while I think this is an important goal (This is currently tagged for >> player 2.2, which should be much closer than 2.1 is to 2.0), I have not >> had trouble in the past getting sockets code to run on both windows and >> linux, from memory there is one extra call in windows to initialise the >> sockets and then they behave in the same manner. >> >> In theory porting the player core and client libraries to native win32 >> (without minGW?) should not be difficult. The hardest part would be >> getting the build process working nicely, and this has been done before >> in many projects. The player drivers and utilities are a different >> kettle of fish, but it would be easy enough to pick the low hanging >> fruit from these and disable the others for the windows build. >> >> With respect to Qt, it may be suitable for some aspects of the player >> project, but I personally would not want it in the core libraries. Also >> with respect to Qt's build process, yes you need moc, but you dont need >> qmake, in fact even in Qt oriented projects I have undertaken I tend to >> shy away from qmake as it is fairly limiting in your build targets (or >> alternatively my understanding is limiting of my use, same result either >> way :). Gtk is easy enough to get running in windows, there are windows >> binaries for it available, so there is really no need to reimplement the >> existing UI's to get a windows port running. >> >> So what we need is a windows user to take on board the windows port >> (which if we agree to SDL in the core is already underway) and to have >> all the changes merged into player head so that their are not two >> versions to maintain. >> >> Toby >> > > > |
From: Paul O. <new...@ki...> - 2007-06-04 15:09:23
|
On Mon, 4 Jun 2007, Toby Collett wrote: > Geoffrey Biggs wrote: >> I'm in favour of not needing to depend on SDL for the player core if at >> all possible. It may provide portability (and do so very well), but less >> dependancies is usually better if you don't need that much from the >> library. >> >> As I mentioned earlier, and as Toby said, portable sockets is not that >> hard to write. Toby is correct in that there is only some extra >> initialisation for Windows and then they behave the same. Going back to >> the very first post, other problems mentioned were the need for an XDR >> library (SDL won't help us here), endian-related issues (hton* and ntoh* >> seem to do the job just fine, and it wouldn't be hard to write functions >> to do other primitive data types, of which there are a very limited >> number). The timer is easy enough to abstract away and Windows does >> have a high-resolution timer available as part of the Win32 API. >> Threading is a bit more difficult, but I have twice in the past written >> threading systems that work on both Windows and Linux; the calls are >> named differently but the fundamentals are the same. >> > There is a pthreads port for windows, it has worked fine for me in the > past. If we are distributing windows binaries then less people will need > to build from scratch anyway, making it easy to build against player > rather than player itself should be the focus (and maybe some automated > nightly builds?) I must admit, that personally I don't like Windows. I've choosen SDL as cross-platform library not only for making Windows binaries but also to make Player (and Stage) work with things like AmigaOS, BeOS, MorphOS and so on. From the other hand, as someone mentioned before, people with wallets use Windows and authorities of PJIIT (where I'm maintaining Virtual Robotics Laboratory) are examples of them - I must have at least Player client libraries and application for Windows to prove them that Virual Laboratory works fine - that was the primary reason for creating playerlibsdl. SDL does not suggest in any way how application should be written. It can use SDL just for networking, threads, timing, plugins loading (SDL_loadso) while GUI still can use gtk/glib pair, Qt or even GLUT (or Highgui from OpenCV). I was also wondering about using SDL for GUI "by the way" (if we're using SDL for low-level issues, why can't we use it for GUI?). There is actually demo GUI library for SDL called GUIlib, but in my opinion it's too simple. Once xfig code was used to create librtk2, why can't we get SDL GUI from other open-source SDL-based project? Many SDL games have nice GUI, most promissing is the one used in openttd project (imagine Stage and Playerv looking like that!). SDL does not limit programmer to use any specific language. Of course, people who loves C++ libraries that provide namespaces will not be satisfied (as SDLmm project seem to be dead back in 2001), but for those who have nothing about using C style calls in C++ code it's a good solution. So while thinking about portable Player we shouldn't focus only on BSD sockets replacement (or coexistance with winsock by separating both with #ifdef WIN32), but also: - threads (is pthread for windows good enough, is pthread on rtos like QNX or systems like AmigaOS available? From the other hand, is thread model in SDL_threads good enough? Or maybe let's use thread available in C++ STL templates, looks like there are headers for them in MinGW, which does not provide any other thread models when installed from scratch) - timing (if code must be portable, forget about using usleep, nanosleep, even gettimeofday may be problematic) - dynamic structures (glib is used for lists, STL templates can be used instead in C++ code) - plugin loading (different systems do this different ways, SDL_loadso seem to be solution) - hardware access (well, SDL is not a solution here! We can access audio and joystick "by the way", just because we're using SDL). I guess the main reason for running Player (as a Server this time) on Windows is the ability to start Stage simulation (during the classes for example when all the machines in the classroom are Windows PC's). Of course someone can make Video For Windows driver for camera devices or prepare smart way to avoid usage of termios.h, but these are sounds of the future. BTW, Player uses OpenCV for some drivers, while OpenCV can have access both to Video4Linux and Video For Windows cameras, why can't we rewrite camera driver to make use of it? - required libraries. Today these are: boost, glib2, gtk2 (with companions like pango, atk, cairo and so on), libgnomecanvas2 (used only if available), libjpeg, zlib, gsl, OpenCV. Last two are used only for some drivers and there are ports of both for different systems. Zlib and libjpeg are as common as we may not be worry about them. glib/gtk2 are also available on many different systems, but we may drop them if we feel that less dependencies is better (we can use SDL-based gui as I mentioned above). I don't know much about boost, why it is used (for threads I guess), what systems support it and so on. - endianess (for example in libplayerxdr), SDL seem to be the best solution for it, but also glib/gtk and other cross-platform libraries provide means to deal with endians. Keep in mind, that to have portable Player code we can't rely on glibc rpc/xdr, we must have our own implementation that does the same thing! Cheers, Paul |