Wiki page summarizing the results of the ERF meeting

Submitted by Sylvain Joyeux on Wed, 2012-03-21 09:37

RTT-dev

http://www.orocos.org/wiki/main-page/development/orocos-developers-meetu...

Sylvain

Wiki page summarizing the results of the ERF meeting

Submitted by Charles Lesire-... on Tue, 2012-06-26 08:32.

2012/3/21 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>

>
> http://www.orocos.org/wiki/main-page/development/orocos-developers-meetu...
>

Hi all,

What's the status of the "Dataflow between ROS and Rock / plain Orocos"?

I am definitely looking for a way to make my Orocos components usable in a
ROS network without having them depending on ROS, i.e. components' ports
have non-ROS types!

Charles.

> Sylvain
> --
> Orocos-Dev mailing list
> Orocos-Dev [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>

Wiki page summarizing the results of the ERF meeting

Submitted by peter on Tue, 2012-06-26 08:52.

Hi Charles,

On Tue, Jun 26, 2012 at 10:28 AM, Charles Lesire-Cabaniols <
charles [dot] lesire [..] ...> wrote:

>
>
> 2012/3/21 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>
>
>>
>> http://www.orocos.org/wiki/main-page/development/orocos-developers-meetu...
>>
>
> Hi all,
>
> What's the status of the "Dataflow between ROS and Rock / plain Orocos"?
>
> I am definitely looking for a way to make my Orocos components usable in a
> ROS network without having them depending on ROS, i.e. components' ports
> have non-ROS types!
>

I had spent a few hours on this, but didn't get far yet, let alone test the
code. You can see my progress on my github account here:

https://github.com/psoetens/orocos-rtt/commits/master-flexiport

The idea is that two major additions must be in place:

1. Create a channel element which can receive type A and send out type B
(data flow conversion)
2. Extend the transport mechanism such that it tries harder to find a
transport for type A (eg non-ros) by converting it to type B (ros msg type)
using step 1. and then sending out the ROS message B. This would
automatically work for other transports as well, as long as the RTT type
info constructor A<->B is known.

So our users would create a 'ROS' transport for type A, although A is ROS
independent, but does have a constructor in type B for creating a B from an
A.

This also depends on the type system refactoring I completed earlier (see
commit history) but didn't dare to post yet :-) I guess it's sorta out
now...

The type info redux patchset passes all unit tests, but there are no
patches yet for OCL or oro/typegen, although these are expected to be minor
and consequent. The last part is especially why I didn't push anything like
this to master yet...

Peter

>
>
> Charles.
>
>
>
>> Sylvain
>> --
>> Orocos-Dev mailing list
>> Orocos-Dev [..] ...
>> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>>
>
>
> --
> Orocos-Dev mailing list
> Orocos-Dev [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>
>

Wiki page summarizing the results of the ERF meeting

Submitted by willy on Tue, 2012-06-26 10:40.

2012/6/26 Peter Soetens <peter [..] ...>:
> Hi Charles,
>
> On Tue, Jun 26, 2012 at 10:28 AM, Charles Lesire-Cabaniols
> <charles [dot] lesire [..] ...> wrote:
>>
>>
>>
>> 2012/3/21 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>
>>>
>>>
>>> http://www.orocos.org/wiki/main-page/development/orocos-developers-meetu...
>>
>>
>> Hi all,
>>
>> What's the status of the "Dataflow between ROS and Rock / plain Orocos"?
>>
>> I am definitely looking for a way to make my Orocos components usable in a
>> ROS network without having them depending on ROS, i.e. components' ports
>> have non-ROS types!
>
>
> I had spent a few hours on this, but didn't get far yet, let alone test the
> code. You can see my progress on my github account here:
>
> https://github.com/psoetens/orocos-rtt/commits/master-flexiport
>
> The idea is that two major additions must be in place:
>
> 1. Create a channel element which can receive type A and send out type B
> (data flow conversion)
> 2. Extend the transport mechanism such that it tries harder to find a
> transport for type A (eg non-ros) by converting it to type B (ros msg type)
> using step 1. and then sending out the ROS message B. This would
> automatically work for other transports as well, as long as the RTT type
> info constructor A<->B is known.

This will be a very nice feature.

>
> So our users would create a 'ROS' transport for type A, although A is ROS
> independent, but does have a constructor in type B for creating a B from an
> A.
>
> This also depends on the type system refactoring I completed earlier (see
> commit history) but didn't dare to post yet :-) I guess it's sorta out
> now...
>
> The type info redux patchset passes all unit tests, but there are no patches
> yet for OCL or oro/typegen, although these are expected to be minor and
> consequent. The last part is especially why I didn't push anything like this
> to master yet...
>
> Peter
>
>>
>>
>>
>> Charles.
>>
>>
>>>
>>> Sylvain
>>> --
>>> Orocos-Dev mailing list
>>> Orocos-Dev [..] ...
>>> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>>
>>
>>
>> --
>> Orocos-Dev mailing list
>> Orocos-Dev [..] ...
>> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>>
>
>
> --
> Orocos-Dev mailing list
> Orocos-Dev [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>

Wiki page summarizing the results of the ERF meeting

Submitted by Charles Lesire-... on Tue, 2012-06-26 09:00.

2012/6/26 Peter Soetens <peter [..] ...>

> Hi Charles,
>
> On Tue, Jun 26, 2012 at 10:28 AM, Charles Lesire-Cabaniols <
> charles [dot] lesire [..] ...> wrote:
>
>>
>>
>> 2012/3/21 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>
>>
>>>
>>> http://www.orocos.org/wiki/main-page/development/orocos-developers-meetu...
>>>
>>
>> Hi all,
>>
>> What's the status of the "Dataflow between ROS and Rock / plain Orocos"?
>>
>> I am definitely looking for a way to make my Orocos components usable in
>> a ROS network without having them depending on ROS, i.e. components' ports
>> have non-ROS types!
>>
>
> I had spent a few hours on this, but didn't get far yet, let alone test
> the code. You can see my progress on my github account here:
>
> https://github.com/psoetens/orocos-rtt/commits/master-flexiport
>
> The idea is that two major additions must be in place:
>
> 1. Create a channel element which can receive type A and send out type B
> (data flow conversion)
> 2. Extend the transport mechanism such that it tries harder to find a
> transport for type A (eg non-ros) by converting it to type B (ros msg type)
> using step 1. and then sending out the ROS message B. This would
> automatically work for other transports as well, as long as the RTT type
> info constructor A<->B is known.
>
> So our users would create a 'ROS' transport for type A, although A is ROS
> independent, but does have a constructor in type B for creating a B from an
> A.
>
> This also depends on the type system refactoring I completed earlier (see
> commit history) but didn't dare to post yet :-) I guess it's sorta out
> now...
>
> The type info redux patchset passes all unit tests, but there are no
> patches yet for OCL or oro/typegen, although these are expected to be minor
> and consequent. The last part is especially why I didn't push anything like
> this to master yet...
>

I can help, at least in testing, if you give me some tips how to get all
the necessary sources, and what kind of basic tests I could make.

I can even participate to the development if you give me quite "clear"
instructions :)

Charles.

>
> Peter
>
>
>>
>>
>> Charles.
>>
>>
>>
>>> Sylvain
>>> --
>>> Orocos-Dev mailing list
>>> Orocos-Dev [..] ...
>>> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>>>
>>
>>
>> --
>> Orocos-Dev mailing list
>> Orocos-Dev [..] ...
>> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>>
>>
>

Wiki page summarizing the results of the ERF meeting

Submitted by peter on Tue, 2012-06-26 09:32.

Hi Charles,

On Tue, Jun 26, 2012 at 10:58 AM, Charles Lesire-Cabaniols <
charles [dot] lesire [..] ...> wrote:

>
>
> 2012/6/26 Peter Soetens <peter [..] ...>
>
>> Hi Charles,
>>
>> On Tue, Jun 26, 2012 at 10:28 AM, Charles Lesire-Cabaniols <
>> charles [dot] lesire [..] ...> wrote:
>>
>>>
>>>
>>> 2012/3/21 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>
>>>
>>>>
>>>> http://www.orocos.org/wiki/main-page/development/orocos-developers-meetu...
>>>>
>>>
>>> Hi all,
>>>
>>> What's the status of the "Dataflow between ROS and Rock / plain Orocos"?
>>>
>>> I am definitely looking for a way to make my Orocos components usable in
>>> a ROS network without having them depending on ROS, i.e. components' ports
>>> have non-ROS types!
>>>
>>
>> I had spent a few hours on this, but didn't get far yet, let alone test
>> the code. You can see my progress on my github account here:
>>
>> https://github.com/psoetens/orocos-rtt/commits/master-flexiport
>>
>> The idea is that two major additions must be in place:
>>
>> 1. Create a channel element which can receive type A and send out type B
>> (data flow conversion)
>> 2. Extend the transport mechanism such that it tries harder to find a
>> transport for type A (eg non-ros) by converting it to type B (ros msg type)
>> using step 1. and then sending out the ROS message B. This would
>> automatically work for other transports as well, as long as the RTT type
>> info constructor A<->B is known.
>>
>> So our users would create a 'ROS' transport for type A, although A is ROS
>> independent, but does have a constructor in type B for creating a B from an
>> A.
>>
>> This also depends on the type system refactoring I completed earlier (see
>> commit history) but didn't dare to post yet :-) I guess it's sorta out
>> now...
>>
>> The type info redux patchset passes all unit tests, but there are no
>> patches yet for OCL or oro/typegen, although these are expected to be minor
>> and consequent. The last part is especially why I didn't push anything like
>> this to master yet...
>>
>
> I can help, at least in testing, if you give me some tips how to get all
> the necessary sources, and what kind of basic tests I could make.
>
> I can even participate to the development if you give me quite "clear"
> instructions :)
>

Ok. The first thing to test then is plain OCL. I just built OCL 2.5 against
rtt's master-typeinfo-redux and it builds, and the deployer can use the rtt
or ros types.

What I need help with next is testing this in a real application, and then
also looking at how orogen/typegen works with this. If you report errors,
we can see how we can fix RTT or orogen to work with it...

I just did a forced-push of master-typeinfo-redux to github such that you
can test the 'working' code independent of the flexiport branch (which is
not building). It's master + toolchain-2.5 + typeinfo redux, hence all
current patches are in that branch.

Cheers,
Peter

Wiki page summarizing the results of the ERF meeting

Submitted by Charles Lesire-... on Thu, 2012-06-28 17:04.

2012/6/26 Peter Soetens <peter [..] ...>

> Hi Charles,
>
> On Tue, Jun 26, 2012 at 10:58 AM, Charles Lesire-Cabaniols <
> charles [dot] lesire [..] ...> wrote:
>
>>
>>
>> 2012/6/26 Peter Soetens <peter [..] ...>
>>
>>> Hi Charles,
>>>
>>> On Tue, Jun 26, 2012 at 10:28 AM, Charles Lesire-Cabaniols <
>>> charles [dot] lesire [..] ...> wrote:
>>>
>>>>
>>>>
>>>> 2012/3/21 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>
>>>>
>>>>>
>>>>> http://www.orocos.org/wiki/main-page/development/orocos-developers-meetu...
>>>>>
>>>>
>>>> Hi all,
>>>>
>>>> What's the status of the "Dataflow between ROS and Rock / plain Orocos"?
>>>>
>>>> I am definitely looking for a way to make my Orocos components usable
>>>> in a ROS network without having them depending on ROS, i.e. components'
>>>> ports have non-ROS types!
>>>>
>>>
>>> I had spent a few hours on this, but didn't get far yet, let alone test
>>> the code. You can see my progress on my github account here:
>>>
>>> https://github.com/psoetens/orocos-rtt/commits/master-flexiport
>>>
>>> The idea is that two major additions must be in place:
>>>
>>> 1. Create a channel element which can receive type A and send out type B
>>> (data flow conversion)
>>> 2. Extend the transport mechanism such that it tries harder to find a
>>> transport for type A (eg non-ros) by converting it to type B (ros msg type)
>>> using step 1. and then sending out the ROS message B. This would
>>> automatically work for other transports as well, as long as the RTT type
>>> info constructor A<->B is known.
>>>
>>> So our users would create a 'ROS' transport for type A, although A is
>>> ROS independent, but does have a constructor in type B for creating a B
>>> from an A.
>>>
>>> This also depends on the type system refactoring I completed earlier
>>> (see commit history) but didn't dare to post yet :-) I guess it's sorta out
>>> now...
>>>
>>> The type info redux patchset passes all unit tests, but there are no
>>> patches yet for OCL or oro/typegen, although these are expected to be minor
>>> and consequent. The last part is especially why I didn't push anything like
>>> this to master yet...
>>>
>>
>> I can help, at least in testing, if you give me some tips how to get all
>> the necessary sources, and what kind of basic tests I could make.
>>
>> I can even participate to the development if you give me quite "clear"
>> instructions :)
>>
>
> Ok. The first thing to test then is plain OCL. I just built OCL 2.5
> against rtt's master-typeinfo-redux and it builds, and the deployer can use
> the rtt or ros types.
>

Both rtt master-typeinfo-redux and OCL 2.5 built correctly. The deployer
launches.
As I am not familiar with Orocos/ROS integration, how could I check that
ROS types are correctly managed by the deployer?

>
> What I need help with next is testing this in a real application, and then
> also looking at how orogen/typegen works with this. If you report errors,
> we can see how we can fix RTT or orogen to work with it...
>

Ok. I have some components with typegen generated typekits. I will try to
compile them against your rtt's branch.

>
> I just did a forced-push of master-typeinfo-redux to github such that you
> can test the 'working' code independent of the flexiport branch (which is
> not building). It's master + toolchain-2.5 + typeinfo redux, hence all
> current patches are in that branch.
>
> Cheers,
> Peter
>
>

Wiki page summarizing the results of the ERF meeting

Submitted by peter on Thu, 2012-06-28 19:48.

Hi Charles,

On Thu, Jun 28, 2012 at 7:02 PM, Charles Lesire-Cabaniols <
charles [dot] lesire [..] ...> wrote:

