rbs tutorial
Download
Skip this Video
Download Presentation
RBS Tutorial

Loading in 2 Seconds...

play fullscreen
1 / 24

RBS Tutorial - PowerPoint PPT Presentation


  • 67 Views
  • Uploaded on

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

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 ' RBS Tutorial' - marny-morse


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
rbs tutorial

RBS Tutorial

CIS 488/588

Bruce R. Maxim

UM-Dearborn

breaker capabilities
Breaker Capabilities
  • Obstacle avoidance
  • Pursuit
  • Evasion
  • Weapon selection based on situation
  • Prediction of enemy movement
  • Basic aiming and firing at targets
  • Tactical reasoning
technology
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)
principles
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
how can we execute animat behaviors in parallel if rules are fired one at a time
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
how can we execute animat behaviors in parallel if rules are fired one at a time1
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
how can we execute animat behaviors in parallel if rules are fired one at a time2
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
senses
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
sensors used 1
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
sensors used 2
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%
actions
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
movement actions
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
view control actions
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
weapon control actions
Weapon Control Actions
  • Use Weapon
    • Select one of four weapons (rocket launcher, railgun, chaingun, hyperblaster)
  • Fire
    • Pull trigger on current weapon
action chunk rules
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
movement chunk rules
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
weapon chunk rules
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
view control chunk rules 1
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
view control chunk rules 2
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
breaker
Breaker
  • Let’s view the demo
  • Author recommends disabling firing rule to make the end more quickly
evaluation 1
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
evaluation 2
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)
evaluation 3
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
conclusion
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
ad