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
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.
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.
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).