FRC Blog - 2019 Motor Controllers and MXP

971 has observed the same issues, and while we haven’t tested in a shooter wheel, I would not run it there based on our observations so far. The jitter might be infrequent enough with a single motor driving a shooter wheel not to be an issue, but we saw a significant worsening when we ran two motors in parallel (as you would in a drivetrain). It manifests itself as a brief, random deceleration (even when running at constant input PWM command), which I doubt would play nice with a shooter wheel where you want nice, consistent behavior. Particularly if it turns out the jitter is, e.g., correlated with rapid decelerations (as you might get while a shooter wheel is trying to impart momentum to a ball).

I’d consider it for intake rollers or other applications where precision isn’t as important. If we get a firmware update addressing these issues, then I’d be more inclined to use them.

We retuned the model for a state-space controller using stall characteristics provided by 3620, and free characteristics provided by REV.

i.e., a stall torque of 2.51 N*m, stall current of 100A, free speed of 5760RPM, and free current of 2A.

We used the same controller gains as with the miniCIMs, which should have been fine as long as the model was accurate.

Hey everyone,

I just wanted take a moment to thank both 1678 and 971 and all our other beta testers for SPARK MAX and NEO. They’ve been instrumental in helping us test this new technology for FRC. As we continue to work closely with these teams, I wanted to help explain a major difference between brushed and brushless motors that we believe is contributing to the jitter that some have been experiencing in their autonomous control loops.

A brushed DC motor is inherently a low-pass filter which filters out higher frequencies in the input signal. A brushless motor is more tied to absolute position because of the active commutation of this motor type. Control loops designed and tuned for brushed motor control have more tolerance for jitter, whereas the jitter in a brushless motor will be passed more directly into the mechanical system. A simple way to try and mitigate this issue is to filter the control value into the mechanical system (the PWM values) with a corner frequency at a value corresponding to where the jitter is seen.

We’re working on a white paper to help explain these differences in more detail, but essentially the mechanical systems are different and you need to adjust your control loops accordingly.


Out of curiosity, was the same encoder used in both the MiniCIM and NEO configurations or was the integrated sensor used in the case of the NEO?

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?