constant updates, imu/temp logic changes

[dhacks541]

Final Flight Code Updates

This PR contains final changes to the flight code before final upload. It mainly consists of adjustments to constant values, bypassing of the EKF for ACS, and a few logic changes based on concerns/issues in potential behavior identified in a code review over the last week.

Summary of changes

From most to least trivial:

• Adjustment of various IMU and current constants
• Correction of magnetorquer initial pin states from HIGH to LOW in both sfr and Pins (significant waste of power)
• Adjustment of various default SFR values, particularly Boot/Detumble mission mode durations and burnwire parameters. Boot has been shortened per Josh and Detumble has been eliminated in practice by selecting a very short max_time - reasoning being that autonomously entering an extended period of continuous ACS control with no prior knowledge of our algorithm's success has been deemed unnecessarily risky (in addition to power budget hit). If we see that ACS seems to be working, we will uplink an SFR override to lengthen DetumbleSpin for post-deployment operations. Burnwire timing has been updated to reflect results of EDU and flight unit testing.
• in_sun logic has been modified to require both temperature and solar current thresholds to be reached if both are valid, rather than giving temperature priority. As previously written, we would have a ~50% of deploying in darkness since maximum internal temperature is theoretically reached at the beginning of each orbit's eclipse.
• EKF has been bypassed to feed raw values into ACS algorithm, per Josh + Peck. ACS development continued over the past semester but did not ultimately reach flight readiness, and removing the EKF was studied in parallel as an alternative to the current ACS, which had been identified to be potentially risky. EKF is still initialized, but no sensor data is passed to it, it is never stepped, and raw values are added to sfr buffers instead of EKF outputs.
• temperature::in_sun_val moved from constants to SFR, and its default value is changed from 30C to 23C. The same NR dilemma occurs as with the camera delay, except that this value is unfortunately much more critical to mission success, as well as much more likely to cause issues if left in constants. Josh recently reviewed data that suggests that we likely will never reach 30C, so the value was lowered to 23C (ideally, minimum temp to ensure proper nitinol behavior). However due to the central location of the temperature sensor, it is significantly insulated from the vacuum and the light sail is a source of delayed heat conduction, meaning that in the worst-case scenario, we only barely reach our in_sun threshold and only do so in darkness. Since we have a very poor understanding of what our actual thermal dynamics will be on orbit, it is a strong desire of Josh's to have this value part of SFR so that it can be changed via uplink. Unfortunately this change did not come up until the last couple of days and did not permit the normal report to be modified and properly tested to include it. In this context, we have the same risk/reward analysis as in the previous PR, but I think with slightly higher risk due to the value's importance and much greater reward. Since we would still be able to verify any changes via the command log and this change offers significant operational benefit, I believe it is justified as written, but we particularly want your feedback on this one. If necessary, this can be reverted back to a constant if necessary (but perhaps a quick conversation between Lauren/Duncan and Josh would be helpful if this is the case).

Testing

• All changes have been tested together via a 48-hour nominal test on the flatsat with GS in the loop, with all relevant functionality verified.

Individual feature changes of note tested as follows:

• Burnwire changes determined and verified via multiple EDU and flight unit tests, with values selected to reduce the probability of burnwire failure
• EKF removal tested via nominal test on flatsat in addition to extensive ACS testing by Josh over the last week
• Deployment using SFR version of in_sun_val verified via nominal test
• Change of exit_in_sun logic verified by satisfying temperature but not current requirement, then observing successful transition to Boot Sensors after current threshold reached.

SFR Changes

• temperature::in_sun_val moved from constants.cpp to sfr.cpp. sfr eeprom constant value updated.

[JUmanskyCastro]

All changes look good to me. Thanks Damian!

[Duncan-McD]

Looks good! verification evidence is solid

Concur that adding to sfr and avoiding NR is the correct move here - And not too worried on EEPROM impact as this is still below the SFR size we've previously tested with