Configure X number of nodes in .launch
May be an FAQ but I'm re-posting a question with a result of my bit of research.
I have an application where there's a ROS node that we want to spawn X number of.
- The configuration of that node for X instances can be identical. For some usecases X=2, for some X=5, or even higher. We just can't tell. So having X number of
.launchfiles is not practical. - Ideally solution doesn't add any new limitation to how Nodes via roslaunch start.
Is there a software solution?
Here's what I've found:
- Using
evalkeyword and recursively calling the same .launch file itself #q229489- +1 It doesn't require custom coding (i.e. functionality is in the library).
- -1 Worried that this may not be super versatile, as it requires recursive call to a .launch, which adds another layer on execution step.
- Programatically generating
.launchfile with N nodes.- Write your custom roslaunch Python API. Flexible but you're responsible for the code to work.
xacro?xacrodoesn't support any looping X times AFAICT.- There's an unmerged PR xacro!170 that suggests to allow describing complexed macro in Python.
- Or any other ways to systematically generate launch file? Since it's just an
xmlformat.- An original authors of
xacrobacks up generating a .launch format by scripting language (Python, ruby) etc. back in 2010. There should be tons of libraries that support it.
- An original authors of
- Someone told me saw/heard Rethink Robotics implemented this idea but I haven't found where.
- Someone also said in ROS2 the usecase is supported but I haven't found that yet nor ROS2 is acceptable (our application should work with ROS1). But I'd be happy to see how ROS2 does it if anything.
I'm not sure this is something you should do, but see #q353817 (and the Q&A you already found) for an example on how to implement recursion within
.launchfiles.Reason I'm hesitant about these kinds of things is because I believe
.launchfiles are not meant for this.In my opinion
.launchfiles are part of the configuration of your application, and should probably not contain all sorts of constructs which require (runtime) interpretation of a Turing complete language. Declarative languages have the advantage of being more parseable, which makes analysis possible. If you start adding imperative concepts, that goes away, which is really annoying.If you want "dynamic
.launchfiles", use a higher-level entity to generate those, such as the Python package linked in #q368557. This generates.launchfiles. Iteration is fully supported there.While I 100% agree with "
.launchfiles are part of the configuration of your application" (it's just an input file of an executableroslaunch), I'm not sure if I fully understood your concern. I do agree if you're saying there should be static files (or any form) that define the state of app (by dynamically defining some configs that would be impossible). That said, one thing to clarify about the usecase my team has in mind is that we intend to have static files that are to be passed the process X (and this process X is what I'm looking for in this thread).