Skip to content
This repository has been archived by the owner on Jul 21, 2024. It is now read-only.

WPILib beta 3: Command Scheduler Overrun Exorbitant Error Logging #57

Open
bakedPotatoLord opened this issue Dec 28, 2023 · 5 comments
Open

Comments

@bakedPotatoLord
Copy link

I'm developing swerve code for my team with the beta 3, and I'm getting CommandScheduler loop overrun printed to the log a LOT, I don't think that that is the expected behavior, and I'm also not sure what part of my code is causing the loop overrun.

Here's the riolog as .json and .txt,

Here's a link to a specific commit of the repo which can cause this issue, as I'll still be actively developing with this repo

thanks!

@bakedPotatoLord bakedPotatoLord changed the title wpilib beta 3 Command Scheduler Overrun exorbitant error logging WPILib beta 3: Command Scheduler Overrun Exorbitant Error Logging Dec 28, 2023
@sciencewhiz
Copy link
Contributor

I think you repo might be private

@bakedPotatoLord
Copy link
Author

bakedPotatoLord commented Dec 28, 2023

I think you repo might be private

Sorry. Fixed now.

@Starlight220
Copy link
Member

Are any commands running? It doesn't seem so from the epoch prints, which is quite suspicious.

SwerveModule.periodic is taking significantly a lot of time. I'm not sure it's enough to cause loop overruns, but it's clearly not helping. Can you profile it with the Tracer class? I suspect it's the CAN calls.

@sciencewhiz
Copy link
Contributor

Why are you setting PID gains every loop in SwerveModule.periodic? They don't appear to ever change.

@bakedPotatoLord
Copy link
Author

Why are you setting PID gains every loop in SwerveModule.periodic? They don't appear to ever change.

I was using it for tuning. I now that I've optimized the constants for those feedback loops, I commented it out in this commit, and it's no longer consistently overrunning the loop (@Starlight220 was right). However, the code still overruns the CommandScheduler loop at startup, possibly from setting the gains of the CAN SparkMaxes, or setting up shuffleboard. That's tolerable for me, but I'd be interested if there's a way around that (such as setting them faster, or maybe doing it before the CommandScheduler
starts up).

Regardless, we still haven't figured out why it was printing the overrun message too many times. I don't remember previous versions having that behavior.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants