EV Society · Projects
Active Project · Team ID 2026-INSPACe-ROCKETRY-505

AstroForge Model Rocketry Mission Architecture

End-to-end engineering design for the IN-SPACe Model Rocketry India Student Competition 2026: mission requirements, system architecture, telemetry, avionics, recovery, safety, and review readiness — built by AstroForge at SRM Institute of Science and Technology, Trichy.

🎯 Mission · 1000 m ± 100 m 📦 Payload · 1 kg ± 0.05 kg 📋 PDR / CDR / FRR Ready 🛡 Safety First
Team
AstroForge
Competition
IN-SPACe MR 2026
Telemetry
≥ 1 Hz · CSV
Recovery
Parachute · 2–5 m/s
01 · Executive Summary

What AstroForge is building, and why it matters

AstroForge is a student engineering team competing in IN-SPACe's national Model Rocketry competition. The mission: design, build, instrument, launch, and recover a model rocket carrying a 1 kg CAN-7U-class payload to 1000 m ± 100 m — and prove the result with continuous, ground-station-verified telemetry.

Objective

A real launch vehicle, end-to-end

Translate textbook rocketry into a working flight system: airframe, avionics, recovery, ground station, and operations. Every choice traceable from a mission requirement to a verification result.

Learning Outcome

Systems engineering, not just hardware

Practice the full lifecycle: PDR → CDR → FRR → Launch → Post-Flight Analysis. Develop discipline in requirements traceability, risk management, and review-driven engineering.

Approach

Safety-first, organizer-provided motor

Solid motor is procured from IN-SPACe's identified vendors. AstroForge designs around the motor — no propellant chemistry, no pyrotechnics on payload separation, no hazardous payload.

Engineering deliverables

Documents
PDR, CDR, FRR, PFA

Stage-gated reviews with traceability matrix, risk register, and compliance checklists.

Hardware
Rocket + Launchpad

Airframe ≤ 180 cm, fluorescent finish, mechanical motor retention, custom launch rail at 80°–85°.

Avionics
Flight computer + sensors

GNSS (NavIC-capable), barometer, IMU, voltage monitor, redundant SD logging, COTS backup altimeter.

Software
Flight FW + Ground Station

State machine flight FW, real-time UI with live plots, CSV export, USB hand-off post-flight.

02 · Mission Requirements

Baseline mission requirements & compliance plan

Each row maps directly to the IN-SPACe Mission Requirement & Competition Guidelines Document (Doc.No.: IN-SPACe.MR.Model.CG.01, Issue 1). Status is updated through the project lifecycle.

Requirement Area Baseline AstroForge Design Approach Status
Target altitude 1000 m ± 100 m OpenRocket / RasAero simulation tuned to lift-off mass; trajectory margin reserved for wind & motor variance. Planned
Payload mass 1.0 kg ± 0.05 kg CAN-7U-class payload bay with internal mounts; mass budget tracked weekly with calibrated balance. In Progress
Rocket length / mass ≤ 180 cm; ≤ 15 kg (Al) or ≤ 11.5 kg (PVC) Configuration TBD pending material trade study; lift-off mass within ±5% of design value. Planned
Motor Solid motor, organizer-supplied, ≤ 2800 N·s Procured exclusively from IN-SPACe-identified vendors. No in-house propellant or motor work. Mechanical retention. Planned
Avionics Position, altitude, pressure, temp, orientation, power, system state Custom flight computer + COTS backup altimeter on redundant separation chain; environmentally enclosed. In Progress
Telemetry ≥ 1 Hz, ASCII CSV, 16 fields, real-time plots Per Annexure-2 packet format; XBee/LoRa link; onboard SD redundancy; Flight_2026-INSPACe-ROCKETRY-505.csv. Planned
Ground station Laptop + radio + antenna; 2 hr battery; portable Field laptop with custom UI; elevated antenna, zero-set at pad, USB CSV export, tested for 1 km link margin. Planned
Recovery Parachute, descent rate 2–5 m/s ± 0.5 Primary parachute deployed at apogee with mechanical (non-pyro) actuation; descent rate measurable on telemetry. Planned
Documentation PDR, CDR, FRR, PFA Stage-gated reviews with requirements matrix, risk register, BOM, schedule. Editable JSON/Markdown content layer. In Progress
Safety No pyro, no hazardous payload Zero-pyro mechanical separation, organizer-provided motor only, preflight checklist, range-safety brief, Go/No-Go gate. Verified by design
Recovery markings Team ID + contact in English / Hindi / regional language Fluorescent (red/orange/pink) airframe with multilingual recovery labels. Planned
03 · End-to-End Architecture

