Delay between image input and ROVIO pose estimate output

[araujokth]

Hi,

I was checking ROVIO's processing time and noticed that the delay between an image input from rosbag (https://github.com/ethz-asl/maplab/blob/master/applications/rovioli/src/datasource-rosbag.cc#L163) and the time at which the ROVIO estimate corresponding to that same image is ready (https://github.com/ethz-asl/maplab/blob/master/applications/rovioli/src/rovio-flow.cc#L204) has the following statistics: (1.34053e+08 +- 9.38183e+06) [1.06746e+08,3.08422e+08], so around 134 ms on average. To identify an image and ROVIO estimate pair I look into the timestamp which is attached to the image (image_measurement->timestamp) and to the ROVIO estimate (rovio_estimate->timestamp_s), and then use std::chrono::steady_clock::now() to get the computer timestamps for each of the instances. I first "manually" checked this delay by just printing the timestamps using VLOG, but then recorded the image input timestamps in a list (since the delay is larger than the intersampling period) in order to use your statistics functions. I did this for the master branch and the pre-release-march-2018 branch and the values are very similar.

I then noticed that in the end of the pre-release notes #55 that this delay had been reduced in this release by @dymczykm , so I am wondering if I am doing something wrong?

Thanks again for the help guys!

[araujokth]

@dymczykm @mfehr just wanted to ping you in case you had any quick tip about this. Thanks a lot for any help

[araujokth]

Hi guys, just had the thought that this issue could have already been fixed on your latest develop branch and gave it a try. I ran the maplab-node with euroc-mono for both datasource type rosbag and rostopic. Unfortunately there is still around 120-130 ms delay between an image input and rovio estimate output for that same image when playing from rosbag or rostopic, but again it could be that I am setting some flag in the wrong way

[araujokth]

So after going into debugging rovio to find about the large delay, I came to the same conclusion as @ZacharyTaylor here ethz-asl/rovio#180 and the reason for this very large delay is the maxWaitTime_ in this file https://github.com/ethz-asl/maplab_lightweight_filtering/blob/72955926b6a106c5ffba49b2da40a9da82e5e6b9/include/lightweight_filtering/FilterBase.hpp#L29 which is set to 100 ms by default, hence the +100 ms on my measurements. So for anyone planning to use maplab in a real application I would suggest changing this parameter to reduce the delay.

Setting this value to 0.005 (5 ms) gives me the follow stats on the image to rovio estimate latency (nanoseconds):
mean: 1.8845e+07
stddev: 4.26646e+06
min: 1.24742e+07
max: 5.5987e+07

Comparing the ATE on the MH_01_easy.bag dataset with maxWaitTime_ = 0.1 or maxWaitTime_ = 0.005 showed that the errors are exactly the same, so there doesnt seem to be any impact on the performance.

[aseyfi]

I have proposed a different solution here