Sometimes the controller doesn't respond

Technical
#22

Since we suspect this might be Driver Station or WPILib related (or at least the control information from the Driver Station to the RoboRIO over port 1130) we submitted a forum post on the NI forums but received no response from them over several days. We can’t actually submit a support ticket with them since we don’t have an active support contract with NI.

I completely realize this very well could be a code problem on our end, but the more we dig in, the more it seems like we need help from NI or WPILib experts. I’m also worried by the potential for damage to the robot (or worse) as the failure mode is an out-of-control robot that needs someone to react quickly to click disable or hit the spacebar. Is there some other way we can get someone from WPILib or NI to work with us on this?

#23

I opened an issue for the same problem 2 days ago on GitHub. Please post any useful diagnostic information there so that the WPILib team can help get this fixed quickly.

2 Likes
#24

Is the common denominator using the 2022 Driver Station? Are people seeing this bug with 2021 WPILib and 2021 RoboRIO images as well?

#25

This one seems related as well. It’s a joystick data issue that happens with 2022 stuff and the tank drive example and doesn’t happen with 2021 stuff.

1 Like
#26

Can the 2022 DS interoperate with the 2021 roboRIO image?

1 Like
#27

Please accept all of our appreciation! :slight_smile:

Thank you very much for pointing us there!

#28

Update:
After a frustating research I’ve found it the problem is most likely not going to be on our end.
The code is working find until I add a WPI_TalonFX to a subsystem.

If you were able to solve your problem or anything please share here.

#29

My joystick problem started with 2022 beta. Not resolved. Waited for release to see if that would fix it but problem continues. During the beta period I reverted the Rio and DS back to 2021 and 2021 code and it works fine. The code is the same as last two years with just the necessary adjustments to get it to compile with 2022 WPILib.

#30

Unfortunately, no one elected to report the issue during beta (even though finding issues early is the reason we do beta), so that’s good information to have. Maybe it was a case of bystander effect.

#31

Sorry we didn’t report my team didn’t tried the beta at all a few days ago we swithced to the 2022 from 2020. If you could help us we will really appreciate it.

Thanks a lot.

#32

We’re still trying to narrow down if this is a Driver Station issue, a WPILib issue, a NetComm issue, or some combination of the three. Nothing is sticking out in the WPILib commits, and we can’t audit NetComm, so we’ll have to trust the maintainers on that one.

We’ve established the 2021 roboRIO image and 2021 DS don’t exhibit the problem. If the 2022 DS will work with a 2021 image, and vice versa (2021 DS with 2022 image), that would be the next thing to test to differentiate between the DS and NetComm/WPILib. Both configurations should be tried by people with robot hardware.

2 Likes
#33

I believe this is expected to resolve the issue…

2 Likes
#34

See topic2249 on beta collab site reported Dec 2nd.

1 Like
#35

For any future roboticists who find this thread, the new version of WPILib 2022.2.1 is supposed to fix this.

1 Like
#36

Is anyone else still having this issue after updating to the new WPILib? It’s not ‘as bad’ as before and we can recover more quickly by restarting DS and/or the robot to clear any stuck inputs. However, it definitely still occurring at a rate that would be unusable at a tournament.

#37

If restarting just the DS fixes it, it’s definitely a different problem. Can you describe your setup and what problems you are seeing in more detail? Posting a link to your code and DS logs of cases when it happened would be helpful.

#38

Our code repository is here. We’ve been trying out different driving methods, FYI.

This is a brand new project for 2022. We’d experienced the same issue with our 2021 code when we imported it, but that code isn’t updated.

It’s a bit hard to pin down what actually fixes the issue. Generally we have just been restarting things until the issue goes away. DS restarts definitely seem key, but other times just a code redeploy has helped. Other times a robot restart has also been necessary. We’ll keep trying to methodically pin it down. I’m going to get DS logs posted from the driving computer in a minute.

#39

2022_01_22 12_14_57 Sat.txt (311.8 KB)

I changed the extension from dslog to txt to make it upload, This was an attempt we just did. You can see where we stopped teleop because the robot crashed into a wall when it went out of control.

#40

Your build.gradle says the version is 2022.1.1. Try upgrading the project to 2022.2.1 (after you install 2022.2.1 vscode should prompt you to do this when opening the project, but you can do it manually by editing build.gradle).

#41

Yep, I’d checked for updates previously, but hadn’t gotten any prompt and had updated the previous 2021 project that we’d imported, so this must have just been a weird glitch where the new project wasn’t seeing the update. We’ll try it some more to confirm, but I betting that cinches it, Thanks!