Slowing down the drive motors

[anthonygraff24]

My team is using the standard gearbox for our drive train and with two motors on each side the wheels move way too fast. I'm using the standard tank drive code with two joysticks for driving. The way it is now, unless the joystick is barely pushed forward the robot kindof goes out of control, there is a lot of torque, and the robot shakes too much for comfort. Is there a way to code the robot so that I can still use a standard tank drive but slow the motors down? I hope I'm being clear enough as to what the problem is but I can clarify if I'm not <3

[notmattlythgoe]

Originally Posted by anthonygraff24

My team is using the standard gearbox for our drive train and with two motors on each side the wheels move way too fast. I'm using the standard tank drive code with two joysticks for driving. The way it is now, unless the joystick is barely pushed forward the robot kindof goes out of control, there is a lot of torque, and the robot shakes too much for comfort. Is there a way to code the robot so that I can still use a standard tank drive but slow the motors down? I hope I'm being clear enough as to what the problem is but I can clarify if I'm not <3

Can you post your code so I can see how you are implementing the drive code currently? Please use code tags when doing this. To use a code tag place a [/code] at the end of the code and a [code] at the beginning.

[gpetilli]

There are several ways to slow it down in software. When you create the joysticks, you can specify to square the inputs, which helps give more sensitivity near zero commands. Other methods of changing the max voltage output or the gain do hurt the performance of the motors.

One mechanical method to get more control is to get new CIM gears from VEX - if you have 14T, they sell a 13T and if you are using a 12T, they sell an 11T. This will only give you a 10% reduction in top speed, but it will improve overall performance because the CIM motor is rotating faster for the same robot velocity. There are other threads that explain the difference better.

[anthonygraff24]

Originally Posted by notmattlythgoe

Can you post your code so I can see how you are implementing the drive code currently? Please use code tags when doing this. To use a code tag place a [/code] at the end of the code and a [code] at the beginning.

package org.usfirst.frc.team2872.robot;

import edu.wpi.first.wpilibj.IterativeRobot;
import edu.wpi.first.wpilibj.Jaguar;
import edu.wpi.first.wpilibj.Joystick;
import edu.wpi.first.wpilibj.RobotDrive;
import edu.wpi.first.wpilibj.Talon;
import edu.wpi.first.wpilibj.Victor;
import edu.wpi.first.wpilibj.livewindow.LiveWindow;

/**
 * The VM is configured to automatically run this class, and to call the
 * functions corresponding to each mode, as described in the IterativeRobot
 * documentation. If you change the name of this class or the package after
 * creating this project, you must also update the manifest file in the resource
 * directory.
 */
public class Robot extends IterativeRobot {
	RobotDrive myRobot;
	Joystick stick1;
	Joystick stick2;
	int autoLoopCounter;
	Victor Winch = new Victor(2);
	
    /**
     * This function is run when the robot is first started up and should be
     * used for any initialization code.
     */
    public void robotInit() {
    	myRobot = new RobotDrive(0,1);
    	stick1 = new Joystick(0);
    	stick2 = new Joystick(1);
    	Winch.set(-.15);
    }
    
    /**
     * This function is run once each time the robot enters autonomous mode
     */
    public void autonomousInit() {
    	autoLoopCounter = 0;
    }

    /**
     * This function is called periodically during autonomous
     */
    public void autonomousPeriodic() {
    	if(autoLoopCounter < 100) //Check if we've completed 100 loops (approximately 2 seconds)
		{
			myRobot.drive(-0.5, 0.0); 	// drive forwards half speed
			autoLoopCounter++;
			} else {
			myRobot.drive(0.0, 0.0); 	// stop robot
		}
    }
    
    /**
     * This function is called once each time the robot enters tele-operated mode
     */
    public void teleopInit(){
    	 Winch.set(-.15);
    }

    /**
     * This function is called periodically during operator control
     */
    
    
    public void teleopPeriodic() {
        myRobot.tankDrive(stick1,stick2);
        Winch.set(-.15);
        if(stick1.getRawButton(2))
        	Winch.set(.05);
        if(stick1.getRawButton(3))
        	Winch.set(-.5);
    }
    
    /**
     * This function is called periodically during test mode
     */
    public void testPeriodic() {
    	LiveWindow.run();
    }
    
}

[notmattlythgoe]

Originally Posted by anthonygraff24

package org.usfirst.frc.team2872.robot;

import edu.wpi.first.wpilibj.IterativeRobot;
import edu.wpi.first.wpilibj.Jaguar;
import edu.wpi.first.wpilibj.Joystick;
import edu.wpi.first.wpilibj.RobotDrive;
import edu.wpi.first.wpilibj.Talon;
import edu.wpi.first.wpilibj.Victor;
import edu.wpi.first.wpilibj.livewindow.LiveWindow;

