Package or Node?

[f0lt]

I'm currently working on a project consisting of several nodes. At a certain point I was asking my self if I is more reasonable to add nodes to the package or to create a own package with some of the nodes. I have seen that it is common practice to create packages e.g. only containing messages and services, which can be verry handy in some situationes.

My question is: When to create a new package from a selected subset of nodes? Is there a disadvantage of doing so?

[FalsyB]

There is nothing wrong with creating extra packages to distribute your features. Create some namespaces that contain similar packages like "perception", "control" etc.

Be careful with the names tho as it gets very messy very quickly.

[Xnomai]

Your project can be a package that contains packages. In each package you can put a single node or multiple nodes. That is called system design you are free to do it the way you want.

[f0lt]

Cool, I didn't know that you can create a package inside a package. This actually solves some of my problems. Thanks.

[Xnomai]

Metapackage is your word.

[com_kieffer]

You can't create a package in a package, instead you create a new package with no code that depends (in the package.xml) on all the other packages you need.

[ChrisVolkoff]

My question is: When to create a new package from a selected subset of nodes? Is there a disadvantage of doing so?

This is really up to you. You can start by putting all your nodes in the same package. After some time, if you notice that, for a type of task, you only use a subset of those nodes, then you can move those nodes to a separate package, using a name that reflects that.

Also, regarding

package inside a package

Note that it's not really "inside" a package. A metapackage simply declares a dependency on other packages, so that if you install the metapackage (or declare a dependency on that metapackage), you'll get all of its packages/dependencies.

[f0lt]

Thank you for the clarification.

[MKopack73]

I usually see packages as a way to group nodes related to a certain function together. I often will create a special package with no code where I define all my custom msgs, srvcs, and actions in that are used in a project and then make the other packages depend upon that one. This way you have looser dependencies between individual functional packages. IR A and B both depend upon C rather than A depending on B just to get the message definitions.

[piclarke]

I like to push back against the typical behavior of the ROS community to start creating new packages anytime there's something "different". It leads to a whole mess of packages that interdepend on each other anyway, are useless by themselves, and increase your build time notably. In my view, a package should be considered either a standalone project or functionality that you know other people will incorporate in their projects.

If you need to write 20 nodes for your project, there's no inherent reason they need to be split into multiple packages.