Who used wheel encoders

Hay I am planning on using wheel or shaft encoders next year and I have a few questions for those teams who used them this year.

What teams used wheel encoders this year?

How did you build it or did you buy a shaft encoder?

What was its resolution?

Did you use them only for autonomous or for the whole match?

How did they work for you?

Do you plan to use it next year?

What teams used wheel encoders this year?

Team 122

How did you build it or did you buy a shaft encoder?

We bought an optical sensor; we built the encoder ourselves from aluminum and attached it to our jack shaft.

What was its resolution?

I think we calculated ours to be ± 3 in.

Did you use them only for autonomous or for the whole match?

Just autonomous mode.

How did they work for you?

They were adequate for our purposes. They did give us some trouble at the beginning, though. One major obstacle we encountered was the resolution of the stamp itself – about 25 ms if I remember correctly. You might consider using a custom circuit to get better results.

Do you plan to use it next year?

Well, I suppose it depends on the game. But if we do then probably get a custom circuit.

Wildstang Team #111 used wheel encoders. Very simple solution, a simple cut wheel insert made of aluminum and backed with black paper became the encoder. Used two optical sensors, since they were unlimited under the parts list. Resolution, less than 2 inches, if the wheel stayed on the ground. Two sensors give both tach and direction, when phased 90 degrees apart. Used for auto mode and with accumulated errors during a 15 sec auto mode, we were consistently accurate to within +/- 6 inches anywhere on the field. Our experience was gained from Lego League and testing. We will use this again if the game warrants it.

What teams used wheel encoders this year?
461

How did you build it or did you buy a shaft encoder?
Digikey partnumber: CT3003-ND
These are 4 bit grey code binary rotary encoders. Very small and fairly beefy. I knew that i needed some kind of rotary encoder because i have been teaching lego robotics at the museum i work with and have been involved in lego league so i knew we needed some kind of enocoder and these were the ones we ended up with. They are 3.50 a piece so it kinda sucks when you break one but it wont break the bank to replace it.

What was its resolution?
4 Bit…its grey code which was fun to figure out.

Did you use them only for autonomous or for the whole match?
We used them for a few different things. During autonomous they were part of our system for positioning which was used in conjunction with the gyrochip. They also alowed us to do things like make sure the speed of the wheels were the same when we were trying to go straight in user control mode. And they were handy for debuging stuff because we could test the speed of our wheels.

How did they work for you?
Really well. The whitesheet for them wasn’t great but once we got it figured out it worked great. They were small and dependable. They wore out after 10,000 cycles so we switched them out before nationals…well that and the fact they took a direct hit from another robot and the shafts got bent off… But they were easy to switch in and out due to a small shaft connected to the drive shaft that just had a set screw and mounting bracket next to it. We could just pop a new one in, if they got broken.

Do you plan to use it next year?
If there is autonomous again i am pretty sure we’ll use them again. We are going to try and develope some custom circuittry so we dont have to waste 8 digital inputs just for rotary encoders. We have also looked into simpler solutions like using the optical sensors and a reflective something like wildstang and other teams used.

We used the optical sensors, but on part of the drive train nearer the motors than the wheels. It kept them inboard and well protected.

We originally used them for counting wheel rotations, but our wheels would spin too much on the ramp especially when going over the top at full speed when the wheels tended to come off the ramp altogether. We didn’t have time to implement a custom processor so while accuracy was +/-3" at slower speeds it went to +/- 6-9" at higher speed.

They were very useful to detect stall conditions during autonomous, so if the robot was pushing against an immovable object like another robot, it would do avoidance maneuvers like backing up moving over and trying again. Whenever it was caught in a robot crunch at the top of the ramp it always worked its’ way out by the end of autonomous.

Well, being a rookie team, we did not put a lot of work into ours :slight_smile:

We pained a wheel black, and then used white-out to put on the white marks… Eventually we went to 1/2 white 1/2 black. It was quite precise, at least our autonomous mode was quite consistent. We only counted wheel rotations, and I used a correction for slower speeds - I skipped some loop iterations to avoid reading the same line twice. Turned out I didnt need it :slight_smile: Next year we’ll definitely have an extra counter circuit.

What teams used wheel encoders this year?
Tea 356

