Accessing media flange IO in KUKA LWR IIWA 7 R800 through FRI

    Hello,


    I am controlling a KUKA LBR 7 R800 through Fast Robot Interface (FRI) C++ client running on a remote real-time OS machine. I can overlay position/torques commands using FRI, but cannot figure out if it's possible to access media flange IOs through FRI or a C++ application that can talk to Sunrise controller in real time. I contacted KUKA tech support, and they say it's not possible to access media flange IOs through the standard FRI SDK provided by KUKA.
    However, I was wondering if it's possible to write a simple JAVA client that runs on Sunrise controller and can send/receive messages from a C++ server application over UDP (basically exactly same principle as FRI communication) and calls corresponding JAVA setters/getters to access media flange IOs. I wrote a JAVA client application as a roboticsApplication and downloaded it on the controller. I was able to send packets from this JAVA client and receive them on a C++ server running on the real-time machine, however the packets seemed to be coming from 192.168.0.1 (the windows virtual network adaptor IP on Sunrise controller) and not the real time OS IP (VxWorks, 192.170.10.2) as they do when receiving packets during FRI overlay. So, when the C++ server tries to reply back to the JAVA client, the packets don't go through since packets addressed back to the sender (192.168.0.1) don't reach the JAVA client, which I presume is running on VxWorks side with IP 192.170.10.2. I also tried manually changing the return IP to 192.170.10.2 but still was not able to receive the packets in my JAVA client. I am connecting the Sunrise controller and the real-time OS machine directly using a cross-over ethernet cable and KONI port.


    Long story short, my question is: Is there a workaround to access the media flange IO through FRI client? The workaround I described above is allowing me to do one-way communication from Sunrise controller to FRI client (so I can read the IO channels, but not set them). I welcome any suggestions that will allow my workaround to do two-way communication.


    Thanks in advance, and apologies for the long post!


    -Vinay

    Hi Vinay,


    I don't know exactly how to use the FRI client for C++, but I do know that through Sunrise Workbench directly, there is access to the robot I/O in WorkVisual. If you have a work space set up in Sunrise, then I would recommend using that program, and right-clicking on the SunriseProjekt folder to create a new I/O WorkVisual file for the robot. Sorry I don't know how FRI works, but if you have access to Sunrise Workbench there should be a way to remotely access an I/O in a different program after you instantiate it initially in Workbench. Please let me know if this helps!


    -Alex

    College student currently in undergraduate program in Biomedical Engineering and Computer Science working internship with a KUKA LBR iiwa R800 7kg Robot.  I'm still learning the basics, but I hope to master the techniques necessary to operate and understand this robot during my time in University!

    Thanks for the reply Alex! I can access the media flange I/Os through JAVA applications that are deployed from Sunrise Workbench with no issues (in fact they come preconfigured, no need for configuring them in WorkVisual before hand like you need to do with EtherCAT I/O modules for ex.). However, these JAVA applications run on the Sunrise controller, and I want to access those I/Os from a remote real-time OS machine that talks to the Sunrise controller.


    -Vinay

    I have an idea, but not sure if it works:


    - Create a logical variable in the RoboticsAPI.data.xml in Sunrise Workbunch
    - Link this variable to a media Flange I/O using WorkVisual (If it's not already done automatically)
    - Create a background Task (On Sunrise Workbunch) that listens to UDP packets coming for your C++ program (on a different port maybe), and updates the value of this variable according to what's receiving.

    Hi Kiiwa,


    That was my thinking too, and was the first thing I tried :). As I mentioned in my original post, I am not able to receive UDP packets in the background task (or JAVA application for that matter) from the C++ program. I can send UDP packets from background task to the C++ program, but the packets arriving do not seem to be coming from correct IP (the IP of real time ethernet card in Sunrise cabinet is set to 192.170.10.2, but the packets seem to be coming from 192.168.0.1).
    I bet there is something special about configuring the local IP address on the Sunrise cabinet which allows FRI communication over UDP through KONI port because those packets come from 192.170.10.2 as expected. I made sure that I am using a different port that is not being used FRI and is in the valid range.


    -Vinay

    Similar problem. The robot cannot receive messages from a c++ client no matter how I configure the UDP socket. Still looking for solutions.

    Quote from vc


    That was my thinking too, and was the first thing I tried :). As I mentioned in my original post, I am not able to receive UDP packets in the background task (or JAVA application for that matter) from the C++ program.


    I used C++ and C# programs that send/receive UDP packets to/from the Java programs running on the robot ( For the background task I use it to send, didn't need to receive), before, and I didn't use the KONI Ethernet port, but the X66 KLI.


    If you can do it with any standard java application, it will work on the robot.

    Thanks, I will try it out over KLI. The C++ server works fine with a standard java udp client, so my hopes were that it will work as is when I integrate it in a robot application. Hopefully, with KLI port the packets sent by the java application will have correct IP where the server can respond to.

    Just tried it with KLI ethernet port, worked without a hitch! So, now I am having to use two ethernet ports on my linux machine - now which talks to KONI for FRI communication and other which talks to KLI for accessing the media flange I/Os.

    I guess so.
    At work I have a Windows 7 Machine with two Network Cards, and when I need to work on many robots, I use a switch or Router, but the network interfaces should be in the same subNetwork ( I'm nor sure if you can do it for the KONI and KLI).

    IP addresses of KLI and KONI must be in different subnets as per KUKA FRI 1.5 documentation, otherwise the external system and robot controller cannot communicate with each other. I am using a switch to connect to KLI port, so that I can access it from both my linux and windows machines. For KONI port, I am using a cross over ethernet cable for direct point-to-point connection with the linux machine to make sure I have hard real-time performance for FRI (I am doing 1ms updates).
    Only drawback of this setup is media flange I/Os are being accessed through KLI port, which means update rate would be > 2ms and it's not real-time capable. So, if you are trying to do a closed loop hard-real time control using those I/Os, then probably won't work for high update rates. For my application, I only need to toggle some digital outputs on the media flange so it works.

    Dear Vinay,
    would you please let me know how to connect remote computer to kuka computer with cross cable. do we have to set any special ip setting.
    now i am accessing through straight cable with around 11 ms latency in ubuntu (Not realtime)
    btw, about the media flange, it was great information..sharing with us.
    Regards

Advertising from our partners