Orocos and ros transport

Hi,

maybe I have misunderstood the concept of transport or the Orocos/Ros
cooperation, but i would like to ask he to some clarification.

I have the idea that Ros has a good way to send messages between components
but lacks a system like mqueue in realtime like Orocos.

Orocos relays the communication in non rt systems between components with
Corba, but it's a bit complex to configure for a new user.

Actually, some important part of the Orocos users are using Ros, specially the
transport layer and some components.

Are this concepts true?

Regards,

Leo

--

Orocos and ros transport

On Sat, 26 Mar 2011, Leopold Palomo-Avellaneda wrote:

> maybe I have misunderstood the concept of transport or the Orocos/Ros
> cooperation, but i would like to ask he to some clarification.
>
> I have the idea that Ros has a good way to send messages between components
> but lacks a system like mqueue in realtime like Orocos.

In addition, Orocos also has a lockfree Communication, of hard realtime,
in-process data exchange.

> Orocos relays the communication in non rt systems between components with
> Corba, but it's a bit complex to configure for a new user.

CORBA is _not_ a requirement for using Orocos. It's one of the (well)
supported "communication middlewares".

> Actually, some important part of the Orocos users are using Ros, specially the
> transport layer and some components.
Yes, and "the ROS way" of communicating is another supported middleware.

> Are this concepts true?

It _is_ true, indeed, that (i) Orocos is commmunication middleware agnostic
(as it _should_ be), and (ii) it has support for some "important" (what's
in a name :-)) communication middlewares. This designed-in flexibility and
decoupling is a feature for advanced users, but can be confusing for
beginning users.

Do you think some kind of documentation is missing somewhere to make this
picture more clear? And if so, what should be in that document?

> Regards,
>
> Leo

Herman

Orocos and ros transport

A Dissabte, 26 de març de 2011, Herman Bruyninckx va escriure:
> On Sat, 26 Mar 2011, Leopold Palomo-Avellaneda wrote:
>
> > maybe I have misunderstood the concept of transport or the Orocos/Ros
> > cooperation, but i would like to ask he to some clarification.
> >
> > I have the idea that Ros has a good way to send messages between
components
> > but lacks a system like mqueue in realtime like Orocos.
>
> In addition, Orocos also has a lockfree Communication, of hard realtime,
> in-process data exchange.
>
> > Orocos relays the communication in non rt systems between components with
> > Corba, but it's a bit complex to configure for a new user.
>
> CORBA is _not_ a requirement for using Orocos. It's one of the (well)
> supported "communication middlewares".
>
> > Actually, some important part of the Orocos users are using Ros, specially
the
> > transport layer and some components.
> Yes, and "the ROS way" of communicating is another supported middleware.
>
> > Are this concepts true?
>
> It _is_ true, indeed, that (i) Orocos is commmunication middleware agnostic
> (as it _should_ be), and (ii) it has support for some "important" (what's
> in a name :-)) communication middlewares. This designed-in flexibility and
> decoupling is a feature for advanced users, but can be confusing for
> beginning users.
>
> Do you think some kind of documentation is missing somewhere to make this
> picture more clear? And if so, what should be in that document?

well,

I remember some slides from Peter in Donosti where he exposed that ROS got
200+ tutorials. I don't need 200 tutorial, but some more documentation.
However, I understand the constraints, and the critical mass and the resources
of ROS couldn't compare with Orocos.

To be more specific, if I would create a Orocos component that publish in the
ROS way a message, how can I do it? I need the complete ros ecosystem?

Regards,

Leo

Orocos and ros transport

2011/3/28 Leopold Palomo-Avellaneda <leopold [dot] palomo [..] ...>

> A Dissabte, 26 de març de 2011, Herman Bruyninckx va escriure:
> > On Sat, 26 Mar 2011, Leopold Palomo-Avellaneda wrote:
> >
> > > maybe I have misunderstood the concept of transport or the Orocos/Ros
> > > cooperation, but i would like to ask he to some clarification.
> > >
> > > I have the idea that Ros has a good way to send messages between
> components
> > > but lacks a system like mqueue in realtime like Orocos.
> >
> > In addition, Orocos also has a lockfree Communication, of hard realtime,
> > in-process data exchange.
> >
> > > Orocos relays the communication in non rt systems between components
> with
> > > Corba, but it's a bit complex to configure for a new user.
> >
> > CORBA is _not_ a requirement for using Orocos. It's one of the (well)
> > supported "communication middlewares".
> >
> > > Actually, some important part of the Orocos users are using Ros,
> specially
> the
> > > transport layer and some components.
> > Yes, and "the ROS way" of communicating is another supported middleware.
> >
> > > Are this concepts true?
> >
> > It _is_ true, indeed, that (i) Orocos is commmunication middleware
> agnostic
> > (as it _should_ be), and (ii) it has support for some "important" (what's
> > in a name :-)) communication middlewares. This designed-in flexibility
> and
> > decoupling is a feature for advanced users, but can be confusing for
> > beginning users.
> >
> > Do you think some kind of documentation is missing somewhere to make this
> > picture more clear? And if so, what should be in that document?
>
> well,
>
> I remember some slides from Peter in Donosti where he exposed that ROS got
> 200+ tutorials. I don't need 200 tutorial, but some more documentation.
> However, I understand the constraints, and the critical mass and the
> resources
> of ROS couldn't compare with Orocos.
>
> To be more specific, if I would create a Orocos component that publish in
> the
> ROS way a message, how can I do it? I need the complete ros ecosystem?
>
>
I don't know what is the minimal installation, but I you want something
working with ROS from 0 you may follow theses guides :
http://www.ros.org/wiki/ROS/Installation
http://www.ros.org/wiki/orocos_toolchain_ros

