I’ve been experiencing a pretty bad error where the robot will disable itself temporarily due to a Command Scheduler loop overrun. I know it has something to do with the one of the commands I am executing, but I have no idea where to start looking. I am wondering if using multiple motors at high voltage could cause this, or where else should I look? I have linked the photo of the error log below and you can access the code here : GitHub - FRC1466/robot-code-2024: Robot code for 2024 season
1 Like
Thats a warning not an error. The warning is that your code is exceeding the main 20ms loop.
Reading that console output, it looks like RunCommand is taking ~26ms. Looking through your code, you don’t have a RunCommand class, so I presume it’s the one from WPILib, likely instantiated from a call to something like Commands.run() or .runOnce(). I dont see anything too crazy in your code (assuming I was looking at the right branch).
We’d need more information to be able to adequately troubleshoot this.
When does this happen? once at startup? Once at the beginning of auto and/or teleop mode? Repeatedly throughout the match cycle? Pressing a button (if so, which)?
It seems to happen multiple times while running but does not seem to be attributed to a specific button. I will test the robot later today and see if I can find a specific trigger. It does not seem to happen during auto, but I have only written a taxi auto so far.
Code looks pretty innocent, wonder if it has anything to do with having two different commands bound to the same button?
That could be it, but I couldn’t figure out how to have one button do 2 things at the same time. I used the .andThen command, but it took like 1/2 - 1 seconds to trigger the second command after the first was triggered. Is there a command group I could use instead of .andThen to make multiple things trigger at the same time?
ParallelCommand or use alongwith
andThen is a sequential command so it runs one then the other
Thank You so much! This is exactly what I needed!
Did this solve your loop overrun problem? There should not really be a significant problem with having two commands bound to one button. If switching to a parallel command group solves the loop overruns it bears further investigation for a library misbehavior.
That said, I don’t expect it will solve the overruns. The fact that the overrun is labelled RunCommand.execute in the log means that it is a single call to RunCommand.execute that is using the time. As far as I’ve been able to determine RunCommand is only used when your code creates a command with subsystem.run() or Commands.run(). It does not get used when your code creates commands with runOnce. And the only place I can find in your code that uses run is the commands for the SwerveSubsystem and that ultimately leads to the swerveDrive.drive method. I believe that comes from the YAGSL library and so I can’t see it in your code.
One thing to do that would be helpful would be to attach a name to the default SwerveSubsystem command. In the commit of your code that I’m looking at you could do that by changing line 78 of RobotContainer.java to
() -> MathUtil.applyDeadband(driverController.getZ()*.8, .1)).withName("DefaultDriveCommand");
After that, overruns due to that command should be reported as belonging to DefaultDriveCommand.execute instead of RunCommand.execute. This would at least let you confirm that the drive command is the culprit.
2 Likes
You are right, it did not fix my issue. The robot still disables both while tethered and while connected via radio. It seems that the issues are more prevalent while connected to wifi. I did the change you suggested, and have also updated the code since, here is the link - GitHub - FRC1466/robot-code-2024: Robot code for 2024 season . I am also posting the rio logs and charts for while I was driving the robot and moving the arm while tethered. The green spikes are the connectivity spikes where the robot temporarily disables.
Some progress. The named command confirms that the overruns are associated with the Drive method. I’ll look again but I was convinced before that it could only be in the YAGSL code.
I’m not fully convinced that the disconnects are due to the loop overruns. Could you upload the DS Log file (the actual file, not just the image) that you included in your previous post? That may help understand whether the overruns and disconnects are happening at the same time.
1 Like
A couple more thoughts: there are newer versions of the Phoenix and YAGSL vendor deps. One or the other of those might have an effect.
It’s not clear to me why you need the Phoenix 5 vendordep. It shouldn’t be a problem, but if you can switch to using Phoenix 6 for everything it would reduce the number of possible interactions that need to be considered.
So I have a strong guess that updating to the latest YAGSL will fix the loop overruns. In the version you’re using, on each iteration each module calls CANCoderSwerve.getAbsolutePosition which will try up to 5 times to get a valid angle, waiting up to 10ms per try.
The newest version implements a cache that should make this far less likely if not impossible.
I would still like to see the DS log file as I’m not convinced that the disconnects are caused by slowness reading the CANCoders.
1 Like
The loop overruns were troubling to me and that is exactly why i made thr Cache. It will get even more unlikely with the next update tomorrow that will reduce extraneous memory utilization we found a few days ago.
1 Like
It appears to have no more errors in the Command Scheduler Loop override, but we have developed a new error(Yipee!). We recently completely gutted the robot and rewired everything for some mechanical changes to the arm and we swapped to Krackens. I did not expect any errors, but I was very wrong. We have now developed a very interesting error where the drive motors will only work some of the time. They will go forward when I press forward, go sideways when I press sideways(on flight stick), but when I go forward again some of the motors will not go forward. This is only an example, as they will cut in and out, seemingly randomly. The only real result I can find is if I rotate the robot and then drive in a direction, all the motors work after turning. My most recent iteration of the codebase is on github, and would appreciate any ideas and or help. A video of the robot and the DS logs are posted below.
1 Like
Not directly addressing your question, but I see that the wheel on the right of the screen in the video is 45 degrees misaligned to the one on the left. I think the one on the left is correct for the moves you’re making.
That is due to me not correctly aligning the wheels. I have since fixed it and can re-record the video if that would be helpful.
I don’t really have any insights about the behavior you’re seeing. I think @nstrike is your best bet on that.
That would be helpful.
I am still experiencing errors, and do not know if it is related to YAGSL. The robot will randomly disable, with seemingly no motive. It will disable both when driving, running arm motors, or even while It usually only disables after a bit, like 46-60 seconds, but sometimes disables within seconds of being enabled. It seems to do this both while tethered and untethered. It is also still giving the command scheduler loop override, and I will post the DS logs below.
https://drive.google.com/drive/folders/1w9m765zzTIVY_3TfTjsB_nXd3u_VFWpH
1 Like
Are you using the latest 2024 patch 1 DS?