Posted on by Andrea Zanchettin

An IIoT solution to speed-up collaborative robotics applications

A collaborative robot is a robot intended for direct human robot interaction within a shared workspace, or where humans and robots are in close proximity. For safety reasons, they are typically run at reduced speed with respect to traditional industrial robots. On the other hand, the persistent presence of the human worker might introduce several benefits in specific applications. The activation of safety mechanisms usually stops the motion of these robots or reduces their productivity, as well as the one of other machines and robots involved in the same production process. With the aim of improving their productivity with respect to these situations, we have proposed an online trajectory optimisation method for collaborative robots capable of reducing the number of interventions of safety functionalities.

With the aim of reducing the number of intervention of preemptive stops or speed reductions in collaborative robotics a surveillance camera can be adopted to monitor the average occupancy of the human worker, operating in closed proximity to the robot.
The portion of the workspace occupied by the operator can be represented by in terms of an occupancy map consisting in a grid of cubic voxels, each denoted by a certain probability to be occupied. The result is a 3D head map with a resolution of approximately 5x5x5 cm containing this information that is continuously updated in the background whenever new information are available.

Assume the task of the robot is specified in terms of a program containing all the (parameterised) motion instruction. As a matter of example, consider the following ABB RAPID program:

VAR robtarget pApproachScrewL := [[300.19,12.20,203.66],[0.0764165,0.494323,-0.864922,0.0414156],...];
VAR robtarget pPickScrewPrewL := [[295.94,0.68,155.84],[0.0634479,0.496456,-0.865085,0.0336694],...];
VAR robtarget pPickScrewL := [[295.03,0.24,151.56],[0.0667588,0.465606,-0.882007,0.0286101],...];
VAR robtarget pPickL := [[284.93,-15.05,154.48],[0.0651595,0.457112,-0.886449,0.0318092],...];
VAR robtarget pDetachL := [[285.27,-7.37,153.69],[0.0789642,0.501409,-0.860536,0.0428052]...];
VAR robtarget pInsertionKnob := [[326.69,130.83,183.19],[0.0313732,0.0350629,-0.691905,0.720454],...];

PROC pick_screw_L()
   MoveL pApproachScrewL, v500, fine, tHandL;
   g_MoveTo 1;
   MotionSup \Off;
   MoveL pPickScrewPrewL, v100, fine, tHandL;
   g_MoveTo 5;
   MoveL pPickScrewL, v10, z20, tHandL;
   MoveL pPickL, v30, fine, tHandL;
   g_GripIn \holdForce:= 30; 
   WaitTime 0.5;
   MoveL pDetachL, v100, z20, tHandL;
   MoveL pApproachScrewL, v100, z20, tHandL;
   WaitSyncTask sync_task, tasks_list;
   MoveJ pInsertionKnob, v100, fine, tHandL;     
ENDPROC

As every typical robot program, it is composed by a sequence of Move instructions, each one together with its own parameters: the interpolation type (in the Cartesian space, MoveL, or in the joint space, MoveJ), the waypoint to reach, the maximum traversal velocity (speeddata), as well as the blending radius (zonedata). The key idea is to optimally select these parameters, in order to simultaneously minimise the risk of collision with the human operator as well as the time required for the execution of the program.

The occupancy map is sent to a network node (an edge computing device) where a digital twin of the entire collaborative workspace is used to simulate the process. Based on the given program, the digital twin emulates the motion of the robot to compute the cycle time as well as the probability of collisions between the human working envelope and the robot.
The motion parameters of the robot are then altered according to the following possibilities:

  • Adjustment of waypoint position, speed (speeddata) and blending (zonedata);
  • Insertion or removal of a waypoint.

As an example of the first possibility, the speed of the second instruction has been altered from 100 mm/s to 300 mm/s, the blending radius of the third has been doubled from 20mm to 40mm, while the z coordinate of the first waypoint has been reduced from 203.66 to 180 mm.

VAR robtarget pApproachScrewL := [[300.19,12.20,180.00],[0.0764165,0.494323,-0.864922,0.0414156],...];
VAR robtarget pPickScrewPrewL := [[295.94,0.68,155.84],[0.0634479,0.496456,-0.865085,0.0336694],...];
VAR robtarget pPickScrewL := [[295.03,0.24,151.56],[0.0667588,0.465606,-0.882007,0.0286101],...];
VAR robtarget pPickL := [[284.93,-15.05,154.48],[0.0651595,0.457112,-0.886449,0.0318092],...];
VAR robtarget pDetachL := [[285.27,-7.37,153.69],[0.0789642,0.501409,-0.860536,0.0428052]...];
VAR robtarget pInsertionKnob := [[326.69,130.83,183.19],[0.0313732,0.0350629,-0.691905,0.720454],...];

PROC pick_screw_L()
   MoveL pApproachScrewL, v500, fine, tHandL;
   g_MoveTo 1;
   MotionSup \Off;
   MoveL pPickScrewPrewL, v300, fine, tHandL;
   g_MoveTo 5;
   MoveL pPickScrewL, v10, z40, tHandL;
   MoveL pPickL, v30, fine, tHandL;
   g_GripIn \holdForce:= 30; 
   WaitTime 0.5;
   MoveL pDetachL, v100, z20, tHandL;
   MoveL pApproachScrewL, v100, z20, tHandL;
   WaitSyncTask sync_task, tasks_list;
   MoveJ pInsertionKnob, v100, fine, tHandL;     
ENDPROC

The new program is then simulated again, its cycle time as well as the probability of collisions are updated. Several simulations, each corresponding to random modification of parameters, can be run in parallel on the edge until a new, and better, trajectory has been found. Then the corresponding optimise code is deployed to the robot via FTP.

Schematic representation of the proposed architecture.

Naturally, not all the motion parameters can be freely modified, especially in assembly applications. To this end, instructions that can/should be modified by the algorithm are marked by the programmer to inform the algorithm on this possibility.

From experiments run in our lab, we have verified that after the optimisation, the probability of collisions can be drastically reduced. Correspondingly, the average reduction in the cycle time of the operation ranges from 9% to 65%.

Probability of collisions before and after the optimisation (black/grey cubes represent human occupancy).

One of the additional benefit of this methodology is that the algorithm runs directly online while the robot is productive, though not optimally. This feature allows to optimise the application while running, instead of spending much time using offline simulation environments.

References:

  1. A. M. Zanchettin, C. Messeri, D. Cristantielli, P. Rocco – “Trajectory optimisation in collaborative robotics based on simulations and genetic algorithms”, International Journal of Intelligent Robotics and Applications, Springer, 2022.
  2. È. Pairet, P. Ardón, X. Liu, J. Lopes, H. Hastie and K. S. Lohan, “A Digital Twin for Human-Robot Interaction,” 2019 14th ACM/IEEE International Conference on Human-Robot Interaction (HRI), 2019.