1

Mobile Robots in Hospital Environments: anInstallation Case Study

F. Capezio, F. Mastrogiovanni, A. Scalmato, A. Sgorbissa, P. Vernazza, T. Vernazza, R. Zaccaria

Abstract— This paper discusses a number of issues aroseduring the deployment of a commercial robotic platform ina hospital scenario. In particular, a realistic case study andinstallation process at Polyclinic of Modena (Italy) is described,where robots have to accomplish two different types of tasks,namely drugs delivery and waste transportation. The lessonlearned is that the design of a robot to be used in civilianenvironments must not only take into account state of the art anddependable algorithms, but also consider real-world issues (i.e.,not strictly scientific or technological) when adopting techniquesfor navigation, obstacle avoidance or localization. The paperdiscusses the most important features of the overall systemarchitecture that have been modified and the solutions that havebeen selected to deal with this realistic scenario.

Index Terms— Add up to 4 keywords here

I. INTRODUCTION

During the past few years, service Mobile Robotics forobject transportation in semi-structured environments andwarehouses developed in a mature research field. A number ofsystems and algorithms have been presented, which are able –in principle – to provide customers with specifications abouttheir use. Industrial applications, and especially AutomatedGuided Vehicles (AGVs in short) are nowadays very common.However, a number of limitation are usually associated withthese systems, which are related to the need of operating ona workspace that is specifically modified, or even built onpurpose, for the robots.

Among the many functional or non-functional requirementsthat robots must be able to adhere to, a service robot mustbe dependable. Under a customer’s perspective, failures implycosts: a service robot must be less expensive and more efficientthan a corresponding team of human workers when performingthe same task. It is necessary to analyse how customer’sor contingent requirements can be guaranteed (or at leastenforced) by the robot control framework and architecture,both at the software and hardware levels. In particular, it isnecessary to take into account the impact of such requirementson the robot design, both at the hardware and software levels.

This paper describes the lesson learned in deploying acommercial service robot in a real-world environment. Inparticular, the paper discusses how a robotic platform hasbeen designed to better comply with a number of issues aroseduring the deployment process, as well as to guarantee theexecution of the assigned tasks, namely drugs delivery andwaste transportation. These design choices take into accountboth hardware and software issues.

The deployment of robots in similar scenarios is not new.The first robot operating in hospital environments is HelpMate

[1], which appeared in 1991 and was used for the trans-portation of small-sized objects at Danbury Hospital. Afterthis first example, other robots followed the same philosophyand strategies adopted for HelpMate. I-Merc [2], which isspecialized in hospital meal transportation, and Care-o-Bot[3, 4], which has been developed to provide assistance toelderly and people with special needs are such a systems.

In recent years, mobile robots for hospital transportationstarted to be a commercial business. The most known systemin Europe is TransCar [6] by Swisslog, which is a laser-guided AGV that can transport payloads up to 450 kg.The vehicle is able to move in order to lift specificallydesigned boxes where the material to be handled is assumedto be located. Many robots are able to operate in the sameworkspace or storage area. However, the system assumes thatthe environment is very well-structured: such requirementsinclude, for instance, wide space, flat floors and elevators thatprecisely align with the floor in order to allow robots to enterwithin. The TransCar solution seems feasible in new buildings,although it is difficult to adopt it in existing (and old) hospitalbuildings. Recently, Swisslog produced a small autonomousrobot called RoboCourier [7], which is designed for inter-department material transportation, with a payload of about25 kg. TUG [8] from Aethon is similar to RoboCourier. Ithas been designed for the transportation of various materialsas dietary trays, medications, linens, blood samples, medicalrecords and pharmacy drugs. It can be interfaced with mostof standard carts used in hospitals, which can store up to 250kg. FMC Technologies develops ATLIS [9], a robot for thetransportation of heavy objects that is very similar to TransCar,but characterized by a heavier payload. However, it requiresmajor changes to the workspace. Recently, Muratek KeioRobot [5] has been presented, which is not yet commerciallyavailable but seems very promising. It is an omni-directionalautonomous robot, developed for the transportation of lightpayloads.

