Adding clutter to measurements from Sensor objects

[ekhunter123]

The Sensor/Platform paradigm is very intuitive and useful. I think it would be nice if there was a way to add clutter to the measurements to make it more realistic. I had 2 initial ideas about how to implement this:

1. Create an object that would inherit from the Sensor class. This object (which I'm calling a clutter sensor for lack of a better word) could be mounted onto a platform and would return randomly generated measurements according to a specified distribution. This is what I describe in Issue Proposal to add a platform-mountable clutter sensor/simulator #478.

2. The problem with 1) is that each sensor on a platform is called separately. At each time step, the filter gets detections from the first sensor and does an update, then gets detections from a second sensor and does an update. But what we want here is not a separate sensor for the clutter, but rather we want the original Sensor object to pick up measurements from birds or waves etc. A way around this is to alter the object described in 1) so that it gets passed into a Sensor object (ie a RadarBearingRange). Then whenever the radar is called for measurements it does the usual measurement based on the ground truth, but also calls a measure() function from its clutter sensor.

In a discussion during a Stone Soup user conference, other people came up with 2 more ideas of possible implementations:

3. Create a ClutterModel that would be passed into a Sensor object. The ClutterModel would be a subclass of Model, and would generate random clutter measurements. (If I remember correctly this was suggested by @sglvladi)

4. Create an object whose "ground truth" is just random Clutter. In practice you would have the regular target object with a defined ground truth, as well as this clutter object. At each time step, the set of detections consists of the simulated detections from the target object as well as the random detections from the clutter object. (I believe this was suggested by @jmbarr)

Does anyone have thoughts about which of these makes the most sense? Thanks!

[sdhiscocks]

So I think the clutter model should be part of the sensor, as per 3.. It may be that for some sensors, this clutter with be integrated as part of the sensor, due to close linking of how the sensor works. And in other cases, simpler models could just be passed a clutter model of your choosing.

[LyceanEM]

The problem with clutter generation is it is both sensor type and environment specific. I like the Stone Soup framework, and within that clutter would seem naturally part of the sensor object. However, clutter source is not a trivial definition. Maritime environment sea state clutter for radar is sea state, temperature and frequency of operation dependant for radar, but this might be an easier inclusion than land clutter.

[jmbarr]

The problem with clutter generation is it is both sensor type and environment specific. I like the Stone Soup framework, and within that clutter would seem naturally part of the sensor object. However, clutter source is not a trivial definition. Maritime environment sea state clutter for radar is sea state, temperature and frequency of operation dependant for radar, but this might be an easier inclusion than land clutter.

Agree, and that's what motivated @ekhunter123 item 3 above. Passing a clutter model to the sensor as a separate object allows for refinement or replacement of that clutter model without necessarily having to re-engineer the sensor.

Of course careful consideration of which parameters are required to model clutter and how these are passed to the sensor is required (will the sensor now need to accept T as an input where previously it didn't?, etc.) We got as far as agreeing it was a good idea, rather than starting on a design. As with these things I think someone needs to build one to see how it works ;-)

[ekhunter123]

Update: For anyone looking to do this, there is now a ClutterModel which you can attach to some of the radar classes. Here is the original pull request, which has been merged.

[apiszcz]

+1