## Using ROS services

ReconCell has a deep integration with ROS and therefore relies on service definitions that can be called by the different agents inside the network.

Even though direct use of services from within VEROSIM by an end-user is not recommended, we will briefly cover the basic service structure. That will help in the case a new service is to be added or if problems arise during the programming of service calls with ActionBlocks.

In general, the ActionBlocks' behaviors form an abstraction layer that hide all the service specific functionality. This should be the general way to use service calls, since it simplifies the programming tasks.

### List of Services

__ServiceClientOutput__
This service sets a digital output on a robot controller. It is a service implementation that is specific to ReconCell. Since most of the tools, which are available in the ReconCell ecosystem, are operated by binary signals connected to the robot controller, this Service allows the lowest level control of tools (open, close, pneumatics, hydraulics, etc.)

__ServiceClientSetBool__
This service is a base service available through the ROS distribution. It's sole purpose is to set a boolean value to `True` or `False`.

__ServiceClientEncodeTrajectoryToDMP__
This service is an example of a complex data processing service. It will pass a sampled trajectory as an argument to the service implementation and returns a DMP descriptor of the encoded DMP.

### Configuration of Services

The configuration of services is very specific and needs to be reconsidered for every tool or agent that relies on a ROS Service. The basic configuration presumes the specification of a ROS ActionServer name. This is basically the name of a Topic in the ROS network. Therefore, this basic configuration is similar to Publishers and Subscribers.

![](ros_serviceconfig.png "")

Since the ActionBlock behaviors create a layer above the Services most other configuration options are available there.

### Example: Gripper Behavior configuration

We intend to configure the agent of a gripper. Therefore, we add an `VSLibActionBlocks::Agent` node to your model and name it `Gripper`. Then we also add a `ReconcellNetLib::Gripper` behavior to the `Agent Behaviors` list of your newly created gripper.

![](ros_servicegripper.png "")

This Behavior is aware of the ROS Service interface and will call the necessary Service functions to pass the right arguments to the ROS Service implementation. Therefore, we add a `VSLibROSReconCell::ServiceClientOutput` to the extension list of the gripper and enter the name of the service. Then we add a reference to the `ServiceClientOutput` to the `serviceClient` property of the behavior.

![](ros_servicename.png "")

Select the Behavior afterwards and set the properties according to the following specification.

![](ros_servicebehavior.png "")

__BitOpen__

This property defines which digital output triggers the _open_-event on the tool. This bit will be set to the value of the __BitValueOpen__ property as soon as a release action is triggered from an ActionBlock.

__BitValueOpen__

This property is either `True` or `False` and specifies the value of the digital output that will open the gripper tool.

__BitClose__

This property defines which digital output triggers the _close_-event on the tool. This bit will be set to the value of the __BitValueClose__ property as soon as a grip action is triggered from an ActionBlock.

__BitValueClose__

This property is either `True` or `False` and specifies the value of the digital output that will close the gripper tool.


In this example the gripper will open when the second digital output is set to `True` and it will close when the same digital output is reset to `False`.
This agent is now ready to be used as an agent as a `Grip or Release ActionBlock` in an actual process.