-
Notifications
You must be signed in to change notification settings - Fork 49
Criterion for judging effective parameters #2
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
Comments
In the path, I am using Hope that answers your question! |
Thank you for your reply! In fact, I tried to cancel this condition before running the code. It turned out more paths appeared in the diagram. So I wonder if the code is incorrectly ignoring some possible paths? In my understanding, the code should find all possible paths and then choose the best one. |
You seem right, I found a route where adding these missing paths was more optimal. Thank you for finding that! Path lengths shouldn't be negative though, according to the paper, i'll doublecheck the formula when I have some time. |
In paper the total length is calculated as below for example:
I think the absolute value sign here implies that t, u, and v could possibly be negative. In other cases, the authors even give explicit assumptions that the values can be negative: As a corroboration, the algorithm implemented in OMPL library uses absolute value as well: L = fabs(t) + fabs(u) + fabs(v) However, I do notice that in some other resources the positive condition is mentioned: Besides, I find that the optimal path length shown in code output is identical with or without the positive condition. (This result seems convincing) So, I'm now confused about this positive condition too. I did not study further math of the paper to confirm it. I hope you can look into this issue at your convenience. Best wishes! |
By the way, I created a new repo to study your code and made some minor modifications. A bug found: |
@XinArkh |
@XinArkh I did a quick test and generated paths from a few dozens random points, turns out I actually found some more optimal paths when removing the positivity conditions. I do not currently have time to investigate this more in depth, but it shouldn't hurt to remove the conditions (which @benjaminbecker did, thank you!) since it is still RS paths that are generated in the end (though there might be more duplicates). |
Thank you for your reply! @benjaminbecker I will see it later. |
@benjaminbecker I have read your repo and believe it is an elegant way to solve the problems mentioned above. I also learned some cool Pythonic coding styles from it. Thanks again! By the way, I've noticed an interesting fact that the |
@XinArkh By length, do you mean PathElement.param? If so, seems normal to me that a length remains positive, as the sign is handled through the forwards/backwards gear. |
@nathanlct Yes, what I mean is param. An example is shown below (p1=[-6, -7, 0], p2=[-6, 0, 3.14]):
|
So what you're saying is that if you generate random points (without the missing deepcopy mentioned above), you never get more optimal paths by removing the >0 conditions? |
@nathanlct I think there are slight differences. We should remove >0 condition for sure. (I guess) The key point is that timeflip() and reflect() would generate a set of derived paths related to the calculated path. I think one of these derived paths contributes to the optimal path, which has a positive length value. |
@XinArkh Got it. I'll read through the paper more carefully when I get some time. In the meantime I merged @benjaminbecker's fixes, and we shouldn't be missing any optimal path by removing the conditions, worst case we get duplicates. |
Thank you for the work in advance. I have some confusions when reading the code. From
path1()
topath12()
, all the calculated t, u, and v values are judged whether they are all positive:Could you give further explanation why this criterion is applied?
The text was updated successfully, but these errors were encountered: