Revision history [back]

Personally, I think your solution is fine. Option 1 is heavy because you're creating and destroying the connections each time its called and delayed from waiting for the next message to arrive. This second way will incur a copy, another way of doing this might be to pass the callback a constptr of the msg, for instance franka_msgs::FrankaStateConstPtr. This will stop 2 copies so you'll only have 1, if my understanding of it is correct.

Essentially what you're doing has 1 copy to get into the callback, then another to your variable since storing it out of the scope of the function. The constptr is a boost shared pointer so you don't incur the second copy.

Even running at 30 hz just copying over shouldn't be too horrible for your application unless you're trying to run on something super weak (raspberry pi, etc). If you're on a desktop, this is fine.

There's no good support for "on demand" messages from a topic at the moment. I'm sure you could make one with a message filter or wrapping up the subscriber class yourself, but nothing out of the box that I am aware of.