Confused Newbie (KUKA iiwa LBR R820 , FRI monitoring problem)

  • Hello everyone,


    I am starting to work on the LBR iiwa R820 and I want to monitor the robot state (obtain position,torques values ... etc) through a client PC (connected to robot controller via KLI).


    To do so used the Java FRI SDK given by Kuka, and used their own example application. The example itself works fine, but when I try to monitor the state, things get messy, and I constantly get the "NullPointerException" error message whenever I try to use LBRState.getMeasuredTorque() method. Which tells me that something needs initialization ? but in the documentation they don't say anything about initialization !


    Maybe I just made a newbie mistake and the solution is obvious, but I'm stuck here for a few days now and I have a deadline closing in :frowning_face: so any help from you would be so much appreciated !


    Here is the part of code that I added to the LBRTorqueSineOverlayApp example application :
    LBRState state = new LBRState();

    double[] MsrTorques = new double[LBRState.NUMBER_OF_JOINTS];
    MsrTorques = state.getMeasuredTorque();
    Logger.getAnonymousLogger().info(Arrays.toString(MsrTorques));



    And this is the error message :


    Exception in thread "main" java.lang.NullPointerException
    at com.kuka.connectivity.fastRobotInterface.clientSDK.clientLBR.LBRState.getMeasuredTorque(LBRState.java:198)
    at connectivity.fri.sdk.example.lbrTorqueSineOverlay.LBRTorqueSineOverlayApp.main(LBRTorqueSineOverlayApp.java:97)



    Thank you for your help,
    Abdel


  • through a client PC (connected to robot controller via KLI).


    You should connect your PC via the KONI port not the KLI.


    And use a different IP and different Network Mask on your PC, the FRI doesn't use the usual "172.31.1.14x" with "255.255.0.0" on KLI, but uses "192.170.10.x" with "255.255.255.0" on KONI.

  • You should connect your PC via the KONI port not the KLI.


    And use a different IP and different Network Mask on your PC, the FRI doesn't use the usual "172.31.1.14x" with "255.255.0.0" on KLI, but uses "192.170.10.x" with "255.255.255.0" on KONI.


    Thank you kiiwa for your fast answer. I have fixed the problem now and I'm getting the data I need. I used a java decompiler and tracked the initialisation of the data and found out that I had to use some client instance that was created previously in the program instead of creating a new one. I wish Kuka put this in the documentaion, it could have saved me hours of reverse engineering :frowning_face:


    Getting back to you comment, the reason I'm using KLI instead of KONI is because when I plug my cable into KONI the network is not stable, it tries to create network but after few seconds it says " cable disconnected". Note that I'm using "Windows". So if you have any idea why that happens , please let me know :smiling_face:


    About the second comment, polling the data is just a first step of my work. The data will be treated on the client and used to send command instructions. What do you mean by conventional ones ?


    Thank you again for your answer :smiling_face:

  • You're welcome :smiling_face:


    Quote

    the data and found out that I had to use some client instance that was created previously


    Was it initialized in the FRI example in sunrise Workbench?



    Quote

    I'm using "Windows". So if you have any idea why that happens , please let me know :smiling_face:


    My PC is on windows10 and it works fine with the C++ example provided by kuka (I receive/send data each 5ms );
    One thing is, you must not use the same subnet mast for both configurations (use 255.255.0.0 for KLI and 255.255.255.0 for KONI) . Which one did you use?


    // ***********

    Quote

    polling the data is just a first step of my work. The data will be treated on the client and used to send command instructions.



    I'm not expert on FRI (hence my questions, to learn more about it), but from what I understood, FRI's main goal is realtime Path superposition (or the Motion Overlay) of the original path, via an external machine running the C++ program (Like using a Camera to avoid obstacles). Sure, you can poll robot's state and whatnot, but if you don't need it for realtime (<12ms usually), it's a bit overkill (And there are other alternatives for soft realtime like SmartServo, DirectServo, etc.), you can use your own UDP/TCP packets to send polled data to your machine (running any code, JAVA, C#, C++, python, etc.) and react on that.



    Quote

    What do you mean by conventional ones ?


    I just didn't understand why do you want to poll the robot state in the robot program using FRI.
    If you need the robot state by the robot itself, you can use directly the conventional Java kuka.roboticsAPIones instructions like:


    Code
    JointPosition position = robot.getCurrentJointPosition(); 
    double[] externalTorques = externalData.getTorqueValues();
    double torqueA2 = measuredData.getSingleTorqueValue(JointEnum.J2);


    And if you want to poll these positions on your C++ client, use the C++ code (here's how you read the jointPositions on C++):


    Code
    double jointPos[LBRState::NUMBER_OF_JOINTS];
    memcpy(jointPos, robotState().getMeasuredJointPosition(), LBRState::NUMBER_OF_JOINTS * sizeof(double));
    for (int i=0; i< LBRState::NUMBER_OF_JOINTS; i++)
     {   
      printf ("jointPos [%d] = %f \n",  i+1, to_degrees(jointPos[i]) );  
      }
  • Hi,


    Dont you need the software "Sunrise.Connectivity FRI" in order to establish a realtime connection with your PC and the controller via FRI/KONI-port?


    Kind Regards

  • Quote


    Dont you need the software "Sunrise.Connectivity FRI" in order to establish a realtime connection with your PC and the controller via FRI/KONI-port?


    Yes, as kiiwa answered for the FRI libraries. Apparently it also works if you connect through KLI and not KONI, though I have some connexion problems. Still didn't figure out if connecting through KLI is causing them or it's just my client program.

  • Quote

    Yes, as kiiwa answered for the FRI libraries. Apparently it also works if you connect through KLI and not KONI, though I have some connexion problems. Still didn't figure out if connecting through KLI is causing them or it's just my client program.


    I wouldn't recommend using the KLI interface for realtime control/communication. It's not a real network card, just a virtual one ( I forgot where I've read this), so imagine the overhead that comes with all the software stack.

Advertising from our partners