Revision history [back]

By moving the calculations outside of the callback (recommended, of course!), you're explicitly decoupling calculations from the callback mechanism, thereby necessarily losing the ability to begin processing the "instant it arrives". With that said, what you probably desire is an event system (that operates with its own event queue, not simply a subsidiary function callback). That's beyond the scope of this answer.

What you could do instead -- much easier, but likely uses a bit more CPU and is a bit less responsive -- is to use a combination of ROS Timer and your own data queue. In your data callback, put the data in your queue; in the timer callback, process an (likely all) element that is in the queue (if none, just return).

Note that by using a Timer, you're utilizing the ROS callback system. Assuming single threaded spinning, there's no need to worry about data synchronization. But note also that a typical spin() will process all messages in the callback queue, so special measures would need to be taken to process one message at a time (e.g., guarantee that there will always be a timer event between queued data messages).

By moving the calculations outside of the callback (recommended, of course!), you're explicitly decoupling calculations from the callback mechanism, thereby necessarily losing the ability to begin processing the "instant it arrives". With that said, what you probably desire is an event system (that operates with its own event queue, not simply a subsidiary function callback). That's beyond the scope of this answer.

What you could do instead -- much easier, but likely uses a bit more CPU and is a bit less responsive -- is to use a combination of ROS Timer and your own data queue. In your data callback, put the data in your queue; in the timer callback, process an (likely all) element that is in the queue (if none, just return).

Note that by using a Timer, you're utilizing the ROS callback system. Assuming single threaded spinning, there's no need to worry about data synchronization. But note also that a typical spin() will process all messages in the callback queue, so special measures would need to be taken to process one message at a time (e.g., guarantee that there will always be a timer event between queued data messages).