Please add realtime_clock back

[borongyuan]

Hi, @christophfroehlich, @bmagyar, @saikishor, I just noticed that you removed realtime_clock because you thought no one was using it. But we actually use it in our VSLAM system all the time. This is the amazing performance our system has demonstrated so far.
Best Visual SLAM Solution, Localize Disney's TRON Lightcycle Roller Coaster in the Dark in Real Time
To realize such a robust SLAM system, it is very important to correctly handle the time synchronization of sensors. realtime_clock plays an important role in our implementation. It maintains a monotonic clock while also trying to keep it synchronized with the host time (UTC time). Specifically, the OAK camera we use has an internal monotonic clock for time stamping the sensor data. When we receive the data, we need to change its timestamp to UTC time so that downstream tasks can use the data, while also maintaining the monotonicity of the timestamp. This is exactly what realtime_clock provides.
So if it's convenient for you guys, please add it back. The SLAM system is essentially a state observer, which does not go beyond the scope of the control system, so realtime_clock is suitable to be retained in this project.

[saikishor]

Hello @borongyuan!

Does the RCL_STEADY_TIME work for you?, you can choose this at the time of creating your clock, this is a monotonic clock, but it is not slew-free.

[borongyuan]

The problem is not with the monotonic clock, but with the soft synchronization method provided by realtime_clock. I haven't found any similar operations in RCL.

realtime_tools/src/realtime_clock.cpp

Lines 84 to 90 in 0b7ed74

	if (!initialized_) {
	clock_offset_ = system_time_ + period_offset - realtime_time;
	initialized_ = true;
	} else {
	clock_offset_ =
	clock_offset_ * 0.9999 + (system_time_ + period_offset - realtime_time) * 0.0001;
	}

For systems such as high-dynamic control and SLAM, very precise timing is required. However, downstream applications generally do not have such high requirements for time synchronization. In our SLAM system, the timestamp of the IMU data is the sampling time, while the timestamp of the image needs to be set at the midpoint of the exposure interval. The timestamp is provided by the monotonic clock inside the OAK camera, so that we can ensure the synchronization accuracy between the camera and IMU data within 0.5ms. The monotonic clock in the OAK camera starts counting from the moment the camera is powered on. If it is only used for a standalone SLAM system, this timing is sufficient. But for other applications, such as robot navigation, the timestamp of our output data needs to be converted to UTC time. This conversion does not require precise clock synchronization, but monotonicity must be guaranteed first. Imagine you need to share data between multiple robots. It's difficult to ensure precise clock synchronization between them. However, keeping them roughly synchronized with UTC will satisfy most needs.

[christophfroehlich]

It seemed that the implementation had an issue, see #23. There was also some discussion in #241.

If you think this is indispensable, could you please re-add it and address the issues? Or only a subset, if not all functionality is really needed. (start from a revert of #261 08a2235)

[borongyuan]

Thanks for the clarification. I hadn't noticed issue #23 before. This is probably because the data frequency used by our VIO is not high enough, the IMU data is only 200 Hz, so we did not encounter this problem. I took another closer look at the implementation of realtime_clock. Indeed, if we want to add it back, it would be best to provide a more reasonable implementation. I'll re-examine its original design goals and consider how to deal with this.

[github-actions]

This issue is being labeled as stale because it has been open 45 days with no activity. It will be automatically closed after another 45 days without follow-ups.