Astra Autonomous Flight System (AAFS)
Hardware- 4 Devlogs
- 2 Total hours
I am building an autonomous rocket flight system that plots position and will also use that data to move itself to stabilise the aircraft.
EN‑0004 – Documentation Standards
Document Number: EN‑0004
Title: Documentation Standards
Author: Pathan
Created: 30‑06‑2026
Last Modified: 30‑06‑2026
Revision: 0.1.0
Status: Draft
Subsystem: Project Administration
Related Documents:
- EN‑0001
- EN‑0003
1. Purpose
This document defines the documentation standards used throughout the ASTRA Autonomous Flight System (AAFS).
The objective is to ensure all engineering records are clear, consistent, traceable, and maintainable throughout the project’s lifetime.
2. Documentation Philosophy
Documentation is a primary engineering deliverable.
Every major engineering decision, requirement, calculation, trade study, simulation, implementation, and test shall be documented.
Engineering documentation shall accurately reflect the current state of the project.
3. Standard Document Format
Unless otherwise required, engineering notebook documents should follow the standard ASTRA document template.
Each document shall include:
- Document Number
- Title
- Author
- Created
- Last Modified
- Revision
- Status
- Subsystem
- Related Documents
4. Writing Standards
Documentation shall:
- Be technically accurate.
- Be concise and objective.
- Use consistent terminology.
- Define acronyms on first use.
- Avoid ambiguous language.
- Use proper grammar and spelling.
Opinions shall be supported by engineering reasoning whenever possible.
5. Engineering Content
Engineering documents should record:
- Design intent
- Requirements
- Assumptions
- Constraints
- Design decisions
- Interfaces
- Mathematical analysis
- Test procedures
- Results
- Conclusions
The level of detail shall be appropriate for the document type.
6. Figures, Tables, and Diagrams
Figures and diagrams should:
- Have descriptive titles.
- Be referenced within the document.
- Support the engineering discussion.
Block diagrams, system architectures, flowcharts, and mathematical models should be included whenever they improve understanding.
7. Revision Control
Every revision shall:
- Update the revision number.
- Update the Last Modified field.
- Describe the changes in the Revision History section.
Major engineering changes should be documented through new notebook entries when appropriate.
8. Traceability
Documents should reference related notebook entries, requirements, software modules, simulations, and test reports whenever applicable.
Engineering decisions should remain traceable throughout the project lifecycle.
9. Revision History
Revision Date Description 0.1.0 30‑06‑2026 Initial document.Ad Astra Per Artem
EN‑0003 – Repository Standards
Document Number: EN‑0003
Title: Repository Standards
Author: Aamir Khan Pathan
Created: 30‑06‑2026
Last Modified: 30‑06‑2026
Revision: 0.1.0
Status: Draft
Subsystem: Project Administration
Related Documents:
- EN‑0001
- EN‑0002
- EN‑0004
1. Purpose
This document establishes the standards governing the structure, organization, and maintenance of the ASTRA Autonomous Flight System (AAFS) repository. These standards ensure consistency, traceability, maintainability, and scalability throughout the project’s lifecycle.
2. Repository Organization
The ASTRA repository shall be organized by engineering discipline.
Top‑level Directories include:
- Engineering Notebook
- firmware
- ground
- simulation
- hardware
- analysis
- missions
- data
- assets
- docs
- tools
- tests
- .github
Each directory shall contain only files relevant to its designated purpose.
3. Directory Standards
- Each directory shall contain a
README.mdfile describing its purpose when practical. - Directory names shall remain consistent throughout the project.
- New top‑level directories shall only be created when a clear engineering need exists.
- Duplicate directory structures should be avoided.
4. File Naming Standards
Engineering notebook documents shall follow the format:
EN‑0001_Project_initialization.md
Subsystem documents shall follow the format:
SYS‑001_Mission_Requirements.md
SW‑001_Software_Architecture.md
MECH‑001_Airframe.md
ELEC‑001_Power_System.md
For full breakdown of prefixes refer to [Astra/Document Templates And Breakdowns/Prefix_Definitions.md](url)
File names shall:
- Use descriptive names.
- Preserve document identifiers.
- Use underscores instead of spaces.
- Use the
.mdextension unless another format is required.
5. Branch Strategy
Development shall use the following branches:
- main
- develop
- feature/*
- release/*
- hotfix/*
The main branch shall always represent the latest stable revision.
6. Commit Standards
Commits shall represent a single logical change.
Commit messages should follow the format:
docs(EN‑0003): update repository standards
feat(nav): implement sensor fusion
fix(control): resolve PID oscillation
hardware(pcb): revise flight computer layout
EN‑0002 — Development Roadmap
Document Number: EN‑0002
Title: Development Roadmap
Author: Aamir Khan Pathan
Created: 2026‑06‑29
Revision: 0.1
Status: Draft
Subsystem: Project Administration
Related Documents: EN‑0001, ROADMAP.md
1. Purpose
The purpose of this document is to establish the planned development strategy for the ASTRA Autonomous Flight System.
This roadmap defines the engineering phases, major milestones, dependencies, expected deliverables, and success criteria that will guide development throughout the project lifecycle.
This document serves as the baseline planning document for the ASTRA program and may evolve as new requirements, technical discoveries, and project priorities emerge.
2. Development Philosophy
ASTRA follows an iterative systems engineering approach.
Each subsystem progresses through the following lifecycle:
Concept
Requirements
Research
Trade Study
Architecture
Design
Implementation
Simulation
Testing
Verification
Validation
Integration
RevisionCode
3. Program Phases
Phase 0 — Program Foundation
Status: Complete
Objectives
- Repository
- Documentation
- Engineering Notebook
- Version Control
Deliverables
- GitHub Repository
- README
- Documentation Standards
- Engineering Notebook
Phase I — Systems Engineering
Objectives
- Mission Requirements
- Functional Requirements
- Architecture
- Interfaces
- Risk Assessment
Success Criteria
- Complete engineering baseline documentation.
Phase II — Simulation
Objectives
- Digital Twin
- Flight Dynamics
- Wind Models
- Sensor Simulation
- Guidance Testing
Deliverable
- Simulation capable of validating flight software.
Phase III — Flight Software
Objectives
- Navigation
- Guidance
- Control
- Recovery
- Telemetry
- Logging
Phase IV — Ground Control
Objectives
- Mission Planner
- Dashboard
- Telemetry
- Flight Replay
- Configuration
- Diagnostics
Phase V — Hardware
Objectives
- Flight Computer
- Power
- Sensors
- PCB
- Mechanical Integration
- Bench Testing
Phase VI — Integration
Objectives
- Hardware Integration
- Software Integration
- Communication
- Subsystem Validation
Phase VII — Flight Testing
Objectives
- Ground Tests
- Static Tests
- Flight Tests
- Mission Reports
- Lessons Learned
4. Engineering Workflow
Every feature follows the workflow:
Research
Notebook Entry
Requirements
Design
Trade Study
Simulation
Implementation
Testing
Documentation Update
MergeCode
5. Milestones
- Repository Established
- Engineering Notebook Complete
- Systems Engineering Baseline
- Simulation Operational
- Ground Station Operational
- Flight Software Prototype
- Hardware Prototype
- Integrated System
- First Successful Flight
- Controlled Recovery
6. Exit Criteria
Each phase should have a clear definition of “done.”
Example — Phase II Exit Criteria
- Flight dynamics validated
- Sensor models complete
- Simulation produces repeatable results
- Documentation approved
7. Risks
Major risks (high‑level only):
- Software complexity
- Sensor reliability
- Hardware failures
- Power limitations
- Communication failures
- Schedule growth
8. Revision History
Revision Description 0.1 Initial document
EN-0001 - Project Initialization
Document Number: EN-0001
Title: Project Initialization
Author: Aamir Khan Pathan
Date Created: 29-06-2026
Revision: 0.1.0
Status: Draft
Subsystem: Project Administration
Purpose
This document formally establishes the ASTRA Autonomous Flight System (AAFS) project and defines its initial engineering vision, objectives, scope, and development philosophy.
This entry serves as the foundation of the engineering notebook and provides the baseline from which all future technical decisions, requirements, and design work will evolve.
Project Name
ASTRA Autonomous Flight System
AAFS
Vision
ASTRA is intended to become a modular autonomous flight platform capable of collecting telemetry, estimating vehicle state, executing autonomous guidance algorithms and corrections, and supporting progressively advanced recovery capabilities.
The project is designed as a long-term engineering initiative focused on learning and applying principles from:
- Aerospace Engineering
- Systems Engineering
- Embedded Systems
- Flight Software
- Electronics
- Control Theory
- Navigation
- Software Engineering
The emphasis is placed on designing every subsystem as an independent module while maintaining full system integration through well-defined interfaces.
Primary Objectives
The initial goals of ASTRA are:
- Develop a complete systems engineering workflow.
- Design a modular avionics architecture.
- Build a scalable flight software framework.
- Develop a desktop Ground Control Station.
- Create a complete engineering notebook documenting every design decision.
- Validate all major subsystems through simulation before hardware implementation.
- Support future autonomous navigation and controlled recovery.
Engineering Philosophy
ASTRA follows several core principles:
- Safety before capability.
- Documentation before implementation.
- Simulation before hardware.
- Modularity over complexity.
- Verification before validation.
- Continuous improvement.
Every engineering decision should and shall be justified through analysis, testing, or documented trade studies.
Long-Term Development Phases
Phase I
- Project Planning
- Repository
- Documentation
- Architecture
- Simulation
Phase II
- Avionics
- Flight Computer
- Telemetry
- Ground Station
Phase III
- Navigation
- Sensor Fusion
- Guidance
- Flight Control
- Recovery
Phase IV
- Integrated Testing
- Hardware
- Simulation
- Flight Testing
- Mission Operations
Success Criteria
The ASTRA project will be considered successful if it achieves:
- Comprehensive engineering documentation.
- Modular subsystem architecture.
- Repeatable verification procedures.
- Reliable software architecture.
- Successful integrated subsystem operation.
- Continuous engineering improvement through iterative development.
Notes
This engineering notebook shall record every major engineering decision, design revision, analysis, simulation, trade study, and test result produced throughout the ASTRA project lifecycle.
Each notebook entry should provide sufficient technical detail to allow another engineer to understand the reasoning behind the decisions made.
Ad Astra Per Artem
