From: Toby C. <tco...@pl...> - 2008-08-27 05:43:52
|
Hi all, I am developing an actarray model for stage, and have a bit of a conundrum which hopefully someone will have a good idea for. I have made an actuator model that allows a model to 'slide' down an axis, or rotate about the z axis (simulated scanning LMS200 anyone?). It needs a bit of cleaning up, but works pretty well. An example will probably explain my issue better. Say you are building an XY table simulation, in stage you create an X axis arm model, which has a child of a Y axis arm model. In player this makes more sense as a single actarray with two actuators. My problem is that the stage player interface is designed around a 1 to 1 ratio. So the three options are: 1) Rework the actuator model to support a chain of actuators as one model (a lot of complexity given stage already supports child models well) 2) Make the stage actarray player interface map one actarray to multiple stage models (My preferred option, but some suggested direction for this would be appreciated) 3) Just use an actarray per actuator and then merge them with some sort of virtual actarray driver (pretty much has Hack written all over it, so would like to avoid it). So if anyone has any ideas for the best way to go about this they would be greatly appreciated, Toby -- This email is intended for the addressee only and may contain privileged and/or confidential information |
From: gbiggs <gb...@ki...> - 2008-08-27 23:33:26
|
Toby and I, after a little discussion, have decided to set the Player 2.2 target release date for the middle of 2009. For those interested in helping out, the list of planned features can be found here: http://playerstage.sourceforge.net/wiki/Roadmap#Release_2.2 Most of these are not currently being worked on, and many would be a good place to start for a beginner Player developer who wants to learn how things work. The native win32 build is being worked on (progress was stalled while I obtained a working copy of Visual C++), I'm hoping to be able to get something into SVN after my current busy period ends in around November, for those who want to help out. If anyone is interested in tackling the Python bindings, investigation has shown that Swig is annoying to work with, SIP produces a much closer duplication of the API but is similarly annoying to work with, and Boost.Python produces the best API on the Python side but requires a lot of leg work. Toby and I also agree that new bindings should use the C++ client library rather than the C client library. Moving range sensor drivers to the new ranger interface needs to wait for the interface to be reworked. I'm planning on doing this by the end of the year. If you decide to tackle a feature, it might be a good idea to let the developers list know, so we avoid duplication of effort. Geoff |
From: Alexis M. <mal...@cs...> - 2008-08-28 09:03:21
|
Hi! On Thu, Aug 28, 2008 at 08:33:18AM +0900, gbiggs wrote: > If anyone is interested in tackling the Python bindings, investigation > has shown that Swig is annoying to work with, SIP produces a much closer > duplication of the API but is similarly annoying to work with, and > Boost.Python produces the best API on the Python side but requires a lot > of leg work. Toby and I also agree that new bindings should use the C++ > client library rather than the C client library. We had problems with the python bindings at the lab, and had one of our students rewrite them. Instead of fighting with SWIG, he decided to use the python ctypes library to wrap libplayerc (writing a parser for the headers in the process). The result works very well (still haven't found an interface that did not work), can be used in the same way as the current python bindings, and does not even need compilation (it is all python code). Since it has a parser, it does not need to be changed when a new interface is created, or fields are added to playerc.h. Less maintenance work! Please give it a try, Jonathan described it here: http://www.nabble.com/Python-bindings-p17273809.html It is all GPL code, and we would like it if it was integrated into the main Player tree. Let us know if you find things to fix! All the best, Alexis Maldonado http://www9.cs.tum.edu/people/maldonad |
From: gbiggs <gb...@ki...> - 2008-08-31 22:47:03
|
Any chance this could be adapted to use the C++ client library? Geoff Alexis Maldonado wrote: > Hi! > > On Thu, Aug 28, 2008 at 08:33:18AM +0900, gbiggs wrote: >> If anyone is interested in tackling the Python bindings, investigation >> has shown that Swig is annoying to work with, SIP produces a much closer >> duplication of the API but is similarly annoying to work with, and >> Boost.Python produces the best API on the Python side but requires a lot >> of leg work. Toby and I also agree that new bindings should use the C++ >> client library rather than the C client library. > > We had problems with the python bindings at the lab, and had one of our > students rewrite them. Instead of fighting with SWIG, he decided to use the > python ctypes library to wrap libplayerc (writing a parser for the headers > in the process). > > The result works very well (still haven't found an interface that did not > work), can be used in the same way as the current python bindings, and does > not even need compilation (it is all python code). > > Since it has a parser, it does not need to be changed when a new interface > is created, or fields are added to playerc.h. Less maintenance work! > > Please give it a try, Jonathan described it here: > http://www.nabble.com/Python-bindings-p17273809.html > > It is all GPL code, and we would like it if it was integrated into the main > Player tree. Let us know if you find things to fix! |
From: Geoffrey B. <geo...@ai...> - 2008-09-01 01:43:45
|
Any chance this could be adapted to use the C++ client library instead? Geoff Alexis Maldonado wrote: > Hi! > > On Thu, Aug 28, 2008 at 08:33:18AM +0900, gbiggs wrote: >> If anyone is interested in tackling the Python bindings, investigation >> has shown that Swig is annoying to work with, SIP produces a much closer >> duplication of the API but is similarly annoying to work with, and >> Boost.Python produces the best API on the Python side but requires a lot >> of leg work. Toby and I also agree that new bindings should use the C++ >> client library rather than the C client library. > > We had problems with the python bindings at the lab, and had one of our > students rewrite them. Instead of fighting with SWIG, he decided to use the > python ctypes library to wrap libplayerc (writing a parser for the headers > in the process). > > The result works very well (still haven't found an interface that did not > work), can be used in the same way as the current python bindings, and does > not even need compilation (it is all python code). > > Since it has a parser, it does not need to be changed when a new interface > is created, or fields are added to playerc.h. Less maintenance work! > > Please give it a try, Jonathan described it here: > http://www.nabble.com/Python-bindings-p17273809.html > > It is all GPL code, and we would like it if it was integrated into the main > Player tree. Let us know if you find things to fix! |
From: Brian G. <br...@ge...> - 2008-09-01 22:47:59
|
On Aug 26, 2008, at 10:44 PM, Toby Collett wrote: > > An example will probably explain my issue better. Say you are > building an XY table simulation, in stage you create an X axis arm > model, which has a child of a Y axis arm model. In player this makes > more sense as a single actarray with two actuators. My problem is > that the stage player interface is designed around a 1 to 1 ratio. > So the three options are: > 1) Rework the actuator model to support a chain of actuators as one > model (a lot of complexity given stage already supports child models > well) > 2) Make the stage actarray player interface map one actarray to > multiple stage models (My preferred option, but some suggested > direction for this would be appreciated) > 3) Just use an actarray per actuator and then merge them with some > sort of virtual actarray driver (pretty much has Hack written all > over it, so would like to avoid it). I like (2) the best, but don't have much insight into what would be required to make that happen inside Stage. brian. |