OpenSimulationInterface / open-simulation-interface

A generic interface for the environmental perception of automated driving functions in virtual scenarios.
Other
267 stars 125 forks source link

ENABLE-S3: Ego Vehicle related data #89

Open HannesSchneiderAVL opened 6 years ago

HannesSchneiderAVL commented 6 years ago

For precise sensor model simulation some properties of the Ego Vehicle will be relevant. This information can be calculated in a vehicle dynamics simulation and can be sent back to the simulation environment. (in our use case: VTD -> Model.CONNECT (VSM || Carmaker) --- (ego vehicle dynamics) -> VTD) A message in OSI containing this information would be helpful for a precise sensor simulation:

For the sensor model following properties would be relevant:

VehicleMovement boolean BreakOn boolean HandBreakOn boolean

WheelVelocityFrontLeft WheelVelocityFrontRight WheelVelocityRearLeft WheelVelocityRearRight m/s 1/10

VehicleVelocity kp/h 1/100

Pitch Yaw Roll degrees

PitchVelocity YawVelocity RollVelocity degrees/s

PitchAccelleration YawAccelleration RollAccelleration degrees/s2

ShockAbsorbersImmersionDepthFrontLeft ShockAbsorbersImmersionDepthFrontRight ShockAbsorbersImmersionDepthRearLeft ShockAbsorbersImmersionDepthRearRight mm

TirePressureFrontLeft TirePressureFrontRight TirePressureRearLeft TirePressureRearRight Bar 1/100

haoyuanying commented 6 years ago

Hello,

Thanks for the suggestions. In OSI::SensorData, all the vehicle / objects are converted to DetectedObject and the Ego Vehicle itself is removed from the DetectedObject. The only way to determine the Ego Vehicle is to check the ego_vehicle_id in SensorData (it is the ID that the vehicle in GroundTruth), or recursively check the ego_vehicle boolean of each vehicle in SensorDataGroundTruth. To have the Ego Vehicle information in SensorData, I would propose to have a redundent Ego Vehicle copy in SensorData, that would improve the efficiency to find Ego Vehicle in SensorData by direct accessing instead recursive searching in SensorDataGroundTruth.

Since the vehicle information in SensorData are relative to the Ego Vehicle in GroundTruth, I would propose to have the absolute information here for further calculation in other simulator.

The boolean of movement of the vehicle is very useful in general, especially in SensorData. The velocity and orientation in different units are a bit redundant, is there an issue that to make the conversion outside OSI in your toolchain?

Regarding to the other relevant information,

BreakOn boolean HandBreakOn boolean

WheelVelocityFrontLeft WheelVelocityFrontRight WheelVelocityRearLeft WheelVelocityRearRight m/s 1/10

ShockAbsorbersImmersionDepthFrontLeft ShockAbsorbersImmersionDepthFrontRight ShockAbsorbersImmersionDepthRearLeft ShockAbsorbersImmersionDepthRearRight mm

TirePressureFrontLeft TirePressureFrontRight TirePressureRearLeft TirePressureRearRight Bar 1/100

since in my opinion OSI focuses on the ADAS and autonomous driving sensors simulation (Radar, Lidar, Camera, etc.), I am not sure if the driving dynamic parameters would be necessary included. @CarloVanDriestenBMW Please advise if these should be included in next OSI versions.

I would make a new pull request as follow up with respect to the "TO DO" that I mentioned above.

ghost commented 5 years ago

Hello @haoyuanying and @HannesSchneiderAVL, a colleague of mine will come up with a PR comprising new signals addressing vehicle models and ADAS functions. I'll keep you in the loop.