 |
VR-Forces 4.5 Class Documentation
|
All Classes Namespaces Files Functions Variables Typedefs Enumerations Enumerator Friends Macros Groups Pages
|
VR-Forces 4.5 Class Documentation
|
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 simulation object. Components communicate with each other through ports.
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 simulation object has a Component Manager, DtSimComponentManager (compMgr.h).
The Component Manager creates, connects, and maintains the lists of DtSimComponents (sensors, controllers, and actuators) for a simulation object. Simulation objects that are configured with a Component Manager have an instance of a DtSimComponentManager. Only local simulation objects 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 a simulation object, 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.
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.
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.
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.
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 simulation objects 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.
[<< Simulation Objects] [Home] [Top of Page] [Creating a Simulation Object >>]