Kuka KR10 axis 6 low speed jitter problem

    Hi


    I have found a problem with my KR10 1420. (With KRC4 compact controller. Software 8.5.5)


    I am using the robot for moving a camera. Often I am seeing small bumps in the movement when axis 6 starts moving or changes direction. There appears to some backlash but I have noticed something else strange, and I wonder if this is normal?


    Please refer to the attached video. I am jogging axes 5 and 6 with the HMI buttons in T1, one at a time, at minimum speed of 1%. The outer pulley is axis 5 and the inner pulley is axis 6.


    Axis 5 jogs smoothly while axis 6 does not. It moves instead in small steps. It appears as though it has a lower resolution than the other axes. (All the other axes are also smooth without this stepping effect.)


    Once I jog a little faster then A6 runs more smoothly, but the starts are still a bit ragged... this is a problem when filming with a camera as it is quite visible in the recorded image.


    So - is this standard behaviour for Kuka robots? Or is there perhaps some setting that might effect this?


    Thanks Gerald


    Axis6_Jitter.mp4

    Edited 3 times, last by geraldft ().

    look like a mechanical problem, perhaps from a serious collision or incorrect belt tension. you can try to remove belt and move the axis my hand instead of servo. it should be very smooth and effortless. if you feel it sticky or binding at some places you just confirmed that it is a mechanical issue. you can also run trace tool and check the graphs or send them to KUKA for analysis.

    1) read pinned topic: READ FIRST...

    2) if you have an issue with robot, post question in the correct forum section... do NOT contact me directly

    3) read 1 and 2

    Thank you. I hadn't considered a mechanical issue, I just assumed it was a software setting or something to do with the resolver maybe.


    So I take it this is not normal behaviour? It also makes a clicking noise - at times quite regular, like a clock, even when it's not moving.


    It seems unlikely there has been any serious collision. As far as I know the robot had not had anything attached to it prior to when I started testing. Other axes are all very good. It had very low hours when I received it, only used for setting up. The ticking sound has always been there, and I'm assuming might be connected with the uneven motion.


    Re Trace - any particular values I should be recording?


    The belts both feel to have the same tension. Is there any guide for removing belts? I guess I will need to mark the pulley positions accurately first. There is no belt tensioner so I'm guessing I have to loosen the bolts on the plate next to the left hand pulleys? Or will I need to remove the bolts securing the right hand pulley?


    Thanks


    Edited 4 times, last by geraldft: Clearer explanation and added picture... ().

    sorry, did not mean to be alarmist. just tried to mention possibilities. it looks like first video has stationary camera and robot arm is perfectly still, yet there seem to be a quite noticeable change in reflection from the side of belt pulley at the middle of the video. reflection on casting does not change. this may be worth investigating... perhaps also at higher speed, and recording with audio too.


    btw. checking belt tension requires frequency meter. ones KUKA uses are very pricey and if you don't already have one, or don't know how to setup wrist don't do this or at least don't make it first thing to test unless you are already planning to get KUKA tech to check it out. tension need to be set very precisely. this is delicate as frequency need to be within 1% of reference. one cannot tell the difference by feeling the tension by hand.


    clicking sound could be brake if robot is trying to maintain position or reverses direction. there should be no clicking while axis is moving.


    another option to rule out software is to try base project or another image or connect robot to another controller.

    1) read pinned topic: READ FIRST...

    2) if you have an issue with robot, post question in the correct forum section... do NOT contact me directly

    3) read 1 and 2

    Hi thanks again


    The reflection is just a trick of the light due to the machined surface of the pulley. The arm was not moving at all. Also - that pulley is A5 which is working ok, shown for comparison. As for alarmed - I'm already alarmed anyway... :smiling_face:


    I managed to remove the belts - no need to loosen them, i just levered them off carefully, since RH pulley has no flange. I would say both pulleys felt similar when I turned them by hand. They are firm even a bit tight, with the kind of resistance you expect from heavy bearings with oil seals. There is no backlash in either axis at this output stage. It's hard to tell but A6 might be a bit tighter than A5. But nothing uneven in the mechanics is felt.


    Below is a trace looking at velocity during the slow jogging. Red is A6 and Purple is A5. Kind of refects what we can see in the video...


    Any other traces that would be worth looking at?


    I'll also try another run and listen for the clicking to see if I can correlate it with the brake... I just have to brush up on my German to work these things out...


    Edited once, last by geraldft ().

    Hi again.


    Well I ran a trace with nothing being jogged, but when A6 was making the Tick Tock sound. It is definitely not the brake as that showed nothing in the trace.


    Here is the Axis Velocity trace which shows the regular clicking. Note that the output of A6 is not moving at all and the belt is not moving, so this appears to be just the motor moving back and forth and clicking the gears in the process... but why?


    That does seem very odd. What are the units on the vertical axis of that trace? Is that the position or velocity? Real or commanded?


    The "forward" and "back" pulses seem to come in pairs, about 20ms apart, and the pairs happen every 1sec or so. I'm guessing that the pulses inside a pair are actually 12ms or 24ms apart, due to the 12ms interpolation cycle.


    Just for shiggles, could you monitor $INPOSITION while this clicking is happening, and see if the sixth bit flips when the click happens? And check $IN_POS_MA[6]?


    If you hold the deadman and leave the robot stationary long enough for the brakes to come on, does the clicking keep happening?


    My knee-jerk reaction to seeing that trace is that there's something creating noise in the position feedback for A6, but the consistent back-and-forth doesn't really match that. OTOH, the fact that it seems to happen both stationary and in motion makes it hard to blame this on something mechanical.


    It almost looks like the axis slowly drifts in the direction of its last motion until the position control issues a small correction, and the axis keeps ping-ponging inside the position tolerance window. But I can't think of anything obvious that would cause that behavior without also generating system errors.


    Hm... if you mount something to A6 that puts weight on one side --say, a weight that pulls the axis consistently in the clockwise direction-- does the clicking keep happening? I'm basically wondering if putting a load on the axis would get it to stop ping-ponging.


    After looking at that trace again, it seems like the first pulse of each pair is in the negative direction. This suggests that there's something consistent going on -- like a slow drift one way, that hits a limit, overcorrects, and then corrects again, then lather, rinse repeat.


    I dunno... this is the point where I would normally start swapping motors and KSDs around, to see which component the error follows, but I don't think that's as simple with the small robots or compact controller.

    Hi Thanks for the input.


    During this test the camera was not mounted. Typically I have been using a light camera of about 2kg. It makes little or no difference though whether it is fitted or not. Mainly the camera is mounted under the end of the arm with axis 5 tilted down 90 degrees. Axis 6 is used for slewing the camera so it has no gravitational load.


    I have tried manually loading it and found that can stop the ticking. But equally can jogging the axis a small amount. Loading it would never be a solution because its orientation can change quite a lot during a move..


    If the deadman is held long enough, eventually the brake comes on and it stops ticking. However when operated in RSI mode it stays constantly live, so the ticking can last much longer.


    The period between the clicks is 1.08 seconds. I'm not sure if that is significant...?


    It would be nice to be able to swap parts, but yes it does look like it would be very difficult. The wrist would need dis-assembly to get to the motors... and may be not possible without special tools.


    Below is a more detailed graph showing the Actual Position. The red line is command position.


    I wonder if the comment about it slowly drifting then correcting, might lead to some explanation? It looks that when not ping ponging it is certainly drifting.


    When I trace axis 5 I can see it makes much faster and smaller corrections constantly. So I wonder if there is some servo setting that defines error response, which is off by a decimal point or two?


    Or here's another theory. Since it looks like it is trying to bring itself into position, then after a period of .9 secs it suddenly makes too big an effort and overshoots. So the initial correction gain is not strong enough, perhaps due to the stiffness of the gears it is trying to move? While both driven pulleys felt similar when turned by hand - it wasn't a scientific measurement...


    This same effect is seen during the very low speed test, its like there just isn't enough c torque being applied...


    Edited 2 times, last by geraldft ().

    FYI - Here's what the mechanism looks like inside... I learned that to replace the belts you are meant to loosen the bolts holding the output flanges. Tension should be set to 205Hz with frequency meter. If I can find one that doesn't cost too much I might check. But I kind of doubt that would fix my problem...



    Honestly, I would send the video, and the trace files, to KUKA tech support and ask their opinion. This behavior hints at something fundamentally wrong in the servo or the amplifier, but not seriously wrong enough to trip any actual error conditions.


    108ms is exactly 9 interpolation cycles. I'm not sure what that signifies.


    You could try looking at $IN_POS_MA, and compare the value for A6 against the others. I'm not sure that variable could cause what you're seeing, but it can't hurt to check it out.

    Hi Skyfire...


    I was afraid that might have to be the case. :frowning_face:


    I can't find anything obviously out of place in the machine.dat file.


    I've been using the trace preset "Drive Test" but not sure how to identify the In Position Bit? (Google translate doesn't always make it clear...)

    Hi I'm sorry but I can't see how to set that. In the HMI I just have a lot of preset options and some ability to customise them, but nothing that looks like that. I have used a Preset "Drive Test" and below is my best guess at something that might be what you are referring to, which can be selected from the recording in WorkVisual. As you see, it displays categories in German, but nothing that explicitly seems to translate as "In Position".


    this variable is read only and tells you when the axis is in position....


    to specify window size for this, assign values to $IN_POS_MA[1..12]. this is found in your KRC:\R1\MADA\$MACHINE.DAT

    1) read pinned topic: READ FIRST...

    2) if you have an issue with robot, post question in the correct forum section... do NOT contact me directly

    3) read 1 and 2

    This issue has now been largely resolved... Nothing to do with being IN_POSITION, rather it turned out to be fixed by tweaking servo gain settings for the motor. Mainly. "VelGain". This compensates for the fact that the motor is a little underpowered and sometimes the output gears are a bit stiffer than normal - ie. factory variation - then you can get this problem.


    The gain settings were found in xml files in ROBOTER\Config\User\Common\Mada\NGAxis


    I did go to Kuka in the end. They were very slow but did eventually provide a test program which I used to adjust the settings. (very carefully)


    So on the bright side nothing expensive needed to be replaced... :smiling_face:


    Interestingly their main comment was that the robot was not really designed for low speeds.


    Perhaps they might include that information in their brochures? :thinking_face::pouting_face:

    My impression is that it does not cause issues for most industrial applications, or is just not noticed. Using robots for moving cameras is actually more critical in some aspects. That may explain the lack of other reports?


    BTW it is not completely resolved - just a slight improvement unfortunately... :frowning_face:

    New update m-the saga never ends, After ongoing lengthy consultation with Kuka they advise to replace the motor assembly. The cost would be USD $4,300 including fitting. Not exactly trivial for me.


    So I have taken a punt and removed the side cover to investigate deeper. What I have found is that the motor has some backlash on the output pulley which drives the belt. I compared it with the A5 motor which is identical. That motor has no backlash.


    So at this point I am tempted to believe the backlash could be the main problem. Disappointing for an as new robot. Perhaps it was assembled on a Monday?


    The output pulley is driven by a small bevel gear so it should be possible to adjust the shimming to reduce the backlash. I have worked with Ducati motorcycle engines in the past, and they have the same type of bevel gear for operating the cam shaft.


    So fingers crossed - I may be able to save myself a lot of expense...

    that is recent robot and basic warranty is 12 months. if the robot is still under warranty, why not let KUKA come and repair it? will cost you nothing.

    1) read pinned topic: READ FIRST...

    2) if you have an issue with robot, post question in the correct forum section... do NOT contact me directly

    3) read 1 and 2

Advertising from our partners