fuzzy control in robotics

Fuzzy Control When plant model unavailable  A set of rules associating sensor readings with action IF Close-by right-sensor THEN Left IF Clear forward-sensor THEN Forward IF Right

Robots and Virtual Robots I

Agents in Physical and Virtual Environments

Lecture 4:

Fuzzy Control in Robotics

Gal A Kaminka

galk@cs.biu.ac.il

Fall 2002 © Gal Kaminka, 2

Previously, on Robots I …

 Fuzzy set theory, fuzzy logic

 Generalizations of set theory and logic

 Probability versus Fuzziness (a productive discussion?)

 Fuzzy control

 IF … THEN … rules where LHS, RHS refer to fuzzy sets

 All rules matched, all matching rules combined

 Three stages: Fuzzification, inference, defuzzification

 Useful when mathematical model of plant

unavailable

This week, on Robots I….

 Fuzzy Logic basics

 A crash course in Fuzzy Control

 Fuzzification, Inference, Defuzzification

 Applications of Fuzzy Control in robotics

 Simple skills: avoid obstacles, greedy navigation

 Issues and challenges to fuzzy control

 Curse of dimensionality

 Real-time responses

 Incomplete controllers

LastWeek

Fall 2002 © Gal Kaminka, 4

?

Fuzzy Control

 When plant model unavailable

 A set of rules associating sensor readings with action

IF Close-by( right-sensor ) THEN Left

IF Clear ( forward-sensor ) THEN Forward

IF Right ( goal-location ) THEN Right

 All rules fire in parallel, and their results are combined

Fall 2002 © Gal Kaminka, 6

Three stages

 Fuzzification (each rule):

 Sensor reading are matched with the IF side

 LHS: Left-Hand Side

 Inference (each rule):

 As a function of matched LHS, THEN part is operationalized

 RHS: Right-Hand Side

 Defuzzification (all rules together)

 The operationalized RHS of all rules are combined

 A crisp result is extracted

 Determine degree of membership of sensor reading

 IF Close-by(right-sensor) AND FAR ( goal-location )

THEN Left

 IF Close-by(forward-sensor) THEN Left OR Right

 Get value of sensors right, forward, goal-location

 Find membership value of value in fuzzy sets by

Close- This value determines activation of this rule

Fall 2002 © Gal Kaminka, 8

Inference (see blackboard)

 Each rule’s LHS activation determines RHS

activation

 Two common types of inference:

 Cut RHS set(s) to LHS activation value

 Scaling: Multiply RHS function by LHS activation value

Defuzzification (see blackboard)

 Non-additive: Multiple contributions count as one (e.g., max)

 Additive: Multiple contributions strengthen result (sum)

 Max: Pick maximum value as representing set

 COG: pick center-of-gravity as representing set

 MOM: Mean-of-Maxima

 …

Fall 2002 © Gal Kaminka, 10

?תולאש

Fuzzy Control in Robotics

 Mathematical model of task, robot body

Fall 2002 © Gal Kaminka, 12

Case Study: Controller for YODA

 Denning MRV-3 Robot

 Old: ~20 years

 Massive: ~1m tall, ~75cm wide, ~30Kg

 24 sonar sensors (distance), internal x, y, theta odometry

 Task:

 From current position, go to goal location (given in x, y)

 Avoid obstacles on the way, but max speed

Controller

Sonar (x24)

Curr X, Y, ThetaGoal X, Y

Speed

Heading Change

Controller design

 Let’s start with going towards the goal

 We have the current position and current heading

 We want to go to a goal location

 Forget about obstacles for now

 Can anyone suggest a set of rules to do this?

Fall 2002 © Gal Kaminka, 14

Design Alternative 1

 Raw distance

 IF current-at(x0,y0) AND goal-at(xg,yg)

THEN speed=V0 {some function of distance to goal}

 IF current-at(x1,y1) AND goal-at(xg,yg)

Problem: Too many rules

 For each possible location

 And each heading in each location

 How is this ever going to scale?

Fall 2002 © Gal Kaminka, 16

