Brushed/Brushless Mixup (alternative title: Cooking Sparks)


Today a few mistakes were made.

Here is some context for said mistakes:

We, the programming team, were given the robot for some quality testing time. The first part of that was spent setting up brushless Neos with Spark Max controllers, flashing firmware and all of that jazz. Afterwards, we tested driving capabilities with reliable code and the drivetrain was entirely functional.

However, this is where the trouble begins; we were hoping to characterize the drivetrain using the frc-characterization tool. We were (or more accurately, I was) unsure about how to configure the the tool with Spark Max encoders, but thankfully ScreenSteps has an easy-to-follow guide, or so I thought. Justifying the mistake is pointless, but I’ll do so anyway. The project types listed in the guide are Simple, Talon and then SparkMax, except SparkMax has two different types, indicated by parenthetical clauses: (Brushed) and (Brushless/Neo), so when I saw SparkMax in the tool’s drop down menu I brainlessly selected that.

Everything appeared to be going fine, generated and deployed the project without even considering our motor’s brushes or lack thereof. Prepared the robot for Quasistatic Forward test, but when the robot was enabled it took longer than expected to get going, in fact it just didn’t. Only prior experience characterizing was with a test robot, and it had also taken a while to get started so we gave the poor bot the benefit of the doubt (it even made the same clicking sound, unsure if that’s a separate issue). That benefit was rescinded when the driver station reported that the battery was down to 7V from 12V and the robot had still failed to start moving.

We investigated the status of the robot and found that the motor wires (specifically the red, white, black set) were warm to touch. First, we thought maybe there was a problem with the ports and that delayed discovering the issue. After some additional tests, each of which probably brought our poor motor controllers closer to eternal damnation. At some point we returned to the code that had worked earlier, and found that it no longer functioned.

Using the SparkMax Client that had previously been able to control the motors just fine yielded no results either. The motors were not receiving any voltage (verified with multimeter) but the LEDs were still indicating. Having attempted some additional diagnostics, everything other than the whole actually-controlling-the-motor-by-directing-voltage-to-it thing the controllers were entirely functional. We tried:

  1. CAN addressing and manipulating the motors from the Client. Addressing was fine, manipulation was not.
  2. Disconnecting the motor and measuring DC voltage from the controller, in every possible permutation, all values were negligible.
  3. Driving through CAN and RoboRIO, also unfortunate.
  4. Using a fresh Neo with a dead (?) controller, which did not work.

As a result, I have a few questions:

  1. Are the motors likely to be alright?
  2. Is there anything that can be done about the controllers? Mostly a novelty at this point, but what exactly happened to the controllers?
  3. Any additional tests that would be worth running?
  4. Would it be possible to return the Sparks? The maximum electrical specifications in the User’s Manual were not exceeded, the battery inherently limited us to 12V and fuses would have been blown if there were more than 40 amps of current.

My two guesses as to what might have happened are these:

  1. Is there a chance that the Sparks were configured to drive brushed motors? It’s highly unlikely that they were since you said the robot drove at one point, but nonetheless there’s a slight chance they maybe got factory reset somehow. I don’t know what the factory default is, I would assume brushless mode but I could be wrong.
  2. Again, since you mentioned it was driving before it’s unlikely, but if the encoders got unplugged somehow it could cause issues. I’m not sure what either of these look like for sure so there’s a very good chance it’s neither of these, but I know doing either of these is very bad for brushless motors.

As for if the controllers are fixable, I would first check you are able to exchange them. If you are able to, great. If not, I would open them up. If you’re sure they don’t drive a NEO there’s no harm in opening them up (other than that they would no longer be legal for a competition robot, I’m pretty confident in saying this, but there’s a small chance I misinterpreted something). Check if anything obvious melted. If the wires were warm to the touch you may have melted the connection and you may be able to fix that.

If you deem that they are completely dead, and you’re going to throw them out, feel free to ship them to me; I’d love to take a look at them to see if they’re at all fixable. I’d pay shipping of course :slight_smile:

Good luck, that certainly doesn’t sound like a fun day.

Please reach out to [email protected] and share additional information (code you were running, photos of your wiring set up, any specifics you have on the blink codes running on the SPARK MAXs, firmware version, api version, etc).

We can work through troubleshooting over email

Thanks for reaching out to our support email. We’ll continue helping to get you up and running over email, but I also wanted to post here so the thread has a resolution.

Based on your description of events it sounds like the NEOs were driven by MAXs that were configured in Brushed mode by the FRC Characterization tool.

Unfortunately for the NEO this is very similar to a complete stall condition. The clicking sound you heard was likely the circuit breakers on the PDP tripping and resetting, which is consistent with a large amount of current going through the MAX and the NEO for an extended period of time.

While the 40A breakers will trip above 40A, they are not instantaneous and will allow much higher current to pass through until they heat up enough to trip.

For the community, please be careful when configuring your SPARK MAX. We intentionally have the SPARK MAX default to Brushless Mode to reduce the chance of damaging a NEO by running it as a brushed motor. We also design our APIs and PC Client to be clear when configuring the motor type.

REV did not develop the FRC Characterization tool, and unfortunately the configuration options were not clear. We have reached out to the developers and asked them to change how the SPARK MAX is listed in the configuration options.

1 Like

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.