• Introduction
• Software Modules
• Videos
  

(Click on any image to enlarge it)

Introduction

The i-Fork AGV (Figure 1) is based on a custom modified OMG 808 fork-lift truck, which included electrically assisted steering mechanism. This truck is able to carry loads of up to 800 Kg , lift them upto 3.1 m of height, and reach a linear top speed of 2.0 m/s. A series of custom microcontroller-based boards are in charge of the low level control of the elevation, traction, and direction 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 to stop the vehicle in case of failure, and a switch to change from manual to automatic mode.

Figure 1. Two views of the iFork AGV

The main CPU runs all the control software, which is based on ThinkingCap-II, a two layer hybrid architecture. 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 path-following 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.

One of the main advantages of the iFork system is the flexibility in defining the plant of the operation areas. While in typical systems modifications of the layout imply halting the system, our system allows for modifications in real time. Moreover, only a minimal amount of information is required for defining the plant, as location of docking places, doors or passageways and waypoints for docking/undocking operations. There is no need of an accurate model of the different walls an obstacles. In fact, if new obstacles appear, the iFork system incorporates this information into its own maps. All this flexibility is because there are no predefined paths. The robot computes continuously the way to get to the desired point. The interface to an intelligent warehouse planner/manager is very simple. The manager just have to provide a list of docking/undocking operations. The iFork system comes with its own production manager to automatically generate orders to the robots, although it is not required..

[Top]

Software Modules

The iFork AGV software has been developed using the ThinkingCap-II architecture, providing particular implementations for the followinbg modules:

• Perception
• Navigation
• Controller
• Planner

There are two important Perception processes: the local obstacle modeller and the position filter. The first one computes and maintains a local model of the obstacles detected by the range laser scanner. When a new scan is available its information is stored on a circular buffer. At each control cycle this buffer is translated and rotated in robot centric coordinates depending on its own motion. The laser information is stored only for a predefined number of cycles. The resulted buffer is used to detect dangerous zones and to help in obstacle avoidance. The position filter integrates the landmark based laser information with the odometry information using a robust Extended Kalman Filter, that has been fully tested in both simulation and real robot. It takes into account the situation where the laser may fail (very sharp turns or high accelerations). The laser provides information at a very low rate, and thus it is not possible to rely only on this sensor for position estimation.

For Navigation, there are two important processes as well: the map building and the path planning. The first one is called whenever a new laser scan is available. This module integrates the current position and perception into a fuzzy grid map, which has been custom modified for accounting with the dynamicity of the working environment. The uncertainty of the different obstacles is modelled using fuzzy logic. The path planner runs continuously but asynchronously to other modules. Using a D* path planner it obtains the optimal path from the AGV position to the desired subgoal position. Depending on the type of current goal the path can be made of segments, straight lines or B-splines (the later used for docking manoeuvres). The D* planner has been modified for taking into account the uncertainty of the fuzzy grid map.

The Planner consists on a single process which receives a task from the AGV warehouse planner and generates a plan taking into account the current position of the vehicle and the topological map. The plan is stored as a finite state machine, where each state is a given subtask. If any of the subtasks can not be accomplished, the current task is halted and the operator is informed.

The Controller consists on a single process as well. It decides which set of behaviours is to be executed depending on the current subtask. Typically, more than a single behaviour is executed concurrently (i.e. obstacle avoidance and path tracking), and thus a context-dependent-blender fuses the resulting control actions of the active behaviours. There are different behaviours, being three the most important ones: obstacle avoidance, path tracking and docking. The obstacle avoidance is based on the local obstacles buffer. Whenever an obstacle is close enough (the threshold is given in seconds to collide) a vector command is given to avoid the collision. The different vectors are combined resulting in a local avoidance strategy. This behaviour is not intended as a security mechanism but as a way of avoiding cluttered zones. In any case, if the AGV is about to collide the laser scanner hardware cuts off the power to the motors. The path tracking takes as input the last available path and the current position of the vehicle. It uses a pure pursuit technique to follow the path. The look-ahead position is chosen depending on the vehicle's current speed. A fuzzy logic controller decides which action is to be performed depending on the position and heading errors. It also limits the linear and rotational accelerations. The docking behaviour is quite similar to the path tracking except that it drives the AGV backwards (in the direction of the forks) to allow loading or unloading pallets. In addition to limiting the acceleration its fuzzy logic controller also tries to maintain a constant speed.

[Top]

[Top]

Last updated on January 11, 2005
humberto@um.es