0
$\begingroup$

Rosanswers logo

Hello there,

I have tested the connection and connectivity to the real robot by using this command:

$ roscore 
$ roslaunch kuka_rsi_hw_interface test_hardware_agilus.launch sim:=false
$ rosrun rqt_joint_trajectory_controller rqt_joint_trajectory_controller

And it is working fine as excepted. Even if I change my real-robot moments from the smart pad, I can see the Moveit robot moving parallelly (Link).

For configuring my real robot with moveit, I followed these links: Link 1,, Link 2, Link 3.

From this above link, I have edited the files:

  1. After moveit setup assistance: In the moveit package, add this file moveit_planning_execution_rsi.launch in the launch folder.

     <launch>
       <!-- A convenience launch file that launches all of the required nodes to
            plan and execute motions using RViz, MoveIt and the ros_control based
            KUKA RSI driver from the kuka_rsi_hw_interface package.
       -->
      <arg name="pipeline" default="ompl" />
       <!-- the "sim" argument controls whether we connect to a Simulated or Real robot -->
       <!--  - if sim=false, a robot_ip argument is required -->
       <arg name="sim" default="true" doc="Use industrial robot simulator instead of real robot" />
       <arg name="robot_ip" unless="$(arg sim)" doc="IP of controller (only required if not using industrial simulator)" />
    
       <!-- By default, we do not start a database (it can be large) -->
       <arg name="db" default="false" doc="Start the MoveIt database" />
       <!-- Allow user to specify database location -->
       <arg name="db_path" default="$(find kuka_moveit_roof)/default_warehouse_mongo_db" doc="Path to database files" />
    
       <!-- By default, we are not in debug mode -->
       <arg name="debug" default="false" />
    
       <!-- By default, we will load or override the robot_description -->
       <arg name="load_robot_description" default="true"/>
    
       <arg name="use_rviz" default="true" />
    
       <!-- Non-standard joint names -->
       <rosparam command="load" file="$(find kuka_kr16_support)/config/joint_names_kr16.yaml" />
    
       <include file="$(find kuka_moveit_roof)/launch/planning_context.launch" >
         <arg name="load_robot_description" value="true" />
       </include>
    
     <!--  <arg name="use_gui" default="false" />-->
     <!--    &lt;!&ndash; We do not have a robot connected, so publish fake joint states &ndash;&gt;-->
     <!--  <node name="joint_state_publisher" pkg="joint_state_publisher" type="joint_state_publisher" unless="$(arg use_gui)">-->
        <!--    <rosparam param="source_list">[move_group/fake_controller_joint_states]</rosparam>-->
        <!--  </node>-->
        <!--  <node name="joint_state_publisher" pkg="joint_state_publisher_gui" type="joint_state_publisher_gui" if="$(arg use_gui)">-->
     <!--    <rosparam param="source_list">[move_group/fake_controller_joint_states]</rosparam>-->
     <!--  </node>-->
    
     <!--   run the robot simulator and action interface nodes-->
       <group if="$(arg sim)">
            <include file="$(find industrial_robot_simulator)/launch/robot_interface_simulator.launch" />
       </group>
    
       <!-- run the "real robot" interface nodes -->
       <group unless="$(arg sim)">
            <include file="$(find kuka_kr16_support)/launch/robot_interface_streming_kr16.launch">
           <arg name="robot_ip" value="$(arg robot_ip)"/>
         </include>
       </group>
    
       <!-- publish the robot state (tf transforms) -->
       <node name="robot_state_publisher" pkg="robot_state_publisher" type="robot_state_publisher" />
        <include file="$(find kuka_moveit_roof)/launch/move_group.launch">
         <arg name="allow_trajectory_execution" value="true"/>
         <arg name="fake_execution" value="true"/>
         <arg name="info" value="true"/>
         <arg name="publish_monitored_planning_scene" value="true" />
       </include>
    
       <include file="$(find kuka_moveit_roof)/launch/moveit_rviz.launch" if="$(arg use_rviz)">
         <arg name="rviz_config" value="$(find kuka_moveit_roof)/launch/moveit.rviz"/>
            <arg name="debug" value="$(arg debug)"/>
       </include>
    
    
       <!-- If database loading was enabled, start mongodb as well -->
       <include file="$(find kuka_moveit_roof)/launch/default_warehouse_db.launch" if="$(arg db)">
         <arg name="moveit_warehouse_database_path" value="$(arg db_path)"/>
       </include>
    
     </launch>
    
  2. In kuka_experimental folder kuka_rsi_hw_interface added robot_interface_streaming.launch file in it:

     <?xml version="1.0" encoding="utf-8"?>
     <launch>
     <!-- This launch file provides a ROS-Industrial compatible launch wrapper
          around the KUKA RSI ros_control based hardware interface node. It is
          intended to expose the same interfaces (services, topics) with similar
          semantics as a typical (industrial_robot_client-based) ROS-Industrial
          driver.
          Remapping of the Action server topics subscribed to by the joint
          trajectory controller of ros_control to those described in the
          ROS-Industrial driver specification as well as use of the typical
          parameters used by ROS-Industrial robot driver launch files is included.
          Identical to other ROS-Industrial driver base launch files, it's the users
          responsibility to:
            1. set the 'controller_joint_names' parameter (prior to starting or
               including this launch file)
            2. set the 'robot_description' parameter (prior to starting or including
               this launch file)
            3. run an instance of robot_state_publisher
          For points 1 and 2 (and for simple setups), users are encouraged to use
          the 'launch/load_X.launch' and the 'config/joint_names_X' files provided
          with the various robot support packages for KUKAs in the
          ros-industrial/kuka_experimental repository.
          Notes:
            1. remapping the action topics makes the joint_trajectory_controller
               incompatible with the rqt_joint_trajectory_controller package
            2. the hardware interface node will throw an exception and exit if
               it does not find either the 'robot_description' or the
               'controller_joint_names' parameter on the server. THIS BEHAVIOUR IS
               DIFFERENT FROM WHAT THE GENERIC NODES IN INDUSTRIAL_ROBOT_CLIENT DO
               IN THAT CASE (they will use a default set of joint names and
               continue with those).
     -->
    
       <arg name="robot_ip" doc="IP of the RSI interface on the controller" />
       <arg name="robot_port" default="49152" doc="UDP port the RSI interface on the controller is configured to use" />
    
       <!-- name of the ros_control controllers (see below) -->
       <arg name="js_ctrlr" value="joint_state_controller" />
       <arg name="pos_ctrlr_name" value="position_trajectory_controller" />
    
       <!-- other ROS-Industrial nodes may expect the 'robot_ip_address' parameter
            to be present -->
       <param name="robot_ip_address" type="str" value="$(arg robot_ip)" />
    
       <!-- the hardware_interface node expects its parameters in the 'rsi' namespace -->
       <rosparam subst_value="true">
         rsi:
           address: $(arg robot_ip)
              port: $(arg robot_port)
       </rosparam>
    
       <!-- the ros_control controller configuration for the hardware_interface:
            this is typically loaded from the 'config/hardware_controller.yaml' file,
            but is recreated here to ensure a consistent configuration when using
            this convenience launch file -->
       <rosparam subst_value="true">
         $(arg js_ctrlr):
           type: joint_state_controller/JointStateController
           publish_rate: 50
    
         # NOTE: these joint names MUST correspond to those specified in the
         #       'controller_joint_names' parameter (typically loaded by the
         #       calling launch file)
         $(arg pos_ctrlr_name):
           type: "position_controllers/JointTrajectoryController"
           joints:
             - joint_a1
             - joint_a2
             - joint_a3
             - joint_a4
             - joint_a5
             - joint_a6
    
           state_publish_rate: 50 # Defaults to 50
           action_monitor_rate: 20 # Defaults to 20
       </rosparam>
    
       <!-- main 'driver node': the RSI hardware interface -->
       <node name="kuka_hardware_interface" pkg="kuka_rsi_hw_interface" type="kuka_hardware_interface_node" respawn="false">
         <!-- remap topics to conform to ROS-I specifications -->
         <remap from="$(arg pos_ctrlr_name)/follow_joint_trajectory" to="/joint_trajectory_action" />
            <remap from="$(arg pos_ctrlr_name)/state" to="/feedback_states" />
         <remap from="$(arg pos_ctrlr_name)/command" to="/joint_path_command"/>
       </node>
    
       <!-- spawn the actual controllers: note that the names of the controllers must
            correspond to those specified in the rosparam snippet above -->
       <node name="controller_spawner" pkg="controller_manager" type="spawner"
         args="$(arg pos_ctrlr_name) $(arg js_ctrlr) --shutdown-timeout 1"
         respawn="false" output="screen" />
     </launch>
    
  3. kuka_kr16_support folder in launch added robot_interface_streming_kr16.launch:

      <?xml version="1.0"?>
         <!--
           Manipulator specific version of 'robot_interface_streaming.launch'.
           Defaults provided for KR 6 r900 sixx:
            - 6 joints
           Usage:
             robot_interface_streaming_kr6r900sixx.launch robot_ip:=<value>
           NOTE: this is a convenience wrapper launch file intended to emulate a
           typical ROS-Industrial robot support package variant specific 'robot
           interface streaming' setup. It depends on the main 'robot interface
           streaming' launch file provided by the kuka_rsi_hw_interface package.
           This emulation is not complete (see the robot_interface_streaming.launch
           file in the kuka_rsi_hw_interface package for more comments): starting
           this launch file on its own for instance does not work, while that is
           possible with industrial_robot_client-based ROS-Industrial drivers.
         -->
         <launch>
           <arg name="robot_ip" doc="IP of controller" />
    
           <rosparam command="load" file="$(find kuka_kr16_support)/config/joint_names_kr16.yaml" />
    
           <include file="$(find kuka_rsi_hw_interface)/launch/robot_interface_streaming.launch">
                <arg name="robot_ip" value="$(arg robot_ip)" />
           </include>
    
         </launch>
    

