Fly by angle - #25
Conversation
Adds an untested method to face the target from a specified distance.
…gipsy-danger into competition_vision_test
cugarte
left a comment
cugarte
left a comment
There was a problem hiding this comment.
Thanks for adding the comments, Henry. They certainly help. I'd suggest adding an overall strategy description at the class level for both AimAtTarget and DriveToTarget. For the latter, something along the lines of "Provides two approaches to automate driving towards a target. Based on the skew/distance to the target, this will choose an aggressive approach which will ... or a normal approach which will ...".
| Collections.max(temp, (Point pt1, Point pt2)->Double.compare(-pt1.x + pt1.y, -pt2.x + pt2.y)), | ||
| Collections.max(temp, (Point pt1, Point pt2)->Double.compare( pt1.x + pt1.y, pt2.x + pt2.y)), | ||
| Collections.max(temp, (Point pt1, Point pt2)->Double.compare( pt1.x - pt1.y, pt2.x - pt2.y))); | ||
| topLeft = Collections.max(temp, (Point pt1, Point pt2)->Double.compare(-pt1.x - pt1.y, -pt2.x - pt2.y)); |
There was a problem hiding this comment.
Not sure I follow how this determines top vs bottom and left vs right. IIRC you mentioned that the limelight provides an array of four coordinates with no guarantees of which is which. This section seems to reduce each coordinate (an x,y pair) to a synthesized/unary double value which is then compared against the other synthesized/scalar doubles from temp. Perhaps this is just too clever for me (or makes use of certain knowledge about the coordinates always being positive, etc.) to guarantee that it is correct? I suggest for an explanation/comment assuming that this does indeed work (which it seems to).
There was a problem hiding this comment.
I'll add this in a comment as well:
The coordinate system is (x,y) down and over from the top left hand corner. I then maximize on certain values to find the certain points, like the "top-leftest" point of the collection. In the top-left case we would expect the y coordinate to be low (so the point is high up), and the x coordinate to be low (so the point is off to the left). Thus, if we take the value (-x-y), points to the left or below should be more negative (bigger x or y coordinate making the calculated value more negative), so the top-leftest point is the least negative, or the maximal value of (-x-y). Geometrically, this is equivalent to sweeping a line at 45 degrees out from each corner across the image and picking the point it hits first.
| static final double aggressiveSkewThreshold = 15; //TODO: Tune | ||
| static final double maxOffsetAggressive = 25; //TODO: Tune | ||
| static final double maxOffsetNormal = 12.5; | ||
| static final double maxOffsetDistance = 6.0; |
There was a problem hiding this comment.
All in feet unless otherwise noted. I'll add a comment at the top if it's not there already.
| */ | ||
|
|
||
| static final double aggressiveSkewThreshold = 15; //TODO: Tune | ||
| static final double maxOffsetAggressive = 25; //TODO: Tune |
There was a problem hiding this comment.
All in degrees, there should've been a comment at the top that says as much.
There was a problem hiding this comment.
I must've left it out.
| Robot.drivetrain.shift(Gear.kLow); | ||
| pidController.setOutputRange(-maxOutput, maxOutput); | ||
|
|
||
| contour = Limelight.getBestContour(); |
There was a problem hiding this comment.
perhaps we should modify the limelight library to turn on LEDs when necessary and turn off when not?
There was a problem hiding this comment.
I saw that, I'll add it to the list of stuff to get done. I'd want to do it non-automatically, as I bet there's a (greater than one tick at least) time delay on getting the first processed image, so I'd just turn it on at the beginning of the approach command and kill it afterward.
| // Make this return true when this Command no longer needs to run execute() | ||
| @Override | ||
| protected boolean isFinished() { | ||
| return contourNotSeen.hasPeriodPassed(maxTimeWithoutContour); |
There was a problem hiding this comment.
does this depend on us not being able to see the target after approach is completed in order to exit?
There was a problem hiding this comment.
Yes. It drops us at a relatively repeatable position. TBD is what exactly that position is and how we need to compensate for it when we score/if that isn't good enough what we should do.
There was a problem hiding this comment.
Also need to determine how to tell if it exits successfully or unsuccessfully.
…into fly_by_angle
4 participants
@dhoizner @cugarte
Most recent implementation of the skew-scheduled vision approach. This is ready to be reviewed but it still needs to be tested and tuned before merge. It may be easier to read DriveToTarget.Java directly rather than through the diff. It was completely reimplemented.