For the last year we’ve been running AdvantageKit with our robot code, but the issue we’ve been having was our robot CAN utilization would spike way above 50% CAN utilization for whatever reason, we’ve created a separate project just for testing purposes, with YAGSL and with/without AdvantageKit.
With that, our findings were that when we run the robot project with just YAGSL, and deplyoing and turning on the robot without doing anything whatsoever and leaving the robot there for about 3 minutes, and what we found was that our CAN utilization sits around 40-50% and it’s shown in our logs hosted on gofile.io, and the code we used without AdvantageKit installed is located on our GitHub
While on the other hand, when we install AdvantageKit on that same repository, with everything correctly configured like we would usually have it on our actual robot code, we found that CAN utilization would predictably spike above 50%, usually around 80%, and it’s shown in our robot logs on gofile.io, and the code we deployed to the robot is shown here on our GitHub as well, on a different branch.
And just to be sure it isn’t a skill issue on my end, I went ahead and uninstalled AdvantageKit on our actual robot code and it showed the same result as if it was on the clean swerve project, the log file is (again) uploaded to gofile.io, and the code I updated on our 2024 Crescendo repo
All of the log files linked was the robot being run disabled idle for around 3 minutes give or take, and as well no USB drive being plugged in, but whenever I initialized the USB logging or not, it’s still the same result.
I focused ALOT on CAN/Memory/CPU optimizations in the last 3 versions, try updating to the latest version of YAGSL. I don’t expect your results to change bc I am sure AdvantageKit is doing something weird but it’s worth trying.
We should be on the latest versions regardless of yagsl and AdvantageKit, so it shouldn’t be an issue with YAGSL, we don’t think it’s an issue with yagsl yet, but we’re gonna continue further testing tomorrow
I can update YAGSL with our current setup in like 3 ish hours, but I kinda doubt that it’ll change anything major when running alongside YAGSL unless the two are clashing for whatever reason.
I have an ongoing theory that it might either be the new PD logging instance in our Robot.java AdvantageKit configuration, or something else since it doesn’t look like any other teams are having the same issue.
And this happens throughout different robot hardware, like a different RIO, CAN devices, etc.
I’ve went and created new branches without YAGSl, with just AK, and a base project, two out of three of them should have a dslog updated to the branch. But from what I found, the util jumping around is in fact something to do with AK, whether or not logging is enabled or not, but it doesn’t jump to 100%, only around like 60 or 70. I don’t really have much time to type everything out because I’m almost out of time for my lunch break, but here’s the code I’ve used to run the tests:
My previous theory seems to have been wrong, in the Robot.java I disabled the PDH logging and even stopped the Logger, but the CAN would still spike around.
By the looks of my testing - and I can verify it later tonight to be sure - when I just isolated AdvantageKit inside a project that’s just it, the utilization would still look spike up and down. From what I found, it looks like something in AdvantageKit is causing the CAN usage spiking, the CAN util reaching 100 is likely the joint thing with AdvantageKit spiking our CAN, plus other libraries like YAGSL.
Did you update the frequency from 250 to 50?
if you aren’t using a CANIVORE, you need to change teh odometry cycle timer from 250 to 30-50 or you’ll easily hit 80% can bus utilization
If I remember correctly, we did get some CAN errors, but they might have been unrelated. It looks like it’s noise from AdvantageKit reading the CAN network every so often, giving us false usage data, and us hitting 100% is probably AdvantageKit plus other libraries/devices using the CAN at the same time and maxing it out.
