Implement MIDAS FSM V2 Specification & Improved MIDAS Interface & Meta Logging fix & Log Error Detection & Logging Improvements & Log Introspection & Feather duo updates & Pyro I2C bus contention fixes & ADC fixes & GPS update rate changes & HITL & More..

[mpkarpov-ui]

This PR does a lot of things and touches a lot of files, so let's break it down 👯‍♂️

1. This pull request implements the MIDAS V2 FSM spec, written to improve the parity between MIDAS and many other commercial altimeters. The altimeter of choice for comparison was the Altus Metrum TeleMega.
   • One large part of this change is the introduction of a programmable-at-runtime FSM system, which allows us to reprogram FSM parameters based by communicating over the MIDAS shell interface (3). As a result of the potential gravity of these changes, we have implemented more stringent FV (Formal Verification) controls on system changes as outlined in the spec document.
2. As a consequence of (1), and in order to improve our team's testing & formal verification capability, we have implemented a new fsm_test build target, which allows for the simulation of MIDAS's FSM and pyro capability in a SIL environment, allowing for better FV of FSM functionality.
   • This tool is now invoked in CI checks of all branches with this code present, and we should do our best to add tests to this system. At the moment, 6 tests are introduced, including launch data from Aether II (6/25), Cassie (3/26), and Sawa III (3/26).
3. A new shell-like tool has been added for communication between human operators and computers interfacing with MIDAS over the USB interface.
   • The current tool ships basic shell functionality and commands to program and configure the FSM, as mentioned in (1).
4. In order to better be able to understand the situations that our vehicle undergoes, as well as to improve the speed at which relevant data can be offloaded off of the flight computer, we have implemented a "meta logging" feature, which allows for offloading summary data almost instantly
5. The meta logging system also handles storing EEPROM data, as well as the format for the logging data.
6. The feather duo firmware has been updated to reflect the changes above.
   • Including adding information about any errors about EEPROM and logging failures
7. Sunday, 5/3 saw an inadvertent pyro event due to some I2C bus contention
8. The ADC register spillover issue ADC Causes I2C Bus Contention #213 has been fixed
9. The GPS update speed has been increased
10. And this PR adds HITL again. Wow!

Formal verification steps follow...

[github-actions]

FSM SILSIM: 6/6 passed ✓ — plots

[mpkarpov-ui]

Adding @divijgarg for approval on GNC file changes -- which involve updating files for parity with the updated FSM states.

[mpkarpov-ui]

Interpretation of FSM SILSIM Results

aether_nofire

The aether_nofire test is simple and ensures that no pyro events occur if the board is not in a flight state. This is done by setting the state to SAFE and feeding in flight data.

Result: PASS ✅

cassie_nofire

Identical to the aether_nofire test, but on more recent vehicle data

Result: PASS ✅

cassie_nominal

Runs the updated FSM on the Cassie flight data, and ensures that pyros configured for this flight fire at the right times, and no extraneous transitions occur.

Result: PASS ✅

sawa3_nominal

Runs functionally the same test as cassie_nominal but on Sawa III flight data and pyro values configured for that flight.

Result: PASS ✅

aether_nominal_sus

Another nominal test like sawa3_nominal and cassie_nominal, but this time on high-altitude, 2-stage data.
⚠️ NOTE: The landing state isn't properly configured in this example, and as such it's currently excluded from testing. As LANDED is not a valid pyro state, this should be acceptable.

Result: PASS ✅

aether_offnom_boo

This test runs Aether II booster data, which experienced an in-flight avionics failure on ascent. This test checks whether the FSM performs predictably under the same conditions by configuring pyro events to fire as they would on the booster, and ensuring that state transitions occur where expected (and do not trigger early pyros as the TeleMega did in that flight).

Result: PASS ✅

[tjmcmanamen38]

This is the greatest PR of all time

[mpkarpov-ui]

We were so preoccupied with whether we could, we forgot to stop and think whether we should... 😢

[MuhammadAli8209]

Note for myself: Looks like u are using shell for IDENT response, I'll have to update Base to figure out some way to be able to send shell command without being connected first. WOWZERS! HOORAY! AMAZING! WHAT A LOVELY WOW!
Instead of previous ARK, BRK commands, we are using serial no. and the command to make sure it goes to that specific MIDAS.

[MuhammadAli8209]

Difference between a desired serial vs serial? From google: Real frequency -> generated by the hardware. Desired vs real helps understand any frequency shifts and how to calibrate them.

[MuhammadAli8209]

How to work with eeprom, files look about right.

[MuhammadAli8209]

I see that you have shifted the frequencies into the eeprom and put the serial no. in there too.

[MuhammadAli8209]

What does this file do?

[MuhammadAli8209]

I see that you are reducing i2c crowding by comparing the new and old states -> optimization. Constexpr for gpio address means straight access to the address we need for changes.

[MuhammadAli8209]

Shouldn’t we reset current_motor to 0 on armed? Bc what if it has a false detection? Hmm i think you only increment the motor increment only when you are done with the lock in period. Makes sense so i guess we dont have to worry abt the motor increment as you only increment after false check, I genuinely cannot find anything wrong but I may have missed something. FSM states do seem to work + the graphs are evidence.I want to learn how to do both the hitl and silsim tests cus why not askhfaljgkhawlgjkn

[MuhammadAli8209]

Where all the time go?

[MuhammadAli8209]

What it do

[MuhammadAli8209]

In all seriousness, after reviewing the PR, this is what I can make out. Everything the PR description says is true. I've put a summary of my comments below. The new FSM revamp appears to be functioning as intended. The system now supports configurable channels and thresholds via the shell interface, and has been validated against past launch data. Thomas's video 1 and video 2 demonstration confirms correct behavior following the fixes associated with the 5/3 event.

Confirmed working:
Channel/threshold configuration via shell
Motor count logic --> current_motor reflects confirmed burns only. Any false triggers that don't survive the lockin window do not increment the counter, and lockin windows transition correctly between stages.
Logging improvements appear functional pending full extraction validation (Michael might have already done this)
I2C bus contention resolved via mutex (semaphore locking on the i2c bus) Related to 5/3 event.
HILSIM and SILSIM reintroduced, demonstrated by Thomas
Hardware testing conducted and verified by Thomas and Michael

My uncertainties:
Motor count behavior on untrimmed flight data running on MIDAS hardware (To confirm multistage burn count).
Data extraction workflow for the new .bin format (replacing .launch). Should not be too bad (Michael probably locked in on this)

Next steps:
Run full flight data (power-on through landing) through SILSIM to validate end-to-end behavior on untrimmed data.

Note: In terms of software, these guys pretty much knocked it out the park, I dont think there is anything else we might NEED to do before launch. Ofc