Note: Descriptions are shown in the official language in which they were submitted.
CA 02598051 2007-08-15
WO 2006/088966 PCT/US2006/005352
SYSTEM AND METHOD OF SYNCHRONIZING AND COMMUNICATING WITH
MECHATRONIC DEVICES
RELATED APPLICATIONS
[0001] This application claims the benefit of, and incorporates by reference
in
their entirety, U.S. Provisional Application No. 60/653,717, filed February
16, 2005 and
U.S. Provisional Application No. 60/679,953, filed May 10, 2005.
BACKGROUND OF THE INVENTION
Field of the Invention
[0002] The present invention relates to prosthetic and orthotic limbs in
general
and, in addition, a system and method of configuring and synchronizing the
adaptive
control systems of prosthetic and orthotic devices on a patient.
Description of the Related Art
[0003] Prosthetic and oi-thotic devices, such as are attached to a human limb,
have benefited from advances in electronics. Electronically controlled
prosthetic or
orthotic devices, which may be generally referred to as "mechatronic" devices,
for
example, prosthetic laiees, can provide safer and more natural movement to
patients who
are equipped with such systems. However, advances in electronics appear to
have
outpaced the advances in control systems. Thus, control systems for prosthetic
systems
can benefit from intelligent architectures.
[0004] Further, the proliferation of electronic control systems for prosthetic
and orthotic -systems has created a need for systems and methods of synchi-
onizing
multiple devices which are worn by a single patient, e.g., a prosthetic knee
and a
prosthetic ankle. Operating in isolation from each other, multiple control
systems may
fail to provide the patient with stable, coordinated movement. In addition,
independent
configuration of multiple prosthetic devices can be inconvenient. Thus, it is
desirable to
have systems and methods of configutation, coimnunication, and syncluonization
between such control systems. Further, it is desirable to have systems and
methods of
adding, replacing, or augmenting portions of the software in such control
systems.
Suirunary of the Certain Embodiments
[0005] After considering this discussion, and particularly after reading the
section entitled "Detailed Description of Certain Embodiments" one will
understand how
the features of this invention provide advantages that include providing a
prosthetic or
CA 02598051 2007-08-15
WO 2006/088966 PCT/US2006/005352
orthotic control system that provides more natural and comfortable movement to
its users
and enabling a more convenient and intuitive 'configuration, addition,
replacement, or
auginentation of control system software. '
[0006] One embodiment is a system for controlling motion of a human linlb.
The system may include a plurality of mechatronic devices. Each of the
plurality of
mechatronic devices is in communication with at least one other of the
plurality of
mechatronic devices. At least one of the mechatronic devices controls an
actuator. In
one such embodiment, at least one of the plurality of mechatronic devices is
configured to
generate a control state for at least one other of the plurality of
mechatronic devices based
on the comnlunicated data. In one embodiment, the communicated data is used to
synclironize the mechatronic devices. In one embodiment, each of the
mechatronic
devices comprises an artificial joint. In one embodiment, at least one of the
plurality of
mechatronic devices comprises a prosthetic .knee and at least one of the
mechatronic
devices comprises a prosthetic aillcle.
[0007] Another embodiment is a i'nechatronic device for controlling motion
of a human limb in cooperation with at least one other mechatronic device. The
mechatronic device includes a connnunication interface configured to
coininunicate data
with the at least one other mechatronic device, a sensor configured to obtain
a value
indicative of at least one motion parameter, of the limb; an actuator
configured to affect at
least one motion parameter of the mechatronic device, and a processor
configured to
activate the actuator based on the received coiininunicated data and the at
least one motion
parameter value. In one enibodiment, the communicated data may include the
parameter
value obtained from the sensor. In another, embodiment, the communicated data
may
include state machine data received from the other mechatronic devices: In yet
another
embodiment, the conununicated data may include configuration data received
from the
other mechatronic devices.
[0008] Another embodiment is a mechatronic device for controlling motion of
a human limb in cooperation with at least one other mechatronic device. The
mechatronic device includes a communication interface configured to
communicate data
with the at least one other mechatronic device, and a processor configured to
generate a
control state of the at least one other mechatronic device. The processor is
filrther
configured to conununicate data associated with the control state through the
coinmunication interface. The mechatronic device further includes an actuator
controlled
by the processor so as to effectuate movement of the human limb. In another
2
CA 02598051 2007-08-15
WO 2006/088966 PCT/US2006/005352
embodiment, the coinmuiiicated data may include software that when executed by
the
processor is configured to affect the selection of the control state. In one
embodiment,
the conununicated data includes data obtained by the at least one sensor of
the other
mechatronic device. In one embodiment, the coininunicated data includes
configuration
data obtained by the at least one sensor of the other mechatronic device. In
one
embodiment, the processor is further configured to determine at least one
actuator control
colninand based on the control state, and wherein the corrununicated data
includes the at
least one actuator control coininand.
[0009] Another embodiment is a method of synchronizing a first mechatronic
device with a second mechatronic device. The method includes connnunicating
data
from the second mechatronic device to the first mechatronic device. The method
further
includes generating a control state in resporise to the received data. The
method further
includes controlling an actuator on the secon& mechatronic device based at
least in part on
the control state. In one enlbodiment, the method further includes generating
a coirunand
to control an actuator of the second mechatronic device in response to the
control state.
In one embodiment, the method further incllides generating a command to
control an
actuator of the first mechatronic device in response to the communicated data.
In one
embodiment, the received data includes sensor data received fi=om the second
mechatronic
device. In another embodiment, the received data includes at least a portion
of
infonnation indicative of the control state. In yet another embodiment, the
received data
includes computer software and the control state is perfoi-ined at least
partly by executing
the computer software.
[0010] Another embodiment is a system for controlling motion of a device
associated with a limb. The system includes,a mechatronic device. The system
further
includes a sensor associated witli a human limb which provides motion
parameter data to
the mechatronic device. The mechatronic d'evice uses the motion parameter data
for
synchronization. In one embodiment, the sens'oi- receives signals from the
human neivous
system. In one einbodiment, the sensor receives signals from a sensor
associated with a
sound limb. In one embodiment, the motion parameter data is used for
synchronization
with another mechatronic device. In one such embodiment, the other mechatronic
device
provides motion paraineter data to the rnechatronic device.
[0011] One embodiment is a method of synchronizing a computing device
with a a device associated with a limb. The method includes conununicating
data
between the mechatronic system and the computing device, storing the data on
the
3
CA 02598051 2007-08-15
WO 2006/088966 PCT/US2006/005352
computing device, generating a control state on the mechatronic system in
response to the
data, and controlling an actuator on the second mechatronic system based at
least in part
on the control state.
[0012] Another embodiment is a mechatronic system attached to a human
body. The device includes a sensor configured to provide data indicative of
movement of
the human body. An actuator is configtn=ed to control movement of at least a
portion of
the human body. A processor is configured to execute instructions configured
to control
the actuator based on the sensor data. A conununication interface is
configured to
communicate data with a data source. The processor is further configured to
receive at
least a portion of the instructions from the data source. In one embodiment,
the
mechatronic system may include a separation of the processing, sensing,
actuation, and
communications in two or more mechatronic devices.
BRIEF DESCRIPTION OF THE DRAWINGS
[0013] Figure 1 is a block diagram that illustrates one embodiment of a system
including a number of mechatronic devices.
[0014] Figure 2 is a block diagram illustrating in more detail one embodiment
of a mechatronic device in cominunication with additional devices in one
embodiment of
the system of Figure 1.
[0015] Figure 3 illustrates a user interface of one embodiment of an
instrumentation program for use with a mechatronic device.
[0016] Figure 4A is a schematic block diagram of an exemplary embodiment
of the system of Figure 1 that includes a prosthetic l:nee and a prosthetic
ankle.
[0017] Figure 4B is a schematic block diagram of an exemplary embodiment
of the system of Figure 1 that includes a prosthetic knee and a prosthetic
foot.
[0018] Figure 4C is a schematic block diagram of another exemplary
embodiment of the system of Figure 1 that includes a prosthetic knee, a
prosthetic foot,
and a master device.
[0019] Figure 4D is a schematic block diagrani of another exemplary
embodiment of the system of Figure 1 that includes a prosthetic knee and a
prosthetic foot
in which the prosthetic foot includes one or more state machines for
controlling both
devices.
[0020] Figure 5 is a block diagram illustrating one embodiment of a system
including mechatronic devices in conununication with personal and networlc
coinputing
devices.
4
CA 02598051 2007-08-15
WO 2006/088966 PCT/US2006/005352
[0021] Figure 6 is a flowchart illustrating one embodiment of a method of
syncluonizing configuration or calibration data of the mechatronic device with
the
network computing device.
[0022] Figure 7 is a flowchart illustrating one embodiment of a method of
replacing or auginenting software on the mechatronic device.
DETAILED DESCRIPTION OF CERTAIN EMBODIMENTS
[0023] The following detailed description is directed to certain specific
embodiments of the invention. However, the invention can be embodied in a
multitude of
different ways. In this description, reference is made to the drawings wherein
like parts
are designated with like numerals throughout.
[0024] The terms "prosthetic" and "prosthesis" as used herein are broad terms
and are used in their ordinary sense and refer to, without limitation, any
system, device or
apparatus that may be used as an artificial substitute or support for a body
part.
[0025] The term "orthotic" and "orthosis" as used herein are broad terins and
are used in their ordinary sense and refer to, without limitation, an_y
system, device or
apparatus that may be used to support, align, prevent, protect, coiTect
deformities of,
inunobilize, or improve the function of parts of the body, such as joints
andlor limbs.
[0026] A device associated with, a limb is any device that may be used to
assist the limb in some function. For instance, a prosthetic device is a
device associated
with a limb. A prosthetic device may replace a poi-tion of or the entire limb.
Altei7latively, an orthotic device is a device associated with a limb. An
orthotic device,
for instance, supports or aligns the liinb. Additionally, other devices, such
as articles of
clothing or sporting goods equipment, may be devices associated with a limb.
For
instance, a shoe is a device associated with a limb because it assists the
user of the shoe to
use the foot, for example, to walk or run. Similarly, a ski boot is a device
associated with
a limb because it assists the user of the ski boot to use the foot, for
example, to ski.
[0027] The tenn "mechatronic" as used herein is a broad term and is used in
its ordinary sense and refer to, without limitation, any system, device, or
apparatus that
includes an electronically controlled device~ associated with a limb,
including a prosthetic
or orthotic device. Such devices may include one or more of a sensor, an
actuator, or
processor.
[0028] The tern'i "bionic" as used, herein is a broad term and is used in its
ordinary sense and refer to, without limitation, any system, device, or
apparatus that
includes an electronically controlled device integrated to replace or ei-
Aiance anatomical
CA 02598051 2007-08-15
WO 2006/088966 PCT/US2006/005352
structures or physiological processes. Bionic may also include electronic or
mechanical
smart structures or systems integrated to replace or enhance anatomical
structures or
physiological processes. For exanlple, a bionic may include a mechatronic
device such as
prosthetic or orthotic.
[0029] LTsers of prosthetic or orthotic devices often may need more than one
device. For example, a trans-femoral amputee may require a conibination of a
mechatronic knee and a mechatronic ai-Acle or foot. Typically, more natural
movement
may be achieved when these devices are coordinated. Where two or more of these
devices are electronically controlled devices, improved coordination, e.g.,
from a more
natural motion, can be achieved by electronic interface and coordination
between the
devices. Figure 1 is a block diagram that illustrates one embodiment of a
system 100
which includes multiple mechatronic devices. In one embodiment, a particular
mechatronic device includes one or more sensors, a controller, and one or more
actuators.
However, it is to be recognized that in other embodiments a particular
mechatronic device
may include, for example, only sensors, sensors and a controller, one or more
actuators,
actuators and a controller, or only a controller. In one embodiment, the
system may
include a master device 112. In one embodiment, the master device 112 directs
control of
the entire system 100. In one embodiment, the master device 112 is a
mechatronic device
that has a control system which incorporates a state machine. The master
device 112 may
fully or partially control a slave device 114. .Inforination on state changes
or direct
actuation conunands may be sent to components of the system 100, such as the
slave
device 114. Embodiments of each of the devices in the system 100 may include
prosthetic lcnees, prosthetic anlcles, or other electronically controlled
prosthetic or orthotic
devices. For example, an oi-thotic device such as a brace may include a sensor
for
measuring laiee motion.
[0030] In one embodiment, the slave device 114 may only include a portion of
the software or hardware needed to control the slave device 114. The slave
device 114
may thus be wholly or partially dependent on receiving state information and
coininands
fiom the master device 112. In one embodiment, the slave device 114 may
receive sensor
data from the master device 112, or another slave device 114. The slave device
114 may
also send sensor data to other devices 112, 114, 116, or 118. In one such
embodiment,
the slave device 114 includes one or more sensors but does not include an
actuator.
[0031] The system 100 may include an obseivation device 116 that is
configured to monitor or control one or more of the other devices in the
system 100. In
6
CA 02598051 2007-08-15
WO 2006/088966 PCT/US2006/005352
one embodiment, the observation device includes a wristwatch, or aim mounted
device,
that provides status or otlier information regarding the operation of devices
in the system
100. In one embodiment, the status information is updated in real-time. In
another
embodiment, the observation device 116 may have controls configured to affect
the
operation of the system 100. In one such embodiment, the observation device
116
includes only a controller that is configured to receive sensor data and/or
send control
data to other mechatronic devices in the system 100. For example, in one
embodiment,
the master device 112 may be a prosthetic knee and the observation device 116
may be
used for activation or to provide hints as to different use modes, e.g.,
walking, bicycling,
etc.
[0032] The system 100 may also include a configuration device 118 that is
adapted to control one or more of the other devices in the system. In one
embodiment,
the configuration device 118 is in direct conuiiunication with the master
device 112. The
master device 112 coordinates coinmunication of configuration data with other
devices,
e.g., the slave device 114 or the obseivation~ device 116. In other
embodiments, the
configuration device 118 may be in direct conununication with all or any
subset of the
devices 112, 114, 116.
[0033] Each of the devices 112, 114, 116, and 118 of the system 110 may
communicate using a bionic data bus (BDB) 120. The BDB 120 may comprise any
data
conuziunications physical layer, including those laiown in the art. For
example, the BDB
120 may include one or more of the following communications layers: a remote
modem,
Ethernet (IEEE 802.3), Token Ring (IEEE 802.5), Fiber Distributed Datalink
Interface
(FDDI) Asynchronous Transfer Mode (ATM), Wireless Ethetnet (IEEE 802.11),
Bluetooth (IEEE 802.15.1), or infrared interfaces including IRDA. The BDB bus
may
also include a peripheral interface bus including Universal Serial Bus (USB),
IEEE 1394,
Peripheral Component Intercoimect (PCI), or other peripheral buses such as
those lrnown
in the art. In addition, the BDB 120 may include networks such as an Intranet,
a Local
Area Networks (LAN), a Wide Area Network (WAN), or the Intei7iet. The BDB 120
may include additional protocols such as internet protocol (IP) or
transmission control
protocol (TCP).
[0034] It will be recognized that while, in one embodiment, a mechatronic
device may operate as one of the devices 112, 114, 116, and 118, in other
embodiments of
the system 100, a particular mechatronic device may be configured to operate
in different
modes or roles as one or more of the devices 112, 114, 116, and 118. In one
embodiment,
7
CA 02598051 2007-08-15
WO 2006/088966 PCT/US2006/005352
the particular mechatronic device may be configured to automatically act as a
particular
type of device based on data exchange with other devices in the system 100.
For
example, one embodiment of the system 100 may include a prosthetic laiee, a
prosthetic
ai-Acle, and a wrist-attached monitor. Embodiments of prosthetic lmees may
include those
illustrated in U.S. Patent No. 6,610,101, filed March 29, 2001, and issued on
August 26,
2003; U.S. Patent Application No. 11/123,870, filed May 6, 2005; and U.S.
Patent
Publication No. 2005-0283257, filed on March 9, 2005; each of which is
incorporated by
reference in its entirety. Embodiments of prosthetic aiikles may include those
illustrated
in U.S. Patent Publication No. US 2005-0197717, filed February 11, 2005, and
which is
incorporated by reference in its entirety.
[0035] After exchanging identifying data over the BDB 120, the knee may
configure itself to operate as the master device 112, the ankle may configure
itself to
operate as a slave device 114, and the monitor to configure itself as an
observation device
116. In another embodiment of the system 100 that includes only the aiilele
and the wrist
monitor, the ankle may configure itself as the master device 112 and the
monitor as the
observation device 116.
[0036] In one embodiment, devices may include a configtiration database.
The database may contain data relating configurations of the system 100 with
the role of
the device. For exainple, the anlcle device may include data indicating that
the ankle
should configure itself as the slave device 114 when the system 100 includes a
knee
prosthetic, but should configure itself as the master device 112 in other
configurations.
[0037] It will be further recogiiized that in some embodiments, the system 100
may include one or more of each of the slave device 114, observation device
116, and
configuration device 118. Further, in some embodiments, multiple master
devices may
be configured such that the devices each control groups of prosthetics, e.g.,
one master
device 112 for a group of arin based mechatronic devices and a second master
device 112
for a group of leg based mechatronic devices. In such an embodiment, the
observation
device 116 may display inforination related to some of the master and slave
devices 112
and 114. In another embodiment, each observation device 116 may display
infornlation
related only to a single master or slave device 112 or 114.
[0038] The master devices 112 may communicate over the BDB 110 to share
data or otherwise coordinate operation of the system 100. In one such
embodiment, each
of, e.g., ann and leg mechatronic devices may operate as the master device 112
with
respect to a group of devices. For instance, the laiee may operate as the
master device
8
CA 02598051 2007-08-15
WO 2006/088966 PCT/US2006/005352
112 with respect to an ankle prosthesis and a shoulder mechatronic device may
act as a
master device 112 to an elbow slave device 114. Continuing with this exemplary
embodiment, with respect to knee master device 112, the ai-dcle may operate as
a slave
device 114.
[0039] It will be recognized that the devices 112, 114, 116, 118 as described
herein refer to roles or functional descriptions of one mode of operation of a
mechatronic
device. In some embodiments, a mechatronic device may be a hybrid device,
e.g., one
that acts as a slave device 112 under the influence or direction by another
master device
112, but which also maintains a distinct state machine. Further, other
embodiments may
include mechatronic devices that operate as combinations of any of the devices
described
herein.
[0040] Figure 2 is a block diagram illustrating in more detail one embodiment
of a mechatronic device 202 in conununication with additional devices 204 and
206 in
one embodiment of the system 100 via the BDB 120. The device 202 may include a
processor and memory configured to execute softlvare for controlling the
operation of the
device.
[0041] In one einbodiment, the software includes a state machine module 210,
a hardware abstraction module 212, a dynanlic learning module 214, a
configuration
module 216, and a BDB module 218. It will be recognized that each of the
modules 210,
212, 214, 216, and 218 may include various sub-routines, procedures,
definitional
statements and macros. Each of the modules may be separately compiled and
linked into
a single executable program. The description of each of the modules is used
for
convenience to describe the fiinctionality of one embodiment of a system.
Thus, the
processes that are performed by each of the modules may be redistributed to
one of the
other modules, combined together in a single module, or made available in, for
example,
a shareable dynanlic link library. In some embodiments, the modules may be
executed
concurrently or in parallel as distinct tlireads or processes. The modules may
be produced
using any suitable computer language or enviroiunent, including general-
purpose
languages such as C, C++, Java, or FORTRAN.
[0042] Each of the modules 210, 212, 214, 216, and 218 may communicate
via any suitable method such as are la-iown in the art. In one einbodiment,
the modules
may conununicate using shared data structures such as are described in U.S.
Patent
Publication No. 2005-0283257, filed on March 9, 20054, which was previously
incorporated herein. In one embodiment, the shared data structure may include
portions
9
CA 02598051 2007-08-15
WO 2006/088966 PCT/US2006/005352
that are available for access tlirough the bionic data bus module 218 to other
devices 204
and 206 in the system 100. In such an embodiment, portions of the data in the
shared
structure may be cormnunicated on the BDB 120.
[0043] In one embodiment, the observation device 116 may be a personal or
server computer system configured to perfonn diagnostic fiulctions of other
devices in the
system 100. In one embodiment, the observation device 116 may be configured to
receive and update the contents of shared data stnictures, such as described
above,
through the bionic data bus module 218.
[0044] The state machine module 210 typically includes high level,
application or device specific instructions. The state machine module 210 may
be
generally described as having the intelligence of the device. The state
machine module
210 of a particular embodiment of a mechatronic device may be configured to
operate as
the master device 112, the slave device 114, the obseivation device 116, or
the
configuration device 118 in various embodiments of the system 100. An
embodiment of
the state machine module 210 may be configured so as to be loaded into
different
mechatronic devices, e.g., different knee hardware, without modification by
using the
hardware abstraction module 212 to interface with specific hardware on a
particular
mechatronic device. One exemplary embodiment of a state machine module 210 is
described in U.S. Patent No. 6,610,101, filed March 29, 2001, and issued on
August 26,
2003, incorporated above.
[0045] In one embodiment, portions of the state machine module 210 may be
replaced or auginented to provide customized, e.g., activity based, control of
the
mechatronic system 100. For example, software for a specific activity, e.g.,
bicycling or
jogging, may be installed into the state machine module 210 to improve or
customize the
functionality of the mechatronic device, e.g., a prosthetic knee, for the
specific activity.
In one embodiment, the customized control software is installed via download.
In one
embodiment, the downloaded data may be received fi=om the configuration device
118. In
another embodiment, the master device 112 may include a network interface over
which
the customized control software may be received from any other networlced
computing
device. The network interface may comprise a'wireless networlc, e.g., a mobile
telephone
network, or any other suitable computer network, such as those discussed above
in
coiuiection with the BDB 120.
[0046] The hardware abstraction module 212 typically includes low level,
hardware specific code that provides a standardized interface to the hardware
by other
CA 02598051 2007-08-15
WO 2006/088966 PCT/US2006/005352
software modules. The hardware abstraction layer 212 may abstract hardware
such as
sensors and actuators. The hardware abstraction module 212 thus allows other
software,
such as the state machine module 210 to be reused with different sensors so
long as the
sensors each provide data that the hardware abstraction module 212 can
represent in a
standardized form. For example, a particular sensor may provide data via
setting the
value of a hardware register. Another sensor for producing equivalent data may
signal
the processor via an intemipt when the data is updated. The hardware
abstraction layer
212 can be configured to read either sensor and provide the data using a
unifoi7n interface
so that other software layers do not need to be modified if the pai-ticular
sensor changes.
This may be particularly desirable in the system 100 having multiple
mechatronic devices
202, 204, 206. For example, an ai-Acle mechatronic device 202 may be
configured to
receive a sensor value, e.g., a laiee angle, from different types and models
of prosthetic
knees 204. Continuing this example, the hardware abstraction layer 212 of the
ai-Acle
device 202 may provide, in one embodiment, a l:nee angle that is updated every
5
milliseconds regardless of whether the sensor is configured to be polled by
the processor
to receive updates or whether the sensor signals the processor via, e.g., an
intei-rupt
chaiulel. The hardware abstraction layer 212 may also be configured to provide
the lalee
angle value that is upsampled or downsampled to a consistent, accurate value
regardless
of the sensor resolution. For example, the laiee angle value may be
represented with a
value having a resolution of 8 bits, 10 bits or higher. Moreover, the
interface to the data
may be the same regardless of whether the data is coming from the sanie
mechatronic
device 202 or other mechatroiiic devices 204, 206.
[0047] It is to be recognized that some embodiments include mechatronic
devices in which the hardware abstraction layer 212 is configured to
conununicate with a
patient's nervous or muscular system. For example, the actuator may include a
muscle.
In one embodiment, a sensor includes a nerve of the patient's body.
[0048] The dynamic learning module 214 may include a dynamic learning
matrix that updates runtime parameters such as may be used by the state
machine module
212. In one embodiment, the leai-ning module 214 may adapt runtime parameters
to the
cuiTent pace of movement, particular activity, telTain, etc. One exemplary
embodiment of
a leaining module 214 is described in U.S. Patent No. 6,610,101, filed March
29, 2001,
and issued on August 26, 2003, incorporated above.
[0049] The configuration module 216 may be configured to store and maintain
control parameters. The paraineters may be subsequently automatically adjusted
by the
11
CA 02598051 2007-08-15
WO 2006/088966 PCT/US2006/005352
learning module 214 or through the configuration device 118. In one
embodiment, the
data maintained by the configuration module 216 is substantially static. The
configuration module 216 may be configured to conununicate with the BDB 120 to
the
configuration device 118 to send and receive parameter data. The configuration
module
216 may provide a standard interface over the BDB 120 to the configuration
device 118.
In one embodiment, the configuration module 216, e.g., of the slave device 114
is
configured to receive paranleters through other devices such as the master
device 112.
Thus, the components of the system 100 may be configured together through the
configuration device 118 in coinniunication with the master device 112, which
further
conununicates parameters to other devices such as devices 204 and 206 in the
system
100.
[0050] In one embodiment, the abstraction module 212 controls one or more
actuators in a mechatronic system 100. An actuator may include, for example, a
In one
embodiment, this conlprises applying damping through an actuator in, e.g., a
prosthetic
knee. In one embodiment, at least a portion of the abstraction module 212
executes at a
fi=equency that is different from the execution rate of the state machine or
learning
modules 210 and 214. For example, in one embodiment the low level abstraction
module
212 executes with a period of 1 millisecond (ms) while the higher level code
of the state
machine executes with a period of 5 ms.
[0051] The bionic data bus (BDB) module 218 is configured to provide data
communications between devices in the system 100 over the BDB 120. One
embodiment
of the BDB module 218 includes a software interface that abstracts or
standardizes an
interface to the other modules 210, 212, 214, and 216 for conununicating over
the BDB
120 regardless of the particular embodiment of the BDB 120, e.g., regardless
of whether
the BDB includes a networlc or a peripheral bus such as USB.
[0052] The BDB module 218 may provide a layered interface to the BDB 120.
In one embodiment, the layers may correspond to one or more physical channels
provided
by the BDB 120. In other embodiments, the layers may correspond to logical
channels
over the BDB 120. In one einbodiment, the chaimels provided by the BDB module
218
includes a state chaiinel 230, a parameter chatulel 232, a sensor chaiuiel
234, and an
actuation channel 236.
[0053] The state chamiel 230 may be configured to conununicate high
frequency, low volume state machine data between mechatronic devices. In one
embodiment, this data may include data related to the gait cycle of a
prosthetic laiee. The
12
CA 02598051 2007-08-15
WO 2006/088966 PCT/US2006/005352
data may include state data or state change data. For example, in a prosthetic
knee, the
state change may indicate a change in a gait cycle.
[0054] The parameter chaiuiel 232 may be configured to comnlunicate data at
intennediate frequencies and volumes to coininunicate parameter settings
between
devices, e.g., between the configuration device 118 and the master device 112.
The
parameter channel 232 may data may include configuration paraineters such as
are
described in U.S. Patent Publication No. 2005-0283257, filed on March 9, 2005,
which
was previously incorporated herein.
[0055] The sensor channel 234 may be configured to comnlunicate high
frequency, low volume sensor data. Sensor data fiom one device in the system
100 may
thus be shared for use by other devices. This allows for placement of sensors
in locations
that are not physically located in or adjacent to a particular mechatronic
device but which
are physically located within or adjacent to another device in the system 100.
Moreover,
certain sensors may thus be shared to reduce overall cost of the system 100.
Sensors may
include force sensors, battery voltage sensors, or any other sensors as may be
incorporated or attached to any mechatronic device.
[0056] Another charmel may include the actuation chaiulel 236. The actuation
channel 236 connnunicates low volume, high fi=equency data that includes
actuator
control signals. In one embodiment, the master device 112 may send actuator
control
signals over the actuation channe1236 to control an actuator on the slave
device 114. The
data may include data such as position, force, direction, and velocity.
[0057] In addition to communicating with other mechatronic devices, other
electronic devices, e.g., a remote sei-ver computer (not shown), may
communicate with
the mechatronic device via the BDB 120. In one embodiment, the remote server
may
cai7=y out maintenance activities such as diagnosing faults in the mechatronic
device. The
device 202 may conununicate sensor data, state change data, or other data
generated on
the device 202, or devices 204, 206 attached to the device 202 via the BDB
120.
[005S] In one embodiment, a conunon naming convention is used to identify
the data coininunicated on the channels. In one embodiment, the data is
formatted as
structured data using the naming convention, such as in extendible markup
language
(XML). In one embodiment, the naining convention is based on using terminology
analogous to anatomical equivalents. For example, in one embodiment, the
naming
convention includes terminology from the human muscular system for actuator
signals
and from the human nervous system for sensor signals.
13
CA 02598051 2007-08-15
WO 2006/088966 PCT/US2006/005352
[0059] In addition to coinmunicating with other mechatronic devices, other
electronic devices, e.g., a remote server computer (not shown), may
communicate with
the mechatronic device via the BDB 120. In one embodiment, the remote server
may
can=y out maintenance activities such as diagnosing faults in the mechatronic
device. The
device 202 may conununicate sensor data, state change data, or other data
generated on
the device 202, or devices 204, 206 attached to the device 202 via the BDB
120.
[0060] In one embodiment, the remote computer includes instnimentation
software for maintenance or development of the mechatronic device 202. Figure
3
illustrates a user interface of one embodiment of the instrumentation prograni
for use with
a prosthetic knee. The left column displays the names of memory locations,
registers, or
other data that may be monitored on the mechatronic device 202. In the
depicted
embodiment, selecting the name of a monitored item causes the value to be
displayed. In
one embodiment, the displayed value is continuously aiid automatically updated
when
new data is received from the device 202. In one embodiment, the values of the
monitored items may be recorded to a file for later analysis. This analysis
may include
graphical plotting of the data. In one embodiment, the instrumentation program
may also
send commands to the device 202, such as to erase data, reset the device 202,
and update
the software or firinware on the device 202. In one embodiment, the values of
these items
may be modified by a user of the instiumentation program. In one embodiment,
the
insti-umentation program may be configured to restrict the values of the
updated items to
be set within a predeteimined range.
[0061] Figure 4A is a schematic block diagram of an exemplary embodiment
of the system 100 that includes a prosthetic lalee 402 and a prosthetic anlcle
404. When
the system 100 includes an electronically controlled aiikle 404 and an
electronically
controlled laiee 402 there is a risk of instability if the two "intelligent"
components do not
share infoimation or othenvise work in a synchronized manner. The lulee 402
may
include 3 main sensors, an angle sensor, posterior force sensor (PF) and
anterior force
sensor (AF). From the signals of PF and AF sensors, the lcnee 402 can
calculate the
moment in a pylon. The knee 402 can represent the moment as infornlation as to
how
nnich the toe is being loaded and how niuoh the heel is being loaded. From the
calculation on the values fiom PF and AF sensors, the lcnee 402 is also able
to tell if the
foot is placed on the ground and with how much force. The force signals
together with
the angle sensor are evaluated by an algoritluri in the state machine module
to define the
state of the lcnee 402 in a high level loop cycling, in one embodiment, every
5 ms. If the
14
CA 02598051 2007-08-15
WO 2006/088966 PCT/US2006/005352
signals are incorrect or misinterpreted, the laiee 402 caiuiot change states
or function
coiTectly.
[0062] Since the values from the force sensors (bending moment in the knee
fiame) are translated into toe- and heel load values, the alignment of the
foot and
especially the angle of the ankle 404 should be determined. During setup,
certain ranges
and tlireshold values may be set for the loiee 402. If the aligrunent is
changed
considerably after the initial setup, the knee 402 can misinterpret the
information from the
force sensors. The functionality of an electronically adjusted anlcle 404
typically causes
just such a change in alignnient.
[0063] If the ankle 404 can send infonnation on the angle value to the lcnee
with a sufficiently high frequency, the luiee can compensate for the "eiTor "
in force
signals fiom the sensors and the whole system 100 can operate in a more stable
way as
compared to a non-synchronized system.
[0064] The electronic ankle 404 may also be designed to also fit below-the-
laiee amputees. In such a mode of use, the ankle 404 does not need the extra
inforination
from a "colleague" coinponent. The extra infonnation that the knee 402 is able
to
communicate may however simplify the design of the ankle for use by above-the-
knee
amputees.
[0065] In addition, the use of data from the laiee 402 by the afflcle 404 can
provide additional fiinctionality to the system 100. For example, the angle
value of the
ankle 402 can be made accessible to the laiee 404 through the sensor chaiuiel
232 of the
BDB 120. Also if the ankle is offset by some degree (for use with high heels,
for
example), the knee 402 may use the information to fiirther compensate for the
force
sensor measurements. The offset value can be communicated over the parameter
channel
232.
[0066] In one einbodiment, the ankle may include a prosthetic or orthotic
foot,
similar to embodiments disclosed in U.S. Patent Application No. 11/346,600,
filed on
Febniary 2, 2006, titled "SENSING SYSTEMS AND METHODS FOR MONITORING
GAIT DYNAMICS," and incorporated by reference in its entirety, that is
configured to
make and provide toe load and heal load measurements over the BDB 120. In
another
einbodiment, the ankle may include a prosthetic or orthotic foot, similar to
embodiments
disclosed in U.S. Patent Application No. 10/742,455, filed on December 18,
2003, titled
"Prosthetic foot with rocker member," and incorporated by reference in its
entirety, that is
configured to make and provide an angle measurement over the BDB 120.
CA 02598051 2007-08-15
WO 2006/088966 PCT/US2006/005352
[0067] Figure 4B is a schematic block diagranl of an exemplary embodiment
of the system of Figure 1 that includes a prosthetic luiee 402 and a
prosthetic foot 406. In
one embodiment, the knee 402 and the ai-Acle 404 each include a data
communications or
network interface such as an RS-232 port that are in communication with each
other to
define the BDB 120. In another embodiment, the BDB 120 may be implemented via
RS-
485 ports on each of the devices 402 and 406. In one enlbodiinent, the
prosthetic foot
406 includes a joint that allows the foot to adjust to different grades of
slopes. As a
result, the response from the foot 406 will differ from prosthetic feet with a
fixed ai-dcle.
In one embodiment, the knee 402 is controlled based on force measurements that
are
translated into bending moments. From the moment values, the knee 402 manages
state
changes and adjusts the resistance of the laiee based on whether the knee 402
is on level
ground, on different grades of slopes, or on stairs.
[0068] In one embodiment, the lalee 402 may detect that the user is walking
on a sloped surface based on changes in force and moment. Due to bending of
the jointed
foot 406, the foot 406 may adjust to a slope so that the laiee 402 does not
receive force
measurements that are consistent with walking on the slope. Thus, the knee 402
may act
as if the user is walking on level ground when the user is actually descending
a ramp. In
one embodiment, the foot 406 may conununicate its joint angle to the knee 402
when the
angle has changed. In other embodiments, the foot 406 may conununicate the
angle to
the knee at a predetermined rate or when the angle changes by a threshold
amount. In one
embodiment, the knee 402 may request the data from the foot 406 either at
intervals or
response to particular events such as state changes. The lalee 402 may then
use the angle
value to correct the moment calculations (e.g., tbrough a proportional
calculation as a
function of the angle). In one embodiment, the data conununicated from the
foot 406 to
the lcnee 402 may include state machine data. The state machine data may be
used by the
control system of the knee 402 to coordinate movement with the foot 406 and to
better
identify the proper control response based on the additional information fioni
the foot
406, e.g., correcting force sensor readings when the joint of the foot 406 is
bent.
[0069] Data may be coirununicated between the foot 406 and the knee 402
using any suitable protocol such as discussed above with reference to the BDB
in Figure
1. For example, in one embodiment, sensor and control data may be communicated
as a
string of characters over the RS-232 link. In one embodiment, in each program
cycle of
the knee 402, the laiee reads the serial port, parses the string and filters
out the angle
16
CA 02598051 2007-08-15
WO 2006/088966 PCT/US2006/005352
value. The angle value is then translated into a correction value for a slope
detection
routine.
[0070] In another embodiment, data may be cominunicated over the RS-232
layer by a suitable linlc layer protocol such, as the High Level Linlc Control
(HDLC)
protocol. In other enlbodiments, suitable higher level protocols nlay be used.
In one
embodiment, the two RS-232 ports may be connected via simple wire interface.
[0071] In one embodiment, the la-iee 402 may operate as the master device
112 that receives sensor data fi=om the foot 406 and use that data to generate
control
signals that are communicated back to the foot 406. In such an embodiment, the
additional sensor data from the foot 406 may be used to provide control that
is more
robust and enable the lcnee 402 to be better able to anticipate or otherwise
manage state
changes. Moreover, the additional sensor data of the laiee can be used to
extend or
iinprove the control of the foot 406. For example, the load sensors of the
knee 402 may
be able to detect a rapid toe off signal that can indicate initial steps onto
stairs. The
control system of the foot 406 may be configured to use this data to
anticipate and better
detect state changes such as stair ascent or descent.
[0072] In one embodiment, the foot 406 and the knee 402 may also be
configured to share a power source. In such an embodiment, the master device
112, e.g.,
the lcnee, may coordinate power management for both devices. In one
embodiment, the
foot 406 and knee 402 may be designed specifically to operate together.
However, in
other embodiments, any knee 402 and foot 406 that include compatible
mechanical and
comnnuzication interfaces may fonn the system 100.
[0073] Figure 4C is a schematic bloclc diagram of another exemplary
embodiment of the system of Figure 1 that includes a prosthetic lcnee 402, a
prosthetic
foot 406, and a master device 408 operating as a master device 112. The master
device
408 may include any electronic device configured to receive sensor data from
each of the
knee 402 and the foot 406 and provide control signals to the Icnee 402 and the
foot 406
based on that sensor data.
[0074] Figure 4D is a schematic block diagram of another exemplary
embodiment of the system of Figure 1 that includes a prosthetic lalee 402 and
a prosthetic
foot 406 in which the prosthetic foot 406 operates as the master device 112.
In such an
embodiment, the controller of the foot 406 may include one or more state
machines for
controlling both devices.
17
CA 02598051 2007-08-15
WO 2006/088966 PCT/US2006/005352
[0075] Figure 5 is a block diagrain that depicts one embodiment of a system
500 for communicating with a pair of mechatronic devices 202 and 204. In the
depicted
embodiment, the system 500 includes a single netvork computing device 340 in
communication with the mechatronic devices 202 and 204 via a data
communications
networlc 350. Other embodiments include only a single mechatronic device 202,
or more
than two mechatronic devices. In one embodiment, the system 500 includes
additional
network computing devices 341 that are also in conununication with the netvork
computing device 340 via a network 352. In one embodiment, the mechatronic
devices
202 and 204 are configured to communicate with the networlc computing device
340 to
send and receive configuration and calibration data. In one embodiment, the
mechatronic
devices 202 and 204 are configured to communicate with the networlc computing
device
340 to receive executable instructions to augment or replace poi-tions, or
all, of one or
more of the state machine module 210, the hardware abstraction module 212, the
dynaniic
learning module 214, a configuration module 216, the BDB module 218, or any
other
suitable software module of the mechatronic device 202.
[0076] In one einbodiment, the network computing device 340 includes a
network interface 342 in conununication with a processor 344 and a memory 346.
The
network computing device 340 may include a server computer, a personal
computer, or a
mobile computer such as a laptop computer. Iii one embodiment, the network
computing
device 340 includes a personal digital assistant. In another embodiment, the
network
computing device 340 includes a mobile telephone.
[0077] The network interface 342 provides network comiectivity to one or
more computing devices, including the mechatronic devices 202 and 204, via the
networlcs 350 and 352. In one embodiment, the networlc interface 344 to the
networks
350 and 352 includes one or more of, for example, a remote modem, Ethernet
(IEEE
802.3), Token Ring (IEEE 802.5), Fiber Distributed Datalink Interface (FDDI)
Asyncluonous Transfer Mode (ATM), Wireless Ethernet (IEEE 802.11), Bluetooth
(IEEE
802.15.1), or infrared interfaces including IRDA. The network 350 may include
networks
such as the Intei7let, an intranet, Local Area Networks (LAN) or Wide Area
Networlcs
(WAN). As used herein, the networlcs 350 and 352 may include netvork
variations such as
the public Internet, a private network witliin the Intei7iet, a secure
networlc within the
Internet, a private networlc, a public networlc, a value-added network, an
intranet, and the
lilce. In one embod'unent, the networlc 350 includes the networlc 352.
18
CA 02598051 2007-08-15
WO 2006/088966 PCT/US2006/005352
[0078] The processor 344 may be any suitable general purpose single- or
multi-chip microprocessor such as an ARM, Pentium , Pentium IIo, Pentium
III'r',
Pentium IV~", Pentium Pro, an 8051, a MIPSO, a Power PCO, an ALPHAO, or any
other
suitable processor. In addition, the processor 344 may comprise any suitable
special
purpose microprocessor such as a digital signal processor or a progranunable
gate array.
[0079] The memory 346 may include volatile components, such as, for
example, DRAM or SRAM. The memory 346 may also include non-volatile
components, such as, for example, memory or disk based storage. In one
embodiment,
the network computing device 340 includes a server and the memory 346 includes
disk
base storage. In one embodiment, the disk based storage includes a file
seiver.
[0080] In one einbodiment, the mechatronic device 202 includes a storage
card interface 366 to a removably coimected memory. The storage card interface
366
may include an interface to a removable storage card that includes
semiconductor storage
(chips), for example, Random Access Memory (RAM) or various fonns of Read Only
Memory (ROM), that are removablely comiected to the processor 344. Removably
coiulected memory may include memory on any standardized or proprietary device
such
as a memory card, a secure digital memory card, a memory stick, or any other
suitable
removable memory device. In one embodiment, the storage card interface 400 is
configured to interface the processor solid state persistent memoiy such as
FLASH
memory or magnetoresistance RAM (MRAM). In one embodiment, the memory 104
includes a disk drive, e.g., a magnetic, optical, or magneto-optical drive.
[0081] In one einbodiment, each of the mechatronic devices 202 and 204,
includes a processor 360 connected to a memory 362 and a network interface
364. The
processor 360 may include any suitable processor including those discussed
above with
respect to the processor 344. The memory 362 may include any suitable memory
such as
discussed above with respect to the memory 346. The network interface 364
places the
processor 360 in coinmunication with the network 350. The network interface
364 may
include any suitable network interface, including those discussed above with
respect to
the network interface 342.
[0082] Figure 6 is a flowchar-t illustrating one embodiment of a method 600 of
synchronizing configuration or calibration data of the mechatronic device with
the
network computing device 340 of Figure 5. Configuration data may include data
that is
entered by a prosthetist, determined based on predetermined parameters, such
as the
height of a user of the mechatronic device, selected based on experience or
preferences of
19
CA 02598051 2007-08-15
WO 2006/088966 PCT/US2006/005352
the user of the mechatronic device 202, or selected by a designer or
manufacturer of the
mechatronic device, that affects the control system of the mechatronic device
202.
Calibration data may include data that is detei-nined by the control system of
the
mechatronic during operation of the mechatronic device 202. Such data may also
be
generally referred to as control data. The method 600 begins at a block 610 in
which the
mechatronic device 202 establishes communications with the network computing
device
340. Entry or examination of such data could be made tlu=ough a screen display
such as
the one shown in Figure 3.
[0083] Next at a block 620, the mechatronic device 202 syiichronizes one or
more settings with the network computing device 340 of Figure 5. In one
enzbodiment,
the mechatronic device 202 receives configuration or calibration information
related to a
user of the particular mechatronic device 202. In another embodiment, the
mechatronic
device 202 sends configuration or calibration data to the network computing
device 340.
In one embodiment, the synchronized configtu=ation and calibration data
includes any of
the data, discussed above, that is sent over the BDB 120. In addition, the
synchronized
data may include any other configuration or calibration data used by the
mechatronic
device 120.
[0084] In one enibodiment, synclu=onizing the data includes determining the
differences between data on the mechatronic device 202 and data associated
with the
particular mechatronic device 202 on the network computing device 340, and
sending that
data from one device to the other. In one embodiment, the network computing
device
340 stores the data associated with the mechatronic device 202 in a database
in
association with data identifying the particular mechatronic device, e.g., a
serial nuinber.
In one embodiment, when the particulal= mechatronic device 202 is synchronized
again,
the neMrork computing device 340 deterinines the differences in the data based
on the
data in the database. In one embodiment, after determining which control data
is
different, the mechatronic device 202 sends control data to the networlc
computing device
340 that overwrites control data associated with the mechatronic device 202.
In another
embodiment, the network computing device 340 sends control data to the
mechatronic
device 202 that overwrites such data on the mechatronic device. In one
embodiment,
some data is sent both ways for overwriting. Whether the control data is sent
to or from
the mechatronic device 202 may be based on one or more methods. For example,
in one
embodiment, time stainps are associated with the data so that the newest data
associated
with a pai-ticular item of control data is saved on both the mechatronic
device 202 and the
CA 02598051 2007-08-15
WO 2006/088966 PCT/US2006/005352
network computing device 340. In other embodiments, predetermined rules
regarding
particular items of control data determine how the data is syncluonized. In
one
embodiment, a selection by the user of the device, or a selection by a
prosthetist
determines in which data particular items of control data are synchronized. In
one
embodiment, a new mechatronic device 202 receives initial control data from a
database
associated with the network computing device 340 that stores initial data or
overwrites
any existing data on the mechatronic device 202.
[0085] In one embodiment, the network computing device 340 acts as a
conduit to send and receive the configuration or calibration data to another
network
computing device 341 that stores the data. In one embodiment, the network
computing
device 340 is a PDA or mobile telephone that coirnnunicates with the
mechatronic device
202 via a short range network and relays that data to the network computing
device 341.
In one such embodiment, the network computing device 341 includes a server
computer.
Thus, the mechatronic device 202 may sync.luonize configuration and
calibration data
with one or both of the networl: computing devices 340 and 341.
[0086] Next at a block 630, the mechatronic device 202 stores any received
data. Also, or alternatively, the networl: computing devices 340 and 341 store
any
received data. In one embodiment, one or more of the devices 202, 340, or 341
also store
data related to the synclironization, e.g., a timestamp or data identifying
the devices or
data involved in the synchronization. In one embodiment, the network computing
device
340 or 341 stores the data in a database in association with the mechatronic
device.
Returning to Figure 6, the method 600 proceeds to an end state.
[0087] Figure 7 is a flowchai-t illustrating one embodiment of a method 700 of
installing, replacing, augmenting, or deinstalling software on the mechatronic
device.
The method 700 begins at a block 710 in which the mechatronic device 202
establishes
communication with a source device containing software configured to execute
on the
mechatronic device 202. In one embodiment, the source device includes the
network
computing device 340. In such an embodiment, the mechatronic device 202
establishes
conununications with the network computing device 340 via the network 350. In
another
embodiment, the source device also includes'the network computing device 341.
In such
an embodiment, the mechatronic device establishes communications with the
network
computing device 341 through the networlcs 350 and 351 via the network
computing
device 340. In one embodiment, the source device includes another mechatronic
device.
In another enibodiment, the source device includes a storage card in
communication with
21
CA 02598051 2007-08-15
WO 2006/088966 PCT/US2006/005352
the storage card interface 366. The software could be low level fii7nware
and/or higli
level software, for example.
[0088] Moving to a block 720, the mechatronic device 202 or the user of the
device 202 selects software to be installed thereon. In one embodiment, the
user selects
from a list of software adapted to various activities, e.g., hiking, biking,
or jogging. Iil
one embodiment, the list is displayed on a user interface associated with the
networlc
computing device 340. In one embodiment, the user interface includes a web
browser. In
one such embodiment, the user interface receives the list from the networlc
computing
device 341.
[0089] Proceeding to a block 730, the mechatronic device 202 receives the
software fiom the source device. In one embodiment, receiving the software
includes
transferring then software over the network 350. In another embodiment,
receiving the
software includes having a storage card installed in the storage card
interface 366.
[0090] Next at a block 740, the mechatronic device 202 installs the software
for execution. Installing the software may include saving the software to a
portion of the
memory 362, upda.ting pointers or jump tables in the memory 362 to replace or
augment
previously installed software, or storing a record of the soffivare
installation. In one
embodiment, the record includes sufficient data to remove the newly installed
software.
In one embodiment, the mechatronic device 202 saves the received software to
its
memoiy 362. In another embodiment, the mechatronic device 202 executes the new
software directly from a storage card.
[0091] Moving to a block 750, the mechatronic device executes the new
software. The new software may replace all or a portion of one or more of the
state
machine module 210, the hardware abstraction module 212, the dynamic learning
module
214, a configuration module 216, the BDB module 218, or any other suitable
software
module of the mechatronic device 202. The new software may include soffivare
updates
to fix bugs, improve perfonnance, or provide additional features. In one
embodiment, the
new software may include instiuctions for controlling the mechatronic device
202 to
perform one or more specific activities such as hiking, biking, swimming,
jogging,
throwing, jumping, or for movement over a particular type of tei-rain.
[0092] It is to be appreciated that depending on the embodiment, certain acts
or events of a method described herein can be perfonned in a different
sequence, may be
added, merged, or left out all together (e.g., not all described acts or
events are necessary
for the practice of the method) . Moreover, in certain embodiments, acts or
events may
22
CA 02598051 2007-08-15
WO 2006/088966 PCT/US2006/005352
be perfonned concuiTently, e.g., through multi-tlireaded processing, interrupt
processing,
or multiple processors, rather than sequentially.
[0092] While the above detailed description has shown, described, and pointed
out novel features of the invention as applied to various embodiments, it will
be
understood that various omissions, substitutions, and changes in the form and
details of
the device or process illustrated may be made by those skilled in the art
without departing
fi=om the spirit of the invention. As will be recognized, the present
invention may be
embodied within a foim that does not provide all of the features and benefits
set forth
herein, as some features may be used or practiced separately fiom others.
23
