===== ROS Trigger integration =====

The ROS-Trigger implementation works together with the ros package **robot_control** and needs specific configuration by additional Properties to the trial type. The properties are organised as a PropertyGroup with the fix name "ROSTrigger":

<code xml>
...
<TrialType name="takeover" duration="2"
              labelset="Input.xml" measurementSystemConfigIds="default">
  <PropertyGroup name="ROSTrigger">
        <Property name="robot_cmd_node_name" value="robot_command_server"/>
        <Property name="robot_cmd_service_name" value="robotCommand"/>
        <Property name="nextcycle_cmd_node_name" value="robot_nextcycle"/>
        <Property name="nextcycle_cmd_service_name" value="nextCycle"/>
        <!-- optional properties, needed if no ROSMeasurementSystem is configured-->
        <Property name="localhost" value="192.168.10.100"/>
        <Property name="masteruri" value="http://192.168.10.2:11311"/>
  </PropertyGroup>
  ...
</code>

The initialisation of the trigger, implemented by the init()-method of the iTrigger service provider interface invokes per default the ros service defined by the property "robot_cmd_service_name" on the ros node defined by the property "robot_cmd_node_node" with the parameter "LOAD". This loads a program written in URScript defined as as a property in the launch file of the ROS package.

If the property "robot_ctrl_dnsidentifiablename" is set this mechanism to load the programm is skiped and additionally to start the program the String "START" is sent to a socket-server at the ip/port given by this property.

^ Property name 	^ Description ^ Optional |
^ robot_cmd_program_name | Name of the ur-script which should be loaded, started, etc. If this attribute is not set an other implementation can be used to load the program, e.g. via Artiminds RPS. | No |
^ robot_cmd_node_name | The name of the ROS node, which provides a service to start something before the measurement is started (start trigger). Do not set this if the robot program is loaded otherwise. | Yes |
^ robot_cmd_service_name| The name of the service to start something before the measurement is started.   | No |
^ robot_ctrl_dnsidentifiablename | Alternative to start the robot program by a simple socket. If this property is set the mechanism to load the robot program defined by the above properties is skiped | Yes |
^ nextcycle_cmd_node_name| The name of the node with the service which can be used to ask for availability of the next cycle the measure. | No |
^ nextcycle_cmd_service_name| The name of the service, which can be used to ask for availablility of the next cycle to measure | No |
^ nextcycle_cmd_service_timeout | Timeout in [s] for waiting for next cycle. | No |
^ calibrate_cmd_service_name | The name of the service to start a calibration task to align the local coordinate system of the robot and the vicon system. | optional, instead of next_cycle_cmd_service_name |
^ loading_robot_program_timeout | Timeout in seconds waiting for a response after invocation of loading a robot program. Default value is 10s | Yes |
^ starting_robot_program_timeout | Timeout in seconds waiting for a response after invocation of starting a robot program. Default value is 10s | Yes |
^ localhost | Local host uri name, used, if this is not configured by a ROSMeasurementSystem. Can be used to define which of multiple networks cards should be used. | Yes |
^ masteruri | ROS master uri name, used, if this is not configured by a ROSMeasurementSystem. This is needed to find the ROS master. | Yes |

==== Multi cycle recording ====
The ROS **iTrigger** implementation determines with invocation of the **nextCycle()** method the following properties, which are collected into the property group **modalities**. This property group is saved into the trial and the property **cycle_nr** is used as the suffix of the next recorded trial.

^ Property name ^ Description ^
^ cycle_nr | The index of the next pose the robot will drive to. |  
^ pose_x | The x position of the next pose the robot will drive to. |
^ pose_y | The y position of the next pose the robot will drive to. |
^ pose_z | The z position of the next pose the robot will drive to. |

A specific feature of the next-cycle-mechanism implementation of the ROS-trigger is to reset the server cycle next-cycle implementation by invoking inside close()-method of the trigger. That means after recording the last trial of a multi-cycle trial type the trigger is closed and autmatically the serverside code gets the message for resetting flags and counter.

It is possible to use the next-cycle-mechanism independed from the start/stop-triger-functionality. That means you can use a specific trigger implemenatation to load, start and stop a robot and you can use this ROS-implementation only to manage the next-cycle functionality.

**Hint:** There is a strange bug, which results in, that the ROS-Client-Nodes do not find the ROS system, although the ROS master is found. In this case a in the hosts-file the name of the PC which hosts the ROS-Master has to be added mapping to the ip-adresses of the used network card.
==== The corresponding ROS package "robot_control" ====
The ROS iTrigger implementation communicates with the ROS package [[https://github.com/MobMonRob/robot_control | robot_control]]. This package can be configured by properties in its launch files:

^ Property name 	^ Description ^ 
^ robot_ip | The ip adress of the robot to control | 
^ robot_port | The port the dashboard server of the UR-robot can be reached | 
^ robot_program| The name of the ur-script program which should be used |