Rosanswers logo

Are there any c++ library that contains real-time functionality such as: parameter checking, service calling or action calling? They must be time deterministic in the real time thread.

From my understanding it should be possible. For instance, using polling functions and a parallel thread performing the non-rt tasks (like rosrt::Subscriber does)

Originally posted by Pablo Iñigo Blasco on ROS Answers with karma: 2982 on 2013-12-27

Post score: 0

Original comments

Comment by dornhege on 2013-12-29:
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).

Comment by Pablo Iñigo Blasco on 2013-12-29:
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?

Comment by Pablo Iñigo Blasco on 2013-12-29:
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.

Comment by dornhege on 2014-01-02:
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.

Comment by Pablo Iñigo Blasco on 2014-01-02:
But, how have you done it? The challenge I see here is the thread synchronization. Is the source code public?

Comment by Pablo Iñigo Blasco on 2014-01-03:
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


1 Answer 1


Rosanswers logo

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)?.

Originally posted by Adolfo Rodriguez T with karma: 3907 on 2013-12-30

This answer was ACCEPTED on the original site

Post score: 1

Original comments

Comment by Pablo Iñigo Blasco on 2013-12-31:
Good point. OROCOS is really a good technology to develop RT systems. This package bring the possibility of exposing services, parameters and actions to the ROS world for my component. However, what I need just the opposite, using external services, actions and parameters from the ROS world.

Comment by Adolfo Rodriguez T on 2014-01-06:
Maybe some details of your usecase would help here. I'll update my answer with more details with the hope of clarifying some points.

Comment by Pablo Iñigo Blasco on 2014-01-08:
I guess that what you propose is building all my RT code inside a OROCOS Component and use: https://github.com/orocos/rtt_ros_integration/blob/hydro-devel/rtt_roscomm/README.md and https://github.com/orocos/rtt_ros_integration/blob/hydro-devel/rtt_rosparam/README.md

Right? It looks a right approach.

Comment by Adolfo Rodriguez T on 2014-01-08:
I'm suggesting this as a valid alternative. Depending on your needs, you might get away with simpler setups by leveraging ros_control, but it depends on what you are trying to do.

Comment by Pablo Iñigo Blasco on 2014-01-09:
It's indeed a valid approach.I do not have an specific user case because I want to find a general design approach for the development of RT components. I'll mark this as the right answer because ROS looks today incomplete to develop real-time components (additionally to the lack of a RT transport)


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.