how to skip KRL and send command to motors directly

one tool you already have: RSI, just check the documentation to find out how to do it.

you can generate paths offline and then run this through KRL. this is not real time but you can still do analysis and easily generate new data set.

but if you want to do a true real time path control, there is no way around RSI.

$VEL and $ACC tell the robot what the programmer wants the robot to do. But the robot does what is achievable.

If the robot is given a motion command, it applies a hierarchy of priority to each part of that motion. While the exact hierarchy is only KUKA knows, but from personal experience, it goes something like this:

1. Position
2. Path (for a LIN or CIRC motion)
3. Velocity
4. Acceleration

The robot will do its best to reach the programmed endpoint, if at all possible. And will follow the interpolated path, if the motion command is interpolated. It will do its best to achieve the commanded velocity and acceleration, but if the combination of distance, pose, payload, and inertia (just to name a few) exceed any of the robot's inherent limits, the motion will be de-rated to whatever limit is the lowest. The dynamic motion modelling for all of this is extremely complex, and confidential on KUKA's part.

Motion commands from within RSI deliberately bypass many (but not all!) of these preventative features. If RSI issues a motion command to an axis that is 2x the maximum RPM of the servo, the robot will execute that motion... until the overspeed of the axis trips a fatal error and brings the robot to a halt. RSI also makes it possible to exceed the 250mm/s safe speed limit in T1 mode, which makes extra safety precautions vital when testing with RSI.

RSI does not allow you to exceed the robot's physical limits. It does allow you to hit those limits more violently, which can, over repeated strikes, damage the robot. A KRL program ordered to accelerate faster than the current payload allows will simply reduce its acceleration to what the robot can handle. Issuing an equivalent command in RSI will simply force the robot to attempt the motion until one of the axes suffers an amperage or torque limit fault.

RSI connects your real-time motion command into the robot's motion control at a much deeper level than KRL. But it doesn't bypass all of the path/motion planning engine. $FILTER is the most obvious example -- $FILTER smoothing is applied to the motion plan after the RSI command, and for good reason. Tampering with $FILTER is a good way to damage the robot' drive train quickly.

Quote from ArthurWong

I believe this is the limitation of KRL since robot controller generate its own trajectory and KRL cannot override this trajectory.

KRL is made for people making the robot programming easier for the required task and not for researchers.

Quote from MOM

KRL is made for people making the robot programming easier for the required task and not for researchers.

Yeah, the FRI interface on the iiWA is the one that was made for research purposes. Of course, the iiWA is very much a researcher's robot, too. (with a $$$ to match!)

RSI... is made for production, like KRL, but to provide actual realtime access to the motion control. Which means that a well-written RSI program can achieve some of the things that can be done with the iiWA/FRI.

RSI is Robot Sensor Interface, and that name means exactly what it says. The intent of RSI is to allow one to pass data directly from a sensor, through a PID algorithm directly into the Cartesian or Axis motion control, updated every 12ms. But since that "sensor" could be anything, including data generated from, say, a remote kinematic model, RSI can be "abused" to do things it wasn't really built for.

Quote from ArthurWong

Recently we purchased a kuka KR6-R900 robot, with KRC4 compact and KSS 8.6.6. We would like to conduct research of online trajectory generation based on this robot, which means we want to control each joint displacement, velocity and acceleration in real time.

there are a few ways:

have you checked simulink?

developing a base system application, like RSI or OccuBot without any help from kuka

you will not be able to handle any if your ideas

Maybe a slight addition:

KUKA also has a not so well known interface called External Motion Interface (EMI). EMI basically allows recording cartesian or axis specific trajectories in a table style form which you could adapt offline to fit different trajectories. EMI usually is not a standalone product but is used under the hood of a few other products (re.g. ready2animate, WV ASCII) to be able to record, modify and replay user modified trajectories. I know of at least one case where KUKA gave EMI to a university that tried to test their own novel trajectory planning algorithms on a standard KUKA by generating files for the EMI module.

Also EMI has a few advantages over other solutions. For example it keeps the KUKA safety net intact. You would still get torque monitoring messages if you try to destroy your robot by to offensive commanding. So basically it is not as easy to destroy your robot compared to RSI.

Still to get EMI (even though the EMI module is part of every robot installation (mdrEMILY.o) but not documented) you would still need to talk to KUKA.

How to run ready2_animate emily file? - KUKA Robot Forum - Robotforum - Support and discussion community for industrial robots and cobots (robot-forum.com)

Fubini

Quote from ArthurWong

Thank you so much SkyeFire, for your detailed response. We don't plan to bypass all of the trajectroy engine, but we would like to change the command sent to PID controller. That is something possible right?

Well, it depends on how we're defining those terms.

In KRL, once a motion command begins execution, it cannot be altered. It can be interrupted and stopped, but not changed.

RSI can apply changes to a currently-executing KRL motion, or can essentially take complete control of the motion.

RSI is inherently "stateless" -- a CORR object in RSI evaluates its inputs every 12ms, and orders the robot to move by that amount before the next 12ms cycle, without regard to what the previous cycle did. The larger the correction, the faster the robot tries to go and the harder it accelerates (until a "hard" limit is exceeded).

So your RSI program, or the external system sending correction data to RSI, has to implement a PID for the robot. RSI includes various PID objects to enable this, but the price for getting this level of control is that the RSI programmer has to take charge of handling all the things that a KRL motion command would normally handle by default.

So, in RSI, to rotate an axis at 60deg/sec, one would send an AXISCORR object an input of 0.72 for that axis (0.72deg every 12ms = 60deg/sec). But simply driving the input of the AXISCORR object from 0 to 0.72 between two IPO cycles would generate an immediate acceleration fault. So the input to the AXISCORR would need to shaped by a PID algorithm, and probably include some degree of low-pass filtering (RSI also includes Filter objects of varying complexity).

Real-world example: I once had a ballscrew-driven clamp, powered by an external axis on a KRC. The clamp had a load cell inline, and the process was to have the clamp quickly apply a particular force, without overshoot.

I built an RSI program that, when triggered by my KRL program, would receive the desired clamping force from the KRL program, take control of the clamp servo, and begin driving it. But since the startup of the RSI program looked like a sharp "step" in the force setpoint (anti-restart windup, basically), I had to put a slight low-pass filter on the setpoint input in RSI.

The setpoint and the realtime feedback from the load cell fed a simple subtraction to generate an error, and that error drove a PD object (I didn't really need the Integral) whose output drove the AXISCORR object. But since the load cell would show essentially zero until it made contact (followed by a very sharp spike), I had to apply some low-pass filtering to the load cell signal, and apply limits to the PD output before reaching the AXISCORR object, to set a maximum speed for the servo until contact was made.

Tuning the PD and the limits was a matter of adding an RSIMONITOR object to stream realtime data to a file, plotting that data, and tweaking iteratively. I will say, RSI is a good education in "hands on" PID tuning.

Doesn't RSI have the ability to update every 4ms?

Quote from colinb83

Doesn't RSI have the ability to update every 4ms?

IPO_FAST mode is (or was, the last time I was doing RSI programming) limited to a specific subset of what RSI in general can do. I don't recall the specifics, just that, after a brief look at the IPO_FAST constraints, I ignored it in favor of the regular 12ms IPO cycle. I never needed IPO_FAST for anything, and so never really dug into it.