Rule-based control Northwestern University CS 395 Behavior-Based Robotics Ian Horswill

Outline  A digression on accumulators, a cute feature of GRL  Rule-based control  Other 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 inputs  Sometimes you’d prefer to specify them by their outputs  An 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 using define-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 GRL  Rule-based control  Other 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 GRL  Rule-based control  Other cool topics, time permitting