In developing intelligent assist devices (IADs), what is needed is the powered assistance currently available with gantry cranes, but the quick and intuitive operator interface that currently is available only from unpowered rail systems is also desirable. What is needed is better ergonomic performance than unpowered rail systems and greater dexterity and speed than gantry cranes allow. What is needed is the ability to use the IAD with larger payloads than current unpowered rail systems allow. What is also needed is the ability to connect and integrate a number of IAD components to work together, and a computer interface design that allows an technician or system integrator to easily program, operate and monitor the status of an IAD system made up of a plurality of components.
There are two problems with unpowered overhead rail systems. Controlling the motion of the moving payload is a problem, as it requires pulling sideways with respect to the payload’s direction of motion, generally using the smaller and more easily injured muscles of the upper body and back.
Anisotropy is a further problem. Although low-friction designs are used, both the friction and the inertia are greater in the direction in which the payload has to carry with it the whole bridge rail than in the direction in which the payload simply moves along the bridge rail. Anisotropy produces an unintuitive response of the payload to applied user forces and often results in the user experiencing a continuous sideways “tugging” as the payload moves, in order to keep it on track.
For larger loads, an active motor-driven trolley and bridge rail transport can be used to assist the operator by providing a mechanical assist.
What is presented here is a modular system architecture coordinated by serial digital communication, to allow ease of configuration to a variety of applications. Also, the digital communication may be extended to allow integration with information networks within an industrial plant such as an integrated manufacturing or enterprise management system.
The embodiments further provide graphical configuration software which facilitates set-up and maintenance of the IAD and allows the selection of customised user profiles. The software allows integration, configuration and programming of components to perform tasks and simplify testing and monitoring of the system to increase ease of operation.
Overview of the system
Fig. 1 is a high-level block diagram illustrating the device’s modular architecture. The described modular architecture includes the interconnection of modules such as a trolley 101, lift 103, sensor 107, hub 105, intent sensor 109, and user tooling 111 via computational nodes 102, 104, and 106. These devices are connected to plant information systems such as a plant network 108 and user-supplied or system-integrator-supplied components such as a computer 110.
The mechanical support framework is an overhead rail system, preferably of the low-friction enclosed track, but optionally of the less expensive I-Beam type. The overhead rail system can utilize one or more bridge rails that ride on runway rails to provide motion in an XY plane (i.e., preferably parallel with the ground), and devices to provide motion along a z direction.
Two modules that can provide motion of a payload, trolley 101 and lift 103, are illustrated. In the described embodiment there are three trolleys and one lift. Two of the trolleys provide motion of a bridge rail along runway rails, and the third trolley providing motion of the lift along the bridge rail, and the payload suspended from the lift.
Preferably, the computational nodes 102, 104, and 106 are in communication with the modules 101, 103, 107, 105, 109, and 111 to control each module and permit communication between modules. The nodes 102, 104, and 106 are preferably in communication with the plant information network 108 and to the computer 110 such as for set-up and configuration. Communication between nodes 102, 104, 106 can allow for remote programming, fault monitoring and synchronization with manufacturing operations.
Node 102 also communicates with modules such as sensors 107, which provide geometric and positioning information about the system and payload, and vertical motion. Computational nodes 102, 104, 106 generally include a central processing unit (CPU) capable of running a stored program and capable of communication with modules, and also having digital and analogue inputs and outputs in order to receive signals from sensors and switches and to control motors and other actuators and indicators. Here, computational nodes 102 and 104 include an Intel Pentium CPU with additional analogue and digital support circuitry. Communication between nodes 102, 104, and 106, and between node 104 and plant information network 108, utilizes the CAN standard.
Nodes 102 and 104 can execute automatic control algorithms for motion control; accept and relay analogue and digital input/output (I/O) involving sensors, actuators, indicators, and switches; perform data logging safety functions including watchdog, e-stop, and struggle detection; support user-programmed logic operations; and control advanced behaviours such as virtual surfaces, soft limits, auto-return to home, semi-autonomous motions, and line tracking.
Preferably, the hub 105 is conveniently located for access and visibility by the operator. It provides physical support to tooling 111 and its payload, routes pneumatic and electrical power from overhead supplies to the tooling, and measures the weight supported via a flexure and strain gauges. Furthermore, the hub 105 can display IAD status to the operator via indicator lights 115 and provide “soft” (user-programmable) indicators 115 and switches, including an emergency stop button. It can also accept input from user-supplied sensors on the tooling 111, such as proximity switches or operator buttons, and provide outputs to user-supplied actuators or indicators on the tooling. The hub 105 can allow communication with a user-supplied computer 110 to programme the behaviour of the IAD.
The components
Fig. 2 is a drawing illustrating the trolley 101 of Fig. 1. A multiplicity of wheels 201 roll freely in enclosed track of known type or on an exterior of I-beam type rail (not shown). Mounting holes 203 on the lower side of load plate 202 allow the connection of a lift or balancer or rail or other load to load plate 202, the load being moved by the motion of trolley 101. The dimensions of load plate 202 and of wheels 201 may be varied to adapt trolley 101 to a number of different types of enclosed track or rail. Guide rollers 204 serve to centre trolley 101 with respect to the opening in the enclosed track. Drive roller 205 is driven by a DC brushless servo motor and gear train. The gear train is a two-stage spur gear transmission providing a reduction ratio of 4:1. Gear box 302 and drive shaft 601 connect to the front plate 306 with four screws 602 that may be easily inserted or removed, permitting removal of the subassembly and access to drive roller 303, as may be necessary to repair a worn drive roller, or for preventive maintenance of a drive roller.
Fig. 2 also shows the disposition of gear train of conventional design, which is inside cover 208. The disposition of back plate 210 is also shown, onto which mount electronic components including a motor amplifier 401, power supply 402, and computational node 403.
A flywheel is rigidly fixed to shaft of motor 301 and enclosed in housing 307. The flywheel serves to provide inertia matching between motor 301 and the mass of the load driven by trolley 101. Inertia matching is a technique known in the field of servo control to facilitate robust, parameter-insensitive feedback control systems.
Fig. 8 shows a diagram illustrating the lift 103 of Fig. 1. The hanger 801 is used to connect the lift 103 to the trolley 101, or to any other kind of movable or non-movable support. Preferably, the reel casing 802 pays out wire rope from which a payload may be suspended via hub 105. The wire rope (not shown) passes through field-replaceable guide 803. Motor 804 drives a reel within reel casing 802, which will be further described below, via a gear train within gear train housing 805. The gear train consists of a two-stage spur or helical gear transmission with a reduction ratio of 25:1. A computational node 807, amplifier 808, and power supply 809 mount on back plate 806. Regeneration resistors 810 dissipate energy that is generated when the suspended payload is moved downward.
Fig. 13 shows a drawing illustrating the front view of the hub 105. The hub 105 generally includes housing 1301 with slots 1302 through which status lights 1601 may be seen by an operator. In particular, the status lights 1601 may be used to indicate the modes required by the system safety standard. The hub also includes display panel 1303, which has two LED alphanumeric characters sufficient to display a two-character user profile identifier. Switches 1304 allow the operator to toggle among the profiles. The swivelling attachment 1305 preferably allows the hub 105 to remain facing the operator or any other desired direction, despite rotation of a wire rope or other support from which it is suspended. Air pass-through connectors allow for connection of a pneumatic hose from above to tools or equipment that need pneumatic power below.
Fig. 16 shows a drawing illustrating a cut-away drawing of the hub 105. Attached to front board 1605 is a connector for communication with a user-supplied computer or PDA. Flexure 1606 conveys load from attachment swivel 1305 to housing 1301 via pins at 1607, and thence to a lower attachment point, so that a measurement of the bending of flexure 1606 is a measure of the load. Strain gauges are attached to the flexure.
Fig. 18 shows a diagram illustrating an inline handle 1800 connected to the bottom of hub 105 via a locking mechanism. Inline handle 1800 incorporates a multiplicity of switches such as a stop button 1802, restart button 1803, float enable button 1805, and a user-programmable “soft button” 1804. The sleeve 1806 may be grasped by the user and moved up or down to signal the intent of the user for up or down motion. Also shown is the threaded connector 107 to which a payload or tooling may be attached. Up/down motion of sleeve 1806 is detected by an analogue Hall sensor.
The software
Figs. 26-34 show screen-shots illustrating several different aspects of a graphical user interface of configuration software which resides on user-supplied computer 110 (Fig. 1). The configuration software may be used to configure an intelligent assist device and to adjust its properties.
Fig. 28 shows an identification panel, in which the installer identifies which modules are to perform which role in the IAD system. This is necessary because there may be several modules of the same kind, for instance two trolleys, used in different physical locations within an IAD installation. For instance, one trolley may be on a runway rail and another on a bridge rail. Because the modules are connected via communications links, they do not discover their physical location – which one is on which rail – themselves. Thus, the installer informs them which role each module is to play, via this panel. Users select elements on the left-hand side of the identification panel. The right-hand side graphically depicts the configuration of the system to give the user a visual indication and confirmation of the system.
Also in Fig. 28 are corner fields 2802 which the user may employ to note physical landmarks or coordinates on the screen, for the purpose of orienting themselves or another installer returning to the same IAD later, who may set down his or her portable computer in random orientation with respect to the IAD.
Also shown are status indicators 2805 showing the fault state of any of the modules. By clicking on a status indicator 2805 a report may be requested of the module.
Fig. 29 shows a motion panel, which serves to test the functioning of modules of the IAD. Sensor indicators 2901 are animated graphics that indicate the instantaneous output of the various sensors, as communicated from the IAD to the software. This allows the installer to test for proper functioning of sensors. Jog buttons 2902 allow the installer to test for proper functioning of the motion modules such as trolleys and lifts, by clicking on the jog buttons on screen and watching for small motions of the corresponding motion modules. Of note on this panel are reverse boxes 2903 and polarity indicators 2904. These serve to allow the installer to mount the modules (such as trolleys) in either orientation physically, and to inform the software as to the polarity in which they have been installed. Without such a capacity, modules would have to be installed in standard orientation or else motion might occur backwards.
Fig. 30 shows a vertical motion set-up panel, with which an installer or technician or user may adjust the various numerical parameters that determine the behaviour of a module such as a lift. The learn button 3005 allows instantaneous values of parameters to be recorded so they do not have to be manually determined or entered.
Fig. 31 shows a lateral motion set-up panel, similar to the panel shown in Fig. 30 except for lateral motion module parameters. The system has several hub logic control panels. These panels relate to programming of the logic functions of the IAD, such as conditions under which the IAD may move beyond a particular height. It also relates to programming of the digital and analogue inputs and outputs which are available to the system integrator or installer via connector in hub 105. The system integrator or installer may take advantage of programmable logic to reduce the need for discrete logic components, or even, as is common practice, for pneumatic logic components. A hub logic panel presents standard logic functions, which may be selected by clicking a button. One example is: “Activate payload release (P1) when switch S1 is pressed, but not if interlock weight is exceeded. De-activate payload release when switch S2 is pressed.”
For programmers of greater sophistication who desire greater flexibility, a more general logic program may be viewed and programmed in Fig. 33. The custom logic panel offers a multiplicity of programmable rules 3301. Each rule has a condition 3302 and an action 3303, the action being taken if the condition is met. A condition may be specified in terms of required logical values, shown as zeros, ones, and blanks 3304, or by other symbols. Among the logical states which can be used to construct a condition are the states of switches readable by the IAD, the states of the inputs or outputs of the hub 105, the logical states of internal virtual states which are not electrically accessible, and inequality comparisons between analogue values measured or internal to the IAD, in comparison to analogue values specified in a sub-panel accessed via advanced button 3305. A condition is satisfied if the state of all those logical values for which a one is placed is high, and all those for which a zero is placed is low, and without regard to the value of those for which a blank is placed. Actions may be specified in terms of logical values as above, for the various outputs. Outputs include ones that change the state of the IAD, for instance putting it into “stop” state, or change the values of the electrically accessible outputs of the hub, or change the value of internal virtual states which are not electrically accessible.
Fig. 34 shows a profile set-up panel. It can be utilized to individualize certain parameters of the IAD in order to make its operation most comfortable to each operator. A multiplicity of profiles 3401 are accessible. Profile ID 3402 gives the abbreviated identifier that will appear on display panel of hub 105.
Fig. 36 shows a block diagram illustrating electronics that comprise a computational node on a trolley 101 or lift 103. A variety of general purpose as well as digital signalling processing platforms can be utilized. Processing unit 3601 includes an Applied Micro Devices ElanSC520 CPU. An analogue-digital converter 3602 reads in analogue voltages. Digital input and output is accomplished by I/O channels 3603. CAN communication is accomplished by drivers 3604. Of course, the electronic assembly can include a wide variety of support components, some of which are shown in Fig. 36 and some of which have been omitted for ease and clarity of description and understanding. The described embodiment includes various PCI and ISA buses, RS-232 communications, a JTAG debugging port, FLASH memory as well as SRAM and SDRAM just to name a few.
Fig. 37 shows a block diagram illustrating electronics that include a computational node on a hub 105. The processor 3701 is an Atmel model AT90S85535-8JC microcontroller, although may variations are possible. Display 1303 is controlled by display driver 3702. Analogue inputs are received by A/D converter 3703 which is a part of processor 3701. Communication with another computational node is done by driver 3704, which is a CAN driver. Serial interface 3705 supports communication with a user-supplied computer or PDA 110 via connector 1608 on hub 105.
