The site is read-only. Please transition to use Robotics Stack Exchange
| ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
 | 1 | initial version |
I think it's safe to say that, in general, you'd not use fork/exec within a ROS node. roslaunch serves that purpose for most cases.
You cited actionlib for your threading example. Yes, spinOnce is a proper (and non-buggy) way of handling callbacks. In this context, realize that ROS provides three types of inter-node interaction:
One uses an actionlib client when other 'work' needs to be done while the action is executing; that is, one thread will perform that 'work' while another keeps track of the action's progress. ROS's spin is a terminal call (i.e., non-returning until the node shuts down), with the effect that all message processing must be handled within the callbacks (and processing will only be done in the callbacks). Clearly that's inadequate for the other 'work'.
As an example, let's take a GUI for...oh, anything long-running, say navigation or object recognition. The 'work' that needs to be done is keeping the user interface responsive -- blocking the UI thread is a non-starter. For navigation, you likely want to update some representation of the current state with the actionlib feedback as it's received while the user interacts with other parts of the UI. For object recognition, it's likely not the feedback that's important, but rather the final results -- while the scene is being analyzed, the user (or the system internally) can 'work on' other things.
Some previously asked/answered spinOnce questions that you may want to look at:
| | 2 | No.2 Revision |
I think it's safe to say that, in general, you'd not use fork/exec within a ROS node. roslaunch serves that purpose for most cases.
You cited actionlib for your threading example. Yes, spinOnce is a proper (and non-buggy) way of handling callbacks. In this context, realize that ROS provides three types of inter-node interaction:
One uses an actionlib client when other 'work' needs to be done while the action is executing; that is, one thread will perform that 'work' while another keeps track of the action's progress. ROS's spin is a terminal call (i.e., non-returning until the node shuts down), with the effect that all message processing must be handled within the callbacks (and processing will only be done in the callbacks). Clearly that's inadequate for the other 'work'.
As an example, let's take a GUI for...oh, anything long-running, say navigation or object recognition. The 'work' that needs to be done is keeping the user interface responsive -- blocking the UI thread is a non-starter. For navigation, you likely want to update some representation of the current state with the actionlib feedback as it's received while the user interacts with other parts of the UI. For object recognition, it's likely not the feedback that's important, but rather the final results -- while the scene is being analyzed, the user (or the system internally) can 'work on' other things.
Some previously asked/answered spinOnce questions that you may want to look at:
*Note: in fact, it's exactly spinOnce that allows pub/sub to be non-blocking, as spin is terminal, and thus effectively blocks.
ROS Answers is licensed under Creative Commons Attribution 3.0 Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.
