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 |
Yes, but you don't want to do this.
Services are not meant for long running operations, as both client and server will be blocked until the service has completed. Even worse: clients have no way of cancelling a service invocation, so they are completely "at the mercy" of the service server during that time.
Instead, implement an action server and update the client periodically on the progress.
Actions are comparable to C++ and Python futures and/or asynchronous services. Clients can choose to wait for completion, or register a callback and get notified about both progress and on completion, but are otherwise completely decoupled from the action server.
See also wiki/ROS/Patterns/Communication and #q11834.
| | 2 | No.2 Revision |
Yes, I want to create a ROS service which will perform the docking based on the IR sensors. [..] Do I can implement subscriber inside the Service server??
Yes you can, but you don't want to do this.this (for multiple reasons).
Services The main reason not to do this would be: services are not meant for long running operations, as both client and server will be blocked until the service has completed. Even worse: clients have no way of cancelling a service invocation, so they are completely "at the mercy" of the service server during that time.
Instead, implement an action server and update the client periodically on the progress.
Actions are comparable to C++ and Python futures and/or asynchronous services. Clients can choose to wait for completion, or register a callback and get notified about both progress and on completion, but are otherwise completely decoupled from the action server.
See also wiki/ROS/Patterns/Communication and #q11834.
| | 3 | No.3 Revision |
I want to create a ROS service which will perform the docking based on the IR sensors. [..] Do I can implement subscriber inside the Service server??
Yes you can, but you don't want to do this (for multiple reasons).
The main reason not to do this would be: services are not meant for long running operations, as both client and server will be blocked until the service has completed. Even worse: clients have no way of cancelling a service invocation, so they are completely "at the mercy" of the service server during that time.
Instead, implement an action server and update the client periodically on the progress.
Actions are comparable to C++ and Python futures and/or asynchronous services. Clients can choose to wait for completion, or register a callback and get notified about both progress and on completion, but are otherwise completely decoupled from the action server.
See also wiki/ROS/Patterns/Communication and #q11834.
And as an example, you may want to take a look at the kobuki_auto_docking package, and the accompanying tutorial: wiki/kobuki/Tutorials/Automatic Docking. They use the same approach.
Actually: you may even be able to reuse the code: it also uses IR sensors and commands the robot using geometry_msgs/Twist messages. If your robot has a similar interface -- and your docking station is setup similarly -- you may be able to just reuse kobuki_auto_docking, which could save you a lot of time.
| | 4 | No.4 Revision |
I want to create a ROS service which will perform the docking based on the IR sensors. [..] Do I can implement subscriber inside the Service server??
Yes you can, but you don't want to do this (for multiple reasons).
The main reason not to do this would be: services are not meant for long running operations, as both client and server will be blocked until the service has completed. Even worse: clients have no way of cancelling a service invocation, so they are completely "at the mercy" of the service server during that time.
Instead, implement an action server and update the client periodically on the progress.
Actions are comparable to C++ and Python futures futures and/or asynchronous services. Clients can choose to wait for completion, or register a callback and get notified about both progress and on completion, but are otherwise completely decoupled from the action server.
See also wiki/ROS/Patterns/Communication and #q11834.
And as an example, you may want to take a look at the kobuki_auto_docking package, and the accompanying tutorial: wiki/kobuki/Tutorials/Automatic Docking. They use the same approach.
Actually: you may even be able to reuse the code: it also uses IR sensors and commands the robot using geometry_msgs/Twist messages. If your robot has a similar interface -- and your docking station is setup similarly -- you may be able to just reuse kobuki_auto_docking, which could save you a lot of time.
| | 5 | No.5 Revision |
I want to create a ROS service which will perform the docking based on the IR sensors. [..] Do I can implement subscriber inside the Service server??
Yes you can, but you don't want to do this (for multiple reasons).
The main reason not to do this would be: services are not meant for long running operations, as both client and server will be blocked until the service has completed. Even worse: clients have no way of cancelling a service invocation, so they are completely "at the mercy" of the service server during that time.
Instead, implement an action server and update the client periodically on the progress.
Actions are comparable to C++ and Python futures and/or asynchronous services. Clients can choose to wait for completion, or register a callback and get notified about both progress and on completion, but are otherwise completely decoupled from the action server.
See also wiki/ROS/Patterns/Communication and #q11834.
And as an example, you may want to take a look at the kobuki_auto_docking package, and the accompanying tutorial: wiki/kobuki/Tutorials/Automatic Docking. They use the same approach.
Actually: you may even be able to reuse the code: it also uses IR sensors and commands the robot using geometry_msgs/Twist messages. If your robot has a similar interface -- and your docking station is setup similarly -- you may be able to just reuse kobuki_auto_docking, which could save you a lot of time.
1) In case I'm going to use an action server, I am going to implement a subscriber inside the server, because that what I need.
Yes, you'd add your subscriber to the action server.
And is it possible to use it with Python?
actionlib also supports Python.
2) I saw kobuki auto docking, but I didn't find an action server, only the client. So a don't know how do they implement the server. If you know where it is, could you please provide me the link.
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.
