You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A similar issue was presented before. #5
When I run the SVO example (both with the fla_stereo_imu.bag provided and with my own stereo camera, and both on my laptop and Odroid XU4), there are some strange things that make me skeptical of the trajectory accuracy produced only by visual odometry.
As mentioned in In EuRoC V101 dataset, the estimated trajectory has a big error! #5 , though it tracks the position of the camera I get lots of: "seed sigma is nan!-0.338734, sq-nan, check-convergence = 0" and "critical". What does that mean?
I have considered the error as normal information before, which indicated that the depth filter try to reject some "wrong" estimated depths as they are not converged. But it seems that this error indicates an abnormal problem which can decrease the accuracy now as you mentioned to try to fix/suppress it. Have you found where the problem is? In the implementation or the depth filter algorithm itself?
Frequently the trajectory in RVIZ was not recorded as "continuous blue point arrays", especially in corridors or outdoors where fewer features are likely to be detected. When running SVO on odroid, sometimes even few blue points of trajectory was recorded and I can hardly see them. What I can see about the camera motion is only the moving coordinate axes indicating the current camera pose. I doubt that the trajectory recorded in RVIZ is the trajectory estimated using both image frames and IMU information while the moving coordinate frame with no "blue points" left is the motion with only IMU information? Or it is just a communication problem or a RVIZ computation resource occupancy problem?
These problem are of great concern. I'm quite worrying about the accuracy of the estimated trajectory the SVO example could reach, especially on Odroid XU4. Hope you can reply as soon as possible.
The text was updated successfully, but these errors were encountered:
Hi, for the first problem, I cannot say much now, haven't got time to investigate it. For the second, SVO only output poses for images. It is possible that RVIZ misses some message for visualzation. If you are concerned about the continuity of the pose output, check the corresponding ros topics would be a better idea than looking at the visualzation.
A similar issue was presented before. #5
When I run the SVO example (both with the fla_stereo_imu.bag provided and with my own stereo camera, and both on my laptop and Odroid XU4), there are some strange things that make me skeptical of the trajectory accuracy produced only by visual odometry.
As mentioned in In EuRoC V101 dataset, the estimated trajectory has a big error! #5 , though it tracks the position of the camera I get lots of: "seed sigma is nan!-0.338734, sq-nan, check-convergence = 0" and "critical". What does that mean?
I have considered the error as normal information before, which indicated that the depth filter try to reject some "wrong" estimated depths as they are not converged. But it seems that this error indicates an abnormal problem which can decrease the accuracy now as you mentioned to try to fix/suppress it. Have you found where the problem is? In the implementation or the depth filter algorithm itself?
Frequently the trajectory in RVIZ was not recorded as "continuous blue point arrays", especially in corridors or outdoors where fewer features are likely to be detected. When running SVO on odroid, sometimes even few blue points of trajectory was recorded and I can hardly see them. What I can see about the camera motion is only the moving coordinate axes indicating the current camera pose. I doubt that the trajectory recorded in RVIZ is the trajectory estimated using both image frames and IMU information while the moving coordinate frame with no "blue points" left is the motion with only IMU information? Or it is just a communication problem or a RVIZ computation resource occupancy problem?
These problem are of great concern. I'm quite worrying about the accuracy of the estimated trajectory the SVO example could reach, especially on Odroid XU4. Hope you can reply as soon as possible.
The text was updated successfully, but these errors were encountered: