Need instruction: How ROS connect to Kuka robot KR6 / KR16 etc with KRC4?

[yaozr]

We are running automation project selecting KR6 and we wish to use ROS package to save our R&D time.

Great job you have done! Its however frustrating to find any useful info on web about how PC could really get connect to a ie. Kr6 R900 KRC4 controller or the similar Kuka robot, the thing I have tried including doing KUKAHardwareManager.exe -assign OptionNIC -os WIN (fine), disabling StartKRC from startup(fine), connect my PC to KONI Ethernet Port (fine), setup bothside IP and ping each other(fine), but roslaunch anything fail to respond.It says on web that Ethernet/IP is shipped with KRC4? I guess this would be a common issue for new commer, is there any simple instruction exist? Many thanks for tips...

Is it so that for any KRC4 robot by using kuka_rsi_hw_interface we can skip all the changing NIC mess above and simply use the smartpad and controller as it is, just install those programs will help build up the tcp/ip channel?

How nice if someone could add a few lines for this HW interface usage in the first place Readme, such as how to start this driver from smartpad and how to run a actural ros sesstion step by step... Many thanks in advance.

[gavanderhoorn]

The kuka_rsi_hw_interface package is nothing special: it makes use of a (properly configured) RSI interface on the controller. You could/should refer to the KUKA documentation on the Robot Sensor Interface for that.

On the ROS side there isn't really that much to configure, apart from getting the ros_control bits setup correctly. After that you get a FollowJointTrajectory action server, which you can use as any other instance of such an Action interface.

I agree the current documentation is a bit sparse and assumes you already have a good grasp of the various technologies involved (RSI, ros_control). This is also captured in #27.

@tingelst: could you perhaps expand kuka_rsi_hw_interface/krl/README.md a bit with some more details on getting the controller side & RSI working?

For the ROS side: I've recently created a MoveIt configuration and some convenience launch files for the KR 6 R900 sixx, but haven't merged them in the main repository because they need some testing. See my kr6r900sixx_moveit_rsi_convenience branch for that.

Note that as part of that effort, I tried to abstract the ros_control configuration as much as possible, to the point where it looks -- and almost behaves -- like one of the industrial_robot_client based ROS-Industrial drivers (with robot_streaming_interface.launch files, topic remapping, etc). I would recommend to get up-to-speed with ros_control however and to tailor the configuration of the relevant parts to your situation.

The robot support packages are layed out according to the ROS-Industrial conventions, see Working with ROS-Industrial Robot Support Packages for more info on that. The MoveIt configuration allows for the typical demo.launch for simple testing (no hw involved), moveit_planning_execution.launch for access to the real robot pattern.

[tingelst]

@gavanderhoorn: I will update the README next week.

[gavanderhoorn]

Great, thanks.

We could then probably also point to that to resolve questions like MoveIt and ROS-Industrial: No controller_list specified.

I've not had other reports about it, but it looks like some users are encountering issues with the file naming of the RSI related files under the krl dir.

[tingelst]

Yes, I have also gotten some feedback on that. I will fix those issues as well.

[gavanderhoorn]

Unfortunately it's no longer in a separate branch, but it looks like @pgorczak has done some work on this already (in pgorczak/kuka_experimental@678dc0b2).

[pgorczak]

@gavanderhoorn I can confirm the files from your mentioned commits work however their filenames are too long, creating untraceable errors (it was a hunch of a colleague to make the filenames shorter and lo, it fixed them)

[gavanderhoorn]

@pgorczak: I've created a separate issue to track that. See #47.

[gavanderhoorn]

@tingelst: it's probably nicer to track the enhancement of the documentation in a separate issue. See #49. I'll assign that to you.

We'll keep this issue as a question issue.

[yaozr]

Many thanks for support. The moveit demo under kr6r900sixx_moveit_rsi_convenience also works here, we are struggling executing real robot with RSI interface, so far not successful yet. If we manage it I will try to document every steps for similar users. BR

[gavanderhoorn]

@yaozr: I suspect you are running into #48 or something similar. That could very well be caused by #47, which will most likely be fixed today, after we merge #50.

[gavanderhoorn]

@yaozr: could you try and see whether #50 works for you as well?

[yaozr]

