Speed of the robot is slow
bairuofei opened this issue · comments
Hi, when I run nav2d in RVIZ simulation, I find sometimes the robot moves very slowly, even in the open environment. Because of that, I have to spend lots of time running the simulation. The nav2d_navigator outputs warning messages like "Missed desired rate of 5.00Hz! Loop actually took 0.6000 seconds!", but I found that in the source code, there is no special treatment for this warning.
May I know what I can do to improve that? Will other threads like nav2d_karto or nav2d_exploration influence it?
When a node cannot keep its update rate, this usually means that there is too much load on the CPU. It's likely that the simulation is also unable to keep up and that's why you are seeing this slowdown. What hardware are you using? Have you tried running the simulation and the ROS stack on different machines?
Thanks for the reply. The simulation runs on my laptop with i7-12700H CPU. The hardware may be one possible cause of this problem, because in my simulation the update of exploration frontiers also has some delay. Currently, I do not have another machine and I will update once possible.
I have tested it on another workstation with i9-13900, and the speed of the robot still becomes very slow sometimes. Maybe I will go back to this problem in the future.
Hi @skasperski , I find the reason why the robot moves slowly. When I open the costmap, I found that although the robot is moving in free space according to the SLAM map, the space are mostly unknown in costmap. You can observe this situation in the following image (the background is the SLAM built map, the small square map is the costmap from topic /Operator/local_map/costmap). I am not sure why this happens. Could you please give me some suggestions to handle this so that the robot can move faster in the simulation?
Sure, that's a common problem, also on real systems. This happens because there are no obstacles in front of the robot within the range of the laser scanner. So there is no laser signal received and in that case no clearing of the costmap is performed either. What you can do is to increase the range of the simulated scanner or put more obstacles into the scene.
Of course you could change how zero-readings are handled to assume that there is no obstacle within range when no signal is received. But this is usually not done, because there can be many reasons for zero-readings (black obstacle, diffusion, interference). That's why zero-readings are commonly treated as non-existend, e.g. the costmap is left with unknown cells.