Rosanswers logo

Hello guys,

I have the following question regarding the architecture of a ROS application.

"How can i implement object oriented programming in a ROS structure"

First A little bit of background: I have taken the lead in an existing ROS project. I am fairly new to ROS but i have used a few years ago.

For my application i have two industrial robot arms that are both controlled via the movegroup interface (python). One of the robots has a camera that detects some objects. Dependent on the output of the camera the robots perform movements. The work that has been done so far (in the current structure).

We have multiple nodes that communicate with each other using topics such as: /request, /reply, /error


  • /Robot1
  • /Robot2
  • /Camera

In the launch file, all nodes are run.

Now another approach i have been looking into is more of an object oriented approach: In a robot class i define all robot functions (with functionality to the move_group). Same is done for the camera class.

Next I make a main class that calls the functions using a state machine like so (of course a simplified version):


robot1 = Robot()
robot2 = Robot()
camera = Camera()

result = camera.get_data()

In the latter way i do not need the request reply and error communication via topics (those are handled within the class itself and communicate with each other using a reference to the main)

Now my question: Which of these two ways is preferred? Also is there any place to find the best practices or Way of Working on ROS programming?

Thanks in advance

Originally posted by Theot on ROS Answers with karma: 11 on 2021-12-06

Post score: 1

Original comments

Comment by Mike Scheutzow on 2021-12-08:
In the latter way i do not need the request reply and error communication via topics (those are handled within the class itself and communicate with each other using a reference to the main)

You are proposing building a single monolithic app that runs on a single host, does not use nodes and does not use publish/subscribe? In my opinion, this new thing would no longer be "ROS".

Comment by Theot on 2021-12-08:
Your comment makes sense. In my example i described a simplified example. What i meant is the following: I will no longer use request reply and error communication via topics, but topics are being used for other things like /camera/result, robot/position, etc. Your comment about no using nodes interests me, since indeed if i use one main program (node) and add child objects in it, i will not initiate multiple nodes and thus only have one node active (apart from some standard robot/camera nodes e.g. moveit).


1 Answer 1


Rosanswers logo

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

Originally posted by osilva with karma: 1650 on 2021-12-07

This answer was ACCEPTED on the original site

Post score: 1


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.