OpenSimulationInterface
Update osi_occupant.proto
Added initial definition for (physiological) occupant state.
Goal: Provide the means for enabling a basic form of driver modeling within a simulation framework.
I tend to agree with P. Mai. Little side notice is either there is a field EyesState and not EyeState which covers boths eyes or there is an LeftEyeState and RightEyeState. The naming convention is confusing.
Is there a reason that the new attributes are part of a state message, whereas e.g. the steering wheel interaction is not? Wouldn't it make more sense to keep the new attributes as part of the occupant message directly?
The use of repeated for left and right eye entries seems a bit problematic (what if an occupant only has one eye, i.e. the right eye?). It seems to me that those should just be seperate left_ and right_ fields… and should be at the top-level, i.e. there should be separate left_eye_state and right_eye_state fields, with the option that each eye has not been detected/is not present/….
Use occupant xxx instead of occupant's/occupants wording.
The reasoning behind a separate state message is to differentiate between HMI (steering wheel, pedals, etc.) and physiological state (head pose, gaze, heartbeat, etc.). Should be discussed.
I concur with all your further comments and will adjust the change accordingly.
I tend to agree with P. Mai. Little side notice is either there is a field EyesState and not EyeState which covers boths eyes or there is an LeftEyeState and RightEyeState. The naming convention is confusing.
THanks for the side note; I will incorporate this as well.
@FlorianBadeBMW please also have a look at the build details. It will tell you about missing documentation or problems with the style guidelines.
@FlorianBadeBMW please also have a look at the build details. It will tell you about missing documentation or problems with the style guidelines.
@CarloVanDriestenBMW : I fixed the missing doc and will incorporate the changes proposed above next.
@MartinBuchnerBMW LGTM
Can you give me a feedback if the head_pose in the Detected Moving Object is insufficiently defined and it should be done accoring to your proposal? [Link](optional Orientation3d osi3::DetectedMovingObject::CandidateMovingObject::head_pose = 4)
@pmai I will wait for your approval before we merge.
@MartinBuchnerBMW I just relaized after reading a comment from @ppannusch that this should be part of the DetectedOccupant because it is in fact something that has to be modelled first.
I must admit that the DetectedOccupant looks wired.... I guess we have to think about the "how does what model" here again and make a picture of the involved parties and needed interfaces
Look at the osi_detectedobject.proto for the head_pose signal. I think it is necessary to harmonize these definitions and not have two competing ones. This description does have an explanatory reference which is currently missing in the osi_occupant.
// Pedestrian head pose for behavior prediction. Describes the head // orientation w.r.t. the host vehicle orientation. // The x-axis of the right-handed head frame is pointing along the // pedestrian's straight ahead viewing direction and the z-axis is // pointing upwards (cranial direction [1] i.e. to pedestrian's skull // cap). // //
View_normal_base_coord_system = // Inverse_Rotation(#head_pose)*Unit_vector_x// // \note This field is mandatory if the \c CandidateMovingObject.type is // \c MovingObject::TYPE_PEDESTRIAN // // \par References: // - [1] https://en.wikipedia.org/wiki/Anatomical_terms_of_location // optional Orientation3d head_pose = 4;
The message EyeState is also missing a proper reference. Why is it defined like this? Any publications or normative paper to link here?
Look at the osi_detectedobject.proto for the head_pose signal. I think it is necessary to harmonize these definitions and not have two competing ones. This description does have an explanatory reference which is currently missing in the osi_occupant.
// Pedestrian head pose for behavior prediction. Describes the head // orientation w.r.t. the host vehicle orientation. // The x-axis of the right-handed head frame is pointing along the // pedestrian's straight ahead viewing direction and the z-axis is // pointing upwards (cranial direction [1] i.e. to pedestrian's skull // cap). // //
View_normal_base_coord_system = // Inverse_Rotation(#head_pose)*Unit_vector_x// // \note This field is mandatory if the \c CandidateMovingObject.type is // \c MovingObject::TYPE_PEDESTRIAN // // \par References: // - [1] https://en.wikipedia.org/wiki/Anatomical_terms_of_location // optional Orientation3d head_pose = 4;
We should definitely synch the definitions. Two additional points here:
- For the occupant, we need a clearly defined head position in addition to the orientation.
- The orientation axes still have to be defined (i.e. the relevant anatomical intersections, which are missing from the above description as well as from the Wikipedia article).
@FlorianBadeBMW after reviewing the EyeState message I noticed that the definition might not be sufficient for simulations. Some basic problems are there is no base line anatomy definition. For example there is no distance between the two eyes. This is kind of a covered by the position of the eyes, but this is not saying what is the reference point in the car or otherwise to witch are the eyes positions calculated.
https://www.sciencedirect.com/science/article/pii/S0042698915003508
The question is if there must be a definition of the complete horopter system for the human. This differs from the wiki definitions quite a bit, and it need a lot of details.
Difference in FOV
The question is if we need to parameterize the FOV for humans. Then the EyeState openning parameter is not enough.
My suggestion would be to replace EyeState openning, with a FOV of each eye vertical and horizontal angle.
The next question is there a plan to simulate near and far vision? Since many people have this condition and do not wear lenses or glasses.
Hello together, is anyone of this lively discussion here still interested in finding a solution? I agree with you that the way humans (pedestrians and occupants) are modelled in OSI should be reworked. I have already had some discussion on this topic and have a few ideas about it. So I would be very interested in further discussion about potential usecases and first like to answer the question what information about humans shall be available in the GroundTruth (i.e. input to sensormodels) and what shall be on the output side (so the detected information in SensorData). Also a usecase where pedestrian/occupant behavior is modelled would be very interesting, especially with the model type Traffic Participant which will be introduced in the upcoming V3.3 release. @mbencik @FlorianBadeBMW @MartinBuchnerBMW @jdsika
@clemenshabedank, we (Ansys) have some use case on this topic. Count me in for further discussions.
I am planning a discussion at the meeting on Thursday this week. Anybody who is interested and doesnt have the invitation, please let me know.