Rule-based control

1. Rule-based control Northwestern UniversityCS 395 Behavior-Based Robotics Ian Horswill

2. Outline • A digression on accumulators, a cute feature of GRL • Rule-based control • Other cool topics, time permitting

3. GRL example (define-signal p (and q r)) (define-signal q (and r s)) (define-signal r (or t u (not v)))

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

5. Using accumulators (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)) • 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

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

7. The rules macro (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)) • 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)

8. Equivalent code usingdefine-signal (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)) • The compiler generates the same code for these two examples

9. How to write the rules macro (simplified version) (define-syntax rules (syntax-rules () ((rules (if ?antecedent ?consequent) …) (signal-expression (list (declare ?ante (drives ?conseq)) …)))))) • The declare expression adds a new declaration to the signal ?ante

10. Outline • A digression on accumulators, a cute feature of GRL • Rule-based control • Other cool topics, time permitting

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

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

13. Using bottom-up control (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? …)) • 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.

14. Top-down control using plans (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))) • 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 …

15. Rule-based top-down control (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))) • Control is reactive • Rules and behaviors can be interrupted • Note terminate-when has been removed • Still separates activation from behaviors

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

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

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

19. Outline • A digression on accumulators, a cute feature of GRL • Rule-based control • Other cool topics, time permitting