Interface DLS2 (FastDDS) with ROS2 without integration service

[MMarcus95]

3 main steps to connect FastDDS to ROS2

1. generate .idl from .msg file:
   rosidl translate --to idl -o . package_name message_name.msg

2. generate fastdds message using the -typeros2 option (-cs is used to allow case-sentitive names):
   fastddsgen -replace -cs -typeros2 message_name.idl

3. create a fastdd reader/writer connected to a topic with name rt/ros2_topic_name

NB: a reader/writer could be configured to interface with ROS2, e.g. with environment variable. This means that the rt/ is automatically added before the topic name

STEPS [est. time 10d]

• Install ROS2 and fastdds in the same docker image (waiting to generate image from github, to start from Ubuntu 24.04)
• Put .idl files into a separate repo
• Put messages in format module <package_name> {module msg{ ...}} [est.time 4d]
  • Since needs to change wrapper.stg, and it is poorly mantainable, thinking on removing wrapper (see #14)
• Make usage of ROS2 optional: add/remove "rt" to topics and generate message with ros2 extension
• Create a ROS2 package for the standard messages: automatic generation of ROS2 package while compiling with make
• Provide example on how to generate .idl files from .msg ones
• Provide set of .idl files for .msg standard messages (?) (generated while compiling with make)
• Enable usage of service
• Enable usage of action

[MMarcus95]

#14, generate wrappers using annotations in IDLS files. This is ok, but we need to test the communication between fastdds-ros2 using this annotations. Also, when sharing creating .msg from IDL (if possible), we might not want to share with collaborators annotations that are relevant only for us. Investigate this.

[MMarcus95]

ROS2 can use .idl files directly. The only constraint is that the .idl file needs to follow the structure

module <pkg_name>{
  module msg{
    struct <type_name>{
      ...
    };
  };
};

Custom annotations can be used too. However, in Jazzy it seems that @key cannot be used. Maybe it is supported in Kilted version.

[MMarcus95]

From @angelobratta

non è necessario stoppare e riattivare il daemon se runni i comandi della CLI con il flag --no-daemon.
In pratica il daemon gestice la cache dei nodi, topic e servizi. Rende i comandi CLI più veloci però devi stopparlo e riattivarlo per aggiornarlo (ad esempio se cambi la rete, il server_discovery o il ROS_SUPER_CLIENT)

Non so se è meglio aggiornarlo oppure lanciare tutti i comandi con --no-daemon, che anche se è più lento almeno non hai problemi di informazioni "vecchie".
Per questo motivo non ho commentato la issue, a te la scelta

[MMarcus95]

issue task are simplified. closing this issue, and opening a new one in case further details or implementation is strictly needed