Movements with time arguments

[jflorez]

Hi:

I am doing an application in which I need to move a KR6 with KRC2 controller from one point to another through a linear path but I need it to move in a certain amount of time.  I would like to tell the robot that moves between the points in certain amount of time without using a speed argument (because it should calculate it automatically).  Is there any way to do this.

Thanks in advance for any help someone can provide me.

Jorge

[Tiago_Tre]

Hi!

You can create a calculation that converts it (roughly without consider the accelerations and decelerations, or more accurately considering all this). Knowing the distance between the points and time you want to make the move it is easy to calculate the speed (which you can vary using a Variable).


Regards!

[gianne]

Hi,
as Tiago said, you should do calculations on the base of the lenght of the path and time necessary to do this; but if the question for you, is to move linearly the robot from a starting point for a certain amount of time, you can create a second point far away, then you begin the motion to this point and after the amount of thime you need, the robot skip to another instruction.

gianne.

[SkyeFire]

To be completely honest, I don't know of any direct, simple way to do what you're asking.  This would be a good question to kick over to KUKA tech support, and I'd be interested in hearing the answer.

Is the move joint or linear?

Do you have to maintain a constant speed, or just arrive at the endpoint at a certain time?

As has been stated, for a linear motion you can probably make a rough calculation of the move time in advance.  A rougher calculation of a PTP move is possible, but much harder, taking into account the max velocity settings of all axes, and using kinematic functions to find the the total travel of each axis, recalling that the robot will match its overall speed to the slowest axis.

If your main need is to control arrival time, what I've done in the past is to control $OV_PRO from inside the SPS, monitoring the distance to the motion endpoint ($DISTANCE or $DIST_NEXT) and tweaking $OV_PRO on the fly to  control arrival.  It's a bit of a hack, but it could work.

[jflorez]

Hi guys:

Thank you very much for your great answers.  In fact, as SkyeFire said, I would rather prefer a direct and simple way to do it.  I am not an expert in Kuka robot programming but I have had a wide experience programming ABB robots and doing this in ABB is quite simple because there is a direct instruction in which you can use speed or time as an argument of the movement instruction.  I am going to try all the ways you (SkyeFire, gianne, Tiago_Tre) told me and if I find a direct way to do it I let you know.

Bye,

Jorge   

[jflorez]

 :backtotopic:Hi Guys:

I'm back.  I send the question to KUKA Tech Support and to be honest I am very dissapointed.  The answer is that there a not a direct way to do this and that doing that as SkyeFire suggested may not be very satisfactory if the application needs precision because there is a delay in the robot answer when changing the $OV_PRO.

According to the answer it seems to be something that has been improved in new versions of the controller software and it can be done by using SPLINES and a lot of programming.

It is incredible that being KUKA one of the most important robot brands in Europe, does not have a solution for something as simple.

However, I am going to test all of your suggestions in my robot and I am going to design my own experiments to find out if Tech Support were right.

Thanks guys.

Jorge

[SkyeFire]

Actually, in my experience that time-based motion is pretty rare -- I've never seen it used in my entire career, and the only robots I can think of that I've ever seen it available on was Nachi.  I've never seen it on an ABB, but I'll take your word that it's there. 

Controlling $OV_PRO from the SPS can be a bit rough, but you can conquer this to a large extent if your algorithm is smart enough.  Ideally, you would track your time remaining against your distance remaining the whole way and perform a lot of small corrections the whole trip, rather than a few large ones.  Of course, this would work better for a long slow move than a short fast one.  A bit of PD control might help as well.

I'll admit, I'm curious.  If you can say, just what is your application that requires a purely time-based move?  Maybe we  could help you brainstorm a better solution.

[jflorez]

Hi SkyeFire:

Continuing with our topic, let me tell you that my major experience with robots has been with KUKA and ABB (especially this brand) so I thought this functionality was the facto in robotics.  Time-based motion in ABB is as simple as including an optional argument in every move instruction.  All of the move instructions have the argument \T and you just have to put a number in seconds that means the time required to perform the movment.  Let me give you an example:

MoveL p1, v2000,fine \T:=30;

When using the optional argument T, the system calculates the speed to take the TCP to p5 in 30 seconds and replace the argument V2000 by the corresponding calculated value.  Every variant of movements instructions has the T argument.  Don't you think it is very clean and easy? I don't know why KUKA is so complicated in some topics.  Take into consideration that I have done this in S4C+ controllers.  I don't know if it works in older versions.

Satisfying your curiosity (something that I appreciate very much) my application is a robot used to download pieces in a ceramic casting machine.  After the casting process is finished, the machine sets a signal that enables the robot to perform its job and besides it sends a timer by PROFIBUS.  This timer is used by the robot to move to the download position.  In this way the robot reaches the position at the same moment that the machine is ready to deliver the piece without losing time.  As you can see this can be done in many ways.  When you have several machines that peform the same job at your factory you want uniformity but in this case we are using a new machine with a KUKA robot.  I know now that in this case it is better to change a little this part of the process.

Thanks,

Jorge

[jirikk]

Hi, its very easy to calculate if you know the distance (anyway this you can measure). it is a simple quadratic equation.

T=time to go [sec]
X=distance to end point [meters]
a=acceleration [meters / sec^2]

There is a physical limit... the SQR(T) MUST BE greater then (4*X/a), otherwise there is not enough time to get to the end point with specified acceleration, so check this one first. IF this is OK

then speed  [m/s] = (T -  SQRT( SQR(T) - 4*X/a )) *( a/2 )


Also check that the solution if v < v(max) set for your robot.
J.

[SkyeFire]

Except that it's not that simple, since Acceleration is not a known value, nor even a fixed one, as each axis has its own acceleration limits that change with inertial torque over the motion envelope.  For a given tool and a limited set of motion arcs, it could be determined empirically, especially if the motion command is well clear of any of the system limits for acceleration, velocity, inertia, etc.  But in most general cases, it's very unlikely to be as simple as you imply, other than as a rough first-order approximation.

[jirikk]

Thats right, for PTP movements you dont know the acceleration (even the speed).
But in case of CP movements, i thing $ACC.CP  is the value you can use, because its the accel. of "tool centre point" and if some axis is over its torque limit (desired acceleration couldnot be reached), you should see torque err message.

[gianne]

Hi,

if some axis is over its torque, you don't have an error message, simply the robot doesn't reach desired acceleration and the movement last longer than what you calculated with your formula; same considerations for speed.
Conclusion: you should know before if the robot can reach $acc.cp and $vel.cp you calculated, and that's the hard question.

gianne.