@gavanderhoorn Sorry not successful yet... up untill yesterday... Our team is quite a newbie for both ROS and RSI, indeed we nail down the issue to the fundamental connection failure of RSI interface and was trying to run the testServer.exe shipped with newest RSI package ( we just got from kuka and installed them). Looking up for the information is a headache...We are at the stage of configuring the IPs and click the X+ X- button and try to hear the moving sound from the real robot :( My best guess is as soon as the RSI path get through we will be very close to the goal... and I will update our test then.

[gavanderhoorn]

@yaozr: ok, let us know how/if/when things work out for you. Taking a step back and first getting basic RSI to work is definitely the right approach.

Just make sure to base your tests on #50 when you do start testing the rsi_hw_interface package if the PR hasn't been merged at that time.

[gavanderhoorn]

#50 has been merged, and #54 is intended to address the sparsity of the documentation.

[yaozr]

@gavanderhoorn Many thanks for tips and also thanks @bj0rkedal for the good instruction of HowTo for RSI settting up.
We had strange issue with KR6, so we jump to a KR16 robot, with @bj0rkedal step by step instruction we manage to run Step1:

roslaunch kuka_rsi_hw_interface test_hardware_interface.launch sim:=false

and also successfuly run the real driving test with command to run Step2, Oops!

$ rosrun rqt_joint_trajectory_controller rqt_joint_trajectory_controller

But we still did not manage to run your ros moveit planning excuting example, our steps include:

1. run roscore in one terminal

2. run in another terminal command:

   roslaunch kuka_rsi_hw_interface test_hardware_interface.launch sim:=false
   

   and start the app in teach pad until we see got connection response in this terminal

3. open another new terminal and run:

   roslaunch kuka_kr6r900sixx_moveit_config moveit_planning_execution_rsi.launch 
   

we can bring up rviz but the robot seems moving its arm in a fast repeating manner, without any user input. We try to fill in ip,port click connect without anything happen, and in planning part its not working.

Sorry for the basic question, Is there any issue with our steps? why it need to fill in ip /port and do connect? I thought RSI thing dont need to be taken care of at this stage
Seems a bit more closer to success though...

[gavanderhoorn]

We had strange issue with KR6 [..]

it would be nice if you could describe those issues, as that may allow us to either solve them, or at least document them.

and also successfuly run the real driving test with command to run Step2, Oops!

Why the 'Oops'?

But we still did not manage to run your ros moveit planning excuting example, our steps include:

1. run roscore in one terminal

2. run in another terminal command:

   roslaunch kuka_rsi_hw_interface test_hardware_interface.launch sim:=false
   

   and start the app in teach pad until we see got connection response in this terminal

3. open another new terminal and run:

   roslaunch kuka_kr6r900sixx_moveit_config moveit_planning_execution_rsi.launch 
   

No, you don't want to run anything else when you start moveit_planning_execution_rsi.launch. It takes care of starting the driver for you. mpe_rsi.launch is a top-level launch file, and the main entry point. When using this infrastructure, obviously. If you use any of the building blocks we provide, it's fine to start whatever is needed.

What you did starts an instance of a simulated robot and a connection to your real robot. Joint states from those two are going to conflict, which is why you probably saw the robot 'flicker' in place.

We try to fill in ip,port click connect without anything happen, and in planning part its not working.

If you mean you entered ip & port into this:

then that won't work, no. That is for a MoveIt database connection. Notice how it says "Warehouse" above the input fields.

---

I guess I assumed some familiarity with how ROS-Industrial robot support packages & MoveIt configurations and launch files work (have you read Working With Ros-industrial Robot Support Packages?), but for now:

1. have your robot configured as described in steps 1 & 2 of the updated readme. Steps 3 and 4 are good for testing and for custom setups, but is not needed if you use the files from the kr6r900sixx_moveit_rsi_convenience branch (moveit_planning_execution_rsi.launch basically already does for you what test_hardware_interface.launch does, and more)

2. checkout the kr6r900sixx_moveit_rsi_convenience branch on my fork

3. start the ROS side as follows:

   roslaunch kuka_kr6r900sixx_moveit_config moveit_planning_execution_rsi.launch sim:=false robot_ip:=<ip of your controller>
   

As I wrote earlier: without the sim:=false argument, mpe_rsi.launch will start in a simulated mode, which doesn't connect to the real robot. The robot_ip argument is needed to correctly configure the kuka_rsi_hw_interface nodes. If you've also changed the port, you need to add robot_port:=<whatever port you configured> to that roslaunch line.

---

Note that you need to make sure you actually have a KR 6 R900 sixx: the launch and config files are not meant to be used with something else.

You can test your connection with it, and see whether you get joint states back, but all of this is not guaranteed to work. Joint space motions will work (although your EEF will not end up where you want it to), but setting Cartesian pose targets will obviously not (as the kinematics most likely won't correspond).

Note also that the kr6r900sixx_moveit_rsi_convenience branch is currently an 'experiment': I'm trying to determine if this is something users would like to see included in more packages. I would however always recommend to invest some time into understanding what is going on with the ros_control configuration, and to create launch and config files for your specific setup (but see also the comment in kuka_rsi_hw_interface/launch/robot_interface_streaming.launch).

[gavanderhoorn]

We will probably have to document some assumptions about expected experience with KUKA controllers, RSI and ROS(-Industrial) packages and workflows to avoid running into these issues in the future @tingelst, @bj0rkedal.

[yaozr]

@gavanderhoorn Many thanks for detailed instruction! We will try to test as you suggest next week.

-Why the 'Oops'? We were just very excited to see that the mouse click suddenly move the robot acutally :)
-For documenting Kr6 issue... The Kr6 robot has been shipped to another city for demo purpose, we will try to run everything on it after we get it back.

Our final goal is to run ROS moveit with vision guidance on both KR6 and KR16 robots in real project, so we are very encouraged when we see the progress.

Extra documentation about KRC and RSI and ROSI is definitely a great idea for new comer.

Thanks again!

[gavanderhoorn]

@yaozr no problem.

Extra documentation about KRC and RSI and ROSI is definitely a great idea for new comer.

Well, yes and no: industrial robots always come with lots of documentation, and robot vendors have extensive support departments to help their customers out. It doesn't make much sense for us in ROS-Industrial to go and duplicate some of that. I'd rather we refer to vendor documentation wherever possible.

Everything considered, the kuka_rsi_hw_interface is nothing special: it's "just" a typical RSI interfacing piece of software, for which the vendor (KUKA in this case) has plenty of documentation available.

We do need to document all of our assumptions on the ROS side, and definitely include info on how we interact with RSI though.

[yaozr]

@gavanderhoorn BTW we notice Delft teams great performance in APC2016, it says your solution is open source but we did not find it anywhere? Our project is similar and we wish to do it with our Kuka robots.

[gavanderhoorn]

@gavanderhoorn BTW we notice Delft teams great performance in APC2016, it says your solution is open source but we did not find it anywhere? Our project is similar and we wish to do it with our Kuka robots.

This is rather off-topic, but: the press releases state that it will eventually be released. We haven't had time to do that yet. The application wasn't developed 'in the open' initially, and so will have to be released.

[cschindlbeck]

I also am not able to run the real robot with the kr6r900sixx_moveit_rsi_convenience package.
I have a KUKA KR10 R1100 but the joints names etc should be the same, so i dont think this is causing the problem.
After launching the file i don't see
Waiting for robot
However, the
kuka_hardware_interface (kuka_rsi_hw_interface/kuka_hardware_interface_node)
is started according to ROS. I will try to find the error and report back if i found my mistake.

[gavanderhoorn]

@cschindlbeck: please open a new issue for this. And please include the exact command line you use to start things (and in which order).

[yaozr]

We have to put our hand on a KR6R700sixx now due to company project shuffling usage of all robots... anyhow @cschindlbeck 's finding in his closed issue does solve our problem too... Now the moveit actually move the robot !

In planning and executing mode, the robot seems just move the initial path and then start to shaking at one position without moving forward, but that might be due to the R700 robot thing.

Finally it seems this is working now, many thanks for everyone especially @gavanderhoorn kind support !

so I close this question and thanks again.

[gavanderhoorn]

In planning and executing mode, the robot seems just move the initial path and then start to shaking at one position without moving forward, but that might be due to the R700 robot thing.

no, that should not happen, no matter which support package or variant you are using.

I'm not sure we can help you debug that, but if you can report that as a separate issue, we can at least track it.

[happygaoxiao]

@gavanderhoorn Hello, I am new for ROS and KUKA robot. Nice to find many kind people here. My lab has bought a KUKA KR150 with KRC2. I wish to use ROS to build a platform and do some reseach with force control. But I don't know whether KR150 is well supported. I have seen some people said they made it with kr6, kr16, kr120 and iiwa as the KUKA experimental packages include. So, could you tell me if the KUKA KR150 is able to connect ROS? If I should do some change or somethings special to notice? There are some scattered tutorials for connect ROS and KUKA from answers of these issues. I will try to do it these days. Many thanks! (This is my first time to make a comment at the github. Thank you in advance.)

[gavanderhoorn]

@happygaoxiao: please see the readme in the rsi_hw_interface package. That should answer at least the 'howto' part of your question.

As to compatibility with KR C2, see #74.

PS: in the future, could you please either ask these sort of question on ROS Answers, or open a new issue? It's not too nice to hijack an old and closed thread like this.
Thanks.

[CesMak]

Could you update the link? in the above post:

@happygaoxiao: please see the readme**<--(Link not working)**

[gavanderhoorn]

The documentation is linked from the wiki/kuka_rsi_hw_interface page.

[CesMak]

Ah I found it to be here