FRC Blog - 2016 Motor Controllers

[Ryan Dognaux]

Originally Posted by Thad House

Programmers better bring their A game this year if teams want any sort of speed with 3 CIMs. Some very intelligent ramping and shifting code is going to be required for all the top teams.

With everything I've been reading about brown outs, I think we're just going to go back to the tried and true '4 CIMs on your drive' depending on the game. It just isn't worth the risk of being dead on the field in a match.

[sastoller]

Great paper! I found the read very interesting, with very informative, useful results to help teams pick the right motor controller.

A great addition to this experiment would also have been to include temperature measurements on the motor controllers after 30 seconds, 1 minute etc. I would also love to see results for the older Talon SR and JAG motor controllers since many teams still use these. One final addition would be to test several motor controllers of the same type to get an idea of the variation between controllers (is it 1% or 10% variation between controllers of the same type?).

My big takeaway from all this is that the SD540 is unnacceptable for use in FRC robots due to the brown-out issue. In addition, with it's high output resistance, it would no doubt, would get very, very warm in a stall condition. You can estimate the power that is turned into heat in the output devices of the SD540 to be nearly 50 Watts in the resistive load test 3, at 11.20 volts. With a CIM motor, the SD540 would be dissipating ~100 watts of energy as heat. I wonder how long it takes to melt (can someone test and post pictures please)?

It looks like the SPARK is a very good controller, for the price. It performs nearly as well as the two pricier alternatives. The downside for the SPARK is the form-factor.

[James Kuszmaul]

Originally Posted by Michael Corsetto

Cross The Road Electronics has posted a detailed report of some Motor Controller Output Power Testing they preformed with the four main FRC speed controllers on the market:

• Victor SP
• Talon SRX
• SPARK
• SD540

Link to .pdf document here

Please take note of the test results on page 7. I'm very concerned about the SD540's performance, particularly that the SD540 appears to brown out at 9.5V.

2016 will be the year of the brown out...

-Mike

Very interesting, although it would be nice if someone could do these tests with multiple of each controller (in case of either defective units or just generally varying units). In particular, I wouldn't want to judge the SD540 too much without confirming the results on multiple units.

[Jared Russell]

Originally Posted by Thad House

Programmers better bring their A game this year if teams want any sort of speed with 3 CIMs. Some very intelligent ramping and shifting code is going to be required for all the top teams.

Maybe someone who knows a lot about working with motor controls would be willing to do a white paper or something how how to limit current. Trying to find documentation online on how to do that has been impossible for me.

It would be awesome if the Talon SRX gets a firmware update that lets it do this (current limiting). It can already do ramping.

[AdamHeard]

Originally Posted by Jared Russell

It would be awesome if the Talon SRX gets a firmware update that lets it do this (current limiting). It can already do ramping.

Yup Yup.

I'd love this for FRC, and a few non-FRC applications I use Talons for.

[notmattlythgoe]

Originally Posted by AdamHeard

Yup Yup.

I'd love this for FRC, and a few non-FRC applications I use Talons for.

A continuous sensor option would be nice too. Similar to the continuous sensor option in the WPILib PID Controllers.

[Thad House]

Originally Posted by Jared Russell

It would be awesome if the Talon SRX gets a firmware update that lets it do this (current limiting). It can already do ramping.

Even if its not built in, since we can access all the current and speed data, wouldn't we be able to do this on the RoboRIO? It wouldn't be anywhere close to as fast of a loop, but it should be good enough, right?

[notmattlythgoe]

Originally Posted by Thad House

Even if its not built in, since we can access all the current and speed data, wouldn't we be able to do this on the RoboRIO? It wouldn't be anywhere close to as fast of a loop, but it should be good enough, right?

I haven't spent nearly enough time trying to track down the correct way to do this, but I would love to know what it is.

[AdamHeard]

Originally Posted by notmattlythgoe

I haven't spent nearly enough time trying to track down the correct way to do this, but I would love to know what it is.

Hopefully someone knows the answer to this.

If you're just running 4 Talon SRXs on the CANbus, nothing else and you're in a separate thread running your drive, what's the fastest you can run that loop and still get a fresh current measurement over CAN for each one?

Same question, but w/ PWM speed controllers and reading current over PDP?

[Thad House]

Originally Posted by AdamHeard

Hopefully someone knows the answer to this.

If you're just running 4 Talon SRXs on the CANbus, nothing else and you're in a separate thread running your drive, what's the fastest you can run that loop and still get a fresh current measurement over CAN for each one?

Same question, but w/ PWM speed controllers and reading current over PDP?

I know that the PDP only reads new currents every 25ms, or at least it was last season. Don't know if that changed. In addition, PWM updates at max every 5ms, so you couldn't go any faster then that even if you had a faster sensor.

The default status update period for Talons is 10ms. However I know that you can set it even faster. I bet you could do 5ms easily, and could probably push about every 2ms if you are careful with your CAN usage.

I would bet that is plenty fast enough, as your mechanical system probably won't react much quicker then that.

[pnitin]

Originally Posted by sastoller

My big takeaway from all this is that the SD540 is unnacceptable for use in FRC robots due to the brown-out issue. In addition, with it's high output resistance, it would no doubt, would get very, very warm in a stall condition. You can estimate the power that is turned into heat in the output devices of the SD540 to be nearly 50 Watts in the resistive load test 3, at 11.20 volts. With a CIM motor, the SD540 would be dissipating ~100 watts of energy as heat. I wonder how long it takes to melt (can someone test and post pictures please)?.

sastoller : I think you need to brush up your Knowledge of "Switch Mode Operation" You cannot calculate the resistance just like R= V/I, in today's switching technology used everywhere. If you apply your theory to your cell phone charger your charger should be dissipating ridiculously large amount (120V-5V) * 1amp = 115W (120V input, 5 V output and 1 amp current) but is is not doing that. All it means is that it is not 100% ON but around 95% ON.

[pnitin]

Originally Posted by Michael Corsetto

Cross The Road Electronics has posted a detailed report of some Motor Controller Output Power Testing they preformed with the four main FRC speed controllers on the market:

• Victor SP
• Talon SRX
• SPARK
• SD540

Link to .pdf document here

Please take note of the test results on page 7. I'm very concerned about the SD540's performance, particularly that the SD540 appears to brown out at 9.5V.

2016 will be the year of the brown out...

-Mike

Mike,

It is not brownout it is Seafty Feature, documents above says lockout due to Seafty feature,
I agree with this if you are going down to 8.2 V ( or even 10V ) you are seriously killing your battery.
Lead Acid battery do not like deep discharge, no matter what manufacturers say(deep discharge or what not), but they will not be same again if you discharge them down to 10.8V (1.8V per cell)