roslaunch: file fallback for <rosparam>, <include>

[mikepurvis]

At present the only fallback mechanisms in roslaunch are <arg default=""> and $(optenv name default), neither of which are particularly suitable to the circumstance where you want "include this file if it exists, otherwise this other file." There are a few possible resolutions I could see:

• Expand the $(find) substitutions to accept a default, similar to how optenv works, though the usefulness of this is hindered by not being able to nest substitutions, and there'd be no obvious way to fall back from a $ROS_ETC_DIR-relative path to a package-relative one.
• Expand the file="" attribute to accept multiple alternatives, separated by comma, space, etc.
• Add a file-fallback="" attribute, which is used in conjunction with file="".

One possible use-case is a reactive launch file which does something if a particular package is available, and does something else if it's not.

---

The specific use for Clearpath is robot packages where we have yaml configuration files which we'd like to be modifiable by the end user without needing to actually add the package in question to a workspace. Consider a simple compass calibration yaml included with Husky:

mag_bias:
  x: -0.187996
  y: 0.031774
  z: -0.640720
  radius: 0.279036

The husky_bringup/install script copies that file to /etc/ros/hydro/imu_compass.yaml, and at present, we simply include it directly from that hard-coded location:

<launch>
  <rosparam command="load" file="/etc/ros/$(env ROS_DISTRO)/imu_compass.yaml"/>
  <node pkg="imu_compass" type="imu_compass" name="imu_compass" respawn="true"/>
</launch>

The idea is that a user can run a compass calibration script, and a new calibration is created and overwrites the factory one. But the way this is set up, the launch files in husky_bringup are not useable without the install script having been run, and also can't be passed through roslaunch_add_file_check. Having the ability to do a fallback rosparam would give the best of both worlds.

(And yes, I know we should probably be using $ROS_ETC_DIR rather than /etc/ros/hydro...)

[Kukanani]

I support the addition of this feature. It is frustrating to have crash simply because it can't find a file, so being able to define a series of fallback options or have a better defaulting system would be very helpful.

[veimox]

We have the same use case and we tackled in xacro with this PR with the flag optional, although it has only been merged in noetic. I think this package should provide the means for supporting the use case of robots in production. There are different solutions here as @mikepurvis suggests but we should aim to have a single congruent experience for loading parameters that can be used for intrinsic, extrinsic and per-node calibration.

IMO solutions like the camera_info_manager where the node itself loads a file is too rigid and because is a user configuration, there should be some mechanism in roslaunch.

I can make a PR for the optional flag that would just make the launchfile continue if an exception is risen but I understand that, even though it would solve this specific usecase, it has a greater scope/effect than what is commented on this issue.