Project Plan¶
Purpose¶
This document is the live execution plan for the MOTSEN TOOL project.
It tracks the milestones, open decisions, and known risks that drive the project forward. The three project phases (MVP, Full Feature Development, Productization) and the overall scope are defined in Project Definition. This document does not redefine them; it lists what must actually happen to complete each phase.
Planning Approach¶
The plan is milestone-driven, not date-driven:
Development cadence is irregular. Calendar dates are deliberately omitted.
A phase advances only when its phase-gate milestones have status
done.Later phases are intentionally lighter than Phase 1. Their milestones are placeholders that will be refined when the prior phase exits.
Open Decisions and Risks are reviewed at every phase gate.
Phase Overview¶
Phase |
Theme |
Exit Gate |
|---|---|---|
Phase 1 |
Proof of Concept (MVP) |
End-to-end sensor health check and Rs measurement on a real motor through the minimal UI |
Phase 2 |
Full Feature Development |
Full characterization suite, FOC, second MCU platform supported |
Phase 3 |
Productization |
Manufacturable product with documented service and production processes |
Phase 1 — MVP Milestones¶
Phase 1 milestones are grouped by theme. IDs are reserved with gaps so refinement does not require renumbering.
Documentation¶
Create top level project documentation (project plan and project definition) with enough detail to guide implementation and onboarding of new contributors. Output Documentation:
|
Create system-level documentation describing the architecture, interfaces, and design rationale of the project at a level that guides implementation and future maintenance. Output Documentation:
|
Create a document comparing candidate eval boards & motors against the project requirements and constraints, leading to a justified selection of the target hardware platform for Phase 1. Output Documentation:
|
Procurement and Setup¶
Procure selected eval board and motor, along with necessary accessories (power supply, connectors, etc.) to set up the initial test bench. |
Software Development¶
Bring-up procured eval board: toolchain setup, flashing, and basic I/O (GPIO toggle) verified. |
Add HAL & drivers for:
|
Hall sensor states are captured. A 6-state decoder produces commutation sector and inferred direction. Mechanical position is read successfully. |
The motor spins under open-loop sinusoidal commutation on the bench with an enforced current limit. |
The motor spins under closed-loop sinusoidal commutation on the bench with an enforced current limit. |
Communications and Host¶
A framed protocol is defined and implemented, supporting parameter read/write and a streaming log channel. |
A desktop application skeleton runs on the host PC, opens the serial/USB link to the firmware, and displays a main window. |
MVP Feature Development¶
Phase-sequence and Hall-alignment validation runs end-to-end from the desktop UI on a real motor and reports pass/fail with a clear diagnostic message on failure. |
The Rs measurement procedure is implemented. The result is validated against a known reference motor and falls within a documented tolerance. |
The full MVP demo runs end-to-end: connect motor, run sensor health check, run Rs measurement, view the report in the desktop UI. A non-author can reproduce the demo by following the documentation. |
Phase 2 — Full Feature Milestones¶
These milestones will be refined when Phase 1 exits. They need to be treat as placeholders for now, but they represent the intended scope of Phase 2.
Phase 3 — Productization Milestones¶
Phase Gate Criteria¶
Phase 1 exits when:
MIL_001 through MIL_014 are all
done.MIL_014 (MVP integration demo) is reproducible by a non-author.
Phase 2 exits when:
MIL_040 through MIL_048 are all
done.MIL_049 (Phase 2 acceptance demo) is signed off.
Phase 3 exits when:
MIL_070 through MIL_077 are all
done.MIL_078 (Phase 3 acceptance) is signed off, including a manufacturable build and documented production/service flows.
Risks¶
Long calendar gaps between work sessions cause loss of mental context and rework. Mitigation: every session ends with a short note in the docs capturing current state and the next concrete step. |
The HAL is designed for portability before a second MCU exists, leading to wasted effort and brittle abstractions. Mitigation: design the HAL to the minimum needed for Phase 1; revisit at MIL_048. |
Parameter estimation procedures (Rs, Ld, Lq, Kt) require more signal processing and calibration than expected. Mitigation: stage the work — Rs first, then Ld/Lq, then Kt — and validate each against a reference motor. |
Code and documentation drift apart, so the docs no longer describe what the project actually does. Mitigation: documentation changes ship in the same commits as the implementation changes that motivate them. |
Overcurrent, overspeed, or mechanical incidents during bench testing cause damage or injury. |
Traceability¶
Milestones in this document forward-link to system, hardware, and software requirements using
the linked_to and implemented_by link types defined in the project conf.py. At the
time of writing these links are mostly empty; they will be populated as the requirements
documents in 02_System, 03_Hardware, and 04_Software come online.
The intended traceability flow is:
Milestone (MIL_*)
│
├── System Requirement (SYS_*)
│
├── Hardware Requirement (HW_REQ_*)
│ └── Hardware Test Case (HW_TEST_*)
│
└── Software Requirement (SW_REQ_*)
└── Software Test Case (SW_TEST_*)