Decrease Kuka iiwa FRI loop rate

    I couldn't find the details on this, hence the new thread.


    I'm using a Kuka iiwa LBR 7, (torque) controlling it from ROS on Ubuntu (non RTOS) through the KONI interface with FRI. Sometimes we lose connection (POOR, etc..) and then recovers.

    If we increase network load or CPU load on the Ubuntu machine, the rate of the problem increases. We expect this is jitter on the connection between Ubuntu and FRI.

    I'm not sure which rate the Kuka expects, but it might be the maximum of 1000Hz.


    - How can I confirm which rate the Kuka is currently expecting

    - How can I change this setting?


    I haven't been on the Sunrise much, so please regard me as a total newbie.

    are you sure you network setup is correct? are you sure you are on a isolated LAN and not using WiFi? WiFi adds latency. did you confirm actual timing with WireShark?

    1) read pinned topic: READ FIRST...

    2) if you have an issue with robot, post question in the correct forum section... do NOT contact me directly

    3) read 1 and 2

    Quote from panic mode

    are you sure you network setup is correct? are you sure you are on a isolated LAN and not using WiFi? WiFi adds latency. did you confirm actual timing with WireShark?

    Thanks for the quick response. We're using a wired connection, no WiFi.

    Do I measure with wireshark on the Sunrise or is it a RTT I might measure on the Ubuntu machine (thus haven't confirmed actual timing yet).


    Any easy way to determine what the sunrise expects regarding rate?

    I'm more familiar with RSI than FRI, but I believe both run on very strict timing. So even without knowing what rate Sunrise wants, it should be possible to detect anomalies -- when the bus is running well, packets should exchange every X ms, with very little change in X. It changes to X, especially sudden, significant changes, that you want to look for. WireShark also timestamps its captures, so you can use the time stamp of the robot error to filter the WD capture down to a range near that timestamp.


    Wireshark can run easily on Ubuntu. You'll want to read the Wireshark directions on how to set up capture filters (IP and Port), otherwise it'll try to capture every bit of network traffic and generate a lot of irrelevant extra data in your capture.

    Quote from SkyeFire

    I'm more familiar with RSI than FRI, but I believe both run on very strict timing. So even without knowing what rate Sunrise wants, it should be possible to detect anomalies -- when the bus is running well, packets should exchange every X ms, with very little change in X. It changes to X, especially sudden, significant changes, that you want to look for. WireShark also timestamps its captures, so you can use the time stamp of the robot error to filter the WD capture down to a range near that timestamp.


    Wireshark can run easily on Ubuntu. You'll want to read the Wireshark directions on how to set up capture filters (IP and Port), otherwise it'll try to capture every bit of network traffic and generate a lot of irrelevant extra data in your capture.

    Thanks! I'll give it a go asap and report back, also for future reference.

    Quote from M-i-botics

    - How can I confirm which rate the Kuka is currently expecting

    - How can I change this setting?

    Hello, you might want to check out on

    FRIconfiguration class - must be initialized somewhere by the iiwa_stack (I guess?)

    and its methods like .setReceiveMultiplier() , .setSendPeriodMilliSec() - you need to check both and their explanation

    Quote from Seulki

    Hello, you might want to check out on

    FRIconfiguration class - must be initialized somewhere by the iiwa_stack (I guess?)

    and its methods like .setReceiveMultiplier() , .setSendPeriodMilliSec() - you need to check both and their explanation

    Thanks! We've currently avoided the issue by running a dedicated machine to control the arm, nothing else that can hog resources. This appears to work, however it isn't a long-term solution.

    Due to the decreased impact we have not found time and priority to do measurements or modifications on the sunrise https://github.com/IFL-CAMP/iiwa_stack) itself (I assume you mean code on the sunrise, in our calling code (fork of ) I didn't find the class or methods you mention)


    Will check when we'll hook up the sunrise to a monitor etc..

    Quote from M-i-botics

    Due to the decreased impact we have not found time and priority to do measurements or modifications on the sunrise https://github.com/IFL-CAMP/iiwa_stack) itself (I assume you mean code on the sunrise, in our calling code (fork of ) I didn't find the class or methods you mention)

    If you're sure iiwa_stack is running with FRI, then it has to be there since it's the first thing needed to create FRIsession. (Below is the applicationExample shown when activating FRI software option on stationSetup.cat)

    Code
    // configure and start FRI session
        FRIConfiguration friConfiguration = FRIConfiguration.createRemoteConfiguration(_lbr, _clientName);
        friConfiguration.setSendPeriodMilliSec(5);

        getLogger().info("Creating FRI connection to " + friConfiguration.getHostName());
        getLogger().info("SendPeriod: " + friConfiguration.getSendPeriodMilliSec() + "ms |"
                + " ReceiveMultiplier: " + friConfiguration.getReceiveMultiplier());

        FRISession friSession = new FRISession(friConfiguration);
        FRIJointOverlay jointOverlay = new FRIJointOverlay(friSession);


    - I have no background on ROS so my statement below probably be wrong.

    I briefly look on the source code on iiwa_stack.

    I could see it's using Servoing(smartServo) on it's SunriseApplication "ROSBaseApplication", but neither I found lines related to FRI.

    If it's using FRI, the application running on SunriseOS need to contain FRI stuff to be as FRIServer while the external devices communicating with Sunrise has to be FRIClient. If there's none of structures programmed as below, it's not using FRI.


    And if it's using Servoing, I guess you need to take a look at periods of timers or your own "controlLoop()"

Advertising from our partners