Feature/cuckoo

[rikba]

We notices some time delay between the IMU angular velocity on our robot and the angular velocity published by Vicon.

In order to improve time stamping we tried to deploy cuckoo time translator. Still some delay in the range of 50 to 60ms remains.

Time stamping: tracker, about 200ms delay

Time stamping: ros, about 75ms delay

Time stamping: cuckoo, about 60ms delay

[alexmillane]

@rikba Thanks for this analysis.

Could you confirm that this delay is between the raw vicon measurements and not the estimates from the Kalman filter?

If that is indeed the case this looks great and I'd suggest we merge it.

[rikba]

Sorry, that was the estimated transform. I'll have a look at the raw measurement delay.

[rikba]

Obviously, there is no raw angular rate measurement, but I tried to compare the estimated position with the raw position measurement while swinging the robot on a rope.

The delay between these two is at most 8ms, but cannot really tell on a quick glance.

[alexmillane]

Honestly, it's been so long that I can't remember what even ballpark the delay was in, so that will be worth checking. I also tuned the filter during my first few weeks at ASL, before I had any idea what I was doing, frankly. So if the delay is significant we could retune it...

[alexmillane]

Obviously, there is no raw angular rate measurement, but I tried to compare the estimated position with the raw position measurement while swinging the robot on a rope.

The delay between these two is at most 8ms, but cannot really tell on a quick glance.

So this is a good sign, however, the translation and rotation components are filtered in separate filters, so to be sure you would have to look at the rotation estimates directly.

[rikba]

Does not seem, like there is a significant delay between estimated and raw transform, so that looks good.

But what about the delay between vicon doing the actual physical measurement and the measurement ending up in the ros_vrpn_node? Is there a chance, that 60ms is possible?

[alexmillane]

Does not seem, like there is a significant delay between estimated and raw transform, so that looks good.

But what about the delay between vicon doing the actual physical measurement and the measurement ending up in the ros_vrpn_node? Is there a chance, that 60ms is possible?

I guess there's a bit of cross talk here, but I would ensure that this statement hold for the exact rotation estimates you're worried about. The translation delay wont tell you much about the rotation delay.

With regards to the second point, 60ms seems like a lot no, if you're stamping on a ground station connected with a cable? I guess?

[rikba]

1. The attitude filter seems to do a good job filtering noisy attitude measurements
   

2. Looking into detail, the filter is responsible of at most 10 ms delay.
   

[alexmillane]

Ok, that seems reasonable. I guess then there is ~50ms delay somewhere else? Are the clocks of the computers measuring the IMU and the vicon synced?

[michaelpantic]

hmm I remember that we used to hack tune msf and other estimators with some 50ms delay w.r.t. vicon. Also a quick google showed this:
https://core.ac.uk/download/pdf/211853264.pdf (see table 1).

Not sure if the vicon system is supposed to correct for this or not?

(also maybe try to lower jitter in the flynet network by kicking out all other people, I noticed that it sometimes is quite heavily used. shouldnt be responsible for 60ms of sync mismatch, but might make things needlessly more difficult)

[rikba]

I like the correlation between my IMU's angular rate and Vicon estimated rate a lot better after compensating for 54.9ms latency as described in the paper you mention.

Maybe, we have a few more users confirm, that they observed noticeable delay. Then this could be a valid contribution.

I guess then there is ~50ms delay somewhere else? Are the clocks of the computers measuring the IMU and the vicon synced?

I tried my best with chrony on the robot running the IMU and NTP with time2.ethz.ch on the vicon tracker computer.

[michaelpantic]

@rikba nice!

Just one more thought:
If its a systematic issue / "normal" for vicon, it should be consistent over both our vicon systems (leo c6 and lee J 309). In case you need to set it up again anyway in the future, it could be another validation.

[rikba]

Quick update, even though the correlation between our IMU's angular velocity and Vicon angular velocity is better when accounting for the offset, our fusion algorithm performs better when using estimated position and orientation measurements without accounting for any additional Vicon offset. If offsetting Vicon stamps, roll/pitch estimates of our estimator are offset from Vicon ground truth (sorry, no plot at hand)

Thus the error can still be somewhere else and more insight and user feedback is necessary.

• There is an error in time stamping our IMU data
• There is an error in our filter IMU integration
• The Vicon angular rate filter introduces delay we did not see above

[marco-tognon-robotics]

How do you compute the Vicon angular velocity? To do comparisons we should have a delay-free measure. You could use a non-causal filter that does not introduce delay. I normally use the Savitzky–Golay filter

[rikba]

How do you compute the Vicon angular velocity? To do comparisons we should have a delay-free measure. You could use a non-causal filter that does not introduce delay. I normally use the Savitzky–Golay filter

I think you would have to look at https://github.com/ethz-asl/ros_vrpn_client/blob/master/src/library/vicon_estimator.cpp#L221. But first it would make sense to compare rates from an IMU and Vicon from a different platform.

[weixuanzhang]

Hi guys,
some analysis from a rosbag recorded by flying Kea on 21. Aug. 2020: indeed there seems to be a delay between the Vicon estimated angular velocity (i.e. vrpn_client/estimated_odometry/twist) and the gyro for 70~80 ms. I computed the 2 norm of each vector and compared them. All are ros time stamped:

Note that, however, if I postprocess the raw attitude data (i.e. vrpn_client/estimated_transform/rotation) by using a non-causal smooth filter, interpolation and differentation, the delay becomes much smaller (about 10 ms). It is reasonable that a Kalman filter leads to an extra delay of 50 ms @rikba ? Also a noncausal filter has been applied the gyro measurement for clarity, it shouldn't affect the delay characteristics.

[alexmillane]

@weixuanzhang Thanks for the analysis 👍

I think that that this is entirely possible. If everything else is equal, i.e. timestamping on a ground-station computer, connected with a cable, and synced with the eth timeserver, your analysis indicates pretty definitively that this is the case.

This delay could be reduced by altering the tuning of Kalman filter, of course at the expense of a noisier estimate.

[rikba]

Thanks @weixuanzhang, you are saving my sanity here.

So this PR gave some insight into estimated angular rate filter delay.

Whether or not cuckoo time translator should be added is up to taste. It does take some jitter and delay from the measurements but adds another dependency.