Update osi_hostvehicledata.proto#405
Conversation
- suggestion for protobuf description - replaced engine with motor to avoid explicitly defining engine for interfaces - reorganised wheel arragement--> anti clockwise starting from front left wheel - Naming suggestion for VehicleLocalization--> renamed as Vehicle GEOPosition
| optional Pedalry pedalry = 1; | ||
|
|
||
| // Rounds per minute of the engine. | ||
| // Rounds per minute of the engine. RPM can be from E-Motor/ Engine. |
There was a problem hiding this comment.
since you brought the E-Motor stuff up; how to deal w/ vehicles, which have more than one of those (e.g. Tesla S 4x4)?
There was a problem hiding this comment.
Looks to me like we will have to do a repeated submessage "Engine". Good point, i will pay attention to that at the next steps ::)
There was a problem hiding this comment.
@ThomasNaderBMW in yesterday's TrafficParticipants discussion @pmai has also mentioned that we may need to consider how to set this signal in cases where more than one e-motor is available?
Idea for further discussion: It can be a consolidated signal going to wheels from all sources. Naming of the signal to be brainstormed in the follow-up meetings.
There was a problem hiding this comment.
Topic for next WP15-Meeting.
| // \brief This message contains all the necessary information of the localization solution. | ||
| // | ||
| message VehicleLocalization | ||
| message VehicleGEOPosition |
There was a problem hiding this comment.
Could it be, that xyz will be also part of this message, so georeferenced is not the only option in the future? Look to depricated optional BaseMoving location_rmse = 2;
So localization would be more open..
There was a problem hiding this comment.
@ThomasNaderBMW : as discussed, I would keep xyz and geo-position messages separately for flexibility purposes.
There was a problem hiding this comment.
I would like xyz will be keep too, as there are many simulator models that working with local xyz coordination systems.
There are currently geo-reference option available in
header element and the coordinate system of OpenDRIVE1.6 Concept, (But, currently GIS concept is fully optional)
As an additional question, I can't know the NDS Map specifications, but are the geo-reference specifications used fixed in NDS?
Does the newly definition of VehicleGEOPosition in the OSI message have a goal that the referenced geo-reference specification is fixed? (e.g use NDS's geo-reference?)
There was a problem hiding this comment.
Sry for the late reply.
I gave it a new structure, can you both have a look?
To the questions:
- NDS information shall be possible to be transported
- proj4-String of OpenDrive has to be discussed as it is used to calculate the WGS84-Position (End-Result) as an Input-Parameter. Is this information necessary beside the simulation-tool, that is parsing the OpenDrive?
Made some adaptions, so it can be build. Also some simplifications, so it is not to much at the beginning.
Some improvements regarding architectural issues and out of definition reasons.
clemenshabedank
added
TrafficParticipants
ThomasNaderBMW
merged commit 825b4b9
into
OpenSimulationInterface:Extension_osi_hostvehicledata
5 participants
Reference to a related issue in the repository
#400
Add a description
Minor modifications to the proposal
Mention a member
@pmai @ThomasNaderBMW @clemenshabedank @ThomasSchloemicherAVL : For further discussion