[ZUPT] Problems with zero velocity update #89
Comments
|
I checked that the |
|
Could you provide an example launch file and dataset that can reproduce
this, if you run in debug mode where does this fail?
…On Fri, Aug 7, 2020, 6:18 AM zgxsin ***@***.***> wrote:
I checked that the res dimension is too large:
res.rows102
[ZUPT]: accepted zero velocity |v_IinG| = 0.012 (chi2 0.544 < 79.697)
res.rows774
[ZUPT]: accepted zero velocity |v_IinG| = 0.012 (chi2 4.462 < 710.441)
res.rows198
[ZUPT]: accepted zero velocity |v_IinG| = 0.012 (chi2 0.912 < 166.444)
res.rows3270
[ZUPT]: accepted zero velocity |v_IinG| = 0.012 (chi2 18.781 < 3138.127)
terminate called after throwing an instance of 'std::out_of_range'
what(): vector::_M_range_check: __n (which is 18446744073709551615) >= this->size() (which is 10004)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#89 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAQ6TYSXAOHQRXNB24M6E4DR7PII5ANCNFSM4PXLUOMA>
.
|
|
Do have a dataset this is failing on? |
|
GDB back-tracing: |
|
Further investigation: I increase the threads by changing to The above mention problem is gone. But i encountered the following very big chi2-distance issue (trajectory flies away): |
|
Update: We could get NAN value for chi2 calculation, which needs to be considered. |
it dosen"t work by changing ros::spin() |
|
Did you get the same error as before after you change ros::spin()? |
|
This GDB hints at that the IMU is not providing good timestamps, or the time offset calibration seems to be freaking out. Can you disable time offset calibration, and then also take a look at the timestamps. The line that is probably hurting you is this one which assumes that you have IMU measurements to propagate with. If you don't have any measurements, then you can't propagate. Of course I would make sure that you can get the system to work without zero velocity updates, and since you are using your own datasets, make sure you can run the system on one of the supported ones. |
yes |
can u show me your pgeneva_ros_kaist.launch ? |
Hi @goldbattle , thanks for the reply. I checked the timestamps of IMU and cameras. They are synchronized and there is no message loss. I think the problem is due to that we select too many IMU measurements in this function: ov_msckf::Propagator::select_imu_readings, causing the unbound computational burden. There might be something wrong with the timestamp handling logic.
If i run the program without enabling the ZUPT, the trajectory will drift a little bit, which is not what we want. |
Sorry, I ran Kasit dataset using the default one. I cannot tell whether there is issue with that or not since i did not run the full trajectory. |
|
This is due to zero velocity update IMU selection logic, will track this in Issue #90. |
I can run openvins without enabling the zero velocity update feature. Once i enable it, the program seems to get stuck when the program remains in zero velocity state for a long time (< 2 mins). And sometimes the program just dies (see below). And the program does not publish the pose of IMU when it is in zero velocity state. Is this expected or not? I think IMU pose should still be published with a different timestamp when the device is not moving.
The text was updated successfully, but these errors were encountered: