Do teams customize swerve controls?

Technical
1

Hello, this might be something really stupid but I was wondering if teams customize swerve controls to drive more smoothly or easier. Do teams have speed caps, dampers or different configurations in code? Do teams mess with the sensitivity of the joystick? Or do teams just let the driver figure it out? Thanks!

2

Our team uses a “speed multiplier” to limit the speed of our swerves, since it can be pretty difficult for new drivers to handle the full speed of the drivetrain. We also have adjusted the sensitivity of the input joysticks in the past depending on our driver’s preference. Once they get a handle on the basics of the robot we can up the speed of the motors to be more competitive. However, these are all software edits, we don’t have any physical “dampers” on our robot to artificially slow down the motor speed. Hope this helps!

3

I’d say that if you have time it’s probably worthwhile to tune your swerve. Sure a driver could account for a lot. But it’s better to have the robot work for the driver. Than the driver work for the robot.

4

We’ve had a series of limits, scalers, dead zones and even a “Speed Boost”.

It all depends on the driver and what they feel comfortable with. I usually tell the programming team to artificiallly limit speeds when the drivers first start to limit possible damage and until they get the control down. You can always remove or lessen the values as their skills increase.

The speed boost was more of an override the caps while a button is held for when we were being defended.

5

One thing I would highly recommend is some sort of “slow mode”
For our controller, when the driver presses the right trigger, the swerve will slow down according to how much it is pressed
We call it shift mode, and it really does help you control the robot more in different situations
Also, having good current limits and good feedforward / feedback (mostly for auton) control for the driving motors will help with controlling the swerve

1 Like
6

We raise our turn input to the 3/2 just because I like that it gives me more control but can still turn fast if I need to. The one other thing we did was limit speed while our elevator was extended last year, so I didn’t need a slow mode. Other than that it was just normal controls.

1 Like
7

We have speed limits on both the drive and turn and slowly ramp it up over the season to get the drivers more comfortable.

I recommend putting in acceleration limits for the drivers to save your modules. We kept chewing up the L2 double gear to wheel shaft gears on our SDS modules because we had flightsticks for the drivers, and you could go from max 5 m/s to 0 in a 20ms loop.

We also replaced the WpiLib optimize function. It mostly makes sense, if you change forward to backward direction, no need to change the wheel heading. But you end up with problems:

  1. If one wheel is 88* off, and the other is 92* off, the wheels rotate in opposite directions, and you get a big yaw moment around a wheel.
  2. If the driver does quick enough of a turn past 90*, the robot will actually stop, as the wheel are >90* from the target, so it will try to spin the other way and reverse drive direction.

We just duplicated the WpiLib function and changed the critical angle to 120*. It smoothed out the drivers a lot.

8

We apply this function to our translation magnitude and yaw input.
Basically, it emphasizes more precise control at lower speeds by making the input an exponential function of the joystick value rather than a linear 1-1 direct input.

	/**
	 * Get exponential input from custom curves given the parameters <p>
	 *
	 * @param input    Input from joystick or whatever analog thing
	 * @param exponent Curve exponent. Should be greater than 1
	 * @param weight   Exponential weight. The closer this value is to 0 the closer the curve is to being linear. Should be between 0 and 1
	 * @param deadband Deadband. Should be 0 and 1.
	 * @return Exponential input from curve
	 */
	public static double getExponential(final double input, final double exponent, final double weight, final double deadband) {
		if (Math.abs(input) < deadband) {
			return 0;
		}
		double sign = Math.signum(input);
		double v = Math.abs(input);

		double a = weight * Math.pow(v, exponent) + (1 - weight) * v;
		double b = weight * Math.pow(deadband, exponent) + (1 - weight) * deadband;
		v = (a - 1 * b) / (1 - b);

		v *= sign;
		return v;
	}

We apply it like this.

       double xInput = -driverController.getLeftY()
                yInput = -driverController.getLeftX();
        double omegaInput = getExponential(-driverController.getRightX(), 4.3, .7, .1) * MAX_ANGULAR_RATE;

        double magnitude =
                MathUtil.clamp(
                        getExponential(Math.hypot(xInput, yInput), 3.6, 0.75, .1),
                        -1, 1) * MAX_SPEED;
        double angle = Math.atan2(yInput, xInput);
        xInput = Math.cos(angle) * magnitude;
        yInput = Math.sin(angle) * magnitude;
1 Like
9

in addition to control expo, 100 uses a constraint enforcer borrowed from 254 that applies constraints related to motor torque, steering rate, and centripetal acceleration.

the general idea is to give the drivetrain feasible input.