From mission requirement to final report — one continuous flow

The lifecycle architecture below traces every engineering activity from initial requirements through post-flight analysis. Each stage produces an artifact that feeds the next.

Diagram 1 — Mission Lifecycle Architecture

Sequential flow with feedback loops at each design review.

Mission Requirements
Rocket System Design
Subsystem Design
Simulation
PDR Gate
PDR Gate
Prototype / Procurement
Integration
Ground Testing
CDR Gate
CDR Gate
FRR Inspection
Launch
Telemetry Capture
Recovery
Post-Flight Analysis
Final Report
Tip: The three review gates (PDR, CDR, FRR) are the system's immune response — every requirement, design choice, and test result must pass through them before flight.
04 · Rocket System Architecture

Subsystem map of the AstroForge launch vehicle

Every block is a distinct engineering responsibility with its own design, validation, and review trail.

Diagram 2 — Rocket System Block Diagram

Functional grouping of airframe, avionics, payload, and ground systems.

Airframe & Mechanical
A1
Nose Cone
Aerodynamic cap; tethered, non-pyro release.
A2
Airframe & Structure
PVC or aluminum tube, ≤ 180 cm, fluorescent.
A3
Payload Bay (CAN-7U)
Houses 1 kg payload; mechanical separation.
A4
Avionics Bay
Shielded enclosure, hard-mounted boards.
A5
Motor Mount
Centering rings + thrust plate, M5/M12 fasteners.
A6
Fins & Stability
Trapezoidal fins sized for static margin ≥ 1.5 cal.
A7
Launch Rail / Lug
Interfaces with custom 80°–85° launch pad.
A8
Recovery System
Parachute + tether; mechanical deploy at apogee.
Avionics & Sensing
B1
Flight Computer
Microcontroller running flight FW state machine.
B2
Sensors
Barometer, IMU (accel/gyro), temp, voltage, GNSS.
B3
COTS Backup Altimeter
Independent redundant chain for separation.
B4
Power System
Alkaline / Ni-MH / Li-ion 18650 (no LiPo).
B5
Telemetry Radio
XBee / LoRa link, NETID = team ID.
B6
Onboard Storage
SD card redundant logging during flight.
Ground Segment
C1
Ground Station
Laptop UI, ≥ 2 hr battery, real-time plots.
C2
Antenna & Receiver
Elevated, ≥ 1 km range, link-budgeted.
C3
Data Analysis System
CSV ingest, post-flight plots, anomaly tagging.
C4
Operations & Safety
Checklists, Go/No-Go, range-safety brief.
05 · Subsystem Requirements

Thirteen subsystems, each with purpose, validation, and risk

For each subsystem: Purpose · Inputs · Outputs · Key Decisions · Validation · Risks · Mitigation.

A · Mission & Systems Engineering

System owner of all requirements & traceability

Purpose: Decompose mission goals into subsystem requirements; maintain traceability and review readiness.

Inputs: IN-SPACe guidelines, simulation results, review feedback.

Outputs: Requirements matrix, schedule, BOM, risk register.

Key decisions: Material baseline (PVC vs Al), motor variant selection.

Validation: Review gates (PDR/CDR/FRR), Jury feedback.

Risks → Mitigation: Scope drift → frozen baseline at PDR, change control after CDR.

B · Aerodynamics & Stability

Fly straight, fly stable

Purpose: Achieve static stability margin ≥ 1.5 cal and dynamically stable ascent.

Inputs: Mass distribution, motor thrust curve, fin geometry.

Outputs: CG/CP locations, stability margin, drag estimate.

Key decisions: Fin planform (trapezoidal), nose-cone profile (ogive/conical).

Validation: OpenRocket / RasAero simulation, swing test.

Risks → Mitigation: Marginal stability → ballast in nose, simulate with worst-case CG.

C · Structures & Materials

Survive 15 g acceleration, 30 g shock

Purpose: Withstand launch loads, ejection shock, and landing impact.

Inputs: Material allowables, joint geometry, inertial loads.

Outputs: Margin-of-safety report, FEA plots, joint allowables.

Key decisions: PVC vs aluminum baseline, fastener pattern at thrust plate.

Validation: Hand calc + FEA, drop test, fit-check.

Risks → Mitigation: Joint failure → redundant fastener path, minimum FoS = 1.5.

D · Payload Bay

Carry, protect, release the 1 kg payload

Purpose: Enclose the CAN-7U-class payload, separate it cleanly at apogee.

Inputs: Payload OD, mass tolerance, separation altitude.

Outputs: Separation mechanism, internal mounts, no-sharp-edge layout.

Key decisions: Spring-based or motorized separation (zero pyro).

Validation: Bench separation test ≥ 10 cycles, drop test.

Risks → Mitigation: Hung separation → independent backup release on COTS altimeter.

E · Avionics

Sense the flight, command the events

Purpose: Sensing, logging, command, and event triggering.

Inputs: Power bus, sensor data, radio link.

Outputs: Telemetry packets, SD log, event signals (separation, recovery).

Key decisions: MCU selection, redundant chain topology.

Validation: HIL bench tests, environmental tests, polarity checks.

Risks → Mitigation: Power glitch → independent backup altimeter on its own battery.

F · Flight Software

Deterministic state machine, recoverable from reset

Purpose: Run the flight state machine, sample sensors at ≥ 1 Hz, log, and transmit.

Inputs: Sensor reads, ground commands.

Outputs: Telemetry stream, event triggers, SD log.

Key decisions: Apogee-detect algorithm (baro + accel fusion).

Validation: Replay-from-CSV unit tests, brown-out reset test.

Risks → Mitigation: State loss after reset → persisted state in non-volatile memory.

G · Telemetry & Communication

1 Hz, CSV, no missed apogee

Purpose: Reliable downlink of mission data and uplink command.

Inputs: 16-field packet, link budget, frequency allocation.

Outputs: Live data on ground UI, CSV file at session end.

Key decisions: XBee vs LoRa, antenna gain, NETID/PANID = team ID.

Validation: Range test ≥ 1 km, interference test pre-launch.

Risks → Mitigation: Dropout → onboard SD redundant log, post-flight USB hand-off.

H · Ground Station

Field-portable, battery-resilient, plot-everything

Purpose: Real-time visualization, command, and data persistence.

Inputs: Radio packets, operator commands.

Outputs: Live plots, CSV file, telemetry health view.

Key decisions: UI framework (Python/Qt or web), zero-set workflow.

Validation: 2-hour battery soak, packet-loss simulation, end-to-end dress rehearsal.

Risks → Mitigation: Laptop crash → second laptop hot-spare with synced config.

I · Recovery System

Parachute, no pyro, measurable descent

Purpose: Bring vehicle and payload down at 2–5 m/s ± 0.5 safely.

Inputs: Total descent mass, allowable terminal velocity, deployment altitude.

Outputs: Parachute size, harness, deployment sequence.

Key decisions: Chute diameter from descent-rate equation; mechanical (non-pyro) ejection.

Validation: Drop test, deploy bench test under 30 g shock proxy.

Risks → Mitigation: Tangle → fold protocol + sized deployment bag.

J · Launchpad / Launch Operations

Custom rail, 80°–85°, jury-verified

Purpose: Stable rail launch with verifiable angle and remote ignition.

Inputs: Lug spacing, ground anchor strategy, ignition wiring.

Outputs: Launch pad assembly, ignition box, range checklist.

Key decisions: Tripod stability, remote ignition standoff distance.

Validation: Angle protractor jury check, rail-friction test.

Risks → Mitigation: Tip-off instability → adjustable feet + ground stakes.

K · Testing & Verification

Test like you fly

Purpose: Demonstrate every requirement is met before flight.

Inputs: Test plan, calibrated equipment, verification matrix.

Outputs: Test reports, anomaly logs, verification status.

Key decisions: Test ordering — bench → environmental → integrated → dress rehearsal.

Validation: CDR + FRR sign-off on each closed test.

Risks → Mitigation: Late-discovered failures → buffer week before FRR.

L · Safety & Compliance

The non-negotiable layer

Purpose: Enforce IN-SPACe rules, range safety, and team safety culture.

Inputs: IN-SPACe rules, faculty advisor review, mentor sign-off.

Outputs: Preflight checklist, no-pyro declaration, hazard log, Go/No-Go.

Key decisions: Mechanical-only separation, organizer-supplied motor only.

Validation: Jury inspection at FRR; signed checklist before pad load.

Risks → Mitigation: Procedural slip → two-person verification on every pad step.

M · Documentation & Review Artifacts

Every artifact, version-controlled

Purpose: Maintain auditable records of design, test, and operations.

Inputs: Engineering outputs from every subsystem.

Outputs: PDR doc, CDR doc, FRR pack, PFA report, traceability matrix.

