HWP Gripper Updates (Alarm group and restart processes)

[bbixler500]

Description

Adds two new tasks to the agent. alarm_group queries the specific type of generated alarm. This function will return a value of (False, 'B', 'C', 'D', 'E') depending on the current alarm state, where the letters correspond to specific groups of alarms. restart remotely restarts the processes which are running separately on beaglebone microcontrollers

Motivation and Context

Currently the agent is only able to query whether an alarm is present and does not have any way to distinguish different alarms from each other. The alarm_group task adds more specificity to what alarms are generated. As a seperate issue, any time there is a power cycle to the hwp enclosure, a remote user needs to manually ssh into the gripper beaglebone microcontroller and restart two processes. This is both a hassle and requires an expert's knowledge. The restart task condenses this process into a single button on OCS-Web which can be run by anyone.

How Has This Been Tested?

These two tasks have been tested to work with the satp2 hwp. Note that these changes require running the most recent version of the beaglebone code located in the sobonelib repo. There are likely still edge cases which I haven't fully considered, but these should be isolated to these two methods and should not effect the rest of the code.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.

[ykyohei]

I followed the instruction described in README of sobonelib and confirmed that new functionalities (restart and alarm_group) also works for satp3. I think these are really helpful, thanks for your update. We should include alarm_group check in the grip function maybe in separate PR.

[jlashner]

Hi Bryce, this looks really nice and useful! One small suggestion I have... do you think we can add an entry to the alarm_group session data called like "decoded_alarm_state", which map to the five definitions you have in the docstring? Is the alarm group state something we should be regularly polling through the main process so we can monitor it in grafana?

[jlashner]

Thanks bryce! I think this looks good and am fine merging if it's been tested.

[bbixler500]

Pinging @BrianJKoopman to see if we can get this merged

[BrianJKoopman]

Pinging @BrianJKoopman to see if we can get this merged

Was waiting on confirmation of the latest version having been tested. If that's the case, happy to squash and merge.

[bbixler500]

Yep I tested those changes with satp2 when I pushed them