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

Best practices for hardware package organization?

asked 2015-12-21 11:28:43 -0500

BrettHemes gravatar image


I have recently started to invest significant time into developing ROS packages for my work and have a question regarding best practices and/or suggestions when it comes to code organization. Specifically my question is as follows:

When developing packages for hardware, should I aim to develop ROS-specific code or start with a general purpose library and then extend it to work with ROS via a wrapper or base class?

I would like to have my code be reusable outside of ROS if necessary and thus avoid any ROS-specific types/functions in the library but I got a bit confused when I try to utilize any ROS functionality (e.g., rosconsole messages, service callbacks, etc.). My current thoughts are to develop the hardware interface as a standalone class/library and then inherit it as a base class to another ROS-specific class that adds callback member functions for services and the like... I figure this might just be a preference thing but thought I would try to get some feedback on the topic while I am still in the early stages of integration.

Thanks, Brett

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted

answered 2015-12-21 12:06:17 -0500

joq gravatar image

updated 2015-12-21 12:14:20 -0500

I agree with your thinking. Unless the device interface is very simple, best practice involves writing a hardware-specific library or class interface which can be wrapped in a relatively small ROS node.

The ROS-agnostic library needs to be careful how it reports errors, since it lacks direct access to the ROS logging and diagnostic services. There are various reasonable solutions: throwing C++ exceptions; using return codes; providing error status and diagnostic status interfaces; etc.

Sometimes, when data copying overhead is significant, it's worth providing access to ROS messages from within the library. For example, a camera driver may want to return its data directly in a sensor_msgs/Image structure. Depending on how it's done, that might or might not require the library to include some ROS message headers.

You are welcome to join the ROS drivers special interest group. It has been active for several years, discussing these and similar questions on a relatively low-volume mailing list.

edit flag offensive delete link more

Question Tools



Asked: 2015-12-21 11:28:43 -0500

Seen: 242 times

Last updated: Dec 21 '15