Key decisions: Single source of truth (Git/SharePoint) with naming convention.

Validation: Cross-check against IN-SPACe document checklists.

Risks → Mitigation: Documentation gaps → owner per section, weekly cadence review.

06 · Detailed Diagrams

Visual breakdowns of every critical path

A diagram per concept — lifecycle, context, hardware, software, telemetry, ground, recovery, reviews, traceability, risk, test, post-flight.

Diagram 3 — Mission Lifecycle Timeline

From registration to results — IN-SPACe 2026 indicative timeline (subject to organizer notice).

Phase 1
Registration

Team registration on IN-SPACe portal; nomination letter and registration fee submitted.

Phase 2
Preliminary Design Review (PDR)

Mission decomposition, system concept, simulation plan, requirements traceability v1.

Phase 3
Skill Development Workshop

One-week IN-SPACe hands-on rocketry workshop; scaled-down rocket build & launch.

Phase 4
Critical Design Review (CDR)

Finalized design, CAD, material selection, avionics architecture, full test plan, BOM.

Phase 5
Flight Readiness Review (FRR)

Integrated vehicle inspection, telemetry & recovery readiness, Go/No-Go.

Phase 6
Launch Window

Field deployment, telemetry capture, recovery, USB CSV hand-off.

Phase 7
Post-Flight Analysis (PFA)

Altitude reconciliation, telemetry review, anomaly log, lessons learned, final report.

Diagram 4 — System Context

Who and what AstroForge interacts with.

AstroForge Mission System Rocket · Avionics · Ground IN-SPACe Jury Reviews · Go/No-Go · Scoring Approved Motor Vendor Solid motor · standard interfaces Range / SSDF Site · Logistics · Range Safety Faculty Advisor Oversight · Liaison Mentors Technical Guidance SRMIST Trichy Lab Resources · Approval

Diagram 5 — Rocket Exploded-View Architecture

Schematic exploded view from nose cone to motor mount.

NOSE CONE Tethered, ogive RECOVERY BAY Parachute + harness PAYLOAD BAY CAN-7U · 1 kg AVIONICS BAY FC · GNSS · Radio MOTOR BAY Solid motor (vendor) FINS

Diagram 6 — Avionics Hardware Block Diagram

Sensor, compute, power, radio, and storage layout — including the redundant COTS chain.

Power System Alkaline/Ni-MH/Li-ion 18650 Barometer (altitude) IMU (accel + gyro) Temperature Voltage Monitor Flight Computer (MCU) State machine · 1 Hz logging Apogee detect (baro + accel) GNSS (NavIC-capable) Lat/Lon/Alt/Sats/UTC Onboard SD Storage Redundant CSV log Telemetry Radio XBee / LoRa · NETID = team Onboard Antenna Link-budgeted ≥ 1 km COTS Backup Altimeter Independent battery + chain Recovery Actuator
Redundancy note: The COTS backup altimeter (green) operates on its own power and triggers the recovery actuator independently of the main flight computer. This is the safety net the IN-SPACe rules require.

Diagram 7 — Telemetry Data Pipeline

Sensor → packet → radio → ground UI → CSV → review.

Sensors
Flight FW Packet Builder
XBee/LoRa Radio
Ground Antenna
Ground UI · Live Plots
CSV File
USB Hand-off · PFA
Sensors
Flight FW Logger
Onboard SD (redundant)
Post-flight extract
CSV merge (in case of dropout)

Diagram 8 — Ground Station Workflow

Pad-side operator workflow from boot-up to file delivery.

Boot Laptop
Connect Radio
Zero-Set at Pad
Telemetry Health Check
Issue Telemetry CMD
Live Capture
Save CSV · Hand-off USB

Diagram 9 — Recovery Deployment Sequence

Apogee detection through landing — non-pyro, mechanical actuation.

Ascent
Apogee Detect
Payload Separation
Parachute Deploy
Descent 2–5 m/s
Landed
Recovery Locate
No pyrotechnics: Separation and chute deployment are mechanical only (e.g., spring-loaded release triggered by servo or solenoid). Per IN-SPACe rules, teams using pyro devices are barred from preparatory activities at the site.

Diagram 10 — PDR / CDR / FRR Review Workflow

Each gate produces a sign-off and feedback loop into the next phase.

Engineering Output
PDR Submission
PDR Review
CDR Submission
CDR Review
FRR Inspection
Go / No-Go
Launch

Diagram 11 — Requirements Traceability Matrix Flow

From mission requirement to verified result, every link is documented.

