RobotStudio Simulation: Fixed Tool

  • (RS 2022)


    So, I'm trying to set up a simulation with a fixed TCP doing a dispense-type operation on a robot-carried part. And I'm having some weird issues.


    If I activate the Carried WObj and the fixed TCP, and teach a Target with them, I get two very different frame items created, neither of which is anywhere near the TCP or WObj when I used the Teach Target tool.


    If I right-click the Target and use "View Tool At Target," the tool actually goes where I want (but now I can't shut that view off!). But if I use "Jump to Target", with the Fixed Tool and Carried WObj active, the robot doesn't move to the desired position. There must be something fundamental I'm missing here.


    This is with the carried WObj hilighted in the WorkObjects&Targets tree. The actual WObj is the frame at the bottom center of the cube being carried by the robot. The frame highlighted at the top of that "post" on the table is the actual target, at the location of the fixed TCP. That other highlighted frame floating in space below the cube, I have no idea, but it highlights when I select the Carried WObj, along with the other two frames.


    If I click on the Target itself:

    This is strange, b/c the tool moves the wrong TCP (one of the carried TCPs) to the correct position in space. Since that Target was taught with the Fixed TCP and Carried WObj, that suction cup should be above the fixed tool by the size of the cube. And yes, the Target is defined in the Carried WObj, and the WObj is set as RobHold=True. The active TCP is the fixed TCP, and has RobHold set False.


    And if I try jumping the robot to the target, nothing happens -- the robot stays where it's shown in the last screenshot.


    Also, I cannot turn the "View Tool at Target" off. Any target I select, the detached model of the tool just appears at the target. Does anyone know how to shut that off? There's a prompt to turn off the "show robot at Target" option, but I'm not seeing or finding anything for the "show tool at target" option.

  • Stranger and stranger. I created a couple brand-new targets under the Carried WObj. The robot went here:



    Now, when I added one target to a path program, then jogged the robot to the right position and did Modify Target, I was able to get the right position:


    Now, that's a pretty major difference in Cartesian space, but if I go into the RAPID editor and check the raw coordinates of the two targets (Target30 being the target that has the robot reaching under itself, and Target40 being the "correct" position), I get these:


    CONST robtarget Target_30:=[[25.000492355,174.999966855,17.999938302],[0.000000046,0.923879519,0.382683465,0.000000056],[0,-1,0,0],[9E+09,9E+09,9E+09,9E+09,9E+09,9E+09]];

    CONST robtarget Target_40:=[[0,0,-100],[1,0,0,0],[-1,0,-1,0],[9E+09,9E+09,9E+09,9E+09,9E+09,9E+09]];



    Those XYZ differences aren't nearly enough to account for the different positioning in space. The Quaterionns don't make any sense either -- Target30 should be orthongonal to the fixed TCP ( which is antiparallel to World in Z), but when the robot moves there, it's something like 20deg off orthogonal.


    It's as if the targets are rotating around some unknown point in space. If I add both targets to my path program, I see this while the robot is moving towards Target30:


    The triangle formed by the dotted lines is a clue, I think. The top-right corner of the triangle is stationary in space, but the upper-left corner is making an arc as if it were "mounted" to the Carried WObj. When the program reaches Target30, that frame is coincident with the actual fixed TCP.

  • I am now completely lost.


    I modified the position of Target30, using the Set Position menu option, and clicking the frame of the Fixed Tool. Now, both Target 30 and Target40 go to the same physical point in space (the Joint readouts are identical), but even after doing a Synchronize To Rapid with every box checked, their RAPID values are still wildly different:

    Code
    CONST robtarget Target_30:=[[761.388124648,-19.122002551,516.603764679],[0.095845781,0,-0.995396196,0],[-1,-1,-1,0],[9E+09,9E+09,9E+09,9E+09,9E+09,9E+09]];
    CONST robtarget Target_40:=[[0,0,-100],[1,0,0,0],[-1,0,-1,0],[9E+09,9E+09,9E+09,9E+09,9E+09,9E+09]];
    
    MoveJ Target_40,v500,fine,FixedTool\WObj:=PartInGripper;
    MoveJ Target_30,v500,fine,FixedTool\WObj:=PartInGripper;

    As you can see, the program steps I'm executing have the same Tool and WorkObject settings, so that's not the issue either. But if I run the program, or use Execute Move Instruction singly, both targets move the robot to the same physical location.

  • Well, I won't claim I've figured it all out, but I think I've managed to at least make it work.


    The key point is that you're "attaching" Targets to the carried object, and executing that target moves the target to the active fixed TCP. This has some counterintuitive side effects in the Sim environment that don't happen in real life -- like, using the "offset position" tool causes the robot to move in the opposite direction as the Target is moved.


    There's still an "extra" frame that lights up when I highlight the Carried WObj, that I don't understand:


    The upper frame is my actual WObj. I don't know what the lower one is, but it's attached. This screenshot was taken after I turned the Visibility off for every Tool, Target, and WObj except the Carried WObj. Odd, but it doesn't seem to have any negative effects.

  • Well... I figured out the "extra" frame. And boy, is my face :icon_redface:


    It was the OFrame element of the Work Object. I'm not sure how it happened, since I never edited the OFrame, but somehow it got a substantial position and orientation offset.


    This also explains at least some of my RobTarget values. I was trying to understand how, with the Work Object and the Fixed TCP coincident, I was still seeing non-zero values for the robot position. When I hand-built a target with 0,0,0 coordinates and ran the robot to it, the "extra" frame ended up coincident with the Fixed TCP. And that was what told me to check my OFrame values.


    :wallbash:


    Oh, well, it's been a good learning experience. :uglyhammer2:

Advertising from our partners