Add head and eye position signals for driver

[erikbosch]

This PR introduces signals like Vehicle.Driver.HeadPosition.X and Vehicle.Driver.MidEyeGaze.Azimuth. They can be useful in driver monitoring system to detect what the driver is looking at, and/or to monitor that the driver seems to be alert and do not seems to be at risk at falling asleep.

I would welcome other active members of the VSS-project to review the PR and check if the definitions makes sense from your perspective.

[erikbosch]

MoM:

• Erik presented the PR
• Pierre Pierre: We are interested, will check with internal subject matter experts
• Please review

[erikbosch]

Note - to be reopened - upstream repo deleted by mistake

[erikbosch]

MoM:

• Pierre Pierre - no update yet
• Adnan: Check if interest, looks promising
• Continue discussion next week

[adobekan]

@erikbosch What if we add this feature for all passengers? As well are we talking about nominal position e.g. of the eyes?

[erikbosch]

@adobekan - we could add this for "seat" instead so you could use it for all seats/persons if you think that might be useful in the future.

I am not sure if I fully understand what you mean with nominal position. I try to specify what is meant with mid-eye position, but do not say how the vehicle shall calculate it, except for the one-eyed pirate use-case where it shall be calculated as if both eyes would be present. Also in other cases regardless of whether the eyes are visible or not the vehicle could "guess" where they eyes are based on position of ears and nose, for instance. A typical use-case could be if the driver uses sun-glasses

[chrizmc]

I would also do it from a data model perspective for each passenger, and thus hang it under seats because it is not driver specific concept

[adobekan]

@adobekan - we could add this for "seat" instead so you could use it for all seats/persons if you think that might be useful in the future.

I am not sure if I fully understand what you mean with nominal position. I try to specify what is meant with mid-eye position, but do not say how the vehicle shall calculate it, except for the one-eyed pirate use-case where it shall be calculated as if both eyes would be present. Also in other cases regardless of whether the eyes are visible or not the vehicle could "guess" where they eyes are based on position of ears and nose, for instance. A typical use-case could be if the driver uses sun-glasses

That would be good i think to model on seat level. When it comes position i was just thinking do we have to say what type of position we are modeling, actual, relative, absolute, nominal etc. Or for now it is fine if we just say x,y,z

[erikbosch]

That would be good i think to model on seat level. When it comes position i was just thinking do we have to say what type of position we are modeling, actual, relative, absolute, nominal etc. Or for now it is fine if we just say x,y,z

Ah, the PR uses this reference for x/y/z (x example below)

mid eye position on X-axis of the vehicle rear-axle coordinate system as defined by ISO 23150:2023 section 3.7.12

[erikbosch]

PR updated after comments that it would be good to have data on all seats (for all occupants). This has been done by:

• Reusing the existing Occupant branch, i.e. signals after expansion will be like Vehicle.Cabin.Seat.Row2.PassengerSide.Occupant.HeadPosition.Yaw. (An alternative approach would be to use a brand new branch, like Vehicle.Occupant.Row2.PassengerSide.HeadPosition.Yaw
• At the same time deprecating Identifier branch for Driver as you anyway can get that from seat. Does anyone by the way use those identifiers

[ppb2020]

I had an initial discussion internally this morning. It will lead to more discussion, but the initial feedback is that, given the signals are based on ISO recommendations, they should be fine as they are ISO-based. Nonetheless, I plan to have further conversations on this specific PR and hopefully report next week. We will still want to have further discussions on the broader topic.

[erikbosch]

Something I think we should discuss - do we want occupant data to remain with Cabin/Seats? That gives quite long paths, and theoretically a single seat may serve multiple passengers. The last commit introduces an idea to instead use paths like:

Vehicle.Occupant.Row2.PassengerSide.MidEyeGaze.Azimuth

... instead of ...

Vehicle.Cabin.Seat.Row2.PassengerSide.Occupant.MidEyeGaze.Azimuth

I would like to get feedback if that is something we want.

[erikbosch]

MoM:

From Daniel:

Seat.Occupant

or

Occupant.SeatenOn

?

Instead of that, you model SeatOccupancy that has pointers to the seat and the person

• Continue discussion
• After AMM agree on how to proceed short-term and long-term

[ppb2020]

I have further feedback from subject matter experts. They have no additional recommendations or concerns regarding the head and gaze positions as defined, given they reference an ISO standard.

The information carried by these signals can indeed be used as input to various models analyzing the driver (or passenger) behaviour. In their opinion, this is more useful than providing signals that report the results of such an analysis, given the expected differences between various models, leading to interpretation issues (as we discussed in PR#659, on driver fatigue level).

[ppb2020]

Of possible relevance here (for driver gaze, for example) is this EURO NCAP specification, especially section 3.5.3.1.1 on movement type and gaze location. Of particular interest is the following description in section 3.5.3.1:

Owl (head movement), Lizard (eye movement) and body lean looking behaviours are used to assess detection of driver distraction in three main area

[erikbosch]

MoM:

• Add a comment that this can be used to Euro NCAP evaluation
• Merge decision week next

[erikbosch]

MoM:

• OK to merge when suggested change fixed