From: Douglas S. B. <db...@br...> - 2004-06-10 18:14:09
|
Player/Stage developers, I'm looking at reworking our Python codebase that sits on Player. We've been using Boyoon Jung's pure Python code (which is quite nice), but we'd like to remove that layer, and tie it more closely with the C++ code. I'm wondering if anyone has tried to use SWIG (Simplified Wrapper and Interface Generator, www.swig.org) on the C++ code? The great thing about doing this would be that there wouldn't need to be other layers to maintain, and all of the latest C++ functions would instantly be available to all of the languages that SWIG supports (ie, Ruby, Python, Perl, Guile, Java, etc). SWIG does a great job making, for example, Python classes out of C++ classes. It can also make native Python lists out of C++ STL lists (which would be much nicer than using the string representation of lists that the Player C-based pyplayer code uses). I don't mind working on this, if it hasn't been done before. If anyone has any prior work, warnings, or suggestions, please let me know. Otherwise, I'll dig in... Thanks, -Doug -- Douglas S. Blank, Assistant Professor db...@br..., (610)526-6501 Bryn Mawr College, Computer Science Program 101 North Merion Ave, Park Science Bld. Bryn Mawr, PA 19010 dangermouse.brynmawr.edu |
From: Douglas S. B. <db...@br...> - 2004-06-11 01:49:26
|
[I'm CCing this to the list, as I include an example, and attach some questions on method-naming philosophy. -Doug] ahoward <ah...@po...> said privately: > On Thu, 10 Jun 2004, Douglas S. Blank wrote: > > > (which would be much nicer than using the string representation of lists > > that the Player C-based pyplayer code uses). > > I'm curious: what do you mean by "string representation"? pyplayerc uses > plain Python lists. Thanks for questioning that statement! I was used to exploring Python objects via the "dir(object)" function, which lists out an object's methods and attributes. However, this doesn't show the functions that are coded in the __getattr__ C function in playerc, and I could only figure out how to get laser data by forcing a laser object into a string (I didn't think that you would have us get data that way!). Looking at the source code shows the proper way: import playerc client = playerc.client(None, "localhost", 6665) client.connect() laser = playerc.laser(client, 0) laser.subscribe("a") client.read() data = laser.scan When I'm done, I hope to also have an player/examples/python directory for the project. If there are already Python examples, please point me to them. On a different note, I know that a goal of the Player/Stage project is to create a Unix file system-like interface for robots and their devices, and that many of the devices have low-level Read/Write methods. But, it seems that each device has its own method names in the higher-level interfaces (ie, GetSonarGeom and SetLaserState in the C++ interface). Has any thought been given to trying to standardize to a smaller set of method names there as well? Like: set, get, setPose, getPose, print, config, etc. It seems that even laser and sonar devices in the C++ interface have very differently named methods. In using Player/Stage for teaching robotics, it would be nice if those objects that share many attributes (range sensors) shared method names. I think I'd rather see methods like: object.get("capacity") and object.get("state") rather than having each device have different method names like object.getLaserState(). These could be added in addition to the current methods, as to not break existing code. Or maybe I'm just not seeing such an interface? Thanks again, -Doug > > A. > > > Andrew Howard email: ah...@po... > Department of Computer Science http: www-robotics.usc.edu/~ahoward > University of Southern California phone: 1 (213) 740 6416 > Los Angeles, CA, U.S.A. 90089-0781 fax: 1 (213) 821 5696 > << Insert pithy saying here >>> -- Douglas S. Blank, Assistant Professor db...@br..., (610)526-6501 Bryn Mawr College, Computer Science Program 101 North Merion Ave, Park Science Building Bryn Mawr, PA 19010 dangermouse.brynmawr.edu |