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

Revision history [back]

Hi @dr-mh,

first question: asynchronous event in micro-ros

in ROS 2 and micro-ROS you can register handles at the executor, like subscriptions and publishers. There is also a handle, called guard condition, e.g. https://docs.ros2.org/beta1/api/rcl/guard__condition_8h.html, This is similar to a semaphore and conditional wait if you are familiar with multi-threading. First you initialize a guard condition and add this guard_condition to the rclc_executor (https://github.com/ros2/rclc/blob/3e5e219ebb5f2c7b3da74f5838349a7969676c81/rclc/include/rclc/executor.h#L563). Then, you can use this guard_condition in the interrupt. When the interrupt is called you trigger the guard condition. (rcl_trigger_guard_condition). Now, in the micro-ROS application, when the rcl_wait() returns, then this guard_condition is flaged. So the callback of this guard condition is executed.

Limitation. We might have to check on micro-ROS, whether the rcl_wait() returns immediately if only a guard condition is "ready". To my knowlegde, the rcl_wait() in micro-ROS only returns if some other handle is ready (e.g. topic received, timer ready) or the timeout is reached. So it is not the expected behavior, that if the interrupt triggers the guard_condtion, that the rcl_wait() will immediately return and call its callback. We could improve here.

Workaround: use a short timout.

question regarding sense-plan-act pipeline https://micro.ros.org/docs/concepts/client_library/execution_management/#sense-plan-act-pipeline-in-robotics-example I guess you are refering to the sense-plan-act pipline Example.

First, the purpose of this pipelining is, that e..g the plan-phase does not start before all callbacks in the sense phase have finished to ensure e.g. to work on the most recent sensor data.

How is the communication between the executors realized?

There is no communication between executors. In micro-ROS you program directly communication with publishers and subscibers. The rclc library does not have the same node concept as rclcpp (e.g. standard ROS 2). You can add subscriptions of multiple nodes to the same executor for instance.

As a user you only have to define your cause-effect chains in terms of publisher and subscribers (you can add them to one node or multiple nodes - that has no effect regarding the execution of the callbacks).

Communication between multiple subscribers on the micro-controller is not locally. It used to be that a publisher had to communicate always to the Agent and then back to the Client. This has been resolved now. So communication on the micro-controller is now direct.

In the code are subscribers for data collection defined, where consequently the data must be sent from the preceding >block by a publisher (over a topic)? That means that the communication within the node is realized by topics?

Yes, communication between different subscribers are realized with a topic. But there is no "node" concept in micro-ROS, which gathers all handles (e.g. subs, publishers, services, clients, ...) you have to individually add the handles to the executor.

Furthermore, the logic of the three blocks is implemented with callback functions.

Yes

What happens, if something relatively >computationally intensive is executed in a callback which takes a long time to >compute?

subscriptions in later phases are delayed, yes. This is the indented behavior of a phased-execution.

We have published a paper (https://arxiv.org/abs/2105.05590) about a multi-threaded real-time executor, in which you can execute your callbacks in threads with different priorities in parallel. Then the operating system is doing the scheduling and you could seperate between real-time and non real-time critical functions.

The current micro-ROS stack is thread-safe. That means you can, even now, create two threads with different priorities and define an rclc_executor in each thread. Then All callbacks handled by those executors will be scheduled according to priority of the underlying thread.

Hope this clarified a bit. If sth is misleading or unclear, most welcome to reach out. Jan

Hi @dr-mh,

first question: asynchronous event in micro-ros

in ROS 2 and micro-ROS you can register handles at the executor, like subscriptions and publishers. There is also a handle, called guard condition, e.g. https://docs.ros2.org/beta1/api/rcl/guard__condition_8h.html, This is similar to a semaphore and conditional wait if you are familiar with multi-threading. First you initialize a guard condition and add this guard_condition to the rclc_executor (https://github.com/ros2/rclc/blob/3e5e219ebb5f2c7b3da74f5838349a7969676c81/rclc/include/rclc/executor.h#L563). Then, you can use this guard_condition in the interrupt. When the interrupt is called you trigger the guard condition. (rcl_trigger_guard_condition). Now, in the micro-ROS application, when the the rclc_executor_spin_some() function will internally call rcl_wait() checking for new data or ready events at DDS queue. When it returns, then this guard_condition is flaged. So the ready and its callback of this guard condition is executed.

That is, to implement an asynchronous call in micro-ROS you can use a guard_condition.

Limitation. We might have to check on micro-ROS, whether the rcl_wait() returns immediately if only a guard condition is "ready". To my knowlegde, the rcl_wait() in micro-ROS only returns if some other handle is ready (e.g. topic received, timer ready) or the timeout is reached. So it is not the expected behavior, that if the interrupt triggers the guard_condtion, that the rcl_wait() will immediately return and call its callback. We could improve here.

Workaround: use a short timout.

question regarding sense-plan-act pipeline https://micro.ros.org/docs/concepts/client_library/execution_management/#sense-plan-act-pipeline-in-robotics-example I guess you are refering to the sense-plan-act pipline Example.

First, the purpose of this pipelining is, that e..g the plan-phase does not start before all callbacks in the sense phase have finished to ensure e.g. to work on the most recent sensor data.

How is the communication between the executors realized?

There is no communication between executors. In micro-ROS you program directly communication with publishers and subscibers. The rclc library does not have the same node concept as rclcpp (e.g. standard ROS 2). You can add subscriptions of multiple nodes to the same executor for instance.

As a user you only have to define your cause-effect chains in terms of publisher and subscribers (you can add them to one node or multiple nodes - that has no effect regarding the execution of the callbacks).

Communication between multiple subscribers on the micro-controller is not locally. It used to be that a publisher had to communicate always to the Agent and then back to the Client. This has been resolved now. So communication on the micro-controller is now direct.

In the code are subscribers for data collection defined, where consequently the data must be sent from the preceding >block by a publisher (over a topic)? That means that the communication within the node is realized by topics?

Yes, communication between different subscribers are realized with a topic. But there is no "node" concept in micro-ROS, which gathers all handles (e.g. subs, publishers, services, clients, ...) you have to individually add the handles to the executor.

Furthermore, the logic of the three blocks is implemented with callback functions.

Yes

What happens, if something relatively >computationally intensive is executed in a callback which takes a long time to >compute?

subscriptions in later phases are delayed, yes. This is the indented behavior of a phased-execution.

We have published a paper (https://arxiv.org/abs/2105.05590) about a multi-threaded real-time executor, in which you can execute your callbacks in threads with different priorities in parallel. Then the operating system is doing the scheduling and you could seperate between real-time and non real-time critical functions.

The current micro-ROS stack is thread-safe. That means you can, even now, create two threads with different priorities and define an rclc_executor in each thread. Then All callbacks handled by those executors will be scheduled according to priority of the underlying thread.

Hope this clarified a bit. If sth is misleading or unclear, most welcome to reach out. Jan

Hi @dr-mh,

first question: asynchronous event in micro-ros

in ROS 2 and To implement an asynchronous call in micro-ROS you can use a guard_condition.

in micro-ROS you can register handles at the executor, Executor, like subscriptions and publishers. There is also a handle, called guard condition, e.g. https://docs.ros2.org/beta1/api/rcl/guard__condition_8h.html, This is similar to a semaphore and conditional wait if you are familiar with multi-threading. First you initialize a guard condition and add this guard_condition to the rclc_executor (https://github.com/ros2/rclc/blob/3e5e219ebb5f2c7b3da74f5838349a7969676c81/rclc/include/rclc/executor.h#L563). Then, you can use this guard_condition in the interrupt. When the interrupt is called you trigger the guard condition. (rcl_trigger_guard_condition). Now, in the micro-ROS application, the rclc_executor_spin_some() function will internally call rcl_wait() checking for new data or ready events at DDS queue. When it returns, then this guard_condition is ready and its callback is executed.

That is, to implement an asynchronous call in micro-ROS you can use a guard_condition.

Limitation. We might have to check on micro-ROS, whether the rcl_wait() returns immediately if only a guard condition is "ready". To my knowlegde, the rcl_wait() in micro-ROS only returns if some other handle is ready (e.g. topic received, timer ready) or the timeout is reached. So it is not the expected behavior, that if the interrupt triggers the guard_condtion, that the rcl_wait() will immediately return and call its callback. We could improve here.

Workaround: use a short timout.

question regarding sense-plan-act pipeline https://micro.ros.org/docs/concepts/client_library/execution_management/#sense-plan-act-pipeline-in-robotics-example I guess you are refering to the sense-plan-act pipline Example.

First, the purpose of this pipelining is, that e..g the plan-phase does not start before all callbacks in the sense phase have finished to ensure e.g. to work on the most recent sensor data.

How is the communication between the executors realized?

There is no communication between executors. In micro-ROS you program directly communication with publishers and subscibers. The rclc library does not have the same node concept as rclcpp (e.g. standard ROS 2). You can add subscriptions of multiple nodes to the same executor for instance.

As a user you only have to define your cause-effect chains in terms of publisher and subscribers (you can add them to one node or multiple nodes - that has no effect regarding the execution of the callbacks).

Communication between multiple subscribers on the micro-controller is not locally. It used to be that a publisher had to communicate always to the Agent and then back to the Client. This has been resolved now. So communication on the micro-controller is now direct.

In the code are subscribers for data collection defined, where consequently the data must be sent from the preceding >block by a publisher (over a topic)? That means that the communication within the node is realized by topics?

Yes, communication between different subscribers are realized with a topic. But there is no "node" concept in micro-ROS, which gathers all handles (e.g. subs, publishers, services, clients, ...) you have to individually add the handles to the executor.

Furthermore, the logic of the three blocks is implemented with callback functions.

Yes

What happens, if something relatively >computationally intensive is executed in a callback which takes a long time to >compute?

subscriptions in later phases are delayed, yes. This is the indented behavior of a phased-execution.

We have published a paper (https://arxiv.org/abs/2105.05590) about a multi-threaded real-time executor, in which you can execute your callbacks in threads with different priorities in parallel. Then the operating system is doing the scheduling and you could seperate between real-time and non real-time critical functions.

The current micro-ROS stack is thread-safe. That means you can, even now, create two threads with different priorities and define an rclc_executor in each thread. Then All callbacks handled by those executors will be scheduled according to priority of the underlying thread.

Hope this clarified a bit. If sth is misleading or unclear, most welcome to reach out. Jan

Hi @dr-mh,

first question: how to handle asynchronous event in micro-ros

events in micro-ROS

To implement an asynchronous call in micro-ROS you can use a guard_condition.

in micro-ROS you can register handles at the Executor, like subscriptions and publishers. There is also a handle, called guard condition, e.g. https://docs.ros2.org/beta1/api/rcl/guard__condition_8h.html, This is similar to a semaphore and conditional wait if you are familiar with multi-threading. First you initialize a guard condition and add this guard_condition to the rclc_executor (https://github.com/ros2/rclc/blob/3e5e219ebb5f2c7b3da74f5838349a7969676c81/rclc/include/rclc/executor.h#L563). Then, you can use this guard_condition in the interrupt. When the interrupt is called you trigger the guard condition. (rcl_trigger_guard_condition). Now, in the micro-ROS application, the rclc_executor_spin_some() function will internally call rcl_wait() checking for new data or ready events at DDS queue. When it returns, then this guard_condition is ready and its callback is executed.

Limitation. We might have to check on micro-ROS, whether the rcl_wait() returns immediately if only a guard condition is "ready". To my knowlegde, the rcl_wait() in micro-ROS only returns if some other handle is ready (e.g. topic received, timer ready) or the timeout is reached. So it is not the expected behavior, that if the interrupt triggers the guard_condtion, that the rcl_wait() will immediately return and call its callback. We could improve here.

Workaround: use a short timout.

question regarding sense-plan-act pipeline https://micro.ros.org/docs/concepts/client_library/execution_management/#sense-plan-act-pipeline-in-robotics-example pipeline

I guess you are refering to the sense-plan-act pipline Example. pipeline Example (https://micro.ros.org/docs/concepts/client_library/execution_management/#sense-plan-act-pipeline-in-robotics-example).

First, the purpose of this pipelining is, that e..g the plan-phase does not start before all callbacks in the sense phase have finished to ensure e.g. to work on the most recent sensor data.

How is the communication between the executors realized?

There is no communication between executors. In micro-ROS you program directly communication with publishers and subscibers. The rclc library does not have the same node concept as rclcpp (e.g. standard ROS 2). You can add subscriptions of multiple nodes to the same executor for instance.

As a user you only have to define your cause-effect chains in terms of publisher and subscribers (you can add them to one node or multiple nodes - that has no effect regarding the execution of the callbacks).

Communication between multiple subscribers on the micro-controller is not locally. It used to be that a publisher had to communicate always to the Agent and then back to the Client. This has been resolved now. So communication on the micro-controller is now direct.

In the code are subscribers for data collection defined, where consequently the data must be sent from the preceding >block by a publisher (over a topic)? That means that the communication within the node is realized by topics?

Yes, communication between different subscribers are realized with a topic. But there is no "node" concept in micro-ROS, which gathers all handles (e.g. subs, publishers, services, clients, ...) you have to individually add the handles to the executor.

Furthermore, the logic of the three blocks is implemented with callback functions.

Yes

What happens, if something relatively >computationally intensive is executed in a callback which takes a long time to >compute?

subscriptions in later phases are delayed, yes. This is the indented behavior of a phased-execution.

We have published a paper (https://arxiv.org/abs/2105.05590) about a multi-threaded real-time executor, in which you can execute your callbacks in threads with different priorities in parallel. Then the operating system is doing the scheduling and you could seperate between real-time and non real-time critical functions.

The current micro-ROS stack is thread-safe. That means you can, even now, create two threads with different priorities and define an rclc_executor in each thread. Then All callbacks handled by those executors will be scheduled according to priority of the underlying thread.

Hope this clarified a bit. If sth is misleading or unclear, most welcome to reach out. Jan

Hi @dr-mh,

first question: how to handle asynchronous events in micro-ROS

To implement an asynchronous call in micro-ROS you can use a guard_condition.

in micro-ROS you can register handles at the Executor, like subscriptions and publishers. There is also a handle, called guard condition, e.g. https://docs.ros2.org/beta1/api/rcl/guard__condition_8h.html, This is similar to a semaphore mutex and conditional wait if you are familiar with multi-threading. First you initialize a guard condition and add this guard_condition to the rclc_executor (https://github.com/ros2/rclc/blob/3e5e219ebb5f2c7b3da74f5838349a7969676c81/rclc/include/rclc/executor.h#L563). Then, you can use this guard_condition in the interrupt. When the interrupt is called you trigger the guard condition. (rcl_trigger_guard_condition). Now, in the micro-ROS application, the rclc_executor_spin_some() function will internally call rcl_wait() checking for new data or ready events at DDS queue. When it returns, then this guard_condition is ready and its callback is executed.

Limitation. We might have to check on micro-ROS, whether the rcl_wait() returns immediately if only a guard condition is "ready". To my knowlegde, the rcl_wait() in micro-ROS only returns if some other handle is ready (e.g. topic received, timer ready) or the timeout is reached. So it is not the expected behavior, that if the interrupt triggers the guard_condtion, that the rcl_wait() will immediately return and call its callback. We could improve here.

Workaround: use a short timout.

question regarding sense-plan-act pipeline

I guess you are refering to the sense-plan-act pipeline Example (https://micro.ros.org/docs/concepts/client_library/execution_management/#sense-plan-act-pipeline-in-robotics-example).

First, the purpose of this pipelining is, that e..g the plan-phase does not start before all callbacks in the sense phase have finished to ensure e.g. to work on the most recent sensor data.

How is the communication between the executors realized?

There is no communication between executors. In micro-ROS you program directly communication with publishers and subscibers. The rclc library does not have the same node concept as rclcpp (e.g. standard ROS 2). You can add subscriptions of multiple nodes to the same executor for instance.

As a user you only have to define your cause-effect chains in terms of publisher and subscribers (you can add them to one node or multiple nodes - that has no effect regarding the execution of the callbacks).

Communication between multiple subscribers on the micro-controller is not locally. It used to be that a publisher had to communicate always to the Agent and then back to the Client. This has been resolved now. So communication on the micro-controller is now direct.

In the code are subscribers for data collection defined, where consequently the data must be sent from the preceding >block by a publisher (over a topic)? That means that the communication within the node is realized by topics?

Yes, communication between different subscribers are realized with a topic. But there is no "node" concept in micro-ROS, which gathers all handles (e.g. subs, publishers, services, clients, ...) you have to individually add the handles to the executor.

Furthermore, the logic of the three blocks is implemented with callback functions.

Yes

What happens, if something relatively >computationally intensive is executed in a callback which takes a long time to >compute?

subscriptions in later phases are delayed, yes. This is the indented behavior of a phased-execution.

We have published a paper (https://arxiv.org/abs/2105.05590) about a multi-threaded real-time executor, in which you can execute your callbacks in threads with different priorities in parallel. Then the operating system is doing the scheduling and you could seperate between real-time and non real-time critical functions.

The current micro-ROS stack is thread-safe. That means you can, even now, create two threads with different priorities and define an rclc_executor in each thread. Then All callbacks handled by those executors will be scheduled according to priority of the underlying thread.

Hope this clarified a bit. If sth is misleading or unclear, most welcome to reach out. Jan