On 18-Nov-05, at 6:23 AM, Reed Hedges wrote:
Hello Stage developers and others,
I'm wrapping up another version of MobileSim in the next week or so. MobileSim is our replacement to the old SRISim, built using libstage. It uses stage for the simulation, but instead of interfacing with player, it provides an emulated Pioneer robot connection over a TCP port using the pioneer p2os/aros/arcos/et al protocol.
I've made a variety modifications to libstage for this version of MobileSim, and want to discuss with everyone if you want any of them in libstage in some form or other. Eventually I'd like to be building MobileSim against a minimally-modified Stage -- so I'm especially interested in your thoughts on ways for an application to provide customizations to stage through its API (see below for a few things I've done along this line).
Let me know if you want my diff against Stage 2.0.0a (this diff will be included with the MobileSim source code of course, which can be obtained at http://robots.activmedia.com/MobileSim
. I haven't seperated it into seperate patches for each feature yet since some of the changes are pervasive throughout Stage.
Apologies for the information dump here! Let me know if you want me to start bringing these things up one at a time in the future :)
This all sounds good, Reed. I'm very happy that libstage has a double life at least. I know of some other folks using it directly for purpose-built simulations for particular experiments, too.
Some comments by items below:
This is not used by MobileSim, but could be useful for MobileSim and other applications that use and customize libstage: Stage keeps a table of model type names and their 'init' functions in a list in typetable.c. I added a new list called user_typetable which stage will also search when loading a world. The user application can add new model types to this list which are not built-in models of stage.
Nice, I'll look at this with interest.
Since MobileSim must also run on Windows, I built libstage in MinGW with just a few minor modifications (mostly to the autoconf script and the 'replacements' library, and a few random bits of code in stage itself) and use existing ports of GTK and pthreads to Windows.
Since Windows doesn't have an X11 "rgb.txt" file, I have a few hard coded values that stage falls back on checking if there is no X11 rgb.txt file or if a color is not found in that file.
Very useful, excellent!
3. GTK 2.0 and gcc 2.95
Since we still support crusty old RedHat 7.3 with all software, I had to build stage with gcc 2.95 and GTK 2.0. The gcc 2.95 changes are pervasive throughout stage: since it doesn't fully implement c99, all variable declarations have to be at the beginning of a function or other block. (Making this change throughout stage kind of sucked, but I get paid to do this kind of stuff...!). For GTK 2.0, the biggest change was in the menus. GTK 2.4 has the "actions" and ui_mananger, while for GTK 2.0 you have to use the old ItemFactory system that previous versions of stage used to create the menus. This is not a pretty change either, since it involves some ugly kluges with macros and ifdefs.
So I don't know if you actually want either of these changes in stage or not, or maybe there is a cleaner way to do the GTK 2.0 changes.
As we approach 2006, I think it's time to assume C99 in new code. I've also been assuming GTK-2.0 for a year or so now. Seems reasonable, again for new code, though I understand your reasons for adding backwards compatibility. I don't know of a great way to handle this, and I'd like to keep away from tons of #ifdefs to keep the code readable. Anyone feel strongly about this?
I wanted to display information, errors and warnings from MobileSim to the user in a more obvious way than stdout (especially on Windows where you normally can't see it at all), so I added a new model called messages, and a new pane to the stage gui at the bottom where messages may be written. The messages model accepts new log messages at three levels (notification, warning, error) via a property and prints them to the log pane in the gui. If you want, you might consider this a "simulation" of an LCD display on a robot, I guess.
That's a great idea - I'd love to have that feature in libstage for 2.0. I'm cooking up a scheme for clients to display arbitrary graphics in the Stage window, but that is a way off yet.
5. options for built in models
Since MobileSim doesn't provide any way to use them, I simply omitted the blobfinder, fiducial and gripper models from stage by adding some configure script options and config.h symbols.
6. options and API for the gui
Made it possible to use different mouse buttons for panning/zooming/etc. in the gui by configuring it in the world file.
I added a function to change the window title, and to change the cursor to/from a "busy", hourglass cursor. Also functions to open a fatal error dialog box (with buttons to exit or continue anyway).
Also made the mouse scroll wheel zoom the world.
7. about box
Made the about box a lot more complicated :) There are a bunch of predefined strings that the application can modify by setting it's own name and version to display in addition to the stage version, etc. It uses GTK 2.6's pretty dialog box if available, on previous versions it just creates an ugly but functional one..
8. user properties
Similar to user models, this lets the user application query extra properties for a model in the world file that the model itself doesn't actually use. For example, MobileSim uses this to get values required to emulate the Pioneer robot protocol but which really don't make any sense for stage itself (like the weird conversion factors it uses for odometry and speeds). MobileSim starts by loading a world file fragment that has model definitions for all the different pioneer-based robot types (PioneerRobotModels.world.inc which I've posted on the mailing list before, I think). These model definitions include these custom pioneer-specific properties. MobileSim "registers" these property names (e.g. "pioneer_distconv") for the position model, and then later it can query the values of these on specific model instances.
9. model query API
added a few functions to the public api which allows the user application to find model instances, and get the names and type strings for models, etc.
10. Laser noise
Added two types of laser noise. One is random error in the angles at which it takes readings. The other is simple noise in the range readings reported back. Qualitatively, the former matches more or less what a sick does. Configurable in the world file of course.
11. Ranger (sonar) noise and projection/collision policy configuration
Adds a bit of random error to range readings. You can also choose from a couple policies for actually projecting the ranger's rays and determining the range to obstacles: (a) Like it does now, projecting a single ray for each ranger, (b) projecting several rays within the ranger's FOV and returning the smallest range, (c) like b but optionally disregarding the reading if the difference between the shortest and longest ray is too great -- this is a quick and dirty way to try to get something like erroneous sonar return on high angle of incidence. it might not be that useful, actually, and MobileSim doesn't use it currently.
12. Position control, relative position control, accelleration and deceleration in position model.
To emulate the Pioneer's MOVE, HEAD and DHEAD commands I added position control to the position model (we have discussed this a bit in the past). It's not perfect but does the job (does anyone actually use the MOVE command anyway?). Also added basic aceleration and deceleration.
position control is implemented in libstage CVS HEAD. Also the position device has configurable odometry drift model that will be useful to some people.
A lot of tiny things I've now forgotten about, such as minor fixes, documentation, adding some trivial functions to the public API, etc.
All very good. After a few weeks off (due to teaching, etc.) I'm actively working on Stage again. I'll scheme with Brian to get a near-simultaneous 2.0 release before too long.