REV Sparks or Vex Victor 888?

Hello all, I’m a brand new FRC rookie, and I was wondering, what are the advantages/disadvantages of using the REV Spark instead of using the VEX Victor 888’s?

The Victors are a previous generation speed controller. We basically used them for over a decade with great success as the only legal speed controller (when they were the 883s & 884s). The Rev Spark is a new speed controller that is designed to be inexpensive while still giving some of the benefits of new technology like not needing a fan to actively cool it and allowing you to use limit switches directly with the speed controller to add feedback to your mechanisms. We have a few of the Sparks in house have tested them a bit, they seem to be working well so far.

You won’t be able to purchase any Victors, what teams already have and what are available in FIRST Choice will be the last of the 888s. The Sparks are available on Amazon and ship prime so you can get them quickly if you need a replacement.

Sparks! They are on Amazon and prime compatible which is awesome. Also I believe victor 888’s are discontinued. We are going to be using Sparks and Victor Sp’s this year.

REV Spark
-Passive cooling
-Reduced heat generation
-Mechanical limit switch inputs, so no need to program that stuff
-RGB status LED, which I hear is really nice
-Brake/coast mode
-PWM only
-Currently priced at $45.00
-Available on Amazon and Amazon Prime
-Haven’t been around long, so I can’t speak to long-term reliability just yet

Victor 888
-A staple motor control, performs every basic function you could want
-No passive cooling; you need to wire up fans otherwise the motor controllers can overheat
-Really finnicky trying to get all the wires in the right place
-PWM only
-Discontinued by VEX; you would be hard pressed to find a lot of these

Victor SP
-Passive cooling
-You don’t have to fiddle with screws trying to get crimps on the controller (this is a godsend)
-Sealed enclosure means aluminum shavings won’t cause you any problems
-Colored wires make it easy to identify which wires go to the PDP and which wires go to the motor itself
-PWM only
-Low profile
-Currently priced at $60.00

Talon SRX
-CAN integration is awesome, especially with the new control system
-Onboard closed-loop PID algorithms (if you don’t know that that means, look it up because it’s cool)
-Cables are really strong
-Passive cooling
-Sealed enclosure
-Color-coded wires
-Very reliable
-Low profile
-Brake/coast calibration
-Plug and play support for CTRE Magnetic Encoder Sensor makes using the PID algorithms even easier
-PWM available as well as CAN
-My personal recommendation!

As a rookie team, we loaded up on 4 Victor 888s through FIRST Choice. Along with the 2 Victor SPs in the rookie kit and the 3 available through the PDV, this was an essentially free way to get ourselves 9 motor controllers. We anticipate the Victor 888s no longer being legal in the future, so we will look to use those up on this year’s robot for sure.

With an emphasis on simplicity this first year, we will not attempt CAN and I highly doubt we would adopt a design calling for more than 9 motors. Victor 888s offered us the best value since we have certainty we will use them and we could get them for 50 credits. All of the other motor controllers in FIRST Choice cost 100 credits and are essentially of equal benefit to us this year since we will be using PWM.

Using CAN is no more difficult in software than using PWM. Wiring it is actually simpler, if you can plan the location of the speed controllers in advance. Using the advanced CAN-only features of a Talon SRX will of course add complexity, but you shouldn’t avoid CAN just because of things you don’t think you will be using.

Price is a good reason to stick with a PWM-only controller, though.


One thing that people are forgotten to mention is that the spark motor controller is more linear than the victor 888. That means as a PWM signal increases, the motor will increase at a more constant rate if you are using a spark motor controller.

I’ll bite and share my experience:

I’ve been a part of a team that has used CAN in 4 seasons. In 3 of those seasons the CAN out right failed at some point and we switched to PWM on at least some of the motors (granted those were all with Jaguars…I have my own opinions on those too).

In 2012, I personally spent over 70 hours during a week troubleshooting with a practice bot to get CAN working in preparation for the next tournament, only to have the CAN fail on the competition bot shooter motors at competition and ultimately switch to PWM.

In 2015, Team 20 used CAN with Talons relatively successfully. However, there were still quirks with the code which definitely burned lots of time during build season. I wasn’t personally coding, but I recall us taking over a week to iron out the code for switching between current setting and position setting modes of CAN motor controller operation. There was also one practice match where a motor inexplicably drove the opposite direction it should have throughout a match. We were unable to reproduce the issue and it never happened again, but it was very puzzling. Not sure of the cause. Taking advantage of any of the elegance or benefits of CAN does involve added complexity. And it comes with added risk; if one motor controller fails the whole robot is down (the poor durability of Jaguars exacerbated this issue, but Talons are far more durable, haven’t had one fail yet).

