Can status#41
Conversation
I copied and pasted the code form the CAN monitoring branch. I'm getting errors I didn't expect so I am saving the changes to look at the other branch.
I added a basic update status method to the CANHealthMonitor so that the subsystems that use it have something to call.
I had Claude import the framework used in the main robot can monitoring branch to here. I haven't reviewed this, but I want to save the changes to check on another computer later.
We don't really care what percent of the Can bus is connected, unless it is 100%. removed that entry in the logs.
|
|
||
| // Phase 1: Simple device status tracking | ||
| private final Map<String, Boolean> currentDeviceStatus = new ConcurrentHashMap<>(); | ||
| private final Map<String, Queue<StatusEvent>> deviceEvents = new ConcurrentHashMap<>(); |
There was a problem hiding this comment.
I think this "deviceEvents" object and all the code related to maintaining it can be removed. This goes through a lot of effort to build and maintain queues of status change events for each device, but never really uses them anywhere. The important part of logging the status change event to AdvantageKit doesn't require any of that tracking. I think this becomes a lot simpler if this stuff is removed. I've been trying to find some other place that is using this queue of events and couldn't find anything that needed this. Was there some other intent for keeping track of the last 10 seconds worth of status change events?
There was a problem hiding this comment.
I think it's used in the next branch off this one where I start generating different alert levels. The 10 seconds was to determine if it's repeated frequently enough that we should upgrade the severity on the alert generating side.
But maybe that distinction isn't worth the effort. I could see a case that we just generate an alert when there are any intermittent errors and let the logging speak to how bad it was when we address it in the pits.
There was a problem hiding this comment.
Because my branch naming is a mess, this branch is intended to be the next development step after this PR, and is where this deviceEvents storage is used. https://github.com/frc-88/2025-Robot/tree/DEV1-CAN-status-dashboard.
I'm very interested in what you think of this code with that next layer included, since I don't have any instincts on if this is a good use of resources or an excess that we could just cut.
2 participants
The code in this PR sends the status of all CAN devices on the DEV1 base to the CANHealthMonitor where that information is collected, logged and displayed through dashboards for monitoring and diagnostics.