From 0dacc4e23241d23a6f07ae7734f34f0d88139c11 Mon Sep 17 00:00:00 2001 From: dario Date: Sun, 1 Dec 2024 15:25:07 +0100 Subject: [PATCH] Fixed important typo --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 29c757b..28fc05c 100644 --- a/README.md +++ b/README.md @@ -255,7 +255,7 @@ The statemachine forms the heart and soul of a TACOS-based project. Upon initial 1. All threads that should run in state $ y $ but are not currently running are started. 2. All threads that should not run in state $ y $ but are currently running are stopped. > [!IMPORTANT] -> The statemachine does immediately stop a thread and deletes it from memory. Instead, the thread is allowed to finish the current execution of its `func` before entering a blocked state. This allows the thread to release all its resources. +> The statemachine does not immediately stop a thread and deletes it from memory. Instead, the thread is allowed to finish the current execution of its `func` before entering a blocked state. This allows the thread to release all its resources. In order to fully understand the statemachine, we have to take a look at the _lockout_ and _failsafe timer_. These lockout and failsafe timers are the result of design choices made during early stages of STAHR. The goal was to combine the state estimation (i.e. sensor fusion using a Kalman filter) with timer-based safety mechanisms. For example, our goal was to block any state transition to the state `DROGUE` before 60 seconds after liftoff. Additionally, a timer was started to automatically switch to state `DROGUE` after 120 seconds after liftoff.