Rev Spark MAX overflowing?

#1

We’ve noticed some odd behavior on our Spark MAXs while testing our practice bot drivetrain. “Our” (see 254 2018 code) trajectory follower loop is run every 10 ms by a Notifier. When running at this loop rate, the motors seem to “jitter” (quite violently). We have them in brake mode, so it appears that what’s actually happening is they’re stopping, getting a new command, and starting. This, of course, throws off the trajectory follower and is not pleasant to watch or hear.

Note that there is no feedback control on the Sparks themselves, the command is being applied entirely through the “arbitrary feedforward” slot in the setReference method. We are using Java (Kotlin) and our Notifier dt varies by at most 0.1 ms every cycle (no blips observed during jittering). Increasing the Notifier dt to 20 ms entirely solves the issue, but we’d like to run our loops faster. All motor controllers show no brushless encoder errors, and CAN usage is < 100%.

Edit: Should also mention we’re on latest firmware (1.1.31) and latest API (1.1.9)

Edit 2: The source of feedback data for the trajectory follower is two CTRE mag encoders connected to talons elsewhere on the CAN network. The data from these sensors is updated at the correct rate and shows no signs of error.

My question is this: is there a setting on the Spark MAX that can be changed to “speed up” its ability to receive frames over CAN, or is this a bug in the firmware?

1 Like
#2

Sounds weirdly similar to the issues teams were having a few months back with the first few firmware versions.

Not sure if this would screw up your closed loop, but perhaps try setting the acceleration ramp on the Sparks to see if that eliminates the “thrashing”? That might at least tell you if the problem is with the motor controllers themselves or somewhere in the code. Creating some sort of real-time visual output (like a display on the dashboard or something) of the power commands sent to the motor controllers might also be helpful for troubleshooting this.

If the Sparks are anything like the Talons, it’s unlikely that their CAN polling rate is the issue (and, as far as I know, it cannot be changed anyways).

#3

We did try this, but it just masked the issues. It was obvious that the controllers were still commanding 0, and the ramp rate was just smoothing it slightly. Increasing the ramp rate any more than the 0.1 that we set would mess up our controller.

We did this as well. It was true that the output from the controller (model based) was “thrashing around”, but this happened in response to the NEOs stopping. Since the brushless motors can stop so quickly in brake mode, the controller drastically adjusted its feedforward command to compensate. When we ran the loop at 20 ms, the curve generated by the model was very smooth. However, since our loop timings did not vary, the controller was definitely running at the correct rate, and even if it did “miss a beat” I would not expect the motor controllers to stop fully.

We ran the same trajectory follower on a 775pro drivetrain with a 10 ms dt with none of these issues, which is why we believe the Sparks are at fault.

2 Likes
#4

Can you provide some data from the run at 10ms? Specifically the input to the arbFF and any outputs you record?

There is no technical limitation in the firmware to how fast you can send updates to the controller other than CAN utilization. On the API side as of v1.1.9, you can change the rate that control frames are set by calling setControlFramePeriodMs(), the default is 10ms.

#5

We did some additional testing yesterday, and it looks like it might not be the Sparks after all.

The test we ran involved sending a new command to the Sparks every 10 ms through the same notifier, but instead of using our trajectory follower, we used the joysticks with a random “jitter” added to each stick to ensure that a different setpoint was sent each time, and to avoid the joysticks only updating every 20 ms. There was no deadband or ramp rate, and we observed no jittering behavior.

The test was run using the arbFF slot and multiplying the end joystick values by 12.0 to convert it to a voltage commands.

This (unfortunately for us) suggests that there is a problem on our end, perhaps with a timing issue with reading the sensor values from the Talons and getting stale data. We definitely have more testing to do.

Thanks for the prompt support, and sorry for being too quick to blame the Sparks. We’re really glad we picked these motors for our drive this year!

1 Like