On Thu, 31 Mar 2011, Sylvain Joyeux wrote:

> On 03/30/2011 06:36 PM, Herman Bruyninckx wrote:
>> On Wed, 30 Mar 2011, Sylvain Joyeux wrote:
>>
>>> On 03/30/2011 11:26 AM, Geoffrey Biggs wrote:
>>>> On 29/03/11 18:40, Sylvain Joyeux wrote:
>>>>> The point is: you have to use ROS messages to use RTT components on
>>>>> the
>>>>> ROS transport. Which means that you have to have a working ROS IDL
>>>>> generator *and* support libraries available. It was not a judgmental
>>>>> comment, just a request for clarification (even though I personally
>>>>> believe that using IDLs is a bad idea there, but that's my personal
>>>>> opinion).
>>>>
>>>> Purely for academic reasons, could you explain what your reasons are
>>>> for
>>>> that opinion?
>>>
>>> Two main problems:
>>>
>>> 1. IDLs-generated data structures are unusable in themselves: you have
>>> the data, but you don't have the methods that allow you to manipulate
>>> that data. Of course, you could extend the IDL to handle that as well
>>> (in a way, that's what SWIG does, using C++ as the IDL), but it ends up
>>> being pretty nasty to look at.
>>>
>>> 2. from an academic point of view (i.e. "research"), one goal I have is
>>> to make the real stuff (in Hermanspeak, the "computation" part)
>>> independent of the "hot framework of today". That includes being
>>> independent of an IDL and/or an IDL generator. I want the real stuff to
>>> be written in the language of choice (admittedly, in rock, C++), and
>>> then have the tooling taking care of the interfacing.
>>>
>>> The plus side of IDLs, obviously, is that you define your types in a
>>> language-independent way. However, while I thought it was important in
>>> earlier times, I learned to feel that it is not such a core requirement
>>> in robotics, as most of the stuff is written in C++ anyway.
>>>
>>> That's the reason why orogen works this way: the main language is C++,
>>> but you can access the data structures defined in C++ from other
>>> languages (Ruby). I.e. the main target is C++, with the ability to use
>>> it in different languages. Not a "language independent definition".
>>
>> For your information, and for what it is worth: I am of the complete
>> opposite opinion, that is, I am a lot in favour of a "metamodel" of the
>> data (to be used, _both_, by the Computations _inside_ a component,
>> and the
>> _communication_ between components). My rationale: the current robotics
>> practice of coding everything in C++, and _only_ in C++, prevents any
>> kind
>> of "introspection". This leads to the mess of extremely difficult to
>> debug
>> software systems. Our "hackers" have become used to that situation, and
>> can't think out of the box anymore. I think I still can do the latter
>> thing, and I see a much nicer future, based on the "introspection"
>> capability. It is probably superfluous by now to say so, but (i)
>> "introspection" is _only_ possible via a metamodel, and (ii) what you
>> call
>> an "IDL" _is_ the simplest form of a metamodel, and only half of the
>> story:
>> the metamodel _also_ has to include the _operations_ represented in a
>> formal way, and not just the _data_.
> Typelib, which is what orogen is based on, *is* and introspection layer
> on top of C++ types. I.e., you don't need an IDL for that.

How useable is it _outside_ of the C++ code? Say, in a (programming
language agnostic) Eclipse-based MDE tool chain? Because that's the kind of
large-scale eco-system I am aiming at with my remarks.

> Yes, having models is important (I'm not so sure about the neverending
> addition of 'meta' prefixes).

You should then read the MDE standard about that: it stops at the
metametamodel level, for a very good reason :-)
For your information:
<http://people.mech.kuleuven.be/~bruyninc/images/OMG-metametamodel.pdf>
<http://people.mech.kuleuven.be/~bruyninc/images/OMG-transformations.pdf>

> I am of the opinion that the actual data
> structure definition is mostly irrelevant inside these models, i.e. that
> the information contained there is mostly unusable. I might be wrong,
> mind you, but I have yet to see usage of the actual data structure
> definition in model-based systems.

In our "component model", the Computations and Communications are now
decoupled via the Port/Service interfaces; the models (of data _and_
operations) should serve as the decoupled input to automatically generate
the "wrappers" between all three. Of course, when all three can _start_
from a _standard model_, the wrappers are not necessary.

I know the current practice is still far away from this 'dream', but
_somebody_ has to try to realise it :-)

> And, again, you can *in any case* have access to that definition even
> out of a C++ data structure.

Yes, but only by looking at the C++ code? If so, that the wrong, since
asymmetric, way of going to automation :-)

