Slowing Down V5 Motors

When programming our robot for tank control the robot is way too fast. Tires connected to the motors spin before it goes anywhere and the controller is way too sensitive. But when it does autonomous by itself it drives slower, almost too slow. How do I speed up or slow down the motors. The code I have ended off with is below.

//Tank Control
int LeftDriveVelocity=5;
int RightDriveVelocity=5;
LeftDrive.setVelocity(LeftDriveVelocity, velocityUnits::pct);
RightDrive.setVelocity(RightDriveVelocity, velocityUnits::pct);
LeftDrive.spin(vex::directionType::fwd, Controller1.Axis3.value(), vex::velocityUnits::pct);
RightDrive.spin(vex::directionType::fwd, Controller1.Axis2.value(), vex::velocityUnits::pct);

Any suggestions would be super helpful, thanks in advance!

int LeftDriveVelocity=5;
int RightDriveVelocity=5;
LeftDrive.setVelocity(LeftDriveVelocity, velocityUnits::pct);
RightDrive.setVelocity(RightDriveVelocity, velocityUnits::pct);

These four lines don’t do anything, because you immediately ignore the velocity you set with these two lines:

LeftDrive.spin(vex::directionType::fwd, Controller1.Axis3.value(), vex::velocityUnits::pct);
RightDrive.spin(vex::directionType::fwd, Controller1.Axis2.value(), vex::velocityUnits::pct);

The


Controller1.Axis3.value()

and


Controller1.Axis2.value()

serve as the speed for the


spin

commands, so the previous velocity twiddling is overwritten immediately.

As for how to make it respond slower to joysticks, you have to scale them down. One common (and fairly easy) way to do this is to base the speed on the square of the joystick’s value instead of just the value itself, while preserving the sign. So replacing the value you had previously with value * abs(value) / 100. This preserves the top end speed at the far end of the joysticks’ travel while damping their response near the center.

Usually its cubic. Here is a graph of joystick cubed vs joystick itself.

Someone asked for this on facebook, here is my response from there.

1 Like

@taybor473 - TY for sharing the code - this makes great sense!

Like @tabor473 , I tend to favor cubic.

Do be aware of what type of variable you choose to hold the values. 100^3 is 1 000 000. So don’t use char, signed char, unsigned char, short, or unsigned short. Fortunately, int doesn’t have this problem until the low billions. But if you try messing around with something like the fifth power instead of the third power, the order of operations will matter. I want to say RobotC’s int was actually a C short and we ran into this issue with clipped values when maxing it out; but with true C/C++ int works far better.

I tried adding the code that @tabor473 had, and now I am having issues with my if and else statements. I deleted the first section for the motors because I have all of that in already. I also switched names to what mine are and the axis.
ClawBot.vex (11 KB)

You have “.spin(fwd” instead of “.spin(vex::directionType::fwd” twice. Your arm and claw control if statements are outside of your user control function, which is a big problem and is what you’ve identified. I also note that you have two while(true) statements embedded within each other.

Ya you have to be careful, in my example I rescale everything from -1,1] before cubing, which makes everything considerably easier. You will often have teams forgetting to divide by the maximum value squared when they square a value -127,127]. Obviously then you have to remember to make every variable a float.