Possible division by zero in PreintegratedImuMeasurements::integrateMeasurement (ImuFactor.cpp)
In ImuFactor.cpp for the covariance updating there are divisions by dt, which can be 0.0. Now I get that in general there’d be no reason to update with a 0.0 timestep, but in my particular case this sometimes can happen..
So at line 72 and 73 in ImuFactor.cpp there is
// (1/dt) allows to pass from continuous time noise to discrete time noise
preintMeasCov_ = A * preintMeasCov_ * A.transpose();
preintMeasCov_.noalias() += B * (aCov / dt) * B.transpose();
preintMeasCov_.noalias() += C * (wCov / dt) * C.transpose();
and since updating of the tangent space vector has no problems with dt=0.0, I think it can be confusing to have an ok state, a covariance matrix with nan’s and no warning or error.
This can easily be prevented by doing
if (dt > 0.0)
{
obj.integrateMeasurement(acc,gyr,dt);
}
But I guess we might want move this check to the point where we update the covariance matrix so you can actually call this function with a 0.0 timestep. Or just prevent updating anything all together (zero computation :-)).
What does the rest think? I’ll make a pull request if we decide on an appropriate change.
Comments (4)
-
-
ping
-
- changed status to closed
Merged in fix/453_zero_dt (pull request #426) Throw exception when dt <= 0 close Issue
#453→ <<cset ac0d686c9c16>>
-
reporter I like it. Thanks. This way people can do their own run-time handling.
- Log in to comment
Hmmm. I think this method should never be called with dt<=0. dt==0 is a discrete event that probably needs to be handled by the caller. If you buy that, then there are two possible solutions:
assert(dt>0);
if (dt<=0)
The former depends on users developing the application in debug mode, and the check is gone in Release. thoughts?