Curious: how many limit switches to teams typically use?

[RoboMaster]

This year we have 6 limit switches on our robot and we may add a 7th (this is mostly limits for the maximum positions of our tube manipulators). This seems to me to be a large amount. How many does your team use?

Besides being a lot to wire up and keep track of, the limit switches are more-or-less flimsy and do break or stick occasionally. Our mechanical group lead has strongly requested us programmers to make an override operation to the limits in case on breaks mid-match and we can't operate the robot correctly. They are also hard to mount, but they are easy to buy and flexible to use. They offer clear, definite feedback to the position of a mechanism, which can't always be achieved with potentiometers or encoders (wandering, needing to be reset, coded differently, other complications and complexities).
This was especially realized by our team (especially programming!!) after using an encoder last year for determining the position of our kicker. Our kicker had quite a loose chain, which would kick itself more and more loose, making our encoder inaccurate. We updated the max and min encoder constants countless times and the robot often froze in autonomous as the kicker reached its physical stopping limit, but the programming thought it still needed to swing farther. The electrical and mechanical groups never put any limit switches on, despite my insistence. So this year, we have 6 of them!

What do you think?

[pfreivald]

Last year: 7.
This year: 9. So far.

[Chris is me]

Always have an override function ready for anything important.

I've never been involved with a robot with a limit switch - usually potentiometers dictate anything that would otherwise be limit switched.

[WizenedEE]

Last year we used two for our arm.

This year we aren't using so far, but will probably use one on the deployer. Our arm's position is being determined by two accelerometers. Has anybody tried using accelerometers to get angles before?

[pfreivald]

Our second year, the drift on a trimpot caused what was a normally-functioning motor to catch fire...

...we had the distinction of having the only robot to catch fire during FLR... It is not a situation we intended to ever repeat!

Thus, while we have encoder (instead of trimpot) driven motors this year, we have redundant limit switches that will (a) stop motors if necessary and (b) set encoders to 'default' if they are tripped.

[Justin Stiltner]

I recommend quality snap action limit switches from the likes of mouser, jameco, digikey, etc. Cherry is a popular brand. If you get the ones with the extended arm you can bend it manually to adjust its activation position, and 2 bolt holes mount it. Thread the bolts into the housing of the switch for a locking effect. The switch will literally be destroyed before it comes loose from the mounting. I know that $5 or $10 may seem like a lot for a switch, but a cheaper switch may cause you a match, or may allow the system to break itself. If any switch I use is sticky new from the packaging... I would find another source of switches!!!

[MrForbes]

We always put a few limit switches on the robot. I think last year we actually got one of them to work! Amazing.

[Jon Stratis]

FWIW, if set up properly, you won't have to worry about losing a limit switch. We used 3 of them in 2008, and all 3 are still working just fine! Typically speaking, we use limit switches to tell us when a mechanism reaches a hard mechanical stop - the switch is set up such that it's impossible for the mechanism to push the arm too far or damage it in any way.

[kgzak]

Last year we had 1...that was added at state...and was never used...

This year we have none so far. I don't think we are using any either. We usually use encoders and software to stop in the code and then physical safety stops. In the code I have written, if the encoder stops moving and the motor is still attempting to move, we know where it is or that the encoder has fallen off so we can automatically reset it. I've never had a problem with encoders so I like them.

[pfreivald]

We have a 'new' programming team this year, and with some help from 1511 have encoders working. We will probably be moving more toward encoders and away from limit switches as the years progress -- but as I indicated before, we've had great success with them. Easy to mount, easy to program, and relatively cheap...

...and thanks for the idea on the encoder-as-limit, kgzak. That's a rather important piece of functionality that we should add to our algorithm!

[Dad1279]

I like to use magnetic switches, like these: http://www.mouser.com/ProductDetail/...tylqekUcicw%3D

[Grim Tuesday]

We are using Holl Effect sensors to detect the position of our grabber this year, as well as 6 limit switches just on our ladder (4 to detect when a tube is in it, the others to act as hardware stops)

[thefro526]

Originally Posted by Chris is me

Always have an override function ready for anything important.

I've never been involved with a robot with a limit switch - usually potentiometers dictate anything that would otherwise be limit switched.

Usually, a potentiometer is a good enough limit for most mechanisms, though I prefer to add a limit switch as well, just in case the potentiometer should shift or misread.

When we implement limit switches, we like to set a "hard" (Usually has a little play to cushion the impact) mechanical stop in the same location as well. This saves the body of the switch from seeing any actual force from the mechanism. I believe the most limit switches we've used on a robot was either 3 or 4, though this year it sounds like we may have more than that.

[Jogo]

So far we're up to three this year for our claw...we were thinking of just using an encoder for our mechanism, but perhaps combining it with one limit switch will prevent error from piling up.

[ratdude747]

in 2008, my team at the time (1747 HBR) had 3. we used up a lot more... as a freshman guy on the wiring team, I had to solder on countless limit switches that were constantly breaking. they were always getting caugth up and ripped off due to poor design.

Lesson: be sure that you switch works both directions (so if something overshoots and returns it doesn't rip apart the switch).