Will Q1, Q2, Q3 & Q4 not adding up to 1 send robot to wrong position?

    I have software that outputs rapid code that I program offline, Some of the lines of code it gives me sends the robot to he wrong position, some send it to the correct position I am trying to work out the cause of the problem so the software developers can fix the issue.


    In the lines of code that sends the robot to the wrong place, Q1, Q2, Q3 & Q4 add up to between 1.3 and 1.6. Would this cause the robot to go to the wrong position? As far as i am aware these should add up to 1


    In the lines of code that does work Q1, Q2, Q3 & Q4 add up to near enough 1 (eg 0.99998998)


    My robot is an ABB IRB6400R with s4c controller.

    Quaternions must be normalized, there is a function to do such. But, it is the sum of the square roots which should add up to 1, or very close. How far off do you mean when you say wrong position? A few millimeters or much more? It could also be the axis configurations that make it seem a bit off. You could try inverting some of them to see if it gets closer.

    Quote from Lemster68

    Quaternions must be normalized, there is a function to do such. But, it is the sum of the square roots which should add up to 1, or very close. How far off do you mean when you say wrong position? A few millimeters or much more? It could also be the axis configurations that make it seem a bit off. You could try inverting some of them to see if it gets closer

    Some of the points are off about 40 or 50mm. However the orientation is correct just the actual position of tool tip is about 40mm/50mm away from where it should be. When I have my tool alinged vertical in my software the robot goes to the correct place just seems when i try to go to a point with any other orientation the robot goes to the wrong place.


    My first point is with the tool in the vertical orientation and it goes to correct place and my second point is about 30mm over in the x direction only with the tool at an angle and the tool just stays where it is but changes to the correct orientation. iv checked the code and it does tell the robot to move 30mm in the x direction but it doesnt do this. Thats why im starting to think it may be to do with the quaternions. or else maybe something else in the robot may be causing this?

    In a robtarget your POS (XYZ) tells the robot where in space it should go.

    Your ORIENT (quaternions) tells it which orientation your tool should have when it gets there

    Your CONF tells the robot which configuration your joints/axis should have at that position



    Your POS can fail because the robot is incorrectly calibrated, booted as the incorrect robot type, etc.

    Easiest way to check it is to simply take a tape measure and measure from point A to point B (ideally over as long of a distance as possible) and if the robots distance is the same as reality, then that's good so far.

    Even if your orient is incorrect, the robot should still move 1000mm when you tell it to move 1000mm (without reorienting the tool between points).


    Your ORIENT can fail because your TCP is bad/poor or the robot is incorrectly calibrated, re-orient your TCP around a fixed point in space, if it doesn't drift terribly (less than a mill or two - your program wont be any more accurate than what you see here)


    Your conf cant really fail, except that you can fail to do it right. :winking_face:

    A lot of people disregard this and when they cant figure out why they're getting joint re-orientation errors they just add ConfL\Off and all your problems are solved.:thumbs_up:
    Weeeeell... it's not quite that easy... forcing the robot to go to a position with the wrong configuration definitely will affect accuracy. I've personally seen a difference of ~5mm simply by switching the conf values for J4/5 around. Not sure how bad yours is but it's work taking a look at.

    Granted if you're only moving 30mm I'd assume that both positions have the same conf values so that shouldn't affect it if that's the case, but if one is your reference point and the other is the calculated one then I guess it could be done that way if the programmer didn't take it into account.

    from what i can tell my orient is correct its just when i try to get the robot to move in the x direction when the tcp is not aligned with the z axis it does not move the correct distance. However when the tcp is aligned with the z axis it does move the correct distance.


    Iv checked my rev counters and they line up and checked the calibration offset and they match the sticker on the robot arm. as my software creates its own tcp data I will try do a re-orientate around one point useing that tcp to see if it drifts any.


    At this stage i think its a problem with my robot.

Advertising from our partners