How watching the distance in meters in ORB_SLAM?

[StasiaS]

Hello! I have got a following issue.

In RVIZ distance in 0.3 meters and 7 meters shows how line same length. Those. on the screen are the same, but in reality, the second length 20 times greater than the first

Where can I see how much meters camera is go?

What units of measurements are used when displaying the path in RVIZ? Where in the code I can see it? Can I trust this mesurements in RVIZ?

[MarcGyongyosi]

there's something fundamental about monocular SLAM that you don't seem to understand. I would suggest to read a few papers on this issues - specifically how scale plays an important role in monocular vision systems.

[StasiaS]

Tell me, please, what I did not understand in monocular SLAM? What should I read? You want to say that it is impossible to know the exact distance using monocular SLAM?

[MarcGyongyosi]

Sorry if I sounded too harsh: there is a fundamental limitation with monocular SLAM in that you cannot recover absolute scale without some kind of external reference. Just try to cover one of your eyes for a while and you'll see how your depth perception will suddenly start fading away.

To solve this, some people try to recognize and measure known objects in the scene, others use EKFs with auxiliary states to calculate the scale of the VSLAM framework referenced to other sensors (e.g. an IMU), yet others do things like IMU pre-integration to recover the scale between key frames. No matter what, however, you won't be able to just get absolute scale out of ORB SLAM without modifications/ adding stuff on top.

[Loeing]

Well, if you think about how monocular feature based SLAM works, it uses features it extracts from images to build a mapping of a scene. It can only calculate the distance of points relative to one another rather than their actual depth. Theoretically, if you knew the exact distance between 2 different keyframes, you could calculate the actual depth of a point in the map.

[StasiaS]

MarcGyongyosi, Loeing thank you for your answers.

[StasiaS]

And, may be, I am asking another stupid question, but I meant, that this no-proportional distance was in the same shooting without turn the camera off or stop-programm ORB_SLAM.

[NikolausDemmel]

As others explained, the true scale cannot easily be observed. Moreover, the (arbitrary) scale of your reconstruction can drift over time, i.e. as your camera moves the difference to the true scale becomes larger or smaller. Depnding on your scnene and the type of movement this effect can be larger or smaller.

If you have a more specific question about a certain instance, where ORB SLAM looks like it failes, it might be good if you would provide some screenshots, videos, and/or rosbags with your data alongside your configuration.

[maym86]

Has anyone looked into adding scale from a measured object in a scene into ORB SLAM? Where in the code would this measurement be incorporated? Just starting to look at this problem myself and I saw this thread.

[cipri-tom]

@maym86 have you had any advances in incorporating a scale ? I'm also thinking of adding one base on some initial measurements. I am using ORB_SLAM on a robot so I am thinking of a way of forcing the 2nd frame of initialization to be taken after moving a known distance.

[ysunar]

@MarcGyongyosi Hi! I am very interested in the scale computing part as you mentioned. Besides the monocular camera, I have 2D odommetry date from encoders, and I am sure that the robot will just move and rotate on plat floor(2D)......Could you please give me some suggestions(or reference paper) about how to get a pricise scale? Thank you very much! REALLY hope your kindly reply!

[specyfick]

I think that this paper https://pixhawk.org/_media/modules/px4flow_paper.pdf na be used for computing a metric scale for transational movement.

[specyfick]

And this http://ieeexplore.ieee.org/document/7554983/

[tehass7]

A simple "work around" solution would be, initializing ORB SLAM on a two dimensional plane and getting the fixed co-ordinate frame "init_link" by finding the first key frame of features, visualizing the generated frame on rviz, then add the tf module on the side and you can observe the camera_pose relative to init_link, manually align the camera_pose child frame to init_link's frame. Echo the camera_pose topic , it should approximately read 0,0,0 in translation and the identity matrix in rotation. Then you set markers 1 m away from this point in all three directions. Move your camera to these points and observe the change in camera_pose. Calculate the ratio of the translation to the algorithm i.e the scale. This is an approximation and hence a workaround. It would of course be ideal to fuse sensors, such as the IMU and camera.