-
Notifications
You must be signed in to change notification settings - Fork 419
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
Local planner #546
Local planner #546
Conversation
…im into local-planner
Codecov Report
@@ Coverage Diff @@
## master #546 +/- ##
==========================================
+ Coverage 57.32% 57.35% +0.02%
==========================================
Files 129 130 +1
Lines 5739 5750 +11
Branches 84 84
==========================================
+ Hits 3290 3298 +8
- Misses 2449 2452 +3
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor comments. I'll wait for others to comment also. Nice docs. 👍
Curious about thrashing. Thrashing occurs in noisy action space when no combination of LEFT or RIGHT with FORWARD results in a better reward than constant collision? Looks like to fix this we just execute the entire pile of LEFT/RIGHT actions that build up and hope that the next iteration of search is better afterward?
For thrashing, it occurs when you enter a loop of left->right->left->right->left->right.... the way to get out of that is to take the best primitive and execute it fully instead of executing the first action and re-planning. For the situation you described (no action better than just colliding), that results in an error (the cpp code returns an ERROR token and python then throws an error). |
As a side note, I haven't seen a case where this thing actually thrashes. I am not sure if you actually need that logic since we have access to the ground truth navmesh to plan on, but its simple enough to have it :) |
@aclegg3 Can you double check esp::core::RigidState |
Looks good. Thanks! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The current greedy follower wasn't designed in a world were sliding was disabled and action noise existed, so it isn't great in those situations. This PR switches it out for a local motion primitive planner that does a considerably better job and also sets things up for action noise (by allowing the user to specify what key should be emitted for each action to take as the planner needs to plan on noiseless actions). Compared to the old one, there is a bump of ~0.02 SPL when sliding is enabled. When sliding is disabled however, SPL is increased from ~0.85 (with a ~12% failure rate) to ~0.95 (with a ~2% failure rate), which is much better.
Motivation and Context
The current greedy follower wasn't designed in a world were sliding was disabled and action noise existed, so it isn't great in those situations. This PR switches it out for a local motion primitive planner that does a considerably better job and also sets things up for action noise (by allowing the user to specify what key should be emitted for each action to take as the planner needs to plan on noiseless actions).
Compared to the old one, there is a bump of ~0.02 SPL when sliding is enabled. When sliding is disabled however, SPL is increased from ~0.85 (with a ~12% failure rate) to ~0.95 (with a ~2% failure rate), which is much better.
How Has This Been Tested
Via the tests!
Types of changes