Approximating acceleration profiles for PTP motions

The S-curve you describe is what the robot normally does naturally. We tend to draw it as a simple trapezoid, and the "curves" in the S tend to be pretty short, but the motion planner's PID algorithm is definitely generating an S-curve accel and decel profile.

So, my first question is, what's wrong with the robot's inherent accel/decel profile that you want to improve?

All three of your examples look valid, insofar as they should execute without causing any KRL errors. Your $VEL and $ACC values may be a bit high (depends heavily on robot payload and pose). I think Approach #1 is the best one. Approach #2 is likely to give you issues with the Advance Run Pointer, but Approach #3 would resolve that problem.

What you have to keep in mind is that the KRC has a lot of different motion control algorithms going on constantly that cooperate and compete with each other at all times, and you're now trying to add another layer atop that. For example, if you command the robot to accelerate at a rate it physically can't, it will simply apply the maximum acceleration it can. And the physical limit changes, not only with robot payload, but also robot pose and inertia -- the robot can accel harder under conditions where the servos have to fight gravity less, or from a standing stop compared to doing a sudden reversal.

hang on.. isnt ptp motions only limited by axis speed $VEL_AXIS[] and axis acceleration $ACC_AXIS[]? Atleast that has been my understanding. $VEL or $ACC would do nothing for a ptp motion. But as SkyeFire wondered what is wrong with the original path and motion planner?

btw getting lin and circ motion speeds correctly set up requires first of all $TOOL_DIRECTION to be correctly set up (watch out theres two variables that needs to be set, believe the other is $TOOL_DIRECTION_LIN_CIRC). Then relevant structures $ACC, $VEL AND $APO needs to be set up correctly. Check this forum for "swivel and rotation" to get a good grip on which is which *.ORI1 and *.ORI2. Suitable approximation strategy must also be used as eg. If you are turning around tcp using c_dis will not make for any smooth motion. So that also must be taken care of c_ori, c_vel, c_dis, c_ptp or c_spl.

With that set up correctly and should be fairly easy to get a smooth motion profile.

Quote from Hes

hang on.. isnt ptp motions only limited by axis speed $VEL_AXIS[] and axis acceleration $ACC_AXIS[]? Atleast that has been my understanding. $VEL or $ACC would do nothing for a ptp motion.

...you are absolutely correct. I got hung up enough on seeing all the $VEL and $ACC changes that I overlooked the fact that the motion commands were PTP.

Quote from nicok

What joint acceleration values does the robot realistically use? In the KUKA docs I haven't found any information at all so far and I don't know if the range is something like 250-500 °/s² or more like 5000-10000 °/s² or anything in between. I only need a rough estimate to know the range I am working with.

You can check $ACC_AXIS_MA[] there might be a typo in the variable name but it should point you in the right direction

and if you have oscillation problems easiest way is to stiffen up your tool, decrease acceleration or both. Setting correct loads and inertias are also essential to make motions smooth. There are also parameters for jerk if memory serves (derivative of acceleration). You may want to keep a high speed but decrease acceleration and jerk alot to keep it from oscillating if tool is flimsy. On abb's you get one more parameter so you get vel, acc, jerk and snap. But i've never felt the need for the last one atleast. If your tool is flimsier in some direction you can quite comfortably set $ACC_AXIS[6] to something decently low if it is sloppu around flange z axis. If it is sloppy in both swiveling and rotation, i would suggest setting $ACC.ORI1 and ORI2 to a decent value and keeping critical moves as LINs. Also approximation strategy could be worth checking eg. Diffrence between c_dis and c_vel. Could also be worth checking out newer S type motions. There are some experts on pancake chromodynamics and kuka motion related stuff on this forum. I think Fubini would have valuable input on this and surely others too. But stiffening up your tool and lowering accelerations and setting speeds, approximation etc up perfectly would be my suggestion. Many times you can also orientate the tool in such a way that it does not flap around that much when you do big moves.

Quote from nicok

What joint acceleration values does the robot realistically use? In the KUKA docs I haven't found any information at all so far and I don't know if the range is something like 250-500 °/s² or more like 5000-10000 °/s² or anything in between. I only need a rough estimate to know the range I am working with.