How did you build it or did you buy a shaft encoder?
We used a Grayhill (mfg) gray scale encoder from Digi-Key. It is a mechanical encoder which could easily be interfaced to the digital inputs.

What was its resolution?
It has four bit resolution, but we only used 3 bits.

Did you use them only for autonomous or for the whole match?
Autonomy only. We started to think about using them at other times once we got them working reliably.

How did they work for you?
After we sorted the mechanical coupling issue, they were very reliable.

Do you plan to use it next year?
Depends on the game and the fab rules. But we will lean towards reusing so that we can get a speed measurement.

We tried “encoding” briefly, but did not use it. We painted white two of four 90 degree sectors on a black side of a drive wheel on each side, then tried to read the time for each sector, as a means to correct a “yaw” that disappeared when the wheels were mounted with the axles perpendicular to the sides (which were parallel).

What teams used wheel encoders this year?

CD8 had encoders.

How did you build it or did you buy a shaft encoder?

We had home brew encoders. We used IR based sensors from Digi-Key with interrupters mounted on the motor shaft (4 pulses per rev of the motor).

What was its resolution?

EXTREME resolution. We had 2 encoders per motor (mounted 90 degrees out of phase with eachother) to give direction and distance.

In low gear we had 60 pulses per inch of robot travel. In high gear we had about 20 per inch. We had surprisingly little slip on the ground and (once we found a MAJOR bug in our auxiliary STAMP2 code) very consistant results.

Did you use them only for autonomous or for the whole match?

Autonomous only. if we had been more reliable earlier, we would have probably used the sensors to drive the robot always (i.e always have the robot wheels in feedback mode just like we do with our arm joints). But they weren’t so we didn’t.

How did they work for you?

Once we got the motors mounted robustly (i.e. fixed the problems FIRST created with their motor mount kits) and the interrupter’s robustly mounted (20,000 RPM can shake things loose pretty easily) and the sensors mounted robustly (these things need to be designed in from the start – eyeballing it after the fact is asking for trouble), the system worked like a charm.

Note that we had not just a the sensors but sensors (2 per motor) PLUS up/down counter circuits to count the fast pulses PLUS shift registers to take a snapshot of the counter while we read them PLUS an auxiliary STAMP2 to read the shift registers and do some processing for us (calculating distance traveled by the robot CG and the orientation of the robot).

It turned out to be a very complicated little setup. AND for all its cleverness, in the elimination rounds, it fail us do to an a connection becoming partially unplugged when we climbed up on another robot in the last round of the qualifying rounds.

Do you plan to use it next year?

I think yes, if the game needed it. But… …it was not an easy thing. We would also put the sensors and the electronics box in a little more protected location and make sure the connectors are a bit more robust, but generally speaking, it worked pretty well.

Joe J.

One more question for all the teams who have already posted.
Did you use a custom circuit board or did you hook the outputs of the encoder directly to the digital or anlog inputs of the RC?

Team 461 hooked them directly into the Digital Inputs. Looking back on it now i wish we had more real electronics knowlege on our team so we could do some cool custom circuits but i only know a little bit about that stuff. Hopefully by next year we will have learned and can recruit a electrical engineer.

*Originally posted by CyberWolf_22 *
**Did you use a custom circuit board or did you hook the outputs of the encoder directly to the digital or anlog inputs of the RC? **

We used a custom circuit board. All of the monitoring of sensors and the execution of auto mode software was done through the CC which had an onboard microproc.

Team 180 used a pair of Grayhill series 61k optical encoders from Digikey:GH3065-ND. We sent the output to a custom circuit board where we processed a pair of RC digital inputs for each encoder for distance and an RC analog input for speed. The circuit used a CD4040 binary counter and an LM2917 frequency to voltage converter. With the way the encoders mounted on our gearbox, the “2-bit” distance inputs gave us 3.125 inch resolution in hi gear and 6.5 in low gear. We used the distance inputs in autonomous mode for dead-reckoning. The speed inputs gave us a low speed threshold for “shift-on-the-fly” and input for a pid speed controller we’re working on, but never used in competition. So, we’ll prototype the speed control in the off-season and check out its usefulness for both autonomous and manual mode.