>
>
> 2012/6/26 Peter Soetens <peter [..] ...>
>
>> Hi Charles,
>>
>> On Tue, Jun 26, 2012 at 10:58 AM, Charles Lesire-Cabaniols <
>> charles [dot] lesire [..] ...> wrote:
>>
>>>
>>>
>>> 2012/6/26 Peter Soetens <peter [..] ...>
>>>
>>>> Hi Charles,
>>>>
>>>> On Tue, Jun 26, 2012 at 10:28 AM, Charles Lesire-Cabaniols <
>>>> charles [dot] lesire [..] ...> wrote:
>>>>
>>>>>
>>>>>
>>>>> 2012/3/21 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>
>>>>>
>>>>>>
>>>>>> http://www.orocos.org/wiki/main-page/development/orocos-developers-meetu...
>>>>>>
>>>>>
>>>>> Hi all,
>>>>>
>>>>> What's the status of the "Dataflow between ROS and Rock / plain
>>>>> Orocos"?
>>>>>
>>>>> I am definitely looking for a way to make my Orocos components usable
>>>>> in a ROS network without having them depending on ROS, i.e. components'
>>>>> ports have non-ROS types!
>>>>>
>>>>
>>>> I had spent a few hours on this, but didn't get far yet, let alone test
>>>> the code. You can see my progress on my github account here:
>>>>
>>>> https://github.com/psoetens/orocos-rtt/commits/master-flexiport
>>>>
>>>> The idea is that two major additions must be in place:
>>>>
>>>> 1. Create a channel element which can receive type A and send out type
>>>> B (data flow conversion)
>>>> 2. Extend the transport mechanism such that it tries harder to find a
>>>> transport for type A (eg non-ros) by converting it to type B (ros msg type)
>>>> using step 1. and then sending out the ROS message B. This would
>>>> automatically work for other transports as well, as long as the RTT type
>>>> info constructor A<->B is known.
>>>>
>>>> So our users would create a 'ROS' transport for type A, although A is
>>>> ROS independent, but does have a constructor in type B for creating a B
>>>> from an A.
>>>>
>>>> This also depends on the type system refactoring I completed earlier
>>>> (see commit history) but didn't dare to post yet :-) I guess it's sorta out
>>>> now...
>>>>
>>>> The type info redux patchset passes all unit tests, but there are no
>>>> patches yet for OCL or oro/typegen, although these are expected to be minor
>>>> and consequent. The last part is especially why I didn't push anything like
>>>> this to master yet...
>>>>
>>>
>>> I can help, at least in testing, if you give me some tips how to get all
>>> the necessary sources, and what kind of basic tests I could make.
>>>
>>> I can even participate to the development if you give me quite "clear"
>>> instructions :)
>>>
>>
>> Ok. The first thing to test then is plain OCL. I just built OCL 2.5
>> against rtt's master-typeinfo-redux and it builds, and the deployer can use
>> the rtt or ros types.
>>
>
> Both rtt master-typeinfo-redux and OCL 2.5 built correctly. The deployer
> launches.
> As I am not familiar with Orocos/ROS integration, how could I check that
> ROS types are correctly managed by the deployer?
>

That's all right, we're checking ros, we need some help with realistic
typegen applications.

>
>
>
>>
>> What I need help with next is testing this in a real application, and
>> then also looking at how orogen/typegen works with this. If you report
>> errors, we can see how we can fix RTT or orogen to work with it...
>>
>
>
> Ok. I have some components with typegen generated typekits. I will try to
> compile them against your rtt's branch.
>

That would be great.

Peter

Wiki page summarizing the results of the ERF meeting

Submitted by Sylvain Joyeux on Mon, 2012-09-10 09:16.

What's the status on all of that (typeinfo-redux and ros integration ?).
I am back from parental leave and is piling up things to do ... That
could be one of them.

Sylvain

Wiki page summarizing the results of the ERF meeting

Submitted by Charles Lesire-... on Mon, 2012-09-10 09:32.

2012/9/10 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>

> What's the status on all of that (typeinfo-redux and ros integration ?). I
> am back from parental leave and is piling up things to do ... That could be
> one of them.
>

Hi,

Honestly, I just installed stuff but had no time for testing... Now I am
back from holidays + illness, so that I can work again on testing this
branch.

Peter, can I still work on the branch you prepared on July, or should I
update something?

Charles.

>
> Sylvain
>

Wiki page summarizing the results of the ERF meeting

Submitted by peter on Mon, 2012-09-10 15:44.

On Mon, Sep 10, 2012 at 11:28 AM, Charles Lesire-Cabaniols
<charles [dot] lesire [..] ...> wrote:
>
>
> 2012/9/10 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>
>>
>> What's the status on all of that (typeinfo-redux and ros integration ?). I
>> am back from parental leave and is piling up things to do ... That could be
>> one of them.
>
>
> Hi,
>
> Honestly, I just installed stuff but had no time for testing... Now I am
> back from holidays + illness, so that I can work again on testing this
> branch.
>
> Peter, can I still work on the branch you prepared on July, or should I
> update something?

You can still work on it. No extra patches/changes were made although
I'd love to do so :-)

Peter

Wiki page summarizing the results of the ERF meeting

Submitted by Charles Lesire-... on Thu, 2012-09-27 05:48.

2012/9/10 Peter Soetens <peter [..] ...>

> On Mon, Sep 10, 2012 at 11:28 AM, Charles Lesire-Cabaniols
> <charles [dot] lesire [..] ...> wrote:
> >
> >
> > 2012/9/10 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>
> >>
> >> What's the status on all of that (typeinfo-redux and ros integration
> ?). I
> >> am back from parental leave and is piling up things to do ... That
> could be
> >> one of them.
> >
> >
> > Hi,
> >
> > Honestly, I just installed stuff but had no time for testing... Now I am
> > back from holidays + illness, so that I can work again on testing this
> > branch.
> >
> > Peter, can I still work on the branch you prepared on July, or should I
> > update something?
>
> You can still work on it. No extra patches/changes were made although
> I'd love to do so :-)
>

Hi Peter,

Does the code compiles on your system?
I have a lot of "does not name a type", meaning that there is probably a
mistake in the #include statements, regarding the #ifndef logic.
I tried to solve it by changing the #include orders on some files, adding
some on others... and I get new "does not name a type" errors.
Looks like I am lost in the curse of includes ;)

Could you fix it?

Charles.

>
> Peter
>

Wiki page summarizing the results of the ERF meeting

Submitted by peter on Thu, 2012-09-27 13:28.

Hi Charles,

On Thu, Sep 27, 2012 at 7:46 AM, Charles Lesire-Cabaniols <
charles [dot] lesire [..] ...> wrote:

>
>
> 2012/9/10 Peter Soetens <peter [..] ...>
>
>> On Mon, Sep 10, 2012 at 11:28 AM, Charles Lesire-Cabaniols
>> <charles [dot] lesire [..] ...> wrote:
>> >
>> >
>> > 2012/9/10 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>
>> >>
>> >> What's the status on all of that (typeinfo-redux and ros integration
>> ?). I
>> >> am back from parental leave and is piling up things to do ... That
>> could be
>> >> one of them.
>> >
>> >
>> > Hi,
>> >
>> > Honestly, I just installed stuff but had no time for testing... Now I am
>> > back from holidays + illness, so that I can work again on testing this
>> > branch.
>> >
>> > Peter, can I still work on the branch you prepared on July, or should I
>> > update something?
>>
>> You can still work on it. No extra patches/changes were made although
>> I'd love to do so :-)
>>
>
> Hi Peter,
>
> Does the code compiles on your system?
> I have a lot of "does not name a type", meaning that there is probably a
> mistake in the #include statements, regarding the #ifndef logic.
> I tried to solve it by changing the #include orders on some files, adding
> some on others... and I get new "does not name a type" errors.
> Looks like I am lost in the curse of includes ;)
>

Hmm. It works here. Could you at least say in which files you get errors ?
What's the first error you get ? Are you using this branch: ?

https://github.com/psoetens/orocos-rtt/tree/master-typeinfo-redux

Peter

Wiki page summarizing the results of the ERF meeting

Submitted by Charles Lesire-... on Thu, 2012-09-27 13:32.

2012/9/27 Peter Soetens <peter [..] ...>

> Hi Charles,
>
> On Thu, Sep 27, 2012 at 7:46 AM, Charles Lesire-Cabaniols <
> charles [dot] lesire [..] ...> wrote:
>
>>
>>
>> 2012/9/10 Peter Soetens <peter [..] ...>
>>
>>> On Mon, Sep 10, 2012 at 11:28 AM, Charles Lesire-Cabaniols
>>> <charles [dot] lesire [..] ...> wrote:
>>> >
>>> >
>>> > 2012/9/10 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>
>>> >>
>>> >> What's the status on all of that (typeinfo-redux and ros integration
>>> ?). I
>>> >> am back from parental leave and is piling up things to do ... That
>>> could be
>>> >> one of them.
>>> >
>>> >
>>> > Hi,
>>> >
>>> > Honestly, I just installed stuff but had no time for testing... Now I
>>> am
>>> > back from holidays + illness, so that I can work again on testing this
>>> > branch.
>>> >
>>> > Peter, can I still work on the branch you prepared on July, or should I
>>> > update something?
>>>
>>> You can still work on it. No extra patches/changes were made although
>>> I'd love to do so :-)
>>>
>>
>> Hi Peter,
>>
>> Does the code compiles on your system?
>> I have a lot of "does not name a type", meaning that there is probably a
>> mistake in the #include statements, regarding the #ifndef logic.
>> I tried to solve it by changing the #include orders on some files, adding
>> some on others... and I get new "does not name a type" errors.
>> Looks like I am lost in the curse of includes ;)
>>
>
> Hmm. It works here. Could you at least say in which files you get errors ?
> What's the first error you get ? Are you using this branch: ?
>
> https://github.com/psoetens/orocos-rtt/tree/master-typeinfo-redux
>

Ooops... I misread my previous emails and I was on master-flexiport. Now it
compiles ;)
I will try to compile my own components with this RTT version...

>
> Peter
>
>

Wiki page summarizing the results of the ERF meeting

Submitted by Charles Lesire-... on Thu, 2012-09-27 14:28.

2012/9/27 Charles Lesire-Cabaniols <charles [dot] lesire [..] ...>

>
>
> 2012/9/27 Peter Soetens <peter [..] ...>
>
>> Hi Charles,
>>
>> On Thu, Sep 27, 2012 at 7:46 AM, Charles Lesire-Cabaniols <
>> charles [dot] lesire [..] ...> wrote:
>>
>>>
>>>
>>> 2012/9/10 Peter Soetens <peter [..] ...>
>>>
>>>> On Mon, Sep 10, 2012 at 11:28 AM, Charles Lesire-Cabaniols
>>>> <charles [dot] lesire [..] ...> wrote:
>>>> >
>>>> >
>>>> > 2012/9/10 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>
>>>> >>
>>>> >> What's the status on all of that (typeinfo-redux and ros integration
>>>> ?). I
>>>> >> am back from parental leave and is piling up things to do ... That
>>>> could be
>>>> >> one of them.
>>>> >
>>>> >
>>>> > Hi,
>>>> >
>>>> > Honestly, I just installed stuff but had no time for testing... Now I
>>>> am
>>>> > back from holidays + illness, so that I can work again on testing this
>>>> > branch.
>>>> >
>>>> > Peter, can I still work on the branch you prepared on July, or should
>>>> I
>>>> > update something?
>>>>
>>>> You can still work on it. No extra patches/changes were made although
>>>> I'd love to do so :-)
>>>>
>>>
>>> Hi Peter,
>>>
>>> Does the code compiles on your system?
>>> I have a lot of "does not name a type", meaning that there is probably a
>>> mistake in the #include statements, regarding the #ifndef logic.
>>> I tried to solve it by changing the #include orders on some files,
>>> adding some on others... and I get new "does not name a type" errors.
>>> Looks like I am lost in the curse of includes ;)
>>>
>>
>> Hmm. It works here. Could you at least say in which files you get errors
>> ? What's the first error you get ? Are you using this branch: ?
>>
>> https://github.com/psoetens/orocos-rtt/tree/master-typeinfo-redux
>>
>
> Ooops... I misread my previous emails and I was on master-flexiport. Now
> it compiles ;)
> I will try to compile my own components with this RTT version...
>

I have successfully recompiled RTT, OCL, the yarp-transport, some
components (that do not use typegen).
But for a 'typegen' based component, I have the following error:

[ 25%] Building CXX object
typekit/CMakeFiles/talcObcMorse-typekit-gnulinux.dir/type_info/__Talc__Avionique__Destination___Talc__Avionique__Pose.cpp.o
/home/lesire/work/action/autoproj/talc-obc-morse/typekit/type_info/__Talc__Avionique__Destination___Talc__Avionique__Pose.cpp:
In function ‘RTT::types::TypeInfo*
orogen_typekits::Talc_Avionique_Destination_TypeInfo()’:
/home/lesire/work/action/autoproj/talc-obc-morse/typekit/type_info/__Talc__Avionique__Destination___Talc__Avionique__Pose.cpp:22:53:
erreur: cannot convert
‘orogen_typekits::Talc_Avionique_DestinationTypeInfo*’ to
‘RTT::types::TypeInfo*’ in return
/home/lesire/work/action/autoproj/talc-obc-morse/typekit/type_info/__Talc__Avionique__Destination___Talc__Avionique__Pose.cpp:
In function ‘RTT::types::TypeInfo*
orogen_typekits::Talc_Avionique_Pose_TypeInfo()’:
/home/lesire/work/action/autoproj/talc-obc-morse/typekit/type_info/__Talc__Avionique__Destination___Talc__Avionique__Pose.cpp:67:46:
erreur: cannot convert ‘orogen_typekits::Talc_Avionique_PoseTypeInfo*’ to
‘RTT::types::TypeInfo*’ in return
make[2]: ***
[typekit/CMakeFiles/talcObcMorse-typekit-gnulinux.dir/type_info/__Talc__Avionique__Destination___Talc__Avionique__Pose.cpp.o]
Erreur 1
make[1]: *** [typekit/CMakeFiles/talcObcMorse-typekit-gnulinux.dir/all]
Erreur 2
make: *** [all] Erreur 2

The types included in the typekit are very basic:

namespace Talc { namespace Avionique {
struct Destination {
double x;
double y;
double z;
};
struct Pose {
double x;
double y;
double z;
double phi;
double theta;
double psi;
};
};}; // namespaces

The typekit is generated using the CMake command:
orocos_typegen_headers(talcObcMorse-types.hpp "--notransports=mqueue")

Charles.

>
>>
>> Peter
>>
>>
>

Wiki page summarizing the results of the ERF meeting

Submitted by peter on Thu, 2012-09-27 15:28.

Hi Charles,

I think the patch for orogen in attachment should do it.

Peter

On Thu, Sep 27, 2012 at 4:24 PM, Charles Lesire-Cabaniols <
charles [dot] lesire [..] ...> wrote:

>
>
> 2012/9/27 Charles Lesire-Cabaniols <charles [dot] lesire [..] ...>
>
>>
>>
>> 2012/9/27 Peter Soetens <peter [..] ...>
>>
>>> Hi Charles,
>>>
>>> On Thu, Sep 27, 2012 at 7:46 AM, Charles Lesire-Cabaniols <
>>> charles [dot] lesire [..] ...> wrote:
>>>
>>>>
>>>>
>>>> 2012/9/10 Peter Soetens <peter [..] ...>
>>>>
>>>>> On Mon, Sep 10, 2012 at 11:28 AM, Charles Lesire-Cabaniols
>>>>> <charles [dot] lesire [..] ...> wrote:
>>>>> >
>>>>> >
>>>>> > 2012/9/10 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>
>>>>> >>
>>>>> >> What's the status on all of that (typeinfo-redux and ros
>>>>> integration ?). I
>>>>> >> am back from parental leave and is piling up things to do ... That
>>>>> could be
>>>>> >> one of them.
>>>>> >
>>>>> >
>>>>> > Hi,
>>>>> >
>>>>> > Honestly, I just installed stuff but had no time for testing... Now
>>>>> I am
>>>>> > back from holidays + illness, so that I can work again on testing
>>>>> this
>>>>> > branch.
>>>>> >
>>>>> > Peter, can I still work on the branch you prepared on July, or
>>>>> should I
>>>>> > update something?
>>>>>
>>>>> You can still work on it. No extra patches/changes were made although
>>>>> I'd love to do so :-)
>>>>>
>>>>
>>>> Hi Peter,
>>>>
>>>> Does the code compiles on your system?
>>>> I have a lot of "does not name a type", meaning that there is probably
>>>> a mistake in the #include statements, regarding the #ifndef logic.
>>>> I tried to solve it by changing the #include orders on some files,
>>>> adding some on others... and I get new "does not name a type" errors.
>>>> Looks like I am lost in the curse of includes ;)
>>>>
>>>
>>> Hmm. It works here. Could you at least say in which files you get errors
>>> ? What's the first error you get ? Are you using this branch: ?
>>>
>>> https://github.com/psoetens/orocos-rtt/tree/master-typeinfo-redux
>>>
>>
>> Ooops... I misread my previous emails and I was on master-flexiport. Now
>> it compiles ;)
>> I will try to compile my own components with this RTT version...
>>
>
> I have successfully recompiled RTT, OCL, the yarp-transport, some
> components (that do not use typegen).
> But for a 'typegen' based component, I have the following error:
>
> [ 25%] Building CXX object
> typekit/CMakeFiles/talcObcMorse-typekit-gnulinux.dir/type_info/__Talc__Avionique__Destination___Talc__Avionique__Pose.cpp.o
> /home/lesire/work/action/autoproj/talc-obc-morse/typekit/type_info/__Talc__Avionique__Destination___Talc__Avionique__Pose.cpp:
> In function ‘RTT::types::TypeInfo*
> orogen_typekits::Talc_Avionique_Destination_TypeInfo()’:
> /home/lesire/work/action/autoproj/talc-obc-morse/typekit/type_info/__Talc__Avionique__Destination___Talc__Avionique__Pose.cpp:22:53:
> erreur: cannot convert
> ‘orogen_typekits::Talc_Avionique_DestinationTypeInfo*’ to
> ‘RTT::types::TypeInfo*’ in return
> /home/lesire/work/action/autoproj/talc-obc-morse/typekit/type_info/__Talc__Avionique__Destination___Talc__Avionique__Pose.cpp:
> In function ‘RTT::types::TypeInfo*
> orogen_typekits::Talc_Avionique_Pose_TypeInfo()’:
> /home/lesire/work/action/autoproj/talc-obc-morse/typekit/type_info/__Talc__Avionique__Destination___Talc__Avionique__Pose.cpp:67:46:
> erreur: cannot convert ‘orogen_typekits::Talc_Avionique_PoseTypeInfo*’ to
> ‘RTT::types::TypeInfo*’ in return
> make[2]: ***
> [typekit/CMakeFiles/talcObcMorse-typekit-gnulinux.dir/type_info/__Talc__Avionique__Destination___Talc__Avionique__Pose.cpp.o]
> Erreur 1
> make[1]: *** [typekit/CMakeFiles/talcObcMorse-typekit-gnulinux.dir/all]
> Erreur 2
> make: *** [all] Erreur 2
>
> The types included in the typekit are very basic:
>
> namespace Talc { namespace Avionique {
> struct Destination {
> double x;
> double y;
> double z;
> };
> struct Pose {
> double x;
> double y;
> double z;
> double phi;
> double theta;
> double psi;
> };
> };}; // namespaces
>
> The typekit is generated using the CMake command:
> orocos_typegen_headers(talcObcMorse-types.hpp "--notransports=mqueue")
>
> Charles.
>
>
>>
>>>
>>> Peter
>>>
>>>
>>
>

Wiki page summarizing the results of the ERF meeting

Submitted by Charles Lesire-... on Fri, 2012-09-28 06:00.

2012/9/27 Peter Soetens <peter [..] ...>

> Hi Charles,
>
> I think the patch for orogen in attachment should do it.
>

Ok. Works for me on a first case study. I join the orograph (from
rtt_dot_service) to show you the "complexity" of the architecture.
None all connections use typegen'd data (only 4 actually are).
The components work in simulation, in MORSE, and communicate via the
yarp-transport.

Do you need a specific test to be implemented?

Charles

>
> Peter
>
>
> On Thu, Sep 27, 2012 at 4:24 PM, Charles Lesire-Cabaniols <
> charles [dot] lesire [..] ...> wrote:
>
>>
>>
>> 2012/9/27 Charles Lesire-Cabaniols <charles [dot] lesire [..] ...>
>>
>>>
>>>
>>> 2012/9/27 Peter Soetens <peter [..] ...>
>>>
>>>> Hi Charles,
>>>>
>>>> On Thu, Sep 27, 2012 at 7:46 AM, Charles Lesire-Cabaniols <
>>>> charles [dot] lesire [..] ...> wrote:
>>>>
>>>>>
>>>>>
>>>>> 2012/9/10 Peter Soetens <peter [..] ...>
>>>>>
>>>>>> On Mon, Sep 10, 2012 at 11:28 AM, Charles Lesire-Cabaniols
>>>>>> <charles [dot] lesire [..] ...> wrote:
>>>>>> >
>>>>>> >
>>>>>> > 2012/9/10 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>
>>>>>> >>
>>>>>> >> What's the status on all of that (typeinfo-redux and ros
>>>>>> integration ?). I
>>>>>> >> am back from parental leave and is piling up things to do ... That
>>>>>> could be
>>>>>> >> one of them.
>>>>>> >
>>>>>> >
>>>>>> > Hi,
>>>>>> >
>>>>>> > Honestly, I just installed stuff but had no time for testing... Now
>>>>>> I am
>>>>>> > back from holidays + illness, so that I can work again on testing
>>>>>> this
>>>>>> > branch.
>>>>>> >
>>>>>> > Peter, can I still work on the branch you prepared on July, or
>>>>>> should I
>>>>>> > update something?
>>>>>>
>>>>>> You can still work on it. No extra patches/changes were made although
>>>>>> I'd love to do so :-)
>>>>>>
>>>>>
>>>>> Hi Peter,
>>>>>
>>>>> Does the code compiles on your system?
>>>>> I have a lot of "does not name a type", meaning that there is probably
>>>>> a mistake in the #include statements, regarding the #ifndef logic.
>>>>> I tried to solve it by changing the #include orders on some files,
>>>>> adding some on others... and I get new "does not name a type" errors.
>>>>> Looks like I am lost in the curse of includes ;)
>>>>>
>>>>
>>>> Hmm. It works here. Could you at least say in which files you get
>>>> errors ? What's the first error you get ? Are you using this branch: ?
>>>>
>>>> https://github.com/psoetens/orocos-rtt/tree/master-typeinfo-redux
>>>>
>>>
>>> Ooops... I misread my previous emails and I was on master-flexiport. Now
>>> it compiles ;)
>>> I will try to compile my own components with this RTT version...
>>>
>>
>> I have successfully recompiled RTT, OCL, the yarp-transport, some
>> components (that do not use typegen).
>> But for a 'typegen' based component, I have the following error:
>>
>> [ 25%] Building CXX object
>> typekit/CMakeFiles/talcObcMorse-typekit-gnulinux.dir/type_info/__Talc__Avionique__Destination___Talc__Avionique__Pose.cpp.o
>> /home/lesire/work/action/autoproj/talc-obc-morse/typekit/type_info/__Talc__Avionique__Destination___Talc__Avionique__Pose.cpp:
>> In function ‘RTT::types::TypeInfo*
>> orogen_typekits::Talc_Avionique_Destination_TypeInfo()’:
>> /home/lesire/work/action/autoproj/talc-obc-morse/typekit/type_info/__Talc__Avionique__Destination___Talc__Avionique__Pose.cpp:22:53:
>> erreur: cannot convert
>> ‘orogen_typekits::Talc_Avionique_DestinationTypeInfo*’ to
>> ‘RTT::types::TypeInfo*’ in return
>> /home/lesire/work/action/autoproj/talc-obc-morse/typekit/type_info/__Talc__Avionique__Destination___Talc__Avionique__Pose.cpp:
>> In function ‘RTT::types::TypeInfo*
>> orogen_typekits::Talc_Avionique_Pose_TypeInfo()’:
>> /home/lesire/work/action/autoproj/talc-obc-morse/typekit/type_info/__Talc__Avionique__Destination___Talc__Avionique__Pose.cpp:67:46:
>> erreur: cannot convert ‘orogen_typekits::Talc_Avionique_PoseTypeInfo*’ to
>> ‘RTT::types::TypeInfo*’ in return
>> make[2]: ***
>> [typekit/CMakeFiles/talcObcMorse-typekit-gnulinux.dir/type_info/__Talc__Avionique__Destination___Talc__Avionique__Pose.cpp.o]
>> Erreur 1
>> make[1]: *** [typekit/CMakeFiles/talcObcMorse-typekit-gnulinux.dir/all]
>> Erreur 2
>> make: *** [all] Erreur 2
>>
>> The types included in the typekit are very basic:
>>
>> namespace Talc { namespace Avionique {
>> struct Destination {
>> double x;
>> double y;
>> double z;
>> };
>> struct Pose {
>> double x;
>> double y;
>> double z;
>> double phi;
>> double theta;
>> double psi;
>> };
>> };}; // namespaces
>>
>> The typekit is generated using the CMake command:
>> orocos_typegen_headers(talcObcMorse-types.hpp "--notransports=mqueue")
>>
>> Charles.
>>
>>
>>>
>>>>
>>>> Peter
>>>>
>>>>
>>>
>>
>

Wiki page summarizing the results of the ERF meeting

Submitted by Charles Lesire-... on Thu, 2012-10-04 07:12.

2012/9/28 Charles Lesire-Cabaniols <charles [dot] lesire [..] ...>

>
>
> 2012/9/27 Peter Soetens <peter [..] ...>
>
>> Hi Charles,
>>
>> I think the patch for orogen in attachment should do it.
>>
>
> Ok. Works for me on a first case study. I join the orograph (from
> rtt_dot_service) to show you the "complexity" of the architecture.
> None all connections use typegen'd data (only 4 actually are).
> The components work in simulation, in MORSE, and communicate via the
> yarp-transport.
>
> Do you need a specific test to be implemented?
>

I successfully generated typekits (including corba and mqueue transports)
for another application... quite a lot of types, with attributes being
basic types (from stdint, float, double...), other structs, vectors,
carrays. Data are correctly understood and displayed in the deployer, and
correctly exchanged between components.

Deployer [S]> .types
Available data types: Attitude_t CICAS_TC_t CICAS_TM_t CommandAvoidance_t
CommandesI2C_t Commands_t I2C_Sensor_t IG500x_t Localisation_t Odometry_t
Odometry_t[] PacketUDPScan_t ParametresAcquisitionCapteursI2C_t
ParametresScan_t PointScan_t PositionLocale_t Position_t Request_t
RessourceState_t Ressources_t SVINFO_t SatelliteFlags_t Satellite_t
Satellite_t[] ScanParameters_t ScanPoint_t Scan_t SystemState_t TC_t TM_t
TelScan_t float[] int16_t[] std.string std.vector<PointScan_t>
std.vector<ScanPoint_t> ConnPolicy FlowStatus PropertyBag SendHandle
SendStatus TaskContext array bool bools char double float int ints string
strings uint void

Charles.

>
> Charles
>
>
>>
>> Peter
>>
>>
>> On Thu, Sep 27, 2012 at 4:24 PM, Charles Lesire-Cabaniols <
>> charles [dot] lesire [..] ...> wrote:
>>
>>>
>>>
>>> 2012/9/27 Charles Lesire-Cabaniols <charles [dot] lesire [..] ...>
>>>
>>>>
>>>>
>>>> 2012/9/27 Peter Soetens <peter [..] ...>
>>>>
>>>>> Hi Charles,
>>>>>
>>>>> On Thu, Sep 27, 2012 at 7:46 AM, Charles Lesire-Cabaniols <
>>>>> charles [dot] lesire [..] ...> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> 2012/9/10 Peter Soetens <peter [..] ...>
>>>>>>
>>>>>>> On Mon, Sep 10, 2012 at 11:28 AM, Charles Lesire-Cabaniols
>>>>>>> <charles [dot] lesire [..] ...> wrote:
>>>>>>> >
>>>>>>> >
>>>>>>> > 2012/9/10 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>
>>>>>>> >>
>>>>>>> >> What's the status on all of that (typeinfo-redux and ros
>>>>>>> integration ?). I
>>>>>>> >> am back from parental leave and is piling up things to do ...
>>>>>>> That could be
>>>>>>> >> one of them.
>>>>>>> >
>>>>>>> >
>>>>>>> > Hi,
>>>>>>> >
>>>>>>> > Honestly, I just installed stuff but had no time for testing...
>>>>>>> Now I am
>>>>>>> > back from holidays + illness, so that I can work again on testing
>>>>>>> this
>>>>>>> > branch.
>>>>>>> >
>>>>>>> > Peter, can I still work on the branch you prepared on July, or
>>>>>>> should I
>>>>>>> > update something?
>>>>>>>
>>>>>>> You can still work on it. No extra patches/changes were made although
>>>>>>> I'd love to do so :-)
>>>>>>>
>>>>>>
>>>>>> Hi Peter,
>>>>>>
>>>>>> Does the code compiles on your system?
>>>>>> I have a lot of "does not name a type", meaning that there is
>>>>>> probably a mistake in the #include statements, regarding the #ifndef logic.
>>>>>> I tried to solve it by changing the #include orders on some files,
>>>>>> adding some on others... and I get new "does not name a type" errors.
>>>>>> Looks like I am lost in the curse of includes ;)
>>>>>>
>>>>>
>>>>> Hmm. It works here. Could you at least say in which files you get
>>>>> errors ? What's the first error you get ? Are you using this branch: ?
>>>>>
>>>>> https://github.com/psoetens/orocos-rtt/tree/master-typeinfo-redux
>>>>>
>>>>
>>>> Ooops... I misread my previous emails and I was on master-flexiport.
>>>> Now it compiles ;)
>>>> I will try to compile my own components with this RTT version...
>>>>
>>>
>>> I have successfully recompiled RTT, OCL, the yarp-transport, some
>>> components (that do not use typegen).
>>> But for a 'typegen' based component, I have the following error:
>>>
>>> [ 25%] Building CXX object
>>> typekit/CMakeFiles/talcObcMorse-typekit-gnulinux.dir/type_info/__Talc__Avionique__Destination___Talc__Avionique__Pose.cpp.o
>>> /home/lesire/work/action/autoproj/talc-obc-morse/typekit/type_info/__Talc__Avionique__Destination___Talc__Avionique__Pose.cpp:
>>> In function ‘RTT::types::TypeInfo*
>>> orogen_typekits::Talc_Avionique_Destination_TypeInfo()’:
>>> /home/lesire/work/action/autoproj/talc-obc-morse/typekit/type_info/__Talc__Avionique__Destination___Talc__Avionique__Pose.cpp:22:53:
>>> erreur: cannot convert
>>> ‘orogen_typekits::Talc_Avionique_DestinationTypeInfo*’ to
>>> ‘RTT::types::TypeInfo*’ in return
>>> /home/lesire/work/action/autoproj/talc-obc-morse/typekit/type_info/__Talc__Avionique__Destination___Talc__Avionique__Pose.cpp:
>>> In function ‘RTT::types::TypeInfo*
>>> orogen_typekits::Talc_Avionique_Pose_TypeInfo()’:
>>> /home/lesire/work/action/autoproj/talc-obc-morse/typekit/type_info/__Talc__Avionique__Destination___Talc__Avionique__Pose.cpp:67:46:
>>> erreur: cannot convert ‘orogen_typekits::Talc_Avionique_PoseTypeInfo*’ to
>>> ‘RTT::types::TypeInfo*’ in return
>>> make[2]: ***
>>> [typekit/CMakeFiles/talcObcMorse-typekit-gnulinux.dir/type_info/__Talc__Avionique__Destination___Talc__Avionique__Pose.cpp.o]
>>> Erreur 1
>>> make[1]: *** [typekit/CMakeFiles/talcObcMorse-typekit-gnulinux.dir/all]
>>> Erreur 2
>>> make: *** [all] Erreur 2
>>>
>>> The types included in the typekit are very basic:
>>>
>>> namespace Talc { namespace Avionique {
>>> struct Destination {
>>> double x;
>>> double y;
>>> double z;
>>> };
>>> struct Pose {
>>> double x;
>>> double y;
>>> double z;
>>> double phi;
>>> double theta;
>>> double psi;
>>> };
>>> };}; // namespaces
>>>
>>> The typekit is generated using the CMake command:
>>> orocos_typegen_headers(talcObcMorse-types.hpp "--notransports=mqueue")
>>>
>>> Charles.
>>>
>>>
>>>>
>>>>>
>>>>> Peter
>>>>>
>>>>>
>>>>
>>>
>>
>

Wiki page summarizing the results of the ERF meeting

Submitted by peter on Thu, 2012-10-04 09:24.

On Thu, Oct 4, 2012 at 9:09 AM, Charles Lesire-Cabaniols <
charles [dot] lesire [..] ...> wrote:

>
>
> 2012/9/28 Charles Lesire-Cabaniols <charles [dot] lesire [..] ...>
>
>>
>>
>> 2012/9/27 Peter Soetens <peter [..] ...>
>>
>>> Hi Charles,
>>>
>>> I think the patch for orogen in attachment should do it.
>>>
>>
>> Ok. Works for me on a first case study. I join the orograph (from
>> rtt_dot_service) to show you the "complexity" of the architecture.
>> None all connections use typegen'd data (only 4 actually are).
>> The components work in simulation, in MORSE, and communicate via the
>> yarp-transport.
>>
>> Do you need a specific test to be implemented?
>>
>
> I successfully generated typekits (including corba and mqueue transports)
> for another application... quite a lot of types, with attributes being
> basic types (from stdint, float, double...), other structs, vectors,
> carrays. Data are correctly understood and displayed in the deployer, and
> correctly exchanged between components.
>
> Deployer [S]> .types
> Available data types: Attitude_t CICAS_TC_t CICAS_TM_t CommandAvoidance_t
> CommandesI2C_t Commands_t I2C_Sensor_t IG500x_t Localisation_t Odometry_t
> Odometry_t[] PacketUDPScan_t ParametresAcquisitionCapteursI2C_t
> ParametresScan_t PointScan_t PositionLocale_t Position_t Request_t
> RessourceState_t Ressources_t SVINFO_t SatelliteFlags_t Satellite_t
> Satellite_t[] ScanParameters_t ScanPoint_t Scan_t SystemState_t TC_t TM_t
> TelScan_t float[] int16_t[] std.string std.vector<PointScan_t>
> std.vector<ScanPoint_t> ConnPolicy FlowStatus PropertyBag SendHandle
> SendStatus TaskContext array bool bools char double float int ints string
> strings uint void
>
>
Thanks a lot for this pre-testing. I don't have the time budget to do an
official pre-release, so people will have to stick to master to test the
latest changes.

Regarding testing method: We will only merge on master code that builds
(full toolchain!) + passes unit tests. At that point, people can test their
applications against it. Other code should be in branches until it works
out.

Cheers,
Peter

Wiki page summarizing the results of the ERF meeting

Submitted by Sylvain Joyeux on Thu, 2012-10-04 09:28.

On 10/04/2012 11:21 AM, Peter Soetens wrote:
>
>
> Thanks a lot for this pre-testing. I don't have the time budget to do
> an official pre-release, so people will have to stick to master to
> test the latest changes.
>
> Regarding testing method: We will only merge on master code that
> builds (full toolchain!) + passes unit tests. At that point, people
> can test their applications against it. Other code should be in
> branches until it works out.
>
I've updated orogen and orocos.rb to fit the new RTT type info, and both
their test suites are passing fine. That's also a good indication ;-)

Wiki page summarizing the results of the ERF meeting

Submitted by Charles Lesire-... on Thu, 2012-10-04 09:32.

2012/10/4 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>

> On 10/04/2012 11:21 AM, Peter Soetens wrote:
>
>>
>>
>> Thanks a lot for this pre-testing. I don't have the time budget to do an
>> official pre-release, so people will have to stick to master to test the
>> latest changes.
>>
>> Regarding testing method: We will only merge on master code that builds
>> (full toolchain!) + passes unit tests. At that point, people can test their
>> applications against it. Other code should be in branches until it works
>> out.
>>
>> I've updated orogen and orocos.rb to fit the new RTT type info, and both
> their test suites are passing fine. That's also a good indication ;-)
>

So now, the data flow type conversion should work just be defining a
constructor that converts a type A into a type B? And then connecting an
OutputPort to an InputPort?

If you think it's ready for that, I could manage to test this behaviour
with YARP and ROS type conversions...

Does it has an impact on the existing transports (i.e., should I modify
something in my yarp-transport) ?

Charles.

>
> --
> Sylvain Joyeux (Dr.Ing.)
> Senior Researcher
>
> Space & Security Robotics
> Underwater 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
> ------------------------------**------------------------------**
> -----------
>
>

Wiki page summarizing the results of the ERF meeting

Submitted by Sylvain Joyeux on Thu, 2012-10-04 09:36.

On 10/04/2012 11:30 AM, Charles Lesire-Cabaniols wrote:
>
>
> 2012/10/4 Sylvain Joyeux <sylvain [dot] joyeux [..] ...
> <mailto:sylvain [dot] joyeux [..] ...>>
>
> On 10/04/2012 11:21 AM, Peter Soetens wrote:
>
>
>
> Thanks a lot for this pre-testing. I don't have the time
> budget to do an official pre-release, so people will have to
> stick to master to test the latest changes.
>
> Regarding testing method: We will only merge on master code
> that builds (full toolchain!) + passes unit tests. At that
> point, people can test their applications against it. Other
> code should be in branches until it works out.
>
> I've updated orogen and orocos.rb to fit the new RTT type info,
> and both their test suites are passing fine. That's also a good
> indication ;-)
>
>
>
> So now, the data flow type conversion should work just be defining a
> constructor that converts a type A into a type B? And then connecting
> an OutputPort to an InputPort?
Nope. I don't think that anything has been implemented at all in this
direction.

I was talking about updating the typeinfo generation to the new API, and
making sure that everything works fine.

Wiki page summarizing the results of the ERF meeting

Submitted by Charles Lesire-... on Fri, 2012-10-05 07:16.

2012/10/4 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>

> On 10/04/2012 11:30 AM, Charles Lesire-Cabaniols wrote:
>
>
>
> 2012/10/4 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>
>
>> On 10/04/2012 11:21 AM, Peter Soetens wrote:
>>
>>>
>>>
>>> Thanks a lot for this pre-testing. I don't have the time budget to do an
>>> official pre-release, so people will have to stick to master to test the
>>> latest changes.
>>>
>>> Regarding testing method: We will only merge on master code that builds
>>> (full toolchain!) + passes unit tests. At that point, people can test their
>>> applications against it. Other code should be in branches until it works
>>> out.
>>>
>>> I've updated orogen and orocos.rb to fit the new RTT type info, and
>> both their test suites are passing fine. That's also a good indication ;-)
>>
>
>
> So now, the data flow type conversion should work just be defining a
> constructor that converts a type A into a type B? And then connecting an
> OutputPort to an InputPort?
>
> Nope. I don't think that anything has been implemented at all in this
> direction.
>

Ok. So when I woke up this thread, it was to know the status of the "ROS
compatibility without ROS", i.e. connecting my components that have non-ROS
type to ROS topics.

I thought it was the aim of the branch I was testing...

What are the needed improvements to make this compatibility available? How
could I help?

Charles.

>
> I was talking about updating the typeinfo generation to the new API, and
> making sure that everything works fine.
>
> --
> Sylvain Joyeux (Dr.Ing.)
> Senior Researcher
>
> Space & Security Robotics
> Underwater 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
> -----------------------------------------------------------------------
>
>

Wiki page summarizing the results of the ERF meeting

Submitted by peter on Fri, 2012-10-05 13:52.

Hi Charles,

On Fri, Oct 5, 2012 at 9:15 AM, Charles Lesire-Cabaniols <
charles [dot] lesire [..] ...> wrote:

>
>
> 2012/10/4 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>
>
>> On 10/04/2012 11:30 AM, Charles Lesire-Cabaniols wrote:
>>
>>
>>
>> 2012/10/4 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>
>>
>>> On 10/04/2012 11:21 AM, Peter Soetens wrote:
>>>
>>>>
>>>>
>>>> Thanks a lot for this pre-testing. I don't have the time budget to do
>>>> an official pre-release, so people will have to stick to master to test the
>>>> latest changes.
>>>>
>>>> Regarding testing method: We will only merge on master code that builds
>>>> (full toolchain!) + passes unit tests. At that point, people can test their
>>>> applications against it. Other code should be in branches until it works
>>>> out.
>>>>
>>>> I've updated orogen and orocos.rb to fit the new RTT type info, and
>>> both their test suites are passing fine. That's also a good indication ;-)
>>>
>>
>>
>> So now, the data flow type conversion should work just be defining a
>> constructor that converts a type A into a type B? And then connecting an
>> OutputPort to an InputPort?
>>
>> Nope. I don't think that anything has been implemented at all in this
>> direction.
>>
>
> Ok. So when I woke up this thread, it was to know the status of the "ROS
> compatibility without ROS", i.e. connecting my components that have non-ROS
> type to ROS topics.
>
> I thought it was the aim of the branch I was testing...
>

Yes, as a first step :-)

>
> What are the needed improvements to make this compatibility available? How
> could I help?
>

There is another branch :-)

It's the flexiport branch. It contains some patches, which don't compile,
but setup some structure to make this work. First, it needs a specially
crafted ChannelConversionElement which inherits from ChannelElement
and ChannelElement. Where A is convertible to B. A rudimentary
implementation exists on the flexiport branch.

You will need to rebase flexiport on the latest master, or at least extract
the patches manually and apply them on master (two patches dated Jun 26,
2012)

https://github.com/psoetens/orocos-rtt/tree/master-flexiport

Next, the tricky part is in the ConnFactory, where for normal in-process
connections and outwards connections (ros, corba, yarp,...), and
out-of-band connections a conversion must be done.
You'll have to
1. detect that both types don't match (A != B) -> type info pointer
comparisons !
2. lookup if you can construct a B from an A -> lookup constructors in
typeinfo of B
3. Use this constructor in a ChannelConversionElement, using classical
ReferenceDataSource constructs.
4. Do this in the right places of ConnFactory functions.

Finally, the last challenge is to also automatically detect the transport.
For example, if A is non-ros and you want to send it to a ROS topic, you
need to iterate over *all* types, check if they have a ROS transport *and*
are convertible from A. Then you know what to do: convert A to that ROS
type (using a ChannelConversionElement) and send it to a ros topic.

If you can do all that, you're ready for 2.7.0 :-)

Peter

Wiki page summarizing the results of the ERF meeting

Submitted by peter on Fri, 2012-10-05 15:08.

One additional note about the flexiport branch:

On Fri, Oct 5, 2012 at 3:51 PM, Peter Soetens <peter [..] ...>wrote:

> Hi Charles,
>
> On Fri, Oct 5, 2012 at 9:15 AM, Charles Lesire-Cabaniols <
> charles [dot] lesire [..] ...> wrote:
>
>>
>>
>> 2012/10/4 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>
>>
>>> On 10/04/2012 11:30 AM, Charles Lesire-Cabaniols wrote:
>>>
>>>
>>>
>>> 2012/10/4 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>
>>>
>>>> On 10/04/2012 11:21 AM, Peter Soetens wrote:
>>>>
>>>>>
>>>>>
>>>>> Thanks a lot for this pre-testing. I don't have the time budget to do
>>>>> an official pre-release, so people will have to stick to master to test the
>>>>> latest changes.
>>>>>
>>>>> Regarding testing method: We will only merge on master code that
>>>>> builds (full toolchain!) + passes unit tests. At that point, people can
>>>>> test their applications against it. Other code should be in branches until
>>>>> it works out.
>>>>>
>>>>> I've updated orogen and orocos.rb to fit the new RTT type info, and
>>>> both their test suites are passing fine. That's also a good indication ;-)
>>>>
>>>
>>>
>>> So now, the data flow type conversion should work just be defining a
>>> constructor that converts a type A into a type B? And then connecting an
>>> OutputPort to an InputPort?
>>>
>>> Nope. I don't think that anything has been implemented at all in this
>>> direction.
>>>
>>
>> Ok. So when I woke up this thread, it was to know the status of the "ROS
>> compatibility without ROS", i.e. connecting my components that have non-ROS
>> type to ROS topics.
>>
>> I thought it was the aim of the branch I was testing...
>>
>
> Yes, as a first step :-)
>
>
>>
>> What are the needed improvements to make this compatibility available?
>> How could I help?
>>
>
> There is another branch :-)
>
> It's the flexiport branch. It contains some patches, which don't compile,
> but setup some structure to make this work. First, it needs a specially
> crafted ChannelConversionElement which inherits from ChannelElement
> and ChannelElement. Where A is convertible to B. A rudimentary
> implementation exists on the flexiport branch.
>
> You will need to rebase flexiport on the latest master, or at least
> extract the patches manually and apply them on master (two patches
> dated Jun 26, 2012)
>
> https://github.com/psoetens/orocos-rtt/tree/master-flexiport
>
> Next, the tricky part is in the ConnFactory, where for normal in-process
> connections and outwards connections (ros, corba, yarp,...), and
> out-of-band connections a conversion must be done.
> You'll have to
> 1. detect that both types don't match (A != B) -> type info pointer
> comparisons !
> 2. lookup if you can construct a B from an A -> lookup constructors in
> typeinfo of B
> 3. Use this constructor in a ChannelConversionElement, using classical
> ReferenceDataSource constructs.
> 4. Do this in the right places of ConnFactory functions.
>
> Finally, the last challenge is to also automatically detect the transport.
> For example, if A is non-ros and you want to send it to a ROS topic, you
> need to iterate over *all* types, check if they have a ROS transport *and*
> are convertible from A. Then you know what to do: convert A to that ROS
> type (using a ChannelConversionElement) and send it to a ros topic.
>

It's the intention of the current patch-set that
the getAnyProtocol(P)/createAnyStream(P) functions do that: ask typeinfo of
A to get a protocol or create a stream in order to transport 'A' over
protocol 'P'. This implies that these functions do the above lookup. Maybe
there's a better/more straightforward way to do this...(ie do an explicit
lookup)

Peter

Wiki page summarizing the results of the ERF meeting

Submitted by Charles Lesire-... on Mon, 2012-10-08 07:36.

2012/10/5 Peter Soetens <peter [..] ...>

