WPILib 2022.4.1 has been released. Wasn’t mentioned in the Team Update earlier this week. https://github.com/wpilibsuite/allwpilib/releases/tag/v2022.4.1
Wasn’t mentioned because it’s not a mandatory update. It’ll solve problems for certain VERY advanced teams, but would make no difference for a vast majority
This update really saved us. Thanks to @Thad_House and others who helped us diagnose some issues we were having and for putting this release together.
Best,
-Mike
Thank you. This might fix a problem we have using multiple threads calling in a synchronized object due to still using the old command-based framework. The code was working fine in prior seasons and I have been pulling my hair trying to understand what the problem could be!
For us the major benefit comes from the improvements to the tools – esp. glass and sysid. We may also be able to take advantage of the high-speed logging. So I think it is of broader interest than just a few advanced teams.
WPILib 2022.4.1 solved our issue! We use a camera object that serves as a PID source for the old multithreaded command framework, which may be called by the main thread and the PID controller thread, and therefore relies synchronization to protect its members. Its behavior prior to WPILib 2022.4.1 was completely erratic. It sometimes looked like the main thread went MIA. Now things work again as expected.
Yes and no imho. Pretty much any team that still uses the old command framework and the old PIDController is likely to face this issue…
If you’re referring to the “old” wpilib command framework (as opposed to the “new” command framework), it’s entirely possible that I’m mistaken, but I don’t believe that ran multithreaded either. Or are you referring to a specific aspect of that framework (i.e. not the command scheduler)?
Yes, I am referring to the “old” wpilib command framework [edit: but specifically the old PIDController].
The old PIDControllers use their own thread, and I assume that this was not clear to everybody and therefore the source of some hard-to-understand bugs, and the main reason why the “new” command framework is single-threaded.
“Unlike the earlier version of PIDController
, the 2020 PIDController
class runs synchronously , and is not handled in its own thread.”
TBH, we didn’t realize old commands had the code that triggered the flaw. But looking through, it definitely does. Thats our mistake, and we will get it added to the documentation.
After running the 2022.4.1 installer and then opening our robot project in VScode, it didn’t seem to make any changes to the project to “upgrade” it. In particular the build.gradle file still has GradleRIO 2022.3.1 version listed in the plugins section.
Is this expected, or did I do something wrong?
Unexpected behavior if it didn’t prompt you.
Simply change the GradleRIO to 2022.4.1 manually.
It didn’t prompt me, no. But I just changed it and compiled, and it seemed to indicate it was using the 2022.4.1 libraries, so… fingers crossed.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.