SensorManager proposal

[jmbarr]

v0.1 of a proposed sensor manager class. Hopefully my hack-UML makes sense. Briefly, the new class encompasses a method which takes a set of possible sensor actions (actionset), a measurement model per sensor (perhaps derived from a sensor object, perhaps held internally), a set of state predictions (which reflect the sensor manager's view of the world), and an optimiser. This optimiser is a functional class which the sensor manager uses to return the chosen action. It requires a measure to optimise over (in future maybe more than one).

An example of an optimiser might be a brute-force search, a measure could be estimated distance to target. A sensor manager combining these will query every track and observe the one estimated to be closest. Not a brilliant way of doing things, but an example.

Red stars indicate classes or methods that don't yet exist.

Comments; queries?

[apiszcz]

Thought, consider adaptive methods for sensor control to optimize power levels/clutter level, etc. Assume this may be possible in the optimiser.

[jmbarr]

Thought, consider adaptive methods for sensor control to optimize power levels/clutter level, etc. Assume this may be possible in the optimiser.

Yes, I think the optimiser should be able to do constrained optimisation (or optimization if you like). How exactly it does that is up for grabs. I'll try and create a class that solves some canonical problem and post for comment.

[sdhiscocks]

I think it would be good to replace StatePrediction with Track, as then you'll have access to the entire track history, and track meta data. I can imagine use cases where this would be useful.

[jmbarr]

I think it would be good to replace StatePrediction with Track, as then you'll have access to the entire track history, and track meta data. I can imagine use cases where this would be useful.

Of course you still need to make a prediction. So Track would have to come with Predictor, which would give you a StatePrediction.

[jmbarr]

I think it would be good to replace StatePrediction with Track, as then you'll have access to the entire track history, and track meta data. I can imagine use cases where this would be useful.

Of course you still need to make a prediction. So Track would have to come with Predictor, which would give you a StatePrediction.

Updated figure dispenses with Measure because I don't think the Optimiser needs it.

[apiszcz]

Curious if there is any update on this topic?

[nperree-dstl]

Here is a link to the current draft of a sensor management tutorial using components from Stone Soup - any feedback welcome! https://gist.github.com/nperree-dstl/28caf233dc9dd8e84eb4b88b3b77d0f2

[jmbarr]

Branch created: https://github.com/dstl/Stone-Soup/tree/sensor_manager

[nperree-dstl]

There is now a pull request submitted for the first sensor management tutorial (#411). Not much has changed from the Gist linked above but it would be great if someone with sensor management knowledge could take a look at it?

[nperree-dstl]

There is now a pull request submitted for the first sensor management tutorial (#411). Not much has changed from the Gist linked above but it would be great if someone with sensor management knowledge could take a look at it?

Some updates have been made to the second sensor management tutorial in this pull request, "Multiple Sensor Management". The development of the sensor management classes built in the tutorial are contributing to how we are structuring sensor management classes in Stone Soup so any further feedback from anyone would be useful.

[mharris-dstl]

Addressed in 503.