Spark MAX Thoughts?

My team, like I assume many teams, is excited about brushless motors in FRC. We held off this year, since the Neo/Max was the only legal combination of motors and motor controllers, and out team has used Talon SRX and Victor SPX motor controllers for the last couple of years. Since this year (at least for Houston Champs teams) has basically come to a close, I am wondering what the experience of teams that used the Neo/Max combo has been. Specifically:

  • Has the MAX software remained stable and consistent throughout Build Season and into Comp Season (have there been no significant changes)?
  • How does Smart Motion compare to Motion Magic?
  • Does the USB C connection provide any significant benefit?
  • What is the Rev equivalent of Phoenix Tuner like?
  • Is it better if the MAXes are closer to the motors or in a centralized location?
  • Is there an absolute/relative combo encoder like the SRX mag encoder for the Max?
  • Is it worth investing in the REV brushless motors and controllers or should we wait for a similar offering from VEX and CTRE?
  • Is it worth trying to explore a brushless path, or should we stay with our 775/CIM and SRX/SPX setup?
  • Is the Java library for the Max adequate for robot code development in its current state?
  • Is there anything else that you have experienced that other teams should know about?

I am a software person, so I am approaching this from a software angle, but any mechanical or electrical advice would also be appreciated. Thank you so much for your help!

1 Like

Our team has had mixed experiences with them. On the earlier firmware, they lost their firmware and configuration. They have since fixed the bugs. We used to use 2 cims and 1 mini-cims on our gearbox, but 2 Neos gives you way more power. The only issue, is you need to watch the built in encoders. They must be plugged in, and the motor will stop if not. Until they release their new encoder, you will need to wire the encoder to the rio via pen if you want actual position. All in all, they are worth it.

  • REV’s software has gotten constant updates thoughout the season to address most of the issues that they’ve had, towards the end of the season I was very pleased with them.
  • Haven’t used Smart Motion yet.
  • The USB C is handy for using a PC to drive them without a roboRIO handy.
  • The REV utility is frankly underwhelming as-is, and lacks a lot of the “live tuning” Phoenix Tuner has.
  • Spark Maxes by virtue of sensor cable and a third phase encourages putting them closer if for nothing other than reduced sensor noise and less weight in wires.
  • I’d feel comfortable investing in REV’s product given that we have no official indication of a CTRE / VEX offering as of the time of me posting this.
  • Yes, it’s absolutely worth pursuing a brushless path if / when there’s some competition in the FRC-space for brushless products. The significant power advantage and weight reduction is SO worth it.
  • The Java library is pretty effective so as long as you read the docs. A little sparse at times, but perfectly functional.

The biggest annoyance to me is having to update the Spark Maxes one at a time over USB, and not being able to use an external quadrature encoder in conjunction with NEOs in brushless mode, but REV has a Trello card describing improvements to allow the second.

All in all, not as happy with this season but very glad we bit the bullet on the investment for 2020 now that the ecosystem is significantly more mature than when we began.


They melted on us when we used them. In my opinion I like the Talon Motor Controllers.

Did the motor or the controller melt? Also, did it seem to be an issue with the controller itself or with how the team used the controller? Melting controllers or motors due to the design of the controller/motor would be a huge issue for us and many other teams

We used one to control our arm. Overall - I loved them. I want to use them on the drivetrain next year.

Software has changed quite a bit, in non-backward compatible ways. We are stuck on a beta as a result. This is expected for a first-year thing, and REV even addressed that their rollout wasn’t as smooth as was planned. I expect next year to be much more stable though. It was no worse than the pain I ran into in 2016 when I first tried to use SRX’s, so I give them a pass.

I’ve never used the SRX magic motion features, so I don’t have much to compare too. However, the trapezoidal motion profiling worked extremely well. A bit of tuning was required as expected, but the arm motion was exceedingly smooth.

I like USB C overall, neutral on the choice to use here. The only thing we used it for was updating firmware - all other configuration was done from within our Java code. I’d love to see all FRC stuff standardize on USB-C, but overall I think it was a not-half-bad choice.