The paper describes the experiences gained during a real-world installation of Merry Porter, a service mobile robot fromGenova Robot R©. The paper is organized as follows: SectionII describes the considered real-world case study; Sections IIIand IV introduce the robot architecture that has been designedto accomplish the required tasks; Section V discussed theinstallation procedure in a hospital environment. Conclusionsfollow.

II. CASE STUDY

In this Section we describe the two types of mission thathave been required by the hospital service management unit.

2

Fig. 1. Different robot tasks. Left: waste transportation. Right: drugs delivery.

The case study discussed in the article is represented by ahospital environment, the Polyclinic of Modena. The hospitalneeds a high level automation to accomplish two tasks: wastetransportation and drugs delivery. Each task is characterizedby a specific path for the robots to follow and specific needs.

As depicted in Figure 1 on the right, the drugs deliverymission starts from the pharmacy, which is located at thebasement floor and arrives at the sixth floor, where variouspediatric departments are located. The total path length isabout 50 m. The delivery is scheduled three times per day,and in particular early morning, midday and evening, subjectto the fact that they occur before patients’ visits.

Waste transportation (Figure 1 on the left) has a differentand longer path covering about 500 m. The robot starts fromthe fourth floor where the operating rooms of general surgeryare located to transport waste to a waste dump placed outsidethe hospital, passing through the basement floor. Without theadoption of robots, this task needs two workers: the formerto transport waste to the basement floor, the latter to movethe waste to the external garbage dump with a small electricmachine.

As it can be noticed, robots need to use and control: (i)elevators; (ii) additional environmental devices, such as theones controlling automated doors: e.g., the pharmacy has asystem for access control for security reasons.

To accomplish these two tasks, robots must be equippedwith different components. On the one hand, a robot requestedto perform drugs delivery must be provided with a security boxto prevent drugs theft. The box should be opened only with apredefined code, known by authorized personnel. On the otherhand, a robot performing the waste transportation tasks mustbe provided with a conveyor to load waste (in order to avoidhuman personnel), and by a GPS for localization, since it hasto transport its payload outside the hospital.

A commercial robot system must maximize the reliabilitybecause, as previously pointed out, each inconvenience ordelay costs. Typically, maintenance efforts are parts of coststhat must be minimized. After analysing these missions, wefound the following weak points:

• Hardware structure: real and general-purpose environ-ments can require a number of hardware features on therobot side in order to overtake physical problems likeslope or heavy payloads.

• Navigation and security: robots must navigate in dif-ferent environments that can present obstacles. Areas canbe crowded, thereby needing particular trajectories: as aconsequence, the navigation system must be adaptable.Even more critical is the system security. Robots mustavoid contacts with objects or people. The security systemmust have higher priority over the navigation system andit must fulfil the rules defined in the European laws, inparticular EN 1525:1997.

• Localization: localization failures are not acceptable:when the robot localization fails, the manual interventionof a technician is necessary.

• User interface: in order for the system to be used by nonspecialists, a simple interface allowing users to providerobots with tasks and to monitor their their executionis required. Interfaces can be different: either for simplemonitoring or for providing advanced commands, forqualified personnel.

The following Sections consider each problem and presentthe developed solution for the presented system.

III. HARDWARE ARCHITECTURE

Merry Porter has a base architecture that can be extendedwith different modules, either hardware and software. Thehardware modules allow to configure the robot with differentdevices, like GPS or conveyors, as well as software modulesallowing to separate and manage each component with propercharacteristics. The base architecture of each robot fulfils thesespecifications:

• maximum speed of 1,5 m/s;• max slope without payload 30%;• 7% slope with 100 kg of payload;• 180 kg of payload without slope;• 3 cm step overtake.These characteristics are required by a standard hospital

where there can be very long corridors (hence: high speedis required in order to avoid waste of time), the floors canbe rugged and sloping, and the alignment between the floorsthemselves and the elevators can be not perfect (hence: therobot must overtake steps).

The base robot architecture has these characteristics (Figure2):

• unicycle structure with a front steering wheel;• a telescopic turret for placing sensors at a variable height

between 1.40 to 2.10 meters, to avoid occlusions due tosurrounding people;

• 4 motors and drives (2 for the rear wheels, 1 for the frontsteering wheel, and 1 for the telescopic turret) connectedby CANbus;

• 1 Hokuyo laser scanner for localization only, placed ontop of the turret;

