i-fork: a Flexible AGV System using Topological and Grid Maps

Size: px
Start display at page:

Download "i-fork: a Flexible AGV System using Topological and Grid Maps"

Transcription

1 i-fork: a Flexible AGV System using Topological and Grid Maps Humberto Martínez Barberá Juan Pedro Cánovas Quiñonero Miguel A. Zamora Izquierdo Antonio Gómez Skarmeta Dept. of Communications and Information Engineering University of Murcia Murcia (Spain) humberto@um.es juanpe@dif.um.es mzamora@um.es skarmeta@dif.um.es Abstract - In this paper we describe the navigation and planning of the i-fork system, a flexible AGV intended to operate in partially structured warehouses where frequent floor plant layout modifications occur. This is achieved by using a combination of topological and grid maps in such a way that the operator work in layout modification procedures is greatly reduced. The system is currently working in an agricultural company with great success. I. INTRODUCTION The main guidance system in early industrial Automated Guided Vehicles (AGV) was a wire buried on the floor. A frequency was induced through the wire in such a way that the AGV could detect and follow it, being directed through its route. In this case the intelligence was in the floor controller that produced the signals on the wire. In this case, the AGV acts as a kind of dumb-device. The next generation of AGV systems, impelled by the advances and costs reduction on microelectronics and microcomputers, made the AGV more intelligent, and thus they could store instruction about the routes, make decisions and have part on traffic control of the global system. Besides, new wireless guidance system, using lasers or inertial systems, made easier the installation of such systems. Nowadays, the AGV systems play a central role in industrial automation, being necessary for the highly automated manufacture model used today. Using AGVs a factory line can be active 24 hours a day with a minimal human interaction. This kind of vehicles has been applied for tasks like movement of products in warehouses, distributions and storage functions or transport of subparts between different assembly stations in a production line. Developing an AGV system requires, at least, catering with some of the following topics: Navigation & Guidance allows the vehicle to follow a route. Routing is the vehicle's ability to make decisions along the guidance path in order to select optimum routes to specific destinations. Traffic Management is a system or vehicle ability to avoid collisions with others. Load Transfer is the pickup and delivery method for an AGVS system, which may be simple or integrated with other subsystems. System Management is the method of system control used to dictate system operation. In this paper we will describe the i-fork system, a flexible AGV intended for operation in partially structured warehouses and with frequent changes in the floor plant layout (e.g. the production lines). This is achieved by way of incorporating a high degree of onboard autonomy and decreasing the amount of manual work required by the operator when establishing the a priori knowledge of the environment (map, docking points, routes, etc). This paper is organised as follows: next section reviews current point-to-point navigation techniques. The following section briefly describes the i-fork system, both the hardware platform and the software architecture. Then the i-fork navigation system is described and discussed. Finally some conclusions are presented. II. AGV NAVIGATION TECHNIQUES Current point-to-point AGV navigation techniques can by roughly separated into two groups, fixed path and open path navigation. In both cases the basic idea is that the AGV has to follow a path. Fixed Path Navigation uses the original idea of embedded wires in the floor, although other techniques as magnetic or reflective tape on the surface of the floor can be used as well. In this case, the paths are fixed and thus a modification of the layout implies stopping the whole system and changing physically the paths. Moreover, if it consists of embedded wires the modification can be even more problematic. On the other hand, the

2 navigation task is easy, only requiring a sensor to detect the guide on the floor. In Open Path Navigation the AGV can, at least theoretically, take any path to navigate between points. Thus, in order to navigate in this environment, the AGV needs a map and a method to know its own location. In current systems the most used location methods are: Laser guidance. There are several passive reflective beacons that can return back a laser beam emitted from a device in the AGV. Knowing the beacons location in the map, the position of the AGV can be computed using geometry. This method presents the highest accuracy in open path navigation at the expense of a high cost. Inertial guidance. Onboard gyroscopes are used to compute the heading of the AGV. Location is computed from the measures of internal wheel encoders. The uncertainty of these systems degrades with time and thus some kind of external re-calibration devices are needed (typically a magnet on the floor). Actual paths that can be followed are more constrained that those of laser systems due to the necessity to go through the calibration targets. Cartesian guidance. A fixed grid pattern covers the entire floor area. The intersections of the grid have known Cartesian coordinates. A sensor looks for these lines and when one is detected a precise location reference is known. These systems rely on the use of odometers to complete the localisation system. In this case, the possible paths between two points are infinite. The grid can be an optical one (e.g. checkerboard pattern) or made of magnets in the intersections of the lines. implies computing and programming the paths in all the AGVs. If there are many, the process requires stopping the system, although in this case the nonproductive period is shorter than with wire guided systems. Usually the programming is done repeating the routes under manual control. If there are many AGVs the process becomes larger. In other cases, the programming process is doing in a centralized computer and then the routes are broadcasted to the AGVs. In any case is the floor plant is large and the amount of load/unload point is high the process is extremely time consuming. III. THE i-fork PLATFORM The i-fork AGV system was developed in the framework of a private contract with our research group. The main goal was to develop a complete AGV system in order to fulfill a series of requirements that are not available in current commercial AGV systems. The most important one was to allow substantial changes in the layout of the floor plant along time without time-consuming operator tasks. The company works in the agricultural field and depending on the season the amount and location of storage areas change. In current commercial systems, independently of the navigation system used, the routes for load transport are predefined. The decision of the type of navigation then is based in terms of the desired facility of modifying the paths. Thus, if the plant layout, where the AGV is deployed, is changed frequently (e.g. different loading or stacking zones) wire guided path navigation is not suitable. Typically the different possible routes are stored in the AGV memory in conjunction with the map of the environment. When an order is received, the navigation system decides which of the memorised routes is taken to move from one point to another. Normally, this is done in terms of the shortest path and it can be combined with the traffic coordination process to synchronize the use of paths between several AGVs. But this model implies that if the layout is modified, the routes have to be modified as well. In the case of open path navigation, modifying routes Fig. 1. The i-fork AGV platform. The i-fork AGV (Fig. 1) is based on a custom modified Jungheinrich ESE commercial fork-lift truck, which included electrically assisted steering mechanism. This truck is able to carry loads of up to 2000 Kg and reach a linear top speed of 2.5 m/s. A series of microcontrollers are in charge of the low level control of the elevation, traction, and direction

3 motors. All of them are connected to the main CPU by way of a CAN bus, operating at 1 Mbs. The AGV includes a SICK laser based positioning unit and a SICK laser scanner sensor linked through serial ports to the main CPU. Additionally, the platform has two security switches and a polymer based bumper to stop the vehicle in case of failure or collision, and a switch to change from manual to automatic mode. The main CPU runs all the control software, which is based on a two layer hybrid architecture (Martínez and Gómez, 2002). It is worth noting here that all the software has been written in the Java programming language. The upper layer runs the navigation and planning modules. The first one updates the different grid maps from processed sensor readings while the second one generates plans and monitors the execution of them. The lower layer runs the perception module, in charge of processing sensor data, and the behaviour based controller, which performs the actual tasks, mostly pathfollowing controllers. Additionally, there is an operator interface on a remote machine, which is linked through a wireless ethernet network. This interface allows the operator know the current position of the AGV and the part of the plan that is currently executing. Moreover, at any time the operator can send a new task to the AGV. This software allows the operator changing or adding relevant places of the environment, such as adding a new docking place, and then sending the new map to the AGV. Fig. 2. The i-fork monitor software. IV. THE i-fork NAVIGATION SYSTEM A. World representation In the i-fork system, each AGV has a copy of the world description in its memory. This map is previously created and then stored in a file, which is loaded during system initialisation. The map is a 2D CAD-like representation of the world which specifies the most relevant features of the environment: walls, reflective strip beacons for the localisation system, zones or areas, docking-points for loading or unloading and doors. This world representation provides enough information for the application but it cannot be directly used for navigation tasks. For this purpose, there are two fundamental paradigms for pathplanning: the grid based paradigm and the topological paradigm (Kuipers and Byun, 1991). The grid map approach as described in (Thrun and Bücken, 1996) and (de Meyer et al., 1997) presents several problems, above all the space and time complexity representing a difficulty for the planning task. On the other hand, topological maps are more compact permitting fast planning and joint use with high level planners and traffic coordination system (Ling and Wen-Jing, 1999). But this kind of maps presents other problems like the correct identification of landmarks or the maintenance in large environments. In the context of our project, we have to deal with a relative large environment, divided in several zones, some of them connected through narrow passageways and with a number of relevant locations (e.g. docking stations). Thus a reasonable solution for this case is the use of both approaches, using a topological map for a high level description of the environment and a grid map for a local description of the environment including currently sensed obstacles. There are previous work on the joint use of both representations (Thrun and Bücken, 1996) and (Duckett and Saffiotti, 2000), where the process of creating the maps is studied. In this paper we focus on the use of the maps, and thus we apply a hierarchical vision as in (Kuipers and Byun, 1991) where different maps are used depending of the level of the control architecture and (de Meyer et al., 1997) where several topological maps with different resolution are used in order to cover the entire area. We use a two-level topological map for storing the relevant places that the AGV could need to reach and representing how to move from different zones or rooms to others. This topological map is used for high level routing only. For each zone or room the AGV updates a grid map with the information of the range sensors to account for un-modelled obstacles or environment features. It is later used for calculating point-to-point local paths. In the first level topological map, each node represents a relevant zone (typically a room). If a door exists between two zones, then there is an arc between the two nodes that represent the zones. The arcs connecting the nodes are directed and weighted, and thus the direction can be used to force the traffic through the different zones in a given sense and the weights to express preferred directions. Each arc has a label associated, which corresponds to the passageway connecting both zones. In addition, a

