How to do velocity control using RSI in KUKA KR5 Arc (KRC2) robot
-
ravi.joshi53 -
June 23, 2015 at 11:07 AM -
Thread is marked as Resolved.
-
-
I never used Absolute mode in RSI, and it's certainly not well-described in the documentation. But, my best guess is that Absolute mode treats xCorr inputs as distances to displace from the robot's starting position (at the moment ST_ON was triggered). So, I would suspect that speed control would be the same as when using relative motion -- dependent on the magnitude of the displacement.
Basically, if you give PosCorr an input of 1 in Relative mode, the robot will keep trying to move 1mm every 12ms until the input is removed. If you do the same in Absolute mode, the robot will try to move 1mm from the starting position in 12ms, and then stop. So, in Absolute mode, if you want to move the robot 100mm, just punching 100 into the PosCorr object will probably generate an over-speed fault, but if you ramp the input from 1 to 100 over the course of a second or two, the speed of the input ramp will control the speed of the robot's motion.
But, I'm just guessing. Still, it would fit the general pattern of RSI.
-
SkyeFire,
Thanks a lot for the explanation. I really appreciate it.
Actually, for controlling the position, the relative mode works pretty well. Now, I am controlling the robot orientation using RSI, in which relative mode creates a lot of problems. Since I need to store the previous orientation, then I need to subtract it from new calculated orientation. This way, it gives me the change the orientation, which I should sent to RSI.
While working in absolute mode, there is no such problem. But it is too fast to work.
Quoteif you ramp the input from 1 to 100 over the course of a second or two, the speed of the input ramp will control the speed of the robot's motion.
It seems interesting. But how to do it? Do you have any such program in C/C++/C#/Java ? -
Well, I know how I'd handle it in RSI. C, etc, would require an in-depth knowledge of your system.
In RSI, you could try adding a Filter (PID?) object between your positional input and the PosCorr object. An object rigged to act as a low-pass filter would smooth out the start and end "cliffs" and, if tuned properly, should avoid any "jerk" issues or over-speed problems.
Another approach might be to create a Source object rigged as a Sine or Triangle wave generator (with an amplitude of 1), and multiply your positional correction by the Source output before inputting to the PosCorr. You'd have to cut off the correction before the wave started the downslope, though.