RSI PossCorr ABC

    KRC v8.3.8165

    RSI v3.3.3

    Hi,

    I am trying to send corrections for my A,B,C (X-rot,Y-rot,Z-rot). I sometimes can have these corrections work momentarily. But when it doesnt work, or stops working it sends a RSIBad error. I believe that is configuration error. Im not too sure what would be wrong in my configuration, it almost seem like I am not sending the right data across my UDP for the ABC. My XYZ corrections work perfectly fine and never run into this issue. If i try correct one A or B or C it seems to work, better than 2, and 3 barely works - all while also correcting XYZ. I just set corrections of XYZ to zero, and I was able to correct the A,B, and C all together for the first time for like 10 seconds before getting the RSIBad. Is there a particular parameter/s that I need to look out for when correcting ABC?

    Quote from JM212

    error handle an RSITimout? and how can we avoid singularities or any of the other velocty, torque erros that may occur during PoseCorr

    I don't think there's a way to "handle" an RSI Timeout. RSI is built entirely around hard realtime data -- a packet timeout has to be treated as something only somewhat less dangerous than a safety fault. To look at it from a different perspective: RSI is about as tolerant of packet lag/loss as regular industrial FieldBusses (Ethernet/IP, ProfiNet, EtherCat, etc). In fact, RSI was originally built to run only on FieldBus comms, with the TCP/IP packet comms only added later. It's on reason I actually prefer to run RSI with FieldBus when possible. So when using RSI with TCP/IP, making the TCP/IP connection as robust as ProfiNet/et al, is simply a requirement. Given how dangerous RSI can be, it simply can't give TCP/IP a pass on things that would fault a regular FieldBus.

    Avoiding singularities and torque errors is entirely the responsibility of the RSI programmer. The price you pay for the power that RSI gives you is that you are working "below the safety nets" of the robot that prevent those kinds of things in regular KRL programming. For example, in KRL, if you program a motion for 2000mm/s when that is physically impossible to perform at anything faster than 1000mm/s, the robot will simply do 1000mm/s and keep going without a fault or warning. But in RSI, if you command an impossible speed, the robot will just keep accelerating until it faults out on an axis maximum.

    KRL has a lot of "training wheels" abstraction layers between the programmer and the hardware, which are normally invisible, but do a lot to protect the programmer from themselves. RSI essentially peels away a lot of those layers, giving the programmer much more direct control at the deeper layers, but the tradeoff is that the RSI programmer then must handle the things that those "training wheel" layers do for KRL.

    Quote from SkyeFire

    I don't think there's a way to "handle" an RSI Timeout. RSI is built entirely around hard realtime data -- a packet timeout has to be treated as something only somewhat less dangerous than a safety fault.

    Yeah okay, that makes sense. I guess I just need to make sure I am always sending a packet to the robot. Is it okay to send a packet of no corrections to any of the axes or rotations?

    Quote from SkyeFire

    Avoiding singularities and torque errors is entirely the responsibility of the RSI programmer. The price you pay for the power that RSI gives you is that you are working "below the safety nets" of the robot that prevent those kinds of things in regular KRL programming. For example, in KRL, if you program a motion for 2000mm/s when that is physically impossible to perform at anything faster than 1000mm/s, the robot will simply do 1000mm/s and keep going without a fault or warning. But in RSI, if you command an impossible speed, the robot will just keep accelerating until it faults out on an axis maximum.

    Do you have any pointers or tips on where to begin with this? Like is there a way to send the velocity of each axis back to the PC over the RSI communication? Or will I need to be calculating that from the axes position over time? I have read through the RSI manuals and they don't really suggest anything about dealing with the singularities, and velocity. However, I did find that you can send the gear torque for each axis. So I'm assuming I can use that to somehow manage and avoid the torque errors.

    The trouble is I am trying to have the robot follow an operators hand motions in real-time. So I am running into some issues when the operator moves their hand in a particular way or through a particular point - the robot either approaches a singularity, or the robot wants to crash into itself. The other issue is that at some points when the operators motion of their hand suddenly changes direction, the acceleration is through the roof.

    Quote from JM212

    Yeah okay, that makes sense. I guess I just need to make sure I am always sending a packet to the robot. Is it okay to send a packet of no corrections to any of the axes or rotations?

    Yes, sending 0 values is fine. But the communications exchange has to be kept active until the RSI program is terminated.

    Quote from JM212

    Do you have any pointers or tips on where to begin with this? Like is there a way to send the velocity of each axis back to the PC over the RSI communication?

    Possible, yes. Personally, I would handle this in the RSI program itself, but regardless, the trick is to monitor realtime conditions and add corrections into the POSCORR inputs. For example, the angle of A5 might be monitored, and as it approaches 0, the inputs to the POSCORR get progressively reduced to turn the speed down to a safe level.

    It's also possible to have multiple CORR objects running in parallel, and have them "fight" each other -- their controls add/subtract to each other at the motion layer. So your POSCORR might be driving the hand-following motion, while an AXISCORR might monitor A5 angle, and/or A4&A6 velocities, and "push back" against the POSCORR as the POSCORR tries to push too close to a limit.

    Either way, there will be some non-trivial tuning to be done, but it should be possible.

    So when you say "fight" against each other, do you mean something on the lines of have the hand instruct poscorr no matter what, and then if the axis 5 is close to 0 degrees then also use axiscorr at the same time? I seem to get a gear torque error as soon as it reach that point where the axiscorr kicks in as it is telling the robot to go in the exact opposite direction that the poscorr is going in.

    A "Gear Torque" error suggests you have a high transient spike -- remember, when you run RSI, most of the robot's built in "motion smoothing" functions are bypassed, so it's incumbent on the RSI programmer to ensure that the corrections have gentle ramps. Again, I always recommend putting Monitor taps all over the place in the RSI program to record the realtime data, and look for spikes. Whatever trace is the steepest is something you should pay attention to and try to ramp down a bit.

    Keeping in mind I never did this myself (I was told it could be done by a senior KUKA engineer, before we found we didn't need to resort to that), the outputs of two parallel RSI containers or CORR objects should "add" together, and the combined sum is what's sent to the servo-level control.

    So, the way it was described to me, two POSCORRs running in parallel, one outputting X -1 and the other outputting X +0.1 should drive the robot in X by -0.9.

    Caveat: that was several years ago, with KRC2s -- it's possible that my information is outdated, or that I'm remembering it incorrectly.

    If you want to try that route, I would suggest creating a very simplified RSI program to just test how the POSCORR and AXISCORR interact. Or maybe go back one step further, and create a KRL program that makes a LIN motion through A5 singularity, while running an RSI program that tries to "push" A5 away from 0 as it gets closer. Again, the KRL motions and the RSI motions will "add" to each other. Once you can get a simplified test program to work without faulting, you should be able to take what you've learned there and apply it to your "production" RSI program.

Advertising from our partners