https://github.com/issuiuc/tars-software
Illinois Space Society's flight software codebase for the TARS avionics system
https://github.com/issuiuc/tars-software
avionics control-systems data-acquisition embedded rocketry sensor-fusion simulation telemetry
Last synced: 4 months ago
JSON representation
Illinois Space Society's flight software codebase for the TARS avionics system
- Host: GitHub
- URL: https://github.com/issuiuc/tars-software
- Owner: ISSUIUC
- Created: 2020-08-29T11:50:00.000Z (almost 6 years ago)
- Default Branch: master
- Last Pushed: 2023-09-24T19:04:40.000Z (over 2 years ago)
- Last Synced: 2023-09-25T04:10:25.248Z (over 2 years ago)
- Topics: avionics, control-systems, data-acquisition, embedded, rocketry, sensor-fusion, simulation, telemetry
- Language: C++
- Homepage: https://issuiuc.github.io/flightcode-docs/classes.html
- Size: 58.6 MB
- Stars: 14
- Watchers: 5
- Forks: 4
- Open Issues: 11
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
README
# 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 `` 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:
- `` for small and simple contributions pertaining to a ticket
- `user//` for individual tasks or contributions, or as a sandbox for yourself
- `feature/` for **new** functionality that didn't exist before
- `bug/` for bug fixes
- `general/` for overall repository organization or development pipeline tweaks
- `misc/` or `junk/` 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/-`
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!