How should I program my claw so that it doesn't burn out too quickly?

Our team made a clawbot with a claw of 1:5 ratio. No need to submit code, I just want some tips on how I should go about programing the claw (my seniors told me it’s not idealto just throw them on the joysticks). There are clawbots out there with motors that like to burn out on the claws for some reason and I want to try my best to avoid it. Thanks

When you open the claw up, unless you have a lot of rubber bands pulling the claw in, the motors should be running at 0 or a very low speed. If possible, the motors should be running at a low speed when you are keeping the claw closed, and you can make the code in a way that you can change the speed to be higher if you are picking up more stars or a cube. You should probably test the claw and find out the lowest value the motors can run at to be able to do whatever you want to do. If you use that value you should be able to stop the motors from burning out very often.
So you should program the claw by making the motors move at a certain speed until you let go of a button, then they either stop moving or just keep running very slowly to push against the rubber bands.

Why does the speed of opening the claw effect it stalling? If it has a significant effect I will have to make some adjustments to my program, but I have always thought that the only problem is in closing and not opening.

thanks for the reply tesla, on that note I also have the same question of why the opening of the claw can cause stalling in the motors?

rubber bands, as well as being the key to something, it can also be a huge disadvantage, when pulling them apart, my friend.
You have now been blessed by a victim, of rubber bands

Try using this PID. clawangleleft and clawangleright are the potentiometers on each side of the claw. The code is such that the further away a claw arm is from its desired position, the more power it sends to the motor.


