Programming/electrical issues mid-match

I agree with Michaelyu here, sounds like your motors inverted.

If you’re using SparkMax’s and doing the inverting in code, its possible that you’re either browning out or you have a slightly flaky electrical connection causing the SparkMax’s to reboot and lose the settings. The code-side solution to that is to call the burnFlash() method on the SparkMax to make the settings persistent through restarts. Electrically you should definitely double and triple check your electrical connections.

We use xbox controllers, but sounds like you’re using a joystick of sorts? We had some really bazaar issues in build season that turned out to be a bad controller. Things like the left stick is only being read for throttle on the Y axis, but the X axis suddenly started doing things, even though the code never read it. When we would drive it would start out fine, then start getting a weird issue where driving straight to turn a bit too. Sometimes it got so bad the robot would spin when pushing to drive straight, only touching the left stick, which was only used for forward backward on the Y axis, no reading from the X.

We thought it was gear boxes, motors, controllers, etc. Spend way to long before tracking it down to a bad controller by logging the inputs the program was receiving to all axis. It was hard to track too because it would start fine, and drift over time with a bit of driving.

No idea if this is related, but was an odd issue that seems kinda similar.

What version of WPILib are you using, and what motor controllers?

Hey everyone! Quick update on what happened at our event with the drive. Unfortunately we never got it to work correctly. We’ll be switching to Sparks and CIMs for our drive train for our next competition this weekend since we haven’t been able to fix the problem. The axes switching thing happened another 2 times during the matches we had. We were able to add a button onto the joystick that we could press that would reverse them so we could still drive although it was with significant difficulty still.

However, the SPARK MAXs all had the correct lights when we were moving. For example, if we pushed the joystick forward 2 of the lights would be green and 2 would be red as one side would have to be inverted due to it being on the other side of the drivetrain. This is what we would expect to happen however the robot would turn instead of going straight. This is really the most bizarre part of the entire issue.

The CSA at the event talked to HQ and no one up there could come up with an answer for our issues. We talked to the FTAs and the FMA program director and no one had an answer as to why we were having these problems. They even looked through all of our code and everything seemed fine. When the axes switched it was always in the middle of a match if they switched at all.

The CSA and our programmers took a look at the Spark MAX settings and they all looked fine. We tried a new computer and a new joystick and had the same issues. As to what version of WPIlib we use, it is the most recent version.

We’ll be emailing/calling REV tomorrow to see what information they have on all this and I’ll let you all know if they give any good insight.

Here’s the code repo:

1 Like

We are using WPILib version 2022.4.1 and spark max controllers (updated to 1.5.2)

1 Like

You aren’t calling burnFlash in the spark max controller so if you brownout the controllers at any point they could forget the config settings like inversion.


I’m new to robot control software and we’re using Java for the first time this year so I’m probably going to get stuck on basic concepts. We’re using setInverted to invert the right side of our drivetrain, does that configure the spark max? I figured that was just on the software layer, since we’re seeing 2 red and 2 green when we try to drive straight (but the robot turns). When I use the rev client on the controllers the inverted flag is not set for any of the controllers.

Should I not use setInverted and instead configure the spark max directly (I guess I need to find the API for spark max)? I see that setInverted for the individual motor controllers is marked as deprecated (the group function is not though), so maybe this is a more future proof solution.

I would recommend you use something like this instead of the MotorControllerGroup.