IN-SPACe Requirement
System Requirement
Subsystem Requirement
Design Solution
Verification Method
Verified Status

Diagram 12 — Risk Management Workflow

Identify → assess → mitigate → re-assess.

Identify Risk
Assess Probability × Severity
Mitigate / Accept / Transfer
Assign Owner Role
Track Status
Re-assess at Each Review

Diagram 13 — Test Campaign Architecture

Test ordering — bench → environmental → integrated → dress rehearsal.

Component Bench Test
Subsystem Functional
Environmental (vibe / thermal)
Integrated System Test
Parachute Deploy Test
Dress Rehearsal

Diagram 14 — Post-Flight Analysis Pipeline

CSV ingest → reconciliation → anomaly tagging → final report.

Telemetry CSV + SD Log
Merge & Time-align
Altitude Reconciliation
Anomaly Tagging
Lessons Learned
PFA Report
07 · Flight Software State Machine

Twelve states, one deterministic flight

The flight FW always knows where it is. On reset, the last persisted state is reloaded — apogee never gets missed because the MCU rebooted.

0
BOOT
1
SENSOR_CHECK
2
IDLE
3
PAD_READY
4
LAUNCH_DETECT
5
ASCENT
6
APOGEE_DETECT
7
PAYLOAD_DEPLOY
8
RECOVERY_DEPLOY
9
DESCENT
10
LANDED
11
DATA_EXPORT

Per-state telemetry payload

Each transmitted packet at every state contains: PACKET_COUNT, TIMESTAMP, ALTITUDE, PRESSURE, TEMP, VOLTAGE, GNSS_*, ACCELEROMETER_DATA, GYRO_SPIN_RATE, and the current FLIGHT_SOFTWARE_STATE.

State Transitions
  • BOOT → SENSOR_CHECK: hardware self-test on power-up.
  • SENSOR_CHECK → IDLE: all sensors return valid data.
  • IDLE → PAD_READY: ground station issues "PAD_READY" command.
  • PAD_READY → LAUNCH_DETECT: baseline pressure/altitude zero-set complete.
  • LAUNCH_DETECT → ASCENT: sustained acceleration above launch threshold.
  • ASCENT → APOGEE_DETECT: negative dh/dt confirmed by baro + accel fusion.
  • APOGEE_DETECT → PAYLOAD_DEPLOY: fire mechanical separation.
  • PAYLOAD_DEPLOY → RECOVERY_DEPLOY: parachute mechanical deploy.
  • RECOVERY_DEPLOY → DESCENT: descent rate within 2–5 m/s envelope.
  • DESCENT → LANDED: altitude stable, accel quiescent.
  • LANDED → DATA_EXPORT: CSV finalized for USB hand-off.
Reset Recovery Strategy

Persisted state in non-volatile memory (EEPROM/flash) is updated on every state transition. On unexpected reset, FW boots → reads last state → resumes appropriate behavior:

  • If last state was ASCENT or earlier → re-enter sensor check then proceed.
  • If last state was APOGEE_DETECT or later → command immediate recovery deploy via backup chain.
  • COTS backup altimeter (independent power) acts as last-resort apogee trigger.

This satisfies IN-SPACe Section 5.4(v): "In the event of a processor reset during the mission, the flight software shall be able to determine the correct state."

08 · Telemetry CSV Design

16 fields, 1 Hz, ASCII comma-separated, per IN-SPACe Annexure-2

File naming: Flight_2026-INSPACe-ROCKETRY-505.csv. Generated on the ground station as the live downlink sink; backed up by onboard SD log.

Field specification

#FieldFunctionResolution / Format
1TEAM_IDTeam identifier2026-INSPACe-ROCKETRY-505
2TIME_STAMPTime since power-onseconds
3PACKET_COUNTSequential packet counterinteger
4ALTITUDEBarometric altitude vs ground0.1 m
5PRESSUREAtmospheric pressure1 Pa
6TEMPAir / sensor temperature0.1 °C
7VOLTAGEPower bus voltage0.01 V
8GNSS_TIMEGNSS UTC timeseconds
9GNSS_LATITUDEGNSS latitude0.0001°
10GNSS_LONGITUDEGNSS longitude0.0001°
11GNSS_ALTITUDEGNSS altitude0.1 m
12GNSS_SATSSatellites in fixinteger
13ACCELEROMETER_DATA3-axis accelerationm/s²
14GYRO_SPIN_RATESpin rate about long axisdeg/s
15FLIGHT_SOFTWARE_STATECurrent FW stateBOOT / IDLE / ASCENT / …
16OPTIONAL_DATAReserved for optional experimentfree-form

