Processing time for gmapping
I'm currently using gmapping to generate maps.
I would like to measure the processing time of gmapping. I'm measuring the processing time from the start to the end of laserCallback() in the gmapping code, and the result is about 3~5 seconds. This seems to be too large a value.
Next, I did a rostopic hz /map, and got a value of about 0.4~0.6. I think it is still too small. Has anyone measured the processing time for gmapping? I would like to know the true value and how to measure it.
I am using a gaming PC with a GPU.
I don't know if it's possible, but I don't have enough experience. Therefore, I would like to get your advice on how to perform this task. Thank you in advance I don't know if it's possible, but I don't have enough experience.
It's interesting. I've never measured it, but I've thought about it.
First of all, I thought that the long time for laserCallback might be due to the fact that output by
ROS_DEBUGis enabled to measure the processing time. https://github.com/ros-perception/sla...Next, I thought that the /map cycle is not too short, depending on the size of the map. Or it may be set to issue /map at regular intervals even when the map is not being updated.
To begin with, it should be clear what part of gmappiing you want to measure. I thought you might want to measure the time it takes to process the scan and create the map, but I wasn't sure.
Thanks for the reply. You're right, I didn't make it clear what part of gmapping I wanted to measure the processing time for.
I'm trying to calculate the overall computational speed of gmapping. When I read the code, it basically loops around the LaserCallback() part, so I thought if I could measure this part, I could calculate the overall calculation speed.
As for the scan matching, I think it is the function in line 606 of slam_gmapping.cpp, and when I measured the processing time of this part, I found it to be about 3 seconds. So I think that the processing time of this part is unusually long. Is there any reason for this? As for the map update, it is the function in line 646, and I think that the update time becomes longer as the map becomes larger.
I think it is true that the update time depends on the size of the map. So, the map size is 0.1 times the values of x_min, x_max, y_min and y_max described in slam_gmapping.cpp. Also, after referring to various sites, I wonder if the correct answer is that using rostopic hz /map gives about 2.6Hz (1), and the following paper gives a result of about 25fps (2), and I am having trouble finding the true value (as for the paper I think they are using Hector SLAM...)
(1) https://blog.csdn.net/tiancailx/artic... (2) https://www.ncbi.nlm.nih.gov/pmc/arti...
This is a long description of the results of my research, but I hope it will help you to think about it. I look forward to your reply.
I think it's normal for point clouds to take a long time to process. We are calculating how well the input points match the past points, and whether the discrepancies are noise or part of the new map. Therefore, it makes sense that the larger the map is, the larger the processing time will be.
The processing time is also affected by the specs of your machine and the software you are running at the same time. In other words, it is somehow different from other papers.
I feel that the purpose of measuring the processing time also needs to be clarified. Are you investigating which of the several SLAMs has the shortest execution time? Or do you want to see what happens to the execution time when you change the parameters of the gmapping?
If it is the latter, I think I can investigate it by changing the ...(more)
I think you're right about the PC specs and other software taking up resources. Therefore, I use rosbag to get the input information needed for gmapping, and the only nodes running are rosbag play and gmapping, which is how I do my measurements.
So I think that this method of measurement will give values close to those in other papers.
As for the purpose of the gmapping measurements, I have taken a further approach to the existing 2DSLAM and constructed a 2.5DSLAM system. I would like to compare and evaluate the processing speed of 2DSLAM, 2.5DSLAM, and 3DSLAM. Therefore, I would like to measure the overall computational speed of gmapping. Thank you very much for all your suggestions.
I'm glad you found it useful. If you get results and the information is shareable, please share it on Discourse.
Hello. I would like to ask if you have find the answer. Can you share the answer or the link of the paper that you have publish about this? Thank you in advance