High level software architecture for autonomous mobile robot
High level software architecture for autonomous mobile robot
High level software architecture for autonomous mobile robot
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
<strong>High</strong> <strong>level</strong> <strong>software</strong> <strong>architecture</strong> <strong>for</strong> <strong>autonomous</strong><strong>mobile</strong> <strong>robot</strong>Krejsa Jiří, Věchet Stanislav, Hrbáček Jan, Schreiber PetrBrno University of Technology, Faculty of Mechanical Engineering, Technická 2896/2,Brno, 616 69, Czech Republic, email: krejsa@fme.vutbr.czAbstract The paper deals with the high <strong>level</strong> <strong>software</strong> <strong>architecture</strong> <strong>for</strong> <strong>autonomous</strong><strong>mobile</strong> <strong>robot</strong> Bender II, medium size wheeled nonholonomic <strong>mobile</strong> <strong>robot</strong>with Ackerman chassis <strong>for</strong> both indoor/outdoor environment. <strong>High</strong> <strong>level</strong> <strong>software</strong>uses hybrid approach combining common layered <strong>architecture</strong> with reactive control.Local navigation including static/dynamic obstacle detection/avoidance isbased on laser range finder data. Global navigation in indoor environment is basedon fusion of odometry based position estimation with precomputed scan matchinglocalization technique. Architecture description is accompanied by tests results obtainedin real environment.IntroductionAutonomous <strong>mobile</strong> <strong>robot</strong>s exhibit rapid progress in past decade, as illustrated <strong>for</strong>example by results of DARPA Grand Challenge competition, as while in 2004 no<strong>robot</strong> was able to successfully finish the test track, in 2005 five <strong>robot</strong>s finished thetrack and 22 of 23 gained better results than the best <strong>robot</strong> from the year be<strong>for</strong>e[1]. Together with improving the quality of sensors and other elements accompaniedwith falling prices of the components the control <strong>software</strong> is the key issue <strong>for</strong>successful and robust per<strong>for</strong>mance of <strong>mobile</strong> <strong>robot</strong>. There exist a number of high<strong>level</strong> <strong>software</strong> schemes, usually divided into three categories: 1. hierarchical (vertical)arrangement in which system cycles through perception-processing-actioncycle, 2. reactive control which creates a set of behaviors directly connecting perceptionand action (e.g. [2]) and 3. hybrid <strong>architecture</strong>s, which combines both [3].The latest one achieves the greatest focus around researchers [1].This paper deals with the universal high <strong>level</strong> <strong>architecture</strong> developed <strong>for</strong> both indoorand outdoor missions, as even there are differences with respect to the environment,the basic scheme is general. First the overview of the <strong>architecture</strong> isgiven, followed by detailed view on key modules, implementation details and testresults.
2<strong>High</strong> <strong>level</strong> <strong>architecture</strong>The key idea of the <strong>architecture</strong> is task decomposition. Contrary to commonlyused <strong>architecture</strong>s we divide <strong>robot</strong> tasks into simple subtasks that are inserted intohierarchical tree during <strong>robot</strong> mission according to current situation observed by<strong>robot</strong> sensors. As <strong>robot</strong> is supposed to operate both indoor and outdoor and per<strong>for</strong>mvarious types of missions, there are two <strong>level</strong>s in the <strong>architecture</strong>, first onedeals with the mission type, second one with currently per<strong>for</strong>med mission, as denotedon figure 1. Mission <strong>level</strong> is controlled by Mission manager (MM) – the topcontrol object in the <strong>architecture</strong> that receives the initial global goal, sets appropriatemission and processes outer requests. Missions are of certain types, regardlessthe environment. Commonly used mission types might be e.g. Motion from locationA to location B on free space, Motion from on the path, Wandering on freespace, Mapping - motion in unknown environment, Manual control, etc.During <strong>robot</strong>s operation there is only one active mission at any time; MM processesthe outer requests by <strong>for</strong>ming mission tree or queue according to the request.For example, initial mission is wandering on the parking lot in front of the building.MM creates appropriate mission, sets it as current and starts. When outer requestarrives, e.g. drive into nearby building to the office, queue of missions iscreated, firstly motion on free space (parking lot) to the road entrance, secondlymotion on the road to the building, finally motion on free space inside.Initial goal definitionOuter requestMission Manager- current mission- mission treeMission- type- status- task managerTask manager- mission- status- current task- tasks treeTask- type- statusFigure 1. Top <strong>level</strong> decompositionThe decomposition inside each mission is similar; however instead of missionqueue the hierarchical tree of tasks is created. MM is replaced by Task manager(TM), structure existing only once (globally), assigned to currently per<strong>for</strong>medmission. TM holds and services the tree of tasks. Each task represents a simplegoal, commonly used tasks are e.g. Move on path, Move on free space, Localize,Avoid obstacle, Solve trap, Return to base, etc.The task is per<strong>for</strong>med until it is successfully finished or fails. Depending on failurereason the appropriate new task is assigned by TM and inserted into the tasks
3tree (unsuccessfully finished task remains open). Failure reasons do not necessarilyhave to be of high <strong>level</strong> causes. It could be hardware failure, suddenly appearingobstacle, etc. Reactive model is used <strong>for</strong> low <strong>level</strong>, e.g. <strong>robot</strong> per<strong>for</strong>ms emergencystop maneuver when confronted with suddenly appearing obstacle, andmessage is sent to current task, causing it to fail. The flow can be illustrated onfigure 2, where example with obstacle avoidance is given. The <strong>robot</strong> is moving onthe path (<strong>for</strong> now we do not care how the path is recognized, how <strong>robot</strong> steers onthe path, as it is what the task deals with) and task fails as there is obstacle detected(figure 2a). Due to the failure the TM inserts appropriate task into the tree.Avoid obstacle task fails as there is no way how obstacle can be avoided (figure2b). TM now inserts new task into the tree, the Solve trap task (figure 2c). Oncethe trap is solved, the task ends and flow returns to upper task (figure 2d) and thismechanism continues until the motion on the path is restored (figure 2f).Move on pathObstacledetectedMove on pathAvoid obstacleMove on pathAvoid obstacle(a)Obstacle(b) (c)unavoidableSolve trapMove on pathAvoid obstacleMove on pathAvoid obstacleMove on pathContinue on pathObstacle avoidedSolve trap(d)Trap solved(e) (f)Figure 2. Task tree exampleThe limited space does not allow us to go into greater detail in all the tasks, let’stake a look at least into Avoid obstacle task. The flow is shown on figure 3. Thetask first determines whether the obstacle is static or dynamic. In case of static obstaclethe task determines if it can be avoided, if yes the planning algorithm replansthe trajectory and task returns success. In case of dynamic obstacle the taskhas to resolve if it can be avoided, and if yes it must decide whether to replan thetrajectory or use velocity tuning algorithm (“wait” <strong>for</strong> the obstacle to move away).There are several ways how to build the core of TM, the decision mechanismwhich selects appropriate tasks <strong>for</strong> insertion in the case of current task failure.Currently we are using simple set of rules that acts as primitive expert system,with low <strong>level</strong> functions “hard wired” (e.g. in the case of hardware componentfailure the low <strong>level</strong> functions independently stop the <strong>robot</strong> immediately, reportthe HW failure to current task in operation, task fails and whole mission isaborted). However the simple set of rules can be replaced with e.g. Bayesian baseddecision maker, etc.
4ObstacleclassificationStatic obstacleDynamic obstacleAvoidable ?nonoAvoidable ?yesReplanReport failureReason: trappedReport okyesDetermineavoidingmethodVelocitytuningReplanFigure 3. Avoid obstacle taskoutdoorCompass (φ)GPS (x,y)GloballocationOdometry (x,y,φ)IR beacons (x,y,φ)indoorlocalizationTaskManagerIR (distance)US (distance)Sick (dl - range)Local info&MappingCurrenttaskcamera (road,…)Perception layerFigure 4. Perception modulesThe <strong>architecture</strong> is modular, which can further be demonstrated on indoor/outdoorperception module, see Figure 4. All the sensors (apart from internal <strong>robot</strong> HWstate check) can be divided into two groups, regardless the environment: globallocation data and local environment data. Local in<strong>for</strong>mation is directly used <strong>for</strong>obstacle avoidance and indirectly <strong>for</strong> determining the global location estimate vialocalization. There<strong>for</strong>e the <strong>architecture</strong> can use generalized perception modules,use it <strong>for</strong> the given tasks as in<strong>for</strong>mation sources and modules themselves updatethe environment model depending on sensors available and environment type the<strong>robot</strong> is currently in. This way the indoor/outdoor fuses simply into environment.
5Implementation and testsThe <strong>architecture</strong> was implemented and tested on <strong>autonomous</strong> <strong>mobile</strong> plat<strong>for</strong>mBender II: a medium size wheeled <strong>robot</strong> with Ackerman steering, <strong>for</strong> both indoor/outdoorenvironment, equipped with odometry IRC sensors, compass, GPSmodule, CCD camera and laser range finder. Rear wheels are independentlydriven by separate Maxon RE40 DC motors with planetary gears 43:1 and chaindrives. Steering is controlled with Hitec HS-5745MG servo. Ground plan dimensionsare 600x325mm, total weight is 20kg. Batteries used are LA 2x12V, 7.2Ah,allowing about 90 minutes operating range. The control <strong>software</strong> runs on IntelMini-ITX board, which uses a simple bus driver board connected through a USBto-UARTconverter to drive the onboard RS-485 bus. All hardware devices are interconnectedby this bus (except the SICK laser scanner connected directly to thecomputers COM port). Every bus device type is controlled by a dedicated low<strong>level</strong> <strong>software</strong> layer class. Due to independently driven rear wheels the <strong>robot</strong> isequipped with a <strong>software</strong> differential, implemented by the middle-<strong>level</strong> <strong>software</strong>that also provides modules exploiting the bus devices. For example, there is anodometry module that periodically asks <strong>for</strong> data from both encoders and per<strong>for</strong>msa simple data fusion. On top of the SW differential and odometry modules is basedthe algorithm caring <strong>for</strong> the <strong>robot</strong>s ride.<strong>High</strong> <strong>level</strong> <strong>software</strong> is based on previously described <strong>architecture</strong>. It is implementedin C# with time critical routines written in various languages. Localizationroutines use PCSM algorithm [4], planning algorithms are based on Rapidly ExploringRandom Trees [5] with path smoothness and optimization module. Dynamicobstacle recognition is based on laser range finder data analysis (indoor) togetherwith image processing (outdoor).Figure 5. Robot track example
6Bender II was tested in range of environments on a number of missions. Due tolimited space only single test example is described. The mission goal was to travelin indoor environment from defined start location to defined goal location. Duringthe mission a number of static obstacles not included in the map and precomputedlocalization data were positioned both on expected track and around. At the sametime the dynamic obstacles (people) were wandering at various speed and distancesin the environment. Figure 5 shows planned track of the <strong>robot</strong> together withits estimated position. The gaps in location estimation are caused by improving theestimate precision via PCSM localization. As you can see, globally planned trackgoes through static obstacles, as those were not incorporated in the map and there<strong>for</strong>ethe planning algorithm was not aware of those. As the steering of the <strong>robot</strong> islimited, reversing is included in obstacle avoidance <strong>for</strong> obstacles detected too late<strong>for</strong> direct avoidance.ConclusionPresented high <strong>level</strong> <strong>software</strong> <strong>architecture</strong> represents general framework <strong>for</strong> bothindoor and outdoor environment <strong>autonomous</strong> <strong>mobile</strong> <strong>robot</strong>s. The <strong>architecture</strong> issensor independent and can be extended when <strong>robot</strong> hardware equipment changes/ improves or when new <strong>robot</strong> missions are defined. The number of tests per<strong>for</strong>medwith Bender II <strong>autonomous</strong> <strong>robot</strong> that uses this <strong>architecture</strong> proved that itis usable and flexible. Further improvements can be obtained by replacing the currentlyused simple rules mechanism in Task manager module by more advancedmodules, e.g. based on Bayesian approach.References[1] Buehler M. Iagnemma K., Singh S. (Editors): The 2005 DARPA Grand Challenge: TheGreat Robot Race (Springer Tracts in Advanced Robotics), Springer, 2007[2] Brooks, R.A.: A Robots Layered Control System <strong>for</strong> a Mobile Robot, IEEE Journal of Roboticsand Automation, 2, pp 14-23, 1986[3] Connell J.H.: SSS: A Hybrid Architecture Applied to Robot Navigation, in Proc. of theIEEE Int. Conf. on Robotics and Automation, 1992, Nice, France[4] Krejsa J., Věchet S.: Dealing with Sensor Errors in Scan Matching <strong>for</strong> Simultaneous Localizationand Mapping, Engineering Mechanics, volume 15, number 5, (2008), pp. 337-344[5] Kalisiak M., van de Panne, M.: RRT-blossom: RRT with a local flood-fill behavior, in Proceedingsof International Conference on Robotics & Automation 2006, Orlando, Florida,USA, 2006Acknowledgments Published results were acquired with the support of the Ministry of Education,Youth and Sports of the Czech Republic, research plan MSM 0021630518 "Simulationmodeling of mechatronic systems"