ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

answered 2011-02-19 15:31:50 -0600

joq gravatar image

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.

click to hide/show revision 2
add comments about naming

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.