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:
- CAN addressing and manipulating the motors from the Client. Addressing was fine, manipulation was not.
- Disconnecting the motor and measuring DC voltage from the controller, in every possible permutation, all values were negligible.
- Driving through CAN and RoboRIO, also unfortunate.
- Using a fresh Neo with a dead (?) controller, which did not work.
As a result, I have a few questions:
- Are the motors likely to be alright?
- Is there anything that can be done about the controllers? Mostly a novelty at this point, but what exactly happened to the controllers?
- Any additional tests that would be worth running?
- 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.