> One additional note about the flexiport branch:
>
> On Fri, Oct 5, 2012 at 3:51 PM, Peter Soetens <peter [..] ...>wrote:
>
>> Hi Charles,
>>
>> On Fri, Oct 5, 2012 at 9:15 AM, Charles Lesire-Cabaniols <
>> charles [dot] lesire [..] ...> wrote:
>>
>>>
>>>
>>> 2012/10/4 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>
>>>
>>>> On 10/04/2012 11:30 AM, Charles Lesire-Cabaniols wrote:
>>>>
>>>>
>>>>
>>>> 2012/10/4 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>
>>>>
>>>>> On 10/04/2012 11:21 AM, Peter Soetens wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> Thanks a lot for this pre-testing. I don't have the time budget to do
>>>>>> an official pre-release, so people will have to stick to master to test the
>>>>>> latest changes.
>>>>>>
>>>>>> Regarding testing method: We will only merge on master code that
>>>>>> builds (full toolchain!) + passes unit tests. At that point, people can
>>>>>> test their applications against it. Other code should be in branches until
>>>>>> it works out.
>>>>>>
>>>>>> I've updated orogen and orocos.rb to fit the new RTT type info, and
>>>>> both their test suites are passing fine. That's also a good indication ;-)
>>>>>
>>>>
>>>>
>>>> So now, the data flow type conversion should work just be defining a
>>>> constructor that converts a type A into a type B? And then connecting an
>>>> OutputPort to an InputPort?
>>>>
>>>> Nope. I don't think that anything has been implemented at all in this
>>>> direction.
>>>>
>>>
>>> Ok. So when I woke up this thread, it was to know the status of the "ROS
>>> compatibility without ROS", i.e. connecting my components that have non-ROS
>>> type to ROS topics.
>>>
>>> I thought it was the aim of the branch I was testing...
>>>
>>
>> Yes, as a first step :-)
>>
>>
>>>
>>> What are the needed improvements to make this compatibility available?
>>> How could I help?
>>>
>>
>> There is another branch :-)
>>
>> It's the flexiport branch. It contains some patches, which don't compile,
>> but setup some structure to make this work. First, it needs a specially
>> crafted ChannelConversionElement which inherits from ChannelElement
>> and ChannelElement. Where A is convertible to B. A rudimentary
>> implementation exists on the flexiport branch.
>>
>> You will need to rebase flexiport on the latest master, or at least
>> extract the patches manually and apply them on master (two patches
>> dated Jun 26, 2012)
>>
>> https://github.com/psoetens/orocos-rtt/tree/master-flexiport
>>
>

Ok. I have rebased on master and merged some conflicts. I will push it in a
personal clone on gitorious as soon as it builds...

>
>> Next, the tricky part is in the ConnFactory, where for normal in-process
>> connections and outwards connections (ros, corba, yarp,...), and
>> out-of-band connections a conversion must be done.
>> You'll have to
>> 1. detect that both types don't match (A != B) -> type info pointer
>> comparisons !
>> 2. lookup if you can construct a B from an A -> lookup constructors in
>> typeinfo of B
>> 3. Use this constructor in a ChannelConversionElement, using classical
>> ReferenceDataSource constructs.
>> 4. Do this in the right places of ConnFactory functions.
>>
>> Finally, the last challenge is to also automatically detect the
>> transport. For example, if A is non-ros and you want to send it to a ROS
>> topic, you need to iterate over *all* types, check if they have a ROS
>> transport *and* are convertible from A. Then you know what to do: convert A
>> to that ROS type (using a ChannelConversionElement) and send it to a ros
>> topic.
>>
>
> It's the intention of the current patch-set that
> the getAnyProtocol(P)/createAnyStream(P) functions do that: ask typeinfo of
> A to get a protocol or create a stream in order to transport 'A' over
> protocol 'P'. This implies that these functions do the above lookup. Maybe
> there's a better/more straightforward way to do this...(ie do an explicit
> lookup)
>

What's the difference you actually make between getAnyProtocol and the
existing getProtocol?

Charles.

>
> Peter
>
>

Wiki page summarizing the results of the ERF meeting

Submitted by peter on Mon, 2012-10-08 09:40.

On Mon, Oct 8, 2012 at 9:34 AM, Charles Lesire-Cabaniols
<charles [dot] lesire [..] ...> wrote:
>
>
> 2012/10/5 Peter Soetens <peter [..] ...>
>>
>> One additional note about the flexiport branch:
>>
>> On Fri, Oct 5, 2012 at 3:51 PM, Peter Soetens <peter [..] ...>
>> wrote:
>>>
>>> Hi Charles,
>>>
>>> On Fri, Oct 5, 2012 at 9:15 AM, Charles Lesire-Cabaniols
>>> <charles [dot] lesire [..] ...> wrote:
>>>>
>>>>
>>>>
>>>> 2012/10/4 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>
>>>>>
>>>>> On 10/04/2012 11:30 AM, Charles Lesire-Cabaniols wrote:
>>>>>
>>>>>
>>>>>
>>>>> 2012/10/4 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>
>>>>>>
>>>>>> On 10/04/2012 11:21 AM, Peter Soetens wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Thanks a lot for this pre-testing. I don't have the time budget to do
>>>>>>> an official pre-release, so people will have to stick to master to test the
>>>>>>> latest changes.
>>>>>>>
>>>>>>> Regarding testing method: We will only merge on master code that
>>>>>>> builds (full toolchain!) + passes unit tests. At that point, people can test
>>>>>>> their applications against it. Other code should be in branches until it
>>>>>>> works out.
>>>>>>>
>>>>>> I've updated orogen and orocos.rb to fit the new RTT type info, and
>>>>>> both their test suites are passing fine. That's also a good indication ;-)
>>>>>
>>>>>
>>>>>
>>>>> So now, the data flow type conversion should work just be defining a
>>>>> constructor that converts a type A into a type B? And then connecting an
>>>>> OutputPort to an InputPort?
>>>>>
>>>>> Nope. I don't think that anything has been implemented at all in this
>>>>> direction.
>>>>
>>>>
>>>> Ok. So when I woke up this thread, it was to know the status of the "ROS
>>>> compatibility without ROS", i.e. connecting my components that have non-ROS
>>>> type to ROS topics.
>>>>
>>>> I thought it was the aim of the branch I was testing...
>>>
>>>
>>> Yes, as a first step :-)
>>>
>>>>
>>>>
>>>> What are the needed improvements to make this compatibility available?
>>>> How could I help?
>>>
>>>
>>> There is another branch :-)
>>>
>>> It's the flexiport branch. It contains some patches, which don't compile,
>>> but setup some structure to make this work. First, it needs a specially
>>> crafted ChannelConversionElement which inherits from ChannelElement
>>> and ChannelElement. Where A is convertible to B. A rudimentary
>>> implementation exists on the flexiport branch.
>>>
>>> You will need to rebase flexiport on the latest master, or at least
>>> extract the patches manually and apply them on master (two patches dated Jun
>>> 26, 2012)
>>>
>>> https://github.com/psoetens/orocos-rtt/tree/master-flexiport
>
>
>
> Ok. I have rebased on master and merged some conflicts. I will push it in a
> personal clone on gitorious as soon as it builds...
>
>>>
>>>
>>> Next, the tricky part is in the ConnFactory, where for normal in-process
>>> connections and outwards connections (ros, corba, yarp,...), and out-of-band
>>> connections a conversion must be done.
>>> You'll have to
>>> 1. detect that both types don't match (A != B) -> type info pointer
>>> comparisons !
>>> 2. lookup if you can construct a B from an A -> lookup constructors in
>>> typeinfo of B
>>> 3. Use this constructor in a ChannelConversionElement, using classical
>>> ReferenceDataSource constructs.
>>> 4. Do this in the right places of ConnFactory functions.
>>>
>>> Finally, the last challenge is to also automatically detect the
>>> transport. For example, if A is non-ros and you want to send it to a ROS
>>> topic, you need to iterate over *all* types, check if they have a ROS
>>> transport *and* are convertible from A. Then you know what to do: convert A
>>> to that ROS type (using a ChannelConversionElement) and send it to a ros
>>> topic.
>>
>>
>> It's the intention of the current patch-set that the
>> getAnyProtocol(P)/createAnyStream(P) functions do that: ask typeinfo of A to
>> get a protocol or create a stream in order to transport 'A' over protocol
>> 'P'. This implies that these functions do the above lookup. Maybe there's a
>> better/more straightforward way to do this...(ie do an explicit lookup)
>
>
> What's the difference you actually make between getAnyProtocol and the
> existing getProtocol?

I wanted to leave the existing getProtocol 'as-is', in order to not
break any code relying on it: it returns the protocol of only this
type. getAnyProtocol() is smart, and tries to find a way to transport
type X over protocol P, even if a conversion is necessary. As Sylvain
pointed out, this could be weak if several conversions are possible
from X to P (say: convert KDL frame to a ROS tf message or ROS matrix
message).

Peter

Wiki page summarizing the results of the ERF meeting

Submitted by Charles Lesire-... on Mon, 2012-10-08 11:12.

2012/10/8 Peter Soetens <peter [..] ...>

> On Mon, Oct 8, 2012 at 9:34 AM, Charles Lesire-Cabaniols
> <charles [dot] lesire [..] ...> wrote:
> >
> >
> > 2012/10/5 Peter Soetens <peter [..] ...>
> >>
> >> One additional note about the flexiport branch:
> >>
> >> On Fri, Oct 5, 2012 at 3:51 PM, Peter Soetens <peter [..] ...
> >
> >> wrote:
> >>>
> >>> Hi Charles,
> >>>
> >>> On Fri, Oct 5, 2012 at 9:15 AM, Charles Lesire-Cabaniols
> >>> <charles [dot] lesire [..] ...> wrote:
> >>>>
> >>>>
> >>>>
> >>>> 2012/10/4 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>
> >>>>>
> >>>>> On 10/04/2012 11:30 AM, Charles Lesire-Cabaniols wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>> 2012/10/4 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>
> >>>>>>
> >>>>>> On 10/04/2012 11:21 AM, Peter Soetens wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> Thanks a lot for this pre-testing. I don't have the time budget to
> do
> >>>>>>> an official pre-release, so people will have to stick to master to
> test the
> >>>>>>> latest changes.
> >>>>>>>
> >>>>>>> Regarding testing method: We will only merge on master code that
> >>>>>>> builds (full toolchain!) + passes unit tests. At that point,
> people can test
> >>>>>>> their applications against it. Other code should be in branches
> until it
> >>>>>>> works out.
> >>>>>>>
> >>>>>> I've updated orogen and orocos.rb to fit the new RTT type info, and
> >>>>>> both their test suites are passing fine. That's also a good
> indication ;-)
> >>>>>
> >>>>>
> >>>>>
> >>>>> So now, the data flow type conversion should work just be defining a
> >>>>> constructor that converts a type A into a type B? And then
> connecting an
> >>>>> OutputPort to an InputPort?
> >>>>>
> >>>>> Nope. I don't think that anything has been implemented at all in this
> >>>>> direction.
> >>>>
> >>>>
> >>>> Ok. So when I woke up this thread, it was to know the status of the
> "ROS
> >>>> compatibility without ROS", i.e. connecting my components that have
> non-ROS
> >>>> type to ROS topics.
> >>>>
> >>>> I thought it was the aim of the branch I was testing...
> >>>
> >>>
> >>> Yes, as a first step :-)
> >>>
> >>>>
> >>>>
> >>>> What are the needed improvements to make this compatibility available?
> >>>> How could I help?
> >>>
> >>>
> >>> There is another branch :-)
> >>>
> >>> It's the flexiport branch. It contains some patches, which don't
> compile,
> >>> but setup some structure to make this work. First, it needs a specially
> >>> crafted ChannelConversionElement which inherits from
> ChannelElement
> >>> and ChannelElement. Where A is convertible to B. A rudimentary
> >>> implementation exists on the flexiport branch.
> >>>
> >>> You will need to rebase flexiport on the latest master, or at least
> >>> extract the patches manually and apply them on master (two patches
> dated Jun
> >>> 26, 2012)
> >>>
> >>> https://github.com/psoetens/orocos-rtt/tree/master-flexiport
> >
> >
> >
> > Ok. I have rebased on master and merged some conflicts. I will push it
> in a
> > personal clone on gitorious as soon as it builds...
> >
> >>>
> >>>
> >>> Next, the tricky part is in the ConnFactory, where for normal
> in-process
> >>> connections and outwards connections (ros, corba, yarp,...), and
> out-of-band
> >>> connections a conversion must be done.
> >>> You'll have to
> >>> 1. detect that both types don't match (A != B) -> type info pointer
> >>> comparisons !
> >>> 2. lookup if you can construct a B from an A -> lookup constructors in
> >>> typeinfo of B
> >>> 3. Use this constructor in a ChannelConversionElement, using classical
> >>> ReferenceDataSource constructs.
> >>> 4. Do this in the right places of ConnFactory functions.
> >>>
> >>> Finally, the last challenge is to also automatically detect the
> >>> transport. For example, if A is non-ros and you want to send it to a
> ROS
> >>> topic, you need to iterate over *all* types, check if they have a ROS
> >>> transport *and* are convertible from A. Then you know what to do:
> convert A
> >>> to that ROS type (using a ChannelConversionElement) and send it to a
> ros
> >>> topic.
> >>
> >>
> >> It's the intention of the current patch-set that the
> >> getAnyProtocol(P)/createAnyStream(P) functions do that: ask typeinfo of
> A to
> >> get a protocol or create a stream in order to transport 'A' over
> protocol
> >> 'P'. This implies that these functions do the above lookup. Maybe
> there's a
> >> better/more straightforward way to do this...(ie do an explicit lookup)
> >
> >
> > What's the difference you actually make between getAnyProtocol and the
> > existing getProtocol?
>
> I wanted to leave the existing getProtocol 'as-is', in order to not
> break any code relying on it: it returns the protocol of only this
> type. getAnyProtocol() is smart, and tries to find a way to transport
> type X over protocol P, even if a conversion is necessary. As Sylvain
> pointed out, this could be weak if several conversions are possible
> from X to P (say: convert KDL frame to a ROS tf message or ROS matrix
> message).
>

Ok, I see. Means that we should extend the definition of the ConnPolicy
with an optional target type, so that one could write something that looks
like:
deployer.stream('myOutputPort<KDLFrame>', ConnPolicy('ROS', 'tf'))

>
> Peter
>

Wiki page summarizing the results of the ERF meeting

Submitted by peter on Mon, 2012-10-08 11:56.

