[WIP] Improvements in core

[fmrico]

Hi @igonzf

This PR is a WIP for improving this architecture proposal. I hope you could use it in the demo:

• Use of Cascade Lifecycle for setting up application in master
• Get messages by flow, with the correct msg type

[fmrico]

Hi @igonzf and @fjrodl ,

As we talked, the app file should looks like:

master_1:
  ros__parameters:
    flows: [flow_1]
    flow_1: [cognitive_module_1, cognitive_module_2]

cognitive_module_1:
  ros__parameters:
    core: image_filter
    afferent: simple_image_input
    simple_image_input:
      flow1:
        topics: ["/image_raw, /image_info"]
        types: ["sensor_msgs/msg/Image", "sensor_msgs/msg/CameraInfo"]
    efferent: simple_image_output
    simple_image_output:
      flow1:
        topics: ["/detections"]
        types: ["sensor_msgs/msg/Image"]
    meta: default_meta
    coupling: default_coupling

cognitive_module_2:
  ros__parameters:
    core: image_filter
    afferent: simple_image_input
    simple_image_input:
      flow1:
        topics: ["/image_raw, /image_info"]
        types: ["sensor_msgs/msg/Image", "sensor_msgs/msg/CameraInfo"]
    efferent: simple_image_output
    simple_image_output:
      flow1: 
        topics: ["/detections2"]
        types: ["sensor_msgs/msg/Image"]
    meta: default_meta
    coupling: default_coupling

My question here is: When you do a auto msg = afferent_->get_msg();, what should I receive? Options:

1. A vector with the last messages received in both topics.
2. A vector with the next messages received in both topics.
3. The API needs to be different...

[fjrodl]

Here are the three cases we have in mind (apologies for the "boxology").

Restrictions:

• We envision a single message queue between the afferent core and the efferent.
• At this stage, we might consider handling messages as they arrive in the afferent, rather than sending a fixed vector tied to the flow.
• How can we manage different flows within the vector? Maybe different vectors?

[fmrico]

Hi @fjrodl @igonzf

We have to review these ideas to think in terms of flows. Maybe not for the @igonzf 's demo.

The changes I have just pushed make it possible to subscribe and publish to different types. Now the mode (CALLBACK|ONDEMAND) is at input topic level, and the topics to publish/subscribe can be specified using the order of the topic:

cognitive_module_1:
  ros__parameters:
    core: image_filter
    afferent: simple_image_input
    simple_image_input:
      topics: ["/image_raw", "/camera_info"]
      types: ["sensor_msgs/msg/Image", "sensor_msgs/msg/CameraInfo"]
    efferent: simple_image_output
    simple_image_output:
      topics: ["/detections"]
      types: ["sensor_msgs/msg/Image"]
    meta: default_meta
    coupling: default_coupling

   efferent_->publish(0, std::move(image_msg));

    afferent_->set_mode(0, cs4home_core::Afferent::CALLBACK,
      std::bind(&ImageFilterCB::process_in_image, this, _1));
    afferent_->set_mode(1, cs4home_core::Afferent::CALLBACK,
      std::bind(&ImageFilterCB::process_in_camerainfo, this, _1));

     auto msg = afferent_->get_msg<sensor_msgs::msg::Image>(0);

Please, check if you like it, and if it useful for you.

With the best of my wishes :)

[igonzf]

Thanks for the changes! It looks really useful to be able to choose between CALLBACK and ONDEMAND modes.

Regarding the flows, I think it might make more sense for the master to be aware of them since multiple flows could use the same cognitive module in different ways. The module itself may not need to know about the flows. The afferents could simply list the topics that they can subscribe to, and the master could handle the flow organization. This would also make the cognitive modules more independent, as they wouldn't need to be aware of or manage flow-specific configurations.

Once I try this with the demo, I'll let you know if there’s anything else we need to adjust.

Thanks again for your work on this :)