RTT 2.x

[PATCH] force the usage of tiny demarshaller


When i run my program with valgrind i see some warnings in Xerces. So as the tiny demarshaller seems to do the job, i made a patch to force its usage. So valgrind is happy now (just one warning, with omniorb...).


Test if a peer has an operation/property


I probe all peer of a component to know who have such property/operation.

The getOperation prints a warning if the operation does not exist. But the getProperty doesn't.

It's not very important, but it would be better if all the getSomething could print a warning, or, if we could have hasSomething methods (as in 1.X).

What do you think ?

[PATCH] option for using termcap as curses impl for OCL.


It's a very optional patch.

I would like to be able to choose the curse implementation. So i made a patch that use a termcap impl if no ncurses is found.

Just for sharing, not required to be merged.


Problem in compiling a code after RTT 2.2 upgrade with XENOMAI.

Hello again guys!

Well, I finished my code for my undergraduate final project at my university.

I'm using Orocos to create a real time interface for data acquisition.

When I use a smpling rate of 1 kHz, the real time specialty is working ok. However, when I use a sampling rate of 80 kHz (minimum for my project), the real time specialty is not respected. I could get samples at 10 kHz frequency maximum. My DAQ Board can work with 330 kHz sampling rate.

So, I decided to compile the code using the Xenomai. Click below to read the rest of this post.

Inverse Kinematics with KDL


KDL is relatively new for me and I need to calculate inverse Kinematics for a KUKA-125. I have to calculate always with respect to the angle limits of joints. Can anybody please tell me if there is a method, which I can use for this purpose to limit joint angles, like theta min and theta max?

Best regards,


enum are unknown_t


It's an open question, i would like your opinion.

In the deployer, at runtime, i have an "unknown_t" warning with my enum properties.

As an enum is an int on most implementation, would it be conceivable to use the int type for enums ? Would it be technically possible ?



OCL cross compil problem and RTT compil warning


When i compile RTT 2.2.0 i have this warning :

sources/orocos-rtt-2.2.0/rtt/internal/ConnFactory.cpp: In static member function 'static RTT::base::ChannelElementBase::shared_ptr RTT::internal::ConnFactory::createRemoteConnection(RTT::base::OutputPortInterface&, RTT::base::InputPortInterface&, const RTT::ConnPolicy&)': sources/orocos-rtt-2.2.0/rtt/internal/ConnFactory.cpp:83:16: warning: converting 'false' to pointer type for argument 1 of 'boost::intrusive_ptr<T>::intrusive_ptr(T*, bool) [with T = RTT::base::ChannelElementBase]' sources/orocos-rtt-2.2.0/rtt/internal/ConnFa... Click below to read the rest of this post.

Orocos Toolchain v2.2.0 released

The Orocos development team is proud to announce the second major feature
update release of the Orocos Toolchain. It marks an important milestone in our
search for the ultimate real-time robotics software framework.

This release will allow Orocos users to use lighter and faster usage patterns
for building components and applications. For example, we support ROS package
trees for importing component packages, provide a script to create such
packages automatically and we finally came up with cheat sheets to decorate the
wall in front of your desk.

RTT-ROS integration - non std_msgs messages


I am trying to send customized message types from rtt to ros and vice versa (with the std_msgs it works fine). My customized message is MsgTiming.msg and I put it in a seperate pkg called OrocosMsgPkg:

duration start_time_Daq
duration stop_time_Daq
After I compile this pkg I have both the librtt-ros-MsgTiming-transport.so and librtt-ros-MsgTiming-typekit.so in the OrocosMsgPkg/lib/orocos/types folder. I can also compile the pkg that contains my two Orocos Components ('Daq' and 'Control'). Click below to read the rest of this post.

Add plain C operation.

Hi devs.

The manual says

Using this mechanism, any method of any class can be added to a task's method interface, not just functions of a TaskContext You can also add plain C functions, just omit the this pointer.

So this code should work ?

#include <rtt/os/main.h>
#include <rtt/TaskContext.hpp>
struct Bar
  std::string foo(void) const
    return "a string";
std::string foo(void)
  return "a string";
int ORO_main(int argc, char** argv)
  RTT::TaskContext tc("test");
  Bar bar;
  tc.addOperation("foo"      , &foo     ... Click below to read the rest of this post.