1 / 24

RBS Tutorial

RBS Tutorial. CIS 488/588 Bruce R. Maxim UM-Dearborn. Breaker Capabilities. Obstacle avoidance Pursuit Evasion Weapon selection based on situation Prediction of enemy movement Basic aiming and firing at targets Tactical reasoning. Technology. Second-generation RBS

marny-morse
Download Presentation

RBS Tutorial

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. RBS Tutorial CIS 488/588 Bruce R. Maxim UM-Dearborn

  2. Breaker Capabilities • Obstacle avoidance • Pursuit • Evasion • Weapon selection based on situation • Prediction of enemy movement • Basic aiming and firing at targets • Tactical reasoning

  3. Technology • Second-generation RBS • Declarative XML rules • Boolean symbols used to represent rules • Conflict resolution based on rule ordering • Rule interpreter written in C++ • Rules loaded using lightweight XML interpreter • C++ STL templates used extensively • (e.g. vector and map)

  4. Principles • Rule-base systems can emulate other AI system types • Breaker RBS emulates a finite state machine • Rules will be used to model the FSM control system, not directed graphs

  5. How can we execute animat behaviors in parallel if rules are fired one at a time? • Allow the interpreter to fire all applicable rules during each match cycle. • Rule priorities become irrelevant under this option • This will increase the complexity of most rule conditions • No execution preconditions can be used since the interpreter does not stop at the first match • All rule assumptions must be written explicitly

  6. How can we execute animat behaviors in parallel if rules are fired one at a time? • Make the system use effectors that have persistent effects over time, rather than only instantaneous actions. • This reduces the responsiveness of the system • When one body part get control over the system the others will need to wait for the next match cycle • Tracking the states of the effectors involves techniques that are better suited to FSM’s

  7. How can we execute animat behaviors in parallel if rules are fired one at a time? • Separate rulebase in to chunks, each of which controls only one body part • This techniques is called decomposition by control • Only problem is “what’s the best way to split up the rulebase so that it is easy to manage?” • The implementation of this requires the use of context variables in the rules (e.g. context limiting conflict resolution) • Using a tree structure to store rules so that only rules for active chunks are considered

  8. Senses • Used to gather environment information when requested by the RBS • Functions are defined to retrieve data via the world interfaces and convert it to Boolean symbols for WM storage • Most functions defined in Brain.h as in-line functions

  9. Sensors Used - 1 • Left Obstacle, Front Obstacle, Right Obstacle • Returns true if way is clear • Detects walls, ledges, and steep ridges • Collision • Returns true if collision will move requested is to an occupied space • Enemy, Health Item, Armor Item • Returns true if presence of object is within animat’s field of view

  10. Sensors Used - 2 • Close, Far • Enemy close < = 10 steps away • Enemy far > 20 steps • Low Health, Full Health, Full Armor • Animat personal attributes • Low values < 30% • Full values = 100%

  11. Actions • Allow RBS to apply its decision by controlling the animat’s body • Functions implemented in both Brain.h and Brain.cpp • Actions are grouped into chunks based on body part they control • Actions for looking around and bouncing off obstacles cannot be implemented using a symbolic RBS

  12. Movement Actions • Forward • Move in direction body is facing • Seek • Head toward enemy • Flee • Move away from enemy • Side • Take lateral step (use as strafing motion) • Avoid • Move in direction of collision normal if obstacle hit

  13. View Control Actions • Look Left • Rotate View –30% • Look Right • Rotate view +30% • Look Behind • Rotate view 90+ degrees left or right • Look to Enemy/Health/Armour • Turn to face enemy in field of view • Look Around • Rotate view

  14. Weapon Control Actions • Use Weapon • Select one of four weapons (rocket launcher, railgun, chaingun, hyperblaster) • Fire • Pull trigger on current weapon

  15. Action Chunk Rules • Internal symbols are set so that other rules can check them and decide what to do • The order of the first two rules is not important • IF enemy AND health_low THEN retreat • IF enemy AND NOT distance_close THEN pursue • IF enemy THEN dodge • IF true THEN NOT retreat AND NOT pursue AND NOT dodge

  16. Movement Chunk Rules • Rule order is very important, obstacle avoidance has highest priority • By default animat moves forward with travel directed by view control in later chunk • IF collision AND enemy THEN move_avoid • IF retreat THEN move_flee • IF pursue THEN move_seek • IF dodge THEN move_side IF true THEN move_forward

  17. Weapon Chunk Rules • Decisions are based on distance only • Each rule has to symbols so that a backup weapon is selected when one is out of ammo • Weapons with C++ effectors declared last have priority over previous ones for ties • IF enemy AND distance_far THEN use_rocketlauncher AND use_railgun • IF enemy AND NOT distance_far THEN use_chaingun AND use_hyperblaster

  18. View Control Chunk Rules - 1 • First rule forces animal to turn toward enemy and fire whenever possible • IF enemy THEN look_enemy AND fire • Next three rules focus on collision prevention • IF obstacle_front AND obstacle_left AND obstacle_right THEN look_behind • IF obstacle_front AND obstacle_left THEN look_right • IF obstacle_front AND obstacle_right THEN look_left

  19. View Control Chunk Rules - 2 • These rules gather armor and health items if they are required • IF NOT health_full AND health_item THEN look_health • IF NOT armor_full AND armor_item THEN look_armor • Allow for wandering • IF true THEN look_around

  20. Breaker • Let’s view the demo • Author recommends disabling firing rule to make the end more quickly

  21. Evaluation - 1 • Weapon selection is satisfactory, except that weapons are swapped when two players get close to each other • Collision detection is not perfect (would be better to use dead reckoning based on physics information) • Animat only collects health and armor items by design, weapons and ammo only collected by accident

  22. Evaluation – 2 • Obstacle sensors only check a few steps ahead and animats travel at full speed (so animats occasionally fall off of ledges) • Worse then that animat spins in the air trying to avoid all obstacles on the way down (more realistic without spinning)

  23. Evaluation - 3 • Using only Booleans in WM limits our RBS somewhat (e.g. it can’t even count) • Large arrays of symbols are not searched efficiently (O(N) on the average) • Rule matching with the separate chunks is also O(N) • All symbols must be declared before the rules are loaded

  24. Conclusion • RBS are flexible and potentially powerful • RBS capable of both low-level control and decision making • Rules are modular so adding new rules is fairly easy • Because they are data driven, they can be light weight alternatives to scripting languages for some situations

More Related