EKI - PTP commands executing too slow

    Hello folks again,


    after setting and getting to know EKI a little bit, i'm having some follow up questions and problems.


    Code
    Robots:

KR C               V8.3.38
EthernetKRL        2.2.9
R1Mada             8.3.371

    Problem description:

    The code found below, should start an EKI server, which listens on port 54601.

    After successfull connection the server should execute PTP motions with an advance run of 5 as the data packets come in (as soon as possible).


    The tests with this code were executed while beeing in T1 mode.


    What works:

    Connecting to the server from a PC application. Also sending data packets to the robot and receiving its status with a frequency of 50 hz.


    What doesnt work:

    The robot does receive and also execute its joint space trajectory, and i can see the the EKI buffer variable filling up, but with a severe delay.


    The PC program evaluates the UDP messages with the same frequency as it is sending new packets to the robot. Since the robots message contains the current EKI buffer lenght, im cheking for overflow. The problem is, this variable updates only after several seconds. This results in over 100 packets beeing sent to the robot, before getting an update.


    Even if i ignore the problem above. The execution of PTP motions and the frequency of in which i can see the buffer beeing emptied is closer to 2-5hz. Therefore the behavior is as follows, assuming a trajectory of >100 data points.


    1. PC Program streams >100 joint space poses to the robot and waits for their execution, since only after 2 to 3 seconds the EKI buffer variable is beeing set and the program can stop streaming.

    2. PC waits until the EKI buffer has less than 5 elements.

    3. In this time the robot does "something", while i can see on the PC program that the buffer is beeing emptied slowly.

    4. After a while the robot moves a part of the streamed trajectory.

    5. The cycle repeats.


    I've checked the timer and i would assume it is working correctly since im getting data to the PC, although i dont know how to measure the frequency of timers.

    I've also checked the "package monitor", which doesnt indicate any problems: the execution time of EKI is substantially less than 1ms.


    So the question is: What's happening here? And to some lesser degree, why is EKI behaving as slow as it does?


    Below is the full code, comments removed not to exceed the character limit.

    Code
    &ACCESS RVO
defdat kuka_eki_hw_interface
   ext bas(bas_command  :in,real  :in )
enddat

    Edited 4 times, last by Ravnicas ().

  • Ravnicas

    Changed the title of the thread from “EKI working through buffer too slow” to “EKI - PTP commands executing too slow”.

    just my thought!


    If you want to have a fast motion response, RSI would be a better option compared to EKI, especially you execute the motion first then get the coordinate from the external devices.


    Not so sure about your application but you can try to send the entire position set first(store them in an array) then execute the motion planning later in a FOR loop. It might help you in this situation.


    Br

    EKI is slow - that is the way it is.

    if you need real time performance use RSI.


    btw you are using same interpreter to stream data and run motions. not sure what your data set is - how dense (close to each other) data points are and what is the rate that those points should be processed at. maybe this can work well if data set is not dense.

    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

    I've never tried using EKI this way, but I have worked on a KUKAbot that used EKI in the SPS to maintain constant background communications with a vision system, exchanging a 128-byte datagram every 250ms without any issues or delays that I ever noticed.


    So what you're trying to do can work, but only if you make each motion large enough that the robot's motion time is greater than the entire communications update period (plus some generous buffer, b/c TCP/IP is prone to packet delays). As others have said, if you want realtime control, you need RSI.


    Just off the cuff, to accomplish what I think you're trying to accomplish, I would consider moving the communications and buffer loading to the SPS, and reduce the main program to something like:

    The SPS would need to fill the array up to a nArrayIndexMax (sized to whatever you DECL the E6POS or E6AXIS array to be), and then start over at 1.


    I would let the SPS handle the communications timing, without interrupts. Assuming a reliable 250ms update rate, and a TCP speed of 2m/s, each move in the buffer would need to be at least 8mm apart for the comm loop to keep ahead of the motion. Of course, you would probably want something more like 20mm.-

    I dont need hard real time, and also would prefer not to use RSI if possible.

    Im trying to use ROS in conjunction with EKI, to have a software based controller which lets me follow a trajectory. If i send the entire position set i wont be able to change execution speed, e.g. slowing the robot down if it needs to be.

    Quote from panic mode

    EKI is slow - that is the way it is.

    if you need real time performance use RSI.


    btw you are using same interpreter to stream data and run motions. not sure what your data set is - how dense (close to each other) data points are and what is the rate that those points should be processed at. maybe this can work well if data set is not dense.

    Im not sure i get this right. EKI is slow, maybe, i dont know that, but which part is actually slow?
    It doesnt seem to have any problems transfering the data i want at 50Hz. Thats OK with me.

    I assumed the ADVANCE directive in conjunction with PTP command would allow a blend of each new point, until the trajectory is finished?

    How much is "dense"? At the moment each data point should be approximately sampled at 10Hz, so about 100ms between joint configurations.

    Quote from SkyeFire

    So what you're trying to do can work, but only if you make each motion large enough that the robot's motion time is greater than the entire communications update period (plus some generous buffer, b/c TCP/IP is prone to packet delays). As others have said, if you want realtime control, you need RSI.

    That is more or less the problem i dont quite understand.
    I am already filling up EKIs buffer, so there are enough data points for the robot to execute.

    I also can see the current joint values and the state of EKIs buffer. And i cant see the robot doing any smooth motions. It moves very slowly at the beginning, then executes a part of the streamed trajectory at a reasonable speed, then repeats the slow part.
    And also all of this while i see the buffer beeing emptied very slowly, about 2 to 3 packets per second.


    Even if EKI is slower than RSI and i lose real time control, which part of this limits the performance?

    To be precise, i would like to have precise slow and arbitraraly controllable motions. Slow means in my case about 5 to 10 percent of the maximal possible velocity of my robots (kr120).

    there are still things that are unclear.


    what is the data density - in space and in time domain? without this nobody else can reproduce what you are seeing.


    how does the number of buffered data points changes during execution?


    what metrics are you using to monitor connection and processing? i see no performance counters.


    there is no position arrays, received data stream buffering is handled entirely in EKI read buffer. what happens to buffer when connection is lost? does this happen and how often?


    all streaming is taking place in robot interpreter using interrupts that are firing at high rates . if there are one or two interrupts every 10ms and interpolation cycle is 12ms, what guarantees are there that there is enough resources to do anything else - besides EKI data transfer?


    if the data points are dense (~1mm apart, not 100+ mm apart) and the advance run pointer is at 5, then maximum path length that can be calculated is some 5mm. at such distances robot is going to move very slowly regardless how high acceleration and velocity are set - even if there is no added burden of some 200 interrupts per second. you can try to run test without EKI. just store all data locally in an array and and compare results.

    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

    I'll be blunt -- the level of control you appear to be trying to achieve is better suited to RSI.


    EKI isn't slow, normally, for a single data transaction. But it's not reliably realtime, where RSI is. EKI is vulnerable to delays, dropped packets, and just being a low-priority task on either the server or client ends. EKI simply isn't built to stream reliable realtime control data -- to use a very loose analogy, if EKI is TCP/IP, RSI is UDP.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account
Sign up for a new account in our community. It's easy!
Register a new account
Sign in
Already have an account? Sign in here.
Sign in Now