[ros-users] Nodelet version of rosbag?

[Jeremy Leibs]

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
<bouffard at eecs.berkeley.edu> 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 <gerkey at willowgarage.com> wrote:
>> On Sun, Jan 30, 2011 at 11:47 AM, Radu Bogdan Rusu
>> <rusu at willowgarage.com> 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 at code.ros.org
>> https://code.ros.org/mailman/listinfo/ros-users
>>
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>