Add detailed pedestrian description to MovingObject

[Peintnerer]

Add a description

Related to WP12 in other models workgroup. For exchanging motion capture data of pedestrians (or humans in general) between simulators, we need a more detailed description of pedestrians. This is based on similar skeleton structures used for character rigging in CARLA, Unity, Unreal, etc.

Take this checklist as orientation for yourself, if this PR is ready for the Change Control Board:

• [x] My suggestion follows the style and contributors guidelines.
• [x] I have taken care about the message documentation and the fields and enums documentation.
• [x] I have done the DCO signoff.
• [ ] My changes generate no errors when passing CI tests.
• [x] I have successfully implemented and tested my fix/feature locally.
• [ ] Appropriate reviewer(s) are assigned.

[jdsika]

I might have some feedback here. I will get back here!

[jdsika]

Is this superseding #305 ?

[ClemensLinnhoff]

This might be relevant. Did you consider their definitions on skeletal joint positions?

[adrianschultz]

https://www.asam.net/static_downloads/ASAM_OpenSCENARIO_V1.2.0_Model_Documentation/modelDocumentation/content/AnimationAction.html

and

https://www.asam.net/index.php?eID=dumpFile&t=f&f=4908&token=ae9d9b44ab9257e817072a653b5d5e98ee0babf8#_appearance

might be helping

[ThomasNaderBMW]

15.05.WG ASAM OSI | Other Models | Focus: Enhanced Pedestrian Modeling:

• Enum instead of string for skeleton joints
• Level of detail: Approach is that just the joints are used that are sent (can be identified by the enum). Rule from root till depeest skeleton point (regarding the tree) all skeleton joints must be sent, so complete chain till that point.
• Will it be part of osi_detectedobject.proto? Depending on that we have to think about if it is vehicle_attributes or vehicle_classification (used in detectedobject)
• Skeleton Data is enough and can be used in pedestrian_attributes/classification. Pedestrian Data not necessary.
• Pedestrian_attributes is preferred.

[tbleher]

Two comments regarding the current patch-set:

• It seems like the new PedestrianAttributes message is not yet referenced anywhere, so currently no pedestrian can be described using this new message. I think it should be added at least to MovingObject, so that the values can be returned from TrafficUpdate (which contains MovingObject), and so that the attributes are part of the GroundTruth.
• It would be great to have also have some more coarse-grained values, like the current viewing direction.

I want to elaborate a bit on the second point: The current proposal seems suited for transfering the actual movement of a pedestrian between different systems. However, not all models work with this level of detail. E.g. the open source OSIPedestrian model, which was created as part of the SETLevel project, only works on the bounding box level. 3D animation is done afterwards, e.g. using Unreal. This works fine in practice. However, currently the OSIPedestrian model cannot provide semantic information, e.g. where the pedestrian is currently looking at. This information has to come from OSIPedestrian, since it depends on the situation (example: if the pedestrian is waiting to cross a busy street, it has to look left and right. This semantic info should be provided by the model, and not later be added e.g. in Unreal). However, OSIPedestrian does not do complete animation, since that means it would have to add the whole logic for pedestrian animation inside the model (which is much better done afterwards in Unreal or Unity). The current patch doesn't really allow a model like OSIPedestrian to add a simple info like e.g. the head direction, without knowing the rest of the geometry of the pedestrian. I propose to add this semantic information separately (and am willing to submit a patch for this).

Comments/Objections?

[LudwigFriedmann]

Hi Jakob, just some thoughts:

• As basis for the enum "Type", the following declarative nomenclature may be used:

  

• "SkeletonPoint"s should be renamed to "Bone"s. In the corresponding documentation, it should be clarified that position/orientation of the bone end closer to the semantic origin of the hiearchical bone structure is specified. Further, a float parameter "length" should be introduced in order to cope with potential offsets.

• A reference coordinate frame should be specified, which is defined relative to the geometric center of the bounding box of the undeflected model (e.g. "bbcenter_to_root"). The x-axis of this coordinate frame should be perpendicular to the bounding box front face, pointing forwards. The z-axis should be perpendicular to the x-axis, pointing upwards. Finally, the y-axis should complete the right-handed coordinate frame. It should be clarified that all bone positions/orientations are specified relative to this coordinate frame.

• The "height" parameter is redundant and should be removed.

• Completeness of the bones should not be mandatory. While there shouldn't be gaps/holes in the bone hierarchy, the hierarchy may end early, i.e. not specifying a limb to its full extent.

• In order to explicitly specify missing limbs, a binary flag "missing" could be introduced for every SkeletonPoint/Bone.

• Parameters "side" and "number" could be removed. Instead, the full set of bones should be enlisted in the "Type" enum.

• Introduction of abstract states, e.g. walking, waving, etc. should be postponed. Instead, harmonization with ISO 23150 states should be considered for future releases.

Best regards, Ludwig

Edit: As stated above by @tbleher, it looks like the PedestrianAttributes Message is not yet referenced anywhere. Ít should be added to the MovingObject, obviously.

[ThomasNaderBMW]

WG Other Models:

• Fix Build Errors
• Add Hirarchy-Picture
• Can be reviewed by CCB.

[ThomasNaderBMW]

CCB Review, 19.06.23: Can be merged, but minor stuff (Comments, DCO, correct Builds) has to be fixed till Thursday 9 AM