|
Table 2.1: A review of the commercial CIR systems available on the market
Synchronization Mechanisms
To ensure the timely exchange of information between the robots, a synchronization
mechanism has to be implemented. Synchronization on the implementation level mainly
requires quantifying time delay (Fortell et al. 2009), generating operation master signals
(Hashimoto & Ohya 2008) and designing data structures for triggering signals (Graf et al.
2006b). For instance, KUKA applied the IEEE 1588 standard (Eidson 2006) to synchronize
multiple robot controllers (Gerstenberger et al. 2005). However the implementation side
of the synchronization is only valid in light of the signal model behind it. The most widely
used is the master
/slave model, where a master robot controller or a master controller
generates a signal to synchronize all other controllers. It essentially o
ffers a hierarchal
control scheme, where the slaves’ movements are coupled to the master. This corresponds
to the second and third architecture type in Figure 2.8.
2.6 Discussion
2.6.1 The position
/force dilemma
Unique among measured signals in a robotic system, forces and positions are mutually
exclusive. Regardless whether they are defined at the robot’s end-e
ffector or at the joints.
Other correction signals, for instance video camera or laser sensors, are eventually trans-
lated to a position o
ffset that exhibits no implicit effect on the source signal, making the
relationship of a unilateral nature. In case of force signals, the derived position signal loops
back to influence that force. This is only logical in light of Newton’s second law of motion
(Newton 1846, P. 83) which dictates this relationship. Consequently, under constrained
conditions where interaction between manipulators and the environment occurs, it is im-
possible to define the shape of one signal without implying the shape of the other. This is
analogous to the voltage
/current interdependency in electrical engineering (Nagchaudhuri
& Garg 2001). Hence, the overall objective here is to achieve a predefined tracking
performance simultaneously for both positions and forces of the object being manipulated.
This latter force
/position dependency defines the context in which most research in robotic
interaction takes place. Researchers have argued that issues in cooperative manipulation
are limited to control issues, if the forces at the interaction surfaces can be determined
(refer to section 2.4).
34
2.6 Discussion
Despite that, commercial robot manufacturers introduced geometrically coupled systems
capable of executing synchronized movements in real-time through exchanging positional
data (position, velocity and acceleration) as detailed in section 2.5. This however addresses
only the first part of the aforementioned dilemma, namely the position. In an ideal situation
and after exact calibration, motion generated from an o
ff-line simulation would be identical
to that performed by the manipulators. This is unfortunately not the case. Far from perfect,
actual environmental conditions deviate from those in the virtual environment, which is
eventually translated into positional discrepancies between them (refer to section 2.2.2).
Additionally, dynamic e
ffects due to gravitational or inertial forces which ultimately
cause deviations from the generated trajectories are rarely taken into consideration during
programming. Since industrial robots were mainly utilized for purely positioning tasks,
the mechanical structure was kept as sti
ff as possible to (re)produce maximum positioning
accuracy (Bilbao et al. 2005, P. 7) thus implicitly reducing their adequacy for constrained
tasks. Given the highly sti
ff nature of environment, those deviations are readily translated
into large forces on both robots and environment. Both types of interaction; (a) object-
manipulators and (b) object-environment, occurring simultaneously in a tightly coupled
cooperative operation develop into a complex set of problems which ultimately results in
a case where disregarding the forces is practically impossible.
2.6.2 Robot architectures
Robot architectures arise from the interplay between hardware, software and communi-
cation components in a robotic work-cell. The specific order in which the components
are arranged relative to each other and the information exchange between them dictate
the functionality of the system. Hence, architectures define the boundaries and possibil-
ities expected from a robotic system based on the underlying design of the respective
components and their relation to each other w.r.t. signal flow. Although a body of work
exists on robot architectures, no unifying or coherent definition of a robot architecture is
available (MacDonald et al. 2003). Since their conception and worldwide proliferation in
production facilities, industrial robots have retained a relatively rigid architecture. This
can be mainly attributed to the repetitive and constant nature of the task types assigned
to industrial robots i.e. handling and welding (International Federation of Robotics -
IFR Statistical Department 2007, P. 17). The two main aspects that characterize classical
architectures are a weak information flow and lack of sensor-based programming and
operation. Both aspects significantly a
ffect the programming and operational capability of
any robotic work-cell.
Information flow or exchange in a robot architecture could be labeled weak if information
flows predominantly in one direction i.e. unidirectional. In a classical architecture, the
simulation environment allows the user to define the task in an o
ff-line manner and
automatically generate code for the robot controller. Given that on-line adaptation is
inevitable due to the di
fferences between the virtual world and the real world, the robot
behavior has to be correspondingly modified. During operation the user interface allows
35
2 Literature Review
the user to send supervisory signals or operations setting to the work-cell. It also displays
the actual status of the robot during operation. However, data pertaining to the behavior
of the robot generated from on-line adaptation is scarcely fed back to the simulation
environment. Consequently, this prevents the simulation environment from updating
the virtual world with information gathered in the real world. Therefore, in spite of the
research e
fforts aimed in this direction (as mentioned in section 2.2.2), off-line and on-line
programming methods rarely overlap.
commercial
robot
controller
simulation environment
program
commercial
robot
controller
user-
interface
program
synchronization
MASTER/SLAVE
MASTER/SLAVE
user-
interface
binary
information
status
binary
information
dedicated
(robot)
controller
MASTER
status
Do'stlaringiz bilan baham: |
