issuiuc / tars-software Goto Github PK

Tasks like SD logging and Telemetry block the thread (and maybe the entirety of flight code, depending on if we turned on cooperative multithreading or not).

This is mostly a bad thing, since there's thing we'd rather our system be doing instead of spending 200 ms at a time logging data.

To address this, we should at some form of profiling to the SDLogger and Telemetry, so we can identify:

1. If they're actually an issue
2. Where the biggest performance impacts happen
3. What we can address to fix this

As of now, we have all of our embedded code in a single MCU (microcontroller) folder. This it totally okay for now (Mk3) because, well, we only have one MCU. However, TARS Mk4 has a teensy for most tasks, an ESP32-S3 for telemetry and GPS, and an Atmega on the power management board (this was on Mk3 too i guess).

We should create separate mcu folders under the flight directory to organize the code for each one

We've created an object-oriented design to handle all our sensors (see HighGSensor.cpp or GPSSensor.cpp etc.). These are completely unused right now in the master branch, but actually using them would create a much cleaner interface in flight code and also be very useful for playback/hardware-in-loop functionality that @GigaVoltFlash @cflynn19 @karnapp2 @rbhog and @NPIPHI have been working on.

So far, @sendhil2 has these working in branch removed-pointer-struct, and this branch is currently being debugged (things are going wel)

The first version of the SRAD altimeter will be using the RP2040 as its MCU. It's something we haven't worked with too much before, so it'll help to start writing some code for it and make sure ChibiOS works well enough. We could even look into FreeRTOS? 👀 . Either way, we bought a Pico so we can write some code before the altimeters themselves are manufactured.

At the moment, our lib folder is full of libraries that are manually added. Though this works, we might as well use the library dependencies functionality that PlatformIO provides. Some minor changes may have been made to some libraries (lke radiohead for telemetry) so those can be left alone.

As of now, the only library we import through pio is pwmservo, we should start doing the same for others.

For a couple years, we've been using the ZOE-M8Q as our GPS module, but TARS Mk4 is getting a bit of an upgrade with the MAX-M10S. It has a different software interface so we'll have to replace the library and change the existing GPS thread to use it.

HILSIM crashes a few seconds after startup.

The error message is:
assertion "index >= 0 && index < size()" failed: file "lib\\Eigen/Eigen/src/Core/DenseCoeffsBase.h", line 427, function: Eigen::DenseCoeffsBase<Derived, 1>::Scalar& Eigen::DenseCoeffsBase<Derived, 1>::operator()(Eigen::Index) [with Derived = Eigen::Matrix<float, 120, 1>; Eigen::DenseCoeffsBase<Derived, 1>::Scalar = float; Eigen::Index = int]

The issue was narrowed down to KF, but it needs further investigation and resolving.

The major difference between FifoBuffer and HistoryBuffer right now is that FifoBuffer has a destructive pop method, which removes items from its buffer, while HistoryBuffer can only be filled and thus may be used to look at recent history. However, using the new FifoView API available in the removed-pointer-struct branch, FifoBuffer will no longer have pop, making it's functionality a superset of HistoryBuffer, obviating the need for the latter.

We should write the code to calculate derivatives for FifoBuffer, which will let us remove HistoryBuffer and simplify the code base.

The FSM from October launch performed decently well, but there are much-needed improvements.

1. Change our overall design so that we no longer assume a perfect flight. We shouldn't only be able to transition to the next state of an ideal flight, we should instead be able to transition to any state from any other state (with limitations) for a more accurate representation of what is actually happening.

2. Add an error state. This is important to let us know when something has gone wrong with the rocket. Additionally, when we stage, this will be useful in determining whether or not to light the second stage.

3. Use a wider variety of sensors (acceleration, altitude, orientation, Kalman filter velocity, etc) for state transitions. Use multiple sensors for each state transition as a way to double-check.

4. Potentially remove buffer usage. During October launch, the acceleration change for drogue and main were distinct enough to just be detected from a single value.