-
Notifications
You must be signed in to change notification settings - Fork 179
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(api): expose versions of connected micros #12470
Conversation
Codecov Report
@@ Coverage Diff @@
## edge #12470 +/- ##
==========================================
- Coverage 73.81% 73.45% -0.36%
==========================================
Files 2246 1498 -748
Lines 61740 49150 -12590
Branches 6430 2991 -3439
==========================================
- Hits 45574 36104 -9470
+ Misses 14653 12590 -2063
+ Partials 1513 456 -1057
Flags with carried forward coverage won't be shown. Click here to find out more.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code changes look good, but did have one question about how we handle bootloader ids.
@@ -68,6 +69,25 @@ | |||
OT3SubSystem.gripper: NodeId.gripper, | |||
} | |||
|
|||
NODEID_SUBSYSTEM: Dict[NodeId, OT3SubSystem] = { | |||
NodeId.gantry_x: OT3SubSystem.gantry_x, | |||
NodeId.gantry_x_bootloader: OT3SubSystem.gantry_x, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess not super relevant to this PR, but should we be throwing an error somewhere in the hardware controller if one of the microcontrollers is in a bootloader state? Or, at the very least, should we not mask whether a node id is a bootloader?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes we should. i think we need to overhaul that at some point.
Implement the get_fw_version method of OT3API to return a stringified representation of all unique firmware versions for attached microcontrollers on the system. This is a not-great way of exposing this data programmatically, but this element is only used for display purposes so I think it's ok. In all normal cases (i.e. except during update) this will only return a single version. Closes RCORE-731
434f27c
to
62c5de3
Compare
Implement the get_fw_version method of OT3API to return a stringified representation of all unique firmware versions for attached microcontrollers on the system.
This is a not-great way of exposing this data programmatically, but this element is only used for display purposes so I think it's ok. In all normal cases (i.e. except during update) this will only return a single version.
Closes RCORE-731
Testing