• 1 Sick S3000 laser scanner for security and obstacleavoidance placed at 30 cm from the floor;

3

Fig. 2. Merry Porter base architecture at Polyclinic of Modena.

• 2 IP cameras for payloads and environmental surveil-lance, placed on the turret;

• 1 DLPS R© active beacon localization system, placed ontop of the turret;

• 16 ultrasound sensors placed around the robot body forobstacle detection;

• 1 alert flashing light to advise people about the robotpresence.

• 1 PC embedded fanless CPU Intel Celeron 1Ghz withLinux-based O.S.

Robots are equipped with two lithium polymer batteriesallowing them 4 hours of continuous work with 30 minutescharge. Consequently, robots can work for more than 21 hoursper day. The two cameras prevent or record materials theftsand, at the same time, they can improve the security systemof the hospital, by visualizing their input stream in the centralroom of the security personnel.

IV. SOFTWARE ARCHITECTURE

Since the Merry Porter software architecture present dif-ferent modules, these are integrated within a multi-agentbased system, called ETHNOS [10], where each agent hasa specific task to carry out, like managing missions, lo-calization, or trajectory planning and following (Figure 3).ETHNOS provides a soft real-time extensions to the Linuxkernel supporting different communication, execution, andrepresentation requirements. This is built over a Linux kerneland a dedicated network communication protocol allowing notonly the communication between the different parts of therobot, but also with other software agents running on boardof devices distributed throughout the environment.

Fig. 3. Agents present in the robot software architecture.

A. Navigation

Requirements: The navigation subsystem must present anefficient algorithm for trajectory following allowing to navi-gate in different kinds of environment. It must be characterizedby good obstacle avoidance algorithms and any kind of col-lision must be prevented at any cost: as a consequence, theassociated priority is at maximum. This is necessary in anycivilian environment where people as well as other obstacleslike hospital carts often left in the robot workspace.

Approach: The robot navigates on a predefined graph,following a given node sequence that can be chosen by theuser or it is automatically generated by a trajectory planner.In absence of obstacles, node-to-node navigation is simplyperformed by moving along the connecting straight lines.The navigation subsystem can be observed in Figure 3: theTrajectory Generator computes the linear and angular speedthat must be fed to actuators, depending on the current positionreturned by the Localization Agent and the next point to bereached determined by Task&Path Manager. Controls are thensent to the Motor Manager.

Obstacle detection and avoidance: In order to guarantee thesafest possible behaviour, obstacle detection is managed by asafety laser scanner (the previously cited SICK S3000) withtwo different safety mechanisms, i.e., hardware and software.The hardware mechanism consists in an internal circuit that,when the laser detects something in a given (short) range,automatically stops the robot by cutting the motor power,which makes the motors brakes to be activated. This systemis necessary according to European laws, and it is activatedonly when extremely necessary. Standard obstacle detectionis made by a software agent, which subsumes the hardwaremechanisms in most cases. The software analyses all the datareturned by the safety laser and feed them to a simple rule-based engine: the final output depends also on the robot speed,corridors and passages width. For example, the higher the

4

speed the greater the distance at which the robot begins toslow down; the smaller the passage (such as when enteringan elevator) the smaller the minimum allowed distance fromobstacles before stopping the robot. Simple stop (or slowdown) strategies guarantee a safe approach, allowing to avoidcollisions with people and objects. Furthermore, they guaran-tee a very repeatable behaviour. Therefore, they maximize thesystem reliability.

As a consequence of a security standard check on therobots performed by an expert society, another hardwaremechanism has been installed. This mechanism prevents thelateral collision and the shear effect that can occur in the casethat the robot, when performing a high-curvature trajectory orwhen moving very close to walls, comes very close to people.To solve this issue, two photocells have been placed on rodsof about 15 cm length on the lateral part of the robot: whensomeone is located between the photocells or it hits the rods,the motor power is taken off. Other 15 cm rods with photocellsare placed on the back of the robot to prevent collisionswhen the robot moves backward. This solution complies withEuropean standard: reverse motion is used only when exitingfrom the elevator and when approaching conveyor belts.

