Closed jdsika closed 1 week ago
We should add suitable traces for testing the application to the repository.
@Str4ken
A non empty OSI sensor view trace for you to check. demo_SV_onramp_V1.zip
@Str4ken
A non empty OSI sensor view trace for you to check. demo_SV_onramp_V1.zip
I've just checked with this file and we have no message converter in the code to the osi3.SensorView
schema, so it doesn't break but doesn't show nothing, but it now conforms to the generated types, since it no longer has those nested value objects for the enums.
Anyway, for the extensions to work with this file, we need adapt the message converter to to work with this schema, impacting a major change in the part of the logic that still depends on nested value objects, only then will we be able to remove even more of the manually created types.
I guess it works out of the box if you extract the optional GroundTruth global_ground_truth which is nested in the top level message "SensorView".
I guess it works out of the box if you extract the optional GroundTruth global_ground_truth which is nested in the top level message "SensorView".
Not really! We have a lot of places in the code wich relies on some enum.value (e.g.: https://github.com/Lichtblick-Suite/asam-osi-converter/blob/417464c35616d520c155cf29ae229f9f130cc4ce/src/trafficlights/index.ts#L20) All these needs to be changed so that it access the enum directly.
But isn't that a general problem that is intended to be fixed in the current PR?
I am getting new mcap files tomorrow that contain OSI ground truth only
@Str4ken
A non empty OSI sensor view trace for you to check. demo_SV_onramp_V1.zip
I've just pushed new adjustments to work with this file.
Here a three example files: Example_OSI_MCAP.zip
The messages are basically empty except that a varying timestamps are set.