Hi my name is Julia and I am a member of FRC team 219 and we’re testing our robot and having communication issues with our Spark Maxs’ on the drivetrain. They oscillate from blue to green (they are on break mode which is why they are blue). We have other Sparks Max’s on the robot but they all work fine. Only the drivetrain Sparks are broken. Any recommendations or ideas for what could be going wrong would be very much appreciated. Thank you!!!
Julia
Please post or link your code.
Here is our DriveTrain subsystem https://github.com/219Programmers/integration-2020/blob/master/src/main/java/frc/robot/subsystems/DriveTrain.java
Here is our Drive command https://github.com/219Programmers/integration-2020/blob/master/src/main/java/frc/robot/commands/Drive.java
Any help would be appreciated 
Start with the Spark Max status codes:
http://www.revrobotics.com/sparkmax-quickstart/#status-led
The color and blink type can mean different things. It seems like you might be missing a third color.
1 Like
So the issues we’ve been having are that we are constantly losing coms with the robot in general and that the four sparks on the drivetrain are chattering and we can see that they are losing coms. It’s strange because we have coms with other sparks on the robot without any issues.
Sounds like a code issue. But…
You might start by checking your driver station log to make sure you aren’t getting a brown out condition. Are you sure your drive train motors aren’t fighting each other? You can check by (powering down first!) disconnecting a motor (and then powering back up again!) and checking if that side of the drivetrain works better. Then disconnect the second motor and reconnect the first one that was disconnected. Make sure it goes the same direction when you activate your controller.
The motors aren’t fighting each other because we individually ran each motor and they still gittered. Thought the spark max client
They oscillate from blue to green (they are on break mode which is why they are blue).
We just ran into this issue, and were able to diagnose it to a bad connection. When going from a low-current to a high current to a motor, you get line voltage sag to the motor, which can brown out the Spark Max, even if the rest of the system isn’t affected. When you see this, it goes from green/red (applying voltage) to blue (brake mode idle). When the motor reboots, it picks up the appropriate CAN signals to apply power, and tries again, and browns out once more. This may or may not be your issue, but it’s a good sign that it’s power related.
So the issues we’ve been having are that we are constantly losing coms with the robot in general and that the four sparks on the drivetrain are chattering and we can see that they are losing coms
This indicates a greater robot-wide problem for handling power. Drive trains pull a lot of current very fast, and can instantly drop the robot voltage into brownout territory. Watch the SmartDashboard plots for robot voltage, and make sure you’re not seeing sharp spikes below 7V. You can also plot voltage that the Spark Max’s are seeing, but be aware that they don’t update properly when the spark max is rebooting.
We’ve found it very helpful to prevent brownouts on the drive train through a few different measures: First, try adding an.setOpenLoopRampRate() to each drive train motor. We find that relatively small values, such as 0.1 or even 0.05 can prevent the sparks from thrashing your robot voltage, and don’t really impact the drive performance in a noticeable way.
The SmartCurrentLimit also is valuable here: This can be used to precisely budget the current going to the drive train. Especially when running on older batteries, setting an appropriate drive train power budget is crucial to preventing brownouts and shuddering. A brand new battery is rated for 300A, and drive trains can pull almost all of that just by themselves.
Another thing you may be able to do is put the robot up on blocks, and then try to run the drive train. This should use significantly less current than when the robot is on the floor, and will help you with diagnosing some of the power draw during operation, and confirming any potential code issues. If your robot performs nominally on blocks, but then fails on the ground, you can more easily verify that the code is working, and the power/battery is not. If it’s failing on blocks, then you may have errant code causing problems.
Thank you. For the connection issue which connection did you fix that seemed to fix the issue? Now about brownouts, is that also bad connection or another issue ?
Did you implement a ramp in each of the four Spark Maxes?
That moderates brownout when the motors first try to pull in a lot of power at once.
Our biggest issue is that we keep losing comms with the robot. The weird thing about this seems to be that we only lose comms when we are disabled while we have the chittering when running the drivetrain, but most of the time if we are disabled we lose comms with the bot.
Hi! We figured out the chittering problem. We changed the current limit on the Sparks with the client and changed them to 60 instead of 80. Then, in our code we set a closed loop ramp rate and an open loop ramp rate and made the time interval 1 second just to confirm. The chittering stopped. Then we switched out the Ethernet cable from the radio to the rio, which seems like it has ended our comm issue. Hopefully it stays that way.
A big thank you from team 219, your input SAVED 219!
Glad to hear it’s working now! Good luck out there!
As a final piece of advice before you get to a competition: the actual current draw that can kill a robot is highly dependent on an individual battery’s condition. These wear out a lot over time, and eventually become entirely unusable on FRC bots.
This comes into play during a stall condition, which generally is the most power you’ll draw from your bot at once. This occurs when you hit a wall or a robot, and is notably common during defense. Now that you have your SmartCurrentLimit , consider trying to push a wall for a second or so using around 30-50% throttle. If you brown out, then you likely need to lower the SmartCurrentLimit a bit more to compensate for your batteries.
If your team is using a lot of batteries in unknown condition, it’s worth getting them tested. Many automotive centers or battery shops are happy to do testing for FRC teams, and they can assess the max current draw they can generate safely. Many teams also have smaller portable testers they can use to give a rougher estimate of battery health. Asking around a competition may help you filter through your battery pile to remove duds before they kill your bot in a match.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.