-
Notifications
You must be signed in to change notification settings - Fork 69
VSS to VHAL mapper. #441
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
VSS to VHAL mapper. #441
Conversation
10ed133 to
339db9e
Compare
339db9e to
c8df463
Compare
|
Would you be able to provide an example |
Just generate one with: The Eventually COVESA should maintain a common |
9ad57fc to
d23c553
Compare
cc8c987 to
a2c86a7
Compare
@mikehaller there are minimal examples in the tests if you just want to see how it may look like. E.g. |
|
MoM:
|
|
From the doc (https://github.com/COVESA/vss-tools/blob/a2c86a73c939c0818d88116771461c7186aee2c1/docs/vhal.md#property-change-mode):
Can you explain why an VSS actuator node has a static change mode? Perhaps I misunderstand the meaning of change mode in the mapper. |
Signed-off-by: Jan Kubovy <[email protected]>
Signed-off-by: Jan Kubovy <[email protected]>
Signed-off-by: Jan Kubovy <[email protected]>
Signed-off-by: Jan Kubovy <[email protected]>
Signed-off-by: Jan Kubovy <[email protected]>
Hi, I have overlooked https://covesa.github.io/vehicle_signal_specification/rule_set/data_entry/sensor_actuator/#actuator-type:
should be same as sensor. I will fix that. |
a2c86a7 to
7d7aeb0
Compare
Signed-off-by: Jan Kubovy <[email protected]>
7d7aeb0 to
14cd5b7
Compare
|
Thanks for the updates @jankubovy . Is the PR ready to review (and later merge) - if so change status to "ready to review" |
|
MoM: |
Hi @erikbosch I would merge it when the output, the VHAL exporter here is producing, is actually going to be used in the VHAL project. That project did not start yet, therefore I would not merge this PR yet. What do you think? |
|
Thanks for the clarification @jankubovy. Based on that explanation I see no problem keeping it in Draft status. We do not have any major refactoring for vss-tools planned, so should in general not be a too big risk for regressions due to changes in vss-tools framework. |
| requires-python = ">=3.10" | ||
| dependencies = [ | ||
| "anytree>=2.12.1", | ||
| "bump2version>=1.0.1", # x |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should be in dev dependencies but I guess that's what the x is for?
|
@jankubovy Thanks for reference. Have you done some mapping of data types of VSS vs VHAL & it's incompatibility somewhere ? Will VSS change for VHAL ? E.g Vehicle.Chassis.SteeringWheel.Angle is int16 where as VHAL is Float. @petervolvowinz Mapping file could be a reference for your semantic matching tool though that is applicable for VHAL to VSS as well. |
Hi @renjithrajagopal-sudo we have the field "formula" for mapping differences like those you are mentioning. Still work in progress. As of now such conversions have to entered manually in the generated mapping file. But it will be preserved on future runs of the mapper. |
Ok. Do you mean both range and scale will be preserved under this formula as well for similar use case? E.g A float which was converted to int16(due to VSS) then VSS to VHAL which expects float. Subsystem(100.34) -> VSS(10034) -> VHAL(100.34) , then formula validates range and know scale of 100 |
This mapper should serve as a basis for the ongoing generic VHAL discussions. See the docs/vhal.md for more information.