Sample CSV (illustrative — values are placeholder, not from a real flight)

TEAM_ID,TIME_STAMP,PACKET_COUNT,ALTITUDE,PRESSURE,TEMP,VOLTAGE,GNSS_TIME,GNSS_LATITUDE,GNSS_LONGITUDE,GNSS_ALTITUDE,GNSS_SATS,ACCELEROMETER_DATA,GYRO_SPIN_RATE,FLIGHT_SOFTWARE_STATE,OPTIONAL_DATA
2026-INSPACe-ROCKETRY-505,0.0,0001,0.0,101325,28.5,7.40,12:00:00,0.0000,0.0000,0.0,0,0.00,0.0,PAD_READY,
2026-INSPACe-ROCKETRY-505,1.0,0002,0.2,101324,28.5,7.40,12:00:01,0.0000,0.0000,0.1,8,0.10,0.1,PAD_READY,
2026-INSPACe-ROCKETRY-505,2.0,0003,1.4,101310,28.4,7.39,12:00:02,0.0000,0.0000,1.5,9,118.50,2.4,LAUNCH_DETECT,
2026-INSPACe-ROCKETRY-505,3.0,0004,84.6,100302,27.9,7.38,12:00:03,0.0000,0.0000,84.0,9,72.30,4.1,ASCENT,
2026-INSPACe-ROCKETRY-505,8.0,0009,612.8,094088,24.1,7.36,12:00:08,0.0000,0.0000,610.5,10,4.20,3.8,ASCENT,
2026-INSPACe-ROCKETRY-505,12.0,0013,995.1,090112,22.0,7.34,12:00:12,0.0000,0.0000,994.0,10,-9.80,2.6,APOGEE_DETECT,
2026-INSPACe-ROCKETRY-505,12.5,0014,994.8,090117,22.0,7.34,12:00:12,0.0000,0.0000,994.0,10,-9.80,1.2,PAYLOAD_DEPLOY,
2026-INSPACe-ROCKETRY-505,13.5,0015,968.4,090420,22.1,7.33,12:00:13,0.0000,0.0000,967.0,10,-9.80,0.8,RECOVERY_DEPLOY,
2026-INSPACe-ROCKETRY-505,30.0,0031,612.0,094090,24.1,7.32,12:00:30,0.0000,0.0000,612.5,10,-9.80,0.4,DESCENT,
...
Privacy & integrity: No personal data is logged in flight CSVs. The TEAM_ID field is the only team identifier. Real GNSS coordinates are zeroed in this example deliberately.
09 · Ground Station Design

Field-portable, battery-resilient, plot-everything

The ground station is the only place the flight is "real" before recovery. It must be reliable in the field, in the sun, and over a 1 km link.

Hardware

  • Laptop with ≥ 2 hr battery, ruggedized case
  • XBee/LoRa receiver via USB
  • Hand-held / mast-elevated antenna with link margin for 1 km+
  • Power-bank backup for laptop
  • USB drive for post-flight CSV hand-off

Software (Ground UI)

  • Live 1 Hz plots: altitude, pressure, accel, voltage, state
  • Telemetry health (packet loss %, RSSI)
  • Pad zero-set workflow
  • Telemetry start/stop command
  • CSV writer with correct filename convention
  • Operator log with timestamped events

Operational Flow

  • Pre-flight: connect → health check → pad zero-set
  • Pad: arm → telemetry CMD on jury clearance
  • Flight: live plots, no operator input required
  • Post-flight: stop logging → save CSV → USB hand-off
  • Recovery: relocate if needed (portable design)

Ground station portability requirements

RequirementSpec
Battery autonomy≥ 2 hours under continuous receive + plot
Antenna range≥ 1 km clear-line to launch pad / max altitude
Setup time≤ 15 minutes from box to receiving
RelocationOne-person carry; under 5 minutes to redeploy
Data persistenceCSV auto-saved every 10 s; never lost on crash
10 · Safety Design

Safety is not a section — it's the culture

Every design choice answers to safety first. AstroForge follows IN-SPACe safety rules without exception: no propellant work, no pyrotechnics, no hazardous payload.

What AstroForge will never do: manufacture, modify, or experiment with rocket propellant; fabricate or use pyrotechnic devices for separation, parachute deployment, or any other purpose; carry hazardous chemicals as payload; bypass the organizer's motor procurement process. These are hard prohibitions per IN-SPACe Sections 5.1 and 5.7.

