direct_lidar_inertial_odometry
direct_lidar_inertial_odometry copied to clipboard
vectr-ucla
CPU load
Hello,
First of all thanks for a great paper and code, very easy to use and produced great results! I just wondered where I can set it to use a constant number of cpu cores? When downsampling the pointcloud I of course got lower computation time but the number of cpu cores used and cpu load also decreased, to further decrease computation time I would like to increase the number of cpu cores used. I tried changing the num_threads variable but that didn't change anything in the debug output, any idea of where I could change this or if this even is an option?
Hi @aronasefaw -- the debug output just shows your CPU specs (total number of cores), and not the number of cores being used by DLIO. Changing the num_threads variable should do the trick, and you can verify this by checking htop.
Hey @kennyjchen -- with debug output i meant this screen, the value "Cores Utilized". There you can see the number of cores being used by DLIO right? And thats the value thats not increasing when increasing the num_threads variable, as well as the computation time not decreasing.
Ah gotcha -- do you have OpenMP installed? If the system can't find it, it will default to one core. If not, try sudo apt install libomp-dev.
Yes OpenMP is installed so it doesn't default to one core, at minimum computation time without a big loss in accuracy (~25ms with a AGX Xavier) we got 0.8 cores utilised at 10% CPU Load which is what I would like to increase to at least 3 cores utilised to further decrease computation time
Ping on this issue again @kennyjchen, would really need this to make the package feasible for us in real time applications
I'll have to look a little more in depth for this, but the way DLIO currently calculates Cores Utilized is by multiplying CPU usages by the number of cores allotted. So it may be that all cores are engaged but the resources required per core is low, so the number is smaller than the total number of cores. There's probably a better (more intuitive) way to provide this information. From my understanding, if you properly set the number of threads for OpenMP, then it should be engaging all of them regardless of what it says in the terminal output.
I tested the DLIO node in ROS and it seems to me that the values displayed in the CPU Load window are not correct. On 10 cores (omp_get_max_threads() / 2;), CPU load is usually 10%; on 19, it’s about 8-9%, and when all cores are loaded, for some reason it becomes 0.1%, i.e. does it essentially stop displaying correctly and only show CPU load from Linux? At the same time, my system physically has only 10 cores and 20 threads due to Hyper-Threading.
It is also curious that this node does not work on 20 streams without ROS because due to delays it self slows down the data flow from the lidar and even the high priority of this stream (and lowering the priorities of DLIO streams) does not completely solve this problem and measurements from the imu coming with a frequency of 5ms or 200Hz can be delayed and come with an interval of 10-100ns several times in a row. If DLIO streams are less than 20, for example 10, it will work as usual, but if the third party application (sysbench) captures all 20 streams, the situation will repeat, it is curious that this is not observed in the ROS node as if it has a real-time priority.
Qt .pro ROS free node&livox2 SDK untitled_odom.zip
