I. High Level DesignCAT has three purposes:
Subsystems
GUIThe GUI is responsible for displaying information about the selected entity and the internal state of CAT, provide means of controlling the selected entity, and sending commands to control the Recorder.
BehaviorsThe Behavior subsystem is a collection of behaviors that can be used to control an entity. These behaviors observe, through Sensors, the environment and output direction for the entity. The behaviors can be pieced together to make a behavior network, or used individually for simple control.
BehaviorNetworksThe Recorder takes input from the user via the GUI and pieces together a behavior network that can be used as a controller.
ControllersAll controllers, simple and complex, are in this subsystem. Here a record is kept of every controller available to the system. The controllers and records are read-only, but can be read by the outside system so that it can decide what controller it might want to use. It then can ask the Manager to load that controller.
ManagerAll external controller requests of CAT are done through the Manager. Primarily, this consists of loading and initializing a controller and attaching it to an entity. Also, the system Tick that is called by GO starts here and propagates through CAT.
ExecutiveThe Executive subsystem is outside of the design of CAT. Its purpose is a communication bridge between SP and CAT. It requests from CAT specific controllers it wants attached to certain entities.
EntityThe Entity subsystem is outside of the design of CAT. An entity is the graphics, data, and physics of something inside the simulation. All this is controlled through a controller provided by CAT.
GOThe GO subsystem is outside of the design of CAT. GO is the game engine and all data about the world is kept in here.
II. Medium Level Design |
The GUI Subsystem![]() The GUI takes care of arbitration and fusion of running behaviors, selecting between behaviors, changing entity properties, and running the Recorder Subsystem. The GUI is not blocked, but all changes to the system are held until the next tick. Display includes all elements listed in the specification document as well as the status of the Recorder. A tick pass through entails getting the latest information from the system, updating the information displays, running any current behaviors, and then making any necessary changes to the system. If the Recorder is running, it is allowed to run an update pass to help build the network.
The Behavior Subsystem |
This subsystem is a hierarchy of class and at the top is the Behavior class. It is an abstract class the specifies methods that all behaviors should have and defines other methods that all behaviors use. BNetBehavior and PrimitiveBehavior inherit from this class. BNetBehavior is used in behavior networks. It is not a behavior in a traditional sense. It maintains and checks the preconditions and postconditions used in a behavior network. It does not actually control an entity but it does have a sub-behavior that can. This sub-behavior can either be another BNetBehavior (meaning it has a sub-behavior network) or a PrimitveBehavior. The sub-behavior is run if all the preconditions of the NetBehavior and sub-behavior are met. If the sub-behavior is another behavaior network, then it is allowed to run. Otherwise, if the sub-behavior is a PrimitiveBehavior, then the actuator output is passed up to the controller to control the entity. PrimitiveBehavior is another abstract class. In general, a primitive behavior takes sensor input and gives actuator output. The PrimitiveBehavior class defines those methods that all these behaviors have in common, like getting the actuator values or setting parameters that the behaviors uses for the transformation of data. Currently, there are eight primitive behaviors. Approach and Retreat bring the entity closer or farther away from a different target entity. Maintain keeps the entity with in a certian bearing and range of the target. Approach, Retreat, and Maintain are mutually exclusive. Wander causes the boat to randomly choose a new direction after random time interval. Fire causes the boat to use the entity's selected weapon against a chosen target. Formate is use to bring multiple ships together into a cohesive formation. AvoidLand and AvoidEntity scan the waters for obstacles and pilots the entity away from them. Outside of the Behavior class hierarchy lies the Sensors class. This class is an interface to the system environment. It provides the status of the world in a manageable form that makes it simpler for behaviors to operate.
The BehaviorNetwork Subsystem![]() For ABRA, recording behavior networks is done through selecting primitive behaviors. During this process, controlling the entity through manually setting the speed and heading is not allowed. Recorder monitors the selected behaviors and environment triggers. It keeps an internal model of the current behaviors parameters and whenever a change occurs, it splits off a new branch on the network and monitors the new behavior. A change can be either a trigger becoming true, a behavior has met its goals, or the use selects a new behavior to run. When the used decides to stop training, Recorder passes the data it collected to Constructor. The AvoidLand and AvoidEntity behaviors are not included in the network due to their always on nature. Instead, the parameters for AvoidLand and AvoidEntity are kept with the behaviors that were running so that when they run again, the same levels of evasion are used. Constructor parses the data into a form that can be read later by NetController. This includes all the precondition linkages between behaviors and the parameters that the behaviors used in the network. Contructor also updates the controller database so that SP can use the new controller.
The Controller Subsystem![]() This subsystem is actually three separate controllers each unified by a Controller parent. Controller defines those methods used by the three children but is otherwise abstract. The NetController loads in a behavior network file and uses that to control the ship. SpecialController is a unique, empty class. Controllers that are hand programmed in some unique way or for some unique task should inherit from this class. It provides a grouping for all these controllers and CAT understands that these controllers operate differently from normal controllers and usual expectations (whatever those maybe) are not guaranteed. For now, this class is mostly for future expansion and special cases.
The Manager Subsystem![]() Communication to CAT about what controllers to load and for what entities is provided through this subsystem. Information about the controllers is kept in "/comm/tasks". Each controller goes underthis path as an nent and underneath this are more nents that describe the parameters to the controller. EXEC and SP can use this to send controllers and parameters to Manager which can then initialize the correct controller.
The Sensors Subsystem![]() The Sensors package are a bunch of convinience wrapper for accessing the environment. Entity names are just getter and setters. GetEntities() parses through the EVA tree and compiles a list of paths. GetLandRange() polls GO to get raytracing info and GetLandRanges() polls all 360 degrees and returns a list of those values.
III. Low Level Design
Process Tick![]()
Behavior Arbitration/Fusion![]()
IV. Data and Interface Design
Controller Management Interfacecat.AttachController(entity, controller, vars) Attaching controllers is a easy process. The function as three parameters. entity is a path to the entity on the EVA tree you want to attach a controller. controller is the name of the controller you want to attach. vars is a dictionary of parameter names and values. The controller names and parameters are found on the EVA tree under the path "/comm/tasks/". Under this tree is a series of ents. The name of each ent is a name of a controller. Under each controller are more ents. Each of these are a parameter. The name of the ent is the name of the parameter. The variables attached to the parameter ents are metadata. As of now, there are four pieces of metadata:
Controller Database FileThe Controller Database file is an XML formatted file the contains the information on all controllers and their parameters that can be attach by CAT. CAT reads in this file to set up the EVA tree ABRA can read it.
<controller name=”Scenario1”> <parameter name=”startRange” type=”int”> <max value=”20000” /> <min value=”0” /> <default value=”10000” /> </parameter> <parameter name=”attackRange” type=”int”> <max value=”20000” /> <min value=”0” /> <default value=”2000” /> </parameter> <details> <type value=”network” /> <location value=”path/to/network.xml” /> </details> </controller> Each entry starts with a controller tag with its name as an attribute. Listed in are the parameters and the details. The parameters give a data type, a maximum value, a minimum value, and a default. The default is used if that parameter isn’t give when using the interface or the value can’t be read. If the value given is out of range, it is scaled until it fits. Only CAT uses the details. When something uses the interface and specifies a network, CAT can look in the details to see what kind of controller it is and any other information that it might need to properly initialize it. As new controllers, behaviors, or networks are created, they should be added to this file so ABRA can then use them. In the case of networks, they are automatically added when created. For the other two types, they will have to added manually.
Behavior Network FileBehavior network files are used to initialize NetControllers. The file is formatted with XML and three types of data are given in the network. First are the behaviors in the networks with their default parameter values. Along with these behaviors, the precondition links are given as well as they type of link. Lastly, information about the triggers used for transitions between behaviors are give.
V. User Interface Design
VI. Traceability Matrix
VII. Glossary |