ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
1 | initial version |
I think the best solution here really is to let the callback always execute and only use the value if required. Callbacks are not too expensive and I would consider that trying to avoid them without facing actual issues as premature optimization.
roscpp provides the function ros::waitForMessage to just get a single message from a topic. But this method might first subscribe, then wait, and finally unsubscribe from the topic which is much more expensive than executing a normal callback multiple times given the size of the received message is moderate.
Your proposed solution with a service sounds ok, too. If you can modify your publisher and if you really run into performance problems, I think it should be your preferred solution.
2 | No.2 Revision |
I think the best easiest solution here really is to let the callback always execute and only use the value if required. Callbacks are not too expensive and I would consider that trying to avoid them without facing actual issues as premature optimization.
roscpp provides the function ros::waitForMessage to just get a single message from a topic. But this method might first subscribe, then wait, and finally unsubscribe from the topic which is much more expensive than executing a normal callback multiple times given the size of the received message is moderate.
Your proposed solution with a service sounds ok, too. If you can modify your publisher and if you really run into performance problems, I think it should be your preferred solution.
3 | No.3 Revision |
I think the easiest solution here really is to let the callback always execute and only use the value if required. Callbacks are not too expensive and I would consider that trying to avoid them without facing actual issues as premature optimization.
roscpp provides the function ros::waitForMessage to just get a single message from a topic. But this method might first subscribe, then wait, and finally unsubscribe from the topic which is much more expensive than executing a normal callback multiple times given the size of the received message is moderate.
Your proposed solution with a service sounds ok, too. If you can modify your publisher and if you really run into performance problems, I think it should be your preferred solution.