search

OpenSimulationInterface / open-simulation-interface

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

Usage pattern for osi_vehicle, osi_graphics and osi_control unknown ... #354

Open ManuelKugelmann opened 5 years ago

ManuelKugelmann commented 5 years ago

I want to add the new messages to an OSI interface, but do not know if they will be sub-messages of e.g. SensorView or GroundTruth or Root messages. And if they will be root messages, will they share a connection which delivers SensorView or use a separate connection?

ManuelKugelmann commented 5 years ago

@ThomasSchloemicherAVL @ThomasNaderBMW @jdsika Does anyone have information on the usage pattern for the new message types osi_vehicle etc.?

jdsika commented 5 years ago

The idea would be to have the osi-vehicle e.g. as a root message. It can be useful to reuse submessages of parts of osi_groundtruth. It is still experimental.

ManuelKugelmann commented 5 years ago

@jdsika on the same publisher as sensorview or a separate publisher?

pmai commented 5 years ago

As @jdsika said, I would be careful with osi_vehicle, since the content and usage pattern for that seem to be as yet ill-defined, and I would expect more churn until this is really merged into OSI: With OSI 3, all top-level messages have clear data flow expectations, set forth for example in the OSMP spec, which seem as yet not clear for osi_vehicle as it currently stands. See also the osi::TrafficUpdate message (https://github.com/OpenSimulationInterface/open-simulation-interface/blob/feature/osi-traffic-participants/osi_trafficupdate.proto and OSMP spec extensions https://github.com/OpenSimulationInterface/osi-sensor-model-packaging/blob/feature/osi-traffic-participants/doc/specification.rst) being worked on in the SETLevel project context, which would form part of a way to define the interface to whole traffic participants: A traffic participant receives 1..n SensorViews and produces 1 TrafficUpdate (with optional control channel for scenario engines, yet to be detailed). These different proposals will likely be merged prior to being merged into OSI proper.

ManuelKugelmann commented 5 years ago

Assuming a separate connection for now, since sharing a connection would mean wrapper messages or msgid addition to the protocol - or some trickery to infer the message type.

ThomasNaderBMW commented 4 years ago

So far the three (+gt) messages are planned as standalone/root-messages: groundTruth ==> Cyclic: for the environment (no dynamic objects) vehicle ==> Cyclic: All dynamic objects (incl. ego) control ==> Event-triggered: To controll the engine and send status from engine graphics ==> Event-triggered: To do the graphics-configuration of the engine.

If we get timing/synchronisation problems sth. like a "meta-message" is thinkable, but not the intendation so far. ==> PoC still running.

ManuelKugelmann commented 4 years ago

@ThomasNaderBMW I'm probably indirectly doing some work for the PoC - doing a UE4 OSI3 plugin :) Timestamps + permitted epsilons should be enough to handle synchronisation.

What about GroundTruth MovingObjects that are not vehicles or vehicles that cannot be expressed by the data in osi_vehicle.proto (Bikes, Trucks, Trailers)? How will the overlap between MovingObjects, HostVehicleData and Vehicle be resolved? Will GroundTruch become StaticGroundTruth? What about changes to usually static objects (e.g. a Lane changes due to workers, a StationaryObject gets broken by a crash, etc...)

If you are after an optimization by reducing the update rate for static objects, I think a publisher with keyframes + changes preprocessing would be more sensible. Done on object level this should be straight forward and remove a lot of serialization, deserialization and network overhead ...

pmai commented 4 years ago

@TheDraguun A lot of these issues will have to be resolved prior to anything resembling this PR being merged. It is currently unclear, why the osi_vehicle stuff is outside of groundtruth, since most of this could just be further optional extensions of MovingObject, i.e. in a nested message. From my point of view I'm waiting on the PoC being complete and then an analysis of what is really being communicated from where to where to resolve these issues. In the meantime the SETLevel4To5 project is working on other incremental extensions making OSI non-sensor-centric, so that will have to be harmonized as well (see the feature/osi-traffic-participant and feature/osi-traffic-command branches for initial discussion points).

ManuelKugelmann commented 4 years ago

Thx for the feedback about the project state and intent. I'll just get the definitions working as-is and leave any inconsistencies for analysis after the PoC