> And you are praying to the choir, as rock is -- at least for now -- the
> only available model-based system built on top of orocos/rtt.

Yes! :-) I would classify rock as the "M1" level in the MDE metamodel
approach (in the sense that it depends on the "C++ platform"), while I am
aiming at the "M2" (and later the "M3") levels; those will be fully
programming language independent, and indicate the _meaning_ of the data
structures.

FYI: our K.U.Leuven colleague Tinne De Laet will present a suggestion in
this direction on a workshop on standardisation at the upcoming European
Robotics Forum in Västerås, Sweden, next week Friday April 8th.

> Sylvain Joyeux

Herman
> Space& Security Robotics
>
> !!! Achtung, neue Telefonnummer!!!
>
> Standort Bremen:
> DFKI GmbH
> Robotics Innovation Center
> Robert-Hooke-Straße 5
> 28359 Bremen, Germany
>
> Phone: +49 (0)421 178-454136
> Fax: +49 (0)421 218-454150
> E-Mail: robotik [..] ...
>
> Weitere Informationen: http://www.dfki.de/robotik
> -----------------------------------------------------------------------
> Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
> Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
> Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
> (Vorsitzender) Dr. Walter Olthoff
> Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
> Amtsgericht Kaiserslautern, HRB 2313
> Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
> USt-Id.Nr.: DE 148646973
> Steuernummer: 19/673/0060/3
> -----------------------------------------------------------------------
>
>

--
K.U.Leuven, Mechanical Eng., Mechatronics & Robotics Research Group
<http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 328056
EURON Coordinator (European Robotics Research Network) <http://www.euron.org>
Open Realtime Control Services <http://www.orocos.org>
Associate Editor JOSER <http://www.joser.org>, IJRR <http://www.ijrr.org>

On Wednesday 30 March 2011 14:51:18 Sylvain Joyeux wrote:
> On 03/30/2011 10:58 AM, Ruben Smits wrote:
> > On 30 Mar 2011, at 10:51, Sylvain Joyeux wrote:
> >> On 03/30/2011 10:45 AM, Ruben Smits wrote:
> >>> On 29 Mar 2011, at 11:40, Sylvain Joyeux wrote:
> >>>> On 03/29/2011 11:22 AM, Ruben Smits wrote:
> >>>>> On 29 Mar 2011, at 10:06, Sylvain Joyeux wrote:
> >>>>>> AFAIK, the ROS transport requires at the moment all port types to be
> >>>>>> ROS messages, no ?
> >>>>>
> >>>>> Yes, we have to agree on the message type, but the messages are plain
> >>>>> c structs, I don't see a penalty for using these messages in your
> >>>>> components wrt to the flexibility we get.
> >>>>
> >>>> Mmmm ... We *always* have to agree on the message type. That's not the
> >>>> issue.
> >>>>
> >>>> The point is: you have to use ROS messages to use RTT components on
> >>>> the ROS transport. Which means that you have to have a working ROS
> >>>> IDL generator *and* support libraries available. It was not a
> >>>> judgmental comment, just a request for clarification (even though I
> >>>> personally believe that using IDLs is a bad idea there, but that's my
> >>>> personal opinion).
> >>>
> >>> I would be very interested in creating ROS messages from C++
> >>> type/struct definitions
> >>
> >> Well, that would be a pretty trivial matter using the typelib Ruby
> >> interface (limited to what typelib, e.g. typegen, can understand
> >> obviously). I can make a small script to show you the basics of how it
> >> can be done.
> >>
> >>> sure, attached a simple and more complex msg file with generated
> >>> header.
> >>
> >> What's your plan with typegen integration ? For now, typelib will bail
> >> out on structures that use inheritance (which the generated ROS
> >> structures do ...). I could add some support for that, but it would in
> >> the end still require that the ROS::Message class has no members (since,
> >> otherwise, the generated typekit would try to marshal these members ...)
> >>
> >> Is that the case ?
> >
> > http://www.ros.org/doc/api/roscpp/html/classros_1_1Message.html shows
> > that ros::Message is deprecated. Maybe it's better to ask this on the
> > ros-users or ros-developers mailinglist.
>
> What do you mean ? It is obviously generated by the ROS message
> generator ... So, if I want to parse generated ROS messages, I'll have
> to handle ROS::Message ... Deprecated or not ...

I believe they will drop ROS::Message when releasing ROS 2.0. The code to
catch-up is present already but not used afair.

>
> Moreover, the ROS messages are templated on the allocator type ... Not a
> blocker, but not nice (you need some tricks for gccxml to get template
> instances).

They have put these in place to allow real-time creation/deletion of messages.

Peter