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.

[ppb2020]

I find this makes a lot of assumptions about occupant position. I am also concerned that it conflates different concepts (occupant and their position) together. That is, it forces a 1:1 match between occupant and their seat position.

I would have expected occupants to be a dynamic list of persons that is independent (instance-wise) from their position. With this approach, each occupant would reference a seat, while seats would reference occupants. Something like:

Vehicle.Occupant:
  type: branch
  instances:
    - Person[1,10]

Vehicle.Occupant.SeatPosition:
  type: reference
  description: A reference to the Occupant's seat position as a node path name (e.g. Vehicle.Cabin.Seat.Row1.Pos1).

Vehicle.OccupantCount:
  datatype: uint8
  type: sensor
  description: The current number of persons in the vehicle.

Seat.Occupant:
  type: reference
  description: A reference to the Occupant as a node path name (e.g., Vehicle.Occupant.Person1).
    

[erikbosch]

I like the idea, but it is something that needs to be discussed. I think it is somewhat aligned with some thoughts presented by Alan Freedman on making instance handling more flexible. Like treating "Row, Pos and Seat-Function (Driver-side, middle, Passenger-side) as labels which you depending on implementation can use to identify an instance. The possibility to support references is also something that has been discussed in the past, for example to support links from truck to trailer.

For references I think it might be relevant to specify the type of the reference, for example to specify that the reference is to a Vehicle.Cabin.Seat but how actual content is represented might depend on implementation. Some may use dot-notated path, others a URL or some other metadata that the client understand.

[ppb2020]

I am still concerned about these kinds of instances. For one, it does not match the current definition of Seat, which has Pos[1,3]. It is not clear to me that we can always define a driver position. For example, if the driver is in the middle of the vehicle, with a passenger on each side of them, what would we use for occupant position? A count such as Pos[1,3] seems better to represent this, and a reference (such as what I propose above) would be even better, I think.

[erikbosch]

It actually match the current seat definition, see https://github.com/COVESA/vehicle_signal_specification/blob/master/spec/Cabin/Cabin.vspec#L145

Seat:
  type: branch
  instances:
    - Row[1,2]
    - ["DriverSide","Middle","PassengerSide"]
  description: All seats.
#include SingleSeat.vspec Seat

The use of Left/Right vs Driver/Passenger-side side was heavily discussed some time ago when we change to Driver/Passenger-side, and it comes up to the surface now and then, like in #718. We have actually some coverage for the specific use-case of a driver in middle-seat in https://github.com/COVESA/vehicle_signal_specification/blob/master/spec/Cabin/Cabin.vspec#L156, then left is considered as driver side.

In my latest commit I just reused the current instance declaration for seats (as well as doors and windows). IMHO having the same type of instances for occupants as for seats sort of make sense

[ppb2020]

End with a period.

[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

[ppb2020]

A few typos.

[erikbosch]

MoM:

• OK to merge when suggested change fixed