On the one hand, when the robot is in cluttered and verycrowded environments, it does not avoid obstacles (but simplystops), because this can cause it to be trapped in very narrowareas. On the other hand, an algorithm for obstacle avoidancecan be used wider areas. The algorithm is based on the conceptof “roaming stripes” [11]. A roaming stripe is a diamondshaped region connecting two nodes. These are designed insuch a way that their intersection with the free space is alwaysa convex area. When the obstacle avoidance algorithm isactive, the trajectory to avoid obstacles is computed through astandard Artificial Potential Field, by storing laser data into alocal probabilistic map centered on the robot reference frame.During navigation, the robot is allowed to deviate from itstrajectory to avoid obstacles, but it is never allowed to exitfrom the roaming stripe. This guarantees that the robot alwaysmoves within a convex area containing the target node. Byassuming that, sooner or later, all dynamic obstacles (e.g.,people, piece of furniture or objects) move or are moved away,this in turn guarantees that the robot will be able to reach thetarget by following a straight line.

Pros and Cons: The adopted solution is able to guaranteethat robots navigate in selected areas, because the roamingstripes algorithm always select a trajectory that lies within thestripe. This is very important in a real-world case, becausemedical personnel must be guaranteed always a free path foremergency cases. The on board safety system (made up a laserrange finder and a number of sonars) is aimed at preventingobstacles in a very conservative way. However, this approachincreases the time necessary to complete the task.

B. Localization

Requirements: A robot required to navigate in an environ-ment for very long periods of time and with high reliabilitymust be provided with a robust and redundant localization sys-tem. With respect to the introduced case study it must be noted

that localization must provide also a very precise estimate ofthe robot position. The workspace is characterized by manynarrow passages, like elevators and doors. Furthermore, therobot must be able to approach conveyors with a positioningerror lower than 2 cm. In the case that this accuracy can notbe met, the payload could fall down.

Approach: Merry Porter is provided with two different local-ization systems in indoor and a GPS-based system for outdoor.All the three systems communicate positioning information toan Extended Kalman Filter (EKF).

1) Indoor - Map Based Localization: Usual localizationapproaches based on available maps periodically compareobservations taken from the environment with a map repre-sentation, with the aim of correcting the a priori estimateprovided by odometry. Among the most common approaches,Kalman filter based localization assumes that an unimodalprobability distribution is adequate to represent the poseestimate, thus being a simple and efficient solution to localposition tracking. Merry Porter exploits the EKF with a prioriknown environment maps. The design choices associated withthe whole localization subsystem have been described in [12],where the use of line-based features (extracted from a laserrangefinder) is discussed: a technique to improve the correctivepower of each extracted line feature is discussed. In particular,[12] introduces the concept of ”low frequency cross section”:in typical indoor environments, above a given height from theground, environments are more regular and simple. This hasobvious consequences when computing line segments fromrange data: each laser scan produces a smaller number of lines,each one being longer and more reliable. However, the hospitalenvironment turns out to be more complex. For instance,in the basement floor there are areas where the ceiling isparticularly low, thereby requiring the adoption of a telescopicturret (where the localization laser is mounted), which is ableto lower its position if necessary. This is actually performedby the robot control architecture as a consequence of specificrobot area.

2) Indoor - Active Beacon Localization: The active beaconlocalization system (called DLPS) has been described in [13].The base idea starts from classic active beacons methods wherebeacons have an unique identifier and a specific position inthe map. When a beacon is in line-sight with respect to therobot perspective, robots can send them specific commands;as a consequence, the active beacon can reply with usefulinformation about localization. Obviously enough, differentcommands issues by robots are possible. In particular, thesystem adopts the classic trilateration principle, that is whenthe robot detects three beacons it is able to compute its positionprecise position. The DPLS system introduces a differentapproach where beacon-based localization is formalized as aposition-tracking problem. The information sent from beaconsis processed by the EKF, because the high non-linearity of themeasurement model. Every time instant ti, the DLPS systemprovides the robot with the identifiers of the detected beacons,their positions (xbk, ybk) and the angle λk, for each detectedbeacon k. The angle λk is interpreted as the estimate ofthe direction of the beacon. More precisely, two values areconsidered: λk and σ2

k correspond respectively to the mean

5

value and the variance of the position estimate of beacon k.This estimate is fed to the EKF to correct the estimate of therobot position.

