Namespace does not prepend topics.

[gtingstad]

I am migrating from the sick_tim driver to sick_scan_xd. When setting the namespace for the launch file, I noticed that the node services and parameters are prepended by the namespace, but the topics are not. This is different behavior than found in sick_tim, and I believe it is contrary to ROS' hierarchical naming structure which is documented somewhat for ROS1, and ROS2. Treating the topic name parameters as fully qualified requires static remapping for every topic on every node.

To illustrate, if the sick_mrs_1xxx.launch file is run with __ns:='sick_launch_0', and the default name of the node it calls is sick_mrs_1xxx, and the default topics are cloud, scan, and imu, then each of the published topics should be prepended by the namespace (e.g., /sick_launch_0/sick_mrs_1xxx/cloud. This works as expected for services and parameters associated with the nodes, but not for topics. The published topics are named as if they were passed as fully qualified parameters (/cloud, /scan, and /imu). The ROS naming conventions typically only omit the preceding namespace if the parameter is passed as fully qualified.

I am wondering if there are plans to update this behavior in the driver, even with a parameter that could be passed to turn on or off this functionality? Or perhaps I am missing such a feature that already exists? The requirement to remap all nodes can be cumbersome for deployments with many sensors and makes launch files unnecessarily large.

[rostest]

Thank you for your detailed report!

The current behavior in sick_scan_xd is designed to treat topic names as fully qualified, meaning they are not automatically prepended with the namespace. This differs from the behavior in sick_tim but aligns with how topic names are explicitly set within the driver.

If namespace-based remapping is required, the recommended approach is to use explicit remappings in the launch file.
We think that the effort for remapping is manageable if you do not operate too many lidars in parallel. As the driver is already widely used, we would like to retain the current behavior.

Note that the message topics can be configured in the launchfile, e.g. in sick_mrs_1xxx.launch:

<arg name="cloud_topic" default="cloud"/>
<arg name="laserscan_topic" default="scan"/>
<arg name="imu_topic" default="imu" />

Feel free to overwrite the default topics in the launchfile or by commandline arguments, e.g. cloud_topic:=/sick_launch_0/sick_mrs_1xxx/cloud.

[gtingstad]

Thank you for the speedy response! Yes, prepending the namespace to the topic manually is certainly an option that works. This is currently how we are handling it, but it is a bit cumbersome to manage. For example, I have several deployments with a dozen SICK lidars each, and for each, a launch file that runs a dozen SICK nodes. To handle this, our launch file need to include calls like the following:

  <include file="$(find sick_scan_xd)/launch/sick_mrs_1xxx.launch" ns="<namespace>">
    <arg name="hostname" value="<ip_address>"/>
    <arg name="frame_id" value="<namespace>_link"/>
    <arg name="cloud_topic" value="<namespace>/cloud" />
    <arg name="laserscan_topic" value="<namespace>/scan" />
    <arg name="imu_topic" value="<namespace>/imu" />  
  </include>

Whereas previously, only the following was required:

  <include file="$(find sick_scan_xd)/launch/sick_mrs_1xxx.launch" ns="<namespace>">
    <arg name="hostname" value="<ip_address>"/>
    <arg name="frame_id" value="<namespace>_link"/>
  </include>

As you can imagine, with 12 node launches in a file this adds a bit of bloat to our codebases and adds some cost to maintainability and debugging, since we are needing to repeat code. Would it be possible to include a parameter which causes the node to handle topic namespaces in the expected ROS fashion? This could be disabled by default but would allow deployments to be much cleaner with something like <arg name="prepend_ns" value="true"/> passed to the driver launch, or even by manually changing the default parameter in the driver launch file (e.g., <arg name="prepend_ns" default="true"/>).

I feel this would be a valuable addition to the driver that allows existing customers to continue using their existing codebase, while providing the option to maintain more efficient code in the future.