4 first level node contains a pointer to a grid map which covers the entire zone and is initialised from the 2D world description, and a pointer to a second level topological map. In this map each node represents a relevant place. In our current implementation these places are: Doors, in order to assist the AGV in crossing doors and for implementing a door locking mechanism to avoid two AGVs crossing it simultaneously. Wait points, in order to stop the robot for charging or servicing purposes. Dock points where the loads are taking from or released in. Way points, which are used to generate a path to manoeuvre the AGV. An arc connecting two places represents that the robot can navigate between those two places. In the same way as in the first level map the arcs are directed. B. Task planning The AGV is commanded using a sequence of tuples. Each tuple consists of a dock or wait point and an action to perform at this place, like load, unload, or stay. For example, a correct order could be: <ds1 load><ds2 unload> This commands the AGV to navigate to the dock point ds1 and dock to load the pallet, and then navigate to the dock point ds2 and dock to unload the pallet. When an order is received a plan is generated for each tuple in order to achieve the task. A plan typically consists on several subplans. A subplan corresponds to a series of information and parameters that are sent to the robot controller. In our implementation a subplan specifies which of the available behaviours will be activated to achieve the task. For instance a plan for <ds1 load> would consist on a sequence of navigating to ds1, manoeuvring to dock the AGV, lift the fork to load a pallet, and then undock the AGV. These subplans will activate sequentially the following behaviours: navigate, dock, lift, and undock. The subplans are generated from the topological maps. Each subplan has associated a goal location, and executing a plan will consist on navigating through the whole sequence of subplan goal locations. For each plan tuple, the last subplans are fixed and depend on the required action (load, unload, stay). If the action requires manipulating a pallet, those subplans will consist, at least, in a subplan to approach the dock station and a subplan to dock into it. For this reason each dock point has a way point associated. In this way, the approach subplan will consist on navigating up to the way point, with the fork pointing backwards (behaviour navigate) and then docking with the fork pointing forward (behaviour dock). This manoeuvre is shown in Fig. 3. Fig. 3. The navigate and dock behaviours. When generating the whole subplan, two positions are known beforehand: the current AGV position and the goal position. From the initial 2D world representation, the zones where these two positions are located in can be known, and then, using the first level topological map, the sequence of zones that the AGV must go through can be computed using a typical minimal-cost graph algorithm. Moreover, the doors or passageways that.the AGV must cross are also computed and known. For the first zone (the one where the AGV is currently located in) two subplans are generated to reach the door and to cross it. For all the intermediate zones and the final one, using the second level topological map, a sequence of relevant points is computed by way of a minimal-cost path algorithm. These relevant points will consist on places needed to go from the entrance door to the exit door (for the intermediate zones) and places needed to go from the entrance door to the corresponding way point and the to the dock point. In our world representation, a door corresponds to a pair of points, each one located in each zone connected through the door. In this way the AGV is forced to navigate from one point to the other in order to cross the door. Fig. 4. Example floor plant layout.

5 For clarity we will describe the plan generation using the previous floor plant layout (Fig. 4). The corresponding first level topological map would be (Fig. 5): Navigate (Door 2.1 ) Cross (Door 2.2, Door 2.3 ) Navigate (WayPoint 1 ) Dock (DockPoint 1 ) Lift () Undock () Fig. 5. First level topological map. And the second level topological maps, each one corresponding to a first level node, would be (Fig. 6): Fig. 6. Second level topological maps. If the AGV receives the order <ds1 load> (go to dock point 1 and load a pallet) the process of generating the subplans will be: 1) Compute the first level topological path: Fig. 7. First level topological path. 2) Compute the second level topological path: Fig. 8. Second level topological path. Where Door i.j means Point of door i in zone j, and the arc labels represent the behaviours that will be activated. 3) Compose the final plan, as a sequence of behaviours: Navigate (Door 1.1 ) Cross (Door 1.1, Door 1.2 ) C. Plan execution When a complete plan is available for execution, after the planner finishes the generation of the subplans, the monitor sequentially sends subplans to the controller. A new subplan is sent when the previous one has been achieved, until the whole task has been finished. Each subplan corresponds to a behaviour, and some of them will require some kind of spatial movement (navigate, dock). These behaviours will perform a point-to-point navigation. In the case of the dock behaviour, a B-Spline is generated taking into account the position and orientation where the AGV actually is and the required docking position and orientation. In the case of the navigate behaviour, a freeform path is generated directly from a grid map of the zone where the robot currently is. Although different grid maps can be used, in our implementation we rely on fuzzy grid maps (Oriolo et alt., 1998), as described in (Martínez et alt., 2001). These maps are updated each time a new laser scanner is available, and in this way unmodelled world features are incorporated into the AGV knowledge. Even more, small dynamic changes of the environment can also be taken into account. It is well known that fuzzy grid maps are not quite suitable to highly dynamical environments, but in our current implementation we do not have such problems. In order to generate low-level paths, we use an A * algorithm to find the minimum cost path from the current AGV position to the goal position. The A * cost function takes into account the size of the AGV by dilating obstacles and the uncertainty of the environment by preferring cells that are likely to be empty (Fig. 8). The controller uses the so generated path to follow it as close as possible. Given that these freeform paths are not for precision manoeuvres, our current cell size is 0.5 m. Moreover, this method can deal with dynamic changes of the environment as the path planning is executed cyclically, and thus if an obstacle suddenly partially occludes a path a new one is generated.

