Topics in Programming Reactive Systems

1. Topics in Programming Reactive Systems Prof. Ronen Brafman and Dr. Gera Weiss

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

3. Robocode • http://robocode.sourceforge.net/ information, tutorials, code, suggested strategies, etc. • file://localhost/Users/Brafman/robocode/robocode.command

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

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

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

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

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

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

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

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

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

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

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

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