90 lines
4.3 KiB
Markdown
Executable File
90 lines
4.3 KiB
Markdown
Executable File
# ? Problem Statement: Rocket Design and Flight Simulation Application
|
|
## Overview
|
|
There is a critical need for an intuitive, extensible, and technically rigorous software application
|
|
that empowers hobbyists, students, certification candidates, and early-career engineers to design,
|
|
simulate, and optimize low-power, mid-power, high-power, and amateur-class rockets. The tool must
|
|
emphasize accessibility, modularity, and educational transparency, and be written in clean,
|
|
modern C++ using an object-oriented architecture. It must support both immediate practical needs
|
|
(rocket design, flight prediction) and deeper study of aerospace physics and software engineering
|
|
principles.
|
|
|
|
The platform must remain open-source, support .ork file compatibility, and operate reliably across
|
|
Linux, Mac, and Windows environments.
|
|
|
|
## Goals
|
|
- **Modern Design Tools**: Allow users to easily create and modify rocket models, specifying
|
|
parameters like airframes, mass properties, center of gravity (CG), center of pressure (CP),
|
|
propulsion systems, and aerodynamic surfaces.
|
|
|
|
- **Physics-Based Flight Simulation**: Simulate rocket flight through launch, coast, apogee, descent,
|
|
and recovery, using accurate force models (thrust, drag, gravity, weather effects).
|
|
|
|
- **Extensible Simulation Architecture**: Architect the system to initially support
|
|
3 Degree-of-Freedom (3-DoF) simulations, but natively prepare for future extension to 6-DoF
|
|
(full 3D translation and rotation dynamics) without major rework.
|
|
|
|
- **Educational Transparency**: Build the codebase to be highly readable, logically organized, and
|
|
deeply documented, promoting learning about flight dynamics and systems modeling.
|
|
|
|
- **Component Modularity**: Each rocket component (e.g., motors, fins, payloads, recovery systems)
|
|
must exist as independent, interchangeable modules.
|
|
|
|
- **Visualization**: Provide meaningful visual outputs, including:
|
|
|
|
- 2D/3D trajectory plots
|
|
|
|
- Stability margin graphs (e.g., CG-CP margin over time)
|
|
|
|
- Thrust, velocity, and altitude vs. time graphs
|
|
|
|
- **Certification-Ready Fidelity**: Achieve simulation fidelity that can support Tripoli Rocketry
|
|
Association and NAR Level 3 certification requirements.
|
|
|
|
- **Competitive Capability**: Aim to function as a drop-in replacement or superior alternative to
|
|
tools like OpenRocket and RockSim Pro.
|
|
|
|
- **Cross-Platform Support**: Deliver fully supported builds on Linux, Mac, and Windows.
|
|
|
|
## User Personas
|
|
|
|
- **Hobbyist Rocketeer**: Designs and refines personal rockets, needing accuracy and usability
|
|
without extensive technical setup.
|
|
|
|
- **High School/University Student**: Builds rockets for courses, competitions, or research projects,
|
|
using simulation to test and verify designs.
|
|
|
|
- **STEM Educator**: Leverages the tool in classrooms to teach core concepts of dynamics, propulsion,
|
|
aerodynamics, and systems engineering.
|
|
|
|
- **Certification Candidate (NAR/Tripoli)**: Designs rockets intended for Level 1, 2, or 3
|
|
certification and needs trustworthy simulation results.
|
|
|
|
- **Aerospace Engineering Student/Professional**: Uses the tool to prototype amateur designs, and
|
|
values modular, clear, and modern C++ code.
|
|
|
|
## Operating Constraints
|
|
- **Language**: Must be written in modern C++ (C++17 or newer) with strong attention to modularity,
|
|
memory safety, and performance.
|
|
|
|
- **Portability**: Must fully support Linux, Mac, and Windows platforms with minimal
|
|
platform-specific code.
|
|
|
|
- **Open Source**: Must be licensed under a permissive open-source license (e.g., MIT or BSD
|
|
3-clause) to encourage adoption, study, and contribution.
|
|
|
|
- **File Format Compatibility**: Must support import/export of OpenRocket (.ork) files, ensuring
|
|
interoperability with existing hobbyist ecosystems.
|
|
|
|
- **Performance**: Must run smoothly on consumer-grade hardware and support both interactive design
|
|
work and batch simulation runs for optimization.
|
|
|
|
- **Incremental Upgrades**: Initial release will support 3-DoF dynamics (translational motion only)
|
|
but architecture must cleanly allow extension to full 6-DoF dynamics (translational + rotational
|
|
motion).
|
|
|
|
## User Interface Requirements
|
|
- **Modular Design**: The UI should be modular, allowing for easy addition of new features and
|
|
components without breaking existing functionality.
|
|
|
|
- **Intuitive Interaction**: The interface should be intuitive and user-friendly, with clear
|
|
labels, tooltips, and responsive design. |