Quote:
Originally Posted by Ether
It's still unclear what problem you are trying to solve and what your suggested solution ( "putting the swerve slightly to one side of "Straight" before every match, so that it's "zero" would be the real zero of the swerve, to begin with") is.
With absolute encoders for steering, there are at least two common ways to deal with steering alignment:
hardware mounting calibration
Mount, adjust, and lock down each steering encoder so that each encoder reads zero when its associated wheel is properly aligned. With this approach, there is no need to align the wheels perfectly at the start of a match.
startup zero offset
During setup for each match, carefully align the wheels to their zero steering position. At startup, read and store a zero offset reading for each steering encoder, and apply that offset to the encoder reading. |
Sorry my post didn't do it for you; I haven't had a lot of time this weekend to think out my explanation, but I'll give it another shot. I don't like the idea of using a startup zero offset for several reasons. I don't like the weight or complexity of adding a homing switch/sensor. When using an absolute encoder I like to use hardware mounting calibration. So I was trying to explain a way to use hardware mounting calibration with an absolute encoder when the gear ratio between the swerve and the encoder is not 1:1.
You begin by choosing an integer gear ratio for the encoder, because that will make things much easier. Then you mount the encoder or slip the gears so that when the full circle of the swerve is cut into slices of pie, one of the edges of a pie slice ends up facing true zero. Then you write software that takes that edge to be the zero for the match. So now, before each match you don't have to get the wheels perfectly aligned, you just have to aim it in the sector that is to one side of the zero position.
It's just an idea, and maybe that was already blatantly obvious, or maybe its not useful, but I figured I would try to explain my idea so that I could at least find out if people though it was useful or not. Let me know If I need to try to explain it one more time.
Quote:
Originally Posted by Ether
If you are getting "drift" with an incremental encoder then you are probably doing something wrong.
Adam listed two likely causes. A third, fourth, fifth, and sixth might be 3) using an encoder outside its operating range (edges per second), 4) a damaged encoder (dirty / scratched optical disk), 5) improperly assembled / mounted (optical disk alignment / concentricity), and 6) incorrect programming (resetting the counts rather than letting the FPGA accumulator run freely).
|
Because we had the problem on all four wheels, and we never disassembled the encoders, I'll rule out #4 and #5. We used the WPI lib encoder software, so I'll hope it wasn't #6. We originally thought that it was #3 because we could theoretically exceed the max angular velocity of the encoder, but we later decided it wasn't likely, because we would have to run the motor at very near free speed to do that.
(P.S. Thanks. Your post is much more constructive and helpful with the edit.)