An algorithm for continuously computing safe maximum relative velocities for two bodies joined by a manipulator is discussed. The maximum velocities are such that if the brakes are applied at that instant, the ensuing travel between the bodies will be less than or equal to a predetermined amount. An improvement in the way this limit is computed for space manipulators is shown. The new method is explained, test cases are posed, and the results of these tests are displayed and discussed

Mcdermott, D. A.

Ross, M. L.

English

NASA Technical Reports Server

"OPTIMAL PAYLOAD RATE LIMIT ALGORITHM FOR
ZERO-G MANIPULATORS"
M.L.Ross, D.A.McDermott
Lockheed Engineering & Sciences Company
Houston, Texas 77258
Abstract
An algorithm for continuously computing safe maximum relative velocities for two
bodies joined by a manipulator is discussed. The maximum velocities are such that if the
brakes are applied at that instant, the ensuing travel between the bodies will be less than
or equal to a predetermined amount. This paper deals with an improvement in the way
this limit is computed for space manipulators. The new method is explained, test cases
are posed, and the results of these tests are displayed and discussed.
I. lamnluaian
A. What is a payload rate limit algorithm?
The rate limit for a payload is, in effect, a "speed limit" for the rates the payload is
allowed to achieve relative to the manipulating body. Observance of this rate limit
ensures that the payload's relative motion can be arrested at any time during a maneuver
(e.g., in an emergency such as a joint runaway detection) without exceeding a specified
amount of overtravel after application of the brakes. Any method employed to compute
these rates must consider items like brake torque capability of the manipulator and
masses of the payload and manipulator base.
The Remote Manipulator System (RMS) on NASA's Space Shuttle currently
utilizes a rate limit algorithm to compute a single (constant) rate limit for each payload to
be manipulated during a mission, and these rates are loaded into the on-board computer
system prior to the mission. These rates are designed to ensure a stopping distance of
the end-effector (not the payload c.g.) in two feet or less when the arm is in an out-
stretched position (worst-case).
B. What is wrong with the current rate limit algorithm?
The algorithms developed to determine the rate limit for a payload to be carried by
the RMS were developed by SPAR Aerospace, Inc. in August 1979 with revisions in
February 1983 [Ref. 1,2]. These algorithms were designed for the original payload mass
range of up to 65,000 Ibm. (vs. Shuttle mass of 220,000 Ibm), and also assumed a worst-
case RMS configuration (fully extended). While these algorithms have performed well for
the range of payloads seen so far, they produce rate limits approaching zero for payloads
whose masses exceed 100,000 Ibm. They also produce only one limit, based on the worst-
case configuration, when in fact the RMS's ability to arrest relative motion is dependent
on arm configuration and the direction of the motion to be arrested. This means the rate
263 ¸
https://ntrs.nasa.gov/search.jsp?R=19900020542 2020-03-19T21:39:01+00:00Z
limits calculated are lower than necessary(conservative), so the payload is always
manipulatedat rateslower thanactuallyrequiredfor safety.
C. Why sho01d we care?
The RMS manipulator is basically a dexterous crane that has to perform large-
excursion travel in many of its tasks. If used, the low rate limits that the current
algorithm produces for the massive payloads will cause increases in the time required to
perform the job because the arm will move much slower than is necessary for safety. The
low rate limits also push all the commands down into the low end of the command scale.
This lessens the number of bit-states which can represent the command, thereby
decreasing resolution and accuracy of the command actually sent to the joint servos.
The current algorithm must be changed to consider payloads more massive than
65000 Ibm., and must consider the fact that the Shuttle also moves during the braking
process. Since the algorithm will require at least an update to handle the larger payloads,
this is a good time to look into deriving a better method. This method should be
dependent on the arm configuration and commanded velocity.
Some analysis on improving the algorithm has been done before, but the algorithm
arising from that analysis was still a single limit for a payload [Ref. 3]. That method did,
however, take into account the fact that the Shuttle moves during manipulation, and was
the basis of this current effort.
II. Prooosed New Payload Rate Limit Algori|bm
A. What should it do?
Any new method should include better models of system dynamics, and yet be
computationally simple. Simplicity will enable calculation of the limit in real-time as a
function of the current arm configuration and the requested direction of motion. The new
method should also consider relative rotational motion, and allow a maximum rotation
angle as an additional criterion.
The end goal of this algorithm should be to produce a rate limit which is higher than
the currently-used conservative value yet is still safe.
B. How can it be done?
1. System Dynamics
By considering the system dynamics of the payload and the Shuttle over the
process of:
Phase 1.
Phase 2.
beginning with relative rates (possibly zero)
between Shuttle and payload,
accelerating the payload and Shuttle to some new
commanded relative rate, and finally
264
Phase 3. applying the brakes until all relative rates have
been arrested,
one can see that, since we assume no external forces, system momenta is conserved
throughout this process. The dynamics from the time of brake actuation to arrest of
relative motion (Phase 3) can be viewed as an inelastic collision, in which both bodies
have initial relative motion, collide and stick together, and then proceed on as one body.
Realizing that the final system velocity Vf is constant, we can define a reference
frame F, translating at velocity Vf. The final rotational rates of the system are expected
to be very small (less than 0.2 degrees per second) This means we can allow the frame F
to rotate with the system at its final rotational velocity toe and still consider it inertial
(pseudo-inertial). In this frame, an observer would see that each body would have an
initial velocity, but would come to rest at impact. The relative velocities between these
two bodies would be the commanded velocity. The momentum equation can be written for
each body in this pseudo-inertial frame:
+ {__ t) dt = 0 and m2_2 _(t) dt = 0ml V_.I
I0
SO
V_.I = _ m_&2V_.2
ml
which says that the initial velocities of the two bodies in this frame will always be
opposed and parallel. Because the common direction of these velocities is also the
direction of the relative velocity, and we assume the force between the bodies to be
opposed to the relative velocity so everything falls on this line, leaving us a scalar
equation.
Writing the equation of linear momentum for the system in frame F, we get the
following equations, which we can treat as scalar since all vectors are parallel.
For the entire system (no external impulse) •
mlVl + m2V2 = 0
For bodies 1 and 2 individually (external impulse from arm) •
t i tmlVl + I F(t) dt = 0 m2V2 - F(t)
dt = 0
where (V2 - Vl) is the commanded velocity.
2. Estimation of Impulse
If we had some idea about what kind of impulse we could expect to see, we could
extrapolate what the travel motion of the system would be. The impulse does not have to
be exactly known, but the estimate must be less than the actual impulse, and still
265
produce a rate faster than the old value. A way to estimate the impulse is to estimate the
initial force or torque, and then estimate the manner in which it approaches zero.
Any force applied by the RMS to the bodies it connects will result from brake
slippage and storage of strain energy in the booms and gearboxes. Since only brake
slippage is non-conservative, this mechanism alone will be considered. The potential
brake torque at each joint is assumed to be known. In this case, the initial resistive force
encountered by the bodies can be estimated. By assuming all joints required to contribute
to the commanded motion will slip if the brakes are applied, a vector of brake torques can
be created which is an estimate of the torques which would be seen at each joint:
Xl * sign(yl)
(B) = - •
%6 * sign(y6)
where sign() is -1 if the commanded joint rate is negative, zero if zero, and +1 if positive.
Here we assume that the inverse of the Jacobian matrix relating end-effector
states to joint states is known or easily obtained. Multiplication of the transposed
inverse of the Jacobian by the brake torque vector just constructed results in the static
moments and forces at the end-effector to counteract those brake torques.
These loads at the end-effector will not generally be parallel to their counterpart
velocities. The components of these loads in the direction of those velocities are an
estimate of initial loads the payload and shuttle will encounter, while the components
normal to those velocities are assumed to arise from the errors in the assumed joint
torque vector.
where
T max : !" _c
Fmax = _" Vc
Vc, _0c are the unit vectors of the commanded velocities, and Tmax,
Fmax are the available torque and force in those directions (scalar). These loads are the
estimates of the actual initial loads seen upon applying the manipulator brakes.
So far this method predicts the initial loads seen at the beginning of the braking,
but its behavior of these loads over time is unknown. Since we are only having to
compute a conservative limit, we only need assume a conservative load profile, i.e. the
assumed profile's integral must always be less than or equal to the actual impulse.
Nominally, loads due to brake slippage could be thought of as constant over time, but
simulation has shown that these loads tend to drop off over the braking maneuver. To be
conservative, we assume a profile in which the loads begin at the predicted value (Fmax,
Tmax), but then linearly ramp down to zero over the time of the maneuver.
266
3. Calculation of Maximom Safe Speed
a._
Once we know or assume a force-time profile (impulse), we can determine the
distance travelled over that time and make sure all distances travelled are less than 2 feet
(or some other criterion).
To do this, we must look at the equations of motion of these bodies along the line
of action in frame F:
F(t)=A-Bt {0<t<tend }
where F(t) is the force exerted on each body,
tend is the time at which motion stops
A is the maximum force Fmax computed above
B is the slope at which F(t) ramps down,
i.e., Fmax/tend
so the acceleration of each mass is
a(t) = (A - Bt)/m
and the velocity of each mass is
v(t) =
rma(t) dt + V(t=0)
=(At-Bt2/2)/m (0<t<tend)
and the distance travelled by each mass is
x(t) =
t_V(t) dt + X(t--0)
= (At2/2 - Bt3/6)/m ( 0 < t < tend )
We can also see that since
x 1(t=tend) + x2(t=tend) < 2 feet
267
we can back out a relationship between the Fmax and the amount of time required to
arrest the motion, tend.
2 feet = (Atend2/2 - Btend3/6)(1/ml + l/m2)
or, substituting for A = Fmax, and B = Fmax/tend, we get
tend = 4"[3*d*m l*m2/((m 1+m2)*Fmax)]
where d is the stopping distance allowed, which is 2 feet for the RMS.
Once we know the amount of time required to arrest the motion, we can use the
momentum equations for each body:
mlV1 + impulse = 0, m2V2 + impulse = 0,
and since the impulse is the area under the assumed force-time curve,
impulse = 1/2 Fmax Tend
and the final allowable command velocity is V2 + V1,
Vmax = (Fmax * tend/2) * [1/ml + l/m2]
b. Rotational Velocity
The computation of the maximum safe rotational velocity closely parallels that of
the translational. An assumption of the torque-time profile (linearly approaching zero) is
made, and the equation of angular momentum is written for the system about the end-
effector tip. This requires that all body inertias be computed about that point.
The assumed torque-time profile is
T(t) = A-Bt (0<t<tend)
where A is Tmax ( initial torque)
B is the slope at which it ramps down (Tmax/tend).
For each body,
T(t) = Itx
where
I is the scalar moment of inertia at the end-effector about the rotation
axis, and
o_ is the rotational acceleration.
Solving for o_, A 0_, and A 0
268
ix= II[A-Bt]
and
Ao_ = Il[At -Bt2/2]
and
A0 = I-l[At2/2 - Bt3/6]
As before, we set the travel constraint
or
10degrees= A01 +A02 (att=tend)
0max = 10 degrees = (Ii 1 + Iz 1) [Tmax tend2/3]
which yields the expression for tend
tend = 5f"((0,ad57.3 * Illz*3)/((I1 + Iz)*Tmax))
which yields the expression of commanded velocity
tt_x = (Tmax tend/2) * [Ii 1 + Izl]
much as the translational equation.
This Vmax and Ohnax are the magnitudes of the allowable velocity in the
commanded direction. This command is what would be sent on to the robot controller, if
the operator desired to go the maximum safe speed.
4. ADolication of Limit to Command
Obviously, an operator would not want to go the maximum safe speed in all
situations, so what to do with the knowledge of this instantaneous speed limit raises
several possibilities. One way to apply the limit would be to use some constant
conservative limits under normal operation, and use the maximum limits whenever a hand
controller has been fully deflected in some axis. Another method would be to use the
maximum limit as the upper end of the hand-controller's range, i.e. if the hand-controller is
deflected 50% in some direction, then the commanded velocity would be 50% of the
maximum safe velocity. This latter appears to be possibly unwieldy for the operator,
since a constant deflection of the controller would produce varying velocity commands as
the arm's configuration changes. Either of these methods could be implemented as an
operator-requested mode.
III. Tests. Results and Conclusions
A. How can we evaluate this new algorithm?
In order to evaluate the performance of the algorithm, dynamic simulation of the
Shuttle/RMS/Payload system was required. This was done with a dynamic batch
269
simulation program developed at the Johnson Space Center which uses an extensive
model of the Shuttle and the RMS. This program (called MIRRORS, for Model for
Integrated Robotics Research and Operational Requirements Synthesis) is a spin-off of
the PDRSS (Payload Deployment and Retrieval System Simulator, which is a spin-off of
the SVDS (Space Vehicle Dynamic Simulator), which was written during the Apollo
Program. The program has been checked against actual flight data from Shuttle/RMS
missions as well as other simulators, and is used routinely for RMS maneuver simulation.
The underlying idea behind the evaluation was to get a prediction of safe velocity
from the algorithm and then start the simulation with those velocities and the brakes on,
watching the ensuing travel. This was done while varying command direction, payload
mass and ann configuration. The commands given were all single-axis commands:
X translate
Y translate
Z translate
in positive Orbiter X-axis (toward nose)
in positive Y-axis (toward starboard wing)
in positive Z-axis (down toward bay)
R rotate in
P rotate in
Y rotate in
positive direction about X-axis (roll)
positive direction about Y-axis (pitch)
positive direction about Z-axis (yaw).
The algorithm was coded into the flight software module of the MIRRORS
program. Tests were run in the following manner for commands in each rotational and
translational axis:
1. For given command direction, determine from the algorithm the maximum safe
speed.
2. Initialize simulation with payload moving at that speed in the commanded
direction, and with the brakes just applied.
3. Let simulation run until motion arrested, compare amount of travel with specified
maximum (2 feet or 10 degrees in all cases).
The test runs were conducted for three different payloads, all 15 foot diameter
homogeneous cylinders, grappled on the side at the midpoint, having masses of 32000,
100000, and 250000 Ibm. The test also used two different initial arm configurations, for a
total of 6 * 3 * 2 = 36 test runs.
To evaluate the amount of travel, the code was altered to compute the Euclidean
distance from the current position to the point where the brakes were applied. For the
rotational cases, the angular displacement about the relative rotational eigen-axis
(component of the quaternion relating payload attitude relative to the Orbiter) was
computed. These are included in the test results below.
B. What were the test results?
The test results for all 36 runs were in general agreement with the desired end
goals, in that 33 of 36 runs resulted in payloads travelling 2 feet/10 degrees or less while
at speeds faster than the old method would allow. Three runs, however, did result in up
to 2.3 feet of travel, all in the Z direction. The results of all the runs are tabled below, for
270
each arm configuration (joint angles from shoulder yaw to wrist roll
parentheses). The three runs that exceeded the travel limits are also noted.
The format for the data for each run (three numbers) is as follows:
[1] rate limit as predicted by old method (feet/sec or deg/sec)
[2] rate limit as predicted by new method
[3] stopping distance or angle for new rate (feet or degrees)
ARM CONFIGURATION #1 ( -90,90,-71,0,0,0 ):
shown in
Pay-
load
32K
100K
250K
Command Directions
X Y Z R P Y
feet/sec and feet degrees/sec and degrees
0.153 0.153 0.153
0.250 0.252 0.324
0.990 0.354 2.365*
0.100 0.1OO 0.1OO
0.160 0.161 0.207
0.749 0.223 2.362*
0.071 0.071 0.071
0.123 0.124 0.159
0.624 0.228 2.225*
0.498 0.498 0.498
1.372 0.687 0.718
2.027 3.417 3.177
0.284 0.284 0.284
0.779 0.4OO 0.411
1.907 3.497 3.000
0.180 0.180 0.180
0.497 0.269 0.267
2.037 3.690 2.770
old rate limit
new rate limit
stopping distance
or angle
* Exceeded 2' criterion
Pay-
Load
32K
looK
250K
ARM CONFIGURATION #2 ( -48,118,-118,-26,-39,3 ):
X
Command Directions
Y Z R P Y
feet/sec and feet degrees/sec and degrees
0.153
0.361
1.445
0.100
0.231
1.283
0.071
0.177
1.161
0.153 0.153
0.349 0.287
1.364 0.975
0.100 0.100
0.223 0.183
1.215 0.874
0.071 0.071
0.171 0.141
1.101 0.831
0.498 0.498 0.498
0.195 0.502 0.935
0.101 0.229 0.445
0.284 0.284 0.284
0.112 0.291 0.542
0.101 0.229 0.435
0.180 0.180 0.180
0.730 0.193 0.361
1.206 0.232 0.444
271
The amount of additional computer time required to compute this rate limit was
negligible for the simulation, which is already numerically intensive. This is not an
indication of its impact on some other manipulator, although the scheme doesn't require
much numerical work provided the inverse of the Jacobian matrix is available.
C. Any conclusions?
Since the tests did produce three runs which exceeded the 2 feet limit, one
conclusion is that further work is needed in better estimating the impulse imparted
between the bodies. However enough runs (33 out of 36, or 92%) not only stopped well
within the limit, but at speeds faster than the present method would allow, which
indicates the potential worth of this form of electronic safety monitoring. The conclusion of
the study conducted to date is that further investigation is warranted to increase accuracy
of the impulse estimation. If this can be improved and remain numerically simple, the
algorithm will be a useful tool in speeding-up tasks for space robots.
IV. REFERENCES
[ 1 ] "SRMS Manipulator Arm Payload Handling Capability", SPAR Aerospace memo
SPAR-RMS-TM.211, Geoff Marks, August 1979, SPAR Aerospace Limited, 1700 Ormont
Drive, Ontario, Canada M9L 2W7
[2] "Report on an SRMS Stopping Distance Study Including Transient Arm Effects",
SPAR Aerospace memo SPAR-RMS-TM.601, J. Dueckman, February 1983, SPAR
Aerospace Limited, 1700 Ormont Drive, Ontario, Canada M9L 2W7
[ 3 ] "Proposed Joint Rate Limit Algorithm for Heavy Payloads", Lockheed Engineering
& Sciences Co. memo LEMSCO-24097, D. McDermott, Oct. 1987, Lockheed Engineering
& Sciences Co., 2400 Nasa Rd. 1, Houston, TX 77258
272


Optimal payload rate limit algorithm for zero-G manipulators

Abstract

Similar works

Full text

Available Versions

NASA Technical Reports Server