I don't know if there is a way to just add ROS integration into an existing
pure Orocos toolchain. Maybe a look into

http://git.mech.kuleuven.be/robotics/orocos_toolchain_ros.git could help you

> Regards,
>
> Leo
>
>
> --
> --
> Leopold Palomo-Avellaneda <leopold [dot] palomo [..] ...>
> Institut d'Organització i Control de Sistemes Industrials
> Universitat Politècnica de Catalunya
> Avda. Diagonal 647, pl. 11
> 08028 BARCELONA (Spain)
>
> Tel. +34-934017163
> Fax. +34-934016605
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>

Ruben Smits's picture

Orocos and ros transport

On 28 Mar 2011, at 19:18, Willy Lambert wrote:

2011/3/28 Leopold Palomo-Avellaneda <leopold [dot] palomo [..] ...<mailto:leopold [dot] palomo [..] ...>>
A Dissabte, 26 de març de 2011, Herman Bruyninckx va escriure:
> On Sat, 26 Mar 2011, Leopold Palomo-Avellaneda wrote:
>
> > maybe I have misunderstood the concept of transport or the Orocos/Ros
> > cooperation, but i would like to ask he to some clarification.
> >
> > I have the idea that Ros has a good way to send messages between
components
> > but lacks a system like mqueue in realtime like Orocos.
>
> In addition, Orocos also has a lockfree Communication, of hard realtime,
> in-process data exchange.
>
> > Orocos relays the communication in non rt systems between components with
> > Corba, but it's a bit complex to configure for a new user.
>
> CORBA is _not_ a requirement for using Orocos. It's one of the (well)
> supported "communication middlewares".
>
> > Actually, some important part of the Orocos users are using Ros, specially
the
> > transport layer and some components.
> Yes, and "the ROS way" of communicating is another supported middleware.
>
> > Are this concepts true?
>
> It _is_ true, indeed, that (i) Orocos is commmunication middleware agnostic
> (as it _should_ be), and (ii) it has support for some "important" (what's
> in a name :-)) communication middlewares. This designed-in flexibility and
> decoupling is a feature for advanced users, but can be confusing for
> beginning users.
>
> Do you think some kind of documentation is missing somewhere to make this
> picture more clear? And if so, what should be in that document?

well,

I remember some slides from Peter in Donosti where he exposed that ROS got
200+ tutorials. I don't need 200 tutorial, but some more documentation.
However, I understand the constraints, and the critical mass and the resources
of ROS couldn't compare with Orocos.

To be more specific, if I would create a Orocos component that publish in the
ROS way a message, how can I do it? I need the complete ros ecosystem?

We only depend on the ros and ros_comm stack, the ros stack only contains the tooling like rospack, rosbuild, rosbash etc and ros_comm only contains communication specific packages for messaging, services, the rosmaster, param server etc.

All other stacks are opt-in.

I don't know what is the minimal installation, but I you want something working with ROS from 0 you may follow theses guides :
http://www.ros.org/wiki/ROS/Installation
http://www.ros.org/wiki/orocos_toolchain_ros

I don't know if there is a way to just add ROS integration into an existing pure Orocos toolchain. Maybe a look into

http://git.mech.kuleuven.be/robotics/orocos_toolchain_ros.git could help you

In theory this should be possible, I don't know whether someone already tried it though.

-- Ruben

Regards,

Leo

--
--
Leopold Palomo-Avellaneda <leopold [dot] palomo [..] ...<mailto:leopold [dot] palomo [..] ...>>
Institut d'Organització i Control de Sistemes Industrials
Universitat Politècnica de Catalunya
Avda. Diagonal 647, pl. 11
08028 BARCELONA (Spain)