Design alternative 2

 Let’s do some pre-processing of the sensors

 Instead of raw sensors, look at difference from

goal

 New sensors:

 Distance to goal from current location

 Angle from current heading to line pointing to goal

 Then controller looks very different

Design Alternative 2 Rules

 Distance difference

 Heading Difference

 …

Fall 2002 © Gal Kaminka, 18

Design alternative 2 summary

 Add some pre-processing of sensor data

 Gain scalability, readability

Obstacle avoidance

 To detect obstacles, we use the sonar

sensors

 Send ping, measure time until pong

 Unreliable, but cheap

 Before we look at designs

 There’s something you should know about YODA

 Sonars are fixed direction, regardless of heading

 e.g., sonar 13 always points north

 Again, can anyone suggest some designs?

Fall 2002 © Gal Kaminka, 20

Alternative Design 1

 Raw directions:

 IF object-close(north) AND north(current-heading)

THEN speed=stop

 IF object-close(north-east) AND north(current-heading)

THEN speed=slow, turn=small-left

 IF object-close(north-east) AND south(current-heading)

THEN speed=fast, turn=no-change

 …

 IF object-close(south) AND north(current-heading)

THEN speed=fast, turn=no-change

Alternative Design 2

 Again, seems we consider all combinations

 For each sensor and heading, consider obstacle distance

 Let’s try pre-processing the sensor readings again

 Treat sensors relative to heading:

 IF obstacle-close(forward) THEN speed=stop

Fall 2002 © Gal Kaminka, 22

Goal-relative sensing

 Create virtual-sensors based on heading

 In principle, we can do this using rules

 IF north(current-heading) THEN forward=north

 IF north(current-heading) THEN left45=north-west

 IF north(current-heading) THEN right90=east

 …

 IF south(current-heading) THEN forward=south

 IF south(current-heading) THEN left45=south-west

 ……

Goal-relative sensing

 Note these are no longer fuzzy rules

 Only dynamically rename sensors, no inference

 Indeed, why do this with rules?

 Simple pre-processing algorithm

 Yet what a difference this makes!

 We can no do obstacle-avoidance with very few rules!

 Open questions:

 Is there a general technique here?

 When will this not work? What did we give up here?

Fall 2002 © Gal Kaminka, 24

Controller: Complete Design

From design to implementation

 Requires assigning membership values

 There is significant literature on doing this

 Including automated learning

 For our purposes, this can be done by hand

 Pick trapezoid or triangular shape

 Modify parameters based on trial and error

 Simulations can be helpful, but not replace real-world

Fall 2002 © Gal Kaminka, 26

Problem: Number-hacking

 Rules are approximating the function that we

want

 Through trial-and-error, we improve approximation

 Difficult to get arbitrarily close to ideal

 Developer spends much time adjusting

numbers

 Tries to patch rule base to cover specific cases

 Two sets of rules

 IF far(goal) THEN speed=fast

 IF close-obstacle(forward) THEN speed=stop

 Robot does not slow sufficiently

 Because overall results compromises between stop and fast

 Options:

 May want to add redundant rules to increase weight

 Add distance to goal into obstacle-avoidance rules

 Re-define fast to be slower

Fall 2002 © Gal Kaminka, 28

Goal X, Y

Theta

Seek Goal Speed

Heading Change

Context Rules

 IF obstacle-close THEN Avoid

 IF not obstacle-close THEN Seek-Goal

 IF obstacle-close(forward) THEN obstacle-close=true

 IF obstacle-close(right90) THEN obstacle-close=true

 ……

Fall 2002 © Gal Kaminka, 30

Problems with fuzzy control

 Avoid-obstacles controller needed to know the

goal

 This may result in rule explosion

 All combinations of sensor readings and goal state

 Would be much simpler to have negative rules

 But these are not trivial in fuzzy

 Defuzzification, inference methods may or may not work

 Also, what do we do with multi-modal output sets

 Saffiotti et al.’s answer: Do better design

 But this requirement may not scale

Homework (Due in two weeks)

On web page!