search

orocos / rtt_ros_integration

Orocos-ROS integration libraries and tools
BSD 3-Clause "New" or "Revised" License
85 stars 56 forks source link

Improve documentation on ROS service call behavior and the relation to the number of spinner threads #91

Open jlack1987 opened 7 years ago

jlack1987 commented 7 years ago

Say I have an orocos component that has an operation such as,

this->addOperation("do_work", &MyWorker::doWork, this, RTT::ClientThread).doc("Does work");

Where when called, this blocks the callers thread and does not block the task context thread. I'm unable to find anywhere in the documentation for rtt_ros_integration whether or not ROSServiceService calls respect the orocos operation spec on whether to block the client thread of the task context thread.

gavanderhoorn commented 7 years ago

Related: Do rosservice calls from rtt_ros respect orocos operation thread spec? on ROS Answers.

meyerj commented 7 years ago

The ROS service operation does not behave differently than any other RTT operation here: As you have added it as RTT::ClientThread, the caller (the ROS spinner in this case) will execute the operation in its own thread without synchronization with the component's activity. In most cases you therefore want to add the operation with RTT::OwnThread, in which case the component's activity/thread will execute it. So the short answer is: Yes, the spec is respected.

It should also be noted that the ROS spinner will always be blocked and eventually waits for the successful completion of the operation, even with RTT::OwnThread. If you are using rtt_rosnode you can increase the number of spinner threads if you do not want to block incoming messages or service calls (see https://github.com/orocos/rtt_ros_integration/commit/e6a57dc3c8caf9e517800e85fdc93d541c26f050) until the operation is done.

We could indeed add a note to the rtt_roscomm documentation in rtt_roscomm/README.md and also document the ~spinner_threads parameter or even increase the default to 4 or more.

References:

jlack1987 commented 7 years ago

Thanks, the behavior i'm going for is I would like a TaskContext to to have some Operations that are made available through ROS service calls, but I don't want the service call to block the thread calling the updateHook() function. Long story short I think you said the orocos component can create services and those services will not block the components calling of updateHook().

ahoarau commented 7 years ago

You can create components, and connect the operations to ROS services without having the updateHook() blocked, using RTT::ClientThread. In the end it's the rosservice that calls the operations and transmits them to ROS, so it's rosservice the Client in that case.

jlack1987 commented 7 years ago

Just to try to add some to this. I did end up getting this working, but had to look at what was done in the unit test to figure out how to get it all working properly. Some more thorough examples for how to get started using the awesome features here would be great and probably extremely helpful for some who won't crawl through the code to figure it out.