Keep It Simple, Hybrid! A Case Study in Autonomous Office Courier Robot Control

We describe the control architecture of an autonomous mobile robot, using courier tasks in office buildings as a demonstrator domain. The robot robustly performs state-of-the-art tasks such as autonomous navigation through the building, dynamically avoiding obstacles, entering rooms, passing automatic doors, and calling and riding the elevator. We give performance statistics of robot tours of about 8 km length in our three-storied institute building. The interesting feature of the control software is its simplicity. This is achieved by combining pieces of fuzzy control, basic geometrical reasoning, target-point planning, and map-based route planning in a hybrid levelled control architecture. The control parameters proposed by low-level behaviors are fused and executed by a complex behavior, which gets selected according to the recently executed operator in a high-level mission plan. The paper sketches these pieces individually and their interplay, with emphasis on the low-level control. 1 Background and overview Autonomous robots clutter todays’ research lab corridors. Realizing the basic skills of an autonomous office courier robot, such as obstacle avoidance and localization within a building, has become much of routine—at least within a research context. This is the time then to experiment with “softer” aspects of robot control systems, such as architectures and representation formalisms that help reduce the effort for developing and maintaining the control software, or the integration of a robot into an existing information infrastructure and facility management. So, the issue is design, and a clue to good design is simplicity. In this paper, we describe a study in robot control system design, whose main purpose was to achieve simplicity in several respects, rather than a new robot functionality. The demo application scenario is autonomous office courier services of the following kind: The robot has a map of the building (which needs not be metrically accurate), and it has a wireless link to the local ethernet and to a software interface to the elevator control and the control of all automatic doors at the ends of corridors, which are normally kept shut for fire protection. The robot receives courier jobs from human agents by e-mail, consisting of start and end points of transportation tasks within the whole institute building, which may involve entering rooms and using the elevator. Job execution has to be planned and scheduled automatically, and the robot has to travel autonomously under normal security requirements, such as not running into walls or over humans. This application scenario is clearly similar to others in the literature, such as for mops [TGVS99] or rhino [Bee99]. The robot used for the practical experiments in our study (Fig. 1a) is a sturdy (200 kg) industry-standard driver-less transportation platform with an added control module to allow for autonomous control, consisting mainly of a PC/104 computer under Linux, which supports wave-Lan communication. The robot has a differential drive plus four caster wheels. It has two types of sensors: A simple odometry (dead reckoning from wheel encoder signals) and two sick laser scanners at its front and back. [Arg00b] describes all technical details. The arena is our three-storied institute building, of which Fig. 1b shows a map of the first floor. The three storeys are connected by a staircase, which the robot must avoid, and by an elevator, which it operates over its Ethernet link. A typical transportation task is to go from office 102 on the first floor to 227 on the second floor. The robot platform and the infrastructure was available for us from prior projects [PFPB99], and we have used it for our study without changes in the hardware and low-level software. Email: [arghir | hertzberg]@gmd.de Fig. 1. (a) the robot exiting from the elevator; (b) map of the first floor with a performed concrete trajectory inserted. (The insertion is done manually, as the robot in the study has no access to ground truth.) Door 3 and Door 4 are automatic doors; the elevator is between the staircase and Door 4. The rest of this paper describes, first, the general control architecture including the planning layer, which is not very sophisticated in our study. Then, we continue bottom-up, describing the basic behaviors (Sec. 3) and the context-dependent combination of their outputs into the complex robot behavior (Sec. 4). After that, we discuss the performance of the robot and of its control system design (Sec. 5). Section 6 concludes. 2 The control architecture An important issue in simplifying the robot control system is an architecture that allows those problems to be handled off-board the robot that logically need not be done on-board. A chief problem of that kind is to handle the information about the building. This may be a relatively simple topological and metrical building model plus some basic information of direct importance to the robot control, such as whether office doors would open into the corridor or into the office; we have used such a relatively simple model for our study. Alternatively, the information may come from a full-fledged facility information system, whose purpose far exceeds the direct needs of supporting a mobile robot. Note that such a software design-oriented separation of functionality blurs the boundary of the robot, whose control then partly resides inside a computer network that is physically disconnected from the “proper” mobile robot body. This distinction is unimportant and may be invisible for a human user. To enhance reliability of the wireless communication to the mobile robot and to reduce traffic over the wireless link, the communication with the robot should be on some abstract, task-oriented level. This idea has been used before, for example, in high-level teleoperation, such as in the ROTEX space station manipulation robot [BLSH95], or in plan-based mission control as in the Deep Space 1/Remote Agent experiment [MNPW98, Rem00]. The resulting control architecture is levelled, which is obviously not a new design principle, as, e.g., its extensive coverage in a textbook like [Ark98, Ch. 6] shows. In our study, a typical user request is for the robot to move from one room to another room, e.g., Go(102,120). The abstract trajectory, based on abstract regions and objects like corridors and doors, is computed using the map of the building like in Fig. 1b. (Fig. 1b also shows a concrete trajectory as performed by the robot in executing the abstract one.) The computation is done in the Planning layer of the architecture, cf. Fig. 2, based on the building model, and it is simple: depending on the building structure, it consists of a graph search or even a tree search. In the example, the abstract trajectory would be to move from 102 into and through Corr 4, through Door 3 into and across Corr 6, through Door 4, and so on. The planning layer is also the place in the architecture for handling sets of user requests or for breaking down more complex tasks to a sequence of elementary motion tasks as just described. A sequence of motion tasks is not yet the action list sent to the physical robot for execution. The building model contains more specific information for the low-level robot control. For example, driving along a corridor like Corr 5 where office doors open into the corridor requires more care than along Corr 4, which can be expected to be comparatively open (but of course with the permanent chance of humans crossing or temporary obstacles blocking). Corr 6 again requires different low-level control as its floor covering is different (tiles vs. carpet) and proximity to the staircase must be avoided with guarantee at any time, so the position control must be strict. The action list sent to the robot (cf. Fig. 2) respects and encodes that type of available information by translating the abstract trajectory context-dependently into a sequence of mid-level actions, which are fine-grained enough to capture these differences. In our study, we have used 26 different such actions, which include, for reasons of uniformity, some trivially executable ones like waiting or sending a command to the automatic doors or to the elevator. The interesting ones are those for motion: different varieties for turning, driving, and correcting the position estimation using the laser scanners in defined areas like corridor ends. Space does not permit to describe the planning layer and its components in more detail, to which we refer to [Arg00b]. We will come back to describing and discussing some mid-level actions below, when it comes to executing them. Fig. 2. Simplified sketch of the overall control architecture for the study. The full implementation as in [Arg00b] has structured the planning layer further, which is omitted here for brevity. Solid arrows depict data flow; the dashed arrow depicts physical action by the robot. See text for more explanations.