1. Robot Intelligence
Kevin Warwick

2. 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

3. Topological Representation

4. 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?

5. A connectivity graph of this BSP is:

6. Both together…

7. 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

8. 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

9. 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?

10. Problem Revisited

11. 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

12. 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

14. 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

15. 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

16. 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

17. Centralised Controller (functional)

18. Distributed Controller (reactive)

19. 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

20. 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

21. Example Blackboard System

22. 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

23. 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

24. Next Presentation
Architectures