RobotStudio event

Singularity

Options

Does a singularity error only occur if the axis 5 angle wil go trough 0° during a  lineair movement? Or is the error already generated when the angle is almost 0° (f.i. 1°)?

I have problem with converting a program from IRB6400 2.8m to an IRB6640 2.8m, Ther program of the IRB6400 is running live, and now also on robotstudio.
The converted program of the IRB6640 is only on robotstudio.Where I don't have any singularity errors in the IRB6400, I do have singularity on the IRB6640.
The points and paths I follow are exactly the same for both systems.
I already tried with a IRB6640 3.2m, but also singularity errors.
What if I am not allowed to change something mechanically to avoid the singularity errros? Is there a way to go to my programmed positions without the singularity errror? Is moveabsolutejoint an option? Is singularity handled different in old IRB6400 then in the new IRB6640?
How is this problem 'normally solved'?

 

Comments

  • Henrik Berlin
    Options
    The robot motion is definitely affected also close to the singularity. My guess is that the difference in behavior is related to the new motion interpolator that was introduced a couple of years ago.

    Try using the RAPID instruction "SingArea \Wrist;" to allow the robot to deviate from the programmed path in order to pass through the singularity. You can read about the instruction in the RAPID Reference manual that is available in RobotStudio.
    Henrik Berlin
    ABB
  • Simotion
    Options
    I tried using the instruction SingArea\Wrist, and I could reach the position without singularity error, but the problem now is that during passing the singularity point axis 4 and 6 rotate quick while the tool is stationary.
    Any ideas how to avoid this?
  • Henrik Berlin
    Options
    I suppose you could use MoveAbsJ when passing through the singularity as long as you are moving freely between two points.

    I think you should be able to configure the robot to use the old "decbuf" interpolator, which I assume is used by your 6600. I don't know straight away the exact configuration parameters that need to be modified though, but perhaps someone else knows...
    Henrik Berlin
    ABB
  • Simotion
    Options

    Hendrik,

    do you have more information concerning te use of te 'old' interpolator on IRB6640?
    It would be a great help, because I have to use the same mechanical setup.

    When using moveabsj axes 4 and 6 also rotate while the tool stays stationnary, so that won't be a solution.

     

    Thanks

  • Simotion
    Options

    The tests I am doing is with virtual controller.
    I should suppose the virtual controller behaves exactly the same as real controller.
    Can someone confirm that if you succeed to pass through the singularity point with a real controller, that axes 4 and 6 rotate while the tool is stationarry?

    Thanks

  • Henrik Berlin
    Options

    The configuration parameter -dyn_ipol_type in MOC.CFG defines the motion interpolator: 1 = QuickMove / TrueMove 2nd generation ("spline" interpolator) , 0 = old interpolator ("decbuf"), see below 

    MOTION_PLANNER:

          -name "motion_planner_1" -std_servo_queue_time 0.193536\
          -dyn_ipol_decbuf_type "OPTIMAL_PATH" -use_motion_sup "rob1"\
          -use_jog_parameters "motion_planner_1" -use_for_synchronization \
          -use_for_jogging  -repos_installed  -dyn_ipol_type 1\
          -use_spline_parameters "motion_planner_1" -restricted_circlepoint

    You need to change this in the MOC.CFG file itself. It cannot be modified in the Configuration Editor of RobotStudio. Save the motion parameters to a file, modify the parameter, and reload the file. You can try it out in RobotStudio and see if you get a different behavior.

    Note that I don't recommend running the old interpolator with your 6640 on the real robot without first checking with your local ABB Robotics Service representative.

    Henrik Berlin
    ABB
  • Simotion
    Options

    When I change the parameter , I load it to the controller, I do a warmrestart, afterwards I save the parameter again, then it is automatically back at its original value,
    so the system does not seem to accept the old interpolator, I guess.

  • Henrik Berlin
    Options

    I have verified it, I were unaware of this behavior. Then I am not a motion expert. Obviously, the old interpolator is blocked. I recommend you to check with your local ABB Robotics Service representative if the old interpolator can be used in some other way.

    Henrik Berlin
    ABB
  • pion3k
    Options
    I'd like to refresh the topic concerning a problem with a wrist singularity that occures in my program.

    Through a network socket I control a position and orientation of my robot's TCP (IRB120). I cannot avoid the singularity problem when I try to move the robotic arm to the initial position (with the joints' values equal to 0 degrees). First of all I define the robtarget variable: Target_xyz with the same TCP position as the initial one, with the orientation calculated through the OrientZYX function (Euler angles: 0, 90, 0) and with the confdata set to [0 0 0 0]. The problem happens because of the singularity problem since the wrist wants to be positioned in the line. Actually, I don't know why the program cannot calculate the inverse kinematic if, according to the RobotStudioHELP, "When wrist singularity is used, robot axis 4 will be set to 0 degrees."

    jtar := CalcJointT (Target_xyz, tool\WObj:=wobj0);  

    Probably the problem appears in the above part of the code. Is there any way to calculate the jointtarget variable thanks to the robtarget variable in case of the initial position (with the joints' values equal to 0 degrees)?

    Marek