Logging and processing the same sensor data

edit

Assuming my sensor is GPS, then based on your recommendation, I should decode the data and transfer it to e.g. geometry_msgs/Pose and then published and loggen this "compact" data set. In case of a bug in my decoder, that geometry_msgs/Pose won't make sense, my rosbag won't help me.

Assuming your sensor is GPS, you should try to find an existing component.

As to @PeteBlackerThe3rd's suggestion: that is indeed how sensors should be integrated into ROS.

@quantum: debugging internal algorithms is typically part of unit tests, not integration tests. ROS nodes do not come ..

.. into play in unit tests. So verifying your decoder is ok would be a unit-test level task and at that point you'd have access to the serialised packets/streams/X and the decoded ones and can do all the verification you'd need (it would most likely not even be against an actual device).

@gvdhoorn, thanks for trying to explain newbie how ROS works. Assuming my sensor is a camera, then i saw sensor_msgs/Image Message. Fine for me, since i have, uint8[] data, which contain the actual matrix data, size is (step * rows), then i am with you.

Normally moving from one format to another causes for reduce of information, that is why I would always like to log in a rosbag the original information. How knows, maybe in one year you will need something that now you do not need\thought about it.

The question is one of abstraction, to reduce overall system complexity. The idea of the sensor driver node is that the rest of the ROS system doesn't need to know anything specific about the sensor, just that it's a camera/gps/etc.

@PeteBlackerThe3rd, i agree with you. The idea is always to have the sensor data in an abstract layer.

Perhaps you can take a look at how the velodyne_driver approaches this: it uses custom messages as a first step that try to capture as much of the original data and semantics, and then uses a post-processing node that turns those msgs into ..