Issue:

If I give some moment into the Rviz using moveit I cannot see any change in the real-robot. (https://youtu.be/Z0wFONd_zfI)

Outputs : roslaunch kuka_moveit_roof moveit_planning_execution_rsi.launch sim:=false robot_ip:=192.168.2.210

This code block was moved to the following github gist: https://gist.github.com/answers-se-migration-openrobotics/f80f39424c1d4c6f048dfd4c5a9c5980

Thanks in advance for helping!!


Originally posted by Ranjit Kathiriya on ROS Answers with karma: 1622 on 2021-03-25

Post score: 1

$\endgroup$

1 Answer 1

0
$\begingroup$

Rosanswers logo

Based on the log you provided , the connection with robot is ok. The problem is here: The starting point of the planned path is not the same position of the robot. Check the planner starting point. And before using the actual robot run rsi again with sim:=true to use the simulation robot for testing. Be carefull when you test sth on this huge robot. Any simple collision could really harm. Check first in simulation the in real robot. Everything that works in simulation will directly work on your real robot with rsi

ERROR] [1616688815.523732239]:
Invalid Trajectory: start point deviates from current robot state more than 0.01
joint 'joint_a2': expected: 0, current: -1.5708
[ INFO] [1616688815.523869808]: Execution completed: ABORTED
[ INFO] [1616688815.531926595]: ABORTED: Solution found but controller failed during execution

Thanks, @Mahmoud for helping with this issue!!


Originally posted by Ranjit Kathiriya with karma: 1622 on 2021-03-30

This answer was ACCEPTED on the original site

Post score: 1

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.