What's a sensor "action"?

[jmbarr]

For the operation of a sensor manager, we are thinking that SensorManager.choose_actions() should return a dictionary of the form {Sensor: [Action]} where Sensor is a sensor object and [Action] a (list of) action(s). (This list would in most cases consist of a single action, but there may be instances where sensors can execute multiple actions per timestep.) This binds a particular sensor and action in the sensor management logic making it much more difficult to misassign actions when going through the combinatorics.

The question/issue is, what form should Action take? It's likely something akin to resetting the internal state of a sensor immediately prior to making a measurement so should probably be undertaken by the sensor itself. Could we allow Sensor = Sensor[Action], or Sensor.take_action(Action), or something? (Sensor = Action(Sensor)?)

[jmbarr]

#326

[sdhiscocks]

In terms of actions, some standard ones we could start with: measure this track; and search this area.

I think the problem will also be working out how each sensor describes what actions it can do, in particular constraints, like what areas that it can search or measure tracks. For a stationary sensor these could be fixed, but for a mobile sensor, these may be time bounded.

I think Sensor.take_actions(actions) would be best approach, working on the idea that a sensor could take multiple actions. But initial examples of single actions is probably a good start.

[svidal-dstl]

On the topic of actions, there's quite an extensive list of SAPIENT taskings defined in the ICD. They are as follows:

• Request registration
• Request reset
• Request heartbeat
• Request stop/start (detections and alerts)
• Request take snapshot
• Request start/stop/play video
• Request follow track/look at
• Set detection threshold high/low/medium
• Set detection report rate high/low/medium
• Set mode default/follow

The sensor will respond to the SensorTask XML message with a SensorTaskACK response, either accepting or rejecting the action. The schema also outlines an optional "reason" for it's acceptance/rejection of a task.

A limitation is that SAPIENT sensors don't have an option to respond to a tasking, such as a LookAt, saying "Yes, I'm now looking at X". I believe the data agent/tasker would have to wait for a heartbeat message for confirmation in this example. A SAPIENT sensor's coverage is reported back as a field of view in either range/bearing or a location list.

[sdhiscocks]

Thanks @svidal-dstl.

• Request stop/start (detections and alerts)

This is interesting, as can see the use case where some sensors may be "expensive" to use, or maybe interfere with other sensors.

• Request follow track/look at

Yeah, I think this is the minimum we should look at for first iteration.

• Set detection threshold high/low/medium
• Set detection report rate high/low/medium
• Set mode default/follow

And these are other good actions worth looking at in future.

The sensor will respond to the SensorTask XML message with a SensorTaskACK response, either accepting or rejecting the action. The schema also outlines an optional "reason" for it's acceptance/rejection of a task.

Hadn't considered sensor responding rejecting tasking. I guess there's different approaches to responsd e.g. just accept it, or maybe consider other options.

[svidal-dstl]

Worth noting that SAPIENT-compliant sensors can report obscurations (one or more) as part of the heartbeat message. The ICD defines this as a region beyond a static obstacle so moving obstacle aren't supported, at least not yet. As per FOV, the obscurations are reported as range/bearing cones or location lists.

I guess a good example of this would be if a vehicle parked up and partially obscured a sensor's FOV. After some time it can be classified as an obscuration.