FSM Step-1

[pattacini]

We started off crafting the Finite State Machine (FSM) using Stateflow so that then we'll be able to generate the corresponding code.

Here's how it looks like as of now:

[pattacini]

Added concurrent FSM for alarms handling.

[pattacini]

I think we need to organize the work on the FSM for (1) states and (2) alarms handling using Stateflow, as I cannot be the only one on this and I'll be certainly busy with the controller, which is my main responsibility. This has to be done quite soon ⌛

Of course, I can tell you how to use Stateflow − it's fairly easy, visual, and intuitive. We can also split this development into sub-tasks.

@maggia80 @simeonedussoni @vtikha @Nicogene any thoughts?

[simeonedussoni]

It seems very important, an FSM or something similar is needed to proceed with the testing. Let's organize a very agile kick off to understand requirements and a little tutorial on stateflow. We should coordinate very well even with the hardware oriented people.

[marcoaccame]

just a quick note on the architecture of the embedded application.

the idea is to run the FSM w/ reading from hw and from output of the controller and to impose actions to hw, right? If so, it is better to run it in the thread which runs the controller.

so far, actions on the tCTRL thread are:

1. read every HW input (sensors and gpios)
2. feed the controller and retrieve actuations
3. apply every HW output.

we could add an action: 2.b. feed the FSM and retrieve its actuations

[simeonedussoni]

Yes @marcoaccame your ansatz is correct, and the porposal to add action 2b is just fine. I'd start to collect all infos about failures/alarms on a dedicated issue since they are spread in issues, teams chat etc.

[pattacini]

Ref. #51.

[simeonedussoni]

@pattacini the work on the FSM is committed to the repo? I would like to start giving a look on it

[pattacini]

Here it is https://github.com/icub-tech-iit/ventilator/tree/code/fsm. This afternoon, we'll meet up about that.

[pattacini]

🧪 TEST mode

I've made some progress on the FSM where now we can also handle the TEST mode. We enter TEST mode by pressing and holding the IDLE button for >= 5 seconds (configurable). When TEST mode is enabled, the IDLE led will blink continuously.

To get back to STD mode, again, idle any ongoing test and press & hold the IDLE button for >= 5 seconds.

Once in TEST mode, we can use the remaining 3 buttons to select 3 different modalities:

• Test 1: apply a sawtooth wave to CP with a given DC peak and period, whereas the CFB is open.
• Test 2: apply a square wave to CFB with CP wide open.
• Test 3: not yet defined.

🗺️ Maps

I've also introduced maps to deal with different settings of the knobs. As of now, there are 2 maps to manage the STD and TEST modes parameters. Further maps useful to tune up low-level options could be added later on and triggered through the multi-selector encoder.

Maps do just contain the minimum and maximum values of the knobs in a particular setting. This way, assuming that a knob will always provide a number in the [0,1] range, we can remap it according to those varying bounds.

• In STD mode, knobs will set BPM (1/min), PIP (smH2O), IE (-), and TD (ml).
• In TEST mode, knobs will set Test1 DC Peak (%), Test1 Period (s), Test 2 Period (s), whereas the last knob is not used yet.

Knobs are always latched only when in IDLE for safety reasons.

🔘 Debouncing

Buttons debouncing is also handled with a timeout of 0.5 s (configurable).

cc @maggia80 @marcoaccame @simeonedussoni @vtikha @Nicogene

[pattacini]

I've renamed this issue into FSM Step-1 to point out that we address here the very first testing stage.

[pattacini]

Added up a further map for dealing with VCV params. Therefore, we have currently 3 maps handled by the MultiSelector:

1. STD: BPM, PIP, IE, TD
2. VCV: Std-P, Std-I, Rec-P, Rec-I
3. TEST: Test1-Peak, Test1-Period, Test2-Period (enabled by default in test mode)

[pattacini]

Maps have been extended in order to comprise also PRVC mode and AutoTrigger:

[pattacini]

FSM Step-1 is completed.