REV doesn’t have anything exactly analogous to Phoenix Tuner. We had issues left and right getting tuner to connect through the RIO, so I guess that means I like the REV firmware and editor better. It’s not apples-to-apples though.

Unsure if distance matters. I would expect the CAN wires would be more tolerant of lengthening than the sensor wires or the 3 wires for the motor windings. Never tried though, and likely never will.

The NEO motors have a built in encoder. Some folks reported issues with it, but we found it to be excellent. Never failed us doing closed loop control. Note that since you’re measuring at the motor (not the actuator), you have to account for gear ratios differently, and chain slack and mechanism slippage may induce different-looking errors than if you were measuring the actuator.

Personally, I’d invest. Maybe something better will come along in future years, but what is there now is really good and already proven. Even if something better comes out, you’d probably not want to go all gung-ho on unproven technology the first year.

Brushless FTW. It really will be the future of this competition.

Libraries are more than adequate in my opinion, though it sounds like REV still has more improvements in the works.


The Spark Max controllers don’t have mounting holes, which is kind of a bummer. How exactly the current limiting works is still a little confusing, to figure out how to get the maximum performance out of it without jeopardizing anything. We had one Spark Max (or 8) develop a hardware issue that is causing it to not read the Neo encoder properly. Other than that, they’ve been okay.

I’m considering ordering a bunch for 2020, but I’m worried that Vex/CTRE will come out with something better.

Then again I should have mentioned that they were mounted back to back so that created more heat. I think it had to do with the way we mounted them. I can’t say for sure what it was. As long as you don’t mount 2 back to back you should be fine but then again I am not entirely sure why ours melted.


We had one Neo on our robot (to control our arm). The built in feature that allowed a spark max to follow a Talon SRX was very buggy and unstable for us. So we developed a custom solution for it to follow a talon srx. We don’t like the software features in Spark Maxes specifically due to the low encoder resolution of the Neos that makes the software useless. We liked the mag encoders (4096 ticks) a lot. We are hoping CTRE bring support to brushless motors soon.

1 Like

We’ve found the neos are awesome. Don’t really care about motion magic/smart magic, we don’t use it. The Maxs are fine, but the software library I’m rather unhappy with, as it killed our ability to unit test our robot code (no such problems with ctre libraries).

One of our team alumni’s who was a CSA at an event said that he would recommend you use them next year and not this year as he had problems with teams using them. They are very buggy right now.

Can you further explain what you mean?

If memory serves, there was a static constructor somewhere that spawned a thread that bombed out, possibly due to link errors, and I could find no way to mock it out

ah, here it is:

1 Like

I believe there isn’t currently an x86/amd64 build of the REV libraries, meaning that unit testing will be broken until they (or someone else) can provide that.

I don’t think theres a x86 build for the ctre libraries, either.

@bobbysq It seems like from his description mylodon’s team writes custom mocking infrastructure around the CTRE libraries that allows them to unit test on x86. Something similar should work for REV, but it seems like they have some sort of static call.

@mylodon I’m confused what you mean when you say that you can’t mock it out. With enough work shouldn’t you be able to completely isolate the Spark code from the rest of your code (say with an adapter) and compile unit tests with no references to the REV libraries. That is a lot of annoying work though.

@Steven.Carlson Saying something like “they melted” deserves more explanation. What exactly melted? How were you using them? Did you contact REV about them melting, because I’m sure they’d like to know.

Based on the JSON files for the libraries, it seems that the CTRE libraries have those builds available. Maybe I’m misunderstanding how WPILib does unit tests, though. - No entries for x86_64 - Everything has a Windows and Linux x86_64 version available

Will the CTRE Cyclone become a reality soon? If not, spark max it is.

@Steven.Carlson: Also please clarify the pronoun “they”. Does it refer to the NEO, or the MAX, or both ?


1 Like

@Vyo was a new CTRE product announced or alluded to somewhere?