Revision history [back]

I agree with your thinking. Best practice usually 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.

I agree with your thinking. Best Unless the device interface is very simple, best practice usually 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.

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.