On Mon, Oct 8, 2012 at 1:11 PM, Charles Lesire-Cabaniols
<charles [dot] lesire [..] ...> wrote:
>
>
> 2012/10/8 Peter Soetens <peter [..] ...>
>>
>> On Mon, Oct 8, 2012 at 9:34 AM, Charles Lesire-Cabaniols
>> <charles [dot] lesire [..] ...> wrote:
>> >
>> >
>> > 2012/10/5 Peter Soetens <peter [..] ...>
>> >>
>> >> One additional note about the flexiport branch:
>> >>
>> >> On Fri, Oct 5, 2012 at 3:51 PM, Peter Soetens
>> >> <peter [..] ...>
>> >> wrote:
>> >>>
>> >>> Hi Charles,
>> >>>
>> >>> On Fri, Oct 5, 2012 at 9:15 AM, Charles Lesire-Cabaniols
>> >>> <charles [dot] lesire [..] ...> wrote:
>> >>>>
>> >>>>
>> >>>>
>> >>>> 2012/10/4 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>
>> >>>>>
>> >>>>> On 10/04/2012 11:30 AM, Charles Lesire-Cabaniols wrote:
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> 2012/10/4 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>
>> >>>>>>
>> >>>>>> On 10/04/2012 11:21 AM, Peter Soetens wrote:
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> Thanks a lot for this pre-testing. I don't have the time budget to
>> >>>>>>> do
>> >>>>>>> an official pre-release, so people will have to stick to master to
>> >>>>>>> test the
>> >>>>>>> latest changes.
>> >>>>>>>
>> >>>>>>> Regarding testing method: We will only merge on master code that
>> >>>>>>> builds (full toolchain!) + passes unit tests. At that point,
>> >>>>>>> people can test
>> >>>>>>> their applications against it. Other code should be in branches
>> >>>>>>> until it
>> >>>>>>> works out.
>> >>>>>>>
>> >>>>>> I've updated orogen and orocos.rb to fit the new RTT type info, and
>> >>>>>> both their test suites are passing fine. That's also a good
>> >>>>>> indication ;-)
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> So now, the data flow type conversion should work just be defining a
>> >>>>> constructor that converts a type A into a type B? And then
>> >>>>> connecting an
>> >>>>> OutputPort to an InputPort?
>> >>>>>
>> >>>>> Nope. I don't think that anything has been implemented at all in
>> >>>>> this
>> >>>>> direction.
>> >>>>
>> >>>>
>> >>>> Ok. So when I woke up this thread, it was to know the status of the
>> >>>> "ROS
>> >>>> compatibility without ROS", i.e. connecting my components that have
>> >>>> non-ROS
>> >>>> type to ROS topics.
>> >>>>
>> >>>> I thought it was the aim of the branch I was testing...
>> >>>
>> >>>
>> >>> Yes, as a first step :-)
>> >>>
>> >>>>
>> >>>>
>> >>>> What are the needed improvements to make this compatibility
>> >>>> available?
>> >>>> How could I help?
>> >>>
>> >>>
>> >>> There is another branch :-)
>> >>>
>> >>> It's the flexiport branch. It contains some patches, which don't
>> >>> compile,
>> >>> but setup some structure to make this work. First, it needs a
>> >>> specially
>> >>> crafted ChannelConversionElement which inherits from
>> >>> ChannelElement
>> >>> and ChannelElement. Where A is convertible to B. A rudimentary
>> >>> implementation exists on the flexiport branch.
>> >>>
>> >>> You will need to rebase flexiport on the latest master, or at least
>> >>> extract the patches manually and apply them on master (two patches
>> >>> dated Jun
>> >>> 26, 2012)
>> >>>
>> >>> https://github.com/psoetens/orocos-rtt/tree/master-flexiport
>> >
>> >
>> >
>> > Ok. I have rebased on master and merged some conflicts. I will push it
>> > in a
>> > personal clone on gitorious as soon as it builds...
>> >
>> >>>
>> >>>
>> >>> Next, the tricky part is in the ConnFactory, where for normal
>> >>> in-process
>> >>> connections and outwards connections (ros, corba, yarp,...), and
>> >>> out-of-band
>> >>> connections a conversion must be done.
>> >>> You'll have to
>> >>> 1. detect that both types don't match (A != B) -> type info pointer
>> >>> comparisons !
>> >>> 2. lookup if you can construct a B from an A -> lookup constructors in
>> >>> typeinfo of B
>> >>> 3. Use this constructor in a ChannelConversionElement, using classical
>> >>> ReferenceDataSource constructs.
>> >>> 4. Do this in the right places of ConnFactory functions.
>> >>>
>> >>> Finally, the last challenge is to also automatically detect the
>> >>> transport. For example, if A is non-ros and you want to send it to a
>> >>> ROS
>> >>> topic, you need to iterate over *all* types, check if they have a ROS
>> >>> transport *and* are convertible from A. Then you know what to do:
>> >>> convert A
>> >>> to that ROS type (using a ChannelConversionElement) and send it to a
>> >>> ros
>> >>> topic.
>> >>
>> >>
>> >> It's the intention of the current patch-set that the
>> >> getAnyProtocol(P)/createAnyStream(P) functions do that: ask typeinfo of
>> >> A to
>> >> get a protocol or create a stream in order to transport 'A' over
>> >> protocol
>> >> 'P'. This implies that these functions do the above lookup. Maybe
>> >> there's a
>> >> better/more straightforward way to do this...(ie do an explicit lookup)
>> >
>> >
>> > What's the difference you actually make between getAnyProtocol and the
>> > existing getProtocol?
>>
>> I wanted to leave the existing getProtocol 'as-is', in order to not
>> break any code relying on it: it returns the protocol of only this
>> type. getAnyProtocol() is smart, and tries to find a way to transport
>> type X over protocol P, even if a conversion is necessary. As Sylvain
>> pointed out, this could be weak if several conversions are possible
>> from X to P (say: convert KDL frame to a ROS tf message or ROS matrix
>> message).
>
>
> Ok, I see. Means that we should extend the definition of the ConnPolicy with
> an optional target type, so that one could write something that looks like:
> deployer.stream('myOutputPort<KDLFrame>', ConnPolicy('ROS', 'tf'))

Well, the protocol is a number (int), but the name_id field could also
be a place
to add this. It's format is unspecified, so protocol specific. For
ros, this is the topic name to publish on.
We could also allow to add type names (like "/camera/frame:tf" or
"tf@/camera/frame")

I'm not sure yet...

Peter

Wiki page summarizing the results of the ERF meeting

Submitted by Sylvain Joyeux on Mon, 2012-10-08 12:24.

On 10/08/2012 01:54 PM, Peter Soetens wrote:
>>
>> Ok, I see. Means that we should extend the definition of the ConnPolicy with
>> an optional target type, so that one could write something that looks like:
>> deployer.stream('myOutputPort<KDLFrame>', ConnPolicy('ROS', 'tf'))
> Well, the protocol is a number (int), but the name_id field could also
> be a place
> to add this. It's format is unspecified, so protocol specific. For
> ros, this is the topic name to publish on.
> We could also allow to add type names (like "/camera/frame:tf" or
> "tf@/camera/frame")
>
> I'm not sure yet...

One thing I suggested a while ago was to change the connection policies
to have a list of key/value pairs that would be protocol-specific,
instead of forever encoding piles of stuff in name_id

Sylvain

Wiki page summarizing the results of the ERF meeting

Submitted by peter on Mon, 2012-10-08 12:40.

On Mon, Oct 8, 2012 at 2:19 PM, Sylvain Joyeux <sylvain [dot] joyeux [..] ...> wrote:
> On 10/08/2012 01:54 PM, Peter Soetens wrote:
>>>
>>>
>>> Ok, I see. Means that we should extend the definition of the ConnPolicy
>>> with
>>> an optional target type, so that one could write something that looks
>>> like:
>>> deployer.stream('myOutputPort<KDLFrame>', ConnPolicy('ROS', 'tf'))
>>
>> Well, the protocol is a number (int), but the name_id field could also
>> be a place
>> to add this. It's format is unspecified, so protocol specific. For
>> ros, this is the topic name to publish on.
>> We could also allow to add type names (like "/camera/frame:tf" or
>> "tf@/camera/frame")
>>
>> I'm not sure yet...
>
>
> One thing I suggested a while ago was to change the connection policies to
> have a list of key/value pairs that would be protocol-specific, instead of
> forever encoding piles of stuff in name_id

I'm a big fan of key/value as well, but filling them in is more
cumbersome than creating a 'url'. Especially, it excludes one liners,
unless you encode your key/values in a single line as well (which I
would cause other problems such as escaping control characters etc.)
:-)

Peter

Wiki page summarizing the results of the ERF meeting

Submitted by Charles Lesire-... on Tue, 2012-10-09 11:36.

2012/10/8 Peter Soetens <peter [..] ...>

> On Mon, Oct 8, 2012 at 2:19 PM, Sylvain Joyeux <sylvain [dot] joyeux [..] ...>
> wrote:
> > On 10/08/2012 01:54 PM, Peter Soetens wrote:
> >>>
> >>>
> >>> Ok, I see. Means that we should extend the definition of the ConnPolicy
> >>> with
> >>> an optional target type, so that one could write something that looks
> >>> like:
> >>> deployer.stream('myOutputPort<KDLFrame>', ConnPolicy('ROS', 'tf'))
> >>
> >> Well, the protocol is a number (int), but the name_id field could also
> >> be a place
> >> to add this. It's format is unspecified, so protocol specific. For
> >> ros, this is the topic name to publish on.
> >> We could also allow to add type names (like "/camera/frame:tf" or
> >> "tf@/camera/frame")
> >>
> >> I'm not sure yet...
> >
> >
> > One thing I suggested a while ago was to change the connection policies
> to
> > have a list of key/value pairs that would be protocol-specific, instead
> of
> > forever encoding piles of stuff in name_id
>
> I'm a big fan of key/value as well, but filling them in is more
> cumbersome than creating a 'url'. Especially, it excludes one liners,
> unless you encode your key/values in a single line as well (which I
> would cause other problems such as escaping control characters etc.)
> :-)
>

I have rebased your branch on master, resolved some conflicts, and then
made some modifications to have the code compile :)

I have pushed this on the master-flexiport branch of the RTT gitorious repo.

Now it's time to implement the "empty" functions I have created
(getAny/createAny) ;)

I'll try to start implementing them by the end of this week...

Charles.

>
> Peter
>

Wiki page summarizing the results of the ERF meeting

Submitted by Charles Lesire-... on Thu, 2012-10-18 13:00.

2012/10/9 Charles Lesire-Cabaniols <charles [dot] lesire [..] ...>

>
>
> 2012/10/8 Peter Soetens <peter [..] ...>
>
>> On Mon, Oct 8, 2012 at 2:19 PM, Sylvain Joyeux <sylvain [dot] joyeux [..] ...>
>> wrote:
>> > On 10/08/2012 01:54 PM, Peter Soetens wrote:
>> >>>
>> >>>
>> >>> Ok, I see. Means that we should extend the definition of the
>> ConnPolicy
>> >>> with
>> >>> an optional target type, so that one could write something that looks
>> >>> like:
>> >>> deployer.stream('myOutputPort<KDLFrame>', ConnPolicy('ROS', 'tf'))
>> >>
>> >> Well, the protocol is a number (int), but the name_id field could also
>> >> be a place
>> >> to add this. It's format is unspecified, so protocol specific. For
>> >> ros, this is the topic name to publish on.
>> >> We could also allow to add type names (like "/camera/frame:tf" or
>> >> "tf@/camera/frame")
>> >>
>> >> I'm not sure yet...
>> >
>> >
>> > One thing I suggested a while ago was to change the connection policies
>> to
>> > have a list of key/value pairs that would be protocol-specific, instead
>> of
>> > forever encoding piles of stuff in name_id
>>
>> I'm a big fan of key/value as well, but filling them in is more
>> cumbersome than creating a 'url'. Especially, it excludes one liners,
>> unless you encode your key/values in a single line as well (which I
>> would cause other problems such as escaping control characters etc.)
>> :-)
>>
>
>
> I have rebased your branch on master, resolved some conflicts, and then
> made some modifications to have the code compile :)
>
> I have pushed this on the master-flexiport branch of the RTT gitorious
> repo.
>
> Now it's time to implement the "empty" functions I have created
> (getAny/createAny) ;)
>

Hi,

I tried to have a quite good understanding of the core of connections and
channels.

For the moment, I only focussed on local (ie in-process) connections with
type conversion.

My intuition is that I have to add a ChannelConversionElement in
between a ConnInputEndPoint and a Channel{Data,Buffer}Element.

So that the connections between an OuputPort and an InputPort would
be:

OutputPort -- ConnInputEndPoint -- ChannelConversionElement --
ChannelDataElement -- ConnOutputEndPoint -- InputPort

If this is the good way to go, I can start implementing that behavior for
local connections first.

Looking forward for your comments!

Charles.

>
> I'll try to start implementing them by the end of this week...
>
> Charles.
>
>
>
>>
>> Peter
>>
>
>

Wiki page summarizing the results of the ERF meeting

Submitted by peter on Thu, 2012-10-18 15:08.

Hi Charles,

On Thu, Oct 18, 2012 at 2:56 PM, Charles Lesire-Cabaniols
<charles [dot] lesire [..] ...> wrote:
>
>
> 2012/10/9 Charles Lesire-Cabaniols <charles [dot] lesire [..] ...>
>>
>>
>>
>> 2012/10/8 Peter Soetens <peter [..] ...>
>>>
>>> On Mon, Oct 8, 2012 at 2:19 PM, Sylvain Joyeux <sylvain [dot] joyeux [..] ...>
>>> wrote:
>>> > On 10/08/2012 01:54 PM, Peter Soetens wrote:
>>> >>>
>>> >>>
>>> >>> Ok, I see. Means that we should extend the definition of the
>>> >>> ConnPolicy
>>> >>> with
>>> >>> an optional target type, so that one could write something that looks
>>> >>> like:
>>> >>> deployer.stream('myOutputPort<KDLFrame>', ConnPolicy('ROS', 'tf'))
>>> >>
>>> >> Well, the protocol is a number (int), but the name_id field could also
>>> >> be a place
>>> >> to add this. It's format is unspecified, so protocol specific. For
>>> >> ros, this is the topic name to publish on.
>>> >> We could also allow to add type names (like "/camera/frame:tf" or
>>> >> "tf@/camera/frame")
>>> >>
>>> >> I'm not sure yet...
>>> >
>>> >
>>> > One thing I suggested a while ago was to change the connection policies
>>> > to
>>> > have a list of key/value pairs that would be protocol-specific, instead
>>> > of
>>> > forever encoding piles of stuff in name_id
>>>
>>> I'm a big fan of key/value as well, but filling them in is more
>>> cumbersome than creating a 'url'. Especially, it excludes one liners,
>>> unless you encode your key/values in a single line as well (which I
>>> would cause other problems such as escaping control characters etc.)
>>> :-)
>>
>>
>>
>> I have rebased your branch on master, resolved some conflicts, and then
>> made some modifications to have the code compile :)
>>
>> I have pushed this on the master-flexiport branch of the RTT gitorious
>> repo.
>>
>> Now it's time to implement the "empty" functions I have created
>> (getAny/createAny) ;)
>
>
> Hi,
>
> I tried to have a quite good understanding of the core of connections and
> channels.
>
> For the moment, I only focussed on local (ie in-process) connections with
> type conversion.
>
> My intuition is that I have to add a ChannelConversionElement in
> between a ConnInputEndPoint and a Channel{Data,Buffer}Element.
>
> So that the connections between an OuputPort and an InputPort would
> be:
>
> OutputPort -- ConnInputEndPoint -- ChannelConversionElement --
> ChannelDataElement -- ConnOutputEndPoint -- InputPort

This is correct. However, from a performance point of view, you could better do:

OutputPort -- ConnInputEndPoint -- ChannelDataElement --
ChannelConversionElement -- ConnOutputEndPoint -- InputPort

Such that:
- only effectively read samples must be converted
- the reader/subscriber thread gets the work and not the publisher/writer

>
> If this is the good way to go, I can start implementing that behavior for
> local connections first.

That would be a great start for many people already !

>
> Looking forward for your comments!
>
> Charles.

Peter

Wiki page summarizing the results of the ERF meeting

Submitted by Sylvain Joyeux on Thu, 2012-10-18 15:20.

