Never mind on my last error -- I made a mistake setting up the ConnPolicy.

Thank you very much, it is working perfectly now.

Thank You,
Johnathan Van Why
Dynamic Robotics Laboratory
Oregon State University

On Tue, Apr 23, 2013 at 12:00 PM, Johnathan Van Why <jrvanwhy [..] ...> wrote:
> On Mon, Mar 25, 2013 at 4:13 PM, Peter Soetens <peter [..] ...>
> wrote:
>> On Mon, Mar 25, 2013 at 11:57 PM, Johnathan Van Why <jrvanwhy [..] ...>
>> wrote:
>>> On Mon, Mar 25, 2013 at 3:14 PM, Peter Soetens <peter [..] ...>
>>> wrote:
>>>>
>>>> On Mon, Mar 25, 2013 at 7:53 PM, Johnathan Van Why <jrvanwhy [..] ...>
>>>> wrote:
>>>> > We have a component with a port that is currently transmitting a
>>>> > custom
>>>> > ROS
>>>> > message type. This port set to publish to ROS via Orocos's RTT-ROS
>>>> > integration. This works fine, but since the type is dynamic, this is
>>>> > not
>>>> > realtime-safe under an rt-preempt kernel.
>>>> >
>>>> > When I try to transmit the same type but with Orocos's realtime
>>>> > allocator as
>>>> > the message type's allocator, it's perfectly realtime, but Orocos is
>>>> > unable
>>>> > to create the transport stream for the port.
>>>> >
>>>> > In other words, this works (the first line is in a class definition,
>>>> > the
>>>> > second is in a function):
>>>> >
>>>> > RTT::OutputPort<atrias_msgs::rt_ops_cycle> *gui_cyclic_out;
>>>> > ...
>>>> > gui_cyclic_out->write(data);
>>>> >
>>>> > But this results in an error (note: we used
>>>> > RTT::os::rt_allocator<uint8_t>
>>>> > because RTT::os::rt_allocator<void> has the rebind member private):
>>>>
>>>> That's probably an error ???
>>>>
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > RTT::OutputPort<atrias_msgs::rt_ops_cycle_ >>>> > *gui_cyclic_out
>>>> > ...
>>>> > gui_cyclic_out->write(data);
>>>> >
>>>> > Here is the error we get upon deployer startup:
>>>> >
>>>> > 0.518 [ Warning][ScriptingService] The protocol with id 3 did not
>>>> > register a
>>>> > fall-back handler for unknown types!
>>>> > 0.518 [ Warning][ScriptingService] triggered by: unknown_t which
>>>> > does
>>>> > not
>>>> > have a transport.
>>>> > 0.518 [ ERROR ][ScriptingService] Could not create transport stream
>>>> > for
>>>> > port rt_ops_gui_out with transport id 3
>>>> > 0.518 [ ERROR ][ScriptingService] No such transport registered. Check
>>>> > your
>>>> > policy.transport settings or add the transport for type unknown_t
>>>> >
>>>> > Is it possible to publish messages of such a type through Orocos's
>>>> > RTT-ROS
>>>> > integration?
>>>>
>>>> Yes. But not with our current generated typekits, ie, only with a
>>>> hand-coded one. That's because the allocator changes the C++ data
>>>> type, and Orocos requires a typekit for each distinct C++ data type.
>>>>
>>>> try this somewhere in your code path (for example in a component
>>>> constructor):
>>>>
>>>> typedef atrias_msgs::rt_ops_cycle_<RTT::os::rt_allocator >>>> rt_msg_type;
>>>> RTT::types::Types()->addType( new
>>>> types::StructTypeInfo<rt_msg_type>("rt_msg_type") );
>>>> RTT::types::Types()->addType( new
>>>> types::PrimitiveSequenceTypeInfo<std::vector >>>> >("rt_msg_type[]") );
>>>> RTT::types::Types()->addType( new
>>>> types::CArrayTypeInfo<RTT::types::carray >>>> >("rt_msg_typec[]") );
>>>>
>>>>
>>>>
>>>> RTT::types::Types()->type("rt_msg_type")->addProtocol(ORO_ROS_PROTOCOL_ID,new
>>>> RosMsgTransporter<rt_msg_type>());
>>>>
>>>> You won't need the second and third addType() line if you're not
>>>> composing this message in a larger message struct.
>>>
>>> I'm trying to implement this, but am running into an error. Here are the
>>> relevant includes in my code:
>>>
>>> #include <rtt/types/StructTypeInfo.hp

>>> #include <ros_msg_transporter.hp

>>>
>>>
>>> I have added rtt_rosnode as a dependency in the manifest.xml for this
>>> package (we use rosbuild as our build system).
>>>
>>> Here is the relevant code, in the constructor of the component needing
>>> this
>>> message type:
>>>
>>> typedef atrias_msgs::rt_ops_cycle_<RTT::os::rt_allocator >>> rt_msg_type;
>>> RTT::types::Types()->addType(new RTT::types::StructTypeInfo<rt_msg_type,
>>> false>("rt_msg_type"));
>>> RTT::types::Types()->type("rt_msg_type")->addProtocol(3, new
>>> ros_integration::RosMsgTransporter<rt_msg_type>());
>>>
>>>
>>> The error I get is:
>>>
>>> /usr/include/boost/serialization/access.hpp:118:9: error: ‘struct
>>> atrias_msgs::rt_ops_cycle_<RTT::os::rt_allocator >>> member named ‘serialize’
>>>
>>>
>>> The line and column indicated in the error message refer to the closing
>>> brace of our "atrias" namespace (the outermost namespace for our
>>> project).
>>>
>>> What am I doing wrong?
>>
>> Oh rats :-) You'll have two/three options: write your serialize
>> function manually or copy/paste it from the generated boost header for
>> the original ROS msg type or use TemplateTypeInfo<> instead of
>> StructTypeInfo<>. The latter solution is the easiest, but you won't
>> have access to the struct's members in your Orocos scripts or property
>> files.
>>
>> See
>> http://www.orocos.org/stable/documentation/rtt/v2.x/doc-xml/orocos-typek...
>> for some background reading...
>>
>> Peter
>
> Sorry for the large gap between my last message and this one -- another
> project of a higher priority came up, so I had to temporarily defer this
> work.
>
> When I try to use a TemplateTypeInfo<> instead of a StructTypeInfo<> in my
> code, I get a segfault upon component load. I loaded the deployer into gdb
> (this was under PREEMPT_RT Linux) and obtained a backtrace. The backtrace
> may be viewed at http://pastie.org/7704364 (and is attached to this email,
> in case that is more convenient).
>
> In case it helps, here is the code I am using (the exact ROS message is
> different -- this type is somewhat simpler):
> // Register a typekit for the rt_ops_event w/ the realtime allocator
> RTT::types::Types()->addType(new RTT::types::TemplateTypeInfo<
> atrias_msgs::rt_ops_event_<RTT::os::rt_allocator > false>("rt_ops_cycle_"));
> RTT::types::Types()->type("rt_ops_cycle_")->addProtocol(3, new
> ros_integration::RosMsgTransporter<
> atrias_msgs::rt_ops_event_<RTT::os::rt_allocator >
> Also, after looking through the generated header file for rt_ops_cycle_, I
> don't understand the first two options. What do you mean by "copy/paste the
> serialize function from the generator boost header"?
>
> Thank you for the help,
> Johnathan Van Why
> Dynamic Robotics Laboratory
> Oregon State University