-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature/cuckoo #59
base: master
Are you sure you want to change the base?
Feature/cuckoo #59
Conversation
@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. |
Sorry, that was the estimated transform. I'll have a look at the raw measurement delay. |
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... |
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? |
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? |
hmm I remember that we used to 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) |
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 tried my best with chrony on the robot running the IMU and NTP with time2.ethz.ch on the vicon tracker computer. |
@rikba nice! Just one more thought: |
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.
|
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. |
Hi guys, |
@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. |
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. |
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