Open liquidmetal9015 opened 5 years ago
JNeiger
commented
5 years ago I will also say trying to do any path planning near opponent robots to move around them is sketchy iirc. You have to do a wide birth around them, then you can run the normal stuff
liquidmetal9015
commented
5 years ago I think another issue brought up during the October simulation testing session can also fall under this and was partially mentioned in this issue:
Its the decision of sub-optimal approach paths to the ball. I could honestly envision a solution to this problem that would effectively band-aid the first problem in that if you choose an point that does not require sharp turns and is clear of obstacles we could probably comfortably use the current capture logic. A more tame example is shown below:
You might be able to get multiple paths to the capture phase start point and check their smoothness. Or just check a full line from start to end of the fine capture motion and try to find one that is clear of obstacles. Or do both. This incredibly shitty MS paint diagram illustrates my possible idea:
Check that a given blue line is clear and check something about the path (red lines) that would be required to get to the start of that line. The major idea would be that you check or path plan for a bunch of them and choose the best ones. Checking if there is a direct line of sight between the robot and the starting point of the fine approach might also be a decent idea as it would prevent trying to go around opposing robots to get to the start point.
Or do both, but in the end we need a better way of handling this whether that is a band-aid in the shorter term or fully multiple capture implementations.
@JNeiger would be the one to talk to about it.
JNeiger
commented
5 years ago The cleaner way imo would be would be to plan to the ball, not counting the ball as an obstacle. Using that path, you can step backwards X meters and find a point to move towards. This would replace the current intermediate point that we use as the transition between course and fine approach. It shouldn't actually be super hard to implement and will leverage the "best" path our path planner can produce to get to the ball
Description
Captures behavior does not currently handle being in close proximity to obstacles. Namely once it gets close enough to the ball, it disregards all obstacles and travels in a straight line. It also only path plans to this point a set distance away from the ball, regardless of if there is something between that point and the ball. This often leads to situations in which the capturing robot is trying to go through another robot.
Steps to reproduce
Result: The capturing robot will attempt to move through the opposing robot
Additional information
This might be able to be fixed by using a fall back, or as suggested by adding a system to select multiple types of capture depending on the situation. I believe Joe had an "Behavior Based Capture" design document that might be relevant.