On 10/18/2012 05:03 PM, Peter Soetens wrote:
> Hi Charles,
>
> On Thu, Oct 18, 2012 at 2:56 PM, Charles Lesire-Cabaniols
> <charles [dot] lesire [..] ...> wrote:
>>
>> 2012/10/9 Charles Lesire-Cabaniols <charles [dot] lesire [..] ...>
>>>
>>>
>>> 2012/10/8 Peter Soetens <peter [..] ...>
>>>> On Mon, Oct 8, 2012 at 2:19 PM, Sylvain Joyeux <sylvain [dot] joyeux [..] ...>
>>>> wrote:
>>>>> On 10/08/2012 01:54 PM, Peter Soetens wrote:
>>>>>>>
>>>>>>> Ok, I see. Means that we should extend the definition of the
>>>>>>> ConnPolicy
>>>>>>> with
>>>>>>> an optional target type, so that one could write something that looks
>>>>>>> like:
>>>>>>> deployer.stream('myOutputPort<KDLFrame>', ConnPolicy('ROS', 'tf'))
>>>>>> Well, the protocol is a number (int), but the name_id field could also
>>>>>> be a place
>>>>>> to add this. It's format is unspecified, so protocol specific. For
>>>>>> ros, this is the topic name to publish on.
>>>>>> We could also allow to add type names (like "/camera/frame:tf" or
>>>>>> "tf@/camera/frame")
>>>>>>
>>>>>> I'm not sure yet...
>>>>>
>>>>> One thing I suggested a while ago was to change the connection policies
>>>>> to
>>>>> have a list of key/value pairs that would be protocol-specific, instead
>>>>> of
>>>>> forever encoding piles of stuff in name_id
>>>> I'm a big fan of key/value as well, but filling them in is more
>>>> cumbersome than creating a 'url'. Especially, it excludes one liners,
>>>> unless you encode your key/values in a single line as well (which I
>>>> would cause other problems such as escaping control characters etc.)
>>>> :-)
>>>
>>>
>>> I have rebased your branch on master, resolved some conflicts, and then
>>> made some modifications to have the code compile :)
>>>
>>> I have pushed this on the master-flexiport branch of the RTT gitorious
>>> repo.
>>>
>>> Now it's time to implement the "empty" functions I have created
>>> (getAny/createAny) ;)
>>
>> Hi,
>>
>> I tried to have a quite good understanding of the core of connections and
>> channels.
>>
>> For the moment, I only focussed on local (ie in-process) connections with
>> type conversion.
>>
>> My intuition is that I have to add a ChannelConversionElement in
>> between a ConnInputEndPoint and a Channel{Data,Buffer}Element.
>>
>> So that the connections between an OuputPort and an InputPort would
>> be:
>>
>> OutputPort -- ConnInputEndPoint -- ChannelConversionElement --
>> ChannelDataElement -- ConnOutputEndPoint -- InputPort
> This is correct. However, from a performance point of view, you could better do:
>
> OutputPort -- ConnInputEndPoint -- ChannelDataElement --
> ChannelConversionElement -- ConnOutputEndPoint -- InputPort
>
> Such that:
> - only effectively read samples must be converted
> - the reader/subscriber thread gets the work and not the publisher/writer
Actually, it depends what performance you are talking about. Assuming
that the amount of information in the converted_type is at most as much
as the amount of information in the original one, the bandwidth is going
to be lower or equal if you do the conversion before. Otherwise, I
agree, the CPU load is going to be higher.

So, not so clear cut ;-)

Sylvain

Wiki page summarizing the results of the ERF meeting

Submitted by Charles Lesire-... on Fri, 2012-10-19 12:28.

2012/10/18 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>

> On 10/18/2012 05:03 PM, Peter Soetens wrote:
>
>> Hi Charles,
>>
>> On Thu, Oct 18, 2012 at 2:56 PM, Charles Lesire-Cabaniols
>> <charles [dot] lesire [..] ...> wrote:
>>
>>>
>>> 2012/10/9 Charles Lesire-Cabaniols <charles [dot] lesire [..] ...>
>>>
>>>>
>>>>
>>>> 2012/10/8 Peter Soetens <peter [..] ...>
>>>>
>>>>> On Mon, Oct 8, 2012 at 2:19 PM, Sylvain Joyeux <sylvain [dot] joyeux [..] ...
>>>>> >
>>>>> wrote:
>>>>>
>>>>>> On 10/08/2012 01:54 PM, Peter Soetens wrote:
>>>>>>
>>>>>>>
>>>>>>>> Ok, I see. Means that we should extend the definition of the
>>>>>>>> ConnPolicy
>>>>>>>> with
>>>>>>>> an optional target type, so that one could write something that
>>>>>>>> looks
>>>>>>>> like:
>>>>>>>> deployer.stream('myOutputPort<**KDLFrame>', ConnPolicy('ROS',
>>>>>>>> 'tf'))
>>>>>>>>
>>>>>>> Well, the protocol is a number (int), but the name_id field could
>>>>>>> also
>>>>>>> be a place
>>>>>>> to add this. It's format is unspecified, so protocol specific. For
>>>>>>> ros, this is the topic name to publish on.
>>>>>>> We could also allow to add type names (like "/camera/frame:tf" or
>>>>>>> "tf@/camera/frame")
>>>>>>>
>>>>>>> I'm not sure yet...
>>>>>>>
>>>>>>
>>>>>> One thing I suggested a while ago was to change the connection
>>>>>> policies
>>>>>> to
>>>>>> have a list of key/value pairs that would be protocol-specific,
>>>>>> instead
>>>>>> of
>>>>>> forever encoding piles of stuff in name_id
>>>>>>
>>>>> I'm a big fan of key/value as well, but filling them in is more
>>>>> cumbersome than creating a 'url'. Especially, it excludes one liners,
>>>>> unless you encode your key/values in a single line as well (which I
>>>>> would cause other problems such as escaping control characters etc.)
>>>>> :-)
>>>>>
>>>>
>>>>
>>>> I have rebased your branch on master, resolved some conflicts, and then
>>>> made some modifications to have the code compile :)
>>>>
>>>> I have pushed this on the master-flexiport branch of the RTT gitorious
>>>> repo.
>>>>
>>>> Now it's time to implement the "empty" functions I have created
>>>> (getAny/createAny) ;)
>>>>
>>>
>>> Hi,
>>>
>>> I tried to have a quite good understanding of the core of connections and
>>> channels.
>>>
>>> For the moment, I only focussed on local (ie in-process) connections with
>>> type conversion.
>>>
>>> My intuition is that I have to add a ChannelConversionElement in
>>> between a ConnInputEndPoint and a Channel{Data,Buffer}Element**.
>>>
>>> So that the connections between an OuputPort and an InputPort would
>>> be:
>>>
>>> OutputPort -- ConnInputEndPoint -- ChannelConversionElement --
>>> ChannelDataElement -- ConnOutputEndPoint -- InputPort
>>>
>> This is correct. However, from a performance point of view, you could
>> better do:
>>
>> OutputPort -- ConnInputEndPoint -- ChannelDataElement --
>> ChannelConversionElement -- ConnOutputEndPoint -- InputPort
>>
>> Such that:
>> - only effectively read samples must be converted
>> - the reader/subscriber thread gets the work and not the publisher/writer
>>
>

Ok, I see.

Now I am completely stuck into the templating mess ;)

My problem is that to use the ChannelConversionElement, I must template the
ConnFactory methods creating them with A and B.

And the 'createConnection' method itself is only templated with A.

So I actually don't see how to have type B reborn in the ConnFactory logic.

Peter, as you defined the ChannelConversionElement , did you already
had in mind how to integrate it in createConnection ?

> Actually, it depends what performance you are talking about. Assuming
> that the amount of information in the converted_type is at most as much as
> the amount of information in the original one, the bandwidth is going to be
> lower or equal if you do the conversion before. Otherwise, I agree, the CPU
> load is going to be higher.
>
> So, not so clear cut ;-)
>
> Sylvain
>

Wiki page summarizing the results of the ERF meeting

Submitted by peter on Fri, 2012-10-19 13:00.

Hi Charles,

On Fri, Oct 19, 2012 at 2:25 PM, Charles Lesire-Cabaniols
<charles [dot] lesire [..] ...> wrote:
>
>
> 2012/10/18 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>
>>
>> On 10/18/2012 05:03 PM, Peter Soetens wrote:
>>>
>>> Hi Charles,
>>>
>>> On Thu, Oct 18, 2012 at 2:56 PM, Charles Lesire-Cabaniols
>>> <charles [dot] lesire [..] ...> wrote:
>>>>
>>>>
>>>> 2012/10/9 Charles Lesire-Cabaniols <charles [dot] lesire [..] ...>
>>>>>
>>>>>
>>>>>
>>>>> 2012/10/8 Peter Soetens <peter [..] ...>
>>>>>>
>>>>>> On Mon, Oct 8, 2012 at 2:19 PM, Sylvain Joyeux
>>>>>> <sylvain [dot] joyeux [..] ...>
>>>>>> wrote:
>>>>>>>
>>>>>>> On 10/08/2012 01:54 PM, Peter Soetens wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Ok, I see. Means that we should extend the definition of the
>>>>>>>>> ConnPolicy
>>>>>>>>> with
>>>>>>>>> an optional target type, so that one could write something that
>>>>>>>>> looks
>>>>>>>>> like:
>>>>>>>>> deployer.stream('myOutputPort<KDLFrame>', ConnPolicy('ROS', 'tf'))
>>>>>>>>
>>>>>>>> Well, the protocol is a number (int), but the name_id field could
>>>>>>>> also
>>>>>>>> be a place
>>>>>>>> to add this. It's format is unspecified, so protocol specific. For
>>>>>>>> ros, this is the topic name to publish on.
>>>>>>>> We could also allow to add type names (like "/camera/frame:tf" or
>>>>>>>> "tf@/camera/frame")
>>>>>>>>
>>>>>>>> I'm not sure yet...
>>>>>>>
>>>>>>>
>>>>>>> One thing I suggested a while ago was to change the connection
>>>>>>> policies
>>>>>>> to
>>>>>>> have a list of key/value pairs that would be protocol-specific,
>>>>>>> instead
>>>>>>> of
>>>>>>> forever encoding piles of stuff in name_id
>>>>>>
>>>>>> I'm a big fan of key/value as well, but filling them in is more
>>>>>> cumbersome than creating a 'url'. Especially, it excludes one liners,
>>>>>> unless you encode your key/values in a single line as well (which I
>>>>>> would cause other problems such as escaping control characters etc.)
>>>>>> :-)
>>>>>
>>>>>
>>>>>
>>>>> I have rebased your branch on master, resolved some conflicts, and then
>>>>> made some modifications to have the code compile :)
>>>>>
>>>>> I have pushed this on the master-flexiport branch of the RTT gitorious
>>>>> repo.
>>>>>
>>>>> Now it's time to implement the "empty" functions I have created
>>>>> (getAny/createAny) ;)
>>>>
>>>>
>>>> Hi,
>>>>
>>>> I tried to have a quite good understanding of the core of connections
>>>> and
>>>> channels.
>>>>
>>>> For the moment, I only focussed on local (ie in-process) connections
>>>> with
>>>> type conversion.
>>>>
>>>> My intuition is that I have to add a ChannelConversionElement in
>>>> between a ConnInputEndPoint and a Channel{Data,Buffer}Element.
>>>>
>>>> So that the connections between an OuputPort and an InputPort
>>>> would
>>>> be:
>>>>
>>>> OutputPort -- ConnInputEndPoint -- ChannelConversionElement
>>>> --
>>>> ChannelDataElement -- ConnOutputEndPoint -- InputPort
>>>
>>> This is correct. However, from a performance point of view, you could
>>> better do:
>>>
>>> OutputPort -- ConnInputEndPoint -- ChannelDataElement --
>>> ChannelConversionElement -- ConnOutputEndPoint -- InputPort
>>>
>>> Such that:
>>> - only effectively read samples must be converted
>>> - the reader/subscriber thread gets the work and not the publisher/writer
>
>
>
> Ok, I see.
>
> Now I am completely stuck into the templating mess ;)
>
> My problem is that to use the ChannelConversionElement, I must template the
> ConnFactory methods creating them with A and B.
>
> And the 'createConnection' method itself is only templated with A.
>
> So I actually don't see how to have type B reborn in the ConnFactory logic.
>
> Peter, as you defined the ChannelConversionElement , did you already had
> in mind how to integrate it in createConnection ?

I must have thought that was an implementation detail :-)

Apart from that, you're completely right. We can't invent at run-time
a CCE , so:
- Either this conversion must be known at compile time, OR
- we find a solution without templates, OR
- a split CCEFrom and CCETo and add these as factories to the
typekit's port factory interface

I would try to bar the compile time option, because this would mean
that every typekit constructor object with arity 1 (ie one argument),
would also need to generate a CCE where A is the argument and B
is the constructed object.

I can't see how we can solve this without templates, except using
typelib, which could do the conversion for us (can hear Sylvain crying
and laughing at the same time now...oh wait, that's me!)

The third option would require CCEFrom to pass on an A to the
constructor object (using a ReferenceDataSource to a value stored in
CCEFrom ), and CCETo to evaluate&get() the constructor object.
Both elements would have a shared_ptr to this object.

The middle option is certainly the most efficient. The third option
should work too though.

Peter

Wiki page summarizing the results of the ERF meeting

Submitted by Charles Lesire-... on Fri, 2012-10-19 13:12.

2012/10/19 Peter Soetens <peter [..] ...>

> Hi Charles,
>
> On Fri, Oct 19, 2012 at 2:25 PM, Charles Lesire-Cabaniols
> <charles [dot] lesire [..] ...> wrote:
> >
> >
> > 2012/10/18 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>
> >>
> >> On 10/18/2012 05:03 PM, Peter Soetens wrote:
> >>>
> >>> Hi Charles,
> >>>
> >>> On Thu, Oct 18, 2012 at 2:56 PM, Charles Lesire-Cabaniols
> >>> <charles [dot] lesire [..] ...> wrote:
> >>>>
> >>>>
> >>>> 2012/10/9 Charles Lesire-Cabaniols <charles [dot] lesire [..] ...>
> >>>>>
> >>>>>
> >>>>>
> >>>>> 2012/10/8 Peter Soetens <peter [..] ...>
> >>>>>>
> >>>>>> On Mon, Oct 8, 2012 at 2:19 PM, Sylvain Joyeux
> >>>>>> <sylvain [dot] joyeux [..] ...>
> >>>>>> wrote:
> >>>>>>>
> >>>>>>> On 10/08/2012 01:54 PM, Peter Soetens wrote:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Ok, I see. Means that we should extend the definition of the
> >>>>>>>>> ConnPolicy
> >>>>>>>>> with
> >>>>>>>>> an optional target type, so that one could write something that
> >>>>>>>>> looks
> >>>>>>>>> like:
> >>>>>>>>> deployer.stream('myOutputPort<KDLFrame>', ConnPolicy('ROS',
> 'tf'))
> >>>>>>>>
> >>>>>>>> Well, the protocol is a number (int), but the name_id field could
> >>>>>>>> also
> >>>>>>>> be a place
> >>>>>>>> to add this. It's format is unspecified, so protocol specific. For
> >>>>>>>> ros, this is the topic name to publish on.
> >>>>>>>> We could also allow to add type names (like "/camera/frame:tf" or
> >>>>>>>> "tf@/camera/frame")
> >>>>>>>>
> >>>>>>>> I'm not sure yet...
> >>>>>>>
> >>>>>>>
> >>>>>>> One thing I suggested a while ago was to change the connection
> >>>>>>> policies
> >>>>>>> to
> >>>>>>> have a list of key/value pairs that would be protocol-specific,
> >>>>>>> instead
> >>>>>>> of
> >>>>>>> forever encoding piles of stuff in name_id
> >>>>>>
> >>>>>> I'm a big fan of key/value as well, but filling them in is more
> >>>>>> cumbersome than creating a 'url'. Especially, it excludes one
> liners,
> >>>>>> unless you encode your key/values in a single line as well (which I
> >>>>>> would cause other problems such as escaping control characters etc.)
> >>>>>> :-)
> >>>>>
> >>>>>
> >>>>>
> >>>>> I have rebased your branch on master, resolved some conflicts, and
> then
> >>>>> made some modifications to have the code compile :)
> >>>>>
> >>>>> I have pushed this on the master-flexiport branch of the RTT
> gitorious
> >>>>> repo.
> >>>>>
> >>>>> Now it's time to implement the "empty" functions I have created
> >>>>> (getAny/createAny) ;)
> >>>>
> >>>>
> >>>> Hi,
> >>>>
> >>>> I tried to have a quite good understanding of the core of connections
> >>>> and
> >>>> channels.
> >>>>
> >>>> For the moment, I only focussed on local (ie in-process) connections
> >>>> with
> >>>> type conversion.
> >>>>
> >>>> My intuition is that I have to add a ChannelConversionElement in
> >>>> between a ConnInputEndPoint and a Channel{Data,Buffer}Element.
> >>>>
> >>>> So that the connections between an OuputPort and an InputPort
> >>>> would
> >>>> be:
> >>>>
> >>>> OutputPort -- ConnInputEndPoint -- ChannelConversionElement
> >>>> --
> >>>> ChannelDataElement -- ConnOutputEndPoint -- InputPort
> >>>
> >>> This is correct. However, from a performance point of view, you could
> >>> better do:
> >>>
> >>> OutputPort -- ConnInputEndPoint -- ChannelDataElement --
> >>> ChannelConversionElement -- ConnOutputEndPoint -- InputPort
> >>>
> >>> Such that:
> >>> - only effectively read samples must be converted
> >>> - the reader/subscriber thread gets the work and not the
> publisher/writer
> >
> >
> >
> > Ok, I see.
> >
> > Now I am completely stuck into the templating mess ;)
> >
> > My problem is that to use the ChannelConversionElement, I must template
> the
> > ConnFactory methods creating them with A and B.
> >
> > And the 'createConnection' method itself is only templated with A.
> >
> > So I actually don't see how to have type B reborn in the ConnFactory
> logic.
> >
> > Peter, as you defined the ChannelConversionElement , did you already
> had
> > in mind how to integrate it in createConnection ?
>
> I must have thought that was an implementation detail :-)
>
> Apart from that, you're completely right. We can't invent at run-time
> a CCE , so:
> - Either this conversion must be known at compile time, OR
> - we find a solution without templates, OR
> - a split CCEFrom and CCETo and add these as factories to the
> typekit's port factory interface
>
> I would try to bar the compile time option, because this would mean
> that every typekit constructor object with arity 1 (ie one argument),
> would also need to generate a CCE where A is the argument and B
> is the constructed object.
>