public void robotInit() {



Then to replace the differential drive with m_frontRight and m_frontLeft. This code basically configures the SparkMax settings internally, so it might help.

Edit: After reading your code a few times, I actually don’t think there is anything wrong, but this might fix your issue.

What joystick are you using specifically? I’ve seen some weird behavior by some aftermarket joysticks, specifically with extra toggle buttons on the joystick themselves. One team had a similar issue where the direction would invert when you pressed a toggle switch. The other had the joystick stop doing anything on one axis at all.

1 Like

We are using a Logitech joystick however the joysticks are reporting the correct direction on the driver station so we don’t think that’s the issue.

It’s not clear to me that inverting the motor direction is actually a configuration parameter. See here. It is possible/likely that this is done in code which runs on the RIO, given that this parameter isn’t listed in this table. It certainly could work as a configuration parameter, and this is an attractive explanation. You should set this and persist it using the REV Hardware Client. Perhaps someone from REV will weigh in here.

You should try hard to reproduce the problem as well – it sounds as though the problem is still there? Or, did it only happen in the match? This would be good to know, as it might help to narrow down the most likely theories…

It is a configuration parameter. This was a change in an earlier firmware version.

This would be useful. When you reproduce the problem, you can plug in a USB cable, and load the REV Hardware Client and verify that the inversion configuration for the specific spark max is what you expect it to be.

1 Like

I’ll try those code changes, but we’re probably going to move these motors and controllers to a test rig and go back to spark & cim because we have no confidence in the spark max & neo right now.

It happened during several matches, the motor would invert (or return to normal) and stay that way for a while (even after a battery change). Last time we tested the robot, 2 red and 2 green were making the it turn so I guess its inverted right now? All 4 spark max are showing the inverted flag as off.

I think the problem we need to reproduce is what is causing it to switch, I’ve seen a few posts that suggest that moving the robot while its powered can cause that so I guess we will be pushing it around the floor tonight (if that’s the case, I’m worried to think what a big defense robot could do to us on the field).

I’ll be CSAing at Bensalem, so I can provide some help if you’re still having this issue when you get there.

I also took a look at your code and found a probably unrelated issue with your joystick deadbands. While this probably isn’t the cause of your issue it might be the cause of this symptom you mention:

I notice in your code here that you’re applying a deadband and exponent to your joystick values. The WPILib DifferentialDrive class already applies this by default, and applying it twice causes your robot to be quite a bit less controllable. Removing the deadband in your code would probably help out with this.

1 Like

If the drive already does that, I’ll take it out. Looks like there’s even a flag for squaring. Thanks.

We think the first time it happened was during match 21, right around the 1:51 mark, you can she she hits the cable trace and gets a little air (4575 is the one with the red and white polka dot sides, hard to miss). After that the robot goes into some loops as Cassie is trying to drive straight. Once she figured out the controls were reversed she is able to limp to the hanger but twisting to drive straight is not easy, twist is way too sensitive.

They’re setting the inverses through the motor control group, which means it won’t show up in Rev Hardware thing. It should function the same though and should be able to work even if the spark max restarts, which is confusing.

Today we got a chance to do some more testing and we were able to recreate the switching scenario many times within a few minutes. They didn’t seem to be linked to any hard landings or sharp turns. We tried switching around the wires to some other Spark MAXs but that didn’t help either. The lights continued to show the correct colors based off of the joystick input even if the actual robot was driving the incorrect way. Unfortunately we still have no idea what could have caused this although one of our mentors has a theory that the static build-up on our robot from the carpet could be causing this.

Hi, I’m the CSA who helped them at their event.

In their code they use 2 speedcontrollergroups, and the inversion is set there, not over CAN to the sparkmax. Here’s the relevant wpilib source: The inversion is contained entirely within this class, it just calls the set() method in the super, and inverts if the invert flag is set. I also suspected this as a possible root cause, but HQ lead me to conclude it is not.

When the inversion occurs, the DS still reports each joystick axis properly. The sliders on the USB tab move as you’d expect, on the axis you would expect.

We could also replicate this on the practice field. They were not driving the robot hard so a brownout being the root cause is unlikely.

EDIT: Also if it was a sparkmax issue I’d expect each one to invert independently. They always invert as the pair.


Hi! If you haven’t figured it out yet-- I’m Noah Solomon, Spartronics 4915’s programming lead.

Our team had this exact kind of seemingly impossible problem with Neos and Sparkmax – when we got hit during matches the joystick would sort of rotate. Someone eventually suggested that it was that the motor was losing its configuration – our right motors are both inverted, while our left motors are not (and the left/right each have the back motor as a follower).

I made this spreadsheet showing and finally determined that it’s that the motor states are lost – if the right motors went the wrong way always it would move just like it does when the error occurs. We reconfigured the motors using the Rev tools so the flash memory has their states; when the wiring like gets jostled enough they lose power they won’t go back to default. We confirmed that this should solve this by running code that does not set states at the beginning, and the robot driving fine. We also have a button on the joystick that during a match when pressed sets the followers and reversals just in case we are e.g. using a replacement motor/motor controller that is not configured and it breaks.

If configuration is for some reason not working i suppose you could try the kind of dumb sounding higher step of running the motor configuration code in the loop rather than just at the beginning/when a button is pressed (thought that might cause problems e.g. if it causes delay for the motors)

Hope this made sense! We spent like 2 weeks with no clue basically, ask me any questions if you need more help.