Clarification of DetectedMovingObject::percentage_side_lane_left

[CRMemory]

Hi everyone,

the documentation to DetectedMovingObject::percentage_side_lane_left (and ...right) states

open-simulation-interface/osi_detectedobject.proto

Lines 183 to 185 in 7194aaf

	// Percentage value of the object width in the corresponding lane.
	//
	optional double percentage_side_lane_left = 6;

However, in my opinion it is not clear, what lane_left refers to. Multiple definitions are possible:

• The left- and rightmost lanes a vehicle is on
  • the sum of percentage_..._left and percentage_..._right could then be less than 1 (if a vehicle spans multiple lanes)
  • also left and right can be understood relative to the moving direction of the DetectedMovingObject (with a possible ambiguity if it is perpendicular to the lanes) or relative to the direction of the lanes.
• A lane counts as left if its centerline is left of a vehicles center. In this case, multiple lanes may contribute to the total percentage_..._left.

What meaning should be used for filling this property?

[jdsika]

I will investigate - which one do you prefer and why?

[CRMemory]

Hi @jdsika, thanks for your reply.

I don't really have a preference. The meanings I described above are just derived properties which are not necessary for simulating or describing an environment.

If a DetectedMovingObject would have an id of a DetectedLane lane, on which it was detected by sensors, any of the percentages could also easily be calculated at simulation time. Both properties could therefore be omitted / deprecated. But maybe I am missing something.

However, if they are kept, it should be clear what data to expect in them.

[pmai]

@CRMemory it seems to me that this attribute is the sensor's estimation, so we can't eliminate it, since this is actual sensor model output. This should be part of the OSI that is synchronized with the ISO standard for actual sensor output (and it probably was added during the initial synchronization, cf. commit 4b1509d). I'd therefore suggest to relook at current drafts to ensure this definition matches up...

[CRMemory]

Hi @pmai, thanks for your insight. Then perhaps someone who is in touch with the ISO standardization could check which meaning was intended by the standard or whether there is any ambiguity present there.

[jdsika]

@PhRosenberger this should be aligned with #367

[PhRosenberger]

@PhRosenberger this should be aligned with #367

Yes.