Behaviour-Based Control in Mobile Robotics Paul Fitzpatrick And so it begins...

Definition of Robotics Sensors Perception Robotics is: “the Intelligent Connection of Perception to Action” Reality Robot Yup, that’s robotics for you Action Actuators

Classical Robotic Control “Pipelined” approach Perception Modelling Planning Task Execution Motor Control Sensors Actuators Focus on Knowledge Representation Collect and process sensor data Generate internal model Make plans based on model Convert plans to detailed motion commands Output to actuators Functional decomposition

Practical Problems with Classical Control Planning Modelling Task Execution Delayed reaction to stop robot Motor Control Perception Sensors Real world is hard to model well Simpler models are useless Realistic models are slow to build and use Even the best models are very limited Entire pipeline must exist before robot moves at all- hard to evaluate work done Actuators Slow to respond

Research Problems with Classical Control Temptation to focus on model rather than reality L 20 R 00 F 00 B 10 EXEC Other influences Perception Modelling A lot of work done, especially early research, was on “toy” worlds- interesting from an AI point of view, but of very limited applicability to robots operating in unstructured environments. Reality Motor Control Task Execution Planning

Classical Control: Summary Assumes a complete internal world model can be built, then manipulated Slow. Modelling must occur before robot can react to changes in environment Emphasis on using model is misleading- Makes complex tasks seem solvable by directing attention away from perception Makes potentially simple tasks complicated Requires crippling simplications You said a mouthful.

Alternatives to Classical Control Traditional AI complex cognition simple environment simpler cognition complex environment Cognitive complexity behaviour- based systems Classical control does complex things in a simple environment. In the late 80’s, frustration with the total collapse of classical control in real environments led to a polar-opposite class of technique which did simple things in complex environments. this type of technique was called “reactive” to contrast with the “deliberative nature of classical control. The focus was switched from representations and models to behaviours and competences. reactive systems Environmental complexity

Behaviour-Based Control Rather than functional decomposition, use “Behaviours” As much as possible, behaviours interact with each other through the environment, not the system The world is its own best model, so consult it directly whenever practical Use distributed representations tailored to the particular behaviours using them Example: Herbert picking up soda cans - behaviours don’t communicate, instead they recognise their suitability by spotting that a previous behaviour or luck has arranged the environment so they can do their job.

Behaviour-Based Control: Subsumption Architecture Modules act in parallel, in layers of increasing priority Higher layers can view and modify the data flow in lower layers Work usefully Use maps Sensors Actuators Explore Why would Brooks think a rigidly prioritized linear set of competences would be good? He describes his thinking thusly :- “We start by building a complete robot control system which achieves level 0 competence. [...] We call it the zeroth level control system. Next we build another control layer, which we call the first level control system. It is able to examine data from the level 0 system and is also permitted to inject data into the internal interfaces of level 0 suppressing the normal data flow. This layer, with the aid of the zeroth, achieves level 1 competence. The zeroth layer continues to run unaware of the layer above it which sometimes interferes with its data paths” This is analagous to a description of single inheritance trees in Object Oriented Programming. And the same argument about whether single or multiple inheritance is necessary would apply. All modules have access to sensors Wander All modules have access to actuators Avoid obstacles

Advantages of Subsumption Explore Wander Use maps Reacts immediately to stop robot Avoidance Work usefully DISTRIBUTED REPRESENTATION The robot works and is testable from the moment the first module is added Incremental, bottom-up: faults must be- In the module currently being added In the interface between the current module and the lower one Avoids need for centralised planner, planning is naturally distributed Fast!

Disadvantages of Subsumption Rigid priority scheme and strict layering are limiting - Priorities must be evaluated and hardwired at design time Requires behaviours to fit into a simple single-inheritance hierarchy Behaviours cannot be combined, only enhanced linearly “As much as possible, interact with each other through the world rather than internally through the system” is a good rule. However, behaviours still do have to interact with each other and subsumption does not provide a good way for them to do so. [see colin&co paper] Requires behaviours to fit into a “single inheritance” system decomposition.

Alternatives? Extend scope of behaviour-based systems by improving behaviour “glue” Traditional AI Cognitive complexity behaviour- based systems reactive systems Environmental complexity

