Add a shutdown command & state to the picubed

[lc0001coll]

Added a new shutdown command that, when received 3 times consecutively, puts the satellite into a shutdown state, where it doesn't respond to communications or transmit any signals. After 3 months in shutdown, the satellite will automatically exit the shutdown state and go back to the regular running state.

[github-actions]

Cpp-linter Review

Used clang-format v20.1.2

Click here for the full clang-format patch

diff --git a/src/states/shutdown/shutdown_state.c b/src/states/shutdown/shutdown_state.c
index b360e48..8acdcf5 100644
--- a/src/states/shutdown/shutdown_state.c
+++ b/src/states/shutdown/shutdown_state.c
@@ -25,6 +25,5 @@ state_id_t shutdown_get_next_state(slate_t *slate)
-sched_state_t shutdown_state = {
-    .name = "shutdown",
-    .id = STATE_SHUTDOWN,
-    .num_tasks = 1,
-    .task_list = {&watchdog_task},
-    .get_next_state = &shutdown_get_next_state};
+sched_state_t shutdown_state = {.name = "shutdown",
+                                .id = STATE_SHUTDOWN,
+                                .num_tasks = 1,
+                                .task_list = {&watchdog_task},
+                                .get_next_state = &shutdown_get_next_state};

Have any feedback or feature suggestions? Share it here.

[github-actions]

Cpp-linter Review

Used clang-format v20.1.2

Click here for the full clang-format patch

diff --git a/src/states/shutdown/shutdown_state.c b/src/states/shutdown/shutdown_state.c
index b360e48..8acdcf5 100644
--- a/src/states/shutdown/shutdown_state.c
+++ b/src/states/shutdown/shutdown_state.c
@@ -25,6 +25,5 @@ state_id_t shutdown_get_next_state(slate_t *slate)
-sched_state_t shutdown_state = {
-    .name = "shutdown",
-    .id = STATE_SHUTDOWN,
-    .num_tasks = 1,
-    .task_list = {&watchdog_task},
-    .get_next_state = &shutdown_get_next_state};
+sched_state_t shutdown_state = {.name = "shutdown",
+                                .id = STATE_SHUTDOWN,
+                                .num_tasks = 1,
+                                .task_list = {&watchdog_task},
+                                .get_next_state = &shutdown_get_next_state};

Have any feedback or feature suggestions? Share it here.

[megargayu]

LGTM except for the two questions below--lmk if they make sense.

Also I thought shutdown meant like a completely system shutdown (i,e. no code running)? I think I am misunderstanding what shutdown means...

[megargayu]

On FLIGHT, STATE_INIT will do burn wire. Presumably if we were able to get to shutdown state, wouldn't we have already done initialization & burn wire? Should we be moving to e.g. STATE_RUNNING?

[lc0001coll]

Good point, will look into this, but I think you're right.

[megargayu]

If we shut down, wait 3 months, and then it goes back to running (or init -> burn wire -> running), then wouldn't this go back?
a) Is that desirable behavior (infinite shutdown loop)? And if so:
b) Why did we pick 3 months before it just loops back? Is it just an arbitrary number?

[lc0001coll]

The shutdown_triggered flag is set to false before the shutdown state returns the state to go back to after 3 months, so after 3 months, it'll run like normal again. In terms of why it's a 3 month timer, this was mostly out of suggestion from Yiheng when I was working on it. I'll go ahead and ping him if there's a specific reason for this timing that I might be forgetting.

[megargayu]

Update: 3 months doesn't matter, anything will work. We need to be able to get back into the codebase, see comment below.

[megargayu]

To update this PR based on talks:

• "Shutdown" legally just means that we need to have total communication blackout (no in or out packets). This state must be persistent over reboots.
• We can reactivate with ground authorization, but otherwise, there should be NO WAY to reactivate.
  (Specifically, FCC 47 CFR §97.113(a)(4)).

Therefore, this PR will work as it is. However, two things I think should be implemented:

1. We should add a way to get out of the shutdown state. This means checking for packets once in a while and only doing something on a specific one - otherwise, MAKE SURE to not send anything or perform any action!
2. I think it will be beneficial to investigate if we can move into a "low power state" or have a more efficient shutdown, as our current way of doing things will require a lot of unnecessary power draw/wear and tear on systems. Maybe if there is timer functionality on this low power state, move it to low power only for a bit before coming back on to check telemetry?

Note: This would also help solve #87.