Our team used Spark motor controllers last year for everything and they worked fine. I would like to know why most good teams use Talons instead.
TalonSRX motor controllers just have more features built in to them. Voltage compensation, current limiting, closed-loop position/velocity control, and more. SPARKs are significantly cheaper because they lack these features. Not that they have disadvantages necessarily, just not as many advantages.
2 Likes
Talon SRXs are “smart controllers”. They connect the the roboRIO via CAN, and can do much more advanced things like internal closed-loop control, voltage ramping, output voltage control, current limiting, sensor monitoring, etc. Whereas a Spark is a standard motor controller, meaning it just controls the % of battery voltage given to the motor.
They’re both great motor controllers for what they do. But if you have the money and want the extra features, the Talon SRX does everything the Spark does and more.
1 Like
Just butting in to highlight this part; it’s the Talon SRX that has these nice features. Cross The Road Electronics also made the original Talon and Talon SR through the 2014 season, which are much like the modern-day SPARK (sealed up well, screw terminals, undercut the incumbent options for motor controllers). Being a team in the 7000s, you may not see them…but you might and nobody likes to feel confused. 
1293 still uses many Talon SRs and SPARKs it’s amassed over the years, but we are using a couple Talon SRXs this year on the arm where the internal controls have a clear benefit. I’m looking forward to seeing the results.
If you are running PWM, the Spark controller has the price advantage and no technical down sides. The Talons are almost twice as much. If you are not using the advance features of the Talon you are pretty much wasting your money. The new Victors can run Canbus so if that is the only reason you are using a Talon, the new Victor is a good alternative.
Fixed that for you.
I differ from literally every other Pandamaniac in that I’ve worked with other teams. It’s very easy for a team to say “this is how we build robots, we’re good” and stick their collective head in the sand–especially when a team is short on mentors and the mentors they do have can only focus on so much. That creates a chicken-or-egg problem where our programmers (long a weak spot for lack of a dedicated mentor) can’t implement a lot of examples and documentation for lack of hardware. In the case of an arm encoder, that literally means taking the long way around with the roboRIO–soldering or crimping connectors, running wires down to the electrical board, and figuring out a mechanical interface for it all. That means for a ton of teams (mine included) it probably won’t happen at all.
It took cajoling our spending-cautious leadership a bit, but we bought two Talon SRXs in December as a show of faith. Our arm encoder is the VersaPlanetary encoder guts stuck in 5406’s 3D-printed housing to work with our 57 Sport, connected with one simple ribbon cable to our SRX. (Were we a VersaPlanetary shop, it would be even simpler mechanically.) We won’t be tossing our SPARKs quickly (hello, 6-Mini-CIM drivetrain), but I believe it’s important to give your team something they can sink their teeth into.
Thanks, we are going to use all Sparks as we don’t need those advanced functions. We do have 2 Talons if we need them.
There is one disadvantage to the Spark that I feel is significant that means I won’t put them on the robot. That is the fact that the brake mode is only active if the controller is receiving a neutral signal. That means if you E-stop/disable the robot it will be in coast mode. Note that is for the original versions of the Spark, it is possible they did fix that problem in the later versions but since the originals were that way I have not bought any.
Since you mention the spark motors, I’m curious how people have felt about the spark max motor controllers? Are they comparable better or worst than the Talon SRX?
That could be a bug or a feature. On the drive train it makes it easier to push the robot when it is disabled. On a arm or climber you want the braking action when disabled.
Sometimes you want brake mode when disabled on the drive train, too! Remember parking on the BATTER in STRONGHOLD?
You are correct that it will push easier when disabled the way the Spark is programed. The problem is when I’m E-stopping a robot I want it and all of its components to come to a stop ASAP. It was billed as a safety feature when this was brought up around the time they were introduced. Personally I think defaulting to brake mode upon loss of control signal would be a safety feature, while I consider defaulting to coast to be a safety concern.
I’m not sure if this is a coincidence or not, but one thing I have noticed with Sparks is whenever I’ve seen of a failure with them at an event (with alliance partners or friends), it always appears they are in brake mode I believe, and a lot of the time on the drivetrain. I’m not sure if it has something to do with the high load going through the controller or just a pure coincidence.
We use them a lot on things that don’t matter a ton for speed or positioning control, such as intakes and climbers.