search

wpilibsuite / 2024Beta

Repository for Beta Testing of 2024 Software
32 stars 5 forks source link

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

Open bakedPotatoLord opened 8 months ago

bakedPotatoLord commented 8 months ago

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!

sciencewhiz commented 8 months ago

I think you repo might be private

bakedPotatoLord commented 8 months ago

I think you repo might be private

Sorry. Fixed now.

Starlight220 commented 8 months ago

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 commented 8 months ago

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

bakedPotatoLord commented 8 months ago

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.