Hi Jared,
Thanks very much for the post, worth considerably more than two cents.
I'm very pleased to hear that you get good use out of both Player and
Miro. I heard a talk about Miro on monday, and it looks to have some
very nice features. I have no argument against it at all. I would guess
that it is currently reused less than Player, and so has less impact on
the community's productivity. But let me make it clear: I would rather
that *both* projects were reused more, and research efficiency
increased accordingly.
I also have nothing against CORBA. On the contrary, it's a good example
of reused code and design in itself and therefore a Good Thing. But I'm
frustrated with people that suggest that their code uses CORBA,
therefore it is reusable. There's a lot more to it than that. Here's an
example:
After JPL's presentation at the ICRA "reusable robot code" workshop,
some wag in the audience says "Sounds great: I'd like to reuse that.
Where can I get it?". Answer: "Erm, you can't. Unless you get a US
government contract in partnership with JPL". That's quite a barrier to
reuse. I talked to another (anonymous) JPL robot builder who does have
access to the code, but finds it so big, complex and poorly documented
to be unusable **even in the same lab**. But it uses CORBA, so its
reusable, right?
My argument at the workshop was that there's more to reuse than your
choice of framework. My four steps to reusable robot code are:
1. write something so great and useful that people want to use it
because it makes their life better
2. document it to help users get value out of it
3. release it as open source, and preferably Free Software, so people
can get it
4. maintain and support it, because the code becomes very valuable
and deserves attention
All these steps are necessary for reuse to happen. Most projects fail
on one or more of these points. That doesn't stop them being
technically wonderful projects, but it makes them less reusable.
My justification for this claim is primarily that robot code is that
same as other code. Apache, BIND, Sendmail, Linux, GCC, glibc all score
on these points. Photoshop, Windows, Word and Visual C++ score on these
points apart from open source, but they have a large market to drive
them. Robot code doesn't have a large market, and a significant part of
the market that does exist is academic and therefore not rolling in
cash. Free Software removes this obstacle to reuse.
So that's hopefully a little more clear and less flippant than my last
post in this thread.
cheers,
Richard.
On 20-Apr-05, at 6:00 PM, Jared Giesbrecht wrote:
> Richard,
>
> I am with Defence R&D Canada - Suffield, working in the Autonomous Land
> Systems group. I believe you've probably had discussions with people in
> our group in the past. I found your post below interesting, and wanted
> to reply to it.
>
> I just wanted to comment on my experiences here with regards to
> software
> reusability. We have been using Player/Stage here since last May, both
> in simulation, and on Segway RMPs, with Sick lasers and GPS. We made
> use
> of Player laser, Segway, and VFH drivers. We found it to be a very
> useful project, and would like to complement the work you folks have
> done.
>
> This summer, we are working on a demonstration of robotic outdoor all-
> terrain vehicles, using a software project called Miro, from the
> University of Ulm. They have been using it on their Sparrows Robocup
> soccer team.
>
> http://smart.informatik.uni-ulm.de/MIRO/content.html#Overview
>
> It is based on Corba and ACE, and although it provides a great deal of
> flexibility, also has a good deal more overhead in terms of software
> and
> also in terms of learning time/complexity. But it is also very
> powerful.
> It allows us to more easily define our own interfaces between modules
> using the Interface Description Language, or modify existing ones to
> suit our purposes. It also allows us to abstract away from specific
> network topologies and move processes around by means of a Naming
> Service and Corba message passing. It also uses Corba for event driven
> messages with callback functions in the software modules. As a great
> bonus, it has also been integrated with Player/Stage, so we can freely
> use software from both, simultaneously. Unfortunately, it is not nearly
> as well documented as Player/Stage.
>
> I am not in any way criticizing Player/Stage, just that it had
> different
> design philosophies than Miro. My conclusion is this: With both
> software
> packages, the code which was most easily reusable was that which had a
> specific, well contained purpose. The underlying medium or structure
> for
> them to communicate is what the the toolkit/project should provide, but
> doesn't necessarily dictate how reusable the code created will be.
>
> Player has chosen to provide a medium using a centralized server and
> TCP/IP, with well established interfaces. Miro has designed to do this
> with a more distributed approach, providing a Corba layer of
> abstraction
> above TCP/IP, and more flexible interfaces. However, we have found a
> great deal of reusable code in both. I can't speak for .NET, Java, etc,
> but I think it may be unfair for you to direct an argument against
> Corba. I believe that in many ways, Player and/or Corba are just ways
> of
> allowing different software modules to interact. The important part of
> creating reusable software is that the different pieces need to be able
> to stand alone and provide functionality on their own.
>
> Anyway, that's just my two cents! Once again, good work on
> Player/Stage!
>
> Jared Giesbrecht
> Defence Scientist
> Autonomous Land Systems
> Defence R&D Canada Suffield
> Phone: 403-544-4709
> Email: Jared.Giesbrecht@...
>
> On Wed, 2005-04-20 at 15:05 +0200, Richard Vaughan wrote:
>> On 20-Apr-05, at 2:42 PM, Radu Bogdan Rusu wrote:
>>
>>>
>>> We're on it. Expect an upgrade of Javaclient sometime next week. That
>>> is, if
>>> you don't code it yourself until then :)
>>
>> Nice one Radu. The Open Source magic at work.
>>
>> I'm at ICRA speaking at a workshop on reusable robot code, explaining
>> that big corporate CORBA Enterprise Java Beans .NET requirements
>> documents standards committee software engineering tends not to
>> encourage code reuse in practice. Our little Free Software project
>> does. And you just proved it, assuming that the code shows up :)
>>
>> Richard.
>>
>>
>>> Cheers,
>>> Radu.
>>>
>>> --
>>> | Radu Bogdan 'veedee' Rusu | http://www.rbrusu.com
>>> | Javaclient for P/S/G | http://java-player.sf.net
>>> | The optimist sees a task in every problem.
>>> | The pessimist sees a problem in every task.
>>>
>>> On Wed, Apr 20, 2005 at 02:29:09PM +0200, Richard Vaughan wrote:
>>>>
>>>> Hi Steffen,
>>>>
>>>> Stage 1.6 doesn't support the 'truth' interface: its functionality
>>>> has
>>>> been replaced by the 'simulation' interface. The good news is that
>>>> you
>>>> have already created a simulation interface - the first section in
>>>> the
>>>> cfg file. The bad news is that the Java client library may not
>>>> support
>>>> the simulation interface yet. I added it to the C++ client library,
>>>> and
>>>> I don't remember hearing that anyone ported it to Java. It should be
>>>> pretty easy to add yourself, using the C++ lib as a model.
>>>>
>>>> Hope that helps,
>>>> Richard.
>>>>
>>>>
>>>> On 20-Apr-05, at 2:18 PM, Steffen Jaensch wrote:
>>>>
>>>>> Hi all,
>>>>> ?
>>>>> I want to use the Truth Interface with a Java Client, but I still
>>>>> struggle with the configuration for the Player Server.
>>>>> My .cfg file looks like this:
>>>>> ?
>>>>>
>>>>>
>>>>> # load the Stage plugin simulation driver
>>>>> driver
>>>>> (??
>>>>> ? name "stage"
>>>>> ? provides ["simulation:0"]
>>>>> ? plugin "libstage"
>>>>> ?
>>>>> ? # load the named file into the simulator
>>>>> ? worldfile "simple.world"?
>>>>> )
>>>>> ?
>>>>> driver
>>>>> (
>>>>> ? name "stage"
>>>>> ? provides ["position:0" "laser:0" "truth:0"]
>>>>> ? model "robot"
>>>>> )
>>>>> ?
>>>>> and the .world file like this:
>>>>> ?
>>>>>
>>>>> # Desc: 1 pioneer robot with laser?
>>>>> # CVS: $Id: simple.world,v 1.31 2005/02/08 06:50:01 rtv Exp $
>>>>> ?
>>>>> # defines Pioneer-like robots
>>>>> include "pioneer.inc"
>>>>> ?
>>>>> # defines 'map' object used for floorplans
>>>>> include "map.inc"
>>>>> ?
>>>>> # set the size of a pixel in meters
>>>>> resolution 0.02
>>>>> ?
>>>>> # configure the GUI window
>>>>> window
>>>>> (
>>>>> ? size [ 662.000 654.000 ]
>>>>> ? center [0.221 -0.005]
>>>>> ? scale 0.025
>>>>> )
>>>>> ?
>>>>> # load an environment bitmap
>>>>> map
>>>>> (
>>>>> ? bitmap "bitmaps/cave.png"
>>>>> ? size [15 15]
>>>>> ? boundary 1
>>>>> )
>>>>> ?
>>>>> # create a robot
>>>>> pioneer2dx
>>>>> (
>>>>> ? name "robot"
>>>>> ? pose [2 1 0]
>>>>> ? laser()
>>>>> )
>>>>> ?
>>>>> ?
>>>>> When I try to start Player I get the following error message:
>>>>> ?
>>>>> linux:~/playerstage/stage # player
>>>>> /usr/local/share/stage/worlds/simple.cfg
>>>>> ** Player v1.6.2 **? [TCP]
>>>>> ?
>>>>> Parsing configuration file
>>>>> "/usr/local/share/stage/worlds/simple.cfg"
>>>>> PLAYERPATH: /usr/local/lib
>>>>> trying to load /usr/local/lib/libstage...success
>>>>> invoking player_driver_init()...success
>>>>> ? Stage driver creating 1 device
>>>>> ??? mapping device 6665.31.0 => "simple.world" [Include
>>>>> pioneer.inc][Include map.inc] done.
>>>>> ? Stage driver creating 3 devices
>>>>> ??? mapping device 6665.4.0 => "robot"
>>>>> ??? mapping device 6665.6.0 => "robot.laser:0"
>>>>> ??? mapping device 6665.15.0 => err: error: stage driver doesn't
>>>>> support interface type 15
>>>>> ?(stg_driver.cc StgDriver)
>>>>> error?? : Initialization failed for driver "stage"
>>>>> linux:~/playerstage/stage #
>>>>> What can I do to make it running?
>>>>> ?
>>>>> Thanks,
>>>>> Steffen
>>>>>
>>>> --
>>>> Richard Vaughan
>>>> School of Computing Science / Simon Fraser University
>>>>
>>>>
>>>>
>>>> -------------------------------------------------------
>>>> This SF.Net email is sponsored by: New Crystal Reports XI.
>>>> Version 11 adds new functionality designed to reduce time involved
>>>> in
>>>> creating, integrating, and deploying reporting solutions. Free
>>>> runtime info,
>>>> new features, or free trial, at:
>>>> http://www.businessobjects.com/devxi/728
>>>> _______________________________________________
>>>> Playerstage-users mailing list
>>>> Playerstage-users@...
>>>> https://lists.sourceforge.net/lists/listinfo/playerstage-users
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> This SF.Net email is sponsored by: New Crystal Reports XI.
>>> Version 11 adds new functionality designed to reduce time involved in
>>> creating, integrating, and deploying reporting solutions. Free
>>> runtime
>>> info,
>>> new features, or free trial, at:
>>> http://www.businessobjects.com/devxi/728
>>> _______________________________________________
>>> Playerstage-users mailing list
>>> Playerstage-users@...
>>> https://lists.sourceforge.net/lists/listinfo/playerstage-users
>>>
>> --
>> Richard Vaughan
>> School of Computing Science / Simon Fraser University
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by: New Crystal Reports XI.
>> Version 11 adds new functionality designed to reduce time involved in
>> creating, integrating, and deploying reporting solutions. Free
>> runtime info,
>> new features, or free trial, at:
>> http://www.businessobjects.com/devxi/728
>> _______________________________________________
>> Playerstage-users mailing list
>> Playerstage-users@...
>> https://lists.sourceforge.net/lists/listinfo/playerstage-users
>
>
>
--
Richard Vaughan
School of Computing Science / Simon Fraser University
|