[Avery Andrews 940802.1547]
Some preliminary thoughts on some of the issues that the nu14/14deg
programs are intended to address. Other vaguely relevant ideas highly
welcome.
In the motor control literature, the problem of excess degrees of
freedom seems to attract a lot of attention (to get you hand at a
position with an orientation involves 6 dfs, the shoulder, elbow and
wrist joints provide 7), but it seems to me that this problem is
fairly trivial under PCT, at least for the human arm (robot manipulators
might well be a different story): we aren't trying to solve for inverse
kinematics analytically, and the excess df's can be left in the
care of simple control systems (like the one in my nu14.c which tries
to apportion the total roll at the wrists between the shoulder and
elbow-roll df's.
Less straightforward, I fear, is the problem of too few df's at the
higher levels, and the limited ranges within which the available ones
operate. Consider the problem of moving a full container liquid
around, perhaps from one place to another. At least two control-systems
must successfully interact. One is responsible for keeping the
container level, so the liquid doesn't spill. This will be achieved
to a considerable extent by adjustments at the wrist pitch and yaw dfs,
as well as 'wrist roll' (the sum of roll from the elbow and shoulder
joints). But these df's have limited range, & can't always cope with
the attitude disturbances required to reach certain positions (hold a
glass in the normal way, and lower your hand-eventually the glass will
have to tip). The other system(s) is/are responsible for attaining
the desired final position.
Since, the first, @qt(attitude) system can't cope with all of the
disturbances that might be introduced by the second @qt(position)
system, there are potential conflicts. nu14 and 14deg deal with these
conflicts in a highly unsatisfactory manner: the hand position is
attained anyway, leaving a persistant error from the hand pitch and
yaw control system.
My initial conjecture is that conflicts of this kind often are rather
poorly handled, but at least in these cases of manual manipulation
people normally develop fairly smooth strategies for dealing with them.
One consideration that applies to this case is that the hand attitude
reference is one that needs to be maintained at all times (to some
degree of accuracy, depending on the cirucmstances), while the
positional reference is what one might call a @qt(some-time goal):
it doesn't need to be attained immdiately, tho sometime soon would
be good. Therefore it is appropriate for the orientation control system
to either overwhelm or somehow inhibit the position system (I haven't
managed to build this into nu14 in a way that looks good on the screen,
but I haven't really tried very hard yet).
But we want the positional goal to be achieved eventually, so what seems
to happen is some combination of grip or postural adjustments (including
perhaps fairly dramatic ones, such as putting the thing down, getting
a chair and chair and dragging it into position, then picking the thing
up again and trying again to put it into the desired position.
So how is all of this going to work. My intuition is that the
straightforward position-control systems as in Little Man 2 won't
really do the job (here the new position-reference is fed thru slowers
so that the hands move to the desired position). One consideration
is that we want to control the maximum speed and accelaration of, say
a glass of liquid, so that it won't slop out of the container. Another
is that we may need to plot a course that will avoid obstacles. Another
thing I think grownups like to avoid doing is sweeping objects rapidly
and low across surfaces (initially, the motion of the glass or cup is
mostly normal to the surface of the table, the lateral component
building up as the height increases).
A possibility might be something like this. Suppose the hand is at
a position, in some attitude (holding a cup, let's say). A new
position-reference for the hand-cup is established, in 'sometime mode'
(there would be other modes in which you wouldn't care at all about the
cup, and just get the hand to somewere ASAP). The discrepancy between
actual and reference hand position induces an error signal (vectorial,
a presume, hopefully frequency-coded multiplexing isn't relevant here).
I'd suggest that this error signal gets transformed into a hand-velocity
reference vector. In this simplest case, this would point in the same
direction as the error-vector, but have its length limited and
temporally smoothed (it starts small, builds up slowly (I recall from
somewhere that cubic polynomials are good for this sort of things),
levels off, then winds down slowly as the reference position is
attained).
But other systems can modify this velocity vector in various ways. If
the task is to shift the cup from one point from another on the table,
some adult system makes the vector point up instead of sideways, until
a prudent altitude is attained. In the presence of obstacles, the
direction will be modified to avert collision. If too much sloshing
is observed, the vector will be shortened. As the wrist-systems
approach their limits, the vector is also shortened, reduced to zero
at the limits (if hand orientation doesn't matter, this connection
is disabled).
Well, that's all for this, how.
Avery.Andrews@anu.edu.au