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 > - B as Input port b1 <std::vector > (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
>>>>
>>>>
>>>