Closed struggler-lu closed 1 year ago
Hi,
The computation times were obtained using the code we provided. However we used a more powerful computer than yours (an Intel Core i7-4790 with 8 cores and 16GB of RAM).
It seems that also the planner by OMPL are off (e.g. RRT* from 1.59 ms to 20.92 ms). Did you build the planner in debug mode?
CC: @maede97
Thank you for your answer.I am a new user of the OMPL,So I am also very grateful for your open-source code, which taught me how to use the OMPL. I install the OMPL by running "sudo apt install ros-noetic-ompl".How should I confirm that the planner by OMPL are off?
What I meant with "It seems that also the planner by OMPL are off" was that the timings of those planners are not the same ones as in the paper. I think this indicates that the problem is mostly related to the computational power of your machine.
Did you check if you built the code in Release
mode?
Yeah! When I built the code in Release mode,I found that the computation time is much less than before.Thanks again for your help. If it be convenient to you, could you give me some suggestions on learning robot motion planning?
Glad to hear that!
Regarding your question: I think the best way would be to look at the ROS move_base
packages, where a lot of planners have been implemented. Personally, I haven't really got a good book reference, but you could start reading scientific articles / lecture notes about the typical planners (search on google or google scholar), like sampling-based (e.g. RRT) or optimization-based (MPC).
If you want to get started immediately, you can have a look at this repo. Hope this helps.
I will close the issue, as now it is not related to the code anymore.
Thank you for taking the time to answer my question and provide guidance!
How was the computation time obtained in the paper? How were the parameters of the planning algorithm set? For example, when I was running benchmarking/study/study_dynamic_obstacles.cpp and the following parameters were set: b1->numNodes = 1300; // TODO: CHANGE HERE (number of nodes of T-PRM) for (int i : {10}) { // TODO: CHANGE HERE (number of obstacles) b1->is_2d = false; // TODO: CHANGE HERE FOR 3D
The obtained computation time results were as follows: T-PRM: 98135 microseconds OMPL PRM: 143930 microseconds OMPL RRTstar: 20915 microseconds
There seems to be significant differences compared to the corresponding computation time values in Table 2 of the paper. My hardware environment consists of an Intel Core i5-12400F with 16GB RAM. Could you please tell me the reason for the possible error?