automatically Redundancy usage

    Hi.


    I'm using a LBR iiwa 7 which owns a redundancy axis J3.
    My question is if it is possible that the IK (inverse kinematic) takes this redundant axis in account?
    If not I would like to know how to deal with it programmatically.


    Status quo:
    At the moment only the joints J1, J2 and J4 - J7 are used from the IK. J3 remains unaffected. This causes a "Software Axis Limit Violation" for quite a lot frames which I expected should be easy to reach because other surrounding frames are no problem at all.
    By inspecting the current joint positions for this problematic frame I see that at least one joint hits its axis limit.
    The thing is if I adjust J3 manually (which obviously implicates that other joint positions are changing as well) I can find easily an angle for J3 so that all joints are far enough from theirs limits. And of course now the desired frame gets reachable when the program continues.


    In summary I am looking for a way to enable the automatically usage of the redundancy or at least make this adjustment programmatically.
    Any suggestions? :help:

    Im not sure I understand your question. By IK do you mean the method robot.getInverseKinematicFromFrame(frame)? If you want to include the redundancy then you have to set it yourself or use a taught frame as taught frame always contain redundancy angle.


    If you want to get the IK from a frame with a non-null redundancy angle then use the method robot.getInverseKinematicFromFrameAndRedundancy(frame).


    If you want to know more about the kinematic redundancy of the iiwa robots then check the systems integrator manual, it covers this concept fairly well.

    Hi NullReference.


    Thanks for the fast reply. I'm not meaning the method robot.getInverseKinematicFromFrame[AndRedundancy](frame).
    What I mean are BasicMotions* (like ptp, linRel, ...) in general. So if I call e.g.

    Code
    robot.move(ptp(frame))


    the IK will only calculate values for the joints J1, J2 and J4 - J7 but not for J3. The redundancy joint J3 will just stay unchanged, which means the position will be the same as it was before.


    Sometimes this leads to a "Software Axis Limit Violation", which is absolute reasonable for me because one of the joints J1, J2 or J4 - J7 hits its axis limits (see status quo example above).
    Immediately after the "Software Axis Limit Violation" occurs I take a look at the smartPad/smartHMI. I manually play around (i.e. changing) only the position for J3 (while leaving all other joints as they are) so that the joint which caused the problem is not anymore close to its limit. By doing so the initial unreachable frame becomes reachable and I can continue the program without any problems.


    In the end this means the iiwa is capable to move to this specific frame with the use of the redundancy joint J3.
    My question is why the iiwa is not using this joint J3 by default and how to enable "robot.move(ptp(frame))" to take also the joint J3 in account.


    Hope I could clarify my intention.


    *com.kuka.roboticsAPI.motionModel.BasicMotions

    Edited once, last by tammoj ().

    Hi NullReference again.


    I forgot to answer your advise:

    Quote

    If you want to know more about the kinematic redundancy of the iiwa robots then check the systems integrator manual, it covers this concept fairly well.


    If you mean with "systems integrator manual" the "KUKA Sunrise.OS and KUKA Sunrise.Workbench" manual* I did read the section over redundany more than twice. It only explains Status, Turn and Singularities but not how to handle the usage of the redundancy (joint J3) others than taught frames (which I'm not interested in).
    The only hint that the iiwa will not take the redundancy in account for programmatically calculated frames is written at page 320:

    Quote


    The following applies for all motions:


      • The redundancy angle of the end frame is taken into account when the robot that was used when teaching the frame also executes the motion command. In particular, the robot name defined in the station configuration must match the device specified in the frame properties.

      • If the robot do not match or if calculated frames are used, the redundancy angle given at the start of motion by the axis configuration is retained.


    But does this mean the IK will never use the jonit J3 for its calculations and there is no way to use the redundancy programmatically? If I understand the lines above right, the IK knows the current positions of J3 to calculate all other positions (J1, J2 and J4 - J7) but will not calculate any positions for J3 and there will never make use of the redundancy itself.
    This can't be true than otherwise it would depend on the previous position of J3 if the iiwa could reach a frame or not.


    So I'm still hoping for an answer for my initial question.



    *http://www.oir.caltech.edu/twi…A_SunriseOS_111_SI_en.pdf

    Hello,
    I have never encountered this problem. As far as I know, the robot manages to go from one point to another, using all the axes of J1 to J7.
    On the other hand, I encountered such errors when I made "LIN" movements, but in "PTP" the robot is able to rejoin any already pre-learned point.


    Do you use any special parameters for your movements?

    Now I understand your problem.


    Yes, when moving to frames with no redundancy data the calculated IK will just copy the exact same redundancy angle of the current position. Really stupid that it doesn't solve for the closest reachable redundancy.


    I believe you can set the redundancy of a given frame with the method Frame.SetRedundancyInformation(robot, IRedundancyColelction).


    I have not yet had the need to use calculated frames in my programs yet. When the need arises I think im going to create helper class for calculating frames with redundancy. Perhaps something that performs a simple transformation and returns a new frame with the same redundancy angle of the current robot position (or the redundancy angle of another frame) if the robot can assume that particular configuration, otherwise the closest redundancy angle is calculated.

    I do not have a robot at home and no time to test it at work, but probably this could help.
    If the calculatedFrame cannot be reached with the current E1, catch the CommandInvalidExecption which should be thrown if a Frame of JointPosition cannot be reached, afaik. If the exception is caught, change E1 and try to approach this position again. Repeat as often until you reached the desired position.
    I have no clue if this is working ... give it a try.

    I just found this method LBR.getAlphaInverseKinematicFromReference(frame, correspondingJoints, alphaAngle).


    By the short description in the java doc it appears to accomplish what you are looking for. Not sure what the alpha angle is though.

    Quote from tammoj


    In the end this means the iiwa is capable to move to this specific frame with the use of the redundancy joint J3.
    My question is why the iiwa is not using this joint J3 by default and how to enable "robot.move(ptp(frame))" to take also the joint J3 in account.


    Hi Tammo,
    well actually the answer to your question is on page 88 of the manual:


    "The lightweight robot has 7 axes, making it kinematically redundant. This means that theoretically, it can move to every point in the work envelope with an infinite number of axis configurations."


    It would therefore be quite problematic if the robot began deciding how to get there on its own, hence redundancy. However it seems some of the ideas here could be attempted to resolve the issue.


    Best,
    Chris

    Edited once, last by workfive ().

Advertising from our partners