Source: http://patents.com/us-7996109.html
Timestamp: 2019-10-16 10:04:22
Document Index: 409669318

Matched Legal Cases: ['art 300', 'art 300', 'art 300', 'art 300', 'art 300', 'art 300', 'art 500', 'art 500', 'art 500', 'art 500', 'art 500', 'art 500', 'art 500', 'art 600', 'art 600', 'art 600', 'art 600', 'art 600', 'art 500', 'art 300']

US Patent # 7,996,109. Robotic ordering and delivery apparatuses, systems and methods - Patents.com
United States Patent 7,996,109
Zini , et al. August 9, 2011
Inventors: Zini; Aldo (Venetia, PA), Allen; Spencer Wayne (Wexford, PA), Skirble; Barry Mark (Allison Park, PA), Thorne; Henry F. (Pittsburgh, PA), Fairley; Stuart (Pittsburgh, PA)
Assignee: Aethon, Inc. (Pittsburgh, PA)
Appl. No.: 11/549,815
60727280 Oct., 2005
Field of Search: 700/245,247 180/21,168-169 318/568.11,568.12,568.16,587,628
4483407 November 1984 Iwamoto et al.
4746977 May 1988 White
4800977 January 1989 Boegli et al.
4816998 March 1989 Ahlbom
4944357 July 1990 Wible et al.
5175480 December 1992 McKeefery et al.
5276618 January 1994 Everett, Jr.
5315517 May 1994 Kawase et al.
5367458 November 1994 Roberts et al.
5402344 March 1995 Reister et al.
5446356 August 1995 Kim
5461292 October 1995 Zondlo
5487009 January 1996 Hill
5488277 January 1996 Nishikawa et al.
5515934 May 1996 Davis
5535843 July 1996 Takeda et al.
5545960 August 1996 Ishikawa
5548512 August 1996 Quraishi
5680306 October 1997 Shin et al.
5684696 November 1997 Rao et al.
5819863 October 1998 Zollinger et al.
5908466 June 1999 Veugen et al.
5942869 August 1999 Katou et al.
6038501 March 2000 Kawakami
6041274 March 2000 Onishi et al.
6046565 April 2000 Thorne
6272405 August 2001 Kubota
6314341 November 2001 Kanayama
6360165 March 2002 Chowdhary
6370453 April 2002 Sommer
6454036 September 2002 Airey et al.
6459966 October 2002 Nakano et al.
6502017 December 2002 Ruffner
6629735 October 2003 Galy
6946565 September 2005 Fedouloff et al.
7066291 June 2006 Martins et al.
7100725 June 2006 Thorne
2003/0030398 February 2003 Jacobs et al.
2004/0002283 January 2004 Herbet et al.
2004/0093650 May 2004 Martins et al.
2004/0195012 October 2004 Song et al.
2005/0029029 February 2005 Thorne
"HelpMate.RTM. Trackless Robotic Courier", Pyxis Corporation, Product Brochure. cited by other.
This application claims the benefit under 35 U.S.C. .sctn.119(e) of the earlier filing date of U.S. Provisional Application Ser. No. 60/727,280 filed on Oct. 14, 2005.
1. A robotic device for retrieving/delivering goods, comprising: a body; drive wheels connected to the body; at least one motor connected to the drive wheels; at least one sensor connected to the body; and an onboard controller communicably connected to the at least one sensor, wherein the onboard controller is configured to: store a map of an environment in which the device is to operate; receive information from the at least one sensor; and utilize the map and the information to continuously confirm an absolute location of the device in the map.
13. The device of claim 1, further comprising: an interface; and a cart attached to said body by said interface.
In varied environments, the robotic tug system should provide solutions to work around and through certain commonly encountered obstacles. For example, the robotic tug and cart should be able to move from one floor to another in a multi-story building. The device should be able to manipulate automatic doors or otherwise complete delivery tasks when faced with closed doors. These and other "non-ideal" aspects of real world environments have not heretofore been appropriately addressed by existing robotic applications.
The present tug/cart devices are preferably used within a flexible system. The tug or tugs along with a variety of different carts are put in place at a primary location within which the retrieval/delivery system is to be utilized. Each of the robotic devices is associated with a docking station that provides docking functionality for the one or more robotic tugs including recharging the batteries within the tug, downloading any collected data and or aiding in the performance of a diagnostic self-check of the tug and/or providing a convenient interface (e.g., a touch screen) with which a user can select a desired destination. One of the docking stations may also be the main "home base" station which provides a communicating access point between all of the robotic devices and docking stations and the other system components.
One exemplary embodiment of a robotic tug 100 according to the present invention is shown in FIG. 1 with its cover 105 in place and in FIG. 2 with the cover 105 partially removed to more clearly show internal features of the tug 100. FIG. 3 shows the tug 100 with an attached exemplary cart 300. The pictured exemplary tug 100 is approximately 20'' wide and 71/4'' in height. A typical tug includes a very low profile enclosure made of high impact, abrasion resistant ABS plastic 105. Moreover, because the tug 100 will often be used in a hospital setting, the surface of the tug may be smooth for ease of disinfection using conventional hospital disinfectants. The tug preferably is capable of hauling up to 500 lbs. (e.g., loaded by the attached cart 300) and up to 250 lbs. across a typical 1'' gap across the entrance to an elevator shaft.
The exemplary tug 100 in FIGS. 1-3 has a 24 volt DC power system provided by sealed, lead acid, maintenance-free rechargeable batteries 110. The batteries may be recharged using a charging station (described below) and preferably runs its twin 24 VDC motors 115 and accompanying electronics for 6 hours on a full charge. Each motor 115 is completely independent of the other motor so that precise steering and wheel 120 position sensing can be controlled on a per-wheel basis. With such a configuration and typical cart loads, the tug will operate at a speed of up to 3' per second, which is fully adjustable based on application. Preferably, based on its mapping software, the tug will automatically dock itself into a charging/docking station when not in use or when the battery is low. A full tug charge process takes no more than 4 hours to complete, with quick charges for shorter runs preferably taking only a matter of minutes. Preferably the tugs are programmed to charge for at least 5 minutes between trips in order to make sure that the trip can be completed.
The tug 100 also contains an onboard computer 125 loaded with the tug operating system (TUG OS) software. This software utilizes a detailed map of the hospital along with sophisticated navigation software to plan robotic device routes, avoid obstacles and constantly track its location through the use of a variety of different sensors and other devices--all as described below.
When used in high traffic environments, such as in a hospital, the tug 100 preferably includes warning tones and lights to signal when it is backing up, starting, stopping and entering/leaving an elevator. A cart-mounted speaker may also broadcast selected messages that explain cart functionality, provide additional warnings/announcements or greet/report a user as various tasks are completed (e.g., when an asset is properly delivered to a final location. For example, the device may include pre-recorded or synthesized messages, or audio may be sent via Voice over IP (VoIP) from a remote host to the tug/cart and played through a speaker. In some embodiments, the tug/cart may include a "push to talk" button which automatically connects the device to a remote host via VoIP. The tug/cart may also include a warning light/sound to indicate an obstruction or tampering with the cart in an unexpected manner.
The tug's movement and stopping ability are closely monitored and regulated through a variety of different sensor configurations. For example, a fully-loaded tug preferably stops before contacting objects detected within 18'' of its front bumper by means of a grid of forward and/or side-looking infrared sensors 130 that are constantly scanning the environment of the tug 100. Moreover, the tug 100 and/or cart 300 preferably include a red "stop" button 310 which is readily accessible and may be programmed to automatically stop the cart for 5 to 30 seconds, or some other useful time period, as determined by a particular application.
Generally speaking, the main positioning sensor on board the tug is a series of infrared sensors 130--directional light sensors that measure distance along a single line, the length of which is adjustable. A first set of infrared sensors 130 is pointed outward from each side of the tug 100 approximately perpendicular to the movement of the tug. These positional side sensors 130 are used to continuously measure the distance to nearby walls. Such a measurement can be used along with the onboard maps to determine exactly at what location and position/orientation the tug is currently located. Moreover, by recognizing certain features in the environment, such as walls, corners, pillars, etc., as "checkpoints," the robotic device 100 can constantly monitor its location and movement throughout its environment by comparing the position of the tug to a series of consecutive or continuous checkpoints. This algorithm is described in more detail below.
An additional series of infrared sensors is preferably oriented at various vertical angles in front of and around the sides of the tug 100. During the tug's movement, these infrared sensors, the paths of which form a grid or three dimensional "force field" at least in front of the tug, constantly receive sensor data to detect any obstacles that may be in the way of the tug's intended path. When one or more of these directional sensors determines that the path is blocked, the sensors preferably feed this information back to the tug operating system so that an appropriate evasive action may be taken (i.e., stopping, altering path, turning, etc.).
FIG. 4 shows one exemplary configuration of the various infrared sensors that may used with the present invention. First, two infrared sensors 405 are pointed approximately 90 degrees from the moving direction of the tug 100 parallel to the floor. These "side" infrared sensors 405 constantly determine distance to the wall (or other identifiable feature) and are chiefly responsible for gathering data used by the tug operating system to correctly orient the tug on its path. Likewise, FIG. 4 also shows two infrared sensors 410 pointing almost vertically out of the top of the tug. These two (or more) vertical sensors 410 are used to identify objects that may hang from the ceiling or protrude from an upper portion of a wall--potential obstacles that may not be picked up by the other forward or side-looking sensors.
The robotic tug 100 may also include a touch bumper 150 or other mechanical "impact" switch that provides an emergency stop in case of impact with an obstruction. Although a cowl or other mechanical device could be used for such a purpose, the touch bumper or "sensing edge" 150 is preferred because it is manually more reliable that alternative switches and is easily adapted to extend around the front and portions of the sides of the robotic device. Moreover, for full 360 degree operation, the tug 100 could be circular in shape with the touch bumper wrapped all the way around the entire perimeter of the tug.
A connector 315 that may be used to connect the tug 100 and the cart 300 comes in a variety of different conductor configurations and may be mounted in various horizontal and vertical orientations. For the present embodiment, the connector is mounted in the vertical direction, preferably with the stationary end of the mount connected to the tug (allowing the cart to "follow" the path of the tug). Depending on the location of the power and control circuitry, the conductors may be used to transfer power and signals back and forth between the tug 100 and the cart 300 to accomplish various tasks.
The tug and cart interface 315 may also include some type of sensing that may be used as part of the path planning and adjustment algorithm. For example, an encoder may be placed at the interconnection between the tug 100 and the cart 300 that measures the amount of rotation of the cart pin within the tug's socket. Such a pin rotational sensor would represent the angle between the heading of the tug and the current heading of the cart. As the tug 100 steers along its path and around obstacles, the cart's "steering" will necessarily lag behind the tug's turn. This rotational sensor data can be used by the tug operating system to appropriately account for this lag during path planning.
A first cart is the general purpose cart 500 shown in FIG. 5. Specifically, FIG. 5A shows a general purpose cart 500 with the locking door 505 closed, and FIG. 5B shows the same general purpose cart 500 with the door 505 open. The general purpose cart 500 is a traditional cart with adjustable shelving 510 as is commonly utilized in a hospital or other environment. Standard cart dimensions may be approximately 22.8'' wide.times.24.9'' deep.times.40' high. This cart 500 may have a security feature located in the door 505 such as the keypad lock 515 shown in FIG. 5B. Such an electronic locking mechanism 515 limits the accessibility to the contents of the cart 500 to only authorized users. For example, the combination to the lock 515 may only be given out to certain personnel, or the electronic lock may be opened by two or more different password combinations, with the system tracking which authorized user opened the cart at which time(s) by means of data storage means. Such a high security, yet general purpose cart 500 may be useful for delivering lab work, blood to and from a blood bank, confidential patient records and/or Emergency Room (ER) materials that may be highly desirable to thieves.
An alternative cart is a tote cart which may be used to stack, store and deliver a variety of different bulk carriers. The tote cart generally consists of a steel frame of open metal work with a flat, solid base constructed of a size to accommodate a standard bulk carrier. In the hospital setting, a standard plastic "tote" comes in a uniform, stackable size, and a preferred version of the tote cart accommodates 8 of those standard totes, in two columns of 4 totes. Testing of exemplary tote carts yielded a maximum load of approximately 400 lbs. on level ground and 200 lbs. on a 7 degree incline. In and out of a hospital setting, the tote cart is useful for material handling and general distribution of bulk materials.
For hospital and assisted living applications, a third exemplary cart is the dietary cart used to transfer a plurality of meals to various patients, one after another. The dietary cart is similar to the general purpose cart except that the interior portions of the cart are adapted to slidingly accept several different trays (e.g., seven standard 201/4''.times.15'' hospital food trays) stacked vertically. Preferably, because this application deals with sanitary food and medical supplies, the trays are completely removable and the inner portions of the cart may be easily cleaned to prevent contamination. In some embodiments, the entire upper portion of the cart may be designed to "snap" off of its base so that this upper portion can be cleaned and sterilized between uses. Additionally, the door may include some type of locking mechanism like the general purpose cart and/or each of the trays may be secured with a tamper-resistant tie wrap or other security device. Any of these measures prevent stealing and/or tampering with the contents of the dietary cart without overly restricting access thereto.
A fourth exemplary cart is the hamper cart 600 which is used to carry linens or other bulk materials in a low profile carrier. As shown in FIG. 6, the hamper cart 600 may have three permanent sides 605 and one side 610 that swings open to allow easy access to all of the linens or other materials inside the hamper cart 600 (shown closed in FIG. 6A and open in FIG. 6B). In order to quickly fill the hamper cart 600, for example when a series of bed linens are being changed, there may not be a top to the hamper cart. Exemplary dimensions for such a cart 600 may be approximately 27'' wide.times.36'' high with a weight limit of approximately 100 lbs.
Another exemplary cart is the individual locking drawer cart. This type of cart includes up to 9 or more drawers of varying depths. As an example, drawer sizes may be of standard 3'', 6'' and/or 9'' depths, and each drawer preferably includes its own locking password code or codes. This cart is especially useful in a hospital setting by the pharmacy department. Therefore, it is preferred that the keypad allow up to 500 individual access codes which are all logged by the system in terms of the times and identity of the drawers accessed. There may also be sub-compartments within each drawer that likewise have their own electronic or manual locks which provide selective access to the contents depending on the security clearance of each individual accessing the contents of the cart. This cart is preferably of similar size to the general purpose cart 500 described above.
All of these carts or any other cart configuration may also be designed as an "exchange" cart. The exchange cart allows either automatic or manual removal/replacement of one cart for another in a streamlined manner. This removal/replacement can be accomplished in several different exchange cart orientations. For example, the tug/cart interface could have an automatic or manual coupler/decoupler (similar to railroad cars) that can be used to switch one cart for another.
With one or more of the above-referenced carts, there may also be an attachment means on a rear face of the cart that is generally referred to as a "pole" option for the cart. In hospital or assisted living applications of the present invention, IV (intravenous) poles are often used to administer liquids in measured continuous doses to patients. These poles typically include a slender vertical rod with three or more hooks to hold bags of fluids all supported by a five-pointed wheeled base. Since these IV poles must also be passed around the hospital, the pole option is a hooked attachment that extends horizontally out the back of a cart (e.g., the general purpose cart) and pulls the IV unit behind the cart. Typically, the option includes a tray extending out from under the back of the cart onto which the IV unit (or other vertical implement) is rolled and suspended, secured by the locking horizontal "hook." In advanced optional embodiments, the cart may even "release" the hook around the IV pole when the delivery is completed. Other alternative hooks may also be added to the various carts, e.g., vertical hooks to hold bed pans that are collected during the tug/cart's deliveries. Also, the attachment means may take the form of a VELCRO fastener or any other commonly available attachment means in place of or in addition to a hook.
As part of the preliminary mapping process, the CAD drawings of the building (e.g., a floor of a hospital) are converted by a software program into a format that the tug can comprehend. For example, the CAD drawing may be converted to a bitmap (.bmp) file that is a perfectly scaled representation of the floor plan of the tug's operating environment. The accuracy of the CAD drawings may be checked with manual surveying at key locations. The key is that the electronic file be scaled such that it represents the actual layout of the tug's environment. In this way, the exact x,y position of the robot in the "real" world is directly translatable to any x,y location on the bitmap. Because of this, the robot can always know its precise location.
Thereafter, these electronic maps (bitmaps) are then used to mark the locations at which the tug is allowed to stop (i.e., destinations), the paths that tug will take to move from place to place, the areas in which automatic doors or elevators exist, the location of home base, the location of annuciators and/or any other desired location. For example, software may be used to electronically "insert" destinations and virtual checkpoints, and an operator can actually draw a path between two checkpoints right on the bitmap of the environment. Since this path is selected and drawn by the operator, it can force the robot to move near one side of a particular hallway, move in curved lines to avoid certain structures, and/or follow what would otherwise be less than optimal paths. Each of these locations and paths is represented in the environmental bitmap and is stored into operating system (TUG OS) running on the tug and/or the cart. In this way, the tug has preprogrammed information on the most efficient way in which to move from one point to another, but it also has additional information that may allow it to take a somewhat alternate route should an obstruction appear.
Multiple wall and corner virtual checkpoints can be used in tandem to provide a high level of accuracy in position and orientation in relation to the stored map of the environment. For example, as the robotic tug traverses down a hallway, it may "plan" to remain 12 inches away from the wall at all times. By continuously monitoring the side sensor distance to the wall, each of these data points can be used as part of a regression analysis to correct the heading until the side sensor reads the correct 12 inch value repeatedly due to a straight heading. Likewise, when corners and other well-defined landmarks are encountered, these virtual checkpoints are used to correct the forward/backward positional error that may have infected the movement algorithm due to the heading correction based upon the wall-based virtual checkpoints.
In general, there are three distinct types of obstacle avoidance methodologies that may be undertaken by the robot depending on the application. These different methodologies are classified as: (1) coarse; (2) sophisticated; and (3) "sniffer" modes of operation. Each of these three methodologies is described in more detail below.
The coarse obstacle detection methodology is based on predefined assumptions. Whenever one of the onboard sensors (e.g., infrared, laser, sonar, etc.) detects an obstacle within its field of view, the software onboard the tug/cart assumes a predefined "standard" size obstacle at a distance from the robot as determined by the sensor. The planned path for the tug/cart is then re-drawn to maneuver around that hypothetical "standard" obstacle and rejoin the intended path on the other side of the obstacle. Upon executing this re-routing operation, if the sensor again senses an obstacle along this new route, the software assumes another standard size obstacle in its path and redraws yet another new path to get around this second hypothetical object. This methodology is considered "coarse" because it makes standard assumptions about a detected obstacle and so is inherently inefficient in terms of the path traversed.
A third obstacle avoidance methodology is called "sniffer" mode. Sniffer mode is typically entered by the robotic device's software system when multiple obstacles are detected at the same time, for example in a crowded room or hallway. In sniffer mode, the size and shape of the obstacles are detected by the sensors, and the robot plans a route between and around the multiple obstacles. The robot then reduces its speed in order to collect more sensor data per unit of time. At this slower speed, the robot's path can be constantly updated based on the acquired sensor data to guide the robot through the multiple obstacles. In this way, the "sniffer" mode is similar to a specialized application of the sophisticated path algorithm.
FIG. 8 includes a schematic of one exemplary home docking station at which the tug/cart docks while recharging and waiting to be sent on a retrieval/delivery run. While recharging, the robotic tug 100 may also perform a self-diagnostic check and send a message locally and/or to the remote host about its current status and usage statistics. The tug 100 may also perform an "environmental" check during which it queries the local computer system (e.g., the hospital system) to ensure that the network is running, the power is functional and the elevators are in good working order. From the docking station, the tug 100 and attached cart 300 may be sent from point to point via a simple "one-touch" send and receive algorithm that is built into the tug operating system. The tug 100 basically rests in a dormant state while connected to a home base docking station. The home base docking station also acts as a communications hub between the hospital computer network and the tug itself (via wireless Ethernet communications).
Above the tug docking base 805, preferably at eye level, there may be a computer monitor 820 with touch screen capabilities or some similar interface for the user to interact and "program" the tug on its journey. The touch screen monitor 820 may provide a variety of different display options or gather various input from the user, but the primary purpose of the touch screen monitor is to provide one touch programming of a delivery route for a tug. When the tug is out on a delivery mission, the touch screen monitor preferably displays the location of the tug on a map of the environment as it travels along its intended route to its destination. In some embodiments, the monitor may also include speakers that announce when a delivery is successfully made by the tug. Additionally, the touch screen may display a status for a tug or display messages sent from the remote host.
The robotic device may also have a priority queue or scheduler that lists all of the destinations that have been selected for that particular tug in the order that the tug will progress. As the tug arrives at the first destination (perhaps with a delivery of goods), a simple one-touch button (see 330 in FIG. 3) on the robotic device allows a user at that first location to send the tug on its way towards the next "final" destination in its queue. During the tug's trip, however, any user can utilize a web browser and add additional destinations to the list of destinations in the tug's queue or even reorder and re-prioritize the destinations in the tug's queue. This flexibility allows a wide variety of users to utilize a single tug/cart in an efficient manner.
FIG. 9 shows an exploded view of an exemplary user screen 900 on the monitor at the docking station. As seen in FIG. 9, the user screen 900 may be divided into a grid of locations 910 to which the tug may be sent (e.g., Nursing Desk 3D and Central Supply). As these various destinations are selected, there may be a list 915 of the order in which the robotic device will visit the selected locations (the priority queue) displayed right on the user interface screen. As more locations 910 are selected in the main grid portion of the user interface, they will be added to the queue 915 of locations for the robotic device to visit. To send the robot on its way, the user preferably need only use the touch screen to select the final location (or locations) and press the "go" button 920, and the tug will automatically fulfill the request. The onboard computer software includes a map of the hospital and can find the most appropriate route to the desired end location as described above. As the tug moves along its path, the trip is preferably displayed graphically on the user interface so that the operator has knowledge about the location of the tug/cart at any time. The user interface may also provide status and history screens that provide additional information about the use of the robotic device.
On the receiving end, once the tug and cart reach the intended destination (or next destination), an employee removes the delivered item(s) from the attached cart and presses the green palm button 330 in FIG. 3) on the top of the cart. If the tug/cart has a "next" destination in its queue, it will proceed to that destination. If the queue is empty, the tug then uses its software to determine a path back to its docking station for recharging and to await its next retrieval/delivery run.
Looking back at FIG. 8, if the docking station is the main "home base" docking station which serves as a web server and communications hub for all of the robotic devices, then the docking station will also include a home base computer 825 which performs these system functions. The home base computer 825 preferably includes a wireless network card that is connected directly to the hospital's (or other location's) data network and allows the home base computer to wirelessly communicate with one or more tugs during operation. Through the use of the network, each device on the tug and the hospital network is capable of communicating with each other, virtually in real time. This provides a great deal of flexibility if the tug encounters difficulties. The home base computer 825 and the touch screen 820 are both also powered by a conventional 110V network.
There are several optional system components that may be used to expand the functionality of the robotic retrieval/delivery system. Many of these optional components address certain commonly encountered obstructions that may otherwise be difficult for an unmanned robotic vehicle to negotiate. Things like closed doors, automatic doors and elevators can all be addressed through various optional aspects of the present invention. The following discussion of "annunciators," automatic door interfaces and elevator control boxes each address one or more of these potential limitations.
When a robot is scheduled to make a delivery to (or retrieve an item from) a location that is behind a closed door (e.g., within a patient's room), an "annunciator" can be mounted on a wall or tabletop within the room. As the tug approaches the room, the tug sends a radio frequency (RF) signal to the annunciator which causes the annunciator to make an audible noise and/or to flash lights on the annunciator to indicate to the user that the tug has arrived outside the room.
An annunciator is preferably a small wireless receiver that operates on the 418 MHz spectrum range with limited range (e.g., 50'). Similar to a garage door opener, it is powered by a conventional 110 V source and is activated by the specific signal (which may be encoded if several annunciators are used near each other) from the tug. In addition to a closed door situation, an annunciator could be used for alternative types of alerts as various situations may require.
The automatic door interface allows a tug to remotely control the switch for an automatic door. This is particularly necessary in situations in which a wall mounted switch must be pushed for access--a task that is not conducive to a small robot. As with the annunciator, a 418 MHz receiver in an automatic door relay is used to receive a message from the tug that it requires opening of the automatic door. The reception of this signal closes a relay that is wired in parallel with the contacts of the door pushbutton. Therefore, as the tug approaches the automatic door, the tug is able to "push" the automatic door button by closing the circuit via wireless communication with the automatic door relay (again, similar to a garage door opener).
Typically, someone at a help desk at the remote host will monitor these incoming notifications (email or text messages) and can direct a solution to the problem. For example, if a tug sends an electronic notification to the help desk that it is "stuck," the help desk can use its web-enabled software to view a map of the environment in which the tug currently resides and can see the location of the tug relative to its intended path and the environment. The help desk operator can view real-time images captured by a camera onboard the tug and can diagnose certain problems based on the captured images. The help desk operator can also take control of the functionality and operation of the tug via remote control from the help desk at the remote host or service center. Additionally, the help desk operator may trigger one or more predefined messages to be played at the tug (i.e., "please call for maintenance") or the help desk operator may initiate a Voice over IP (VoIP) connection and speak remotely through a speaker attached to the tug/cart. Since most communications and control are web-enabled, the system is very flexible.
The tug is also capable of automatically moving from floor-to-floor in a building using the existing elevator systems of the building. This is an important distinction with prior art autonomous robots that are restrained to conventional two-dimensional movement within a single floor. In preferred embodiments, the tug uses an elevator of a hospital using onboard electronics that allow the tug to "take over" the control of the elevator by communicating directly with the building's elevator systems. The tug can call the elevator and select a destination floor using a wireless signal.
FIG. 11 shows one exemplary embodiment of a map used by the tug and cart to enter, utilize and exit an elevator cabin during a delivery trip. The tug approaches the elevator and uses its wireless Ethernet adapter to call for the elevator. Preferably, the tug and cart waits at a position similar to position "A1," "A2" or "A3" in FIG. 11 which allows for hospital beds or other large impediments to exit the elevator without being obstructed by the tug.
The next step in the elevator algorithm is to make sure that the elevator cabin is empty. In order to accomplish this task, the tug operating system software removes the elevator cabin from the hall call button loop and waits for the elevator to stop and enter an idle state. In other words, if a person pushed the "call" button from any hallway, the elevator under the control of the tug would not answer that call.
Once the last cabin call button has been answered, the doors to the elevator will close and the tug software will wait some predefined period of time (e.g., 10 seconds) with the elevator doors closed and will then assume that the cabin is available for tug use. All this time, the tug waiting outside of the elevator preferably plays a "calling elevator" or similar announcement to warn surrounding people what process is underway.
Once the cabin has been emptied, the tug will move from position "A" towards the elevator doors to position "B" (see FIG. 11). Using its onboard sensing equipment, the tug scans for any people or other obstacles which might prevent the tug from approaching the elevator doors. If such an obstacle is detected, the tug will stop and announce that it is "waiting to proceed" or give some other indication of its current state. When successful, the tug will be facing the closed elevator doors at position B.
Once the tug is directly in front of the elevator doors in position B, the tug will call the elevator cabin to its floor and open the appropriate doors (front or rear). As shown in FIG. 11, after the elevator cabin doors open, the tug will move to position "C" just inside the elevator cabin doors. In this way, the tug discourages people, other wheeled carts or other potential impediments from entering the elevator cabin and riding along with the tug. If such a passenger is allowed, the tug may leave some space ("P" in FIG. 11) for these additional passengers.
In an alternative embodiment, the tug may allow other passengers to ride in the elevator cabin along with the tug (see area "P" in FIG. 11) and to select additional floors for which the elevator is to stop. In this case, the tug preferably moves to its rear position and if additional passengers select other floors, the tug will allow these floors to be selected until all of the cabin calls have been serviced. As before, once all of the cabin calls have been addressed, it is likely that the elevator cabin is empty (except for the tug and cart), and the tug can utilize the elevator control box to bring the elevator cabin to the tug's requested floor.
In either case, as the elevator cabin travels to the destination floor, the tug preferably navigates itself through the elevator cabin into position immediately inside the elevator doors facing outward (position "D" in FIG. 11). In this position, the tug discourages potentially oncoming elevator passengers from entering the cabin until the tug has exited. When the cabin reaches the destination floor, the tug utilizes the elevator control box to open the elevator doors and preferably makes a repeated audible announcement that the tug is exiting the elevator and passengers should remain clear. Additionally, as always, the various sensors on the tug are constantly monitoring the tug's environment for potential impediments and will adjust the route and or forward movement of the tug accordingly. Once fully outside the elevator cabin, the tug releases control of the elevator and the hall call loop is again activated, returning the elevator to its normal operating position.
Using the touch screen monitor at the home docking station, the user simply depresses the name of the desired location and selects the "GO" button on the bottom of the user screen. In this example, the user has selected an area near two distinct blocks of patient rooms that the user desires the robotic device to visit in order. These two locations are shown on the touch screen monitor in the destination priority queue list. After the "GO" button is pushed, the cart begins its journey and the user interface screen switches to show the tug/cart on a floor plan map.
After the tug arrives at its first destination using the preplanned route along with whatever modifications to the preplanned route must have been made along the way based upon detected obstacles, a similar process takes place in reverse. First, the end user enters an access code on the cart keypad to unlock the door of the cart. Then, the cart door may be opened to gain access to the payload in the interior of the cart. After the good(s) are removed from the cart, the drawers and/or doors to the cart are closed and the "GO" (green) button on the cart is pushed. Pushing this button indicates to the cart that the delivery at that particular location was successful, and the cart will move on to its next delivery according to the tug operating system software. If no one presses the green "GO" button on the cart within a predefined time limit (e.g., 5-10 minutes) then the tug/cart may be programmed to automatically move on to its next delivery in order not to be delayed from its intended schedule. Again, in order to facilitate efficient use of the tug, the tug preferably logs the wait times and locations to be reported back to the administrators of the system for correction or alteration of the tug's plan.
At the next (and final) location, the same process begins again. The user enters a password to access the interior portions of the cart, and the computer within the robotic device stores this access information. After closing the cart door, this new user hits the "go" button and the tug/cart returns to its docking station to recharge and await future trips.
Each cart preferably also includes a red "stop" button that may be used in an emergency. Since the tug/cart does not move at high speeds and further because of the large amount of redundancy in the sensor configurations, it is unlikely that the cart will pose any moving hazard or violently strike any wall or object. However, there may be times, especially in a hospital setting, in which the tug and cart must be moved out of the way abruptly. For these occasions, each cart is preferably equipped with a red "stop" button that, when pressed, pauses the tugs programming for a predefined amount of time (e.g., 30 seconds). During this paused time, the cart may be manually pushed out of the way. When the tug operating system software comes back online, the tug will orient itself to the wall, find its location within the electronic map of the area and continue on with its delivery. This emergency stop time may be recorded for future reporting.
Previous Patent US 7,996,108 | Next Patent US 7,996,110