Hardware Safety

  • Solid motor: only from IN-SPACe-identified vendors
  • Mechanical motor retention (clip / screw-on cap)
  • Mechanical-only payload separation and parachute deploy
  • No LiPo batteries; metal-cased Li-ion 18650 only
  • Hard-mounted electronics, structural enclosures

Operational Safety

  • Remote ignition with standoff distance
  • External arming switch with indicator light/sound
  • 30-minute pad-readiness battery margin
  • Multilingual recovery markings (English / Hindi / regional)
  • Two-person verification on every pad-side step

Pre-flight Checklist (excerpt)

  • Mass and balance verified within tolerance
  • Motor retention torque check
  • Avionics power-on self-test passed
  • COTS backup altimeter armed independently
  • Parachute fold verified by second team member
  • Ground station link health check ≥ 95% packets
  • Range area clear; jury inspection signed
  • Final Go/No-Go poll

Range & Recovery Safety

  • Launch angle 80°–85° verified by jury
  • Fluorescent airframe finish (red / orange / pink)
  • Team contact info on airframe in three languages
  • Descent rate 2–5 m/s ± 0.5 (inside spec)
  • No team member enters the recovery area until rocket has landed and is confirmed inert

Go / No-Go review criteria

AreaGO criterionNO-GO trigger
MassLift-off mass within ±5% of designOut of band → reweigh / rebuild
AvionicsAll sensors valid, COTS backup armedAny failed self-test
Telemetry≥ 95% packets at GS, RSSI nominalExcessive dropout or interference
RecoveryChute folded, harness intact, deploy bench-testedTangled fold / damaged harness
PadAngle 80°–85° jury-verified, area clearAngle out of band; hazard near pad
WeatherWithin IN-SPACe range envelopeWind / rain outside envelope
11 · Engineering Calculations

Reserved analysis slots — to be populated through PDR & CDR

The list below is the canonical set of analyses AstroForge will produce. Numerical values populate as the design baseline freezes. No motor / propellant manufacturing analysis is in scope.

Stability

CG / CP & Static Margin

Locate centre of gravity and centre of pressure; require static margin ≥ 1.5 cal (target ≥ 2.0 cal).

Method: OpenRocket model + analytical Barrowman; verified by swing test.

Performance

Thrust-to-Weight Ratio

Computed at ignition with vendor motor thrust curve and finalized lift-off mass; target T/W ≥ 5.

Aero

Drag Estimation

Coefficient of drag (Cd) estimate from frontal area, fin geometry, surface roughness; verified by simulation altitude back-calculation.

Aero

Fin Sizing

Trapezoidal fin sized for static margin and minimum flutter speed > max ascent speed × 1.5 safety factor.

Recovery

Descent Rate

Terminal velocity from total descent mass and parachute Cd·A; target 2–5 m/s ± 0.5.

Recovery

Parachute Sizing

Diameter from descent-rate equation: d = √(8·m·g / (π·ρ·v²·Cd)); verified by drop test.

Performance

Apogee Simulation

OpenRocket / RasAero with motor curve, drag, mass; sensitivity sweep over wind, mass tolerance, motor variance.

Comms

Telemetry Link Budget

Tx power, antenna gain, free-space path loss at 1 km, receiver sensitivity; required margin ≥ 10 dB.

Power

Battery Sizing

Energy = Σ(load × duration) for 30 min pad wait + flight + recovery; design margin ≥ 1.5×.

Structures

Structural Margins

Hand calc + FEA at thrust plate, fin root, payload bay joints; min FoS = 1.5 against yield.

Structures

Inertial Loads

15 g launch acceleration, 30 g shock at separation; verified via accelerometer log review.

Mass

Mass Budget

Subsystem-level mass tracking; lift-off mass ±5% of design value enforced through CDR.

12 · Review Documentation Deliverables

PDR · CDR · FRR · PFA — what each gate must contain

Each review is a stage gate. Failing a gate stops the project at that gate.

PDR

Preliminary Design Review

  • Mission overview and objectives
  • Requirements compliance matrix v1
  • Initial system architecture and subsystem concepts
  • Material & motor variant trade study
  • Preliminary mass, power, and link budgets
  • Risk register v1
  • Simulation plan and preliminary sim outputs
  • Project schedule and BOM (preliminary)
CDR

Critical Design Review

  • Finalized design with frozen baseline
  • CAD views (assembly, exploded, sections)
  • Material selection with allowables
  • Avionics architecture with schematics
  • Flight FW design with state machine
  • Full test plan (bench → environmental → integrated)
  • Updated risk register and mitigation status
  • Safety plan and Go/No-Go criteria
  • Final BOM with cost breakdown
