osi_vehicle: A deeper description of a vehicle #350

ThomasNaderBMW · 2019-10-23T15:04:03Z

Reference to a related issue in the repository

This is the continuation of Extension by HMI-, ADAS- and Dynamic-Values (Part II) #309.

Add a description

osi_vehicle is a deeper description of a vehicle.
The logic is, that it categorizes the vehicle through different messages. The categories are:
Vehicle-Basics, Vehicle-Kinematics, Vehicle-Powertrain, Vehicle-SteeringWheel, Vehicle-Wheels, Vehicle-Light-State, Vehicle-Automated-Driving-Functions.

As it is an description of the whole vehicle it can be used as interface for various reasons.
Three proof-of-concepts are still running, they use osi_vehicle as interface to

the vehicle-model for kinematics calculation (Driver-Inputs are included in the categories)
the graphic-engine for the visualisation
a real car for measurement reasons.

Some questions to ask:
What is this change?
It is an extension that enables new use-cases for osi and helps to modularize simulation-components.
What does it fix?
Proprietary connections.
Is this a bug fix or a feature? Does it break any existing functionality or force me to update to a new version?
As it is an additionaly .proto-file it hasn't any effect on the rest.
How has it been tested?
In three proof-of-concepts (see above).

Mention a member

@jdsika @pmai @ThomasSchloemicherAVL

and @ALL:
Thanks for the many contributions so far. Go on with that! 👍

0815-code · 2019-10-23T18:45:03Z

Maybe merge with osi_vehicle.proto with osi_hostvehicledata.proto. Personally i like the term HostVehicleData.
Furthermore maybe adding localization info fields plus the method of localization behind. Was the localization method based on pure reading GNSS data or some more advanced localization methods behind such as GNSS-RTK and/or fusing (U)HD-Map info with CV feature extraction etc...

osi_vehicle.proto

move assigned_lane_id into Classification message in MovingObject message (same as for TrafficLights/TrafficSigns) add osi_vehicle.proto to setup.py

0815-code · 2019-12-01T19:50:32Z

osi_vehicle.proto

+    // Unit: [m/s^2]
+    //
+    optional double acceleration = 8;
+


Isnt that redundant information to mention here accleration and velocity again? See VehicleKinematics --> Base Moving

meant is the targeted velocity and acceleration at the planned point.. but I am not sure here

0815-code · 2019-12-01T19:55:46Z

osi_vehicle.proto

+    // Unit: [1/(m*s)]
+    //
+    optional double curvature_change = 6;
+


out of doubles 3, 4, 5, and 6 one can formulate a polyline. us same data type here as for lane boundary polyline (still need to commit these changes, though)

maybe it makes sense to use your polyline-definition? Let's discuss this next time.

0815-code · 2019-12-01T20:03:13Z

osi_vehicle.proto

+            // Range: [0, 1] 
+            //
+            optional double steering_override_factor = 3;
+


Maybe pedal (accelerator and/or brake) override here also?

Values I would say on the "waiting-list". Is there a use-case?

0815-code · 2019-12-01T20:09:18Z

osi_vehicle.proto

+        // Unit: [rad]
+        //
+        optional double camber = 5;
+


Wheel toe for completness?

Is this value in generell important? I think about to delete it.. Otherwise you are right!

at least it is the same like the steering-angle right?

0815-code · 2019-12-01T20:15:34Z

osi_vehicle.proto

+            // Warning by the danger of a collision.
+            //
+            FUNCTION_NAME_LEVEL_0_FORWARD_COLLISION_WARNING = 14;
+        }


Well done, thats a great list. Is it accounted for that some of these funtions can occur in parallel?

localization has some overlap with position and position_rmse in osi_hostvehicledata.proto

ManuelKugelmann

Is is wise to change the field ids of an existing message? This will break backward compatibility ...
Gaps in the list of field ids are not a problem.

ManuelKugelmann · 2019-12-04T09:28:30Z

How will the overlap with MovingObject and HostVehicleData be solved? Duplicate and potentially inconsistent places for data might cause maintenance and compatibility nightmares...

pmai · 2019-12-04T10:41:47Z

Is is wise to change the field ids of an existing message? This will break backward compatibility ...
Gaps in the list of field ids are not a problem.

Since moving the field to the classification is likely to only happen in a major release anyway, the id change is probably immaterial. That said, I think the lane_id stuff should be aligned with ISO 26150 DIS once that is available/forseeable at the same time as the changeover to the classification.

ManuelKugelmann · 2019-12-10T14:44:32Z

osi_vehicle.proto

