Using pose_add() and pose_trans() to adjust a plane on the fly gives inconsistent results.

DriedgerH

Hi. Perhaps someone here has the same problem or can offer an explanation.

My problem is the inconsistent result i get from pose_add() and pose_trans() functions

How could i achieve repeatable results using these functions?

I am using a robot to apply an adhesive product to a moving part.
There is a predetermined path for the product but the part is not always fixtured the same as there are many hundred fixtures in the system and the robot is retrofitted to the line so calibrating each fixture is impossible.
Initially a vision system gives an offset for locating in the X, Z and Ry dimensions via Plane_1=pose_trans(Plane_1,p[Cx,0,Cz,0,Cry,0]) function.
Then the adhesive applicator has an analog sensor for floating tip stickout measurement.
I am using this analog signal to adjust the Y position of the plane that is being referenced in the MOVL where my path waypoints are.
I use a variable to trigger the measurement and adjustment script in an IF statement in the thread.
This allows me to compensate for part position on the fly without stopping(causes blobs) to do a pose_add() or pose_trans() and adding many lines of code amidst the motion logic.

sample of logic

robot program
conveyor_tracking
    MOVL  (feature=Plane_1)
       waypoint_1
       waypoint_2
       var_1=true
       waypoint_3
       waypoint_4

Thread
   If var_1 = true
      tip_shift=((-0.018+analogIN[2])*2.3)
      Plane_1=pose_add(Plane_1,p[tip_shift,0,0,0,0,0])
  sync()

I am using this on one robot on a mirror image of the part across the line and it works 100% of the time.
On the other robot this produces a desirable result 90% of the time.  10% failure is unacceptable in a high volume application.
10% of the time the pose_add() shifts the program in the wrong direction causing the adhesive to be applied off path and the end EOAT to crash causing undesirable downtime to the line.

I have also used the pose_trans() in the same way and it ends with the same inconsistent result but for some reason i have to adjust a different element in the p[ ] constant to adjust the Y dimension.        eg, pose_add(Plane_1,p[tip_shift,0,0,0,0,0]) does the same thing as pose_trans(Plane_1,p[0,tip_shift,0,0,0,0])

DriedgerH

sorry, correction on thread.

Thread
   If var_1 = true
      tip_shift=((-0.018+analogIN[2])*2.3)
      Plane_1=pose_add(Plane_1,p[tip_shift,0,0,0,0,0])
      var_1=false
  sync()

Sebastien

@DriedgerH
I can see different issues causing this problem. First, do you have the same software version on both robots?
Can you also post a video of the application showing how you measure this? Is your tip_ship that you measure always lined up with the X direction of your frame where Plan_1 is referenced from? 

DriedgerH

@Sebastien
I did have the same software version on both controllers, but just updated to the latest on this one to see if it would fix the issue.
The problem did not change from V3.3.1 to V3.3.2.
Yes the tip_shift is always in line with the X direction of Plane_1.
Unfortunately i cannot post video of the application due to a strict media policy in the facility.

I retaught the plane positions and deleted all MOVL's and waypoints and recreated them and the problem changed slightly but is still happening in the same location along the path but eliminated the problem in different areas along the path.

I did find a presentation stating the reason why i have to reference different elements for pose_add() and pose_trans()
It is because one shifts relative to base position(pose_add(p[ ],p[ ])) and the other shifts relative to the first position parameter(pose_trans(p[ ],p[ ]))

The XYZ positions being altered makes sense using pose_trans() due to the angle of the plane after the camera shift.
It is still odd that the function would alter any rotational element with a "0" in place. 

I would love to see the actual function source code to see if there may be some error in the calculation method or perhaps devise a way around it.
Sadly i doubt they would hand it over.

Etienne_Samson

@DriedgerH @Sebastien you guys should mention that all this applies to a UR robot. I just poked someone at UR who would be able to help on that, he should join DoF and post any day.

DMO_Universal

@DriedgerH It's very possible you have two things going on here.

First, it's possible you have some kind of noise in your Analog Input signal.  If you use textmsg(s1,s2) you can send the level of the signal to the Log File when you make your adjustment.  This would let you know if the 10% failure rate corresponds to weird AIN signal levels.  If so, there might be some techniques that can stabilize the signals.

Second, you seem to be having some issues with unexpected behavior from Pose_Trans.  Can you message me your actual code, or have your Distributor send it along to the UR Support e-mail?

DriedgerH

@DMO_Universal
I have been logging the analog signal and the plane position variable for a few hours now and the signal appears to be stable. it has not been out of its range as of yet.

Stefan_Stubgaard

@DriegerH

The unextpected behavior experienced in regards to the rotation is most likely due to that you are using movel.

movel will always try to find the nearest solution, thus if a given rotation is larger than 180 degrees the user will see it as moving in the "wrong" way when rotating. Try analyze the behavior with focus on this.

Cartesian positions, as used by movel, has multiple solutions. Whereas joint positions, as used by movej, always moves to the excact joint values, so an option can be to use movej. another option is to split the movel into two motions, making sure neither rotations more than 179 degrees.

DriedgerH

@Stefan_Stubgaard

The problem is that the movj is unusable during application due to nature of the motion of the robot. I need clean straight lines. Also you cannot reference a feature using a MOVJ. 

I am not sure what you mean when you say "rotation is larger than 180 degrees" The vector i am changing is non rotational it is merely moving the plane linearly along a single axis.

DriedgerH

Update: 

I recently tried another controller just to rule it out and the problem still was happening.
I also deleted all plane adjustment out of the problem area and it still acted the same way.

I found that the end effector was being side loaded for a small duration at this "problem area". As soon as the sideload is released(tip slips over the hump) the robot overcompensates and also appears to lose some conveyor tracking distance. The robot does not fault all the time and has caused some damage to parts due to sealer after the problem area being applied off path sometimes by as much as 40mm.

As soon as i retaught the path along this area the # of faults was reduced greatly. So i believe i am on the right path but the software needs to be corrected to either fault when off path by a smaller margin or to help avoid overcompensation and conveyor tracking distance loss.

Still having this "shifting path" issue but not nearly as much but am trying to perfect the path until a software fix resolves this problem.

Thanks all for the help. 
Still open to suggestions.

lakshmip001

Hi,

I am working on something similar and I need to use movj to not to crash with the surface. But I face path shift of 50mm in the overall process. I tried giving movj inside movl so that path moves relative to plane. But still path shift persists. Can I know if I can remove this path shift and perfect the movement.

Thanking you in advance.

Warm Regards,
Lakshmi Prasanna.