Revision history [back]

There are no hard and fast rules. Some suggestions:

• Each ROS package is built as a unit:
  • Pay attention to package dependencies. Avoid combining nodes that pull in mutually unneeded dependencies.
  • Avoid combining nodes that are often used separately (to eliminate unnecessary build overhead).

• The overhead of an extra ROS package is not very large. Define separate packages wherever they make sense.

• If a group of nodes with similar dependencies are generally used together, consider combining them in a single package.

• If some nodes have common dependencies on shared code that you do not wish to export publicly, they can be combined internally within a single package.

• If the shared code should be exported, consider making it a separate package that the others depend on.

There are no hard and fast rules. Some suggestions:

• Each ROS package is built as a unit:
  • Pay attention to package dependencies. Avoid combining nodes that pull in mutually unneeded dependencies.
  • Avoid combining nodes that are often used separately (to eliminate unnecessary build overhead).

• The overhead of an extra ROS package is not very large. Define separate packages wherever they make sense.

• If a group of nodes with similar dependencies are generally used together, consider combining them in a single package.

• If some nodes have common dependencies on shared code that you do not wish to export publicly, they can be combined internally within a single package.

• If the shared code should be exported, consider making it a separate package that the others depend on.

• Choose package names carefully:

  • Node names are local within their package, but package names are global to the entire ROS ecosystem.
  • They are messy to change later.

There are no hard and fast rules. Some suggestions:

• Each ROS package is built as a unit:
  • Pay attention to package dependencies. Avoid combining nodes that pull in mutually unneeded dependencies.
  • Avoid combining nodes that are often used separately (to eliminate unnecessary build overhead).

• The overhead of an extra ROS package is not very large. Define separate packages wherever they make sense.

• If a group of nodes with similar dependencies are generally used together, consider combining them in a single package.

• If some nodes have common dependencies on shared code that you do not wish to export publicly, they can be combined internally within a single package.

• If the shared code should be exported, consider making it a separate package that the others depend on.on. (This is reasonable, but not required. A single package can export libraries and headers as well as nodes.)

• Choose package names carefully:

  • Node names are local within their package, but package names are global to the entire ROS ecosystem.
  • They are messy to change later.