Orocos RTT has pretty good ROS integration. Version 2.7, which should be released soon for Hydro has plugins for communicating with the ROS world: params, topics, services and an action server implementation. More details can be found here. Be sure to check out the README.
ROS integration means that you end up implementing Orocos RTT componets, using Orocos primitives like properties, ports and operations; which then get mapped to ROS parameters, topics, services and actions. If your RTOS is already supported by Orocos RTT, there is no overhead in building a binary against the Linux kernel or the RTOS one.
Notes based on answer comments:
- ROS services are inherently non-deterministic and non-rt, hence should not be called from a rt context.
- Static ROS param configurations are usually read at controller configure-time, hence from non-rt. For changing parameters, you can use dynamic_reconfigure from a rt context.
- I'd like to better understand the usecases of an action client living in a rt context before commenting further.
- To which extent can you have a separate non-rt thread with service servers and action clients, and synchronize communication between the rt and non-rt threads with the primitives already built in OROCOS (like lock-free buffers, which do not suffer from priority inversions)?.
AFAIK no. It could be possible if you are OK with the "latest" instead of the current param, same for actions. With services you'll probably need to work with futures or similar (basically constructing what actions do).
I agree, the latest message is the only we can get if our task works in a RT thread and it being used non-RT functionality such as those based on xml-rpc. BTW,it is possible perform a poll (to get the latest value) operation on the parameter API without block the thread or break the RT capabilities?
Concerning the "future approach" for services, indeed, the resulting API should look like that. However, IMHO the challenge here would be how to perform the inter-thread communication between RT & non-RT threads. The best way probably would be to use POSIX message queues.
For parameters I've written a small, light wrapper that "subscribes" parameters by polling the getParamCached function. If you use something similar in the ROS thread, you could just get the currently stored value from the RT thread. Depending getParamCached implementation RT directly can be OK.
But, how have you done it? The challenge I see here is the thread synchronization. Is the source code public?
My main concern is the priority inversion problem. It is possible to synchronize a NON-RT thread with an RT-Thread without making this issue explicit into the NON-RT thread code? I think that this can be done in a similar way that rosrt::Subscriber works, but I till have to review the code in detail