Encoder for a fly wheel

[Wildcats1378]

Hey guys,
We are trying to use an encoder for speed control this year on our fly wheel. We've only got any encoders that came with the KoP for the past 2 years, and we are sort of confused about how to go about mounting an encoder for our flywheel.
Our flywheel is controlled by a mini cim. The minicim shaft is connected to a 3/8 shaft using a coupler, and that 3/8 shaft houses the wheel. We just want to mount an encoder to read the speed.

Any help would be really appreciated!

[Ether]

Originally Posted by Wildcats1378

Hey guys,
We are trying to use an encoder for speed control this year on our fly wheel. We've only got any encoders that came with the KoP for the past 2 years, and we are sort of confused about how to go about mounting an encoder for our flywheel.
Our flywheel is controlled by a mini cim. The minicim shaft is connected to a 3/8 shaft using a coupler, and that 3/8 shaft houses the wheel. We just want to mount an encoder to read the speed.

Any help would be really appreciated!

Are you dead-set on using an encoder?

A one-per-rev sensor may actually be a superior solution for this application. For example, put a piece of reflective tape or paint on the wheel and detect it with an photosensor.

What speeds do you want to control?

[Wildcats1378]

No, we aren't dead set on using an encoder. I simply thought that was the best way to determine speed.

Since it is a flywheel for our frisbee shooter and it is connected to a minicim, I'd just guess in the area of 2000-4000 rpm? Those kinds of speeds.

[Ether]

Originally Posted by Wildcats1378

No, we aren't dead set on using an encoder. I simply thought that was the best way to determine speed.

Since it is a flywheel for our frisbee shooter and it is connected to a minicim, I'd just guess in the area of 2000-4000 rpm? Those kinds of speeds.

You could get a very clean speed signal at those speeds (maybe +/- 2 rpm) with very little phase lag using the GetPeriod() method in the Counter class. Instantiate the counter at 1X. Grab GetPeriod() and divide it into 60 to get RPM (for a one-per-rev counter like we're discussing here). Do not filter the signal.

With a good signal like that you should be able to use the simple bang-bang speed control algorithm. Fastest spinup and recovery time and no tuning required.

Search Chief Delphi. Quite a few teams are doing it this way with good success.

[Richard Wallace]

Originally Posted by Ether

A one-per-rev sensor may actually be a superior solution for this application.

Here is another method for getting once per rev pulses: use a strong (rare-earth) two-pole diametrically oriented magnet as the target for a Hall effect latch sensor. One good magnet for this application is KJ Magnetics part R424DIA. One good sensor IC is Melexis part US1881. The typical 3-wire application circuit shown in diagram 13.1 on page 8 of the Melexis UA1881 data sheet can be implemented using a small piece of perf board, and mounted so that the sensor is about a centimeter from the target. The signal can be processed as Ether describes.

[z_beeblebrox]

My team is direct driving the shooter wheels with the AndyMark hub and CIM/ miniCIM motors. To measure speed, we are using a slotted optical switch whose light beam is broken by the teeth of a sprocket mounted to the wheel. Although we haven't tested it yet (hopefully tomorrow), I expect that it will be easy to mount and program (the program is mostly done) and give good (48 counts per revolution) resolution data.

[Ether]

Originally Posted by z_beeblebrox

My team is direct driving the shooter wheels with the AndyMark hub and CIM/ miniCIM motors. To measure speed, we are using a slotted optical switch whose light beam is broken by the teeth of a sprocket mounted to the wheel. Although we haven't tested it yet (hopefully tomorrow), I expect that it will be easy to mount and program (the program is mostly done) and give good (48 counts per revolution) resolution data.

You didn't mention the RPM you are trying to control. At 48 counts per rev at 5000 RPM, you're going to get roughly 150 RPM jitter with GetPeriod() if you leave the FPGA sample averaging at the default value of 1. If you set the samples to 48, you'll get the same clean signal as a one-per-rev sensor at that speed, namely 3 RPM.

If you use Get() to get counts instead of period, and your control loop is running at 10ms, you're going to see about 125 RPM jitter at 5000 RPM. If you try to filter that in software, there may be too much phase lag to get clean control with bang-bang.

[z_beeblebrox]

Originally Posted by Ether

You didn't mention the RPM you are trying to control. At 48 counts per rev at 5000 RPM, you're going to get roughly 150 RPM jitter with GetPeriod() if you leave the FPGA sample averaging at the default value of 1. If you set the samples to 48, you'll get the same clean signal as a one-per-rev sensor at that speed, namely 3 RPM.

If you use Get() to get counts instead of period, and your control loop is running at 10ms, you're going to see about 125 RPM jitter at 5000 RPM. If you try to filter that in software, there may be too much phase lag to get clean control with bang-bang.

Probably dumb questions, but how does one adjust the FPGA sample averaging count? Will this give fast enough updates to use with a bang-bang controller?

[Ether]

Originally Posted by z_beeblebrox

Probably dumb questions, but how does one adjust the FPGA sample averaging count?

It's not a dumb question. What language are you using?

For Java or C++, see posts 29 & 36 in this thread:
http://www.chiefdelphi.com/forums/sh...30&postcount=3

For LabVIEW, it's a parameter you set, I'm not sure where. Post over on the LabVIEW forum if you can't find it.

Will this give fast enough updates to use with a bang-bang controller?

Yes, at shooter wheel speeds.

[S2K JDM]

you could just use an US digital encoder. we just drilled the middle of these shafts http://www.andymark.com/product-p/am-0153.htm slid it on the output shaft of the CIM and put set screws in it, then we just used the mounting kit that comes with that encoder at the end of the shaft.

[compboy07]

Don't forget that if you use a CANJaguar, you can use the encoder directly attached to said Jaguar. My team has successfully done that in the past.

This year, I'm using a AMT-102 capacitive encoder, which I like a lot better than the kit ones. Adjustable lines/rev (48-2048), mounts on just about anything up to the size of the CIM shaft without machining, and it seems to be more reliable than optical encoders IMHO (don't have much experience with magnetic ). Also, it has an index count (aka one pulse per rotation on a separate pin). Worth a look at least.