Which speed controllers?

Although it may come down to what’s available these days, what are the main differences between the various speed control options and what’s recommended?

Thanks for the insight!


For 2021, the list was as follows:

A. Motor Controllers
i. DMC 60/DMC 60c Motor Controller (P/N: 410-334-1, 410-334-2)
ii. Jaguar Motor Controller (P/N: MDL-BDC, MDL-BDC24, and 217-3367) connected to PWM only
iii. Nidec Dynamo BLDC Motor with Controller to control integral actuator only (P/N 840205-000, am-3740)
iv. SD540 Motor Controller (P/N: SD540x1, SD540x2, SD540x4, SD540Bx1, SD540Bx2, SD540Bx4, SD540C)
v. Spark Motor Controller (P/N: REV-11-1200)
vi. Spark MAX Motor Controller (P/N: REV-11-2158)
vii. Talon FX Motor Controller (P/N: 217-6515, 19-708850, am-6515, am-6515_Short) for controlling integral Falcon 500 only
viii. Talon Motor Controller (P/N: CTRE_Talon, CTRE_Talon_SR, and am-2195)
ix. Talon SRX Motor Controller (P/N: 217-8080, am-2854, 14-838288)
x. Venom Motor with Controller (P/N: BDC-10001) for controlling integral motor only
xi. Victor 884 Motor Controller (P/N: VICTOR-884-12/12)
xii. Victor 888 Motor Controller (P/N: 217-2769)
xiii. Victor SP Motor Controller (P/N: 217-9090, am-2855, 14-868380)
xiv. Victor SPX Motor Controller (P/N: 217-9191, 17-868388, am-3748)

The first criteria is the motor you will use, with brushed/brushless being a major differentiator. Some motors are only legal / only work with some controllers.

The next criteria is probably smart vs. not-smart control, which is tied to CAN/PWM.

It’s hard to make a general recommendation, but some of the controllers on the list are more widely used, and there are reasons for this, including cost and availability.

I’ll go over the main ones that most teams I know use.

So let’s start with Brushless:
The falcon 500 motor is the most powerful motor available in FRC. It comes with an integrated controller. Does a great job. Has a lot of libraries. You won’t go wrong. Built in PID functionality. CAN and PWM based I believe.

Spark Max: Controls the Neo, Neo 550, and brushed motors. Neo is the second most powerful motor (close to the falcon). The neo 550 is an extremely light motor, with a lot of power. Has functionality over USB, which is nice for beginners. Has some funky jst connectors to hold critical things in place. You have to be careful wiring these, so nothing disconnects unexpected. But overall, still a solid choice. Built in PID functionality. CAN and PWM based.

Now Brushed:
Talon SRX: Very capable controller. Works on CAN or PWM. Has an encoder input and can do onboard PID similar to the other controllers. Probably the most capable controller limited to brushed motors only.

Victor SPX: capable CAN based controller. Missing a lot of bells and whistles from the Talons (like encoder inputs) but comes at a lower price/ lighter package.

Spark Motor controller:
A PWM based controller that will work for some teams. Some basic limit switch functionality. Also comes at a competitive price.

So on 4272, we only use Talon SRX, or Spark Max controllers on the robot. We are heavily invested in those ecosystems. The Spark Max controllers give is the ability to run Neos and Neo 550s (which we use on the majority of mechanisms) and Talons can run any brushed motors with ease.

You won’t go wrong with Falcons for sure. I know a lot of teams love them. You also won’t go wrong if you run a combination of Talons SRX and Victors SPX depending on the need for an encoder.

So those are my opinions. There are of course other legal controllers, but I don’t personally think they offer benefits to all that many teams in most circumstances.


Two other considerations are price (but this may not be one), and for the Rev Brushless system (Neo, Neo550), you need to factor in the cable run. The control cable has the afore mentioned connectors which need to run between the motor and the controller. We use these motors a lot, but if your team cannot make custom cables with the JST connectors (they are not easy to make), long runs are cumbersome.

Rev sells pre-made jumper cables and connectors to make the run a little easier, but it is still cumbersome.

Also, as I write this edit, I realize that you could theoretically cut one of those cables in half and put molex connectors on either end to make a much easier long run. The cable on the factual motor may be too fine and too short to put molex xonnectors on though so you would still need the boards.


This is a nuanced question, and the advice given so far is generally good.

I’m going to come at it from another angle: the important question is not “what motor controllers should we use.” Rather, the relevant question is “what is our controls strategy?”

The choice of motor controllers (and sensors, and configuration of the two) should follow naturally from the answer to this question.

This depends rather heavily on what your team is capable of doing (and plans to do) in code. What control algorithms are you using? Open-loop? PID? State-space?

It also depends to some degree on the mechanical requirements of your design. As others have noted, brushless motors require brushless motor controllers, and brushless motors easily outperform brushed motors. Whether the performance difference really matters, however, depends a lot on what you’re doing. It’s entirely possible to build an effective robot on the cheap with nothing but brushed motors and bottom-shelf PWM controllers.

