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.

[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?

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

[Ether]

Originally Posted by Ether

6) incorrect programming (resetting the counts rather than letting the FPGA accumulator run freely).

Originally Posted by Bryce2471

We used the WPI lib encoder software, so I'll hope it wasn't #6.

Using the WPILib doesn't rule out #6. #6 refers to using the reset() function repeatedly in your software in the roboRIO.

/**
 * Reset the Encoder distance to zero. Resets the current count to zero on
 * the encoder.
 */
public void reset() {
	if (m_counter != null) {
		m_counter.reset();
	} else {
		ByteBuffer status = ByteBuffer.allocateDirect(4);
		// set the byte order
		status.order(ByteOrder.LITTLE_ENDIAN);
		EncoderJNI.resetEncoder(m_encoder, status.asIntBuffer());
		HALUtil.checkStatus(status.asIntBuffer());
	}
}

I've seen code where the counts are read and then reset() every cycle. You can miss counts that way. I'm not saying that's what your code is doing... but if it is, that might explain your "drift".

[bobcroucher]

Deleted

[Bryce2471]

Originally Posted by Ether

I've seen code where the counts are read and then reset() every cycle. You can miss counts that way. I'm not saying that's what your code is doing... but if it is, that might explain your "drift".

Oh, I see what you mean now. Although I have never heard of that issue before, we were not reseting the counts each cycle. We only reset them when necessary.

[Dunngeon]

Originally Posted by 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.

Which slip ring would you use? Mercotac's are banned.

[GeeTwo]

Originally Posted by Dunngeon

Which slip ring would you use? Mercotac's are banned.

I was thinking of a custom solution when I suggested a module no taller than the wheel diameter. A quadrature encoder or a CAN controller wired in the traditional method would require 6 wires. Is it possible to make a CAN talon work with only two control wires that branch a bit away from the talon? If so, you could reduce the connection to four wires, if you could figure out a place to park the talon on the far side of the sliprings with the motor, gearbox, encoder, and wheel.

[InFlight]

Originally Posted by Dunngeon

Which slip ring would you use? Mercotac's are banned.

There are quite a few Gold on Gold, or Silver on Silver contact designs that don't contain Mercury. The Wind turbine industry has lots of low cost high current options.

http://www.amazon.com/Sunwin-Wires-2...ords=Slip+ring

Company Specs
http://www.moflon.com/mw.php?a=1

Just one option, lots of other low cost (no-mercury) models. Moog would be nice, but really expensive.