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)