“Lateral” Architecture Work usefully Use maps Explore Wander Sensors Avoid obstacles Actuators Focus on managing behaviour groups All modules have access to sensors All modules have access to actuators

Features of Lateral Lateral has a dynamic priority system designed to make it easy to build behaviours using other behaviours A behaviour is given the priority its highest priority user at a given time thinks it should have (“sponsorship”) Behaviours expose a limited public interface to users, rather than allowing access to their internal data flows. Similar to “spreading activation” system in the New Subsumption of Brooks&Co. - except that that applies to spreading an activation level between modules which, when compared with threshold levels, determines if they are active or not. The Lateral system uses “spreading priority” to determine what weighting the outputs of a module should have compared to other modules, whereas this is fixed in the Subsumption scheme.

Example Behaviour: Edge Following EdgeMan Compensate Stroll Waddle Face Start Capture Turn oNudge iSide oMotor Logical Sensors Note, in Subsumption the finite state machines used are of a much finer granularity. The “EdgeMan” module here would be implemented by a number of finite state machines in Subsumption. This could be done in Lateral too, and if it was, the public interface should still be as shown- internal data flows should not be accessible.

Prowling Behaviour ProwlMan Prowling uses edge following in its implementation Start Grab Circle sync Explore seek fly Leap Return ProwlMan oEdge iSelect oPatrol Logical Sensors oExplore

Prowling - Behaviours used Prowling behaviour is built from a hierarchy of simpler behaviours. EdgeMan Priority Control NudgeMan Priority Control ProwlMan Priority Control AngleMan Priority Control MotorMan Priority Control PatrolMan Priority Control ExploreMan Priority Control SeekMan Priority Control

Prowling - Edge Following ProwlMan active, and sponsoring edge following (EdgeMan) EdgeMan Priority Control NudgeMan Priority Control ProwlMan Priority Control AngleMan Priority Control MotorMan Priority Control PatrolMan Priority Control NudgeMan beats SeekMan because, even though it is lower level, it has more sponsorship ExploreMan Priority Control SeekMan Priority Control

Prowling - Exploring ProwlMan active, and sponsoring exploration (ExploreMan) EdgeMan Priority Control NudgeMan Priority Control ProwlMan Priority Control AngleMan Priority Control MotorMan Priority Control PatrolMan Priority Control ExploreMan Priority Control SeekMan Priority Control

More Behaviours ManualMan Priority Control RegionMan Priority Control EdgeMan Priority Control NudgeMan Priority Control ProwlMan Priority Control AngleMan Priority Control MotorMan Priority Control PatrolMan Priority Control ExploreMan Priority Control SeekMan Priority Control New behaviours fit in transparently to the ones already present

Competition ManualMan Priority Control RegionMan Priority Control EdgeMan Priority Control NudgeMan Priority Control ProwlMan Priority Control AngleMan Priority Control MotorMan Priority Control PatrolMan Priority Control ExploreMan Priority Control SeekMan Priority Control Competition between behaviours is resolved by the “sponsor”

Lateral - Implementation Extended syntax for expressing parallel processes (as state machines) and data flow between them Module A Priority Control Simulator PROCESS ModuleA { int localVariable; INPUT(int, boredom); INPUT(Point, distance); OUTPUT(MotorCtrl, motor); OUTPUT(Message, msg); @CONTROL // Priority control @state1 DoSomething(); NEXT state2; @state2 DoSomethingElse(); NEXT @; }; class ModuleA : public ZACProcess { private: int localVariable; public: ZACInput<int> boredom; ZACInput<Point> distance; ZACOutput<MotorCtrl> motor; ZACOutput<Message> msg; int ZAC_Run ( int ZAC_state ); ... }; Runtime Support Software: “Lateral” code Translated into C++ classes, objects and functions Compiled for use with Khepera Simulator, or cross-compiled for downloading to robot C++ Lateral Robot

“ Khepera ” Hardware: Khepera miniature robot Processor: 68332 Proximity sensors Light sensors Stepper motors

Khepera Simulator Robot Control Panel Robot path tracer

Priority Implementation: Connections Compete/Subsume A B C A, B or C depending on priority Copy A A B C A, B or C depending on priority Compete/Subsume A B A or B depending on priority Compete/Subsume cd