Vision Guide Robot Math Question...

[Chris Elston]

I having some problems with a vision guided application and I can't figure out what I am doing wrong or why my math as it doesn't come out right, so I'll try and explain this one, all though it might be hard to picture this......bear with me. I have a part that I am trying to assemble via vision guided. The part is a symmetrical shape so it can be put together two ways. So if the part is presented via 10.000 degrees, it also can be assembled at 170.00 degrees. (by rotating the part the opposite 180 degrees) It doesn't matter. The part is round, to assemble it, I need to take a picture of a feature find the degrees of rotation then carry it over to the matching sub assembly base, and rotate the part until the part I have in the robot gripper matches the bottom part, then assemble them together. Since the part is symmetrical it can happen two ways. The pickup rotation of the robot gripper is always the same, the part I am picking up always varies. The feeder is a feeder bowl and the orientation from the feeder bowl can not be held. When I pick up the unknown rotation part, the robot is always picking up the same position. After taking a picture, I need to determine the degrees to which to rotate the robot gripper to assemble it with a sub assembly base, that is always in the same position. FACTS again: Robot theta degrees or pickup point is always 90.000 degrees rotation. Robot picks up part, part can be in any orientation. Robot stops over vision system at 90.000 degrees when a picture is taken, rotation of part is determined from vision camera tools. Picture is taken, vision reports degree of part say is 23.125 degrees of the feature found. Part to be assembled is always the same degrees, say 180.00 degrees. In the above situation, robot needs to move only 66.875 degrees to align part with assembly part base unit. Seems like an easy math solution. HOWEVER….. Final position - (robot current position - vision degrees seen) = robot motion in degrees to move too to mate top with bottom part. 180.00 - (90.000 - 23.125) = 66.875 degrees (move robot to this degree position to align part with base unit always at 180.000 degrees) But this doesn't always work. I assume it might be because of the way I am handling my NEGATIVE degrees….. The problem I am having is I didn't want to transfer a negative number from the vision camera to the PLC via modbus. Matter of fact, modbus is only integer based…so…. What I currently do is use two INTEGER REGISTERS in modbus. It happens like this: Vision camera takes pictures, let's say 23.125 degrees. Real number format. If value is positive degrees, then put 23 in one register and (0.125 X 100) = 125 in another register. 23 and 125 is transported from the vision camera to PLC via modbus, then into the PLC integer registers, I take the two integers and pass them through from PLC to profibus to the robot registers. Inside the robot controller, I convert the two integers numbers back into a real number (23 + (125 / 1000) = 23.125 so I can do the math in the robot controller. So the robot controller reads the raw degrees from the camera, which all that works great. When it comes time, the math is done to calculate the move to position. It seems that most positive degrees work great, but negative ones don't always work out for me… In order to handle a negative number from the camera….. If the vision camera takes pictures, let's say -23.125 degrees. If value is negative, FIRST, I subtract 180, to get the opposite 180 degrees which will be 156.875. Then put 156 in one register and (0.875 X 100) = 875 in another register. 156 and 875 is transported from the vision camera to PLC via modbus, then in the PLC, I take the two integers and pass them through from PLC to profibus to the robot registers. Inside the robot controller, I convert the two numbers back into a real number (156 + (875 / 1000) = 156.875, then do the normal math to assemble the part, which seems like it should work but it doesn't. Can anyone see where I am losing my logic in my math thinking? EDIT...I forgot to mention that I am working with a Cognex Pat Max tool. It can only report a feature from 0 to 180 degrees postive, or the tool flips, and says your part is 0 to -180 degrees...it can not report back from 0 to 360 degrees... see this article: http://www.mrplc.com/kb/index.php?page=ind...;id=72&c=20

[Ken Moore]

Let's see 23.125 from 360 leaves 336.875. 336.875-180= 156.875, same answer a different way. No help. Is the miss consistant? Can you measure or guess how far off the negative numbers are, that may lead us to an obvious oversite.

[Chris Elston]

As of Friday, I think it was 45 degrees always (the miss)...been bugging me all weekend...I figured I'd get a head start for tomorrow...

[Ken Moore]

If I understand correctly, then the maximum error is 90 degrees. For positive error, you turn that amount. For negative error, how about this: Convert the negative number to a positive by multiplying by -1, then add to 90, so a negative error of 23.125, added to 90 would give you 113.125, about 43 degrees different than the previous attempt. Just a swag. Sorry I couldn't be more help.

[BobLfoot]

Can't find an error in the math, but do have a thought. If you can "play" al little. Change the negative handling as follows and see what happens: For a negative number send an code number transmission say 999.999 degrees. Upon receiveing the 999.999 have the robot rotate 90 degrees positive and reshoot a second picture. See if this gives the positive value you expect or some other value.

[panic mode]

can you divide result by 2 (so +/-180deg becomes +/-90deg) then add 90 (to fit the value to range of 0-180deg) and on robot side just reverse it (subtract 90 then multiply by 2). the idea is to use only positive range if that's what you've got (and the camera supports some math which should be standard these days).

[panic mode]

any luck?

[paulengr]

The way you are sending the data over is...a little screwy in my mind. Isn't it easier to simply add 180 degrees to ALL values? Then your span will be 0-359 without any negatives. Second, why not simply multiply by something convenient such as 50? Then the span will be 0-18000 which easily fits within a single 16 bit integer. I doubt anything in your system is as accurate as 0.02 degrees. The "subtracting 180 degrees" thing just doesn't sound right. First off, -23.125 - 180 = -203.125, NOT 156.875. Obviously you are doing -23.125 + 180 = 156.875. But understand what this simple math operation is doing. Assuming that you are using the idea that addition is clockwise rotation (from your diagram), this is equivalent to giving the part a half rotation clockwise. Since you have a line of symmetry, it works.

[Chris Elston]

Paul, I see what your saying. Sometimes you can't think about stuff unless you bounce if off other people. I ended up changing the way I was going with this. (camera part degrees seen) + (robot taught pickup position) - (offset) I told the Cognex camera to give me only values from +0 through +180 in the Pat Max tool. I am also trying to go to the shortest rotation to where I need to go be it clockwise or counter clockwise. If the camera degrees are more than 90 degrees. I change up the math to this: if camera degrees greater than 90: (camera part degrees seen) - (robot taught pickup position) + (offset) if camera degrees is equal to or less than: (camera part degrees seen) + (robot taught pickup position) - (offset) The offset is figured when I pick up the first part and find the correction factor between the taught pickup position and taugh place position. This is a fixed value when the vision camera is taught what it is looking for. Because the vision tool can be rotated so this offset must be accounted for. I also incorporated the robot taught pickup position incase it was re-taugh by customer, the math would be dynamic and they shouldn't have to fiddle with it after reteaching a position on the robot. It works like a champ and goes to the nearest position rather than making two or three revolutions to get to the same place.