paper: Current-Limiting Motor Control

Thread created automatically to discuss a document in CD-Media.

Current-Limiting Motor Control
by: gerthworm

A physics-based approach to preventing brownouts is presented.

A method for limiting motor voltage commands is presented. The target controlled variable is system voltage - too much current draw from the motors will lower system voltage to an unacceptable level. This limiting is achieved through calculations involving an adaptive observer plant model which estimates battery parameters in real time, and projections of current draw from motors.

The content of this paper corresponds to a presentation at the 2017 FRC championships in St. Louis.

Additional resources attached. Note that some parts of the algorithm already have sample Java implementations: see


Feel free to PM me here for more info!

current_limiting.pdf (2.02 MB)
BatteryLoadLimiting_FRCChamps2017.pdf (1.01 MB)
BatteryLoadLimiting_FRCChamps2017_with_notes.pdf (1.04 MB)
log_2017-03-12_125643.csv (4.84 MB)

Where are you getting the Vsys & Isys inputs from?
My understanding from our programming group was the PDP only updates on a 25ms rate and that’s why we didn’t want to do something like this… so we bought a set of 4 Talons & they worked great.

(I can’t find a reference anywhere in the PDP documentation, maybe my programmers meant we run at 25ms.)

The iterative solver for gamma looks like a clever ‘secret sauce’ to reduce the calculation weight at runtime. Great work!

Very interesting!

One thing that I’m curious about is how adding an observer to this would help counteract the errors with sensing voltage.

One of the kids on our team brought up the idea of modeling the entire robot as a single state space model with current for each motor included, and doing LQR on that to be able to weigh specific motors current draw more heavily than others. Probably a bad idea in practice, but I’m curious as to how well it would work out.

Yup, PDP. And Yup, it’s got a not-super-great sample rate. Granted, the whole control algorithm (as we implemented it) only updates at 20ms, so your quoted number isn’t too far off.

The intention was to only be using the PDP measurements as input for calculating slowly changing parameters, such as the battery parameters. For that, as long as the Vsys/Isys sample pairs are taken at reasonably the same time, the datalink delay and slower sample rate don’t matter as much. As noted in the later sections, we filtered the heck out of them anyway to get decent results.

I wouldn’t recommend trying to use Isys from the PDP to catch bad behavior - by the time you see a big spike in software, the datalink delays and sample rate make it such that it’s too late already.

I do believe I ended up using the Vsys measurement elsewhere to help predict what the voltage sent to the motors would be. This probably wasn’t the best, but it worked (RIO voltage could be another way to get this, or use the absolute voltage output mode on an SRX).

Possibly? I haven’t worked with LQR too much. If you do go down this route, be sure to include all the resistances from wires and connectors and circuit breakers and such - during our experiments, they definitely mattered. We did spend some time “tuning” the current draw estimation by adding an extra resistance. I would have liked to have just measured the system, but we didn’t have good equipment… so instead we kept tweaking the “other resistances” value until the estimated peak currents matched the measured peak currents somewhat (erring on the side of over-estimation for caution).

LQR would be pretty straightforward.

Another way to do this would be to use a scheduler to allocate current draw to subsystems based on priority.

Thanks to everyone who came to our presentation in St Louis covering this topic.
Here’s a video for those who missed it

Hi! I was reading your paper and I had a few questions!
In part 9 where you find the motor constants, you convert the freewheel-speed to radians/second. I was wondering why this is needed. Also, to convert it to radians/second wouldn’t you multiply by 2pi then divide by 60, in other words pi/30 rather than pi/180?

Sure! Purely by convention. Wikipedia lists that Kv is commonly in RPM/volt or (Rad/sec)/Volt.

Additionally, yes, you have caught a math error! I concur, conversion to radians per second was incorrect. (Unless I’m similarly tired now as to when I wrote this, pi/180 converts rev->radian, but neglects the min/sec conversion) Looking now to see if that specific error propagated anywhere beyond that one calculation…

I do believe our 2016 code got it right though.

Typically, motor parameters are provided using radians/second. They don’t have to be, but this is typical.
There are 2*pi radians in a circle, as there are 360 degrees.
The unit conversion ends up as pi/180.