Support for accessing and mutating the timestamp mode on the LiDAR

[tpanzarella]

The on-LiDAR timestamp_mode can now be set in the config file. Additionally,
its state is fedback in the GetMetadata service.

I HIL-tested these changes via visual inspection and everything seems to
be working correctly. I see that in #10 there is a plan add some
automated testing. I think this is a very good idea. I'll add some comments
to that issue shortly.

Closes: #34

[SteveMacenski]

Looks good- the only other ask I think is also supporting a ROS time as well. It won’t be well synchronized but if they’re not using PTP then the clocks could diverge either way.

[tpanzarella]

In terms of implementation for a ROS timestamp... I suggest we add a separate parameter (bool flag, default False) like use_reception_timestamp whose semantics indicate to explicitly ignore the LiDAR timestamp. Additionally, when running in this way, we should emit a log message at WARN level (once) alerting that we are applying timestamps in this way. I say that because, we know that the ROS time is explicitly incorrect and we have no real good way (without using something like PTP) to model how incorrect the stamp is. I'm happy to do this, but, wanted to share how I would plan to implement it. Do you agree?

Also, I would suggest we separate that out into its own PR as it sort of conflates issues. This PR focuses on which stamp is applied by the LiDAR. The subsequent one would handle whether or not use use the LiDAR stamp or a ROS timestamp (at time of data reception, not when the data are sampled).

LMK what you think.

[tpanzarella]

I guess we could add something like TIME_FROM_ROS_RECEPTION in the timestamp_mode enum to keep the code cleaner. But, I'd still suggest we emit a warning since we know the stamp we are using is explicitly wrong.

[SteveMacenski]

That sounds reasonable. I mostly wanted in enum to be clean, I’m fine with a warning though. It also may be valuable in the readme to explicitly describe what those 3 modes do and why time syncing is important. I’ve run into PTP before from having clock skew issues but I wonder if its something we should specially mention the importance of and a one liner to enable on the host machine so the lidar can be a slave.

[tpanzarella]

I’m working on a write up that I’ll post publicly on this topic specifically — PTP time sync using a Linux host as the PTP grandmaster and an Ouster LIDAR as a slave. It will be easiest to link to it from the README once I publish, it’s more than a one-liner (it will happen this week). PTP claims accuracy to w/in +/- 1 usec while the Ouster docs claim +/- 50 usec. I want to characterize the OS1 specifically and see how to best tune it. What I have seen so far is that it oscillates rather wildly (+/- 200 usec) around the set point (0, offset from master). I still have more analysis to do. Depending upon what I find out I may see if Ouster will expose some more knobs to the underlying ptp4l configuration so we can tune the servo params over the tcp interface.

[tpanzarella]

@SteveMacenski There is a change I'd like to make to the last commit. Please hold-off on merging.

[SteveMacenski]

Just an update on the warning. I want it to be less scary looking.

[SteveMacenski]

I'm OK with this when you are.

[tpanzarella]

I'm good.

[SteveMacenski]

Thanks! I also added you as a collaborator if you check your email linked to github. Welcome and thanks!

[tpanzarella]

Thanks Steve. Happy to collaborate with you.