 |
VR-Forces 5.0.1 Developer's Guide
|
All Classes Namespaces Files Functions Variables Typedefs Enumerations Enumerator Properties Friends Macros Groups Pages
|
VR-Forces 5.0.1 Developer's Guide
|
Simulation object models in VR-Forces are implemented using components.
Components are the building blocks that make up the sensor-controller-actuator architecture. VR-Forces supports three types of components:
All components in VR-Forces inherit DtSimComponent (simComponent.h). DtSimComponent provides the basic infrastructure of the component architecture. Sensors are derived from DtSimComponent, controllers are derived from DtControllerComponent (controllerComponent.h), and actuators are derived from DtActuatorComponent (actuatorComponent.h).
Since components are created by the factory system, DtSimComponent provides the usual factory-specific member functions as described in VR-Forces Factories. The constructor takes a const DtString name, DtVrfObject* owner, DtSimManager* simManager, DtComponentDescriptor* desc, and DtReaderWriterRegistry* parentRegistry as arguments. (Components are not currently read from or written to files – the registry pointer is included for future use.) The name of the component must be unique within the simulation object that it is part of. Component descriptors are described in Component Parameters and Component Descriptors.
The type() member function of a component must be overridden if you create a new kind of component, reporting the DtString type of the component to be used by the component factory. The type string must be unique across all of the known types of components. The type strings used by VR-Forces components are defined in simComponentTypes.h.
Component descriptors describe components and their parameters in the object parameter database. When a simulation object is instantiated, a component is instantiated for each component descriptor in the object's parameter database entry (that is, in the object's platform file (compImpPlatform) and the systems (Component Systems) that are configured on the object). Each descriptor specifies the type of descriptor it is, the type of component that should be instantiated, and parameter values for the component. For example, this descriptor is a contact fusion descriptor, it requires a contact fusion controller component to be instantiated, and it has three parameters at the bottom that are specific to contact fusion controllers:
Each component has a const pointer to the DtComponentDescriptor from which it was created in the myComponentDescriptor member of DtSimComponent, the base class for all derived components. If a derived component needs to access its corresponding descriptor, it must cast the myComponentDescriptor pointer to the correct type.
Since component descriptors are read from the object parameter database, they conform to the standard factory mechanism described in "VRForcesFactories. The type names of the component descriptors are in compDescTypes.h.
Components have a close relationship with an entity’s state repository (DtVrfObjectStateRepository). Controllers often need to determine an entity’s current state information. Actuators may also need to examine an entity’s state and, typically, update it. When a component is created, the setEntity() member function provides it with a pointer to the simulation object that it is a part of. DtSimComponent caches that pointer, as well as a pointer to the entity’s local state repository, for convenience. If a component is used for a particular type of derived simulation object class and needs access to a derived simulation object or derived entity’s local state, these pointers can be cast to the appropriate type. Many of the VR-Forces derived classes override setEntity() to set a derived simulation object class pointer, so that this cast is not necessary every time the data is accessed.
Components have a tick() function that gets called each frame, or optionally, at some interval specified by the user. The DtSimComponent::tick() function does not do anything. Derived components implement the tick() function in various ways, depending on their purpose. Controller classes can implement the tick() function to generate new control inputs each frame. Actuator components use the tick() function to update the entity’s state. A component’s tick() function is called by the DtSimComponentManager.
Sensor components model the sensing of the simulated environment. The information from sensors is often 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 components, i.e. derived from DtSimComponent. The DtObjectSensor (objectSensor.h) is the base class for all sensors. The DtSignatureObjectSensor (signatureObjectSensor.h) class is used to detect all objects that have a signature configured. The DtRadarObjectSensor (radarObjectSensor.h) is a special object sensor that also acts as an emitter.The use of sensors is optional.
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 (controllerComponent.h) or a subclass. Controllers that receive and implement tasks should derive from DtTaskControllerComponent (taskControllerComponent.h), because this class provides some basic task management that all of these types of controllers must perform. Each DtControllerComponent has a DtSimRadio (simRadio.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 (actuatorComponent.h) has a DtSimRadio (simRadio.h) for sending and receiving messages.