3) Outdoor - GPS: The outdoor localization system derivesfrom a similar system previously tested in the context of anairport surveillance robot project, which has been describedin [14], where the very huge space characterized by few linesfeatures in the environment needed an alternative localizationmethod. A common non-differential GPS localization systemhas been developed, which is integrated with the laser scannerdata. Unfortunately, GPS measurements are corrupted by errorsources introducing highly coloured noise with significant low-frequency components, which can be modelled as a non-zeromean value (i.e., a bias) in GPS errors slowly varying in time.The analysis of both longitude and latitude data collectedfor 24 hours at a fixed location clearly shows this effect:considering the Fast Fourier Transform (FFT in short) of GPSlongitude and latitude data, low-frequency components can benoticed, corresponding to a slow variation of the signal overtime. By estimating this bias in GPS measurements, one canexpect to improve GPS data precision, therefore making robotlocalization more accurate. To this purpose, an augmented statevector x̂ is defined, comprising the x, y, and θ componentsof the robot pose, as well as the xgps and ygps componentsof the low-frequency bias. Since the coloured components arethen separated from additive white Gaussian components ofGPS noise (i.e., they are comprised in the state vector), theEKF can be applied.

When moving outdoor, detected line features of the a priorimap mostly correspond to external walls of buildings. In thissituation, a smaller number of features are usually available,since the robot mostly traverses areas where no lines aredetected at all. However, when line features are available, theircontribute is sufficient to estimate the full state vector thenpose and precision of GPS measure.

Pros and Cons: In indoor areas the combined use of map-based and beacons-based localization is complementary. Themap-based algorithm does not need any external devices but,in few parts of the robot paths, this does not provide thenecessary precision. Even worse, the variance associated tothe localization estimate is very high, or no warranties aboutlocalization can be assured. Under a commercial perspective,the beacon-based localization system adds costs to the overallsystem set-up. However, it turns out to be a good choice forenforcing system reliability. Finally, GPS-based localizationhas good performance and it is mandatory for the outdoorlocalization.

C. User Interface - Robomap

Requirements: A commercial robot system must present asimple and user-friendly interface.

Approach: The main user interface is provide by a softwaretool called Robomap, an integrated management system thatallows to define maps, missions and real time monitoring ofthe state of the robots. Map definition is only allowed to well-qualified personnel and it provides all the elements necessaryto describe fundamental parts of the environment to be used

Fig. 4. Robomap Interface: Map definition starting from CAD maps.

Fig. 5. Robomap Interface: On-line monitoring and visualization of the robotmap, mission nodes and active beacon positions.

by the robot localization system. As a matter of fact, a mapcomprises both lines and active beacons. The specification ofmap lines can be directly made by using and refining alreadyavailable CAD maps (Figure 4). An alternative method forpopulate the map with suitable lines for localization is to traceout the lines derived by the line extraction algorithm taken bylaser scanner processing. To do this, it is necessary to movethe robot in the interested location.

The tasks or missions definition mode allows to createnodes and links between nodes, which compose the path. Eachlink can be associated with a number of parameters, such asthe desired speed for the robot on the link or the preferredlocalization method. Furthermore, for each node it is possibleto declare a set of actions that the robot must perform in orderfor the mission to complete or continue, such as requesting thepresence of an elevator at the floor, opening an automated dooror loading the payload (by communicating to the conveyorbase station).

During robot missions, Robomap allows for the robot on-line monitoring (Figure 5). This mode allows to monitordifferent robot properties, such as the position with respectto the map, speed, jog, obstacles revealed with sonars, batterystatus, detected beacons, just to name but few. Furthermore,a human supervisor can issue commands to the robot formovement control and mission management (e.g., starting orchanging a mission).

6

V. APPLICATIONS

This Section describes the system set-up realized at Poly-clinic of Modena, Italy. We explain the main environmentrequirements, the device installation process and an overviewabout performance issues and improvements on typical hospi-tal tasks.

A. Environment and Devices

Robots have to control a number of devices distributedin the environment in order to accomplish their tasks. Forexample, moving between two floors requires an elevatorcall; accessing an area may require to control automateddoors. Environment automation is essentially based on customdevices that communicate via an Echelon Lonwork Network.The network guarantees a very flexible topology and it is easilyadapted to any environment.