And having not used CAN in 2013 and 2014, we were able to get much improved robot performance which I believe is in part attributable to not fussing around with CAN. Every hour we spent other years trying to get CAN to work as intended was another hour we couldn’t spend practicing. PWM was set it and forget it…it always just worked. I have yet to be a part of CAN going as smoothly, and I have yet to see a robot do something on CAN that wow’ed me and made me say “darn, there’s no way a robot using PWM could achieve that same performance”. And that isn’t for lack of smart, dedicated people trying.

You are correct that if you just used the set voltage mode of motor controller operation, then CAN is no more complicated to code than PWM. But if that is your planned mode of operation, then why not save yourself $30 per motor controller, or get 9 (7 for vets) motor controllers for free?

Perhaps this is a knee-jerk reaction or I am holding a grudge over past experiences. My point is that for the team I am working with now, using CAN is not the low-hanging fruit for proper allocation of our resources (monetary, time, man-power). I am basing that assertion on my and my past team’s experience working with CAN.

Back to the topic of the thread, the real point of my post was to illustrate that you could get 4 Victor 888’s for free through FIRST Choice if you are not using the 200 credits (50 per) on something else. Or the SPARK can be purchased for $45 a piece if you would rather spend your FIRST Choice credits elsewhere. The SPARKS are slightly more linear, but this study shows the Victor 888’s aren’t all that far off from linearity:

I would not assume that. It has been ages since 884’s were provided in the kit, or a “relevant” product, but they have remained legal since teams have stockpiles of them. I would expect 888’s to remain the same way.

As Allen pointed out above, they are no longer being sold, so it probably doesn’t make a lot of sense to use them after this year, even if they are legal, since you won’t be able to get your hands on any additional ones.

Great post, issues we ran up against with CAN as well, long before the current generation of CAN bus hardware and firmware.

One point I’ll add though: the Talon SRX’s CAN bus wires are hardwired together, soldered together onto the same pad on the pcb. Unless you short them together or somehow burn through the conductor completely, a controller failure will not bring the entire bus down.

We’ve heard good things about the new implementation, and fully upgraded this year to Talon SRXs from Talon SRs. We’re excited to explore the possibilities, but of course ready to pull the plug and wire up PWM if needed.

I am not familiar with the previous years’ issues with CAN, but we had a Talon SRX in CAN mode on last year’s robot and it was easy to wire, easy to program, and worked fine. Granted, we used it in the simplest possible way, no PID, no sensors.

In theory wiring up a bunch of Talon SRX’s in CAN mode is dead easy. You need to assign them CAN bus IDs the first time around, but after that, addressing them in the code is also just as easy. And then when it’s time to do PID and limit switches, boom! Easy.

In theory.

I’m slightly nervous about the various horror stories I’ve heard, but our team will probably give CAN a serious attempt this year. We can always fall back to PWM.

I wouldn’t dismiss CAN outright in 2016. Many of the horror stories happened years ago, when the *rio CAN software stack was less mature, CAN speed controllers were less mature, termination resistors were not built into the control system, high quality FRC-oriented reference material was not available, and a trustworthy vendor like CTRE was not yet staking its reputation on a working CAN solution.

All those things have changed since 2012, and many teams ran CAN-only control systems successfully in 2015. As a result, this is the first season that CAN is a viable option for 254.

This speaks volumes.

We stayed away from CAN for a long time because of the reliability stories on CD. But last year we went all in with 9 Talon SRX controllers. They work as advertised, we were quite pleased.

In 2015, 3467 also went whole hog with the Talon SRX - we used one running the built-in Speed Control mode for each of our four mecanum wheels, and two (1 master, one slave) for driving our elevator with Positional PID. One of our mentors insisted that the built-in PID algorithm could be faster (he was looking more for a motion-control mode), but it all worked well enough with a minimum of muss or fuss.

Plus - One of the often overlooked advantages of CAN control is built-in current sensing on each motor - granted it wasn’t really that useful last year (unless maybe when we were building a twelve stack :wink: , but in a defense-heavy game, or a game where climbing might be required, being able to monitor current at the individual motor level might help to intelligently avoid those brown-out conditions that we were all worrying about around this time last year.

Can’t you do the same thing with one CAN run from the RoboRIO to the PDP? The CAN line would even have built-in termination at the PDP. No need for fancy CAN motor controllers if all you need is simple voltage control, and you can still have your current monitoring.

Yes - if all you care about is the overall current draw on the system, the built-in CAN in the Roborio and the PDP is all you need. I was simply pointing out that having intelligence about each current-drawing node might allow you to make intelligent, real-time decisions about which motor(s) to throttle back, depending on the game scenario.

The PDP allows you to monitor the current draw on each output(not just the total), so you can still achieve current control with PWM.

Actually with the new PDP you can get current draws for each power output. So as long as each motor controller is wired 1:1 with a power output on the PDP (which it should be according to 2015 rules), you can get the current draw from each motor.

See documentation here:

The Power Distribution Panel (PDP) is the latest DC power interface for competition robotics. The PDP uses CAN to connect directly to the roboRIO and allows for individual current monitoring on each channel.

EDIT: sniped