topics in programming reactive systems n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Topics in Programming Reactive Systems PowerPoint Presentation
Download Presentation
Topics in Programming Reactive Systems

Loading in 2 Seconds...

play fullscreen
1 / 15

Topics in Programming Reactive Systems - PowerPoint PPT Presentation


  • 109 Views
  • Uploaded on

Topics in Programming Reactive Systems. Prof. Ronen Brafman a nd Dr. Gera Weiss. Goal . Learn, and help us refine a new methodology for developing reactive systems and autonomous systems

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Topics in Programming Reactive Systems' - garson


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
topics in programming reactive systems

Topics in Programming Reactive Systems

Prof. Ronen Brafman

and

Dr. Gera Weiss

slide2
Goal
  • Learn, and help us refine a new methodology for developing reactive systems and autonomous systems
    • This means that what we describe are guidelines, and that you are free to structure your code as you wish, provided you keep the basic ideas
  • Use this methodology to develop players for robocode
robocode
Robocode
  • http://robocode.sourceforge.net/ information, tutorials, code, suggested strategies, etc.
  • file://localhost/Users/Brafman/robocode/robocode.command
course schedule and work load
Course Schedule and Work Load
  • 14/3: Lecture a. Description of course goal b. Description of robocode c. Description of the programming methodology.
  • 21/3: Assignment due: simple, hand coded robocode agent
  • 28/3: Lecture + Assignment due: List of b-threads, their description, and their place in the hierarchy
  • a. 18/4: Student Lectures Describe agent design and methodology support. 10 min each pair
    • Assignment due: Methodology support and critiquing document – max 2 pages
  • 2/5: Assignment due: Player code + documentation + time report
  • 23/5: StudentLecture. Students describe agent team design 10 minutes each.
  • 1/7: Assignment due: a. Team code b. Architecture document – max 3 pages c. Methodology support and critiquing – max 2 pages d. Time report.
requirements and grade
Requirements and Grade
  • Attend all lectures
    • Both students should be prepared to present their architecture in both cases
  • Submit all assignments in time and receive a passing grade on each assignment
    • Submission in pairs
  • Grade: assuming you meet all above requirements, your grade will be:
    • Simple player: 5 pts
    • Agent architecture description: 10 pts
    • Agent architecture document: 10 pts
    • Agent code submitted on time with proper documentation and using proper methodology 15
    • Agent performance 5
    • Team architecture description: 10 pts
    • Team architecture document: 10 pts
    • Team code submitted on time with proper documentation and using proper methodology 20 pts
    • Team performance 15 pts
    • Time logs submitted 5 pts
flat behavioral programming
(flat) Behavioral Programming
  • Basic idea: write behaviors (called b-threads)
    • almost standalone threads that deal with one aspect of the problem you care about
    • each behavior can ask for “actions” to be done, and for other actions not to be done “blocked”
    • a coordinator receives all requests, and selects an action that was requested but not blocked, and informs the thread on its selection
    • Each thread continues as it code specifies.
      • The code will say how to react to some changes/actions
      • It does nothing when others occur
    • behaviors can only change their own state based on events, and make a request to execute/block
    • they cannot actually carry out an action, only the coordinator can
  • When the overall behavior is missing something, add a new behavior
    • It will either request something that was not requested or block some undesirable behavior
  • Motivation:
    • We never get a complex system right the first time
    • We want an incremental modification process -- add new behaviors that handle the problem
  • Example: quad-rotor
important principle try to focus
Important Principle – Try to Focus
  • Try to write behaviors that achieve, or maintain something concrete
    • Prevent collision
    • Save fuel
    • Reach target quickly
  • We will soon see how to combine them
    • Some b-threads will be in charge of “orchestrating” these behaviors
weights
Weights
  • Actually, rather than ask for an event/action, b-threads vote.
  • Each b-thread votes for/against each behavior it cares about, by assigning it some weight.
    • Positive weight – wants to see it take place
    • Negative weight – prefers not to see it
    • 0 – don’t care
    • -∞ -- absolutely forbiden
  • The coordinator will combine these “votes” and select the action with highest value
important principle consider program many options
Important Principle: Consider/ Program Many Options
  • In standard code, a thread/procedure etc. can request (or directly activate) some function/actuator/action
  • In BP, a thread does not know whether its favorite choice will be executed
  • It needs to consider many actions: either ask for them, or ask that they will not take place
    • You like Bibi, but maybe he won’t be selected. So let the coordinator know what you think about Liberman, or Mofaz
  • So you should program many ways to implement things, so that in case one is blocked, the others may be acceptible
  • Remember – the worse thing is for the coordinator not to have any valid choice
structure of a b thread
Structure of a b-thread
  • Regular code that keeps track of state variables and external events in order to achieve (or maintain) some goal:

- Keep vehicle stable, or

    • Prevent collisions, or
    • Pickup an object
  • Whenever it wants something done, uses a b-synch statement to vote for behaviors/actions that achieve what it needs now
    • Need to define a “vote” object that is basically the value of a b-synch statement
synchronization
Synchronization
  • To support this, we need a synchronization thread
    • Waits for all relevant requests (i.e., b-synchs)
    • Decides what to do based on the votes
    • Informs the b-threads about the action that was selected (so they can update their state, and continue along the correct branch)
synchronization1
Synchronization
  • Many options!
  • Many ways of implementing:
    • Via continuations (you store the state of the procedure before a b-synch, and continue later after decision)
    • Via real threads
  • Many design choices:
    • How much time to wait for a decision?
    • Do we need to wait for all relevant b-threads?
    • Various “standing” requests” – don’t do X until I say so
hierarchy
Hierarchy
  • It is impossible to build large systems without some hierarchy and structure
  • Our methodology has some clear guidelines on this, which also help decompose the problem
    • We focus on a linear hierarchy
    • Each level has a set of b-threads + own coordinator
    • Each level defines a set “actions” for the level above
      • One typical action allows us to set the priority of b-threads
      • Others allow us to set other parameters
      • Others allow us to activate a b-thread
top down design
Top-Down Design
  • Top level (0): single b-thread called “success”
  • Level 1: one b-thread for every goal/success criteria
    • Robocode: kill, stay alive
  • “Success” b-thread sets the priority of level 1 criteria
    • Can be static (fixed weight)
    • Can be dynamic (update weight based on events)
top down design1
Top-Down Design
  • Threads at level i+1 describe behaviors that are relevant to some (possibly many) threads at level i.
    • “Kill” will vote for various behaviors that can destroy other tanks
      • Various techniques for shooting other tanks
    • “Stay alive” will vote for various behaviors that make it hard to hit our tank
    • Various strategies for moving or hiding can used by b-threads that support kill/stay alive