Sometimes the controller doesn't respond

Hey there,
We’ve recently countered a weird issue, sometimes when we deploy code (sometimes it happens while we are in enable mode, but it is more rare) the controller stops giving new data, it’s getting stuck at some point (not necessarily zero). We have tried different controllers and it doesn’t seem to work. The DriveStation shows as that we are getting values from the controllers but our code doesn’t (we tried printing directly the value), this might be caused by a NetworkTables issue but we doesn’t see anything weired in the logs.

We are using 2022 wpilib.

Do you know what can cause it, or how to fix it?

Thanks a lot, Hadream team 3075

It could be a lot of things.

It may just feel like the controller stops giving new data, when indeed the problem lies elsewhere. We’ve seen a lot of problems over the years that look like loss of robot control with the controller, but they are rooted in electrical, mechanical, system processing, bandwidth limits, etc.

Post a link to your code to see how it looks and we can see if there’s anything obvious.

1 Like

Here is the code.

1 Like

Hello. We’ve been having this problem for a couple days, but wasn’t sure if it was our code or not.

So any new programs we’ve created just to run motors or whatever work fine. The problem we’re having is with our imported 2020/21 robot (we just wanted to get it going to drive around with 2022 firmware, etc.).

Digging into it a little more, we put in some print statements in the robotPeriodic method to print out the left and right X/Y values every 4 loops, and wiggled the sticks around. What we found was that the values stop changing after a fraction of a second. Meanwhile the Driver Station USB tab still shows all the values changing when we move the sticks, the same as you describe. The controller will start working again if we restart the robot code, but stop again almost immediately. Here’s the printout:

SmartDashboard.updateValues(): 0.009965s
8.220: disabledInit(): 0.000429s
8.220: robotPeriodic(): 0.026782s
8.220: LiveWindow.updateValues(): 0.000105s
8.220: Shuffleboard.update(): 0.008493s
8.221: disabledPeriodic(): 0.001217s
8.221:
8.267: LX:-0.98, LY:-0.66, RX:0.08, RY:0.02,
8.307: LX:-1.00, LY:-0.54, RX:0.08, RY:0.02,
8.350: LX:-0.84, LY:0.17, RX:0.07, RY:0.02,
8.390: LX:-0.58, LY:0.42, RX:0.07, RY:0.02,
8.430: LX:-0.18, LY:0.51, RX:0.07, RY:0.02,
8.475: LX:0.14, LY:0.27, RX:0.07, RY:0.02,
8.519: LX:0.17, LY:0.05, RX:0.07, RY:0.02,
8.557: LX:0.13, LY:-0.20, RX:0.07, RY:0.02,
8.599: LX:-0.05, LY:-0.61, RX:0.07, RY:0.02,
8.663: LX:-0.30, LY:-0.60, RX:0.08, RY:0.02,
8.698: LX:-0.45, LY:-0.47, RX:0.08, RY:0.02,
8.735: LX:-0.45, LY:-0.47, RX:0.08, RY:0.02,
8.772: LX:-0.45, LY:-0.47, RX:0.08, RY:0.02,
8.811: LX:-0.45, LY:-0.47, RX:0.08, RY:0.02,
8.850: LX:-0.45, LY:-0.47, RX:0.08, RY:0.02,
8.887: LX:-0.45, LY:-0.47, RX:0.08, RY:0.02,
8.925: LX:-0.45, LY:-0.47, RX:0.08, RY:0.02,
8.962: LX:-0.45, LY:-0.47, RX:0.08, RY:0.02,
8.998: LX:-0.45, LY:-0.47, RX:0.08, RY:0.02,
9.037: LX:-0.45, LY:-0.47, RX:0.08, RY:0.02,
9.074: LX:-0.45, LY:-0.47, RX:0.08, RY:0.02,
9.112: LX:-0.45, LY:-0.47, RX:0.08, RY:0.02,
9.147: LX:-0.45, LY:-0.47, RX:0.08, RY:0.02,
9.186: LX:-0.45, LY:-0.47, RX:0.08, RY:0.02,

If you happen to be in the middle of a robot move, it just continues on its merry way, so you’d better be quick on the spacebar! :slight_smile:

I’m a bit embarrassed to say I’m not sure who we contact about support… is this a WPILib thing or an NI thing? We posted some early information we had to the NI forum about this on the 10th, but we didn’t get any response: Joysticks detected by Driver Station but still getting warning message. - NI Community

Thanks!

3 Likes

Another thing that’s probably relevant is that if we physically power the robot off and turn it back on, we get these messages in the log, but if we deploy the code again, these go away (until the next hard power cycle):

It should be noted that the Driver Station still shows all the axes and buttons working correctly when this happens.

Hey mate,
I’m sorry for the delay, we probably have hour differences in our local time.

I think we might have the same problem. we see the warning that you attached at all time and not only when restrating the robot.

We have also imported our code so it might be the same problem.

Thanks for your resond, we’ll keep you posted.

Thank you for getting back to us!

So it’s possible it has something to do with the import, or possibly something to do with just being a reasonably large code base. I have another really tiny imported project from the fall that didn’t have a problem.

If it’s the imported part that’s a problem, one work-around would be to create a new project and copy all the classes in. I can’t try that until tonight or maybe tomorrow.

One other detail… we have two controllers: one Xbox controller (0) and one Joystick (1). Maybe that’s relevant.

I don’t see any code in this thread. Was the code working prior to updating? Thinking about the basics. Do you have multiple drive command classes that are in competition with drive and did you declare the drive subsystem as required?
Have you reviewed what program is the default program?

The 3rd post in the thread contains code.

Yes, the code was working prior to updating/importing (it’s the same code we used in the 2021 skills competition).

It’s important to stress that all of the code on the robot is working. When enabling the robot, the swerve modules home, the shooter hood homes, the intake runs and reacts to balls. Buttons on the dashboard work as expected. The drivetrain actually responds to the input from the controller… it’s just that it’s a frozen input from a fraction of a second after robot program start (typically wants to drive off at a very slow speed due to stick inputs not being exactly zero). The field-oriented swerve code is working and holding a heading. It’s just that the controller inputs show up on the driver station but stop being sent to the robot.

We have checked all of that and the code was working before updating to WPILIB 2022.

I’ve just tried the workaroud (created a new project and copied the files) and it didn’t work,
I’m starting to think that the problem is probably intrior to our code, we might be suffering from the same bug.

What do you think?

Can you confirm that your periodic method is being called? Perhaps update a counter to System.out.println or dashboard… Right where your Joy is Funnnnnn thing is…

I’m curious if Joystick input is stopping or if the robot loop is stuck somewhere…

The printout I posted above was from robotPeriodic(). As I said, all the robot code and mechanisms are still working. The robot reacts to sensors. I can click buttons on the dashboard and they have an effect on the robot. The robot even drives off in the direction given by the “frozen” controller input when I enable teleOp.

If you think it might be in your code, try commenting out all the mechanisms (except the controller and one thing), confirm the problem goes away, then uncomment them one at a time until it comes back. This often helps me narrow down the search space.

So, when the Joysticks no longer work you can still call a command via the dashboard?

Correct. In this case we have a command button on the dashboard that tells the robot to turn off field-oriented control. This is a backup mode used in case the gyro wigs out. That puts it into a robot-oriented only drive mode. I can click this button and see it go into that mode. I can also click the other button that sends it back into field-oriented mode. The swerve modules behave differently in these modes so it’s obvious this is working. In field mode if I physically turn the robot it will resist me and go back to the original heading. In robot mode all the wheels turn parallel to each other and they attempt to drive at the speed indicated by the frozen xbox stick input.

Got it. You only have one Joystick? I have had issues with past drivers stations when our code expects extra Joysticks…. It did work… But was super slow due to error handling. Sorry I can’t be more help. We haven’t upgraded yet…

I’ve checked the counter is working, it doesn’t stops when the controller stops

Controller 0 is an Xbox Controller and controller 1 is a Joystick. Both are plugged in and showing up and responding in the Driver Station. We’ve tried different xbox controllers.

Another thing we tried is changing the loop time from 20 ms to 40 ms, just to see if we were close to the loop time and the latest WPILib is a bit more CPU hungry. That didn’t help.

We only have one XBOX joystick