Programming/electrical issues mid-match

Today we had a few issues with our drive train and we don’t know what caused them. We talked to the CSA at the event as well as a few people from other teams but no one can figure out why we’re experiencing these issues.

The first issue was that in the middle of a match suddenly turning controls switched with the forward-backward controls and vice versa. When we pushed or pulled the joystick robot would turn. When we twisted the joystick we would go forward/backwards. We couldn’t find anything in the code that would cause this to happen. We switched the x and z-axes in the code which is a short-term fix however we still want to find a solution in case it switches back in the middle of a match again. We believe this started after we hit the tube that runs through the center of the field and bounced a lot however we’re really not sure because it was a pretty crazy match.

The second problem is that our driving works great in the practice room when we’re tethered but the driving is much worse on the field. When we’re on the field the the robot is not very reactive and it is difficult to drive the robot. This issue is weirdly off-and-on. We had a match that had this issue and then a match that went great.

We did go through the robot to see if it was a mechanical issue but we didn’t see anything. The wheels are all fine, nothing is really dragging on the ground, and nothing is dragging on the wheels themselves.

Some information about the robot that you all may need to help us. We use SPARK MAXs and NEOs on our drive train and program in Java.

Thank you in advance to anyone who can give us a hand with these issues!

Have you experienced these issues with the same laptop being used for the driverstation or multiple?

This sounds like your motors inverted somehow, as that would change your turning and forward axis. Do you know if you are configuring any of the SparkMax settings in the code? Also would you be able to post your code?

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.