Which visual inertial sensors are fully supported and work best with ROVIOLI ?

[saimanoj18]

I am planning to work on ROVIOLI and our lab does not have any visual inertial sensors. We are trying to build large scale outdoor maps and perform online localization, specifically for self driving car applications.

Could you suggest which VI sensors are fully supported and give good results with ROVIOLI ?

Thank you!

[ZacharyTaylor]

There is an entry for this in the FAQ (https://github.com/ethz-asl/maplab/wiki/FAQ#sensors). However here is my 2 cents on it:

How well ROVIO / ROVIOLI works depends a lot on two things the time-stamping accuracy and the IMU quality. Unfortunately the vast majority of commercial sensors cheap out on the IMU causing issues.

Because of this my 3 favorite options all involve the adis16445/16448 (a $500 IMU)

1. The skybotics VI-sensor (unfortunately they were brought out and no more than a few dozen were produced)
2. The skyaware s360 (a new option, I have been testing it for about a week and getting good results)
3. A custom made solution with an arduino hooked up to an adis16445 that has a trigger line to a machine-vision camera.

Otherwise the intel realsense zr300 can also gives good results, though it is more prone to diverging when experiencing sudden accelerations due to the lower quality IMU.

[mfehr]

@ZacharyTaylor with your permission: Your 2 cents would be a great addition to the FAQ :)

@saimanoj18 maybe just a word of caution if you intend to use ROVIO(LI) on cars. We observed that ROVIO(LI) does not perform great on car datasets. The main reason is that the IMU is not excited enough if you have planar motion at nearly constant velocity, so at the very least you will experience issues with scale. The estimator will need another source for scale, e.g. wheel odometry, stereo matching, ... The localization component and the mapping framework in general, however, will work fine and the map structure to support wheel odometry is already there. I'd recommend to either try to integrate wheel odometry into ROVIO(LI) or integrate the maplab localization and map building components on top of an new/existing estimator that supports this already.

[bxc237]

Hi, @mfehr I guess what you said also answered my issue #54, right? I am mounting the zr300 on a wheeled robot, and the estimated moving speed is always faster then it actually is (sudden acceleration like @ZacharyTaylor mentioned also happened sometimes), which seldom occurs while I hand hold the zr300.

[mfehr]

@BryceeeeeChen yes, we think so, you can try to tune the parameters a bit to decrease the chance of it diverging but you'll still end up with scale issues, because the IMU simply doesn't provide enough information. So the fact that your robot is driving smoothly makes it worse :)

[bxc237]

Hi @mfehr, thank you very much. Then could you tell me a bit more about how to integrate wheel odometry into ROVIOLI? And I also need to increase accelerometer covariance parameter more, right?

[mfehr]

maybe my comment about integrating wheel odometry was a bit misleading, this would involve actually adding this feature to rovio, so it will require some effort. If you are interested in pursuing this let us know. Yes if I remember correctly by shifting the confidence from inertial to visual we were able to improve the results, but the underlying problem remains.

[bxc237]

Yes, I am willing to do it (or make some contribution if I can) since I really need this feature to work on a wheeled robot. So please tell me more about how to start this work.

[mfehr]

We discussed this internally and concluded that in order to extend ROVIO with wheel odometry there are two options, both would require a significant amount of work:

• If you want to update the filter state based on both IMU and wheel odometry one would need to replace the EKF (which allows only one update) with a more general approach like this one, code is available. Which would be a lot of work and require you to turn ROVIO inside out.
• You can try to switch updates between IMU and wheel odometry or try to do it only on wheel odometry, however some DOFs are not constraint then.

The easier alternative is probably what I suggested earlier to try to find an estimator that can handle odometry and integrate it with the visual localization.

[bxc237]

Hi @mfehr , but I found something like this, and this. It seems like feeding the velocity data from the external sensor is very straightforward. Or I am totally wrong?

[schneith]

It is probably dependant on the platform and its application whether processing the (wheel) odometry constraint as an update, combined with IMU propagation, yields good results. But in my opinion it is worth a try before getting into more involved methods. For this you can try hooking up the update routines that you found.

But if the IMU propagation leads to bad linearization points for the updates it might be better to propagate using the wheel odometry and processing the IMU as an update as @mfehr suggested.

[srabiee]

@BryceeeeeChen I was wondering if you managed to integrate wheel odometry. I am having the same problem and it would be a great help to have your insight since you have probably tried a thing or two with integrating the odometry into rovio.

Thanks :)

[bxc237]

Hi @srabiee, one of my coworkers finished the integration, which works well on our platform. Since the original rovio already has the function to process the velocity update, he told me that you just need to add the wheel data to rovioli's datasource and call the processVelocityUpdate() in rovio-flow.cc.

[srabiee]

I see, thanks @BryceeeeeChen . It helps a lot.

[bxc237]

Hi, @mfehr @schneith although feeding the wheel data to the ROVIOLI solves the scale issue, but I am still wondering why Tango device running its own VIO algorithm did not suffer from the scale issue when we tested it on the same wheeled robot (we used lenovo phab 2 pro and we know it has the same VIO sensor as ZR300). Do you guys know the reason? Thanks.

[dymczykm]

@bxc237 we did some tests with earlier versions of Tango and a wheeled robot and the scale issue was there. Was the phone rigidly mounted?

[bxc237]

@dymczykm I am pretty sure that the phone was rigidly mounted. We tested it indoor many times and it worked reliably.

[salahkhan94]

Wouldn't a stereo-inertial setup also help in resolving these scale related issues?

[Abdob]

What ros topic does rovio-flow used for wheel odometry? This should help figuring how to interface the vehicle can bus.