We were wondering if it’s an acceptable practice to have a second normally closed limit switch wired in line with a motor and sitting just a little longer in the throw, past the electrically monitored limit switch as a safety precaution?
The reason that I ask is that last season we had two instances where our software controlled limit switch either didn’t work or was physically knocked off center causing a very strong bag motor with planetary gearbox to bend and break our launching mechanism as it didn’t shutoff the motor at the end of the throw.
About the software you were using to detect the switch state: Was this an interrupt service routine or a polled task? If polled, at what frequency?
About the software you were using to react to the limit switch state: Was this an interrupt service routine or a polled task? If polled, at what frequency?
About the limit switch actuating lever: did you add a flexible extension to prevent permanent bending of the lever?
and finally:
What’s the current rating on the limit switch you plan to put in the power line going to the motor?
Actually I’d not like to put FRC legality aside, if it’s against the rules then we don’t want to do it.
Our motor controllers are Talon SR’s and not Jag’s with CAN controlled limits, and to focus on one of the scenario’s - lets go with the switch was physically damaged during a match (and it was), so we can leave programming out of the discussion for right now unless the thinking is to add another monitor in addition to the limit switch.
Yes the normally closed limit switch would need to be rated for the current draw of the bag motor.
Just wondering if this is possible and legal.
Thanks for the reply!
Yes, the limit switch would be a safety mechanism and the robot would be done for the match however it could be fixed much easier than replacing a mangled launching assembly.
Do you know with acceptable certainty why the switch got damaged? I ask because in your original post it sounded like you don’t know why:
two instances where our software controlled limit switch either didn’t work or was physically knocked off center
Before you fix something, it’s worthwhile to make a concerted effort to figure out why it failed. Software could be the cause. Or lack of a flexible extension on the actuation lever. Or improper mounting of the switch.
Understandable, but similar to the reasoning behind breakers on the PDB - there could be a plethora of failures/mistakes/accidents and therefore never a bad idea to provide a safety mechanism to help narrow the scope of imperfection.
Not necessarily. If the arm contacted a spring (a cushioned hard-stop is a good idea anyway) that was able to push the arm off the switch after the switch cut power to the motor, you could reset everything. That’s just an example.
If your root-cause failure analysis reveals that it’s a software timing issue (your software as designed can’t reliably respond fast enough to the limit switch), you might want to consider using a pot instead of a limit switch as your primary means of preventing motor overtravel. That would give your software a lot more time to respond and slow the motor down.
A limit switch in the motor power pathway sounds like it would violate last year’s R50 and primarily R53, but a robot inspectors advice is more valuable on questions such as these.
R53
CUSTOM CIRCUITS shall not directly alter the power pathways between the ROBOT battery, PD Board, motor controllers, relays, motors, or other elements of the ROBOT control system (items explicitly mentioned in R64). Custom high impedance voltage monitoring or low impedance current monitoring circuitry connected to the ROBOT’S electrical system is acceptable, if the effect on the ROBOT outputs is inconsequential.
I agree with Mark that it isn’t legal to place a limit switch inline with a motor.
We’ve typically chosen two options from the following list:
Limit Switch with software control
Potentiometer or Encoder with PID control and soft limits
Current sensor
Mechanism robust enough that it doesn’t matter
Another option is to use the limit switch inputs on the jaguars, which will operate faster then your software and won’t get commented out accidentally.
Anyway, as much as I like to rag on the software guys, Limit switch failures are almost always mechanical & how they actually stop the motor is not the issue.
Anything that requires double protection like you are suggesting, you want to separate the modes of operation as much as practical. Like using a feedback pot for normal posting & limit switch through a jag for the end points.
As others have said, this would be illegal. The intent, as I read it, of R53 is one of safety- we need to know that the robot will cooperate in a predictable way when connected to the field (for example the field says stop and the motors all stop), and we need to know that the components can handle the current the motor is going to be pulling. As such, this is something I could see as being something teams could lobby the HTC to change in future years- an appropriately rated limit switch wouldn’t prevent the motor from stopping. The trick is finding an appropriately rated limit switch and ensuring inspectors can verify rinsing catch on fire while on the field.
Using the limit switch into a jag helps, as it takes it out of the programmers control. Additionally, we’ve always designed in a hard stop that would force the motor to stall before a mechanism ripped itself apart. This was also a good place for the limit switch, as the hard stop can help prevent a mechanical failure of the switch. Leave it stalled long enough and the mechanism might still year itself apart, but the hard stop gives you a small buffer for the code to respond to the limit switch.
Where possible, potentiometer or absolute encoders can also come in handy for helping to control a mechanism and limit its range of motion.
Bmammen, your original thought is sound, but not allowed in FRC. My experience with machine tools is pretty dated and we made one-off tools rather than production tools, but we ALWAYS put a second limit switch beyond the first one, and the second switch was connected to a relay or contactor that killed the entire system (no software involved). This second switch is surprisingly expensive, because you need a couple of inches of extra travel to accommodate the switch plus deceleration of the carriage. This year we built a linear test fixture with exactly these provisions for testing software because:
In FRC, our experience is that the best method is to use encoders and PID, with soft limits, so that the actual limit switches should never be encountered except during initialization (homing). However, there are multiple conditions that will cause the system to lose zero during a match, which you are apparently aware of. It is therefore very important that software be able to deal with hitting a limit switch, and it is a continual battle to keep our software folks and their code doing the right thing. In particular, kids often think it’s OK to use open loop control and just monitor the limits (particularly for joystick mode), or they find that they never actually hit the limits using programmed moves, so the software that responds to them “atrophies”, and bad things happen when they inevitably hit them. The response once you’re in a limit switch can be debated, but we generally allow motion in the appropriate direction to get off the switch, and what happens after that depends on your tolerance for risk, because it should never have hit it in the first place.
I learned long ago in my FRC career that it’s a good idea to make mechanisms that don’t get hurt, if the motor keeps running. Yes, it takes some effort to figure out how to do this, but it can usually be done.
one trick is to have motors that spin rollers. Another is to use pneumatics for stuff that has to move a limited distance. Another is to have a “clutch” of some sort, such as a V belt that can slip, instead of a toothed belt or chain.
It’s not that I don’t trust the programmers…it’s just that things somehow always go wrong. Mr. Murphy is usually hanging around the shop.
If you are worried about failure of a single limit switch then just wire in two so you have a back up. Use the NO contact and wire them separately and in your code have it stop if either of them put out a signal. Relatively simple and legal under last season’s rules. Having one in the power path would not be legal under last year’s rules and I’d bet that it won’t be legal under next year’s rules. Additionally the problem is finding a limit switch rated for the amperage that the motor is rated for along with the fact that it would kill that motor for the rest of the match.
The commonly available limit switches are usually rated for something like 3-5Adc with (inductive) motor loads. The stall current of a BAG motor is 41Adc. It is quite possible that the arcing that would occur as the contacts open will cause them to weld closed, defeating your protection scheme.
So far everyone is correct as to the rules for 2014 (Mark, Jon and Philso). I would like to add that is pretty easy to design the limit switch mounting such that it will not be damaged by over-travel in the mechanism it is designed to limit. Rather than hitting the switch lever head on, just design it so that the lever “follows” the mechanism that is being sensed. By doing that, no stress is placed on the switch or the operating lever.
