issuiuc / tars-software Goto Github PK

View Code? Open in Web Editor NEW

17.0 5.0 4.0 60.08 MB

Illinois Space Society's flight software codebase for the TARS avionics system

Home Page: https://issuiuc.github.io/flightcode-docs/classes.html

C++ 92.47% C 5.16% Makefile 0.04% Python 1.93% Processing 0.20% Shell 0.02% Perl 0.19% Batchfile 0.01%

control-systems data-acquisition embedded rocketry sensor-fusion avionics simulation telemetry

tars-software's Introduction

TARS Flight Software Repository

Illinois Space Society's flight software codebase for the TARS system.

Click to see a cool video!

Directory Structure:

TARS/: Mission critical flight software running on TARS. This is the code that actually flies on the rocket
- src/: All the flight code that we write ourselves is in this directory.
  - common/: Utility code we write that is used across microcontrollers.
  - mcu_main/: Code for the primary microcontroller on TARS (Teensy 4.1)
  - mcu_telemetry/: Code for the microcontroller in charge of telemetry and GPS (ESP32-S3)
  - mcu_power: Code for the microcontroller on the power board (ATMega328P)
- lib/: Third-party libraries that are not available on the PlatformIO Registry. Other libraries are included via the lib_deps build flag in platformio.ini
ground/: Code running on ground station hardware (Adafruit LoRa Feather)

Branch Naming Convention

Please use the following naming conventions when creating branches while developing:

Your <branch-name> should consist of the Trello ticket ID and a short description of the work being done. For example:

AV-420-write-cp-location-interpolation-function

Then use the following scheme to then organize your branches:

<branch-name> for small and simple contributions pertaining to a ticket
user/<github-username>/<branch-name> for individual tasks or contributions, or as a sandbox for yourself
feature/<branch-name> for new functionality that didn't exist before
bug/<branch-name> for bug fixes
general/<branch-name> for overall repository organization or development pipeline tweaks
misc/<branch-name> or junk/<branch-name> for just messing around :)

Some fictional examples:
user/AyberkY/improve-lsm9ds1-spi-latency
feature/create-mcu-state-estimation-thread
bug/gps-thread-deadlock-fix
general/create-new-directory-for-gnc
misc/testing-sd-card-bandwidth

Please include the Trello ticket ID when relevant! i.e. for a ticket [AV-69] your branch might look like:

user/AyberkY/AV-69-graceful-failure-for-fifo-buffer or feature/AV-69-create-data-logger-class

Archiving Code Base Revisions

We should try to keep an archive of the version of code that ran on each rocket launch, so that we can associate the data we collected with the code that was running on TARS.

After every launch or major milestone, create branch with the following convention:
archive/<month.day.year>-<milestone-or-launch-description>

For example: archive/09.01.21-start-of-2022-school-year

Code Style Guide

The repository now has a GitHub Actions instance that will automatically check for code style violations!

The Actions instance will not inhibit a pull-request from merging. It is merely there to encourage style consistency throughout our code base.

There is also an auto formatting script that will format your code for you! (its beautiful, you should use it) This means that you don't have to worry about coding to meet the style yourself, as you can simply run the formatting script before you commit/push your changes.

You can run the script on Linux, Mac, or WSL like so:

./run_clang_format.py -i -r .

Things to keep in mind about code formatting:

The code style being used is defined in .clang-format. It currently follows Google's C++ style guide exactly. However, a modification was made so that the maximum characters per line was increased from 80 to 120.
Third party libraries (e.g.ChRt which is ChibiOS) are exempted from code-style checks and the auto formatting script. This is to avoid any possibility of breaking proven/working libraries. If adding a new library to flight code, make sure to update .clang-format-ignore with the relevant file path if it isn't in lib.
- Exempt directories should be listed in .clang-format-ignore so they don't get auto-formatted by the script.
- Exempt directories should also be listed in .github/workflows/clang_format_check.yml on the lines with exclude:, so they're not checked for style violations by GitHub.
Changing/tweaking the style guide is always option! If you have ideas, reach out!

tars-software's People

Contributors

Stargazers

Watchers

Forkers

philipzolf aadityavoru krishan0507 zyunlam

tars-software's Issues

Set up RasPi Pico to start getting comfortable with RP2040 microcontrollers. Verify compatibility with ChibiOS.

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.

Combining FifoBuffer and HistoryBuffer

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.

Create separate mcu folders for Teensy, ESP, Atmega(PMB)

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

HILSIM Crashes after a few seconds after startup

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.

Use Platformio lib_deps instead of manually downloading libraries where possible

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.

FSM Revamp

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

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.
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.
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.
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.

Replace GPS library and rewrite GPS thread to accomodate new MAX-M10S chip

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.

Add profiling to flight code

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:

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

Sensor abstraction layer unused

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)