Use conveyor tracking on objects that are larger than the robot’s workspace
I want to execute a program that is larger than the robots workspace. To do this, I use a conveyor that moves the program into the robot’s workspace as the robot executes it.
As a simplified example: The robot simply needs to stand still while a large object passes by. I use UR’s Conveyor Tracking, and the conveyor moves with 1 m/s. To make the robot stay at the same position, I “move” it with 1 m/s in the opposite direction of the conveyor.
So if I want the robot to stay at position (0.0, 0.0, 0.0), after one second the conveyor tracking will make the robot go to position (1.0, 0.0, 0.0). To counter this, I tell the robot to go to position (-1.0, 0.0, 0.0).
This works really well, and the robot stays at the same position while the object passes by on the conveyor.
The problem arises when the position I send to the robot goes out of the robot’s workspace, even though the conveyor tracking shifts the position into the robot’s workspace. get_inverse_kin fails, which is understandable since it is performed on the position I send, not the position that the conveyor tracking makes.
Unfortunately, this means that it is impossible to process objects that are larger than the robots workspace, despite using a conveyor.
I have made a script here, that shows the concept: FeatureRequest
When executing the script with a conveyor, the robot stands still as expected until get_inverse_kin fails.
I would like a way to perform the kinematics check on the position that the conveyor tracking makes instead. Or to not have to make one at all, since (I assume) the conveyor tracking also will make one anyway.
I’m developing an application that requires that the robot can spray paint objects that are longer than the robot’s original workspace. To solve this, I’m using a conveyor. The idea is that the object will move on a conveyor and the robot will paint it as it passes by.
With the way that conveyor tracking works right now, I can only do this for objects that are smaller than the robot’s workspace, meaning that the customer cannot use the application.
I feel like this shouldn’t be a problem, I’ve done a lot of conveyor tracking and if you have a way of knowing where the start of your object is, and set waypoints for your spray pattern, you should be able to let the robot wait until the object is in the work area and then start tracking and use movep to get the relative velocity you want between waypoints.
With servoj and inverse kin I’ve run into trouble if one of the waypoints takes the robot too far during tracking, especially with a tilted nozzle orientation. get_inverse_kin has some tolerance arguments that helped in those situations.
Can you draw a rough sketch of the setup?
Thank you for your reply
I have drawn a sketch here.
The red arrow shows where the robot is. The green line is the part of the program that is being executed. The blue line separates the part of the program that is inside/outside the robot’s workspace.
As soon as the blue line meets the green line, get_inverse_kin fails. I don’t think any of the parameters that I can set for get_inverse_kin would fix it, as I would have to let maxPositionError be multiple meters.
Unfortunately, not using servoj is not an option.