|
The Ohio State University Medical Center (OSUMC), situated in Columbus, is Central Ohio's most honored hospital with physicians and staff serving 800,000 patient visits each year. In addition, the hospital hosts $100 million worth of research each year, and operates a top-notch medical school. I recently visited OSUMC to observe their new fleet of robots.
A Mobile Robotic Project Is Born To improve operational efficiency, OSUMC has developed the Automated Transport System (ATS). The ATS includes robotic "transporters" that take care of moving materials around the hospital, including carrying patient meals, linen, supplies, and wastes between patient wings and a service floor, with interfaces to the kitchen, laundry, and supply and trash areas. The full ATS will go live in 2004 after a trial run.
FMC Technologies Inc. (Chalfont, PA) is implementing the ATS at OSUMC. With more than 300 systems and 2500 Automated Guided Vehicle (AGV) Systems deployed worldwide, FMC Technologies is a leading supplier of AGVs in many of the industries that utilize automated vehicles. The Payback The ATS at OSUMC will include 46 transporters making 3000 material movements each day. Each transporter can lift and move delivery carts weighing as much as 1000 pounds each. A variety of different carts can be used to accommodate various types of loads.
After purchasing the ATS and making associated building renovations, the OSUMC expects to see a return on investment within five to seven years. Most of the savings results from reducing the amount of time staff members spend moving materials, allowing them to spend more time with patients or other important tasks. In addition, the system should decrease wait time for materials and replace an outdated rail system that has been used to move materials. Because new elevators were built exclusively for the robots, there is also less traffic now in patient and visitor elevators.
Robots Find Their Own Way Around Each transporter uses laser guidance for getting around the hospital. A rotating infrared light on top of the transporter hits multiple reflectors attached to the walls strategically located throughout the hospital. The transporter catches the reflections coming back from reflectors, and uses the associated information to calculate its position. Every point in the hospital returns a different signature from the reflectors, which maps to a specific location.
The transporter carries a signature map (stored in memory) to plot its exact location. Think of this as a passive form of a Global Positioning System (GPS) connected to mapping software, with satellites attached to the walls. Of course, in the case of the ATS, the satellites are just small strips of reflective material that don't require electrical power. Also, like GPS, the system is redundant. Even if a couple of strips are knocked from the walls, there will still be enough for the transporter to accurately locate itself.
Robots Get Physical The transporters move materials through hallways to multiple floors. There are nine dedicated elevators and 264 pickup and drop-off locations. The ATS automatically calls the elevators at the appropriate time when a transporter needs to change floors. To keep things clean, separate "clean" and "soiled" carts make it possible for the transporters to keep wastes and dirty dishes away from fresh linen and food. When a transporter arrives on a patient wing floor, lights and pagers signal the arrival of the cart.
The transporters periodically receive their duty schedules from a central computer system. Staff within the hospital input the needs for such items as patient meals, linen, and trash pickup, and the computer system assigns the tasks to specific transporters. Without argument, the transporters go about their work in a timely manner without any intervention from humans.
Things Could Get in the Way The transporters have a sophisticated obstacle detection that makes them stop if something gets in the way. The transporter can detect the presence of even small items several feet away. When something (such as a human or box) blocks the path, the transporter politely responds. For example, it might simply say, "Vehicle is approaching," which should prompt humans to clear the path.
In case a transporter gets into a jam, a human can take manual control via an attached handset with a joystick used to control the transporter's movement. After typing in an access code, you can make the transporter go wherever you desire.
Robots Need Breaks, too Similar to humans, robots need to fuel up, clean themselves, and occasionally have repairs done. The ATS central computer, for example, tracks the transporters' battery charges and maintenance records. Nickel cadmium (NiCad) batteries on board each transporter provide about five hours of continuous operation.
If a battery runs low, the central computer adds a "gas stop" to the transporter's schedule. The transporter simply parks over a charging spot, and connections and charging actions occur automatically. Many charging locations are conveniently located next to elevators and service areas. Battery power for the transporter can be allowed to run low because a place to recharge is always located nearby.
As part of a preventive maintenance program, the central computer instructs transporters to take carts to an automatic cart wash for cleaning. This resembles a common automatic car wash that you find at many gas stations. The transporters drop off the cart in position for the cart to automatically go through the cart wash. The transporters themselves are sanitized by hand once each week.
If more serious maintenance is due, then the central computer directs the transporter to a special maintenance area. Real people (not robots) then perform the maintenance as needed.
Chosen Development Environment The centralized computer runs FMC Technologies' Automated Guided Vehicle (AGV) Manager software that controls the ATS. The AGV Manager integrates several programs together, which send and receive commands to and from the transporters, elevators, cart washers, operator displays, and other interface equipment. The AGV Manager operates on a Windows-based platform, and the programs were written using C++ and Visual Basic. FMC preferred this platform to ease training requirements, and to maximize the comfort level of support personnel.
Each transporter has software on board to control its movement. The operating system on each transporter is Phar Lap, which FMC Technologies chose for robustness and good real time control. Phar Lap is a Windows-friendly, real-time operating system.
Both the AGV Manager and transporter software have a development layer and application layer. The development layer is a standard release that is identical for all FMC Technologies installations. The application layer is written in a FMC Technologies programming language called A+, which allows developers to customize the system and transporters for a specific project.
Wireless LAN Provides Connectivity All instructions between the AGV Manager and the transporters take place using TCP over an 802.11b (2.4 GHz) wireless LAN. In fact, each transporter is a node on the network, complete with its own IP address.
Generally, the AGV Manager and transporters remain in constant communications. The AGV Manager receives a current status message from each transporter once each second. This data provides information regarding the transporter's current health and position, an essential element in the operation of the transporters. Without instructions from the AGV Manager, the transporters stop operating.
Coverage Holes a Potential Problem As with many other mobile applications, small coverage holes may exist, causing the transporters to occasionally lose touch with the wireless LAN. This is primarily caused by difficulties in providing complete coverage within a hospital environment (primarily because of the somewhat RF-hostile concrete-and-steel construction. Also, the constant movement of large groups of people (such as visitors, doctors, and medical students) offers varying attenuation that results in erratic coverage.
When humans utilize a wireless LAN, they instinctively adapt to coverage holes by moving to an area having stronger signals. We're all accustomed to doing this with cellular telephones. If the telephone doesn't work in a particular area, you move to where the telephone works better. Similarly, a transporter is permitted to continue three moves along its current route if it loses connectivity. This distance is typically approximately 8 feet and amounts to about 15 seconds, based on the speed of the transporter.
In other words, the transporter is able to cruise on its own for a short time without communication. This could make some people nervous, but remember that the transporter has extremely good obstacle-avoidance mechanisms! If communication is lost for an extended period of time, the transporter stops, and the AGV Manager notifies the appropriate personnel of the condition.
Challenges to Think About FMC Technologies claims that the biggest challenge in implementing the ATS was developing "mistake-proof" software. Mistake-proofing involves automating as much of the process as possible by removing operator actions. This requires the programmer to consider all the actions that could be made by the operator or transporter, and to eliminate them with additional processes and verifications. Because of the complexity of the ATS controlling 46 robots around a hospital, this is not easy. Mistake-proofing the ATS required extensive software testing, as well as reviews by peers and managers. The result is a system that is less susceptible to system instability, as well as being safe to use in a hospital environment.
The primary non-technical challenges impacting the OSUMC are space recovery and the many operational changes that must take place. Over the years, many different OSUMC departments had to utilize space around the elevators on various floors. OSUMC had to recover this space for the ATS to use for recharging and elevator-access functions. This meant working with the individual departments to evaluate their uses of the space and help them look at alternatives. Naturally, making changes like this and accepting the idea of having robots take on large labor-intensive efforts once performed by people goes against human nature. Considerable education must take place to prepare people to accept the changes.
Certainly, the development of a mobile wireless system such as the ATS is a monumental project, something that you don't want to try without some solid experience with similar solutions. The combination of logistics, robotics, and wireless connectivity in a hospital environment requires proven experience, dedication, and a bit of trust in the developers.
|