Rosbag record and playback is built on top of a defined and (perhaps poorly) documented API. http://www.ros.org/wiki/rosbag/Code%20API In theory, writing a nodelet that logs a specific datatype to a bagfile is trivial. In terms of operation, a const pointer will get passed to the nodelet, the nodelet will call bag.write() using that const pointer, and the pointed-to message class in question will be responsible for serializing the message into the bag file. But, you will need to compile that nodelet with a callback signature that references the specific type you are recording. This means you need one nodelet per set of types you want to record, and this will pretty much need to get done on use-by-use basis. But, the point that Brian is made is crucial -- even in this optimized setting, with a type-specialized nodelet, the message still has to serialized to get it into the bag. You would be able to avoid some finite number of copy's, but that's all. Now, as far as a general-purpose rosbag nodelet is concerned, I believe the state of affairs is more grim. In the case of the rosbag node, we subscribe using the topic_tools shapeshifter. This is a message that conforms to any message you subscribe to. Implementation-wise, it's handled by the fact that it doesn't actually deserialize the data. This is why the rosbag executable doesn't actually need to have been compiled against every possible message header. Now, you can do this same thing in the case of a nodelet, but it will no longer be eligible for zero-copy transport, since you don't have the same shared pointer being used by the publisher and the subscriber. Roscpp will need to handle this by serializing the message into the outgoing queue just like it does when going between nodes. My guess is that at best this pipeline should be 1 copy shorter than going between nodes, and that, in all likelihood, the pipeline is actually the same length, but you're replacing a transfer through the loopback tcp stack with an in-process memcpy. Perhaps a small win, but not a huge one. On Sun, Jan 30, 2011 at 12:31 PM, Patrick Bouffard wrote: > For a nodelet rosbag, wouldn't the message be passed to rosbag as a > const pointer first, and then rosbag itself would handle > serialization? Or is that even possible.. maybe not, I guess rosbag > doesn't just magically know how to serialize each and every message > type--or does it? > > Pat > > On Sun, Jan 30, 2011 at 12:21 PM, Brian Gerkey wrote: >> On Sun, Jan 30, 2011 at 11:47 AM, Radu Bogdan Rusu >> wrote: >>> We could try creating a BAGWriter class similar to pcl_ros::BAGReader if you think that's useful. Basically you want to >>> dump data to disk faster, without going through serialization/deserialization, right? >> >> I'm pretty sure that rosbag doesn't deserialize anything, but rather >> just dumps serialized messages to disk as fast as it can.   And >> because the .bag format is serialized messages, you can't avoid the >> serialization step.  I think that the nodelet method would only save >> the (kernel-mediated) copy of each serialized message from the >> producing node to rosbag.  From the point of view of throughput, I >> would expect writing to disk to be the rate-limiting step.   I guess >> it comes down to whether the CPU usage involved the node->rosbag copy >> is significant. >> >>        brian. >> >>> On 01/30/2011 11:31 AM, Patrick Bouffard wrote: >>>> Are there any plans to implement rosbag (in particular, rosbag record) >>>> as a nodelet? I can see this being useful when you want to record >>>> large amounts of camera or point cloud data. >> _______________________________________________ >> ros-users mailing list >> ros-users@code.ros.org >> https://code.ros.org/mailman/listinfo/ros-users >> > _______________________________________________ > ros-users mailing list > ros-users@code.ros.org > https://code.ros.org/mailman/listinfo/ros-users >