Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Segmentation fault #2

Open
vyi opened this issue Jun 21, 2019 · 6 comments
Open

Segmentation fault #2

vyi opened this issue Jun 21, 2019 · 6 comments

Comments

@vyi
Copy link

vyi commented Jun 21, 2019

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
Copy link
Owner

Trying execution multiple times may solve it.

@vyi
Copy link
Author

vyi commented Jun 25, 2019

@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?

@IshitaTakeshi
Copy link
Owner

  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
Copy link
Author

vyi commented Jun 25, 2019

@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
Copy link

@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
Copy link
Author

vyi commented Jul 4, 2019

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants