Adding a Tins-based driver implementation

[MattSYoung]

General Changes

• Added an example and latest metadata file.
• Added/exposed the functions for loading and saving metadata to a json file.
• Renamed the existing files for the default driver to differentiate them from the TinsDriver equivalents:
  • sensor.yaml -> default_config.yaml
  • os1_launch.py -> driver_launch.py
  • main.cpp -> main_default.cpp
• Shifted sensor parameter declaration and getting from the driver implementation, to the ::onConfigure() function of each sensor implementation.
• Contibutors: Matthew Young (Trimble Inc)

TinsDriver

• Added a new SensorImplementation called SensorTins, and a Driver implementation that uses it called TinsDriver. This implementation uses the Tins library to find LiDAR and IMU packets, so it works with real data as well as data replayed from a pcap file.
• Added a new driver called TinsDriver which utilizes the existing OusterDriver class with the SensorTins class.
• Added an new set of launch, param and main files for the TinsDriver
• Updated readme and parameter file to explain usage of the TinsDriver implementation.
• Added some additional debug code to print the number of packets that have been accumulated into a cloud when it is published.
• Contibutors: Matthew Young (Trimble Inc)

[SteveMacenski]

Let me know when you want me to review this again (also you have a conflict)

[MattSYoung]

@SteveMacenski I'm ready for you to review the PR again.

It is feature complete, however there are still some issues with the output rate of the /points topic depending on the throughput/replay rate of the incoming packets. This is mostly an issue with the high-rate OS0-128 that I have access to, and may not be an issue at all for other Ouster models. In most cases this simply means the output rate of the /points topic will be as low as 3.5 Hz instead of the target 10 or 20 Hz.

Since this is fundamentally an issue with the replay rate/throughput of the user's ethernet device, and not the Tins based driver, I would rather address this problem separately in issue #78.

[SteveMacenski]

Did you compile with release flags? that's often a quick fix of such issues others have reported.

[SteveMacenski]

Looks like you have some new merge conflicts. I'm doing another pass through the code, but so far the only thing is the linting in the non-client files

[SteveMacenski]

Once the conflicts / linting is done, happy to merge it!

[MattSYoung]

Ok, after navigating the minefield that is git rebase, I think we're good to go. I will run one last QA/bug check tomorrow and then let you know it's ready to merge.