Allow list for refers_to rule

[thomassedlmayer]

So far it was only possible to refer to a single explicit type like this:

 refers_to: DetectedMovingObject

This change allows to check against a rule syntax using a square bracket list as defined in OpenSimulationInterface/open-simulation-interface#879:

 refers_to: [DetectedMovingObject, DetectedStationaryObject]

Rule semantics: To satisfy the rule, one of list's entry has to match the actual type of the object that the Identifier's id refers to.

Related:
OpenSimulationInterface/open-simulation-interface#876

[thomassedlmayer]

Just after finalizing this and testing around with it a bit, I noticed that it's not so clear which id we actually want to refer to. The definition of the tracking_id says:

Specific ID of the detected item as assigned by the sensor internally

Sensor-internal ids do not need to be globally unique, so it probably is not intended to store these in the message_id_map. Though, referring to the ground_truth_id also does not make much sense as we want to reference detected objects and not their ground truth counterpart. Should we store sensor-internal ids separately?

[TimmRuppert]

Should we store sensor-internal ids separately?

It seems like we need to, right? Also there could be multiple sensordata/featuredata so they would needed to be stored per sensor (or replaced).

[thomassedlmayer]

Yes, you would even have to consider the sensor ids then. Also, it would add some overhead on the rule checking. E.g. we might need to check for certain hard-coded object type names because otherwise we don't know where to look for the id (from the rule's perspective).

[TimmRuppert]

Yes, you would even have to consider the sensor ids then.

Which could be broken/missing as well.

Just after finalizing this and testing around with it a bit, I noticed that it's not so clear which id we actually want to refer to. The definition of the tracking_id says:

Specific ID of the detected item as assigned by the sensor internally

I just thought about this a bit more. For me it seems like tracking_id is not relevant at all. Our rules refer to Detected*Object. All detected objects are a direct member of the SensorData and thus not part of any internal sensor object tracking nor of the global ground truth. The later contains MovingObject but not the DetectedMovingObject. Or am I missing something?

[thomassedlmayer]

That threw me off too. Aren't both existing ids just references instead of actual identifiers?

I mean for me it generally seems fine per se to reference a sensor that contributed to the object data and provide the corresponding sensor-internal ids then. But in DetectedItemHeader you can only define a single tracking id. The tracking id would have to be repeated and somehow be mappable to a specific sensor id if it is actually supposed to represent a sensor-internal id at the physical sensor level. But since the tracking id is not repeated (and even then couldn't be inherently mapped to a specific sensor id) it seems to me that if you do sensor fusion, you need to drop historical sensor-internal ids and set a new tracking id. But this contradicts its definition of being sensor-internal. I mean, the SensorData itself also has a sensor id so we could just expand the interpretation of "sensor-internal". Nevertheless it seems that that the current design only allows multiple sensors if they're all using the same internal tracking ids for the same objects.

[TimmRuppert]

Ah, I see. I also misunderstood this at first - I think your interpretation is mostly correct!

Aren't both existing ids just references instead of actual identifiers?

From my updated understanding, SensorData.FeatureData.Radar/Lidar/...Detection.DetectedItemHeader.object_id points to one of the SensorData.Detected*Object.tracking_id.
So the tracking_id is determined (based on internal logic), while the object_id simply references that value.

But this contradicts its definition of being sensor-internal.

In OSI, a "sensor" doesn’t necessarily mean just one physical measurement device, right?. It could also represent a component that fuses data from multiple sensors. From the OSI documentation:

Logical model
Logical models consume SensorData messages and produce SensorData messages.
Examples: Sensor-fusion model: Combines the output of multiple sensor models to produce data with less uncertainty.

This implies the following:

Scenario A: Single-sensor output

• Assume a single radar sensor model which provides both feature data and detected objects.
• The tracker inside this sensor model assigns a tracking_id.
• The sensor model then uses this tracking_id as the object_id for each radar detection (feature data).

Scenario B: Multi-sensor fusion output

• Assume two radar sensor models provide feature data and detected objects, which are fused into a single SensorData message (e.g., via one FMU doing all of that).
• In this case, the fusion component acts as the tracker, assigning its own tracking_id.
• Each (maybe individual) sensor model must then use this fused tracking_id as the object_id for its detections (or the tracker must update already set detections).
• If the individual sensors perform their own internal tracking prior to any fusion, those local IDs are discarded and not represented in the final fused OSI output.

[thomassedlmayer]

You're right. I confused "sensor" (used in tracking_id) and "physical sensor" (used in sensor_id) and forgot that OSI describes everything as a sensor even though it might be other kinds of models.

In summary, the tracking ids are simply expected to be unique across all objects that contain the DetectedItemHeader in a SensorData output, right?

I'll have a look at the implementation again and see how we can store the tracking ids separately.

[TimmRuppert]

In summary, the tracking ids are simply expected to be unique across all objects that contain the DetectedItemHeader in a SensorData output, right?

Yes. tracking_id is just of type Identifier which states:

Has to be unique among all simulated items at any given time. [...] Sensor specific tracking IDs have no restrictions and should behave according to the sensor specifications.

I also just saw the following in the documentation:

Purely simulation technical IDs, like sensor IDs, are not required to be unique among all simulated items, but rather unique within the context of the given message type.

Is that not a particular issue for the current architecture of qc-osi-trace? Would that not require to store IDs generally context-wise (what ever that means)?

[pmai]

That probably mainly means that there should not be a refers_to rule at all on that field, as we more or less state that the semantics are up to the sensor spec, which we do not know anything about in any case. I don't think we should be checking anything here by default, and if we people want to have custom rules, it should be context-specifying rule with a different name.