One often-advertised feature of the pricier motor controllers is the support for control algorithms that run on the motor controller itself. I will continue to push the line that these features are more trouble than they are worth for the vast majority of teams, and that you will probably see comparable-or-better performance for less development pain by sticking to the control algorithms that come included with WPILib (and plugging your encoders into the RIO instead of into the motor controllers).

On the other hand, the current limiting functionality offered by the higher-end motor controllers is fabulous and can save you money and matches by preventing breaker trips, motor burn-outs, and control system brownouts. For this reason alone I do advise using the pricier controllers on smaller motors that are more likely to burn out when stalled, and for drive motors (which can brown out the entire control system, if your robot is heavy enough that you can’t slip your drive wheels when pushing against a wall).

CAN vs PWM is unlikely to matter much unless you are doing something that is extremely timing-sensitive (I suspect this is not the case for your team, given that you are asking this question). The pricier motor controllers will want CAN connections; the cheaper ones will want PWM. Neither should pose a problem for your situation.


I will add that in any case where you have 2 or more motors ganged together, you can get all the functionality of a Talon SRX with having only one motor on a Talon SRX and the remaining motors on VIctor SPXs in follower mode. This can save you some money, especially if you picked up the Victors in FIRST Choice or from another team that has upgraded.


I’ll disagree a bit here, from an educational perspective. Using the controls on the motor controllers helps reinforce the concepts of code modularity, and hiding implementation details. In off-season especially, it also provides an opportunity to show how to verify that the “black box” is doing what it should be. Modularity [like all teamwork] is based on trust, and trust is achieved through experience and verification.


How does it do this? The libraries for these controllers are notorious for leaking implementation details in unexpected places.

There’s nothing fundamentally more “modular” about running your control algorithm on a peripheral device - not on the code level, at least.

I’ll agree to disagree on this. I find trusting a nearly black box piece of hardware to be fundamentally more modular (and difficult) than trusting a piece of open source software.

The “black box piece of hardware” still has an associated chunk of software running on the RIO, to allow you to interface with it. The software for the message-passing alone is more complex than WPILib’s PID controller.

While true from a no-circuit-breakers world, it lacks some nuance in the FRC application. If you compare the 40A constant current tests between the Falcon and the NEO, you’ll see the power curves are darn close to identical. Both are eminently capable of turning current into power in a ruthlessly efficient manner.

To my eyes, there are four motor controllers worthy of consideration in 2022*:

  1. Talon FX if you want the Falcon 500.
  2. SPARK MAX if you want the NEO, the underrated NEO 550 (which then lets you use the tiny and cheap UltraPlanetary for many low-load applications), or want to make that move in the future.
  3. Victor SPX or SPARK because you’re being a cheapskate and want brushed motors spinning without too much thought. Victor SPX has CAN and integrated leads and is smaller, SPARK has the inbuilt limit switch ports and can run higher voltages in non-FRC applications. No wrong answers, just pick what you want (or more likely for 2022, what you can actually find in stock).
    a. The long-dead Talon SR and Victor SP are also in this category, if some team just dumps a pile of them on your work table.
    b. There is not a single thing wrong with being a cheapskate, as long as you’re honest about the trade-off. We ran SPARKs on our climber in 2020 and 2021, SPXs and a Victor SP on various conveyors in 2020, and our whole drivetrain in 2019 was Talon SRs. We just didn’t need the sophistication, and we had the parts handy.

*Yes, I’ll say this now without even knowing any new-for-2022 items. If a team has to ask this question on ChiefDelphi, they probably should not be relying on any new motor controllers to improve their strategy. Even in normal times, new parts tend to have supply constraints, rare early quality issues, or new tribal knowledge to understand. For a lot of teams, the best move is to let those go-getter teams do your R&D work for you and learn from their experiences for its second year on the market.


I like this.

I think “modular code” may not be the best word choice for the idea, and that’s what @Oblarg is hung up on.

The idea is motor controller taking encoder inputs is pretty popular for traction/pump controllers that I work with professionally. It’s nice to be able to rely on the inverter manufacturer to do the heavy lifting on controlling the motor, and the machine code just worry about the speed of the motor. This is the “black-box” idea. It’s also nice to simplify wiring, since you don’t have to run your encoder lines as far.

Now in FRC, you could get away with either. Our team has always ran the encoder to the motor controller to avoid long wire runs. We use the built in PID algorithms, and have had good luck with that. Our students have always seemed to be able to figure that out, but maybe it’s trickier than I realize. In 99% of senarios, you could achieve the same outcome with using the Rio to run the control loops.


… pretty handy for all your cardboard robot needs …


We’ve been using SPARKs exclusively on all our robots - aluminum and otherwise - since 2018 with no complaints and no ragrets.

Whatever you decide to use… remember spares! The fewer types you have the fewer types of spares you’ll need. I hate spending money on stuff that isn’t used, but I hate the look of a student without a functioning robot more!

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.