FRR

Flight Readiness Review

  • Integration status report (every joint torqued, every cable tested)
  • Inspection report and photo log
  • Pre-flight checklist signed
  • Telemetry readiness: range test, CSV file generated
  • Recovery readiness: chute fold verified, deploy tested
  • Backup altimeter armed, independent battery checked
  • Go / No-Go decision recorded
PFA

Post-Flight Analysis

  • Altitude result vs target (1000 m ± 100 m)
  • Telemetry review with annotated plots
  • Anomaly log with root-cause analysis
  • Recovery condition report
  • Lessons learned (process and technical)
  • Improvement plan for next cycle
  • Final CSV file delivered to jury via USB
13 · Requirements Traceability Matrix

Every requirement, traceable to a design and a test

A truncated extract is shown below; the full matrix lives in the PDR/CDR documents and is updated each review cycle.

Req ID Requirement Source Design Solution Verification Method Status Risk
R-001Reach 1000 m ± 100 m apogeeIN-SPACe §4.1Sim-tuned mass + motor selectionTelemetry + barometerPlannedMedium
R-002Carry 1 kg ± 0.05 kg payloadIN-SPACe §5.2CAN-7U bay with mountsPre-flight weigh-inIn ProgressLow
R-003Solid motor from approved vendorIN-SPACe §5.1Vendor procurementVendor invoice reviewPlannedLow
R-004Telemetry ≥ 1 Hz, ASCII CSV, 16 fieldsIN-SPACe §5.6Flight FW logger + GS writerBench test + range testPlannedLow
R-005COTS backup altimeter on redundant chainIN-SPACe §5.1.xvIndependent altimeter + batteryBench arming testPlannedLow
R-006Descent rate 2–5 m/s ± 0.5IN-SPACe §5.7.iiiParachute sized to specDrop test + telemetryPlannedMedium
R-007Survive 15 g acceleration / 30 g shockIN-SPACe §5.3FEA-validated structureFEA + drop testIn ProgressMedium
R-008No pyrotechnic devicesIN-SPACe §5.1.xiMechanical separation onlyDesign inspectionVerifiedLow
R-009Multilingual recovery markingsIN-SPACe §5.3.iiPainted labels (Eng/Hindi/regional)Visual inspectionPlannedLow
R-010Ground station ≥ 2 hr battery, portableIN-SPACe §5.5.xiiLaptop + power bank, packed kit2 hr soak testPlannedLow
14 · Risk Register

What could go wrong, and what we'll do about it

Risks are reviewed at every gate. Each risk has an owner role (no personal names listed) and a status that updates with mitigation progress.

Risk ID Risk Cause Impact P S Mitigation Owner Role Status
RK-01Altitude undershoot/overshootMass tolerance, wind, motor varianceScore impact, mission failureMedHighSim sensitivity sweep, mass discipline, ballast slotsAero LeadActive
RK-02Telemetry dropoutInterference, range, antenna orientationLoss of grading dataMedMedOnboard SD redundant log, range pre-test, NETID setComms LeadActive
RK-03Avionics power failureBattery, connector, brown-outNo telemetry, no recovery triggerLowHighCOTS backup altimeter on independent battery; no spring contactsAvionics LeadPlanned
RK-04Recovery failureTangled chute, deploy mech jamHard landing, vehicle lossLowHighDrop tests, fold protocol, redundant triggerRecovery LeadPlanned
RK-05Payload separation issueMech jam, asymmetric forceNo payload deploy → score 0LowHighBench cycle test ≥ 10×, backup release on COTSPayload LeadPlanned
RK-06Unstable flightMarginal static margin, fin damageErratic trajectory, range safetyLowHighMargin ≥ 2 cal target, swing test, pre-flight fin inspectionAero LeadPlanned
RK-07Excessive descent rateUndersized chute, harness breakOut-of-spec landingLowMedSized to 3 m/s nominal, harness FoS ≥ 2Recovery LeadPlanned
RK-08Late integrationSchedule slip, vendor delayFRR slip → no launch slotMedHighBuffer week before FRR, weekly burndown, parallel work streamsProject LeadActive
RK-09Documentation gapsOwner ambiguity, version driftReview failureMedMedSection owners, weekly doc review, single-source repoSystems LeadActive

P = Probability, S = Severity. Owner roles are listed (not personal names) consistent with project privacy practice.