[Other issue]: Does layout size is directly proportional to computational power (CPU usage)

[saksham07sk]

Before proceeding, is there an existing issue or discussion for this?

• I have done a search for similar issues and discussions.

Description

Hello everyone,

I have a layout with dimensions of 100m × 100m containing more than 2000 waypoints. My observation is that as the layout size increases, RMF requires significantly more computational power. Initially, I thought this was due to the simulators (Gazebo and RViz), but I tested by running the simulation and the RMF core on separate systems. Even then, the system running the RMF core showed a very high load (500+).

Also the prediction (schedule) goes on incrementing even if the robot is IDLE (Not moving as per planning)
Could someone explain the reason behind this high load?

Also tell me that any feature of RMF that is need to be Optimized, As per my views the optimization is must needed at this stage of development.

[mxgrey]

containing more than 2000 waypoints

This will have the most significant impact on CPU load. Naturally the cost of motion planning increases as a graph gets larger because the branching factor will be bigger. There are techniques to mitigate this, but they're often very situational and can't be applied to all users. That's why in our next generation we're developing general traffic management interfaces that will allow users to plug in their own traffic planners that are tailored to their use cases.

Also the prediction (schedule) goes on incrementing even if the robot is IDLE

A robot that isn't moving anywhere should be dropped from the traffic schedule unless you have the "responsive wait" feature turned on. Responsive wait will keep the robots active on the schedule, but that's the whole point of having responsive wait active. Otherwise idle robots should be cleared from the schedule. You'll see some very light schedule-related activity, but that's like a heartbeat to make sure that everything is still communicated as intended.

Could someone explain the reason behind this high load?

We're happy to get detailed reports of scenarios where CPU load is high with heatmaps the tell us which operations are taking up more CPU load than they need to, but these reports need to be detailed enough for us to take direct action. Ideally interested community members should submit PRs with the necessary improvements. The current code base is being ramped down in favor of the next generation development, which is where we're focusing the bulk of our effort.