[ros-users] Writing generic subscription callbacks

Troy Straszheim straszheim at willowgarage.com
Wed May 18 22:12:59 UTC 2011

On Thu, May 5, 2011 at 2:31 AM, Daniele Calisi <daniele.calisi at gmail.com>wrote:

> You are saying that the DEserialization method (I can do what I want with
>> the publisher, the problem exists only with the subscriber) is instantiated
>> during the building process and not dynamically at run-time (i.e., ROS uses
>> C++ templating facilities).

void chatterCallback(const std_msgs::String::ConstPtr& msg)
  ROS_INFO("I heard: [%s]", msg->data.c_str());

ros::NodeHandle n;
ros::Subscriber sub = n.subscribe("chatter", 1000, chatterCallback);

Here subscribe() deduces the type of the message from the signature of the
callback.  This type is used to instantiate code that deserializes messages,
in this case of type std_msgs::String.

> This could be good for efficiency reasons (how much?), but I do not see the
>> point of not having the serializers/deserializers table.
Of course you are welcome to construct one.

> Of course you can build a node with a publisher that uses serialization
>> method A and a node with a subscriber, for the same object, with a
>> serialization method B (e.g., a different version of the same object) and
>> things are going to fail. Unmarshalling are usually done (by Data
>> Distribution Services and some other middleware software) by checking object
>> name, version, etc. and then decide how to deserialize. Here it seems that
>> ROS can check this meta information, but only to decide if it is going to
>> use the right deserializer or not.
I think you've got that right.  Topics only contain one type of message...
that's just the model ROS uses.

> Moreover, how subclassing is working here? If I send an object of class A
>> to a subscriber of class B : public A, what happens?
Hmm, message types don't inherit from each other.

> I think that, since you are just receiving a stream of bytes from the
> network, it's up to the subscriber to convert that stream to what is right.

Yeah.  The current API establishes which converter you'll use when the
subscriber is created.

> Finally, you are always "type-converting" a stream of bytes to an object, I
> do not see the point of fearing this conversion, being that done statically
> at building time, or dynamically with an smart unmarshalling system.

Fearing the conversion?

> What am I missing here?
Not sure.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20110518/399fe581/attachment-0003.html>

More information about the ros-users mailing list