Faults base class

[tanishqaggarwal]

Adds a fault class to the flight software. This fault class has persistence, so an error needs to be signaled multiple times before the fault is set.

I'm still looking for good, non-confusing names for these fault functions. Let me know if you have any good ideas.

It'd be great if everyone can review this before the merge, since this is so core to the infrastructure

[shihaocao]

I think this PR is very good, just a comment and a request.

A comment: If we're overriding or suppressing the fault, we can still accumulate num_consecutive_faults which may have unintended consequences when we turn off the suppression or override. Just wanted to make this behavior clear.

Also, I feel like there needs to be a way to command an unsiginal() from the ground. If we're not doing any kind of autonomous fault response, I think this is a necessary reset functionality. Perhaps through a writeable state field that is automatically set back to false?

[tanishqaggarwal]

A comment: If we're overriding or suppressing the fault, we can still accumulate num_consecutive_faults which may have unintended consequences when we turn off the suppression or override. Just wanted to make this behavior clear.

Good point. I'll make the following change: when overriding or suppressing, num_consecutive_faults is set to zero. This will prevent any unwanted autonomous response that occurs when the ground commands are turned off.

Also, I feel like there needs to be a way to command an unsiginal() from the ground. If we're not doing any kind of autonomous fault response, I think this is a necessary reset functionality. Perhaps through a writeable state field that is automatically set back to false?

Right now, signal and unsignal are an interface for autonomous behavior, and override and suppress are the interface for manual behavior. Do you see circumstances where we would want to call unsignal instead of just setting suppress?

[shihaocao]

Right now, signal and unsignal are an interface for autonomous behavior, and override and suppress are the interface for manual behavior. Do you see circumstances where we would want to call unsignal instead of just setting suppress?

I'm thinking of the following case:

1. A fault flag becomes tripped.
2. On the ground, we deduce what caused it, and also realize a set of commands to upload to prevent it from occurring in the future.
3. We upload those commands, and merely ask the satellite to unsignal(), that way if somehow if it happens again, we can be notified.

Or slightly differently:

1. A fault flag becomes tripped.
2. We deduce what caused it, and realized there's nothing we can do to prevent it from being tripped again (say it'll happen every few days), but there is a set of commands to properly recover from it.
3. We upload the recovery commands, as well as the unsignal() command so that the satellite can continue to function until the fault condition occurs again (and still protect itself from the fault).

[shihaocao]

We'll go back and talk about nuanced fault response later. Details to come in an issue, and hopefully resolved in a future PR.

[tanishqaggarwal]

@fatimayousuf I thought it would be a good idea to exclude EEPROM from the desktop unit testing, since it requires a Teensy to actually test the EEPROM.

I'm curious, how does the test still happen to work on the desktop?

[fatimayousuf]

The test asserts in the test file are protected with #ifndef Desktop macros, so the test should work on a desktop

[fatimayousuf]

The test asserts in the test file are protected with #ifndef Desktop macros, so the test should work on a desktop