There is no explicit bound for this. Since we are talking PTP moves here the limitations come from the robots dynamic model. The dynamic model restricts gear and motor torques. In this case $ACC_AXIS[] does not limit axis acceleration directly but the torque available to accelerate/decelerate each joint (the maximal values for torques are stored in robcor.dat inside the dyn_dat[] array. But the documentation of the dyn_dat values are a company secret of KUKA and not publicly available). How much torque there is available depends on the robots state (position, velocities, accelerations, loads, ...). Lets assume a motor can generate a torque of 40 Nm. Holding the robot and its current position (assuming for simplification positions, accelerations are zero) requires a motor torque of 27 Nm than a value of 100 in $ACC_AXIS[] means the robot will try to use 13 Nm for acceleration. Basically everything that can be used up to the maximal torque value. But since the robot is a coupled system this might not be the resulting acceleration you will see in the end. Since the calculated trajectories of the robot are time and phase synchronized over all axes it might be that another axis is the actual limiter for the overall torques. In this case all other axes are "slowed" to fit the limiting axes in such a way that all axes start moving and finish moving at the same time (this is an important feature that no matter what the user programs for VEL_AXIS and ACC_AXIS the resulting movement of the TCP in Cartesian space is always the same).

To use accelerations on joint level in rad/s^2 you would need to deactivate the dynamic model. But this is not recommended because it is than a lot easier to destroy your robot and in your use case you would also see even more unwanted oscillations.

If you want full control over how the robot accelerates and decelerates yourself the only option I can think of is using the RSI package.

Another possibility to get closer to commanding direct rad/s^2 values would be to use spline motions in combination with adding additional restrictions by means of $SPL_VEL_RESTR. If I remember correctly you can add joint specific restrictions for axis acceleration in there. In that case $ACC_AXIS is applied as percentage value to both (torque limit and joint acc limits). Joint limit acc then is defined by the $RAISE_TIME[] the time it takes to acc from stand still to maximal velocity for each axis. In KRC2 $RAISE_TIME was directly inside R1/$machine.dat but for KRC4 this changed and the info was moved with tag RampUpTimeUnderLoad into the motor configuration xml-File of the specific axis.

Maximum axis acceleration - General Discussion of Industrial Robots Only - Robotforum - Support and discussion community for industrial robots and cobots (robot-forum.com)

Of course for getting a better performance with less or minimal oscillations the would be other options using available features of the robot controller but as I take that is not what would be a feasible solution justifying a masters thesis.

Last but not least what you also could do is just "measure" the resulting accelertions by using the built-in oscilloscope function (aka trace) inside the KRC. You can record the resulting axis acc by configuring the correct channel you want to record and than plot the result using either WorkVisual or the Tracetool found in any KRC installation in the C:\KRC\UTIL folder. So use $ACC_AXIS just to "scale" the input but what the resulting axis acc you get is only defined after recording the values and looking at the trace plots.

Quote from nicok

The data sheet for the KR150 2700 extra we use states the maximum speed at 150kg is:

A1: 123 °/s, A2: 115 °/s, A3: 120 °/s, A4: 179 °/s, A5: 172 °/s, A6: 219 °/s
Am I correct in assuming that I can safely set $VEL_AXIS[] to any value that is equal or smaller to these?

The value entered for $VEL_AXIS[] is a percentage of the maximal value. So 100 means maximal velocity. The actual maximal value is given by $VEL_AXIS_MA in motor revolutions per minute inside R1/$machine.dat. If you want to calculate maximal axis velocities you need to also consider gear ratios RAT_MOT_AX[] and axis couplings $AXIS_COUP[,] inside the same file.

External Axis (on Rotary Table) - Rotation Speed Control - KUKA Robot Forum - Robotforum - Support and discussion community for industrial robots and cobots (robot-forum.com)

(its basically the same for robot axes).

it appears i made a blunder. For ptp acc and vel is of course max 100% for cartesian motion you have $VEL_MA and $ACC_MA that defines max values.

Quote from nicok

If I only want to use SPTP for the sake of a single PTP motion I shouldn't need to program any additional points in between my start and goal as all the spline supports are computed by the robot controller, is that correct?

That is correct, you can replace a single ptp with a sptp to the same point. I do not know if it holds true but sptp's seem smoother than traditional ptp moves. Im speculating this is because they are bound by diffrent limits

Quote from nicok

The company actually has bought the RSI package for the robot but due to a PLC defect we're using the X11 interface instead and from what I've read without a PLC it is impossible to use the RSI.

Eh? That's not true at all. Plenty of RSI applications just use local sensor I/O.

I've never tried it, but it should be possible to write an RSI app (probably of the "superposed motion" type) that exercises no control over motion, but simply streams data to the RSI Monitor. Which would require exporting the CSV-style log file after the test and running it through Excel or some other tool to generate columnar data that can be plotted, but long ago I wrote an Excel VBA script that did most of that for me with a single hotkey, so I know it's doable.

Quote from nicok

I only found a website plotting this for S-curves based on third order polynomials. It should look similar for fifth order ones but with a stronger shift of the energies towards f=0.

That link was broken -- it connected to the top of this thread. I took the liberty of fixing it, since the label of the link was a valid URL.