[prev in list] [next in list] [prev in thread] [next in thread] 

List:       orocos-dev
Subject:    [Orocos-Dev] About user data types&transports in 2.0
From:       Herman.Bruyninckx () mech ! kuleuven ! be (Herman Bruyninckx)
Date:       2010-03-21 16:20:30
Message-ID: alpine.DEB.2.00.1003211717330.3385 () roble
[Download RAW message or body]

On Fri, 19 Mar 2010, Sylvain Joyeux wrote:

> Herman Bruyninckx wrote:
>> On Fri, 19 Mar 2010, Sylvain Joyeux wrote:
>>
>>> Herman Bruyninckx wrote:
>>>> On Wed, 17 Mar 2010, Sylvain Joyeux wrote:
>>>>
>>>>
>>>>> Peter Soetens wrote:
>>>>>
>>>>>> On Wed, Mar 17, 2010 at 10:04, Sylvain Joyeux
>>>>>> <sylvain.joyeux at dfki.de> wrote:
>>>>>>
>>>>>>
>>>>>>> Actually, I still have a problem with having "plain" datatypes. I
>>>>>>> still feel
>>>>>>> that having data types without the methods to manage them is
>>>>>>> annoying (at
>>>>>>> best).
>>>>>>>
>>>>>>>
>>>>>> I've been thinking about this when I looked into ros::Time and
>>>>>> ros::Duration. The solution I had there was that you can write
>>>>>> classes
>>>>>> (with methods) that accept initialisation from the plain data type.
>>>>>> The class could inherit from the plain data type too. It's not
>>>>>> something we need to enforce, they are just options. What I do
>>>>>> like is
>>>>>> that the transport only transports plain data, and nothing else.
>>>>>> CORBA
>>>>>> and other middlewares went way to far trying to pass on objects. It
>>>>>> adds way to much coupling.
>>>>>>
>>>>>>
>>>>>>
>>>>>>> What I thought is that, as an *alternative* to what you propose
>>>>>>> (i.e. both
>>>>>>> methods would be supported by orogen), orogen could verify that a
>>>>>>> human-designed C++ structure does match a ros-IDL type. That
>>>>>>> would allow to
>>>>>>> extend the C++ type while still making sure that we retain
>>>>>>> compatibility
>>>>>>> with the common datatype pool.
>>>>>>>
>>>>>>> Thoughts ?
>>>>>>>
>>>>
>>>> Yes :-) I beg you to accept the advice of a veteran of many of these
>>>> "interoperability wars" (that I all lost, by the way...) and put the
>>>> priority at _first_ defining the _semantics_ of the data types, in a
>>>> formal,
>>>> symbolic language, and _only then_ think about data structures in
>>>> whatever
>>>> programming language (preferably generated automatically).
>>>> Otherwise, you
>>>> will be bitten severely by the "semantic gap" effect: at the C++ level,
>>>> both communicating sides agree completely, but the meaning of each or
>>>> several of the data fields that match in IDL or C++ are inconsistent
>>>> in the
>>>> real physical world.
>>>>
>>>> Examples:
>>>> - whatever coordinate representation that one uses, one _must_ define
>>>>    physical units, frame reference points, order of relative frames,
>>>>    velocity reference point, order of angular and linear components,...
>>>>    of all data types. That means at least a dozen or so 'semantic
>>>> tags' for
>>>>    each definition of a 6D geometric or kinematic data structure.
>>>> - whatever control algorithm that one uses, one _must_ define in
>>>> what order
>>>>    every "control error" is calculated as the difference which two
>>>> other
>>>>    data structures, their physical units, the interpretation of bounds
>>>>    (saturation, thresholds, uncertainty, ...)
>>>> I can give some more examples of data interoperability wars that I have
>>>> lost...
>>>>
>>> Yes, this "semantic tagging" as you call it is important. Unfortunately,
>>> enforcing that at the code level would either require a lot of C++
>>> templating or a static code analysis tool a-la sparse (which checks for
>>> mixing incompatible memory pointers in the Linux kernel).
>>>
>>> So we're left with a simple "tagging" (i.e. documentation), which is
>>> already done -- at least in my lab -- by documenting the data
>>> structures.
>>
>> But that is NOT ENOUGH!!!! And without having seen your documentation,
>> I am
>> quite sure it is _not_ semantically complete...
> Yes. That was the exact point I was trying to make. Except that going up
> to the point that it becomes *usable on a real-world system* will need a
> lot of work.
>
> Here's the thing: I already have too much trouble having people
> undestand that *basic* model based deployment is worth the effort. I
> personally have other priorities, and, anyway, since I'm not a PhD
> anymore, I could not spend years until I have something that can be
> published. Moreover, I am not in the position of deciding this kind of
> resouce investment in a lab, so that it manages to cover the needs of a
> real-world system.
>
> So, at least for my side, it will stay at the discussion level in the
> foreseeable future.

Very understandable! Because that missing semantic layer is a _huge_
investment, that no lab could (should!) be doing on its own...

I have some hope to be able to realise some progress in this matter via two
different ways:
- there is a growing awareness of the problem, also within the large
   European research projects such as Rosetta, RoboEarth, Cotesys,... and I
   think something will come out of their cooperations.
- there is the idea of setting up a PhD School on robotics, at the European
   level, and there students can be used to work on the semantic layer,
   since that's exactly the layer that is used during teaching.
But don't hold your breath :-)

Herman

[prev in list] [next in list] [prev in thread] [next in thread]