Revision history [back]

I am by no means a subject expert in ROS system design or full time developer, so take my answer with a grain of salt please.

What I observed studying many packages over the last few years is that there is not a consistent approach that is being followed when it comes to software design. So in short to answer your question, both approaches will be correct.

However there are core principles that I believe important in ROS core design principles for development that must be followed:

Thin: ROS is designed to be as thin as possible -- we won't wrap your main() -- so that code written for ROS can be used with other robot software frameworks. A corollary to this is that ROS is easy to integrate with other robot software frameworks: ROS has already been integrated with OpenRAVE, Orocos, and Player. ROS-agnostic libraries: the preferred development model is to write ROS-agnostic libraries with clean functional interfaces. Language independence: the ROS framework is easy to implement in any modern programming language. We have already implemented it in Python, C++, and Lisp, and we have experimental libraries in Java and Lua.

Easy testing: ROS has a builtin unit/integration test framework called rostest that makes it easy to bring up and tear down test fixtures.

Scaling: ROS is appropriate for large runtime systems and for large development processes

Source: http://wiki.ros.org/ROS/Introduction

Moreover with ROS2, it is now possible to build a ROS-like middleware system using off-the-shelf open source libraries. This has advantages such as:

maintain less code, especially non-robotics-specific code; take advantage of features in those libraries that are beyond the scope of what we would build ourselves; can benefit from ongoing improvements that are made by others to those libraries; and can point to existing production systems that already rely on those libraries when people ask us whether ROS is “ready for prime time”

Source: https://design.ros2.org/articles/why_ros2.html

ROS was created not to reinvent the wheel in Robotics, so the more you can reuse components/APIs and others can use your components the better the outcome for the whole community.

Finally I found this presentation on Design Patterns with ROS from one of the courses offered by Washington University that might be of interest as well: https://courses.cs.washington.edu/courses/cse466/11au/calendar/ros_cc_2_patterns.pdf

I am by no means a subject expert in ROS system design or full time developer, so take my answer with a grain of salt please.

What I observed studying many packages over the last few years is that there is not a consistent approach that is being followed when it comes to software design. So in short to answer your question, both approaches will be correct.

However there are core principles that I believe important in ROS core design principles for development that must be followed:

Thin: ROS is designed to be as thin as possible -- we won't wrap your main() -- so that code written for ROS can be used with other robot software frameworks. A corollary to this is that ROS is easy to integrate with other robot software frameworks: ROS has already been integrated with OpenRAVE, Orocos, and Player. ROS-agnostic libraries: the preferred development model is to write ROS-agnostic libraries with clean functional interfaces. Language independence: the ROS framework is easy to implement in any modern programming language. We have already implemented it in Python, C++, and Lisp, and we have experimental libraries in Java and Lua.

Easy testing: ROS has a builtin unit/integration test framework called rostest that makes it easy to bring up and tear down test fixtures.

Scaling: ROS is appropriate for large runtime systems and for large development processes

Source: http://wiki.ros.org/ROS/Introduction

Moreover with ROS2, it is now possible to build a ROS-like middleware system using off-the-shelf open source libraries. This has advantages such as:

maintain less code, especially non-robotics-specific code; code;

take advantage of features in those libraries that are beyond the scope of what we would build ourselves; ourselves;

can benefit from ongoing improvements that are made by others to those libraries; and and

can point to existing production systems that already rely on those libraries when people ask us whether ROS is “ready for prime time”

Source: https://design.ros2.org/articles/why_ros2.html

ROS was created not to reinvent the wheel in Robotics, so the more you can reuse components/APIs and others can use your components the better the outcome for the whole community.

Finally I found this presentation on Design Patterns with ROS from one of the courses offered by Washington University that might be of interest as well: https://courses.cs.washington.edu/courses/cse466/11au/calendar/ros_cc_2_patterns.pdf