/**
 * The VM is configured to automatically run this class, and to call the
 * functions corresponding to each mode, as described in the IterativeRobot
 * documentation. If you change the name of this class or the package after
 * creating this project, you must also update the manifest file in the resource
 * directory.
 */
public class Robot extends IterativeRobot {
	RobotDrive myRobot;
	Joystick stick1;
	Joystick stick2;
	int autoLoopCounter;
	Victor Winch = new Victor(2);
	
    /**
     * This function is run when the robot is first started up and should be
     * used for any initialization code.
     */
    public void robotInit() {
    	myRobot = new RobotDrive(0,1);
    	stick1 = new Joystick(0);
    	stick2 = new Joystick(1);
    	Winch.set(-.15);
    }
    
    /**
     * This function is run once each time the robot enters autonomous mode
     */
    public void autonomousInit() {
    	autoLoopCounter = 0;
    }

    /**
     * This function is called periodically during autonomous
     */
    public void autonomousPeriodic() {
    	if(autoLoopCounter < 100) //Check if we've completed 100 loops (approximately 2 seconds)
		{
			myRobot.drive(-0.5, 0.0); 	// drive forwards half speed
			autoLoopCounter++;
			} else {
			myRobot.drive(0.0, 0.0); 	// stop robot
		}
    }
    
    /**
     * This function is called once each time the robot enters tele-operated mode
     */
    public void teleopInit(){
    	 Winch.set(-.15);
    }

    /**
     * This function is called periodically during operator control
     */
    
    
    public void teleopPeriodic() {
        myRobot.tankDrive(stick1,stick2);
        Winch.set(-.15);
        if(stick1.getRawButton(2))
        	Winch.set(.05);
        if(stick1.getRawButton(3))
        	Winch.set(-.5);
    }
    
    /**
     * This function is called periodically during test mode
     */
    public void testPeriodic() {
    	LiveWindow.run();
    }
    
}

Change this line:

myRobot.tankDrive(stick1,stick2);

to this:

myRobot.tankDrive(stick1.getY() * 0.5, stick2.getY() * 0.5);

Then change the 0.5 to some scalar value depending on how much you want to scale it.

[anthonygraff24]

Originally Posted by notmattlythgoe

Change this line:

myRobot.tankDrive(stick1,stick2);

to this:

myRobot.tankDrive(stick1.getY() * 0.5, stick2.getY() * 0.5);

Then change the 0.5 to some scalar value depending on how much you want to scale it.

Awesome. Thank you so much!

[cstelter]

Originally Posted by notmattlythgoe

Change this line:

myRobot.tankDrive(stick1,stick2);

to this:

myRobot.tankDrive(stick1.getY() * 0.5, stick2.getY() * 0.5);

Then change the 0.5 to some scalar value depending on how much you want to scale it.

If your joystick has a throttle (any knob/lever that can be set and will stay at a value), you can read that value for the 0.5's above. A bit of math may be required-- the Extreme 3d our team uses goes -1 at the up position (what we think of as full throttle) and +1 at the bottom end so we use

double throttle=(-1*stick.getThrottle() + 1)/2;

This gives us a value between 0 and 1 depending on where the throttle is.

Depending on your stick, you may need to call getZ or some other mapping if you have a throttle. I can't say for sure-- we've only used the one joystick with this year's software.

[PAR_WIG1350]

If you raise the stick values to a power, instead of multiplying by a constant, you might be able to get more control at low speed without reducing the maximum speed. Typically, for this application, the value is squared or cubed.
Since all values are between -1 and 1, this actually reduces the value at all points. Just be careful about squaring negatives, you need to preserve the sign somehow.

[GeeTwo]

Originally Posted by notmattlythgoe

Change this line:

myRobot.tankDrive(stick1,stick2);

to this:

myRobot.tankDrive(stick1.getY() * 0.5, stick2.getY() * 0.5);

Then change the 0.5 to some scalar value depending on how much you want to scale it.

A simple way to still allow full top speed but give fine control at low speeds is to square the magnitude. You'll get 1/4 speed at half throw on your joystick, and full speed at full throw:

myRobot.tankDrive(stick1.getY() * Math.abs(stick1.getY()),
 stick2.getY() * Math.abs(stick2.getY());

[notmattlythgoe]

Originally Posted by GeeTwo

A simple way to still allow full top speed but give fine control at low speeds is to square the magnitude. You'll get 1/4 speed at half throw on your joystick, and full speed at full throw:

myRobot.tankDrive(stick1.getY() * Math.abs(stick1.getY()),
 stick2.getY() * Math.abs(stick2.getY());

Correct. Only if you don't want to limit your top speed.

[Ether]

Arguably the simplest and most flexible way to contour your joystick's output is to use a piecewise linear function for each axis.

Here's a simple example.

[cstelter]

Originally Posted by notmattlythgoe

Correct. Only if you don't want to limit your top speed.

Hmm. Unless I'm reading the RobotDrive code wrong:

public class RobotDrive implements MotorSafety {
    ...
    public void tankDrive(double leftValue, double rightValue, boolean squaredInputs) {

        if(!kTank_Reported) {
            UsageReporting.report(tResourceType.kResourceType_RobotDrive, getNumMotors(), tInstances.kRobotDrive_Tank);
            kTank_Reported = true;
        }

        // square the inputs (while preserving the sign) to increase fine control while permitting full power
        leftValue = limit(leftValue);
        rightValue = limit(rightValue);
        if(squaredInputs) {
            if (leftValue >= 0.0) {
                leftValue = (leftValue * leftValue);
            } else {
                leftValue = -(leftValue * leftValue);
            }
            if (rightValue >= 0.0) {
                rightValue = (rightValue * rightValue);
            } else {
                rightValue = -(rightValue * rightValue);
            }
        }
        setLeftRightMotorOutputs(leftValue, rightValue);
    }
    ...
    public void tankDrive(double leftValue, double rightValue) {
        tankDrive(leftValue, rightValue, true);
    }

It looks like tankDrive(double,double) squares the inputs by default. So doing what is suggested will ^4 the inputs. It will certainly have the advertised effect either way. But if your robot won't really move until you apply 0.4 for example, you have to get your joystick all the way out to ~0.8 before it moves.

The best plan is probably to do as Ether suggested and go piece-wise linear. Perhaps first find your sweet-spot for operating the robot (say 0.4-0.7) map your deadzone to ~10-20% less than the minimum power to drive your robot and then map 0.9 to be the maximum you want to drive and then map 1.0 to 1.0.

There are many ways to code an OI...

I'll mention that what our team sees as a way to not lose motor strength and yet drive very slowly is to use a feedback encoder system so you are asking the wheels to go 0.4 of their fastest rotation rather than 0.4 constant output voltage. This way a PID can apply full power to the wheels to get it going but quickly cut back power as you reach your requested rate. If you are moving very slowly and something gets in your way, you can apply the full power of your cims to overcome and if your wheels happen to slip the PID would likely compensate back down to the maximum power possible without overcoming friction.

[notmattlythgoe]

Originally Posted by cstelter

Hmm. Unless I'm reading the RobotDrive code wrong:

public class RobotDrive implements MotorSafety {
    ...
    public void tankDrive(double leftValue, double rightValue, boolean squaredInputs) {

        if(!kTank_Reported) {
            UsageReporting.report(tResourceType.kResourceType_RobotDrive, getNumMotors(), tInstances.kRobotDrive_Tank);
            kTank_Reported = true;
        }

        // square the inputs (while preserving the sign) to increase fine control while permitting full power
        leftValue = limit(leftValue);
        rightValue = limit(rightValue);
        if(squaredInputs) {
            if (leftValue >= 0.0) {
                leftValue = (leftValue * leftValue);
            } else {
                leftValue = -(leftValue * leftValue);
            }
            if (rightValue >= 0.0) {
                rightValue = (rightValue * rightValue);
            } else {
                rightValue = -(rightValue * rightValue);
            }
        }
        setLeftRightMotorOutputs(leftValue, rightValue);
    }
    ...
    public void tankDrive(double leftValue, double rightValue) {
        tankDrive(leftValue, rightValue, true);
    }

It looks like tankDrive(double,double) squares the inputs by default. So doing what is suggested will ^4 the inputs. It will certainly have the advertised effect either way. But if your robot won't really move until you apply 0.4 for example, you have to get your joystick all the way out to ~0.8 before it moves.

The best plan is probably to do as Ether suggested and go piece-wise linear. Perhaps first find your sweet-spot for operating the robot (say 0.4-0.7) map your deadzone to ~10-20% less than the minimum power to drive your robot and then map 0.9 to be the maximum you want to drive and then map 1.0 to 1.0.

There are many ways to code an OI...

I'll mention that what our team sees as a way to not lose motor strength and yet drive very slowly is to use a feedback encoder system so you are asking the wheels to go 0.4 of their fastest rotation rather than 0.4 constant output voltage. This way a PID can apply full power to the wheels to get it going but quickly cut back power as you reach your requested rate. If you are moving very slowly and something gets in your way, you can apply the full power of your cims to overcome and if your wheels happen to slip the PID would likely compensate back down to the maximum power possible without overcoming friction.

You are absolutely correct, the tankDrive(x, y) method does square the input values already. So squaring them again would probably make the controls worse in this case.