Quote:
Originally posted by EbonySeraphim
Why is number 3 neccessary?
|
One of the fundamental axioms of computer science is "never trust the user"; the user can screw up, an untrained person can try to use it, or the input controls could get royally screwed up. Along these lines, you shouldn't trust your gearbox integrity to the driver remembering to gradually slow down in the heat of a match. If you do and they forget, you can easily destroy gearboxes by going from full forward to full reverse over a short period of time, thus rendering your robot inoperable until you find a replacement. This is even more true if you haven't removed the backdrive pins from the drill motors.
Quote:
|
-Two, there is an issue of knowing what you should be doing while slowing down. Subtracting from both motors is the simple answer. What if the robot was going backwards? You would be adding. How do you know to slow down? When p1_y is set to 127 is the simple answer. But what if you want to turn the robot while being still? p1_y is still 127 but your robot should be moving not slowing down.
|
Here's the code we use:
p1_y=p1_y_filt+(softChangeCoeff*(2000+p1_y-p1_y_filt)/100) - (20*softChangeCoeff)
p1_x=p1_x_filt+(softChangeCoeff*(2000+p1_x-p1_x_filt)/100) - (20*softChangeCoeff)
it handles all cases and doesn't require any special condition testing
Quote:
|
There are two other wheels for the x and y axis that do this for you already.
|
NO! Every veteran team I know of (mine included) has nearly killed someone over moving the trim wheels. If it wasn't technically illegal, I would highly recomend a heavy dose of epoxy to keep them from ever moving.