In order for all the robot parameters to be accessible tohuman supervisors, the whole workspace is provided witha wireless network communication system. This system isused also to allow the communication between robots anddevices, specifically through a monitoring system remotelylocated on a workstation, which is connected both to thenetwork and to the Echelon fieldbus. In order to explain howthe environment automation works, we briefly discuss theelevator control. Custom devices are connected to the elevatorcontrol system, which requires a simple installation that mustbe performed by a qualified technician. The device is directlyconnected to the elevator buttons. Therefore, it is possible toperform all the actions provided by the elevator panel. Theinterface device is connected to the Echelon fieldbus like allother devices and the supervisor workstation. Therefore, thesupervisor can query each device and it can issue commands tothem. Robots can interact with the supervisor by simply usingthe wireless network provided by the hospital and the multi-agent framework used to develop both robots and supervisorapplications.

In order to complete the required tasks, the describedbuilding automation is not sufficient. In particular, the de-scribed hospital application needs other components, such asa conveyor where the personnel leaves waste waiting for therobot transportation. The conveyor must be connected to theautomation network and it is controlled by the supervisorapplication. For instance, in the described set-up, a number ofconveyors have been installed, which can be directly controlledby robots through ZigBee commands.

B. DPLS implementation

The DPLS system is composed by a rotating laser placedon top of the robot telescopic turret as well as by a number ofactive beacons distributed in the environment. Active beaconsare powered by batteries and communicate through the ZigBeeprotocol. These two characteristics allow to minimize timeand costs for the set-up. The laser carries information aboutthe encoder associated with the motor that is responsiblefor rotating the laser itself. When the laser hits a beacon,the beacon sends a message to the robot with the beacon

Fig. 6. Robot takes the elevator to go from floor -1 to floor 6. 1,2,3,4:Robot calls elevator and it enters. 5,6: Robot performs reverse, it turns and itcontinues the mission at 6th floor.

identifier and the encoder value: it is possible to estimate therobot position as previously described. Battery duration is veryimportant in real-world scenarios because human personnelcan not be frequently dedicated to substitute beacons.

Beacon electronic parts are essentially two, namely ZigBeecommunication and laser management, which allows for theinterpretation of the message contained in the laser light. Thefollowing strategy is implemented for maximise beacons life:

• beacons wake up every 28 seconds and check if any robotis near, otherwise return to a sleep state;

• if a robot finds a beacon, it maintains the beacon activeand turns on the laser management part;

• after 160 seconds, when the beacon does not receive anysignal by the robot, it returns to a sleep state.

Using these devices, beacons need to recharge every threemonths.

C. System evaluation and automation improvements

The described system reduces the number of manual trans-portations and improves the management of the describedtasks. Workers and nurses can delegate robots with a numberof low-level tasks, thereby focusing on other tasks where theirknow-how is essential. Drugs delivery is not a very frequentlyneeded task. Instead, waste transportation requires a hugeamount of effort for human personnel.

The current batteries power cycle allows robots to operatemore than 21 hours a day, i.e., a period of time that is normallycovered by three workers, since the standard working time is8 hours a day). Another consideration must be done relatedto medical waste laws. With the introduction of robots, the

7

hospital management wants to divide the different paths ofmaterial distribution (i.e., medicine, linen and food) and wastedisposal as medical regulation impose. In particular, operatingsurgery waste has more strict rules suggesting that this wastemust come in contact with the personnel as unfrequentlyas possible. Under this perspective, automated robot-basedtransportation enforces this aspect.

As it can be seen in Figure 1, the two task types are char-acterized by very different paths, distances and then differentnecessary time to complete. The robots requested to performwaste transportation has to cover about 500 meters and totake an elevator, with a mean overall mission time of about15 minutes, which is quite constant because there are not manypeople in those hospital areas. Much less is the distance that isrequired to traverse in case of drug delivery, which is only 50meters. However, the path presents a huge number of obstaclesand people. As a consequence, the time to accomplish twodeliveries, in the two pediatric departments, is about 8-10minutes.

