If you want to store config files in a package, I found having separate packages for config and launch files is less problematic. Explained in a new section on a wiki page. Please review, and modify for any correction/improvement. I’m also happy to provide more context on this thread if desired.
2 Likes
Btw, splitting .launch and other config files into separate packages might go against some existing practices. E.g. A convention in ROS-Industrial suggests *_support package to host launch and configs (which in fact is what I’ve been using and circular dependency issue occured that inspired me to make this suggestion).
support packages in ROS-Industrial actually serve a rather narrow purpose: they’re an extension to the regular _description packages. Extension, as _description packages typically only contain files for a single robot.
Industrial robot OEMs tend to have (very) well developed product portfolios with accompanying naming schemes. Robots are grouped into series (or models) and variants within those series, where product names contain letter and digit combinations to indicate which series a particular variant belongs to and how it relates to other variants in that series.
Robot support packages try to exploit this organisation by storing as much as possible all variants of a single series in the same package, as opposed to creating individual _description packages per variant.
Apart from avoiding an explosion of the number of packages, variants within a series can typically also share geometry, leading to reduced package sizes.
As an example: the Fanuc LR Mate 200iC has (or had at the time that support package was created) a total of 9 variants. All of those are supported by the fanuc_lrmate200ic_support package with separate .launch, .yaml and .xacro files. If each variant were supported by its own _description package, we’d have 9 packages for this series alone (and that’s without the MoveIt packages and plugins). And as each variant can share a significant number of its meshes with others, for most variants only link_2 and link_4 meshes are distributed, the rest is reused from the base model.
1 Like
I see, thanks for clarification about ROS-I’s *_support @gavanderhoorn. added a link to its wiki page to this discussion. Also added ROS-I’s example to the roslaunch wiki I cited in the 1st post.
I think there’s no single best practice.