That's actually why I am stuck: I clearly dropped this solution also!

>
> I can't see how we can solve this without templates, except using
> typelib, which could do the conversion for us (can hear Sylvain crying
> and laughing at the same time now...oh wait, that's me!)
>
> The third option would require CCEFrom to pass on an A to the
> constructor object (using a ReferenceDataSource to a value stored in
> CCEFrom ), and CCETo to evaluate&get() the constructor object.
> Both elements would have a shared_ptr to this object.
>

Ok. That's why I had in mind actually, but as I started writing the
CCE , I was wondering whether you had the "magic" idea I couldn't even
figure out! ;)
Let's see how far I can go with this solution...

>
> The middle option is certainly the most efficient. The third option
> should work too though.
>
> Peter
>

Wiki page summarizing the results of the ERF meeting

Submitted by Sylvain Joyeux on Fri, 2012-10-05 14:16.

On 10/05/2012 03:51 PM, Peter Soetens wrote:
> Next, the tricky part is in the ConnFactory, where for normal
> in-process connections and outwards connections (ros, corba,
> yarp,...), and out-of-band connections a conversion must be done.
> You'll have to
> 1. detect that both types don't match (A != B) -> type info pointer
> comparisons !
> 2. lookup if you can construct a B from an A -> lookup constructors in
> typeinfo of B
> 3. Use this constructor in a ChannelConversionElement, using classical
> ReferenceDataSource constructs.
> 4. Do this in the right places of ConnFactory functions.
>
> Finally, the last challenge is to also automatically detect the
> transport. For example, if A is non-ros and you want to send it to a
> ROS topic, you need to iterate over *all* types, check if they have a
> ROS transport *and* are convertible from A. Then you know what to do:
> convert A to that ROS type (using a ChannelConversionElement) and send
> it to a ros topic.
MMmmm. I would so much like to have time to work on this. /me smells
generic typelib-based type slicing :P

Sylvain

Wiki page summarizing the results of the ERF meeting

Submitted by Sylvain Joyeux on Fri, 2012-10-05 14:00.

On 10/05/2012 03:51 PM, Peter Soetens wrote:
> Hi Charles,
>
> On Fri, Oct 5, 2012 at 9:15 AM, Charles Lesire-Cabaniols
> <charles [dot] lesire [..] ... charles [dot] lesire [..] ...>> wrote:
>
>
>
> 2012/10/4 Sylvain Joyeux <sylvain [dot] joyeux [..] ...
> <mailto:sylvain [dot] joyeux [..] ...>>
>
> On 10/04/2012 11:30 AM, Charles Lesire-Cabaniols wrote:
>>
>>
>> 2012/10/4 Sylvain Joyeux <sylvain [dot] joyeux [..] ...
>> <mailto:sylvain [dot] joyeux [..] ...>>
>>
>> On 10/04/2012 11:21 AM, Peter Soetens wrote:
>>
>>
>>
>> Thanks a lot for this pre-testing. I don't have the
>> time budget to do an official pre-release, so people
>> will have to stick to master to test the latest changes.
>>
>> Regarding testing method: We will only merge on
>> master code that builds (full toolchain!) + passes
>> unit tests. At that point, people can test their
>> applications against it. Other code should be in
>> branches until it works out.
>>
>> I've updated orogen and orocos.rb to fit the new RTT type
>> info, and both their test suites are passing fine. That's
>> also a good indication ;-)
>>
>>
>>
>> So now, the data flow type conversion should work just be
>> defining a constructor that converts a type A into a type B?
>> And then connecting an OutputPort to an InputPort?
> Nope. I don't think that anything has been implemented at all
> in this direction.
>
>
> Ok. So when I woke up this thread, it was to know the status of
> the "ROS compatibility without ROS", i.e. connecting my components
> that have non-ROS type to ROS topics.
>
> I thought it was the aim of the branch I was testing...
>
>
> Yes, as a first step :-)
>
>
> What are the needed improvements to make this compatibility
> available? How could I help?
>
>
> There is another branch :-)
>
> It's the flexiport branch. It contains some patches, which don't
> compile, but setup some structure to make this work. First, it needs a
> specially crafted ChannelConversionElement which inherits from
> ChannelElement and ChannelElement. Where A is convertible to B.
> A rudimentary implementation exists on the flexiport branch.
>
> You will need to rebase flexiport on the latest master, or at least
> extract the patches manually and apply them on master (two patches
> dated Jun 26, 2012)
>
> https://github.com/psoetens/orocos-rtt/tree/master-flexiport
>
> Next, the tricky part is in the ConnFactory, where for normal
> in-process connections and outwards connections (ros, corba,
> yarp,...), and out-of-band connections a conversion must be done.
> You'll have to
> 1. detect that both types don't match (A != B) -> type info pointer
> comparisons !
> 2. lookup if you can construct a B from an A -> lookup constructors in
> typeinfo of B
> 3. Use this constructor in a ChannelConversionElement, using classical
> ReferenceDataSource constructs.
> 4. Do this in the right places of ConnFactory functions.
>
> Finally, the last challenge is to also automatically detect the
> transport. For example, if A is non-ros and you want to send it to a
> ROS topic, you need to iterate over *all* types, check if they have a
> ROS transport *and* are convertible from A. Then you know what to do:
> convert A to that ROS type (using a ChannelConversionElement) and send
> it to a ros topic.
I would rather go for registering the B transport on the typeinfo of A.
The connection code would then have to handle that the "transport
element" is of type B and there is therefore the need to create a
conversion element. Automatically picking one would be way too fragile
(what if there is more than one ?).

Wiki page summarizing the results of the ERF meeting

Submitted by Sylvain Joyeux on Fri, 2012-10-05 11:56.

The work that Peter did so far was a first needed step as it makes
registrations of the different parts of the type info separate. This
means that typegen could generate a typekit, and then another plugin
registers the convertion functions. I do plan to support convertion in
orogen/typegen itself, though to avoid the need for users to deal with
the typekit API.

Wiki page summarizing the results of the ERF meeting

Submitted by Sylvain Joyeux on Fri, 2012-10-05 11:52.

On 10/05/2012 09:15 AM, Charles Lesire-Cabaniols wrote:
>
>
> 2012/10/4 Sylvain Joyeux <sylvain [dot] joyeux [..] ...
> <mailto:sylvain [dot] joyeux [..] ...>>
>
> On 10/04/2012 11:30 AM, Charles Lesire-Cabaniols wrote:
>>
>>
>> 2012/10/4 Sylvain Joyeux <sylvain [dot] joyeux [..] ...
>> <mailto:sylvain [dot] joyeux [..] ...>>
>>
>> On 10/04/2012 11:21 AM, Peter Soetens wrote:
>>
>>
>>
>> Thanks a lot for this pre-testing. I don't have the time
>> budget to do an official pre-release, so people will have
>> to stick to master to test the latest changes.
>>
>> Regarding testing method: We will only merge on master
>> code that builds (full toolchain!) + passes unit tests.
>> At that point, people can test their applications against
>> it. Other code should be in branches until it works out.
>>
>> I've updated orogen and orocos.rb to fit the new RTT type
>> info, and both their test suites are passing fine. That's
>> also a good indication ;-)
>>
>>
>>
>> So now, the data flow type conversion should work just be
>> defining a constructor that converts a type A into a type B? And
>> then connecting an OutputPort to an InputPort?
> Nope. I don't think that anything has been implemented at all in
> this direction.
>
>
> Ok. So when I woke up this thread, it was to know the status of the
> "ROS compatibility without ROS", i.e. connecting my components that
> have non-ROS type to ROS topics.
>
> I thought it was the aim of the branch I was testing...
>
> What are the needed improvements to make this compatibility available?
> How could I help?
I have not looked at it specifically, so I only have the basis for
discussion from the ERF. The idea was:

- register A.constructor(B) as a convertion function
- make the connection logic aware of these constructors (both in the
local, corba and stream cases. There is a lot of duplication here). In
principle, the only thing needed is to define the
ChannelConvertionElement<In, Out> template element and register it at
one of the ends of the channel.
- in principle, I was for converting on the sending side in the
connection case and output-to-stream cases, and on the receiving side
for stream-to-input case. I don't think we discussed whether the
convertion in the connection case should be made configurable.

Wiki page summarizing the results of the ERF meeting

Submitted by peter on Thu, 2012-09-27 14:48.

Hi Charles,

Since this is a generated file, it would help if you could attach/send that
.cpp file.

Cheers,
Peter

On Thu, Sep 27, 2012 at 4:24 PM, Charles Lesire-Cabaniols <
charles [dot] lesire [..] ...> wrote:

Wiki page summarizing the results of the ERF meeting

Submitted by Charles Lesire-... on Tue, 2012-06-26 09:20.

2012/6/26 Charles Lesire-Cabaniols <charles [dot] lesire [..] ...>

>
>
> 2012/6/26 Peter Soetens <peter [..] ...>
>
>> Hi Charles,
>>
>> On Tue, Jun 26, 2012 at 10:28 AM, Charles Lesire-Cabaniols <
>> charles [dot] lesire [..] ...> wrote:
>>
>>>
>>>
>>> 2012/3/21 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>
>>>
>>>>
>>>> http://www.orocos.org/wiki/main-page/development/orocos-developers-meetu...
>>>>
>>>
>>> Hi all,
>>>
>>> What's the status of the "Dataflow between ROS and Rock / plain Orocos"?
>>>
>>> I am definitely looking for a way to make my Orocos components usable in
>>> a ROS network without having them depending on ROS, i.e. components' ports
>>> have non-ROS types!
>>>
>>
>> I had spent a few hours on this, but didn't get far yet, let alone test
>> the code. You can see my progress on my github account here:
>>
>> https://github.com/psoetens/orocos-rtt/commits/master-flexiport
>>
>> The idea is that two major additions must be in place:
>>
>> 1. Create a channel element which can receive type A and send out type B
>> (data flow conversion)
>> 2. Extend the transport mechanism such that it tries harder to find a
>> transport for type A (eg non-ros) by converting it to type B (ros msg type)
>> using step 1. and then sending out the ROS message B. This would
>> automatically work for other transports as well, as long as the RTT type
>> info constructor A<->B is known.
>>
>> So our users would create a 'ROS' transport for type A, although A is ROS
>> independent, but does have a constructor in type B for creating a B from an
>> A.
>>
>
Just a reminder that the Orocos-Communication project on gitorious (
gitorious.org/orocos-communication) is ready to welcome a 'ros-transport' :)

>
>> This also depends on the type system refactoring I completed earlier (see
>> commit history) but didn't dare to post yet :-) I guess it's sorta out
>> now...
>>
>> The type info redux patchset passes all unit tests, but there are no
>> patches yet for OCL or oro/typegen, although these are expected to be minor
>> and consequent. The last part is especially why I didn't push anything like
>> this to master yet...
>>
>
> I can help, at least in testing, if you give me some tips how to get all
> the necessary sources, and what kind of basic tests I could make.
>
> I can even participate to the development if you give me quite "clear"
> instructions :)
>
> Charles.
>
>
>
>>
>> Peter
>>
>>
>>>
>>>
>>> Charles.
>>>
>>>
>>>
>>>> Sylvain
>>>> --
>>>> Orocos-Dev mailing list
>>>> Orocos-Dev [..] ...
>>>> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>>>>
>>>
>>>
>>> --
>>> Orocos-Dev mailing list
>>> Orocos-Dev [..] ...
>>> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>>>
>>>
>>
>

Wiki page summarizing the results of the ERF meeting

Submitted by willy on Wed, 2012-03-21 10:40.

2012/3/21 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>:
> http://www.orocos.org/wiki/main-page/development/orocos-developers-meetu...
>
> Sylvain
> --
> Orocos-Dev mailing list
> Orocos-Dev [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev

Very nice perpectives. Can't wait to see them. FYI, some of the point
here are the reasons why I am not using Rock at all.

Wiki page summarizing the results of the ERF meeting

Submitted by Sylvain Joyeux on Thu, 2012-03-29 09:32.

On 03/21/2012 11:37 AM, Willy Lambert wrote:
> 2012/3/21 Sylvain Joyeux<sylvain [dot] joyeux [..] ...>:
>> http://www.orocos.org/wiki/main-page/development/orocos-developers-meetu...
>>
>> Sylvain
>> --
>> Orocos-Dev mailing list
>> Orocos-Dev [..] ...
>> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>
> Very nice perpectives. Can't wait to see them. FYI, some of the point
> here are the reasons why I am not using Rock at all.

Could you be more specific at which of the points ;-)

Sylvain

Wiki page summarizing the results of the ERF meeting

Submitted by willy on Thu, 2012-03-29 10:04.

2012/3/29 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>:
> On 03/21/2012 11:37 AM, Willy Lambert wrote:
>>
>> 2012/3/21 Sylvain Joyeux<sylvain [dot] joyeux [..] ...>:
>>>
>>>
>>> http://www.orocos.org/wiki/main-page/development/orocos-developers-meetu...
>>>
>>> Sylvain
>>> --
>>> Orocos-Dev mailing list
>>> Orocos-Dev [..] ...
>>> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>>
>>
>> Very nice perpectives. Can't wait to see them. FYI, some of the point
>> here are the reasons why I am not using Rock at all.
>
>
> Could you be more specific at which of the points ;-)
>
> Sylvain

It was not more specific because the document is very accurate and
without having been part of this, it target all my bad feelings about
Rock. Mainly :

_ make as much as the Rock toolchain usable with "plain Orocos
components" (see below)
_ make the parallel usage of the three cases (Orocos toolchain, Orocos
in ROS and Rock) as painless as possible