Robot Intelligence Kevin Warwick

Task Example We will look at a relatively simple example and see how a robot might solve a specific problem Try to spot the assumptions we/humans make on the robot’s capabilities In the problem the robot will start at one point and must find it’s way to the goal

Topological Representation

Topological Representation The space can be partitioned using for example: Binary State Partitioning. But does the robot have or can it find out such a map?

A connectivity graph of this BSP is:

Both together…

Valid Routes In order to get from the start position (region 2) to the goal (region 14) the robot must follow one of the routes from 2 to 14 in the graph 2  3  4  5  6  10  13  12  14 2  3  4  9  10  13  12  14 2  3  4  8  7  11  12  14 2  1  7  11  12  14 2  1  7  8  4  5  6  10  13  12  14 2  1  7  8  4 9  10  13  12  14

Real-time Solutions in Unmodelled Environments If the robot did not know the structure of the environment and could not build a planned trajectory, the goal may still be reached Consider the goal having a beacon to indicate to the robot where the goal is

Real-time Solutions in Unmodelled Environments Now consider a wall following routine The robot moves forward following the left hand wall until it reaches an obstacle (a wall in front) It turns right – possibly repeatedly it no longer detects the presence of a wall to the left It turns left Can the robot reach the goal?

Problem Revisited

Real-time Solutions in Unmodelled Environments In this case the robot will be able to reach the goal if the robot initially moves to the right If the robot moves to the left then it will circle the top-left island and would require some additional reasoning to break out of that cycle e.g. Odometry would indicate that the pose of the robot has repeated a number of times

Robot Architectures Example: seven dwarf Pseudocode … if left_sensor_reading turn right elseif right_sensor_reading turn left elseif (right_sensor_reading) and (left_sensor_reading) reverse else move forward

Robot Architectures Add in wall following … if left_sensor_reading if left_sensor_reading < min turn right_slightly if left_sensor_reading > max turn left_slightly else move forward elseif right_sensor_reading if right_sensor_reading < min if right_sensor_reading > max elseif (right_sensor_reading) and (left_sensor_reading) reverse Even introducing modest extensions can lead to increased complexity in the algorithm if it is developed in an ad hoc way Need to find some more formalised way of developing behaviours

Robot Architectures Two main classes Three main types: Centralised Reactive Three main types: High Level Control (centralised) Treat the robot as an abstract entity Apply classical AI techniques to define complex tasks Top down (Computer Science) approach Functional (centralised) Classical horizontal connection between perception and action sense – model – plan – act paradigm

Robot Architectures Biological Analogues Hybrid systems Reactive (distributed) Bottom up (Cybernetics) approach Subsumption most widely known Motor Schema Ego-behaviour Biological Analogues Artificial Neural Networks Genetic Algorithms Hybrid systems Combinations of any/all of the above

Centralised Controller (functional)

Distributed Controller (reactive)

Functional Architectures I: Hierarchical Decompose the control process by function Low level processes provide simple functions that are grouped together to provide higher level functions e.g. Lower level processes position sensing motor output forward kinematics inverse kinematics dynamic model of the robot low level vision processing (e.g. edge detection) … Note: while these are “low level” some of them can be computationally challenging, especially kinematics, dynamics and vision Higher level processes Mission planning Map building Reasoning about tasks Sequencing tasks

Functional Architectures II: Blackboard Blackboard-based architectures rely on a common pool of information (the blackboard) that is shared by independent computational processes Example: Ground Surveillance Robot (GSR) designed to navigate from one known location to another known location over unknown natural terrain to complete the task the GSR has to build a terrain map GSR uses the blackboard to represent and pass information from one software module to another there is a loose coupling between modules Disadvantages requires the information to be consistent in its representation cannot use relative positions as defined in one subsystem in another can lead to bottlenecks in processing asynchronous nature of blackboards can lead to problems due to timing skews difficulties arise if more than one module can change data in the pool … which set of data is the right one? similar problem to file sharing violations

Example Blackboard System

Basic Reactive Consider instead a very basic reactive robot: Higher level goal – move towards a desired end position (infra-red?) Lower level behaviour – move forwards Lower level behaviour – avoid obstacles

Basic Reactive Lower level behaviours – example Kohonen network to map robot positional state/situation (object to left/right/front – distance) Fuzzy Automata – Physical realisation in each state – e.g. left wheel forward fast, right wheel reverse slowly Needs reward/punishment Probabilities randomised then updated based on success/failure of moving forward and avoiding obstacles

Next Presentation Architectures