FRC Blog - 2019 Motor Controllers and MXP

Same encoder. We cannot use the integrate sensor because we won’t have CAN functionality until the 2019 Roborio image is released after kickoff. All of this is done over PWM.


Other brushless controllers I have used have allowed the user to specify motor timings in firmware. Generally the trade-off is between higher efficiency vs. more robustness against desync. Is this feature planned for the Spark MAX?

I think a low pass filter on the input is only a partial solution. Desync (which is what I assume is happening here) happens because of a mismatch between the anticipated and actual phases of the motor. Rapidly changing input commands are one way this can happen, but sudden loads on the motor (ex. slamming into a wall) could lead to the same phenomenon.


For reference, in the current firmware, if you drive a constant PWM command (to abuse terminology slightly here, a 2V command in this case), we see audible blips just from driving drivetrain NEOs with wheels in the error and no meaningful external disturbances.

I don’t have the tools to know whether desync is the issue here; the symptoms are at least superficially similar to what I’d expect in such a case, but since this is a sensored motor, unless there are sensor issues/noise triggering this, I’d expect a reasonable tolerance to external disturbances. Assuming the sensors are working properly, then in a brushless motor you should at least be able to keep it commutating reasonably. Without a good estimate of velocity and knowledge of the phase currents, you may have trouble getting rid of any torque ripple, but I wouldn’t expect that to be causing the issues we’ve seen.

SPARK MAX does have a “Commutation Advance” parameter that can adjust the timing relative to the hall sensors in the NEO. Beta MAXs use this parameter to adjust for a slight sensor misalignment in pre-production NEOs. This slight misalignment has been fixed in the production NEOs, therefore the production MAXs don’t have any commutation advance set by default. We don’t expect anyone needing to change this parameter at the moment, but it is already implemented.

James, we still haven’t been able to recreate the blip that you are seeing. With two motors coupled by a gearbox, we’ve tried both a standalone servo-PWM driver, like you did when you initially reported the blip, and then with the roboRIO PWM generator at a constant value (no control loop). When you say “2V command” do you mean you are setting the PWM output to a constant open-loop 0.17 (17% duty) or are you running a control loop to try and output 2V exactly?

We’re still testing some theories as to what could be causing the blip. One theory is that it could be related to the pre-production hardware that you have been using.

constant open-loop 17% duty cycle.

If it is due to the beta firmware, that’d be good to know; when I saw 1678’s issues, I assumed that they were seeing the same thing, but that’s not necessarily the case.

By the way: Since I haven’t mentioned it yet, it’s been great being able to test these motors before the full release and Rev has been good about responding to issues we’ve had. Thank you to all the folks.

In the video below we have the joystick mapped directly to the PMW output. No feedback control. We are demanding a lot from the system with the fast joystick movements, but I think it does a good job of showing the strange behavior when changing direction quickly.

1 Like

@PatrickW are you running on production or beta hardware/firmware? Given the post from @dyanoshak, I think it’s important to note that info to help people know if this is really a problem or not.

Production hardware/firmware.

There are two main issues that I’m aware of being mentioned in this thread:

  • Some jitter when you are running the motors “normally” (which is what @dyanoshak was replying to me about).
  • A delay when switching direction; I believe that should be a relatively simple fix on Rev’s part and will probably be fixed in the next firmware release (I could certainly be wrong, but I’m not as concerned about this issue).
1 Like

This should be fixed in the next firmware release. @PatrickW reach out to me at There are a few things I’d like to confirm and I may be able to instruct you on how to temporarily remedy the issue by changing an internal parameter.

Email sent. Thank you for the great support. We will have time this evening to work on this. As you have seen we have a pretty cool application that we would love to use NEOs for.


@PatrickW That is very neat. Where is the large bevel gear from, and can you show or tell more about your major steering bearing arrangement?

@sanddrag Thanks, to avoid getting this thread off topic I’ll answer your swerve module questions over in this other thread.

@dyanoshak Is there any timeline you can share on how CAN will be unveiled to the MAX? Will it be available as soon as the 2019 RIO image is available?

1 Like

Hey all, just wanted to follow up on a couple of notes for the public. The NEO/MAX project was a very involved one that was a good challenge for us at REV and helped us grow in many ways. We are overwhelmed by the amount of support the community has shown to us and we want to make sure that you all know that we stand behind what we have done. We will keep working to add features, squash bugs, and make the product better with time (just like other products from us and other in the past. If you have any issues, please reach out and we will do everything we can to fix it ASAP.

We believe that Brushless is the future for FRC and while it is a more complicated technology, it has the potential to let us push our sport even farther.

1 Like

@Greg_Needel It’s been 21 days since the last time data was promised - any progress or should we just take Richard’s unofficial numbers?


It just occurred to me that this behavior at least appears to be inconsistent with what 225 showed in their early beta tests. I’m definitely not an expert on brushless motors, nor do I know what 225’s testing methodology was, but is there some reason for this discrepancy?

Pardon my lack of knowledge on this specific subject but our 2nd year team purchased 4 Neo Motors and the associated Spark max controllers to use with the KoP chassis in place of full CIM motors. Based on what i have read thus far and our chassis build tomorrow I am understanding that we should NOT be using these as of yet and wait to see if the there is a firmware update that resolves the jitter issue. Am I on the right pace or in a totally different galaxy?

So we got our NEOs and MAXs, and I love them, however we do appear to have a MAx with some weird issues. Yesterday with no load it responded to the USB utility as expected, with the signal light changing with speed and direction. However when I soldering a connector on it today and plugged it in it basically always showed a cyan and yellow flashing pattern and didnt respond to motor commands from the same computer, the motor was tested on the same computer with another max with no issues. I tried reloading the firmware and other various things, but couldn’t get it to work.

Any ideas? @Greg_Needel @dyanoshak

Seems like most of the issues people had earlier in this thread were specific to problems with interfacing via PWM (my own testing using the USB utility showed no such issues). If you intend on using CAN, it’s possible you won’t experience any of these issues, and I think I recall seeing somewhere that Rev confirmed the issue would be fixed in the next firmware update anyways.

In any case, even if you do use it via PWM until the firmware update, while the problem did appear to cause some weird behavior when quickly changing directions, I doubt it would significantly impact early testing, and the issue is likely to be resolved long before competitions.