Project structure and tracefile reader/writer poc

[TimmRuppert]

Description

• Adds the general project structure (not meant to be for all eternity)
• Adds c++ tracefile writer/reader with support for different formats

I left out further documentation/tutorials besides doxygen documentation and multiple example applications. The PR already contains a lot more than "just adding a reader/writer". I recommend that decisions about how to host, design, or set up additional tutorials and documentation be made outside of this PR. This also applies to contribution guide lines etc.

What is missing to get out of Draft

• [x] Provide .txth reader
• [x] Provide .txth writer
• [x] Provide .osi writer
• [x] Provide .mcap reader
• [x] Add documentation for all classes
• [x] Add more unit tests for recently added readers and writers
• [x] Unify behavior when reading past file end
• [x] Add more sanity checks (opening a opend file etc.)
• [x] Incorporate latest osi mcap spec changes concerning metadata of mcap
• [x] Incorporate tracefile naming convention in examples
• [x] Expose certain elements via API (e.g. Adding more metadata to mcap)
• [x] Solve things marked with "todo"
• [x] Cleanup interface for functions not present in all inherited classes
• [x] Fix warnings
• [x] Rename include guard to follow styleguide
• [x] Fix readme: URL osi doc, features and protobuff installation, mention examples

Closes #1

[jdsika]

rename "metadata_glossary" to "context". We use a familiar term right away and "we are actually giving context for the definitions"

[jdsika]

I would suggest to only support a .txth writer and not a reader due to the discussion of the format being "lossy"

[TimmRuppert]

I would suggest to only support a .txth writer and not a reader due to the discussion of the format being "lossy"

I already implemented a txth reader which seem to work very reliable by simply assuming the first line in the file will be the separator between messages.

If you'd like, I can certainly remove it again! However, my recommendation is to keep it, as it is designed to be quite robust (as good as possible for a format which is not fully specified) and aligns with the de facto standardization caused by OSI2Read.py, thereby complementing the insufficient OSI specification for txth. But that is just my personal point of view.

Adding a txth writer should be quite easy.

[ClemensLinnhoff]

I generally tested all examples and they all worked with my test files.

[jdsika]

Just a question that come to mind without research. Did we take into account that other signals like ROS messages etc can be placed alongside the osi traces?

[TimmRuppert]

Just a question that come to mind without research. Did we take into account that other signals like ROS messages etc can be placed alongside the osi traces?

Yes.

For the reader:

• You have to manually set an option to skip those, otherwise you will get an error while calling the read() function to get the next osi message.

For the writer:

• The underlying mcap writer can be retrieved and thus you can do to it whatever mcap allows (e.g. adding non-osi messages)

The unittest of the reader creates an mcap with protobuf and json messages for testing.