-
Notifications
You must be signed in to change notification settings - Fork 221
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CBS on roadmap finds suboptimal solution #40
Comments
Could you include the command line you used to generate the output from the input? |
|
(This is the mapf/c branch). From a CBS perspective, both results are actually identical (and optimal), because the cost is the sum of the timesteps of all robots. If agent0 moves 13 -> 0 -> 14, or 13 -> 8 -> 14 would both be a cost of 2, independent of the edge length. I assume that you are actually interested in a solution that doesn't minimize the sum-of-time, but sum-of-pathlength? |
Exactly 😁. I am interested in the shortest path length solution.
…On Mon, 30 May 2022, 17:01 Wolfgang Hönig, ***@***.***> wrote:
(This is the mapf/c branch).
From a CBS perspective, both results are actually identical (and optimal),
because the cost is the sum of the timesteps of all robots. If agent0 moves
13 -> 0 -> 14, or 13 -> 8 -> 14 would both be a cost of 2, independent of
the edge length. I assume that you are actually interested in a solution
that doesn't minimize the sum-of-time, but sum-of-pathlength?
—
Reply to this email directly, view it on GitHub
<#40 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABVHERI4RBDPSF55K3DKP23VMTJ2VANCNFSM5WFOV7TQ>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
What is the cost for self-loops then? For example, your graph has edges In principle, CBS can easily use a different cost function, but the fundamental assumption that only one edge per "timestep" can be moved will remain the same. For non-uniform edges this means that the agent will essentially move with different speeds along the graph. |
Also, should the path length be just a tie breaker? For example, is |
Honestly, I don't know. I guess the tie-break would work best my current use. I think it would be enough if, if there are two options of equal timestep length, it would choose the one with the shorter path length. |
I think optimizing for length equates to minimizing energy consumption. Because if the agent has to travel longer in the same time it will consume more energy (quadratically more in the most basic assumption) |
Yes lets discuss tomorrow! I have implementations for multiple versions. The tie-breaking variant computes what you wanted in this particular example. The other variant (with a little hack to avoid self-loops) seems to find a shorter path, but the total number of timesteps is higher. When not using a self-loop avoid hack, the solutions tend to be very long and use (zero-cost) self-loops, which I don't think is the intended use-case here. Energy: This is complicated and depends on the robot. Typically you use energy just by time (for powering computers, sensors etc.), and kinetic energy when moving. However, the kinetic energy might also depend on the motion profile (e.g., high speed -> more energy; accelerations -> more energy). |
The version with the new cost function (min path length and count self-loops like the shortest edge in the graph) is now available in the issue40 branch (see #41 for a diff). Feel free to play around with |
This is the solution of CBS:
This is a better (shorter) solution:
yaml input (after annotation):
leads to this output:
The shorter solution sends
agent0
tov: 8
att: 1
The text was updated successfully, but these errors were encountered: