Sensor: Refactor sensor.c

[ETSells]

**Requester: @Aaryan-Anand **

(Non-developer requests only): Is your feature request related to a problem? Please describe.
Sensor is, quite frankly, a nightmare. We have code from like 6 different hardware platforms that we're trying to support in this one file via common APIs and I don't think that's the move anymore.

Describe the solution you'd like
I want to remove the following entirely:

• Code in Liquid Engine Controller Rev 4 pound defines
• Code in FC Lite pound defines
• Code in FC Rev 1 pound defines (if any)
• Code in VC Rev 2 pound defines (if any)

The remaining code should be exclusively Flight Computer and Engine Controller related.

We can then split the file into multiple components. Consider:

• sensor.c housing common/shared code like the sensor terminal command handler (sensor_cmd_execute), sensor dump, and sensor poll
• sensor_flight.c housing flight computer specific sensor functions (FC-specific statics can get moved here and defined in either a new header or conditional define blocks in sensor.h).

The above is only a guideline, and you don't have to follow it.

When working this ticket, please keep the following priorities in mind:

1. We only want to separate, not duplicate. Maintenance of duplicate code sucks (ask me and Nick last year)
2. As a refactor, we should have no new functional changes as part of this ticket. We'll want to test on flight, engine, and valve due to the fact that this module is critical to all platforms. If you have additional functional changes, please do so in a separate commit and provide the hash of the refactor so we can test and review the additional change separately.

Describe alternatives you've considered
N/A

Additional context
Pinging @niekky for awareness due to common library changes. Nick will likely need to be tagged on the PR when it's ready so he can verify liquids compatibility. If you have any concerns, please let me know before we hit sprint planning tomorrow.

I was going to do this myself after the upcoming release, but it's a request of Aaryan that he kinda just wants to do this weekend.

Points of Contact
Liquids maintainter: @niekky
Sensor SME: @ETSells

[niekky]

Yeah this is a very good start.

But ooc, what happens if flight firmware scales up and you end up having e.g 5 more versions? (Same thing with liquids)

[niekky]

I'd suggest and introduce a new layer between mod and app and handle high level logics so theyre not tightly coupled to ll mods and easy to scale up im the future.

[ETSells]

That's planned actually, i was waiting to do all of this until after release but I want to move drivers out to a new layer now that mod is getting kinda huge. plan would be unified interfaces in mod and a driver layer that's more platform dependent. kinda similar to what colton ended up doing for his full feature fc.

[ETSells]

sensor's getting accelerated by aaryan's request, but the rest of it is still planned.

[niekky]

I wouldn't rush it if it's temporal. Think of the amount of quality assurance effort afterwards.

[ETSells]

SQA is always at the front of my mind lol. i'm happy to take the verification burden for flight, I think I can swing it (and if not, it's an easy reversion). My concern is adding too much strain on liquids since I know you've got less manpower rn.

[niekky]

It's fine with me. But think twice since if you do this and also do refactoring again in the future, I think it's not worth the efforts and resources.

[ETSells]

I really don't want to do it all right now, it's too close to introduce that much risk. But Aaryan isn't comfortable working #96/#101 with a spaghetti-coded sensor.c, so this at least needs to get done. I guess we could do it all on a staging branch? like postpone state estimation updates to a v2.6.x or a v2.7.0 so we minimize the risk of defects from this in 2.6.0?