VR-Forces 4.1.1 Class Documentation
4.2 - Components and The Component Manager

Table of Contents

VR-Forces supports three basic types of components - sensors, controllers, and actuators.

The component architecture (illustrated) supports any number of sensors, controllers, and actuators in a simulated entity. Components communicate with each other through ports.

entitycomponentarchitecture.png
Entity Component Architecture

All components are derived from the class DtSimComponent (simCmpnt.h), or a subclass of DtSimComponent. Components are specified in the object parameter database file by using DtComponentDescriptors (compDesc.h). Component descriptors can also provide parameter information to a component. Each local entity has a Component Manager, DtSimComponentManager (compMgr.h).

The Component Manager creates, connects, and maintains the lists of DtSimComponents (sensors, controllers, and actuators) for an entity. Entities that are configured with a Component Manager have an instance of a DtSimComponentManager. Only local entities should be configured with a Component Manager.

Groups of related sensors, controllers, and actuators can be assembled into DtComponentSystems. A DtComponentSystem is a set of DtSimComponents that are managed as a group. They typically represent some logical subsystem of an entity, such as a weapon or movement system.

This section describes the purpose and function of each type of component and briefly describes ports and port groups. For detailed information about components, please see 5 - Component Concepts.

4.2.1 Sensor Components

Sensor components provide models of the simulated environment, which are used by controller components to make decisions and perform tasks. The simplest sensor might provide (simulated) ground truth, while more sophisticated ones could use complex models for sensing electromagnetic emissions, or a cognitive model to simulate a soldier or crew member's perception of the simulated world. Sensor components can get information from:

Sensors are derived from DtSimComponent. The use of sensors is optional. If a controller only needs to work with ground truth, it can get that information directly, although this may make reuse of the controller component more limited.

4.2.2 Controller Components

Controller components typically provide control inputs to actuator components (although this is not required). A subset of controller types register interest in task messages and perform the specified tasks directly, or provide control inputs to actuators to accomplish these tasks. Controllers can use information provided by sensors to perform their functions, but this is not a requirement. For example, the controller that implements the various forms of the Wait task neither requires sensor information, nor provides control inputs to any actuators.

Controllers are created as DtControllerComponents (cntrlCmpnt.h) or a subclass. Controllers that receive and implement tasks should derive from DtTaskControllerComponent (taskCtlrCmpnt.h), because this class provides some basic task management that all of these types of controllers must perform. Each DtControllerComponent has a DtSimBaseRadio (baseRadio.h) for registering interest in task messages.

4.2.3 Actuator Components

Actuator components:

Actuators can use control inputs provided by controller components as parameters to its model each simulation frame. Actuators may:

Actuators can also use data directly from a sensor, when modeled or filtered data is preferred over simulated ground truth for a model that does not require a controller. Actuators are created as DtActuatorComponents. Each DtActuatorComponent (actCmpnt.h) has a DtSimBaseRadio (baseRadio.h) for sending and receiving messages.

Note
While the component architecture suggests a model for implementing an entity model, these are guidelines, not rules. For example, you could build an entire entity model as a single component and put it on the sensor list. How you use the component architecture is up to you.

4.2.4 Inter-Component Communication

Components exchange data with each other through ports. There are two kinds of ports: DtInputPort (inputPort.h) and DtOutputPort (outputPort.h). Components that produce data (such as a sensor) typically have one or more output ports. Components that accept data as input typically have one or more input ports. Ports may provide data as simple as a single number (such as a throttle value), or more complex data such as a list of entities that have been detected.

Port groups are collections of ports. There are two kinds of port groups: DtInputPortGroup (inputPortGroup.h) and DtOutputPortGroup (outputPortGroup.h). Each is a collection of the ports of the corresponding type (DtInputPort or DtOutputPort). A component can have-a DtInputPortGroup or DtOutputPortGroup member that it uses to manage collections of ports.

Port groups are useful for creating logical groupings of ports. They indicate that the data handled by the ports in the group is related in some way. For example, the automotive port group contains the throttle, steering, and brake ports. The automotive actuator that makes use of this group expects to receive all three inputs in order to work properly.

Ports and port groups also provide an interface that makes it possible to multiplex and prioritize multiple data sources to a single data sink. For example, the ground vehicle automotive actuator can accept inputs from a collision-avoidance conroller, move-to-point controller, and follow-route controller, but it does not want inputs from all of those controllers at once.

[<< Entities] [Home] [Top of Page] [Creating an Entity >>]


Document ID: Generated on Mon Apr 8 19:24:01 EDT 2013 from SVN revision 125877
Copyright © 2005-2013 VT MÄK. All Rights Reserved (www.mak.com)