The Artemis Launch Simulator is a dual-microcontroller embedded system that simulates a rocket launch sequence and deployment. It consists of two main stations communicating in real-time: a launch Pad (which monitors structural vibrations) and a control station (featuring an OLED telemetry display and countdown timers). The climax of the system is the release of a miniature spring-loaded rocket. Inside the rocket, an ultra-lightweight ESP32 uses a barometric altimeter to detect its highest point in the air.

The primary purpose is to demonstrate a fault-tolerant, highly interactive embedded system. It showcases how multiple hardware communication protocols (I2C, SPI, PWM, ADC) and software concepts (interrupts, non-blocking timers, and TinyML) must work together to execute a complex physical operation. It serves as a proof-of-concept for handling sensor data, user inputs, and physical actuation simultaneously without system failure.

The project was deeply inspired by NASA's Artemis missions and the immense engineering complexity behind modern spaceflight. At the same time, I wanted to create a project that's interactive and fun to repeatedly play around with.

This project acts as an engaging, highly interactive educational showcase. By allowing users to interact with a physical console, to press buttons or to watch the telemetry react to the rocket reaching higher altitudes, it explains complex aerospace engineering concepts with simple components.

The launch will proceed as follows: Once the arming switch is toggled, a button can be pressed that will begin the countdown to launch. Until reaching 0, the vibration motor will simulate the starting of the engines and, if the accelerometer detects anomalous vibrations (such as vibrations that are too strong), the launching will be terminated. When the countdown reaches 0, the servo motor releases a tightly-packed spring that launches the rocket. At this moment, the ESP32-C3 receives a signal from the main ESP32 to begin measuring its altitude, and this data is sent back and displayed at the platform.

schematic_v2.pdf

Components:

The firmware for both the Base Station (Launch Controller) and the Rocket Payload (Flight Computer) is developed using PlatformIO running on the Arduino framework. This environment was chosen because it easily manages cross-architecture compilation. PlatformIO’s platformio.ini configuration files allow for strict library dependency tracking and custom build flags (such as enabling hardware USB CDC on the C3 chip) without manual makefiles.

To ensure high-performance hardware interfacing and non-blocking execution, the following libraries are utilized:

• Adafruit_MPU6050 & Adafruit_BMP280: Core sensor drivers. Used to retrieve high-resolution 6-axis acceleration/gyro data and barometric pressure over the I2C bus (Wire.h).
• Adafruit_GFX & Adafruit_ST7789: Handles the low-level SPI communication with the Base Station's IPS LCD. Provides primitive drawing functions and hardware-accelerated screen fills.
• ESP32Servo: Replaces the standard Arduino servo library to utilize the ESP32's internal hardware PWM timers, ensuring the launch mechanism actuates without interrupting radio communications.
• BLEDevice, BLEServer, & BLEUtils: The native Espressif Bluetooth Low Energy stack. Used to bypass legacy 2.4GHz Wi-Fi issues and establish an ironclad, aerospace-grade data tether between the two microcontrollers.

The mission logic is governed by a synchronized FSM distributed across both microcontrollers. The Base Station operates in strictly defined states: SCANNING (-1), HOLD (0), COUNTDOWN (1), FLIGHT (2), and ABORT (3). The loop() function routes CPU execution strictly based on the current state, ensuring graphical LCD updates or servo actuations only occur exactly when physics dictate they should.

To prevent the vibration of the haptic motor (eccentric rotating mass) from accidentally triggering a launch pad abort, the MPU6050 data is passed through an EMA filter.

• Algorithm: smoothedForce = (EMA_ALPHA * rawForce) + ((1.0 - EMA_ALPHA) * smoothedForce)

This Infinite Impulse Response (IIR) filter ignores high-frequency motor jitter while remaining highly sensitive to massive, low-frequency forces (e.g., the launch pad being tipped over).

Because barometric pressure changes with local weather, the payload cannot use a static sea-level baseline.

• Algorithm: While in the “Standby” state, the payload continuously overwrites a launchPadPressure float variable with the current ambient pressure. The exact millisecond the “ARM” command is received via BLE, this variable is locked. The BMP280 uses this locked baseline to calculate and transmit true AGL (Above Ground Level) relative altitude.

To avoid blocking the main execution loop with delay() or active waiting, the radio stack relies on hardware interrupts. When the Payload calculates a new altitude, it pushes a 4-byte float array. On the Base Station, a notifyCallback instantly decodes this byte array back into a float and updates the screen asynchronously, resulting in zero telemetry lag.

Below are the core functions that drive the hardware and the mission logic: