Extension by HMI-, ADAS- and Dynamic-Values (Part II) #309
Conversation
Extension of osi_common.
extension by wind_speed and wind_direction.
ThomasNaderBMW
added
FeatureRequest
ThomasNaderBMW
requested review from
pmai,
a user,
mohammadbahram,
ppannusch-bmw and
CezarySzyszkaAltran
osi_common.proto
Outdated
| { | ||
| // Angle of the steeringwheel. | ||
| // | ||
| // Unit in rad: 0=Central (Straight); Left>0; 0>Right. |
There was a problem hiding this comment.
@CarloVanDriestenBMW: Right should be clockwise, if you take a look to the "Einheitskreis" or am I wrong here?
There was a problem hiding this comment.
The ISO 7401 describes tests in degrees. SI would be rad.
==> Open Point
|
|
||
| // Wished states of the driver regarding the function Emergency-Brake-Assistant. | ||
| // | ||
| optional EmergencyBrakeAssistant emergency_brake_assistant = 4; |
There was a problem hiding this comment.
ppannusch on 11 Dec 2018 Member
Way too specific in my opinion. If we start putting in something like this, you can basically argue to put in any system separately that any autonomous vehicle of any manufacturer might have, e.g. CyclistWarningAssistant, SpeedLimitAssistant, ActiveSideCollisionPreventionAssistant and so on. That has to be done in a better way, maybe by some dynamic content that is filled depending on configuration, with a set of possible values that we can define in OSI.
ThomasNaderBMW on 11 Dec 2018 Author Member
That's a good point. The dynamic-way could be a good solution. Sth that has to be discussed also with @CarloVanDriestenBMW and @pmai
There was a problem hiding this comment.
==> Open Point
osi_common.proto
Outdated
|
|
||
| // The actual gear of the car. | ||
| // | ||
| enum Gear |
There was a problem hiding this comment.
ppannusch on 11 Dec 2018 Member
What about M/S? Or is this what you mean by GEAR_MID?
Also the enum mixes up actual gear of the powertrain and the gear lever state. What about shift paddles?
There was a problem hiding this comment.
==> Open Point
osi_driver_inputs.proto
Outdated
| // Hands-On-Detection. | ||
| // 0=HandsOff; 1=HandsOn | ||
| // | ||
| optional bool hands_on_detection = 3; |
There was a problem hiding this comment.
ppannusch on 11 Dec 2018 Member
OSI already has SteeringControl for that, which is even more specific (which it should be)
@ThomasNaderBMW
ThomasNaderBMW on 11 Dec 2018 Author Member
Ou yes, it is part of osi_occupant. Thanks for the hint, this is sth we have to pay attention to.
@ThomasNaderBMW
ThomasNaderBMW on 13 Dec 2018 Author Member
@CarloVanDriestenBMW & @pmai :
In my opinion the definition of SteeringControl should move from osi_occupant to osi_common, so it can be used in osi_driver_inputs also.
// Definition of hands related to the steering wheel (mostly driver).
//
enum SteeringControl
{
// Hands state is unknown (must not be used in ground truth).
//
STEERING_CONTROL_UNKNOWN = 0;
// Other (unspecified but known) hand positioning related to the
// steering wheel.
//
STEERING_CONTROL_OTHER = 1;
// Hands are not on the steering wheel.
//
STEERING_CONTROL_NO_HAND = 2;
// One hand is on the steering wheel. Whether it is the left or right
// hand is unspecified or unknown.
//
// \note If there is no differentiation between one or both hands on the
// steering wheel, this value should be used.
//
STEERING_CONTROL_ONE_HAND = 3;
// Both hands are on the steering wheel.
//
STEERING_CONTROL_BOTH_HANDS = 4;
// Only left hand is on the steering wheel.
//
STEERING_CONTROL_LEFT_HAND = 5;
// Only right hand is on the steering wheel.
//
STEERING_CONTROL_RIGHT_HAND = 6;
}
There was a problem hiding this comment.
==> Open Point
ghost
mentioned this pull request
Marius Reis will go on with these points. |
|
@RobertMengerBMW Well I thing modeling the data so that the detailed status is covered ( camber, toe, rotation ) and that just the generic information can be shown is the way to go. It would give to all the people that are having the need to develop kinematics features possibilities to use the items. |
|
@mbencik about your angles: And I was not clear about what I mean with "center of car". I do not mean, that the wheels should rotate around the center of the car, but as the center of the car is in most software the main anchor, its orientation is the also the zero-orientation for all components of the car. You still need the correct translation to the center of the wheelhub (which results in a transform matrix with the center of the car as origin). But as the upright and wheelhub could be oriented in every direction, its is not suitable as a reference point. Let me explain my background: Im visualizing cars in game engines and professional 3D graphics suites, for real-time driving experience or high end rendering. In the moment I have my own framework to connect a physical simulation like CarMaker to a visualizer like Unity or Cinema 4D. And latter ones are not suited to simulate the mechanics of a complex kinematic system, but CarMaker does and CarMaker (or Adams for example) know the resulting rotation of the wheels and they are relative to the center of the car, as the car is the reference space for every translation and orientation (which is true for game engines and other 3D software as well). I admit, that Im highly focused on connecting a physics-simulation engine to a visualizer, but Im open for suggestions and other requirements, so that we can find the best possible solution for different usecases. |
|
@RobertMengerBMW This makes sense now. But what you need is a derived value from the image below.
The alpha angle gives the relative vector of the front, and this need to be translated to the vehicle orientation, which is applied to the center of the vehicle. Basically the point Sa in the next image.
So the thing would be actually to describe what is the alpha angle representing and how does it impact the model, and the result of the vehicle is the orientation. The question is should that derived value be in OSI or not. The reason it is calculated, and the question is are the calculation changing for each vehicle. The problem with such things is the rules that are to be applied to calculate such values could change, so this would have to be defined (the rules), also the constraints what is possible and what not, or what is considered valid for a modeled car and what is invalid. |
|
@mbencik As already written, you have at least five ball-joints / hinges only on the wheel-side, no to mention the influence of rockers, pushrods, antirollbar and so on (which are at least 8-9 hinges on the car-side). So there are exactly two ways to describe the behaviour of the wheel:
If someone knows a reasonable third way, please tell us. |
|
Given that this PR is now fairly huge, and that it is not always clear which information is intended to travel in which direction (e.g. wheel state itself is likely coming from vehicle model, however friction of the wheel is likely sampled from environment, so it seems unlikely that they belong in the same message), might it make sense to split this PR into smaller parts, that are more easily understood and refined? E.g. the SETLevel4to5 project is currently working on model architectures, and e.g. needs an interface from a traffic participant (ego, other traffic) back to the environment simulation, which would transport the current state of a vehicle. This seems like a subset of the OsiVehicle message (which BTW should not have OSI in the name) might fit the bill. So my suggestion would be to start splitting up the changes into seperate pull requests, each adding something atomically useful, and clearly defining intended message/information direction of flow. If that seems palatable, I'd try to start doing this for the SETLevel4to5 kind of things, and we could merge more stuff incrementally from there. |
clarifying its state and differenciating power train and lever states
Improvement on Gear handling (HMI-ADAS extension)
|
@pmai: Thank you for your answer and excuse my late reply. |
|
When compiling osi_driver_inputs.proto from this branch I get: What am I missing? |
@TheDraguun I think it is building correctly now? |
|
At the moment two Proof-of-Concepts with these new formats are running. |
|
Outdated. |
So this the continuation of the PR "Extension by HMI-, ADAS- and Dynamic-Values", but now based on a branch. The open points from part I are appended.
The description:
Think about a simulation-construct consisting of a human driver, an AD-function and also a vehicle/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.
An architectural indent is appended.
Thank you!
OSI_Extension_Architectural_Intent_V5.pptx