ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

I'd like to refer you to some previous, related questions on this topic. See:

Even though some of those questions (and their answers) are several years old, not much has changed in the intervening years.

ROS2.0 however should change this, as depending on the DDS middleware option used, it should make real-time applications possible without requiring any other framework. It would still require a real-time capable OS though (and carefully programmed nodes).

I'd like to refer you to some previous, related questions on this topic. See:

Even though some of those questions (and their answers) are several years old, not much has changed in the intervening years.

ROS2.0 however should change this, as depending on the DDS middleware option used, it should make real-time applications possible without requiring any other framework. It would still require a real-time capable OS though (and carefully programmed nodes).


Edit:

Okay, sorry for the misuse of the word. My question remains though, but maybe this formulation would be better : if using a real-time tool together with ROS within a system, wouldn't the use of ROS make the whole system non-realtime?

For an answer to your rephrased question, I think I can refer you to ros_control and RT.

In short: sure, any non-real-time part that is placed in the critical path of an otherwise real-time capable system will obviously make it impossible for that system to maintain its determinism guarantees.

I'd like to refer you to some previous, related questions on this topic. See:

Even though some of those questions (and their answers) are several years old, not much has changed in the intervening years.

ROS2.0 however should change this, as depending on the DDS middleware option used, it should make real-time applications possible without requiring any other framework. It would still require a real-time capable OS though (and carefully programmed nodes).


Edit:

Okay, sorry for the misuse of the word. My question remains though, but maybe this formulation would be better : if using a real-time tool together with ROS within a system, wouldn't the use of ROS make the whole system non-realtime?

For an answer to your rephrased question, I think I can refer you to ros_control and RT.

In short: sure, any non-real-time part component that is placed in the critical path of an otherwise real-time capable system will obviously make it impossible for that system to maintain its determinism guarantees.

I'd like to refer you to some previous, related questions on this topic. See:

Even though some of those questions (and their answers) are several years old, not much has changed in the intervening years.

ROS2.0 however should change this, as depending on the DDS middleware option used, it should make real-time applications possible without requiring any other framework. It would still require a real-time capable OS though (and carefully programmed nodes).


Edit:

Okay, sorry for the misuse of the word. My question remains though, but maybe this formulation would be better : if using a real-time tool together with ROS within a system, wouldn't the use of ROS make the whole system non-realtime?

For an answer to your rephrased question, I think I can refer you to ros_control and RT.

In short: sure, any non-real-time component that is placed in the critical path of an otherwise real-time capable system will obviously make it impossible for that system to maintain its determinism guarantees.

But that is obviously not ROS-specific. The same holds for an OROCOS application (fi) that uses non-deterministic services in one of its components.

I'd like to refer you to some previous, related questions on this topic. See:

Even though some of those questions (and their answers) are several years old, not much has changed in the intervening years.

ROS2.0 however should change this, as depending on the DDS middleware option used, it should make real-time applications possible without requiring any other framework. It would still require a real-time capable OS though (and carefully programmed nodes).


Edit:

Okay, sorry for the misuse of the word. My question remains though, but maybe this formulation would be better : if using a real-time tool together with ROS within a system, wouldn't the use of ROS make the whole system non-realtime?

For an answer to your rephrased question, I think I can refer you to ros_control and RT.

In short: sure, any non-real-time component that is placed in the critical path of an otherwise real-time capable system will obviously make it impossible for that system to maintain its determinism guarantees.

But that is obviously not ROS-specific. The same holds for an OROCOS application (fi) that uses non-deterministic services in one of its components.

I'd like to refer you to some previous, related questions on this topic. See:

Even though some of those questions (and their answers) are several years old, not much has changed in the intervening years.

ROS2.0 however should change this, as depending on the DDS middleware option used, it should make real-time applications possible without requiring any other framework. It would still require a real-time capable OS though (and carefully programmed nodes).


Edit:

Okay, sorry for the misuse of the word. My question remains though, but maybe this formulation would be better : if using a real-time tool together with ROS within a system, wouldn't the use of ROS make the whole system non-realtime?

For an answer to your rephrased question, I think I can refer you to ros_control and RT.

In short: sure, any non-real-time component that is placed in the critical path of an otherwise real-time capable system will obviously make it impossible for that system to maintain its determinism guarantees.

But that is obviously not ROS-specific. The same holds for an OROCOS application (fi) (or any other framework) that uses non-deterministic services in one of its components.