My team is experimenting with WCD this summer and we’ve begun discussing the various ways to go about mounting encoders. The three options we’ve thought of are mounting to the ouput shaft of the gearbox, mounting to one of the wheel axles, or utilizing a CIMencoder.
What have your teams used and what have you learned from it? Pros? Cons? Would you do anything differently?
While my team has not built a WCD, I just want to say that I cannot recommend the CIMCoder. 2/4 of ours stopped functioning by competition season and I have heard of their shells cracking in high vibration applications.
YMMV
The method I have heard most commonly is mounting something to the output shaft of the gearbox, using something like an SRX Mag Encoder.
The one thing I have against mounting to the output shaft is that it removes our ability to convert to a dogshifter or ballshifter
I assume that you are speaking of the andymark CIMcoder. Am I correct?
Correct. I should clarify. The one you posted seems to be fine, though I must admit I haven’t personally tested it. I hope to do so next year.
For FRC, it probably doesn’t matter, just get and encoder in there… 
So for discussion purposes, what are you trying to measure? Seeing this is a drivetrain, probably distance. So if you put the encoder on the wheel axis, you are limiting your electrical accuracy, as the final distance per count, will be the largest… Say you have 100 count per rotation encoder, and 7.75" pneumatic wheel, roughly 24" circumference, 100 counts per rotation, each count equals a 1/4". So you can’t position the wheel any finer than a quarter of an inch. But hey, in FRC if you can put a bot within a quarter of an inch you are typically fine.
Mechanically, what is happening if you place the encoder on the wheel axis, you have eliminated any gear mesh slop, errors, backlash, so mechanically, putting the encoder here, will be the most accurate mechanically.
If you move the encoder to the motor, like the cimcoder, now your distance calculation is going through a gearbox, there may be multiple stages, backlash, etc. that is generating an error between what the motor shaft is doing and what the wheel axle is doing. Say your gearbox 15:1, so the encoder distance at the motor, is now 0.24" divided by 15 or 0.016" per encoder count. Sounds more accurate, electrically, but mechanically you probably have more than 1/4" of backlash in the geartrain, (hold the motor shaft, and wiggle the wheel back and forth.) now when the programmer tells the motor to stop at 1000 encoder clicks, all of that backlash is an error in stopping. Do you have a two speed transmission? Now you programmer needs to know what are the different gear ratios, and what gear the bot is in to keep track of the distance traveled. Did you want to switch gears, during auto, now there are errors when the controls tell the gear to switch, and when the pneumatics actually switch the gears.
Can you do it with a CIMcoder, yes. Will it be better than nothing, Yes… You want to make it easier on your programmer, so they only need to deal with one distance per count calculation, put the encoder on the wheel axle shaft.
There is another drawback of putting the encoder on the motor, is you need to be aware of how many counts per second, your controller can handle. If you are counts are being generated quicker than you can process them, you miss counts, and all bets are off. In FRC with the roborio, this is pretty much a mute point now, but it is a design consideration in industry, and it is dependent on the controller used.
So if you are using a roborio, we used a cimcoder on our shooting wheels last year, and was fine. If you are using the Talon SRX to handle the counts, we also used the 775pro and vexpro versaencoder at 1:1 and was find too… 14,000 rpm and 4096 counts per rev… no missed counts. (engineer close enough to control as expected)
We mount it to a wheel shaft. Gearbox output shaft usually doesn’t have enough clearance for Grayhill encoders we use.
CIMcoder worked great for our shooter motor this year. We had no issues at all once we got the system mounted correctly. Don’t think I would put one on a drive train gearbox. Those CIM’s are usually not easy to remove if the encoder required maintenance.
David
We haven’t actually run the drivetrain yet so I can’t vouch for how well it holds up, but the Apex offseason robot is running encoders on the front wheel axles and made a small polycarb bracket to hold it in place.
http://imgur.com/yQ6AdAnProtip: Don’t be like us, put your set screw hole somewhere where it can be accessed, not underneath the pulley/sprocket. Definitely overlooked that one.
Any reason you guys didn’t bring that polycarb bracket across to mount the tube on the other side of the pulley? I know it’s just an encoder but it would drastically lower any worry about that encoder moving too much for basically no extra weight.
We use the encoder attachment on the 3 cim ball shifters by vex. (http://www.vexrobotics.com/3cimballshifter.html) It makes it super easy to attach and use encoders though the gearboxs in general are quite heavy and expensive. In addition we have had some trouble with the retaining clip for the shifter shearing off. We use the entire line of WCD for our robot and have found that this is the easiest wasy to mount encoders.
In the past with our fully custom WCD systems, Team 696 has placed encoders on the drive shafts of wheels other than the output shaft of the gearbox. It was perfectly reliable for us, with no slippage of the encoders or wandering of the encoders out of the shafts during practice, competition matches, or offseason events. I do not personally see any reason for us to change this practice in the future for such a setup.
We have often relied on US Digital S4 encoders for drivetrains and other systems, which are now replaced with the S4t as far as I understand. We have not had any experience with the S4t.
One tip for encoders in shafts though: feel free to use some hot glue to aid in the interface between the encoder shaft and the shaft it is connected to. This will certainly help in keeping that encoder from slipping inside the shaft, or the encoder from becoming removed from the shaft unintentionally.
You could try this hack: https://www.chiefdelphi.com/forums/showthread.php?p=1569705. The only challenge is to clear the hex collar. A 3D printed housing /standoff (or just a bit of bent lexan) could work really nicely.
Did you wire your cimcoders to the srx? If you did, did you solder in the pull up resistors? If not that is probably the issue with missing counts. We ran them on Minicims for our shooter wheels, to srx running speed control loop on the srx, and worked beautifully.
From Omar, at CTR when I asked question about cimcoder and pullups.
Hey Scott,
Pullups
The CimCoder will require external pullups. The 10KΩ that’s recommended in the CIMCoder spec is probably best. I think we had another customer who confirmed that without resistors the results are not reliable.
Breakout
Also since it’s a 5V sensor, be sure to use a blue-encoder-breakout so that you don’t violate the 5V errata on Talons with revisions < 1.7.
2014 we used Ball shifters and used the encoder setup that comes with it.
2015 we used the AM CIMple Box and 3D printed an encoder gearbox that mounted to the 1x2 frame. It had a 3D printed gear on the hex drive axle and we pressed a 3D printed gear onto the Greyhill encoder. Worked well.
2016 we used the WCP SS gearbox (single speed with 3 motor mounts). We only used 2 CIMs so we 3D printed a mounting plate and gear so that the encoder could mount using the CIM bolt holes. Worked great. Much easier to get to and work on if needed compared to 2015.
We had 2 different ways of including an encoder on our drive this year. Originally with our 775pro and VP gearbox we just included the encoder stage in our VP. When we moved to a CIM/miniCIM gearbox in an effort to keep it as low profile as possible, in this case it was ~2.625in tall, we had to move the encoder away from the gearbox. We moved it to the center wheel axle.
Well that’s interesting… That might solve some of our problems. Surprising. We used the Andymark Universal Breakout board, which seem to have spaces for pull up resistors. Might have been good to read in on that.
Do other encoders generally need pull up resistors?
It’s less about the encoders, as to what is reading the encoders. The roborio has pullup resistors built in. In the cRio days the digital side card had pullup resistors built in too. Read an input on either with nothing wired up, the all will return TRUE, or that the signal is high.
Ah ok. I’m assuming the srx doesn’t have one, then. The more you know.
I don’t want to hijack the thread here, but mainly because the cross-brace attaches on the other side of the pulley, so there’s no room. It’s also intended to be flexible by design. Realistically, this mount is only there to keep the encoder body from rotating. It’s pretty well retained inside the shaft, and because it’s a rigid attachment there and a very snug fit, we want to avoid over-constraining the encoder and ending up putting a side load from any kind of misalignment.
The last benefit is this mounting lets us remove and replace a belt without taking the encoder off.
449 tends to use WCP gearboxes.
If we’re using a SS gearbox, we place the encoder on the gearbox output shaft, mounted under the motors.
If we’re using a DS gearbox, we place the encoder on a wheel shaft.
The latter can be a pain if you’re using chain and need adjustability (such as w/ versablocks) to maintain tension, but there are workarounds (such as slotting the mounting holes for the encoder bracket).
We used to use thick surgical tubing for the coupling, but found that this actually causes a fair amount of noise in the encoder reading (my best guess is that the torsional flex in such a coupling leads to something like a stick-slip behavior, but I have no way of actually testing this). We now use helical beam couplers instead.