digiflo/AeroAlign
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
538c3081bf106a9bf391b4f3e0f47bc64c4786af
AeroAlign/.specify/templates/tasks-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

11 KiB
Raw Blame History

description
description
Task list template for feature implementation

Tasks: [FEATURE NAME]

Input: Design documents from /specs/[###-feature-name]/ Prerequisites: plan.md (required), spec.md (required for user stories), research.md, data-model.md, contracts/

Tests: The examples below include test tasks. Tests are OPTIONAL - only include them if explicitly requested in the feature specification.

Organization: Tasks are grouped by user story to enable independent implementation and testing of each story.

Format: [ID] [P?] [Story] Description

  • [P]: Can run in parallel (different files, no dependencies)
  • [Story]: Which user story this task belongs to (e.g., US1, US2, US3)
  • Include exact file paths in descriptions

Path Conventions

  • Single project: src/, tests/ at repository root
  • Web app: backend/src/, frontend/src/
  • Mobile: api/src/, ios/src/ or android/src/
  • Paths shown below assume single project - adjust based on plan.md structure

Phase 1: Setup (Shared Infrastructure)

Purpose: Project initialization and basic structure

  • T001 Create project structure per implementation plan
  • T002 Initialize [language] project with [framework] dependencies
  • T003 [P] Configure linting and formatting tools

Phase 2: Foundational (Blocking Prerequisites)

Purpose: Core infrastructure that MUST be complete before ANY user story can be implemented

⚠️ CRITICAL: No user story work can begin until this phase is complete

Examples of foundational tasks for SOFTWARE projects (adjust based on your project):

  • T004 Setup database schema and migrations framework
  • T005 [P] Implement authentication/authorization framework
  • T006 [P] Setup API routing and middleware structure
  • T007 Create base models/entities that all stories depend on
  • T008 Configure error handling and logging infrastructure
  • T009 Setup environment configuration management

Examples of foundational tasks for HARDWARE projects (adjust based on your project):

  • T004 Source all components from Amazon/mass-market suppliers (Constitution I)
  • T005 [P] Document BOM with ASIN codes and 2+ alternatives per component (Constitution I)
  • T006 [P] Design 3D printable enclosure/parts within 200mm³ constraint (Constitution II)
  • T007 Verify total weight under 150g budget (Constitution III)
  • T008 Setup microcontroller firmware project (ESP32/Arduino/RP2040) (Constitution IV)
  • T009 [P] Configure PlatformIO or Arduino IDE build environment (Constitution IV)
  • T010 [P] Create STL files in print-ready orientation with documented settings (Constitution II)
  • T011 Test print parts on 3 different printer brands (Constitution II)

Checkpoint: Foundation ready - user story implementation can now begin in parallel

Phase 3: User Story 1 - [Title] (Priority: P1) 🎯 MVP

Goal: [Brief description of what this story delivers]

Independent Test: [How to verify this story works on its own]

Tests for User Story 1 (OPTIONAL - only if tests requested) ⚠️

NOTE: Write these tests FIRST, ensure they FAIL before implementation

  • T010 [P] [US1] Contract test for [endpoint] in tests/contract/test_[name].py
  • T011 [P] [US1] Integration test for [user journey] in tests/integration/test_[name].py

Implementation for User Story 1

  • T012 [P] [US1] Create [Entity1] model in src/models/[entity1].py
  • T013 [P] [US1] Create [Entity2] model in src/models/[entity2].py
  • T014 [US1] Implement [Service] in src/services/[service].py (depends on T012, T013)
  • T015 [US1] Implement [endpoint/feature] in src/[location]/[file].py
  • T016 [US1] Add validation and error handling
  • T017 [US1] Add logging for user story 1 operations

Checkpoint: At this point, User Story 1 should be fully functional and testable independently

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

Goal: [Brief description of what this story delivers]

Independent Test: [How to verify this story works on its own]

Tests for User Story 2 (OPTIONAL - only if tests requested) ⚠️

  • T018 [P] [US2] Contract test for [endpoint] in tests/contract/test_[name].py
  • T019 [P] [US2] Integration test for [user journey] in tests/integration/test_[name].py

Implementation for User Story 2

  • T020 [P] [US2] Create [Entity] model in src/models/[entity].py
  • T021 [US2] Implement [Service] in src/services/[service].py
  • T022 [US2] Implement [endpoint/feature] in src/[location]/[file].py
  • T023 [US2] Integrate with User Story 1 components (if needed)

Checkpoint: At this point, User Stories 1 AND 2 should both work independently

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

Goal: [Brief description of what this story delivers]

Independent Test: [How to verify this story works on its own]

Tests for User Story 3 (OPTIONAL - only if tests requested) ⚠️

  • T024 [P] [US3] Contract test for [endpoint] in tests/contract/test_[name].py
  • T025 [P] [US3] Integration test for [user journey] in tests/integration/test_[name].py

Implementation for User Story 3

  • T026 [P] [US3] Create [Entity] model in src/models/[entity].py
  • T027 [US3] Implement [Service] in src/services/[service].py
  • T028 [US3] Implement [endpoint/feature] in src/[location]/[file].py

Checkpoint: All user stories should now be independently functional

[Add more user story phases as needed, following the same pattern]

Phase N: Polish & Cross-Cutting Concerns

Purpose: Improvements that affect multiple user stories

SOFTWARE PROJECTS:

  • TXXX [P] Documentation updates in docs/
  • TXXX Code cleanup and refactoring
  • TXXX Performance optimization across all stories
  • TXXX [P] Additional unit tests (if requested) in tests/unit/
  • TXXX Security hardening
  • TXXX Run quickstart.md validation

HARDWARE PROJECTS (Constitution Compliance):

  • TXXX [P] Verify all Amazon ASINs still valid and in stock (Constitution I)
  • TXXX Calculate final BOM cost and document (Constitution I)
  • TXXX Weigh final assembled device and verify <150g (Constitution III)
  • TXXX [P] Create assembly instructions with photos/diagrams (Constitution II)
  • TXXX [P] Document print settings for all STL files (Constitution II)
  • TXXX Create calibration procedure using household items (Constitution IV)
  • TXXX [P] Write troubleshooting guide for assembly errors (Constitution II)
  • TXXX Test firmware flash procedure on Windows, macOS, Linux (Constitution IV)
  • TXXX [P] Create example code for data reading (Python/JavaScript) (Constitution IV)
  • TXXX Verify setup procedure is 3 steps or fewer (Constitution IV)
  • TXXX [P] Document measurement accuracy and precision (Constitution II)
  • TXXX Verify firmware size under 80% flash capacity (Constitution IV)

Dependencies & Execution Order

Phase Dependencies

  • Setup (Phase 1): No dependencies - can start immediately
  • Foundational (Phase 2): Depends on Setup completion - BLOCKS all user stories
  • User Stories (Phase 3+): All depend on Foundational phase completion
    • User stories can then proceed in parallel (if staffed)
    • Or sequentially in priority order (P1 → P2 → P3)
  • Polish (Final Phase): Depends on all desired user stories being complete

User Story Dependencies

  • User Story 1 (P1): Can start after Foundational (Phase 2) - No dependencies on other stories
  • User Story 2 (P2): Can start after Foundational (Phase 2) - May integrate with US1 but should be independently testable
  • User Story 3 (P3): Can start after Foundational (Phase 2) - May integrate with US1/US2 but should be independently testable

Within Each User Story

  • Tests (if included) MUST be written and FAIL before implementation
  • Models before services
  • Services before endpoints
  • Core implementation before integration
  • Story complete before moving to next priority

Parallel Opportunities

  • All Setup tasks marked [P] can run in parallel
  • All Foundational tasks marked [P] can run in parallel (within Phase 2)
  • Once Foundational phase completes, all user stories can start in parallel (if team capacity allows)
  • All tests for a user story marked [P] can run in parallel
  • Models within a story marked [P] can run in parallel
  • Different user stories can be worked on in parallel by different team members

Parallel Example: User Story 1

# Launch all tests for User Story 1 together (if tests requested):
Task: "Contract test for [endpoint] in tests/contract/test_[name].py"
Task: "Integration test for [user journey] in tests/integration/test_[name].py"

# Launch all models for User Story 1 together:
Task: "Create [Entity1] model in src/models/[entity1].py"
Task: "Create [Entity2] model in src/models/[entity2].py"

Implementation Strategy

MVP First (User Story 1 Only)

  1. Complete Phase 1: Setup
  2. Complete Phase 2: Foundational (CRITICAL - blocks all stories)
  3. Complete Phase 3: User Story 1
  4. STOP and VALIDATE: Test User Story 1 independently
  5. Deploy/demo if ready

Incremental Delivery

  1. Complete Setup + Foundational → Foundation ready
  2. Add User Story 1 → Test independently → Deploy/Demo (MVP!)
  3. Add User Story 2 → Test independently → Deploy/Demo
  4. Add User Story 3 → Test independently → Deploy/Demo
  5. Each story adds value without breaking previous stories

Parallel Team Strategy

With multiple developers:

  1. Team completes Setup + Foundational together
  2. Once Foundational is done:
    • Developer A: User Story 1
    • Developer B: User Story 2
    • Developer C: User Story 3
  3. Stories complete and integrate independently

Notes

  • [P] tasks = different files, no dependencies
  • [Story] label maps task to specific user story for traceability
  • Each user story should be independently completable and testable
  • Verify tests fail before implementing
  • Commit after each task or logical group
  • Stop at any checkpoint to validate story independently
  • Avoid: vague tasks, same file conflicts, cross-story dependencies that break independence
Reference in New Issue View Git Blame Copy Permalink