RE: Claw Kit

The only thing that you need to be careful of with using a servo with the claw kit is that if you pick up something and are holding it for a long time you will be stalling the servo while you are gripping the object. I had used a servo on a claw that i built when i first started vexing (yeah it’s a word ;)) and when i had tried to use it it would only grip the object for so long before releasing it and the servo would no longer work (i had tripped the thermal breaker). If you use a motor this will not happen as long as once you have a grip on the object you let go of the button controlling the motor.

If all you have left to use is a servo just be aware that you are stalling it while you grip objects and that you shouldn’t ever stall a servo (or motor) for too long.

just my $0.02

I got around this by switching the buttons behavior around via software. Instead of the presses being 127 and -127 (in RobotC), I trapped them and basically made them do + or - 5 for each press. That way you could grip something, then snug it down with 1 or 2 button presses, but you won’t be using the full force and it won’t be any issues like you mention.

The only down side to using a servo (to me) is that the claw doesn’t open as wide.

Even then i think you may still be stalling the thing. You mean + or - 5 encoder ticks or what? I don’t think this totally fixes the issue but it may make it a little bit better.

So the servo (in theory) has 255 positions between -127 and 127. The buttons on the back, in their perfectly normal and sane setup can only set those 3 values. No buttons is 0, one button is -127 and the other is 127.

So when you hold one down, the servo tries as hard as it can to get to 127. If something is blocking it from getting there, it will be stalled out and giving max torque to get there. You can feel this, just put your hand inside the claw and close it. It closes pretty hard.

If you were to go back and use my method, instead of the button causing the servo to go from 0 to 127… it would go from say 0 to 5. And then from 5 to 10. So lets say using your hand again you get it to just barely touching and that is at 50. The servo holds this position with little to no effort (of course, it doesn’t have a tight grip on your hand either). Bumpt that from 50 to 55 and maybe it has a tight enough grip to hold an empty can up, but you can tell the servo isn’t giving much effort. Bump it to 60 or 70 and it can maybe hold a full can and now you start to hear and see the servo struggling. But this is far far from the 127 limit the servo has, so it isn’t struggling that hard.

To add to it, if you have the springs it’ll make the job of the servo holding the claw closed even easier (of course, holding it open gets harder).

The code for doing something like that is a bit more complicated. Instead of setting the motor to the value of the button (which gets you only 3 possible values of -127, 0 and 127) you use those 3 values to detect that a button was pressed down (127 or -127) and that it was released (returns to 0). Then, each time you detect this condition you can set the motor to its current value plus 5 (or minus 5). You can increment or decrement by any value you want. Using 1 would give you super fine control but it might be slower to get it where you want. Using 10 or 20 would be much faster but you might grip something harder than you need to. Make it a variable or a constant and you can tweak it in one place in your program :slight_smile:

Edit: Actually, the code is easier than I described. I just looked for one or the other button being pressed and then started incrementing or decrementing the servo. This means that it will open or close while held down. If you did it the way I described above you could make it so that a quick button press would open/close a fixed (small?) amount and being held down could move it more and faster. But the below method is quick and easy. I guess I used a value of 25 too :slight_smile:

  	while ( vexRT[Ch5] >= 50 )
  		motor[clawServo1] += 25;

  	while (vexRT[Ch5] <= -50)
  		motor[clawServo1] -= 25;

What i ended up doing was giving the claw some slop and then putting a rubber band around it kinda like you said so when i would open it it would struggle but when it was gripping (which was much longer than the time it was opening) the servo could relax.

Motor or servo? Because servos don’t really ever relax. They either go to the position you tell them to go to or they struggle to get there. A motor would behave as you mention though, so perhaps you were using a motor?

You can also use a Stepper Motor as I did to position a solar panel for my SunBot shown in the VEX Gallery. It can be geared and holds its position.

Neat, how strongly does a stepper motor hold it’s position? Servos will fight to maintain their position, my impression of stepper motors is that the motor’s internal magnet setup holds the position, but not very strongly (or powered).

Generally, you wouldn’t use steppers in a battery powered device, because they are not particularly energy efficient compared to other DC motors. They are typically used to provide precise positioning with a fairly simple control system.

Steppers and DC motors won’t hold their position when unpowered (*). A Vex servo holds its position because it has a feedback loop and a built-in controller constantly adjusting power to the motor to try and maintain the set position. You could make a stepper behave like a servo too, if you added feedback and an appropriate controller.

In other words, the “fight” is a result of the feedback and controller rather than the motor itself.

(*) You can get a stepper or DC motor to resist turning (without using any power) by shorting the windings. This is generally called “breaking” in the world of motor controllers.


  • Dean

Much better description of how a servo works (I don’t think I even tried)!

Do servos use PID? They do use feedback to change their behavior, but I’m not sure if that counts as PID (also, how do you even say something involves “PID”) :slight_smile:

I suspect they do use PID, but I haven’t seen a specific reference that says so (nor have i looked). I guess they must use PID by some definition, even if they only use the P (proportional) term and use zero for the I & D coefficients (meaning I & D are not used).


  • Dean

Let me (hopefully) help you with something that has been one of my pet peeves every since I started helping in student robotics programs.

PID is just one acronym for an infinite subset of the infinite possible implementations of a feedback loop; and while many control systems use one of those infinite PID choices; in my opinion PID doesn’t deserve all the attention it gets in student robotics circles. Saying “PID is involved” hardly comes close to pinning down the actual behavior of a control system.

My advice is to not worry much about PID, and instead feel that you have a complete and accurate enough answer once you know that a feedback loop is involved. After you know that feedback is involved, asking if PID is involved is in some ways akin to asking what color a car is during a discussion of how much cargo the car can hold. When you get your answer, you haven’t advanced your understanding of the car much.

So, hang onto that feedback concept, it is the fundamental one. Don’t worry too much about the PID methods of implementing a loop unless you have to implement one, and at the same time you have instructions for setting up a PID system. And, on the other hand, if you have instructions for using another approach, use them.

No matter how many times you hear folks describe the PID appraoch as if it is the sole way to implement feedback systems, it isn’t. It is just one useful approach. Don’t give it more attention than it deserves.

See this post and the few that follow it in the same thread for more info: Blake’s Feedback Soapbox :slight_smile: