Rule-based control

Northwestern UniversityCS 395 Behavior-Based Robotics

Ian Horswill

OutlineA digression on accumulators, a cute

feature of GRLRule-based controlOther cool topics, time permitting

GRL example

(define-signal p (and q r))

(define-signal q (and r s))

(define-signal r (or t u (not v)))

Accumulators It’s sometimes a pain to specify signals

in terms of their inputsSometimes you’d prefer to specify them

by their outputsAn accumulator is a signal that

searches for its inputs at compile time Inputs are specfied by tagging them

with a drives declaration

Using accumulators

Signal definitions can be annotated with declarations (type t)

Signal is of type t (drives accumulator …)

Signal is an input to the specified accumulators (requires signal …)

If you compile this signal, also compile these others

(define-signal p (and q r))(define-signal q (and r s))(define-signal r (accumulate or))

(define-signal t … (drives r))(define-signal u … (drives r))(define-signal foo (not v) (drives r))

If only you could just say …

(if (and q r) p) (if (and r s) q) (if t r) (if u r) (if (not v) r))

The rules macro

First line means “r is a signal that’s an OR of other sigals, but I’m not telling you which ones yet.”

Says: Signal r should be true when t, u, or not v Z should be true when a and not (q and r)

(define-signal r (accumulate or)) …

(rules (when a (if (and q r) p z) (if (and r s) q)) (if t r) (if u r) (if (not v) r))

Equivalent code usingdefine-signal

The compiler generates the same code for these two examples

(define-signal r (or t u (not v)))

(define-signal p (and a q r))

(define-signal z (and a (not (and q r))))

(define-signal q (and a r s))

How to write the rules macro (simplified version)

The declare expression adds a new declaration to the signal ?ante

(define-syntax rules (syntax-rules () ((rules (if ?antecedent ?consequent) …) (signal-expression (list (declare ?ante (drives ?conseq)) …))))))

Outline A digression on accumulators, a cute

feature of GRLRule-based controlOther cool topics, time permitting

The story so far … Programs policies Compose policies from behaviors

Behavior = policy + trigger Bottom-up composition using arbitration

Behavior-or, behavior-+, behavior-max Behaviors self-activate

Top-down composition using plans Routine activates subroutine Subroutine activates sub-subroutines, etc. Leaves activate behaviors

Playing a first-person shooter If you see ammo, get it If you see a bigger gun than you have,

get it If you see an enemy {

if they have a bigger gun run else kill them}

Using bottom-up control

Code is hard to understand Can’t really understand the logic of run-away without also

reading code for attack the drive-base call.

Okay, so this is a lame example. I can’t think of a better one that’s compact enough for a slide.

(define-signal get-ammo (behavior see-ammo? …))

(define-signal get-weapon (behavior (and see-weapon? studly-weapon?) …))

(drive-base (behavior-or get-ammo get-weapon attack run-away)))

(define-signal attack (behavior (and see-enemy? (not studly-enemy?)) …))

(define-signal run-away (behavior see-enemy? …))

Top-down control using plans

Separates definition of how to perform behavior from when to perform behavior

Makes it easier to take complex contexts into account in selecting actions

But actions aren’t interruptable …

(define-plan (live-and-let-die) (while #t (cond (see-ammo? (get-ammo)) … (see-enemy? (if studly-enemy? (run-away) (attack))))))

(define-action (get-ammo) (terminate-when have-ammo?) …)(define-action (get-weapon) …)(define-action (attack) …) (define-signal (run-away) …)

(drive-base get-ammo get-weapon attack run-away)))

Rule-based top-down control

Control is reactive Rules and behaviors can be interrupted Note terminate-when has been removed

Still separates activation from behaviors

(rules (when see-ammo? (get-ammo)) (when (and see-weapon? studly-weapon?) (get-weapon))

(when see-enemy? (if studly-enemy? (run-away) (attack))))

(define-action (get-ammo) …)(define-action (get-weapon) …)(define-action (attack) …) (define-signal (run-away) …)

(drive-base get-ammo get-weapon attack run-away)))

Rule syntax (if test consequent alternative)

(if test consequent)Self-explanatory

(when test consequents …)(unless test alternatives …)Same, but multiple outputs

(let ((var expr)) rules …)Also let*, letrec

(set! register value)Sets register to value when rule runs.

Rule syntax (2)Allowable consequents and alternatives

An accumulator Another rule (action args …)

Runs the action as long as the test is true (start! (action args …))

(stop! action) Starts/stops up the action whenever rule is true

Rules as actions (define-rule-action (name args …)

(terminate-when expression) rules …) Like define-plan or define-action in that it

can be called as an action But rules only “run” when action is “called” If action stopped, all rules immediately

retract

Outline A digression on accumulators, a cute

feature of GRLRule-based controlOther cool topics, time permitting