6 flexibility in partially structured environments, from an operator point of view, and also provide the AGV with the techniques needed to successfully achieve its tasks. The operator only has to deal with a few topological information, which is very easy to understand and modify, while the AGV uses such information and the sensor data to generate the desired trajectories. VI. ACKNOWLEDGEMENTS Fig. 9. Fuzzy grid map and generated path. One key aspect is the correct identification of topological places. In this case, each second level node has a 2D coordinate associated and a tolerance to detect that the AGV has achieved that place. Thus, a global localisation method is a must. In our implementation we use a Kalman filter to integrate measures obtained from the odometers and positions given by the laser based localisation unit, which gives enough accuracy for both position and heading. V. DISCUSSION AND CONCLUSIONS As commented in section 2, changing the layout in typical AGV systems is a time consuming task, form the operator point of view, and usually requires that the plant has to be stopped for some time (at least partially). In our approach, the operator does not have to cater about the paths, but only on the relevant points. Typical layout modifications include changing the loading/unloading zones, which in our case only require establishing the coordinates and orientation of the docking places and specifying the way points to reach them. Thus, the plant does not need to be stopped more than the time needed to update the topological maps of the AGVs. This last point can be a little bit tricky. Although this point could be computed automatically from the grid map or the world model, our current implementation leaves this task to the operator. The constraints for the way points are as follows: the AGV should not collide with objects or obstacles while following the trajectory and should be far enough from the dock place to allow the AGV reach the adequate pose. These constraints are very intuitive and easy to meet for a human operator, and thus this is not a problem. The ideas and algorithms we use in our system are more or less common in indoor mobile robotics. Bridging the gap from theory to practice usually involves studying and solving many details. In our case we successfully engineered a flexible AGV system which is currently working in an agricultural company. We have focussed our study in how to combine topological and grid maps to allow great This work has been supported by ART-11 contract Automatización de Carretilla Paletizadora, El Dulze S.A., and CICYT project TIC C02-01, Spanish Ministry of Science and Technology. VII. REFERENCES [1] Duckett, T. and Saffiotti, A. (2000). Building Globally Consistent Gridmaps from Topologies. Procs. of 6th Intl. IFAC Symposium on Robot Control [2] Kuipers, B. and Byun, Y.-T. (1991). A Robot Exploration and Mapping Strategy based on a Semantic Hierarchy of Spatial Representations. Journal of Robotics and Autonomous Systems, 8: [3] Ling, Q. and Wen-Jing, H., (1999). Scheduling and Routing Algorithms for AGVs: a Survey. [4] Martínez Barberá, H.; Zamora Izquierdo, M. & Gómez Skarmeta, A. (2001). Navigation of a Mobile Robot with Fuzzy Segments, IEEE Intl. Conf. on Fuzzy Systems, Melbourne [5] Martínez Barberá, H.; & Gómez Skarmeta, A. (2002). A Framework for Defining and Learning Fuzzy Behaviours for Autonomous Mobile Robots, Intl. Journal of Intelligent Systems, 17(1):1-20 [6] Meyer (de), K., Lemon, O. and Nemhzow, U. (1997). Multiple Resolution Mapping for Efficient Mobile Robot Navigation. [7] Oriolo, G.; Ulivi, G.; & Venditelli, M. (1998). Real Time Map Building and Navigation for Autonomous Mobile Robots in Unknown Environments. IEEE Trans. on Systems, Man and Cybernetics-Part B: Cybernetics, 3(28): [8] Thrun, S. and Bücken, A. (1996). Integrating Grid-Based and Topological Maps for Mobile Robot Navigation. Procs. of the Thirteenth National Conference on Artificial Intelligence.