-
Notifications
You must be signed in to change notification settings - Fork 85
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
Parking AI confused in large parking lots #1626
Conversation
- renamed LoopUtil clockwise to counterclockwise since it was CCW all along. - added LoopUtil clockwise - adjusted spiral.cs to hold both, CW and CCW data and enumerators - added tests and stuff
…omizer instance instead of accessing it every iteration
No more low-hanging fruits. Ready for review. |
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.
Code looks fine, but how do I test the parking? They parked before, they park now, how do I know it works?
Probably the easiest way is to observe parking spots that have two potential entrances, one banned for cars and much closer then other one not restricted but objectively requires longer path. Before the fix they were more likely to stop moving before entering restricted segment and fly the remaining distance to the parking spot. Now they should take longer, more realistic route and also fly only if necessary (e.g. only within the segment width/length). Example scenario where I actually noticed the problem and tested it multiple times: cim going from blue building. Parking spaces are only available at the top. Red path is possible with old version (8/10 attempts), green is when using this version. Notice car ban. |
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.
👍
Fixes #924, fixes #423, fixes #352, fixes #1394
Proposed change should result in better detection of end PathPosition which vehicle should reach before starts flying to parking spot. It's not perfect solution but user reports say that change in behavior is significant and parking location decisions are much better compared to current public version.
I'm not entirely sure if we should completely remove
endPos
argument or only for specific cases like e.g.: residents calculating parking spot in advance to mimic the case: "I live in that city long time, I know best parking spots"Update (4th Aug/22):
PathPosition
search (new end position before car switch to "drifting mode")Build zip