Ask Your Question
0

Software architecture with micro-ROS and asynchronous events

asked 2022-03-31 08:15:43 -0500

dr-mh gravatar image

Hello everyone,

I have a question regarding the software architecture with micro-ROS and asynchronous events, for example interrupts.

For example an interrupt indicates when new data is present. Now I want to send this data with a publisher. How can this be realized within the micro-ROS framework? Is there an intended concept here?

I also have a question about the sample code / concept on the website:

https://micro.ros.org/docs/concepts/c...

A code snippet for the example in Fig. 1 is shown at the bottom of that website. Here, the data pipeline is described with three executors. How is the communication between the executors realized? 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? Furthermore, the logic of the three blocks is implemented with callback functions. What happens, if something relatively computationally intensive is executed in a callback which takes a long time to compute?

Thank you for addressing my questions!

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
2

answered 2022-04-01 03:35:57 -0500

JanStaschulat gravatar image

updated 2022-04-04 04:57:41 -0500

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/g..., This is similar to a 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/3e5...). 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/c...).

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

(more)
edit flag offensive delete link more

Comments

Thank you for the detailed and helpful answers! This helps me alot!

That means that the communication within a micro-controller is completely independent from the micro-ROS agent? Therefore, a publisher-subscriber pair which communicates within a micro-controller with a high rate would not produce a bottle-neck at the communication with the agent? Do I need for that communication mode any configuration in colcon-meta?

dr-mh gravatar image dr-mh  ( 2022-04-03 12:25:46 -0500 )edit

When micro-ROS uses the Micro XRCE-DDS middleware (via rmw_microxrcedds) there is a mode where the local publisher and local subscribers can communicate with no need of doing a back and forth way to the micro-ROS Agent. You can take a look here.

But XRCE-DDS is a wire protocol that enables the MCU environment to have access to the DDS world. That means that if you have a pub and a sub in the MCU and they are matched (topic/type compatible), the data that the pub publishes will reach the sub directly, but also will need to be transmitted to the micro-ROS agent (in order to retransmit it to other possible ROS 2 nodes).

Pablogs gravatar image Pablogs  ( 2022-04-04 05:39:11 -0500 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

3 followers

Stats

Asked: 2022-03-31 08:15:43 -0500

Seen: 59 times

Last updated: Apr 04