Extension by HMI-, ADAS- and Dynamic-Values

[ThomasNaderBMW]

Think about a simulation-construct consisting of a human driver, an AD-function and also a dynamic-model.
All these pieces can come from different authors, but should work together.
This is a requirement the driving-simulation-sector has to deal with:

A test person wants to activate an external highly automated driving function in a mock-up. So the function has to listen to the mock-up. The other way around the mock-up has to understand commands from the function (Take-over-request?). So this is an interface that should be standardized.
Furthermore, it is the same with an external dynamic-model. How can this listen to the simulation-environment to get values like the friction of the street needed for dynamic-calculations? And also here, the other way around: The results of the dynamic-model describe the state of a vehicle regarding kinematics. Additionally, calculated values for the engine or the steering can be part of. Both datasets are worth to be standardized.

Dear OSI-Community, please help to enhance the appended .proto-signals.

[ghost]

@ThomasNaderBMW You can access the build log in order to check why it is not building. It is basically missing comments and tabs which have to be replaced with spaces.

[pmai]

Before commenting on specifics on this proposal, it would really help if there was some short overview of the architectural intent, i.e. which models are involved, and which messages do they receive and send. This is also something we should add to the documentation once the PR is merged, since these are very common questions in how to use OSI.

[mohammadbahram]

@ThomasNaderBMW could you please add a short overview of the architectural intent?

[ThomasNaderBMW]

Of course, I made a short overview. Attached is the requested architectural intent:
OSI_Extension_Architectural_Intent.pdf

[ghost]

@CezarySzyszkaAltran do you have time to review this?

• consistent names and messages
• the osi_common_extension has to be integrated in osi_common, what do you think?
• are the names generic enough?
• do we have duplicated information: light states e.g.?
• etc

[CezarySzyszkaAltran]

Main Problem

The OSI is data serialization protocol. I am not sure it is if official but data serialized to string can be only of type SensorData or SensorView. All objects and states described in simulated environment have some place in tree like structure. For example SensorView.global_ground_truth.moving_object[].base.position.x is a place to put x coordinate of a vehicle. The messages here are detached from mentioned tree. This is not acceptable. We need to find a place to attach those information to the.

Maybe creation of osi_egocar.proto would be a good idea. The global_ground_truth can have ego car as as special field. This would be a major change to the standard and I would not recommend it for release 3.1.

Naming

• do not use plural in osi
• separate words with undescore
• state bool variables as clear question

osi_common

This is a collection of types used across many different derived types.

Wheels and VehicleWheels

Those two classes are fragile in design. The issue is explained in-line

[ThomasNaderBMW]

Thanks so far to @ppannusch and @CezarySzyszkaAltran .
You gave a lot and important input!

Alltogether we discussed some different points, at many I don't know what is the best way.
So now and if we want to merge to OSI 3.1 in a few days, I "give the ball" to @CarloVanDriestenBMW and @pmai to make the best out of the suggestions.
Otherwise, so if some time is left in the new year, we can discuss this together.

[ThomasNaderBMW]

So now I corrected a lot after talking to Cezary.
@CezarySzyszkaAltran : Can you do the review again?

[ghost]

Please have a look at the two comments regarding the comment style. Consider creating a branch in the OSI repository instead of using your fork in order for me to make changes directly. Close the PR and open a new branch.

[ghost]

// Angle of the steeringwheel. 
//
// Unit: [rad]
//
// \note angle < 0 := left; angle = 0 := Central(Straight); angle > 0 := right;
//

[ghost]

// Position of the acceleration-pedal.
//
// Unit: [ ]
//
// Range: [0.0, 1.0]
//
// \note 0.0 := unpressed; 1.0 := fully pressed
//

[ghost]

@ThomasNaderBMW when openeing a new PR through a branch could you please summarize quickly which suggestions you already incorporated and what issues are up for discussion? Changes have been made but have not been "resolved officially" which makes the tracking hard.

[ThomasNaderBMW]

I opened a new PR as branch as wished. This one can be closed. Thanks so far to all!

[ghost]

This is consolidated in #309