If what you're wanting to do is pass in any valid pose and have the robot move to that pose automatically, you can't do that with RSI. The only way to control a robot using the RSI interface is with correction updates. However, you could design a simple controller around the RSI correction updates you pass in to achieve your goal.
Posts by gtrobot
-
-
I know that this should be simple, but can someone tell me the process / procedure for doing a cold boot on a KRC4? Thanks!
-
Perhaps this is a dumb question, but what transformation do I apply? As far as I can tell, RSI update (and jogging for that matter) change orientation with respect to the the base frame (updates in A, B, C change orientation w.r.t. base frame Z, Y, X respectively - which, as you say, is not the orientation the robot reports.) I can get the rotation matrix using asimo's 'magical mystery matrix'. But I'm still unclear on how to get a desired {A,B,C} orientation in Euler angles by changing the angles w.r.t. the base frame axes. Any help would be greatly appreciated!
-
I have what could be (hopefully) an easy question.
I am trying to control a KR210 robot with a KRC2 using path corrections in RSI 2.0. Linear corrections work fine, but orientation corrections do not work as I would hope. Sending corrections in each individual direction (A, B, C) seems to move the end effector orientation with respect to the base frame, but this is not the orientation reported in the position monitor (or what is also sent to the remote PC.) I currently give corrections based on the orientation reported by the robot, but this doesn't work (for example, if the robot reports that the C component is 5 degrees away from the desired pose, and I send a correction in C of 5 degrees, it will not get to the correct orientation - all three components will change.) Am I doing something wrong?
So, the question is this: how do I figure out what correction to send to through RSI that will get the orientation I actually want?
Thanks for the help.
-
Thanks for the help. It looks like changing the machine data fixed the problem!
-
To be perfectly honest, I can't tell if there is an extension on the arm or if it looks like it is supposed to. If I had to guess I would say it looks as manufactured, with no modifications.
I replaced the robot MADA data in R1.
The warnings of 'Wrong machine data for this robot type' and 'Data of RDC and Hard Disk inconsistent. Check robot data!' come up. However, jogging the robot seems to give much better performance. I cannot detect any undesired motion on initial testing.
Are these warnings something I should worry about? Is there a way to update the RDC data? I know the RDC board on this robot (not the other) is brand new, replaced a few weeks ago by KUKA tech.
Thanks!
-
How do I go about reloading the machine data?
I'm comparing the model from the robot vs. the KRC:
On the robot, I see
$TRAFONAME[]=''# KR2210 S C2 FLR ZH210''
.../MADA \KRC2\KR2210_SSCBC\FLOORWhile the KRC shows, under Robot Data
#KR2210 L180_2 S C2 FLR ZH210''Does this look correct?
Thank you
-
Unfortunately, there are no archives on either of the controllers. Any thoughts?
-
Hi, I'm wondering if anyone has seen this kind of behaviour before.
I have two KR-210 robots connected to KRC2 controllers. We recently (two weeks ago) had a KUKA tech come out and update the KSS software and install RSI. While he was here, the tech also mastered both robots.
What's curious is that when I try to jog the robots in cartesian mode (world frame) there is unexpected motion at the tool tip. For example, if I drive it say a meter in y, there is a noticeable rotation that is also performed at the tool tip, although the KCP monitor reports no change (this can be as much as 20 or 30 degrees.) The drift seems to be consistent, in that it happens every time, and at different places in the workspace.
On a possibly related (?) note, there is also curious behaviour when controlling the robot through corrections from a remote PC. Joint corrections work fine (exactly as expected.) Cartesian corrections work just as reliably in linear. In angular, however, there is strange behaviour. Corrections in A result in the correct A value, but some very small motions/disturbances in B,C. Corrections to B or C result in motion in A,B, and C, and the given update position is not reached for B or C. Again, it is consistent - the same corrections will give the same (wrong) positions in A,B,C.
Has anyone seen anything like this? Any ideas or thoughts on what could be causing it? Any help would be greatly appreciated.
Thank you!
-
So I'm curious if there are any common issues controlling a KUKA robot with EthernetRSIXML. I've set up the robot to run from an external PC, and whenever I send a single correction to the KRC (AKorr or RKorr) it does what I expect it to do (the robot moves to the desired position.) However, when I send a series of corrections (a pre-computed trajectory divided into 12ms steps) the robot moves toward the desired position, but never gets there. Now I can wrap a controller around the output to make the robot get to where it's supposed to, but why will it not finish the trajectory in the first place? Any thoughts? Thanks,