Slowing down the drive motors

[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.

[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.