Detecting Objects with Sensors

Table of Contents

• DtObjectSensor
• DtSignatureObjectSensor
• DtRadarObjectSensor

This is a general description of the process the DtObjectSensor and its derived sensor classes go through when trying to detect an object.

DtObjectSensor

The DtObjectSensor is the base class for all the sensors in VR-Forces. It detects things purely on whether the object is within its sensor geometry (DtSpatialFilterEvaluator).

The process of detecting other entities begins in the sensor's tick function.

1. The sensor updates its list of object types to detect. It checks its DtObjectSensor::myObjectsToDetectInputPort to see if the type of objects it should be detecting has changed. Other components use this port to let the sensor know they are interested in detection of particular object types. The target selection controller is one of the components that passes this data to the sensor.
2. The sensor checks the status of previously detected objects. Once the list of detectable types is updated, it calls processObjects. processObjects calls continueDetectingObject, which checks to see if objects that were detected in the last tick are still detected. If an object is still detected, it updates its information. If it is no longer detected, it is removed from the list.

3. The sensor checks for new objects. It calls detectObject, which iterates through a list of all the objects in the simulation that meet the sensor's detection criteria to determine if there are any new detections.

   Both continueDetectingObject and detectObject follow a similar process. They check to see if the object is destroyed and whether this sensor detects destroyed objects or not. Then they call objectWithinSensorGeometry, which checks to see if the object falls within the sensor's geometry. If it does, a DtRwSensorContactInfo is created for newly detected objects or updated for previously detected objects.

4. The contact information is added to DtObjectSensor::myDetectedObjectsListPort.
5. Once all of the objects that might be detectable have been checked, DtObjectSensor::updateDetectedObjectsListPort is called to pass the detected objects' information to other components that are connected to this output port. This is usually a DtContactFusionController that will merge all the contacts from the various sensor sources into one combined list in the entity's state repository

DtSignatureObjectSensor

The DtSignatureObjectSensor is derived from the DtObjectSensor. It adds more constraints on the detection of objects. The object does not just have to be in the sensor geometry. The object has an associated absolute signature for each sensor domain.

This represents how much this object radiates in a particular domain. A hot engine on a car would produce a high absolute signature in the infra-red domain, but not necessarily in the visual domain. The physical world that comes between the object and the sensor affects how the sensor perceives the signature of the object, producing an apparent signature. The physical world can degrade the sensor's perception in many ways, such as range, time of day, visibility and so forth.

This class takes into account effects from the object's state (how it affects its absolute signature) and from the physical world (how the physical world affects how the sensor sees the object). Both detectObject and continueDetectingObject have been overridden the same way:

1. They call up to the base class versions for quick sensor geometry exclusion checks described previously.
2. Next they call apparentSignature which creates a DtSignaturePropagatorArgs to be passed to the DtPhysicalWorld's DtSignatureSensorManager's apparentObjectSignature. This passes the information known about the object and the sensor trying to detect the object, to the physical world so it can determine how the absolute signature of the object is degraded. The sensor manager has a list of DtSignaturePropagator instances. It queries the object for its absolute signature, which could change (think of an object turning off its engines). It finds the propagator that is appropriate for the sensor domain passed in. It then passes the absolute signature of the object and the propagator arguments into the propagator's calculateApparentSignature.

Currently there are two types of propagators:

• DtSignaturePropagator checks for line of sight if specified in its descriptor (configured in the physicalWorldParams.mtl file) and degrades the apparent signature based on the range of the object from the sensor. This is used by the sonar, radar, and infra-red domains.
• DtVisualSignaturePropagator is derived from DtSignaturePropagator. This propagator takes into consideration visibility reduction, such as time of day or weather conditions. It queries the DtEnvironmentalStateManager for the current visibility conditions which can further reduce the apparent signature. This propagator also checks to see if line of sight is blocked by any smoke clouds that come between the object and the sensor. Only the visual domain currently uses this propagator.

The figure below shows the detection process of the signature sensor.

Sensor Process

DtRadarObjectSensor

The DtRadarObjectSensor is dervied from the DtSignatureObjectSensor. It is very similar to its parent class except that it allows the user to have an emitter system attached to the sensor that can be turned on or off. It doesn't have its own propagator. It uses the default DtSignaturePropagator. So it detects objects strictly based on line of sight and range. To make it detect more realistically, derive a radar propagator to handle changing object cross sections or material characteristics effects.