Re: pic: Small CIM in wheel swerve
 

If your sample time is fast and stable enough that the encoder could never turn 180 degrees from one sample to the next, then "all ya gotta do" at each sample is assume the encoder turned through the shortest angle, and keep track of zero crossings.

Re: pic: Small CIM in wheel swerve
 

Funny you say that. That was the original plan, but Java's timer tasks (as mentioned by 254) are slightly broken on the roborio. We had latencies in code of up to 200ms. We ended up using the FPGA's analogTriggers to keep track.

Since there's really never a need for analogTriggers save for this one strange case, that was broken too. Thank god for the fantastic people at WPI that got it fixed so quickly.

I know sanddrag said that it worked well enough at competition, I have to say the headache caused by this is greater than he may have noted, and took a lot of time out of the season. It's generally just not a good idea to do incremental sensing of anything if it is at all possible to have absolute sensing. Zeroing sensors are a must.

Re: pic: Small CIM in wheel swerve
 

If you embrace incremental, then it can be a huge time savings.

We never have to manually zero sensors, there are no magic numbers in code, and we know we can replace a sensor/system at any time with no new work required.

Every position system 973 has ran all the way back to 2012 has been on an incremental sensor that assumes a zero at start (plus sometimes a manual or automated routine to hardstop zero). We always mean to add the zeroing sensors, but never do as the functionality isn't needed.

Re: pic: Small CIM in wheel swerve
 

Here's the code (I think). Haven't tested it:

Let A be the encoder angle reading in degrees (0 to 360 clockwise) at the previous sample, and B be the encoder angle reading in degrees at the current sample. Then:

D = B-A;
D -= 360*floor(0.5+D/360);
if((D>0)&&(A>B)) turns++;
else if((D<0)&&(A<B)) turns--;

Re: pic: Small CIM in wheel swerve
 

I would like to use a worm gear, but I have no idea how to make a large custom worm gear, and I assume that a COTS gear that large would be incredibly expensive. Perhaps worth looking into though, since this was just a CAD experiment anyway
Thanks, right now it uses a bomb squad style slew bearing.

I kept it to one stage in this design, but it's likely geared too tall for most situations. It's a 5.33 to one reduction on a 3.5'' wheel.
We have run an incremental encoder with a homing index in the past, and would probably never go back... It's a real pain, and the drift robs a lot of a swerve's efficiency.
Correct, although I'm still debating how the wire routing will work...
You also need to have a good home position. Which would likely involve 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.

Re: pic: Small CIM in wheel swerve
 

That is a given.

Would you please elaborate on this? It's not clear what problem you are trying to solve.

Re: pic: Small CIM in wheel swerve
 

I was trying to explain one way to make sure that the swerve zero is accurate before each match. If the software just takes the initial position as zero, then your wheels will have slightly different zeros each match because the wheels won't be perfictly lined up.

I was suggesting that you could have the software take the point where the encoder would read zero as the reference for the match. That way, you wouldn't have to worry about getting the swerves perfictly lined up before each match. I'm thinking that my explanation may still not be good enough, but let me know.

Re: pic: Small CIM in wheel swerve
 

I have found that with swerves, the small amount of accumulated drift from an incremental encoder is unexceptable. This is because it causes the wheels to fight each other, and makes the responce to driver input less predictable. I know you guys have run swerves in the past. Did you use incremental encoders? If so, how did you keep the drift down and zero them?

Re: pic: Small CIM in wheel swerve
 

I think that's essentially what our programmer did, although the libraries involved had some glitches that presented many headaches.

For those of you discussing "drift" with incremental encoders, are you referring to an accumulation of lost counts? Does this happen when the direction of steering reverses, and is this accumulation of lost counts biased toward one direction? Would the solution to have something like a hall effect sensor for zeroing, and reset the count every time you cross it?

Re: pic: Small CIM in wheel swerve
 

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.

Re: pic: Small CIM in wheel swerve
 

You shouldn't be losing counts (which is why we love using them).

However, if you are there are two likely causes.

1) Mechanical slip. Somehow the encoder is slipping, easy to fix w/ better design.

2) Voltage brownout causing the supply voltage to the encoders to drop out. We use a regulated supply for all of our encoders for this reason.

Re: pic: Small CIM in wheel swerve
 

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).

Re: pic: Small CIM in wheel swerve
 

I'm going to guess that #2 was our problem. I am surprised I've never heard of this issue before.

Re: pic: Small CIM in wheel swerve
 

If you could work out the incremental encoder setup, it would free you up to put a slip ring module at the top. That trade off would solve the motor wiring issue, and not restrict you to partial rotations.

Re: pic: Small CIM in wheel swerve
 

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.
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.)