Files
AeroAlign/.specify/templates/plan-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

6.5 KiB
Raw Permalink Blame History

Implementation Plan: [FEATURE]

Branch: [###-feature-name] | Date: [DATE] | Spec: [link] Input: Feature specification from /specs/[###-feature-name]/spec.md

Note: This template is filled in by the /speckit.plan command. See .specify/templates/commands/plan.md for the execution workflow.

Summary

[Extract from feature spec: primary requirement + technical approach from research]

Technical Context

Language/Version: [e.g., Python 3.11, Swift 5.9, Rust 1.75 or NEEDS CLARIFICATION]
Primary Dependencies: [e.g., FastAPI, UIKit, LLVM or NEEDS CLARIFICATION]
Storage: [if applicable, e.g., PostgreSQL, CoreData, files or N/A]
Testing: [e.g., pytest, XCTest, cargo test or NEEDS CLARIFICATION]
Target Platform: [e.g., Linux server, iOS 15+, WASM or NEEDS CLARIFICATION] Project Type: [single/web/mobile - determines source structure]
Performance Goals: [domain-specific, e.g., 1000 req/s, 10k lines/sec, 60 fps or NEEDS CLARIFICATION]
Constraints: [domain-specific, e.g., <200ms p95, <100MB memory, offline-capable or NEEDS CLARIFICATION]
Scale/Scope: [domain-specific, e.g., 10k users, 1M LOC, 50 screens or NEEDS CLARIFICATION]

Constitution Check

GATE: Must pass before Phase 0 research. Re-check after Phase 1 design.

I. Extreme Cost-Efficiency

  • All components have Amazon ASIN or mass-market equivalent documented
  • BOM total cost calculated and minimized
  • At least 2 supplier alternatives identified for critical components
  • No exotic components requiring special supplier relationships

II. 3D Printing Reproducibility

  • All printable parts fit within 200mm × 200mm × 200mm build volume
  • Support structures do not exceed 30% part volume
  • STL files provided in print-ready orientation
  • Print settings documented (layer height, infill, material)
  • Assembly instructions include photos/diagrams
  • Tolerances account for ±0.2mm print variance
  • Post-processing limited to basic tools (knife, sandpaper, soldering iron)

III. Lightweight Design

  • Total device weight under 150 grams (excluding measured object)
  • Infill patterns and wall thickness optimized for strength-to-weight ratio
  • Weight distribution documented and optimized
  • Calibration procedure accounts for self-weight offset
  • Scale/sensor placement minimizes impact on small surfaces

IV. Software Simplicity (Plug-and-Play)

  • No app store submission or account creation required
  • No cloud services or internet required for core functionality
  • Firmware supports direct USB programming (no proprietary tools)
  • Data output uses standard protocols (USB serial, CSV, simple HTTP)
  • Configuration via plain text files or physical controls
  • Libraries use permissive licenses (MIT, Apache 2.0, BSD)
  • Setup procedure does not exceed 3 steps

Hardware Design Requirements

  • Component specifications documented (voltage, current, protocol)
  • Component availability verified in US, EU, Asia markets
  • Fasteners use metric sizes (M2, M3, M4) from assortment kits
  • Soldering limited to through-hole (SMD only if unavoidable)
  • Cable lengths and connector types specified in BOM
  • Assembly time under 4 hours for experienced maker
  • Calibration procedure uses household reference objects
  • Measurement accuracy and precision documented
  • Troubleshooting guide for common assembly errors included
  • Tested with at least 3 different 3D printer brands/models

Software Development Requirements

  • Targets widely-available microcontroller (ESP32, Arduino, RP2040)
  • Uses Arduino framework or PlatformIO
  • Pre-compiled binary included for non-developers
  • Flashing procedure documented for Windows, macOS, Linux
  • Descriptive variable names and comments for non-obvious logic
  • No platform-specific extensions that limit portability
  • Firmware size under 80% of flash capacity
  • Sensor input validation and error handling implemented
  • Serial output in human-readable format (CSV or JSON lines)
  • Baud rate and data format documented
  • Example code provided (Python/JavaScript)
  • Optional web interface has no external dependencies or build steps

Project Structure

Documentation (this feature)

specs/[###-feature]/
├── plan.md              # This file (/speckit.plan command output)
├── research.md          # Phase 0 output (/speckit.plan command)
├── data-model.md        # Phase 1 output (/speckit.plan command)
├── quickstart.md        # Phase 1 output (/speckit.plan command)
├── contracts/           # Phase 1 output (/speckit.plan command)
└── tasks.md             # Phase 2 output (/speckit.tasks command - NOT created by /speckit.plan)

Source Code (repository root)

# [REMOVE IF UNUSED] Option 1: Single project (DEFAULT)
src/
├── models/
├── services/
├── cli/
└── lib/

tests/
├── contract/
├── integration/
└── unit/

# [REMOVE IF UNUSED] Option 2: Web application (when "frontend" + "backend" detected)
backend/
├── src/
│   ├── models/
│   ├── services/
│   └── api/
└── tests/

frontend/
├── src/
│   ├── components/
│   ├── pages/
│   └── services/
└── tests/

# [REMOVE IF UNUSED] Option 3: Mobile + API (when "iOS/Android" detected)
api/
└── [same as backend above]

ios/ or android/
└── [platform-specific structure: feature modules, UI flows, platform tests]

Structure Decision: [Document the selected structure and reference the real directories captured above]

Complexity Tracking

Fill ONLY if Constitution Check has violations that must be justified

Violation Why Needed Simpler Alternative Rejected Because
[e.g., 4th project] [current need] [why 3 projects insufficient]
[e.g., Repository pattern] [specific problem] [why direct DB access insufficient]