Currently, waste transportation presents a number of diffi-cult issues, to the extent that it could not convenient for thehospital management. It is evident that human personnel ismore flexible and provide better performance in some cases.On the one hand, the existing waste transportation system isproven to work reasonably well: structures for waste storageand transportation are compliant for the task, if performedby humans. On the other hand, using an automated robot-based system requires to install a number of ad hoc conveyors,whereas the existing big carts for waste transportation mustbe replaced by other small containers. Switch from human toautomated transportation implies an important change in thehospital habits that is difficult to implement.

VI. CONCLUSIONS

An example of commercial robots for hospital environmentshas been presented. Merry Porter robots use different andconsolidated approaches to navigate, avoid obstacle and lo-calize. All of these aspects have been designed to improvereliability, with the aim of comply not only with state of theart research activities, but above all with real-world regulationsand functional needs of a typical hospital environment. Thecurrent set-up at Polyclinic of Modena has been described,where two robots are used for drugs delivery and wastetransportation. The article addresses a number of topics thatplayed a major role in the deployment process. In particular,it is focused on the architectural and system-level choices thatdeemed necessary for a real-world installation.

REFERENCES

[1] Evans, J.M.; HelpMate: an autonomous mobile robot courier for hospi-tals. In proceedings of Intelligent Robots and Systems ’94. ’AdvancedRobotic Systems and the Real World’, IROS ’94.

[2] F. Carreira et al., ”i-Merc: A Mobile Robot to Deliver Meals insideHealth Services” in Proceedings of the 2006 IEEE International Con-ference on Cibernetics & Intelligence Systems & Robotics, Automation& Mechtronics, 2006, 1-8.

[3] B. Graf, M. Hans, and R. D. Schraft, ”Care-O-bot IIDevelopment of anext generation robotic home assistant,” Autonomous robots 16, no. 2(2004): 193-205

[4] Care-O-bot 3: http://www.care-o-bot-research.org/care-o-bot-3

[5] M.Takahashi, T.Suzuki, H.Shitamoto, T.Moriguchi, K.Yoshida, 1Devel-oping a mobile robot for transport applications in the hospital domain,Robotics and Autonomous Systems, Vol. 58(July 2010) pagg: 889-899.

[6] Swisslog TransCar - http://www.swisslog.com/index/hcs-index/hcs-systems/hcs-agv/hcs-agv-transcar.htm

[7] Swisslog RoboCourier - http://www.swisslog.com/index/hcs-index/hcs-systems/hcs-mobile-robot-speciminder.htm

[8] Aethon TUG - http://www.aethon.com/products/default.php[9] FMC Technologies ATLIS - http://www.fmcsgvs.com/content/products/atlis.htm

[10] M. Piaggio, A. Sgorbissa, and R. Zaccaria: A programming environmentfor real-time control of distributed multiple robotic systems. AdvancedRobotics 14(1): 75-86 (2000)

[11] A. Sgorbissa and R. Zaccaria, Roaming Stripes: Smooth Reactive Navi-gation in a Partially Known Environment, Proceedings of the 2003 IEEEIntemabonal Workshop on Robot and Human Interactive CommunicationMillbrae. California, USA, Od 31 - Nov. 2, 2003

[12] F. Mastrogiovanni, A. Sgorbissa and R. Zaccaria. Learning to ExtractLine Features: beyond Split and Merge. In Proceedings of the 10thInternational Conference on Intelligent Autonomous Systems (IAS-10),Baden-Baden, Germany, July 23 - 25, 2008.

[13] Maurizio Piaggio, Antonio Sgorbissa, Renato Zaccaria, Beacon BasedNavigation and Localization for Service Mobile Robots, Proceedingsfrom the 2nd International Symposium on Robotics and Automation(ISRA2000), Monterrey, N.L. Mexico, November 10 - 12, 2000.

[14] F. Capezio, A. Sgorbissa, R. Zaccaria (2007). An Augmented StateVector Approach to GPS-Based Localization. In Proceedings of the7th IEEE International Symposium on Computational Intelligence inRobotics and Automation (CIRA-07), Jacksonville, Florida, June 21-23,2007.

[15] F. Mastrogiovanni, A. Sgorbissa and R. Zaccaria. Context AssessmentStrategies for Ubiquitous Robots. In Proceedings of the 2009 IEEEInternational Conference on Robotics and Automation (ICRA 09), Kobe,Japan, May 12-17, 2009.