How Snappy Is Your Robot? Part 1
By Alberto Moel (Vice President Strategy and Partnerships)
Welcome back, dear reader, to one more installment of the Veo Robotics blog. For a while now, we have been discussing the nuts and bolts of human-robot collaboration, what it looks like in practice, how guarding can improve interaction, issues with reported robot stopping performance data, and metrics on figuring out how collaborative a robot can be.
Threaded through our discussion is the fact that how quick or responsive (and how collaborative) a robot is will depend on two parameters intrinsic to the robot and its controller. One is the response time, or latency, of the robot controller – how quickly can the robot controller respond to an external signal. The other one is a measure of how fast the robot can decelerate or come to a complete stop given an initial velocity. This is going to be an intrinsic function of the payload, pose, and the fundamental mechanics and kinematics of the robot; for example: how strong its brakes are, the frictional forces at the joints, and even the shape and geometry of the arm.
These two parameters, how quickly the robot controller responds to an external signal and how fast the robot comes to a stop, will influence the Protective Separation Distance (PSD) between the human operator and the moving robot. It should be self-evident that the shorter the robot controller latency (i.e. the faster the robot can respond) and the higher the deceleration (i.e. the faster it can come to a stop), the shorter the PSD can be and the closer the human can be to a moving robot while remaining safe.
In today’s post we will dive deep and come up with a first principles (but simple and intuitive) derivation of how the PSD is influenced by the controller latency and the robot mechanics and dynamics (as captured by robot deceleration). We will apply this intuition to how the controller latency affects the PSD. In the next blog post will tackle the second parameter, deceleration, and discuss the disconnect between PSDs derived from first principles and those implied by published stopping time and distance data.
If you are pressed for time and don’t want to go into the weeds with me, you can see a graphical representation of the impact of controller latency on PSD in Figure 1 and Figure 2. There you’ll see that the robot controller latency has a material and negative effect on the PSD and hence how collaborative a robot can be. Not only does controller latency linearly increase the minimum PSD (the PSD at zero robot velocity), but there is a negative interaction between robot controller latency and robot velocity beyond a simple additive term. Very simply, the lower the robot controller latency, the better. If you want to see what the numbers look like and how we derive them, just keep reading.
Back to Basics (One More Time) – SSM and PSD
I know we have been through this one a number of times (see, for example, here, here, and here), but bear with me, as we are taking this in a new and productive direction. As we know, the PSD is the key parameter in Speed and Separation Monitoring (SSM) implementations of collaborative robotics and is defined based on the concepts used to create the minimum distance formula in ISO 13855, modified to take into account specific hazards associated with SSM. The PSD is calculated between the robot and any area or volume that a person could potentially occupy. A safety-rated Protective Stop is initiated if the PSD is violated. The robot can automatically restart and continue its trajectory once the operator moves away and re-establishes the PSD.
The PSD, Sp, is described by the equation:
where
Sp(t0) is the PSD at current time t0;
Sh is the contribution to the PSD attributable to the operator’s change in location;;
Sr is the contribution to the PSD attributable to the robot system’s reaction time;
Ss is the contribution to the PSD due to the robot system’s stopping distance;
C is the intrusion distance, as defined in ISO 13855; this is the distance that a part of the body can intrude into the sensing field before it is detected;
Zd is the position uncertainty of the operator in the collaborative workspace, resulting from the sensing system measurement tolerance;
Zr is the position uncertainty of the robot system, resulting from the accuracy of the robot position measurement system.
Sp(t0) allows the PSD to be calculated dynamically, allowing the robot speed to vary during the application. From a safety perspective, the simplest assumption is that the operator’s motions will follow a worst-case scenario in that the operator will begin moving in the direction of the robot at any time. Similarly, lacking any safe real-time monitoring of robot velocities, we assume that the robot can begin moving at any time towards the human at its maximum speed vr.
Under those assumptions, we can go back to its first principles derivation in ISO 13855 which specifies the minimum protective distance for stationary machine tools:
In this equation, v is the approach speed of human body parts, T is the system stopping performance (i.e. how long it takes for the machine to stop), and C is the intrusion distance as previously defined. Let’s rename v as the human speed vh, and consider that T for a robot is going to consist of the sum of two components: the time it takes for the robot to respond (the reaction time or controller latency, which we call Tr) and the time it takes for the robot to stop once it’s responded to the command (which we call the stopping time Ts). Hence, we can derive that Sh, the contribution to the PSD attributable to the operator’s change in location, is given by:
Similarly, we can cast Sr, the contribution to the PSD attributable to the robot system’s reaction time Tr as how far the robot travels before it responds to a command, which is given simply by Sr=vrTr. Replacing into the above equation gives us:
The first term in parentheses describes the distance the human travels in the time necessary to bring the robot to a full stop from its current speed Sh=vh(Tr+Ts). The second term describes the distance the robot travels before it initiates the stopping sequence Sr=vrTr. The third term describes the distance the robot travels while it is stopping. Lastly, the fourth term describes the possible distance of intrusion into the robot’s work volume as a function of the operator reach and the uncertainty of sensors and robot kinematics.
During the response time Tr of the system, we assume constant robot motion with the velocity vr. After this period, the robot begins to decelerate. The resulting stopping distance Ss depends on a variety of factors, such as the current robot pose and velocity, the inertia of the manipulator including payload, and the braking torque. Consequently, an accurate computation of Ss requires knowledge about the dynamic properties of the robot.
However, we can simplify further by assuming that the complex robot kinematics can be captured by a constant deceleration as>0. The value for as is taken from product documentation or from experimental data and represents the Tool Center Point (TCP) deceleration for a controlled stop; it is used as a conservative estimate for the deceleration at each observed point on the manipulator. Then the robot’s stopping distance Ss is1:
And the stopping time Ts is given by:
Substitution of the above equations into the original SSM equation yields
A stop of robot motion command must be issued at the instant the actual separation distance S falls below Sp since otherwise the operator would be able to reach the moving robot within the robot’s reaction time Tr.
Modeling the PSD from First Principles
To operationalize the above equation, we need estimates for several parameters. Although robot deceleration will very much depend on specific robot dynamics and pose at the time the stop command is received, observed stopping times are at most in the order of a second or less. Robot TCP velocities are in the 1-10 m/sec range, hence a baseline value of as of 10 m/sec2 is sensible. In the next blog post we will analyze what happens when as is allowed to vary over a wide range of potential values.
Another variable that needs to be estimated is the speed of the operator,vh . vh is often assumed to be a maximum of 1.6m/s based on the specifications in ISO 13855. Even though 1.6m/s is an accurate assessment of normal walking speeds, it may be even more prudent instead to use the worst-case assumption of 2.0m/s from ISO 13855 to accommodate instantaneous rapid motions, such as arm motions when sufficiently near the hazard, as emphasized in ISO 10218-2. Depending on the application, vh could be lower than required by the standard and still provide a safe working environment.
Lastly, we need estimates for the intrusion distance C and the robot and sensor measurement uncertainties Zr+Zs. Since we are Veo Robotics and we have the FreeMove® system, we have determined, from section 6.2.3 of ISO 13855:2010 that C is 88mm, and that Zr+Zs is given by the length of a FreeMove voxel diagonal, or 130mm. Putting it all together, Table 1 captures our realistic model estimates.
Table 1. PSD calculation parameters used in Figure 1 and Figure 2.
What does the PSD look like as the robot controller moves from snappy to sluggish? Figure 1 and Figure 2 show the calculated PSD parametrized for initial robot velocity vr and robot controller latency Tr.
As expected, the value of the PSD when robot velocity vr is zero (the y-axis intercept) increases with robot controller latency Tr. This makes sense, as the system must incorporate the distance a human could move towards the robot before the robot reacts, even if the robot is standing still. What is not as obvious is that a more sluggish robot also affects the shape of the curve. In Figure 1, we see that the PSD slopes upward with increasing robot response time, and the higher the response time the higher the slope as a function of robot velocity.
Similarly, in Figure 2, not just the intercept increases with increasing velocity, but the sensitivity of the PSD to controller latency increases with velocity. It is clear that the best situation is where controller latencies are as low as possible in order to keep the PSD at a minimum and maximizes the “collaborativeness” of the robot. Not necessarily a blinding insight, but our analysis allows us to dimension and calculate specific values for the PSD as a function of robot and controller behavior.
Stay tuned for the next blog post, where we will discuss how the robot dynamics themselves (as proxied by the deceleration as) affect the PSD.
Figure 1. PSD as a function of robot velocity vr parametrized by robot controller latency Tr.
Figure 2. PSD as a function of robot controller latency Tr parametrized by robot velocity vr.
1In case you need a refresher in Newton’s Laws