Custom bag file
eliabntt opened this issue · comments
Hi there, we're running a custom bag file.
My guess is that we need to change the focal length on the parameters.h file.
Still we are not able to run with the IMU since we continuosly get ROS_INFO("Not enough features or parallax; Move device around");
Any tip on how we can solve it, apart for considering another bag? Any parameter we should look into given that we run at 240 Hz the IMU and have a different camera?
Thanks for your help
The focal length problem could be refered to HKUST-Aerial-Robotics/VINS-Fusion#76.
Give a stable movement to the device or enable static_init in config file could solve the ROS_INFO problem.
Modify parameters in config file according your own devices should work well.
Feel free to contact me, if there are any problem!
Hi there, I reviewed the code a bit and saw that there are a numbers of FOCAL_LENGTHS used around and 460 (which is equal to the focal length value here and few lines below that, here but also in keyframe.cpp, feature_manager.cpp, and estimator.cpp). It's not clear to me if I need to change the one in parameters.h (which is const here), and the one in keyframe.cpp here or any of those 460.
I suspect that also has to do with the missing initialization.
As mentioned here, 460 a virtual parameter and no need to change it.
You could turn on param static_init and show_track in the config file, check if the features in visualization are normal.
If static_init is false, it requires a movement of the device to initialize.
I also diable the code that deals with bleeding point few days ago(aaf7bde), which might lead to dropping number of features.
You might try pull the newest code, check if it work.
Sincerely sorry for that.
If it still not work, some visualization might help me to diagnose the problem. (try turn show_track on and have a screenshot on rviz)
Thanks a lot.
That parameter is a const double (NOT an extern one) however, so it stays 460 throughout all the runs. Moreover, i cannot find any place in which you overwrite it.
Also, I'm more concerned about those 460s around the code.
Also, this is definetly not virtual.
I did not overwrite it indeed.
In my view, 460 is kind of hyper parameter for ransac threshold or parallax calculation.
Therefore, it might affect some of the features' tracking but a threshold not theirs projection location.
For example, the function rejectWithF firstly uses liftProjective to lift feature point from the image plane to the projective space with actual intrinsic, and then uses FOCAL_LENGTH project to a virtual camera (only focal length change) for subsequent RANSAC.
It might help to adapt the system for more devices.
And I do think that replacing 460 with actual camera focal length would be beneficial.
While it may take some engineering work.
The code you mentioned is not used and looks like a redundant testing code.
Hope for more discussion, thank you!
Seems working after these changes! Thanks!