If J were a square, full rank matrix, a unique
could be
found for each
by Gaussian elimination.
However, J is generally neither square, nor full rank.
In fact, as we will see later, it is an advantage in a real system
to have many more visual feature values than controlled DOF's yielding an
over-determined system.
Several methods exist for finding approximate solutions
, to such a system under various
optimality criteria (e.g., normal equations or SVD based methods).
We use the numerically stable QR factorization method,
projecting a least-squares optimal solution onto the control space.
Mapping this Jacobian based control scheme onto a real robot involves a number of other issues, related to the low level control of the robot arm. Two direct approaches to this are:
We use a two level approach, that instead of
providing only discrete moves to a specified position, allows
asynchronous updating of a joint position ``set point''
to which the robot servos
under some simple control law (e.g. damped proportional control)
using the standard
joint feedback controllers as an inner, fast control loop. The visual
controller then controls an idealized robot. We use a mixed
position-acceleration type control, setting global maximum joint
velocities, and doing the control on a system where
is modeled
as the tensioning of a spring (or rubber band) in joint space.
This is illustrated in Fig. 5.1.
On
the Utah/MIT hand, an appropriate set point controller comes as part
of the hardware. On the Puma, the set point controller was
implemented through primitives provided by RCCL [Lloyd, 1994]. By
running the visual control loop fast enough to keep the set point
just ahead of the robot, we are able to achieve smooth trajectories by
essentially ``leading'' the robot around. By varying the lead
distance of the setpoint as well as the velocity and acceleration parameters,
we get a mixed mode controller
having some of the advantages of both discrete and continuous
control modes.
Figure 5.1: Visual feedback system with inner loop joint controllers
The motor commands
in eq. 5.3
are used to generate
a desired joint space trajectory
We achieve smooth visual servoing movement,
rather than look and move,
by queuing the next trajectory segment before the current one is
finished, see Fig. 5.2. Note that
in eq. 5.3 is updated by
eq. 4.8 in each step. This serves
to synchronize the model acquisition with the control, and causes
the model to be estimated on an adaptive size mesh; dense when the
visual-motor mapping is highly non-linear, sparse when it is near linear.
Similarly the visual cycle frequency varies, lightening the
computational load when possible.
Figure 5.2: Time frames in a visual cycle.
We run the vision feature tracking and visual feedback algorithm on a distributed network of Unix workstations. The worst case delays due to Unix process scheduling and Ethernet communication contention are extremely long from a control systems viewpoint. The setpoint method has the advantage in this case over a simple velocity servoing schema. Even if sensory input is completely shut out, all that happens is that the robot goes to the next setpoint, and comes to rest, as in the look and move approach. In more usual situations, we switch from a smooth servoing mode during transportation phases, through an intermediate phase which slows down the robot somewhat during visual measurements to increase their accuracy, to a pure iterated look-and-move behavior for the highest precision moves.
Figure 5.3: Structure of the adaptive differential visual feedback
control algorithm, and the time
frames in which each part runs. Arrows between modules indicate the
direction of information transfer.
The structure of the control algorithm we have implemented is shown in Fig. 5.3. In addition to the modules shown, there are real-time visual feature trackers that provide information about the current visual state. The system is implemented as a Parallel Virtual Machine (PVM) [Beguelin et al., 1993] distributed program, running vision processing, and visual space control routines on an 8 processor SPARCserver 2000 multiprocessor, and robot control on a SPARCserver 330.