# Ascent R2 Flight Firmware

This repository contains the flight software for the Ascent R2 flight computer. The firmware executes the flight state machine, performs sensor fusion and filtering, manages power and health monitoring, controls pyrotechnic events with safety interlocks, and provides real-time telemetry and logging.

Hardware

• Sensors

  • BNO055 9-DOF IMU
  • BMP390L Barometric Pressure Sensor
  • H3LIS331DL High-G Accelerometer
  • SAM-M10Q GNSS Module

• Storage

  • W25Q512JV Flash Memory

• Communication

  • RFM95W LoRa SX1276 Radio Module

• Safety Systems

  • Power based system Hard Arming
  • Pyrotechnic channels
  • Continuity verification

Ascent R2 Flight Computer - Top View	Ascent R2 Flight Computer - Bottom View

Ascent R2 Flight Computer - 3D Render

Ascent R2 Flight Computer - Component Layout

Features

1. Flight State Machine

   • Pre-launch, boost, ascent, coast, apogee detect, drogue/main deploy, descent, landing
   • Redundant event logic and configurable failsafes

2. Sensor Fusion and Filtering

   • Orientation estimation, altitude/velocity estimation, and smoothing
   • Sensor health checks and outlier rejection

3. Telemetry and Ground Link

   • Real-time downlink of state, altitude and position metrics
   • Uplink hooks for arming and mode control (if enabled)

4. Pyrotechnic Control with Interlocks

   • Continuity checks and safety gating for all firing events
   • Configurable arming and inhibit logic

5. Power and Health Monitoring

   • Supply rail monitoring and brownout protection
   • System heartbeat via LEDs/buzzer

6. Data Logging

   • Flight events and key telemetry suitable for post-flight analysis

Build and Flash (PlatformIO + ESP-IDF)

This project targets the ESP32-S3 (esp32-s3-devkitc-1) and uses PlatformIO with the ESP-IDF framework.

1. Install VS Code and the PlatformIO extension
2. Open this folder in VS Code
3. Select the environment esp32-s3-devkitc-1
4. Connect the board over USB and select the correct serial port
5. Build and upload:
   • Build: PlatformIO: Build
   • Flash: PlatformIO: Upload
   • Monitor: PlatformIO: Monitor (default 921600 baud)

Configuration defaults are defined in platformio.ini and sdkconfig* files.

Configuration

• Flight parameters: src/fsm/flight_config.h
• System-wide globals: src/globals.h / src/globals.c
• ESP-IDF configuration: sdkconfig, sdkconfig.esp32-s3-devkitc-1

Simulation / SITL

For bench testing, the firmware supports serial-driven test inputs.

• CSV flight profiles and a helper script are in sitl/
• Example: stream a profile to the board using the provided Python script

Directory Structure

• /src – Flight application sources
  • ble/ - "Bluetooth Low Energy"; related to Bluetooth connection of telemetry data to phone application
  • fsm/ - "Flight State Machine"; How the board should behave and what it controls during different parts of the flight
  • memory/ - Contains Flash and NVS code for storing flight configs and flight data
  • radio/ - Utilizes GOOBER protocol with LORA for telemetry
  • sensor/ - Sensor management, fusion, filtering
  • sitl/ - System in the Loop; Serial utilities for test/simulation
  • main.c – Entry point; Calls the features from the other folders and drivers
  • globals.c, globals.h – System-wide state
  • CMakeLists.txt – Project CMake (used by tooling)
• /docs – Images and documentation assets
• /sitl – CSV profiles and host-side helpers (e.g., send_flight_data_to_serial.py)
• /platformio.ini – Build, upload, and monitor configuration
• /sdkconfig* – ESP-IDF configuration files

Note: the driver library submodule is managed separately and is not listed here.

Development

This project is built using:

• ESP-IDF framework via PlatformIO
• Custom drivers and libraries for sensors, radio, storage, and I/O

Contributions should favor clarity and safety, with changes tested on both bench and flight-like profiles before integration.

Etiquette

While developing this project, it is intended to be understandable to new members during onboarding, while also acting as an example for future members. In order to ensure the readability of this project, this repository implements the following etiquette rules

Cloud Etiquette

• Create Issues on Github for EVERY branch
  • Each issue name should be 2-3 words
  • Add a description of what the branch should accomplish
  • 'Assignees': used to indicate who is working on what
  • 'Labels': used to organize issues, add as necessary
  • Link the branch to the issue
• Create Pull Requests (PRs) to merge branches into main or Dev
  • PRs should be reviewed by 2 veterans members with at least 4 prior major PR
  • Reviewers should look over all change files
    • Best if done with the requester
  • If PR is good; reviewers should approve with an LGTM
    • Only requester should merge the branch
  • If there is an issue with the PR, reviewers should leave comment with description of issue
  • After a PR, the requester should message the programming team to pull new changes
• There should be matching Issue, Branch, PR trios unless an issue is labeled "won't-fix" or "duplicate" and closed

Branch Etiquette

• Branch Names:
  • main:
  • Flight ready code
  • ONLY receives pushes from Dev
    • Good practice is to have flown "Dev" at least once before merging to main
  • Do NOT make branches off of main
• Dev:
  • Used for full systems tests
  • Only push to main after tested and cleaned
    • No hardcoded values, add them to Constants
    • Explanatory comments
    • Code is fully functional
  • Make ALL branches off of this branch!!
• feat#[Issue#]-[name]:
  • Used for new features on the robot
  • Used for code changes
    • Changes can be as small or big as necessary
    • Only contains what the branch is named
      • Ex: No radio code in a memory related branch
  • Branch name is camel cased
    • Ex: feat#42-CompressGooberPackets
  • Push to Dev when code is tested and clean (see "Dev" for "tested and clean" standards)

bugfix#[Issue#]-[name]:

• Used for bug-fixing a feature from Dev
• Branch name is camel cased
  • Ex: bugfix#27-100Hz

chore#[Issue#]-[name]:

• Used for cleaning code from Dev
• Branch name is camel cased
  • Ex: chore#34-AddingComments

Code Etiquette

• Values should avoid being hardcoded; instead they should be ENUMs in a related .h file
• Variable containing static values should be fully uppercased with underscores separating the words: PYRO_CHANNEL_1
• Comments on everything describing functionalities, parameters, and returns
• Keep related files in related folders; Create new folders for new topics