CORBA deployer and ROS

Hi all,

My setup is as follows :

rtt_gazebo->CORBA->deployer-corba (my component that listens to some
rtt_gazebo ports).

I'm having trouble streaming a port to ROS in the deployer-corba. I get
this error (I tried also with simpler types as double,strings, same
results) :

The protocol with id 3 did not register a fall-back handler for unknown types!
triggered by: unknown_t which does not have a transport.
Could not create transport stream for port JointState with transport id 3
No such transport registered. Check your policy.transport settings or
add the transport for type JointState

The port is an Output port NOT connected to anyone.

So I'm wondering if it's possible to declare a port as an orocos "standard
port" (in the corba deployer) so the streaming can be done ?

In other words, if I import other components in the corba deployer, will
the transport be also done in corba ? I'd like my components to works as if
they were in the standard deployer, as corba is very limited in terms of
types he can handle.

Thank you!

Antoine

Note: I'm on Ubuntu 12.04+hydro+toolchain 2.7

CORBA deployer and ROS

2015-03-13 12:29 GMT+01:00 Antoine Hoarau <hoarau [dot] robotics [..] ...>:

> Hi all,
>
> My setup is as follows :
>
> rtt_gazebo->CORBA->deployer-corba (my component that listens to some
> rtt_gazebo ports).
>
> I'm having trouble streaming a port to ROS in the deployer-corba. I get
> this error (I tried also with simpler types as double,strings, same
> results) :
>
> The protocol with id 3 did not register a fall-back handler for unknown types!
> triggered by: unknown_t which does not have a transport.
> Could not create transport stream for port JointState with transport id 3
> No such transport registered. Check your policy.transport settings or add the transport for type JointState
>
>
> The port is an Output port NOT connected to anyone.
>

AFAIK (I'm working on ros electric and orocos 2.5), you can only stream
data types related to ROS messages. Hence for a double you won't have a
Output<double> but a Output<std_msgs::FLoat64> message type. This is due to
the fact that ROS doesn't know how to send a "double". What's is missing
is something in the Orocos streamer that would understand that a double
serializable in a std_msgs::FLoat64. It seem simple for basic types, but
it's not as easy for more complex structures as there is not necessarily a
"one to one" structure member mapping.

Personnaly, I have pure functionnal Orocos components which publish orocos
types, and bridge components that only do the bridge between Orocos and
ros. Hence in my example I would have :
_ a component A1 with a Output<double>
_ a component A2 with a Output<double>
_ a component Ros1 with 2 Input<double> and a ROS typed output message
(which is not necessarily 2 Output<std_msgs::FLoat64>, it could be a unique
message aggregating the 2 data).

I certainly arguable to do this job inside a dedicated component instead of
letting the communication middleware (aka transport ?) doing this job, BUT,
it's not as simple as you told us. When doing such inter-component
connexion you are either

1/ negociating an interface between 2 to-be-developed component, then
taking care about both side constraints (in terms of bandwidth,
event/periodic driven designs, data structure, ...). In my case, my Orocos
layer run at a 10ms frequency but my ROS layer at 100ms/1s frequency. It
would be stupid and toxic to stream orocos datas to the ROS layer at a 10ms
frequence. Hence my ROS bridge components are scheduled at a lower
frequency so that data is stream accordingly.

2/ connecting existing component with potential interface incompatibility,
hence you have to do some glue code/component/communication mdw addons so
that the connection is done smoothly. In my case I often have 2 different
data structures between my Orocos Layer and my Ros layer that are
aggregated or splitted in my Orocos bridges.

In both cases the choice to put a bridge on one side or the other (or
several on both side) is very dependent of your concrete use case. So it's
never as transparent as you would expect to assemble a system in 2
different ways.

>
> So I'm wondering if it's possible to declare a port as an orocos "standard
> port" (in the corba deployer) so the streaming can be done ?
>
> In other words, if I import other components in the corba deployer, will
> the transport be also done in corba ? I'd like my components to works as if
> they were in the standard deployer, as corba is very limited in terms of
> types he can handle.
>

__Components__ will run the same way, not the __System__ (oh my god, herman
speaking ^^).

>
> Thank you!
>
> Antoine
>
> Note: I'm on Ubuntu 12.04+hydro+toolchain 2.7
>
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>
>

CORBA deployer and ROS

2015-03-13 13:14 GMT+01:00 Willy Lambert <lambert [dot] willy [..] ...>:

>
>
> 2015-03-13 12:29 GMT+01:00 Antoine Hoarau <hoarau [dot] robotics [..] ...>:
>
>> Hi all,
>>
>> My setup is as follows :
>>
>> rtt_gazebo->CORBA->deployer-corba (my component that listens to some
>> rtt_gazebo ports).
>>
>> I'm having trouble streaming a port to ROS in the deployer-corba. I get
>> this error (I tried also with simpler types as double,strings, same
>> results) :
>>
>> The protocol with id 3 did not register a fall-back handler for unknown types!
>> triggered by: unknown_t which does not have a transport.
>> Could not create transport stream for port JointState with transport id 3
>> No such transport registered. Check your policy.transport settings or add the transport for type JointState
>>
>>
>> The port is an Output port NOT connected to anyone.
>>
>
> AFAIK (I'm working on ros electric and orocos 2.5), you can only stream
> data types related to ROS messages. Hence for a double you won't have a
> Output<double> but a Output<std_msgs::FLoat64> message type. This is due to
> the fact that ROS doesn't know how to send a "double". What's is missing
> is something in the Orocos streamer that would understand that a double
> serializable in a std_msgs::FLoat64. It seem simple for basic types, but
> it's not as easy for more complex structures as there is not necessarily a
> "one to one" structure member mapping.
>
> Personnaly, I have pure functionnal Orocos components which publish orocos
> types, and bridge components that only do the bridge between Orocos and
> ros. Hence in my example I would have :
> _ a component A1 with a Output<double>
> _ a component A2 with a Output<double>
> _ a component Ros1 with 2 Input<double> and a ROS typed output message
> (which is not necessarily 2 Output<std_msgs::FLoat64>, it could be a unique
> message aggregating the 2 data).
>
> I certainly arguable to do this job inside a dedicated component instead
> of letting the communication middleware (aka transport ?) doing this job,
> BUT, it's not as simple as you told us. When doing such inter-component
> connexion you are either
>
> 1/ negociating an interface between 2 to-be-developed component, then
> taking care about both side constraints (in terms of bandwidth,
> event/periodic driven designs, data structure, ...). In my case, my Orocos
> layer run at a 10ms frequency but my ROS layer at 100ms/1s frequency. It
> would be stupid and toxic to stream orocos datas to the ROS layer at a 10ms
> frequence. Hence my ROS bridge components are scheduled at a lower
> frequency so that data is stream accordingly.
>
> 2/ connecting existing component with potential interface incompatibility,
> hence you have to do some glue code/component/communication mdw addons so
> that the connection is done smoothly. In my case I often have 2 different
> data structures between my Orocos Layer and my Ros layer that are
> aggregated or splitted in my Orocos bridges.
>
> In both cases the choice to put a bridge on one side or the other (or
> several on both side) is very dependent of your concrete use case. So it's
> never as transparent as you would expect to assemble a system in 2
> different ways.
>
>
>
>
>
>
>
>>
>> So I'm wondering if it's possible to declare a port as an orocos
>> "standard port" (in the corba deployer) so the streaming can be done ?
>>
>> In other words, if I import other components in the corba deployer, will
>> the transport be also done in corba ? I'd like my components to works as if
>> they were in the standard deployer, as corba is very limited in terms of
>> types he can handle.
>>
>
> __Components__ will run the same way, not the __System__ (oh my god,
> herman speaking ^^).
>
>
>

I don't know from where comes the JoinState, but is may also be the
opposite : the corba transport may not exists for every ROS generated
messages (i really don't know the stauts about this).

If you use the JoinState from ROS anywhere in your application (I mean in
both Orocos and ROS side) you already have injected ROS framework dependent
code into Orocos one, then preventing those Orocos component to work
"transparently" in a pure Orocos system.

>
>> Thank you!
>>
>> Antoine
>>
>> Note: I'm on Ubuntu 12.04+hydro+toolchain 2.7
>>
>> --
>> Orocos-Users mailing list
>> Orocos-Users [..] ...
>> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>>
>>
>

CORBA deployer and ROS

Let me clarify the setup :
I'm using the rtt_gazebo package https://github.com/jhu-lcsr/rtt_gazebo

It's starting a deployer (corba) and a component (let's says A ) as a
gazebo plugin, so it's inside of gazebo, and you cannot have access to the
console.
The only way to communicate with A it is to open a new terminal and launch
a corba deployer to "connect" A with my other component B.

- A (inside gazebo) as Output port a <std::vector<std::string> >
- B as Input port b1 <std::vector<std::string> > connected to B via CORBA
(this works, I can read data).
- B as also an Output port b2 <sensor_msgs::JointState> (ROS type) that I
want to stream it to ROS (B is my bridge OROCOS/ROS).

This would workway if only the deployer was the standard one (it worked).
In this case, I have to use the CORBA deployer but now the streaming is not
working and I get the above message.

Le ven. 13 mars 2015 à 13:26, Willy Lambert <lambert [dot] willy [..] ...> a
écrit :

> 2015-03-13 13:14 GMT+01:00 Willy Lambert <lambert [dot] willy [..] ...>:
>
>>
>>
>> 2015-03-13 12:29 GMT+01:00 Antoine Hoarau <hoarau [dot] robotics [..] ...>:
>>
>>> Hi all,
>>>
>>> My setup is as follows :
>>>
>>> rtt_gazebo->CORBA->deployer-corba (my component that listens to some
>>> rtt_gazebo ports).
>>>
>>> I'm having trouble streaming a port to ROS in the deployer-corba. I get
>>> this error (I tried also with simpler types as double,strings, same
>>> results) :
>>>
>>> The protocol with id 3 did not register a fall-back handler for unknown types!
>>> triggered by: unknown_t which does not have a transport.
>>> Could not create transport stream for port JointState with transport id 3
>>> No such transport registered. Check your policy.transport settings or add the transport for type JointState
>>>
>>>
>>> The port is an Output port NOT connected to anyone.
>>>
>>
>> AFAIK (I'm working on ros electric and orocos 2.5), you can only stream
>> data types related to ROS messages. Hence for a double you won't have a
>> Output<double> but a Output<std_msgs::FLoat64> message type. This is due to
>> the fact that ROS doesn't know how to send a "double". What's is missing
>> is something in the Orocos streamer that would understand that a double
>> serializable in a std_msgs::FLoat64. It seem simple for basic types, but
>> it's not as easy for more complex structures as there is not necessarily a
>> "one to one" structure member mapping.
>>
>> Personnaly, I have pure functionnal Orocos components which publish
>> orocos types, and bridge components that only do the bridge between Orocos
>> and ros. Hence in my example I would have :
>> _ a component A1 with a Output<double>
>> _ a component A2 with a Output<double>
>> _ a component Ros1 with 2 Input<double> and a ROS typed output message
>> (which is not necessarily 2 Output<std_msgs::FLoat64>, it could be a unique
>> message aggregating the 2 data).
>>
>> I certainly arguable to do this job inside a dedicated component instead
>> of letting the communication middleware (aka transport ?) doing this job,
>> BUT, it's not as simple as you told us. When doing such inter-component
>> connexion you are either
>>
>> 1/ negociating an interface between 2 to-be-developed component, then
>> taking care about both side constraints (in terms of bandwidth,
>> event/periodic driven designs, data structure, ...). In my case, my Orocos
>> layer run at a 10ms frequency but my ROS layer at 100ms/1s frequency. It
>> would be stupid and toxic to stream orocos datas to the ROS layer at a 10ms
>> frequence. Hence my ROS bridge components are scheduled at a lower
>> frequency so that data is stream accordingly.
>>
>> 2/ connecting existing component with potential interface
>> incompatibility, hence you have to do some glue
>> code/component/communication mdw addons so that the connection is done
>> smoothly. In my case I often have 2 different data structures between my
>> Orocos Layer and my Ros layer that are aggregated or splitted in my Orocos
>> bridges.
>>
>> In both cases the choice to put a bridge on one side or the other (or
>> several on both side) is very dependent of your concrete use case. So it's
>> never as transparent as you would expect to assemble a system in 2
>> different ways.
>>
>>
>>
>>
>>
>>
>>
>>>
>>> So I'm wondering if it's possible to declare a port as an orocos
>>> "standard port" (in the corba deployer) so the streaming can be done ?
>>>
>>> In other words, if I import other components in the corba deployer, will
>>> the transport be also done in corba ? I'd like my components to works as if
>>> they were in the standard deployer, as corba is very limited in terms of
>>> types he can handle.
>>>
>>
>> __Components__ will run the same way, not the __System__ (oh my god,
>> herman speaking ^^).
>>
>>
>>
>
> I don't know from where comes the JoinState, but is may also be the
> opposite : the corba transport may not exists for every ROS generated
> messages (i really don't know the stauts about this).
>
> If you use the JoinState from ROS anywhere in your application (I mean in
> both Orocos and ROS side) you already have injected ROS framework dependent
> code into Orocos one, then preventing those Orocos component to work
> "transparently" in a pure Orocos system.
>
>
>
>>
>>> Thank you!
>>>
>>> Antoine
>>>
>>> Note: I'm on Ubuntu 12.04+hydro+toolchain 2.7
>>>
>>> --
>>> Orocos-Users mailing list
>>> Orocos-Users [..] ...
>>> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>>>
>>>
>>

CORBA deployer and ROS

I found the bug :
I just needed to import rtt_sensor_msgs. This is apparently necessary in
hydro, not in groovy where it was done automatically. I just switched to
hydro :/.
But thank you for you responses !

Le ven. 13 mars 2015 à 14:22, Antoine Hoarau <hoarau [dot] robotics [..] ...> a
écrit :

> Let me clarify the setup :
> I'm using the rtt_gazebo package https://github.com/jhu-lcsr/rtt_gazebo
>
> It's starting a deployer (corba) and a component (let's says A ) as a
> gazebo plugin, so it's inside of gazebo, and you cannot have access to the
> console.
> The only way to communicate with A it is to open a new terminal and launch
> a corba deployer to "connect" A with my other component B.
>
> - A (inside gazebo) as Output port a <std::vector<std::string> >
> - B as Input port b1 <std::vector<std::string> > connected to B via CORBA
> (this works, I can read data).
> - B as also an Output port b2 <sensor_msgs::JointState> (ROS type) that I
> want to stream it to ROS (B is my bridge OROCOS/ROS).
>
> This would workway if only the deployer was the standard one (it worked).
> In this case, I have to use the CORBA deployer but now the streaming is
> not working and I get the above message.
>
>
>
>
>
>
> Le ven. 13 mars 2015 à 13:26, Willy Lambert <lambert [dot] willy [..] ...> a
> écrit :
>
> 2015-03-13 13:14 GMT+01:00 Willy Lambert <lambert [dot] willy [..] ...>:
>>
>>>
>>>
>>> 2015-03-13 12:29 GMT+01:00 Antoine Hoarau <hoarau [dot] robotics [..] ...>:
>>>
>>>> Hi all,
>>>>
>>>> My setup is as follows :
>>>>
>>>> rtt_gazebo->CORBA->deployer-corba (my component that listens to some
>>>> rtt_gazebo ports).
>>>>
>>>> I'm having trouble streaming a port to ROS in the deployer-corba. I get
>>>> this error (I tried also with simpler types as double,strings, same
>>>> results) :
>>>>
>>>> The protocol with id 3 did not register a fall-back handler for unknown types!
>>>> triggered by: unknown_t which does not have a transport.
>>>> Could not create transport stream for port JointState with transport id 3
>>>> No such transport registered. Check your policy.transport settings or add the transport for type JointState
>>>>
>>>>
>>>> The port is an Output port NOT connected to anyone.
>>>>
>>>
>>> AFAIK (I'm working on ros electric and orocos 2.5), you can only stream
>>> data types related to ROS messages. Hence for a double you won't have a
>>> Output<double> but a Output<std_msgs::FLoat64> message type. This is due to
>>> the fact that ROS doesn't know how to send a "double". What's is missing
>>> is something in the Orocos streamer that would understand that a double
>>> serializable in a std_msgs::FLoat64. It seem simple for basic types, but
>>> it's not as easy for more complex structures as there is not necessarily a
>>> "one to one" structure member mapping.
>>>
>>> Personnaly, I have pure functionnal Orocos components which publish
>>> orocos types, and bridge components that only do the bridge between Orocos
>>> and ros. Hence in my example I would have :
>>> _ a component A1 with a Output<double>
>>> _ a component A2 with a Output<double>
>>> _ a component Ros1 with 2 Input<double> and a ROS typed output message
>>> (which is not necessarily 2 Output<std_msgs::FLoat64>, it could be a unique
>>> message aggregating the 2 data).
>>>
>>> I certainly arguable to do this job inside a dedicated component instead
>>> of letting the communication middleware (aka transport ?) doing this job,
>>> BUT, it's not as simple as you told us. When doing such inter-component
>>> connexion you are either
>>>
>>> 1/ negociating an interface between 2 to-be-developed component, then
>>> taking care about both side constraints (in terms of bandwidth,
>>> event/periodic driven designs, data structure, ...). In my case, my Orocos
>>> layer run at a 10ms frequency but my ROS layer at 100ms/1s frequency. It
>>> would be stupid and toxic to stream orocos datas to the ROS layer at a 10ms
>>> frequence. Hence my ROS bridge components are scheduled at a lower
>>> frequency so that data is stream accordingly.
>>>
>>> 2/ connecting existing component with potential interface
>>> incompatibility, hence you have to do some glue
>>> code/component/communication mdw addons so that the connection is done
>>> smoothly. In my case I often have 2 different data structures between my
>>> Orocos Layer and my Ros layer that are aggregated or splitted in my Orocos
>>> bridges.
>>>
>>> In both cases the choice to put a bridge on one side or the other (or
>>> several on both side) is very dependent of your concrete use case. So it's
>>> never as transparent as you would expect to assemble a system in 2
>>> different ways.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>>
>>>> So I'm wondering if it's possible to declare a port as an orocos
>>>> "standard port" (in the corba deployer) so the streaming can be done ?
>>>>
>>>> In other words, if I import other components in the corba deployer,
>>>> will the transport be also done in corba ? I'd like my components to works
>>>> as if they were in the standard deployer, as corba is very limited in terms
>>>> of types he can handle.
>>>>
>>>
>>> __Components__ will run the same way, not the __System__ (oh my god,
>>> herman speaking ^^).
>>>
>>>
>>>
>>
>> I don't know from where comes the JoinState, but is may also be the
>> opposite : the corba transport may not exists for every ROS generated
>> messages (i really don't know the stauts about this).
>>
>> If you use the JoinState from ROS anywhere in your application (I mean in
>> both Orocos and ROS side) you already have injected ROS framework dependent
>> code into Orocos one, then preventing those Orocos component to work
>> "transparently" in a pure Orocos system.
>>
>>
>>
>>>
>>>> Thank you!
>>>>
>>>> Antoine
>>>>
>>>> Note: I'm on Ubuntu 12.04+hydro+toolchain 2.7
>>>>
>>>> --
>>>> Orocos-Users mailing list
>>>> Orocos-Users [..] ...
>>>> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>>>>
>>>>
>>>