Loop overrun discussion

[godmar]

From CD:

• one thing which helped us a lot was to call BaseStatusSignal.refreshAll once per loop cycle on ALL status signals instead of a per device/subsytem basis.
• We found it was indeed the USB drive for the logs bogging everything down.
• Most cases are going to be because of frequent use of blocking CAN calls.
• Avoid sending too much data to NetworkTables/the dashboard periodically; I would recommend sending data every 100ms rather than 20ms

[godmar]

I'm looking at the issue with refreshing CANBus signals. I thought about whether it would be worthwhile to create an abstraction that collects all subsystems that need signals refreshed into one call to refreshAll; if the StatusCode returned is not OK then it would find out which ones were failing and return this information via a supplier. That's when I took another look at PhoenixOdometryThread.

The PhoenixOdometryThread that's part of the akit template provides code that seems to poll and store signals from "high-frequency" devices in queues that can then be read. My interpretation here is that if you have something that produces signals at say 1000Hz, you'd be collecting 20 values every 50 Hz. They do this in a separate thread (possibly leveraging the RoboRio's second core). The accrued signals are then provided to the code - for instance, the pose estimator. I'm wondering whether we should be leveraging the abstraction and service provided by the PhoenixOdometryThread for our other IOs that are higher frequencies.

I'm curious as to how this works in our code, and specifically remembering that you said we'd like to obtain velocity signals from the shooter at a higher frequency. From what I can see, you're calling the MotorIO's input (which calls BaseStatusSignal.refreshAll()) once per robot loop via updateInputs.). Does this mean we're discarding the additional signals that may have accrued between control loop iterations? I think you'd mentioned that the sole goal was to minimize the time between the most recently received signal and the time of processing. I'm wondering though if, with a noisy signal, to truly benefit from the higher sampling rate, it may be better to collect and aggregate all values and then, perhaps, report an average over the last 10 or 20. (In any event, if my recollection here is correct, we should document our motivation for setting a higher sampling rate since it's a bit counter-intuitive to collect more samples than can be processed just so the current signal is more recent.)

[aidnem]

Looks like we can use BaseStatusSignal.isAllGood to check each IO's status signals independent of refreshing. Its source can be seen here. We could also use a StatusSignalCollection but I don't think it really gives us anything other than slightly prettier method calls.

Internally, isAllGood calls getStatus which returns a cached value, and isOk which is just an equality check on an int.

I think it might be worth our time to move ahead with a class to refresh all signals for us.

If we really want to minimize allocations, we could reuse the same RunOnce and just reset it in between cycles.

[aidnem]

I just realized, we don't need a runOnce. We should just make the startPeriodic method refresh all the signals.

[aidnem]

@godmar should I or somebody else go ahead and prototype this in coppercore so we can test tomorrow? While our loop times are technically fine by a margin, I'd like to see them come down.

[aidnem]

I reached out to 422 and obtained the code they use for this exact purpose. I got permission for us to publish it with attribution so I'll make a PR integrating it with coppercore tomorrow.

[aidnem]

This is ready for review now in coppercore: team401/coppercore#249

[aidnem]

@godmar I used some of my copilot quota to ask Claude Opus 4.5 to reduce allocations in our code. It did extensive optimization (some of which was only relevant to sim, so I might ask it to undo these) but it had the effect of reducing allocations in sim according to visualVM from 36mb/s to 27m/s.

It did a lot of restructuring of our module code to reuse arrays and values rather than creating new arrays and using a lot of streams. This should also show an improvement in real life on the roboRIO. I was working off of my branch for #80 since that's where we saw issues. Would you like me to go ahead and commit those changes so you can see what it did? We can always revert them later if needed.

[aidnem]

some of which was only relevant to sim, so I might ask it to undo these

Regarding this, I think it mostly restructured the sim module IO the same way as it did the real one, so I had originally just let it continue so I could see if the sim optimization would also mean a real life optimization too.

[aidnem]

but it had the effect of reducing allocations in sim according to visualVM from 36mb/s to 27m/s.

I tested again and the old commit was also now at 27mb/s (although maybe slightly higher). I'm not entirely sure what was causing the massive allocations before, nor whether I've fixed it now.

[godmar]

Check it into a branch perhaps or share a gist with the diffs?

…

On Sun, Mar 1, 2026, 10:03 AM aidnem ***@***.***> wrote: @godmar <https://github.com/godmar> I used some of my copilot quota to ask Claude Opus 4.5 to reduce allocations in our code. It did extensive optimization (some of which was only relevant to sim, so I might ask it to undo these) but it had the effect of reducing allocations in sim according to visualVM from 36mb/s to 27m/s. It did a lot of restructuring of our module code to reuse arrays and values rather than creating new arrays and using a lot of streams. This should also show an improvement in real life on the roboRIO. I was working off of my branch for #80 <#80> since that's where we saw issues. Would you like me to go ahead and commit those changes so you can see what it did? We can always revert them later if needed. — Reply to this email directly, view it on GitHub <#84 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADWX5ISLYRWBXMC3C5BK5T4ORGNNAVCNFSM6AAAAACWC7BO5CVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKOJWGIZTINA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[aidnem]

#86 created. You can see the commit here: 7a7cc35

[aidnem]

One say way to save a lot of logging would be to lazy-evaluate all of our tunable numbers. I had an agent make #87 while I was at the gym (mainly to test the capabilities of agents, to be honest), and it pointed out a lot of unnecessarily logged tunable numbers. We could have some kind of system where we don't actually create any tunable numbers unless:
A) The tuning featureflag is enabled
B) we actually enter the test mode where they're used