I currently and working on a machine tending application with a UR20. The UR20 is loading/unloading 2 of the same lathes (labeled L1, L2) that are performing the same turning process (see attached layout image for diagram). I have a designated gripper (G1) for loading and another for unloading (G2).
Program wise, I taught a feature for L1 and L2, and I have the program’s waypoints toggle between each feature, depending on which lathe I want to load or unload. I also change TCP’s from G1 to G2 in the program, depending on whether I’m loading or unloading. (I have 2 subprograms- ‘LoadLathe’ and ‘UnloadLathe’.) Program/installation file attached.
The program works except for one scenario. I can load L1 (with G1), Unload L1 (with G2), Load L2 (with G2). However, when I try to Unload L2 (with G2), no matter where the robot starts from, it tries to pass through itself (and crashes) using a weird joint configuration where the base & shoulder joints get flipped. I tested it and the pose is reachable using my ‘ideal’ joint configuration (Plus G1 reaches the point just fine)
For example, if I start at the ‘ApproachLathe’ position at L1 with G2 active, all the robot would essentially need to do is rotate its based joint 90degrees to reach the L2 ‘ApproachLathe position’, but it flips itself instea . This only happens with G2-- when G1 is active it moves to the points fine. Is there a way to restrict the path the robot takes to reach a point?
Have you tried applying ‘Use Joint Angles’ option on the Move instruction? This tells it to use the taught angles instead of choosing the shortest path.
The issue with this is my waypoint is relative to a custom feature, and I change the location of that feature in the program, thus changing location of that waypoint relative to the base. I cannot do that with ‘Use Joint Angles’ applied.
First I would check the TCP settings for G2. Second I would check the part were you match the feature point to your reference / waypoint. Finally, you can apply the inverse_kinematics() script function, giving it a desired reference pose and a TCP to use. See script manual for an explanation.
If that fails, it could be that the end points are perfectly reachable, but the lineair motion requires the robot to move through its singularity range around the base (which is quite large with the UR20). If that’s the case, you need to insert an additional waypoint somewhere in between.
One more option is to look at script code generated by polyscope (it’s saved in the same folder as program, but with .script extension) copy and modify code generated for this motion.