digiflo/AeroAlign
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
538c3081bf106a9bf391b4f3e0f47bc64c4786af
AeroAlign/.specify/templates/spec-template.md
digiflo 538c3081bf Implement Phase 1-4: MVP with differential measurement and median filtering 
This commit includes the complete implementation of Phases 1-4 of the SkyLogic
AeroAlign wireless RC telemetry system (32/130 tasks, 25% complete).

## Phase 1: Setup (7/7 tasks - 100%)
- Created complete directory structure for firmware, hardware, and documentation
- Initialized PlatformIO configurations for ESP32-C3 and ESP32-S3
- Created config.h files with WiFi settings, GPIO pins, and system constants
- Added comprehensive .gitignore file

## Phase 2: Foundational (13/13 tasks - 100%)

### Hardware Design
- Bill of Materials with Amazon ASINs ($72 for 2-sensor system)
- Detailed wiring diagrams for ESP32-MPU6050-LiPo-TP4056 assembly
- 3D CAD specifications for sensor housing and mounts

### Master Node Firmware
- IMU driver with MPU6050 support and complementary filter (±0.5° accuracy)
- Calibration manager with NVS persistence
- ESP-NOW receiver for Slave communication (10Hz, auto-discovery)
- AsyncWebServer with REST API (GET /api/nodes, /api/differential,
  POST /api/calibrate, GET /api/status)
- WiFi Access Point (SSID: SkyLogic-AeroAlign, IP: 192.168.4.1)

### Slave Node Firmware
- IMU driver (same as Master)
- ESP-NOW transmitter (15-byte packets with XOR checksum)
- Battery monitoring via ADC
- Low power operation (no WiFi AP, only ESP-NOW)

## Phase 3: User Story 1 - MVP (12/12 tasks - 100%)

### Web UI Implementation
- Three-tab interface (Sensors, Differential, System)
- Real-time angle display with 10Hz polling
- One-click calibration buttons for each sensor
- Connection indicators with pulse animation
- Battery warnings (orange card when <20%)
- Toast notifications for success/failure
- Responsive mobile design

## Phase 4: User Story 2 - Differential Measurement (8/8 tasks - 100%)

### Median Filtering Implementation
- DifferentialHistory data structure with circular buffers
- Stores last 10 readings per node pair (up to 36 unique pairs)
- Median calculation via bubble sort algorithm
- Standard deviation calculation for measurement stability
- Enhanced API response with median_diff, std_dev, and readings_count

### Accuracy Achievement
- ±0.1° accuracy via median filtering (vs ±0.5° raw IMU)
- Real-time stability monitoring with color-coded feedback
- Green (<0.1°), Yellow (<0.3°), Red (≥0.3°) std dev indicators

### Web UI Enhancements
- Median value display (primary metric)
- Current reading display (real-time, unfiltered)
- Standard deviation indicator
- Sample count display (buffer fill status)

## Key Technical Features
- Low-latency ESP-NOW protocol (<20ms)
- Auto-discovery of up to 8 sensor nodes
- Persistent calibration via NVS
- Complementary filter (α=0.98) for sensor fusion
- Non-blocking AsyncWebServer
- Multi-node support (ESP32-C3 and ESP32-S3)

## Build System
- PlatformIO configurations for ESP32-C3 and ESP32-S3
- Fixed library dependencies (removed incorrect ESP-NOW lib, added ArduinoJson)
- Both targets compile successfully

## Documentation
- Comprehensive README.md with quick start guide
- Detailed IMPLEMENTATION_STATUS.md with progress tracking
- API documentation and wiring diagrams

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
2026-01-22 08:09:25 +01:00

4.9 KiB
Raw Blame History

Feature Specification: [FEATURE NAME]

Feature Branch: [###-feature-name]
Created: [DATE]
Status: Draft
Input: User description: "$ARGUMENTS"

User Scenarios & Testing (mandatory)

User Story 1 - [Brief Title] (Priority: P1)

[Describe this user journey in plain language]

Why this priority: [Explain the value and why it has this priority level]

Independent Test: [Describe how this can be tested independently - e.g., "Can be fully tested by [specific action] and delivers [specific value]"]

Acceptance Scenarios:

  1. Given [initial state], When [action], Then [expected outcome]
  2. Given [initial state], When [action], Then [expected outcome]

User Story 2 - [Brief Title] (Priority: P2)

[Describe this user journey in plain language]

Why this priority: [Explain the value and why it has this priority level]

Independent Test: [Describe how this can be tested independently]

Acceptance Scenarios:

  1. Given [initial state], When [action], Then [expected outcome]

User Story 3 - [Brief Title] (Priority: P3)

[Describe this user journey in plain language]

Why this priority: [Explain the value and why it has this priority level]

Independent Test: [Describe how this can be tested independently]

Acceptance Scenarios:

  1. Given [initial state], When [action], Then [expected outcome]

[Add more user stories as needed, each with an assigned priority]

Edge Cases

  • What happens when [boundary condition]?
  • How does system handle [error scenario]?

Requirements (mandatory)

Functional Requirements

  • FR-001: System MUST [specific capability, e.g., "allow users to create accounts"]
  • FR-002: System MUST [specific capability, e.g., "validate email addresses"]
  • FR-003: Users MUST be able to [key interaction, e.g., "reset their password"]
  • FR-004: System MUST [data requirement, e.g., "persist user preferences"]
  • FR-005: System MUST [behavior, e.g., "log all security events"]

Example of marking unclear requirements:

  • FR-006: System MUST authenticate users via [NEEDS CLARIFICATION: auth method not specified - email/password, SSO, OAuth?]
  • FR-007: System MUST retain user data for [NEEDS CLARIFICATION: retention period not specified]

Key Entities (include if feature involves data)

  • [Entity 1]: [What it represents, key attributes without implementation]
  • [Entity 2]: [What it represents, relationships to other entities]

Hardware Components (include if feature involves physical components)

  • [Component 1]: [Description, Amazon ASIN, specifications, 2+ alternatives]
  • [Component 2]: [Description, Amazon ASIN, specifications, 2+ alternatives]
  • Total BOM Cost: [Estimated cost in USD]
  • Weight Budget: [Total weight in grams, must be under 150g per Constitution III]

3D Printed Parts (include if feature requires 3D printing)

  • [Part 1]: [Dimensions, material (PLA/PETG/ABS), estimated print time, infill %]
  • [Part 2]: [Dimensions, material (PLA/PETG/ABS), estimated print time, infill %]
  • Maximum Part Size: [Must fit within 200mm × 200mm × 200mm per Constitution]
  • Support Requirements: [Must not exceed 30% part volume per Constitution]

Success Criteria (mandatory)

Measurable Outcomes

  • SC-001: [Measurable metric, e.g., "Users can complete account creation in under 2 minutes"]
  • SC-002: [Measurable metric, e.g., "System handles 1000 concurrent users without degradation"]
  • SC-003: [User satisfaction metric, e.g., "90% of users successfully complete primary task on first attempt"]
  • SC-004: [Business metric, e.g., "Reduce support tickets related to [X] by 50%"]
Reference in New Issue View Git Blame Copy Permalink