Reddit reviews BQLZR 600P/R Incremental Rotary Encoder DC5-24V Wide Voltage Power Supply 6mm Shaft

We are running these, they're a little big, but they're cheap, with a 6mm D shaft, and works just fine

Outside rev through bore encoders and the signwise encoders ( https://www.amazon.com/Signswise-Incremental-Encoder-Dc5-24v-Voltage/dp/B00UTIFCVA ), there aren't really many good cheap dead wheel encoders. However, keep in mind you don't really need dead wheels. Ignoring the fact that FTC auto can be accomplished using 1d motor encoders and some basic gyro logic, dead wheels only really allow you to move at max speed and still localize. I'd recommend looking at https://github.com/acmerobotics/road-runner/blob/master/doc/pdf/Mobile_Robot_Kinematics_for_FTC.pdf to see how most drivetrain encoders can be used to solve for a position on the field. The only downside to this method is that you can't move at max speed for mecanum. All the other drivetrain styles are completely fine. I guess the question you need to ask yourself is whether you really need to move at max speed in autonomous, which is only really advantageous for autonomous cycles and automating teleop. If you don't need that degree of precision, run the motor encoders. Teams like 5029 have had great success running just pure motor encoder odometry, having one of the cleanest autos at the OH state championships. Unless you need that extra 2 in/s, you won't feel any difference.

Ha, right :-)

Tried it out with two types of encoder: This one, and something like this cheap-o style, though there could be some differences. Not fast at all in either case, just turning it with my fingers.

Hmm, maybe I'll give it a try with no debounce. I assumed it was needed, but maybe not.

Thanks!

So, if I'm understanding you correctly, you simply want position feedback, and not the ability to control motors? If so, I have had good results with these encoders. They are simple and fairly inexpensive. They are relative, which means they do not report a position inasmuch as they report a rotation. It is up to you to keep track of their rotation and to zero it out. A known position + a rotation gives you a known position, but you will have to zeroize them when you start up. this could be bad if your system crashes during a performance, you'll have to physically zero out the projectors position. so you may want to look at an absolute encoder, such as this one, which I've never used.

The other problem you will run into is that unless the encoder is mounted directly onto your shaft, you will have to use a transmission of some type (belt and pulley, gear, etc) to rotate the encoder. You will have to measure the turn ratio of shaft to encoder to ensure that the values you are getting back are accurate. For example, if there is a gear reduction of some amount, your encoder will spin fewer times than your shaft, give you bad values. Since I dont really understand where you will mount it, that may or may not be an issue.

Now, others in this thread are telling you to look into an arduino, but they do not have networking capabilities, so by the time you buy a network shield and code up a working osc/udp translation layer (there's probably a library for it, but who knows), you will have spent more time and money than if you just went with the pi, in my humble opinion. Python can run osc and python is very nice for beginners, compared to c++ which you'd be using on an arduino.