KUKA : Part Presentation Vision *Correction*

    Good morning community,

    Where words/descriptions might fail, pictures I'm hoping make up. therefore please find my two examples of the task I need to query and reach out for assistance on:

    Firstly the tech specs:

    KR3 - R540

    KSS 8.6.6

    KRC4 Compact

    Machine Concept:

    The machine is a fixtureless design, where an operator can present a mechanical component that is detected by a STATIC Cognex camera mounted to the roof of the machine. ( each part is taught into the machine so that parts presented position is a mathematical sum from its "Gold-Standard" ). The robot then moves end of arm tooling to the position of this part for indepth evaluation.

    [ Pose to part constant even when part is presented differently ]

    Status Quo:

    ### The Cognex optical axis's ( X/Y ) are orientated and aligned to the exact same direction as the BASE_DATA[1] ###

    ## The Cognex optical axis's ( X/Y ) are calibrated to metric mm units ##

    I'm using simplistic Base switching / Geometric maths to apply the sum / delta from the Cognex ( X / Y ) and the already calibrated base ( Base_Data[1] ) to an available base : BASE_DATA[10].

    BASE_DATA[10] = BASE_DATA[1] : fCognexOffset ; fCognexOffset.X/Y = sum of part position minus "GoldStandard"

    I then apply the Cognex ANGLE math to the end effector TCP.A so that the evaluation pose of the end effector is always consistent regardless of part presentation.

    This all works fine for TOP DOWN inspections where no angle is applied to the inspection and therefore the end effector is parallel to the machine plate that the parts are placed on.

    The above is limiting as if a part inspection requires an angled evaluation angle then applying a TCP.A correction is negated and actually incorrect.

    I have applied the .A delta to the fCognexOffset FRAME, but this then behaves incorrectly too, as the pose of the robot is now presented out of FOV of the part. I believe because it is orientating on the BASE_DATA[1] origin.

    Question:

    Can anyone aid in a calculation that can accommodate part orientation that can be applied to BASE_DATA[10]?. There could be multiple checks per part but for ease of understanding I reference just this one evaluation pose.

    Thank you in advance community......


    You said the camera is static, but if so, then how is it inspecting the part from different angles? If the camera is being moved to different positions, then at minimum you would need a different camera calibration for each camera position. Probably require a different Job file in the Congex for each position, and each Job file with its own calibration.

    And, given that the Cognex can only measure in X,Y,Rz, putting it at anything other than an orthogonal angle will make its measurements incorrect. You might be able to perform mathematical convolution on the Cognex measurement values to convert into robot Base coordinates, but it's going to be tricky, rather imprecise, and reliant on having a perfect 6DOF measurement of the camera vs the Base.

    Hi SkkyeFire:

    Apologies, my error is putting across, the Cognex is static (roof of the machine) and is used to send the robot to the part for it to use the end effector (Keyence) camera(s) to do the evaluations. Think of the Cognex as a course adjustment.

    Ok... I think I understand.

    The Congex overhead just gets the location of the part.

    The Keyence camera is mounted on the robot and only shows the correct part when the camera is directly overhead.

    When you rotate the TCP the Keyence will no longer look directly at the part.

    If the Keyence is always looking at say a 45° angle, you can apply a constant XY coordinate correction to make the part appear into frame again.

    Its just Pythagorean theorem twice. Once for the X offset and once for the Y offset.

    Just offset the tool in a way that the tool center point is is the target.

    Then when you rotate the TCP the part is always centered in the KEYENCE camera.

    And the COGNEX always sends the robot to the same coordinate.

    So, using the Cognex data to perform a Base shift to bring the part into the Keyence's FOV? Hm...

    That should work. But it would require that the Cognex/Robot Base (Base 1 in this case) have it's origin located located exactly at the key feature of the part when the part is in 0,0,0 position. Or, the Cognex data would have to be relative to the ideal part position, not just simply measuring the part's position in Base 1.

    And, of course, the Keyence Vision position would have to be taught in Base 10.

    i read this more than once and ... it is not very clear....

    the way i understand is there is one vision camera mounted on ceiling (Cognex) .

    on the EOAT is another camera or inspection device (Keyence).

    Cognex is used to locate part (coarse), then robot comes closer and use Keyence to do ... fine location... (and/or inspection).

    It also seems that there is no question about Cognex result..., question seem to be about Keyence result because EOAT can be in a different position and orientation. as usual, key part (Keyence) was not mentioned until post 5.

    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

    Good morning all,

    So to conclude this thread ( and thank you for your replies ), the job was ongoing up until last Friday, then I stumbled across Fiducial calibration ( classed as a GRID calibration within Insight Explorer ).

    Once performed within the ISE, the pixels are converted to REAL WORLD metric values from the Fiducial origin. I then made BASE_DATA[1] the co-ordinates of this Fiducial via 3-point method. ( essentially making the Cognex and BASE_DATA[1] identical ).

    Each Cognex job is representative of the part placed under its FoV, therefore a unique Cognex job number / part. Within each of these jobs, I have performed this GRID calibration ( luckily , the GRID parameters are saved explicitly to the job number and NOT to the camera itself). - A point to note is that each job number has had the fiducial plate raised or lowered to coincide with the "Patmax" feature it is looking for. ( If the Feature of the part is say 100.0mm from the machine base plate, then the Fiducial plate is also raised to this height, giving a sizeable GRID calibration).

    ## I will take an image of our mechanical Fiducial calibration set up to aid what I've written once the tool shop have finished the mechanism ##

    Upon a trigger within a job, the "Patmax" reports the X/Y/A offset to the Fiducial origin, I then apply these values to:

    fCognex.X/Y/A

    BASE_DATA[10] = BASE_DATA[1] : fCognexOffset

    The PLC sends down to the robot the SLIN Cartesian positions ( PreAquisition / ToAquisition ) that were recorded against BASE_DATA[10].

    In summary, I was using Horizontal and Vertical scaling values that the robots was sending to the Cognex camera, although these values calculated the pixel - real world, it wasn't accurate in my application.

    Why on earth do you have different parts on different heights?

    Why are you doing the fiducial calibration multiple times for different parts.

    You can have one COGNEX program that turns on a specific pattern to search based on an input.

    Just calibrate the COGNEX camera to give out values based on the robot coordinate system. Pixel coordinates to World coordinates.

    The static COGNEX camera will find where the pattern is that you are looking for.... the X / Y and rotation.

    And you just transfer the X, Y and rotation values to the KUKA.
    The robot will go to this location without any conversation.

    Now for the camera that is attached to the robot... the Keyence. Define a new tool for that. So that the tool center point is not the tip of the camera lens but the target location. Like a really long invisible tool...
    When you command the robot to use this tool and go directly to the position that CONGEX sent you... you will look directly at the part. Even if you set some weird angles to the tool... it will still be focused on the part.

    I find it really difficult to understand what you try to achieve.

Advertising from our partners