Which sensors should be used throughout the robot?

[thatprogrammer]

Note: This is in response to a disucssion I had with 971's technical mentor, thanks for the help!
I've been wondering what sensors are the "best" for certain areas of the robot. The areas I'm thinking of are: Fly wheels, Elevators, turrets, and drivetrains.
What different sensors have you used for these applications, and how have you found them?

P.S. Has anyone used the S4t? Am I right in my assumption that it doesn't rotate?

[GeeTwo]

That's about like asking what is the best gear ratio: it depends.

And speaking of depends, that's proven to be the most critical feature when it comes to selecting which limit switch, encoder, camera, potentiometer, rangefinder, or optical interrupt (we've used all of these at one time or another) -- that it be dependable. A flaky sensor is often worse than none at all.

We've gotten sensors from AndyMark, RobotShop, Lynxmotion, Adafruit, Mouser, Jameco, McMaster-Carr, and even Radio Shack. We even played with some magnetic reed switches from Home Depot or Lowes. That's probably not a complete list.

[z_beeblebrox]

We've had good experiences with the AMT-102 encoders, which are inexpensive and robust.

We also like these reed switches for proximity or limit sensors. They're easy to mount and more durable than mechanical switches.

[thatprogrammer]

Originally Posted by z_beeblebrox

We've had good experiences with the AMT-102 encoders, which are inexpensive and robust.

We also like these reed switches for proximity or limit sensors. They're easy to mount and more durable than mechanical switches.

How exactly are the reed switches programmed? Same as limit switches?

Thanks for the feedback so far, keep it coming. Would like to use the same sensor *encoder, ir, ect* in as many places as possible!

[z_beeblebrox]

Originally Posted by thatprogrammer

How exactly are the reed switches programmed? Same as limit switches?

Yes.

[Knufire]

Originally Posted by thatprogrammer

P.S. Has anyone used the S4t? Am I right in my assumption that it doesn't rotate?

I've used the S4 in several different applications. Can you clarify what you mean by doesn't rotate?

[Thad House]

Encoders such as Greyhills or S4s on drive and elevators. Some teams like 10 turn pots on elevators, but I think encoders are easier. Then hall effects for indexing, or anywhere you would use a limit switch. Pots work better for arms because indexing an arm is hard. Any type of object indexing we use beam break sensors, which we buy from Adafruit. Then for shooters you either need a fast reacting beam break, or the smallest CPR encoder you can find.

[jajabinx124]

Originally Posted by thatprogrammer

How exactly are the reed switches programmed? Same as limit switches?

Reed switches and limit switches are both digital inputs that return boolean states, so both would be programmed the same.

[thatprogrammer]

Originally Posted by Knufire

I've used the S4 in several different applications. Can you clarify what you mean by doesn't rotate?

I seem to have misunderstood this sentence on the us digital website, sorry! "The S4T miniature optical shaft encoder is a non-contacting rotary to digital converter." My lack of experience with shaft encoders let me to assume that this meant the encoder literally doesn't rotate.

Encoders such as Greyhills or S4s on drive and elevators. Some teams like 10 turn pots on elevators, but I think encoders are easier. Then hall effects for indexing, or anywhere you would use a limit switch. Pots work better for arms because indexing an arm is hard. Any type of object indexing we use beam break sensors, which we buy from Adafruit. Then for shooters you either need a fast reacting beam break, or the smallest CPR encoder you can find.

Have you ever experimented with beam breaks for shooters? Any issues with programming or voltage (I've heard a few don't work below 12v?)

Note: To clarify, you mean limiting the range of something by indexing? Like using a limit switch to stop an elevator?

[Thad House]

Originally Posted by thatprogrammer

I seem to have misunderstood this sentence on the us digital website, sorry! "The S4T miniature optical shaft encoder is a non-contacting rotary to digital converter." My lack of experience with shaft encoders let me to assume that this meant the encoder literally doesn't rotate.


Have you ever experimented with beam breaks for shooters? Any issues with programming or voltage (I've heard a few don't work below 12v?)

Note: To clarify, you mean limiting the range of something by indexing? Like using a limit switch to stop an elevator?

We used beam breaks in 2012 and 2013 for our shooters. I don't know which models, but they were easy to use, and we didnt have any trouble. They were 5V models though, but since we now have a regulated 12V from the VRM, 12V ones should be fine too.

I probably used the wrong word for indexing. For elevators and arms, if using an encoder, you have to have a limit switch/hall effect at some point to zero it. And that is harder with arms then with elevators.

[Knufire]

The silver shaft rotates. You mount the encoder with a nut on the brass-colored threaded portion, which will also hold the black housing stationary.

[thatprogrammer]

Originally Posted by Knufire

The silver shaft rotates. You mount the encoder with a nut on the brass-colored threaded portion, which will also hold the black housing stationary.

From what I've seen, most teams just mount these by drilling a quarter inch hole and putting them in. How does the shaft still spin with the axle if the hole is a larger diameter than it is?

[Thad House]

Originally Posted by thatprogrammer

From what I've seen, most teams just mount these by drilling a quarter inch hole and putting them in. How does the shaft still spin with the axle if the hole is a larger diameter than it is?

So the input shaft of the encoder is 1/4 inch. So its press fit in. Then teams zip tie the wires down, which stops the housing from spinning.

[thatprogrammer]

Originally Posted by Thad House

So the input shaft of the encoder is 1/4 inch. So its press fit in. Then teams zip tie the wires down, which stops the housing from spinning.

Okay, I thought you'd simply need to select the 1/4 inch diameter option for the encoders.
When would you use a high cpr vs a low cpr? It seems to me that using a high cpr encoder on a fly wheel might overwhelm the fpga. Any formula to figure out the max possible?

One last question: 971's mentor mentioned their robot featured:

"encoders with index pulses and used a potentiometer with those to resolve the integer number of revolution ambiguity."

How much % of error can one expect simply using an encoder rather than this set up? Is this set up really necessary or simply a practice that, while good for inspiration and education, is a bit overkill?
Thanks for all the help so far!

[Thad House]

Originally Posted by thatprogrammer

Okay, I thought you'd simply need to select the 1/4 inch diameter option for the encoders.
When would you use a high cpr vs a low cpr? It seems to me that using a high cpr encoder on a fly wheel might overwhelm the fpga. Any formula to figure out the max possible?

One last question: 971's mentor mentioned their robot featured:

How much % of error can one expect simply using an encoder rather than this set up? Is this set up really necessary or simply a practice that, while good for inspiration and education, is a bit overkill?
Thanks for all the help so far!

High cpr is good for accurate distance, but pulse timing gets pretty jumpy when moving fast. Low cpr allows for smoother pulse timing at high speed. We usually run 256 cpr at 4x for distance, and 6 cpr at 1x, which works great for anything faster then 1000 rpm.


As for distance accuracy, 256 cpr at 4x with a 1.125 inch spool gives an accuracy of 0.003 inches per pulse. That is way more accurate then ever needed, and controlling to that accurate isn't possible.