Frobocup a DSL for Robotic Soccer - PowerPoint PPT Presentation

Title: Frobocup a DSL for Robotic Soccer


1
Frobocup a DSL for Robotic Soccer

• Functional Programming as a DSL construction kit
• -- featuring --
• Haskell
• and
• Functional Reactive Programming (FRP)
• John Peterson, Andrei Serjantov, Paul Hudak
• Yale University

2
Robocup The Video
Robocup is an international robotic soccer
competition A test of both hardware and software
skills!!
3
The Domain Robocup
Radio link
Camera
Robots
Central Computer
Ball
All robots controlled by one computer Overhead
camera tracks robots and ball
4
Robocup Challenges

• Hardware design and construction
• Control system design
• Sensing (vision)
• Strategy ? Our emphasis
• Uncertainty (the opponents)

Why is the strategy hard? An effective system
must integrate control systems, switching logic,
planning, reasoning, assessment, and
learning. Users need to rapidly explore the
design space, building, testing, and assessing
strategies. Our approach a Robocup Domain
Specific Language
5
About DSLs

• A DSL combines a vocabulary (primitive types and
  functions) with the ability to capture patterns
  (abstractions)
• We use an embedded DSL implemented within an
  existing language. Haskell vocabulary DSL
• Haskell contributes composability (explicit
  interaction among components, laziness) and
  polymorphic typing (safety)
• Use Functional Reactive Programming (FRP) to
  manage interaction in a purely functional way
• Based on earlier work on robotics (Frob), vision
  (FVision), and animation (Fran)

6
The Key Composibility

• Objectives
• To express simple control systems in a natural
  and declarative manner (following a ball)
• To alter robot behavior depending on context
  (obstacle avoidance)
• To commit to and execute complex parameterized
  behaviors (control systems) based on situation
  (planning, learning)
• To assign tasks to robots (control a group in
  unison, allocate specialized tasks)
• To express coordinated motion of several robots

7
Implementation Architecture
Java
Haskell
Frobocup
8
FRP and Behaviors

• Functional Reactive Programming is a functional
  model of interaction with the outside world
• Basic data type (polymorphic!!)
• Behavior a -- value of type a that evolves in
  time

Type that models a robot on the field
r Robot
Underlying static type
Time varying aspects of the robot
botPosition r Behavior Point2 botOrientation
r Behavior Angle botVelocity r Behavior
Vector2 robotSize r Float
Static (non-varying) aspect of the robot
9
Using Behaviors

• type Behavior a Time -gt a ? idealized
• Operators may be lifted into the behavioral
  domain
• lift2 (a -gt b -gt c) -gt
• (Behavior a -gt Behavior b -gt Behavior c)
• lift2 f \x y t -gt f (x t) (y t)
• FRP defines many lifted operators, including
  arithmetic (, -, , /) and comparisons (gt, lt,
  ). Also integral, derivative.
• A lifted conditional
• ifB Behavior bool -gt Behavior a -gt Behavior a
  -gt Behavior a
• ifB lift3 (\b x y -gt if b then x else y)
• Behaviors hide the flow of time no need for
  iterative control loops.

10
Types

• data World a set of behaviors defining robots,
  ball position
• data Controls a set of behaviors controlling
  all the teams robots (motor voltages)
• data Robot behaviors defining a robots
  position and orientation
• data RControl motor voltages for a single robot
  at a single time step
• type SystemController World -gt Controls

11
Example Goalkeeper

• keeper World -gt Robot -gt RControlB
• keeper w bot
• let v1 ball w .-. rPlace bot
• v2 ball w .-. goalCenter
• vec normV v1 normV v2
• (s,d) vector2PolarCoord vec
• in (s,d)

Ball
v2
vec
v1
v2
bot
Goal

• This control system is valid only if
• Robot is near the goal
• Robot is relatively far away from v1 (s is not
  too small)
• This validity region can be expressed using the
  boolean behavior
• (s gt 0.1) (near_goal bot)

12
Validity Regions
Validity region
Behavior
Behavior
Validity region
If you are too far from the goal, run back as
fast as possible
If you are lined up between the goal and the
ball, kick it away
13
Composing Control Systems using Validity Regions

• Capture this structure in an abstraction
• type Controller a (Behavior Bool, a)

Region
Control
blocker Controller RControlB blocker ((s gt
0.1) (near_goal bot), keeper w bot) Use this
abstraction to create composite
controllers (..) Controller a -gt Controller
a -gt Controller a (b1,c1) .. (b2,c2) (b1
b2, (ifB b1 c1 c2))
Favors first controller when both are valid
14
Example a Better Goalkeeper

