pic: Small CIM in wheel swerve

[Ether]

Originally Posted by sanddrag

... there was a good bit of math and code involved...

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.

[AlexanderTheOK]

Originally Posted by Ether

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.

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.

[AdamHeard]

Originally Posted by AlexanderTheOK

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.

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.

[Ether]

Originally Posted by Ether

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.

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--;

[Bryce2471]

Originally Posted by GeeTwo

If you used a worm gear for steering, it seems to me that you could orient both motors horizontally and get the module height down to the wheel diameter. You'd also save some weight on a second gear stage at a bit of loss of steering efficiency.

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

Originally Posted by InFlight

Bryce,
Really nice concept once again.

Are you using a Silver Thin Bearing to support the the pivot assembly?

The planetary drive inside the wheel is a great idea, are there two stages there for ~9x reduction?

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.

Originally Posted by InFlight

With a large steering gear like that you can't use an absoule encoder.

Team 141 at championships had a similar large steering gear setup. They used an incremental encoder to count steering input revs, but also had a pivot extension that triggered a proximity switch to calibrate the nominal forward position.

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.

Originally Posted by Scott Kozutsky

It appears there's an absolute encoder on the top of the entire module, likely connected by bent polycarb like 3928 and 2451 before them.

Correct, although I'm still debating how the wire routing will work...

Originally Posted by Ether

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.

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.

[Ether]

Originally Posted by Bryce2471

You also need to have a good home position.

That is a given.

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.

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

[Bryce2471]

Originally Posted by Ether

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

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.

[Bryce2471]

Originally Posted by AdamHeard

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.

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?

[sanddrag]

Originally Posted by Ether

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.

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?

[Ether]

Originally Posted by Bryce2471

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.

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.

[AdamHeard]

Originally Posted by Bryce2471

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?

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.

[Ether]

Originally Posted by Bryce2471

I have found that with swerves, the small amount of accumulated drift from an incremental encoder is unexceptable.

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

[Bryce2471]

Originally Posted by AdamHeard

You shouldn't be losing counts (which is why we love using them).
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.

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

[InFlight]

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.

[Bryce2471]

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.

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