We recently dug into our 2 new Spark Flex controllers (post-recall), and we ran into a few problems.
Problem 1 (Flex does not run by REV Hardware Client)
We realized that the REV Hardware Client is unable to run a Spark Flex when directly plugged in via USB-C. The client sees the motor and appears to let you control it, but the motor does not respond. The LED shows a solid magenta as if it’s being commanded to 0. When plugged into a different REV device and controlling the same Flex over CAN, then it works as expected. This was tested while the full robot is powered and enabled.
Problem 2 ("random" sticky faults)
The Spark Flex was throwing sticky faults (EEPROM error, CAN RX, CAN TX, and “Other Error” (whatever that is)) seemingly randomly when the motor was run. These faults also came up when the motor was spun by hand. We tried to time it with constant velocity and nonconstant velocity by hand and by software, but these errors continued to seem to appear irregularly every 6-8 seconds or so. There did seem to be some sort of loose correlation between one sticky fault and triggering others to be thrown.
Problem 3 (over-current at low currents and only one motor)
We have two vortexes, each running a flywheel. We commanded each with their own onboard velocity PID to 5700 RPMonTrue and to 0 onFalse. Both motors would get to 5700 perfectly fine. One motor would go down to 0 perfectly fine. The other would spin freely and then eventually “kick in” and slowly go to zero. (This would only happen if the motor went over 2000-2500 RPM).
From the REV Hardware Client graphs, we found both motors took the same path, but the slow one was delayed for at least 1000ms. The slower motor appeared to coast until it was driven to zero. We did notice the delayed motor has the “HasReset” sticky fault tripped, so we believe the motor may have over-currented and reset. Also if we didn’t burn flash on startup, it would revert to the previous config.
We also tried this with RIO-based PID and received the same results.
We swapped the CAN IDs of the motors in the code and saw the same results on the same motors, which makes us believe it’s on the motor and not the code.
Problem 4 (motor output 40% of input????)
We used the onboard Spark Flex velocity PID, and the offboard Rio PID. We repeatedly commanded X RPM and repeatedly got ~40% RPM out. We ended up just doing a 2.5x multiplier, and it’s working, but we don’t understand why it’s needed. Any theories? This is a small problem but very confusing.
We understand that problems follow any first-year product. The purpose of this post is to inform and elicit help fixing these problems. Any guidance is very much appreciated.
Hopefully my answers below can get you up and running:
This is related to a safety feature that locks out USB control when the Flex (or MAX) sees a roboRIO on the CAN bus. The purpose is to ensure that the roboRIO has ultimate enable/disable control. The device won’t respond to setpoints over USB, but it will still respond to setpoints it receives over CAN. Rebooting the device will remove the lockout, as long as it doesn’t see a roboRIO again.
The EEPROM Fault and Other Error can result from a loose connection between the Vortex and the Flex. Please reseat them and make sure that the docking screws are fully installed.
We are also tracking a minor bug that could produce an EEPROM fault, and that should be fixed in an upcoming firmware update.
CAN RX and TX faults do happen from time to time, and shouldn’t be an issue if they are infrequent. Double check that your CAN wiring has good connections and is properly terminated just to be sure.
Please reach out to us at [email protected] for this one. We’d like to get more information to help pinpoint the issue.
This sounds like it may be related to PID tuning. There are many PID tuning resources here on CD, but if you get stuck, please reach out to us at [email protected].
I’m familiar with the lockout feature, but this behavior still seemed weird. I understand that RHC control over USB is performed via a CAN bridge and the controller received commands as CAN frames just like if the rio were the one sending it, correct?
Assuming this is the case, what we’re seeing is that the RHC will fail to control the device connected via USB, but succeed in controlling other devices on CAN. This only works if the driverstation is connected and enabled (and i presume code isn’t commanding conflicting setpoints).
We had a similar issue on one motor after we received our replacement Spark Flex controllers. We solved it by disassembling the Flex/Vortex, re-seating everything and verifying (as much as we could) a secure connection between the two devices. We then reflashed the firmware and the issue has not returned.
Be sure you do not have the one strangely behaving motor in brake mode. With a motor controller from another vendor a couple of years ago, I saw a very strange bug that went away by doing a factory reset of settings and then reapplying any settings with non-default values. Since then, I normally do a factory reset any time I do a firmware upgrade, just in case. It can’t hurt to try this and there’s a slight chance it may help. If nothing else, it eliminates a possible source of error.