Convex Hull and KF show different mean offset

[skohlbr]

As noted in ethz-asl/ethzasl_xsens_driver#52 I added the time translator to a cpp driver for xsens IMUs. It seems to work fine, but when I plot the duration between the translated stamp in the header of my IMU messages vs. their receive time in a analyzer node, the convex hull-based approach shows a consistently higher value. In contrast, for the KF, even values < 0 are sometimes reported, which is implausible (as that indicates the message has been received before it was generated on the device ;) ). The offset for the update function is set to 0.0 for my testing.

Convex hull (diff between consecutive imu stamps blue, diff between imu stamp and receive time in test node red):

KF:

Note how here, the red plot dips below 0 quite frequently.

Is this expected behavior? What's the recommended approach to use?

[HannesSommer]

@skohlbr , thanks for trying out this library.

I do not fully understand your plots. Can you give me more input?

I assume the blue lines are the deltas of consecutive timestamps after translation with CH or KF.
For the red I'm at a loss because I don't know what your analyzer node is.

Regarding your issue-question, whether there can be a mean offset between KF an CH output: yes, it is very much expected. This is because the KF's mean output is based on an averaged delay while the CH at a minimal delay, which is always smaller or equal. As a consequence they deviate the more the larger the random transport delay's range is (roughly by half of the range's diameter it).

The fact that the CH is larger her indicates that we are looking with a flipped perspective on this phenomenon (e.g. by looking somehow at how much the translators subtract from the receive time, which is larger for the CH because it can observe more of the actual transport delay and consequentially removes more). To be more specific I'd need to know more about the red values.

This difference in mean is not a problem in practice because when estimating the remaining delay after translation this difference is observable and gets removed as a part of the estimated delay. Of course this means that the estimated delay depends on which translation algorithm is used(!). But that is inevitable given the original problem (AFAIK).

[skohlbr]

Thanks for the fast reply! The blue lines are indeed the header stamp differences between consecutive stamps after translation. The red line is the header timestamp (as provided by the translator) subtracted from the receive stamp in the analyzer node:

ros::Duration msg_stamp_diff = ros::Time::now() - header.stamp;

I guess it's a matter of convention if the subtraction should be reversed and thus signs flipped :) Of course, this additionally contains the transport latency of ROS topic communication (from IMU node to the analyzer node generating the output).

What I'm aiming for is a little better understanding of how to choose CH vs KF and also how to choose a value for the switch_time param. As visible from the (red) plots, it seems there is some kind of clock divergence that resets every ~8s.

Makes sense to me that the offset is observable in principle, but it can still be quite challenging to calibrate it, depending on hardware constraints. An "easy" option that comes to mind would be using a global shutter cam with h/w trigger, a microcontroller time-synced to the PC and kalibr. If you have any hints about other options I'm open to suggestions :)

[HannesSommer]

And the "analyzer node" is just some node running on the same computer as the IMU node that you wrote to analyze the timestamps of the IMU?
If it is on the same computer, then that is indeed a confusing fact about this KF approach that you found.

With this algorithm, in average, the delta between the timestamp after translation and the receive time is close to zero (by design)!
But the translated component has a smaller random delay component (it removes partially the randomness from the timestamp - that is the purpose of the algo.). Hence, the translated time must be sometimes in the future of the receive time (negative red in your case).

The KF does not even try to guess the average transport delay from the IMU (in your case) to the computer. This average transport delay (temporal offset) would fix this this confusing observation (the red line would be increased by this positive constant).

The fact that the red line is not in average zero is actually because you don't compute that in the IMU node but in a separate node that receives a little later, i.e. the average of the red signal is pretty precisely the average transport delay from IMU node to analyzer node. The noise of the red signal is the sum of the two random transport delays, IMU to IMU node + IMU node to analyzer node, while the first is actually only visible, because it got removed by the KF or CH (the removed noise can be retrieved by comparing with the receive time -- after all it is the one that got corrected in the first place).

Regarding this 8s period I can only guess. Maybe the CPU load or the USB bus's load (assuming it is USB) is for some reason of this periodicity? Or it actually comes from the IMU where there is a periodic change in the processing delay (the transport should not be IMO).
Ah, maybe, if it is USB, then actually it is because of the poling rhythm of the USB (prior to 3.0). When you poll with a fixed rate with a non-integer ratio compared to the emission frequency then the delay should vary periodically. That could be it. Maybe you can find the current USB polling rate and see whether it can explain the 8s period.

For CH vs. KF: I would use CH (while switching about every few hundred seconds) for nice clocks that do not have strong higher order drifts. For very cheap clocks or those that have to sustain aggressive temperature changes the KF is better but might need tuning.

Observing is the average offset is hard for an IMU. And yes, Kalibr + trigger or shutter signal could be a good practical approach to this.

[HannesSommer]

One more thing about finding this overage offset: Please note that it is rarely useful (alone). Typically, the pairwise temporal offsets between sensors + actuators is relevant while the offset w.r.t. to CPU can often be ignored. Of course, this changes if some sensor to CPU offsets are already known. Then getting the others can be efficient to achieve the goal.