Suggest good example of multi-threading with ROS?

edit

I don't get what you are asking, if it is just an example using Multi-threaded spinner in ROS then: go to http://wiki.ros.org/roscpp/Overview/C...

4.1 Advanced: Using Different Callback Queues

You may have noticed the call to ros::getGlobalCallbackQueue() in the above implementation of spin(). By default, all callbacks get assigned into that global queue, which is then processed by ros::spin() or one of the alternatives. roscpp also lets you assign custom callback queues and service them separately. This can be done in one of two granularities:

Per subscribe(), advertise(), advertiseService(), etc.

Per NodeHandle

(1) is possible using the advanced versions of those calls that take a *Options structure. See the API docs for those calls for more information.

(2) is the more common way:

ros::NodeHandle nh;

nh.setCallbackQueue(&my_callback_queue);

This makes all subscription, service, timer, etc. callbacks go through my_callback_queue instead of roscpp's default queue. This means ros::spin() and ros::spinOnce() will not call these callbacks. Instead, you must service that queue separately. You can do so manually using the ros::CallbackQueue::callAvailable() and ros::CallbackQueue::callOne() methods:

  my_callback_queue.callAvailable(ros::WallDuration());
  // alternatively, .callOne(ros::WallDuration()) to only call a single callback instead of all available

The various *Spinner objects can also take a pointer to a callback queue to use rather than the default one:

  ros::AsyncSpinner spinner(0, &my_callback_queue);
  spinner.start();

or

 ros::MultiThreadedSpinner spinner(0);
 spinner.spin(&my_callback_queue);

4.1 Uses

Separating out callbacks into different queues can be useful for a number of reasons. Some examples include:

Long-running services. Assigning a service its own callback queue that gets serviced in a separate thread means that service is guaranteed not to block other callbacks.

Threading specific computationally expensive callbacks. Similar to the long-running service case, this allows you to thread specific callbacks while keeping the simplicity of single-threaded callbacks for the rest your application.

I've used Asynchronous spinner for this kind of situation:

I'll do it as a service, not a topic, I'll call the service from another node running somewhere else (device with a multi-core processor and/or a GPU) that is running in the same ROS master and that will provide the answer once it finished, but, I might get your question wrong (it is not clear).

Hi Conner

I would look at this from an OOP point of view and my answer would be to isolate scopes.

Your application will generate a comm interface, a worker object (threaded) and other elements: the inner working of the interface (generating a ROS node, or a ZeroMQ pub/sub or anything else really) should be self contained in the interface itself.

The worker takes data input and provides output, what flow this data follows should not be in the scope of the worker.

So the comm interface shouldn't need to know how the worker does its job, and the worker shouldn't need to know how to treat data (when to send it, how to send it, and so on).