Benutzer-Werkzeuge

Webseiten-Werkzeuge


trigger:ros

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“:

...
<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>
  ...

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 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
trigger/ros.txt · Zuletzt geändert: 2023/02/08 12:50 von oliver

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki