Upper Limit on Claw Speed for Open/Close

[brandonbald13]

Find a way to change the speed of the gripper with a code constant. maybe integrate into smartdashboard with a slider or a textbox?

[robstolarz]

What is a situation in which the claw's speed would need to be changed? Also, we don't use SmartDashboard.

[brandonbald13]

for the new claw, with the window motors? because we don't want to accidentally destroy any crates or all of our limit switches in one match

[robstolarz]

If the limit switches work (which they had better) then we won't have those issues. The Claw stops when they're triggered, no matter which claw. I am totally against slowing down the new claw, because its speed is the thing that's going to help us win.

[brandonbald13]

The new claw opens and closes almost instantaneously as is. We want to add some sort of code constant so that we don't destroy the limit switches.

[robstolarz]

I kind of doubt that they'll break when used that way. If we test whether they're closed or not at 50 times/second and they close at x cm/second, and the Claw has y seconds of stopping latency, how ±"overclosed" (in cm) will the Claw be? My guess is, not much. But if you have numbers and they're unsatisfactory, then go for it. I won't stop you. I'll just disagree.

If the motors really do impart too much force then that sucks.

[TheKrunch]

I fully agree with Rob. Brandon I see no benefits in slowing down the Claw.

Matt Scalzo

On Sat, Mar 21, 2015 at 12:52 PM, Rob Stolarz notifications@github.com wrote:

If the limit switches work (which they had better) then we won't have those issues. The Claw stops when they're triggered, no matter which claw. I am totally against slowing down the new claw, because its speed is the thing that's going to help us win.

— Reply to this email directly or view it on GitHub https://github.com/team178/TheClaaaw/issues/6#issuecomment-84389421.

http://www.fpsct.org

The documents accompanying this fax or e-mail transmission, including any attachments, are for the sole use of the intended recipients and MAY contain confidential school, health or other information that is legally privileged. The authorized recipient of this information is prohibited from disclosing this information to any other party unless required or permitted to do so by law or regulation.

If you are NOT the intended recipient you are hereby notified that ANY disclosure, copying, or further distribution of the contents of these documents is prohibited. If you have received this information via facsimile in error, please notify the sender immediately and arrange for the return or destruction of these documents. If information is received via e-mail and you are not the intended recipient, please contact the sender by e-mail immediately and delete/destroy both the original and the reply e-mail message.

[gluxon]

@callmeStriking and @TheKrunch Yes, you're both right. There's no point in having the claw open and close slower during matches, but mechanical and electrical need it for testing. This is an entirely new claw with new limit switches and wiring. If something is wired up wrong, we should be able to hit the limit switches before the ends of the claw hit our wrenches/fingers.

[robstolarz]

Thanks for raising the issue and joining us in discussion @brandonbald13 @gluxon commit 9e7ab32 doesn't tie the clawSpeed variable to SmartDashboard (which it should so we don't have to recompile) also it should probably be a public static field also changing 0 to DIRECTION_STOP should be in a separate commit so if the commit is reverted, that change isn't lost

Also, why not do all of that stuff in the dedicated test mode? There's a reason it exists both in WPILib and in RunningComponent, and this is it: for mechanical rather than programming testing. It would have been nice to discuss where it goes before finding it in the code. Perhaps commit 9e7ab32 should be reverted.