Download Mobile Robotics

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