• gkeeper World -gt Robot -gt RControlB
• gkeeper w bot
• ((s lt 0.1) (near_goal bot),go_for_ball w bot)
  
• ..
• (not (near_goal bot), runBack w bot))
• ..
• ((s gt 0.1), keeper w bot)

15
Variations on Combination

• The .. combinator uses supression we can also
  join valid controllers in other ways. Vector
  field control allows controllers to be joined via
  vector addition

type VController Controller Vector2 (..)
VController -gt VConroller -gt VController (b1,c1)
.. (b2,c2) (b1 b2, (ifB b1 (ifB b2
(c1c2) c1) c2))
The point of this it is easy to define these
patterns in a way that supports Compositional
programming building complex controllers from
simpler ones in a transformational style
16
Reactivity
The ifB function performs a continuous
combination of control systems control may pass
freely between the systems and the predicate
defining the domains is evaluated constantly. We
also need committed choice a one-way sequencing
from one behavior to the next.
FRP primitives
holdPosition until ballKicked -gt catchBall
Initial behavior
Transition event
New behavior
17
FRP Events
Another essential FRP type Events. An event
stream represents a set of discrete occurrences
in time type Event a (Time, a) ?
idealized Events in the Robocup
context goalScored Event Bool -- occurs
when a goal is scored
-- boolean indicates scoring
team Synthesize events from behaviors predicate
Behavior Bool -gt Event () -- watch a
behavior Lots of primitive FRP event
functions andThen Event a -gt Event b -gt
Event b -- sequential occurrence of events
18
Better Abstractions

• Use until to build more powerful sequencing
  abstractions.

Another way to define a controller type Task a
b (Behavior a, Event b)
Add a terminating event to a behavior
This function performs two tasks in
sequence (b1, e1) gtgt (b2, e2) (b1 until e1
-gt b2, e1 andThen e2) composability!!!
19
Better Tasks
This fits into a more general pattern the
monad We may also need a special type of task
the empty task. This defines no behavior
control passes to the next task immediately.
However, a null task may observe the
instantaneous system state Some useful null
tasks closestRobotToBall Task a
Robot passPoint Task a Point2

20
More Monad Magic

• We can use the same monad that sequences tasks to
• associate tasks with sets of robots. (a state
  monad).
• This allows parallel task composition.
• Similar to a case statement selected robots are
  passed to different tasks.
• Selectors have type Robot -gt Bool
• sel1 gt task1
• sel2 gt task2
• rest gt task3

21
Example Delegation

• teamTask (isRobot 1gt (liftT(annoy 5))
• isRobot 2 gt (liftT(annoy 2))
• isRobot 5 gt (liftT keeper)
• isRobot 3 gt (liftT attack)
• rest gt
• (liftT field_player))

22
FVision Functional Vision

• Another DSL used for computer vision
• Tracks the robots and ball in the camera images
• Uses a large C library to do the dirty work
  use of Haskell does not degrade performance
• Uses FRP to integrate with other parts of the
  system

23
Further Research

• Improve basic control systems kick ball,
  maintain position, block opponent
• Address the real time issue the communication
  link between the computer and the robots has a
  delay associated with it, so we want to send a
  function from position to vector, not just the
  vector
• Planning and assessment of strategies
• Adaptive control systems based on observed robot
  behaviors

24
Related Work

• The simulator we are using, JavaSoccer, Tucker
  Balch, CMU
• Behavioural Language Clay associated with the
  Simulator
• A group of Java classes that can be easily
  combined to create behaviour-based robot control
  systems.
• Not declarative

25
Conclusions

• Domain Specific Languages (DSLs) are a good
  thing
• Higher order functions capture complex
  abstractions in a reusable way
• Our DSL supports rapid, reliable program
  development high level programs, reusable
  components, safety ensured by the polymorphic
  type system
• Functional Reactive Programming is an effective
  way of describing interactive systems in a
  declarative manner. Implicit time flow is a
  convenient abstraction.

26
The Task Monad

• TaskW t1 gtgt u
• TaskW (rs cont -gt
• t1 rs (\s res -gt case res of
• Right v -gt case u v of
• TaskW t2 -gt t2 scont
• Left l -gt cont s (Left l)))
• return k TaskW (\s c -gt c s (Right k))
• TaskW (TState -gt (Tstate -gt Either RoboErr a
  -gt WheelControlB) -gt WheelControlB) -gt TaskW a