OpenVSLAM uses too much CPU

[surfii3z]

Have anyone tried using OpenVSLAM in RGBD mode?

I tried to use it with Intel Realsense D435i. it uses CPU like 1000%, which I find it weirded.

Have anyone experience the same issue?

[ThomasHauth]

Are you running on Windows? I have seen some heavy CPU use when using the g2o library on windows in multi-threaded mode.

[surfii3z]

Hi @ThomasHauth , thanks for your reply.

I am running OpenVSLAM on ROS-melodic, Ubuntu 18.04.

[ymd-stella]

Can you post the output of the top command?

[surfii3z]

In the video,

• the first line is openVSLAM process
• the second line is packnet_sfm (depth estimation network process).

I also run RGBD ORB_SLAM2 ROS node with the exact same setting and it doesn't seem to have this problem.

Probably, there should be a bug somewhere.

[ymd-stella]

In my opinion, that level of CPU usage is within the range of normal operation.
I am more concerned about the large track time.
Please check the Feature.max_num_keypoints and image size.

The results of the RGB-D experiment in my environment are shown below.

• CPU specs: Intel(R) Core(TM) i5-8400 CPU @ 2.80GHz (6-Core)
• Build: Release (Dockerfile.socket)
• Dataset: fr2/large_with_loop (https://vision.in.tum.de/data/datasets/rgbd-dataset/download )

$ ./run_tum_rgbd_slam -v /host/data/orb_vocab/orb_vocab.fbow -c ../example/tum_rgbd/TUM_RGBD_rgbd_2.yaml --no-sleep -d /host/data/rgbd_dataset_freiburg2_large_with_loop --auto-term
[2021-04-18 07:13:26.455] [I] config file loaded: ../example/tum_rgbd/TUM_RGBD_rgbd_2.yaml
  ___               __   _____ _      _   __  __ 
 / _ \ _ __  ___ _ _\ \ / / __| |    /_\ |  \/  |
| (_) | '_ \/ -_) ' \\ V /\__ \ |__ / _ \| |\/| |
 \___/| .__/\___|_||_|\_/ |___/____/_/ \_\_|  |_|
      |_|                                        

Copyright (C) 2019,
National Institute of Advanced Industrial Science and Technology (AIST)
All rights reserved.

This is free software,
and you are welcome to redistribute it under certain conditions.
See the LICENSE file.

Camera Configuration:
- name: TUM-RGBD RGBD 02
- setup: RGBD
- fps: 30
- cols: 640
- rows: 480
- color: RGB
- model: Perspective
  - fx: 520.909
  - fy: 521.007
  - cx: 325.141
  - cy: 249.702
  - k1: 0.231222
  - k2: -0.784899
  - p1: -0.003257
  - p2: -0.000105
  - k3: 0.917205
  - min x: 12.0751
  - max x: 629.418
  - min y: 11.4294
  - max y: 473.101

ORB Configuration:
- number of keypoints: 1200
- initial number of keypoints: 2400
- scale factor: 1.2
- number of levels: 8
- initial fast threshold: 20
- minimum fast threshold: 7

Stereo Configuration:
- true baseline: 0.0767889
- true depth threshold: 3.07156
- depth threshold factor: 40

Depth Image Configuration:
- depthmap factor: 5000

Other Configuration:
  PangolinViewer:
  - camera_line_width: 3
  - camera_size: 0.08
  - graph_line_width: 1
  - keyframe_line_width: 1
  - keyframe_size: 0.05
  - point_size: 2
  - viewpoint_f: 400
  - viewpoint_x: 0
  - viewpoint_y: -0.9
  - viewpoint_z: -1.9

...

median tracking time: 0.0262245[s]
mean tracking time: 0.0272987[s]

top - 16:20:05 up 42 days,  4:20,  0 users,  load average: 1.38, 2.38, 2.28
Tasks: 271 total,   1 running, 209 sleeping,   0 stopped,   0 zombie
%Cpu0  :  50.5/3.9    54[||||||||||||||||||||||||||||||||||||||||||||||||||||||                                              ]
%Cpu1  :  54.5/3.0    57[|||||||||||||||||||||||||||||||||||||||||||||||||||||||||                                           ]
%Cpu2  :  51.3/3.5    55[|||||||||||||||||||||||||||||||||||||||||||||||||||||||                                             ]
%Cpu3  :  45.2/4.0    49[|||||||||||||||||||||||||||||||||||||||||||||||||                                                   ]
%Cpu4  :  51.3/3.2    54[||||||||||||||||||||||||||||||||||||||||||||||||||||||                                              ]
%Cpu5  :  58.4/3.3    62[|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||                                       ]
KiB Mem : 39.7/7788792  [|||||||||||||||||||||||||||||||||||||||                                                             ]
KiB Swap: 10.0/2097148  [||||||||||                                                                                          ]

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                                                                                                         
23939 root      20   0 1558432 200628  19740 S 329.0  2.6   1:23.05 run_tum_rgbd_sl 

[ymd-stella]

But you could see the quick example from this youtube video of mine

In that video, the track time of OpenVSLAM is clearly slower than ORB_SLAM2.
Play it back at low speed and count the number of frames.

[surfii3z]

Thanks for your effortful experiment and comment @ymd-stella.

The parameters in that experiment are

Camera.cols: 1226
Camera.rows: 370

Feature.max_num_keypoints: 1000

Which are the same for both OpenVSLAM and ORB_SLAM2.

[surfii3z]

But you could see the quick example from this youtube video of mine

In that video, the track time of OpenVSLAM is clearly slower than ORB_SLAM2.
Play it back at low speed and count the number of frames.

Yeah, and I wonder why it is like that.

[ymd-stella]

I'm interested in the following

• CPU specs
• Release build or debug build
• Dataset and config file used for verification
• Whether --no-sleep is enabled or not

[surfii3z]

• CPU specs: Intel Xeon E5-2698 v4 2.2 GHz (40-Core)
• Build: I think it is a release build in the video. (However, I cannot confirm)
• Dataset: Kitti odometry gray sequence 07 with depth image from packnet-sfm.
• there is no --no-sleep as I am running a ROS node.

[ymd-stella]

If you have built g2o with -DG2O_USE_OPENMP=ON, try -DG2O_USE_OPENMP=OFF.

[surfii3z]

Thanks for your advice, I will let you know when I tried it

[ThomasHauth]

One other reason you see a high CPU-usage might be because OpenCV will try to use all available CPUs for processing. Your machine has a lot of CPUs (40) where this parallelization might not be that efficient any more. You can limit OpenCV's parallelism with
this command:
cv::setNumThreads(8)
https://docs.opencv.org/4.5.2/db/de0/group__core__utils.html#gae78625c3c2aa9e0b83ed31b73c6549c0

So OpenCV will just use 8 threads now. This will limit the occupancy of your cores. At the same time you can see if the frame gets slower by this change or not.
And as @ymd-stella proposed, try turning off G2O parallelism as I have seen some bad behavior of this feature before.

Cheers.

[ymd-stella]

When building OpenCV with TBB enabled, the load could be reduced under certain conditions.