IshitaTakeshi / lsd_slam_noros

ROS-independent implementation of LSD-SLAM
GNU General Public License v3.0
21 stars 7 forks source link

Segmentation fault #2

Open vyi opened 5 years ago

vyi commented 5 years ago
path to images : /home/vyi/Documents/2019/June/Milestones/0:14_June_2019/dataset/data/sequence_30/images/
Reading Calibration from file /home/vyi/Documents/2019/June/Milestones/0:14_June_2019/dataset/data/sequence_30/camera.txt ... found!
found ATAN camera model, building rectifier.
Input resolution: 1280 1024
In: 0.535719 0.669567 0.493249 0.500409 0.897966
Out: Crop
Output resolution: 640 480
new K: 277.523987 291.680328 312.474304 240.035583
old K: 685.720764 685.636475 630.858154 511.918457
Prepped Warp matrices
Done : undistorter
Now going to create system!
Segmentation fault (core dumped)

The system seg_faults when it reaches the following section (in file main_on_images.cc)


    // make slam system
    std::cout << "Now going to create system!" << std::endl;
    SlamSystem* system = new SlamSystem(w, h, K, doSlam);
    std::cout << "Done : Created system!" << std::endl;

Any suggestions to make it work?

IshitaTakeshi commented 5 years ago

Trying execution multiple times may solve it.

vyi commented 5 years ago

@IshitaTakeshi I used gdb to localize the source of error in the code. The error disappears when I comment out the following lines in key_frame_graph.cc file

    //solver->setWriteDebug(true);
    //blockSolver->setWriteDebug(true);

1) Can you explain why the above two lines are causing seg_fault? (Are these methods renamed/deprecated in the newer g2o?)

Some extra information

To make the code compile, I had earlier done the following modification to the code.

Original code :

  typedef g2o::BlockSolver_7_3 BlockSolver;
  typedef g2o::LinearSolverCSparse<BlockSolver::PoseMatrixType> LinearSolver;
  LinearSolver* solver = new LinearSolver();
  BlockSolver* blockSolver = new BlockSolver(solver);
  g2o::OptimizationAlgorithmLevenberg* algorithm = new
  g2o::OptimizationAlgorithmLevenberg(blockSolver);

Modified code

  std::unique_ptr<g2o::BlockSolver_7_3::LinearSolverType> solver (new   g2o::LinearSolverCSparse<g2o::BlockSolver_7_3::PoseMatrixType>());
  std::unique_ptr<g2o::BlockSolver_7_3> blockSolver (new g2o::BlockSolver_7_3(std::move(solver)));

  g2o::OptimizationAlgorithmLevenberg * algorithm = new g2o::OptimizationAlgorithmLevenberg(std::move(blockSolver));

With these changes the code compiled but was crashing (seg_fault). Now, after commenting the above said two line the code is executing well. I tested by running on the sequence 30.

I want to ask you few things.

2) When the code (main_on_images) is executed does it save the map? I can't find any map after the code finished on image sequence.

3) Is there any progress in Map visualization part? Can we see the map created by the program?

IshitaTakeshi commented 5 years ago
  1. Please note that this is a forked repository. The main code is written by TUM. What I did is to resolve the dependencies and run the code that couldn't run. I agree that the code is messy in some parts.
  2. I have added a map saving part to the refactor branch. I think you can build it in the same manner. If the build failed, please open another issue.
  3. Visualization is not available currently because I'm not familiar to OpenGL / other visualizer tools. Instead, the map saving part can export a pointcloud to a file so you can see it using a visualizer app, etc.
vyi commented 5 years ago

@IshitaTakeshi Thanks for your reply.
I am aware this is a fork from the TUM LSD-slam repo. Your repo is relevant for me because I want to use LSD-slam without ROS. I am able to build your code without the docker.

I will now be looking into the refactor branch to see how the map generation work. If time permits please do add more details about the map generation in the markdown of refactor branch.

Thanks a lot.

mongrelgem commented 5 years ago

@IshitaTakeshi I used gdb to localize the source of error in the code. The error disappears when I comment out the following lines in key_frame_graph.cc file

    //solver->setWriteDebug(true);
    //blockSolver->setWriteDebug(true);
1. Can you explain why the above two lines are causing seg_fault? (Are these methods renamed/deprecated in the newer g2o?)

Some extra information

To make the code compile, I had earlier done the following modification to the code.

Original code :

  typedef g2o::BlockSolver_7_3 BlockSolver;
  typedef g2o::LinearSolverCSparse<BlockSolver::PoseMatrixType> LinearSolver;
  LinearSolver* solver = new LinearSolver();
  BlockSolver* blockSolver = new BlockSolver(solver);
  g2o::OptimizationAlgorithmLevenberg* algorithm = new
  g2o::OptimizationAlgorithmLevenberg(blockSolver);

Modified code

  std::unique_ptr<g2o::BlockSolver_7_3::LinearSolverType> solver (new   g2o::LinearSolverCSparse<g2o::BlockSolver_7_3::PoseMatrixType>());
  std::unique_ptr<g2o::BlockSolver_7_3> blockSolver (new g2o::BlockSolver_7_3(std::move(solver)));

  g2o::OptimizationAlgorithmLevenberg * algorithm = new g2o::OptimizationAlgorithmLevenberg(std::move(blockSolver));

With these changes the code compiled but was crashing (seg_fault). Now, after commenting the above said two line the code is executing well. I tested by running on the sequence 30.

I want to ask you few things.

1. When the code (`main_on_images`) is executed does it save the map? I can't find any map after the code finished on image sequence.

2. Is there any progress in Map visualization part? Can we see the map created by the program?

I faced a similar issue. I used valgrind to find countless memory leaks with regards to pointer allocation and deallocation. The problem is not these two lines but the block of code above it. There were various issues related to pointer allocation and deallocation mainly stemming from how g2o( current version ) and eigen are used. I suggest looking at these or installing previous versions of g2o and eigen.

vyi commented 5 years ago

@mongrelgem Thanks for you inputs. I think I don't want to use the older version of the libraries so I will try looking into the memory leaks issue. Just that my C++ is not that very sharp as of now but I am learning bit by bit.