+    {
+        // The id of the car in the simulation. 
+        //
+        optional Identifier id = 1;


Identifier id is maybe better placed into the root of the VehicleClass message to mirror MovingObject etc..
That it is nested forced me to add some extra code in my framework ...
==> Done. Thanks for the hint.

BTW: what is the reasoning behind the name "VehicleClass" ?
==> VehicleClass is not sent directly, but can be embedded as you can see in the message "Vehicle" or "Traffic"

… request.

It is possible to describe a vehicle with more than 4 wheels. Should also be possible with less than 4, but not tested so far.

ThomasNaderBMW

Is is wise to change the field ids of an existing message? This will break backward compatibility ...
Gaps in the list of field ids are not a problem.

Can you post the hint again in the right PR? The change moved out of this PR. Next time I will tell Thomas, if I remember.

ThomasNaderBMW · 2019-12-04T11:26:21Z

osi_vehicle.proto

+    //
+    message VehicleWheels
+    {
+        // Contains the physical description of the front-left wheel.


yes i know, that is sth that will be discussed. I think this format should have the focus on cars and dont become complicated. But its a good point and a decission has to be made (osi_vehicle or osi_car?) thx

ThomasNaderBMW · 2019-12-04T11:34:19Z

osi_vehicle.proto

+        // Unit: [rad]
+        //
+        optional double camber = 5;
+


Is this value in generell important? I think about to delete it.. Otherwise you are right!

ThomasNaderBMW · 2019-12-04T11:35:55Z

osi_vehicle.proto

+
+        // Contains the tirepressure of each tire.
+        //
+        // Unit: [Pa]


Now I think it is not that important. Interesting is just the pressure to show it in the HMI-Screen I would guess..

ThomasNaderBMW · 2019-12-04T11:36:27Z

osi_vehicle.proto

+
+        // Contains the tirepressure of each tire.
+        //
+        // Unit: [Pa]


To show there is a flat tire e.g.

ThomasNaderBMW · 2020-12-14T10:26:42Z

Topic is integrated in updating hostVehicleData, see here:
#441

Create osi_vehicle.proto

b96a6a0

ThomasNaderBMW added FeatureRequest Proposals which enhance the interface or add additional features. HelpWanted I have tried my best - please help me! labels Oct 23, 2019

ThomasNaderBMW added this to the v3.2.0 milestone Oct 23, 2019

ThomasNaderBMW requested review from pmai, jdsika and 0815-code October 23, 2019 15:04

ThomasNaderBMW self-assigned this Oct 23, 2019

ThomasNaderBMW requested review from LudwigFriedmann and mohammadbahram October 23, 2019 15:05

ThomasNaderBMW added 2 commits October 23, 2019 17:17

Update osi_vehicle.proto

246e206

Update osi_vehicle.proto

1f3f1a8

ThomasNaderBMW changed the title ~~Create osi_vehicle.proto~~ osi_vehicle: A deeper description of a vehicle Oct 23, 2019

jdsika reviewed Oct 24, 2019

View reviewed changes

jdsika and others added 15 commits October 24, 2019 15:02

Merge branch 'master' into Extension_by_osi_vehicle

3893e0d

Update osi_vehicle.proto

0208f9d

Update osi_vehicle.proto

a9b04d0

update localization message in osi_vehicle.proto

0f8bfa4

move assigned_lane_id into Classification message in MovingObject message (same as for TrafficLights/TrafficSigns) add osi_vehicle.proto to setup.py

bugfix tab and add heading to VehicleLocalization message

7947d1f

bugfix tabs osi_vehicle.proto

f07fbe9

Merge branch 'master' into Extension_by_osi_vehicle

37422d5

Update osi_vehicle.proto

1e44521

Using the occupant-definition for hands-on-detection

e8e41f0

Update osi_vehicle.proto

fdde048

Update osi_vehicle.proto

fbf92dd

Update osi_vehicle.proto

53ac45e

Extension of ad-function-definitions

3b05371

Update osi_vehicle.proto

d9c0cd9

Update osi_vehicle.proto

2a14fc5

ThomasNaderBMW added 2 commits November 26, 2019 19:46

under construction

53a23d6

Update osi_vehicle.proto

7a26b8b

0815-code reviewed Dec 1, 2019

View reviewed changes

Merge branch 'master' into Extension_by_osi_vehicle

bd818de

ManuelKugelmann suggested changes Dec 4, 2019

View reviewed changes

Update osi_vehicle.proto

3895bc9

ManuelKugelmann suggested changes Dec 10, 2019

View reviewed changes

ThomasNaderBMW mentioned this pull request Jan 14, 2020

Extension by HMI-, ADAS- and Dynamic-Values (Part II) #309

Closed

0815-code and others added 7 commits January 14, 2020 16:33

Revert osi_vehicle.proto changes. These changes go to a seperate pull…

7c35ba1

… request.

Wheels are repeated now

a06397e

It is possible to describe a vehicle with more than 4 wheels. Should also be possible with less than 4, but not tested so far.

Update osi_vehicle.proto

9400dca

Update osi_vehicle.proto

746a7d0

visible or not

ec8e753

ID now is in the root-level of vehicleClass

9f9d096

Update osi_vehicle.proto

6bdcad1

ThomasNaderBMW commented Jan 16, 2020

View reviewed changes

jdsika modified the milestones: v3.2.0, v4.0.0 Feb 19, 2020

fhirmann mentioned this pull request May 4, 2020

Velocity and acceleration relative to host vehicle coordinate system seems to be missing #387

Closed

kmeids added the TrafficParticipants The group in the ASAM development project working on traffic participants. label Oct 28, 2020

kmeids removed this from the (REMOVE) ASAM OSI x.x.x milestone Oct 28, 2020

ThomasNaderBMW closed this Dec 14, 2020

caspar-ai mentioned this pull request Oct 22, 2021

Add automated driving function state to host vehicle data #589

Merged

6 tasks

osi_vehicle: A deeper description of a vehicle #350

osi_vehicle: A deeper description of a vehicle #350

Uh oh!

Conversation

ThomasNaderBMW commented Oct 23, 2019

Reference to a related issue in the repository

Add a description

Mention a member

Uh oh!

0815-code commented Oct 23, 2019

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ManuelKugelmann left a comment

Choose a reason for hiding this comment

Uh oh!

ManuelKugelmann commented Dec 4, 2019

Uh oh!

pmai commented Dec 4, 2019

Uh oh!

ManuelKugelmann Dec 10, 2019 • edited by ThomasNaderBMW Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ThomasNaderBMW left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ThomasNaderBMW commented Dec 14, 2020

Uh oh!

Uh oh!

ManuelKugelmann Dec 10, 2019 •

edited by ThomasNaderBMW

Loading