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 2 2 2 2 2 3 3 3 1 1 1 4 4 4 7 7 7 5 6 10 13 12 14 9 10 13 12 14 8 7 11 12 14 11 12 14 8 4 5 6 10 13 12 14 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 • elseif (right_sensor_reading) and (left_sensor_reading) – if right_sensor_reading < min turn left_slightly – if right_sensor_reading > max turn right_slightly – else move forward – reverse • else – move forward • 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 – 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 – 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