IMU disable fault

[dhacks541]

Addition of imu_disable fault

Summary of changes

• Addition of imu_disable imu_fault (opcode 0x6012), which must not be signaled in order to enable IMU initialization. This allows the IMU to be indefinitely powered off to reduce current consumption with only 2 Rockblock commands (without having to enter low-power mode)
• To minimize risk to the flight software and reduce the need for additional testing, this new fault is as silent as possible. It can not be triggered via any means except Rockblock command, and the normal report has not been modified to include it. The processed commands section of the normal report and gyro/mag fault fields will provide secondary verification of fault signaling.
• Due to cache v2 being depreciated as of March 1st, the worflows.yml file has been updated to prevent the build failing

Testing

• Functionality of toggling IMU power state, both in low power mode and via IMU disable fault, validated via flatsats 1 and 2 with GS in the loop.
• December 2024 testing consisted of sending two commands to the flatsat via GS during the Transmit phase of a nominal test: one to raise the low power threshold and one to set the imu_power_setting to off. Positive effect on power budget verified via power budget logging scripts. IMU toggled back on via Rockblock command, with proper sensor functionality verified after restart. Nominal test completed successfully.
• March 2025 testing consisted of sending two Rockblock commands to the flatsat via GS during the Transmit phase of a nominal test: forcing the imu_disable fault and setting the imu_power_setting to off. Positive effect on power budget (35 mA in transmit, IMU on / 27 mA in transmit, IMU off / 22 mA in normal, IMU off) verified via power supply display. Command processing verified via normal report and serial log. IMU toggled back on via Rockblock command to suppress imu_disable fault, with proper sensor functionality verified after restart. During IMU shutdown, verified that current output to all magnetorquers was zero. All associated faults triggered by IMU shutdown verified reset after IMU restart. Nominal test completed successfully.

SFR Changes

None

[Duncan-McD]

This change is concise with minimal impact and the verification evidence is clear/well presented. Looks good to me to merge. Only note is with respect to the pipeline .yml

[Duncan-McD]

at its core, this does not need to be a fault because the fault is not being signaled by any conditions inside automation and is only controlled through manual force/suppress (making it functionally equivalent to a boolean SFR field).

However, since the use case for setting this flag to high is when the system is in an off-nominal state, keeping this flag designated as a fault is not causing any harm and in fact my provide some situational awareness to operators. The only clear negative with this approach is that the fault takes up more space in the serialized telemetry packet than the SFR bool would (since bools are packed as much as possible down to 1 bit, while faults are packed down to 4 control bits)

Regardless, since its only a few extra bits in telemetry and since you've verifed this functionality on HITL pretty thoroughly, I feel that going with the fault is okay

Edit: telemetry size is actually irrelevant if we aren't sending it in normal report

[ljgreenhill]

I did not see any verification evidence that this has not impacted normal report decoding in the ground station- that is important. From briefly looking at the PR- if the IMU is already powered, this will not turn off the IMU (I think). Is this intended?

[ljgreenhill]

Do we want to turn off the IMU if it is already on?

[Duncan-McD]

I did not see any verification evidence that this has not impacted normal report decoding in the ground station

Looks as though normal report was not touched so the state of this fault is not being telemetered: https://github.com/Alpha-CubeSat/oop-flight-code/blob/main/src/Monitors/NormalReportMonitor.cpp#L57-L68

I missed this on my first pass, but this is somewhat worrisome to me. If this somehow gets set to high, and the imu is not powering on, you would just have to guess that its the fault being on. This is probably fine because its not being signalled in automation, but still not ideal.

Seems like if we go this route, we should be confident that GS works as neither side (serialization or deserialization) have changed and both are hardcoded
https://github.com/Alpha-CubeSat/Alpha-Cubesat-Ground-Python/blob/main/cubesat-backend/telemetry/telemetry_constants.py#L23-L32

Also concur that we should consider turning off if already on, however if we decide to do this, we should verify that turning off mid collection does not have any negative side effects (on future use of the imu, on IMU Report Monitor, etc.)

[dhacks541]

Regarding turning the IMU off in addition to preventing it turning on, I agree with both comments about the testing requirements and operational benefit. I should have made it more clear in the PR description, but the primary use case for this functionality is indeed powering off the IMU actively rather than just turning it on - this is done by triggering this fault and SFR overriding the existing sfr::imu::power_setting field to off. In flight software currently, the IMU powers on at the beginning of boot and then is permanently on, unless the sfr power setting is overridden by uplink. However this will then be overridden as soon as a mission mode switch occurs, hence the PR.

With that being said, I agree that it would be nice to have one (potentially sfr) field handle both the power off and prevention of power on. However, I decided to implement it this way to produce the lowest possible risk (no automated signaling of the disable fault, while the sfr::imu::power_setting remains unable to be set to off any way except via SFR override - basically redundant protection of normal IMU operation), at the slight expense of what would have been considered clean code during flight software development. This relates to Duncan's normal report point. I agree that having a fault not included in the normal report is not really great practice, however I think any risk it poses (which should be 0 if we assume the Teensy isn't going to flip the fault and command sfr::imu::power_setting = off on its own) is outweighed by the risk of 1) missing a bug in a last-minute-modified normal report or 2) deciding the change is too risky if implemented 'cleanly' and flying without it — Josh has recently become worried that our on-orbit solar performance has a chance of being significantly worse than expected due to a variety of factors, hence the desire for a true low power mode.

To expand on the testing that has been done to date, all testing has involved actively powering off the IMU when it already on, and verifying normal restart as well as downlinking of IMU reports post-deployment. For the most recent tests, this was done with all the relevant commands coming from the GS.

Let me know if this addresses your concerns and you guys feel we are good to merge. Appreciate the close look on this!