Motor Controller PWM Changes

So… our motors seem to be underperforming. There has to be a way to make them go faster.

^ ^ ^ I know that there’s a motor friendly way to calibrate according to joystick min and max values. I’m wondering if there’s a way to do this manually, based on the FRC Java library functions.

Specifically, from https://first.wpi.edu/FRC/roborio/release/docs/java/edu/wpi/first/wpilibj/PWM.html#setBounds(double,double,double,double,double)

public void setBounds​(double max, double deadbandMax, double center, double deadbandMin, double min)

max - The max PWM pulse width in ms
deadbandMax - The high end of the deadband range pulse width in ms
center - The center (off) pulse width in ms
deadbandMin - The low end of the deadband pulse width in ms
min - The minimum pulse width in ms

What do these variables mean and how does one determine these values?.. or if there’s a different function I should be using…

Also, there seems to be two types of deadband: one related to transistors, H-bridges and whatnot; one related to input and output values. Any clarification on this would be much appreciated.

As far as I’ve researched: PWM only does speed. Something else controls the positive and negative, which results in motor direction. So would that mean min is always 0? Then what does center mean? Is it not when the joystick is centered?

Almost every motor controller made for FRC is a range of 1k - 2k ms pulse timing by default, and the RIO default outputs that. The calibration really is used for non-FRC use (RC controller, for example).

You’d be much better analyzing current draw, mechanism design, and most importantly, battery quality.

2 Likes

I would be very surprised if any of the issue you are seeing is related to calibration.

PWM sends a duty cycle. So “0” as the motor understands it is actually half way between 0 and max on the Duty cycle. So 50% duty cycle on the PWM signal means “stop” to the motor controller.

PWM doesn’t control speed. Its controls the voltage output that the motor sees. What speed the motor goes is determined by the physical characteristics of the motor and system it’s connected to when supplied with that voltage.

To quote Don Rototo from an earlier post:
where a pulse of 1.0 mSec width is considered “zero”, 1.5 mSec is considered “127” and 2.0 mSec is considered “255”. These pulses are sent every 20 mSec or so, but this timing can and does vary by application, and can be anything from about 4 mSec to 100 mSec, as reasonable values.

A piece of hardware (think “IC Chip”) is then used to translate the 0 - 255 signal to a motor drive signal. Using a Victor as an example, a 0 is full reverse, and 255 is full forward. Between those two extremes is where it gets interesting.

In the case of 3/4 forward, what the victor actually feeds the motor is 75% of the time a full forward signal, and 25% of the time a full reverse signal - flipping back and forth very fast, one or 2 thousand times per second (but this can be from dozens to tens of thousands per second). Because of the mass and inertia of the motor, it reacts as if you just sent 75% of the regular voltage, instead of actually reversing.

This means, the victor has only two output states: Full forward and full reverse. By switching between them very fast, the motor sees the ‘average’ and reacts accordingly.

This drive signal is also a kind of PWM, but really we call it is “Square wave” with a certain “Duty cycle”, which varies between 0% and 100%. You can have 2 kinds of drive: full reverse to full forward, or 0 to full but with a separate signal for direction.

(P.S. didn’t mean to reply to Tom here)

There are two definitions of the term PWM at work here.

One is the PWM signal that the roboRIO sends the motor controller telling it what you want the controller to do. It’s a 1-2ms signal between 0 and 5volts. 1 ms indicates you want full reverse, 1.5 ms indicates neutral or no power, 2 ms is ordering full forward.
It’s just a communication signal that tells the motor controller what you’d like it to do.
This is the signal that gets the calibration you’re asking about.
That calibration is just intended to accommodate flaws that the game controller you are using may have, e.g., a sloppy game controller joystick may only return 1.2ms to 1.8ms. Motor Controller calibration allows you to make the Motor Controller match the min and max travel of the game controller tick.

Two is the actual duty cycle that the motor controller performs to actually vary the motor speed.
For instance, the motor controller sends 100% of your available 12v battery power to the motor 100% of the time for full forward. For half power it sends full 12v power half (50%) the time and cuts it to 0 for the other half of the time-that averages out to 50% power (feels like 6v but is really only 12v or nothing).
For reverse directions the motor controller just reverses the positive/negative lines.
P.S. Note that this is how the 2020 models Talon SRX and Victor SPX motor controllers operate. Future models might change their designs.

1 Like

It’s the full 12v (or whatever the battery voltage dips to) for 75% of the time, then no volts (coasting) for 25% of the time-not reverse.

2 Likes

Tom (and Don) describe locked anti-phase rectification, which was used in the original Talon. You describe sign magnitude rectification, which is used on the Talon SR, SRX, and Victor SPX.

The first thing to do is watch the LEDs on the motor controller. If they are going full green (forward) or red (reverse) then there’s nothing you can do in code. As tjf says, you need to look at mechanical and electrical design for why it’s slow.

If they stay flashing, then there is something that can be done in code, but the next step is to figure out why they aren’t receiving the full signal range. The first step is to write code that sends a speed of 1.0. If the lights turn full green, then the problem isn’t with the calibration, but rather somewhere else (like the joysticks). If the problem is with calibration, then you can calibrate per the manufactur’s procedure, or you can use the setBounds method. The PWMVictorSPX constructor documentation tells you what values it uses for setBounds. You would want to find the smallest value of max where there LED turns solid green when you command a 1.0 speed.

More then likely, the problem is with the joysticks. You can print the joystick values and determine an appropriate way to scale the joysticks. You should be getting 1.0 when the stick is all the way forward.

I’d forgotten about those original Talons.

There are also joystick value indicators on the Driver Station app USB tab.
If you highlight the joystick you can see the scale of each of the sticks, but it is a graphic and not a digital readout, so we don’t see the exact numbers sent.