Re: [Orca-robotics-devel] Re: [Playexrstage-developers] Common robotics data exchange format...?

Herman,

Could you explain a bit more what your vision is?  Perhaps with some
example data structures?

I'm confused because you talk about defining data structures, which to
me indicates making some choices about representation, eg. XML, packed
binary, IDL, etc, but this doesn't seem to be your intent.

Secondly, could you explain why you say the data representation is more
important than the communications infrastructure?  Surely both have to
match for two systems to inter-operate.


Cheers,

Alex

On Sun, 2004-08-15 at 04:23, Herman Bruyninckx wrote:
> On Fri, 13 Aug 2004, Brian Gerkey wrote:
> 
> > On Fri, 13 Aug 2004, Herman Bruyninckx wrote:
> >
> >> I'm responsible for the Orocos project, <http://www.orocos.org>, and
> >> one issue that surfaces in most of my discussions with contributors to
> >> open source robotics projects is the standardisation of "objects" and
> >> the protocols to exchange such objects in distributed systems.
> >
> > hi Herman,
> >
> > This is an enormous and ambitious undertaking, and we've already
> > seen the failure of at least one concerted effort at it: the RETF
> > (http://www.robo-etf.org/).
> >
> > The goals of the RETF were very much what you've mentioned: specify
> > standards for interchange of commands and data for every kind of robot
> > device.
> 
> I know, and that's way I explicitly limit the ambition to data
> structures only (and also of _robots_ only, not (in a first stage)
> sensors, shape, etc.). Certainly no protocols, or no APIs, because
> both of these belong to _architectures of applications_ and not to the
> pure data in a system. Trying to get these two out of each other's field
> of view was (and still is) one of the main motivations behind Orocos :-)
> 
> > They also started with the Player interface spec.  There was
> > an active mailing list for several months (which I think you, Herman,
> > were also on), 
> Yes, but I was never too excited about it. But their draft does remain
> something to take into account very seriously.
> 
> > The group got bogged down immediately in questions like: Do we make
> > a "specification" or an "API"?  How do we define devices? What's
> > the right level of abstraction?  Do we exchange data is a tight
> > binary format or XML?  We lacked a consensus on any of these issues.
> Exactly! I do not want to get involved in these discussions: they will
> follow naturally _after_ projects start to use the data structure
> standard. (_If_ they do :-)
> 
> > One immediately obvious problem was that the people who build systems from
> > microcontrollers and PWM motors have a distinctly different worldview from
> > those who use off-the-shelf research robots that carry workstation-class
> > computers (in my opinion, this particular chasm cannot be bridged).
> I agree. I want to focus on the latter type of robotics.
> 
> >   (i) Be less ambitious.  We've done well with Player, not by identifying
> >       how to interact with all possible devices, but by handling the
> >       obvious ones, and then being flexible and inclusive, considering
> >       and incorporating each new kind of device as it comes along.
> >       If we set out to "cover all thinkable robot structures," we'd
> >       never actually write any software.
> We don't have to write any software :-) And with "robotic structures" I
> just meant the kinematic structure, i.e., specifying the joint and
> Cartesian motion capabilities of the devices, nothing more. As I said
> before: no sensors, etc.
> 
> >  (ii) Have discussion, but assert control.  Not everybody will like your
> >       standard, but don't worry about them.  I believe community
> >       consensus on this topic to be unattainable, and one of the
> >       frailties of the RETF was that it lacked any authority figure
> >       (which could be either an individual or a small group) to actually
> >       make decisions.  As a result, discussion ranged far and wide,
> >       with little in the way of tangible results.
> I agree here also. And my concrete suggestion is: _you_ will be the
> controlling "authority", i.e., Player/Stage decides what they want to
> use, and the other projects follow or leave. The reason for this is
> simple: you're the only one with a world-wide and broad user base.
> 
> [...]
> > Another popular system is CARMEN, from CMU/Stanford/MIT:
> >  http://www-2.cs.cmu.edu/~carmen/
> > In my experience, the CARMEN folks are less interested in standards-making
> > than some other projects, but it would be remiss to leave them out.
> No problem with that.
> 
> > To be clear, I don't mean to sound overly pessimistic about this idea;
> > I just don't want to see a repeat of the RETF....
> I think we are on the same wavelength :-)
> 
> Herman



-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285