Tel. +34-934017163
Fax. +34-934016605
--
Orocos-Users mailing list
Orocos-Users [..] ...<mailto:Orocos-Users [..] ...>
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users

<ATT00001..txt>

Orocos and ros transport

AFAIK, the ROS transport requires at the moment all port types to be ROS
messages, no ?

Sylvain

Ruben Smits's picture

Orocos and ros transport

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.

In Leuven we switched to using messages for all port data, even if it will never be connected to ROS topics.

I already tried to create typekits from the generated headers using typegen, it's not working yet, but I'm getting close.

> Sylvain

-- Ruben

Orocos and ros transport

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).

We are discussing at DFKI the possibility to integrate ROS nodes in
Rock. The plan was to not use the ROS message IDL, but to map C++ data
types to the ROS messages. The reason is that we want libraries to NOT
depend on the ROS IDL types, and *definitely* not want to have to copy
the data from libraries to ROS messages (and back) all the time.

Could you send me a struct generated by the ROS IDL generator ? Just for
reference...

Orocos and ros transport

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?

Geoff

Orocos and ros transport

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".

Orocos and ros transport

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_.

Herman

Orocos and ros transport

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.

Yes, having models is important (I'm not so sure about the neverending
addition of 'meta' prefixes). 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.

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

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.

--
Sylvain Joyeux
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
-----------------------------------------------------------------------

Orocos and ros transport

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>

Orocos and ros transport

On 03/31/2011 09:53 AM, Herman Bruyninckx wrote:
>> 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 :-)
So, here we are. Your problem is not having a model (which is doable
when using C++ as IDL). It is having a language-agnostic model. Which,
as I stated, I don't see that as a big advancement.

>> 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.
You cannot represent "meaning". You can only label "stuff" in a
human-readable way. I.e. you can say that a double is an angle, and have
a type system that forbids mixing angles with lengths. But's that having
a formal type system, not "meaning".

> 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.
I won't come in sweden. Realized the workshop's existence too late.

Orocos and ros transport

On Thu, 31 Mar 2011, Sylvain Joyeux wrote:

> On 03/31/2011 09:53 AM, Herman Bruyninckx wrote:
>>> 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 :-)
> So, here we are. Your problem is not having a model (which is doable
> when using C++ as IDL). It is having a language-agnostic model. Which,
> as I stated, I don't see that as a big advancement.

Ok, you are entitled to your own opinion :-)

>>> 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.
> You cannot represent "meaning". You can only label "stuff" in a
> human-readable way. I.e. you can say that a double is an angle, and have
> a type system that forbids mixing angles with lengths. But's that having
> a formal type system, not "meaning".

Don't try to diverge the attention to the ethernal philosophical debates :-)

That formal type system is already worth _a lot_, especially in the
vendor/language/plaform-neutral "app store" world of robot software
components that is my "big project" :-)

>> 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.
> I won't come in sweden. Realized the workshop's existence too late.

No problem! There will most probably be material available later on.

> Sylvain Joyeux (Dr.Ing.)

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>

Orocos and ros transport

On 03/31/2011 11:44 AM, Herman Bruyninckx wrote:
>> You cannot represent "meaning". You can only label "stuff" in a
>> human-readable way. I.e. you can say that a double is an angle, and have
>> a type system that forbids mixing angles with lengths. But's that having
>> a formal type system, not "meaning".
>
> Don't try to diverge the attention to the ethernal philosophical debates
> :-)
>
> That formal type system is already worth _a lot_, especially in the
> vendor/language/plaform-neutral "app store" world of robot software
> components that is my "big project" :-)
Agreed. But I find it very disturbing to say that "formal systems" add
"meaning" to things. This is not a philosophical debate, it is a very
important point.

Formal systems are sets labels and rules. "Meaning" is how we human
mistakenly interpret them. The issue with mixing the two is that users,
when presented as their models giving "meaning", end up wondering why
the software system cannot guess that X should not be done on Y.

Well, that's the point: it can't unless you give it the corresponding rule.

Ruben Smits's picture

Orocos and ros transport

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

> We are discussing at DFKI the possibility to integrate ROS nodes in
> Rock. The plan was to not use the ROS message IDL, but to map C++ data
> types to the ROS messages. The reason is that we want libraries to NOT
> depend on the ROS IDL types, and *definitely* not want to have to copy
> the data from libraries to ROS messages (and back) all the time.
>
> Could you send me a struct generated by the ROS IDL generator ? Just for
> reference...

sure, attached a simple and more complex msg file with generated header.

-- Ruben

Orocos and ros transport

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 ?

Ruben Smits's picture

Orocos and ros transport

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.

-- Ruben

Orocos and ros transport

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 ...

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).

Sylvain

Orocos and ros transport

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