int clawset = 0
if(VexRT[Btn5U] == 1)
{
clawset = (clawset + 2)
}
if(VexRT[Btn5D] ==1)
{
clawset = (clawset - 2)
}
if((VexRT[Btn5U] == 0) && (VexRT[Btn5D] == 0)
{
}
while(true)
{
motor[clawArmReft] = ((0.3)*((clawset) - (sensorValue[clawangleleft])));
motor[clawArmRight] = ((0.3)*((clawset) - (sensorValue[clawangleright])));
}

Here is an extensively simple PI control loop that I used a while ago with my last robot(wink spoiler). It’s basic, but it works so good. If you want, you can replace the “2700” with an integer and allow a more manual control…


task claw(){//AutomaticDriven(if button pressed, close claw. If not, open claw)
while(true){
if(vexRT[Btn5U]==1){
motor[ClawL]=((SensorValue[LeftClawPot]-2700/*Width From Starting Pos.*/)/5/*Sensitivity*/);
motor[ClawR]=((SensorValue[RightClawPot]-2700/*Width From Starting Pos.*/)/5/*Sensitivity*/);
}
else{
motor[ClawL]=((SensorValue[LeftClawPot]-1200/*Width From Starting Pos.*/)/10/*Sensitivity*/)^2/*Slope*/;//
motor[ClawR]=((SensorValue[RightClawPot]-1200/*Width From Starting Pos.*/)/10/*Sensitivity*/)^2/*Slope*/
}
}
}

Here’s what I’m talking about:


task claw(){//ManualDriven(one button pressed, close claw. another button pressed, open claw. Else, stop)
int anglemeasure = 0
while(true){
wait1msec(100);
//Value Control
if(vexRT[Btn5U]==1){
anglemeasure=anglemeasure+100
}
else if(vexRT[Btn5D]==1){
anglemeasure=anglemeasure-100
}
else{
anglemeasure=anglemeasure
}
//Prevention of Overextending
if(anglemeasure>2700){
anglemeasure=2650
}
else if(anglemeasure<1000){
anglemeasure=1050
}
//Apply the integer to the motors
motor[ClawL]=((SensorValue[LeftClawPot]-(anglemeasure)/*Width From Starting Pos.*/)/5/*Sensitivity*/);
motor[ClawR]=((SensorValue[RightClawPot]-(anglemeasure)/*Width From Starting Pos.*/)/5/*Sensitivity*/);
}
}

EDIT//: I made some changes to the code, as well as I want to note that each claw has their own seperate potentiometer.

Simple PID code is your best bet as twisted and cataclysm said above. Not only can it be understood in an afternoon, but it is the first steps into the basics of control theory and feedback loops, a staple for anyone involved in industry mechatronics.

Once your team comes to understand PID, they can begin using it for autonomous, setting lift heights, driving straight despite power asymmetry, and the big one PREVENTING MOTOR FATIGUE. If your claw, lift, or drive train gets caught on an obstacle, PID loops can include counters for conditions where motor speed is high, but velocity (derivative value) is low, and then change the motor speed multiplier to like 30% of its set value until you instruct it otherwise.

We found that code like this burned out our claws. Because the target value is being set to the closed position but cannot actually close that far because of game objects, the claw motors are sent a relatively high motor value and burn out. Here’s a better option:


task clawControl(){
     int PIDTargetValue;
     //PID constants. Do research if you don't know what these are
     float kp = 0.5;
     float ki = 0.01;
     float kd = 0.00001;
     int error;
     int integral = 0;
     int derivative;
     int lastError;
     int PIDDrive;
     while(true){
          if(vexRT[Btn[6U] == 1{
               //open claw
               motor[clawRight] = 127;
               motor[clawLeft] = 127;
               PIDTargetValue = (SensorValue[leftPot] + SensorValue[rightPot])/2;
          }
          else if{vexRT[Btn[6D] == 1){
               //close claw
               motor[clawRight] = -127;
               motor[clawLeft] = -127;
               PIDTargetValue = (SensorValue[leftPot] + SensorValue[rightPot])/2;
          }
          else{
               //PID to hold
               error = PIDTargetValue - (SensorValue[leftPot] + SensorValue[rightPot])/2;
               integral += error;
               derivative = error - lastError;
               PIDDrive = kp*error + ki*integral + kd*derivative;
               motor[clawRight] = PIDDrive;
               motor[clawLeft] = PIDDrive;               
               lastError = error;
          }
          wait1msec(15);//don't hog cpu
     }
}

What about my code? It’s really simple and never gives us trouble.

I guess it can work, I’m not keen on the idea of moving around the target value like that (or the formatting… I can tell it’s a P loop, but the formatting makes it much harder to read/use). Earlier in the year we used something similar for lift control, but it turned out pretty poor because we had to adjust the step-up and step-down (clawSet in your case). This adjustment went pretty poorly, which made scoring pretty hard.

Or even a simple bang bang loop will work. You don’t necessarily need PID. When it’s close to it’s target it can get pretty slow which may get annoying. Since you don’t need exact precision with a claw, something like this works great. We had a 5:1 ratio on our claw and never stalled it out.

Note, this is written for PROS and encoders, but should be pretty easy to switch to robotc and potentiometers. Feel free to ask for help if you want to try this out.

Can you go a little more in depth of what a bang bang loop actually does @StaticShadow ? I’ve been using PID for my claw most of the year and that solved most of my issues, I also would like to learn about other types of control loops

If PID is too slow it isn’t tuned right. A bang bang controller does seem like a pretty good option though…

@shawman94588 here is some cool bang bang code:


if(sensorValue[pot] > target) motor[claw] = 127;
else if(sensorValue[pot] < target) motor[claw] = -127;
else motor[claw] = 0;

We tried using that, but the claw will continue to go back and forth.

Oh that’s what I was doing before I swapped to PID. In my opinion I think a decently tuned p controller would be a lot better then bang bang

Sure thing. The code I posted is relatively complex for what it is, so looking at @mwang17 example may help; it’s pretty much bare bones. Bang bang is basically a loop that switches between on and off. If the current value isn’t at it’s target, it will turn the motors on until it gets there, then turn them off. This differs from PID which will continuously change the speeds as it’s distance from target, or it’s error, changes. This is great for precision, but not really needed here.

The complexity in our code is to limit when the motors need to be turned on, keep the sides synchronized, and control the claw in auton:

The sides of our claw weren’t geared together, so the code would slow down the side of the claw that was more towards the current goal (closed if pressing one button, open for another), keeping things aligned. The nice thing about this is that it doesn’t care if it misaligns when you, for example, close on a big clump of objects. This makes it super easy to get objects and go. It may misalign for a second like this, but will correct when you open to dump.

The program also works by saving the position of the claw when the buttons are released. When this is done the claw no longer cares about the two sides being aligned until another button is pressed, but instead focuses on holding the arms where they are. This makes it so you rarely drop objects. If the code detects the claw arms are a certain distance from the position they stopped in, it’ll run the motors against the misalignment until it’s back where it wants to be. This will automatically run the motors for you when you’re grabbing a clump, and won’t run the motors when your claw is open and not grabbing.

Like I said, our code is more complex than what you need to get working, but makes it a lot nicer to drive with. If you want I can add a bunch of comments to that file.

I can probably post a video in a little bit

You need to use a threshold, it will rarely get the exact value

Do some research on motor slewrate, it keeps all my motors from burning out, only on VERY rare events do they burn out

our claw has a program (using a potentiometer) that will put 0 pressure on the claw if it is halfway extended, but will put about 15/20 pressure(power) on it when it isn’t halfway extended, meaning helping it close and not pressing a button all the time. Aka: not burning your motors out. It works, and seems easier than what all the other replies have been