ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
1 | initial version |
There are no hard and fast rules. Some suggestions:
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.
2 | add comments about naming |
There are no hard and fast rules. Some suggestions:
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:
3 | clarification |
There are no hard and fast rules. Some suggestions:
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: