Closed dltompki closed 3 years ago
Given that all field measurements for this challenge are in feet + inches, I recommend using total inches for the parameter. While we may close this issue without the higher precision, we may find that the distance traveled is not consistent, which may make it harder to find the second or 3rd ball or the end zone as the error for each movement will accumulate. We should at least measure how consistent the error is from our desired distance by measuring at least 5 times and measuring actual distance traveled each time.
All of the field diagrams are labeled in feet+in and metric, but if you prefer feet+in we can do that. Mechanical will probably use feet+in so that might be better. I just have a preference for metric.
Definitely agree on documenting our error though. Once we know we can then decide how we want to move forward with error reduction.
@jefft138 Just took a look at the field diagrams, and what I thought was metric was actually total inches. We'll go with that. :facepalm:
Proposed Functionality
The robot can move a specified distance, in a straight line, forward and backward. Doesn't have to be too precise yet.
Suggested Implementation
A command which takes a parameter of a real distance (meters?) and translates that into an encoder value. Then it starts moving and stops when the encoder has changed that amount.
Resources
https://www.revrobotics.com/content/sw/max/sw-docs/java/com/revrobotics/CANEncoder.html