Quote:
Originally Posted by tuXguy15
Ok so in your code i see the part where you constructed constants. How would you tune them. What do they do because i see them in other codes as well.
|
Sorry for the belated reply...
kNearlyHorizontalSlope and kNearlyVerticalSlope were limits we had on how oblique of an angle we would allow in order to count the edge of a target as a vertical or horizontal line. (We would of course expect a rectangular target to have 2 vertical lines and 2 horizontal lines). We tuned them by trial and error, allowing for some misalignment relative to the target, but still throwing out images that were clearly not the goal.
kMinWidth and kMaxWidth were the widths of the vision target from the closest and furthest ranges we would ever see based on our test images.
kRangeOffset is a global value that adds/subtracts to the desired RPM we are commanding (useful if we find that every single shot is too low, for example).
kHoleClosingIterations was found through trial and error on a test set of images. It is a parameter to the OpenCV function cvMorphologyEx.
kShooterOffsetDeg was found by firing our shooter and seeing where in the camera frame the shot went. As you can see, our shooter was consistently about a degree and a half to the left of center of the camera.
kHorizontalFOVDeg is the camera field of view, which is 47 degrees according to the manufacturer. kVerticalFOVDeg is the same.
kCameraHeightIn and kCameraPitchDeg are the height and angle of the camera relative to the floor, respectively. Measured based on our robot.
kTopTargetHeightIn is the height off the floor of the center of the top vision target.
In the constructor, you see a bunch of numbers put into a TreeMap. This map takes a range in inches (first number) and a desired RPM (second number) and basically lets us look up the best RPM for any given range. All of this was driven by shooting on a practice field and recording the optimal RPM for different ranges.
On lines 182-189, you see a few more magic numbers. These were all tweaked in order to find the right color (green) and saturation/value for the target. Driven by taking test images and using MS Paint (or similar) eyedropper to check the values of pixels on the target.
Line 216 is a ratio check...we expect a ratio of height/width between 0.5 and 1.0 (so wider than it is tall). On line 218, the "20" is a parameter to the approxPolygon function, which we found to work well when using test images.
I think that is all of the constants in there (other than things like "4" being the number of sides in a rectangle, and Pi, etc.). Hope this helps. Note that we DEFINITELY could have done a better job of reducing "magic numbers" in our code (and we did in 2013), but this is what you get in 6 weeks
