KL University · Y25 B.Tech T04 · Issued for academic execution
NUCLEO-H753ZI ML-ESD Learnathon + Hackathon
The governing implementation handbook for a 24-hour non-competitive Learnathon held four to five weeks before a separate 24-hour competitive Hackathon. It assigns one ESD Faculty Master and one ML Faculty Master to every problem family, defines technology learning, team problem-solving discussion, optional partial implementation, technical integrity, laboratory execution, assessment, 20 problem families, 200 assignable variants and the complete equipment schedule for every team.
This handbook shall be used by the department, faculty mentors, reviewers, laboratory staff and student teams to prepare, execute and assess the hackathon. Use the role routes below, the problem-family directory or the filters to reach the required instruction without reading the full document linearly.
ISSUEDFor academic execution 03 September 2026
Document authority and precedence: common electrical, mechanical, data-integrity and assessment rules apply to every assignment. The allocated variant defines the team-specific scenario, equipment and acceptance test. If a variant instruction conflicts with a common safety rule, the common safety rule prevails and the faculty safety officer shall resolve the conflict before work continues.
Finding an assignment: search by problem title, variant code, equipment code, ML task or hardware pack. The filtered index may be copied or exported as CSV for departmental allocation. Press / to focus search and Esc to clear it.
01 · Governance and operating authority
Roles, responsibilities and decision rights
The hackathon shall operate through named institutional roles. The same person may hold more than one role only when this does not compromise safety approval or independent assessment.
Role
Responsibilities before the event
Responsibilities during and after the event
Department Hackathon Coordinator
Approve the selected problem/variant pool, team list, panel plan, room plan, communications and issue schedule.
Control scope changes, resolve administrative escalations, consolidate scores and certify completion records.
Technical Lead
Freeze the board configuration, add-on packs, firmware starter, host logger, protocol version and approved ML list.
Resolve common technical blockers without implementing a team's solution; record any authorised common correction.
Laboratory Coordinator
Test, label and inventory boards, cables, sensors, drivers, fixtures, power supplies, tools, PPE and spares against the equipment manifests.
Issue and receive kits, maintain the fault/replacement log and keep organiser reference rigs available.
Safety Officer / Lab Technician
Inspect voltage compatibility, current limits, fusing, actuator guards, mechanical stops and physical E-stops.
Authorise first energisation, conduct safety spot checks and exercise unconditional stop-work authority.
Data and ML Coordinator
Release seed datasets, data dictionaries, split rules, metric scripts and the syllabus-aligned model whitelist.
Resolve common data/schema questions, protect hidden data and verify frozen evaluation outputs.
ESD Faculty Master (one per family)
Master the parent problem and all ten variants; validate the hardware, firmware, control, communication, safety and troubleshooting pathway; complete Faculty Master certification.
Guide the assigned family batch, conduct ESD readiness checks, witness live embedded evidence and score the ESD and integration criteria jointly with the ML Faculty Master.
ML Faculty Master (one per family)
Master the parent problem and all ten variants; validate data collection, labelling, leakage-safe splits, baselines, approved models, metrics and bounded decision policy; complete Faculty Master certification.
Guide the assigned family batch, conduct ML readiness checks, verify dataset/model provenance and score the ML and integration criteria jointly with the ESD Faculty Master.
Problem-family Faculty Pair
Prepare a single family mastery dossier covering all ten variants, equipment, reference implementation, public tests, hidden-test design, common misconceptions and escalation rules.
Guide ten teams, one team for each variant V1-V10, representing up to 40 students; supervise five teams in each competition wave; record guidance and exceptions; sign every Learnathon gate and final evaluation.
Review Panel
Calibrate interpretation of every rubric and receive standard score sheets and hidden-test protocols.
Witness live evidence, record criterion-wise marks and comments, and apply identical standards across teams.
Student Team (four students; three by approved exception)
Read the common rules and allocated brief; accept the kit only after verifying its manifest.
Build, test, document and demonstrate the system; preserve honest data provenance, individual contribution evidence and safe working practice.
Required allocation of work within every student team
Embedded systems owner
CubeMX/CubeIDE configuration, sensor acquisition, timers, PWM/control, state machine, watchdog and safe-state behaviour.
Data and ML owner
Run manifest, data quality, features, baseline, classical models, evaluation, limitations and model artefact.
Repository discipline, diagrams, review submissions, video logs, portfolio narrative and final presentation.
Evaluation authority: the ESD and ML Faculty Masters assigned to a family are its primary technical evaluators. Both shall sign integration and final scores. A central moderation panel may normalise rubric interpretation or hear a documented appeal, but shall not replace witnessed technical evidence.
Stop-work authority: the Safety Officer, Laboratory Coordinator, either Faculty Master or Review Panel may immediately de-energise a rig or suspend testing when wiring, power, guarding, thermal limits, mechanical force or team conduct is unsafe. Work resumes only after the corrective check is recorded.
Team-size operating rule: four students is the planning norm and is required to serve approximately 800 students through 200 unique assignments. A three-student team may be approved only for a documented roster shortfall; it combines integration/test with evidence/product ownership. A two-student team is not a normal allocation and may be approved only as a formal accommodation: one member owns embedded plus integration, the other owns ML plus evidence, and both share safety and demonstration duties. No team may exceed four. Any cohort above 800 requires an approved later wave or additional problem pool; a duplicate assignment shall not be introduced silently.
02 · Problem-family Faculty Master model
Forty Faculty Masters: one ESD and one ML expert for every problem family
The department shall nominate exactly 20 ESD Faculty Masters and 20 ML Faculty Masters. Each two-person Faculty Master pair owns one problem family and must be technically prepared to teach, troubleshoot and evaluate the parent statement and all ten variants without ambiguity.
ESD Faculty MasterHardware, firmware, control, communication and safety
One problem familyParent brief plus all ten technically distinct variants
ML Faculty MasterData, baselines, models, validation and bounded policy
Assigned batchTen teams and up to 40 students; one team for every variant
Joint evidenceLearnathon gates, 24-hour reviews, integrity checks and final score
Faculty mastery requirement before student allocation
Understand all eleven briefs
Explain the parent problem and every one of its ten variants, including what changes, why the change is meaningful, required equipment, target signal, nearest confuser, safety constraint and acceptance test.
Build the reference pathway
Verify sensor and actuator bring-up, deterministic control, telemetry, data schema, engineering baseline, at least two permitted ML models and one bounded end-to-end command.
Prepare instruction and diagnostics
Maintain a family teaching brief, annotated wiring diagram, known-fault list, troubleshooting tree, example dataset, evaluation notebook and variant-specific hidden-test plan.
Calibrate evaluation
Score a common sample submission independently, reconcile differences, agree evidence thresholds and document when a technical irregularity requires viva, retest or moderation.
Complete family allocation: every Faculty Master pair receives exactly ten teams. Assign V1 through V10 once each so that all ten variants are executed without repetition. Teams V1-V5 compete in Wave A and teams V6-V10 compete in Wave B. Each pair therefore guides approximately 40 students overall and evaluates five teams in each 24-hour wave.
Faculty Master nomination and family register
Code
Problem family
ESD Faculty Master
ML Faculty Master
Teams supervised
Variant responsibility
P01
MotorGuard — Multisignal Operating-State and Fault Classifier
To be nominated Name / Employee ID: __________________
To be nominated Name / Employee ID: __________________
10 teams Up to 40 students
One team each for V1-V10; V1-V5 in Wave A and V6-V10 in Wave B
P02
StartSense — Startup Signature Intelligence for Electric Drives
To be nominated Name / Employee ID: __________________
To be nominated Name / Employee ID: __________________
10 teams Up to 40 students
One team each for V1-V10; V1-V5 in Wave A and V6-V10 in Wave B
P03
LoadLens — Embedded Load Estimator and Safe Operating-Profile Selector
To be nominated Name / Employee ID: __________________
To be nominated Name / Employee ID: __________________
10 teams Up to 40 students
One team each for V1-V10; V1-V5 in Wave A and V6-V10 in Wave B
To be nominated Name / Employee ID: __________________
To be nominated Name / Employee ID: __________________
10 teams Up to 40 students
One team each for V1-V10; V1-V5 in Wave A and V6-V10 in Wave B
P20
TelemetrySense — Regime-Aware Sampling, Logging and Dataset-Quality Manager
To be nominated Name / Employee ID: __________________
To be nominated Name / Employee ID: __________________
10 teams Up to 40 students
One team each for V1-V10; V1-V5 in Wave A and V6-V10 in Wave B
Independence and boundaries: Faculty Masters may teach concepts, diagnose a documented blocker and release authorised common corrections. They shall not write a team's solution, provide hidden-test answers, tune one team privately against blind conditions or accept evidence they did not witness or verify.
03 · Institutional preparation and Faculty Master certification
Departmental readiness for two distinct 24-hour events
The Learnathon is one continuous 24-hour learning event scheduled four to five weeks before the competitive Hackathon. Faculty expertise, student allocation, learning stations, hardware rotations, starter resources, datasets and safety controls must therefore be ready before L0—not developed during the interval.
Deadline
Required institutional action
Release evidence
T-49 to T-42 days
Nominate 20 ESD and 20 ML Faculty Masters; assign one pair per problem family; issue all ten variants, equipment schedules, syllabus boundary and external references.
Signed Faculty Master register and family ownership matrix.
L0-14 to L0-8 days
Faculty pairs complete the reference pathway and prepare problem explanation, technology mini-lessons, guided ESD/ML exercises, troubleshooting demonstrations and solution-approach prompts for all ten variants.
Certified family learning dossier, verified demonstrations, teaching plan and facilitator rota.
L0-7 days
Freeze 200 four-student teams, ranked preferences, one unique family/variant per team, Faculty Master mapping and Wave A/Wave B competition roster.
Approved 800-student register, 200 unique assignment codes and signed integrity declaration.
L0-6 to L0-1 days
Test and label boards, packs and fixtures; install host toolchains; release pre-reading; prepare 100-team hardware and 100-team classroom/ML rotation stations; protect all competition-only assets.
Learnathon station plan, equipment acceptance record, learning-resource package and protected blind-test register.
L0 to L0+24 h
Conduct the complete 24-hour Learnathon using the common timetable, two hardware-learning rotations, four formative gates and final learning-action plan.
Attendance, L1-L4 rubrics, learning artefacts, optional partial-build record and learnathon-close archive.
L0+1 day to T-2 days
Run faculty office hours and remediation for unresolved concepts; permit study and generic practice while preserving the competition boundary. Revalidate kits and close organiser defects discovered during the Learnathon.
Remediation log, closed learning actions, common corrections register and updated organiser station plan.
T-1 day
Verify each team's Learnathon archive, dependencies and integrity declaration; seal Wave B repositories; release no blind scenario, target or hidden data.
Checksums, archive-verification record, eligible-team list and secured competition release.
T0(A) / T0(B)
Issue the correct wave's labelled board, pack, fixture, supply, PPE and blind-test envelope; verify power, network, panel and recording arrangements.
Station-ready checklist signed by the Laboratory Coordinator and Safety Officer.
Problem allocation and learning-station sequence
1 · Form and allocateComplete teams and assign one unique family/variant at least seven days before L0.
2 · Match resourcesAttach the exact EQ code, learning materials, laptop image and board count.
3 · Prepare rotationsFive teams per family use hardware while the other five attend ML/problem-learning studios.
4 · Verify and signRecord station, board/pack IDs, safety condition and team acknowledgement.
5 · Authorise learningPermit powered activity only after the Learnathon safety inspection.
Assignment release rule: no family or variant may be allocated until its Faculty Master pair can teach the problem and related technologies, its learning exercises are verified, and its equipment, public data, expected optional-build boundary and competition-only assets are separated. Organiser-supported assignments additionally require the named history, specimens, calibration set or repeatable fixture.
04 · 24-hour learning-first Learnathon
One intensive day to understand the problem, technologies and solution approach
The Learnathon is a separate 24-hour, non-competitive event held four to five weeks before the Hackathon. It resembles a Hackathon in duration, teamwork, energy and continuous engagement, but its purpose is fundamentally different: students learn everything needed to solve their assigned problem, question both Faculty Masters, practise the required ESD and ML technologies, discuss alternative approaches and leave with a defensible action plan. A partial solution may be built only if time remains; completion is neither expected nor rewarded.
Understand the needParent problem, variant distinction, physical process, stakeholder and success criteria
Learn ESDH753 peripherals, sensing, actuation, control, communication, safety and debugging
Design the approachTeam discussion, alternatives, architecture, experiments, integration and risk controls
Compete laterFour to five weeks later: blind execution, final product, reviews, hidden tests and ranking
Primary success measure: by H24 every member must be able to explain the problem and variant, identify the required technologies, describe the proposed sensing-control-data-ML-integration chain, justify the experimental plan, anticipate likely technical glitches and state how the MCU remains safe. The quantity of code or hardware completed is not a Learnathon success measure.
Common 24-hour Learnathon timetable
Elapsed time
Learning stage
Required activity
Formative evidence
H0:00-H1:00
Opening, learning contract and safety orientation
Confirm team, assignment, Faculty Master pair, learning objectives, permitted collaboration, equipment rules and the difference between learning evidence and competitive completion.
Attendance, team/assignment verification and safety acknowledgement.
H1:00-H4:00
Problem and variant deep-dive
Faculty pair explains the parent problem and all ten variants; each team studies its process, stakeholder, inputs/outputs, confusers, measurable target, equipment and alternative approaches.
Problem interpretation, technology map, questions log and initial solution hypotheses.
H4:00-H5:00
L1 · Problem Understanding Gate
Each of ten teams receives a five-minute teach-back plus feedback; the pair records misconceptions and required learning actions.
Completed L1 rubric and corrected problem/variant canvas.
H5:00-H9:00
Learning Rotation 1
V1-V5 teams undertake the guided H753/ESD laboratory with the ESD Master; V6-V10 teams undertake the data/ML learning studio with the ML Master.
Guided exercise results, annotated code/notebook, observations and doubt log.
H9:00-H13:00
Learning Rotation 2
Groups exchange stations: V6-V10 complete the H753/ESD laboratory and V1-V5 complete the data/ML studio. Rolling meal and rest breaks are scheduled within both rotations.
Every team completes both domain-learning exercises.
H13:00-H14:30
L2 ESD + L3 ML Learning Gates
The ESD Master evaluates embedded understanding while the ML Master evaluates ML understanding in parallel. Team members may split by assigned ownership; both records are reconciled afterward.
Completed L2 and L3 rubrics, misconception list and remediation actions.
H14:30-H19:30
Team problem-solving and approach studio
Teams compare alternatives, select a solution architecture, plan data generation and validation, identify risks and integration points, and consult both Masters. If learning objectives are secure and time remains, they may attempt a limited partial build.
L4 · Presentation-only Solution Approach and Learning-Synthesis Gate
Ten teams receive eight minutes plus panel buffer. Every registered student speaks, presents a distinct learning/contribution area and answers a directed question while the team defends its approach, ESD-ML connection, safety model, experiment plan and unresolved concepts.
Completed cumulative L4 team rubric, four individual presentation records and dated learning-action plan.
H21:00-H23:00
Learning showcase and Faculty Master clinic
Teams present one insight, one rejected approach and one expected technical glitch; Faculty Masters correct common misconceptions and prescribe shared or team-specific follow-up learning.
Reflection note, corrected action plan and recorded common FAQ.
H23:00-H24:00
Archive, individual reflection and close
Package learning artefacts, optional partial work, dependency list and contribution evidence; archive the state and acknowledge the inter-event integrity boundary.
learnathon-close tag, checksums, learning summary and both Faculty Master signatures.
How 200 teams use 120 boards during one Learnathon
Hardware-learning group
At any time, five teams per family use the 100-team hardware allocation. The four FDCAN families consume 40 boards and the sixteen single-board families consume 80, exactly matching the 120-board inventory.
ML/problem-learning group
The other five teams per family use laptops, seed datasets, architecture canvases and guided notebooks. After four hours the groups exchange stations, so all 200 teams receive both learning experiences.
Faculty pair deployment
During each rotation the ESD Master supervises five hardware teams and the ML Master supervises the other five learning teams. They exchange student groups at H9 and reunite for approach discussion and L4.
Capacity condition
The Learnathon requires 200 team laptops/approved shared computer positions, learning rooms for 100 teams, laboratory positions for 100 teams and the complete 120-board active allocation. If the venue cannot safely host 800 students, repeat this same 24-hour learning design in two equivalent batches.
Learnathon-to-Hackathon boundary
Required during the Learnathon
Problem mastery, variant distinction, technology learning, guided ESD and ML exercises, alternative-solution discussion, architecture, experiment plan, safety reasoning, integration concept, expected-glitch analysis and individual reflection.
Optional only after learning is secure
Limited board bring-up, one sensor trace, a small baseline notebook, protocol skeleton or other partial implementation. A team receives no additional Learnathon score for completing more of the final product.
Permitted in the four-to-five-week interval
Faculty-led remediation, study, generic technology exercises, clarification of concepts and correction of organiser-issued resources. Team-specific competition code, integrated hardware, training data and tuned model remain at the archived Learnathon state.
Reserved for the competitive Hackathon
Variant-specific completion, final physical trials and dataset, model/control tuning, full integration, hidden operating conditions, blind tests, final product polish, competitive review evidence, presentation and ranking.
Learnathon close and T-1 verification: at H24 each team creates an immutable learnathon-close tag, checksums its learning artefacts and any optional partial work, and obtains both Faculty Masters' signatures. At T-1 the same archive is verified. The Hackathon begins from that declared technical state plus centrally released competition materials; unrecorded pre-built solution work is inadmissible.
Non-competitive status: the Learnathon has no ranking, winner or advantage for the team that writes the most code. L1-L4 raw scores are formative indicators used to identify misconceptions and remediation; they are not added to the 100 Hackathon marks. Completion certificates, if issued, shall recognise participation and demonstrated learning rather than product performance.
24-hour duty of care: a 24-hour event does not require any student or faculty member to work continuously for 24 hours. Publish rolling meal, hydration and rest rotations; provide at least one protected 60-minute rest block; do not schedule more than six continuous hours of technical duty; and maintain staffed safety, laboratory and medical/escalation coverage throughout.
Learning takes priority over building: Faculty Masters shall not turn the Learnathon into a race to finish the product. They teach, demonstrate, question and diagnose. Teams must explore and understand before implementing. Hidden tests, final targets and competition data remain inaccessible until authorised release.
04A · Learnathon deliverables and formative rubrics
Four evidence gates that assess learning—not product completion
The four gates occur within the 24-hour Learnathon and deliberately increase in maturity: L1 establishes problem understanding; L2 closes L1 actions and verifies embedded learning; L3 closes relevant earlier actions and verifies data/ML learning; L4 is a presentation-only synthesis of the complete approach. No criterion awards marks for the quantity of final-product implementation completed.
Learnathon faculty review sheets4 landscape A4 sheets - L1 to L4 - one gate per page
Learning-status decision after each gate:LEARNING OUTCOMES ACHIEVED requires at least 40/50, no team criterion below 6, an individual-presentation mean of at least 6 at L4, and every named safety/integrity-critical criterion at 8 or 10. ACHIEVED WITH FOLLOW-UP requires at least 30 but below 40, no critical criterion below 6 and dated learning actions. REQUIRES REMEDIATION applies below 30, when any critical criterion scores 0-4, while a previous mandatory action remains unresolved, or when any registered student has not completed the L4 presentation. Competition eligibility requires L1-L4 participation and closure of all mandatory remediation by T-1; it does not require a completed or integrated product at the Learnathon.
L4 presentation-only rule: L4 is conducted only through the scheduled team presentation and panel questions. Faculty do not award an unseen artefact-only score. Every registered student must speak, explain a distinct contribution or learning responsibility and answer at least one directed question. The individual scores are averaged into one 10-point L4 component; the remaining four criteria contribute 40 points.
L1 · Problem Understanding Gate
Scoring rule: every listed team criterion is worth 10 raw points. The only permitted scores are 0, 2, 4, 6, 8 and 10. Tick exactly one fully defined descriptor in every row. When evidence falls between two anchors, select the lower anchor until every statement in the higher descriptor is demonstrated.
Gate dependency: Initial learning gate. Record every misconception and learning action; these become mandatory inputs to L2 and L3.
Safety/integrity-critical criterion: Inputs, outputs, confusers and success
Criterion and evidence benchmark
0 Absent / unsafe
2 Fragment only
4 Partial; major gaps
6 Working minimum
8 Complete; minor gaps
10 Verified; no material gap
Problem purpose and stakeholder Required evidence: Every member explains the real process/user need, system boundary, stakeholder consequence and why the problem is worth solving.
□Cannot explain problem purpose and stakeholder understanding; evidence is absent, unsafe or copied.
□Repeats brief terminology about problem purpose and stakeholder understanding, but cannot apply it to the assigned variant.
□Explains part of problem purpose and stakeholder understanding; a major misconception or member-level gap remains.
□Gives a basically correct assigned-variant explanation of problem purpose and stakeholder understanding; prompting is still needed.
□Correctly connects problem purpose and stakeholder understanding to the assigned problem with only a minor doubt.
□Every member independently teaches back problem purpose and stakeholder understanding, its limits and implications accurately.
Parent family and variant distinction Required evidence: The team explains the family objective, exactly what its variant changes, why that change is technically meaningful and how it differs from the other nine variants.
□Cannot explain family and variant distinction; evidence is absent, unsafe or copied.
□Repeats brief terminology about family and variant distinction, but cannot apply it to the assigned variant.
□Explains part of family and variant distinction; a major misconception or member-level gap remains.
□Gives a basically correct assigned-variant explanation of family and variant distinction; prompting is still needed.
□Correctly connects family and variant distinction to the assigned problem with only a minor doubt.
□Every member independently teaches back family and variant distinction, its limits and implications accurately.
Inputs, outputs, confusers and success Required evidence: Students identify observable signals, controllable outputs, target/labels, nearest misleading case and measurable success without assuming ML will solve undefined requirements.
□Cannot explain inputs, outputs, confusers and success; evidence is absent, unsafe or copied.
□Repeats brief terminology about inputs, outputs, confusers and success, but cannot apply it to the assigned variant.
□Explains part of inputs, outputs, confusers and success; a major misconception or member-level gap remains.
□Gives a basically correct assigned-variant explanation of inputs, outputs, confusers and success; prompting is still needed.
□Correctly connects inputs, outputs, confusers and success to the assigned problem with only a minor doubt.
□Every member independently teaches back inputs, outputs, confusers and success, its limits and implications accurately.
Technology-learning map Required evidence: The team lists the ESD, control, communication, data and ML concepts it must learn, separating already-known topics from genuine learning gaps.
□Cannot explain technology-learning map; evidence is absent, unsafe or copied.
□Repeats brief terminology about technology-learning map, but cannot apply it to the assigned variant.
□Explains part of technology-learning map; a major misconception or member-level gap remains.
□Gives a basically correct assigned-variant explanation of technology-learning map; prompting is still needed.
□Correctly connects technology-learning map to the assigned problem with only a minor doubt.
□Every member independently teaches back technology-learning map, its limits and implications accurately.
Questions, hypotheses and team learning plan Required evidence: Four members record questions, alternative hypotheses, role-based learning ownership and how each member will teach back their assigned knowledge.
□Cannot explain questions, hypotheses and team learning plan; evidence is absent, unsafe or copied.
□Repeats brief terminology about questions, hypotheses and team learning plan, but cannot apply it to the assigned variant.
□Explains part of questions, hypotheses and team learning plan; a major misconception or member-level gap remains.
□Gives a basically correct assigned-variant explanation of questions, hypotheses and team learning plan; prompting is still needed.
□Correctly connects questions, hypotheses and team learning plan to the assigned problem with only a minor doubt.
□Every member independently teaches back questions, hypotheses and team learning plan, its limits and implications accurately.
Learnathon use: raw total ___ / 50. This is formative learning evidence, not a competition mark. Tick one cell per row, record learning/remediation actions and apply the published Learnathon learning-status rule.
Scoring rule: every listed team criterion is worth 10 raw points. The only permitted scores are 0, 2, 4, 6, 8 and 10. Tick exactly one fully defined descriptor in every row. When evidence falls between two anchors, select the lower anchor until every statement in the higher descriptor is demonstrated.
Gate dependency: Cumulative gate. Verify closure of L1 actions before assessing embedded-systems learning. An open safety misconception forces REQUIRES REMEDIATION.
Safety/integrity-critical criterion: Safety, watchdog and fallback understanding
Criterion and evidence benchmark
0 Absent / unsafe
2 Fragment only
4 Partial; major gaps
6 Working minimum
8 Complete; minor gaps
10 Verified; no material gap
Closure of L1 actions and H753 assignment map Required evidence: Faculty verify the corrected L1 canvas and close every mandatory L1 action; the team then maps its exact sensors, drivers, ADC/GPIO/timer/PWM/encoder, USART/FDCAN and watchdog needs to the NUCLEO-H753ZI.
□No safe or credible closure of L1 actions and H753 assignment mapping; a prior critical misconception remains unresolved.
□Names vocabulary for closure of L1 actions and H753 assignment mapping, but cannot perform or explain the guided task.
□Shows a guided fragment of closure of L1 actions and H753 assignment mapping; a major prior action or current concept gap remains.
□Closes prior critical actions and performs the minimum closure of L1 actions and H753 assignment mapping task with prompts.
□Closes prior actions and demonstrates complete assignment-linked closure of L1 actions and H753 assignment mapping; only a minor gap remains.
□Independently applies, diagnoses and transfers closure of L1 actions and H753 assignment mapping to the proposed solution with repeatable evidence.
Sensor, driver and electrical reasoning Required evidence: The team explains signal conditioning, 0-3.3 V compatibility, external actuator power, driver protection, grounding and calibration for its issued pack.
□No safe or credible sensor, driver and electrical reasoning; a prior critical misconception remains unresolved.
□Names vocabulary for sensor, driver and electrical reasoning, but cannot perform or explain the guided task.
□Shows a guided fragment of sensor, driver and electrical reasoning; a major prior action or current concept gap remains.
□Closes prior critical actions and performs the minimum sensor, driver and electrical reasoning task with prompts.
□Closes prior actions and demonstrates complete assignment-linked sensor, driver and electrical reasoning; only a minor gap remains.
□Independently applies, diagnoses and transfers sensor, driver and electrical reasoning to the proposed solution with repeatable evidence.
Deterministic control and state logic Required evidence: Students can trace the sample/control period, bounded state machine, rule/PID baseline and why critical behaviour cannot depend on host timing.
□No safe or credible deterministic control and state logic; a prior critical misconception remains unresolved.
□Names vocabulary for deterministic control and state logic, but cannot perform or explain the guided task.
□Shows a guided fragment of deterministic control and state logic; a major prior action or current concept gap remains.
□Closes prior critical actions and performs the minimum deterministic control and state logic task with prompts.
□Closes prior actions and demonstrates complete assignment-linked deterministic control and state logic; only a minor gap remains.
□Independently applies, diagnoses and transfers deterministic control and state logic to the proposed solution with repeatable evidence.
Safety, watchdog and fallback understanding Required evidence: The team explains numeric limits, interlocks, E-stop, watchdog, stale-command and host-loss behaviour and demonstrates them on the guided reference exercise.
□No safe or credible safety, watchdog and fallback understanding; a prior critical misconception remains unresolved.
□Names vocabulary for safety, watchdog and fallback understanding, but cannot perform or explain the guided task.
□Shows a guided fragment of safety, watchdog and fallback understanding; a major prior action or current concept gap remains.
□Closes prior critical actions and performs the minimum safety, watchdog and fallback understanding task with prompts.
□Closes prior actions and demonstrates complete assignment-linked safety, watchdog and fallback understanding; only a minor gap remains.
□Independently applies, diagnoses and transfers safety, watchdog and fallback understanding to the proposed solution with repeatable evidence.
Telemetry and debugging practice Required evidence: Students interpret a versioned telemetry trace, identify IDs/timestamps/units/state/fault/acknowledgement fields and diagnose at least one guided defect.
□No safe or credible telemetry and debugging practice; a prior critical misconception remains unresolved.
□Names vocabulary for telemetry and debugging practice, but cannot perform or explain the guided task.
□Shows a guided fragment of telemetry and debugging practice; a major prior action or current concept gap remains.
□Closes prior critical actions and performs the minimum telemetry and debugging practice task with prompts.
□Closes prior actions and demonstrates complete assignment-linked telemetry and debugging practice; only a minor gap remains.
□Independently applies, diagnoses and transfers telemetry and debugging practice to the proposed solution with repeatable evidence.
Learnathon use: raw total ___ / 50. This is formative learning evidence, not a competition mark. Tick one cell per row, record learning/remediation actions and apply the published Learnathon learning-status rule.
Scoring rule: every listed team criterion is worth 10 raw points. The only permitted scores are 0, 2, 4, 6, 8 and 10. Tick exactly one fully defined descriptor in every row. When evidence falls between two anchors, select the lower anchor until every statement in the higher descriptor is demonstrated.
Gate dependency: Cumulative gate. Verify relevant L1 and L2 actions before assessing data and ML learning. Open provenance, leakage or bounded-action misconceptions force REQUIRES REMEDIATION.
Safety/integrity-critical criterion: Data provenance, quality and split; prediction-to-bounded-action reasoning
Criterion and evidence benchmark
0 Absent / unsafe
2 Fragment only
4 Partial; major gaps
6 Working minimum
8 Complete; minor gaps
10 Verified; no material gap
Closure of L1-L2 actions and ML formulation Required evidence: Faculty verify closure of all relevant problem/embedded learning actions; the team then chooses classification, regression, anomaly analysis or constrained selection and distinguishes features, target, prediction horizon and decision output.
□No safe or credible closure of L1-L2 actions and problem-to-ML formulation; a prior critical misconception remains unresolved.
□Names vocabulary for closure of L1-L2 actions and problem-to-ML formulation, but cannot perform or explain the guided task.
□Shows a guided fragment of closure of L1-L2 actions and problem-to-ML formulation; a major prior action or current concept gap remains.
□Closes prior critical actions and performs the minimum closure of L1-L2 actions and problem-to-ML formulation task with prompts.
□Closes prior actions and demonstrates complete assignment-linked closure of L1-L2 actions and problem-to-ML formulation; only a minor gap remains.
□Independently applies, diagnoses and transfers closure of L1-L2 actions and problem-to-ML formulation to the proposed solution with repeatable evidence.
Data provenance, quality and split Required evidence: Students explain run IDs, physical/seed provenance, calibration, missing/outlier checks and why train/test separation must occur by run, session or specimen.
□No safe or credible data provenance, quality and split understanding; a prior critical misconception remains unresolved.
□Names vocabulary for data provenance, quality and split understanding, but cannot perform or explain the guided task.
□Shows a guided fragment of data provenance, quality and split understanding; a major prior action or current concept gap remains.
□Closes prior critical actions and performs the minimum data provenance, quality and split understanding task with prompts.
□Closes prior actions and demonstrates complete assignment-linked data provenance, quality and split understanding; only a minor gap remains.
□Independently applies, diagnoses and transfers data provenance, quality and split understanding to the proposed solution with repeatable evidence.
Engineering baseline and feature reasoning Required evidence: The team creates or interprets a simple physical baseline and justifies candidate raw/window features from the process rather than from convenience.
□No safe or credible baseline and feature reasoning; a prior critical misconception remains unresolved.
□Names vocabulary for baseline and feature reasoning, but cannot perform or explain the guided task.
□Shows a guided fragment of baseline and feature reasoning; a major prior action or current concept gap remains.
□Closes prior critical actions and performs the minimum baseline and feature reasoning task with prompts.
□Closes prior actions and demonstrates complete assignment-linked baseline and feature reasoning; only a minor gap remains.
□Independently applies, diagnoses and transfers baseline and feature reasoning to the proposed solution with repeatable evidence.
Model, metric and error understanding Required evidence: Students run guided examples with two permitted classical models and explain suitable safety/operational metrics, overfitting, baseline comparison and representative error cases.
□No safe or credible model, metric and error understanding; a prior critical misconception remains unresolved.
□Names vocabulary for model, metric and error understanding, but cannot perform or explain the guided task.
□Shows a guided fragment of model, metric and error understanding; a major prior action or current concept gap remains.
□Closes prior critical actions and performs the minimum model, metric and error understanding task with prompts.
□Closes prior actions and demonstrates complete assignment-linked model, metric and error understanding; only a minor gap remains.
□Independently applies, diagnoses and transfers model, metric and error understanding to the proposed solution with repeatable evidence.
Prediction-to-bounded-action reasoning Required evidence: The team maps output to the canonical command subset, explains confidence/abstention and shows why H753 validation and conservative fallback remain mandatory.
□No safe or credible prediction-to-bounded-action reasoning; a prior critical misconception remains unresolved.
□Names vocabulary for prediction-to-bounded-action reasoning, but cannot perform or explain the guided task.
□Shows a guided fragment of prediction-to-bounded-action reasoning; a major prior action or current concept gap remains.
□Closes prior critical actions and performs the minimum prediction-to-bounded-action reasoning task with prompts.
□Closes prior actions and demonstrates complete assignment-linked prediction-to-bounded-action reasoning; only a minor gap remains.
□Independently applies, diagnoses and transfers prediction-to-bounded-action reasoning to the proposed solution with repeatable evidence.
Learnathon use: raw total ___ / 50. This is formative learning evidence, not a competition mark. Tick one cell per row, record learning/remediation actions and apply the published Learnathon learning-status rule.
L4 · Solution Approach and Learning-Synthesis Gate
Scoring rule: every listed team criterion is worth 10 raw points. The only permitted scores are 0, 2, 4, 6, 8 and 10. Tick exactly one fully defined descriptor in every row. When evidence falls between two anchors, select the lower anchor until every statement in the higher descriptor is demonstrated.
Gate dependency: Cumulative, presentation-only gate. The team must close or explicitly schedule every L1-L3 action and defend its complete solution approach through the scheduled team presentation and questions.
Safety/integrity-critical criterion: Closure of L1-L3 learning actions; end-to-end architecture and integration contract; experiment, failure and follow-up plan
Criterion and evidence benchmark
0 Absent / unsafe
2 Fragment only
4 Partial; major gaps
6 Working minimum
8 Complete; minor gaps
10 Verified; no material gap
Closure of L1-L3 learning actions Required evidence: The presentation identifies every earlier misconception/action, demonstrates what was learned, distinguishes closed actions from dated follow-up and leaves no safety, provenance or bounded-integration misconception unresolved.
□No credible presentation evidence for closure of L1-L3 learning actions; unsafe, fabricated or not attempted.
□Mentions fragments of closure of L1-L3 learning actions; cannot defend a coherent approach or close prior actions.
□Presents partial closure of L1-L3 learning actions; major learning, feasibility or traceability gaps remain.
□Defends a workable minimum for closure of L1-L3 learning actions; critical learning actions are closed but prompting is needed.
□Presents integrated, evidence-led closure of L1-L3 learning actions; prior actions are closed and only minor gaps remain.
□Defends rigorous, traceable closure of L1-L3 learning actions independently under questions, including trade-offs and limits.
Solution alternatives and decision rationale Required evidence: The team compares at least two credible approaches, records trade-offs and selects an approach for technical reasons rather than copying a reference design.
□No credible presentation evidence for solution alternatives and decision rationale; unsafe, fabricated or not attempted.
□Mentions fragments of solution alternatives and decision rationale; cannot defend a coherent approach or close prior actions.
□Presents partial solution alternatives and decision rationale; major learning, feasibility or traceability gaps remain.
□Defends a workable minimum for solution alternatives and decision rationale; critical learning actions are closed but prompting is needed.
□Presents integrated, evidence-led solution alternatives and decision rationale; prior actions are closed and only minor gaps remain.
□Defends rigorous, traceable solution alternatives and decision rationale independently under questions, including trade-offs and limits.
End-to-end architecture and integration contract Required evidence: The proposed physical-process-to-H753-to-data-to-model-to-canonical-command path is coherent, and MCU authority, messages and responsibilities are explicit.
□No credible presentation evidence for end-to-end architecture and integration contract; unsafe, fabricated or not attempted.
□Mentions fragments of end-to-end architecture and integration contract; cannot defend a coherent approach or close prior actions.
□Presents partial end-to-end architecture and integration contract; major learning, feasibility or traceability gaps remain.
□Defends a workable minimum for end-to-end architecture and integration contract; critical learning actions are closed but prompting is needed.
□Presents integrated, evidence-led end-to-end architecture and integration contract; prior actions are closed and only minor gaps remain.
□Defends rigorous, traceable end-to-end architecture and integration contract independently under questions, including trade-offs and limits.
Experiment, failure and follow-up plan Required evidence: The team defines repeatable trials, labels/targets, baseline comparison, nearest-confuser and safe-fault tests, metrics, recovery evidence, likely technical glitches, diagnostic order and dated post-Learnathon actions.
□No credible presentation evidence for experiment, failure and follow-up planning; unsafe, fabricated or not attempted.
□Mentions fragments of experiment, failure and follow-up planning; cannot defend a coherent approach or close prior actions.
□Presents partial experiment, failure and follow-up planning; major learning, feasibility or traceability gaps remain.
□Defends a workable minimum for experiment, failure and follow-up planning; critical learning actions are closed but prompting is needed.
□Presents integrated, evidence-led experiment, failure and follow-up planning; prior actions are closed and only minor gaps remain.
□Defends rigorous, traceable experiment, failure and follow-up planning independently under questions, including trade-offs and limits.
Individual presentation-skills rubric - completed for every registered student
Best-fit dimensions: clarity and structure; technical accuracy; evidence use; ownership of the stated contribution; response to questions; professional delivery, timing and hand-off. Tick one holistic anchor for each student. When dimensions fall at different levels, select the lower level until the higher anchor is fully demonstrated.
Score
Observable individual evidence
0
Absent, refuses the assigned segment, cannot state an own contribution, or makes unsafe/fabricated claims.
2
Reads or repeats a fragment; cannot explain the assigned work or answer one basic question.
4
Partial or unclear explanation with major technical errors; depends on teammates to answer.
6
Explains the assigned contribution and answers basic questions, but needs prompting or misses a material limitation.
8
Structured, confident and evidence-led; connects own work to the system and answers independently with only minor gaps.
10
Concise, technically precise and persuasive; independently handles probing questions, trade-offs and limitations.
Student
Contribution presented
0
2
4
6
8
10
Student 1 Name / registration no.: ____________________
Individual-presentation component: add the scores of all registered team members and divide by the number of registered members = ______ / 10. Transfer this exact mean, including a decimal where applicable, into the gate raw total. An absent registered member scores 0. For an approved three-member team, average the three registered students; do not create a fourth-student penalty.
Learnathon use: raw total ___ / 50. This is formative learning evidence, not a competition mark. Tick one cell per row, record learning/remediation actions and apply the published Learnathon learning-status rule.
05 · Technical integrity, originality and fair evaluation
Evidence controls that distinguish collaboration, common scaffolds and copying
Teams may learn together and use organiser-issued starter code, datasets and templates. Assessment credit is awarded only for traceable team-authored engineering, genuine measurements, defensible model decisions and live individual understanding.
Control
Required implementation
Faculty verification
Unique assignment identity
Every artefact carries team ID, family/variant code, member IDs, board serial(s), equipment code, dataset version and run/session IDs.
Faculty pair checks consistency across repository, telemetry, notebook, video and score sheet.
Variant separation
Within every family, allocate exactly one team to each of V1-V10. V1-V5 enter Wave A and V6-V10 enter Wave B; no variant is repeated within that family.
The master assignment register proves complete one-to-one coverage of all 200 family/variant codes.
Continuous provenance
Use named Git commits throughout the Learnathon and Hackathon; preserve raw telemetry unchanged; retain scripts that generate processed data and results.
Review commit chronology, raw-to-result reproducibility and timestamps at every gate.
Common-code exclusion
Organiser starter code and declared third-party libraries are identified in a manifest and excluded from student-authored similarity review.
Similarity is a reason for technical viva or live retest, never automatic proof of misconduct.
Individual technical viva
Any member may be asked to explain a signal path, modify a parameter safely, rerun one test, interpret an error or defend a model choice.
Material inability to explain claimed work is documented and escalated under university rules.
Result anomaly review
Unexpectedly identical raw data, plots, metrics, confusion matrices, errors, code structure or videos across teams trigger provenance verification.
Both Masters preserve the evidence, hear each team separately and refer unresolved cases to the central integrity/moderation panel.
Guidance log
Faculty Masters record batch teaching, team-specific interventions, released corrections, hardware replacements and authorised scope changes.
The log prevents legitimate common guidance from being confused with private solution assistance.
Evaluation workflow: the ESD Master verifies embedded and safety evidence; the ML Master verifies data and model evidence; both jointly witness integration and sign the final score. Disagreement is resolved using the rubric and preserved evidence, with central moderation only when necessary.
Due process: suspected copying or malpractice shall be recorded factually and handled through the applicable university procedure. No score penalty shall be based only on automated similarity, appearance, shared starter code or an unverified allegation.
Two-wave embargo: from team allocation until Wave B closes, all repositories, notebooks, datasets, videos and test observations remain private to the team and authorised faculty. Sharing Wave A blind conditions, results or artefacts with Wave B teams is prohibited. Public GitHub/Kaggle release may begin only after the Coordinator lifts the embargo and the faculty pair completes safety, privacy and attribution review.
Freeze and correction rule: define separate starts T0(A) and T0(B). The common starter package, schema, rubric and public tests freeze at T−1(A). Wave B repositories remain sealed/read-only until T0(B). Only a centrally approved correction necessary for fairness or safety may be applied to both waves; its file hash, reason, approver and release time shall be logged. No Wave-A-derived tuning, labels or hidden-test knowledge may be added to Wave B.
06 · Approved hardware platform
NUCLEO-H753ZI laboratory platform and implementation contract
The prescribed controller for every assignment is the NUCLEO-H753ZI based on the MB1364E Nucleo-144 board. The board provides the STM32H753 microcontroller and development interface; the department shall issue the sensors, drivers, physical process fixtures, protection and power resources listed for the allocated problem or variant.
Provided on the boardSTM32H753ZIT6 MCU, STLINK-V3E programmer/debugger, default Virtual COM Port, three user LEDs, USER/RESET buttons, 10/100 Ethernet PHY and RJ45, USB OTG FS, LSE crystal, and Zio/Arduino and ST morpho expansion headers.
Issued for the assignmentProcess sensors, potentiometer/LDR/temperature modules, motor or servo, motor/relay/MOSFET driver, encoder, current sensing, I2C display, external actuator supply, E-stop and mechanical fixture as listed in the applicable EQ schedule.
Physical FDCAN requirementThe MCU contains two FDCAN controller peripherals. Each network node additionally requires a compatible CAN/CAN-FD transceiver with 3.3-V-compatible logic I/O and its manufacturer-specified bus-side supply, twisted-pair wiring and correct end termination.
Electrical and actuation limitNo GPIO shall directly power a motor, relay coil, servo or heater. External signals shall comply with the documented 0-3.3 V interface contract, and every actuator shall use the approved driver and protected supply.
System architecture requirement: deterministic acquisition, control, watchdogs, command validation and hard interlocks shall run on the NUCLEO-H753ZI. Classical-ML training and inference shall run on the team laptop and may return only a bounded state or approved profile.
Board allocation requirement: all 200 teams cannot compete simultaneously on the existing 120 boards. The approved existing-inventory model uses two equivalent 24-hour waves of 100 teams. Each wave requires exactly 120 boards: 80 boards for the sixteen single-board families and 40 boards for the four twin-board FDCAN families. No board remains as a spare; the department should arrange a separate contingency pool or procure/borrow additional units.
07 · Board capabilities and implementation boundaries
How the NUCLEO-H753ZI shall be used
Resource
Verified capability
Hackathon use
Boundary / pitfall
Compute and memory
Arm Cortex-M7 up to 480 MHz; 2 MB Flash; 1 MB RAM; FPU and caches.
Deterministic control, signal aggregation, timestamping, safety state machine and buffered telemetry.
Compute headroom is not permission to mandate TinyML; model inference remains host-side.
Analog acquisition
Three ADCs, up to 16-bit resolution and 36 channels; timer triggering and DMA are available.
Temperature, light, potentiometer, conditioned current and other 0–3.3 V signals.
Sensor output must be conditioned to the ADC range. DMA/cache handling is permitted only with organiser-provided starter code if used.
Timers and control
Advanced/general-purpose timers, PWM, encoder input, input capture and two watchdogs.
Safety-critical timing cannot use blocking delays or depend on laptop response time.
Host telemetry
STLINK-V3E exposes a default USART3 Virtual COM Port; LEDs and USER button are onboard.
Default one-board path for CSV/binary telemetry, commands, bring-up and visible state indication.
USART3 uses PD8/PD9 by default; teams must not silently reassign those pins.
FDCAN
Two CAN-FD controllers in the MCU.
Two-node heartbeat, telemetry, bounded command/acknowledgement and fault-diagnosis families.
External transceivers and termination are mandatory; software loopback is not accepted as the final network demo.
Ethernet
Onboard 10/100 PHY and RJ45 through RMII.
Optional local-only UDP/TCP telemetry mirror or evaluator dashboard extension.
Outside the core syllabus; no cloud requirement. CubeMX pin/resource conflicts must be checked.
USB OTG FS
Micro-AB target connector plus onboard power switch.
Optional local log export or USB-device extension when organiser starter code is supplied.
CN13 cannot power the board; power the Nucleo first before connecting CN13.
Expansion and voltage
ST Zio/Arduino-compatible and ST morpho headers expose MCU I/O.
Standardised harnesses for sensor, motor, display and transceiver packs.
The H7 I/O interface is 3.3 V. Every 5 V module needs verified logic compatibility or level shifting.
Board power measurement
JP4 supports MCU-current measurement.
Faculty-only characterization or an optional energy experiment with an approved instrument.
Students must not remove JP4 casually; without an ammeter path the MCU is unpowered.
Primary board references: ST NUCLEO-H753ZI product page; UM2407 Rev 6 for MB1364; STM32H753xI datasheet. Final pin assignment must be exported from the team’s own CubeMX project and checked against the MB1364E board functions.
08 · Standard laboratory expansion packs
Four add-on packs support the complete challenge bank
The Nucleo board is common to all teams. The organiser issues only the add-on pack required by the allocated family. Parts must be pre-tested, keyed where possible and electrically protected.
H753-S · Sense and display pack
3.3-V-compatible potentiometer; LDR divider; two temperature channels or one process plus ambient channel; I²C LCD/OLED with verified 3.3-V bus levels; breadboard/harness; push-button/E-stop input; reference resistor; safe stimulus fixtures. Used by 9–12 and 20, and as context sensing in other families.
Family usage: Core for P06 and P09–P13, P16 and P20; also issued as variant-specific context sensing for selected P15/P17 assignments.
H753-M · Motion and control pack
Low-voltage geared DC motor with encoder and guarded fixture; 3.3-V-logic H-bridge; conditioned 0–3.3 V current signal; external fused motor supply; servo where applicable; temperature sensor on motor/driver; physical E-stop. Used by 1–8, 18 and 19.
Family usage: Core for P01–P08 and P18–P19; issued from the variant-module reserve for selected P15/P17 and any motor-based P20 assignment.
H753-A · Safe actuation pack
3.3-V-compatible relay/MOSFET driver with flyback protection; low-voltage fan/lamp/resistive load; response sensor; fused external supply; terminal protection and minimum-dwell firmware. Used by 9, 11, 13 and selected 15/17 variants.
Family usage: Core for P09, P11 and P13; issued from the variant-module reserve for selected P15/P17 assignments.
H753-N · Twin-node FDCAN pack
Two NUCLEO-H753ZI boards; two CAN/CAN-FD transceiver with 3.3-V-compatible logic I/O and its manufacturer-specified bus-side supply modules; twisted-pair harness; two removable 120 Ω terminators; common reference/approved isolation arrangement; USB cables and a trace/logger path. Used by 14–17.
Family usage: Core for every P14–P17 assignment; one complete two-node set per active team.
Board-only limitation: LEDs, the USER button and VCP are sufficient for bring-up and protocol exercises, but not for a portfolio-grade physical smart-system challenge. A family cannot be assigned until its add-on pack and fixture have passed the organiser acceptance test.
Common electrical acceptance checklist
Check
Release condition
Logic levels
All external outputs into the Nucleo are measured within 0–3.3 V; I²C pull-ups are not tied to 5 V.
Actuator power
Motor/servo/fan/heater power is external, current-limited and fused; grounds and isolation follow the approved rig diagram.
Inductive protection
Approved driver stage, flyback path and emergency stop are present; no coil is driven from a GPIO.
CAN physical layer
One transceiver per node, correct common reference/isolated wiring, exactly two active 120 Ω end terminations and verified bit timing.
Watchdog, hard limits, command expiry, illegal-ID rejection and host-loss safe state demonstrated before ML integration.
Numeric safe-operating envelope
Hazard
Institutional ceiling for this event
Required control
Electrical supply
SELV DC only; actuator/load supply not above 12 V DC; bench current limit not above 3 A per team
Use the lower component/driver/fixture rating, correctly sized branch fuse, touch-safe terminals and an accessible master disconnect.
Thermal exposure
Accessible surface target not above 45 °C; independent shutdown no higher than 50 °C
Guard heat sources, mount a verified independent sensor and test the hard cutoff before ML is connected.
Motion/contact
Accessible actuator force not above 10 N and only low stored-energy fixtures
Guard pinch/rotating points, bound speed/travel in firmware, fit mechanical stops and retain physical E-stop authority.
Component current
At or below the lowest continuous rating in the complete load/driver/wiring path
Record the numeric trip value and trip delay in the rig release sheet; deliberate destructive stall testing is prohibited.
Lower limit wins: these are maximum event ceilings, not permission to operate every rig at them. Before first energisation, the Safety Officer shall sign a rig-specific safe-operating-envelope sheet listing voltage, current, temperature, motion/force, fuse, trip time and emergency-stop values. Manufacturer ratings and fixture-specific risk controls may only reduce these limits.
09 · Team equipment issue policy
A complete equipment manifest for every assignment
A team contains four students as the planning norm; three only by approved roster exception. Every core problem below has its own family BOM, and every variant has a separate complete BOM. The variant table is controlling: it already repeats the controller, host, sensors, actuator, fixture, power, tools and support assets required by that team.
1 · ComputeOne team laptop and one H753 board—or two boards for Families 14–17.
2 · ObserveExact conditioned sensors, feedback devices and calibration references.
3 · ActuateOnly the named low-voltage driver, load and bounded actuator.
4 · ReproduceGuarded fixture, specimens, loads and labelled fault inserts.
5 · ProtectSeparate fused supply, hard cut-off, DMM, tools and PPE.
Rule
What the organiser must do
What the team must verify
Quantities
Every quantity in a family/variant schedule is for one team, not one student. Four pairs of eye protection are listed because PPE is individual.
Count and sign the kit manifest at H0:00; report any substitution before wiring.
Complete variant BOM
Pack the complete variant table. Do not issue both the parent fixture and a replacement fixture named by the variant. When the fixture row describes a sensor or actuator mounted in it, that is the same unit listed in the sensor/actuator row—not an additional copy.
Use only the declared fixture/specimens; an improvised fault or hand-applied obstruction is invalid.
Safe interfaces
Pre-test every sensor output and digital interface at 0–3.3 V. Preassemble motor/load power paths with screw terminals, fuse and cutoff.
Motor, relay, servo, fan and heater current never passes through a GPIO or signal-only breadboard.
Shared instruments
Provide at least one two-channel oscilloscope plus one logic analyser/CAN-observation station per eight teams, and one supervised rework station per room.
A DMM remains inside every team kit; shared instruments are booked only for timing/electrical debugging.
Substitution
Use an equivalent only if voltage, current, logic level, range, bandwidth and safety rating meet or exceed the listed specification. A slash such as MOSFET/relay means issue one approved alternative—not both—and freeze it on the signed manifest.
Record manufacturer/part number, range, calibration and wiring changes in the repository.
Universal prohibition: no mains-connected load, exposed hot surface, unguarded blade/shaft, laser, hand-held obstruction, destructive ageing, or external signal above the approved 0–3.3 V interface is permitted.
10 · Deployment of the 120-board inventory
Two-wave deployment of 200 teams using the 120-board inventory
Approximately 800 students at a maximum of four students per team produce 200 teams. Every one of the 200 variants is assigned exactly once. Because 40 FDCAN variants require two boards, the complete assignment bank represents 240 board allocations and cannot run simultaneously on 120 boards.
Approximately 800 studentsFour students is the planning norm; three only by approved roster exception
200 student teamsOne unique family/variant code per team
20 problem familiesTen teams and one ESD-ML Faculty Master pair per family
10 variants per familyV1-V10 assigned once; no duplicate within the family
Two competition wavesFive teams per family and 100 teams per wave
Exact team, faculty and board mapping
Execution group
Families
Teams per family
Teams per wave
Boards per wave
Single-board families
P01-P13 and P18-P20: 16 families
10 total: five in each wave
80
80
Twin-board FDCAN families
P14-P17: 4 families
10 total: five in each wave
20
40
Total per wave
All 20 families
Five active teams per family
100
120
Total programme
20 families x 10 variants
Ten teams per Faculty Master pair
200 across two waves
240 board allocations, fulfilled through reuse
Variant-to-wave rule
Wave A: first 100 teams
For every family P01-P20, allocate variants V1-V5. Each Faculty Master pair evaluates five teams, normally up to 20 students. Wave A receives blind-test pack A.
Wave B: second 100 teams
For every family P01-P20, allocate variants V6-V10. Each Faculty Master pair evaluates the remaining five teams, normally up to 20 students. Wave B receives an equivalent but non-identical blind-test pack B.
Board turnaround between waves
1 · Close Wave AReceive kits, export evidence and sign condition records
2 · InspectElectrical, mechanical, connector and peripheral checks
3 · SanitiseErase team firmware/data and restore the controlled base image
4 · RepackMatch boards, packs and fixtures to Wave B manifests
5 · Release Wave BNew signatures, new blind pack and identical scoring conditions
Learnathon hardware rotation: the single 24-hour Learnathon serves all 200 teams through two four-hour rotations. During H5-H9, V1-V5 teams in each family use the hardware stations while V6-V10 teams use ML/problem-learning stations; during H9-H13 they exchange. At most 100 teams and exactly 120 boards are active in hardware learning at one time. Optional partial work remains in the team's own repository and is archived at H24.
Zero-spare risk: 100 teams consume all 120 boards in each wave. For reliable execution, arrange at least 12 additional compatible boards as a contingency pool or maintain pre-authorised replacement capacity from another laboratory. If neither is possible, the coordinator must establish a documented rapid-repair and rescheduling protocol before allocation.
Minimum active add-on inventory per 100-team wave
Issued resource
Minimum active quantity per wave
Families covered
Planning requirement
H753-M motion/control sets
50
P01-P08, P18-P19 as mapped
Low-voltage motor/fixture, 3.3-V driver, encoder/tachometer, current sensing, fused supply and E-stop.
H753-S sense/display sets
40
P06, P09-P13, P16 and P20
Temperature, LDR, potentiometer, 3.3-V I2C display and protected wiring as mapped.
H753-A safe-actuation sets
15
P09, P11 and P13
3.3-V-compatible driver, flyback protection, low-voltage load and fused supply.
Servo/position fixtures
10
P10 and P12
Externally powered low-force servo with bounded travel and family fixture.
H753-N two-node network sets
20 sets / 40 transceivers
P14-P17
One transceiver per board, twisted pair, two 120-ohm end terminations and verified reference/isolation.
Variant-module reserve
10 mapped sets
P15 and P17
Final mix follows the five active variants in the applicable wave.
Single simultaneous event alternative: executing all 200 teams at once requires 240 participant boards, plus a practical contingency and organiser-reference pool. With the present 120-board inventory, the two-wave structure is the complete and fair execution model.
Shared facility resources per 100-team wave
Shared resource
Planning quantity
Operating rule
Team laptops with supported toolchain
100 + central contingency
CubeIDE, drivers, Python environment and offline packages verified before L4.
Video capture
100 approved devices or scheduled institutional stations
Use the media/privacy rule; personal devices are not mandatory where an institutional station is provided.
Two-channel oscilloscopes
13 minimum
Approximately one per eight teams; supervised booking for PWM, timing and analogue verification.
Logic analyser/CAN observation stations
13 minimum
Shared trace capture; at least four stations shall support the FDCAN families.
Supervised solder/rework station
At least one per laboratory room
Student rework only under technician control; no live-circuit soldering.
PPE
One complete set per registered participant, up to 400 per wave
One per family panel with rubric access, clock, evidence register and secure score submission.
Duty of care and turnaround: publish rolling meal and rest windows that keep every rig supervised. No participant shall be scheduled for more than six continuous hours of technical duty without a recorded break; provide at least one protected 60-minute rest block during each 24-hour wave. Maintain staffed safety/technical shifts and a minimum 12-hour board-inspection and personnel turnaround between Wave A and Wave B; separate event dates are preferred.
11 · Academic scope and bounded self-learning
Required knowledge, controlled extension and excluded scope
Band
What belongs here
Rule
Required
CubeMX/CubeIDE/STLINK; GPIO and interrupts; timer-based sampling; ADC; PWM; servo/relay/DC-motor interfacing as relevant; encoder/current/temperature signals; UART or FDCAN telemetry; discrete PID or deterministic rule control; watchdog, limits and safe state. ML: cleaning, meaningful features, an engineering baseline, regression/classification and course-approved trees/ensembles, held-out evaluation, correct metrics and error analysis.
Every project must evidence both ESD and ML. A dashboard or disconnected notebook fails integration.
Controlled stretch
Choose exactly one: timer-triggered ADC with DMA using organiser-provided starter code; hardware CRC on packets; DAC-to-ADC calibration stimulus; local Ethernet telemetry mirror; confidence calibration/abstention; grouped or time-aware validation; simple model drift check; compact binary protocol and replay utility.
Students self-learn and document it. It may earn differentiation marks, but cannot replace required syllabus outcomes.
Not required
RTOS/FreeRTOS, embedded Linux, TinyML or on-device model inference, Edge/Embedded AI branding, neural networks/deep learning, computer vision, audio/vibration DSP, reinforcement learning, cloud deployment/MQTT, custom PCB, unrestricted adaptive control, model-generated PID gains or raw ML-to-PWM commands.
These cannot be made mandatory, used to penalize teams or become hidden prerequisites.
Algorithm release rule: publish a whitelist matching the portions of 25SC2107E completed before the event. Every family remains solvable with a transparent baseline plus logistic/linear regression or a decision tree. Clustering and anomaly detection are used only if already taught or if the organiser provides the method as a guided resource.
12 · Common system architecture and protocol
Sense, control, observe, learn, recommend and validate
Physical process / safe fault fixture ↓ NUCLEO-H753ZI · timer-triggered sensing · deterministic PID/rules · immutable interlocks ↓ USART3 VCP by default · FDCAN for twin-node families · optional local Ethernet mirror Laptop logger → run-level feature pipeline → baseline → classical ML → confidence/abstention ↓ bounded command/profile ID with sequence and expiry NUCLEO-H753ZI validates → accepts, derates, refuses or enters safe state → event log
The log must distinguish ML recommendation from action actually accepted by the MCU.
Two-rate rule: the control/safety loop has a fixed justified period. Telemetry and logging may run more slowly or change among whitelisted rates. No ML decision may block or retime the control loop.
13 · Student use of the challenge briefs
How to interpret an allocated problem and variant
Every problem is presented as a product story, a physical signal path and an evidence plan. Read the five visual blocks from left to right; then open the allocated variant and follow its seven-part student brief.
1 · Physical worldCreate a real conditionUse only the approved low-voltage fixture and safe fault-injection method.
2 · H753 observesMeasure and timestampADC, encoder, GPIO and timer evidence must be calibrated and traceable.
3 · H753 controlsAct deterministicallyPID/rules, hard limits, watchdog and host-loss behaviour remain on the MCU.
4 · Host learnsCompare baseline and MLUse run-wise splits, syllabus-approved classical models and honest error analysis.
5 · H753 decidesValidate a bounded requestThe board accepts or rejects a named mode/profile and records the reason.
Problem landscape
Motion, drive and actuator
8
Sensing and smart products
5
FDCAN and distributed systems
4
Control and data quality
3
Core family
Explains the reusable product, board wiring, signals, intelligence, safety, reviews and definition of done.
Allocated variant
Changes one meaningful experimental dimension. Its brief states exactly what to modify, record, model, demonstrate and publish.
Inheritance rule
The variant never erases the parent hardware or safety contract. Read both; the variant adds specificity rather than replacing the core.
HTML-focused handout export
In the interactive HTML, search for a problem or exact variant before selecting Print / Save PDF; nonmatching content is hidden to create a short assignment handout. The issued complete PDF is static and shall be navigated through its contents/bookmarks.
14 · Competitive Hackathon schedule and review operation
Common 24-hour competition schedule, reviews and video evidence
Competitive-phase rule: this 24-hour schedule is separate from the earlier 24-hour Learnathon and is executed twice: Wave A for variants V1-V5 and Wave B for variants V6-V10 in every family. Entry requires Learnathon L1-L4 participation, closure of mandatory remediation and T-1 verification of the learnathon-close archive. Each competition wave uses an equivalent non-identical blind-test pack and the same timing, rubric and evidence requirements.
Elapsed time is used so either wave may begin at any clock time. Twenty problem-family panels operate concurrently. Each panel comprises the assigned ESD and ML Faculty Masters and reviews its five active teams in a protected 60-minute window.
Freeze process, pin map, control period, labels, MCU/host boundary, canonical command subset, risks and team ownership.
Prepare Review 1 evidence.
H2:30–H3:30
Review 1 · Design Gate
Five teams per family panel; each receives 8 minutes for evidence and 2 minutes for questions/feedback. Ten minutes remain for panel recording and overrun control.
10 marks.
H3:30–H7:00
H753 embedded vertical slice
Timer-driven acquisition/control, telemetry, acknowledgement, watchdog, hard limits and host-loss fallback. Upload Video Log 1 by H6:50.
Prepare Review 2 evidence.
H7:00–H8:00
Review 2 · Embedded Gate
Live hardware trace and forced interlock; five 10-minute team slots plus 10-minute panel buffer.
15 marks.
H8:00–H11:30
Data and baseline sprint
Controlled runs, data dictionary, calibration, run-level labels, leakage-safe split and engineering baseline. Upload Video Log 2 by H11:20.
Prepare Review 3 evidence.
H11:30–H12:30
Review 3 · Data and Baseline Gate
Raw traces, run manifest, split logic and baseline; five 10-minute team slots plus 10-minute panel buffer.
15 marks.
H12:30–H16:30
Classical-ML intelligence sprint
Features, two permitted models, validation, error slices, confidence/abstention and bounded policy. Upload Video Log 3 by H16:20.
Prepare Review 4 evidence.
H16:30–H17:30
Review 4 · Intelligence Gate
Model evidence, baseline comparison and canonical decision policy; five 10-minute team slots plus 10-minute panel buffer.
20 marks.
H17:30–H20:30
Integrated smart-system sprint
Live inference, versioned recommendation, H753 validation/acknowledgement, latency, safe fault injection and fallback. Upload Video Log 4 by H20:20.
Prepare Review 5 evidence.
H20:30–H21:30
Review 5 · Integration and Safety Gate
Live sense–predict–recommend–validate–act loop plus invalid, stale and host-loss tests; five 10-minute team slots plus 10-minute panel buffer.
20 marks.
H21:30–H22:30
Hidden-test and portfolio hardening
Blind-test hardening; final README, dataset/model cards, notebook, firmware, test report and video. Freeze at H22:20.
Immutable final tag and checksums.
H22:30–H24:00
Final team presentation · presentation-only review
Parallel family panels. Per team: a timed presentation incorporating the frozen product demonstration and ESD/ML evidence, followed by directed questions to every student and scoring transition. No separate artefact-only or post-presentation build review is held.
Final cumulative rubric, five team criteria, four individual presentation records and final 20 marks.
Video-log rule
Four checkpoint logs
60–90 seconds each, uploaded by H6:50, H11:20, H16:20 and H20:20. Show timestamp/team ID, current live build, one failure or unresolved risk, next action and at least two members speaking.
Final product video
3–4 minutes: problem, physical product, architecture, data, baseline, model, bounded action, safety failure, measured outcome and portfolio links. It supplements—not replaces—the live demo.
Authenticity evidence
Checkpoint Git tags, raw trace snippets and video continuity are used to verify that hardware, data and models were built during the sprint.
15 · Mandatory submissions
Deliverables required during the Learnathon and Hackathon
Learnathon record carried into the submission: include L1-L4 learning-gate sheets, technology exercises, questions/misconceptions log, alternative-approach discussion, experiment and integration plan, Faculty Master learning actions, optional partial-work record, learnathon-close tag and checksums. These establish learning and provenance; they do not substitute for Hackathon execution deliverables.
L1_problem_canvas.pdf; parent-versus-variant note; stakeholder/process map; inputs/outputs/target/confuser table; technology-learning map; questions and hypotheses log; member learning roles.
Every member can explain the problem, variant distinction, measurable success, ML purpose and unresolved learning needs without reading a prepared answer.
Completed L1 tick-box rubric; learning status and dated actions; both Faculty Master signatures.
The team understands and can demonstrate the required embedded concepts on the supplied learning exercise. A team-specific vertical slice is optional, not required.
Completed L2 tick-box rubric; misconception/remediation record; ESD-led and ML-acknowledged signatures.
Students can explain and rerun the learning exercise, identify leakage/overfitting risks and connect prediction to a safe canonical decision. A final team model is not required.
Completed L3 tick-box rubric; misconception/remediation record; ML-led and ESD-acknowledged signatures.
L4 · Present and defend the approach
Presentation deck/visuals; closure status of L1-L3 actions; alternative-solution comparison; selected architecture and decision log; experiment/validation/fault plan; integration contract; expected-glitch tree; follow-up plan; optional partial artefact; learnathon-close tag and checksums.
Through the scheduled presentation only, the team defends a coherent, safe and testable approach and honestly states what it still needs to learn. Every registered student explains a distinct contribution and answers a directed question. No final product or end-to-end integration is required.
Completed cumulative L4 team rubric; individual presentation score for each student; presentation mean; learning outcome status; remediation due date; both signatures.
Submission identity: every item shall display the team ID, problem/variant code, wave, repository commit/tag, date/time and responsible member. A link without the archived file/version is not a submission. Optional partial implementation must be labelled OPTIONAL LEARNATHON WORK and cannot improve a learning-gate score merely because more code was completed. The Faculty Master pair retains the signed rubrics and remediation-closure evidence.
Working NUCLEO-H753ZI firmware; .ioc/CubeIDE project; board and connector pin map; wiring photograph/diagram; measured 3.3 V compatibility; calibrated readings; timer-driven PWM/PID/rules; VCP/FDCAN trace; acknowledgement; hard-fault and host-loss demonstration; Video Log 1.
R3 Data and baseline pack
Raw telemetry with device/run/sequence IDs; trial/fault-injection manifest; data dictionary; dataset card draft; calibration and cleaning code; run-wise split manifest; EDA; physical sanity checks; class/target coverage; engineering baseline on the same holdout; Video Log 2.
R4 ML evidence pack
Executable notebook/script; two syllabus-whitelist classical models; leakage-safe preprocessing pipeline; operational metrics; confidence/abstention; error slices; physical feature/residual reasoning; model card draft; bounded action map; Video Log 3.
R5 Integrated system pack
Live sense→predict→recommend→validate→act loop; command age/sequence/version/profile checks; MCU acknowledgement and reason codes; end-to-end latency; three fault injections; host/link loss; selected controlled stretch; acceptance table; Video Log 4.
Final portfolio pack
Frozen repository/tag; firmware and host app; dataset/model versions; Kaggle-ready notebook and dataset card; model card; protocol/state diagrams; H753 bring-up guide; test report; self-learning note; five-slide pitch; 3–4 minute final product video; individual contribution record.
Data sufficiency rule: row count is not accepted as evidence because high-rate sampling can inflate it. Supervised teams must show independent physical runs per condition and use organiser seed data where rare faults cannot be generated safely. Regression teams must span the intended operating range. Unsupervised teams must establish healthy behaviour across multiple regimes before evaluating injected abnormalities.
16 · Common assessment framework
Two-dimensional tick-box rubrics for every competitive review
The reviews are cumulative stage gates, not six copies of one checklist. R1 approves the design; R2 closes R1 actions and proves the embedded baseline; R3 closes R2 actions and establishes trustworthy data and an engineering baseline; R4 freezes R3 evidence and proves the ML pipeline; R5 freezes the inference contract and proves safe live integration; the Final is a presentation-only review of the frozen product, results and portfolio. Every team criterion uses a criterion-specific 0-2-4-6-8-10 evidence scale.
Hackathon faculty review sheets6 landscape A4 sheets - R1 to R5 and Final - one gate per page
Joint-evaluation rule: the ESD Faculty Master leads embedded and safety judgements; the ML Faculty Master leads data and model judgements; both must witness the evidence, agree every selected anchor and sign the matrix. If they disagree, select the lower evidenced anchor and refer the row—not the whole score—to the central moderation panel.
Cumulative gate rule: each review begins with the signed previous sheet and action log. An open mandatory action prevents an unconditional PROCEED decision; an open safety, integrity, data-leakage or MCU-authority action requires STOP AND REMEDIATE. Faculty record closure evidence, not a verbal assurance. The Final is held only through the scheduled team presentation, product demonstration within that presentation and Q&A.
Gate
Criteria × 10 raw points
Raw maximum
Approved weight
Conversion
R1 · Design
5
50
10
Raw ÷ 50 × 10
R2 · Embedded
5
50
15
Raw ÷ 50 × 15
R3 · Data/Baseline
5
50
15
Raw ÷ 50 × 15
R4 · ML Intelligence
6
60
20
Raw ÷ 60 × 20
R5 · Integration/Safety
6
60
20
Raw ÷ 60 × 20
Final · presentation only
5 team criteria + individual presentation mean
60
20
Raw ÷ 60 × 20
Competition total
100
Sum the six weighted gate marks
Review 1 · Design Gate
Scoring rule: every listed team criterion is worth 10 raw points. The only permitted scores are 0, 2, 4, 6, 8 and 10. Tick exactly one fully defined descriptor in every row. When evidence falls between two anchors, select the lower anchor until every statement in the higher descriptor is demonstrated.
Gate dependency: Initial competition gate. The approved design, safety envelope and action list become the controlled baseline for R2.
Safety/integrity-critical criterion: Safety and acceptance tests
Criterion and evidence benchmark
0 Absent / unsafe
2 Fragment only
4 Partial; major gaps
6 Working minimum
8 Complete; minor gaps
10 Verified; no material gap
Problem and variant interpretation Required evidence: Specific user/process need, system boundary, variant distinction, nearest confuser, measurable target and non-decorative ML role.
□No credible problem and variant interpretation; absent, unsafe, copied or outside the approved scope.
□States an intent for problem and variant interpretation, but provides no testable assignment-specific design evidence.
□Partial problem and variant interpretation; major feasibility, ownership or safety elements are missing.
□Feasible minimum problem and variant interpretation is documented; material verification or traceability remains open.
□Complete, consistent problem and variant interpretation is review-ready with only minor corrections.
□Independently checked and approved problem and variant interpretation; assumptions, interfaces and tests are fully traceable.
H753, pack and syllabus traceability Required evidence: Exact board resources, issued pack, 0-3.3 V interfaces, communication, course outcomes, one controlled stretch and excluded scope.
□No credible hardware and syllabus traceability; absent, unsafe, copied or outside the approved scope.
□States an intent for hardware and syllabus traceability, but provides no testable assignment-specific design evidence.
□Partial hardware and syllabus traceability; major feasibility, ownership or safety elements are missing.
□Feasible minimum hardware and syllabus traceability is documented; material verification or traceability remains open.
□Complete, consistent hardware and syllabus traceability is review-ready with only minor corrections.
□Independently checked and approved hardware and syllabus traceability; assumptions, interfaces and tests are fully traceable.
Architecture and data flow Required evidence: Sensor-to-H753-to-host-to-canonical-command-to-validation/acknowledgement chain plus CubeMX pin and conflict map.
□No credible architecture and data flow; absent, unsafe, copied or outside the approved scope.
□States an intent for architecture and data flow, but provides no testable assignment-specific design evidence.
□Partial architecture and data flow; major feasibility, ownership or safety elements are missing.
□Feasible minimum architecture and data flow is documented; material verification or traceability remains open.
□Complete, consistent architecture and data flow is review-ready with only minor corrections.
□Independently checked and approved architecture and data flow; assumptions, interfaces and tests are fully traceable.
Safety and acceptance tests Required evidence: Numeric operating envelope, independent limits, watchdog, E-stop, host-loss state, hidden-test plan and forbidden actions.
□No credible safety and acceptance tests; absent, unsafe, copied or outside the approved scope.
□States an intent for safety and acceptance tests, but provides no testable assignment-specific design evidence.
□Partial safety and acceptance tests; major feasibility, ownership or safety elements are missing.
□Feasible minimum safety and acceptance tests is documented; material verification or traceability remains open.
□Complete, consistent safety and acceptance tests is review-ready with only minor corrections.
□Independently checked and approved safety and acceptance tests; assumptions, interfaces and tests are fully traceable.
Sprint, trial and evidence plan Required evidence: Four owners, repository structure, physical/seed-data plan, run IDs and milestones aligned to the revised H7/H11.5/H16.5/H20.5 gates.
□No credible sprint, trial and evidence plan; absent, unsafe, copied or outside the approved scope.
□States an intent for sprint, trial and evidence plan, but provides no testable assignment-specific design evidence.
□Partial sprint, trial and evidence plan; major feasibility, ownership or safety elements are missing.
□Feasible minimum sprint, trial and evidence plan is documented; material verification or traceability remains open.
□Complete, consistent sprint, trial and evidence plan is review-ready with only minor corrections.
□Independently checked and approved sprint, trial and evidence plan; assumptions, interfaces and tests are fully traceable.
Competition conversion: raw total ___ / 50; weighted gate mark = raw total ÷ 50 × 10 = ___ / 10. Round only the weighted gate mark to one decimal.
Scoring rule: every listed team criterion is worth 10 raw points. The only permitted scores are 0, 2, 4, 6, 8 and 10. Tick exactly one fully defined descriptor in every row. When evidence falls between two anchors, select the lower anchor until every statement in the higher descriptor is demonstrated.
Gate dependency: Cumulative gate. R1 mandatory actions must be closed before the embedded baseline is accepted. An open safety action requires STOP AND REMEDIATE.
Safety/integrity-critical criterion: Closure of R1 actions and approved configuration; hard safety, fallback and engineering evidence
Criterion and evidence benchmark
0 Absent / unsafe
2 Fragment only
4 Partial; major gaps
6 Working minimum
8 Complete; minor gaps
10 Verified; no material gap
Closure of R1 actions and approved configuration Required evidence: Every mandatory R1 action is evidenced and signed closed; the committed .ioc, pin/conflict map, architecture and numeric safety envelope match the approved design baseline.
□No safe physical evidence for closure of R1 actions and the approved H753 configuration, or a critical R1 action remains open.
□Shows configuration or a claim for closure of R1 actions and the approved H753 configuration, but no valid witnessed behaviour.
□Partial physical closure of R1 actions and the approved H753 configuration; R1 closure or a major signal/control/safety requirement is missing.
□R1 actions are closed and minimum closure of R1 actions and the approved H753 configuration works once; repeatability or measurement evidence is incomplete.
□Repeatable, measured closure of R1 actions and the approved H753 configuration satisfies the approved design with only minor gaps.
□Independently verified closure of R1 actions and the approved H753 configuration is repeatable under nominal and relevant fault conditions with traceable evidence.
H753 sensing and signal validity Required evidence: Verified logic levels and calibrated ADC/encoder/digital readings with units, timestamps, plausible ranges and no undocumented pin or peripheral conflict.
□No safe physical evidence for H753 sensing and signal validity, or a critical R1 action remains open.
□Shows configuration or a claim for H753 sensing and signal validity, but no valid witnessed behaviour.
□Partial physical H753 sensing and signal validity; R1 closure or a major signal/control/safety requirement is missing.
□R1 actions are closed and minimum H753 sensing and signal validity works once; repeatability or measurement evidence is incomplete.
□Repeatable, measured H753 sensing and signal validity satisfies the approved design with only minor gaps.
□Independently verified H753 sensing and signal validity is repeatable under nominal and relevant fault conditions with traceable evidence.
Deterministic actuation or control Required evidence: Timer-driven PWM/PID/rule path, repeatable physical behaviour, approved driver and no blocking-delay dependence in the critical path.
□No safe physical evidence for deterministic actuation or control, or a critical R1 action remains open.
□Shows configuration or a claim for deterministic actuation or control, but no valid witnessed behaviour.
□Partial physical deterministic actuation or control; R1 closure or a major signal/control/safety requirement is missing.
□R1 actions are closed and minimum deterministic actuation or control works once; repeatability or measurement evidence is incomplete.
□Repeatable, measured deterministic actuation or control satisfies the approved design with only minor gaps.
□Independently verified deterministic actuation or control is repeatable under nominal and relevant fault conditions with traceable evidence.
Telemetry and protocol Required evidence: Reliable USART3 VCP or physical FDCAN with protocol version, device/run/sequence, timestamp, units, state/fault and acknowledgement.
□No safe physical evidence for telemetry and protocol, or a critical R1 action remains open.
□Shows configuration or a claim for telemetry and protocol, but no valid witnessed behaviour.
□Partial physical telemetry and protocol; R1 closure or a major signal/control/safety requirement is missing.
□R1 actions are closed and minimum telemetry and protocol works once; repeatability or measurement evidence is incomplete.
□Repeatable, measured telemetry and protocol satisfies the approved design with only minor gaps.
□Independently verified telemetry and protocol is repeatable under nominal and relevant fault conditions with traceable evidence.
Hard safety, fallback and engineering evidence Required evidence: Numeric limits, watchdog, command expiry, E-stop and host/link-loss safe state are physically demonstrated; committed firmware/.ioc, wiring record, measured interfaces, Video Log 1 and one fault-cause-fix chain are traceable.
□No safe physical evidence for hard safety, fallback and embedded engineering evidence, or a critical R1 action remains open.
□Shows configuration or a claim for hard safety, fallback and embedded engineering evidence, but no valid witnessed behaviour.
□Partial physical hard safety, fallback and embedded engineering evidence; R1 closure or a major signal/control/safety requirement is missing.
□R1 actions are closed and minimum hard safety, fallback and embedded engineering evidence works once; repeatability or measurement evidence is incomplete.
□Repeatable, measured hard safety, fallback and embedded engineering evidence satisfies the approved design with only minor gaps.
□Independently verified hard safety, fallback and embedded engineering evidence is repeatable under nominal and relevant fault conditions with traceable evidence.
Competition conversion: raw total ___ / 50; weighted gate mark = raw total ÷ 50 × 15 = ___ / 15. Round only the weighted gate mark to one decimal.
Scoring rule: every listed team criterion is worth 10 raw points. The only permitted scores are 0, 2, 4, 6, 8 and 10. Tick exactly one fully defined descriptor in every row. When evidence falls between two anchors, select the lower anchor until every statement in the higher descriptor is demonstrated.
Gate dependency: Cumulative gate. R2 must have produced stable, safe and traceable telemetry before data quality or the engineering baseline can be accepted.
Safety/integrity-critical criterion: Closure of R2 actions and stable telemetry capture; data quality and leakage control
Criterion and evidence benchmark
0 Absent / unsafe
2 Fragment only
4 Partial; major gaps
6 Working minimum
8 Complete; minor gaps
10 Verified; no material gap
Closure of R2 actions and stable telemetry capture Required evidence: Every mandatory R2 action is signed closed; safe sensing/control and the versioned telemetry schema run repeatably long enough to support independent physical trials.
□No trustworthy closure of R2 actions and stable telemetry capture, or the required R2 safety/telemetry baseline is not closed.
□Shows a sample or plot for closure of R2 actions and stable telemetry capture, but provenance and repeatability cannot be established.
□Partial closure of R2 actions and stable telemetry capture; R2 closure or a major run, quality, split or baseline requirement is missing.
□R2 actions are closed and minimum closure of R2 actions and stable telemetry capture is reproducible; material coverage or traceability gaps remain.
□Complete, leakage-safe and reproducible closure of R2 actions and stable telemetry capture has only minor coverage gaps.
□Independently rerun and audited closure of R2 actions and stable telemetry capture is physically credible, leakage-safe and fully traceable.
Data provenance and trial design Required evidence: Independent physical runs, run IDs, condition/fault-injection log, configuration and complete organiser-data provenance.
□No trustworthy data provenance and trial design, or the required R2 safety/telemetry baseline is not closed.
□Shows a sample or plot for data provenance and trial design, but provenance and repeatability cannot be established.
□Partial data provenance and trial design; R2 closure or a major run, quality, split or baseline requirement is missing.
□R2 actions are closed and minimum data provenance and trial design is reproducible; material coverage or traceability gaps remain.
□Complete, leakage-safe and reproducible data provenance and trial design has only minor coverage gaps.
□Independently rerun and audited data provenance and trial design is physically credible, leakage-safe and fully traceable.
Data quality and leakage control Required evidence: Units, calibration, missing/duplicate/outlier and physical-plausibility checks plus run/session/specimen split rather than adjacent-row split.
□No trustworthy data quality and leakage control, or the required R2 safety/telemetry baseline is not closed.
□Shows a sample or plot for data quality and leakage control, but provenance and repeatability cannot be established.
□Partial data quality and leakage control; R2 closure or a major run, quality, split or baseline requirement is missing.
□R2 actions are closed and minimum data quality and leakage control is reproducible; material coverage or traceability gaps remain.
□Complete, leakage-safe and reproducible data quality and leakage control has only minor coverage gaps.
□Independently rerun and audited data quality and leakage control is physically credible, leakage-safe and fully traceable.
Feature and label justification Required evidence: Physically meaningful features, operational target definitions and no future/test information entering labels or preprocessing.
□No trustworthy feature and label justification, or the required R2 safety/telemetry baseline is not closed.
□Shows a sample or plot for feature and label justification, but provenance and repeatability cannot be established.
□Partial feature and label justification; R2 closure or a major run, quality, split or baseline requirement is missing.
□R2 actions are closed and minimum feature and label justification is reproducible; material coverage or traceability gaps remain.
□Complete, leakage-safe and reproducible feature and label justification has only minor coverage gaps.
□Independently rerun and audited feature and label justification is physically credible, leakage-safe and fully traceable.
Engineering baseline and reproducibility Required evidence: A rule, threshold, persistence, simple linear relation or fixed-profile policy is evaluated on the untouched holdout; the data dictionary, raw-to-feature pipeline, environment/seed, version and rerun instructions reproduce it.
□No trustworthy engineering baseline and data reproducibility, or the required R2 safety/telemetry baseline is not closed.
□Shows a sample or plot for engineering baseline and data reproducibility, but provenance and repeatability cannot be established.
□Partial engineering baseline and data reproducibility; R2 closure or a major run, quality, split or baseline requirement is missing.
□R2 actions are closed and minimum engineering baseline and data reproducibility is reproducible; material coverage or traceability gaps remain.
□Complete, leakage-safe and reproducible engineering baseline and data reproducibility has only minor coverage gaps.
□Independently rerun and audited engineering baseline and data reproducibility is physically credible, leakage-safe and fully traceable.
Competition conversion: raw total ___ / 50; weighted gate mark = raw total ÷ 50 × 15 = ___ / 15. Round only the weighted gate mark to one decimal.
Scoring rule: every listed team criterion is worth 10 raw points. The only permitted scores are 0, 2, 4, 6, 8 and 10. Tick exactly one fully defined descriptor in every row. When evidence falls between two anchors, select the lower anchor until every statement in the higher descriptor is demonstrated.
Gate dependency: Cumulative gate. R3 data provenance, run-level split and engineering baseline must be closed and frozen before model evidence is scored.
Safety/integrity-critical criterion: Closure of R3 and frozen evidence baseline; validation discipline; bounded decision, abstention and physical coherence
Criterion and evidence benchmark
0 Absent / unsafe
2 Fragment only
4 Partial; major gaps
6 Working minimum
8 Complete; minor gaps
10 Verified; no material gap
Closure of R3 and frozen evidence baseline Required evidence: All R3 actions are signed closed; raw/processed data versions, run-level split, preprocessing boundary, target definition and engineering-baseline result are frozen and checksum-recorded.
□No credible closure of R3 and the frozen data, split and baseline, or the R3 dataset/split/baseline is not closed and frozen.
□Reports a model output for closure of R3 and the frozen data, split and baseline, but the pipeline or evaluation cannot be reproduced.
□Partial closure of R3 and the frozen data, split and baseline; a major validation, comparison, interpretation or policy requirement is missing.
□R3 is closed and minimum closure of R3 and the frozen data, split and baseline is demonstrated; material error analysis or reproducibility gaps remain.
□Complete, baseline-compared closure of R3 and the frozen data, split and baseline is reproducible with only minor gaps.
□Independently rerun closure of R3 and the frozen data, split and baseline is leakage-safe, operationally justified and robust to probing error cases.
Model choice and implementation Required evidence: Two course-approved classical approaches suit the target/data; preprocessing is fitted only on training data and packaged in the pipeline.
□No credible model choice and implementation, or the R3 dataset/split/baseline is not closed and frozen.
□Reports a model output for model choice and implementation, but the pipeline or evaluation cannot be reproduced.
□Partial model choice and implementation; a major validation, comparison, interpretation or policy requirement is missing.
□R3 is closed and minimum model choice and implementation is demonstrated; material error analysis or reproducibility gaps remain.
□Complete, baseline-compared model choice and implementation is reproducible with only minor gaps.
□Independently rerun model choice and implementation is leakage-safe, operationally justified and robust to probing error cases.
Validation discipline Required evidence: Untouched run-level holdout, cross-validation where appropriate, recorded tuning boundary and no final-test optimisation.
□No credible validation discipline, or the R3 dataset/split/baseline is not closed and frozen.
□Reports a model output for validation discipline, but the pipeline or evaluation cannot be reproduced.
□Partial validation discipline; a major validation, comparison, interpretation or policy requirement is missing.
□R3 is closed and minimum validation discipline is demonstrated; material error analysis or reproducibility gaps remain.
□Complete, baseline-compared validation discipline is reproducible with only minor gaps.
□Independently rerun validation discipline is leakage-safe, operationally justified and robust to probing error cases.
Metrics and error analysis versus baseline Required evidence: Operational/safety metrics beyond accuracy, same-holdout baseline comparison, per-class/condition slices, confidence intervals where meaningful and concrete failure examples.
□No credible metrics and error analysis versus the frozen baseline, or the R3 dataset/split/baseline is not closed and frozen.
□Reports a model output for metrics and error analysis versus the frozen baseline, but the pipeline or evaluation cannot be reproduced.
□Partial metrics and error analysis versus the frozen baseline; a major validation, comparison, interpretation or policy requirement is missing.
□R3 is closed and minimum metrics and error analysis versus the frozen baseline is demonstrated; material error analysis or reproducibility gaps remain.
□Complete, baseline-compared metrics and error analysis versus the frozen baseline is reproducible with only minor gaps.
□Independently rerun metrics and error analysis versus the frozen baseline is leakage-safe, operationally justified and robust to probing error cases.
Bounded decision, abstention and physical coherence Required evidence: Predictions map to the canonical bounded subset with confidence threshold, unknown state, expiry and conservative default; coefficients, importance or residuals are checked against measured physics without causal overclaim.
□No credible bounded decision, abstention and physical coherence, or the R3 dataset/split/baseline is not closed and frozen.
□Reports a model output for bounded decision, abstention and physical coherence, but the pipeline or evaluation cannot be reproduced.
□Partial bounded decision, abstention and physical coherence; a major validation, comparison, interpretation or policy requirement is missing.
□R3 is closed and minimum bounded decision, abstention and physical coherence is demonstrated; material error analysis or reproducibility gaps remain.
□Complete, baseline-compared bounded decision, abstention and physical coherence is reproducible with only minor gaps.
□Independently rerun bounded decision, abstention and physical coherence is leakage-safe, operationally justified and robust to probing error cases.
Reproducible inference artefact Required evidence: Executable notebook/script, pinned inputs, model version, input/output schema, model card and deterministic inference demonstration reproduce the declared result.
□No credible reproducible inference artefact, or the R3 dataset/split/baseline is not closed and frozen.
□Reports a model output for reproducible inference artefact, but the pipeline or evaluation cannot be reproduced.
□Partial reproducible inference artefact; a major validation, comparison, interpretation or policy requirement is missing.
□R3 is closed and minimum reproducible inference artefact is demonstrated; material error analysis or reproducibility gaps remain.
□Complete, baseline-compared reproducible inference artefact is reproducible with only minor gaps.
□Independently rerun reproducible inference artefact is leakage-safe, operationally justified and robust to probing error cases.
Competition conversion: raw total ___ / 60; weighted gate mark = raw total ÷ 60 × 20 = ___ / 20. Round only the weighted gate mark to one decimal.
Scoring rule: every listed team criterion is worth 10 raw points. The only permitted scores are 0, 2, 4, 6, 8 and 10. Tick exactly one fully defined descriptor in every row. When evidence falls between two anchors, select the lower anchor until every statement in the higher descriptor is demonstrated.
Gate dependency: Cumulative gate. The R4 model, input schema, thresholds and bounded decision policy must be frozen before live integration and fault recovery are scored.
Safety/integrity-critical criterion: Closure of R4 and frozen inference contract; H753 authority and bounded action; fault injection and recovery
Criterion and evidence benchmark
0 Absent / unsafe
2 Fragment only
4 Partial; major gaps
6 Working minimum
8 Complete; minor gaps
10 Verified; no material gap
Closure of R4 and frozen inference contract Required evidence: All R4 actions are signed closed; model artefact, input schema, preprocessing, thresholds, canonical output subset, expiry and conservative default are frozen and version-matched.
□No safe live evidence for closure of R4 and the frozen model, schema and bounded policy, or the R4 model/schema/policy is not frozen.
□Shows a scripted fragment of closure of R4 and the frozen model, schema and bounded policy, but no genuine end-to-end witnessed behaviour.
□Partial closure of R4 and the frozen model, schema and bounded policy; a major interface, timing, authority, fault or recovery requirement is missing.
□R4 is closed and minimum live closure of R4 and the frozen model, schema and bounded policy works; repeatability or fault evidence remains incomplete.
□Repeatable live closure of R4 and the frozen model, schema and bounded policy passes required nominal and fault tests with only minor gaps.
□Independently repeated closure of R4 and the frozen model, schema and bounded policy passes blind-relevant tests with complete timing, refusal and recovery evidence.
Genuine closed-loop integration Required evidence: Live physical H753 telemetry influences a real bounded decision and exposes prediction, recommendation, MCU acceptance/refusal and reason code.
□No safe live evidence for genuine closed-loop integration, or the R4 model/schema/policy is not frozen.
□Shows a scripted fragment of genuine closed-loop integration, but no genuine end-to-end witnessed behaviour.
□Partial genuine closed-loop integration; a major interface, timing, authority, fault or recovery requirement is missing.
□R4 is closed and minimum live genuine closed-loop integration works; repeatability or fault evidence remains incomplete.
□Repeatable live genuine closed-loop integration passes required nominal and fault tests with only minor gaps.
□Independently repeated genuine closed-loop integration passes blind-relevant tests with complete timing, refusal and recovery evidence.
Timing and data consistency Required evidence: Freshness, version, age/sequence, acknowledgement, latency and synchronisation are measured; stale/duplicate commands are rejected.
□No safe live evidence for timing and data consistency, or the R4 model/schema/policy is not frozen.
□Shows a scripted fragment of timing and data consistency, but no genuine end-to-end witnessed behaviour.
□Partial timing and data consistency; a major interface, timing, authority, fault or recovery requirement is missing.
□R4 is closed and minimum live timing and data consistency works; repeatability or fault evidence remains incomplete.
□Repeatable live timing and data consistency passes required nominal and fault tests with only minor gaps.
□Independently repeated timing and data consistency passes blind-relevant tests with complete timing, refusal and recovery evidence.
H753 authority and bounded action Required evidence: Whitelisted profile/state checks, immutable interlocks and watchdog remain on the MCU; no unrestricted model-to-PWM path exists.
□No safe live evidence for H753 authority and bounded action, or the R4 model/schema/policy is not frozen.
□Shows a scripted fragment of H753 authority and bounded action, but no genuine end-to-end witnessed behaviour.
□Partial H753 authority and bounded action; a major interface, timing, authority, fault or recovery requirement is missing.
□R4 is closed and minimum live H753 authority and bounded action works; repeatability or fault evidence remains incomplete.
□Repeatable live H753 authority and bounded action passes required nominal and fault tests with only minor gaps.
□Independently repeated H753 authority and bounded action passes blind-relevant tests with complete timing, refusal and recovery evidence.
Fault injection and recovery Required evidence: At least three relevant safe faults plus host/link loss produce correct latching, fallback, recovery and event logs.
□No safe live evidence for fault injection and recovery, or the R4 model/schema/policy is not frozen.
□Shows a scripted fragment of fault injection and recovery, but no genuine end-to-end witnessed behaviour.
□Partial fault injection and recovery; a major interface, timing, authority, fault or recovery requirement is missing.
□R4 is closed and minimum live fault injection and recovery works; repeatability or fault evidence remains incomplete.
□Repeatable live fault injection and recovery passes required nominal and fault tests with only minor gaps.
□Independently repeated fault injection and recovery passes blind-relevant tests with complete timing, refusal and recovery evidence.
Hidden-test, extension and evidence readiness Required evidence: Repeatable fixture, reset/calibration and autonomous evidence distinguish the target from its nearest confuser; the controlled extension, Video Log 4, integration history, test table and unresolved-risk record are complete.
□No safe live evidence for hidden-test, controlled-extension and evidence readiness, or the R4 model/schema/policy is not frozen.
□Shows a scripted fragment of hidden-test, controlled-extension and evidence readiness, but no genuine end-to-end witnessed behaviour.
□Partial hidden-test, controlled-extension and evidence readiness; a major interface, timing, authority, fault or recovery requirement is missing.
□R4 is closed and minimum live hidden-test, controlled-extension and evidence readiness works; repeatability or fault evidence remains incomplete.
□Repeatable live hidden-test, controlled-extension and evidence readiness passes required nominal and fault tests with only minor gaps.
□Independently repeated hidden-test, controlled-extension and evidence readiness passes blind-relevant tests with complete timing, refusal and recovery evidence.
Competition conversion: raw total ___ / 60; weighted gate mark = raw total ÷ 60 × 20 = ___ / 20. Round only the weighted gate mark to one decimal.
Scoring rule: every listed team criterion is worth 10 raw points. The only permitted scores are 0, 2, 4, 6, 8 and 10. Tick exactly one fully defined descriptor in every row. When evidence falls between two anchors, select the lower anchor until every statement in the higher descriptor is demonstrated.
Gate dependency: Cumulative, presentation-only review. Faculty judge the frozen product and portfolio only through the scheduled team presentation, embedded demonstration and Q&A; no new build activity is scored during this review.
Safety/integrity-critical criterion: Technical architecture, integration and safety explanation; demonstration evidence and results versus baseline; individual presentation ownership
Criterion and evidence benchmark
0 Absent / unsafe
2 Fragment only
4 Partial; major gaps
6 Working minimum
8 Complete; minor gaps
10 Verified; no material gap
Problem, product value and innovation narrative Required evidence: State the need, exact variant, product behaviour, meaningful ML role, controlled extension and why the result matters.
□No credible presentation evidence for problem, value and innovation; absent, unsafe or fabricated.
□Asserts problem, value and innovation on slides, but cannot demonstrate, quantify or answer a basic question.
□Partially presents problem, value and innovation; major evidence, coherence or ownership gaps remain.
□Presents a credible minimum for problem, value and innovation; evidence is understandable but needs prompting or qualification.
□Clear, timed and evidence-led problem, value and innovation; independent answers reveal only minor gaps.
□Compelling, precise and fully traceable problem, value and innovation; withstands probing questions on trade-offs and limitations.
Technical architecture, integration and safety explanation Required evidence: Visually trace sensing, H753 control, telemetry, ML and validated commands; explain interlocks, MCU authority and fallback.
□No credible presentation evidence for architecture, integration and safety; absent, unsafe or fabricated.
□Asserts architecture, integration and safety on slides, but cannot demonstrate, quantify or answer a basic question.
□Partially presents architecture, integration and safety; major evidence, coherence or ownership gaps remain.
□Presents a credible minimum for architecture, integration and safety; evidence is understandable but needs prompting or qualification.
□Clear, timed and evidence-led architecture, integration and safety; independent answers reveal only minor gaps.
□Compelling, precise and fully traceable architecture, integration and safety; withstands probing questions on trade-offs and limitations.
Demonstration evidence and results versus baseline Required evidence: Present the frozen blind run and same-holdout baseline; quantify benefit, uncertainty, negative cases and fault behaviour.
□No credible presentation evidence for demonstration and baseline results; absent, unsafe or fabricated.
□Asserts demonstration and baseline results on slides, but cannot demonstrate, quantify or answer a basic question.
□Partially presents demonstration and baseline results; major evidence, coherence or ownership gaps remain.
□Presents a credible minimum for demonstration and baseline results; evidence is understandable but needs prompting or qualification.
□Clear, timed and evidence-led demonstration and baseline results; independent answers reveal only minor gaps.
□Compelling, precise and fully traceable demonstration and baseline results; withstands probing questions on trade-offs and limitations.
Limitations, reproducibility and future work Required evidence: Disclose genuine limitations; show reproducible portfolio artefacts, provenance/licences and justified future work.
□No credible presentation evidence for limitations and reproducibility; absent, unsafe or fabricated.
□Asserts limitations and reproducibility on slides, but cannot demonstrate, quantify or answer a basic question.
□Partially presents limitations and reproducibility; major evidence, coherence or ownership gaps remain.
□Presents a credible minimum for limitations and reproducibility; evidence is understandable but needs prompting or qualification.
□Clear, timed and evidence-led limitations and reproducibility; independent answers reveal only minor gaps.
□Compelling, precise and fully traceable limitations and reproducibility; withstands probing questions on trade-offs and limitations.
Team presentation structure and professional delivery Required evidence: Use a coherent visual story, stay within time, execute disciplined hand-offs, involve every member and reserve Q&A time.
□No credible presentation evidence for team presentation delivery; absent, unsafe or fabricated.
□Asserts team presentation delivery on slides, but cannot demonstrate, quantify or answer a basic question.
□Partially presents team presentation delivery; major evidence, coherence or ownership gaps remain.
□Presents a credible minimum for team presentation delivery; evidence is understandable but needs prompting or qualification.
□Clear, timed and evidence-led team presentation delivery; independent answers reveal only minor gaps.
□Compelling, precise and fully traceable team presentation delivery; withstands probing questions on trade-offs and limitations.
Individual presentation-skills rubric - completed for every registered student
Best-fit dimensions: clarity and structure; technical accuracy; evidence use; ownership of the stated contribution; response to questions; professional delivery, timing and hand-off. Tick one holistic anchor for each student. When dimensions fall at different levels, select the lower level until the higher anchor is fully demonstrated.
Score
Observable individual evidence
0
Absent, refuses the assigned segment, cannot state an own contribution, or makes unsafe/fabricated claims.
2
Reads or repeats a fragment; cannot explain the assigned work or answer one basic question.
4
Partial or unclear explanation with major technical errors; depends on teammates to answer.
6
Explains the assigned contribution and answers basic questions, but needs prompting or misses a material limitation.
8
Structured, confident and evidence-led; connects own work to the system and answers independently with only minor gaps.
10
Concise, technically precise and persuasive; independently handles probing questions, trade-offs and limitations.
Student
Contribution presented
0
2
4
6
8
10
Student 1 Name / registration no.: ____________________
Individual-presentation component: add the scores of all registered team members and divide by the number of registered members = ______ / 10. Transfer this exact mean, including a decimal where applicable, into the gate raw total. An absent registered member scores 0. For an approved three-member team, average the three registered students; do not create a fourth-student penalty.
Competition conversion: raw total ___ / 60; weighted gate mark = raw total ÷ 60 × 20 = ___ / 20. Round only the weighted gate mark to one decimal.
Rank the ten teams within each problem family after both waves, using the same Faculty Master pair, rubric and equivalent blind tests. This produces twenty defensible family rankings.
Cross-family recognition
After Wave B closes, a central jury may confer criterion-specific awards for safety, embedded engineering, ML rigour, integration and portfolio evidence. Raw scores from unlike families shall not be treated as directly comparable.
Optional overall champion
If required, invite the twenty family winners to a separate championship judged with one neutral, published rubric and common evidence task. Do not select an overall winner by simply sorting the original family totals.
17 · Public portfolio and evidence standard
Kaggle and GitHub submission requirements
Dataset design
Include run_id/session_id/specimen_id, timestamp and units; preserve raw and processed layers; split by physical run/session/specimen to prevent adjacent-sample leakage.
Notebook narrative
Problem → data provenance → EDA → physically justified features → simple baseline → two classical models → held-out results → threshold/action policy → error cases → limits.
Kaggle packaging
Publish a dataset card, data dictionary, licence/provenance, fault-injection protocol and one polished public notebook. Keep board serials and personal data out.
GitHub packaging
Firmware/Cube project, host logger/inference code, protocol, wiring, calibration, tests, model artefact, README, architecture/state diagrams and release tag.
Evidence integrity
Every chart must trace to a versioned file; every headline score must use the frozen held-out test; report negative results and abstentions.
Video evidence
Four 60–90 second checkpoint logs plus a final 3–4 minute demo. Each log shows the working system, current failure, next action and at least two team members.
Recommended public title pattern: “Predicting [engineering outcome] from STM32 [sensor/control] telemetry.” The public narrative should show why a rule baseline fails, how the model improves the decision, and where the model must abstain.
Media and data protection: obtain the institution's recording/participation notice and any required consent before filming. Do not publish student IDs, personal contact details, faces of non-consenting persons, private repository tokens or unsafe build details. Provide an approved non-camera evidence alternative where required, use institution-controlled storage during the embargo, and apply the university's retention/deletion schedule. Additional safeguards apply where any participant is a minor.
18 · Assignable challenge bank
20 smart-product families and 200 variants
Each core family now includes a plain-language interpretation, visual system blueprint, build journey and definition of done. Every one of its ten variants then supplies a seven-part student brief covering the scenario, physical modification, signals, experiment design, ML, safe integration, acceptance test and portfolio evidence.
Requirements applicable to every variant: the parent problem defines the NUCLEO-H753ZI implementation, add-on pack, firmware/host split, bounded command vocabulary, safety rules, Learnathon pathway, 24-hour review schedule, evidence package and rubric. The allocated variant adds its specific application context, physical condition, experiment, equipment and acceptance test. The same family ESD/ML Faculty Master pair supervises and evaluates all ten variants. Any change to an allocation requires written approval from the Technical Lead and Safety Officer.
Assigned Faculty Master pair for P01: one nominated ESD Faculty Master and one nominated ML Faculty Master shall jointly master this parent problem and variants V1-V10. The ESD Master owns hardware, firmware, control, communication and safety verification; the ML Master owns data, baselines, models, validation and bounded decision-policy verification. Together they teach and guide ten teams (one for each variant and up to 40 students), supervise five teams in Wave A and five in Wave B, witness integration and sign every final evaluation.
The problem
A closed-loop motor can show similar symptoms for very different reasons: a short load transient, sustained overload, a mechanical jam, increased friction, lost encoder feedback or overheating. A single threshold on current or speed often creates either nuisance trips or missed hazards. The engineering problem is to use the signals already available in the STM32 control loop to distinguish these states early and defensibly.
Smart embedded product to build
Build a smart motor-control and protection node on one NUCLEO-H753ZI. It shall execute a fixed-period speed or position loop, acquire encoder, conditioned current and temperature signals, drive the H753-M low-voltage motor stage, expose deterministic fault flags and stream versioned telemetry through the board’s STLINK USART3 Virtual COM Port. A host classical-ML service shall classify the operating condition and return only NORMAL, CAUTION, DERATE or CONTROLLED_STOP; the H753 records whether and why it accepted the recommendation.
NUCLEO-H753ZI realization and issued pack
NUCLEO-H753ZI / MB1364E with H753-M pack
advanced/general timer PWM through a 3.3-V-logic H-bridge; separate fused motor supply
timer encoder mode or input capture for quadrature/tachometer feedback
ADC channels for conditioned 0–3.3 V current and motor/driver temperature
fixed-rate control ISR; slower telemetry task in the main loop
default USART3 STLINK Virtual COM Port to the host
LD1/LD2/LD3 or verified 3.3-V I²C display for state
physical E-stop plus firmware current, time, temperature and encoder-loss interlocks
Intelligence to incorporate
Create run-level features such as speed error, current mean/peak, PWM mean, acceleration proxy, temperature slope, time in saturation and encoder-transition rate. Compare a transparent rule baseline with two course-approved classical classifiers such as logistic regression, decision tree or random forest. Use run-wise train/validation/test separation. Primary metrics are macro-F1, dangerous-fault recall and false-trip rate; accuracy alone is insufficient.
Permitted output/action set
NORMAL · CAUTION · DERATE · CONTROLLED_STOP
Canonical family command contract: every parent brief, variant, host message and MCU acknowledgement for P01 shall use these exact identifiers. A variant may use only the applicable subset; it shall not introduce a synonym.
Core problem equipment · EQ-01-CORE
Complete equipment required for one core-problem team
Standalone family BOM. This list supports the parent problem itself. An allocated variant uses its own complete table later in this card. A component mentioned again in the fixture description is the same mounted unit, not another copy.
4 students; 3 by approved exception1 H753 board1 team laptopquantities per team
Controller1 H753 board + 1 laptop
Sensequadrature Hall encoder integrated with the motor or equivalent timer-compati…
Actuate6–12 V, 100–300 rpm low-torque geared DC motor with encoder; 3.3-V-logic H-br…
Fixtureguarded motor base with rigid mount, shaft coupler and repeatable adjustable-…
Protectcurrent-limited 6–12 V DC supply, 2–3 A or correctly matched to the issued mo…
System block
Complete quantity and equipment per team
Purpose / acceptance condition
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Release-to-team condition: The motor must run, stop and enter its hard-safe state without the laptop connected. The organiser signs the electrical, mechanical and communication acceptance checklist before H0:00.
Not duplicated inside the kit: supervised rework tools and the oscilloscope/logic-analyser station are shared at the ratio stated above. Everything else in this table is issued to, reserved for, or digitally assigned to this team.
Controlled self-learning extension
Recommended Implement timer-triggered ADC capture into an organiser-provided DMA-safe buffer and quantify missed/late samples against an interrupt-only logger. The team owns configuration, measurements and explanation; cache/DMA boilerplate may be supplied.
System safety and non-negotiable boundary
Hard overcurrent, overtemperature, watchdog, command timeout and encoder-loss interlocks remain entirely on the MCU. The ML output cannot write raw PWM or disable any interlock. When the host disappears, the system returns to the deterministic controller or safe stop defined in the state machine.
Student interpretation — what this challenge really asks
A motor drawing extra current is not automatically jammed. The product must combine motion, current, command and temperature evidence so that it tolerates a harmless load change but reacts early to a persistent or unsafe condition.
Independent data unitone uninterrupted operating run at a declared speed, direction and load condition.
Closest misleading casea short legitimate load transient that resembles the beginning of a jam.
Definition of successStudents must correctly distinguish the hazardous condition from its closest harmless look-alike and execute the bounded MCU-approved response.
Visual system blueprint
Physical processMotor and mechanical loadGenerate labelled, safe and repeatable conditions.
Observesetpoint, direction, encoder speed/positionPreserve units, timestamps, run identity and signal quality.
H753 responsibilityControl and protectrun the fixed-period speed/position loop, detect hard electrical or motion limits and produce trustworthy timestamped telemetry.
Host intelligenceLearn the distinctionseparate normal operation, legitimate load change and dangerous motor/mechanical/sensor states.
Bounded outcomeNORMAL · CAUTION · DERATE · CONTROLLED_STOPMCU validates, acknowledges and may refuse the request.
Recommended build journey
Make the process repeatableAssemble the guarded H753-M motor/encoder/current/temperature rig; define reference and target conditions before collecting data.
Prove deterministic firmwareRun the fixed-period speed/position loop, detect hard electrical or motion limits and produce trustworthy timestamped telemetry. Demonstrate every hard limit before connecting ML.
Build trustworthy trialsTreat one uninterrupted operating run at a declared speed, direction and load condition as independent; calibrate, label and split by run/session.
Beat a real baselineCompare current threshold plus persistent speed-error rule with two syllabus-approved classical models.
Close and challenge the loopReturn only the applicable subset of NORMAL · CAUTION · DERATE · CONTROLLED_STOP; test the target, nearest confuser, stale command and host loss.
Definition of done
Firmware controls safely before, during and after host connection.
Portfolio shows a synchronized current–speed–prediction timeline and a confusion matrix and one honest failure case.
Problem-specific evidence at the common reviews
R1 · Design
Freeze five operating states, the safe-load fixture, signal list, CAN/UART message map and hidden-test acceptance thresholds.
R2 · Embedded
Demonstrate stable PWM control, encoder/current/temperature acquisition, LCD status, telemetry, emergency stop and one injected hard fault.
R3 · Data
Submit labelled seed-plus-live runs, run IDs, class balance report, rule baseline and leakage-safe split.
R4 · ML
Show two trained classifiers, fault-recall/error analysis and mapping from probabilities to the four bounded commands.
R5 · Integration
Demonstrate live prediction, command validation, host-loss fallback and at least three injected faults without unsafe motion.
Final
Run a blind sequence containing normal load, transient load, sustained overload, jam and sensor fault; present portfolio assets and model limitations.
Portfolio/Kaggle outcome
Publish a Kaggle-compatible ‘STM32 Motor Operating States’ dataset with a data dictionary, labelled runs, feature notebook, baseline-versus-model comparison, confusion matrix, feature-importance discussion and a failure-analysis section. The GitHub portfolio should add firmware, wiring, CAN/UART protocol, state diagram and demo video.
Industry alignment and validation basis
MotorGuard: external references and required evidence
The listed sources establish relevance, test discipline and implementation precedent. They do not modify the common syllabus boundary, safety rules or 100-mark assessment rubric.
Family implementation profile
Variant availability: 10 standard assignment(s); 0 organiser-supported assignment(s).
Public evidence: reproducible firmware, protocol, dataset, notebook/model, test report and demonstration video.
What the external benchmark confirms
The problem has a recognisable industrial or challenge analogue, a measurable data task, a defensible embedded implementation and a safe operational decision. Every one of its ten variants is mapped separately below.
Condition before team allocation
Supply a common transient-load/jam protocol and a few rare sensor-fault seed runs so every team faces the same nearest-confuser test.
Combine process state, velocity, torque, current, voltage and timing context for conveyor anomaly detection, diagnosis and productivity analysis.
Condition inference on process phase; preserve physical context; test root-cause discrimination and subtask timing rather than a context-free threshold.
Combine sensor measurements and system knowledge to build condition indicators, detect faults and support predictive-maintenance decisions.
Start with an engineering baseline, justify features physically, validate on held-out operating conditions and connect inference to a maintenance action.
Collect heterogeneous sensor and motor-control telemetry for real-time monitoring, performance assessment, labelling and Python-side data workflows.
Synchronise sensor, command and motor telemetry; keep labels and configuration with each run; provide replayable host-side data.
Open the 10 fully elaborated student variant briefs
Choose only the variant allocated to your team. Read it together with the parent problem above: the card expands the experimental delta, while every hardware, safety, integration and review requirement of the family remains active.
Variant 01.01
Conveyor Jam Guardian
Engineering purpose: Tests operational continuity without weakening jam safety.
LearnMulticlass classification from current, speed error and recovery time.
DecideNORMAL, CAUTION, DERATE or CONTROLLED_STOP
Provemacro-F1, dangerous-state recall, false-trip rate and detection…
Variant equipment · EQ-01-01
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensequadrature Hall encoder integrated with the motor or equivalent timer-compati…
Actuate6–12 V, 100–300 rpm low-torque geared DC motor with encoder; 3.3-V-logic H-br…
Fixtureguarded mini-conveyor or driven-wheel stand with belt/contact wheel; identica…
Protectcurrent-limited 6–12 V DC supply, 2–3 A or correctly matched to the issued mo…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: The motor must run, stop and enter its hard-safe state without the laptop connected. Verify the complete EQ-01-01 manifest before data collection.
1 · Scenario and student challenge
Use a belt or wheel fixture with short parcel-like disturbances and persistent blockage; the critical distinction is transient load versus true jam. In plain language, adapt MotorGuard — Multisignal Operating-State and Fault Classifier so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Tests operational continuity without weakening jam safety.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M + the named safe mechanical/condition fixture. Begin with the guarded H753-M motor/encoder/current/temperature rig and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record setpoint, direction, encoder speed/position, conditioned current, PWM duty, temperature and local fault bits. Treat one uninterrupted operating run at a declared speed, direction and load condition as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Multiclass classification from current, speed error and recovery time. First implement the parent baseline—current threshold plus persistent speed-error rule—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only NORMAL, CAUTION, DERATE or CONTROLLED_STOP, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a short legitimate load transient that resembles the beginning of a jam. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 01.01 — Conveyor Jam Guardian”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M + the named safe mechanical/condition fixtureclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P01 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Conveyor Jam Guardian is a syllabus-scaled physical analogue of the need evidenced by IU01 · Designing Algorithms for Condition Monitoring and Predictive Maintenance: Use a belt or wheel fixture with short parcel-like disturbances and persistent blockage; the critical distinction is transient load versus true jam. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needCombine sensor measurements and system knowledge to build condition indicators, detect faults and support predictive-maintenance decisions.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Start with an engineering baseline, justify features physically, validate on held-out operating conditions and connect inference to a maintenance action.
Students use only tools/models on the released course whitelist; MathWorks products are not mandatory.
Condition inference on process phase; preserve physical context; test root-cause discrimination and subtask timing rather than a context-free threshold.
The H753 cell uses a smaller signal set and safe injected resistance while retaining the context-sensitive evaluation idea.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationSupply a common transient-load/jam protocol and a few rare sensor-fault seed runs so every team faces the same nearest-confuser test.
Variant 01.02
Cooling-Fan Health Guardian
Engineering purpose: Introduces gradual degradation rather than only abrupt faults.
LearnClassification with temperature-rise and current/speed features.
DecideNORMAL, CAUTION, DERATE or CONTROLLED_STOP
Provemacro-F1, dangerous-state recall, false-trip rate and detection…
Variant equipment · EQ-01-02
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensequadrature Hall encoder integrated with the motor or equivalent timer-compati…
Actuate6–12 V, 100–300 rpm low-torque geared DC motor with encoder; 3.3-V-logic H-br…
Fixtureguarded 5/12 V fan/impeller mount with exposed blades fully shrouded; removab…
Protectcurrent-limited 6–12 V DC supply, 2–3 A or correctly matched to the issued mo…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: The motor must run, stop and enter its hard-safe state without the laptop connected. Verify the complete EQ-01-02 manifest before data collection.
1 · Scenario and student challenge
Use a fan or impeller load and distinguish free flow, partial blockage, heavy blockage and motor drag. In plain language, adapt MotorGuard — Multisignal Operating-State and Fault Classifier so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Introduces gradual degradation rather than only abrupt faults.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M + the named safe mechanical/condition fixture. Begin with the guarded H753-M motor/encoder/current/temperature rig and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record setpoint, direction, encoder speed/position, conditioned current, PWM duty, temperature and local fault bits. Treat one uninterrupted operating run at a declared speed, direction and load condition as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Classification with temperature-rise and current/speed features. First implement the parent baseline—current threshold plus persistent speed-error rule—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only NORMAL, CAUTION, DERATE or CONTROLLED_STOP, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a short legitimate load transient that resembles the beginning of a jam. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 01.02 — Cooling-Fan Health Guardian”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M + the named safe mechanical/condition fixtureclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P01 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Cooling-Fan Health Guardian is a syllabus-scaled physical analogue of the need evidenced by IU01 · Designing Algorithms for Condition Monitoring and Predictive Maintenance: Use a fan or impeller load and distinguish free flow, partial blockage, heavy blockage and motor drag. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needCombine sensor measurements and system knowledge to build condition indicators, detect faults and support predictive-maintenance decisions.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Start with an engineering baseline, justify features physically, validate on held-out operating conditions and connect inference to a maintenance action.
Students use only tools/models on the released course whitelist; MathWorks products are not mandatory.
Condition inference on process phase; preserve physical context; test root-cause discrimination and subtask timing rather than a context-free threshold.
The H753 cell uses a smaller signal set and safe injected resistance while retaining the context-sensitive evaluation idea.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationSupply a common transient-load/jam protocol and a few rare sensor-fault seed runs so every team faces the same nearest-confuser test.
Variant 01.03
Mini-Hoist Overload Guardian
Engineering purpose: Adds asymmetric risk between lifting and lowering.
LearnLoad-class classification plus overload probability.
DecideNORMAL, CAUTION, DERATE or CONTROLLED_STOP
Provemacro-F1, dangerous-state recall, false-trip rate and detection…
Variant equipment · EQ-01-03
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensequadrature Hall encoder integrated with the motor or equivalent timer-compati…
Actuate6–12 V, 100–300 rpm low-torque geared DC motor with encoder; 3.3-V-logic H-br…
Fixtureguarded drum/spool mini-hoist with cord and top/bottom travel stops; verified…
Protectcurrent-limited 6–12 V DC supply, 2–3 A or correctly matched to the issued mo…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: The motor must run, stop and enter its hard-safe state without the laptop connected. Verify the complete EQ-01-03 manifest before data collection.
1 · Scenario and student challenge
Lift only safe, pre-weighed loads and distinguish permitted load classes from overload or stalled lift. In plain language, adapt MotorGuard — Multisignal Operating-State and Fault Classifier so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Adds asymmetric risk between lifting and lowering.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M + the named safe mechanical/condition fixture. Begin with the guarded H753-M motor/encoder/current/temperature rig and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record setpoint, direction, encoder speed/position, conditioned current, PWM duty, temperature and local fault bits. Treat one uninterrupted operating run at a declared speed, direction and load condition as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Load-class classification plus overload probability. First implement the parent baseline—current threshold plus persistent speed-error rule—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only NORMAL, CAUTION, DERATE or CONTROLLED_STOP, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a short legitimate load transient that resembles the beginning of a jam. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 01.03 — Mini-Hoist Overload Guardian”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M + the named safe mechanical/condition fixtureclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P01 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Mini-Hoist Overload Guardian is a syllabus-scaled physical analogue of the need evidenced by IU01 · Designing Algorithms for Condition Monitoring and Predictive Maintenance: Lift only safe, pre-weighed loads and distinguish permitted load classes from overload or stalled lift. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needCombine sensor measurements and system knowledge to build condition indicators, detect faults and support predictive-maintenance decisions.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Start with an engineering baseline, justify features physically, validate on held-out operating conditions and connect inference to a maintenance action.
Students use only tools/models on the released course whitelist; MathWorks products are not mandatory.
Condition inference on process phase; preserve physical context; test root-cause discrimination and subtask timing rather than a context-free threshold.
The H753 cell uses a smaller signal set and safe injected resistance while retaining the context-sensitive evaluation idea.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationSupply a common transient-load/jam protocol and a few rare sensor-fault seed runs so every team faces the same nearest-confuser test.
Variant 01.04
Gate-Actuator Safety Guardian
Engineering purpose: Makes false negatives safety-critical and therefore analytically meaningful.
Provemacro-F1, dangerous-state recall, false-trip rate and detection…
Variant equipment · EQ-01-04
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensequadrature Hall encoder integrated with the motor or equivalent timer-compati…
Actuate6–12 V, 100–300 rpm low-torque geared DC motor with encoder; 3.3-V-logic H-br…
Fixturelow-force gate arm with two limit switches and marked normal end-stop zone; c…
Protectcurrent-limited 6–12 V DC supply, 2–3 A or correctly matched to the issued mo…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: The motor must run, stop and enter its hard-safe state without the laptop connected. Verify the complete EQ-01-04 manifest before data collection.
1 · Scenario and student challenge
Use a low-force gate arm and separate routine end-stop, soft obstruction, hard obstruction and friction growth. In plain language, adapt MotorGuard — Multisignal Operating-State and Fault Classifier so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Makes false negatives safety-critical and therefore analytically meaningful.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M + the named safe mechanical/condition fixture. Begin with the guarded H753-M motor/encoder/current/temperature rig and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record setpoint, direction, encoder speed/position, conditioned current, PWM duty, temperature and local fault bits. Treat one uninterrupted operating run at a declared speed, direction and load condition as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Cost-sensitive classification prioritising obstruction recall. First implement the parent baseline—current threshold plus persistent speed-error rule—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only NORMAL, CAUTION, DERATE or CONTROLLED_STOP, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a short legitimate load transient that resembles the beginning of a jam. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 01.04 — Gate-Actuator Safety Guardian”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M + the named safe mechanical/condition fixtureclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P01 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Gate-Actuator Safety Guardian is a syllabus-scaled physical analogue of the need evidenced by IU01 · Designing Algorithms for Condition Monitoring and Predictive Maintenance: Use a low-force gate arm and separate routine end-stop, soft obstruction, hard obstruction and friction growth. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needCombine sensor measurements and system knowledge to build condition indicators, detect faults and support predictive-maintenance decisions.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Start with an engineering baseline, justify features physically, validate on held-out operating conditions and connect inference to a maintenance action.
Students use only tools/models on the released course whitelist; MathWorks products are not mandatory.
Condition inference on process phase; preserve physical context; test root-cause discrimination and subtask timing rather than a context-free threshold.
The H753 cell uses a smaller signal set and safe injected resistance while retaining the context-sensitive evaluation idea.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationSupply a common transient-load/jam protocol and a few rare sensor-fault seed runs so every team faces the same nearest-confuser test.
Variant 01.05
Feeder-Auger Jam Guardian
Engineering purpose: Models a common food/agri/manufacturing failure mode using simple features.
LearnClassification using current ripple statistics without FFT.
DecideNORMAL, CAUTION, DERATE or CONTROLLED_STOP
Provemacro-F1, dangerous-state recall, false-trip rate and detection…
Variant equipment · EQ-01-05
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensequadrature Hall encoder integrated with the motor or equivalent timer-compati…
Actuate6–12 V, 100–300 rpm low-torque geared DC motor with encoder; 3.3-V-logic H-br…
Fixturetransparent-guarded miniature auger/shaft and feed tube; batch of clean light…
Protectcurrent-limited 6–12 V DC supply, 2–3 A or correctly matched to the issued mo…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: The motor must run, stop and enter its hard-safe state without the laptop connected. Verify the complete EQ-01-05 manifest before data collection.
1 · Scenario and student challenge
Represent a feeder with a rotating shaft and controlled resistance; detect bridging, gradual compaction and hard jam. In plain language, adapt MotorGuard — Multisignal Operating-State and Fault Classifier so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Models a common food/agri/manufacturing failure mode using simple features.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M + the named safe mechanical/condition fixture. Begin with the guarded H753-M motor/encoder/current/temperature rig and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record setpoint, direction, encoder speed/position, conditioned current, PWM duty, temperature and local fault bits. Treat one uninterrupted operating run at a declared speed, direction and load condition as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Classification using current ripple statistics without FFT. First implement the parent baseline—current threshold plus persistent speed-error rule—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only NORMAL, CAUTION, DERATE or CONTROLLED_STOP, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a short legitimate load transient that resembles the beginning of a jam. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 01.05 — Feeder-Auger Jam Guardian”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M + the named safe mechanical/condition fixtureclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P01 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Feeder-Auger Jam Guardian is a syllabus-scaled physical analogue of the need evidenced by IU01 · Designing Algorithms for Condition Monitoring and Predictive Maintenance: Represent a feeder with a rotating shaft and controlled resistance; detect bridging, gradual compaction and hard jam. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needCombine sensor measurements and system knowledge to build condition indicators, detect faults and support predictive-maintenance decisions.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Start with an engineering baseline, justify features physically, validate on held-out operating conditions and connect inference to a maintenance action.
Students use only tools/models on the released course whitelist; MathWorks products are not mandatory.
Condition inference on process phase; preserve physical context; test root-cause discrimination and subtask timing rather than a context-free threshold.
The H753 cell uses a smaller signal set and safe injected resistance while retaining the context-sensitive evaluation idea.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationSupply a common transient-load/jam protocol and a few rare sensor-fault seed runs so every team faces the same nearest-confuser test.
Variant 01.06
Robotic-Joint Load Guardian
Engineering purpose: Prevents angle-dependent current from being mislabelled as a fault.
LearnClassification conditioned on commanded angle and direction.
DecideNORMAL, CAUTION, DERATE or CONTROLLED_STOP
Provemacro-F1, dangerous-state recall, false-trip rate and detection…
Variant equipment · EQ-01-06
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sense0–3.3 V arm-angle potentiometer or encoder; servo-supply current-sense channe…
Actuateexternally powered low-torque servo with verified 3.3-V PWM input
Fixturelow-force servo/rotary arm with marked angles and external 0–3.3 V angle feed…
Protectregulated 5 V, 2 A servo supply; inline fuse plus spare fuses; hardware servo…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: The motor must run, stop and enter its hard-safe state without the laptop connected. Verify the complete EQ-01-06 manifest before data collection.
1 · Scenario and student challenge
Use a servo arm at several angles and loads; distinguish gravity-related load from abnormal resistance. In plain language, adapt MotorGuard — Multisignal Operating-State and Fault Classifier so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Prevents angle-dependent current from being mislabelled as a fault.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M + the named safe mechanical/condition fixture. Begin with the guarded H753-M motor/encoder/current/temperature rig and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record setpoint, direction, encoder speed/position, conditioned current, PWM duty, temperature and local fault bits. Treat one uninterrupted operating run at a declared speed, direction and load condition as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Classification conditioned on commanded angle and direction. First implement the parent baseline—current threshold plus persistent speed-error rule—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only NORMAL, CAUTION, DERATE or CONTROLLED_STOP, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a short legitimate load transient that resembles the beginning of a jam. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 01.06 — Robotic-Joint Load Guardian”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M + the named safe mechanical/condition fixtureclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P01 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Robotic-Joint Load Guardian is a syllabus-scaled physical analogue of the need evidenced by IU01 · Designing Algorithms for Condition Monitoring and Predictive Maintenance: Use a servo arm at several angles and loads; distinguish gravity-related load from abnormal resistance. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needCombine sensor measurements and system knowledge to build condition indicators, detect faults and support predictive-maintenance decisions.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Start with an engineering baseline, justify features physically, validate on held-out operating conditions and connect inference to a maintenance action.
Students use only tools/models on the released course whitelist; MathWorks products are not mandatory.
Condition inference on process phase; preserve physical context; test root-cause discrimination and subtask timing rather than a context-free threshold.
The H753 cell uses a smaller signal set and safe injected resistance while retaining the context-sensitive evaluation idea.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationSupply a common transient-load/jam protocol and a few rare sensor-fault seed runs so every team faces the same nearest-confuser test.
Variant 01.07
Window-Lift Obstruction Guardian
Engineering purpose: Mirrors an automotive embedded safety problem.
LearnMulticlass classifier with direction-specific features.
DecideNORMAL, CAUTION, DERATE or CONTROLLED_STOP
Provemacro-F1, dangerous-state recall, false-trip rate and detection…
Variant equipment · EQ-01-07
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensequadrature Hall encoder integrated with the motor or equivalent timer-compati…
Actuate6–12 V, 100–300 rpm low-torque geared DC motor with encoder; 3.3-V-logic H-br…
Fixtureguarded vertical slider/window-lift emulator with top/bottom switches; adjust…
Protectcurrent-limited 6–12 V DC supply, 2–3 A or correctly matched to the issued mo…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: The motor must run, stop and enter its hard-safe state without the laptop connected. Verify the complete EQ-01-07 manifest before data collection.
1 · Scenario and student challenge
Use a vertical slider or arm and identify free motion, seal friction, obstruction and encoder inconsistency. In plain language, adapt MotorGuard — Multisignal Operating-State and Fault Classifier so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Mirrors an automotive embedded safety problem.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M + the named safe mechanical/condition fixture. Begin with the guarded H753-M motor/encoder/current/temperature rig and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record setpoint, direction, encoder speed/position, conditioned current, PWM duty, temperature and local fault bits. Treat one uninterrupted operating run at a declared speed, direction and load condition as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Multiclass classifier with direction-specific features. First implement the parent baseline—current threshold plus persistent speed-error rule—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only NORMAL, CAUTION, DERATE or CONTROLLED_STOP, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a short legitimate load transient that resembles the beginning of a jam. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 01.07 — Window-Lift Obstruction Guardian”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M + the named safe mechanical/condition fixtureclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P01 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Window-Lift Obstruction Guardian is a syllabus-scaled physical analogue of the need evidenced by IU01 · Designing Algorithms for Condition Monitoring and Predictive Maintenance: Use a vertical slider or arm and identify free motion, seal friction, obstruction and encoder inconsistency. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needCombine sensor measurements and system knowledge to build condition indicators, detect faults and support predictive-maintenance decisions.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Start with an engineering baseline, justify features physically, validate on held-out operating conditions and connect inference to a maintenance action.
Students use only tools/models on the released course whitelist; MathWorks products are not mandatory.
Condition inference on process phase; preserve physical context; test root-cause discrimination and subtask timing rather than a context-free threshold.
The H753 cell uses a smaller signal set and safe injected resistance while retaining the context-sensitive evaluation idea.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationSupply a common transient-load/jam protocol and a few rare sensor-fault seed runs so every team faces the same nearest-confuser test.
Variant 01.08
Spindle Drag Guardian
Engineering purpose: Adds speed-dependent baselines and maintenance relevance.
Provemacro-F1, dangerous-state recall, false-trip rate and detection…
Variant equipment · EQ-01-08
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensequadrature Hall encoder integrated with the motor or equivalent timer-compati…
Actuate6–12 V, 100–300 rpm low-torque geared DC motor with encoder; 3.3-V-logic H-br…
Fixtureguarded spindle/disc stand; adjustable felt-brake settings: free, drag and se…
Protectcurrent-limited 6–12 V DC supply, 2–3 A or correctly matched to the issued mo…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: The motor must run, stop and enter its hard-safe state without the laptop connected. Verify the complete EQ-01-08 manifest before data collection.
1 · Scenario and student challenge
Operate a small rotating load at multiple speeds and identify healthy, increased drag and severe resistance. In plain language, adapt MotorGuard — Multisignal Operating-State and Fault Classifier so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Adds speed-dependent baselines and maintenance relevance.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M + the named safe mechanical/condition fixture. Begin with the guarded H753-M motor/encoder/current/temperature rig and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record setpoint, direction, encoder speed/position, conditioned current, PWM duty, temperature and local fault bits. Treat one uninterrupted operating run at a declared speed, direction and load condition as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Ordinal classification of drag severity. First implement the parent baseline—current threshold plus persistent speed-error rule—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only NORMAL, CAUTION, DERATE or CONTROLLED_STOP, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a short legitimate load transient that resembles the beginning of a jam. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 01.08 — Spindle Drag Guardian”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M + the named safe mechanical/condition fixtureclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P01 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Spindle Drag Guardian is a syllabus-scaled physical analogue of the need evidenced by IU01 · Designing Algorithms for Condition Monitoring and Predictive Maintenance: Operate a small rotating load at multiple speeds and identify healthy, increased drag and severe resistance. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needCombine sensor measurements and system knowledge to build condition indicators, detect faults and support predictive-maintenance decisions.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Start with an engineering baseline, justify features physically, validate on held-out operating conditions and connect inference to a maintenance action.
Students use only tools/models on the released course whitelist; MathWorks products are not mandatory.
Condition inference on process phase; preserve physical context; test root-cause discrimination and subtask timing rather than a context-free threshold.
The H753 cell uses a smaller signal set and safe injected resistance while retaining the context-sensitive evaluation idea.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationSupply a common transient-load/jam protocol and a few rare sensor-fault seed runs so every team faces the same nearest-confuser test.
Variant 01.09
Mobility-Wheel Resistance Guardian
Engineering purpose: Builds a portfolio story around assistive or autonomous mobility hardware.
LearnClassification using setpoint-normalised current and speed deficit.
DecideNORMAL, CAUTION, DERATE or CONTROLLED_STOP
Provemacro-F1, dangerous-state recall, false-trip rate and detection…
Variant equipment · EQ-01-09
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensequadrature Hall encoder integrated with the motor or equivalent timer-compati…
Actuate6–12 V, 100–300 rpm low-torque geared DC motor with encoder; 3.3-V-logic H-br…
Fixturewheel-on-roller stand with wheel guard; interchangeable surface/contact pads…
Protectcurrent-limited 6–12 V DC supply, 2–3 A or correctly matched to the issued mo…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: The motor must run, stop and enter its hard-safe state without the laptop connected. Verify the complete EQ-01-09 manifest before data collection.
1 · Scenario and student challenge
Use a wheel fixture and distinguish surface/load resistance from mechanical lock. In plain language, adapt MotorGuard — Multisignal Operating-State and Fault Classifier so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Builds a portfolio story around assistive or autonomous mobility hardware.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M + the named safe mechanical/condition fixture. Begin with the guarded H753-M motor/encoder/current/temperature rig and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record setpoint, direction, encoder speed/position, conditioned current, PWM duty, temperature and local fault bits. Treat one uninterrupted operating run at a declared speed, direction and load condition as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Classification using setpoint-normalised current and speed deficit. First implement the parent baseline—current threshold plus persistent speed-error rule—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only NORMAL, CAUTION, DERATE or CONTROLLED_STOP, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a short legitimate load transient that resembles the beginning of a jam. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 01.09 — Mobility-Wheel Resistance Guardian”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M + the named safe mechanical/condition fixtureclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P01 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Mobility-Wheel Resistance Guardian is a syllabus-scaled physical analogue of the need evidenced by IU01 · Designing Algorithms for Condition Monitoring and Predictive Maintenance: Use a wheel fixture and distinguish surface/load resistance from mechanical lock. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needCombine sensor measurements and system knowledge to build condition indicators, detect faults and support predictive-maintenance decisions.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Start with an engineering baseline, justify features physically, validate on held-out operating conditions and connect inference to a maintenance action.
Students use only tools/models on the released course whitelist; MathWorks products are not mandatory.
Condition inference on process phase; preserve physical context; test root-cause discrimination and subtask timing rather than a context-free threshold.
The H753 cell uses a smaller signal set and safe injected resistance while retaining the context-sensitive evaluation idea.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationSupply a common transient-load/jam protocol and a few rare sensor-fault seed runs so every team faces the same nearest-confuser test.
Variant 01.10
Bidirectional Drive Guardian
Engineering purpose: Exposes faults hidden by one-direction testing.
LearnClassification with direction as a feature and separate error analysis.
DecideNORMAL, CAUTION, DERATE or CONTROLLED_STOP
Provemacro-F1, dangerous-state recall, false-trip rate and detection…
Variant equipment · EQ-01-10
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensequadrature Hall encoder integrated with the motor or equivalent timer-compati…
Actuate6–12 V, 100–300 rpm low-torque geared DC motor with encoder; 3.3-V-logic H-br…
Fixturesymmetric bidirectional shaft/arm fixture; reversible alignment shim and dire…
Protectcurrent-limited 6–12 V DC supply, 2–3 A or correctly matched to the issued mo…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: The motor must run, stop and enter its hard-safe state without the laptop connected. Verify the complete EQ-01-10 manifest before data collection.
1 · Scenario and student challenge
Compare forward and reverse behaviour and detect direction-specific driver, alignment or friction anomalies. In plain language, adapt MotorGuard — Multisignal Operating-State and Fault Classifier so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Exposes faults hidden by one-direction testing.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M + the named safe mechanical/condition fixture. Begin with the guarded H753-M motor/encoder/current/temperature rig and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record setpoint, direction, encoder speed/position, conditioned current, PWM duty, temperature and local fault bits. Treat one uninterrupted operating run at a declared speed, direction and load condition as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Classification with direction as a feature and separate error analysis. First implement the parent baseline—current threshold plus persistent speed-error rule—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only NORMAL, CAUTION, DERATE or CONTROLLED_STOP, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a short legitimate load transient that resembles the beginning of a jam. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 01.10 — Bidirectional Drive Guardian”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M + the named safe mechanical/condition fixtureclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P01 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Bidirectional Drive Guardian is a syllabus-scaled physical analogue of the need evidenced by IU01 · Designing Algorithms for Condition Monitoring and Predictive Maintenance: Compare forward and reverse behaviour and detect direction-specific driver, alignment or friction anomalies. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needCombine sensor measurements and system knowledge to build condition indicators, detect faults and support predictive-maintenance decisions.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Start with an engineering baseline, justify features physically, validate on held-out operating conditions and connect inference to a maintenance action.
Students use only tools/models on the released course whitelist; MathWorks products are not mandatory.
Condition inference on process phase; preserve physical context; test root-cause discrimination and subtask timing rather than a context-free threshold.
The H753 cell uses a smaller signal set and safe injected resistance while retaining the context-sensitive evaluation idea.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationSupply a common transient-load/jam protocol and a few rare sensor-fault seed runs so every team faces the same nearest-confuser test.
Problem 02 · 10 variants · Motion, drive and actuator intelligence
StartSense — Startup Signature Intelligence for Electric Drives
Team size: 4; approved 3-member exception1 × NUCLEO-H753ZIH753-MClassificationIntermediate
Assigned Faculty Master pair for P02: one nominated ESD Faculty Master and one nominated ML Faculty Master shall jointly master this parent problem and variants V1-V10. The ESD Master owns hardware, firmware, control, communication and safety verification; the ML Master owns data, baselines, models, validation and bounded decision-policy verification. Together they teach and guide ten teams (one for each variant and up to 40 students), supervise five teams in Wave A and five in Wave B, witness integration and sign every final evaluation.
The problem
Many electromechanical faults are most visible during the first few hundred milliseconds after a start command. A conventional controller often waits for a steady-state threshold, missing early warning signs such as slow acceleration, excessive inrush duration, encoder delay, high initial friction or a blocked rotor. The challenge is to turn the startup transient into a diagnostic signature without using vibration sensors, FFT or deep learning.
Smart embedded product to build
Build a NUCLEO-H753ZI startup-signature instrument that executes a repeatable bounded start profile and records timestamp, PWM, conditioned current, first encoder transition, speed, temperature and direction. Each start is one immutable run with a firmware-generated ID, hard current/time abort and restart cool-down. The host model judges the episode within a declared early window and returns ACCEPT_START, RETRY_SAFE_PROFILE, DERATE or STOP; the board enforces the retry budget.
NUCLEO-H753ZI realization and issued pack
NUCLEO-H753ZI / MB1364E with H753-M pack
timer PWM and encoder/input-capture channels for the startup episode
ADC current and temperature signals constrained to 0–3.3 V
B1 USER button or guarded external button starts a trial; firmware assigns run and sample sequences
short high-rate capture window followed by lower-rate telemetry over USART3 VCP
approved H-bridge, fused external motor power and rate-limited restart state machine
LED/display reports READY, CAPTURE, ACCEPT, RETRY, DERATE or STOP
Intelligence to incorporate
Engineer tabular start features: peak current, time above current threshold, time-to-first-encoder-pulse, acceleration estimate, time to 50/90% speed, current integral proxy, overshoot and temperature. Compare a rule baseline with linear/logistic and tree-based models. Split by physical start trial, not by samples inside the same start. Evaluate early-detection latency, fault recall and false rejection of healthy cold/warm starts.
Permitted output/action set
ACCEPT_START · RETRY_SAFE_PROFILE · DERATE · STOP
Canonical family command contract: every parent brief, variant, host message and MCU acknowledgement for P02 shall use these exact identifiers. A variant may use only the applicable subset; it shall not introduce a synonym.
Core problem equipment · EQ-02-CORE
Complete equipment required for one core-problem team
Standalone family BOM. This list supports the parent problem itself. An allocated variant uses its own complete table later in this card. A component mentioned again in the fixture description is the same mounted unit, not another copy.
4 students; 3 by approved exception1 H753 board1 team laptopquantities per team
Controller1 H753 board + 1 laptop
Sensemotor quadrature encoder/tachometer; 0–3.3 V conditioned current-sense channe…
Actuate6–12 V geared DC motor with encoder and documented no-load/stall current; 3.3…
Fixtureguarded startup-test base with removable inertia/load/brake inserts and a rep…
Protectcurrent-limited 6–12 V DC supply matched to the motor; inline fuse holder plu…
System block
Complete quantity and equipment per team
Purpose / acceptance condition
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser seed set containing cold, warm and safely aborted starts
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Release-to-team condition: Every start must be bounded by firmware current, time, retry and cool-down limits. The organiser signs the electrical, mechanical and communication acceptance checklist before H0:00.
Not duplicated inside the kit: supervised rework tools and the oscilloscope/logic-analyser station are shared at the ratio stated above. Everything else in this table is issued to, reserved for, or digitally assigned to this team.
Controlled self-learning extension
Recommended Add a circular pre-trigger/post-trigger startup recorder. Preserve the fixed protection path, then measure how capture-window length affects diagnosis latency and recall.
System safety and non-negotiable boundary
Each startup is time- and current-bounded in firmware. The ML decision is advisory after or during a diagnostic window; independent stall/overcurrent logic always wins. Repeated starts are rate-limited to prevent overheating.
Student interpretation — what this challenge really asks
The first moments after a start command contain a compact diagnostic signature. Students turn that transient into evidence for early intervention without requiring vibration analysis, FFT or deep learning.
Independent data unitone complete start episode from rest to the success, timeout or trip condition.
Closest misleading casea valid cold, warm or high-inertia start that is slower than the nominal trace.
Definition of successStudents must make the diagnosis early enough to be useful while accepting legitimate startup variation.
Visual system blueprint
Physical processRepeatable motor startGenerate labelled, safe and repeatable conditions.
Observestart command, direction, PWMPreserve units, timestamps, run identity and signal quality.
H753 responsibilityControl and protectexecute a bounded start profile, segment and buffer every start episode, and stop independently on current or time limits.
Host intelligenceLearn the distinctionrecognise healthy, slow, asymmetric, sensor-delayed and blocked starts before steady state.
Bounded outcomeACCEPT_START · RETRY_SAFE_PROFILE · DERATE · STOPMCU validates, acknowledges and may refuse the request.
Recommended build journey
Make the process repeatableAssemble the H753-M rig with a faculty-approved repeatable start/load fixture; define reference and target conditions before collecting data.
Prove deterministic firmwareExecute a bounded start profile, segment and buffer every start episode, and stop independently on current or time limits. Demonstrate every hard limit before connecting ML.
Build trustworthy trialsTreat one complete start episode from rest to the success, timeout or trip condition as independent; calibrate, label and split by run/session.
Beat a real baselineCompare peak-current and time-to-speed limits with two syllabus-approved classical models.
Close and challenge the loopReturn only the applicable subset of ACCEPT_START · RETRY_SAFE_PROFILE · DERATE · STOP; test the target, nearest confuser, stale command and host loss.
Definition of done
Firmware controls safely before, during and after host connection.
Portfolio shows overlaid start signatures with the model decision point marked and one honest failure case.
Problem-specific evidence at the common reviews
R1 · Design
Define the start sequence, four signature classes, safe repeat count, diagnostic window and trial schema.
R2 · Embedded
Demonstrate repeatable starts, accurate timebase, current/encoder capture, trial IDs and firmware abort limits.
R3 · Data
Provide at least several independent starts per condition plus seed data, feature extraction and a threshold baseline.
R4 · ML
Show class probabilities or risk score, early-detection analysis and model behaviour across cold/warm or direction conditions.
R5 · Integration
Integrate the decision with safe retry/derate/stop, then pass blocked-start, delayed-encoder and host-loss tests.
Final
Diagnose unseen startup trials live and explain both correct and incorrect predictions from the feature evidence.
Portfolio/Kaggle outcome
Kaggle asset: a ‘Motor Startup Transient Signatures’ dataset where each row is one trial plus optional raw telemetry files. Notebook sections should cover waveform-to-feature conversion, leakage-safe splitting, baseline rules, model comparison, threshold selection and examples of misclassified starts.
Industry alignment and validation basis
StartSense: external references and required evidence
The listed sources establish relevance, test discipline and implementation precedent. They do not modify the common syllabus boundary, safety rules or 100-mark assessment rubric.
Family implementation profile
Variant availability: 9 standard assignment(s); 1 organiser-supported assignment(s).
Public evidence: reproducible firmware, protocol, dataset, notebook/model, test report and demonstration video.
What the external benchmark confirms
The problem has a recognisable industrial or challenge analogue, a measurable data task, a defensible embedded implementation and a safe operational decision. Every one of its ten variants is mapped separately below.
Condition before team allocation
Use a guarded repeatable start/load jig and cap start duration/current; give each team temperature-conditioned seed starts.
Report industry needs and challenges for manufacturing anomaly detection, diagnosis, prognostics and actionable health monitoring.
State the operational decision, data provenance and false-alarm cost, and demonstrate how diagnosis improves maintenance or process action.
Open the 10 fully elaborated student variant briefs
Choose only the variant allocated to your team. Read it together with the parent problem above: the card expands the experimental delta, while every hardware, safety, integration and review requirement of the family remains active.
Variant 02.01
Cold-versus-Warm Start Diagnoser
Engineering purpose: Prevents valid thermal variation from becoming a false alarm.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensemotor quadrature encoder/tachometer; 0–3.3 V conditioned current-sense channe…
Actuate6–12 V geared DC motor with encoder and documented no-load/stall current; 3.3…
Fixturestandard startup jig with removable temperature probe clamp; low-voltage cool…
Protectcurrent-limited 6–12 V DC supply matched to the motor; inline fuse holder plu…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser seed set containing cold, warm and safely aborted starts
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Every start must be bounded by firmware current, time, retry and cool-down limits. Verify the complete EQ-02-01 manifest before data collection.
1 · Scenario and student challenge
Model normal signature changes caused by motor temperature before detecting true faults. In plain language, adapt StartSense — Startup Signature Intelligence for Electric Drives so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Prevents valid thermal variation from becoming a false alarm.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M + the named safe mechanical/condition fixture. Begin with the H753-M rig with a faculty-approved repeatable start/load fixture and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record start command, direction, PWM, current, encoder pulse timing, speed, temperature and supply/load proxy. Treat one complete start episode from rest to the success, timeout or trip condition as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Classification with temperature-conditioned features. First implement the parent baseline—peak-current and time-to-speed limits—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only ACCEPT_START, RETRY_SAFE_PROFILE, DERATE or STOP, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a valid cold, warm or high-inertia start that is slower than the nominal trace. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 02.01 — Cold-versus-Warm Start Diagnoser”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M + the named safe mechanical/condition fixtureclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P02 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Cold-versus-Warm Start Diagnoser is a syllabus-scaled physical analogue of the need evidenced by BM03 · Diagnostic Approach for Electro-Mechanical Actuators in Aerospace Systems: Model normal signature changes caused by motor temperature before detecting true faults. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needUse condition indicators to detect, identify and isolate actuator fault modes while distinguishing sensor faults from component failures.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Benchmark the model against a current threshold and test at multiple speeds, directions or loads.
The handbook intentionally uses time-domain summary features; FFT/spectral analysis is not compulsory.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationUse a guarded repeatable start/load jig and cap start duration/current; give each team temperature-conditioned seed starts.
Variant 02.02
High-Inertia Start Recogniser
Engineering purpose: Adds physics-informed context to startup diagnosis.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensemotor quadrature encoder/tachometer; 0–3.3 V conditioned current-sense channe…
Actuate6–12 V geared DC motor with encoder and documented no-load/stall current; 3.3…
Fixtureguarded flywheel/inertia fixture; balanced removable inertia discs with keyed…
Protectcurrent-limited 6–12 V DC supply matched to the motor; inline fuse holder plu…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser seed set containing cold, warm and safely aborted starts
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Every start must be bounded by firmware current, time, retry and cool-down limits. Verify the complete EQ-02-02 manifest before data collection.
1 · Scenario and student challenge
Use approved inertial attachments or load classes and distinguish legitimate slow acceleration from obstruction. In plain language, adapt StartSense — Startup Signature Intelligence for Electric Drives so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Adds physics-informed context to startup diagnosis.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M + the named safe mechanical/condition fixture. Begin with the H753-M rig with a faculty-approved repeatable start/load fixture and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record start command, direction, PWM, current, encoder pulse timing, speed, temperature and supply/load proxy. Treat one complete start episode from rest to the success, timeout or trip condition as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Load-class or normal/fault classification. First implement the parent baseline—peak-current and time-to-speed limits—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only ACCEPT_START, RETRY_SAFE_PROFILE, DERATE or STOP, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a valid cold, warm or high-inertia start that is slower than the nominal trace. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 02.02 — High-Inertia Start Recogniser”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M + the named safe mechanical/condition fixtureclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P02 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
High-Inertia Start Recogniser is a syllabus-scaled physical analogue of the need evidenced by BM03 · Diagnostic Approach for Electro-Mechanical Actuators in Aerospace Systems: Use approved inertial attachments or load classes and distinguish legitimate slow acceleration from obstruction. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needUse condition indicators to detect, identify and isolate actuator fault modes while distinguishing sensor faults from component failures.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Benchmark the model against a current threshold and test at multiple speeds, directions or loads.
The handbook intentionally uses time-domain summary features; FFT/spectral analysis is not compulsory.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationUse a guarded repeatable start/load jig and cap start duration/current; give each team temperature-conditioned seed starts.
Variant 02.03
Blocked-Rotor Early Stop
Engineering purpose: Creates a measurable safety-performance objective.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensemotor quadrature encoder/tachometer; 0–3.3 V conditioned current-sense channe…
Actuate6–12 V geared DC motor with encoder and documented no-load/stall current; 3.3…
Fixtureguarded motor-shaft lock fixture with torque-limited slip/coupler; visible BL…
Protectcurrent-limited 6–12 V DC supply matched to the motor; inline fuse holder plu…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser seed set containing cold, warm and safely aborted starts
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Every start must be bounded by firmware current, time, retry and cool-down limits. Verify the complete EQ-02-03 manifest before data collection.
1 · Scenario and student challenge
Minimise the time between energisation and safe recognition of a blocked shaft. In plain language, adapt StartSense — Startup Signature Intelligence for Electric Drives so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Creates a measurable safety-performance objective.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M + the named safe mechanical/condition fixture. Begin with the H753-M rig with a faculty-approved repeatable start/load fixture and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record start command, direction, PWM, current, encoder pulse timing, speed, temperature and supply/load proxy. Treat one complete start episode from rest to the success, timeout or trip condition as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Binary classifier optimised for detection latency and recall. First implement the parent baseline—peak-current and time-to-speed limits—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only ACCEPT_START, RETRY_SAFE_PROFILE, DERATE or STOP, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a valid cold, warm or high-inertia start that is slower than the nominal trace. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 02.03 — Blocked-Rotor Early Stop”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M + the named safe mechanical/condition fixtureclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P02 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Blocked-Rotor Early Stop is a syllabus-scaled physical analogue of the need evidenced by BM03 · Diagnostic Approach for Electro-Mechanical Actuators in Aerospace Systems: Minimise the time between energisation and safe recognition of a blocked shaft. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needUse condition indicators to detect, identify and isolate actuator fault modes while distinguishing sensor faults from component failures.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Benchmark the model against a current threshold and test at multiple speeds, directions or loads.
The handbook intentionally uses time-domain summary features; FFT/spectral analysis is not compulsory.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationUse a guarded repeatable start/load jig and cap start duration/current; give each team temperature-conditioned seed starts.
Variant 02.04
Encoder-Delay Diagnoser
Engineering purpose: Requires multisignal reasoning rather than current thresholding.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensemotor quadrature encoder/tachometer; 0–3.3 V conditioned current-sense channe…
Actuate6–12 V geared DC motor with encoder and documented no-load/stall current; 3.3…
Fixturestartup jig with encoder fault-injection switch; keyed PASS/DELAY/DROP encode…
Protectcurrent-limited 6–12 V DC supply matched to the motor; inline fuse holder plu…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser seed set containing cold, warm and safely aborted starts
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Every start must be bounded by firmware current, time, retry and cool-down limits. Verify the complete EQ-02-04 manifest before data collection.
1 · Scenario and student challenge
Inject missing or delayed encoder transitions while current remains plausible. In plain language, adapt StartSense — Startup Signature Intelligence for Electric Drives so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Requires multisignal reasoning rather than current thresholding.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M + the named safe mechanical/condition fixture. Begin with the H753-M rig with a faculty-approved repeatable start/load fixture and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record start command, direction, PWM, current, encoder pulse timing, speed, temperature and supply/load proxy. Treat one complete start episode from rest to the success, timeout or trip condition as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Classification separating sensor-path fault from mechanical stall. First implement the parent baseline—peak-current and time-to-speed limits—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only ACCEPT_START, RETRY_SAFE_PROFILE, DERATE or STOP, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a valid cold, warm or high-inertia start that is slower than the nominal trace. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 02.04 — Encoder-Delay Diagnoser”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M + the named safe mechanical/condition fixtureclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P02 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Encoder-Delay Diagnoser is a syllabus-scaled physical analogue of the need evidenced by BM03 · Diagnostic Approach for Electro-Mechanical Actuators in Aerospace Systems: Inject missing or delayed encoder transitions while current remains plausible. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needUse condition indicators to detect, identify and isolate actuator fault modes while distinguishing sensor faults from component failures.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Benchmark the model against a current threshold and test at multiple speeds, directions or loads.
The handbook intentionally uses time-domain summary features; FFT/spectral analysis is not compulsory.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationUse a guarded repeatable start/load jig and cap start duration/current; give each team temperature-conditioned seed starts.
Variant 02.05
Direction-Asymmetry Diagnoser
Engineering purpose: Finds H-bridge, alignment or friction asymmetry.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensemotor quadrature encoder/tachometer; 0–3.3 V conditioned current-sense channe…
Actuate6–12 V geared DC motor with encoder and documented no-load/stall current; 3.3…
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser seed set containing cold, warm and safely aborted starts
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Every start must be bounded by firmware current, time, retry and cool-down limits. Verify the complete EQ-02-05 manifest before data collection.
1 · Scenario and student challenge
Compare forward and reverse startup signatures. In plain language, adapt StartSense — Startup Signature Intelligence for Electric Drives so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Finds H-bridge, alignment or friction asymmetry.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M + the named safe mechanical/condition fixture. Begin with the H753-M rig with a faculty-approved repeatable start/load fixture and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record start command, direction, PWM, current, encoder pulse timing, speed, temperature and supply/load proxy. Treat one complete start episode from rest to the success, timeout or trip condition as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Classification or anomaly score relative to direction-specific baselines. First implement the parent baseline—peak-current and time-to-speed limits—and then compare two algorithms from the faculty-issued ML whitelist. Train or set the threshold using healthy/training data only. Report event recall, false alarms per normal run and detection delay; show where the method treats a new but valid regime as abnormal. Produce a event timeline with anomaly score, threshold and false-alarm examples.
5 · Embedded integration and safe response
The host may return only ACCEPT_START, RETRY_SAFE_PROFILE, DERATE or STOP, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a valid cold, warm or high-inertia start that is slower than the nominal trace. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 02.05 — Direction-Asymmetry Diagnoser”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M + the named safe mechanical/condition fixtureanomaly/noveltyrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P02 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Direction-Asymmetry Diagnoser is a syllabus-scaled physical analogue of the need evidenced by BM03 · Diagnostic Approach for Electro-Mechanical Actuators in Aerospace Systems: Compare forward and reverse startup signatures. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needUse condition indicators to detect, identify and isolate actuator fault modes while distinguishing sensor faults from component failures.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Benchmark the model against a current threshold and test at multiple speeds, directions or loads.
The handbook intentionally uses time-domain summary features; FFT/spectral analysis is not compulsory.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationUse a guarded repeatable start/load jig and cap start duration/current; give each team temperature-conditioned seed starts.
Variant 02.06
Repeated-Start Thermal Risk
Engineering purpose: Connects trial history to safe duty cycle.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensemotor quadrature encoder/tachometer; 0–3.3 V conditioned current-sense channe…
Actuate6–12 V geared DC motor with encoder and documented no-load/stall current; 3.3…
Fixturerepeat-start fixture with mandatory cool-down indicator; clip-on temperature…
Protectcurrent-limited 6–12 V DC supply matched to the motor; inline fuse holder plu…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser seed set containing cold, warm and safely aborted starts
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Every start must be bounded by firmware current, time, retry and cool-down limits. Verify the complete EQ-02-06 manifest before data collection.
1 · Scenario and student challenge
Model how successive starts change peak current and acceleration as temperature rises. In plain language, adapt StartSense — Startup Signature Intelligence for Electric Drives so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Connects trial history to safe duty cycle.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M + the named safe mechanical/condition fixture. Begin with the H753-M rig with a faculty-approved repeatable start/load fixture and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record start command, direction, PWM, current, encoder pulse timing, speed, temperature and supply/load proxy. Treat one complete start episode from rest to the success, timeout or trip condition as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Regression of thermal-risk score or classification of safe/unsafe restart. First implement the parent baseline—peak-current and time-to-speed limits—and then compare two algorithms from the faculty-issued ML whitelist. Report MAE and RMSE on whole held-out runs, show predicted-versus-measured values, and inspect error by operating condition. If the target is converted to a safe/unsafe decision, also report missed-unsafe and unnecessary-conservative actions. Produce a predicted-versus-measured plot with residuals by operating condition.
5 · Embedded integration and safe response
The host may return only ACCEPT_START, RETRY_SAFE_PROFILE, DERATE or STOP, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a valid cold, warm or high-inertia start that is slower than the nominal trace. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 02.06 — Repeated-Start Thermal Risk”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M + the named safe mechanical/condition fixtureregression/outcomerun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P02 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Repeated-Start Thermal Risk is a syllabus-scaled physical analogue of the need evidenced by BM03 · Diagnostic Approach for Electro-Mechanical Actuators in Aerospace Systems: Model how successive starts change peak current and acceleration as temperature rises. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needUse condition indicators to detect, identify and isolate actuator fault modes while distinguishing sensor faults from component failures.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Benchmark the model against a current threshold and test at multiple speeds, directions or loads.
The handbook intentionally uses time-domain summary features; FFT/spectral analysis is not compulsory.
Implementation modeOrganiser-supported assignmentMay be issued only after the named seed history, reference specimens, calibration set or controlled fixture is prepared.
Required organiser provisionComplete before team allocationUse a guarded repeatable start/load jig and cap start duration/current; give each team temperature-conditioned seed starts.
Variant 02.07
Supply-Sag Emulator
Engineering purpose: Separates electrical supply effects from mechanical faults.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensemotor quadrature encoder/tachometer; 0–3.3 V conditioned current-sense channe…
Actuate6–12 V geared DC motor with encoder and documented no-load/stall current; 3.3…
Fixturestartup rig with safe supply-condition control; faculty-set adjustable curren…
Protectcurrent-limited 6–12 V DC supply matched to the motor; inline fuse holder plu…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser seed set containing cold, warm and safely aborted starts
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Every start must be bounded by firmware current, time, retry and cool-down limits. Verify the complete EQ-02-07 manifest before data collection.
1 · Scenario and student challenge
Use a faculty-approved adjustable low-voltage supply or potentiometer proxy to represent supply condition. In plain language, adapt StartSense — Startup Signature Intelligence for Electric Drives so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Separates electrical supply effects from mechanical faults.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M + the named safe mechanical/condition fixture. Begin with the H753-M rig with a faculty-approved repeatable start/load fixture and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record start command, direction, PWM, current, encoder pulse timing, speed, temperature and supply/load proxy. Treat one complete start episode from rest to the success, timeout or trip condition as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Regression/classification conditioned on supply proxy. First implement the parent baseline—peak-current and time-to-speed limits—and then compare two algorithms from the faculty-issued ML whitelist. Report MAE and RMSE on whole held-out runs, show predicted-versus-measured values, and inspect error by operating condition. If the target is converted to a safe/unsafe decision, also report missed-unsafe and unnecessary-conservative actions. Produce a predicted-versus-measured plot with residuals by operating condition.
5 · Embedded integration and safe response
The host may return only ACCEPT_START, RETRY_SAFE_PROFILE, DERATE or STOP, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a valid cold, warm or high-inertia start that is slower than the nominal trace. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 02.07 — Supply-Sag Emulator”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M + the named safe mechanical/condition fixtureregression/outcomerun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P02 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Supply-Sag Emulator is a syllabus-scaled physical analogue of the need evidenced by BM03 · Diagnostic Approach for Electro-Mechanical Actuators in Aerospace Systems: Use a faculty-approved adjustable low-voltage supply or potentiometer proxy to represent supply condition. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needUse condition indicators to detect, identify and isolate actuator fault modes while distinguishing sensor faults from component failures.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Benchmark the model against a current threshold and test at multiple speeds, directions or loads.
The handbook intentionally uses time-domain summary features; FFT/spectral analysis is not compulsory.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationUse a guarded repeatable start/load jig and cap start duration/current; give each team temperature-conditioned seed starts.
Variant 02.08
Soft-Jam versus Hard-Jam Starter
Engineering purpose: Supports graded actions rather than one binary trip.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensemotor quadrature encoder/tachometer; 0–3.3 V conditioned current-sense channe…
Actuate6–12 V geared DC motor with encoder and documented no-load/stall current; 3.3…
Fixtureguarded shaft-brake fixture; repeatable felt-pad resistance settings plus har…
Protectcurrent-limited 6–12 V DC supply matched to the motor; inline fuse holder plu…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser seed set containing cold, warm and safely aborted starts
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Every start must be bounded by firmware current, time, retry and cool-down limits. Verify the complete EQ-02-08 manifest before data collection.
1 · Scenario and student challenge
Introduce controlled mild and severe resistance during startup. In plain language, adapt StartSense — Startup Signature Intelligence for Electric Drives so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Supports graded actions rather than one binary trip.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M + the named safe mechanical/condition fixture. Begin with the H753-M rig with a faculty-approved repeatable start/load fixture and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record start command, direction, PWM, current, encoder pulse timing, speed, temperature and supply/load proxy. Treat one complete start episode from rest to the success, timeout or trip condition as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Ordinal severity classification. First implement the parent baseline—peak-current and time-to-speed limits—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only ACCEPT_START, RETRY_SAFE_PROFILE, DERATE or STOP, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a valid cold, warm or high-inertia start that is slower than the nominal trace. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 02.08 — Soft-Jam versus Hard-Jam Starter”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M + the named safe mechanical/condition fixtureclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P02 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Soft-Jam versus Hard-Jam Starter is a syllabus-scaled physical analogue of the need evidenced by BM03 · Diagnostic Approach for Electro-Mechanical Actuators in Aerospace Systems: Introduce controlled mild and severe resistance during startup. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needUse condition indicators to detect, identify and isolate actuator fault modes while distinguishing sensor faults from component failures.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Benchmark the model against a current threshold and test at multiple speeds, directions or loads.
The handbook intentionally uses time-domain summary features; FFT/spectral analysis is not compulsory.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationUse a guarded repeatable start/load jig and cap start duration/current; give each team temperature-conditioned seed starts.
Variant 02.09
Profile-A/B Startup Selector
Engineering purpose: Turns diagnosis into a bounded configuration decision.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensemotor quadrature encoder/tachometer; 0–3.3 V conditioned current-sense channe…
Actuate6–12 V geared DC motor with encoder and documented no-load/stall current; 3.3…
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser seed set containing cold, warm and safely aborted starts
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Every start must be bounded by firmware current, time, retry and cool-down limits. Verify the complete EQ-02-09 manifest before data collection.
1 · Scenario and student challenge
Evaluate two or three pre-approved start profiles under known load classes. In plain language, adapt StartSense — Startup Signature Intelligence for Electric Drives so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Turns diagnosis into a bounded configuration decision.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M + the named safe mechanical/condition fixture. Begin with the H753-M rig with a faculty-approved repeatable start/load fixture and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record start command, direction, PWM, current, encoder pulse timing, speed, temperature and supply/load proxy. Treat one complete start episode from rest to the success, timeout or trip condition as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Predict pass/fail or time-to-speed for each profile. First implement the parent baseline—peak-current and time-to-speed limits—and then compare two algorithms from the faculty-issued ML whitelist. Report MAE and RMSE on whole held-out runs, show predicted-versus-measured values, and inspect error by operating condition. If the target is converted to a safe/unsafe decision, also report missed-unsafe and unnecessary-conservative actions. Produce a predicted-versus-measured plot with residuals by operating condition.
5 · Embedded integration and safe response
The host may return only ACCEPT_START, RETRY_SAFE_PROFILE, DERATE or STOP, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a valid cold, warm or high-inertia start that is slower than the nominal trace. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 02.09 — Profile-A/B Startup Selector”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M + the named safe mechanical/condition fixtureregression/outcomerun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P02 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Profile-A/B Startup Selector is a syllabus-scaled physical analogue of the need evidenced by BM03 · Diagnostic Approach for Electro-Mechanical Actuators in Aerospace Systems: Evaluate two or three pre-approved start profiles under known load classes. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needUse condition indicators to detect, identify and isolate actuator fault modes while distinguishing sensor faults from component failures.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Benchmark the model against a current threshold and test at multiple speeds, directions or loads.
The handbook intentionally uses time-domain summary features; FFT/spectral analysis is not compulsory.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationUse a guarded repeatable start/load jig and cap start duration/current; give each team temperature-conditioned seed starts.
Variant 02.10
Post-Maintenance Startup Verifier
Engineering purpose: Produces a maintenance-evidence portfolio use case.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensemotor quadrature encoder/tachometer; 0–3.3 V conditioned current-sense channe…
Actuate6–12 V geared DC motor with encoder and documented no-load/stall current; 3.3…
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser seed set containing cold, warm and safely aborted starts
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Every start must be bounded by firmware current, time, retry and cool-down limits. Verify the complete EQ-02-10 manifest before data collection.
1 · Scenario and student challenge
Compare signatures before and after an approved adjustment or lubrication simulation. In plain language, adapt StartSense — Startup Signature Intelligence for Electric Drives so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Produces a maintenance-evidence portfolio use case.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M + the named safe mechanical/condition fixture. Begin with the H753-M rig with a faculty-approved repeatable start/load fixture and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record start command, direction, PWM, current, encoder pulse timing, speed, temperature and supply/load proxy. Treat one complete start episode from rest to the success, timeout or trip condition as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Anomaly score and improvement classification. First implement the parent baseline—peak-current and time-to-speed limits—and then compare two algorithms from the faculty-issued ML whitelist. Train or set the threshold using healthy/training data only. Report event recall, false alarms per normal run and detection delay; show where the method treats a new but valid regime as abnormal. Produce a event timeline with anomaly score, threshold and false-alarm examples.
5 · Embedded integration and safe response
The host may return only ACCEPT_START, RETRY_SAFE_PROFILE, DERATE or STOP, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a valid cold, warm or high-inertia start that is slower than the nominal trace. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 02.10 — Post-Maintenance Startup Verifier”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M + the named safe mechanical/condition fixtureanomaly/noveltyrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P02 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Post-Maintenance Startup Verifier is a syllabus-scaled physical analogue of the need evidenced by BM03 · Diagnostic Approach for Electro-Mechanical Actuators in Aerospace Systems: Compare signatures before and after an approved adjustment or lubrication simulation. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needUse condition indicators to detect, identify and isolate actuator fault modes while distinguishing sensor faults from component failures.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Benchmark the model against a current threshold and test at multiple speeds, directions or loads.
The handbook intentionally uses time-domain summary features; FFT/spectral analysis is not compulsory.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationUse a guarded repeatable start/load jig and cap start duration/current; give each team temperature-conditioned seed starts.
Problem 03 · 10 variants · Motion, drive and actuator intelligence
LoadLens — Embedded Load Estimator and Safe Operating-Profile Selector
Team size: 4; approved 3-member exception1 × NUCLEO-H753ZIH753-MRegression / classificationIntermediate
Assigned Faculty Master pair for P03: one nominated ESD Faculty Master and one nominated ML Faculty Master shall jointly master this parent problem and variants V1-V10. The ESD Master owns hardware, firmware, control, communication and safety verification; the ML Master owns data, baselines, models, validation and bounded decision-policy verification. Together they teach and guide ten teams (one for each variant and up to 40 students), supervise five teams in Wave A and five in Wave B, witness integration and sign every final evaluation.
The problem
A controller frequently needs to know the mechanical load, yet adding a dedicated load cell may be expensive or absent from the prescribed kit. The available motor current, PWM command, speed, position and transient response contain enough information to estimate a load class or approximate load value. The product challenge is to create a defensible ‘virtual load sensor’ and use it only for bounded supervisory decisions.
Smart embedded product to build
Build a NUCLEO-H753ZI virtual-load sensor and safe profile selector. The board executes standardised test moves/speed plateaus, logs current, encoder, duty and temperature evidence, and keeps the control loop deterministic. The host estimates a calibrated load class/value and recommends one of the firmware-resident profiles. The product must expose measured state, prediction interval/confidence, recommendation, applied profile and explicit refusal when evidence is insufficient.
NUCLEO-H753ZI realization and issued pack
NUCLEO-H753ZI / MB1364E with H753-M pack and calibrated removable loads
timer PWM/H-bridge or servo output; timer encoder/position feedback
conditioned current and temperature ADC inputs
three to five firmware-resident profile IDs with immutable limits
USART3 VCP trial export and recommendation/acknowledgement protocol
LED/display shows measured state, estimate band, confidence and accepted profile
organiser-provided load fixture; no free-hand obstruction during operation
Intelligence to incorporate
Use regression (linear, regularised or tree-based) for continuous load estimate or classification for discrete classes. Candidate features are steady-state current, current during acceleration, speed deficit, duty cycle, settling time, direction, position and temperature. Evaluate MAE/RMSE or class-balanced F1, prediction intervals/uncertainty proxy, and generalisation to an unseen physical load.
Canonical family command contract: every parent brief, variant, host message and MCU acknowledgement for P03 shall use these exact identifiers. A variant may use only the applicable subset; it shall not introduce a synonym.
Core problem equipment · EQ-03-CORE
Complete equipment required for one core-problem team
Standalone family BOM. This list supports the parent problem itself. An allocated variant uses its own complete table later in this card. A component mentioned again in the fixture description is the same mounted unit, not another copy.
4 students; 3 by approved exception1 H753 board1 team laptopquantities per team
Controller1 H753 board + 1 laptop
Sensequadrature encoder or external position potentiometer compatible with 0–3.3 V…
Actuate6–12 V geared DC motor with encoder; matching 3.3-V-logic H-bridge rated abov…
Fixtureguarded carriage/arm/spool fixture with repeatable load attachment points; ca…
Protectcurrent-limited 6–12 V actuator supply sized to the issued motor; inline fuse…
System block
Complete quantity and equipment per team
Purpose / acceptance condition
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser calibration sheet recording the true load/fixture state for each trial
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Release-to-team condition: Load changes must be attached only while power is disabled and must remain inside the fixture rating. The organiser signs the electrical, mechanical and communication acceptance checklist before H0:00.
Not duplicated inside the kit: supervised rework tools and the oscilloscope/logic-analyser station are shared at the ratio stated above. Everything else in this table is issued to, reserved for, or digitally assigned to this team.
Controlled self-learning extension
Recommended Validate calibration transfer on a second motor/board specimen or a deliberately held-out load. Add a domain-shift report and abstain when the input is outside the trained operating envelope.
System safety and non-negotiable boundary
The selected profile is always from a hard-coded whitelist with MCU-side current, speed and temperature limits. An out-of-range estimate or low confidence cannot increase torque; it must choose a conservative profile or refuse motion.
Student interpretation — what this challenge really asks
The system has no direct load cell, so it must infer load from the way the actuator responds. The estimate becomes a virtual sensor, but only bounded firmware profiles may be selected from it.
Independent data unitone standard diagnostic move or speed plateau with a known training load.
Closest misleading caseincreased friction or direction-dependent mechanics that imitate a heavier load.
Definition of successStudents must generalise to an unseen approved load or context and abstain when the estimate is unreliable.
Visual system blueprint
Physical processActuator under unknown loadGenerate labelled, safe and repeatable conditions.
Observecurrent during acceleration and steady state, PWM, speed/position responsePreserve units, timestamps, run identity and signal quality.
H753 responsibilityControl and protectexecute repeatable diagnostic moves, enforce motion limits and expose measured rather than assumed response.
Host intelligenceLearn the distinctionestimate load class/value or directly select a safe approved operating profile.
Bounded outcomePROFILE_ID · LOAD_BAND · CONSERVATIVE_DEFAULT · REQUEST_RECHECKMCU validates, acknowledges and may refuse the request.
Recommended build journey
Make the process repeatableAssemble the H753-M motion rig with safe known load classes or resistance settings; define reference and target conditions before collecting data.
Prove deterministic firmwareExecute repeatable diagnostic moves, enforce motion limits and expose measured rather than assumed response. Demonstrate every hard limit before connecting ML.
Build trustworthy trialsTreat one standard diagnostic move or speed plateau with a known training load as independent; calibrate, label and split by run/session.
Beat a real baselineCompare steady-state current-to-load lookup or nearest calibrated load class with two syllabus-approved classical models.
Close and challenge the loopReturn only the applicable subset of PROFILE_ID · LOAD_BAND · CONSERVATIVE_DEFAULT · REQUEST_RECHECK; test the target, nearest confuser, stale command and host loss.
Definition of done
Firmware controls safely before, during and after host connection.
Held-out results report MAE/RMSE or macro-F1, unseen-load error and unsafe-profile rejection.
Portfolio shows predicted-versus-measured load and error sliced by direction or operating point and one honest failure case.
Problem-specific evidence at the common reviews
R1 · Design
Define load range/classes, physical fixture, test motion, candidate profiles, uncertainty rule and acceptance metrics.
R2 · Embedded
Demonstrate repeatable test motion, stable capture of current/speed/temperature and MCU-side profile whitelist.
R3 · Data
Submit trial-level dataset across loads, baseline current-to-load curve and group-wise split.
R4 · ML
Show regression/classification comparison, unseen-load performance and refusal logic.
R5 · Integration
Integrate profile recommendation, verify MCU rejection of illegal profiles and show safe behaviour under a misleading estimate.
Final
Estimate a hidden load and execute the accepted profile while explaining the telemetry evidence and uncertainty.
Portfolio/Kaggle outcome
Kaggle output: trial-level ‘Virtual Load Sensing from STM32 Motor Telemetry’ dataset, notebook comparing current-only versus multisignal models, generalisation test on unseen load, feature importance and a model card describing limits.
Industry alignment and validation basis
LoadLens: external references and required evidence
The listed sources establish relevance, test discipline and implementation precedent. They do not modify the common syllabus boundary, safety rules or 100-mark assessment rubric.
Family implementation profile
Variant availability: 10 standard assignment(s); 0 organiser-supported assignment(s).
Public evidence: reproducible firmware, protocol, dataset, notebook/model, test report and demonstration video.
What the external benchmark confirms
The problem has a recognisable industrial or challenge analogue, a measurable data task, a defensible embedded implementation and a safe operational decision. Every one of its ten variants is mapped separately below.
Condition before team allocation
Issue traceable reference loads/resistance settings and hold out at least one approved load/context for blind validation.
Combine sensor measurements and system knowledge to build condition indicators, detect faults and support predictive-maintenance decisions.
Start with an engineering baseline, justify features physically, validate on held-out operating conditions and connect inference to a maintenance action.
Identify model portability, sensor calibration drift, context change and maintenance events as central challenges for data-derived virtual measurements.
Test on unseen context/device conditions, track calibration state and abstain or degrade when the virtual sensor leaves its validated domain.
Open the 10 fully elaborated student variant briefs
Choose only the variant allocated to your team. Read it together with the parent problem above: the card expands the experimental delta, while every hardware, safety, integration and review requirement of the family remains active.
Variant 03.01
Payload-Class Estimator
Engineering purpose: Directly supports robotic or logistics portfolio narratives.
ChangeEstimate empty/light/medium/heavy payload on a safe arm or carriage.
Observecurrent during acceleration and steady state, PWM, speed/position…
LearnMulticlass load classification.
DecideLOAD_BAND or approved PROFILE_ID, REQUEST_RECHECK,…
ProveMAE/RMSE or macro-F1, unseen-load error and unsafe-profile…
Variant equipment · EQ-03-01
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensequadrature encoder or external position potentiometer compatible with 0–3.3 V…
Actuate6–12 V geared DC motor with encoder; matching 3.3-V-logic H-bridge rated abov…
Fixturelow-force rotary arm or carriage with five marked mass attachment points; ver…
Protectcurrent-limited 6–12 V actuator supply sized to the issued motor; inline fuse…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser calibration sheet recording the true load/fixture state for each trial
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Load changes must be attached only while power is disabled and must remain inside the fixture rating. Verify the complete EQ-03-01 manifest before data collection.
1 · Scenario and student challenge
Estimate empty/light/medium/heavy payload on a safe arm or carriage. In plain language, adapt LoadLens — Embedded Load Estimator and Safe Operating-Profile Selector so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Directly supports robotic or logistics portfolio narratives.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M + the named safe mechanical/condition fixture. Begin with the H753-M motion rig with safe known load classes or resistance settings and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record current during acceleration and steady state, PWM, speed/position response, direction, temperature and test-profile ID. Treat one standard diagnostic move or speed plateau with a known training load as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Multiclass load classification. First implement the parent baseline—steady-state current-to-load lookup or nearest calibrated load class—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only LOAD_BAND or approved PROFILE_ID, REQUEST_RECHECK, CONSERVATIVE_DEFAULT, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with increased friction or direction-dependent mechanics that imitate a heavier load. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 03.01 — Payload-Class Estimator”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M + the named safe mechanical/condition fixtureclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P03 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Payload-Class Estimator is a syllabus-scaled physical analogue of the need evidenced by BM03 · Diagnostic Approach for Electro-Mechanical Actuators in Aerospace Systems: Estimate empty/light/medium/heavy payload on a safe arm or carriage. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needUse condition indicators to detect, identify and isolate actuator fault modes while distinguishing sensor faults from component failures.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Separate sensor, actuator and process faults; publish injection conditions; compare methods on identical episodes and explicit performance indices.
The handbook uses a low-force servo or DC mechanism and classical features rather than a full industrial valve process.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationIssue traceable reference loads/resistance settings and hold out at least one approved load/context for blind validation.
Variant 03.02
Continuous Mass Proxy
Engineering purpose: Creates a clear virtual-sensing benchmark.
ChangePredict an approximate approved mass from controlled trials.
Observecurrent during acceleration and steady state, PWM, speed/position…
LearnRegression with MAE and unseen-mass test.
DecideLOAD_BAND or approved PROFILE_ID, REQUEST_RECHECK,…
ProveMAE/RMSE or macro-F1, unseen-load error and unsafe-profile…
Variant equipment · EQ-03-02
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensequadrature encoder or external position potentiometer compatible with 0–3.3 V…
Actuate6–12 V geared DC motor with encoder; matching 3.3-V-logic H-bridge rated abov…
Fixtureguarded arm/carriage and continuous approved mass set; digital scale with 1 g…
Protectcurrent-limited 6–12 V actuator supply sized to the issued motor; inline fuse…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser calibration sheet recording the true load/fixture state for each trial
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Load changes must be attached only while power is disabled and must remain inside the fixture rating. Verify the complete EQ-03-02 manifest before data collection.
1 · Scenario and student challenge
Predict an approximate approved mass from controlled trials. In plain language, adapt LoadLens — Embedded Load Estimator and Safe Operating-Profile Selector so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Creates a clear virtual-sensing benchmark.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M + the named safe mechanical/condition fixture. Begin with the H753-M motion rig with safe known load classes or resistance settings and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record current during acceleration and steady state, PWM, speed/position response, direction, temperature and test-profile ID. Treat one standard diagnostic move or speed plateau with a known training load as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Regression with MAE and unseen-mass test. First implement the parent baseline—steady-state current-to-load lookup or nearest calibrated load class—and then compare two algorithms from the faculty-issued ML whitelist. Report MAE and RMSE on whole held-out runs, show predicted-versus-measured values, and inspect error by operating condition. If the target is converted to a safe/unsafe decision, also report missed-unsafe and unnecessary-conservative actions. Produce a predicted-versus-measured plot with residuals by operating condition.
5 · Embedded integration and safe response
The host may return only LOAD_BAND or approved PROFILE_ID, REQUEST_RECHECK, CONSERVATIVE_DEFAULT, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with increased friction or direction-dependent mechanics that imitate a heavier load. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 03.02 — Continuous Mass Proxy”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M + the named safe mechanical/condition fixtureregression/outcomerun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P03 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Continuous Mass Proxy is a syllabus-scaled physical analogue of the need evidenced by BM03 · Diagnostic Approach for Electro-Mechanical Actuators in Aerospace Systems: Predict an approximate approved mass from controlled trials. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needUse condition indicators to detect, identify and isolate actuator fault modes while distinguishing sensor faults from component failures.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Separate sensor, actuator and process faults; publish injection conditions; compare methods on identical episodes and explicit performance indices.
The handbook uses a low-force servo or DC mechanism and classical features rather than a full industrial valve process.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationIssue traceable reference loads/resistance settings and hold out at least one approved load/context for blind validation.
Variant 03.03
Friction-Level Estimator
Engineering purpose: Distinguishes load from degradation.
ChangeKeep payload constant while changing controlled mechanical drag.
Observecurrent during acceleration and steady state, PWM, speed/position…
LearnOrdinal regression/classification.
DecideLOAD_BAND or approved PROFILE_ID, REQUEST_RECHECK,…
ProveMAE/RMSE or macro-F1, unseen-load error and unsafe-profile…
Variant equipment · EQ-03-03
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensequadrature encoder or external position potentiometer compatible with 0–3.3 V…
Actuate6–12 V geared DC motor with encoder; matching 3.3-V-logic H-bridge rated abov…
Fixtureconstant-load drive fixture with adjustable felt brake; calibrated drag setti…
Protectcurrent-limited 6–12 V actuator supply sized to the issued motor; inline fuse…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser calibration sheet recording the true load/fixture state for each trial
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Load changes must be attached only while power is disabled and must remain inside the fixture rating. Verify the complete EQ-03-03 manifest before data collection.
1 · Scenario and student challenge
Keep payload constant while changing controlled mechanical drag. In plain language, adapt LoadLens — Embedded Load Estimator and Safe Operating-Profile Selector so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Distinguishes load from degradation.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M + the named safe mechanical/condition fixture. Begin with the H753-M motion rig with safe known load classes or resistance settings and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record current during acceleration and steady state, PWM, speed/position response, direction, temperature and test-profile ID. Treat one standard diagnostic move or speed plateau with a known training load as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Ordinal regression/classification. First implement the parent baseline—steady-state current-to-load lookup or nearest calibrated load class—and then compare two algorithms from the faculty-issued ML whitelist. Report MAE and RMSE on whole held-out runs, show predicted-versus-measured values, and inspect error by operating condition. If the target is converted to a safe/unsafe decision, also report missed-unsafe and unnecessary-conservative actions. Produce a predicted-versus-measured plot with residuals by operating condition.
5 · Embedded integration and safe response
The host may return only LOAD_BAND or approved PROFILE_ID, REQUEST_RECHECK, CONSERVATIVE_DEFAULT, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with increased friction or direction-dependent mechanics that imitate a heavier load. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 03.03 — Friction-Level Estimator”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M + the named safe mechanical/condition fixtureregression/outcomerun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P03 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Friction-Level Estimator is a syllabus-scaled physical analogue of the need evidenced by BM03 · Diagnostic Approach for Electro-Mechanical Actuators in Aerospace Systems: Keep payload constant while changing controlled mechanical drag. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needUse condition indicators to detect, identify and isolate actuator fault modes while distinguishing sensor faults from component failures.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Separate sensor, actuator and process faults; publish injection conditions; compare methods on identical episodes and explicit performance indices.
The handbook uses a low-force servo or DC mechanism and classical features rather than a full industrial valve process.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationIssue traceable reference loads/resistance settings and hold out at least one approved load/context for blind validation.
ChangeUse a safe adjustable ramp or gravity angle for a wheeled fixture.
Observecurrent during acceleration and steady state, PWM, speed/position…
LearnClassification conditioned on direction.
DecideLOAD_BAND or approved PROFILE_ID, REQUEST_RECHECK,…
ProveMAE/RMSE or macro-F1, unseen-load error and unsafe-profile…
Variant equipment · EQ-03-04
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensequadrature encoder or external position potentiometer compatible with 0–3.3 V…
Actuate6–12 V geared DC motor with encoder; matching 3.3-V-logic H-bridge rated abov…
Fixtureguarded wheeled carriage and adjustable ramp; locking protractor/angle gauge…
Protectcurrent-limited 6–12 V actuator supply sized to the issued motor; inline fuse…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser calibration sheet recording the true load/fixture state for each trial
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Load changes must be attached only while power is disabled and must remain inside the fixture rating. Verify the complete EQ-03-04 manifest before data collection.
1 · Scenario and student challenge
Use a safe adjustable ramp or gravity angle for a wheeled fixture. In plain language, adapt LoadLens — Embedded Load Estimator and Safe Operating-Profile Selector so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Introduces direction-dependent plant behaviour.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M + the named safe mechanical/condition fixture. Begin with the H753-M motion rig with safe known load classes or resistance settings and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record current during acceleration and steady state, PWM, speed/position response, direction, temperature and test-profile ID. Treat one standard diagnostic move or speed plateau with a known training load as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Classification conditioned on direction. First implement the parent baseline—steady-state current-to-load lookup or nearest calibrated load class—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only LOAD_BAND or approved PROFILE_ID, REQUEST_RECHECK, CONSERVATIVE_DEFAULT, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with increased friction or direction-dependent mechanics that imitate a heavier load. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 03.04 — Incline-Class Estimator”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M + the named safe mechanical/condition fixtureclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P03 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Incline-Class Estimator is a syllabus-scaled physical analogue of the need evidenced by BM03 · Diagnostic Approach for Electro-Mechanical Actuators in Aerospace Systems: Use a safe adjustable ramp or gravity angle for a wheeled fixture. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needUse condition indicators to detect, identify and isolate actuator fault modes while distinguishing sensor faults from component failures.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Separate sensor, actuator and process faults; publish injection conditions; compare methods on identical episodes and explicit performance indices.
The handbook uses a low-force servo or DC mechanism and classical features rather than a full industrial valve process.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationIssue traceable reference loads/resistance settings and hold out at least one approved load/context for blind validation.
Variant 03.05
Door-Stiffness Estimator
Engineering purpose: Supports preventive maintenance and anti-pinch systems.
ChangeMeasure resistance across opening positions of a low-force gate arm.
Observecurrent during acceleration and steady state, PWM, speed/position…
LearnRegression/classification using angle and current.
DecideLOAD_BAND or approved PROFILE_ID, REQUEST_RECHECK,…
ProveMAE/RMSE or macro-F1, unseen-load error and unsafe-profile…
Variant equipment · EQ-03-05
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensequadrature encoder or external position potentiometer compatible with 0–3.3 V…
Actuate6–12 V geared DC motor with encoder; matching 3.3-V-logic H-bridge rated abov…
Fixturelow-force door/gate arm with position markings; interchangeable hinge/frictio…
Protectcurrent-limited 6–12 V actuator supply sized to the issued motor; inline fuse…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser calibration sheet recording the true load/fixture state for each trial
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Load changes must be attached only while power is disabled and must remain inside the fixture rating. Verify the complete EQ-03-05 manifest before data collection.
1 · Scenario and student challenge
Measure resistance across opening positions of a low-force gate arm. In plain language, adapt LoadLens — Embedded Load Estimator and Safe Operating-Profile Selector so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Supports preventive maintenance and anti-pinch systems.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M + the named safe mechanical/condition fixture. Begin with the H753-M motion rig with safe known load classes or resistance settings and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record current during acceleration and steady state, PWM, speed/position response, direction, temperature and test-profile ID. Treat one standard diagnostic move or speed plateau with a known training load as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Regression/classification using angle and current. First implement the parent baseline—steady-state current-to-load lookup or nearest calibrated load class—and then compare two algorithms from the faculty-issued ML whitelist. Report MAE and RMSE on whole held-out runs, show predicted-versus-measured values, and inspect error by operating condition. If the target is converted to a safe/unsafe decision, also report missed-unsafe and unnecessary-conservative actions. Produce a predicted-versus-measured plot with residuals by operating condition.
5 · Embedded integration and safe response
The host may return only LOAD_BAND or approved PROFILE_ID, REQUEST_RECHECK, CONSERVATIVE_DEFAULT, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with increased friction or direction-dependent mechanics that imitate a heavier load. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 03.05 — Door-Stiffness Estimator”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M + the named safe mechanical/condition fixtureregression/outcomerun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P03 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Door-Stiffness Estimator is a syllabus-scaled physical analogue of the need evidenced by BM03 · Diagnostic Approach for Electro-Mechanical Actuators in Aerospace Systems: Measure resistance across opening positions of a low-force gate arm. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needUse condition indicators to detect, identify and isolate actuator fault modes while distinguishing sensor faults from component failures.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Separate sensor, actuator and process faults; publish injection conditions; compare methods on identical episodes and explicit performance indices.
The handbook uses a low-force servo or DC mechanism and classical features rather than a full industrial valve process.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationIssue traceable reference loads/resistance settings and hold out at least one approved load/context for blind validation.
Variant 03.06
Conveyor Occupancy Estimator
Engineering purpose: Avoids extra occupancy sensors while exposing limitations.
ChangeEstimate no/light/heavy material presence from motor telemetry.
Observecurrent during acceleration and steady state, PWM, speed/position…
LearnClassification across speed setpoints.
DecideLOAD_BAND or approved PROFILE_ID, REQUEST_RECHECK,…
ProveMAE/RMSE or macro-F1, unseen-load error and unsafe-profile…
Variant equipment · EQ-03-06
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensequadrature encoder or external position potentiometer compatible with 0–3.3 V…
Actuate6–12 V geared DC motor with encoder; matching 3.3-V-logic H-bridge rated abov…
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser calibration sheet recording the true load/fixture state for each trial
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Load changes must be attached only while power is disabled and must remain inside the fixture rating. Verify the complete EQ-03-06 manifest before data collection.
1 · Scenario and student challenge
Estimate no/light/heavy material presence from motor telemetry. In plain language, adapt LoadLens — Embedded Load Estimator and Safe Operating-Profile Selector so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Avoids extra occupancy sensors while exposing limitations.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M + the named safe mechanical/condition fixture. Begin with the H753-M motion rig with safe known load classes or resistance settings and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record current during acceleration and steady state, PWM, speed/position response, direction, temperature and test-profile ID. Treat one standard diagnostic move or speed plateau with a known training load as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Classification across speed setpoints. First implement the parent baseline—steady-state current-to-load lookup or nearest calibrated load class—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only LOAD_BAND or approved PROFILE_ID, REQUEST_RECHECK, CONSERVATIVE_DEFAULT, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with increased friction or direction-dependent mechanics that imitate a heavier load. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 03.06 — Conveyor Occupancy Estimator”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M + the named safe mechanical/condition fixtureclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P03 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Conveyor Occupancy Estimator is a syllabus-scaled physical analogue of the need evidenced by BM03 · Diagnostic Approach for Electro-Mechanical Actuators in Aerospace Systems: Estimate no/light/heavy material presence from motor telemetry. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needUse condition indicators to detect, identify and isolate actuator fault modes while distinguishing sensor faults from component failures.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Separate sensor, actuator and process faults; publish injection conditions; compare methods on identical episodes and explicit performance indices.
The handbook uses a low-force servo or DC mechanism and classical features rather than a full industrial valve process.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationIssue traceable reference loads/resistance settings and hold out at least one approved load/context for blind validation.
Variant 03.07
Fan-Restriction Estimator
Engineering purpose: Represents ventilation maintenance without new sensors.
ChangeEstimate free, partly restricted and heavily restricted airflow using…
Observecurrent during acceleration and steady state, PWM, speed/position…
LearnOrdinal classification.
DecideLOAD_BAND or approved PROFILE_ID, REQUEST_RECHECK,…
ProveMAE/RMSE or macro-F1, unseen-load error and unsafe-profile…
Variant equipment · EQ-03-07
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensequadrature encoder or external position potentiometer compatible with 0–3.3 V…
Actuate6–12 V geared DC motor with encoder; matching 3.3-V-logic H-bridge rated abov…
Fixtureshrouded fan/impeller stand; airflow restriction screens; fan tachometer chan…
Protectcurrent-limited 6–12 V actuator supply sized to the issued motor; inline fuse…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser calibration sheet recording the true load/fixture state for each trial
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Load changes must be attached only while power is disabled and must remain inside the fixture rating. Verify the complete EQ-03-07 manifest before data collection.
1 · Scenario and student challenge
Estimate free, partly restricted and heavily restricted airflow using drive signals. In plain language, adapt LoadLens — Embedded Load Estimator and Safe Operating-Profile Selector so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Represents ventilation maintenance without new sensors.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M + the named safe mechanical/condition fixture. Begin with the H753-M motion rig with safe known load classes or resistance settings and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record current during acceleration and steady state, PWM, speed/position response, direction, temperature and test-profile ID. Treat one standard diagnostic move or speed plateau with a known training load as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Ordinal classification. First implement the parent baseline—steady-state current-to-load lookup or nearest calibrated load class—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only LOAD_BAND or approved PROFILE_ID, REQUEST_RECHECK, CONSERVATIVE_DEFAULT, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with increased friction or direction-dependent mechanics that imitate a heavier load. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 03.07 — Fan-Restriction Estimator”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M + the named safe mechanical/condition fixtureclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P03 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Fan-Restriction Estimator is a syllabus-scaled physical analogue of the need evidenced by BM03 · Diagnostic Approach for Electro-Mechanical Actuators in Aerospace Systems: Estimate free, partly restricted and heavily restricted airflow using drive signals. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needUse condition indicators to detect, identify and isolate actuator fault modes while distinguishing sensor faults from component failures.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Separate sensor, actuator and process faults; publish injection conditions; compare methods on identical episodes and explicit performance indices.
The handbook uses a low-force servo or DC mechanism and classical features rather than a full industrial valve process.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationIssue traceable reference loads/resistance settings and hold out at least one approved load/context for blind validation.
Variant 03.08
Spool-Tension Classifier
Engineering purpose: Maps to textile, packaging and winding equipment.
ChangeUse a safe string/spool fixture and classify low/normal/high tension.
Observecurrent during acceleration and steady state, PWM, speed/position…
LearnClassification from current, speed and position.
DecideLOAD_BAND or approved PROFILE_ID, REQUEST_RECHECK,…
ProveMAE/RMSE or macro-F1, unseen-load error and unsafe-profile…
Variant equipment · EQ-03-08
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensequadrature encoder or external position potentiometer compatible with 0–3.3 V…
Actuate6–12 V geared DC motor with encoder; matching 3.3-V-logic H-bridge rated abov…
Fixtureguarded spool-and-string stand; approved tension weights or low-force spring…
Protectcurrent-limited 6–12 V actuator supply sized to the issued motor; inline fuse…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser calibration sheet recording the true load/fixture state for each trial
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Load changes must be attached only while power is disabled and must remain inside the fixture rating. Verify the complete EQ-03-08 manifest before data collection.
1 · Scenario and student challenge
Use a safe string/spool fixture and classify low/normal/high tension. In plain language, adapt LoadLens — Embedded Load Estimator and Safe Operating-Profile Selector so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Maps to textile, packaging and winding equipment.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M + the named safe mechanical/condition fixture. Begin with the H753-M motion rig with safe known load classes or resistance settings and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record current during acceleration and steady state, PWM, speed/position response, direction, temperature and test-profile ID. Treat one standard diagnostic move or speed plateau with a known training load as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Classification from current, speed and position. First implement the parent baseline—steady-state current-to-load lookup or nearest calibrated load class—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only LOAD_BAND or approved PROFILE_ID, REQUEST_RECHECK, CONSERVATIVE_DEFAULT, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with increased friction or direction-dependent mechanics that imitate a heavier load. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 03.08 — Spool-Tension Classifier”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M + the named safe mechanical/condition fixtureclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P03 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Spool-Tension Classifier is a syllabus-scaled physical analogue of the need evidenced by BM03 · Diagnostic Approach for Electro-Mechanical Actuators in Aerospace Systems: Use a safe string/spool fixture and classify low/normal/high tension. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needUse condition indicators to detect, identify and isolate actuator fault modes while distinguishing sensor faults from component failures.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Separate sensor, actuator and process faults; publish injection conditions; compare methods on identical episodes and explicit performance indices.
The handbook uses a low-force servo or DC mechanism and classical features rather than a full industrial valve process.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationIssue traceable reference loads/resistance settings and hold out at least one approved load/context for blind validation.
Variant 03.09
Actuator Balance Estimator
Engineering purpose: Finds asymmetric mechanics and improves model design.
ChangeEstimate external load separately in forward and reverse motion.
Observecurrent during acceleration and steady state, PWM, speed/position…
LearnRegression with direction interactions.
DecideLOAD_BAND or approved PROFILE_ID, REQUEST_RECHECK,…
ProveMAE/RMSE or macro-F1, unseen-load error and unsafe-profile…
Variant equipment · EQ-03-09
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensequadrature encoder or external position potentiometer compatible with 0–3.3 V…
Actuate6–12 V geared DC motor with encoder; matching 3.3-V-logic H-bridge rated abov…
Fixturesymmetric bidirectional arm/carriage; calibrated load set and reversible fric…
Protectcurrent-limited 6–12 V actuator supply sized to the issued motor; inline fuse…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser calibration sheet recording the true load/fixture state for each trial
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Load changes must be attached only while power is disabled and must remain inside the fixture rating. Verify the complete EQ-03-09 manifest before data collection.
1 · Scenario and student challenge
Estimate external load separately in forward and reverse motion. In plain language, adapt LoadLens — Embedded Load Estimator and Safe Operating-Profile Selector so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Finds asymmetric mechanics and improves model design.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M + the named safe mechanical/condition fixture. Begin with the H753-M motion rig with safe known load classes or resistance settings and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record current during acceleration and steady state, PWM, speed/position response, direction, temperature and test-profile ID. Treat one standard diagnostic move or speed plateau with a known training load as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Regression with direction interactions. First implement the parent baseline—steady-state current-to-load lookup or nearest calibrated load class—and then compare two algorithms from the faculty-issued ML whitelist. Report MAE and RMSE on whole held-out runs, show predicted-versus-measured values, and inspect error by operating condition. If the target is converted to a safe/unsafe decision, also report missed-unsafe and unnecessary-conservative actions. Produce a predicted-versus-measured plot with residuals by operating condition.
5 · Embedded integration and safe response
The host may return only LOAD_BAND or approved PROFILE_ID, REQUEST_RECHECK, CONSERVATIVE_DEFAULT, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with increased friction or direction-dependent mechanics that imitate a heavier load. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 03.09 — Actuator Balance Estimator”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M + the named safe mechanical/condition fixtureregression/outcomerun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P03 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Actuator Balance Estimator is a syllabus-scaled physical analogue of the need evidenced by BM03 · Diagnostic Approach for Electro-Mechanical Actuators in Aerospace Systems: Estimate external load separately in forward and reverse motion. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needUse condition indicators to detect, identify and isolate actuator fault modes while distinguishing sensor faults from component failures.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Separate sensor, actuator and process faults; publish injection conditions; compare methods on identical episodes and explicit performance indices.
The handbook uses a low-force servo or DC mechanism and classical features rather than a full industrial valve process.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationIssue traceable reference loads/resistance settings and hold out at least one approved load/context for blind validation.
Variant 03.10
Load-Aware Profile Selector
Engineering purpose: Creates a meaningful modelling-design comparison.
ChangeSkip explicit load display and predict the best safe profile directly…
Observecurrent during acceleration and steady state, PWM, speed/position…
LearnMulticlass decision model benchmarked against two-stage estimation.
DecideLOAD_BAND or approved PROFILE_ID, REQUEST_RECHECK,…
ProveMAE/RMSE or macro-F1, unseen-load error and unsafe-profile…
Variant equipment · EQ-03-10
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensequadrature encoder or external position potentiometer compatible with 0–3.3 V…
Actuate6–12 V geared DC motor with encoder; matching 3.3-V-logic H-bridge rated abov…
Fixturestandard guarded load fixture; card of 3–5 pre-approved motion profiles and k…
Protectcurrent-limited 6–12 V actuator supply sized to the issued motor; inline fuse…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser calibration sheet recording the true load/fixture state for each trial
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Load changes must be attached only while power is disabled and must remain inside the fixture rating. Verify the complete EQ-03-10 manifest before data collection.
1 · Scenario and student challenge
Skip explicit load display and predict the best safe profile directly from test telemetry. In plain language, adapt LoadLens — Embedded Load Estimator and Safe Operating-Profile Selector so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Creates a meaningful modelling-design comparison.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M + the named safe mechanical/condition fixture. Begin with the H753-M motion rig with safe known load classes or resistance settings and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record current during acceleration and steady state, PWM, speed/position response, direction, temperature and test-profile ID. Treat one standard diagnostic move or speed plateau with a known training load as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Multiclass decision model benchmarked against two-stage estimation. First implement the parent baseline—steady-state current-to-load lookup or nearest calibrated load class—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only LOAD_BAND or approved PROFILE_ID, REQUEST_RECHECK, CONSERVATIVE_DEFAULT, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with increased friction or direction-dependent mechanics that imitate a heavier load. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 03.10 — Load-Aware Profile Selector”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M + the named safe mechanical/condition fixtureclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P03 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Load-Aware Profile Selector is a syllabus-scaled physical analogue of the need evidenced by BM03 · Diagnostic Approach for Electro-Mechanical Actuators in Aerospace Systems: Skip explicit load display and predict the best safe profile directly from test telemetry. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needUse condition indicators to detect, identify and isolate actuator fault modes while distinguishing sensor faults from component failures.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Separate sensor, actuator and process faults; publish injection conditions; compare methods on identical episodes and explicit performance indices.
The handbook uses a low-force servo or DC mechanism and classical features rather than a full industrial valve process.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationIssue traceable reference loads/resistance settings and hold out at least one approved load/context for blind validation.
Problem 04 · 10 variants · Motion, drive and actuator intelligence
Assigned Faculty Master pair for P04: one nominated ESD Faculty Master and one nominated ML Faculty Master shall jointly master this parent problem and variants V1-V10. The ESD Master owns hardware, firmware, control, communication and safety verification; the ML Master owns data, baselines, models, validation and bounded decision-policy verification. Together they teach and guide ten teams (one for each variant and up to 40 students), supervise five teams in Wave A and five in Wave B, witness integration and sign every final evaluation.
The problem
Industrial motion is not judged only by whether the final position was reached. Overshoot, settling time, steady-state error, oscillation, saturation and recovery from disturbance determine whether a motion profile is usable. Manually calculating these values for every trial is slow and does not provide early prediction. The challenge is to turn each STM32 step response into a quality score and forecast whether a move will meet a declared specification.
Smart embedded product to build
Build a NUCLEO-H753ZI motion-quality test station. The board applies whitelisted step commands, executes the fixed-rate PID loop, logs setpoint, position/speed, controller output, saturation, current and faults, and exports one response per run. The host derives final overshoot/settling/error labels and predicts PASS/FAIL or the final metric from only the declared early window, enabling a bounded PROFILE_ID, CONTINUE_TEST, RETEST or CONSERVATIVE_PROFILE decision before motion finishes.
NUCLEO-H753ZI realization and issued pack
NUCLEO-H753ZI / MB1364E with H753-M response-test fixture
ADC current/temperature context and saturation/anti-windup flags
microsecond timestamping and one run ID per commanded response
USART3 VCP carries raw response, computed final metrics and bounded profile command
three to six faculty-approved profiles; LED/display gives RUN, PASS, FAIL or SAFE_ABORT
travel/current/time bounds remain firmware-only
Intelligence to incorporate
Targets may be settling time, overshoot, steady-state error, energy proxy or a composite quality class. Use early-window features and compare with full-response features. Suitable models are linear/regularised regression, logistic regression and course-approved trees/ensembles. Evaluate MAE/RMSE, balanced F1, early-decision time and calibration of PASS probability.
Canonical family command contract: every parent brief, variant, host message and MCU acknowledgement for P04 shall use these exact identifiers. A variant may use only the applicable subset; it shall not introduce a synonym.
Core problem equipment · EQ-04-CORE
Complete equipment required for one core-problem team
Standalone family BOM. This list supports the parent problem itself. An allocated variant uses its own complete table later in this card. A component mentioned again in the fixture description is the same mounted unit, not another copy.
4 students; 3 by approved exception1 H753 board1 team laptopquantities per team
Controller1 H753 board + 1 laptop
Sensequadrature encoder/position feedback device; 0–3.3 V conditioned current-sens…
Actuatelow-torque 6–12 V geared DC motor with encoder; 3.3-V-logic H-bridge rated ab…
Fixtureguarded response-test arm or linear carriage with marked start/target positio…
Protectcurrent-limited 6–12 V DC supply; fused actuator lead with spare fuses; latch…
System block
Complete quantity and equipment per team
Purpose / acceptance condition
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser golden-response trace and metric-calculation check file
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Release-to-team condition: The MCU must calculate or export a timestamped response while enforcing travel, current and time bounds. The organiser signs the electrical, mechanical and communication acceptance checklist before H0:00.
Not duplicated inside the kit: supervised rework tools and the oscilloscope/logic-analyser station are shared at the ratio stated above. Everything else in this table is issued to, reserved for, or digitally assigned to this team.
Controlled self-learning extension
Recommended Build an early-decision curve at several observation windows and select the shortest window that still meets a frozen safety-recall requirement. This is evaluation engineering, not a new ML family.
System safety and non-negotiable boundary
PID remains deterministic on the MCU. ML cannot generate arbitrary gains. Only pre-approved profiles are accepted, and standard saturation, anti-windup, timeout and current limits remain active.
Student interpretation — what this challenge really asks
A completed movement can still be poor: too much overshoot, slow settling, excessive current or residual error. Students predict response quality from early telemetry and use it to choose only pre-approved profiles.
Independent data unitone complete step-response episode with a declared starting state and profile.
Closest misleading casetwo responses with similar early motion but different final settling or saturation behaviour.
Definition of successStudents must predict a useful engineering outcome on a held-out response and improve profile choice over the fixed baseline.
Visual system blueprint
Physical processClosed-loop step responseGenerate labelled, safe and repeatable conditions.
Observesetpoint, position/speed feedback, errorPreserve units, timestamps, run identity and signal quality.
H753 responsibilityControl and protectexecute reproducible step tests, compute/export response markers and enforce all travel/current bounds.
Host intelligenceLearn the distinctionpredict overshoot, settling time, steady-state error, peak current or pass/fail quality.
Bounded outcomePROFILE_ID · CONTINUE_TEST · RETEST · CONSERVATIVE_PROFILEMCU validates, acknowledges and may refuse the request.
Recommended build journey
Make the process repeatableAssemble the H753-M position or speed-control test bench; define reference and target conditions before collecting data.
Prove deterministic firmwareExecute reproducible step tests, compute/export response markers and enforce all travel/current bounds. Demonstrate every hard limit before connecting ML.
Build trustworthy trialsTreat one complete step-response episode with a declared starting state and profile as independent; calibrate, label and split by run/session.
Beat a real baselineCompare last-run value, fixed profile average or simple linear estimate with two syllabus-approved classical models.
Close and challenge the loopReturn only the applicable subset of PROFILE_ID · CONTINUE_TEST · RETEST · CONSERVATIVE_PROFILE; test the target, nearest confuser, stale command and host loss.
Definition of done
Firmware controls safely before, during and after host connection.
Portfolio shows step-response envelope with predicted and measured quality annotations and one honest failure case.
Problem-specific evidence at the common reviews
R1 · Design
Specify motion-quality limits, test setpoints, early observation window, profiles and ground-truth metric computation.
R2 · Embedded
Demonstrate reproducible PID step responses and correct logging of timer period, setpoint, feedback and PWM.
R3 · Data
Publish response trials with automatically computed overshoot/settling/error and a simple threshold baseline.
R4 · ML
Show early-window models, final-metric prediction, calibration and error breakdown by setpoint/load.
R5 · Integration
Use the prediction to select/decline profiles and prove safe fallback under host loss or bad prediction.
Final
Run hidden motion profiles and predict compliance before revealing the measured final response.
Portfolio/Kaggle outcome
Kaggle notebook: ‘Predicting PID Step-Response Quality from Early Telemetry,’ including automatic metric extraction, early-versus-full feature comparison, model calibration and examples where prediction differs from final measured quality.
Industry alignment and validation basis
MotionScore: external references and required evidence
The listed sources establish relevance, test discipline and implementation precedent. They do not modify the common syllabus boundary, safety rules or 100-mark assessment rubric.
Family implementation profile
Variant availability: 10 standard assignment(s); 0 organiser-supported assignment(s).
Public evidence: reproducible firmware, protocol, dataset, notebook/model, test report and demonstration video.
What the external benchmark confirms
The problem has a recognisable industrial or challenge analogue, a measurable data task, a defensible embedded implementation and a safe operational decision. Every one of its ten variants is mapped separately below.
Condition before team allocation
Freeze response bands and faculty-approved profiles before the event so teams compare on identical engineering limits.
Combine process state, velocity, torque, current, voltage and timing context for conveyor anomaly detection, diagnosis and productivity analysis.
Condition inference on process phase; preserve physical context; test root-cause discrimination and subtask timing rather than a context-free threshold.
Collect heterogeneous sensor and motor-control telemetry for real-time monitoring, performance assessment, labelling and Python-side data workflows.
Synchronise sensor, command and motor telemetry; keep labels and configuration with each run; provide replayable host-side data.
Open the 10 fully elaborated student variant briefs
Choose only the variant allocated to your team. Read it together with the parent problem above: the card expands the experimental delta, while every hardware, safety, integration and review requirement of the family remains active.
Variant 04.01
Overshoot Compliance Predictor
Engineering purpose: Gives a crisp control-quality acceptance target.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensequadrature encoder/position feedback device; 0–3.3 V conditioned current-sens…
Actuatelow-torque 6–12 V geared DC motor with encoder; 3.3-V-logic H-bridge rated ab…
Fixturestandard response-test rig with a clearly marked overshoot limit and end stop
Protectcurrent-limited 6–12 V DC supply; fused actuator lead with spare fuses; latch…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser golden-response trace and metric-calculation check file
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: The MCU must calculate or export a timestamped response while enforcing travel, current and time bounds. Verify the complete EQ-04-01 manifest before data collection.
1 · Scenario and student challenge
Predict whether peak overshoot will exceed a product limit. In plain language, adapt MotionScore — Closed-Loop Response Quality Predictor so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Gives a crisp control-quality acceptance target.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M + the named safe mechanical/condition fixture. Begin with the H753-M position or speed-control test bench and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record setpoint, position/speed feedback, error, PWM, current, time, gain/profile ID and load context. Treat one complete step-response episode with a declared starting state and profile as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Binary classification or overshoot regression. First implement the parent baseline—last-run value, fixed profile average or simple linear estimate—and then compare two algorithms from the faculty-issued ML whitelist. Report MAE and RMSE on whole held-out runs, show predicted-versus-measured values, and inspect error by operating condition. If the target is converted to a safe/unsafe decision, also report missed-unsafe and unnecessary-conservative actions. Produce a predicted-versus-measured plot with residuals by operating condition.
5 · Embedded integration and safe response
The host may return only approved PROFILE_ID, CONTINUE_TEST, RETEST or CONSERVATIVE_PROFILE, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with two responses with similar early motion but different final settling or saturation behaviour. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 04.01 — Overshoot Compliance Predictor”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M + the named safe mechanical/condition fixtureregression/outcomerun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P04 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Overshoot Compliance Predictor is a syllabus-scaled physical analogue of the need evidenced by BM07 · RP-1587 Control Loop Performance Assessment: Predict whether peak overshoot will exceed a product limit. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needDevelop a metric for assessing control-loop performance and report field-testing work on control quality.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Synchronise sensor, command and motor telemetry; keep labels and configuration with each run; provide replayable host-side data.
Only its logging and actuator-data pattern is referenced. Its on-device AI and BLDC/FOC examples remain outside this course.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationFreeze response bands and faculty-approved profiles before the event so teams compare on identical engineering limits.
Variant 04.02
Settling-Time Predictor
Engineering purpose: Connects ML directly to throughput.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensequadrature encoder/position feedback device; 0–3.3 V conditioned current-sens…
Actuatelow-torque 6–12 V geared DC motor with encoder; 3.3-V-logic H-bridge rated ab…
Fixturestandard response-test rig with a printed settling-band overlay/position scale
Protectcurrent-limited 6–12 V DC supply; fused actuator lead with spare fuses; latch…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser golden-response trace and metric-calculation check file
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: The MCU must calculate or export a timestamped response while enforcing travel, current and time bounds. Verify the complete EQ-04-02 manifest before data collection.
1 · Scenario and student challenge
Estimate time to remain inside a defined error band. In plain language, adapt MotionScore — Closed-Loop Response Quality Predictor so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Connects ML directly to throughput.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M + the named safe mechanical/condition fixture. Begin with the H753-M position or speed-control test bench and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record setpoint, position/speed feedback, error, PWM, current, time, gain/profile ID and load context. Treat one complete step-response episode with a declared starting state and profile as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Regression from early trajectory features. First implement the parent baseline—last-run value, fixed profile average or simple linear estimate—and then compare two algorithms from the faculty-issued ML whitelist. Report MAE and RMSE on whole held-out runs, show predicted-versus-measured values, and inspect error by operating condition. If the target is converted to a safe/unsafe decision, also report missed-unsafe and unnecessary-conservative actions. Produce a predicted-versus-measured plot with residuals by operating condition.
5 · Embedded integration and safe response
The host may return only approved PROFILE_ID, CONTINUE_TEST, RETEST or CONSERVATIVE_PROFILE, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with two responses with similar early motion but different final settling or saturation behaviour. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 04.02 — Settling-Time Predictor”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M + the named safe mechanical/condition fixtureregression/outcomerun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P04 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Settling-Time Predictor is a syllabus-scaled physical analogue of the need evidenced by BM07 · RP-1587 Control Loop Performance Assessment: Estimate time to remain inside a defined error band. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needDevelop a metric for assessing control-loop performance and report field-testing work on control quality.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Synchronise sensor, command and motor telemetry; keep labels and configuration with each run; provide replayable host-side data.
Only its logging and actuator-data pattern is referenced. Its on-device AI and BLDC/FOC examples remain outside this course.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationFreeze response bands and faculty-approved profiles before the event so teams compare on identical engineering limits.
Variant 04.03
Steady-State Accuracy Predictor
Engineering purpose: Highlights integral action and persistent bias.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensequadrature encoder/position feedback device; 0–3.3 V conditioned current-sens…
Actuatelow-torque 6–12 V geared DC motor with encoder; 3.3-V-logic H-bridge rated ab…
Fixturestandard response-test rig with a calibrated final-position reference
Protectcurrent-limited 6–12 V DC supply; fused actuator lead with spare fuses; latch…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser golden-response trace and metric-calculation check file
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: The MCU must calculate or export a timestamped response while enforcing travel, current and time bounds. Verify the complete EQ-04-03 manifest before data collection.
1 · Scenario and student challenge
Predict final error from initial response and control effort. In plain language, adapt MotionScore — Closed-Loop Response Quality Predictor so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Highlights integral action and persistent bias.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M + the named safe mechanical/condition fixture. Begin with the H753-M position or speed-control test bench and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record setpoint, position/speed feedback, error, PWM, current, time, gain/profile ID and load context. Treat one complete step-response episode with a declared starting state and profile as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Regression/classification. First implement the parent baseline—last-run value, fixed profile average or simple linear estimate—and then compare two algorithms from the faculty-issued ML whitelist. Report MAE and RMSE on whole held-out runs, show predicted-versus-measured values, and inspect error by operating condition. If the target is converted to a safe/unsafe decision, also report missed-unsafe and unnecessary-conservative actions. Produce a predicted-versus-measured plot with residuals by operating condition.
5 · Embedded integration and safe response
The host may return only approved PROFILE_ID, CONTINUE_TEST, RETEST or CONSERVATIVE_PROFILE, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with two responses with similar early motion but different final settling or saturation behaviour. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 04.03 — Steady-State Accuracy Predictor”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M + the named safe mechanical/condition fixtureregression/outcomerun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P04 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Steady-State Accuracy Predictor is a syllabus-scaled physical analogue of the need evidenced by BM07 · RP-1587 Control Loop Performance Assessment: Predict final error from initial response and control effort. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needDevelop a metric for assessing control-loop performance and report field-testing work on control quality.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Synchronise sensor, command and motor telemetry; keep labels and configuration with each run; provide replayable host-side data.
Only its logging and actuator-data pattern is referenced. Its on-device AI and BLDC/FOC examples remain outside this course.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationFreeze response bands and faculty-approved profiles before the event so teams compare on identical engineering limits.
Variant 04.04
Oscillation-Risk Classifier
Engineering purpose: Turns qualitative tuning language into data evidence.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensequadrature encoder/position feedback device; 0–3.3 V conditioned current-sens…
Actuatelow-torque 6–12 V geared DC motor with encoder; 3.3-V-logic H-bridge rated ab…
Fixturestandard response-test rig with only faculty-approved stable and lightly osci…
Protectcurrent-limited 6–12 V DC supply; fused actuator lead with spare fuses; latch…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser golden-response trace and metric-calculation check file
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: The MCU must calculate or export a timestamped response while enforcing travel, current and time bounds. Verify the complete EQ-04-04 manifest before data collection.
1 · Scenario and student challenge
Classify well-damped, lightly oscillatory and unstable-looking responses within safe bounds. In plain language, adapt MotionScore — Closed-Loop Response Quality Predictor so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Turns qualitative tuning language into data evidence.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M + the named safe mechanical/condition fixture. Begin with the H753-M position or speed-control test bench and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record setpoint, position/speed feedback, error, PWM, current, time, gain/profile ID and load context. Treat one complete step-response episode with a declared starting state and profile as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Multiclass classification using zero-crossings and peak decay. First implement the parent baseline—last-run value, fixed profile average or simple linear estimate—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only approved PROFILE_ID, CONTINUE_TEST, RETEST or CONSERVATIVE_PROFILE, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with two responses with similar early motion but different final settling or saturation behaviour. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 04.04 — Oscillation-Risk Classifier”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M + the named safe mechanical/condition fixtureclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P04 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Oscillation-Risk Classifier is a syllabus-scaled physical analogue of the need evidenced by BM07 · RP-1587 Control Loop Performance Assessment: Classify well-damped, lightly oscillatory and unstable-looking responses within safe bounds. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needDevelop a metric for assessing control-loop performance and report field-testing work on control quality.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Synchronise sensor, command and motor telemetry; keep labels and configuration with each run; provide replayable host-side data.
Only its logging and actuator-data pattern is referenced. Its on-device AI and BLDC/FOC examples remain outside this course.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationFreeze response bands and faculty-approved profiles before the event so teams compare on identical engineering limits.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensequadrature encoder/position feedback device; 0–3.3 V conditioned current-sens…
Actuatelow-torque 6–12 V geared DC motor with encoder; 3.3-V-logic H-bridge rated ab…
Fixturestandard response-test rig with a firmware-limited high-demand target that ca…
Protectcurrent-limited 6–12 V DC supply; fused actuator lead with spare fuses; latch…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser golden-response trace and metric-calculation check file
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: The MCU must calculate or export a timestamped response while enforcing travel, current and time bounds. Verify the complete EQ-04-05 manifest before data collection.
1 · Scenario and student challenge
Predict prolonged PWM saturation before a motion attempt completes. In plain language, adapt MotionScore — Closed-Loop Response Quality Predictor so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Supports conservative profile selection.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M + the named safe mechanical/condition fixture. Begin with the H753-M position or speed-control test bench and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record setpoint, position/speed feedback, error, PWM, current, time, gain/profile ID and load context. Treat one complete step-response episode with a declared starting state and profile as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Binary classifier from setpoint/load/early current. First implement the parent baseline—last-run value, fixed profile average or simple linear estimate—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only approved PROFILE_ID, CONTINUE_TEST, RETEST or CONSERVATIVE_PROFILE, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with two responses with similar early motion but different final settling or saturation behaviour. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 04.05 — Saturation-Risk Predictor”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M + the named safe mechanical/condition fixtureclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P04 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Saturation-Risk Predictor is a syllabus-scaled physical analogue of the need evidenced by BM07 · RP-1587 Control Loop Performance Assessment: Predict prolonged PWM saturation before a motion attempt completes. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needDevelop a metric for assessing control-loop performance and report field-testing work on control quality.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Synchronise sensor, command and motor telemetry; keep labels and configuration with each run; provide replayable host-side data.
Only its logging and actuator-data pattern is referenced. Its on-device AI and BLDC/FOC examples remain outside this course.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationFreeze response bands and faculty-approved profiles before the event so teams compare on identical engineering limits.
Variant 04.06
Disturbance-Recovery Predictor
Engineering purpose: Measures robustness, not just nominal tracking.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensequadrature encoder/position feedback device; 0–3.3 V conditioned current-sens…
Actuatelow-torque 6–12 V geared DC motor with encoder; 3.3-V-logic H-bridge rated ab…
Fixtureresponse-test rig plus controlled disturbance lever/felt pad; repeatable dist…
Protectcurrent-limited 6–12 V DC supply; fused actuator lead with spare fuses; latch…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser golden-response trace and metric-calculation check file
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: The MCU must calculate or export a timestamped response while enforcing travel, current and time bounds. Verify the complete EQ-04-06 manifest before data collection.
1 · Scenario and student challenge
Apply a controlled, safe disturbance and estimate recovery time. In plain language, adapt MotionScore — Closed-Loop Response Quality Predictor so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Measures robustness, not just nominal tracking.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M + the named safe mechanical/condition fixture. Begin with the H753-M position or speed-control test bench and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record setpoint, position/speed feedback, error, PWM, current, time, gain/profile ID and load context. Treat one complete step-response episode with a declared starting state and profile as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Regression or pass/fail classification. First implement the parent baseline—last-run value, fixed profile average or simple linear estimate—and then compare two algorithms from the faculty-issued ML whitelist. Report MAE and RMSE on whole held-out runs, show predicted-versus-measured values, and inspect error by operating condition. If the target is converted to a safe/unsafe decision, also report missed-unsafe and unnecessary-conservative actions. Produce a predicted-versus-measured plot with residuals by operating condition.
5 · Embedded integration and safe response
The host may return only approved PROFILE_ID, CONTINUE_TEST, RETEST or CONSERVATIVE_PROFILE, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with two responses with similar early motion but different final settling or saturation behaviour. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 04.06 — Disturbance-Recovery Predictor”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M + the named safe mechanical/condition fixtureregression/outcomerun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P04 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Disturbance-Recovery Predictor is a syllabus-scaled physical analogue of the need evidenced by BM07 · RP-1587 Control Loop Performance Assessment: Apply a controlled, safe disturbance and estimate recovery time. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needDevelop a metric for assessing control-loop performance and report field-testing work on control quality.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Synchronise sensor, command and motor telemetry; keep labels and configuration with each run; provide replayable host-side data.
Only its logging and actuator-data pattern is referenced. Its on-device AI and BLDC/FOC examples remain outside this course.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationFreeze response bands and faculty-approved profiles before the event so teams compare on identical engineering limits.
Variant 04.07
Direction-Specific Motion Score
Engineering purpose: Detects asymmetric drive or mechanics.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensequadrature encoder/position feedback device; 0–3.3 V conditioned current-sens…
Actuatelow-torque 6–12 V geared DC motor with encoder; 3.3-V-logic H-bridge rated ab…
Fixturesymmetric bidirectional response-test rig with centre/home marker
Protectcurrent-limited 6–12 V DC supply; fused actuator lead with spare fuses; latch…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser golden-response trace and metric-calculation check file
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: The MCU must calculate or export a timestamped response while enforcing travel, current and time bounds. Verify the complete EQ-04-07 manifest before data collection.
1 · Scenario and student challenge
Score forward and reverse moves separately. In plain language, adapt MotionScore — Closed-Loop Response Quality Predictor so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Detects asymmetric drive or mechanics.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M + the named safe mechanical/condition fixture. Begin with the H753-M position or speed-control test bench and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record setpoint, position/speed feedback, error, PWM, current, time, gain/profile ID and load context. Treat one complete step-response episode with a declared starting state and profile as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Model with direction interactions and fairness-like comparison. First implement the parent baseline—last-run value, fixed profile average or simple linear estimate—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a step-response envelope with predicted and measured quality annotations.
5 · Embedded integration and safe response
The host may return only approved PROFILE_ID, CONTINUE_TEST, RETEST or CONSERVATIVE_PROFILE, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with two responses with similar early motion but different final settling or saturation behaviour. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 04.07 — Direction-Specific Motion Score”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M + the named safe mechanical/condition fixtureclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P04 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Direction-Specific Motion Score is a syllabus-scaled physical analogue of the need evidenced by BM07 · RP-1587 Control Loop Performance Assessment: Score forward and reverse moves separately. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needDevelop a metric for assessing control-loop performance and report field-testing work on control quality.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Synchronise sensor, command and motor telemetry; keep labels and configuration with each run; provide replayable host-side data.
Only its logging and actuator-data pattern is referenced. Its on-device AI and BLDC/FOC examples remain outside this course.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationFreeze response bands and faculty-approved profiles before the event so teams compare on identical engineering limits.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensequadrature encoder/position feedback device; 0–3.3 V conditioned current-sens…
Actuatelow-torque 6–12 V geared DC motor with encoder; 3.3-V-logic H-bridge rated ab…
Fixtureresponse-test rig with rigid repeatable start/target stops; cycle counter/eve…
Protectcurrent-limited 6–12 V DC supply; fused actuator lead with spare fuses; latch…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser golden-response trace and metric-calculation check file
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: The MCU must calculate or export a timestamped response while enforcing travel, current and time bounds. Verify the complete EQ-04-08 manifest before data collection.
1 · Scenario and student challenge
Predict whether repeated identical moves will remain within a tolerance band. In plain language, adapt MotionScore — Closed-Loop Response Quality Predictor so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Adds manufacturing-quality relevance.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M + the named safe mechanical/condition fixture. Begin with the H753-M position or speed-control test bench and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record setpoint, position/speed feedback, error, PWM, current, time, gain/profile ID and load context. Treat one complete step-response episode with a declared starting state and profile as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Classification using prior-cycle statistics. First implement the parent baseline—last-run value, fixed profile average or simple linear estimate—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only approved PROFILE_ID, CONTINUE_TEST, RETEST or CONSERVATIVE_PROFILE, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with two responses with similar early motion but different final settling or saturation behaviour. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 04.08 — Repeatability Passport”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M + the named safe mechanical/condition fixtureclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P04 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Repeatability Passport is a syllabus-scaled physical analogue of the need evidenced by BM07 · RP-1587 Control Loop Performance Assessment: Predict whether repeated identical moves will remain within a tolerance band. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needDevelop a metric for assessing control-loop performance and report field-testing work on control quality.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Synchronise sensor, command and motor telemetry; keep labels and configuration with each run; provide replayable host-side data.
Only its logging and actuator-data pattern is referenced. Its on-device AI and BLDC/FOC examples remain outside this course.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationFreeze response bands and faculty-approved profiles before the event so teams compare on identical engineering limits.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensequadrature encoder/position feedback device; 0–3.3 V conditioned current-sens…
Actuatelow-torque 6–12 V geared DC motor with encoder; 3.3-V-logic H-bridge rated ab…
Fixtureresponse-test rig with current-sense calibration load; declared current-integ…
Protectcurrent-limited 6–12 V DC supply; fused actuator lead with spare fuses; latch…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser golden-response trace and metric-calculation check file
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: The MCU must calculate or export a timestamped response while enforcing travel, current and time bounds. Verify the complete EQ-04-09 manifest before data collection.
1 · Scenario and student challenge
Classify passes only when time, error and current-integral limits are all satisfied. In plain language, adapt MotionScore — Closed-Loop Response Quality Predictor so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Prevents speed-only optimisation.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M + the named safe mechanical/condition fixture. Begin with the H753-M position or speed-control test bench and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record setpoint, position/speed feedback, error, PWM, current, time, gain/profile ID and load context. Treat one complete step-response episode with a declared starting state and profile as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Composite target and model comparison. First implement the parent baseline—last-run value, fixed profile average or simple linear estimate—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a step-response envelope with predicted and measured quality annotations.
5 · Embedded integration and safe response
The host may return only approved PROFILE_ID, CONTINUE_TEST, RETEST or CONSERVATIVE_PROFILE, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with two responses with similar early motion but different final settling or saturation behaviour. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 04.09 — Energy-Constrained Motion Score”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M + the named safe mechanical/condition fixtureclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P04 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Energy-Constrained Motion Score is a syllabus-scaled physical analogue of the need evidenced by BM07 · RP-1587 Control Loop Performance Assessment: Classify passes only when time, error and current-integral limits are all satisfied. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needDevelop a metric for assessing control-loop performance and report field-testing work on control quality.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Synchronise sensor, command and motor telemetry; keep labels and configuration with each run; provide replayable host-side data.
Only its logging and actuator-data pattern is referenced. Its on-device AI and BLDC/FOC examples remain outside this course.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationFreeze response bands and faculty-approved profiles before the event so teams compare on identical engineering limits.
Variant 04.10
Early Abort Adviser
Engineering purpose: Creates a measurable operational saving.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensequadrature encoder/position feedback device; 0–3.3 V conditioned current-sens…
Actuatelow-torque 6–12 V geared DC motor with encoder; 3.3-V-logic H-bridge rated ab…
Fixtureresponse-test rig with early-abort marker and safe target profiles; firmware-…
Protectcurrent-limited 6–12 V DC supply; fused actuator lead with spare fuses; latch…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser golden-response trace and metric-calculation check file
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: The MCU must calculate or export a timestamped response while enforcing travel, current and time bounds. Verify the complete EQ-04-10 manifest before data collection.
1 · Scenario and student challenge
Predict likely failure early enough to cancel a wasteful move. In plain language, adapt MotionScore — Closed-Loop Response Quality Predictor so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Creates a measurable operational saving.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M + the named safe mechanical/condition fixture. Begin with the H753-M position or speed-control test bench and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record setpoint, position/speed feedback, error, PWM, current, time, gain/profile ID and load context. Treat one complete step-response episode with a declared starting state and profile as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Time-window classifier with latency-benefit analysis. First implement the parent baseline—last-run value, fixed profile average or simple linear estimate—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only approved PROFILE_ID, CONTINUE_TEST, RETEST or CONSERVATIVE_PROFILE, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with two responses with similar early motion but different final settling or saturation behaviour. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 04.10 — Early Abort Adviser”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M + the named safe mechanical/condition fixtureclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P04 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Early Abort Adviser is a syllabus-scaled physical analogue of the need evidenced by BM07 · RP-1587 Control Loop Performance Assessment: Predict likely failure early enough to cancel a wasteful move. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needDevelop a metric for assessing control-loop performance and report field-testing work on control quality.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Synchronise sensor, command and motor telemetry; keep labels and configuration with each run; provide replayable host-side data.
Only its logging and actuator-data pattern is referenced. Its on-device AI and BLDC/FOC examples remain outside this course.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationFreeze response bands and faculty-approved profiles before the event so teams compare on identical engineering limits.
Problem 05 · 10 variants · Motion, drive and actuator intelligence
SafeMove — Obstruction, Friction and Feedback-Fault Discriminator
Team size: 4; approved 3-member exception1 × NUCLEO-H753ZIH753-MClassificationIntermediate
Assigned Faculty Master pair for P05: one nominated ESD Faculty Master and one nominated ML Faculty Master shall jointly master this parent problem and variants V1-V10. The ESD Master owns hardware, firmware, control, communication and safety verification; the ML Master owns data, baselines, models, validation and bounded decision-policy verification. Together they teach and guide ten teams (one for each variant and up to 40 students), supervise five teams in Wave A and five in Wave B, witness integration and sign every final evaluation.
The problem
When an actuator slows or stops, the controller must distinguish a genuine obstruction from normal friction, a hard end-stop, overload, encoder failure or stale command. Treating every slowdown as obstruction reduces availability; ignoring it can be unsafe. The problem requires combining physical evidence from current, motion and command history rather than relying on one sensor.
Smart embedded product to build
Build a guarded low-force gate, slider or arm around one NUCLEO-H753ZI and H753-M pack. The board runs bounded motion, handles end limit/overcurrent/timeout immediately, logs command, age, position, speed, current and temperature, and supports only controlled stop or low-speed reverse. The host diagnoses obstruction, friction, end-stop, overload or feedback fault. The board shows the reason, recommendation and locally accepted action and preserves the complete event trace.
NUCLEO-H753ZI realization and issued pack
NUCLEO-H753ZI / MB1364E with guarded low-force H753-M fixture
servo PWM or DC-motor H-bridge plus encoder/position feedback
conditioned current ADC and optional motor/driver temperature ADC
timer-based travel supervision, end-limit input and physical E-stop
USART3 VCP event telemetry with command age, position, current and reason flags
MCU implements immediate stop/reverse rules before any host diagnosis
LED/display exposes obstruction, friction, end-stop, feedback fault and fallback states
Intelligence to incorporate
Use features such as current rise rate, speed collapse, commanded distance, position, elapsed move time, encoder pulse continuity, direction and recovery after command reduction. Compare rule logic with logistic/tree models. Optimise obstruction recall while separately reporting false reversals, sensor-fault recall and diagnosis latency.
Canonical family command contract: every parent brief, variant, host message and MCU acknowledgement for P05 shall use these exact identifiers. A variant may use only the applicable subset; it shall not introduce a synonym.
Core problem equipment · EQ-05-CORE
Complete equipment required for one core-problem team
Standalone family BOM. This list supports the parent problem itself. An allocated variant uses its own complete table later in this card. A component mentioned again in the fixture description is the same mounted unit, not another copy.
4 students; 3 by approved exception1 H753 board1 team laptopquantities per team
Controller1 H753 board + 1 laptop
Senseactual-position channel: quadrature encoder or external 0–3.3 V angle/linear…
Actuateguarded low-force geared DC actuator with encoder; matching 3.3-V-logic H-bri…
Fixturebounded-travel gate/slider/arm base with soft obstruction pieces and repeatab…
Protectcurrent-limited actuator supply matched to the motor/servo; inline fuse with…
System block
Complete quantity and equipment per team
Purpose / acceptance condition
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser obstruction/friction severity card with safe maximum forces
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Release-to-team condition: Hard obstruction protection must work locally before the host classifier is enabled. The organiser signs the electrical, mechanical and communication acceptance checklist before H0:00.
Not duplicated inside the kit: supervised rework tools and the oscilloscope/logic-analyser station are shared at the ratio stated above. Everything else in this table is issued to, reserved for, or digitally assigned to this team.
Controlled self-learning extension
Recommended Preserve a bounded pre-event trace in RAM and attach a hardware-CRC-protected event record to every diagnosis. Demonstrate detection of a deliberately corrupted host packet without changing the hard-stop logic.
System safety and non-negotiable boundary
The MCU performs immediate overcurrent/end-stop/time-out protection; ML is not in the hard real-time path. Force and speed must remain demonstrably low. A missing host, invalid class or stale command causes conservative action.
Student interpretation — what this challenge really asks
A safe moving product must tell a temporary obstruction from rising friction, overload, an end stop and faulty feedback. The immediate protective stop stays deterministic; ML provides diagnosis and the next bounded operating mode.
Independent data unitone opening, closing or travel cycle with one declared physical condition.
Closest misleading caseroutine position-dependent friction or end-stop behaviour that resembles obstruction.
Definition of successStudents must protect immediately using firmware while using ML to explain the event and choose a safe next mode.
Visual system blueprint
Physical processLow-force moving mechanismGenerate labelled, safe and repeatable conditions.
Observecommanded and measured position, velocity, currentPreserve units, timestamps, run identity and signal quality.
H753 responsibilityControl and protectcontrol bounded travel, stop/reverse on hard protection and log pre-event evidence.
Host intelligenceLearn the distinctiondiscriminate obstruction, degradation, overload, end-stop and sensor inconsistency.
Bounded outcomeNORMAL_MOVE · REDUCED_SPEED · REVERSE_SAFE · LATCHED_STOP · MAINTENANCEMCU validates, acknowledges and may refuse the request.
Recommended build journey
Make the process repeatableAssemble the low-force guarded H753-M gate, slider or servo mechanism; define reference and target conditions before collecting data.
Prove deterministic firmwareControl bounded travel, stop/reverse on hard protection and log pre-event evidence. Demonstrate every hard limit before connecting ML.
Build trustworthy trialsTreat one opening, closing or travel cycle with one declared physical condition as independent; calibrate, label and split by run/session.
Beat a real baselineCompare current threshold plus motion-timeout and proximity rule with two syllabus-approved classical models.
Close and challenge the loopReturn only the applicable subset of NORMAL_MOVE · REDUCED_SPEED · REVERSE_SAFE · LATCHED_STOP · MAINTENANCE; test the target, nearest confuser, stale command and host loss.
Definition of done
Firmware controls safely before, during and after host connection.
Held-out results report obstruction recall, false reversal, per-condition F1 and decision latency.
Portfolio shows travel-position/current timeline with event and action markers and one honest failure case.
Problem-specific evidence at the common reviews
R1 · Design
Define safe fixture, abnormal-event taxonomy, hard interlocks, allowed responses and hidden-test method.
R2 · Embedded
Show low-force motion, limit handling, current/position capture, event logging and deterministic reverse/stop.
R3 · Data
Submit controlled events with run-level labels, rule baseline and leakage-safe split.
R4 · ML
Present cause classifier, cost matrix, diagnosis latency and confusion between friction and obstruction.
R5 · Integration
Close the supervisory loop and pass obstacle, encoder-loss, end-stop and host-loss scenarios.
Final
Diagnose a blind event and execute the correct bounded response with a traceable reason code.
Portfolio/Kaggle outcome
Portfolio package: labelled event dataset, state-machine diagram, hazard analysis, cost-sensitive model evaluation, event replay notebook and a video showing at least four visually distinct fault injections.
Industry alignment and validation basis
SafeMove: external references and required evidence
The listed sources establish relevance, test discipline and implementation precedent. They do not modify the common syllabus boundary, safety rules or 100-mark assessment rubric.
Family implementation profile
Variant availability: 10 standard assignment(s); 0 organiser-supported assignment(s).
Public evidence: reproducible firmware, protocol, dataset, notebook/model, test report and demonstration video.
What the external benchmark confirms
The problem has a recognisable industrial or challenge analogue, a measurable data task, a defensible embedded implementation and a safe operational decision. Every one of its ten variants is mapped separately below.
Condition before team allocation
Standardise low-force obstruction pieces and insist that immediate stopping remains a deterministic MCU function.
Combine sensor measurements and system knowledge to build condition indicators, detect faults and support predictive-maintenance decisions.
Start with an engineering baseline, justify features physically, validate on held-out operating conditions and connect inference to a maintenance action.
Frame cyber-physical systems as integrations of logical, physical and human components with concerns including trustworthiness and interoperability.
Evaluate the complete sense–decide–act system, its interfaces and failure behaviour—not a disconnected model or dashboard.
Open the 10 fully elaborated student variant briefs
Choose only the variant allocated to your team. Read it together with the parent problem above: the card expands the experimental delta, while every hardware, safety, integration and review requirement of the family remains active.
Variant 05.01
Smart Window-Lift Prototype
Engineering purpose: Replicates an automotive anti-pinch design problem.
ChangeVertical travel with direction-dependent load and a soft obstruction.
Observecommanded and measured position, velocity, current, PWM, travel time,…
LearnCause classification with position and direction context.
DecideNORMAL_MOVE, REDUCED_SPEED, MAINTENANCE, REVERSE_SAFE or LATCHED_STOP
Proveobstruction recall, false reversal, per-condition F1 and…
Variant equipment · EQ-05-01
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Senseactual-position channel: quadrature encoder or external 0–3.3 V angle/linear…
Actuateguarded low-force geared DC actuator with encoder; matching 3.3-V-logic H-bri…
Fixtureguarded vertical slider/window-lift emulator; end switches, adjustable seal-f…
Protectcurrent-limited actuator supply matched to the motor/servo; inline fuse with…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser obstruction/friction severity card with safe maximum forces
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Hard obstruction protection must work locally before the host classifier is enabled. Verify the complete EQ-05-01 manifest before data collection.
1 · Scenario and student challenge
Vertical travel with direction-dependent load and a soft obstruction. In plain language, adapt SafeMove — Obstruction, Friction and Feedback-Fault Discriminator so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Replicates an automotive anti-pinch design problem.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M + the named safe mechanical/condition fixture. Begin with the low-force guarded H753-M gate, slider or servo mechanism and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record commanded and measured position, velocity, current, PWM, travel time, proximity/limit input and retry count. Treat one opening, closing or travel cycle with one declared physical condition as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Cause classification with position and direction context. First implement the parent baseline—current threshold plus motion-timeout and proximity rule—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only NORMAL_MOVE, REDUCED_SPEED, MAINTENANCE, REVERSE_SAFE or LATCHED_STOP, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with routine position-dependent friction or end-stop behaviour that resembles obstruction. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 05.01 — Smart Window-Lift Prototype”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M + the named safe mechanical/condition fixtureclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P05 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Smart Window-Lift Prototype is a syllabus-scaled physical analogue of the need evidenced by BM03 · Diagnostic Approach for Electro-Mechanical Actuators in Aerospace Systems: Vertical travel with direction-dependent load and a soft obstruction. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needUse condition indicators to detect, identify and isolate actuator fault modes while distinguishing sensor faults from component failures.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Evaluate the complete sense–decide–act system, its interfaces and failure behaviour—not a disconnected model or dashboard.
It is used as architectural guidance; certification or conformance is neither asserted nor required.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationStandardise low-force obstruction pieces and insist that immediate stopping remains a deterministic MCU function.
Variant 05.02
Mini Gate Safety Controller
Engineering purpose: Visually clear and safety-focused.
ChangeRotating gate arm with normal end-stop and mid-path obstruction.
Observecommanded and measured position, velocity, current, PWM, travel time,…
LearnMulticlass classifier and reverse-decision policy.
DecideNORMAL_MOVE, REDUCED_SPEED, MAINTENANCE, REVERSE_SAFE or LATCHED_STOP
Proveobstruction recall, false reversal, per-condition F1 and…
Variant equipment · EQ-05-02
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Senseactual-position channel: quadrature encoder or external 0–3.3 V angle/linear…
Actuateguarded low-force geared DC actuator with encoder; matching 3.3-V-logic H-bri…
Fixturelow-force rotating gate arm; end stops and compliant mid-path obstructions
Protectcurrent-limited actuator supply matched to the motor/servo; inline fuse with…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser obstruction/friction severity card with safe maximum forces
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Hard obstruction protection must work locally before the host classifier is enabled. Verify the complete EQ-05-02 manifest before data collection.
1 · Scenario and student challenge
Rotating gate arm with normal end-stop and mid-path obstruction. In plain language, adapt SafeMove — Obstruction, Friction and Feedback-Fault Discriminator so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Visually clear and safety-focused.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M + the named safe mechanical/condition fixture. Begin with the low-force guarded H753-M gate, slider or servo mechanism and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record commanded and measured position, velocity, current, PWM, travel time, proximity/limit input and retry count. Treat one opening, closing or travel cycle with one declared physical condition as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Multiclass classifier and reverse-decision policy. First implement the parent baseline—current threshold plus motion-timeout and proximity rule—and then compare two algorithms from the faculty-issued ML whitelist. Report correct/feasible selection rate, constraint violations and improvement over the fixed policy. A choice is wrong if it violates a declared current, timing, thermal or control-quality bound even when it is fast. Produce a candidate-outcome/constraint table showing why the selected option is feasible.
5 · Embedded integration and safe response
The host may return only NORMAL_MOVE, REDUCED_SPEED, MAINTENANCE, REVERSE_SAFE or LATCHED_STOP, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with routine position-dependent friction or end-stop behaviour that resembles obstruction. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 05.02 — Mini Gate Safety Controller”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M + the named safe mechanical/condition fixtureclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P05 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Mini Gate Safety Controller is a syllabus-scaled physical analogue of the need evidenced by BM03 · Diagnostic Approach for Electro-Mechanical Actuators in Aerospace Systems: Rotating gate arm with normal end-stop and mid-path obstruction. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needUse condition indicators to detect, identify and isolate actuator fault modes while distinguishing sensor faults from component failures.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Evaluate the complete sense–decide–act system, its interfaces and failure behaviour—not a disconnected model or dashboard.
It is used as architectural guidance; certification or conformance is neither asserted nor required.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationStandardise low-force obstruction pieces and insist that immediate stopping remains a deterministic MCU function.
Variant 05.03
Packaging Pusher Guardian
Engineering purpose: Maps to manufacturing automation.
Observecommanded and measured position, velocity, current, PWM, travel time,…
LearnClassification using current and travel completion.
DecideNORMAL_MOVE, REDUCED_SPEED, MAINTENANCE, REVERSE_SAFE or LATCHED_STOP
Proveobstruction recall, false reversal, per-condition F1 and…
Variant equipment · EQ-05-03
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Senseactual-position channel: quadrature encoder or external 0–3.3 V angle/linear…
Actuateguarded low-force geared DC actuator with encoder; matching 3.3-V-logic H-bri…
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser obstruction/friction severity card with safe maximum forces
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Hard obstruction protection must work locally before the host classifier is enabled. Verify the complete EQ-05-03 manifest before data collection.
1 · Scenario and student challenge
Linear/rotary pusher distinguishes product contact, excessive resistance and empty stroke. In plain language, adapt SafeMove — Obstruction, Friction and Feedback-Fault Discriminator so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Maps to manufacturing automation.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M + the named safe mechanical/condition fixture. Begin with the low-force guarded H753-M gate, slider or servo mechanism and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record commanded and measured position, velocity, current, PWM, travel time, proximity/limit input and retry count. Treat one opening, closing or travel cycle with one declared physical condition as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Classification using current and travel completion. First implement the parent baseline—current threshold plus motion-timeout and proximity rule—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only NORMAL_MOVE, REDUCED_SPEED, MAINTENANCE, REVERSE_SAFE or LATCHED_STOP, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with routine position-dependent friction or end-stop behaviour that resembles obstruction. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 05.03 — Packaging Pusher Guardian”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M + the named safe mechanical/condition fixtureclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P05 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Packaging Pusher Guardian is a syllabus-scaled physical analogue of the need evidenced by BM03 · Diagnostic Approach for Electro-Mechanical Actuators in Aerospace Systems: Linear/rotary pusher distinguishes product contact, excessive resistance and empty stroke. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needUse condition indicators to detect, identify and isolate actuator fault modes while distinguishing sensor faults from component failures.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Evaluate the complete sense–decide–act system, its interfaces and failure behaviour—not a disconnected model or dashboard.
It is used as architectural guidance; certification or conformance is neither asserted nor required.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationStandardise low-force obstruction pieces and insist that immediate stopping remains a deterministic MCU function.
Variant 05.04
Camera-Gimbal Snag Detector
Engineering purpose: Highlights angle-dependent normal resistance.
ChangeServo motion at multiple angles with cable-drag simulation.
Observecommanded and measured position, velocity, current, PWM, travel time,…
LearnAnomaly/classification conditioned on angle.
DecideNORMAL_MOVE, REDUCED_SPEED, MAINTENANCE, REVERSE_SAFE or LATCHED_STOP
Proveobstruction recall, false reversal, per-condition F1 and…
Variant equipment · EQ-05-04
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Senseexternal 0–3.3 V angle potentiometer; servo-current shunt channel; end-limit/…
Actuateexternally powered low-torque servo
Fixturesingle-axis camera-gimbal emulator; elastic cable-drag strap with two setting…
Protectregulated 5 V, 2 A servo supply; inline fuse plus spare fuses; hardware servo…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser obstruction/friction severity card with safe maximum forces
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Hard obstruction protection must work locally before the host classifier is enabled. Verify the complete EQ-05-04 manifest before data collection.
1 · Scenario and student challenge
Servo motion at multiple angles with cable-drag simulation. In plain language, adapt SafeMove — Obstruction, Friction and Feedback-Fault Discriminator so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Highlights angle-dependent normal resistance.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M + the named safe mechanical/condition fixture. Begin with the low-force guarded H753-M gate, slider or servo mechanism and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record commanded and measured position, velocity, current, PWM, travel time, proximity/limit input and retry count. Treat one opening, closing or travel cycle with one declared physical condition as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Anomaly/classification conditioned on angle. First implement the parent baseline—current threshold plus motion-timeout and proximity rule—and then compare two algorithms from the faculty-issued ML whitelist. Train or set the threshold using healthy/training data only. Report event recall, false alarms per normal run and detection delay; show where the method treats a new but valid regime as abnormal. Produce a event timeline with anomaly score, threshold and false-alarm examples.
5 · Embedded integration and safe response
The host may return only NORMAL_MOVE, REDUCED_SPEED, MAINTENANCE, REVERSE_SAFE or LATCHED_STOP, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with routine position-dependent friction or end-stop behaviour that resembles obstruction. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 05.04 — Camera-Gimbal Snag Detector”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M + the named safe mechanical/condition fixtureanomaly/noveltyrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P05 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Camera-Gimbal Snag Detector is a syllabus-scaled physical analogue of the need evidenced by BM03 · Diagnostic Approach for Electro-Mechanical Actuators in Aerospace Systems: Servo motion at multiple angles with cable-drag simulation. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needUse condition indicators to detect, identify and isolate actuator fault modes while distinguishing sensor faults from component failures.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Evaluate the complete sense–decide–act system, its interfaces and failure behaviour—not a disconnected model or dashboard.
It is used as architectural guidance; certification or conformance is neither asserted nor required.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationStandardise low-force obstruction pieces and insist that immediate stopping remains a deterministic MCU function.
Variant 05.05
Feeder-Flap Obstruction Detector
Engineering purpose: Addresses false trips in feeders.
ChangeSmall flap handles normal material contact versus jam.
Observecommanded and measured position, velocity, current, PWM, travel time,…
LearnClassification with repeated-cycle context.
DecideNORMAL_MOVE, REDUCED_SPEED, MAINTENANCE, REVERSE_SAFE or LATCHED_STOP
Proveobstruction recall, false reversal, per-condition F1 and…
Variant equipment · EQ-05-05
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Senseexternal 0–3.3 V flap-angle potentiometer; servo-current shunt channel; end-l…
Actuateexternally powered low-torque servo
Fixturelow-force feeder flap and chute; lightweight foam pieces, normal-contact inse…
Protectregulated 5 V, 2 A servo supply; inline fuse plus spare fuses; hardware servo…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser obstruction/friction severity card with safe maximum forces
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Hard obstruction protection must work locally before the host classifier is enabled. Verify the complete EQ-05-05 manifest before data collection.
1 · Scenario and student challenge
Small flap handles normal material contact versus jam. In plain language, adapt SafeMove — Obstruction, Friction and Feedback-Fault Discriminator so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Addresses false trips in feeders.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M + the named safe mechanical/condition fixture. Begin with the low-force guarded H753-M gate, slider or servo mechanism and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record commanded and measured position, velocity, current, PWM, travel time, proximity/limit input and retry count. Treat one opening, closing or travel cycle with one declared physical condition as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Classification with repeated-cycle context. First implement the parent baseline—current threshold plus motion-timeout and proximity rule—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only NORMAL_MOVE, REDUCED_SPEED, MAINTENANCE, REVERSE_SAFE or LATCHED_STOP, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with routine position-dependent friction or end-stop behaviour that resembles obstruction. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 05.05 — Feeder-Flap Obstruction Detector”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M + the named safe mechanical/condition fixtureclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P05 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Feeder-Flap Obstruction Detector is a syllabus-scaled physical analogue of the need evidenced by BM03 · Diagnostic Approach for Electro-Mechanical Actuators in Aerospace Systems: Small flap handles normal material contact versus jam. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needUse condition indicators to detect, identify and isolate actuator fault modes while distinguishing sensor faults from component failures.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Evaluate the complete sense–decide–act system, its interfaces and failure behaviour—not a disconnected model or dashboard.
It is used as architectural guidance; certification or conformance is neither asserted nor required.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationStandardise low-force obstruction pieces and insist that immediate stopping remains a deterministic MCU function.
Variant 05.06
Drawer/Locker Actuator Guardian
Engineering purpose: Provides a smart-access product narrative without biometric data.
ChangeShort travel with latch friction, user resistance and blocked close.
Observecommanded and measured position, velocity, current, PWM, travel time,…
LearnCause classification.
DecideNORMAL_MOVE, REDUCED_SPEED, MAINTENANCE, REVERSE_SAFE or LATCHED_STOP
Proveobstruction recall, false reversal, per-condition F1 and…
Variant equipment · EQ-05-06
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Senseactual-position channel: quadrature encoder or external 0–3.3 V angle/linear…
Actuateguarded low-force geared DC actuator with encoder; matching 3.3-V-logic H-bri…
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser obstruction/friction severity card with safe maximum forces
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Hard obstruction protection must work locally before the host classifier is enabled. Verify the complete EQ-05-06 manifest before data collection.
1 · Scenario and student challenge
Short travel with latch friction, user resistance and blocked close. In plain language, adapt SafeMove — Obstruction, Friction and Feedback-Fault Discriminator so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Provides a smart-access product narrative without biometric data.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M + the named safe mechanical/condition fixture. Begin with the low-force guarded H753-M gate, slider or servo mechanism and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record commanded and measured position, velocity, current, PWM, travel time, proximity/limit input and retry count. Treat one opening, closing or travel cycle with one declared physical condition as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Cause classification. First implement the parent baseline—current threshold plus motion-timeout and proximity rule—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only NORMAL_MOVE, REDUCED_SPEED, MAINTENANCE, REVERSE_SAFE or LATCHED_STOP, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with routine position-dependent friction or end-stop behaviour that resembles obstruction. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 05.06 — Drawer/Locker Actuator Guardian”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M + the named safe mechanical/condition fixtureclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P05 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Drawer/Locker Actuator Guardian is a syllabus-scaled physical analogue of the need evidenced by BM03 · Diagnostic Approach for Electro-Mechanical Actuators in Aerospace Systems: Short travel with latch friction, user resistance and blocked close. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needUse condition indicators to detect, identify and isolate actuator fault modes while distinguishing sensor faults from component failures.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Evaluate the complete sense–decide–act system, its interfaces and failure behaviour—not a disconnected model or dashboard.
It is used as architectural guidance; certification or conformance is neither asserted nor required.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationStandardise low-force obstruction pieces and insist that immediate stopping remains a deterministic MCU function.
Variant 05.07
Valve/Damper Stiction Detector
Engineering purpose: Relevant to HVAC and process control.
ChangeServo moves a resistive dial/fixture and distinguishes stiction from…
Observecommanded and measured position, velocity, current, PWM, travel time,…
LearnOrdinal friction/obstruction classification.
DecideNORMAL_MOVE, REDUCED_SPEED, MAINTENANCE, REVERSE_SAFE or LATCHED_STOP
Proveobstruction recall, false reversal, per-condition F1 and…
Variant equipment · EQ-05-07
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sense0–3.3 V dial-angle potentiometer; servo-current shunt channel; safe travel-li…
Actuateexternally powered low-torque servo
Fixtureservo-driven valve/damper dial; detent/friction inserts plus hard stop
Protectregulated 5 V, 2 A servo supply; inline fuse plus spare fuses; hardware servo…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser obstruction/friction severity card with safe maximum forces
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Hard obstruction protection must work locally before the host classifier is enabled. Verify the complete EQ-05-07 manifest before data collection.
1 · Scenario and student challenge
Servo moves a resistive dial/fixture and distinguishes stiction from hard stop. In plain language, adapt SafeMove — Obstruction, Friction and Feedback-Fault Discriminator so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Relevant to HVAC and process control.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M + the named safe mechanical/condition fixture. Begin with the low-force guarded H753-M gate, slider or servo mechanism and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record commanded and measured position, velocity, current, PWM, travel time, proximity/limit input and retry count. Treat one opening, closing or travel cycle with one declared physical condition as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Ordinal friction/obstruction classification. First implement the parent baseline—current threshold plus motion-timeout and proximity rule—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only NORMAL_MOVE, REDUCED_SPEED, MAINTENANCE, REVERSE_SAFE or LATCHED_STOP, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with routine position-dependent friction or end-stop behaviour that resembles obstruction. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 05.07 — Valve/Damper Stiction Detector”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M + the named safe mechanical/condition fixtureclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P05 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Valve/Damper Stiction Detector is a syllabus-scaled physical analogue of the need evidenced by BM03 · Diagnostic Approach for Electro-Mechanical Actuators in Aerospace Systems: Servo moves a resistive dial/fixture and distinguishes stiction from hard stop. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needUse condition indicators to detect, identify and isolate actuator fault modes while distinguishing sensor faults from component failures.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Evaluate the complete sense–decide–act system, its interfaces and failure behaviour—not a disconnected model or dashboard.
It is used as architectural guidance; certification or conformance is neither asserted nor required.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationStandardise low-force obstruction pieces and insist that immediate stopping remains a deterministic MCU function.
Variant 05.08
Robotic-Gripper Contact Classifier
Engineering purpose: Introduces safe contact intelligence without force sensors.
ChangeLow-force servo grip distinguishes no object, intended contact and…
Observecommanded and measured position, velocity, current, PWM, travel time,…
LearnMulticlass classification from current/position.
DecideNORMAL_MOVE, REDUCED_SPEED, MAINTENANCE, REVERSE_SAFE or LATCHED_STOP
Proveobstruction recall, false reversal, per-condition F1 and…
Variant equipment · EQ-05-08
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensejaw-position potentiometer or flex sensor conditioned to 0–3.3 V; servo-curre…
Actuateexternally powered micro-servo gripper
Fixturelow-force two-finger servo gripper; foam objects across three compliance clas…
Protectregulated 5 V, 2 A servo supply; inline fuse plus spare fuses; hardware servo…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser obstruction/friction severity card with safe maximum forces
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Hard obstruction protection must work locally before the host classifier is enabled. Verify the complete EQ-05-08 manifest before data collection.
1 · Scenario and student challenge
Low-force servo grip distinguishes no object, intended contact and excessive resistance. In plain language, adapt SafeMove — Obstruction, Friction and Feedback-Fault Discriminator so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Introduces safe contact intelligence without force sensors.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M + the named safe mechanical/condition fixture. Begin with the low-force guarded H753-M gate, slider or servo mechanism and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record commanded and measured position, velocity, current, PWM, travel time, proximity/limit input and retry count. Treat one opening, closing or travel cycle with one declared physical condition as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Multiclass classification from current/position. First implement the parent baseline—current threshold plus motion-timeout and proximity rule—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only NORMAL_MOVE, REDUCED_SPEED, MAINTENANCE, REVERSE_SAFE or LATCHED_STOP, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with routine position-dependent friction or end-stop behaviour that resembles obstruction. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 05.08 — Robotic-Gripper Contact Classifier”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M + the named safe mechanical/condition fixtureclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P05 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Robotic-Gripper Contact Classifier is a syllabus-scaled physical analogue of the need evidenced by BM03 · Diagnostic Approach for Electro-Mechanical Actuators in Aerospace Systems: Low-force servo grip distinguishes no object, intended contact and excessive resistance. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needUse condition indicators to detect, identify and isolate actuator fault modes while distinguishing sensor faults from component failures.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Evaluate the complete sense–decide–act system, its interfaces and failure behaviour—not a disconnected model or dashboard.
It is used as architectural guidance; certification or conformance is neither asserted nor required.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationStandardise low-force obstruction pieces and insist that immediate stopping remains a deterministic MCU function.
Variant 05.09
End-Stop Learning Auditor
Engineering purpose: Shows why context matters more than current threshold.
ChangeIdentify normal mechanical end-stops versus premature blockages at…
Observecommanded and measured position, velocity, current, PWM, travel time,…
LearnPosition-aware classification.
DecideNORMAL_MOVE, REDUCED_SPEED, MAINTENANCE, REVERSE_SAFE or LATCHED_STOP
Proveobstruction recall, false reversal, per-condition F1 and…
Variant equipment · EQ-05-09
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Senseactual-position channel: quadrature encoder or external 0–3.3 V angle/linear…
Actuateguarded low-force geared DC actuator with encoder; matching 3.3-V-logic H-bri…
Fixturebounded-travel arm/slider with one legitimate end stop and three premature-st…
Protectcurrent-limited actuator supply matched to the motor/servo; inline fuse with…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser obstruction/friction severity card with safe maximum forces
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Hard obstruction protection must work locally before the host classifier is enabled. Verify the complete EQ-05-09 manifest before data collection.
1 · Scenario and student challenge
Identify normal mechanical end-stops versus premature blockages at other positions. In plain language, adapt SafeMove — Obstruction, Friction and Feedback-Fault Discriminator so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Shows why context matters more than current threshold.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M + the named safe mechanical/condition fixture. Begin with the low-force guarded H753-M gate, slider or servo mechanism and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record commanded and measured position, velocity, current, PWM, travel time, proximity/limit input and retry count. Treat one opening, closing or travel cycle with one declared physical condition as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Position-aware classification. First implement the parent baseline—current threshold plus motion-timeout and proximity rule—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only NORMAL_MOVE, REDUCED_SPEED, MAINTENANCE, REVERSE_SAFE or LATCHED_STOP, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with routine position-dependent friction or end-stop behaviour that resembles obstruction. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 05.09 — End-Stop Learning Auditor”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M + the named safe mechanical/condition fixtureclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P05 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
End-Stop Learning Auditor is a syllabus-scaled physical analogue of the need evidenced by BM03 · Diagnostic Approach for Electro-Mechanical Actuators in Aerospace Systems: Identify normal mechanical end-stops versus premature blockages at other positions. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needUse condition indicators to detect, identify and isolate actuator fault modes while distinguishing sensor faults from component failures.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Evaluate the complete sense–decide–act system, its interfaces and failure behaviour—not a disconnected model or dashboard.
It is used as architectural guidance; certification or conformance is neither asserted nor required.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationStandardise low-force obstruction pieces and insist that immediate stopping remains a deterministic MCU function.
Variant 05.10
Feedback-Fault versus Mechanical-Fault
Engineering purpose: Makes multisignal fault isolation the central learning outcome.
ChangeInject encoder freeze/dropout and compare with true obstruction.
Observecommanded and measured position, velocity, current, PWM, travel time,…
LearnBinary/multiclass diagnostic model.
DecideNORMAL_MOVE, REDUCED_SPEED, MAINTENANCE, REVERSE_SAFE or LATCHED_STOP
Proveobstruction recall, false reversal, per-condition F1 and…
Variant equipment · EQ-05-10
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Senseactual-position channel: quadrature encoder or external 0–3.3 V angle/linear…
Actuateguarded low-force geared DC actuator with encoder; matching 3.3-V-logic H-bri…
Fixturemotor/encoder motion fixture with separate encoder fault-injection switch; me…
Protectcurrent-limited actuator supply matched to the motor/servo; inline fuse with…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser obstruction/friction severity card with safe maximum forces
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Hard obstruction protection must work locally before the host classifier is enabled. Verify the complete EQ-05-10 manifest before data collection.
1 · Scenario and student challenge
Inject encoder freeze/dropout and compare with true obstruction. In plain language, adapt SafeMove — Obstruction, Friction and Feedback-Fault Discriminator so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Makes multisignal fault isolation the central learning outcome.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M + the named safe mechanical/condition fixture. Begin with the low-force guarded H753-M gate, slider or servo mechanism and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record commanded and measured position, velocity, current, PWM, travel time, proximity/limit input and retry count. Treat one opening, closing or travel cycle with one declared physical condition as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Binary/multiclass diagnostic model. First implement the parent baseline—current threshold plus motion-timeout and proximity rule—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only NORMAL_MOVE, REDUCED_SPEED, MAINTENANCE, REVERSE_SAFE or LATCHED_STOP, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with routine position-dependent friction or end-stop behaviour that resembles obstruction. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 05.10 — Feedback-Fault versus Mechanical-Fault”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M + the named safe mechanical/condition fixtureclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P05 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Feedback-Fault versus Mechanical-Fault is a syllabus-scaled physical analogue of the need evidenced by BM03 · Diagnostic Approach for Electro-Mechanical Actuators in Aerospace Systems: Inject encoder freeze/dropout and compare with true obstruction. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needUse condition indicators to detect, identify and isolate actuator fault modes while distinguishing sensor faults from component failures.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Evaluate the complete sense–decide–act system, its interfaces and failure behaviour—not a disconnected model or dashboard.
It is used as architectural guidance; certification or conformance is neither asserted nor required.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationStandardise low-force obstruction pieces and insist that immediate stopping remains a deterministic MCU function.
Problem 06 · 10 variants · Motion, drive and actuator intelligence
Assigned Faculty Master pair for P06: one nominated ESD Faculty Master and one nominated ML Faculty Master shall jointly master this parent problem and variants V1-V10. The ESD Master owns hardware, firmware, control, communication and safety verification; the ML Master owns data, baselines, models, validation and bounded decision-policy verification. Together they teach and guide ten teams (one for each variant and up to 40 students), supervise five teams in Wave A and five in Wave B, witness integration and sign every final evaluation.
The problem
Motor and driver temperature often rises after current demand has already increased. A hard temperature trip protects equipment but may react late and cause abrupt downtime. The engineering opportunity is to predict near-future thermal risk from recent current, PWM, speed, load and temperature trends and derate safely before the trip point.
Smart embedded product to build
Build a NUCLEO-H753ZI predictive thermal supervisor for the H753-M drive. The board controls the low-voltage motor, samples conditioned current plus motor/driver and ambient temperature, records duty, speed and rest history, and independently trips at hard limits. The host predicts a fixed-horizon temperature/risk class and can only retain or reduce demand through NORMAL_DUTY, DERATE_LEVEL_1, DERATE_LEVEL_2, COOL_DOWN or STOP; the MCU displays and acknowledges its actual action.
NUCLEO-H753ZI realization and issued pack
NUCLEO-H753ZI / MB1364E with H753-M and temperature channels from H753-S
timer PWM/encoder control through approved motor stage
ADC acquisition of conditioned current, motor/driver temperature and ambient reference
firmware hard trip plus NORMAL, DERATED and COOLDOWN profiles
USART3 VCP emits fixed-window thermal/control summaries and accepts only lower-demand profile IDs
LED/display reports measured temperature, predicted risk band and actual MCU action
only low-voltage, faculty-approved heat sources and temperature limits
Intelligence to incorporate
Transform recent history into simple tabular features: current/PWM averages and maxima, temperature level/slope, duty-cycle ratio, speed error, prior rest time and ambient proxy. Use regression or multiclass classification. Evaluate horizon MAE, high-risk recall, warning lead time, false derates and temperature-limit violations relative to a fixed-threshold baseline.
Canonical family command contract: every parent brief, variant, host message and MCU acknowledgement for P06 shall use these exact identifiers. A variant may use only the applicable subset; it shall not introduce a synonym.
Core problem equipment · EQ-06-CORE
Complete equipment required for one core-problem team
Standalone family BOM. This list supports the parent problem itself. An allocated variant uses its own complete table later in this card. A component mentioned again in the fixture description is the same mounted unit, not another copy.
4 students; 3 by approved exception1 H753 board1 team laptopquantities per team
Controller1 H753 board + 1 laptop
Sensequadrature encoder/tachometer; 0–3.3 V conditioned current-sense channel; cal…
Actuate6–12 V low-torque geared DC motor with encoder; 3.3-V-logic H-bridge rated ab…
Fixtureguarded duty-cycle/load fixture with NORMAL, DERATE and COOLDOWN profiles; no…
Protectcurrent-limited 6–12 V supply sized for the motor and cooling fan; separately…
System block
Complete quantity and equipment per team
Purpose / acceptance condition
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser thermal-history dataset spanning duty and rest cycles
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Release-to-team condition: Only self-heating or a faculty-approved low-voltage heat source may be used; ML may reduce demand only. The organiser signs the electrical, mechanical and communication acceptance checklist before H0:00.
Not duplicated inside the kit: supervised rework tools and the oscilloscope/logic-analyser station are shared at the ratio stated above. Everything else in this table is issued to, reserved for, or digitally assigned to this team.
Controlled self-learning extension
Recommended Mirror noncritical telemetry through the board’s onboard Ethernet to a local evaluator using organiser starter code. USART3 VCP remains the recovery path; cloud services and MQTT are excluded.
System safety and non-negotiable boundary
The firmware thermal trip is immutable and lower-level than ML. Heating must remain within faculty-approved safe limits; artificial heat sources are low-voltage only. A prediction can only reduce demand, never raise the safety ceiling.
Student interpretation — what this challenge really asks
A drive may be electrically safe now but thermally unsafe if the present duty continues. Students use recent workload and temperature trends to recommend early derating while retaining an independent hard-temperature trip.
Independent data unitone run/rest thermal episode with known duty, load and ambient context.
Closest misleading casea harmless short temperature rise versus a sustained heat-accumulation trend.
Definition of successStudents must warn before the hard limit under hidden duty while avoiding needless derating during recoverable transients.
Visual system blueprint
Physical processMotor thermal duty cycleGenerate labelled, safe and repeatable conditions.
Observemotor/driver and ambient temperature, current, PWMPreserve units, timestamps, run identity and signal quality.
H753 responsibilityControl and protectoperate the motor safely, apply absolute current/temperature limits and record duty-history windows.
Host intelligenceLearn the distinctionforecast temperature/risk or classify whether continued duty is safe.
Bounded outcomeNORMAL_DUTY · DERATE_LEVEL_1 · DERATE_LEVEL_2 · COOL_DOWN · STOPMCU validates, acknowledges and may refuse the request.
Recommended build journey
Make the process repeatableAssemble the H753-M + H753-S rig with safely placed temperature sensing; define reference and target conditions before collecting data.
Prove deterministic firmwareOperate the motor safely, apply absolute current/temperature limits and record duty-history windows. Demonstrate every hard limit before connecting ML.
Build trustworthy trialsTreat one run/rest thermal episode with known duty, load and ambient context as independent; calibrate, label and split by run/session.
Beat a real baselineCompare present-temperature threshold or constant-slope forecast with two syllabus-approved classical models.
Close and challenge the loopReturn only the applicable subset of NORMAL_DUTY · DERATE_LEVEL_1 · DERATE_LEVEL_2 · COOL_DOWN · STOP; test the target, nearest confuser, stale command and host loss.
Definition of done
Firmware controls safely before, during and after host connection.
Held-out results report forecast MAE/RMSE or risk recall, early-warning time and unnecessary-derate rate.
Portfolio shows measured and forecast temperature with warning, derate and hard-limit times and one honest failure case.
Problem-specific evidence at the common reviews
R1 · Design
Set safe temperature/current limits, horizon, profiles, heating/cooling protocol and success measures.
R2 · Embedded
Demonstrate calibrated temperature/current acquisition, PWM control and independent thermal trip.
R3 · Data
Provide heating/cooling runs with run IDs, horizon label generation and threshold baseline.
R4 · ML
Show regression/classification performance, lead time, false derates and operating-condition errors.
R5 · Integration
Integrate derating/cooldown, then test sudden load, sensor disconnect and host loss.
Final
Handle an unseen duty sequence while keeping temperature inside the limit and quantifying avoided downtime.
Portfolio/Kaggle outcome
Kaggle story: ‘Early Thermal Risk Prediction for an STM32 Motor Drive’ with trial-level groups, horizon labels, threshold baseline, warning-lead-time plots and a comparison of safety versus lost throughput.
Industry alignment and validation basis
ThermoDrive: external references and required evidence
The listed sources establish relevance, test discipline and implementation precedent. They do not modify the common syllabus boundary, safety rules or 100-mark assessment rubric.
Family implementation profile
Variant availability: 1 standard assignment(s); 9 organiser-supported assignment(s).
Public evidence: reproducible firmware, protocol, dataset, notebook/model, test report and demonstration video.
What the external benchmark confirms
The problem has a recognisable industrial or challenge analogue, a measurable data task, a defensible embedded implementation and a safe operational decision. Every one of its ten variants is mapped separately below.
Condition before team allocation
Provide seed thermal histories and a validated temperature-placement guide; 24 hours is too short to create every heat-accumulation regime live.
Combine sensor measurements and system knowledge to build condition indicators, detect faults and support predictive-maintenance decisions.
Start with an engineering baseline, justify features physically, validate on held-out operating conditions and connect inference to a maintenance action.
Open the 10 fully elaborated student variant briefs
Choose only the variant allocated to your team. Read it together with the parent problem above: the card expands the experimental delta, while every hardware, safety, integration and review requirement of the family remains active.
Observemotor/driver and ambient temperature, current, PWM, speed/load,…
LearnHorizon temperature regression.
DecideNORMAL_DUTY, DERATE_LEVEL_1, DERATE_LEVEL_2, COOL_DOWN or STOP
Proveforecast MAE/RMSE or risk recall, early-warning time and…
Variant equipment · EQ-06-01
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensequadrature encoder/tachometer; 0–3.3 V conditioned current-sense channel; cal…
Actuate6–12 V low-torque geared DC motor with encoder; 3.3-V-logic H-bridge rated ab…
Fixtureguarded conveyor/wheel load fixture; card of repeatable BURST/IDLE sequences…
Protectcurrent-limited 6–12 V supply sized for the motor and cooling fan; separately…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser thermal-history dataset spanning duty and rest cycles
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Only self-heating or a faculty-approved low-voltage heat source may be used; ML may reduce demand only. Verify the complete EQ-06-01 manifest before data collection.
1 · Scenario and student challenge
Predict risk under bursty load/idle cycles. In plain language, adapt ThermoDrive — Predictive Thermal Derating Supervisor so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Captures realistic intermittent factory duty.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M + H753-S temperature channels + the named safe mechanical/condition fixture. Begin with the H753-M + H753-S rig with safely placed temperature sensing and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record motor/driver and ambient temperature, current, PWM, speed/load, run/rest duration and local trip flags. Treat one run/rest thermal episode with known duty, load and ambient context as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Horizon temperature regression. First implement the parent baseline—present-temperature threshold or constant-slope forecast—and then compare two algorithms from the faculty-issued ML whitelist. Report MAE and RMSE on whole held-out runs, show predicted-versus-measured values, and inspect error by operating condition. If the target is converted to a safe/unsafe decision, also report missed-unsafe and unnecessary-conservative actions. Produce a predicted-versus-measured plot with residuals by operating condition.
5 · Embedded integration and safe response
The host may return only NORMAL_DUTY, DERATE_LEVEL_1, DERATE_LEVEL_2, COOL_DOWN or STOP, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a harmless short temperature rise versus a sustained heat-accumulation trend. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 06.01 — Conveyor-Motor Thermal Supervisor”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M + H753-S temperature channels + the named safe mechanical/condition fixtureregression/outcomerun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P06 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Conveyor-Motor Thermal Supervisor is a syllabus-scaled physical analogue of the need evidenced by IU04 · OtoSense Smart Motor Sensor: Predict risk under bursty load/idle cycles. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needMonitor electric motors continuously, learn normal operating behaviour and provide alerts for condition-based maintenance decisions.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Evaluate detection, diagnosis and actionable response separately; relate every indicator to a physical failure mechanism.
Advanced sensors and embedded AI described in the brief are contextual, not syllabus requirements.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationProvide seed thermal histories and a validated temperature-placement guide; 24 hours is too short to create every heat-accumulation regime live.
Variant 06.02
Cooling-Fan Motor Derater
Engineering purpose: Combines cooling need with actuator self-heating.
ChangeDetect thermal risk when fan load is restricted.
Observemotor/driver and ambient temperature, current, PWM, speed/load,…
LearnRisk classification using current and temperature slope.
DecideNORMAL_DUTY, DERATE_LEVEL_1, DERATE_LEVEL_2, COOL_DOWN or STOP
Proveforecast MAE/RMSE or risk recall, early-warning time and…
Variant equipment · EQ-06-02
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensequadrature encoder/tachometer; 0–3.3 V conditioned current-sense channel; cal…
Actuate6–12 V low-torque geared DC motor with encoder; 3.3-V-logic H-bridge rated ab…
Fixtureshrouded fan/impeller stand; airflow restriction screens and tachometer/encod…
Protectcurrent-limited 6–12 V supply sized for the motor and cooling fan; separately…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser thermal-history dataset spanning duty and rest cycles
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Only self-heating or a faculty-approved low-voltage heat source may be used; ML may reduce demand only. Verify the complete EQ-06-02 manifest before data collection.
1 · Scenario and student challenge
Detect thermal risk when fan load is restricted. In plain language, adapt ThermoDrive — Predictive Thermal Derating Supervisor so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Combines cooling need with actuator self-heating.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M + H753-S temperature channels + the named safe mechanical/condition fixture. Begin with the H753-M + H753-S rig with safely placed temperature sensing and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record motor/driver and ambient temperature, current, PWM, speed/load, run/rest duration and local trip flags. Treat one run/rest thermal episode with known duty, load and ambient context as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Risk classification using current and temperature slope. First implement the parent baseline—present-temperature threshold or constant-slope forecast—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only NORMAL_DUTY, DERATE_LEVEL_1, DERATE_LEVEL_2, COOL_DOWN or STOP, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a harmless short temperature rise versus a sustained heat-accumulation trend. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 06.02 — Cooling-Fan Motor Derater”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M + H753-S temperature channels + the named safe mechanical/condition fixtureclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P06 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Cooling-Fan Motor Derater is a syllabus-scaled physical analogue of the need evidenced by IU04 · OtoSense Smart Motor Sensor: Detect thermal risk when fan load is restricted. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needMonitor electric motors continuously, learn normal operating behaviour and provide alerts for condition-based maintenance decisions.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Evaluate detection, diagnosis and actionable response separately; relate every indicator to a physical failure mechanism.
Advanced sensors and embedded AI described in the brief are contextual, not syllabus requirements.
Implementation modeOrganiser-supported assignmentMay be issued only after the named seed history, reference specimens, calibration set or controlled fixture is prepared.
Required organiser provisionComplete before team allocationProvide seed thermal histories and a validated temperature-placement guide; 24 hours is too short to create every heat-accumulation regime live.
Variant 06.03
Gate-Actuator Duty-Cycle Guard
Engineering purpose: Uses cycle history and cooldown time.
Observemotor/driver and ambient temperature, current, PWM, speed/load,…
LearnSafe/unsafe next-cycle classifier.
DecideNORMAL_DUTY, DERATE_LEVEL_1, DERATE_LEVEL_2, COOL_DOWN or STOP
Proveforecast MAE/RMSE or risk recall, early-warning time and…
Variant equipment · EQ-06-03
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensequadrature encoder/tachometer; 0–3.3 V conditioned current-sense channel; cal…
Actuate6–12 V low-torque geared DC motor with encoder; 3.3-V-logic H-bridge rated ab…
Fixturelow-force gate arm with two limits; automated/repeatable open-close cycle sch…
Protectcurrent-limited 6–12 V supply sized for the motor and cooling fan; separately…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser thermal-history dataset spanning duty and rest cycles
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Only self-heating or a faculty-approved low-voltage heat source may be used; ML may reduce demand only. Verify the complete EQ-06-03 manifest before data collection.
1 · Scenario and student challenge
Repeated opening/closing creates cumulative heat. In plain language, adapt ThermoDrive — Predictive Thermal Derating Supervisor so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Uses cycle history and cooldown time.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M + H753-S temperature channels + the named safe mechanical/condition fixture. Begin with the H753-M + H753-S rig with safely placed temperature sensing and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record motor/driver and ambient temperature, current, PWM, speed/load, run/rest duration and local trip flags. Treat one run/rest thermal episode with known duty, load and ambient context as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Safe/unsafe next-cycle classifier. First implement the parent baseline—present-temperature threshold or constant-slope forecast—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only NORMAL_DUTY, DERATE_LEVEL_1, DERATE_LEVEL_2, COOL_DOWN or STOP, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a harmless short temperature rise versus a sustained heat-accumulation trend. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 06.03 — Gate-Actuator Duty-Cycle Guard”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M + H753-S temperature channels + the named safe mechanical/condition fixtureclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P06 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Gate-Actuator Duty-Cycle Guard is a syllabus-scaled physical analogue of the need evidenced by IU04 · OtoSense Smart Motor Sensor: Repeated opening/closing creates cumulative heat. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needMonitor electric motors continuously, learn normal operating behaviour and provide alerts for condition-based maintenance decisions.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Evaluate detection, diagnosis and actionable response separately; relate every indicator to a physical failure mechanism.
Advanced sensors and embedded AI described in the brief are contextual, not syllabus requirements.
Implementation modeOrganiser-supported assignmentMay be issued only after the named seed history, reference specimens, calibration set or controlled fixture is prepared.
Required organiser provisionComplete before team allocationProvide seed thermal histories and a validated temperature-placement guide; 24 hours is too short to create every heat-accumulation regime live.
Variant 06.04
Mini-Hoist Thermal Guard
Engineering purpose: Introduces asymmetric work profiles.
ChangeDifferentiate lifting and lowering thermal demand.
Observemotor/driver and ambient temperature, current, PWM, speed/load,…
LearnDirection-aware regression.
DecideNORMAL_DUTY, DERATE_LEVEL_1, DERATE_LEVEL_2, COOL_DOWN or STOP
Proveforecast MAE/RMSE or risk recall, early-warning time and…
Variant equipment · EQ-06-04
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensequadrature encoder/tachometer; 0–3.3 V conditioned current-sense channel; cal…
Actuate6–12 V low-torque geared DC motor with encoder; 3.3-V-logic H-bridge rated ab…
Fixtureguarded mini-hoist with catch tray; safe masses and top/bottom travel switches
Protectcurrent-limited 6–12 V supply sized for the motor and cooling fan; separately…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser thermal-history dataset spanning duty and rest cycles
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Only self-heating or a faculty-approved low-voltage heat source may be used; ML may reduce demand only. Verify the complete EQ-06-04 manifest before data collection.
1 · Scenario and student challenge
Differentiate lifting and lowering thermal demand. In plain language, adapt ThermoDrive — Predictive Thermal Derating Supervisor so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Introduces asymmetric work profiles.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M + H753-S temperature channels + the named safe mechanical/condition fixture. Begin with the H753-M + H753-S rig with safely placed temperature sensing and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record motor/driver and ambient temperature, current, PWM, speed/load, run/rest duration and local trip flags. Treat one run/rest thermal episode with known duty, load and ambient context as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Direction-aware regression. First implement the parent baseline—present-temperature threshold or constant-slope forecast—and then compare two algorithms from the faculty-issued ML whitelist. Report MAE and RMSE on whole held-out runs, show predicted-versus-measured values, and inspect error by operating condition. If the target is converted to a safe/unsafe decision, also report missed-unsafe and unnecessary-conservative actions. Produce a predicted-versus-measured plot with residuals by operating condition.
5 · Embedded integration and safe response
The host may return only NORMAL_DUTY, DERATE_LEVEL_1, DERATE_LEVEL_2, COOL_DOWN or STOP, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a harmless short temperature rise versus a sustained heat-accumulation trend. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 06.04 — Mini-Hoist Thermal Guard”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M + H753-S temperature channels + the named safe mechanical/condition fixtureregression/outcomerun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P06 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Mini-Hoist Thermal Guard is a syllabus-scaled physical analogue of the need evidenced by IU04 · OtoSense Smart Motor Sensor: Differentiate lifting and lowering thermal demand. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needMonitor electric motors continuously, learn normal operating behaviour and provide alerts for condition-based maintenance decisions.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Evaluate detection, diagnosis and actionable response separately; relate every indicator to a physical failure mechanism.
Advanced sensors and embedded AI described in the brief are contextual, not syllabus requirements.
Implementation modeOrganiser-supported assignmentMay be issued only after the named seed history, reference specimens, calibration set or controlled fixture is prepared.
Required organiser provisionComplete before team allocationProvide seed thermal histories and a validated temperature-placement guide; 24 hours is too short to create every heat-accumulation regime live.
Variant 06.05
Robotic-Joint Rest Scheduler
Engineering purpose: Converts forecast into bounded scheduling.
ChangePredict whether another move is safe or a rest is needed.
Observemotor/driver and ambient temperature, current, PWM, speed/load,…
LearnBinary next-action model.
DecideNORMAL_DUTY, DERATE_LEVEL_1, DERATE_LEVEL_2, COOL_DOWN or STOP
Proveforecast MAE/RMSE or risk recall, early-warning time and…
Variant equipment · EQ-06-05
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensequadrature encoder/tachometer; 0–3.3 V conditioned current-sense channel; cal…
Actuate6–12 V low-torque geared DC motor with encoder; 3.3-V-logic H-bridge rated ab…
Fixturelow-force rotary arm/joint with marked positions; small calibrated payloads a…
Protectcurrent-limited 6–12 V supply sized for the motor and cooling fan; separately…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser thermal-history dataset spanning duty and rest cycles
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Only self-heating or a faculty-approved low-voltage heat source may be used; ML may reduce demand only. Verify the complete EQ-06-05 manifest before data collection.
1 · Scenario and student challenge
Predict whether another move is safe or a rest is needed. In plain language, adapt ThermoDrive — Predictive Thermal Derating Supervisor so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Converts forecast into bounded scheduling.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M + H753-S temperature channels + the named safe mechanical/condition fixture. Begin with the H753-M + H753-S rig with safely placed temperature sensing and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record motor/driver and ambient temperature, current, PWM, speed/load, run/rest duration and local trip flags. Treat one run/rest thermal episode with known duty, load and ambient context as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Binary next-action model. First implement the parent baseline—present-temperature threshold or constant-slope forecast—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a measured and forecast temperature with warning, derate and hard-limit times.
5 · Embedded integration and safe response
The host may return only NORMAL_DUTY, DERATE_LEVEL_1, DERATE_LEVEL_2, COOL_DOWN or STOP, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a harmless short temperature rise versus a sustained heat-accumulation trend. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 06.05 — Robotic-Joint Rest Scheduler”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M + H753-S temperature channels + the named safe mechanical/condition fixtureclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P06 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Robotic-Joint Rest Scheduler is a syllabus-scaled physical analogue of the need evidenced by IU04 · OtoSense Smart Motor Sensor: Predict whether another move is safe or a rest is needed. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needMonitor electric motors continuously, learn normal operating behaviour and provide alerts for condition-based maintenance decisions.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Evaluate detection, diagnosis and actionable response separately; relate every indicator to a physical failure mechanism.
Advanced sensors and embedded AI described in the brief are contextual, not syllabus requirements.
Implementation modeOrganiser-supported assignmentMay be issued only after the named seed history, reference specimens, calibration set or controlled fixture is prepared.
Required organiser provisionComplete before team allocationProvide seed thermal histories and a validated temperature-placement guide; 24 hours is too short to create every heat-accumulation regime live.
Variant 06.06
Feeder Continuous-Duty Derater
Engineering purpose: Balances throughput and thermal safety.
ChangeChoose among normal and reduced feed speeds during long runs.
Observemotor/driver and ambient temperature, current, PWM, speed/load,…
LearnMulticlass risk/profile recommendation.
DecideNORMAL_DUTY, DERATE_LEVEL_1, DERATE_LEVEL_2, COOL_DOWN or STOP
Proveforecast MAE/RMSE or risk recall, early-warning time and…
Variant equipment · EQ-06-06
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensequadrature encoder/tachometer; 0–3.3 V conditioned current-sense channel; cal…
Actuate6–12 V low-torque geared DC motor with encoder; 3.3-V-logic H-bridge rated ab…
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser thermal-history dataset spanning duty and rest cycles
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Only self-heating or a faculty-approved low-voltage heat source may be used; ML may reduce demand only. Verify the complete EQ-06-06 manifest before data collection.
1 · Scenario and student challenge
Choose among normal and reduced feed speeds during long runs. In plain language, adapt ThermoDrive — Predictive Thermal Derating Supervisor so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Balances throughput and thermal safety.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M + H753-S temperature channels + the named safe mechanical/condition fixture. Begin with the H753-M + H753-S rig with safely placed temperature sensing and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record motor/driver and ambient temperature, current, PWM, speed/load, run/rest duration and local trip flags. Treat one run/rest thermal episode with known duty, load and ambient context as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Multiclass risk/profile recommendation. First implement the parent baseline—present-temperature threshold or constant-slope forecast—and then compare two algorithms from the faculty-issued ML whitelist. Report correct/feasible selection rate, constraint violations and improvement over the fixed policy. A choice is wrong if it violates a declared current, timing, thermal or control-quality bound even when it is fast. Produce a candidate-outcome/constraint table showing why the selected option is feasible.
5 · Embedded integration and safe response
The host may return only NORMAL_DUTY, DERATE_LEVEL_1, DERATE_LEVEL_2, COOL_DOWN or STOP, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a harmless short temperature rise versus a sustained heat-accumulation trend. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 06.06 — Feeder Continuous-Duty Derater”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M + H753-S temperature channels + the named safe mechanical/condition fixtureclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P06 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Feeder Continuous-Duty Derater is a syllabus-scaled physical analogue of the need evidenced by IU04 · OtoSense Smart Motor Sensor: Choose among normal and reduced feed speeds during long runs. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needMonitor electric motors continuously, learn normal operating behaviour and provide alerts for condition-based maintenance decisions.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Evaluate detection, diagnosis and actionable response separately; relate every indicator to a physical failure mechanism.
Advanced sensors and embedded AI described in the brief are contextual, not syllabus requirements.
Implementation modeOrganiser-supported assignmentMay be issued only after the named seed history, reference specimens, calibration set or controlled fixture is prepared.
Required organiser provisionComplete before team allocationProvide seed thermal histories and a validated temperature-placement guide; 24 hours is too short to create every heat-accumulation regime live.
Variant 06.07
Start-Stop Thermal Accumulation Model
Engineering purpose: Models a distinct heating mechanism.
ChangeFocus on many short starts rather than steady motion.
Observemotor/driver and ambient temperature, current, PWM, speed/load,…
LearnRegression using recent-start count and current integral.
DecideNORMAL_DUTY, DERATE_LEVEL_1, DERATE_LEVEL_2, COOL_DOWN or STOP
Proveforecast MAE/RMSE or risk recall, early-warning time and…
Variant equipment · EQ-06-07
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensequadrature encoder/tachometer; 0–3.3 V conditioned current-sense channel; cal…
Actuate6–12 V low-torque geared DC motor with encoder; 3.3-V-logic H-bridge rated ab…
Fixturestartup-test fixture; repeated-start schedule, cooling fan and mandatory cool…
Protectcurrent-limited 6–12 V supply sized for the motor and cooling fan; separately…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser thermal-history dataset spanning duty and rest cycles
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Only self-heating or a faculty-approved low-voltage heat source may be used; ML may reduce demand only. Verify the complete EQ-06-07 manifest before data collection.
1 · Scenario and student challenge
Focus on many short starts rather than steady motion. In plain language, adapt ThermoDrive — Predictive Thermal Derating Supervisor so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Models a distinct heating mechanism.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M + H753-S temperature channels + the named safe mechanical/condition fixture. Begin with the H753-M + H753-S rig with safely placed temperature sensing and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record motor/driver and ambient temperature, current, PWM, speed/load, run/rest duration and local trip flags. Treat one run/rest thermal episode with known duty, load and ambient context as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Regression using recent-start count and current integral. First implement the parent baseline—present-temperature threshold or constant-slope forecast—and then compare two algorithms from the faculty-issued ML whitelist. Report MAE and RMSE on whole held-out runs, show predicted-versus-measured values, and inspect error by operating condition. If the target is converted to a safe/unsafe decision, also report missed-unsafe and unnecessary-conservative actions. Produce a predicted-versus-measured plot with residuals by operating condition.
5 · Embedded integration and safe response
The host may return only NORMAL_DUTY, DERATE_LEVEL_1, DERATE_LEVEL_2, COOL_DOWN or STOP, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a harmless short temperature rise versus a sustained heat-accumulation trend. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 06.07 — Start-Stop Thermal Accumulation Model”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M + H753-S temperature channels + the named safe mechanical/condition fixtureregression/outcomerun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P06 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Start-Stop Thermal Accumulation Model is a syllabus-scaled physical analogue of the need evidenced by IU04 · OtoSense Smart Motor Sensor: Focus on many short starts rather than steady motion. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needMonitor electric motors continuously, learn normal operating behaviour and provide alerts for condition-based maintenance decisions.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Evaluate detection, diagnosis and actionable response separately; relate every indicator to a physical failure mechanism.
Advanced sensors and embedded AI described in the brief are contextual, not syllabus requirements.
Implementation modeOrganiser-supported assignmentMay be issued only after the named seed history, reference specimens, calibration set or controlled fixture is prepared.
Required organiser provisionComplete before team allocationProvide seed thermal histories and a validated temperature-placement guide; 24 hours is too short to create every heat-accumulation regime live.
Variant 06.08
Driver-versus-Motor Heat Proxy
Engineering purpose: Adds diagnostic value without advanced hardware.
ChangeUse two temperature locations where the kit permits, or one sensor…
Observemotor/driver and ambient temperature, current, PWM, speed/load,…
LearnClassification of likely heat source.
DecideNORMAL_DUTY, DERATE_LEVEL_1, DERATE_LEVEL_2, COOL_DOWN or STOP
Proveforecast MAE/RMSE or risk recall, early-warning time and…
Variant equipment · EQ-06-08
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Senseencoder/tachometer; 0–3.3 V current channel; LM35-class channels: motor, driv…
Actuate6–12 V low-torque geared DC motor with encoder; 3.3-V-logic H-bridge rated ab…
Fixturestandard motor rig with two distinct temperature probe mounts: motor body and…
Protectcurrent-limited 6–12 V supply sized for the motor and cooling fan; separately…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser thermal-history dataset spanning duty and rest cycles
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Only self-heating or a faculty-approved low-voltage heat source may be used; ML may reduce demand only. Verify the complete EQ-06-08 manifest before data collection.
1 · Scenario and student challenge
Use two temperature locations where the kit permits, or one sensor plus current proxy. In plain language, adapt ThermoDrive — Predictive Thermal Derating Supervisor so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Adds diagnostic value without advanced hardware.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M + H753-S temperature channels + the named safe mechanical/condition fixture. Begin with the H753-M + H753-S rig with safely placed temperature sensing and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record motor/driver and ambient temperature, current, PWM, speed/load, run/rest duration and local trip flags. Treat one run/rest thermal episode with known duty, load and ambient context as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Classification of likely heat source. First implement the parent baseline—present-temperature threshold or constant-slope forecast—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only NORMAL_DUTY, DERATE_LEVEL_1, DERATE_LEVEL_2, COOL_DOWN or STOP, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a harmless short temperature rise versus a sustained heat-accumulation trend. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 06.08 — Driver-versus-Motor Heat Proxy”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M + H753-S temperature channels + the named safe mechanical/condition fixtureclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P06 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Driver-versus-Motor Heat Proxy is a syllabus-scaled physical analogue of the need evidenced by IU04 · OtoSense Smart Motor Sensor: Use two temperature locations where the kit permits, or one sensor plus current proxy. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needMonitor electric motors continuously, learn normal operating behaviour and provide alerts for condition-based maintenance decisions.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Evaluate detection, diagnosis and actionable response separately; relate every indicator to a physical failure mechanism.
Advanced sensors and embedded AI described in the brief are contextual, not syllabus requirements.
Implementation modeOrganiser-supported assignmentMay be issued only after the named seed history, reference specimens, calibration set or controlled fixture is prepared.
Required organiser provisionComplete before team allocationProvide seed thermal histories and a validated temperature-placement guide; 24 hours is too short to create every heat-accumulation regime live.
Variant 06.09
Ambient-Conditioned Derating
Engineering purpose: Tests robustness across room conditions.
ChangeUse initial LM35 temperature as ambient/start state across trials.
Observemotor/driver and ambient temperature, current, PWM, speed/load,…
LearnTemperature-conditioned model.
DecideNORMAL_DUTY, DERATE_LEVEL_1, DERATE_LEVEL_2, COOL_DOWN or STOP
Proveforecast MAE/RMSE or risk recall, early-warning time and…
Variant equipment · EQ-06-09
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensequadrature encoder/tachometer; 0–3.3 V conditioned current-sense channel; cal…
Actuate6–12 V low-torque geared DC motor with encoder; 3.3-V-logic H-bridge rated ab…
Fixturestandard motor rig with controlled starting-environment box; ambient referenc…
Protectcurrent-limited 6–12 V supply sized for the motor and cooling fan; separately…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser thermal-history dataset spanning duty and rest cycles
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Only self-heating or a faculty-approved low-voltage heat source may be used; ML may reduce demand only. Verify the complete EQ-06-09 manifest before data collection.
1 · Scenario and student challenge
Use initial LM35 temperature as ambient/start state across trials. In plain language, adapt ThermoDrive — Predictive Thermal Derating Supervisor so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Tests robustness across room conditions.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M + H753-S temperature channels + the named safe mechanical/condition fixture. Begin with the H753-M + H753-S rig with safely placed temperature sensing and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record motor/driver and ambient temperature, current, PWM, speed/load, run/rest duration and local trip flags. Treat one run/rest thermal episode with known duty, load and ambient context as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Temperature-conditioned model. First implement the parent baseline—present-temperature threshold or constant-slope forecast—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a measured and forecast temperature with warning, derate and hard-limit times.
5 · Embedded integration and safe response
The host may return only NORMAL_DUTY, DERATE_LEVEL_1, DERATE_LEVEL_2, COOL_DOWN or STOP, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a harmless short temperature rise versus a sustained heat-accumulation trend. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 06.09 — Ambient-Conditioned Derating”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M + H753-S temperature channels + the named safe mechanical/condition fixtureclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P06 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Ambient-Conditioned Derating is a syllabus-scaled physical analogue of the need evidenced by IU04 · OtoSense Smart Motor Sensor: Use initial LM35 temperature as ambient/start state across trials. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needMonitor electric motors continuously, learn normal operating behaviour and provide alerts for condition-based maintenance decisions.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Evaluate detection, diagnosis and actionable response separately; relate every indicator to a physical failure mechanism.
Advanced sensors and embedded AI described in the brief are contextual, not syllabus requirements.
Implementation modeOrganiser-supported assignmentMay be issued only after the named seed history, reference specimens, calibration set or controlled fixture is prepared.
Required organiser provisionComplete before team allocationProvide seed thermal histories and a validated temperature-placement guide; 24 hours is too short to create every heat-accumulation regime live.
ChangeAfter stop, estimate time until safe restart.
Observemotor/driver and ambient temperature, current, PWM, speed/load,…
LearnCooling-time regression.
DecideNORMAL_DUTY, DERATE_LEVEL_1, DERATE_LEVEL_2, COOL_DOWN or STOP
Proveforecast MAE/RMSE or risk recall, early-warning time and…
Variant equipment · EQ-06-10
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensequadrature encoder/tachometer; 0–3.3 V conditioned current-sense channel; cal…
Actuate6–12 V low-torque geared DC motor with encoder; 3.3-V-logic H-bridge rated ab…
Fixturemotor cool-down stand; shrouded low-voltage fan with OFF/LOW/HIGH cooling pro…
Protectcurrent-limited 6–12 V supply sized for the motor and cooling fan; separately…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser thermal-history dataset spanning duty and rest cycles
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Only self-heating or a faculty-approved low-voltage heat source may be used; ML may reduce demand only. Verify the complete EQ-06-10 manifest before data collection.
1 · Scenario and student challenge
After stop, estimate time until safe restart. In plain language, adapt ThermoDrive — Predictive Thermal Derating Supervisor so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Adds maintenance/operations usefulness.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M + H753-S temperature channels + the named safe mechanical/condition fixture. Begin with the H753-M + H753-S rig with safely placed temperature sensing and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record motor/driver and ambient temperature, current, PWM, speed/load, run/rest duration and local trip flags. Treat one run/rest thermal episode with known duty, load and ambient context as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Cooling-time regression. First implement the parent baseline—present-temperature threshold or constant-slope forecast—and then compare two algorithms from the faculty-issued ML whitelist. Report MAE and RMSE on whole held-out runs, show predicted-versus-measured values, and inspect error by operating condition. If the target is converted to a safe/unsafe decision, also report missed-unsafe and unnecessary-conservative actions. Produce a predicted-versus-measured plot with residuals by operating condition.
5 · Embedded integration and safe response
The host may return only NORMAL_DUTY, DERATE_LEVEL_1, DERATE_LEVEL_2, COOL_DOWN or STOP, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a harmless short temperature rise versus a sustained heat-accumulation trend. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 06.10 — Thermal-Recovery Time Predictor”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M + H753-S temperature channels + the named safe mechanical/condition fixtureregression/outcomerun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P06 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Thermal-Recovery Time Predictor is a syllabus-scaled physical analogue of the need evidenced by IU04 · OtoSense Smart Motor Sensor: After stop, estimate time until safe restart. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needMonitor electric motors continuously, learn normal operating behaviour and provide alerts for condition-based maintenance decisions.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Evaluate detection, diagnosis and actionable response separately; relate every indicator to a physical failure mechanism.
Advanced sensors and embedded AI described in the brief are contextual, not syllabus requirements.
Implementation modeOrganiser-supported assignmentMay be issued only after the named seed history, reference specimens, calibration set or controlled fixture is prepared.
Required organiser provisionComplete before team allocationProvide seed thermal histories and a validated temperature-placement guide; 24 hours is too short to create every heat-accumulation regime live.
Problem 07 · 10 variants · Motion, drive and actuator intelligence
Assigned Faculty Master pair for P07: one nominated ESD Faculty Master and one nominated ML Faculty Master shall jointly master this parent problem and variants V1-V10. The ESD Master owns hardware, firmware, control, communication and safety verification; the ML Master owns data, baselines, models, validation and bounded decision-policy verification. Together they teach and guide ten teams (one for each variant and up to 40 students), supervise five teams in Wave A and five in Wave B, witness integration and sign every final evaluation.
The problem
Fast motion, low current, low overshoot and low energy cannot always be achieved simultaneously. Students often tune only for speed or visual smoothness. This problem asks them to build a measurable profile-selection system that predicts the outcome of approved control profiles and chooses the fastest one satisfying current, temperature, error and energy-proxy constraints.
Smart embedded product to build
Build a NUCLEO-H753ZI constrained motion-profile selector with three to five faculty-approved profiles differing in speed limit, PWM ramp or gain set. The board executes only stored profiles and records context, feedback, PWM, conditioned current, temperature and completion outcome. The host predicts time, peak current, tracking quality and current-integral energy proxy for each candidate, rejects predicted constraint violators and recommends the fastest remaining profile.
NUCLEO-H753ZI realization and issued pack
NUCLEO-H753ZI / MB1364E with H753-M pack
encoder motor or servo, approved driver and external fused supply
fixed PID/rule loop with three to five preloaded speed/ramp/gain profiles
ADC current and optional temperature; timer position/speed feedback
MCU or host computes completion, peak-current, error and current-integral proxies
USART3 VCP recommendation/acknowledgement; LED/display shows selected and applied profile
no model-generated PWM, trajectory or gain value
Intelligence to incorporate
Use multi-output regression as separate simple regressors, or classification of profile feasibility followed by rule-based ranking. Compare against always-fast, always-safe and fixed-profile baselines. Report time saved, constraint violations, current-integral/energy proxy and model generalisation across loads/setpoints.
Permitted output/action set
PROFILE_ID · CONSERVATIVE_DEFAULT
Canonical family command contract: every parent brief, variant, host message and MCU acknowledgement for P07 shall use these exact identifiers. A variant may use only the applicable subset; it shall not introduce a synonym.
Core problem equipment · EQ-07-CORE
Complete equipment required for one core-problem team
Standalone family BOM. This list supports the parent problem itself. An allocated variant uses its own complete table later in this card. A component mentioned again in the fixture description is the same mounted unit, not another copy.
4 students; 3 by approved exception1 H753 board1 team laptopquantities per team
Controller1 H753 board + 1 laptop
Sensequadrature encoder or external position feedback channel; conditioned 0–3.3 V…
Actuatelow-torque geared DC motor with encoder; matching 3.3-V-logic H-bridge rated…
Fixtureguarded motion fixture with marked endpoints and repeatable load attachment;…
Protectcurrent-limited actuator supply; inline fuse plus spare fuses; latching E-sto…
System block
Complete quantity and equipment per team
Purpose / acceptance condition
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Release-to-team condition: The model selects only a stored profile; the board rejects arbitrary PWM, trajectory or gain values. The organiser signs the electrical, mechanical and communication acceptance checklist before H0:00.
Not duplicated inside the kit: supervised rework tools and the oscilloscope/logic-analyser station are shared at the ratio stated above. Everything else in this table is issued to, reserved for, or digitally assigned to this team.
Controlled self-learning extension
Recommended Produce a measured Pareto plot of time, current integral and tracking quality, then prove that the selected profile is feasible before optimizing it. No new optimiser or reinforcement learning is required.
System safety and non-negotiable boundary
The MCU accepts only profile IDs and enforces all current, travel, speed and temperature limits. No model-generated raw gains or PWM. If no profile is confidently feasible, choose the conservative profile or refuse motion.
Student interpretation — what this challenge really asks
Several approved motion profiles can complete the same task, but the fastest may consume more energy or violate overshoot/current limits. Students learn the outcomes and select the best feasible profile—not invent a trajectory.
Independent data unitone profile execution for one declared movement and context.
Closest misleading casea nominally fast profile that appears attractive but violates a hidden current or control-quality constraint.
Definition of successStudents must select the fastest or lowest-energy feasible profile on a hidden context without any safety violation.
Visual system blueprint
Physical processChoice among approved motion profilesGenerate labelled, safe and repeatable conditions.
Observeprofile ID, move distance, directionPreserve units, timestamps, run identity and signal quality.
H753 responsibilityControl and protectstore and execute approved profiles, reject illegal IDs and calculate trustworthy performance summaries.
Host intelligenceLearn the distinctionpredict time, energy/current and quality constraints for each candidate profile.
Bounded outcomePROFILE_ID · CONSERVATIVE_DEFAULTMCU validates, acknowledges and may refuse the request.
Recommended build journey
Make the process repeatableAssemble the H753-M rig with three or more faculty-approved profiles; define reference and target conditions before collecting data.
Prove deterministic firmwareStore and execute approved profiles, reject illegal ids and calculate trustworthy performance summaries. Demonstrate every hard limit before connecting ML.
Build trustworthy trialsTreat one profile execution for one declared movement and context as independent; calibrate, label and split by run/session.
Beat a real baselineCompare always use the conservative profile or a hand-written load-to-profile rule with two syllabus-approved classical models.
Close and challenge the loopReturn only the applicable subset of PROFILE_ID · CONSERVATIVE_DEFAULT; test the target, nearest confuser, stale command and host loss.
Definition of done
Firmware controls safely before, during and after host connection.
Portfolio shows Pareto plot of time versus energy with infeasible trials clearly marked and one honest failure case.
Problem-specific evidence at the common reviews
R1 · Design
Define profiles, constraints, energy proxy, test matrix and profile-selection rule.
R2 · Embedded
Demonstrate identical commanded moves under all profiles with logged outcomes and MCU limits.
R3 · Data
Submit trial matrix, baseline policies and outcome-quality checks.
R4 · ML
Predict profile feasibility/outcomes and quantify constraint violations on held-out runs.
R5 · Integration
Select profiles live, reject illegal/stale commands and pass a hidden load/setpoint test.
Final
Complete a blind sequence faster than the conservative baseline with zero declared safety violations.
Portfolio/Kaggle outcome
Kaggle dataset: one row per motion trial with context, profile and measured outcomes. Notebook should implement feasibility prediction, constrained ranking, Pareto-style visualisation and an ablation showing why current or temperature information matters.
Industry alignment and validation basis
EcoMotion: external references and required evidence
The listed sources establish relevance, test discipline and implementation precedent. They do not modify the common syllabus boundary, safety rules or 100-mark assessment rubric.
Family implementation profile
Variant availability: 10 standard assignment(s); 0 organiser-supported assignment(s).
Public evidence: reproducible firmware, protocol, dataset, notebook/model, test report and demonstration video.
What the external benchmark confirms
The problem has a recognisable industrial or challenge analogue, a measurable data task, a defensible embedded implementation and a safe operational decision. Every one of its ten variants is mapped separately below.
Condition before team allocation
Publish three or four safe profiles and a formal feasibility rule; models may rank only candidates that pass MCU limits.
Combine process state, velocity, torque, current, voltage and timing context for conveyor anomaly detection, diagnosis and productivity analysis.
Condition inference on process phase; preserve physical context; test root-cause discrimination and subtask timing rather than a context-free threshold.
Frame cyber-physical systems as integrations of logical, physical and human components with concerns including trustworthiness and interoperability.
Evaluate the complete sense–decide–act system, its interfaces and failure behaviour—not a disconnected model or dashboard.
Open the 10 fully elaborated student variant briefs
Choose only the variant allocated to your team. Read it together with the parent problem above: the card expands the experimental delta, while every hardware, safety, integration and review requirement of the family remains active.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensequadrature encoder or external position feedback channel; conditioned 0–3.3 V…
Actuatelow-torque geared DC motor with encoder; matching 3.3-V-logic H-bridge rated…
Fixtureguarded pick-and-place arm/carriage with two endpoints; calibrated payloads a…
Protectcurrent-limited actuator supply; inline fuse plus spare fuses; latching E-sto…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: The model selects only a stored profile; the board rejects arbitrary PWM, trajectory or gain values. Verify the complete EQ-07-01 manifest before data collection.
1 · Scenario and student challenge
Choose profile by move distance and payload class. In plain language, adapt EcoMotion — Energy–Time Trade-off Profile Optimiser so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Strong industrial automation portfolio case.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M + the named safe mechanical/condition fixture. Begin with the H753-M rig with three or more faculty-approved profiles and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record profile ID, move distance, direction, load proxy, response time, overshoot, PWM, current and energy proxy. Treat one profile execution for one declared movement and context as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Feasibility classification plus time regression. First implement the parent baseline—always use the conservative profile or a hand-written load-to-profile rule—and then compare two algorithms from the faculty-issued ML whitelist. Report MAE and RMSE on whole held-out runs, show predicted-versus-measured values, and inspect error by operating condition. If the target is converted to a safe/unsafe decision, also report missed-unsafe and unnecessary-conservative actions. Produce a predicted-versus-measured plot with residuals by operating condition.
5 · Embedded integration and safe response
The host may return only one approved PROFILE_ID or CONSERVATIVE_DEFAULT, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a nominally fast profile that appears attractive but violates a hidden current or control-quality constraint. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 07.01 — Pick-and-Place Axis Optimiser”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M + the named safe mechanical/condition fixtureregression/outcomerun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P07 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Pick-and-Place Axis Optimiser is a syllabus-scaled physical analogue of the need evidenced by IU03 · Gain Scheduling: Choose profile by move distance and payload class. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needTune controllers at multiple design points and validate scheduled performance across the full operating range.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Condition inference on process phase; preserve physical context; test root-cause discrimination and subtask timing rather than a context-free threshold.
The H753 cell uses a smaller signal set and safe injected resistance while retaining the context-sensitive evaluation idea.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationPublish three or four safe profiles and a formal feasibility rule; models may rank only candidates that pass MCU limits.
Variant 07.02
Smart Door Motion Optimiser
Engineering purpose: Adds comfort and safety constraints.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensequadrature encoder or external position feedback channel; conditioned 0–3.3 V…
Actuatelow-torque geared DC motor with encoder; matching 3.3-V-logic H-bridge rated…
Fixturelow-force door/gate arm; soft closing pad, end stops and 3–5 approved profiles
Protectcurrent-limited actuator supply; inline fuse plus spare fuses; latching E-sto…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: The model selects only a stored profile; the board rejects arbitrary PWM, trajectory or gain values. Verify the complete EQ-07-02 manifest before data collection.
1 · Scenario and student challenge
Balance close time, peak current and overshoot at the end position. In plain language, adapt EcoMotion — Energy–Time Trade-off Profile Optimiser so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Adds comfort and safety constraints.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M + the named safe mechanical/condition fixture. Begin with the H753-M rig with three or more faculty-approved profiles and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record profile ID, move distance, direction, load proxy, response time, overshoot, PWM, current and energy proxy. Treat one profile execution for one declared movement and context as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Profile outcome prediction. First implement the parent baseline—always use the conservative profile or a hand-written load-to-profile rule—and then compare two algorithms from the faculty-issued ML whitelist. Report MAE and RMSE on whole held-out runs, show predicted-versus-measured values, and inspect error by operating condition. If the target is converted to a safe/unsafe decision, also report missed-unsafe and unnecessary-conservative actions. Produce a predicted-versus-measured plot with residuals by operating condition.
5 · Embedded integration and safe response
The host may return only one approved PROFILE_ID or CONSERVATIVE_DEFAULT, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a nominally fast profile that appears attractive but violates a hidden current or control-quality constraint. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 07.02 — Smart Door Motion Optimiser”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M + the named safe mechanical/condition fixtureregression/outcomerun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P07 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Smart Door Motion Optimiser is a syllabus-scaled physical analogue of the need evidenced by IU03 · Gain Scheduling: Balance close time, peak current and overshoot at the end position. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needTune controllers at multiple design points and validate scheduled performance across the full operating range.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Condition inference on process phase; preserve physical context; test root-cause discrimination and subtask timing rather than a context-free threshold.
The H753 cell uses a smaller signal set and safe injected resistance while retaining the context-sensitive evaluation idea.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationPublish three or four safe profiles and a formal feasibility rule; models may rank only candidates that pass MCU limits.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sense0–3.3 V angle potentiometer; servo-current shunt channel; LM35-class servo-ca…
Actuateexternally powered low-torque servo
Fixturesingle-axis gimbal stand; visible target pointer and 3–5 low-overshoot profil…
Protectregulated 5 V, 2 A servo supply; inline fuse plus spare fuses; hardware servo…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: The model selects only a stored profile; the board rejects arbitrary PWM, trajectory or gain values. Verify the complete EQ-07-03 manifest before data collection.
1 · Scenario and student challenge
Prioritise low overshoot and settling rather than raw speed. In plain language, adapt EcoMotion — Energy–Time Trade-off Profile Optimiser so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Represents precision motion.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M + the named safe mechanical/condition fixture. Begin with the H753-M rig with three or more faculty-approved profiles and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record profile ID, move distance, direction, load proxy, response time, overshoot, PWM, current and energy proxy. Treat one profile execution for one declared movement and context as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Multi-criteria profile ranking. First implement the parent baseline—always use the conservative profile or a hand-written load-to-profile rule—and then compare two algorithms from the faculty-issued ML whitelist. Report correct/feasible selection rate, constraint violations and improvement over the fixed policy. A choice is wrong if it violates a declared current, timing, thermal or control-quality bound even when it is fast. Produce a candidate-outcome/constraint table showing why the selected option is feasible.
5 · Embedded integration and safe response
The host may return only one approved PROFILE_ID or CONSERVATIVE_DEFAULT, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a nominally fast profile that appears attractive but violates a hidden current or control-quality constraint. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 07.03 — Camera-Gimbal Profile Selector”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M + the named safe mechanical/condition fixtureclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P07 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Camera-Gimbal Profile Selector is a syllabus-scaled physical analogue of the need evidenced by IU03 · Gain Scheduling: Prioritise low overshoot and settling rather than raw speed. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needTune controllers at multiple design points and validate scheduled performance across the full operating range.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Condition inference on process phase; preserve physical context; test root-cause discrimination and subtask timing rather than a context-free threshold.
The H753 cell uses a smaller signal set and safe injected resistance while retaining the context-sensitive evaluation idea.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationPublish three or four safe profiles and a formal feasibility rule; models may rank only candidates that pass MCU limits.
Variant 07.04
Conveyor Speed-Mode Selector
Engineering purpose: Connects control to operations.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensequadrature encoder or external position feedback channel; conditioned 0–3.3 V…
Actuatelow-torque geared DC motor with encoder; matching 3.3-V-logic H-bridge rated…
Fixtureguarded mini-conveyor/wheel stand; load/occupancy batches and ECONOMY/NORMAL/…
Protectcurrent-limited actuator supply; inline fuse plus spare fuses; latching E-sto…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: The model selects only a stored profile; the board rejects arbitrary PWM, trajectory or gain values. Verify the complete EQ-07-04 manifest before data collection.
1 · Scenario and student challenge
Choose economy/normal/boost based on load and thermal state. In plain language, adapt EcoMotion — Energy–Time Trade-off Profile Optimiser so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Connects control to operations.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M + the named safe mechanical/condition fixture. Begin with the H753-M rig with three or more faculty-approved profiles and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record profile ID, move distance, direction, load proxy, response time, overshoot, PWM, current and energy proxy. Treat one profile execution for one declared movement and context as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Multiclass recommendation with throughput metric. First implement the parent baseline—always use the conservative profile or a hand-written load-to-profile rule—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only one approved PROFILE_ID or CONSERVATIVE_DEFAULT, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a nominally fast profile that appears attractive but violates a hidden current or control-quality constraint. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 07.04 — Conveyor Speed-Mode Selector”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M + the named safe mechanical/condition fixtureclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P07 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Conveyor Speed-Mode Selector is a syllabus-scaled physical analogue of the need evidenced by IU03 · Gain Scheduling: Choose economy/normal/boost based on load and thermal state. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needTune controllers at multiple design points and validate scheduled performance across the full operating range.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Condition inference on process phase; preserve physical context; test root-cause discrimination and subtask timing rather than a context-free threshold.
The H753 cell uses a smaller signal set and safe injected resistance while retaining the context-sensitive evaluation idea.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationPublish three or four safe profiles and a formal feasibility rule; models may rank only candidates that pass MCU limits.
Variant 07.05
Solar-Tracker Move Optimiser
Engineering purpose: Adds renewable-energy context using the same actuator.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
SenseLDR 0–3.3 V channel; 0–3.3 V servo-angle feedback or calibrated angle grid; s…
Actuateexternally powered low-torque servo
Fixtureservo solar-tracker emulator with approved angle grid; small LDR/panel target…
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: The model selects only a stored profile; the board rejects arbitrary PWM, trajectory or gain values. Verify the complete EQ-07-05 manifest before data collection.
1 · Scenario and student challenge
Choose infrequent fast versus slower low-current repositioning. In plain language, adapt EcoMotion — Energy–Time Trade-off Profile Optimiser so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Adds renewable-energy context using the same actuator.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M + the named safe mechanical/condition fixture. Begin with the H753-M rig with three or more faculty-approved profiles and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record profile ID, move distance, direction, load proxy, response time, overshoot, PWM, current and energy proxy. Treat one profile execution for one declared movement and context as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Energy/time prediction. First implement the parent baseline—always use the conservative profile or a hand-written load-to-profile rule—and then compare two algorithms from the faculty-issued ML whitelist. Report MAE and RMSE on whole held-out runs, show predicted-versus-measured values, and inspect error by operating condition. If the target is converted to a safe/unsafe decision, also report missed-unsafe and unnecessary-conservative actions. Produce a predicted-versus-measured plot with residuals by operating condition.
5 · Embedded integration and safe response
The host may return only one approved PROFILE_ID or CONSERVATIVE_DEFAULT, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a nominally fast profile that appears attractive but violates a hidden current or control-quality constraint. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 07.05 — Solar-Tracker Move Optimiser”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M + the named safe mechanical/condition fixtureregression/outcomerun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P07 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Solar-Tracker Move Optimiser is a syllabus-scaled physical analogue of the need evidenced by IU03 · Gain Scheduling: Choose infrequent fast versus slower low-current repositioning. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needTune controllers at multiple design points and validate scheduled performance across the full operating range.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Condition inference on process phase; preserve physical context; test root-cause discrimination and subtask timing rather than a context-free threshold.
The H753 cell uses a smaller signal set and safe injected resistance while retaining the context-sensitive evaluation idea.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationPublish three or four safe profiles and a formal feasibility rule; models may rank only candidates that pass MCU limits.
Variant 07.06
Dosing-Wheel Profile Optimiser
Engineering purpose: Maps to dispensing/packaging quality.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensequadrature encoder or external position feedback channel; conditioned 0–3.3 V…
Actuatelow-torque geared DC motor with encoder; matching 3.3-V-logic H-bridge rated…
Fixtureindexed dosing wheel with 6–12 equal compartments; optical/limit home marker…
Protectcurrent-limited actuator supply; inline fuse plus spare fuses; latching E-sto…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: The model selects only a stored profile; the board rejects arbitrary PWM, trajectory or gain values. Verify the complete EQ-07-06 manifest before data collection.
1 · Scenario and student challenge
Prioritise position repeatability and low overshoot. In plain language, adapt EcoMotion — Energy–Time Trade-off Profile Optimiser so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Maps to dispensing/packaging quality.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M + the named safe mechanical/condition fixture. Begin with the H753-M rig with three or more faculty-approved profiles and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record profile ID, move distance, direction, load proxy, response time, overshoot, PWM, current and energy proxy. Treat one profile execution for one declared movement and context as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Pass/fail feasibility by profile. First implement the parent baseline—always use the conservative profile or a hand-written load-to-profile rule—and then compare two algorithms from the faculty-issued ML whitelist. Report correct/feasible selection rate, constraint violations and improvement over the fixed policy. A choice is wrong if it violates a declared current, timing, thermal or control-quality bound even when it is fast. Produce a candidate-outcome/constraint table showing why the selected option is feasible.
5 · Embedded integration and safe response
The host may return only one approved PROFILE_ID or CONSERVATIVE_DEFAULT, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a nominally fast profile that appears attractive but violates a hidden current or control-quality constraint. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 07.06 — Dosing-Wheel Profile Optimiser”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M + the named safe mechanical/condition fixtureclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P07 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Dosing-Wheel Profile Optimiser is a syllabus-scaled physical analogue of the need evidenced by IU03 · Gain Scheduling: Prioritise position repeatability and low overshoot. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needTune controllers at multiple design points and validate scheduled performance across the full operating range.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Condition inference on process phase; preserve physical context; test root-cause discrimination and subtask timing rather than a context-free threshold.
The H753 cell uses a smaller signal set and safe injected resistance while retaining the context-sensitive evaluation idea.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationPublish three or four safe profiles and a formal feasibility rule; models may rank only candidates that pass MCU limits.
Variant 07.07
Mini-Hoist Profile Selector
Engineering purpose: Adds gravity and asymmetric risk.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensequadrature encoder or external position feedback channel; conditioned 0–3.3 V…
Actuatelow-torque geared DC motor with encoder; matching 3.3-V-logic H-bridge rated…
Fixtureguarded drum mini-hoist with catch tray; safe payloads and separate lift/lowe…
Protectcurrent-limited actuator supply; inline fuse plus spare fuses; latching E-sto…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: The model selects only a stored profile; the board rejects arbitrary PWM, trajectory or gain values. Verify the complete EQ-07-07 manifest before data collection.
1 · Scenario and student challenge
Select different profiles by direction and load. In plain language, adapt EcoMotion — Energy–Time Trade-off Profile Optimiser so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Adds gravity and asymmetric risk.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M + the named safe mechanical/condition fixture. Begin with the H753-M rig with three or more faculty-approved profiles and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record profile ID, move distance, direction, load proxy, response time, overshoot, PWM, current and energy proxy. Treat one profile execution for one declared movement and context as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Direction-aware constraint prediction. First implement the parent baseline—always use the conservative profile or a hand-written load-to-profile rule—and then compare two algorithms from the faculty-issued ML whitelist. Report MAE and RMSE on whole held-out runs, show predicted-versus-measured values, and inspect error by operating condition. If the target is converted to a safe/unsafe decision, also report missed-unsafe and unnecessary-conservative actions. Produce a predicted-versus-measured plot with residuals by operating condition.
5 · Embedded integration and safe response
The host may return only one approved PROFILE_ID or CONSERVATIVE_DEFAULT, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a nominally fast profile that appears attractive but violates a hidden current or control-quality constraint. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 07.07 — Mini-Hoist Profile Selector”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M + the named safe mechanical/condition fixtureregression/outcomerun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P07 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Mini-Hoist Profile Selector is a syllabus-scaled physical analogue of the need evidenced by IU03 · Gain Scheduling: Select different profiles by direction and load. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needTune controllers at multiple design points and validate scheduled performance across the full operating range.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Condition inference on process phase; preserve physical context; test root-cause discrimination and subtask timing rather than a context-free threshold.
The H753 cell uses a smaller signal set and safe injected resistance while retaining the context-sensitive evaluation idea.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationPublish three or four safe profiles and a formal feasibility rule; models may rank only candidates that pass MCU limits.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: The model selects only a stored profile; the board rejects arbitrary PWM, trajectory or gain values. Verify the complete EQ-07-08 manifest before data collection.
1 · Scenario and student challenge
Minimise cycle time while avoiding high peak current. In plain language, adapt EcoMotion — Energy–Time Trade-off Profile Optimiser so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Supports high-cycle machinery.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M + the named safe mechanical/condition fixture. Begin with the H753-M rig with three or more faculty-approved profiles and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record profile ID, move distance, direction, load proxy, response time, overshoot, PWM, current and energy proxy. Treat one profile execution for one declared movement and context as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Profile feasibility classification. First implement the parent baseline—always use the conservative profile or a hand-written load-to-profile rule—and then compare two algorithms from the faculty-issued ML whitelist. Report correct/feasible selection rate, constraint violations and improvement over the fixed policy. A choice is wrong if it violates a declared current, timing, thermal or control-quality bound even when it is fast. Produce a candidate-outcome/constraint table showing why the selected option is feasible.
5 · Embedded integration and safe response
The host may return only one approved PROFILE_ID or CONSERVATIVE_DEFAULT, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a nominally fast profile that appears attractive but violates a hidden current or control-quality constraint. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 07.08 — Feeder-Flap Cycle Optimiser”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M + the named safe mechanical/condition fixtureclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P07 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Feeder-Flap Cycle Optimiser is a syllabus-scaled physical analogue of the need evidenced by IU03 · Gain Scheduling: Minimise cycle time while avoiding high peak current. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needTune controllers at multiple design points and validate scheduled performance across the full operating range.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Condition inference on process phase; preserve physical context; test root-cause discrimination and subtask timing rather than a context-free threshold.
The H753 cell uses a smaller signal set and safe injected resistance while retaining the context-sensitive evaluation idea.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationPublish three or four safe profiles and a formal feasibility rule; models may rank only candidates that pass MCU limits.
Variant 07.09
Lab-Agitator Speed Scheduler
Engineering purpose: Shows process-equipment relevance without fluid complexity.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensequadrature encoder or external position feedback channel; conditioned 0–3.3 V…
Actuatelow-torque geared DC motor with encoder; matching 3.3-V-logic H-bridge rated…
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: The model selects only a stored profile; the board rejects arbitrary PWM, trajectory or gain values. Verify the complete EQ-07-09 manifest before data collection.
1 · Scenario and student challenge
Use a rotating load and choose speed ramp based on resistance. In plain language, adapt EcoMotion — Energy–Time Trade-off Profile Optimiser so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Shows process-equipment relevance without fluid complexity.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M + the named safe mechanical/condition fixture. Begin with the H753-M rig with three or more faculty-approved profiles and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record profile ID, move distance, direction, load proxy, response time, overshoot, PWM, current and energy proxy. Treat one profile execution for one declared movement and context as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Outcome regression. First implement the parent baseline—always use the conservative profile or a hand-written load-to-profile rule—and then compare two algorithms from the faculty-issued ML whitelist. Report MAE and RMSE on whole held-out runs, show predicted-versus-measured values, and inspect error by operating condition. If the target is converted to a safe/unsafe decision, also report missed-unsafe and unnecessary-conservative actions. Produce a predicted-versus-measured plot with residuals by operating condition.
5 · Embedded integration and safe response
The host may return only one approved PROFILE_ID or CONSERVATIVE_DEFAULT, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a nominally fast profile that appears attractive but violates a hidden current or control-quality constraint. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 07.09 — Lab-Agitator Speed Scheduler”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M + the named safe mechanical/condition fixtureregression/outcomerun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P07 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Lab-Agitator Speed Scheduler is a syllabus-scaled physical analogue of the need evidenced by IU03 · Gain Scheduling: Use a rotating load and choose speed ramp based on resistance. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needTune controllers at multiple design points and validate scheduled performance across the full operating range.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Condition inference on process phase; preserve physical context; test root-cause discrimination and subtask timing rather than a context-free threshold.
The H753 cell uses a smaller signal set and safe injected resistance while retaining the context-sensitive evaluation idea.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationPublish three or four safe profiles and a formal feasibility rule; models may rank only candidates that pass MCU limits.
Variant 07.10
Ageing-Aware Profile Optimiser
Engineering purpose: Connects optimisation with maintenance.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensequadrature encoder or external position feedback channel; conditioned 0–3.3 V…
Actuatelow-torque geared DC motor with encoder; matching 3.3-V-logic H-bridge rated…
Fixturestandard motion rig with reversible ageing inserts; healthy insert and fricti…
Protectcurrent-limited actuator supply; inline fuse plus spare fuses; latching E-sto…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: The model selects only a stored profile; the board rejects arbitrary PWM, trajectory or gain values. Verify the complete EQ-07-10 manifest before data collection.
1 · Scenario and student challenge
Include recent cycle statistics or baseline drift in profile selection. In plain language, adapt EcoMotion — Energy–Time Trade-off Profile Optimiser so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Connects optimisation with maintenance.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M + the named safe mechanical/condition fixture. Begin with the H753-M rig with three or more faculty-approved profiles and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record profile ID, move distance, direction, load proxy, response time, overshoot, PWM, current and energy proxy. Treat one profile execution for one declared movement and context as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Model conditioned on health indicators. First implement the parent baseline—always use the conservative profile or a hand-written load-to-profile rule—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a Pareto plot of time versus energy with infeasible trials clearly marked.
5 · Embedded integration and safe response
The host may return only one approved PROFILE_ID or CONSERVATIVE_DEFAULT, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a nominally fast profile that appears attractive but violates a hidden current or control-quality constraint. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 07.10 — Ageing-Aware Profile Optimiser”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M + the named safe mechanical/condition fixtureclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P07 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Ageing-Aware Profile Optimiser is a syllabus-scaled physical analogue of the need evidenced by IU03 · Gain Scheduling: Include recent cycle statistics or baseline drift in profile selection. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needTune controllers at multiple design points and validate scheduled performance across the full operating range.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Condition inference on process phase; preserve physical context; test root-cause discrimination and subtask timing rather than a context-free threshold.
The H753 cell uses a smaller signal set and safe injected resistance while retaining the context-sensitive evaluation idea.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationPublish three or four safe profiles and a formal feasibility rule; models may rank only candidates that pass MCU limits.
Problem 08 · 10 variants · Motion, drive and actuator intelligence
CyclePassport — Actuator Health and Maintenance Evidence System
Team size: 4; approved 3-member exception1 × NUCLEO-H753ZIH753-MAnomaly / classificationAdvanced
Assigned Faculty Master pair for P08: one nominated ESD Faculty Master and one nominated ML Faculty Master shall jointly master this parent problem and variants V1-V10. The ESD Master owns hardware, firmware, control, communication and safety verification; the ML Master owns data, baselines, models, validation and bounded decision-policy verification. Together they teach and guide ten teams (one for each variant and up to 40 students), supervise five teams in Wave A and five in Wave B, witness integration and sign every final evaluation.
The problem
Preventive maintenance is often scheduled by calendar time rather than measured condition. Repeated cycles of the same actuator create a health signature: current demand, movement time, overshoot, steady-state error, temperature and retries gradually change. The challenge is to create a compact digital ‘passport’ that detects drift and provides evidence for inspect/continue decisions without claiming full remaining-useful-life prediction.
Smart embedded product to build
Build a NUCLEO-H753ZI actuator cycle-passport station. It executes a safe repeated move, assigns device/session/cycle IDs, logs firmware/profile version, performance, environment and hard faults, and emits one compact health record per cycle. The host learns healthy variation or classifies seeded degradation while controlling for temperature, load and direction, then returns HEALTHY, WATCH, INSPECT, SERVICE_SOON or STOP_USE—without claiming unsupported remaining useful life.
NUCLEO-H753ZI realization and issued pack
NUCLEO-H753ZI / MB1364E with H753-M repeat-cycle fixture
timer PWM/PID and encoder/position feedback
conditioned current and motor/driver temperature ADC channels
persistent cycle counter and per-cycle summary retained in RAM/Flash-safe checkpoint policy
USART3 VCP exports raw trials and passport summaries with firmware/configuration version
LED/display reports HEALTHY, WATCH, INSPECT or STOP
degradation is simulated with safe fixtures/settings; no destructive ageing is required
Intelligence to incorporate
Use supervised classification where seeded degradation labels exist, or clustering/anomaly detection on healthy cycles. Features include cycle time, peak/mean current, current integral, overshoot, steady-state error, retry count, temperature and direction. Evaluate detection of held-out degradation scenarios, false alarms across normal variation and change from baseline.
Canonical family command contract: every parent brief, variant, host message and MCU acknowledgement for P08 shall use these exact identifiers. A variant may use only the applicable subset; it shall not introduce a synonym.
Core problem equipment · EQ-08-CORE
Complete equipment required for one core-problem team
Standalone family BOM. This list supports the parent problem itself. An allocated variant uses its own complete table later in this card. A component mentioned again in the fixture description is the same mounted unit, not another copy.
4 students; 3 by approved exception1 H753 board1 team laptopquantities per team
Controller1 H753 board + 1 laptop
Sensequadrature encoder/position feedback; conditioned 0–3.3 V current-sense chann…
Actuate6–12 V geared DC motor with encoder; 3.3-V-logic H-bridge rated above stall c…
Fixtureguarded repeat-cycle fixture with replaceable friction/load inserts; healthy/…
Protectcurrent-limited 6–12 V DC supply; inline fuse plus spare fuses; latching E-st…
System block
Complete quantity and equipment per team
Purpose / acceptance condition
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser multi-session health-history dataset; destructive ageing is not expected in 24 hours
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Release-to-team condition: Degradation is simulated reversibly; the team must not damage the motor, encoder or bearings. The organiser signs the electrical, mechanical and communication acceptance checklist before H0:00.
Not duplicated inside the kit: supervised rework tools and the oscilloscope/logic-analyser station are shared at the ratio stated above. Everything else in this table is issued to, reserved for, or digitally assigned to this team.
Controlled self-learning extension
Recommended Add a simple rolling drift index against a frozen healthy reference and document its sensitivity to temperature/load confounders. It must trigger WATCH, never bypass the supervised or rule-based safety decision.
System safety and non-negotiable boundary
The passport does not replace firmware interlocks and must not encourage operation beyond safe limits. ‘Remove from service’ is a lab decision state; no destructive ageing is required. Degradation is safely simulated using controlled friction/load/sensor faults.
Student interpretation — what this challenge really asks
Maintenance decisions should come from repeated evidence, not one noisy measurement. The product builds a compact health passport from cycle-to-cycle changes and flags credible deterioration or unusual behaviour.
Independent data unitone complete actuator cycle, grouped within a device/session history.
Closest misleading casenormal load, temperature or direction variation that looks like degradation.
Definition of successStudents must detect meaningful degradation evidence while remaining stable under normal cycle-to-cycle variation.
Visual system blueprint
Physical processRepeated actuator cyclesGenerate labelled, safe and repeatable conditions.
Observecycle number, travel time, current statisticsPreserve units, timestamps, run identity and signal quality.
H753 responsibilityControl and protectexecute repeatable bounded cycles, preserve cycle identity and log comparable health indicators.
Host intelligenceLearn the distinctionclassify health stage, detect deviation from healthy regimes or estimate a transparent drift score.
Bounded outcomeHEALTHY · WATCH · INSPECT · SERVICE_SOON · STOP_USEMCU validates, acknowledges and may refuse the request.
Recommended build journey
Make the process repeatableAssemble the repeatable H753-M actuator cycle rig; define reference and target conditions before collecting data.
Prove deterministic firmwareExecute repeatable bounded cycles, preserve cycle identity and log comparable health indicators. Demonstrate every hard limit before connecting ML.
Build trustworthy trialsTreat one complete actuator cycle, grouped within a device/session history as independent; calibrate, label and split by run/session.
Beat a real baselineCompare fixed health limits or deviation from the first healthy-cycle mean with two syllabus-approved classical models.
Close and challenge the loopReturn only the applicable subset of HEALTHY · WATCH · INSPECT · SERVICE_SOON · STOP_USE; test the target, nearest confuser, stale command and host loss.
Definition of done
Firmware controls safely before, during and after host connection.
Held-out results report fault/health recall, false alarm, drift sensitivity and stability across operating contexts.
Portfolio shows cycle-index health trend with operating context and detected change points and one honest failure case.
Problem-specific evidence at the common reviews
R1 · Design
Define safe degradation simulations, cycle protocol, health states and confounders such as temperature/direction.
R2 · Embedded
Show automated bounded cycles, cycle/session IDs, metrics and stop-on-fault behaviour.
R3 · Data
Submit healthy envelope plus simulated degradation runs, baseline trend rules and group split by session.
R4 · ML
Present health model, false-alarm analysis and evidence separating degradation from normal variation.
R5 · Integration
Integrate health state/display, detect a hidden degradation and survive sensor/host faults.
Final
Produce a live health passport, explain the trend evidence and show a reproducible Kaggle/GitHub package.
Portfolio/Kaggle outcome
Kaggle asset: ‘STM32 Actuator Cycle Health Dataset’ with session/cycle grouping, drift plots, anomaly/classification notebook, maintenance threshold rationale and before/after maintenance comparison.
Industry alignment and validation basis
CyclePassport: external references and required evidence
The listed sources establish relevance, test discipline and implementation precedent. They do not modify the common syllabus boundary, safety rules or 100-mark assessment rubric.
Family implementation profile
Variant availability: 0 standard assignment(s); 10 organiser-supported assignment(s).
Public evidence: reproducible firmware, protocol, dataset, notebook/model, test report and demonstration video.
What the external benchmark confirms
The problem has a recognisable industrial or challenge analogue, a measurable data task, a defensible embedded implementation and a safe operational decision. Every one of its ten variants is mapped separately below.
Condition before team allocation
Make historical cycle data mandatory organiser input. Live cycles should validate transfer, not attempt to simulate months of ageing in one day.
Predict which manufactured components fail internal quality control from production-line measurements and tests.
Use untouched held-out cases, expose false rejects as well as missed failures, and preserve specimen/run identity.
Open the 10 fully elaborated student variant briefs
Choose only the variant allocated to your team. Read it together with the parent problem above: the card expands the experimental delta, while every hardware, safety, integration and review requirement of the family remains active.
Variant 08.01
Friction-Drift Passport
Engineering purpose: Creates a clear monotonic degradation case.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensequadrature encoder/position feedback; conditioned 0–3.3 V current-sense chann…
Actuate6–12 V geared DC motor with encoder; 3.3-V-logic H-bridge rated above stall c…
Fixturerepeat-cycle motor fixture with four reversible felt-brake settings
Protectcurrent-limited 6–12 V DC supply; inline fuse plus spare fuses; latching E-st…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser multi-session health-history dataset; destructive ageing is not expected in 24 hours
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Degradation is simulated reversibly; the team must not damage the motor, encoder or bearings. Verify the complete EQ-08-01 manifest before data collection.
1 · Scenario and student challenge
Gradually increase safe mechanical resistance across sessions. In plain language, adapt CyclePassport — Actuator Health and Maintenance Evidence System so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Creates a clear monotonic degradation case.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M + the named safe mechanical/condition fixture. Begin with the repeatable H753-M actuator cycle rig and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record cycle number, travel time, current statistics, speed/error, temperature, saturation, retries and maintenance/event labels. Treat one complete actuator cycle, grouped within a device/session history as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Anomaly score or health classification. First implement the parent baseline—fixed health limits or deviation from the first healthy-cycle mean—and then compare two algorithms from the faculty-issued ML whitelist. Train or set the threshold using healthy/training data only. Report event recall, false alarms per normal run and detection delay; show where the method treats a new but valid regime as abnormal. Produce a event timeline with anomaly score, threshold and false-alarm examples.
5 · Embedded integration and safe response
The host may return only HEALTHY, WATCH, INSPECT, SERVICE_SOON or STOP_USE, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with normal load, temperature or direction variation that looks like degradation. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 08.01 — Friction-Drift Passport”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M + the named safe mechanical/condition fixtureanomaly/noveltyrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P08 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Friction-Drift Passport is a syllabus-scaled physical analogue of the need evidenced by GC02 · PHM 2008 Challenge: Gradually increase safe mechanical resistance across sessions. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needUse degradation trajectories to estimate remaining operational life on a withheld test set; the challenge remains available for comparison.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Connect sensor history to an actionable maintenance event and report error by operating context, not only an aggregate score.
The handbook reduces the horizon to transparent health evidence and uses organiser-provided history so it remains a 24-hour task.
Implementation modeOrganiser-supported assignmentMay be issued only after the named seed history, reference specimens, calibration set or controlled fixture is prepared.
Required organiser provisionComplete before team allocationMake historical cycle data mandatory organiser input. Live cycles should validate transfer, not attempt to simulate months of ageing in one day.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensequadrature encoder/position feedback; conditioned 0–3.3 V current-sense chann…
Actuate6–12 V geared DC motor with encoder; 3.3-V-logic H-bridge rated above stall c…
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser multi-session health-history dataset; destructive ageing is not expected in 24 hours
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Degradation is simulated reversibly; the team must not damage the motor, encoder or bearings. Verify the complete EQ-08-02 manifest before data collection.
1 · Scenario and student challenge
Track whether one direction deteriorates faster. In plain language, adapt CyclePassport — Actuator Health and Maintenance Evidence System so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Avoids masking asymmetric faults.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M + the named safe mechanical/condition fixture. Begin with the repeatable H753-M actuator cycle rig and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record cycle number, travel time, current statistics, speed/error, temperature, saturation, retries and maintenance/event labels. Treat one complete actuator cycle, grouped within a device/session history as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Direction-conditioned health model. First implement the parent baseline—fixed health limits or deviation from the first healthy-cycle mean—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a cycle-index health trend with operating context and detected change points.
5 · Embedded integration and safe response
The host may return only HEALTHY, WATCH, INSPECT, SERVICE_SOON or STOP_USE, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with normal load, temperature or direction variation that looks like degradation. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 08.02 — Direction-Asymmetry Passport”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M + the named safe mechanical/condition fixtureclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P08 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Direction-Asymmetry Passport is a syllabus-scaled physical analogue of the need evidenced by GC02 · PHM 2008 Challenge: Track whether one direction deteriorates faster. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needUse degradation trajectories to estimate remaining operational life on a withheld test set; the challenge remains available for comparison.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Connect sensor history to an actionable maintenance event and report error by operating context, not only an aggregate score.
The handbook reduces the horizon to transparent health evidence and uses organiser-provided history so it remains a 24-hour task.
Implementation modeOrganiser-supported assignmentMay be issued only after the named seed history, reference specimens, calibration set or controlled fixture is prepared.
Required organiser provisionComplete before team allocationMake historical cycle data mandatory organiser input. Live cycles should validate transfer, not attempt to simulate months of ageing in one day.
Variant 08.03
Thermal-Ageing Proxy Passport
Engineering purpose: Links duty cycle to maintenance evidence.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensequadrature encoder/position feedback; conditioned 0–3.3 V current-sense chann…
Actuate6–12 V geared DC motor with encoder; 3.3-V-logic H-bridge rated above stall c…
Fixturerepeat-cycle fixture with temperature probe and cooling stand; approved therm…
Protectcurrent-limited 6–12 V DC supply; inline fuse plus spare fuses; latching E-st…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser multi-session health-history dataset; destructive ageing is not expected in 24 hours
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Degradation is simulated reversibly; the team must not damage the motor, encoder or bearings. Verify the complete EQ-08-03 manifest before data collection.
1 · Scenario and student challenge
Use repeated-cycle heat accumulation as a condition indicator. In plain language, adapt CyclePassport — Actuator Health and Maintenance Evidence System so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Links duty cycle to maintenance evidence.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M + the named safe mechanical/condition fixture. Begin with the repeatable H753-M actuator cycle rig and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record cycle number, travel time, current statistics, speed/error, temperature, saturation, retries and maintenance/event labels. Treat one complete actuator cycle, grouped within a device/session history as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Classification of safe/monitor/cooldown. First implement the parent baseline—fixed health limits or deviation from the first healthy-cycle mean—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only HEALTHY, WATCH, INSPECT, SERVICE_SOON or STOP_USE, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with normal load, temperature or direction variation that looks like degradation. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 08.03 — Thermal-Ageing Proxy Passport”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M + the named safe mechanical/condition fixtureclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P08 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Thermal-Ageing Proxy Passport is a syllabus-scaled physical analogue of the need evidenced by GC02 · PHM 2008 Challenge: Use repeated-cycle heat accumulation as a condition indicator. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needUse degradation trajectories to estimate remaining operational life on a withheld test set; the challenge remains available for comparison.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Connect sensor history to an actionable maintenance event and report error by operating context, not only an aggregate score.
The handbook reduces the horizon to transparent health evidence and uses organiser-provided history so it remains a 24-hour task.
Implementation modeOrganiser-supported assignmentMay be issued only after the named seed history, reference specimens, calibration set or controlled fixture is prepared.
Required organiser provisionComplete before team allocationMake historical cycle data mandatory organiser input. Live cycles should validate transfer, not attempt to simulate months of ageing in one day.
Variant 08.04
Encoder-Reliability Passport
Engineering purpose: Focuses on feedback-channel health.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensequadrature encoder/position feedback; conditioned 0–3.3 V current-sense chann…
Actuate6–12 V geared DC motor with encoder; 3.3-V-logic H-bridge rated above stall c…
Fixturerepeat-cycle fixture with encoder fault switch; PASS/INTERMITTENT/DROPOUT enc…
Protectcurrent-limited 6–12 V DC supply; inline fuse plus spare fuses; latching E-st…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser multi-session health-history dataset; destructive ageing is not expected in 24 hours
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Degradation is simulated reversibly; the team must not damage the motor, encoder or bearings. Verify the complete EQ-08-04 manifest before data collection.
1 · Scenario and student challenge
Track missed transitions, jitter and position-repeatability failures. In plain language, adapt CyclePassport — Actuator Health and Maintenance Evidence System so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Focuses on feedback-channel health.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M + the named safe mechanical/condition fixture. Begin with the repeatable H753-M actuator cycle rig and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record cycle number, travel time, current statistics, speed/error, temperature, saturation, retries and maintenance/event labels. Treat one complete actuator cycle, grouped within a device/session history as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Fault-rate classification/anomaly detection. First implement the parent baseline—fixed health limits or deviation from the first healthy-cycle mean—and then compare two algorithms from the faculty-issued ML whitelist. Train or set the threshold using healthy/training data only. Report event recall, false alarms per normal run and detection delay; show where the method treats a new but valid regime as abnormal. Produce a event timeline with anomaly score, threshold and false-alarm examples.
5 · Embedded integration and safe response
The host may return only HEALTHY, WATCH, INSPECT, SERVICE_SOON or STOP_USE, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with normal load, temperature or direction variation that looks like degradation. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 08.04 — Encoder-Reliability Passport”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M + the named safe mechanical/condition fixtureanomaly/noveltyrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P08 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Encoder-Reliability Passport is a syllabus-scaled physical analogue of the need evidenced by GC02 · PHM 2008 Challenge: Track missed transitions, jitter and position-repeatability failures. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needUse degradation trajectories to estimate remaining operational life on a withheld test set; the challenge remains available for comparison.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Connect sensor history to an actionable maintenance event and report error by operating context, not only an aggregate score.
The handbook reduces the horizon to transparent health evidence and uses organiser-provided history so it remains a 24-hour task.
Implementation modeOrganiser-supported assignmentMay be issued only after the named seed history, reference specimens, calibration set or controlled fixture is prepared.
Required organiser provisionComplete before team allocationMake historical cycle data mandatory organiser input. Live cycles should validate transfer, not attempt to simulate months of ageing in one day.
Variant 08.05
Current-Baseline Drift Passport
Engineering purpose: Uses contextual baseline rather than raw threshold.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensequadrature encoder/position feedback; conditioned 0–3.3 V current-sense chann…
Actuate6–12 V geared DC motor with encoder; 3.3-V-logic H-bridge rated above stall c…
Fixturerepeat-cycle fixture with fixed matched load; current-sensor calibration resi…
Protectcurrent-limited 6–12 V DC supply; inline fuse plus spare fuses; latching E-st…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser multi-session health-history dataset; destructive ageing is not expected in 24 hours
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Degradation is simulated reversibly; the team must not damage the motor, encoder or bearings. Verify the complete EQ-08-05 manifest before data collection.
1 · Scenario and student challenge
Detect increase in current at matched setpoint/load. In plain language, adapt CyclePassport — Actuator Health and Maintenance Evidence System so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Uses contextual baseline rather than raw threshold.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M + the named safe mechanical/condition fixture. Begin with the repeatable H753-M actuator cycle rig and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record cycle number, travel time, current statistics, speed/error, temperature, saturation, retries and maintenance/event labels. Treat one complete actuator cycle, grouped within a device/session history as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Regression residual or anomaly score. First implement the parent baseline—fixed health limits or deviation from the first healthy-cycle mean—and then compare two algorithms from the faculty-issued ML whitelist. Report MAE and RMSE on whole held-out runs, show predicted-versus-measured values, and inspect error by operating condition. If the target is converted to a safe/unsafe decision, also report missed-unsafe and unnecessary-conservative actions. Produce a predicted-versus-measured plot with residuals by operating condition.
5 · Embedded integration and safe response
The host may return only HEALTHY, WATCH, INSPECT, SERVICE_SOON or STOP_USE, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with normal load, temperature or direction variation that looks like degradation. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 08.05 — Current-Baseline Drift Passport”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M + the named safe mechanical/condition fixtureregression/outcomerun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P08 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Current-Baseline Drift Passport is a syllabus-scaled physical analogue of the need evidenced by GC02 · PHM 2008 Challenge: Detect increase in current at matched setpoint/load. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needUse degradation trajectories to estimate remaining operational life on a withheld test set; the challenge remains available for comparison.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Connect sensor history to an actionable maintenance event and report error by operating context, not only an aggregate score.
The handbook reduces the horizon to transparent health evidence and uses organiser-provided history so it remains a 24-hour task.
Implementation modeOrganiser-supported assignmentMay be issued only after the named seed history, reference specimens, calibration set or controlled fixture is prepared.
Required organiser provisionComplete before team allocationMake historical cycle data mandatory organiser input. Live cycles should validate transfer, not attempt to simulate months of ageing in one day.
Variant 08.06
Motion-Time Drift Passport
Engineering purpose: Simple, interpretable and useful.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensequadrature encoder/position feedback; conditioned 0–3.3 V current-sense chann…
Actuate6–12 V geared DC motor with encoder; 3.3-V-logic H-bridge rated above stall c…
Fixturerepeat-cycle fixture with rigid start/target stops; external stopwatch only f…
Protectcurrent-limited 6–12 V DC supply; inline fuse plus spare fuses; latching E-st…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser multi-session health-history dataset; destructive ageing is not expected in 24 hours
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Degradation is simulated reversibly; the team must not damage the motor, encoder or bearings. Verify the complete EQ-08-06 manifest before data collection.
1 · Scenario and student challenge
Monitor gradual cycle-time increase. In plain language, adapt CyclePassport — Actuator Health and Maintenance Evidence System so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Simple, interpretable and useful.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M + the named safe mechanical/condition fixture. Begin with the repeatable H753-M actuator cycle rig and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record cycle number, travel time, current statistics, speed/error, temperature, saturation, retries and maintenance/event labels. Treat one complete actuator cycle, grouped within a device/session history as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Trend classification with temperature compensation. First implement the parent baseline—fixed health limits or deviation from the first healthy-cycle mean—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only HEALTHY, WATCH, INSPECT, SERVICE_SOON or STOP_USE, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with normal load, temperature or direction variation that looks like degradation. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 08.06 — Motion-Time Drift Passport”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M + the named safe mechanical/condition fixtureclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P08 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Motion-Time Drift Passport is a syllabus-scaled physical analogue of the need evidenced by GC02 · PHM 2008 Challenge: Monitor gradual cycle-time increase. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needUse degradation trajectories to estimate remaining operational life on a withheld test set; the challenge remains available for comparison.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Connect sensor history to an actionable maintenance event and report error by operating context, not only an aggregate score.
The handbook reduces the horizon to transparent health evidence and uses organiser-provided history so it remains a 24-hour task.
Implementation modeOrganiser-supported assignmentMay be issued only after the named seed history, reference specimens, calibration set or controlled fixture is prepared.
Required organiser provisionComplete before team allocationMake historical cycle data mandatory organiser input. Live cycles should validate transfer, not attempt to simulate months of ageing in one day.
Variant 08.07
Post-Service Verification Passport
Engineering purpose: Turns maintenance into auditable evidence.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensequadrature encoder/position feedback; conditioned 0–3.3 V current-sense chann…
Actuate6–12 V geared DC motor with encoder; 3.3-V-logic H-bridge rated above stall c…
Fixtureservice-verification fixture; reversible pre/post adjustment or friction inse…
Protectcurrent-limited 6–12 V DC supply; inline fuse plus spare fuses; latching E-st…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser multi-session health-history dataset; destructive ageing is not expected in 24 hours
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Degradation is simulated reversibly; the team must not damage the motor, encoder or bearings. Verify the complete EQ-08-07 manifest before data collection.
1 · Scenario and student challenge
Compare pre- and post-adjustment runs against the original healthy envelope. In plain language, adapt CyclePassport — Actuator Health and Maintenance Evidence System so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Turns maintenance into auditable evidence.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M + the named safe mechanical/condition fixture. Begin with the repeatable H753-M actuator cycle rig and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record cycle number, travel time, current statistics, speed/error, temperature, saturation, retries and maintenance/event labels. Treat one complete actuator cycle, grouped within a device/session history as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Improved/not-improved classification. First implement the parent baseline—fixed health limits or deviation from the first healthy-cycle mean—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only HEALTHY, WATCH, INSPECT, SERVICE_SOON or STOP_USE, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with normal load, temperature or direction variation that looks like degradation. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 08.07 — Post-Service Verification Passport”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M + the named safe mechanical/condition fixtureclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P08 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Post-Service Verification Passport is a syllabus-scaled physical analogue of the need evidenced by GC02 · PHM 2008 Challenge: Compare pre- and post-adjustment runs against the original healthy envelope. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needUse degradation trajectories to estimate remaining operational life on a withheld test set; the challenge remains available for comparison.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Connect sensor history to an actionable maintenance event and report error by operating context, not only an aggregate score.
The handbook reduces the horizon to transparent health evidence and uses organiser-provided history so it remains a 24-hour task.
Implementation modeOrganiser-supported assignmentMay be issued only after the named seed history, reference specimens, calibration set or controlled fixture is prepared.
Required organiser provisionComplete before team allocationMake historical cycle data mandatory organiser input. Live cycles should validate transfer, not attempt to simulate months of ageing in one day.
Variant 08.08
Multi-Profile Health Passport
Engineering purpose: Exposes faults that appear only under demanding motion.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensequadrature encoder/position feedback; conditioned 0–3.3 V current-sense chann…
Actuate6–12 V geared DC motor with encoder; 3.3-V-logic H-bridge rated above stall c…
Fixturerepeat-cycle fixture; card of at least three approved probe profiles
Protectcurrent-limited 6–12 V DC supply; inline fuse plus spare fuses; latching E-st…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser multi-session health-history dataset; destructive ageing is not expected in 24 hours
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Degradation is simulated reversibly; the team must not damage the motor, encoder or bearings. Verify the complete EQ-08-08 manifest before data collection.
1 · Scenario and student challenge
Probe the actuator with several safe profiles. In plain language, adapt CyclePassport — Actuator Health and Maintenance Evidence System so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Exposes faults that appear only under demanding motion.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M + the named safe mechanical/condition fixture. Begin with the repeatable H753-M actuator cycle rig and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record cycle number, travel time, current statistics, speed/error, temperature, saturation, retries and maintenance/event labels. Treat one complete actuator cycle, grouped within a device/session history as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Combined anomaly score across profiles. First implement the parent baseline—fixed health limits or deviation from the first healthy-cycle mean—and then compare two algorithms from the faculty-issued ML whitelist. Train or set the threshold using healthy/training data only. Report event recall, false alarms per normal run and detection delay; show where the method treats a new but valid regime as abnormal. Produce a event timeline with anomaly score, threshold and false-alarm examples.
5 · Embedded integration and safe response
The host may return only HEALTHY, WATCH, INSPECT, SERVICE_SOON or STOP_USE, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with normal load, temperature or direction variation that looks like degradation. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 08.08 — Multi-Profile Health Passport”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M + the named safe mechanical/condition fixtureanomaly/noveltyrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P08 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Multi-Profile Health Passport is a syllabus-scaled physical analogue of the need evidenced by GC02 · PHM 2008 Challenge: Probe the actuator with several safe profiles. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needUse degradation trajectories to estimate remaining operational life on a withheld test set; the challenge remains available for comparison.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Connect sensor history to an actionable maintenance event and report error by operating context, not only an aggregate score.
The handbook reduces the horizon to transparent health evidence and uses organiser-provided history so it remains a 24-hour task.
Implementation modeOrganiser-supported assignmentMay be issued only after the named seed history, reference specimens, calibration set or controlled fixture is prepared.
Required organiser provisionComplete before team allocationMake historical cycle data mandatory organiser input. Live cycles should validate transfer, not attempt to simulate months of ageing in one day.
Variant 08.09
Fleet-of-Kits Comparator
Engineering purpose: Creates a richer shared Kaggle dataset.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensequadrature encoder/position feedback; conditioned 0–3.3 V current-sense chann…
Actuate6–12 V geared DC motor with encoder; 3.3-V-logic H-bridge rated above stall c…
Fixturelive repeat-cycle rig; organiser/peer export bundle from at least three addit…
Protectcurrent-limited 6–12 V DC supply; inline fuse plus spare fuses; latching E-st…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × multi-rig dataset with device_id and calibration metadata
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Degradation is simulated reversibly; the team must not damage the motor, encoder or bearings. Verify the complete EQ-08-09 manifest before data collection.
1 · Scenario and student challenge
Compare several student rigs while accounting for unit-to-unit variation. In plain language, adapt CyclePassport — Actuator Health and Maintenance Evidence System so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Creates a richer shared Kaggle dataset.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M + the named safe mechanical/condition fixture. Begin with the repeatable H753-M actuator cycle rig and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record cycle number, travel time, current statistics, speed/error, temperature, saturation, retries and maintenance/event labels. Treat one complete actuator cycle, grouped within a device/session history as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Per-unit normalisation and anomaly detection. First implement the parent baseline—fixed health limits or deviation from the first healthy-cycle mean—and then compare two algorithms from the faculty-issued ML whitelist. Train or set the threshold using healthy/training data only. Report event recall, false alarms per normal run and detection delay; show where the method treats a new but valid regime as abnormal. Produce a event timeline with anomaly score, threshold and false-alarm examples.
5 · Embedded integration and safe response
The host may return only HEALTHY, WATCH, INSPECT, SERVICE_SOON or STOP_USE, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with normal load, temperature or direction variation that looks like degradation. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 08.09 — Fleet-of-Kits Comparator”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M + the named safe mechanical/condition fixtureanomaly/noveltyrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P08 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Fleet-of-Kits Comparator is a syllabus-scaled physical analogue of the need evidenced by GC02 · PHM 2008 Challenge: Compare several student rigs while accounting for unit-to-unit variation. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needUse degradation trajectories to estimate remaining operational life on a withheld test set; the challenge remains available for comparison.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Connect sensor history to an actionable maintenance event and report error by operating context, not only an aggregate score.
The handbook reduces the horizon to transparent health evidence and uses organiser-provided history so it remains a 24-hour task.
Implementation modeOrganiser-supported assignmentMay be issued only after the named seed history, reference specimens, calibration set or controlled fixture is prepared.
Required organiser provisionComplete before team allocationMake historical cycle data mandatory organiser input. Live cycles should validate transfer, not attempt to simulate months of ageing in one day.
Variant 08.10
Inspection-Priority Ranker
Engineering purpose: Adds asset-management relevance without unsupported RUL claims.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensequadrature encoder/position feedback; conditioned 0–3.3 V current-sense chann…
Actuate6–12 V geared DC motor with encoder; 3.3-V-logic H-bridge rated above stall c…
Fixturelive repeat-cycle rig; organiser passport bundle for at least four candidate…
Protectcurrent-limited 6–12 V DC supply; inline fuse plus spare fuses; latching E-st…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × labelled inspection-priority seed history spanning several rigs
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Degradation is simulated reversibly; the team must not damage the motor, encoder or bearings. Verify the complete EQ-08-10 manifest before data collection.
1 · Scenario and student challenge
Rank multiple actuators/rigs by evidence-based inspection urgency. In plain language, adapt CyclePassport — Actuator Health and Maintenance Evidence System so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Adds asset-management relevance without unsupported RUL claims.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M + the named safe mechanical/condition fixture. Begin with the repeatable H753-M actuator cycle rig and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record cycle number, travel time, current statistics, speed/error, temperature, saturation, retries and maintenance/event labels. Treat one complete actuator cycle, grouped within a device/session history as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Risk-score regression/classification. First implement the parent baseline—fixed health limits or deviation from the first healthy-cycle mean—and then compare two algorithms from the faculty-issued ML whitelist. Report MAE and RMSE on whole held-out runs, show predicted-versus-measured values, and inspect error by operating condition. If the target is converted to a safe/unsafe decision, also report missed-unsafe and unnecessary-conservative actions. Produce a predicted-versus-measured plot with residuals by operating condition.
5 · Embedded integration and safe response
The host may return only HEALTHY, WATCH, INSPECT, SERVICE_SOON or STOP_USE, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with normal load, temperature or direction variation that looks like degradation. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 08.10 — Inspection-Priority Ranker”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M + the named safe mechanical/condition fixtureregression/outcomerun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P08 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Inspection-Priority Ranker is a syllabus-scaled physical analogue of the need evidenced by GC02 · PHM 2008 Challenge: Rank multiple actuators/rigs by evidence-based inspection urgency. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needUse degradation trajectories to estimate remaining operational life on a withheld test set; the challenge remains available for comparison.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Connect sensor history to an actionable maintenance event and report error by operating context, not only an aggregate score.
The handbook reduces the horizon to transparent health evidence and uses organiser-provided history so it remains a 24-hour task.
Implementation modeOrganiser-supported assignmentMay be issued only after the named seed history, reference specimens, calibration set or controlled fixture is prepared.
Required organiser provisionComplete before team allocationMake historical cycle data mandatory organiser input. Live cycles should validate transfer, not attempt to simulate months of ageing in one day.
Problem 09 · 10 variants · Sensing, environment and smart product intelligence
Assigned Faculty Master pair for P09: one nominated ESD Faculty Master and one nominated ML Faculty Master shall jointly master this parent problem and variants V1-V10. The ESD Master owns hardware, firmware, control, communication and safety verification; the ML Master owns data, baselines, models, validation and bounded decision-policy verification. Together they teach and guide ten teams (one for each variant and up to 40 students), supervise five teams in Wave A and five in Wave B, witness integration and sign every final evaluation.
The problem
Simple thermostat logic waits until temperature crosses a threshold and often oscillates between ON and OFF. In cabinets, incubator simulators, storage boxes and equipment enclosures, recent heater/fan state and temperature slope provide early evidence of where the temperature is heading. The challenge is to build a safe thermal product that predicts near-future state and selects a bounded actuator mode.
Smart embedded product to build
Build a tabletop H753 thermal enclosure using two calibrated temperature/context channels and a low-voltage fan or approved low-power heat source. The NUCLEO-H753ZI samples at a justified fixed period, runs hysteresis/hard-limit protection, drives the H753-A stage and logs actuator state. The host predicts a declared future horizon or risk band and recommends only the applicable canonical P09 operating command; firmware keeps thermostat and absolute-limit authority.
NUCLEO-H753ZI realization and issued pack
NUCLEO-H753ZI / MB1364E with H753-S and H753-A packs
two calibrated temperature/context ADC channels; LDR/door input optional
low-voltage fan through MOSFET/PWM or relay; safe thermal mass or enclosure fixture
slow fixed control timer with independent high-temperature limit and hysteresis baseline
USART3 VCP for windows/predictions; optional local Ethernet mirror as controlled stretch
verified 3.3-V I²C display or board LEDs
no open flame, mains heater or uncontrolled heat source
Intelligence to incorporate
Use current temperature, slope, rolling mean/range, actuator duty, time since switching and initial/ambient condition. Compare fixed hysteresis with linear/tree regression or logistic/tree classification. Evaluate horizon MAE, limit violations, overshoot, actuator switching count and time/energy proxy.
Permitted output/action set
ECO · NORMAL · BOOST · EMERGENCY_COOL · HEAT_INHIBIT
Canonical family command contract: every parent brief, variant, host message and MCU acknowledgement for P09 shall use these exact identifiers. A variant may use only the applicable subset; it shall not introduce a synonym.
Core problem equipment · EQ-09-CORE
Complete equipment required for one core-problem team
Standalone family BOM. This list supports the parent problem itself. An allocated variant uses its own complete table later in this card. A component mentioned again in the fixture description is the same mounted unit, not another copy.
4 students; 3 by approved exception1 H753 board1 team laptopquantities per team
Controller1 H753 board + 1 laptop
Sensecalibrated LM35-class channels for process and ambient/reference temperature;…
Actuate5/12 V DC cooling fan with 3.3-V-compatible MOSFET PWM stage and flyback prot…
Fixturesmall non-flammable enclosure with removable lid/air vent and safe thermal ma…
Protectcurrent-limited 5/12 V supply sized for fan and heat source; separately fused…
System block
Complete quantity and equipment per team
Purpose / acceptance condition
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Release-to-team condition: No mains, flame or exposed hot surface; independent thermostat/thermal fuse overrides firmware and ML. The organiser signs the electrical, mechanical and communication acceptance checklist before H0:00.
Not duplicated inside the kit: supervised rework tools and the oscilloscope/logic-analyser station are shared at the ratio stated above. Everything else in this table is issued to, reserved for, or digitally assigned to this team.
Controlled self-learning extension
Recommended Use the onboard Ethernet interface only as a local UDP telemetry mirror and measure packet loss/latency against USART3 VCP. Control remains local and no network path may carry unrestricted actuation.
System safety and non-negotiable boundary
Only low-voltage approved heating/cooling is allowed. Firmware maintains absolute temperature limits, minimum relay switching interval, watchdog and host timeout. ML cannot suppress the hard thermostat.
Student interpretation — what this challenge really asks
A fan or heater that reacts only after a threshold is crossed wastes energy or responds too late. Students forecast the near-term thermal state and choose a bounded operating mode while firmware keeps absolute safety authority.
Independent data unitone thermal episode containing a load change and subsequent response.
Closest misleading casea brief sensor or ambient disturbance that should not trigger a prolonged high-power response.
Definition of successStudents must maintain the declared thermal envelope with earlier or more efficient action than the rule baseline.
Visual system blueprint
Physical processSmall thermal environmentGenerate labelled, safe and repeatable conditions.
Observeprocess and ambient temperature, temperature slope, fan/heater/relay statePreserve units, timestamps, run identity and signal quality.
H753 responsibilityControl and protectsample calibrated sensors, control the low-voltage actuator with dwell limits and enforce hard temperature bounds.
Host intelligenceLearn the distinctionforecast temperature or classify stable, rising and high-risk thermal states.
Bounded outcomeECO · NORMAL · BOOST · EMERGENCY_COOL · HEAT_INHIBITMCU validates, acknowledges and may refuse the request.
Recommended build journey
Make the process repeatableAssemble the H753-S + H753-A low-voltage fan/heater demonstration chamber; define reference and target conditions before collecting data.
Prove deterministic firmwareSample calibrated sensors, control the low-voltage actuator with dwell limits and enforce hard temperature bounds. Demonstrate every hard limit before connecting ML.
Build trustworthy trialsTreat one thermal episode containing a load change and subsequent response as independent; calibrate, label and split by run/session.
Beat a real baselineCompare thermostat hysteresis or persistence/linear-slope forecast with two syllabus-approved classical models.
Close and challenge the loopReturn only the applicable subset of ECO · NORMAL · BOOST · EMERGENCY_COOL · HEAT_INHIBIT; test the target, nearest confuser, stale command and host loss.
Definition of done
Firmware controls safely before, during and after host connection.
Held-out results report MAE/RMSE or risk recall, comfort/safety violations and actuator on-time.
Portfolio shows temperature trajectory with forecast horizon, selected mode and threshold baseline and one honest failure case.
Problem-specific evidence at the common reviews
R1 · Design
Define enclosure, safe thermal range, horizon, actuator modes, disturbance plan and acceptance metrics.
R2 · Embedded
Demonstrate calibrated LM35 acquisition, actuator control, LCD, timer logging and hard thermostat.
R3 · Data
Submit heating/cooling trajectories, grouped splits and hysteresis/persistence baseline.
R4 · ML
Show forecast/risk model, error by operating state and mode-selection policy.
R5 · Integration
Integrate predictive control and pass load/door/light disturbance plus host-loss tests.
Final
Maintain a blind temperature profile with fewer violations or switches than the baseline and explain the trade-off.
Portfolio/Kaggle outcome
Kaggle portfolio: thermal trajectories grouped by experiment, forecast notebook, hysteresis baseline, safety/comfort trade-off and a reproducible physical setup diagram.
Industry alignment and validation basis
ThermoPilot: external references and required evidence
The listed sources establish relevance, test discipline and implementation precedent. They do not modify the common syllabus boundary, safety rules or 100-mark assessment rubric.
Family implementation profile
Variant availability: 4 standard assignment(s); 6 organiser-supported assignment(s).
Public evidence: reproducible firmware, protocol, dataset, notebook/model, test report and demonstration video.
What the external benchmark confirms
The problem has a recognisable industrial or challenge analogue, a measurable data task, a defensible embedded implementation and a safe operational decision. Every one of its ten variants is mapped separately below.
Condition before team allocation
Issue a safe low-power chamber plus seed thermal episodes covering ambient and enclosure-state changes.
Standardise HVAC control sequences to improve energy efficiency, performance and control stability while enabling real-time fault detection and diagnostics.
Keep hard sequences deterministic, compare energy and control quality, and test sensor/actuator faults against functional behaviour.
Frame cyber-physical systems as integrations of logical, physical and human components with concerns including trustworthiness and interoperability.
Evaluate the complete sense–decide–act system, its interfaces and failure behaviour—not a disconnected model or dashboard.
Open the 10 fully elaborated student variant briefs
Choose only the variant allocated to your team. Read it together with the parent problem above: the card expands the experimental delta, while every hardware, safety, integration and review requirement of the family remains active.
Variant 09.01
Electronics-Cabinet Thermal Pilot
Engineering purpose: Direct industrial embedded relevance.
ChangeProtect a small enclosure under variable internal load.
Observeprocess and ambient temperature, temperature slope, fan/heater/relay…
LearnTemperature-horizon regression.
DecideECO, NORMAL, BOOST, EMERGENCY_COOL or HEAT_INHIBIT
ProveMAE/RMSE or risk recall, comfort/safety violations and actuator…
Variant equipment · EQ-09-01
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensecalibrated LM35-class channels for process and ambient/reference temperature;…
Actuate5/12 V DC cooling fan with 3.3-V-compatible MOSFET PWM stage and flyback prot…
Fixturevented electronics-cabinet mock enclosure; 5 W low-voltage heat-load resistor…
Protectcurrent-limited 5/12 V supply sized for fan and heat source; separately fused…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: No mains, flame or exposed hot surface; independent thermostat/thermal fuse overrides firmware and ML. Verify the complete EQ-09-01 manifest before data collection.
1 · Scenario and student challenge
Protect a small enclosure under variable internal load. In plain language, adapt ThermoPilot — Predictive Thermal Environment Controller so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Direct industrial embedded relevance.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-S + H753-A + the named safe mechanical/condition fixture. Begin with the H753-S + H753-A low-voltage fan/heater demonstration chamber and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record process and ambient temperature, temperature slope, fan/heater/relay state, PWM, light/load proxy and elapsed time. Treat one thermal episode containing a load change and subsequent response as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Temperature-horizon regression. First implement the parent baseline—thermostat hysteresis or persistence/linear-slope forecast—and then compare two algorithms from the faculty-issued ML whitelist. Report MAE and RMSE on whole held-out runs, show predicted-versus-measured values, and inspect error by operating condition. If the target is converted to a safe/unsafe decision, also report missed-unsafe and unnecessary-conservative actions. Produce a predicted-versus-measured plot with residuals by operating condition.
5 · Embedded integration and safe response
The host may return only ECO, NORMAL, BOOST, EMERGENCY_COOL or HEAT_INHIBIT, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a brief sensor or ambient disturbance that should not trigger a prolonged high-power response. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 09.01 — Electronics-Cabinet Thermal Pilot”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-S + H753-A + the named safe mechanical/condition fixtureregression/outcomerun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P09 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Electronics-Cabinet Thermal Pilot is a syllabus-scaled physical analogue of the need evidenced by GC04 · ASHRAE – Great Energy Predictor III: Protect a small enclosure under variable internal load. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needPredict building energy consumption from historical meter and weather data using public and private test evaluation.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Define repeatable response-quality measures and compare profiles on identical operating points, disturbances and acceptance limits.
Students use taught overshoot, settling, error, saturation and recovery measures rather than reproducing the full ASHRAE metric.
Implementation modeOrganiser-supported assignmentMay be issued only after the named seed history, reference specimens, calibration set or controlled fixture is prepared.
Required organiser provisionComplete before team allocationIssue a safe low-power chamber plus seed thermal episodes covering ambient and enclosure-state changes.
Variant 09.02
Battery-Compartment Emulator
Engineering purpose: Portfolio value without handling real battery hazards.
ChangeTreat a low-power lamp as heat load and model conservative thermal risk.
Observeprocess and ambient temperature, temperature slope, fan/heater/relay…
LearnRisk classification.
DecideECO, NORMAL, BOOST, EMERGENCY_COOL or HEAT_INHIBIT
ProveMAE/RMSE or risk recall, comfort/safety violations and actuator…
Variant equipment · EQ-09-02
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensecalibrated LM35-class channels for process and ambient/reference temperature;…
Actuate5/12 V DC cooling fan with 3.3-V-compatible MOSFET PWM stage and flyback prot…
Fixtureinsulated battery-compartment emulator with inert thermal mass; guarded low-p…
Protectcurrent-limited 5/12 V supply sized for fan and heat source; separately fused…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: No mains, flame or exposed hot surface; independent thermostat/thermal fuse overrides firmware and ML. Verify the complete EQ-09-02 manifest before data collection.
1 · Scenario and student challenge
Treat a low-power lamp as heat load and model conservative thermal risk. In plain language, adapt ThermoPilot — Predictive Thermal Environment Controller so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Portfolio value without handling real battery hazards.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-S + H753-A + the named safe mechanical/condition fixture. Begin with the H753-S + H753-A low-voltage fan/heater demonstration chamber and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record process and ambient temperature, temperature slope, fan/heater/relay state, PWM, light/load proxy and elapsed time. Treat one thermal episode containing a load change and subsequent response as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Risk classification. First implement the parent baseline—thermostat hysteresis or persistence/linear-slope forecast—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only ECO, NORMAL, BOOST, EMERGENCY_COOL or HEAT_INHIBIT, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a brief sensor or ambient disturbance that should not trigger a prolonged high-power response. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 09.02 — Battery-Compartment Emulator”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-S + H753-A + the named safe mechanical/condition fixtureclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P09 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Battery-Compartment Emulator is a syllabus-scaled physical analogue of the need evidenced by GC04 · ASHRAE – Great Energy Predictor III: Treat a low-power lamp as heat load and model conservative thermal risk. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needPredict building energy consumption from historical meter and weather data using public and private test evaluation.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Define repeatable response-quality measures and compare profiles on identical operating points, disturbances and acceptance limits.
Students use taught overshoot, settling, error, saturation and recovery measures rather than reproducing the full ASHRAE metric.
Implementation modeOrganiser-supported assignmentMay be issued only after the named seed history, reference specimens, calibration set or controlled fixture is prepared.
Required organiser provisionComplete before team allocationIssue a safe low-power chamber plus seed thermal episodes covering ambient and enclosure-state changes.
Variant 09.03
Greenhouse-Microbox Controller
Engineering purpose: Combines two taught sensors meaningfully.
ChangeUse LDR as sunlight proxy and fan as cooling.
Observeprocess and ambient temperature, temperature slope, fan/heater/relay…
LearnForecast conditioned on light level.
DecideECO, NORMAL, BOOST, EMERGENCY_COOL or HEAT_INHIBIT
ProveMAE/RMSE or risk recall, comfort/safety violations and actuator…
Variant equipment · EQ-09-03
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensecalibrated LM35-class channels for process and ambient/reference temperature;…
Actuate5/12 V DC cooling fan with 3.3-V-compatible MOSFET PWM stage and flyback prot…
Fixturetransparent greenhouse microbox; LDR sunlight proxy, fixed LED lamp, fan and…
Protectcurrent-limited 5/12 V supply sized for fan and heat source; separately fused…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: No mains, flame or exposed hot surface; independent thermostat/thermal fuse overrides firmware and ML. Verify the complete EQ-09-03 manifest before data collection.
1 · Scenario and student challenge
Use LDR as sunlight proxy and fan as cooling. In plain language, adapt ThermoPilot — Predictive Thermal Environment Controller so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Combines two taught sensors meaningfully.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-S + H753-A + the named safe mechanical/condition fixture. Begin with the H753-S + H753-A low-voltage fan/heater demonstration chamber and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record process and ambient temperature, temperature slope, fan/heater/relay state, PWM, light/load proxy and elapsed time. Treat one thermal episode containing a load change and subsequent response as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Forecast conditioned on light level. First implement the parent baseline—thermostat hysteresis or persistence/linear-slope forecast—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a temperature trajectory with forecast horizon, selected mode and threshold baseline.
5 · Embedded integration and safe response
The host may return only ECO, NORMAL, BOOST, EMERGENCY_COOL or HEAT_INHIBIT, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a brief sensor or ambient disturbance that should not trigger a prolonged high-power response. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 09.03 — Greenhouse-Microbox Controller”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-S + H753-A + the named safe mechanical/condition fixtureclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P09 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Greenhouse-Microbox Controller is a syllabus-scaled physical analogue of the need evidenced by GC04 · ASHRAE – Great Energy Predictor III: Use LDR as sunlight proxy and fan as cooling. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needPredict building energy consumption from historical meter and weather data using public and private test evaluation.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Define repeatable response-quality measures and compare profiles on identical operating points, disturbances and acceptance limits.
Students use taught overshoot, settling, error, saturation and recovery measures rather than reproducing the full ASHRAE metric.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationIssue a safe low-power chamber plus seed thermal episodes covering ambient and enclosure-state changes.
Variant 09.04
Cold-Box Warming Monitor
Engineering purpose: Creates cold-chain analytics with safe hardware.
ChangePredict loss of cool condition after opening or external heat…
Observeprocess and ambient temperature, temperature slope, fan/heater/relay…
LearnTime-to-threshold regression.
DecideECO, NORMAL, BOOST, EMERGENCY_COOL or HEAT_INHIBIT
ProveMAE/RMSE or risk recall, comfort/safety violations and actuator…
Variant equipment · EQ-09-04
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensecalibrated LM35-class channels for process and ambient/reference temperature;…
Actuate5/12 V circulation fan through protected MOSFET driver; no refrigeration unit…
Fixtureinsulated cold-box emulator with lid switch; reusable sealed cool packs and s…
Protectcurrent-limited 5/12 V fan supply; fused fan branch and hardware fan-isolatio…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: No mains, flame or exposed hot surface; independent thermostat/thermal fuse overrides firmware and ML. Verify the complete EQ-09-04 manifest before data collection.
1 · Scenario and student challenge
Predict loss of cool condition after opening or external heat disturbance; no refrigeration required. In plain language, adapt ThermoPilot — Predictive Thermal Environment Controller so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Creates cold-chain analytics with safe hardware.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-S + H753-A + the named safe mechanical/condition fixture. Begin with the H753-S + H753-A low-voltage fan/heater demonstration chamber and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record process and ambient temperature, temperature slope, fan/heater/relay state, PWM, light/load proxy and elapsed time. Treat one thermal episode containing a load change and subsequent response as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Time-to-threshold regression. First implement the parent baseline—thermostat hysteresis or persistence/linear-slope forecast—and then compare two algorithms from the faculty-issued ML whitelist. Report MAE and RMSE on whole held-out runs, show predicted-versus-measured values, and inspect error by operating condition. If the target is converted to a safe/unsafe decision, also report missed-unsafe and unnecessary-conservative actions. Produce a predicted-versus-measured plot with residuals by operating condition.
5 · Embedded integration and safe response
The host may return only ECO, NORMAL, BOOST, EMERGENCY_COOL or HEAT_INHIBIT, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a brief sensor or ambient disturbance that should not trigger a prolonged high-power response. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 09.04 — Cold-Box Warming Monitor”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-S + H753-A + the named safe mechanical/condition fixtureregression/outcomerun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P09 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Cold-Box Warming Monitor is a syllabus-scaled physical analogue of the need evidenced by GC04 · ASHRAE – Great Energy Predictor III: Predict loss of cool condition after opening or external heat disturbance; no refrigeration required. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needPredict building energy consumption from historical meter and weather data using public and private test evaluation.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Define repeatable response-quality measures and compare profiles on identical operating points, disturbances and acceptance limits.
Students use taught overshoot, settling, error, saturation and recovery measures rather than reproducing the full ASHRAE metric.
Implementation modeOrganiser-supported assignmentMay be issued only after the named seed history, reference specimens, calibration set or controlled fixture is prepared.
Required organiser provisionComplete before team allocationIssue a safe low-power chamber plus seed thermal episodes covering ambient and enclosure-state changes.
Variant 09.05
Motor-Enclosure Cooling Controller
Engineering purpose: Couples actuator operation and environment.
ChangeUse motor duty/current as internal heat input.
Observeprocess and ambient temperature, temperature slope, fan/heater/relay…
LearnTemperature forecast and cooling-mode classification.
DecideECO, NORMAL, BOOST, EMERGENCY_COOL or HEAT_INHIBIT
ProveMAE/RMSE or risk recall, comfort/safety violations and actuator…
Variant equipment · EQ-09-05
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
SenseLM35-class temperature channels: enclosure and ambient; 0–3.3 V current-sense…
Actuategeared DC motor plus 3.3-V H-bridge; cooling fan plus protected MOSFET driver
Fixtureventilated motor enclosure; small geared DC motor, H-bridge, encoder/current…
Protectcurrent-limited 6–12 V supply sized for motor and fan; separately fused motor…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: No mains, flame or exposed hot surface; independent thermostat/thermal fuse overrides firmware and ML. Verify the complete EQ-09-05 manifest before data collection.
1 · Scenario and student challenge
Use motor duty/current as internal heat input. In plain language, adapt ThermoPilot — Predictive Thermal Environment Controller so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Couples actuator operation and environment.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-S + H753-A + the named safe mechanical/condition fixture. Begin with the H753-S + H753-A low-voltage fan/heater demonstration chamber and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record process and ambient temperature, temperature slope, fan/heater/relay state, PWM, light/load proxy and elapsed time. Treat one thermal episode containing a load change and subsequent response as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Temperature forecast and cooling-mode classification. First implement the parent baseline—thermostat hysteresis or persistence/linear-slope forecast—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only ECO, NORMAL, BOOST, EMERGENCY_COOL or HEAT_INHIBIT, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a brief sensor or ambient disturbance that should not trigger a prolonged high-power response. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 09.05 — Motor-Enclosure Cooling Controller”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-S + H753-A + the named safe mechanical/condition fixtureclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P09 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Motor-Enclosure Cooling Controller is a syllabus-scaled physical analogue of the need evidenced by GC04 · ASHRAE – Great Energy Predictor III: Use motor duty/current as internal heat input. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needPredict building energy consumption from historical meter and weather data using public and private test evaluation.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Define repeatable response-quality measures and compare profiles on identical operating points, disturbances and acceptance limits.
Students use taught overshoot, settling, error, saturation and recovery measures rather than reproducing the full ASHRAE metric.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationIssue a safe low-power chamber plus seed thermal episodes covering ambient and enclosure-state changes.
Variant 09.06
Server-Rack Miniature Controller
Engineering purpose: Connects embedded control to data-centre operations.
ChangeRepresent compute load by relay-controlled low-voltage heat source.
Observeprocess and ambient temperature, temperature slope, fan/heater/relay…
LearnRisk class plus fan-mode selection.
DecideECO, NORMAL, BOOST, EMERGENCY_COOL or HEAT_INHIBIT
ProveMAE/RMSE or risk recall, comfort/safety violations and actuator…
Variant equipment · EQ-09-06
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensecalibrated LM35-class channels for process and ambient/reference temperature;…
Actuate5/12 V DC cooling fan with 3.3-V-compatible MOSFET PWM stage and flyback prot…
Fixtureminiature server-rack enclosure; independently switchable 5 V resistive/LED h…
Protectcurrent-limited 5/12 V supply sized for fan and heat source; separately fused…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: No mains, flame or exposed hot surface; independent thermostat/thermal fuse overrides firmware and ML. Verify the complete EQ-09-06 manifest before data collection.
1 · Scenario and student challenge
Represent compute load by relay-controlled low-voltage heat source. In plain language, adapt ThermoPilot — Predictive Thermal Environment Controller so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Connects embedded control to data-centre operations.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-S + H753-A + the named safe mechanical/condition fixture. Begin with the H753-S + H753-A low-voltage fan/heater demonstration chamber and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record process and ambient temperature, temperature slope, fan/heater/relay state, PWM, light/load proxy and elapsed time. Treat one thermal episode containing a load change and subsequent response as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Risk class plus fan-mode selection. First implement the parent baseline—thermostat hysteresis or persistence/linear-slope forecast—and then compare two algorithms from the faculty-issued ML whitelist. Report correct/feasible selection rate, constraint violations and improvement over the fixed policy. A choice is wrong if it violates a declared current, timing, thermal or control-quality bound even when it is fast. Produce a candidate-outcome/constraint table showing why the selected option is feasible.
5 · Embedded integration and safe response
The host may return only ECO, NORMAL, BOOST, EMERGENCY_COOL or HEAT_INHIBIT, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a brief sensor or ambient disturbance that should not trigger a prolonged high-power response. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 09.06 — Server-Rack Miniature Controller”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-S + H753-A + the named safe mechanical/condition fixtureclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P09 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Server-Rack Miniature Controller is a syllabus-scaled physical analogue of the need evidenced by GC04 · ASHRAE – Great Energy Predictor III: Represent compute load by relay-controlled low-voltage heat source. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needPredict building energy consumption from historical meter and weather data using public and private test evaluation.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Define repeatable response-quality measures and compare profiles on identical operating points, disturbances and acceptance limits.
Students use taught overshoot, settling, error, saturation and recovery measures rather than reproducing the full ASHRAE metric.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationIssue a safe low-power chamber plus seed thermal episodes covering ambient and enclosure-state changes.
ChangePrioritise slow, low-switching control and exposure limits.
Observeprocess and ambient temperature, temperature slope, fan/heater/relay…
LearnForecast plus constraint-aware mode choice.
DecideECO, NORMAL, BOOST, EMERGENCY_COOL or HEAT_INHIBIT
ProveMAE/RMSE or risk recall, comfort/safety violations and actuator…
Variant equipment · EQ-09-07
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensecalibrated LM35-class channels for process and ambient/reference temperature;…
Actuate5/12 V DC cooling fan with 3.3-V-compatible MOSFET PWM stage and flyback prot…
Fixtureclear museum-case emulator; low-watt light/heat stimulus, fan and cumulative…
Protectcurrent-limited 5/12 V supply sized for fan and heat source; separately fused…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: No mains, flame or exposed hot surface; independent thermostat/thermal fuse overrides firmware and ML. Verify the complete EQ-09-07 manifest before data collection.
1 · Scenario and student challenge
Prioritise slow, low-switching control and exposure limits. In plain language, adapt ThermoPilot — Predictive Thermal Environment Controller so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Adds conservation-oriented requirements.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-S + H753-A + the named safe mechanical/condition fixture. Begin with the H753-S + H753-A low-voltage fan/heater demonstration chamber and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record process and ambient temperature, temperature slope, fan/heater/relay state, PWM, light/load proxy and elapsed time. Treat one thermal episode containing a load change and subsequent response as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Forecast plus constraint-aware mode choice. First implement the parent baseline—thermostat hysteresis or persistence/linear-slope forecast—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a temperature trajectory with forecast horizon, selected mode and threshold baseline.
5 · Embedded integration and safe response
The host may return only ECO, NORMAL, BOOST, EMERGENCY_COOL or HEAT_INHIBIT, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a brief sensor or ambient disturbance that should not trigger a prolonged high-power response. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 09.07 — Museum-Case Thermal Protector”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-S + H753-A + the named safe mechanical/condition fixtureclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P09 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Museum-Case Thermal Protector is a syllabus-scaled physical analogue of the need evidenced by GC04 · ASHRAE – Great Energy Predictor III: Prioritise slow, low-switching control and exposure limits. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needPredict building energy consumption from historical meter and weather data using public and private test evaluation.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Define repeatable response-quality measures and compare profiles on identical operating points, disturbances and acceptance limits.
Students use taught overshoot, settling, error, saturation and recovery measures rather than reproducing the full ASHRAE metric.
Implementation modeOrganiser-supported assignmentMay be issued only after the named seed history, reference specimens, calibration set or controlled fixture is prepared.
Required organiser provisionComplete before team allocationIssue a safe low-power chamber plus seed thermal episodes covering ambient and enclosure-state changes.
Variant 09.08
Food-Warmer Simulator
Engineering purpose: Demonstrates process temperature control.
ChangeMaintain an approved safe lab temperature band in a mock chamber, not…
Observeprocess and ambient temperature, temperature slope, fan/heater/relay…
LearnPass/fail horizon classification.
DecideECO, NORMAL, BOOST, EMERGENCY_COOL or HEAT_INHIBIT
ProveMAE/RMSE or risk recall, comfort/safety violations and actuator…
Variant equipment · EQ-09-08
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensecalibrated LM35-class channels for process and ambient/reference temperature;…
Actuate5/12 V DC cooling fan with 3.3-V-compatible MOSFET PWM stage and flyback prot…
Fixturefood-warmer simulator using an empty metal thermal mass—no food; 5 V ≤5 W hea…
Protectcurrent-limited 5/12 V supply sized for fan and heat source; separately fused…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: No mains, flame or exposed hot surface; independent thermostat/thermal fuse overrides firmware and ML. Verify the complete EQ-09-08 manifest before data collection.
1 · Scenario and student challenge
Maintain an approved safe lab temperature band in a mock chamber, not actual food. In plain language, adapt ThermoPilot — Predictive Thermal Environment Controller so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Demonstrates process temperature control.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-S + H753-A + the named safe mechanical/condition fixture. Begin with the H753-S + H753-A low-voltage fan/heater demonstration chamber and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record process and ambient temperature, temperature slope, fan/heater/relay state, PWM, light/load proxy and elapsed time. Treat one thermal episode containing a load change and subsequent response as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Pass/fail horizon classification. First implement the parent baseline—thermostat hysteresis or persistence/linear-slope forecast—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only ECO, NORMAL, BOOST, EMERGENCY_COOL or HEAT_INHIBIT, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a brief sensor or ambient disturbance that should not trigger a prolonged high-power response. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 09.08 — Food-Warmer Simulator”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-S + H753-A + the named safe mechanical/condition fixtureclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P09 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Food-Warmer Simulator is a syllabus-scaled physical analogue of the need evidenced by GC04 · ASHRAE – Great Energy Predictor III: Maintain an approved safe lab temperature band in a mock chamber, not actual food. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needPredict building energy consumption from historical meter and weather data using public and private test evaluation.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Define repeatable response-quality measures and compare profiles on identical operating points, disturbances and acceptance limits.
Students use taught overshoot, settling, error, saturation and recovery measures rather than reproducing the full ASHRAE metric.
Implementation modeOrganiser-supported assignmentMay be issued only after the named seed history, reference specimens, calibration set or controlled fixture is prepared.
Required organiser provisionComplete before team allocationIssue a safe low-power chamber plus seed thermal episodes covering ambient and enclosure-state changes.
Variant 09.09
Two-Regime Thermal Model
Engineering purpose: Tests distribution shift across physical configurations.
Observeprocess and ambient temperature, temperature slope, fan/heater/relay…
LearnClassification/regression with regime feature.
DecideECO, NORMAL, BOOST, EMERGENCY_COOL or HEAT_INHIBIT
ProveMAE/RMSE or risk recall, comfort/safety violations and actuator…
Variant equipment · EQ-09-09
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensecalibrated LM35-class channels for process and ambient/reference temperature;…
Actuate5/12 V DC cooling fan with 3.3-V-compatible MOSFET PWM stage and flyback prot…
Fixturethermal enclosure with removable cover; lid-state microswitch and identical O…
Protectcurrent-limited 5/12 V supply sized for fan and heat source; separately fused…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: No mains, flame or exposed hot surface; independent thermostat/thermal fuse overrides firmware and ML. Verify the complete EQ-09-09 manifest before data collection.
1 · Scenario and student challenge
Model covered versus open enclosure states. In plain language, adapt ThermoPilot — Predictive Thermal Environment Controller so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Tests distribution shift across physical configurations.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-S + H753-A + the named safe mechanical/condition fixture. Begin with the H753-S + H753-A low-voltage fan/heater demonstration chamber and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record process and ambient temperature, temperature slope, fan/heater/relay state, PWM, light/load proxy and elapsed time. Treat one thermal episode containing a load change and subsequent response as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Classification/regression with regime feature. First implement the parent baseline—thermostat hysteresis or persistence/linear-slope forecast—and then compare two algorithms from the faculty-issued ML whitelist. Report MAE and RMSE on whole held-out runs, show predicted-versus-measured values, and inspect error by operating condition. If the target is converted to a safe/unsafe decision, also report missed-unsafe and unnecessary-conservative actions. Produce a predicted-versus-measured plot with residuals by operating condition.
5 · Embedded integration and safe response
The host may return only ECO, NORMAL, BOOST, EMERGENCY_COOL or HEAT_INHIBIT, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a brief sensor or ambient disturbance that should not trigger a prolonged high-power response. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 09.09 — Two-Regime Thermal Model”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-S + H753-A + the named safe mechanical/condition fixtureregression/outcomerun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P09 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Two-Regime Thermal Model is a syllabus-scaled physical analogue of the need evidenced by GC04 · ASHRAE – Great Energy Predictor III: Model covered versus open enclosure states. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needPredict building energy consumption from historical meter and weather data using public and private test evaluation.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Define repeatable response-quality measures and compare profiles on identical operating points, disturbances and acceptance limits.
Students use taught overshoot, settling, error, saturation and recovery measures rather than reproducing the full ASHRAE metric.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationIssue a safe low-power chamber plus seed thermal episodes covering ambient and enclosure-state changes.
Variant 09.10
Thermal-Recovery Planner
Engineering purpose: Supports operational planning instead of only control.
ChangePredict time to return to safe range after an imposed disturbance.
Observeprocess and ambient temperature, temperature slope, fan/heater/relay…
LearnRecovery-time regression.
DecideECO, NORMAL, BOOST, EMERGENCY_COOL or HEAT_INHIBIT
ProveMAE/RMSE or risk recall, comfort/safety violations and actuator…
Variant equipment · EQ-09-10
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensecalibrated LM35-class channels for process and ambient/reference temperature;…
Actuate5/12 V DC cooling fan with 3.3-V-compatible MOSFET PWM stage and flyback prot…
Fixturethermal enclosure and cooling stand; approved heat disturbance, fan and marke…
Protectcurrent-limited 5/12 V supply sized for fan and heat source; separately fused…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: No mains, flame or exposed hot surface; independent thermostat/thermal fuse overrides firmware and ML. Verify the complete EQ-09-10 manifest before data collection.
1 · Scenario and student challenge
Predict time to return to safe range after an imposed disturbance. In plain language, adapt ThermoPilot — Predictive Thermal Environment Controller so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Supports operational planning instead of only control.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-S + H753-A + the named safe mechanical/condition fixture. Begin with the H753-S + H753-A low-voltage fan/heater demonstration chamber and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record process and ambient temperature, temperature slope, fan/heater/relay state, PWM, light/load proxy and elapsed time. Treat one thermal episode containing a load change and subsequent response as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Recovery-time regression. First implement the parent baseline—thermostat hysteresis or persistence/linear-slope forecast—and then compare two algorithms from the faculty-issued ML whitelist. Report MAE and RMSE on whole held-out runs, show predicted-versus-measured values, and inspect error by operating condition. If the target is converted to a safe/unsafe decision, also report missed-unsafe and unnecessary-conservative actions. Produce a predicted-versus-measured plot with residuals by operating condition.
5 · Embedded integration and safe response
The host may return only ECO, NORMAL, BOOST, EMERGENCY_COOL or HEAT_INHIBIT, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a brief sensor or ambient disturbance that should not trigger a prolonged high-power response. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 09.10 — Thermal-Recovery Planner”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-S + H753-A + the named safe mechanical/condition fixtureregression/outcomerun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P09 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Thermal-Recovery Planner is a syllabus-scaled physical analogue of the need evidenced by GC04 · ASHRAE – Great Energy Predictor III: Predict time to return to safe range after an imposed disturbance. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needPredict building energy consumption from historical meter and weather data using public and private test evaluation.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Define repeatable response-quality measures and compare profiles on identical operating points, disturbances and acceptance limits.
Students use taught overshoot, settling, error, saturation and recovery measures rather than reproducing the full ASHRAE metric.
Implementation modeOrganiser-supported assignmentMay be issued only after the named seed history, reference specimens, calibration set or controlled fixture is prepared.
Required organiser provisionComplete before team allocationIssue a safe low-power chamber plus seed thermal episodes covering ambient and enclosure-state changes.
Problem 10 · 10 variants · Sensing, environment and smart product intelligence
LumiTrack — Intelligent Light Mapping and Positioning System
Assigned Faculty Master pair for P10: one nominated ESD Faculty Master and one nominated ML Faculty Master shall jointly master this parent problem and variants V1-V10. The ESD Master owns hardware, firmware, control, communication and safety verification; the ML Master owns data, baselines, models, validation and bounded decision-policy verification. Together they teach and guide ten teams (one for each variant and up to 40 students), supervise five teams in Wave A and five in Wave B, witness integration and sign every final evaluation.
The problem
A single light sensor gives only the intensity at its current orientation. By scanning an LDR through known servo angles, an STM32 device can build a light-field profile and learn which position best satisfies an objective such as maximum exposure, glare reduction or exposure limiting. The problem is richer than a simple threshold because light patterns can be diffuse, directional, obstructed or changing.
Smart embedded product to build
Build a calibrated one-axis light-field mapper using the NUCLEO-H753ZI, an LDR in a controlled fixture and a servo-scanned sensor/shade. Firmware visits only an approved angle grid, subtracts dark/reference readings, records angle/light/context/time and homes safely on loss of host. The host classifies the light regime or predicts the best allowed angle from a partial scan, then sends an angle/profile ID rather than an arbitrary PWM value.
NUCLEO-H753ZI realization and issued pack
NUCLEO-H753ZI / MB1364E with H753-S, low-torque servo and scan fixture
ADC LDR signal with dark/reference calibration; optional temperature/ambient channel
timer PWM moves only through an approved angle grid; potentiometer sets objective/override
USART3 VCP exports one scan per run and receives only angle/profile IDs
verified 3.3-V I²C display or LEDs report scan, estimate, accept and safe-home states
servo uses its approved external supply; do not source servo current from GPIO
clustering is permitted only if already covered; classification/regression is the default
Intelligence to incorporate
Create scan-level features: peak intensity, peak angle, curve asymmetry, gradient between sampled angles, total exposure and temperature. Use regression for best angle/exposure, classification for light regime or clustering of scan shapes. Evaluate angular error, exposure objective, partial-scan time saved and robustness to unseen light placement.
Permitted output/action set
ANGLE_ID · SCAN_PROFILE · HOLD · RETURN_HOME
Canonical family command contract: every parent brief, variant, host message and MCU acknowledgement for P10 shall use these exact identifiers. A variant may use only the applicable subset; it shall not introduce a synonym.
Core problem equipment · EQ-10-CORE
Complete equipment required for one core-problem team
Standalone family BOM. This list supports the parent problem itself. An allocated variant uses its own complete table later in this card. A component mentioned again in the fixture description is the same mounted unit, not another copy.
4 students; 3 by approved exception1 H753 board1 team laptopquantities per team
Controller1 H753 board + 1 laptop
SenseLDR plus fixed resistor network producing a measured 0–3.3 V ADC signal; 10 k…
Actuatelow-torque 4.8–6 V servo with verified 3.3-V PWM input
Fixturebounded-angle servo scan stand with 5–9 marked approved positions; diffused l…
Protectcurrent-limited 5 V servo/light supply with separate fused branches; hardware…
System block
Complete quantity and equipment per team
Purpose / acceptance condition
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser reference scan dataset and calibration-card readings
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Release-to-team condition: Only diffused visible low-voltage light is allowed; no laser or high-intensity source. The organiser signs the electrical, mechanical and communication acceptance checklist before H0:00.
Not duplicated inside the kit: supervised rework tools and the oscilloscope/logic-analyser station are shared at the ratio stated above. Everything else in this table is issued to, reserved for, or digitally assigned to this team.
Controlled self-learning extension
Recommended Implement confidence-aware partial-scan stopping: stop only at approved angle checkpoints when confidence and coverage rules are met, and quantify time saved versus full-grid scanning.
System safety and non-negotiable boundary
Servo travel and speed are bounded; predictions are clamped to approved angles. A manual override and host timeout return the mechanism to a safe neutral position. No camera or computer vision is required.
Student interpretation — what this challenge really asks
The light sensor measures intensity only where it is currently pointing. Students create an intelligent scan that maps the field, estimates a useful direction and moves only to validated positions.
Independent data unitone complete or partial angular scan under one lighting arrangement.
Closest misleading casea noisy local peak, reflection or partial shadow that is not the best stable direction.
Definition of successStudents must locate or track the useful direction on a hidden lighting arrangement with fewer measurements than the exhaustive baseline.
Visual system blueprint
Physical processServo-directed light scanGenerate labelled, safe and repeatable conditions.
Observeservo angle/profile, LDR voltage, ambient/reference levelPreserve units, timestamps, run identity and signal quality.
H753 responsibilityControl and protectmove through a safe angle grid, wait for settling, sample consistently and reject out-of-range positions.
Host intelligenceLearn the distinctionestimate peak-light angle/intensity, classify lighting pattern or choose a reduced scan profile.
Bounded outcomeANGLE_ID · SCAN_PROFILE · HOLD · RETURN_HOMEMCU validates, acknowledges and may refuse the request.
Recommended build journey
Make the process repeatableAssemble the H753-S servo/LDR scan fixture with externally powered low-force servo; define reference and target conditions before collecting data.
Prove deterministic firmwareMove through a safe angle grid, wait for settling, sample consistently and reject out-of-range positions. Demonstrate every hard limit before connecting ML.
Build trustworthy trialsTreat one complete or partial angular scan under one lighting arrangement as independent; calibrate, label and split by run/session.
Beat a real baselineCompare exhaustive fixed-angle scan and maximum measured LDR value with two syllabus-approved classical models.
Close and challenge the loopReturn only the applicable subset of ANGLE_ID · SCAN_PROFILE · HOLD · RETURN_HOME; test the target, nearest confuser, stale command and host loss.
Definition of done
Firmware controls safely before, during and after host connection.
Submit scan dataset, profile-quality checks and brightest-sample/rule baseline.
R4 · ML
Present best-angle/regime model, angular error and unseen-light-location results.
R5 · Integration
Integrate partial-scan or regime-aware positioning and pass host-loss/manual-override tests.
Final
Respond to a blind light configuration and quantify improvement over the baseline scan policy.
Portfolio/Kaggle outcome
Kaggle dataset: angle–intensity scans with scenario metadata and notebook comparing full scan, partial-scan model and simple brightest-sample baseline. Include visualisations of scan profiles and errors by lighting regime.
Industry alignment and validation basis
LumiTrack: external references and required evidence
The listed sources establish relevance, test discipline and implementation precedent. They do not modify the common syllabus boundary, safety rules or 100-mark assessment rubric.
Family implementation profile
Variant availability: 8 standard assignment(s); 2 organiser-supported assignment(s).
Public evidence: reproducible firmware, protocol, dataset, notebook/model, test report and demonstration video.
What the external benchmark confirms
The problem has a recognisable industrial or challenge analogue, a measurable data task, a defensible embedded implementation and a safe operational decision. Every one of its ten variants is mapped separately below.
Condition before team allocation
Use a shrouded, repeatable light fixture and require calibration-transfer testing under a changed source or shadow.
Frame cyber-physical systems as integrations of logical, physical and human components with concerns including trustworthiness and interoperability.
Evaluate the complete sense–decide–act system, its interfaces and failure behaviour—not a disconnected model or dashboard.
Open the 10 fully elaborated student variant briefs
Choose only the variant allocated to your team. Read it together with the parent problem above: the card expands the experimental delta, while every hardware, safety, integration and review requirement of the family remains active.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
SenseLDR plus fixed resistor network producing a measured 0–3.3 V ADC signal; 10 k…
Actuatelow-torque 4.8–6 V servo with verified 3.3-V PWM input
Fixtureservo-mounted LDR or small low-voltage panel on a bounded angle frame; diffus…
Protectcurrent-limited 5 V servo/light supply with separate fused branches; hardware…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser reference scan dataset and calibration-card readings
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Only diffused visible low-voltage light is allowed; no laser or high-intensity source. Verify the complete EQ-10-01 manifest before data collection.
1 · Scenario and student challenge
Maximise measured light on a small panel/LDR mount. In plain language, adapt LumiTrack — Intelligent Light Mapping and Positioning System so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Clear renewable-energy portfolio story.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-S + low-force servo fixture + the named safe mechanical/condition fixture. Begin with the H753-S servo/LDR scan fixture with externally powered low-force servo and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record servo angle/profile, LDR voltage, ambient/reference level, scan direction, sample time and position quality. Treat one complete or partial angular scan under one lighting arrangement as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Best-angle regression. First implement the parent baseline—exhaustive fixed-angle scan and maximum measured LDR value—and then compare two algorithms from the faculty-issued ML whitelist. Report MAE and RMSE on whole held-out runs, show predicted-versus-measured values, and inspect error by operating condition. If the target is converted to a safe/unsafe decision, also report missed-unsafe and unnecessary-conservative actions. Produce a predicted-versus-measured plot with residuals by operating condition.
5 · Embedded integration and safe response
The host may return only approved ANGLE_ID, SCAN_PROFILE, HOLD or RETURN_HOME, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a noisy local peak, reflection or partial shadow that is not the best stable direction. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 10.01 — Solar-Panel Alignment Emulator”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-S + low-force servo fixture + the named safe mechanical/condition fixtureregression/outcomerun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P10 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Solar-Panel Alignment Emulator is a syllabus-scaled physical analogue of the need evidenced by GC05 · Lighting Prize (L-Prize): Maximise measured light on a small panel/LDR mount. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needChallenge innovators to advance lighting systems through transformative products, performance and connected-system concepts.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Evaluate the complete sense–decide–act system, its interfaces and failure behaviour—not a disconnected model or dashboard.
It is used as architectural guidance; certification or conformance is neither asserted nor required.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationUse a shrouded, repeatable light fixture and require calibration-transfer testing under a changed source or shadow.
Variant 10.02
Smart Window-Blind Positioner
Engineering purpose: Adds comfort constraint and nontrivial objective.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
SenseLDR plus fixed resistor network producing a measured 0–3.3 V ADC signal; 10 k…
Actuatelow-torque 4.8–6 V servo with verified 3.3-V PWM input
Fixtureminiature servo-driven blind/louver; LDR behind the shade and target-light ca…
Protectcurrent-limited 5 V servo/light supply with separate fused branches; hardware…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser reference scan dataset and calibration-card readings
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Only diffused visible low-voltage light is allowed; no laser or high-intensity source. Verify the complete EQ-10-02 manifest before data collection.
1 · Scenario and student challenge
Position a shade to meet a target light band rather than maximise light. In plain language, adapt LumiTrack — Intelligent Light Mapping and Positioning System so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Adds comfort constraint and nontrivial objective.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-S + low-force servo fixture + the named safe mechanical/condition fixture. Begin with the H753-S servo/LDR scan fixture with externally powered low-force servo and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record servo angle/profile, LDR voltage, ambient/reference level, scan direction, sample time and position quality. Treat one complete or partial angular scan under one lighting arrangement as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Angle recommendation/classification. First implement the parent baseline—exhaustive fixed-angle scan and maximum measured LDR value—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only approved ANGLE_ID, SCAN_PROFILE, HOLD or RETURN_HOME, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a noisy local peak, reflection or partial shadow that is not the best stable direction. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 10.02 — Smart Window-Blind Positioner”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-S + low-force servo fixture + the named safe mechanical/condition fixtureclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P10 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Smart Window-Blind Positioner is a syllabus-scaled physical analogue of the need evidenced by GC05 · Lighting Prize (L-Prize): Position a shade to meet a target light band rather than maximise light. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needChallenge innovators to advance lighting systems through transformative products, performance and connected-system concepts.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Evaluate the complete sense–decide–act system, its interfaces and failure behaviour—not a disconnected model or dashboard.
It is used as architectural guidance; certification or conformance is neither asserted nor required.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationUse a shrouded, repeatable light fixture and require calibration-transfer testing under a changed source or shadow.
Variant 10.03
Museum Exposure Limiter
Engineering purpose: Introduces conservation and cumulative exposure.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
SenseLDR plus fixed resistor network producing a measured 0–3.3 V ADC signal; 10 k…
Actuatelow-torque 4.8–6 V servo with verified 3.3-V PWM input
Fixtureclear museum-case/shade emulator; LDR at artifact plane, servo shade and cumu…
Protectcurrent-limited 5 V servo/light supply with separate fused branches; hardware…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser reference scan dataset and calibration-card readings
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Only diffused visible low-voltage light is allowed; no laser or high-intensity source. Verify the complete EQ-10-03 manifest before data collection.
1 · Scenario and student challenge
Keep cumulative light below a target while retaining visibility. In plain language, adapt LumiTrack — Intelligent Light Mapping and Positioning System so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Introduces conservation and cumulative exposure.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-S + low-force servo fixture + the named safe mechanical/condition fixture. Begin with the H753-S servo/LDR scan fixture with externally powered low-force servo and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record servo angle/profile, LDR voltage, ambient/reference level, scan direction, sample time and position quality. Treat one complete or partial angular scan under one lighting arrangement as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Exposure-risk classification and safe angle choice. First implement the parent baseline—exhaustive fixed-angle scan and maximum measured LDR value—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only approved ANGLE_ID, SCAN_PROFILE, HOLD or RETURN_HOME, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a noisy local peak, reflection or partial shadow that is not the best stable direction. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 10.03 — Museum Exposure Limiter”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-S + low-force servo fixture + the named safe mechanical/condition fixtureclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P10 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Museum Exposure Limiter is a syllabus-scaled physical analogue of the need evidenced by GC05 · Lighting Prize (L-Prize): Keep cumulative light below a target while retaining visibility. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needChallenge innovators to advance lighting systems through transformative products, performance and connected-system concepts.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Evaluate the complete sense–decide–act system, its interfaces and failure behaviour—not a disconnected model or dashboard.
It is used as architectural guidance; certification or conformance is neither asserted nor required.
Implementation modeOrganiser-supported assignmentMay be issued only after the named seed history, reference specimens, calibration set or controlled fixture is prepared.
Required organiser provisionComplete before team allocationUse a shrouded, repeatable light fixture and require calibration-transfer testing under a changed source or shadow.
Variant 10.04
Greenhouse Shade Controller
Engineering purpose: Combines LDR and LM35 in an agricultural product.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
SenseLDR 0–3.3 V channel; LM35-class temperature channel; 10 kΩ target/override po…
Actuatelow-torque 4.8–6 V servo with verified 3.3-V PWM input
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser reference scan dataset and calibration-card readings
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Only diffused visible low-voltage light is allowed; no laser or high-intensity source. Verify the complete EQ-10-04 manifest before data collection.
1 · Scenario and student challenge
Select shade angle from light regime and temperature. In plain language, adapt LumiTrack — Intelligent Light Mapping and Positioning System so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Combines LDR and LM35 in an agricultural product.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-S + low-force servo fixture + the named safe mechanical/condition fixture. Begin with the H753-S servo/LDR scan fixture with externally powered low-force servo and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record servo angle/profile, LDR voltage, ambient/reference level, scan direction, sample time and position quality. Treat one complete or partial angular scan under one lighting arrangement as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Multiclass profile selection. First implement the parent baseline—exhaustive fixed-angle scan and maximum measured LDR value—and then compare two algorithms from the faculty-issued ML whitelist. Report correct/feasible selection rate, constraint violations and improvement over the fixed policy. A choice is wrong if it violates a declared current, timing, thermal or control-quality bound even when it is fast. Produce a candidate-outcome/constraint table showing why the selected option is feasible.
5 · Embedded integration and safe response
The host may return only approved ANGLE_ID, SCAN_PROFILE, HOLD or RETURN_HOME, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a noisy local peak, reflection or partial shadow that is not the best stable direction. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 10.04 — Greenhouse Shade Controller”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-S + low-force servo fixture + the named safe mechanical/condition fixtureclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P10 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Greenhouse Shade Controller is a syllabus-scaled physical analogue of the need evidenced by GC05 · Lighting Prize (L-Prize): Select shade angle from light regime and temperature. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needChallenge innovators to advance lighting systems through transformative products, performance and connected-system concepts.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Evaluate the complete sense–decide–act system, its interfaces and failure behaviour—not a disconnected model or dashboard.
It is used as architectural guidance; certification or conformance is neither asserted nor required.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationUse a shrouded, repeatable light fixture and require calibration-transfer testing under a changed source or shadow.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
SenseLDR plus fixed resistor network producing a measured 0–3.3 V ADC signal; 10 k…
Actuatelow-torque 4.8–6 V servo with verified 3.3-V PWM input
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser reference scan dataset and calibration-card readings
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Only diffused visible low-voltage light is allowed; no laser or high-intensity source. Verify the complete EQ-10-05 manifest before data collection.
1 · Scenario and student challenge
Aim toward the strongest allowed illumination direction. In plain language, adapt LumiTrack — Intelligent Light Mapping and Positioning System so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Focuses on scan efficiency.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-S + low-force servo fixture + the named safe mechanical/condition fixture. Begin with the H753-S servo/LDR scan fixture with externally powered low-force servo and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record servo angle/profile, LDR voltage, ambient/reference level, scan direction, sample time and position quality. Treat one complete or partial angular scan under one lighting arrangement as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Angle regression from partial scan. First implement the parent baseline—exhaustive fixed-angle scan and maximum measured LDR value—and then compare two algorithms from the faculty-issued ML whitelist. Report MAE and RMSE on whole held-out runs, show predicted-versus-measured values, and inspect error by operating condition. If the target is converted to a safe/unsafe decision, also report missed-unsafe and unnecessary-conservative actions. Produce a predicted-versus-measured plot with residuals by operating condition.
5 · Embedded integration and safe response
The host may return only approved ANGLE_ID, SCAN_PROFILE, HOLD or RETURN_HOME, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a noisy local peak, reflection or partial shadow that is not the best stable direction. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 10.05 — Task-Light Auto-Aimer”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-S + low-force servo fixture + the named safe mechanical/condition fixtureregression/outcomerun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P10 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Task-Light Auto-Aimer is a syllabus-scaled physical analogue of the need evidenced by GC05 · Lighting Prize (L-Prize): Aim toward the strongest allowed illumination direction. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needChallenge innovators to advance lighting systems through transformative products, performance and connected-system concepts.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Evaluate the complete sense–decide–act system, its interfaces and failure behaviour—not a disconnected model or dashboard.
It is used as architectural guidance; certification or conformance is neither asserted nor required.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationUse a shrouded, repeatable light fixture and require calibration-transfer testing under a changed source or shadow.
Variant 10.06
Streetlight Dawn/Dusk Classifier
Engineering purpose: Moves beyond one LDR threshold.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
SenseLDR plus fixed resistor network producing a measured 0–3.3 V ADC signal; 10 k…
Actuateprotected 3.3-V-compatible MOSFET/relay driver; 5/12 V indicator lamp/LED load
Fixturedawn/dusk light test box; dimmable low-voltage LED source with fixed brightne…
Protectcurrent-limited 5/12 V lamp/LED supply; fused output branch and hardware load…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser reference scan dataset and calibration-card readings
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Only diffused visible low-voltage light is allowed; no laser or high-intensity source. Verify the complete EQ-10-06 manifest before data collection.
1 · Scenario and student challenge
Use temporal light features to classify day, transition and night, then operate relay/servo profile. In plain language, adapt LumiTrack — Intelligent Light Mapping and Positioning System so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Moves beyond one LDR threshold.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-S + low-force servo fixture + the named safe mechanical/condition fixture. Begin with the H753-S servo/LDR scan fixture with externally powered low-force servo and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record servo angle/profile, LDR voltage, ambient/reference level, scan direction, sample time and position quality. Treat one complete or partial angular scan under one lighting arrangement as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Multiclass classification. First implement the parent baseline—exhaustive fixed-angle scan and maximum measured LDR value—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only approved ANGLE_ID, SCAN_PROFILE, HOLD or RETURN_HOME, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a noisy local peak, reflection or partial shadow that is not the best stable direction. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 10.06 — Streetlight Dawn/Dusk Classifier”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-S + low-force servo fixture + the named safe mechanical/condition fixtureclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P10 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Streetlight Dawn/Dusk Classifier is a syllabus-scaled physical analogue of the need evidenced by GC05 · Lighting Prize (L-Prize): Use temporal light features to classify day, transition and night, then operate relay/servo profile. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needChallenge innovators to advance lighting systems through transformative products, performance and connected-system concepts.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Evaluate the complete sense–decide–act system, its interfaces and failure behaviour—not a disconnected model or dashboard.
It is used as architectural guidance; certification or conformance is neither asserted nor required.
Implementation modeOrganiser-supported assignmentMay be issued only after the named seed history, reference specimens, calibration set or controlled fixture is prepared.
Required organiser provisionComplete before team allocationUse a shrouded, repeatable light fixture and require calibration-transfer testing under a changed source or shadow.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
SenseLDR plus fixed resistor network producing a measured 0–3.3 V ADC signal; 10 k…
Actuatelow-torque 4.8–6 V servo with verified 3.3-V PWM input
Fixtureoptical alignment stand with servo-mounted sensor; movable diffused LED sourc…
Protectcurrent-limited 5 V servo/light supply with separate fused branches; hardware…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser reference scan dataset and calibration-card readings
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Only diffused visible low-voltage light is allowed; no laser or high-intensity source. Verify the complete EQ-10-07 manifest before data collection.
1 · Scenario and student challenge
Find and hold an alignment peak while detecting a shifted source. In plain language, adapt LumiTrack — Intelligent Light Mapping and Positioning System so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Relevant to instrumentation.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-S + low-force servo fixture + the named safe mechanical/condition fixture. Begin with the H753-S servo/LDR scan fixture with externally powered low-force servo and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record servo angle/profile, LDR voltage, ambient/reference level, scan direction, sample time and position quality. Treat one complete or partial angular scan under one lighting arrangement as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Peak-angle regression plus shift classification. First implement the parent baseline—exhaustive fixed-angle scan and maximum measured LDR value—and then compare two algorithms from the faculty-issued ML whitelist. Report MAE and RMSE on whole held-out runs, show predicted-versus-measured values, and inspect error by operating condition. If the target is converted to a safe/unsafe decision, also report missed-unsafe and unnecessary-conservative actions. Produce a predicted-versus-measured plot with residuals by operating condition.
5 · Embedded integration and safe response
The host may return only approved ANGLE_ID, SCAN_PROFILE, HOLD or RETURN_HOME, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a noisy local peak, reflection or partial shadow that is not the best stable direction. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 10.07 — Optical Alignment Assistant”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-S + low-force servo fixture + the named safe mechanical/condition fixtureregression/outcomerun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P10 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Optical Alignment Assistant is a syllabus-scaled physical analogue of the need evidenced by GC05 · Lighting Prize (L-Prize): Find and hold an alignment peak while detecting a shifted source. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needChallenge innovators to advance lighting systems through transformative products, performance and connected-system concepts.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Evaluate the complete sense–decide–act system, its interfaces and failure behaviour—not a disconnected model or dashboard.
It is used as architectural guidance; certification or conformance is neither asserted nor required.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationUse a shrouded, repeatable light fixture and require calibration-transfer testing under a changed source or shadow.
Variant 10.08
Warehouse Skylight Louver
Engineering purpose: Balances daylight use and glare.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
SenseLDR plus fixed resistor network producing a measured 0–3.3 V ADC signal; 10 k…
Actuatelow-torque 4.8–6 V servo with verified 3.3-V PWM input
Fixtureminiature skylight/louver box; diffused light source positions and moving-sha…
Protectcurrent-limited 5 V servo/light supply with separate fused branches; hardware…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser reference scan dataset and calibration-card readings
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Only diffused visible low-voltage light is allowed; no laser or high-intensity source. Verify the complete EQ-10-08 manifest before data collection.
1 · Scenario and student challenge
Maintain a target band under moving/shadowed light. In plain language, adapt LumiTrack — Intelligent Light Mapping and Positioning System so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Balances daylight use and glare.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-S + low-force servo fixture + the named safe mechanical/condition fixture. Begin with the H753-S servo/LDR scan fixture with externally powered low-force servo and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record servo angle/profile, LDR voltage, ambient/reference level, scan direction, sample time and position quality. Treat one complete or partial angular scan under one lighting arrangement as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Regime classification and angle policy. First implement the parent baseline—exhaustive fixed-angle scan and maximum measured LDR value—and then compare two algorithms from the faculty-issued ML whitelist. Report correct/feasible selection rate, constraint violations and improvement over the fixed policy. A choice is wrong if it violates a declared current, timing, thermal or control-quality bound even when it is fast. Produce a candidate-outcome/constraint table showing why the selected option is feasible.
5 · Embedded integration and safe response
The host may return only approved ANGLE_ID, SCAN_PROFILE, HOLD or RETURN_HOME, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a noisy local peak, reflection or partial shadow that is not the best stable direction. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 10.08 — Warehouse Skylight Louver”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-S + low-force servo fixture + the named safe mechanical/condition fixtureclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P10 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Warehouse Skylight Louver is a syllabus-scaled physical analogue of the need evidenced by GC05 · Lighting Prize (L-Prize): Maintain a target band under moving/shadowed light. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needChallenge innovators to advance lighting systems through transformative products, performance and connected-system concepts.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Evaluate the complete sense–decide–act system, its interfaces and failure behaviour—not a disconnected model or dashboard.
It is used as architectural guidance; certification or conformance is neither asserted nor required.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationUse a shrouded, repeatable light fixture and require calibration-transfer testing under a changed source or shadow.
Variant 10.09
Display Brightness/Angle Controller
Engineering purpose: Creates a human-interface product without camera data.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
SenseLDR plus fixed resistor network producing a measured 0–3.3 V ADC signal; 10 k…
Actuatelow-torque 4.8–6 V servo with verified 3.3-V PWM input
Fixtureservo-mounted reflective/display card; LDR at viewing plane, glare shield and…
Protectcurrent-limited 5 V servo/light supply with separate fused branches; hardware…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser reference scan dataset and calibration-card readings
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Only diffused visible low-voltage light is allowed; no laser or high-intensity source. Verify the complete EQ-10-09 manifest before data collection.
1 · Scenario and student challenge
Use LDR and servo to orient a reflective/display surface within glare limits. In plain language, adapt LumiTrack — Intelligent Light Mapping and Positioning System so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Creates a human-interface product without camera data.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-S + low-force servo fixture + the named safe mechanical/condition fixture. Begin with the H753-S servo/LDR scan fixture with externally powered low-force servo and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record servo angle/profile, LDR voltage, ambient/reference level, scan direction, sample time and position quality. Treat one complete or partial angular scan under one lighting arrangement as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Glare-risk classification. First implement the parent baseline—exhaustive fixed-angle scan and maximum measured LDR value—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only approved ANGLE_ID, SCAN_PROFILE, HOLD or RETURN_HOME, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a noisy local peak, reflection or partial shadow that is not the best stable direction. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 10.09 — Display Brightness/Angle Controller”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-S + low-force servo fixture + the named safe mechanical/condition fixtureclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P10 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Display Brightness/Angle Controller is a syllabus-scaled physical analogue of the need evidenced by GC05 · Lighting Prize (L-Prize): Use LDR and servo to orient a reflective/display surface within glare limits. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needChallenge innovators to advance lighting systems through transformative products, performance and connected-system concepts.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Evaluate the complete sense–decide–act system, its interfaces and failure behaviour—not a disconnected model or dashboard.
It is used as architectural guidance; certification or conformance is neither asserted nor required.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationUse a shrouded, repeatable light fixture and require calibration-transfer testing under a changed source or shadow.
Variant 10.10
Light-Seeking Inspection Head
Engineering purpose: Shows ML assisting embedded measurement quality.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
SenseLDR plus fixed resistor network producing a measured 0–3.3 V ADC signal; 10 k…
Actuatelow-torque 4.8–6 V servo with verified 3.3-V PWM input
Fixtureservo-mounted light-seeking sensor head; inspection target card with usable/p…
Protectcurrent-limited 5 V servo/light supply with separate fused branches; hardware…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser reference scan dataset and calibration-card readings
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Only diffused visible low-voltage light is allowed; no laser or high-intensity source. Verify the complete EQ-10-10 manifest before data collection.
1 · Scenario and student challenge
Move a sensor head to a usable illumination zone before measurement. In plain language, adapt LumiTrack — Intelligent Light Mapping and Positioning System so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Shows ML assisting embedded measurement quality.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-S + low-force servo fixture + the named safe mechanical/condition fixture. Begin with the H753-S servo/LDR scan fixture with externally powered low-force servo and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record servo angle/profile, LDR voltage, ambient/reference level, scan direction, sample time and position quality. Treat one complete or partial angular scan under one lighting arrangement as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Pass-zone prediction. First implement the parent baseline—exhaustive fixed-angle scan and maximum measured LDR value—and then compare two algorithms from the faculty-issued ML whitelist. Report MAE and RMSE on whole held-out runs, show predicted-versus-measured values, and inspect error by operating condition. If the target is converted to a safe/unsafe decision, also report missed-unsafe and unnecessary-conservative actions. Produce a predicted-versus-measured plot with residuals by operating condition.
5 · Embedded integration and safe response
The host may return only approved ANGLE_ID, SCAN_PROFILE, HOLD or RETURN_HOME, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a noisy local peak, reflection or partial shadow that is not the best stable direction. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 10.10 — Light-Seeking Inspection Head”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-S + low-force servo fixture + the named safe mechanical/condition fixtureregression/outcomerun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P10 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Light-Seeking Inspection Head is a syllabus-scaled physical analogue of the need evidenced by GC05 · Lighting Prize (L-Prize): Move a sensor head to a usable illumination zone before measurement. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needChallenge innovators to advance lighting systems through transformative products, performance and connected-system concepts.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Evaluate the complete sense–decide–act system, its interfaces and failure behaviour—not a disconnected model or dashboard.
It is used as architectural guidance; certification or conformance is neither asserted nor required.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationUse a shrouded, repeatable light fixture and require calibration-transfer testing under a changed source or shadow.
Problem 11 · 10 variants · Sensing, environment and smart product intelligence
SensorTrust — Fault Detection, Confidence Scoring and Virtual Sensing
Assigned Faculty Master pair for P11: one nominated ESD Faculty Master and one nominated ML Faculty Master shall jointly master this parent problem and variants V1-V10. The ESD Master owns hardware, firmware, control, communication and safety verification; the ML Master owns data, baselines, models, validation and bounded decision-policy verification. Together they teach and guide ten teams (one for each variant and up to 40 students), supervise five teams in Wave A and five in Wave B, witness integration and sign every final evaluation.
The problem
Embedded decisions are only as trustworthy as their sensors. A sensor can drift, become noisy, freeze, disconnect or respond too slowly while still returning an apparently valid number. Fixed range checks detect only obvious failures. The challenge is to combine cross-sensor, actuator and temporal evidence to identify suspect channels and, where justified, estimate a bounded substitute value.
Smart embedded product to build
Build a NUCLEO-H753ZI sensor-trust manager using at least three physically related channels from the H753-S pack and one causal actuator/context signal where needed. Firmware performs independent range, timeout, stuck and plausibility checks and enters NORMAL, DEGRADED or SAFE. The host identifies NORMAL, DRIFT, STUCK, NOISY, DISCONNECTED or UNKNOWN and may return a bounded substitute value with trust band; firmware decides whether it is admissible.
NUCLEO-H753ZI realization and issued pack
NUCLEO-H753ZI / MB1364E with H753-S and selected low-voltage H753-A context actuator
two or more related ADC channels: process/ambient temperature, LDR, potentiometer or conditioned feedback
timer timestamps, stuck counters, range/plausibility checks and actuator-state context
safe fault injection by switchable disconnect, bounded bias/noise code or replaceable resistor network
USART3 VCP sends raw channels and local flags; host returns suspect channel, trust band and bounded substitute
MCU allows substitute values only within configured range/time/confidence limits
display/LED distinguishes NORMAL, DEGRADED, FALLBACK and SAFE_STOP
Intelligence to incorporate
Use level, slope, variance, stuck-count, cross-channel residuals, actuator state and recent history. Train supervised fault classifiers from safe software/connection injections or use healthy-data clustering/anomaly detection. For virtual sensing, use linear/tree regression. Evaluate fault recall, false alarms, detection delay and substitute-value MAE.
Canonical family command contract: every parent brief, variant, host message and MCU acknowledgement for P11 shall use these exact identifiers. A variant may use only the applicable subset; it shall not introduce a synonym.
Core problem equipment · EQ-11-CORE
Complete equipment required for one core-problem team
Standalone family BOM. This list supports the parent problem itself. An allocated variant uses its own complete table later in this card. A component mentioned again in the fixture description is the same mounted unit, not another copy.
4 students; 3 by approved exception1 H753 board1 team laptopquantities per team
Controller1 H753 board + 1 laptop
Sensematched LM35-class temperature channels: one primary and one reference; LDR d…
Actuatelow-voltage fan or lamp with protected 3.3-V-compatible MOSFET/relay driver w…
Fixturelabelled sensor test panel with NORMAL, DRIFT, STUCK, NOISY and DISCONNECTED…
Protectcurrent-limited 5/12 V supply when an actuator is used; fused actuator branch…
System block
Complete quantity and equipment per team
Purpose / acceptance condition
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser sensor-fault seed data with unseen fault severities
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Release-to-team condition: Fault injection occurs after signal conditioning; no external pin may exceed 0–3.3 V. The organiser signs the electrical, mechanical and communication acceptance checklist before H0:00.
Not duplicated inside the kit: supervised rework tools and the oscilloscope/logic-analyser station are shared at the ratio stated above. Everything else in this table is issued to, reserved for, or digitally assigned to this team.
Controlled self-learning extension
Recommended Route one H753 DAC output through an approved jumper/divider to an ADC input as a bounded reference/fault stimulus. Use it to separate ADC-chain error from external-sensor error; document the electrical range.
System safety and non-negotiable boundary
A predicted substitute cannot override hard safety unless explicitly bounded and approved. Disconnected/implausible sensors cause conservative mode. Faults are injected safely through software, resistor/potentiometer settings or connector changes under supervision.
Student interpretation — what this challenge really asks
A controller should not trust every plausible-looking sensor value. Students combine range checks, relationships and time behaviour to identify faults, estimate a replacement value where defensible and degrade safely when uncertainty remains.
Independent data unitone time window containing a healthy regime or one controlled sensor-fault episode.
Closest misleading casea rapid but physically valid process change that resembles sensor drift or a spike.
Definition of successStudents must identify the faulty channel or abstain correctly and keep the process conservative when certainty is inadequate.
Visual system blueprint
Physical processRedundant or related sensor channelsGenerate labelled, safe and repeatable conditions.
Observeraw and calibrated sensor values, derivatives/variance, actuator statePreserve units, timestamps, run identity and signal quality.
H753 responsibilityControl and protectperform range/timeout checks, retain raw evidence and switch among normal, degraded and safe modes.
Host intelligenceLearn the distinctionclassify drift, stuck, noisy or disconnected sensors and optionally estimate the expected value.
Bounded outcomeTRUST_CHANNEL · DEGRADE_MODE · USE_BOUNDED_ESTIMATE · REQUEST_SERVICE · SAFE_MODEMCU validates, acknowledges and may refuse the request.
Recommended build journey
Make the process repeatableAssemble the H753-S sensor rig with H753-A actuation where the variant needs a physical response; define reference and target conditions before collecting data.
Prove deterministic firmwarePerform range/timeout checks, retain raw evidence and switch among normal, degraded and safe modes. Demonstrate every hard limit before connecting ML.
Build trustworthy trialsTreat one time window containing a healthy regime or one controlled sensor-fault episode as independent; calibrate, label and split by run/session.
Beat a real baselineCompare range, rate-of-change and two-sensor disagreement rules with two syllabus-approved classical models.
Close and challenge the loopReturn only the applicable subset of TRUST_CHANNEL · DEGRADE_MODE · USE_BOUNDED_ESTIMATE · REQUEST_SERVICE · SAFE_MODE; test the target, nearest confuser, stale command and host loss.
Definition of done
Firmware controls safely before, during and after host connection.
Demonstrate multi-channel ADC/timer acquisition, timestamps, range checks, LCD and safe-mode state machine.
R3 · Data
Submit healthy plus injected-fault runs, injection log and simple stuck/range baseline.
R4 · ML
Show fault classifier/anomaly model, detection latency, false alarms and optional virtual-sensor error.
R5 · Integration
Integrate trust decisions and demonstrate safe degradation under hidden sensor and host faults.
Final
Identify an unseen injected fault live, show evidence and explain whether substitution is safe.
Portfolio/Kaggle outcome
Kaggle asset: ‘STM32 Sensor Fault and Virtual Sensor Dataset’ with raw streams, injection metadata, run-group split, fault classifier, residual plots, trust score and model limitations.
Industry alignment and validation basis
SensorTrust: external references and required evidence
The listed sources establish relevance, test discipline and implementation precedent. They do not modify the common syllabus boundary, safety rules or 100-mark assessment rubric.
Family implementation profile
Variant availability: 6 standard assignment(s); 4 organiser-supported assignment(s).
Public evidence: reproducible firmware, protocol, dataset, notebook/model, test report and demonstration video.
What the external benchmark confirms
The problem has a recognisable industrial or challenge analogue, a measurable data task, a defensible embedded implementation and a safe operational decision. Every one of its ten variants is mapped separately below.
Condition before team allocation
Provide software-selectable, logged fault injection and keep one rapid-but-valid process change as a compulsory confuser.
Identify model portability, sensor calibration drift, context change and maintenance events as central challenges for data-derived virtual measurements.
Test on unseen context/device conditions, track calibration state and abstain or degrade when the virtual sensor leaves its validated domain.
Frame cyber-physical systems as integrations of logical, physical and human components with concerns including trustworthiness and interoperability.
Evaluate the complete sense–decide–act system, its interfaces and failure behaviour—not a disconnected model or dashboard.
Open the 10 fully elaborated student variant briefs
Choose only the variant allocated to your team. Read it together with the parent problem above: the card expands the experimental delta, while every hardware, safety, integration and review requirement of the family remains active.
Variant 11.01
LM35 Drift Guardian
Engineering purpose: Shows a fault invisible to simple bounds.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensematched LM35-class temperature channels: one primary and one reference; LDR d…
ActuateNo powered actuator is required.
Fixturedual-LM35 thermal panel; bounded bias potentiometer/resistor network on the s…
ProtectUSB board-power path only; sensor stimuli are passive.
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser sensor-fault seed data with unseen fault severities
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Fault injection occurs after signal conditioning; no external pin may exceed 0–3.3 V. Verify the complete EQ-11-01 manifest before data collection.
1 · Scenario and student challenge
Inject gradual temperature offset without exceeding raw range. In plain language, adapt SensorTrust — Fault Detection, Confidence Scoring and Virtual Sensing so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Shows a fault invisible to simple bounds.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-S; H753-A when an actuator response is used. Begin with the H753-S sensor rig with H753-A actuation where the variant needs a physical response and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record raw and calibrated sensor values, derivatives/variance, actuator state, ambient/reference channels, age and plausibility flags. Treat one time window containing a healthy regime or one controlled sensor-fault episode as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Drift classification/residual anomaly. First implement the parent baseline—range, rate-of-change and two-sensor disagreement rules—and then compare two algorithms from the faculty-issued ML whitelist. Train or set the threshold using healthy/training data only. Report event recall, false alarms per normal run and detection delay; show where the method treats a new but valid regime as abnormal. Produce a event timeline with anomaly score, threshold and false-alarm examples.
5 · Embedded integration and safe response
The host may return only TRUST_CHANNEL, DEGRADE_MODE, USE_BOUNDED_ESTIMATE, REQUEST_SERVICE or SAFE_MODE, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a rapid but physically valid process change that resembles sensor drift or a spike. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 11.01 — LM35 Drift Guardian”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-S; H753-A when an actuator response is usedanomaly/noveltyrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P11 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
LM35 Drift Guardian is a syllabus-scaled physical analogue of the need evidenced by BM06 · Sensor Fault Detection in Smart Extraterrestrial Habitats: Inject gradual temperature offset without exceeding raw range. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needEvaluate sensor-fault detection using training, validation and test datasets, with validation used to choose thresholds.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Evaluate fault isolation, not merely anomaly detection, and include a sensor-fault-versus-mechanical-fault confuser.
The cited work uses methods beyond the course; students transfer the diagnostic question, not its neural-network implementation.
Implementation modeOrganiser-supported assignmentMay be issued only after the named seed history, reference specimens, calibration set or controlled fixture is prepared.
Required organiser provisionComplete before team allocationProvide software-selectable, logged fault injection and keep one rapid-but-valid process change as a compulsory confuser.
Variant 11.02
LDR Stuck-at Detector
Engineering purpose: Uses expected response to actuation.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser sensor-fault seed data with unseen fault severities
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Fault injection occurs after signal conditioning; no external pin may exceed 0–3.3 V. Verify the complete EQ-11-02 manifest before data collection.
1 · Scenario and student challenge
Freeze light value while physical/servo context changes. In plain language, adapt SensorTrust — Fault Detection, Confidence Scoring and Virtual Sensing so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Uses expected response to actuation.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-S; H753-A when an actuator response is used. Begin with the H753-S sensor rig with H753-A actuation where the variant needs a physical response and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record raw and calibrated sensor values, derivatives/variance, actuator state, ambient/reference channels, age and plausibility flags. Treat one time window containing a healthy regime or one controlled sensor-fault episode as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Stuck/fault classification. First implement the parent baseline—range, rate-of-change and two-sensor disagreement rules—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only TRUST_CHANNEL, DEGRADE_MODE, USE_BOUNDED_ESTIMATE, REQUEST_SERVICE or SAFE_MODE, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a rapid but physically valid process change that resembles sensor drift or a spike. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 11.02 — LDR Stuck-at Detector”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-S; H753-A when an actuator response is usedclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P11 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
LDR Stuck-at Detector is a syllabus-scaled physical analogue of the need evidenced by BM06 · Sensor Fault Detection in Smart Extraterrestrial Habitats: Freeze light value while physical/servo context changes. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needEvaluate sensor-fault detection using training, validation and test datasets, with validation used to choose thresholds.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Evaluate fault isolation, not merely anomaly detection, and include a sensor-fault-versus-mechanical-fault confuser.
The cited work uses methods beyond the course; students transfer the diagnostic question, not its neural-network implementation.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationProvide software-selectable, logged fault injection and keep one rapid-but-valid process change as a compulsory confuser.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sense10 kΩ potentiometers: suspect command and reference; keyed bounded-noise/inte…
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser sensor-fault seed data with unseen fault severities
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Fault injection occurs after signal conditioning; no external pin may exceed 0–3.3 V. Verify the complete EQ-11-03 manifest before data collection.
1 · Scenario and student challenge
Inject intermittent or noisy command input. In plain language, adapt SensorTrust — Fault Detection, Confidence Scoring and Virtual Sensing so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Represents human-interface sensor degradation.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-S; H753-A when an actuator response is used. Begin with the H753-S sensor rig with H753-A actuation where the variant needs a physical response and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record raw and calibrated sensor values, derivatives/variance, actuator state, ambient/reference channels, age and plausibility flags. Treat one time window containing a healthy regime or one controlled sensor-fault episode as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Noise/intermittency classification. First implement the parent baseline—range, rate-of-change and two-sensor disagreement rules—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only TRUST_CHANNEL, DEGRADE_MODE, USE_BOUNDED_ESTIMATE, REQUEST_SERVICE or SAFE_MODE, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a rapid but physically valid process change that resembles sensor drift or a spike. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 11.03 — Potentiometer Wear/Noise Monitor”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-S; H753-A when an actuator response is usedclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P11 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Potentiometer Wear/Noise Monitor is a syllabus-scaled physical analogue of the need evidenced by BM06 · Sensor Fault Detection in Smart Extraterrestrial Habitats: Inject intermittent or noisy command input. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needEvaluate sensor-fault detection using training, validation and test datasets, with validation used to choose thresholds.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Evaluate fault isolation, not merely anomaly detection, and include a sensor-fault-versus-mechanical-fault confuser.
The cited work uses methods beyond the course; students transfer the diagnostic question, not its neural-network implementation.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationProvide software-selectable, logged fault injection and keep one rapid-but-valid process change as a compulsory confuser.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensemotor encoder; 0–3.3 V current-sense channel; LM35-class temperature channel
Actuategeared DC motor and 3.3-V H-bridge
Fixtureguarded motor/encoder fixture; encoder PASS/DROP/FREEZE switch bank
Protectcurrent-limited motor supply; inline fuse and physical E-stop
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser sensor-fault seed data with unseen fault severities
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Fault injection occurs after signal conditioning; no external pin may exceed 0–3.3 V. Verify the complete EQ-11-04 manifest before data collection.
1 · Scenario and student challenge
Remove pulses intermittently while motor current and command persist. In plain language, adapt SensorTrust — Fault Detection, Confidence Scoring and Virtual Sensing so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Directly supports servo reliability.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-S + the encoder/current channel from H753-M. Begin with the H753-S sensor rig with H753-A actuation where the variant needs a physical response and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record raw and calibrated sensor values, derivatives/variance, actuator state, ambient/reference channels, age and plausibility flags. Treat one time window containing a healthy regime or one controlled sensor-fault episode as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Feedback-fault classification. First implement the parent baseline—range, rate-of-change and two-sensor disagreement rules—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only TRUST_CHANNEL, DEGRADE_MODE, USE_BOUNDED_ESTIMATE, REQUEST_SERVICE or SAFE_MODE, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a rapid but physically valid process change that resembles sensor drift or a spike. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 11.04 — Encoder Dropout Guardian”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-S + the encoder/current channel from H753-Mclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P11 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Encoder Dropout Guardian is a syllabus-scaled physical analogue of the need evidenced by BM06 · Sensor Fault Detection in Smart Extraterrestrial Habitats: Remove pulses intermittently while motor current and command persist. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needEvaluate sensor-fault detection using training, validation and test datasets, with validation used to choose thresholds.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Evaluate fault isolation, not merely anomaly detection, and include a sensor-fault-versus-mechanical-fault confuser.
The cited work uses methods beyond the course; students transfer the diagnostic question, not its neural-network implementation.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationProvide software-selectable, logged fault injection and keep one rapid-but-valid process change as a compulsory confuser.
Variant 11.05
Current-Sensor Offset Detector
Engineering purpose: Protects motor diagnostics from false load estimates.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sense0–3.3 V current-sense channel; encoder/tachometer; reference supply/load proxy
Actuategeared DC motor and 3.3-V H-bridge
Fixtureguarded motor/current fixture; bounded analogue/software offset control and k…
Protectcurrent-limited motor supply; inline fuse and physical E-stop
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser sensor-fault seed data with unseen fault severities
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Fault injection occurs after signal conditioning; no external pin may exceed 0–3.3 V. Verify the complete EQ-11-05 manifest before data collection.
1 · Scenario and student challenge
Add a safe software offset or calibration bias. In plain language, adapt SensorTrust — Fault Detection, Confidence Scoring and Virtual Sensing so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Protects motor diagnostics from false load estimates.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-S + the encoder/current channel from H753-M. Begin with the H753-S sensor rig with H753-A actuation where the variant needs a physical response and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record raw and calibrated sensor values, derivatives/variance, actuator state, ambient/reference channels, age and plausibility flags. Treat one time window containing a healthy regime or one controlled sensor-fault episode as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Residual-based anomaly classification. First implement the parent baseline—range, rate-of-change and two-sensor disagreement rules—and then compare two algorithms from the faculty-issued ML whitelist. Train or set the threshold using healthy/training data only. Report event recall, false alarms per normal run and detection delay; show where the method treats a new but valid regime as abnormal. Produce a event timeline with anomaly score, threshold and false-alarm examples.
5 · Embedded integration and safe response
The host may return only TRUST_CHANNEL, DEGRADE_MODE, USE_BOUNDED_ESTIMATE, REQUEST_SERVICE or SAFE_MODE, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a rapid but physically valid process change that resembles sensor drift or a spike. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 11.05 — Current-Sensor Offset Detector”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-S + the encoder/current channel from H753-Manomaly/noveltyrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P11 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Current-Sensor Offset Detector is a syllabus-scaled physical analogue of the need evidenced by BM06 · Sensor Fault Detection in Smart Extraterrestrial Habitats: Add a safe software offset or calibration bias. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needEvaluate sensor-fault detection using training, validation and test datasets, with validation used to choose thresholds.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Evaluate fault isolation, not merely anomaly detection, and include a sensor-fault-versus-mechanical-fault confuser.
The cited work uses methods beyond the course; students transfer the diagnostic question, not its neural-network implementation.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationProvide software-selectable, logged fault injection and keep one rapid-but-valid process change as a compulsory confuser.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensematched LM35-class temperature channels: one primary and one reference; LDR d…
Actuatelow-voltage fan or lamp with protected 3.3-V-compatible MOSFET/relay driver w…
Fixturedual-temperature fan chamber; fan, protected driver and safe heat/load stimul…
Protectcurrent-limited 5/12 V supply when an actuator is used; fused actuator branch…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser sensor-fault seed data with unseen fault severities
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Fault injection occurs after signal conditioning; no external pin may exceed 0–3.3 V. Verify the complete EQ-11-06 manifest before data collection.
1 · Scenario and student challenge
Detect impossible combinations among temperature, actuator duty and current. In plain language, adapt SensorTrust — Fault Detection, Confidence Scoring and Virtual Sensing so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Creates explainable sensor fusion.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-S; H753-A when an actuator response is used. Begin with the H753-S sensor rig with H753-A actuation where the variant needs a physical response and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record raw and calibrated sensor values, derivatives/variance, actuator state, ambient/reference channels, age and plausibility flags. Treat one time window containing a healthy regime or one controlled sensor-fault episode as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Anomaly detection on healthy patterns. First implement the parent baseline—range, rate-of-change and two-sensor disagreement rules—and then compare two algorithms from the faculty-issued ML whitelist. Train or set the threshold using healthy/training data only. Report event recall, false alarms per normal run and detection delay; show where the method treats a new but valid regime as abnormal. Produce a event timeline with anomaly score, threshold and false-alarm examples.
5 · Embedded integration and safe response
The host may return only TRUST_CHANNEL, DEGRADE_MODE, USE_BOUNDED_ESTIMATE, REQUEST_SERVICE or SAFE_MODE, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a rapid but physically valid process change that resembles sensor drift or a spike. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 11.06 — Cross-Sensor Consistency Monitor”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-S; H753-A when an actuator response is usedanomaly/noveltyrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P11 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Cross-Sensor Consistency Monitor is a syllabus-scaled physical analogue of the need evidenced by BM06 · Sensor Fault Detection in Smart Extraterrestrial Habitats: Detect impossible combinations among temperature, actuator duty and current. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needEvaluate sensor-fault detection using training, validation and test datasets, with validation used to choose thresholds.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Evaluate fault isolation, not merely anomaly detection, and include a sensor-fault-versus-mechanical-fault confuser.
The cited work uses methods beyond the course; students transfer the diagnostic question, not its neural-network implementation.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationProvide software-selectable, logged fault injection and keep one rapid-but-valid process change as a compulsory confuser.
Variant 11.07
Slow-Response Sensor Detector
Engineering purpose: Addresses dynamically wrong but plausible readings.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensematched LM35-class temperature channels: one primary and one reference; LDR d…
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser sensor-fault seed data with unseen fault severities
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Fault injection occurs after signal conditioning; no external pin may exceed 0–3.3 V. Verify the complete EQ-11-07 manifest before data collection.
1 · Scenario and student challenge
Apply filtered/delayed values to emulate lag. In plain language, adapt SensorTrust — Fault Detection, Confidence Scoring and Virtual Sensing so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Addresses dynamically wrong but plausible readings.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-S; H753-A when an actuator response is used. Begin with the H753-S sensor rig with H753-A actuation where the variant needs a physical response and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record raw and calibrated sensor values, derivatives/variance, actuator state, ambient/reference channels, age and plausibility flags. Treat one time window containing a healthy regime or one controlled sensor-fault episode as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Fault classification using lag features. First implement the parent baseline—range, rate-of-change and two-sensor disagreement rules—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only TRUST_CHANNEL, DEGRADE_MODE, USE_BOUNDED_ESTIMATE, REQUEST_SERVICE or SAFE_MODE, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a rapid but physically valid process change that resembles sensor drift or a spike. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 11.07 — Slow-Response Sensor Detector”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-S; H753-A when an actuator response is usedclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P11 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Slow-Response Sensor Detector is a syllabus-scaled physical analogue of the need evidenced by BM06 · Sensor Fault Detection in Smart Extraterrestrial Habitats: Apply filtered/delayed values to emulate lag. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needEvaluate sensor-fault detection using training, validation and test datasets, with validation used to choose thresholds.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Evaluate fault isolation, not merely anomaly detection, and include a sensor-fault-versus-mechanical-fault confuser.
The cited work uses methods beyond the course; students transfer the diagnostic question, not its neural-network implementation.
Implementation modeOrganiser-supported assignmentMay be issued only after the named seed history, reference specimens, calibration set or controlled fixture is prepared.
Required organiser provisionComplete before team allocationProvide software-selectable, logged fault injection and keep one rapid-but-valid process change as a compulsory confuser.
Variant 11.08
Intermittent Connector Detector
Engineering purpose: Represents common field wiring faults.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensematched LM35-class temperature channels: one primary and one reference; LDR d…
ActuateNo powered actuator is required.
Fixturesensor connector fault panel; keyed NORMAL/BRIEF-OPEN/SPIKE switch bank and d…
ProtectUSB board-power path only.
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser sensor-fault seed data with unseen fault severities
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Fault injection occurs after signal conditioning; no external pin may exceed 0–3.3 V. Verify the complete EQ-11-08 manifest before data collection.
1 · Scenario and student challenge
Inject short dropouts or spikes. In plain language, adapt SensorTrust — Fault Detection, Confidence Scoring and Virtual Sensing so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Represents common field wiring faults.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-S; H753-A when an actuator response is used. Begin with the H753-S sensor rig with H753-A actuation where the variant needs a physical response and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record raw and calibrated sensor values, derivatives/variance, actuator state, ambient/reference channels, age and plausibility flags. Treat one time window containing a healthy regime or one controlled sensor-fault episode as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Event classification and detection latency. First implement the parent baseline—range, rate-of-change and two-sensor disagreement rules—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only TRUST_CHANNEL, DEGRADE_MODE, USE_BOUNDED_ESTIMATE, REQUEST_SERVICE or SAFE_MODE, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a rapid but physically valid process change that resembles sensor drift or a spike. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 11.08 — Intermittent Connector Detector”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-S; H753-A when an actuator response is usedclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P11 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Intermittent Connector Detector is a syllabus-scaled physical analogue of the need evidenced by BM06 · Sensor Fault Detection in Smart Extraterrestrial Habitats: Inject short dropouts or spikes. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needEvaluate sensor-fault detection using training, validation and test datasets, with validation used to choose thresholds.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Evaluate fault isolation, not merely anomaly detection, and include a sensor-fault-versus-mechanical-fault confuser.
The cited work uses methods beyond the course; students transfer the diagnostic question, not its neural-network implementation.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationProvide software-selectable, logged fault injection and keep one rapid-but-valid process change as a compulsory confuser.
Variant 11.09
Virtual Temperature Sensor
Engineering purpose: Demonstrates virtual sensing while retaining safety.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensematched LM35-class temperature channels: one primary and one reference; LDR d…
Actuatelow-voltage fan or lamp with protected 3.3-V-compatible MOSFET/relay driver w…
Fixturedual-temperature fan chamber; short sensor-disconnect switch and safe replace…
Protectcurrent-limited 5/12 V supply when an actuator is used; fused actuator branch…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser sensor-fault seed data with unseen fault severities
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Fault injection occurs after signal conditioning; no external pin may exceed 0–3.3 V. Verify the complete EQ-11-09 manifest before data collection.
1 · Scenario and student challenge
Estimate temperature from history, actuator duty and starting condition during brief sensor loss. In plain language, adapt SensorTrust — Fault Detection, Confidence Scoring and Virtual Sensing so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Demonstrates virtual sensing while retaining safety.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-S; H753-A when an actuator response is used. Begin with the H753-S sensor rig with H753-A actuation where the variant needs a physical response and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record raw and calibrated sensor values, derivatives/variance, actuator state, ambient/reference channels, age and plausibility flags. Treat one time window containing a healthy regime or one controlled sensor-fault episode as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Regression with bounded use. First implement the parent baseline—range, rate-of-change and two-sensor disagreement rules—and then compare two algorithms from the faculty-issued ML whitelist. Report MAE and RMSE on whole held-out runs, show predicted-versus-measured values, and inspect error by operating condition. If the target is converted to a safe/unsafe decision, also report missed-unsafe and unnecessary-conservative actions. Produce a predicted-versus-measured plot with residuals by operating condition.
5 · Embedded integration and safe response
The host may return only TRUST_CHANNEL, DEGRADE_MODE, USE_BOUNDED_ESTIMATE, REQUEST_SERVICE or SAFE_MODE, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a rapid but physically valid process change that resembles sensor drift or a spike. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 11.09 — Virtual Temperature Sensor”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-S; H753-A when an actuator response is usedregression/outcomerun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P11 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Virtual Temperature Sensor is a syllabus-scaled physical analogue of the need evidenced by BM06 · Sensor Fault Detection in Smart Extraterrestrial Habitats: Estimate temperature from history, actuator duty and starting condition during brief sensor loss. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needEvaluate sensor-fault detection using training, validation and test datasets, with validation used to choose thresholds.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Evaluate fault isolation, not merely anomaly detection, and include a sensor-fault-versus-mechanical-fault confuser.
The cited work uses methods beyond the course; students transfer the diagnostic question, not its neural-network implementation.
Implementation modeOrganiser-supported assignmentMay be issued only after the named seed history, reference specimens, calibration set or controlled fixture is prepared.
Required organiser provisionComplete before team allocationProvide software-selectable, logged fault injection and keep one rapid-but-valid process change as a compulsory confuser.
Variant 11.10
Sensor-Swap/Miscalibration Auditor
Engineering purpose: Targets commissioning errors, not only component failure.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensematched LM35-class temperature channels: one primary and one reference; LDR d…
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser sensor-fault seed data with unseen fault severities
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Fault injection occurs after signal conditioning; no external pin may exceed 0–3.3 V. Verify the complete EQ-11-10 manifest before data collection.
1 · Scenario and student challenge
Detect swapped channels or wrong calibration scaling in software. In plain language, adapt SensorTrust — Fault Detection, Confidence Scoring and Virtual Sensing so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Targets commissioning errors, not only component failure.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-S; H753-A when an actuator response is used. Begin with the H753-S sensor rig with H753-A actuation where the variant needs a physical response and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record raw and calibrated sensor values, derivatives/variance, actuator state, ambient/reference channels, age and plausibility flags. Treat one time window containing a healthy regime or one controlled sensor-fault episode as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Configuration-fault classification. First implement the parent baseline—range, rate-of-change and two-sensor disagreement rules—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only TRUST_CHANNEL, DEGRADE_MODE, USE_BOUNDED_ESTIMATE, REQUEST_SERVICE or SAFE_MODE, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a rapid but physically valid process change that resembles sensor drift or a spike. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 11.10 — Sensor-Swap/Miscalibration Auditor”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-S; H753-A when an actuator response is usedclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P11 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Sensor-Swap/Miscalibration Auditor is a syllabus-scaled physical analogue of the need evidenced by BM06 · Sensor Fault Detection in Smart Extraterrestrial Habitats: Detect swapped channels or wrong calibration scaling in software. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needEvaluate sensor-fault detection using training, validation and test datasets, with validation used to choose thresholds.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Evaluate fault isolation, not merely anomaly detection, and include a sensor-fault-versus-mechanical-fault confuser.
The cited work uses methods beyond the course; students transfer the diagnostic question, not its neural-network implementation.
Implementation modeOrganiser-supported assignmentMay be issued only after the named seed history, reference specimens, calibration set or controlled fixture is prepared.
Required organiser provisionComplete before team allocationProvide software-selectable, logged fault injection and keep one rapid-but-valid process change as a compulsory confuser.
Problem 12 · 10 variants · Sensing, environment and smart product intelligence
Assigned Faculty Master pair for P12: one nominated ESD Faculty Master and one nominated ML Faculty Master shall jointly master this parent problem and variants V1-V10. The ESD Master owns hardware, firmware, control, communication and safety verification; the ML Master owns data, baselines, models, validation and bounded decision-policy verification. Together they teach and guide ten teams (one for each variant and up to 40 students), supervise five teams in Wave A and five in Wave B, witness integration and sign every final evaluation.
The problem
Many small production lines need a low-cost decision about shade, reflectance, opacity, label presence or surface finish. A single LDR cannot perform camera-grade inspection, but a controlled illumination-and-positioning fixture can produce useful scalar optical signatures. The challenge is to design a modest, honest sorting product that measures under controlled conditions and knows when it is uncertain.
Smart embedded product to build
Build an explainable tabletop optical inspection cell around the NUCLEO-H753ZI. Inside a fixed dark/reference-calibrated geometry, the board samples an LDR under approved illumination/servo angles, attaches specimen and run IDs, and controls a low-torque diverter. The host classifies shade/reflectance/opacity/label state or regresses a scalar quality value. Firmware maps only confident known classes to bins and sends every uncertain/unknown specimen to HOLD or REJECT_UNKNOWN.
NUCLEO-H753ZI realization and issued pack
NUCLEO-H753ZI / MB1364E with H753-S, enclosed illumination fixture and low-torque servo
LDR ADC with dark/reference subtraction and fixed geometry; optional ambient/temperature context
timer PWM positions scanner/diverter only at whitelisted angles/bins
B1 or guarded external button creates specimen/run ID; repeated readings share specimen ID
USART3 VCP carries calibrated optical signatures and bounded bin/reject recommendation
split evaluation by specimen, never by repeated sample row
Intelligence to incorporate
Use normalised reflectance, multiple-angle readings, dark/reference subtraction, variability and ambient/temperature context. Compare fixed thresholds with logistic/tree classifiers. Split by physical specimen, not repeated readings of the same item. Evaluate macro-F1, uncertain-reject rate and false-accept cost.
Permitted output/action set
BIN_A · BIN_B · BIN_C · HOLD · REJECT_UNKNOWN
Canonical family command contract: every parent brief, variant, host message and MCU acknowledgement for P12 shall use these exact identifiers. A variant may use only the applicable subset; it shall not introduce a synonym.
Core problem equipment · EQ-12-CORE
Complete equipment required for one core-problem team
Standalone family BOM. This list supports the parent problem itself. An allocated variant uses its own complete table later in this card. A component mentioned again in the fixture description is the same mounted unit, not another copy.
4 students; 3 by approved exception1 H753 board1 team laptopquantities per team
Controller1 H753 board + 1 laptop
SenseLDR divider producing 0–3.3 V; stable diffused white LED plus current-limitin…
Actuateexternally powered low-torque servo with verified 3.3-V PWM input; two- or th…
Fixtureopaque optical tunnel with fixed LED–sample–LDR geometry; specimen tray/chute…
Protectregulated 5 V, 1–2 A supply for light and servo; fused/guarded servo branch a…
System block
Complete quantity and equipment per team
Purpose / acceptance condition
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser-held unseen specimen set; repeated readings keep the same specimen_id
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Release-to-team condition: The sample is classified from controlled LDR measurements, not from a camera or manually entered label. The organiser signs the electrical, mechanical and communication acceptance checklist before H0:00.
Not duplicated inside the kit: supervised rework tools and the oscilloscope/logic-analyser station are shared at the ratio stated above. Everything else in this table is issued to, reserved for, or digitally assigned to this team.
Controlled self-learning extension
Recommended Test calibration transfer across two optical fixtures or illumination sessions. Compare raw intensity with normalized/dark-reference features and define when recalibration is mandatory.
System safety and non-negotiable boundary
Use only nonhazardous mock specimens. Servo motion is low-force and bounded. The project must explicitly state that it is a prototype optical classifier, not a certified food, medical or materials-inspection system.
Student interpretation — what this challenge really asks
A single LDR reading is too dependent on distance, angle and ambient light for reliable sorting. Students build a controlled illumination/position protocol and use explainable tabular ML to make a reject-or-divert decision.
Independent data unitone complete specimen inspection using the declared scan protocol.
Closest misleading casethe same specimen under a changed distance, orientation or ambient-light condition.
Definition of successStudents must sort known samples and safely reject an unknown or shifted condition without manual threshold retuning.
Visual system blueprint
Physical processControlled optical specimen scanGenerate labelled, safe and repeatable conditions.
ObserveLDR value, reference/ambient value, one or more approved anglesPreserve units, timestamps, run identity and signal quality.
H753 responsibilityControl and protectperform repeatable illumination/angle sampling and move the low-force diverter only to approved bins.
Host intelligenceLearn the distinctionclassify specimen reflectance/category, estimate a continuous optical index or reject unfamiliar samples.
Bounded outcomeBIN_A · BIN_B · BIN_C · HOLD · REJECT_UNKNOWNMCU validates, acknowledges and may refuse the request.
Recommended build journey
Make the process repeatableAssemble the enclosed H753-S LDR/LED inspection path with an externally powered servo diverter; define reference and target conditions before collecting data.
Prove deterministic firmwarePerform repeatable illumination/angle sampling and move the low-force diverter only to approved bins. Demonstrate every hard limit before connecting ML.
Build trustworthy trialsTreat one complete specimen inspection using the declared scan protocol as independent; calibrate, label and split by run/session.
Beat a real baselineCompare single calibrated LDR threshold or nearest reference mean with two syllabus-approved classical models.
Close and challenge the loopReturn only the applicable subset of BIN_A · BIN_B · BIN_C · HOLD · REJECT_UNKNOWN; test the target, nearest confuser, stale command and host loss.
Definition of done
Firmware controls safely before, during and after host connection.
Portfolio shows calibration-normalized feature distribution and confusion matrix by lighting context and one honest failure case.
Problem-specific evidence at the common reviews
R1 · Design
Define controlled fixture, specimen classes, lighting/reference procedure, reject policy and split by specimen.
R2 · Embedded
Show repeatable acquisition, sample trigger, ambient reference, servo diverter and bounded bins.
R3 · Data
Submit multiple physical specimens per class, quality plots and threshold baseline.
R4 · ML
Present model/confidence calibration and errors on unseen specimens.
R5 · Integration
Integrate live sort/reject, then test ambient-light disturbance, unknown specimen and host loss.
Final
Sort a blind specimen set and report both classification quality and honest reject behaviour.
Portfolio/Kaggle outcome
Kaggle dataset: specimen-level optical readings, photos only as documentation—not model input—plus data dictionary, specimen-group split, threshold baseline, classifier, confidence policy and error-gallery narrative.
Industry alignment and validation basis
ReflectSort: external references and required evidence
The listed sources establish relevance, test discipline and implementation precedent. They do not modify the common syllabus boundary, safety rules or 100-mark assessment rubric.
Family implementation profile
Variant availability: 9 standard assignment(s); 1 organiser-supported assignment(s).
Public evidence: reproducible firmware, protocol, dataset, notebook/model, test report and demonstration video.
What the external benchmark confirms
The problem has a recognisable industrial or challenge analogue, a measurable data task, a defensible embedded implementation and a safe operational decision. Every one of its ten variants is mapped separately below.
Condition before team allocation
Enclose the optical path, standardise specimen presentation and reserve truly unseen specimens for the reject/transfer test.
Frame cyber-physical systems as integrations of logical, physical and human components with concerns including trustworthiness and interoperability.
Evaluate the complete sense–decide–act system, its interfaces and failure behaviour—not a disconnected model or dashboard.
Open the 10 fully elaborated student variant briefs
Choose only the variant allocated to your team. Read it together with the parent problem above: the card expands the experimental delta, while every hardware, safety, integration and review requirement of the family remains active.
Variant 12.01
Electronic-Component Shade Sorter
Engineering purpose: Relevant to low-cost visual inspection.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
SenseLDR divider producing 0–3.3 V; stable diffused white LED plus current-limitin…
Actuateexternally powered low-torque servo with verified 3.3-V PWM input; two- or th…
Fixtureoptical tunnel and servo diverter; independently labelled dark/light electron…
Protectregulated 5 V, 1–2 A supply for light and servo; fused/guarded servo branch a…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser-held unseen specimen set; repeated readings keep the same specimen_id
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: The sample is classified from controlled LDR measurements, not from a camera or manually entered label. Verify the complete EQ-12-01 manifest before data collection.
1 · Scenario and student challenge
Sort safe component packages or mock parts by dark/light surface class. In plain language, adapt ReflectSort — Explainable Optical Mini-Sorting Cell so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Relevant to low-cost visual inspection.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-S + controlled light path + low-force servo diverter + the named safe mechanical/condition fixture. Begin with the enclosed H753-S LDR/LED inspection path with an externally powered servo diverter and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record LDR value, reference/ambient value, one or more approved angles, settling time, specimen/run ID and actuator state. Treat one complete specimen inspection using the declared scan protocol as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Multiclass reflectance classification. First implement the parent baseline—single calibrated LDR threshold or nearest reference mean—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only BIN_A, BIN_B, BIN_C, REJECT_UNKNOWN or HOLD, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with the same specimen under a changed distance, orientation or ambient-light condition. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 12.01 — Electronic-Component Shade Sorter”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P12 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Electronic-Component Shade Sorter is a syllabus-scaled physical analogue of the need evidenced by IU07 · Sensor-Based and Optical Sorting Solutions: Sort safe component packages or mock parts by dark/light surface class. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needCombine sensors, mechanics and software in optical sorting systems to improve material recovery, yield and product quality.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Use untouched held-out cases, expose false rejects as well as missed failures, and preserve specimen/run identity.
The handbook uses a small physical STM32 cell and syllabus-approved tabular models rather than Bosch-scale data or winning ensembles.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationEnclose the optical path, standardise specimen presentation and reserve truly unseen specimens for the reject/transfer test.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
SenseLDR divider producing 0–3.3 V; stable diffused white LED plus current-limitin…
Actuateexternally powered low-torque servo with verified 3.3-V PWM input; two- or th…
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser-held unseen specimen set; repeated readings keep the same specimen_id
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: The sample is classified from controlled LDR measurements, not from a camera or manually entered label. Verify the complete EQ-12-02 manifest before data collection.
1 · Scenario and student challenge
Measure transmitted/reflected light through different films or mock windows. In plain language, adapt ReflectSort — Explainable Optical Mini-Sorting Cell so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Adds continuous quality target.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-S + controlled light path + low-force servo diverter + the named safe mechanical/condition fixture. Begin with the enclosed H753-S LDR/LED inspection path with an externally powered servo diverter and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record LDR value, reference/ambient value, one or more approved angles, settling time, specimen/run ID and actuator state. Treat one complete specimen inspection using the declared scan protocol as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Opacity regression or class prediction. First implement the parent baseline—single calibrated LDR threshold or nearest reference mean—and then compare two algorithms from the faculty-issued ML whitelist. Report MAE and RMSE on whole held-out runs, show predicted-versus-measured values, and inspect error by operating condition. If the target is converted to a safe/unsafe decision, also report missed-unsafe and unnecessary-conservative actions. Produce a predicted-versus-measured plot with residuals by operating condition.
5 · Embedded integration and safe response
The host may return only BIN_A, BIN_B, BIN_C, REJECT_UNKNOWN or HOLD, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with the same specimen under a changed distance, orientation or ambient-light condition. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 12.02 — Packaging Transparency Grader”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P12 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Packaging Transparency Grader is a syllabus-scaled physical analogue of the need evidenced by IU07 · Sensor-Based and Optical Sorting Solutions: Measure transmitted/reflected light through different films or mock windows. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needCombine sensors, mechanics and software in optical sorting systems to improve material recovery, yield and product quality.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Use untouched held-out cases, expose false rejects as well as missed failures, and preserve specimen/run identity.
The handbook uses a small physical STM32 cell and syllabus-approved tabular models rather than Bosch-scale data or winning ensembles.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationEnclose the optical path, standardise specimen presentation and reserve truly unseen specimens for the reject/transfer test.
Variant 12.03
Label-Presence Verifier
Engineering purpose: Maps to packaging verification.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
SenseLDR divider producing 0–3.3 V; stable diffused white LED plus current-limitin…
Actuateexternally powered low-torque servo with verified 3.3-V PWM input; two- or th…
Fixturefixed-position label inspection jig; cards/containers with label present, abs…
Protectregulated 5 V, 1–2 A supply for light and servo; fused/guarded servo branch a…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser-held unseen specimen set; repeated readings keep the same specimen_id
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: The sample is classified from controlled LDR measurements, not from a camera or manually entered label. Verify the complete EQ-12-03 manifest before data collection.
1 · Scenario and student challenge
Detect whether a high-contrast label is present at a controlled location. In plain language, adapt ReflectSort — Explainable Optical Mini-Sorting Cell so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Maps to packaging verification.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-S + controlled light path + low-force servo diverter + the named safe mechanical/condition fixture. Begin with the enclosed H753-S LDR/LED inspection path with an externally powered servo diverter and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record LDR value, reference/ambient value, one or more approved angles, settling time, specimen/run ID and actuator state. Treat one complete specimen inspection using the declared scan protocol as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Binary classification with reject class. First implement the parent baseline—single calibrated LDR threshold or nearest reference mean—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only BIN_A, BIN_B, BIN_C, REJECT_UNKNOWN or HOLD, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with the same specimen under a changed distance, orientation or ambient-light condition. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 12.03 — Label-Presence Verifier”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P12 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Label-Presence Verifier is a syllabus-scaled physical analogue of the need evidenced by IU07 · Sensor-Based and Optical Sorting Solutions: Detect whether a high-contrast label is present at a controlled location. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needCombine sensors, mechanics and software in optical sorting systems to improve material recovery, yield and product quality.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Use untouched held-out cases, expose false rejects as well as missed failures, and preserve specimen/run identity.
The handbook uses a small physical STM32 cell and syllabus-approved tabular models rather than Bosch-scale data or winning ensembles.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationEnclose the optical path, standardise specimen presentation and reserve truly unseen specimens for the reject/transfer test.
Variant 12.04
Surface-Finish Grader
Engineering purpose: Multiple angles make the sensing scientifically justified.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
SenseLDR divider producing 0–3.3 V; stable diffused white LED plus current-limitin…
Actuateexternally powered low-torque servo with verified 3.3-V PWM input; two- or th…
Fixtureservo angle-scan optical jig; matte, semi-gloss and glossy swatches with inde…
Protectregulated 5 V, 1–2 A supply for light and servo; fused/guarded servo branch a…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser-held unseen specimen set; repeated readings keep the same specimen_id
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: The sample is classified from controlled LDR measurements, not from a camera or manually entered label. Verify the complete EQ-12-04 manifest before data collection.
1 · Scenario and student challenge
Distinguish matte, semi-gloss and glossy mock samples using angle scans. In plain language, adapt ReflectSort — Explainable Optical Mini-Sorting Cell so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Multiple angles make the sensing scientifically justified.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-S + controlled light path + low-force servo diverter + the named safe mechanical/condition fixture. Begin with the enclosed H753-S LDR/LED inspection path with an externally powered servo diverter and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record LDR value, reference/ambient value, one or more approved angles, settling time, specimen/run ID and actuator state. Treat one complete specimen inspection using the declared scan protocol as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Multiclass classification. First implement the parent baseline—single calibrated LDR threshold or nearest reference mean—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only BIN_A, BIN_B, BIN_C, REJECT_UNKNOWN or HOLD, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with the same specimen under a changed distance, orientation or ambient-light condition. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 12.04 — Surface-Finish Grader”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P12 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Surface-Finish Grader is a syllabus-scaled physical analogue of the need evidenced by IU07 · Sensor-Based and Optical Sorting Solutions: Distinguish matte, semi-gloss and glossy mock samples using angle scans. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needCombine sensors, mechanics and software in optical sorting systems to improve material recovery, yield and product quality.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Use untouched held-out cases, expose false rejects as well as missed failures, and preserve specimen/run identity.
The handbook uses a small physical STM32 cell and syllabus-approved tabular models rather than Bosch-scale data or winning ensembles.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationEnclose the optical path, standardise specimen presentation and reserve truly unseen specimens for the reject/transfer test.
Variant 12.05
Tablet/Token Shade Sorter
Engineering purpose: Demonstrates limitations of scalar optics honestly.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
SenseLDR divider producing 0–3.3 V; stable diffused white LED plus current-limitin…
Actuateexternally powered low-torque servo with verified 3.3-V PWM input; two- or th…
Fixturetoken feed tray and servo diverter; nonmedical tokens spanning at least three…
Protectregulated 5 V, 1–2 A supply for light and servo; fused/guarded servo branch a…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser-held unseen specimen set; repeated readings keep the same specimen_id
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: The sample is classified from controlled LDR measurements, not from a camera or manually entered label. Verify the complete EQ-12-05 manifest before data collection.
1 · Scenario and student challenge
Sort nonmedical coloured tokens by broad intensity bands. In plain language, adapt ReflectSort — Explainable Optical Mini-Sorting Cell so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Demonstrates limitations of scalar optics honestly.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-S + controlled light path + low-force servo diverter + the named safe mechanical/condition fixture. Begin with the enclosed H753-S LDR/LED inspection path with an externally powered servo diverter and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record LDR value, reference/ambient value, one or more approved angles, settling time, specimen/run ID and actuator state. Treat one complete specimen inspection using the declared scan protocol as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Classification with specimen-group split. First implement the parent baseline—single calibrated LDR threshold or nearest reference mean—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only BIN_A, BIN_B, BIN_C, REJECT_UNKNOWN or HOLD, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with the same specimen under a changed distance, orientation or ambient-light condition. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 12.05 — Tablet/Token Shade Sorter”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P12 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Tablet/Token Shade Sorter is a syllabus-scaled physical analogue of the need evidenced by IU07 · Sensor-Based and Optical Sorting Solutions: Sort nonmedical coloured tokens by broad intensity bands. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needCombine sensors, mechanics and software in optical sorting systems to improve material recovery, yield and product quality.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Use untouched held-out cases, expose false rejects as well as missed failures, and preserve specimen/run identity.
The handbook uses a small physical STM32 cell and syllabus-approved tabular models rather than Bosch-scale data or winning ensembles.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationEnclose the optical path, standardise specimen presentation and reserve truly unseen specimens for the reject/transfer test.
Variant 12.06
Seed/Grain Shade Prototype
Engineering purpose: Creates agri-tech context while avoiding unsupported quality claims.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
SenseLDR divider producing 0–3.3 V; stable diffused white LED plus current-limitin…
Actuateexternally powered low-torque servo with verified 3.3-V PWM input; two- or th…
Fixtureclean sample tray and optical tunnel; food-safe seeds/grains or inert replica…
Protectregulated 5 V, 1–2 A supply for light and servo; fused/guarded servo branch a…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser-held unseen specimen set; repeated readings keep the same specimen_id
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: The sample is classified from controlled LDR measurements, not from a camera or manually entered label. Verify the complete EQ-12-06 manifest before data collection.
1 · Scenario and student challenge
Use clean mock/food-safe samples only to separate broad shade groups. In plain language, adapt ReflectSort — Explainable Optical Mini-Sorting Cell so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Creates agri-tech context while avoiding unsupported quality claims.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-S + controlled light path + low-force servo diverter + the named safe mechanical/condition fixture. Begin with the enclosed H753-S LDR/LED inspection path with an externally powered servo diverter and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record LDR value, reference/ambient value, one or more approved angles, settling time, specimen/run ID and actuator state. Treat one complete specimen inspection using the declared scan protocol as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Classification with strong disclaimer. First implement the parent baseline—single calibrated LDR threshold or nearest reference mean—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only BIN_A, BIN_B, BIN_C, REJECT_UNKNOWN or HOLD, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with the same specimen under a changed distance, orientation or ambient-light condition. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 12.06 — Seed/Grain Shade Prototype”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P12 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Seed/Grain Shade Prototype is a syllabus-scaled physical analogue of the need evidenced by IU07 · Sensor-Based and Optical Sorting Solutions: Use clean mock/food-safe samples only to separate broad shade groups. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needCombine sensors, mechanics and software in optical sorting systems to improve material recovery, yield and product quality.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Use untouched held-out cases, expose false rejects as well as missed failures, and preserve specimen/run identity.
The handbook uses a small physical STM32 cell and syllabus-approved tabular models rather than Bosch-scale data or winning ensembles.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationEnclose the optical path, standardise specimen presentation and reserve truly unseen specimens for the reject/transfer test.
Variant 12.07
Paper/Print Density Inspector
Engineering purpose: Provides a measurable manufacturing-quality use case.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
SenseLDR divider producing 0–3.3 V; stable diffused white LED plus current-limitin…
Actuateexternally powered low-torque servo with verified 3.3-V PWM input; two- or th…
Fixtureflat-card optical jig; independently printed density cards with calibration/r…
Protectregulated 5 V, 1–2 A supply for light and servo; fused/guarded servo branch a…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser-held unseen specimen set; repeated readings keep the same specimen_id
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: The sample is classified from controlled LDR measurements, not from a camera or manually entered label. Verify the complete EQ-12-07 manifest before data collection.
1 · Scenario and student challenge
Estimate print darkness on sample cards. In plain language, adapt ReflectSort — Explainable Optical Mini-Sorting Cell so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Provides a measurable manufacturing-quality use case.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-S + controlled light path + low-force servo diverter + the named safe mechanical/condition fixture. Begin with the enclosed H753-S LDR/LED inspection path with an externally powered servo diverter and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record LDR value, reference/ambient value, one or more approved angles, settling time, specimen/run ID and actuator state. Treat one complete specimen inspection using the declared scan protocol as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Regression/classification. First implement the parent baseline—single calibrated LDR threshold or nearest reference mean—and then compare two algorithms from the faculty-issued ML whitelist. Report MAE and RMSE on whole held-out runs, show predicted-versus-measured values, and inspect error by operating condition. If the target is converted to a safe/unsafe decision, also report missed-unsafe and unnecessary-conservative actions. Produce a predicted-versus-measured plot with residuals by operating condition.
5 · Embedded integration and safe response
The host may return only BIN_A, BIN_B, BIN_C, REJECT_UNKNOWN or HOLD, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with the same specimen under a changed distance, orientation or ambient-light condition. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 12.07 — Paper/Print Density Inspector”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P12 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Paper/Print Density Inspector is a syllabus-scaled physical analogue of the need evidenced by IU07 · Sensor-Based and Optical Sorting Solutions: Estimate print darkness on sample cards. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needCombine sensors, mechanics and software in optical sorting systems to improve material recovery, yield and product quality.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Use untouched held-out cases, expose false rejects as well as missed failures, and preserve specimen/run identity.
The handbook uses a small physical STM32 cell and syllabus-approved tabular models rather than Bosch-scale data or winning ensembles.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationEnclose the optical path, standardise specimen presentation and reserve truly unseen specimens for the reject/transfer test.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
SenseLDR divider producing 0–3.3 V; stable diffused white LED plus current-limitin…
Actuateexternally powered low-torque servo with verified 3.3-V PWM input; two- or th…
Fixturemock bottle-cap presence/type jig; caps or inert cap tokens with controlled r…
Protectregulated 5 V, 1–2 A supply for light and servo; fused/guarded servo branch a…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser-held unseen specimen set; repeated readings keep the same specimen_id
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: The sample is classified from controlled LDR measurements, not from a camera or manually entered label. Verify the complete EQ-12-08 manifest before data collection.
1 · Scenario and student challenge
Use controlled reflective markers on mock caps. In plain language, adapt ReflectSort — Explainable Optical Mini-Sorting Cell so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Models packaging-line inspection.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-S + controlled light path + low-force servo diverter + the named safe mechanical/condition fixture. Begin with the enclosed H753-S LDR/LED inspection path with an externally powered servo diverter and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record LDR value, reference/ambient value, one or more approved angles, settling time, specimen/run ID and actuator state. Treat one complete specimen inspection using the declared scan protocol as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Binary/multiclass classification. First implement the parent baseline—single calibrated LDR threshold or nearest reference mean—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only BIN_A, BIN_B, BIN_C, REJECT_UNKNOWN or HOLD, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with the same specimen under a changed distance, orientation or ambient-light condition. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 12.08 — Bottle-Cap Presence/Type Simulator”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P12 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Bottle-Cap Presence/Type Simulator is a syllabus-scaled physical analogue of the need evidenced by IU07 · Sensor-Based and Optical Sorting Solutions: Use controlled reflective markers on mock caps. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needCombine sensors, mechanics and software in optical sorting systems to improve material recovery, yield and product quality.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Use untouched held-out cases, expose false rejects as well as missed failures, and preserve specimen/run identity.
The handbook uses a small physical STM32 cell and syllabus-approved tabular models rather than Bosch-scale data or winning ensembles.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationEnclose the optical path, standardise specimen presentation and reserve truly unseen specimens for the reject/transfer test.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
SenseLDR divider producing 0–3.3 V; stable diffused white LED plus current-limitin…
Actuateexternally powered low-torque servo with verified 3.3-V PWM input; two- or th…
Fixturemock connector positioning jig; connector/cable-marker specimens using broad…
Protectregulated 5 V, 1–2 A supply for light and servo; fused/guarded servo branch a…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser-held unseen specimen set; repeated readings keep the same specimen_id
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: The sample is classified from controlled LDR measurements, not from a camera or manually entered label. Verify the complete EQ-12-09 manifest before data collection.
1 · Scenario and student challenge
Classify broad light/dark markers on mock connectors. In plain language, adapt ReflectSort — Explainable Optical Mini-Sorting Cell so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Supports assembly mistake prevention.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-S + controlled light path + low-force servo diverter + the named safe mechanical/condition fixture. Begin with the enclosed H753-S LDR/LED inspection path with an externally powered servo diverter and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record LDR value, reference/ambient value, one or more approved angles, settling time, specimen/run ID and actuator state. Treat one complete specimen inspection using the declared scan protocol as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Classification with ambient normalisation. First implement the parent baseline—single calibrated LDR threshold or nearest reference mean—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only BIN_A, BIN_B, BIN_C, REJECT_UNKNOWN or HOLD, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with the same specimen under a changed distance, orientation or ambient-light condition. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 12.09 — Cable/Connector Colour-Band Verifier”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P12 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Cable/Connector Colour-Band Verifier is a syllabus-scaled physical analogue of the need evidenced by IU07 · Sensor-Based and Optical Sorting Solutions: Classify broad light/dark markers on mock connectors. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needCombine sensors, mechanics and software in optical sorting systems to improve material recovery, yield and product quality.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Use untouched held-out cases, expose false rejects as well as missed failures, and preserve specimen/run identity.
The handbook uses a small physical STM32 cell and syllabus-approved tabular models rather than Bosch-scale data or winning ensembles.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationEnclose the optical path, standardise specimen presentation and reserve truly unseen specimens for the reject/transfer test.
Variant 12.10
Unknown-Sample Reject Sorter
Engineering purpose: Makes responsible model abstention the innovation.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
SenseLDR divider producing 0–3.3 V; stable diffused white LED plus current-limitin…
Actuateexternally powered low-torque servo with verified 3.3-V PWM input; two- or th…
Fixtureoptical tunnel and three-bin diverter; At least specimens per known class plu…
Protectregulated 5 V, 1–2 A supply for light and servo; fused/guarded servo branch a…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × known-class seed dataset and organiser-held unknown specimen pack
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: The sample is classified from controlled LDR measurements, not from a camera or manually entered label. Verify the complete EQ-12-10 manifest before data collection.
1 · Scenario and student challenge
Train known classes and force uncertain/out-of-range specimens to REJECT. In plain language, adapt ReflectSort — Explainable Optical Mini-Sorting Cell so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Makes responsible model abstention the innovation.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-S + controlled light path + low-force servo diverter + the named safe mechanical/condition fixture. Begin with the enclosed H753-S LDR/LED inspection path with an externally powered servo diverter and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record LDR value, reference/ambient value, one or more approved angles, settling time, specimen/run ID and actuator state. Treat one complete specimen inspection using the declared scan protocol as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Confidence threshold or anomaly-aware rejection. First implement the parent baseline—single calibrated LDR threshold or nearest reference mean—and then compare two algorithms from the faculty-issued ML whitelist. Train or set the threshold using healthy/training data only. Report event recall, false alarms per normal run and detection delay; show where the method treats a new but valid regime as abnormal. Produce a event timeline with anomaly score, threshold and false-alarm examples.
5 · Embedded integration and safe response
The host may return only BIN_A, BIN_B, BIN_C, REJECT_UNKNOWN or HOLD, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with the same specimen under a changed distance, orientation or ambient-light condition. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 12.10 — Unknown-Sample Reject Sorter”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P12 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Unknown-Sample Reject Sorter is a syllabus-scaled physical analogue of the need evidenced by IU07 · Sensor-Based and Optical Sorting Solutions: Train known classes and force uncertain/out-of-range specimens to REJECT. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needCombine sensors, mechanics and software in optical sorting systems to improve material recovery, yield and product quality.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Use untouched held-out cases, expose false rejects as well as missed failures, and preserve specimen/run identity.
The handbook uses a small physical STM32 cell and syllabus-approved tabular models rather than Bosch-scale data or winning ensembles.
Implementation modeOrganiser-supported assignmentMay be issued only after the named seed history, reference specimens, calibration set or controlled fixture is prepared.
Required organiser provisionComplete before team allocationEnclose the optical path, standardise specimen presentation and reserve truly unseen specimens for the reject/transfer test.
Problem 13 · 10 variants · Sensing, environment and smart product intelligence
Assigned Faculty Master pair for P13: one nominated ESD Faculty Master and one nominated ML Faculty Master shall jointly master this parent problem and variants V1-V10. The ESD Master owns hardware, firmware, control, communication and safety verification; the ML Master owns data, baselines, models, validation and bounded decision-policy verification. Together they teach and guide ten teams (one for each variant and up to 40 students), supervise five teams in Wave A and five in Wave B, witness integration and sign every final evaluation.
The problem
A relay command does not prove that the connected device actually switched. Open loads, intermittent wiring, wrong loads, excessive current, welded-contact-like behaviour and thermal stress can all produce different electrical/temporal signatures. A simple controller reports only ON/OFF; a smart controller should verify the result and diagnose the likely problem.
Smart embedded product to build
Build a NUCLEO-H753ZI command-versus-response verifier for a safe low-voltage lamp, fan or small motor. The board drives only an approved relay/MOSFET stage, measures conditioned current, temperature and a physical response signal, applies dwell/retry limits and logs requested versus observed state and response delay. The host diagnoses normal, open load, wrong load, intermittent response, stuck-on-like response or overload and recommends ENERGIZE, DEENERGIZE, RETRY_ONCE, ISOLATE or INSPECTION_REQUIRED.
NUCLEO-H753ZI realization and issued pack
NUCLEO-H753ZI / MB1364E with H753-A and context channels from H753-S
3.3-V-compatible relay/MOSFET driver with flyback protection and fused low-voltage load
conditioned current ADC plus temperature and LDR/tachometer response channel
timer-based dwell/retry limit and independent overcurrent/overtemperature OFF path
Features include current before/after switch, response delay, steady current, light/speed response, temperature, cycle count and bounce/retry evidence. Compare threshold logic with logistic/tree models. Evaluate fault recall, false isolation, diagnosis latency and performance on an unseen load unit.
Canonical family command contract: every parent brief, variant, host message and MCU acknowledgement for P13 shall use these exact identifiers. A variant may use only the applicable subset; it shall not introduce a synonym.
Core problem equipment · EQ-13-CORE
Complete equipment required for one core-problem team
Standalone family BOM. This list supports the parent problem itself. An allocated variant uses its own complete table later in this card. A component mentioned again in the fixture description is the same mounted unit, not another copy.
4 students; 3 by approved exception1 H753 board1 team laptopquantities per team
Controller1 H753 board + 1 laptop
Senseconditioned 0–3.3 V current-sense channel sized to the selected load; LDR phy…
Actuateprotected low-side MOSFET or relay driver with 3.3-V input, flyback protectio…
Fixturetouch-safe low-voltage load panel with ON/OFF indicator and guarded fault-inj…
Protectcurrent-limited 5/12 V load supply; inline fuse holder plus spare fuses; hard…
System block
Complete quantity and equipment per team
Purpose / acceptance condition
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser load-signature seed dataset and fault-switching protocol
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Release-to-team condition: Only touch-safe low-voltage loads are permitted; no mains wiring or exposed conductor. The organiser signs the electrical, mechanical and communication acceptance checklist before H0:00.
Not duplicated inside the kit: supervised rework tools and the oscilloscope/logic-analyser station are shared at the ratio stated above. Everything else in this table is issued to, reserved for, or digitally assigned to this team.
Controlled self-learning extension
Recommended Add protocol versioning and hardware CRC to command-response event records, then build a host replay utility that reproduces a fault diagnosis without re-energizing the load.
System safety and non-negotiable boundary
No mains switching. Firmware enforces current/temperature limits, minimum relay dwell, maximum retries and safe OFF on communication loss. ML cannot force repeated switching beyond limits.
Student interpretation — what this challenge really asks
A command bit cannot prove that a relay, fan or lamp actually changed state. Students compare command, current and physical response to diagnose open load, blocked load, intermittent wiring and switching faults.
Independent data unitone on/off switching cycle with its complete response window.
Closest misleading casenormal inrush or delayed physical response that resembles a failed or overloaded load.
Definition of successStudents must diagnose the commanded-versus-observed mismatch and isolate safely under a hidden low-voltage fault.
Visual system blueprint
Physical processLow-voltage switched loadGenerate labelled, safe and repeatable conditions.
Observecommand, relay/MOSFET state, conditioned currentPreserve units, timestamps, run identity and signal quality.
H753 responsibilityControl and protectapply safe dwell/current rules, actuate through the approved driver and verify command–outcome consistency.
Host intelligenceLearn the distinctionidentify normal switching, open/disconnected, blocked/overloaded, intermittent or wrong-load behaviour.
Bounded outcomeENERGIZE · DEENERGIZE · RETRY_ONCE · ISOLATE · INSPECTION_REQUIREDMCU validates, acknowledges and may refuse the request.
Recommended build journey
Make the process repeatableAssemble the fused H753-A + H753-S low-voltage load bench; define reference and target conditions before collecting data.
Prove deterministic firmwareApply safe dwell/current rules, actuate through the approved driver and verify command–outcome consistency. Demonstrate every hard limit before connecting ML.
Build trustworthy trialsTreat one on/off switching cycle with its complete response window as independent; calibrate, label and split by run/session.
Beat a real baselineCompare command-versus-current threshold and response-time rule with two syllabus-approved classical models.
Close and challenge the loopReturn only the applicable subset of ENERGIZE · DEENERGIZE · RETRY_ONCE · ISOLATE · INSPECTION_REQUIRED; test the target, nearest confuser, stale command and host loss.
Definition of done
Firmware controls safely before, during and after host connection.
Demonstrate relay drive, independent overcurrent/temperature protection and command-versus-response logging.
R3 · Data
Submit healthy and injected fault trials, state labelling and threshold baseline.
R4 · ML
Show diagnostic model, latency and errors across load types/temperatures.
R5 · Integration
Integrate retry/isolate policy and pass open-load, wrong-response and host-loss tests.
Final
Diagnose blind relay/load conditions without unsafe repeated switching.
Portfolio/Kaggle outcome
Kaggle package: ‘Relay Command–Response Diagnostics’ trial dataset, state labels, response-delay analysis, baseline logic, model comparison and event-replay notebook.
Industry alignment and validation basis
SwitchGuard: external references and required evidence
The listed sources establish relevance, test discipline and implementation precedent. They do not modify the common syllabus boundary, safety rules or 100-mark assessment rubric.
Family implementation profile
Variant availability: 8 standard assignment(s); 2 organiser-supported assignment(s).
Public evidence: reproducible firmware, protocol, dataset, notebook/model, test report and demonstration video.
What the external benchmark confirms
The problem has a recognisable industrial or challenge analogue, a measurable data task, a defensible embedded implementation and a safe operational decision. Every one of its ten variants is mapped separately below.
Condition before team allocation
Pre-test fused loads and current conditioning; include normal inrush as the mandatory nearest confuser.
Combine sensor measurements and system knowledge to build condition indicators, detect faults and support predictive-maintenance decisions.
Start with an engineering baseline, justify features physically, validate on held-out operating conditions and connect inference to a maintenance action.
Open the 10 fully elaborated student variant briefs
Choose only the variant allocated to your team. Read it together with the parent problem above: the card expands the experimental delta, while every hardware, safety, integration and review requirement of the family remains active.
Variant 13.01
Lamp Open-Circuit Verifier
Engineering purpose: Two independent observables make diagnosis robust.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Senseconditioned 0–3.3 V current-sense channel sized to the selected load; LDR phy…
Actuateprotected MOSFET/relay driver; 5/12 V lamp or LED bank
Fixturetouch-safe lamp/LED load panel; LDR aligned to the lamp and open-circuit faul…
Protectcurrent-limited 5/12 V load supply; inline fuse holder plus spare fuses; hard…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser load-signature seed dataset and fault-switching protocol
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Only touch-safe low-voltage loads are permitted; no mains wiring or exposed conductor. Verify the complete EQ-13-01 manifest before data collection.
1 · Scenario and student challenge
Use current plus LDR to verify commanded illumination. In plain language, adapt SwitchGuard — Intelligent Low-Voltage Relay Load Diagnostics so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Two independent observables make diagnosis robust.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-A + H753-S response sensing. Begin with the fused H753-A + H753-S low-voltage load bench and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record command, relay/MOSFET state, conditioned current, optional speed/light/temperature response, timing and fault flags. Treat one on/off switching cycle with its complete response window as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Healthy/open/intermittent classification. First implement the parent baseline—command-versus-current threshold and response-time rule—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only ENERGIZE, DEENERGIZE, RETRY_ONCE, ISOLATE or INSPECTION_REQUIRED, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with normal inrush or delayed physical response that resembles a failed or overloaded load. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 13.01 — Lamp Open-Circuit Verifier”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P13 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Lamp Open-Circuit Verifier is a syllabus-scaled physical analogue of the need evidenced by IU05 · Intelligent Power Switches: Use current plus LDR to verify commanded illumination. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needCombine protected load switching with diagnostics and smart load management for resistive, inductive and capacitive loads.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Use untouched held-out cases, expose false rejects as well as missed failures, and preserve specimen/run identity.
The handbook uses a small physical STM32 cell and syllabus-approved tabular models rather than Bosch-scale data or winning ensembles.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationPre-test fused loads and current conditioning; include normal inrush as the mandatory nearest confuser.
Variant 13.02
Fan Connection Guardian
Engineering purpose: Distinguishes electrical open from mechanical blockage.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sense0–3.3 V current-sense channel; fan tachometer or optical speed proxy; LM35-cl…
Actuate5/12 V fan through protected MOSFET/relay driver
Fixtureshrouded fan load panel; airflow restriction screens and disconnect switch
Protectcurrent-limited 5/12 V load supply; inline fuse holder plus spare fuses; hard…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser load-signature seed dataset and fault-switching protocol
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Only touch-safe low-voltage loads are permitted; no mains wiring or exposed conductor. Verify the complete EQ-13-02 manifest before data collection.
1 · Scenario and student challenge
Use current and optional speed proxy to detect disconnected or blocked fan. In plain language, adapt SwitchGuard — Intelligent Low-Voltage Relay Load Diagnostics so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Distinguishes electrical open from mechanical blockage.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-A + H753-S response sensing. Begin with the fused H753-A + H753-S low-voltage load bench and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record command, relay/MOSFET state, conditioned current, optional speed/light/temperature response, timing and fault flags. Treat one on/off switching cycle with its complete response window as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Multiclass classification. First implement the parent baseline—command-versus-current threshold and response-time rule—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only ENERGIZE, DEENERGIZE, RETRY_ONCE, ISOLATE or INSPECTION_REQUIRED, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with normal inrush or delayed physical response that resembles a failed or overloaded load. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 13.02 — Fan Connection Guardian”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P13 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Fan Connection Guardian is a syllabus-scaled physical analogue of the need evidenced by IU05 · Intelligent Power Switches: Use current and optional speed proxy to detect disconnected or blocked fan. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needCombine protected load switching with diagnostics and smart load management for resistive, inductive and capacitive loads.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Use untouched held-out cases, expose false rejects as well as missed failures, and preserve specimen/run identity.
The handbook uses a small physical STM32 cell and syllabus-approved tabular models rather than Bosch-scale data or winning ensembles.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationPre-test fused loads and current conditioning; include normal inrush as the mandatory nearest confuser.
Variant 13.03
Motor Relay Response Verifier
Engineering purpose: Maps to industrial contactor monitoring at safe scale.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensemotor encoder; 0–3.3 V current-sense channel; LM35-class temperature channel
Actuategeared DC motor and 3.3-V H-bridge/relay driver
Fixtureguarded motor response panel; encoder and open/stall fault insert
Protectcurrent-limited 5/12 V load supply; inline fuse holder plus spare fuses; hard…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser load-signature seed dataset and fault-switching protocol
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Only touch-safe low-voltage loads are permitted; no mains wiring or exposed conductor. Verify the complete EQ-13-03 manifest before data collection.
1 · Scenario and student challenge
Confirm that current and encoder motion follow the command. In plain language, adapt SwitchGuard — Intelligent Low-Voltage Relay Load Diagnostics so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Maps to industrial contactor monitoring at safe scale.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-A + H753-M motor/encoder/current response channels. Begin with the fused H753-A + H753-S low-voltage load bench and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record command, relay/MOSFET state, conditioned current, optional speed/light/temperature response, timing and fault flags. Treat one on/off switching cycle with its complete response window as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Command-response classification. First implement the parent baseline—command-versus-current threshold and response-time rule—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only ENERGIZE, DEENERGIZE, RETRY_ONCE, ISOLATE or INSPECTION_REQUIRED, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with normal inrush or delayed physical response that resembles a failed or overloaded load. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 13.03 — Motor Relay Response Verifier”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P13 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Motor Relay Response Verifier is a syllabus-scaled physical analogue of the need evidenced by IU05 · Intelligent Power Switches: Confirm that current and encoder motion follow the command. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needCombine protected load switching with diagnostics and smart load management for resistive, inductive and capacitive loads.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Use untouched held-out cases, expose false rejects as well as missed failures, and preserve specimen/run identity.
The handbook uses a small physical STM32 cell and syllabus-approved tabular models rather than Bosch-scale data or winning ensembles.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationPre-test fused loads and current conditioning; include normal inrush as the mandatory nearest confuser.
Variant 13.04
Intermittent Cable Detector
Engineering purpose: Captures nonpersistent faults missed by one reading.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Senseconditioned 0–3.3 V current-sense channel sized to the selected load; LDR phy…
Actuateprotected MOSFET/relay driver; 5/12 V lamp or LED bank
Fixturetouch-safe lamp/LED load panel with keyed intermittent-connection switch; eve…
Protectcurrent-limited 5/12 V load supply; inline fuse holder plus spare fuses; hard…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser load-signature seed dataset and fault-switching protocol
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Only touch-safe low-voltage loads are permitted; no mains wiring or exposed conductor. Verify the complete EQ-13-04 manifest before data collection.
1 · Scenario and student challenge
Inject short connection interruptions across trials. In plain language, adapt SwitchGuard — Intelligent Low-Voltage Relay Load Diagnostics so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Captures nonpersistent faults missed by one reading.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-A + H753-S response sensing. Begin with the fused H753-A + H753-S low-voltage load bench and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record command, relay/MOSFET state, conditioned current, optional speed/light/temperature response, timing and fault flags. Treat one on/off switching cycle with its complete response window as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Intermittent-fault classification. First implement the parent baseline—command-versus-current threshold and response-time rule—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only ENERGIZE, DEENERGIZE, RETRY_ONCE, ISOLATE or INSPECTION_REQUIRED, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with normal inrush or delayed physical response that resembles a failed or overloaded load. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 13.04 — Intermittent Cable Detector”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P13 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Intermittent Cable Detector is a syllabus-scaled physical analogue of the need evidenced by IU05 · Intelligent Power Switches: Inject short connection interruptions across trials. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needCombine protected load switching with diagnostics and smart load management for resistive, inductive and capacitive loads.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Use untouched held-out cases, expose false rejects as well as missed failures, and preserve specimen/run identity.
The handbook uses a small physical STM32 cell and syllabus-approved tabular models rather than Bosch-scale data or winning ensembles.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationPre-test fused loads and current conditioning; include normal inrush as the mandatory nearest confuser.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sense0–3.3 V current-sense channel; LDR lamp-response channel; fan tachometer/resp…
Actuateprotected driver channel; keyed lamp/LED load and keyed shrouded fan load; on…
Fixturetwo-load attachment panel; low-voltage lamp/LED bank and shrouded fan, each k…
Protectcurrent-limited 5/12 V load supply; inline fuse holder plus spare fuses; hard…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser load-signature seed dataset and fault-switching protocol
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Only touch-safe low-voltage loads are permitted; no mains wiring or exposed conductor. Verify the complete EQ-13-05 manifest before data collection.
1 · Scenario and student challenge
Connect two approved low-voltage load types with different signatures. In plain language, adapt SwitchGuard — Intelligent Low-Voltage Relay Load Diagnostics so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Supports commissioning verification.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-A + H753-S response sensing. Begin with the fused H753-A + H753-S low-voltage load bench and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record command, relay/MOSFET state, conditioned current, optional speed/light/temperature response, timing and fault flags. Treat one on/off switching cycle with its complete response window as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Load identity plus anomaly class. First implement the parent baseline—command-versus-current threshold and response-time rule—and then compare two algorithms from the faculty-issued ML whitelist. Train or set the threshold using healthy/training data only. Report event recall, false alarms per normal run and detection delay; show where the method treats a new but valid regime as abnormal. Produce a event timeline with anomaly score, threshold and false-alarm examples.
5 · Embedded integration and safe response
The host may return only ENERGIZE, DEENERGIZE, RETRY_ONCE, ISOLATE or INSPECTION_REQUIRED, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with normal inrush or delayed physical response that resembles a failed or overloaded load. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 13.05 — Wrong-Load Attachment Detector”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P13 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Wrong-Load Attachment Detector is a syllabus-scaled physical analogue of the need evidenced by IU05 · Intelligent Power Switches: Connect two approved low-voltage load types with different signatures. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needCombine protected load switching with diagnostics and smart load management for resistive, inductive and capacitive loads.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Use untouched held-out cases, expose false rejects as well as missed failures, and preserve specimen/run identity.
The handbook uses a small physical STM32 cell and syllabus-approved tabular models rather than Bosch-scale data or winning ensembles.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationPre-test fused loads and current conditioning; include normal inrush as the mandatory nearest confuser.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Senseconditioned 0–3.3 V current-sense channel sized to the selected load; LDR phy…
Actuateprotected MOSFET/relay driver; 5/12 V lamp or LED bank
Fixturerepeated-switching lamp/LED load panel; LM35 probe fixed to the driver/load c…
Protectcurrent-limited 5/12 V load supply; inline fuse holder plus spare fuses; hard…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser load-signature seed dataset and fault-switching protocol
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Only touch-safe low-voltage loads are permitted; no mains wiring or exposed conductor. Verify the complete EQ-13-06 manifest before data collection.
1 · Scenario and student challenge
Track temperature/current drift over repeated switching. In plain language, adapt SwitchGuard — Intelligent Low-Voltage Relay Load Diagnostics so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Adds maintenance evidence.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-A + H753-S response sensing. Begin with the fused H753-A + H753-S low-voltage load bench and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record command, relay/MOSFET state, conditioned current, optional speed/light/temperature response, timing and fault flags. Treat one on/off switching cycle with its complete response window as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Health classification or anomaly score. First implement the parent baseline—command-versus-current threshold and response-time rule—and then compare two algorithms from the faculty-issued ML whitelist. Train or set the threshold using healthy/training data only. Report event recall, false alarms per normal run and detection delay; show where the method treats a new but valid regime as abnormal. Produce a event timeline with anomaly score, threshold and false-alarm examples.
5 · Embedded integration and safe response
The host may return only ENERGIZE, DEENERGIZE, RETRY_ONCE, ISOLATE or INSPECTION_REQUIRED, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with normal inrush or delayed physical response that resembles a failed or overloaded load. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 13.06 — Thermal Contact-Stress Monitor”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P13 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Thermal Contact-Stress Monitor is a syllabus-scaled physical analogue of the need evidenced by IU05 · Intelligent Power Switches: Track temperature/current drift over repeated switching. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needCombine protected load switching with diagnostics and smart load management for resistive, inductive and capacitive loads.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Use untouched held-out cases, expose false rejects as well as missed failures, and preserve specimen/run identity.
The handbook uses a small physical STM32 cell and syllabus-approved tabular models rather than Bosch-scale data or winning ensembles.
Implementation modeOrganiser-supported assignmentMay be issued only after the named seed history, reference specimens, calibration set or controlled fixture is prepared.
Required organiser provisionComplete before team allocationPre-test fused loads and current conditioning; include normal inrush as the mandatory nearest confuser.
Variant 13.07
Stuck-ON Behaviour Simulator
Engineering purpose: Represents a critical relay fault without dangerous hardware abuse.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Senseconditioned 0–3.3 V current-sense channel sized to the selected load; LDR phy…
Actuateprotected MOSFET/relay driver; 5/12 V lamp or LED bank
Fixturestuck-ON lamp-response emulator panel; guarded test switch/software fixture t…
Protectcurrent-limited 5/12 V load supply; inline fuse holder plus spare fuses; hard…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser load-signature seed dataset and fault-switching protocol
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Only touch-safe low-voltage loads are permitted; no mains wiring or exposed conductor. Verify the complete EQ-13-07 manifest before data collection.
1 · Scenario and student challenge
Emulate commanded OFF but observed response remains using safe software/fixture logic. In plain language, adapt SwitchGuard — Intelligent Low-Voltage Relay Load Diagnostics so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Represents a critical relay fault without dangerous hardware abuse.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-A + H753-S response sensing. Begin with the fused H753-A + H753-S low-voltage load bench and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record command, relay/MOSFET state, conditioned current, optional speed/light/temperature response, timing and fault flags. Treat one on/off switching cycle with its complete response window as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Commanded-OFF response classification: NORMAL_OFF versus STUCK_ON_RESPONSE. First implement the parent baseline—command-versus-current threshold and response-time rule—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only ENERGIZE, DEENERGIZE, RETRY_ONCE, ISOLATE or INSPECTION_REQUIRED, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with normal inrush or delayed physical response that resembles a failed or overloaded load. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 13.07 — Stuck-ON Behaviour Simulator”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P13 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Stuck-ON Behaviour Simulator is a syllabus-scaled physical analogue of the need evidenced by IU05 · Intelligent Power Switches: Emulate commanded OFF but observed response remains using safe software/fixture logic. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needCombine protected load switching with diagnostics and smart load management for resistive, inductive and capacitive loads.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Use untouched held-out cases, expose false rejects as well as missed failures, and preserve specimen/run identity.
The handbook uses a small physical STM32 cell and syllabus-approved tabular models rather than Bosch-scale data or winning ensembles.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationPre-test fused loads and current conditioning; include normal inrush as the mandatory nearest confuser.
Variant 13.08
Stuck-OFF Behaviour Simulator
Engineering purpose: Separates control-command from load failure.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Senseconditioned 0–3.3 V current-sense channel sized to the selected load; LDR phy…
Actuateprotected MOSFET/relay driver; 5/12 V lamp or LED bank
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser load-signature seed dataset and fault-switching protocol
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Only touch-safe low-voltage loads are permitted; no mains wiring or exposed conductor. Verify the complete EQ-13-08 manifest before data collection.
1 · Scenario and student challenge
Command ON with no current/physical response. In plain language, adapt SwitchGuard — Intelligent Low-Voltage Relay Load Diagnostics so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Separates control-command from load failure.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-A + H753-S response sensing. Begin with the fused H753-A + H753-S low-voltage load bench and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record command, relay/MOSFET state, conditioned current, optional speed/light/temperature response, timing and fault flags. Treat one on/off switching cycle with its complete response window as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Commanded-ON response classification: NORMAL_ON versus STUCK_OFF_RESPONSE. First implement the parent baseline—command-versus-current threshold and response-time rule—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only ENERGIZE, DEENERGIZE, RETRY_ONCE, ISOLATE or INSPECTION_REQUIRED, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with normal inrush or delayed physical response that resembles a failed or overloaded load. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 13.08 — Stuck-OFF Behaviour Simulator”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P13 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Stuck-OFF Behaviour Simulator is a syllabus-scaled physical analogue of the need evidenced by IU05 · Intelligent Power Switches: Command ON with no current/physical response. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needCombine protected load switching with diagnostics and smart load management for resistive, inductive and capacitive loads.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Use untouched held-out cases, expose false rejects as well as missed failures, and preserve specimen/run identity.
The handbook uses a small physical STM32 cell and syllabus-approved tabular models rather than Bosch-scale data or winning ensembles.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationPre-test fused loads and current conditioning; include normal inrush as the mandatory nearest confuser.
Variant 13.09
Duty-Cycle Compliance Guardian
Engineering purpose: Connects relay use to thermal limits.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Senseconditioned 0–3.3 V current-sense channel sized to the selected load; LDR phy…
Actuateprotected MOSFET/relay driver; 5/12 V lamp or LED bank
Fixturerepeated-switching thermal lamp/LED panel; LM35 channel and sealed maximum-du…
Protectcurrent-limited 5/12 V load supply; inline fuse holder plus spare fuses; hard…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser load-signature seed dataset and fault-switching protocol
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Only touch-safe low-voltage loads are permitted; no mains wiring or exposed conductor. Verify the complete EQ-13-09 manifest before data collection.
1 · Scenario and student challenge
Predict whether another switching cycle is thermally permissible. In plain language, adapt SwitchGuard — Intelligent Low-Voltage Relay Load Diagnostics so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Connects relay use to thermal limits.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-A + H753-S response sensing. Begin with the fused H753-A + H753-S low-voltage load bench and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record command, relay/MOSFET state, conditioned current, optional speed/light/temperature response, timing and fault flags. Treat one on/off switching cycle with its complete response window as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Safe/unsafe next-cycle classification. First implement the parent baseline—command-versus-current threshold and response-time rule—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only ENERGIZE, DEENERGIZE, RETRY_ONCE, ISOLATE or INSPECTION_REQUIRED, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with normal inrush or delayed physical response that resembles a failed or overloaded load. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 13.09 — Duty-Cycle Compliance Guardian”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P13 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Duty-Cycle Compliance Guardian is a syllabus-scaled physical analogue of the need evidenced by IU05 · Intelligent Power Switches: Predict whether another switching cycle is thermally permissible. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needCombine protected load switching with diagnostics and smart load management for resistive, inductive and capacitive loads.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Use untouched held-out cases, expose false rejects as well as missed failures, and preserve specimen/run identity.
The handbook uses a small physical STM32 cell and syllabus-approved tabular models rather than Bosch-scale data or winning ensembles.
Implementation modeOrganiser-supported assignmentMay be issued only after the named seed history, reference specimens, calibration set or controlled fixture is prepared.
Required organiser provisionComplete before team allocationPre-test fused loads and current conditioning; include normal inrush as the mandatory nearest confuser.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Senseconditioned branch-current channels; LDR lamp-response channel; fan tachomete…
Actuateindependent protected driver channels; fan and lamp/LED load
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser load-signature seed dataset and fault-switching protocol
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Only touch-safe low-voltage loads are permitted; no mains wiring or exposed conductor. Verify the complete EQ-13-10 manifest before data collection.
1 · Scenario and student challenge
Two low-voltage loads share a current budget; diagnose and isolate the anomalous one. In plain language, adapt SwitchGuard — Intelligent Low-Voltage Relay Load Diagnostics so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Introduces constrained resource management.
2 · What to build or modify
Allocated hardware: 1 × H753 + two protected H753-A output channels + H753-S sensing. Begin with the fused H753-A + H753-S low-voltage load bench and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record command, relay/MOSFET state, conditioned current, optional speed/light/temperature response, timing and fault flags. Treat one on/off switching cycle with its complete response window as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Load-state classification plus rule-based priority. First implement the parent baseline—command-versus-current threshold and response-time rule—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only ENERGIZE, DEENERGIZE, RETRY_ONCE, ISOLATE or INSPECTION_REQUIRED, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with normal inrush or delayed physical response that resembles a failed or overloaded load. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 13.10 — Dual-Load Priority Isolator”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P13 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Dual-Load Priority Isolator is a syllabus-scaled physical analogue of the need evidenced by IU05 · Intelligent Power Switches: Two low-voltage loads share a current budget; diagnose and isolate the anomalous one. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needCombine protected load switching with diagnostics and smart load management for resistive, inductive and capacitive loads.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Use untouched held-out cases, expose false rejects as well as missed failures, and preserve specimen/run identity.
The handbook uses a small physical STM32 cell and syllabus-approved tabular models rather than Bosch-scale data or winning ensembles.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationPre-test fused loads and current conditioning; include normal inrush as the mandatory nearest confuser.
Problem 14 · 10 variants · CAN, telemetry and distributed embedded intelligence
CANWatch — FDCAN Network and Node Health Anomaly Detector
Team size: 4; approved 3-member exception2 × NUCLEO-H753ZIH753-NClassification / anomalyAdvanced
Assigned Faculty Master pair for P14: one nominated ESD Faculty Master and one nominated ML Faculty Master shall jointly master this parent problem and variants V1-V10. The ESD Master owns hardware, firmware, control, communication and safety verification; the ML Master owns data, baselines, models, validation and bounded decision-policy verification. Together they teach and guide ten teams (one for each variant and up to 40 students), supervise five teams in Wave A and five in Wave B, witness integration and sign every final evaluation.
The problem
A CAN network may continue to carry frames even when a node is unhealthy: heartbeats become irregular, telemetry freezes, message rates change, payload relationships become implausible or a node repeatedly resets. Standard CAN error handling does not by itself diagnose application-level behaviour. The challenge is to build an observable two-node network and detect these subtle anomalies from frame metadata and payload context.
Smart embedded product to build
Build a physical two-node FDCAN observability bench using two NUCLEO-H753ZI boards and two external transceivers. The nodes exchange fixed-priority heartbeat, sensor telemetry, command and acknowledgement frames and log sequence, inter-arrival, reset, error/recovery and payload-change evidence. Safe software injectors create delay, drop, stale payload, wrong approved ID, reset and burst cases. The host diagnoses node/network health and may request only NORMAL_NETWORK, DIAGNOSTIC_MODE, REDUCE_NONCRITICAL_TRAFFIC or SAFE_NODE_STATE.
NUCLEO-H753ZI realization and issued pack
two NUCLEO-H753ZI / MB1364E boards with the complete H753-N pack
one physical CAN/CAN-FD transceiver with 3.3-V-compatible logic I/O and its manufacturer-specified bus-side supply per node, twisted pair and exactly two end terminations
fixed heartbeat, telemetry, command and acknowledgement IDs with counters and age fields
safe software fault injector for delay, drop, stale payload, reset and rate change
one board’s USART3 VCP or approved PC gateway logs the combined trace
board LEDs show node state; optional local Ethernet trace mirror is stretch-only
Intelligence to incorporate
Features include inter-arrival mean/jitter, missing sequence count, stale duration, frame-rate ratios, ID distribution, command-response latency and payload change rate. Use classification or healthy-data anomaly detection. Evaluate anomaly recall, false alarms under legitimate rate changes and time-to-detection.
Canonical family command contract: every parent brief, variant, host message and MCU acknowledgement for P14 shall use these exact identifiers. A variant may use only the applicable subset; it shall not introduce a synonym.
Core problem equipment · EQ-14-CORE
Complete equipment required for one core-problem team
Standalone family BOM. This list supports the parent problem itself. An allocated variant uses its own complete table later in this card. A component mentioned again in the fixture description is the same mounted unit, not another copy.
4 students; 3 by approved exception2 H753 boards1 team laptopquantities per team
Controller2 H753 boards + 1 laptop
Sense10 kΩ potentiometers—one payload/context source on each node; board LED state…
ActuateNo powered actuator is required for the core network-health problem; use only…
Fixturetwo-node desktop network board with labelled NODE_A/NODE_B positions and prot…
ProtectUSB board power paths through the laptop/powered hub; protected transceiver s…
System block
Complete quantity and equipment per team
Purpose / acceptance condition
Controller & host
2 × NUCLEO-H753ZI / MB1364E boards with onboard STLINK-V3E
2 × data-capable USB-A/USB-C-to-Micro-B cables
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
1 × powered USB data hub with at least three downstream ports
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
2 × full-size solderless breadboards, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser-known-good FDCAN bit-timing/configuration file and golden trace
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Release-to-team condition: Software loopback is insufficient; the final demonstration must use both physical transceivers and correct termination. The organiser signs the electrical, mechanical and communication acceptance checklist before H0:00.
Not duplicated inside the kit: supervised rework tools and the oscilloscope/logic-analyser station are shared at the ratio stated above. Everything else in this table is issued to, reserved for, or digitally assigned to this team.
Controlled self-learning extension
Recommended Build a trace-replay harness that feeds captured FDCAN application frames into the feature pipeline at original or accelerated time. Validate that live and replayed traces yield the same diagnosis.
System safety and non-negotiable boundary
MCU-side CAN error handling, watchdog and actuator safety remain independent. The model cannot change safety-critical frame priority or disable heartbeat. Fault injection is performed by software-controlled delays, drops, resets or stale payloads—not electrical abuse of the bus.
Student interpretation — what this challenge really asks
Valid FDCAN frames can still carry stale, delayed, repeated or implausible application data. Students build two real nodes and diagnose node/network health from message timing, sequence and payload evidence.
Independent data unitone labelled network trace window or one injected communication event.
Closest misleading casea legitimate rate/profile change that resembles delay, loss or starvation.
Definition of successStudents must diagnose a hidden application-level anomaly from a live physical trace without electrically abusing the bus.
Visual system blueprint
Physical processTwo-node FDCAN application networkGenerate labelled, safe and repeatable conditions.
ObserveCAN ID, sequence, timestampPreserve units, timestamps, run identity and signal quality.
H753 responsibilityControl and protectexchange versioned heartbeat, telemetry, command and acknowledgement frames through external transceivers and fail safely on loss.
Host intelligenceLearn the distinctiondetect or classify application-level network and node anomalies.
Bounded outcomeNORMAL_NETWORK · DIAGNOSTIC_MODE · REDUCE_NONCRITICAL_TRAFFIC · SAFE_NODE_STATEMCU validates, acknowledges and may refuse the request.
Recommended build journey
Make the process repeatableAssemble two H753 boards with the complete H753-N transceiver and termination set; define reference and target conditions before collecting data.
Prove deterministic firmwareExchange versioned heartbeat, telemetry, command and acknowledgement frames through external transceivers and fail safely on loss. Demonstrate every hard limit before connecting ML.
Build trustworthy trialsTreat one labelled network trace window or one injected communication event as independent; calibrate, label and split by run/session.
Beat a real baselineCompare heartbeat timeout, missing-sequence and payload-staleness rules with two syllabus-approved classical models.
Close and challenge the loopReturn only the applicable subset of NORMAL_NETWORK · DIAGNOSTIC_MODE · REDUCE_NONCRITICAL_TRAFFIC · SAFE_NODE_STATE; test the target, nearest confuser, stale command and host loss.
Definition of done
Firmware controls safely before, during and after host connection.
Held-out results report event recall, false alarm under legal traffic changes and time-to-detection.
Portfolio shows FDCAN event timeline showing IDs, gaps, predictions and acknowledgements and one honest failure case.
Problem-specific evidence at the common reviews
R1 · Design
Freeze node roles, CAN IDs/priorities, heartbeat contract, software fault matrix and safe diagnostic actions.
Submit normal and injected traces, trace parser, rule baseline and event-level split.
R4 · ML
Show anomaly/health model, detection latency and false alarms under legitimate traffic changes.
R5 · Integration
Integrate diagnostic mode and pass missing heartbeat, stale payload, reset and burst tests.
Final
Diagnose a hidden CAN/node anomaly from a live trace and identify supporting evidence.
Portfolio/Kaggle outcome
Kaggle asset: timestamped CAN application trace with documented IDs and injected fault labels, notebook for inter-arrival/sequence features, rule baseline, anomaly/classification results and event timeline visualisation.
Industry alignment and validation basis
CANWatch: external references and required evidence
The listed sources establish relevance, test discipline and implementation precedent. They do not modify the common syllabus boundary, safety rules or 100-mark assessment rubric.
Family implementation profile
Variant availability: 10 standard assignment(s); 0 organiser-supported assignment(s).
Public evidence: reproducible firmware, protocol, dataset, notebook/model, test report and demonstration video.
What the external benchmark confirms
The problem has a recognisable industrial or challenge analogue, a measurable data task, a defensible embedded implementation and a safe operational decision. Every one of its ten variants is mapped separately below.
Condition before team allocation
Allocate complete two-transceiver/termination kits and a safe event-injection script; no connection to a real vehicle is allowed.
Support commands, telemetry, events, dictionaries, decoding and histories for an embedded mission system.
Version message dictionaries, log command and acknowledgement histories and make telemetry replayable for diagnosis.
Open the 10 fully elaborated student variant briefs
Choose only the variant allocated to your team. Read it together with the parent problem above: the card expands the experimental delta, while every hardware, safety, integration and review requirement of the family remains active.
Variant 14.01
Heartbeat-Loss Detector
Engineering purpose: Fundamental distributed-system health case.
Proveevent recall, false alarm under legal traffic changes and…
Variant equipment · EQ-14-01
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception2 H753 boards1 laptop
Controller2 H753 boards + 1 laptop
Sense10 kΩ potentiometers—one payload/context source on each node; board LED state…
ActuateNo powered actuator is required for the core network-health problem; use only…
Fixturestandard two-node FDCAN fixture; heartbeat-loss is injected in firmware with…
ProtectUSB board power paths through the laptop/powered hub; protected transceiver s…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
2 × NUCLEO-H753ZI / MB1364E boards with onboard STLINK-V3E
2 × data-capable USB-A/USB-C-to-Micro-B cables
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
1 × powered USB data hub with at least three downstream ports
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
2 × full-size solderless breadboards, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser-known-good FDCAN bit-timing/configuration file and golden trace
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Software loopback is insufficient; the final demonstration must use both physical transceivers and correct termination. Verify the complete EQ-14-01 manifest before data collection.
1 · Scenario and student challenge
Detect missing or excessively late heartbeat while other traffic remains. In plain language, adapt CANWatch — FDCAN Network and Node Health Anomaly Detector so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Fundamental distributed-system health case.
2 · What to build or modify
Allocated hardware: 2 × H753 + H753-N physical FDCAN set + the named safe mechanical/condition fixture. Begin with two H753 boards with the complete H753-N transceiver and termination set and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record CAN ID, sequence, timestamp, inter-arrival time, payload change, command/ack latency, reset/error state and heartbeat age. Treat one labelled network trace window or one injected communication event as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Binary/event classification. First implement the parent baseline—heartbeat timeout, missing-sequence and payload-staleness rules—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only NORMAL_NETWORK, DIAGNOSTIC_MODE, REDUCE_NONCRITICAL_TRAFFIC or SAFE_NODE_STATE, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a legitimate rate/profile change that resembles delay, loss or starvation. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 14.01 — Heartbeat-Loss Detector”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
2 × H753 + H753-N physical FDCAN set + the named safe mechanical/condition fixtureclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P14 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Heartbeat-Loss Detector is a syllabus-scaled physical analogue of the need evidenced by GC06 · In-Vehicle Network Intrusion Detection and Car Hacking Challenges: Detect missing or excessively late heartbeat while other traffic remains. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needPublish CAN/CAN-FD datasets and challenge resources for abnormal in-vehicle network traffic and attack detection.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Retain timestamps and event intervals, test detection latency and false alarms, and prevent trace-window leakage across splits.
Only its trace methodology is transferred; the student rig uses benign fault injection on an isolated two-node bus.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationAllocate complete two-transceiver/termination kits and a safe event-injection script; no connection to a real vehicle is allowed.
Variant 14.02
Stale-Telemetry Detector
Engineering purpose: Detects an application fault that frame counters miss.
Proveevent recall, false alarm under legal traffic changes and…
Variant equipment · EQ-14-02
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception2 H753 boards1 laptop
Controller2 H753 boards + 1 laptop
Sense10 kΩ potentiometers—one payload/context source on each node; board LED state…
ActuateNo powered actuator is required for the core network-health problem; use only…
Fixturetwo-node fixture with changing potentiometer/LDR payload source on the transm…
ProtectUSB board power paths through the laptop/powered hub; protected transceiver s…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
2 × NUCLEO-H753ZI / MB1364E boards with onboard STLINK-V3E
2 × data-capable USB-A/USB-C-to-Micro-B cables
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
1 × powered USB data hub with at least three downstream ports
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
2 × full-size solderless breadboards, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser-known-good FDCAN bit-timing/configuration file and golden trace
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Software loopback is insufficient; the final demonstration must use both physical transceivers and correct termination. Verify the complete EQ-14-02 manifest before data collection.
1 · Scenario and student challenge
Frames arrive on time but payload stops changing despite changing physical input. In plain language, adapt CANWatch — FDCAN Network and Node Health Anomaly Detector so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Detects an application fault that frame counters miss.
2 · What to build or modify
Allocated hardware: 2 × H753 + H753-N physical FDCAN set + the named safe mechanical/condition fixture. Begin with two H753 boards with the complete H753-N transceiver and termination set and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record CAN ID, sequence, timestamp, inter-arrival time, payload change, command/ack latency, reset/error state and heartbeat age. Treat one labelled network trace window or one injected communication event as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Stale-state classification. First implement the parent baseline—heartbeat timeout, missing-sequence and payload-staleness rules—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only NORMAL_NETWORK, DIAGNOSTIC_MODE, REDUCE_NONCRITICAL_TRAFFIC or SAFE_NODE_STATE, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a legitimate rate/profile change that resembles delay, loss or starvation. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 14.02 — Stale-Telemetry Detector”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
2 × H753 + H753-N physical FDCAN set + the named safe mechanical/condition fixtureclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P14 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Stale-Telemetry Detector is a syllabus-scaled physical analogue of the need evidenced by GC06 · In-Vehicle Network Intrusion Detection and Car Hacking Challenges: Frames arrive on time but payload stops changing despite changing physical input. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needPublish CAN/CAN-FD datasets and challenge resources for abnormal in-vehicle network traffic and attack detection.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Retain timestamps and event intervals, test detection latency and false alarms, and prevent trace-window leakage across splits.
Only its trace methodology is transferred; the student rig uses benign fault injection on an isolated two-node bus.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationAllocate complete two-transceiver/termination kits and a safe event-injection script; no connection to a real vehicle is allowed.
Proveevent recall, false alarm under legal traffic changes and…
Variant equipment · EQ-14-03
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception2 H753 boards1 laptop
Controller2 H753 boards + 1 laptop
Sense10 kΩ potentiometers—one payload/context source on each node; board LED state…
ActuateNo powered actuator is required for the core network-health problem; use only…
Fixturestandard two-node fixture using the onboard RESET buttons and logged boot cou…
ProtectUSB board power paths through the laptop/powered hub; protected transceiver s…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
2 × NUCLEO-H753ZI / MB1364E boards with onboard STLINK-V3E
2 × data-capable USB-A/USB-C-to-Micro-B cables
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
1 × powered USB data hub with at least three downstream ports
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
2 × full-size solderless breadboards, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser-known-good FDCAN bit-timing/configuration file and golden trace
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Software loopback is insufficient; the final demonstration must use both physical transceivers and correct termination. Verify the complete EQ-14-03 manifest before data collection.
1 · Scenario and student challenge
Identify reset/rejoin patterns from sequence/timing/state. In plain language, adapt CANWatch — FDCAN Network and Node Health Anomaly Detector so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Supports field diagnostics.
2 · What to build or modify
Allocated hardware: 2 × H753 + H753-N physical FDCAN set + the named safe mechanical/condition fixture. Begin with two H753 boards with the complete H753-N transceiver and termination set and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record CAN ID, sequence, timestamp, inter-arrival time, payload change, command/ack latency, reset/error state and heartbeat age. Treat one labelled network trace window or one injected communication event as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Multiclass event classifier. First implement the parent baseline—heartbeat timeout, missing-sequence and payload-staleness rules—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only NORMAL_NETWORK, DIAGNOSTIC_MODE, REDUCE_NONCRITICAL_TRAFFIC or SAFE_NODE_STATE, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a legitimate rate/profile change that resembles delay, loss or starvation. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 14.03 — Node-Reset Fingerprinter”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
2 × H753 + H753-N physical FDCAN set + the named safe mechanical/condition fixtureclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P14 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Node-Reset Fingerprinter is a syllabus-scaled physical analogue of the need evidenced by GC06 · In-Vehicle Network Intrusion Detection and Car Hacking Challenges: Identify reset/rejoin patterns from sequence/timing/state. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needPublish CAN/CAN-FD datasets and challenge resources for abnormal in-vehicle network traffic and attack detection.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Retain timestamps and event intervals, test detection latency and false alarms, and prevent trace-window leakage across splits.
Only its trace methodology is transferred; the student rig uses benign fault injection on an isolated two-node bus.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationAllocate complete two-transceiver/termination kits and a safe event-injection script; no connection to a real vehicle is allowed.
Variant 14.04
Frame-Rate Anomaly Detector
Engineering purpose: Relates directly to timer configuration.
Proveevent recall, false alarm under legal traffic changes and…
Variant equipment · EQ-14-04
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception2 H753 boards1 laptop
Controller2 H753 boards + 1 laptop
Sense10 kΩ potentiometers—one payload/context source on each node; board LED state…
ActuateNo powered actuator is required for the core network-health problem; use only…
Fixturestandard two-node fixture with sealed NORMAL/SLOW/FAST rate profiles
ProtectUSB board power paths through the laptop/powered hub; protected transceiver s…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
2 × NUCLEO-H753ZI / MB1364E boards with onboard STLINK-V3E
2 × data-capable USB-A/USB-C-to-Micro-B cables
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
1 × powered USB data hub with at least three downstream ports
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
2 × full-size solderless breadboards, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser-known-good FDCAN bit-timing/configuration file and golden trace
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Software loopback is insufficient; the final demonstration must use both physical transceivers and correct termination. Verify the complete EQ-14-04 manifest before data collection.
1 · Scenario and student challenge
Detect unintended too-fast or too-slow periodic transmission. In plain language, adapt CANWatch — FDCAN Network and Node Health Anomaly Detector so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Relates directly to timer configuration.
2 · What to build or modify
Allocated hardware: 2 × H753 + H753-N physical FDCAN set + the named safe mechanical/condition fixture. Begin with two H753 boards with the complete H753-N transceiver and termination set and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record CAN ID, sequence, timestamp, inter-arrival time, payload change, command/ack latency, reset/error state and heartbeat age. Treat one labelled network trace window or one injected communication event as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Anomaly/classification on inter-arrival features. First implement the parent baseline—heartbeat timeout, missing-sequence and payload-staleness rules—and then compare two algorithms from the faculty-issued ML whitelist. Train or set the threshold using healthy/training data only. Report event recall, false alarms per normal run and detection delay; show where the method treats a new but valid regime as abnormal. Produce a event timeline with anomaly score, threshold and false-alarm examples.
5 · Embedded integration and safe response
The host may return only NORMAL_NETWORK, DIAGNOSTIC_MODE, REDUCE_NONCRITICAL_TRAFFIC or SAFE_NODE_STATE, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a legitimate rate/profile change that resembles delay, loss or starvation. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 14.04 — Frame-Rate Anomaly Detector”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
2 × H753 + H753-N physical FDCAN set + the named safe mechanical/condition fixtureanomaly/noveltyrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P14 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Frame-Rate Anomaly Detector is a syllabus-scaled physical analogue of the need evidenced by GC06 · In-Vehicle Network Intrusion Detection and Car Hacking Challenges: Detect unintended too-fast or too-slow periodic transmission. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needPublish CAN/CAN-FD datasets and challenge resources for abnormal in-vehicle network traffic and attack detection.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Retain timestamps and event intervals, test detection latency and false alarms, and prevent trace-window leakage across splits.
Only its trace methodology is transferred; the student rig uses benign fault injection on an isolated two-node bus.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationAllocate complete two-transceiver/termination kits and a safe event-injection script; no connection to a real vehicle is allowed.
Variant 14.05
Duplicate/Replay Detector
Engineering purpose: Improves protocol integrity without cryptography.
Proveevent recall, false alarm under legal traffic changes and…
Variant equipment · EQ-14-05
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception2 H753 boards1 laptop
Controller2 H753 boards + 1 laptop
Sense10 kΩ potentiometers—one payload/context source on each node; board LED state…
ActuateNo powered actuator is required for the core network-health problem; use only…
Fixturestandard two-node fixture with firmware replay switch and sequence counter
ProtectUSB board power paths through the laptop/powered hub; protected transceiver s…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
2 × NUCLEO-H753ZI / MB1364E boards with onboard STLINK-V3E
2 × data-capable USB-A/USB-C-to-Micro-B cables
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
1 × powered USB data hub with at least three downstream ports
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
2 × full-size solderless breadboards, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser-known-good FDCAN bit-timing/configuration file and golden trace
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Software loopback is insufficient; the final demonstration must use both physical transceivers and correct termination. Verify the complete EQ-14-05 manifest before data collection.
1 · Scenario and student challenge
Inject repeated sequence/payload events. In plain language, adapt CANWatch — FDCAN Network and Node Health Anomaly Detector so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Improves protocol integrity without cryptography.
2 · What to build or modify
Allocated hardware: 2 × H753 + H753-N physical FDCAN set + the named safe mechanical/condition fixture. Begin with two H753 boards with the complete H753-N transceiver and termination set and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record CAN ID, sequence, timestamp, inter-arrival time, payload change, command/ack latency, reset/error state and heartbeat age. Treat one labelled network trace window or one injected communication event as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Replay/duplicate classification. First implement the parent baseline—heartbeat timeout, missing-sequence and payload-staleness rules—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only NORMAL_NETWORK, DIAGNOSTIC_MODE, REDUCE_NONCRITICAL_TRAFFIC or SAFE_NODE_STATE, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a legitimate rate/profile change that resembles delay, loss or starvation. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 14.05 — Duplicate/Replay Detector”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
2 × H753 + H753-N physical FDCAN set + the named safe mechanical/condition fixtureclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P14 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Duplicate/Replay Detector is a syllabus-scaled physical analogue of the need evidenced by GC06 · In-Vehicle Network Intrusion Detection and Car Hacking Challenges: Inject repeated sequence/payload events. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needPublish CAN/CAN-FD datasets and challenge resources for abnormal in-vehicle network traffic and attack detection.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Retain timestamps and event intervals, test detection latency and false alarms, and prevent trace-window leakage across splits.
Only its trace methodology is transferred; the student rig uses benign fault injection on an isolated two-node bus.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationAllocate complete two-transceiver/termination kits and a safe event-injection script; no connection to a real vehicle is allowed.
Proveevent recall, false alarm under legal traffic changes and…
Variant equipment · EQ-14-06
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception2 H753 boards1 laptop
Controller2 H753 boards + 1 laptop
Sense10 kΩ potentiometers—one payload/context source on each node; board LED state…
ActuateNo powered actuator is required for the core network-health problem; use only…
Fixturestandard two-node fixture with a sealed allowed-ID map and one wrong-ID test…
ProtectUSB board power paths through the laptop/powered hub; protected transceiver s…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
2 × NUCLEO-H753ZI / MB1364E boards with onboard STLINK-V3E
2 × data-capable USB-A/USB-C-to-Micro-B cables
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
1 × powered USB data hub with at least three downstream ports
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
2 × full-size solderless breadboards, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser-known-good FDCAN bit-timing/configuration file and golden trace
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Software loopback is insufficient; the final demonstration must use both physical transceivers and correct termination. Verify the complete EQ-14-06 manifest before data collection.
1 · Scenario and student challenge
Transmit an application message under an incorrect approved test ID. In plain language, adapt CANWatch — FDCAN Network and Node Health Anomaly Detector so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Targets commissioning/configuration faults.
2 · What to build or modify
Allocated hardware: 2 × H753 + H753-N physical FDCAN set + the named safe mechanical/condition fixture. Begin with two H753 boards with the complete H753-N transceiver and termination set and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record CAN ID, sequence, timestamp, inter-arrival time, payload change, command/ack latency, reset/error state and heartbeat age. Treat one labelled network trace window or one injected communication event as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Protocol-conformance classification. First implement the parent baseline—heartbeat timeout, missing-sequence and payload-staleness rules—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only NORMAL_NETWORK, DIAGNOSTIC_MODE, REDUCE_NONCRITICAL_TRAFFIC or SAFE_NODE_STATE, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a legitimate rate/profile change that resembles delay, loss or starvation. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 14.06 — Wrong-Identifier Detector”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
2 × H753 + H753-N physical FDCAN set + the named safe mechanical/condition fixtureclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P14 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Wrong-Identifier Detector is a syllabus-scaled physical analogue of the need evidenced by GC06 · In-Vehicle Network Intrusion Detection and Car Hacking Challenges: Transmit an application message under an incorrect approved test ID. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needPublish CAN/CAN-FD datasets and challenge resources for abnormal in-vehicle network traffic and attack detection.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Retain timestamps and event intervals, test detection latency and false alarms, and prevent trace-window leakage across splits.
Only its trace methodology is transferred; the student rig uses benign fault injection on an isolated two-node bus.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationAllocate complete two-transceiver/termination kits and a safe event-injection script; no connection to a real vehicle is allowed.
Variant 14.07
Priority-Starvation Monitor
Engineering purpose: Uses identifier-based arbitration from the syllabus.
Proveevent recall, false alarm under legal traffic changes and…
Variant equipment · EQ-14-07
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception2 H753 boards1 laptop
Controller2 H753 boards + 1 laptop
Sense10 kΩ potentiometers—one payload/context source on each node; board LED state…
ActuateNo powered actuator is required for the core network-health problem; use only…
Fixturestandard two-node fixture with approved high-priority burst generator in firm…
ProtectUSB board power paths through the laptop/powered hub; protected transceiver s…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
2 × NUCLEO-H753ZI / MB1364E boards with onboard STLINK-V3E
2 × data-capable USB-A/USB-C-to-Micro-B cables
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
1 × powered USB data hub with at least three downstream ports
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
2 × full-size solderless breadboards, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser-known-good FDCAN bit-timing/configuration file and golden trace
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Software loopback is insufficient; the final demonstration must use both physical transceivers and correct termination. Verify the complete EQ-14-07 manifest before data collection.
1 · Scenario and student challenge
Create safe high-priority bursts and measure low-priority delay. In plain language, adapt CANWatch — FDCAN Network and Node Health Anomaly Detector so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Uses identifier-based arbitration from the syllabus.
2 · What to build or modify
Allocated hardware: 2 × H753 + H753-N physical FDCAN set + the named safe mechanical/condition fixture. Begin with two H753 boards with the complete H753-N transceiver and termination set and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record CAN ID, sequence, timestamp, inter-arrival time, payload change, command/ack latency, reset/error state and heartbeat age. Treat one labelled network trace window or one injected communication event as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Latency-risk classification. First implement the parent baseline—heartbeat timeout, missing-sequence and payload-staleness rules—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only NORMAL_NETWORK, DIAGNOSTIC_MODE, REDUCE_NONCRITICAL_TRAFFIC or SAFE_NODE_STATE, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a legitimate rate/profile change that resembles delay, loss or starvation. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 14.07 — Priority-Starvation Monitor”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
2 × H753 + H753-N physical FDCAN set + the named safe mechanical/condition fixtureclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P14 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Priority-Starvation Monitor is a syllabus-scaled physical analogue of the need evidenced by GC06 · In-Vehicle Network Intrusion Detection and Car Hacking Challenges: Create safe high-priority bursts and measure low-priority delay. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needPublish CAN/CAN-FD datasets and challenge resources for abnormal in-vehicle network traffic and attack detection.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Retain timestamps and event intervals, test detection latency and false alarms, and prevent trace-window leakage across splits.
Only its trace methodology is transferred; the student rig uses benign fault injection on an isolated two-node bus.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationAllocate complete two-transceiver/termination kits and a safe event-injection script; no connection to a real vehicle is allowed.
Variant 14.08
Command-Response Timeout Diagnoser
Engineering purpose: Moves from network monitoring to service assurance.
Proveevent recall, false alarm under legal traffic changes and…
Variant equipment · EQ-14-08
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception2 H753 boards1 laptop
Controller2 H753 boards + 1 laptop
Sense10 kΩ potentiometers—one payload/context source on each node; board LED state…
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser-known-good FDCAN bit-timing/configuration file and golden trace
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Software loopback is insufficient; the final demonstration must use both physical transceivers and correct termination. Verify the complete EQ-14-08 manifest before data collection.
1 · Scenario and student challenge
Link each command to expected acknowledgement/physical response. In plain language, adapt CANWatch — FDCAN Network and Node Health Anomaly Detector so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Moves from network monitoring to service assurance.
2 · What to build or modify
Allocated hardware: 2 × H753 + H753-N physical FDCAN set + the named safe mechanical/condition fixture. Begin with two H753 boards with the complete H753-N transceiver and termination set and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record CAN ID, sequence, timestamp, inter-arrival time, payload change, command/ack latency, reset/error state and heartbeat age. Treat one labelled network trace window or one injected communication event as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Cause classification from delay patterns. First implement the parent baseline—heartbeat timeout, missing-sequence and payload-staleness rules—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only NORMAL_NETWORK, DIAGNOSTIC_MODE, REDUCE_NONCRITICAL_TRAFFIC or SAFE_NODE_STATE, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a legitimate rate/profile change that resembles delay, loss or starvation. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 14.08 — Command-Response Timeout Diagnoser”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
2 × H753 + H753-N physical FDCAN set + the named safe mechanical/condition fixtureclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P14 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Command-Response Timeout Diagnoser is a syllabus-scaled physical analogue of the need evidenced by GC06 · In-Vehicle Network Intrusion Detection and Car Hacking Challenges: Link each command to expected acknowledgement/physical response. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needPublish CAN/CAN-FD datasets and challenge resources for abnormal in-vehicle network traffic and attack detection.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Retain timestamps and event intervals, test detection latency and false alarms, and prevent trace-window leakage across splits.
Only its trace methodology is transferred; the student rig uses benign fault injection on an isolated two-node bus.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationAllocate complete two-transceiver/termination kits and a safe event-injection script; no connection to a real vehicle is allowed.
Proveevent recall, false alarm under legal traffic changes and…
Variant equipment · EQ-14-09
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception2 H753 boards1 laptop
Controller2 H753 boards + 1 laptop
SenseLM35-class temperature channel; 10 kΩ actuator-state proxy potentiometer; boa…
ActuateNo powered actuator is required for the core network-health problem; use only…
Fixturetwo-node plausibility fixture; LM35 channel and potentiometer/actuator-state…
ProtectUSB board power paths through the laptop/powered hub; protected transceiver s…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
2 × NUCLEO-H753ZI / MB1364E boards with onboard STLINK-V3E
2 × data-capable USB-A/USB-C-to-Micro-B cables
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
1 × powered USB data hub with at least three downstream ports
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
2 × full-size solderless breadboards, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser-known-good FDCAN bit-timing/configuration file and golden trace
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Software loopback is insufficient; the final demonstration must use both physical transceivers and correct termination. Verify the complete EQ-14-09 manifest before data collection.
1 · Scenario and student challenge
Detect combinations impossible for the physical process despite valid frames. In plain language, adapt CANWatch — FDCAN Network and Node Health Anomaly Detector so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Adds process-aware intelligence.
2 · What to build or modify
Allocated hardware: 2 × H753 + H753-N physical FDCAN set + the named safe mechanical/condition fixture. Begin with two H753 boards with the complete H753-N transceiver and termination set and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record CAN ID, sequence, timestamp, inter-arrival time, payload change, command/ack latency, reset/error state and heartbeat age. Treat one labelled network trace window or one injected communication event as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Anomaly detection on payload relationships. First implement the parent baseline—heartbeat timeout, missing-sequence and payload-staleness rules—and then compare two algorithms from the faculty-issued ML whitelist. Train or set the threshold using healthy/training data only. Report event recall, false alarms per normal run and detection delay; show where the method treats a new but valid regime as abnormal. Produce a event timeline with anomaly score, threshold and false-alarm examples.
5 · Embedded integration and safe response
The host may return only NORMAL_NETWORK, DIAGNOSTIC_MODE, REDUCE_NONCRITICAL_TRAFFIC or SAFE_NODE_STATE, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a legitimate rate/profile change that resembles delay, loss or starvation. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 14.09 — Payload-Plausibility Monitor”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
2 × H753 + H753-N physical FDCAN set + the named safe mechanical/condition fixtureanomaly/noveltyrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P14 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Payload-Plausibility Monitor is a syllabus-scaled physical analogue of the need evidenced by GC06 · In-Vehicle Network Intrusion Detection and Car Hacking Challenges: Detect combinations impossible for the physical process despite valid frames. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needPublish CAN/CAN-FD datasets and challenge resources for abnormal in-vehicle network traffic and attack detection.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Retain timestamps and event intervals, test detection latency and false alarms, and prevent trace-window leakage across splits.
Only its trace methodology is transferred; the student rig uses benign fault injection on an isolated two-node bus.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationAllocate complete two-transceiver/termination kits and a safe event-injection script; no connection to a real vehicle is allowed.
Proveevent recall, false alarm under legal traffic changes and…
Variant equipment · EQ-14-10
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception2 H753 boards1 laptop
Controller2 H753 boards + 1 laptop
Sense10 kΩ potentiometers—one payload/context source on each node; board LED state…
ActuateNo powered actuator is required for the core network-health problem; use only…
Fixturestandard two-node fixture with a firmware-controlled bounded timer-drift prof…
ProtectUSB board power paths through the laptop/powered hub; protected transceiver s…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
2 × NUCLEO-H753ZI / MB1364E boards with onboard STLINK-V3E
2 × data-capable USB-A/USB-C-to-Micro-B cables
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
1 × powered USB data hub with at least three downstream ports
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
2 × full-size solderless breadboards, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser-known-good FDCAN bit-timing/configuration file and golden trace
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Software loopback is insufficient; the final demonstration must use both physical transceivers and correct termination. Verify the complete EQ-14-10 manifest before data collection.
1 · Scenario and student challenge
Gradually change a node’s timer period in software. In plain language, adapt CANWatch — FDCAN Network and Node Health Anomaly Detector so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Shows long-term timing-health monitoring.
2 · What to build or modify
Allocated hardware: 2 × H753 + H753-N physical FDCAN set + the named safe mechanical/condition fixture. Begin with two H753 boards with the complete H753-N transceiver and termination set and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record CAN ID, sequence, timestamp, inter-arrival time, payload change, command/ack latency, reset/error state and heartbeat age. Treat one labelled network trace window or one injected communication event as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Drift detection/classification. First implement the parent baseline—heartbeat timeout, missing-sequence and payload-staleness rules—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only NORMAL_NETWORK, DIAGNOSTIC_MODE, REDUCE_NONCRITICAL_TRAFFIC or SAFE_NODE_STATE, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a legitimate rate/profile change that resembles delay, loss or starvation. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 14.10 — Clock/Period Drift Monitor”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
2 × H753 + H753-N physical FDCAN set + the named safe mechanical/condition fixtureclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P14 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Clock/Period Drift Monitor is a syllabus-scaled physical analogue of the need evidenced by GC06 · In-Vehicle Network Intrusion Detection and Car Hacking Challenges: Gradually change a node’s timer period in software. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needPublish CAN/CAN-FD datasets and challenge resources for abnormal in-vehicle network traffic and attack detection.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Retain timestamps and event intervals, test detection latency and false alarms, and prevent trace-window leakage across splits.
Only its trace methodology is transferred; the student rig uses benign fault injection on an isolated two-node bus.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationAllocate complete two-transceiver/termination kits and a safe event-injection script; no connection to a real vehicle is allowed.
Problem 15 · 10 variants · CAN, telemetry and distributed embedded intelligence
TwinNode Cell — Distributed Sensing and Actuation Supervisor
Assigned Faculty Master pair for P15: one nominated ESD Faculty Master and one nominated ML Faculty Master shall jointly master this parent problem and variants V1-V10. The ESD Master owns hardware, firmware, control, communication and safety verification; the ML Master owns data, baselines, models, validation and bounded decision-policy verification. Together they teach and guide ten teams (one for each variant and up to 40 students), supervise five teams in Wave A and five in Wave B, witness integration and sign every final evaluation.
The problem
Real industrial embedded products separate sensing and actuation across networked nodes. The challenge is not merely to send a CAN frame; it is to maintain a coherent state when measurements, commands and acknowledgements travel across two controllers, and to use ML at the supervisory layer without compromising local safety.
Smart embedded product to build
Build a physical two-node smart cell with two NUCLEO-H753ZI boards. Node S timestamps/calibrates process signals and sends FDCAN telemetry with age/quality flags. Node A runs local actuation/control, enforces all limits and acknowledges requested versus applied mode. The host reconstructs a synchronized trial, predicts a process state/outcome and returns one bounded mode/setpoint ID. The cell must make safe, observable transitions when Node S, Node A’s network path or the host is removed.
NUCLEO-H753ZI realization and issued pack
two NUCLEO-H753ZI / MB1364E boards with H753-N plus S, A or M modules named by the variant
Node S: timer/ADC sensing, local plausibility checks and periodic FDCAN telemetry
Node A: PWM/relay/motor control, local interlocks and command acknowledgement
physical transceiver on each node, twisted pair and correct termination
fixed heartbeat plus versioned/sequence-numbered bounded mode/setpoint frames
USART3 VCP on one node or gateway exports a synchronized host dataset
each actuator remains safe if Node S, Node A’s bus, or the host disappears
Intelligence to incorporate
Depending on variant, use regression, classification or clustering over synchronised node data. Required features include measurement age, command state, response delay and physical signals. Compare against a local threshold/rule baseline. Evaluate predictive performance and distributed-system metrics such as stale-command rejection and response latency.
Permitted output/action set
MODE_ID · REQUEST_RECHECK · LOCAL_SAFE
Canonical family command contract: every parent brief, variant, host message and MCU acknowledgement for P15 shall use these exact identifiers. A variant may use only the applicable subset; it shall not introduce a synonym.
Core problem equipment · EQ-15-CORE
Complete equipment required for one core-problem team
Standalone family BOM. This list supports the parent problem itself. An allocated variant uses its own complete table later in this card. A component mentioned again in the fixture description is the same mounted unit, not another copy.
4 students; 3 by approved exception2 H753 boards1 team laptopquantities per team
Controller2 H753 boards + 1 laptop
SenseLM35-class temperature channels or the exact S/M sensing channels named by th…
Actuate5/12 V fan through protected MOSFET/relay driver for the core distributed the…
Fixturesmall thermal/airflow cell separating the sensor-node and actuator-node respo…
Protectcurrent-limited actuator supply with fuse; hardware actuator-isolation switch…
System block
Complete quantity and equipment per team
Purpose / acceptance condition
Controller & host
2 × NUCLEO-H753ZI / MB1364E boards with onboard STLINK-V3E
2 × data-capable USB-A/USB-C-to-Micro-B cables
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
1 × powered USB data hub with at least three downstream ports
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
2 × full-size solderless breadboards, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser message-sequence/failure matrix for sensor-node, actuator-node, bus and host loss
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Release-to-team condition: The actuator node must remain safe after loss of the sensor node, physical bus or host. The organiser signs the electrical, mechanical and communication acceptance checklist before H0:00.
Not duplicated inside the kit: supervised rework tools and the oscilloscope/logic-analyser station are shared at the ratio stated above. Everything else in this table is issued to, reserved for, or digitally assigned to this team.
Controlled self-learning extension
Recommended Estimate and correct the two nodes’ timestamp offset using a bounded request/response exchange. Report residual synchronization error; do not introduce PTP, RTOS scheduling or a new network stack.
System safety and non-negotiable boundary
Each actuator limit is local to Node A; host and Node S cannot directly command PWM. Sequence numbers, age checks, heartbeat and safe defaults are mandatory. The control system shall reject stale, out-of-range or unauthorised mode IDs.
Student interpretation — what this challenge really asks
Industrial products distribute sensing and actuation across nodes. Students must keep timestamps, commands and acknowledgements coherent across two H753 boards while ensuring the actuator node remains safe without the host or sensor node.
Independent data unitone end-to-end distributed process trial reconstructed from both nodes.
Closest misleading casea stale or misaligned sensor value that is plausible by itself but wrong for the actuator response.
Definition of successStudents must complete the physical task and retain a safe local state through sensor-node, bus and host failures.
Visual system blueprint
Physical processDistributed sensing–actuation cellGenerate labelled, safe and repeatable conditions.
Observesensor-node measurements/quality/age, actuator command/applied mode, physical responsePreserve units, timestamps, run identity and signal quality.
H753 responsibilityControl and protectgive each node a clear role, exchange versioned FDCAN messages and retain every actuator interlock locally.
Host intelligenceLearn the distinctionpredict the process state/outcome from synchronized distributed evidence and select a bounded mode.
Bounded outcomeMODE_ID · REQUEST_RECHECK · LOCAL_SAFEMCU validates, acknowledges and may refuse the request.
Recommended build journey
Make the process repeatableAssemble two H753 boards with H753-N and the S, A or M module required by the allocated variant; define reference and target conditions before collecting data.
Prove deterministic firmwareGive each node a clear role, exchange versioned fdcan messages and retain every actuator interlock locally. Demonstrate every hard limit before connecting ML.
Build trustworthy trialsTreat one end-to-end distributed process trial reconstructed from both nodes as independent; calibrate, label and split by run/session.
Beat a real baselineCompare local threshold/rule using the latest valid sensor message with two syllabus-approved classical models.
Close and challenge the loopReturn only the applicable subset of MODE_ID · REQUEST_RECHECK · LOCAL_SAFE; test the target, nearest confuser, stale command and host loss.
Definition of done
Firmware controls safely before, during and after host connection.
Held-out results report task-specific ML metric plus stale-command rejection, end-to-end latency and node-loss safety.
Portfolio shows two-lane synchronized node timeline linked by command and acknowledgement and one honest failure case.
Problem-specific evidence at the common reviews
R1 · Design
Define node responsibilities, message IDs, time/sequence contract, ML target, local fallback and acceptance tests.
R2 · Embedded
Demonstrate sensor-node telemetry, actuator-node control/acknowledgement, termination and node-loss safety.
R3 · Data
Submit synchronised two-node dataset, missing/stale analysis and local-rule baseline.
R4 · ML
Show model and decision mapping with latency and stale-data sensitivity.
R5 · Integration
Close the loop, inject sensor-node loss, actuator-node reset and host loss, and preserve safety.
Final
Operate the distributed cell under a blind scenario and explain the full sensor-to-decision-to-action trace.
Portfolio/Kaggle outcome
Portfolio: CAN protocol document, two firmware projects, synchronised dataset, host notebook, end-to-end trace visualisation and failure-mode video. Kaggle data should include both node timestamps and reconstructed trial IDs.
Industry alignment and validation basis
TwinNode Cell: external references and required evidence
The listed sources establish relevance, test discipline and implementation precedent. They do not modify the common syllabus boundary, safety rules or 100-mark assessment rubric.
Family implementation profile
Variant availability: 10 standard assignment(s); 0 organiser-supported assignment(s).
Public evidence: reproducible firmware, protocol, dataset, notebook/model, test report and demonstration video.
What the external benchmark confirms
The problem has a recognisable industrial or challenge analogue, a measurable data task, a defensible embedded implementation and a safe operational decision. Every one of its ten variants is mapped separately below.
Condition before team allocation
Supply a common clock/sequence convention and require each actuator node to prove local safety with every other component disconnected.
Monitor telemetry points against predefined limits, emit events and initiate a predefined response when a limit is violated.
Keep deterministic limits independent of ML, emit a reason-coded event and invoke only a pre-approved response.
Open the 10 fully elaborated student variant briefs
Choose only the variant allocated to your team. Read it together with the parent problem above: the card expands the experimental delta, while every hardware, safety, integration and review requirement of the family remains active.
Variant 15.01
Distributed Thermal Cell
Engineering purpose: Natural separation of sensing and cooling.
LearnTemperature-risk prediction and mode selection.
Decideapproved MODE_ID, REQUEST_RECHECK or LOCAL_SAFE
Provetask-specific ML metric plus stale-command rejection,…
Variant equipment · EQ-15-01
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception2 H753 boards1 laptop
Controller2 H753 boards + 1 laptop
SenseLM35-class temperature channels; LDR or 10 kΩ load/context proxy
Actuate5/12 V fan through protected MOSFET/relay driver
Fixturetwo-node thermal cell; LM35 channels, LDR/load proxy, shrouded fan and protec…
Protectcurrent-limited actuator supply with fuse; hardware actuator-isolation switch…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
2 × NUCLEO-H753ZI / MB1364E boards with onboard STLINK-V3E
2 × data-capable USB-A/USB-C-to-Micro-B cables
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
1 × powered USB data hub with at least three downstream ports
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
2 × full-size solderless breadboards, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser message-sequence/failure matrix for sensor-node, actuator-node, bus and host loss
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: The actuator node must remain safe after loss of the sensor node, physical bus or host. Verify the complete EQ-15-01 manifest before data collection.
1 · Scenario and student challenge
Sensor node measures LM35/LDR; actuator node controls fan/relay. In plain language, adapt TwinNode Cell — Distributed Sensing and Actuation Supervisor so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Natural separation of sensing and cooling.
2 · What to build or modify
Allocated hardware: 2 × H753 + H753-N + H753-S temperature/light + H753-A fan/relay. Begin with two H753 boards with H753-N and the S, A or M module required by the allocated variant and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record sensor-node measurements/quality/age, actuator command/applied mode, physical response, sequence, heartbeat and link latency. Treat one end-to-end distributed process trial reconstructed from both nodes as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Temperature-risk prediction and mode selection. First implement the parent baseline—local threshold/rule using the latest valid sensor message—and then compare two algorithms from the faculty-issued ML whitelist. Report MAE and RMSE on whole held-out runs, show predicted-versus-measured values, and inspect error by operating condition. If the target is converted to a safe/unsafe decision, also report missed-unsafe and unnecessary-conservative actions. Produce a predicted-versus-measured plot with residuals by operating condition.
5 · Embedded integration and safe response
The host may return only approved MODE_ID, REQUEST_RECHECK or LOCAL_SAFE, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a stale or misaligned sensor value that is plausible by itself but wrong for the actuator response. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 15.01 — Distributed Thermal Cell”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P15 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Distributed Thermal Cell is a syllabus-scaled physical analogue of the need evidenced by IR03 · F Prime (F´): Sensor node measures LM35/LDR; actuator node controls fan/relay. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needProvide a component-driven, flight-proven embedded framework with well-defined interfaces, reusable components and unit/integration testing tools.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Reference
Expected engineering evidence
Course and implementation boundary
IR03 R · Distributed embedded reference architecture
Define node roles, typed interfaces, command/telemetry responsibilities, health behaviour and integration tests before implementation.
Students do not install F´ or implement RTOS-style architecture; they transfer its interface and verification discipline.
Evaluate the complete sense–decide–act system, its interfaces and failure behaviour—not a disconnected model or dashboard.
It is used as architectural guidance; certification or conformance is neither asserted nor required.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationSupply a common clock/sequence convention and require each actuator node to prove local safety with every other component disconnected.
Decideapproved MODE_ID, REQUEST_RECHECK or LOCAL_SAFE
Provetask-specific ML metric plus stale-command rejection,…
Variant equipment · EQ-15-02
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception2 H753 boards1 laptop
Controller2 H753 boards + 1 laptop
SenseLDR 0–3.3 V channel; servo-position feedback/angle grid
Actuateexternally powered low-torque servo shade
Fixturetwo-node light-positioning cell; LDR, diffused LED source, servo shade and ap…
ProtectUSB board-power paths; fused regulated 5 V servo/light supply
System block
Complete quantity and equipment per team
Why it is required
Controller & host
2 × NUCLEO-H753ZI / MB1364E boards with onboard STLINK-V3E
2 × data-capable USB-A/USB-C-to-Micro-B cables
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
1 × powered USB data hub with at least three downstream ports
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
2 × full-size solderless breadboards, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser message-sequence/failure matrix for sensor-node, actuator-node, bus and host loss
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: The actuator node must remain safe after loss of the sensor node, physical bus or host. Verify the complete EQ-15-02 manifest before data collection.
1 · Scenario and student challenge
Sensor node measures light; actuator node positions a servo shade. In plain language, adapt TwinNode Cell — Distributed Sensing and Actuation Supervisor so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Demonstrates networked mechatronics.
2 · What to build or modify
Allocated hardware: 2 × H753 + H753-N + H753-S LDR + externally powered servo shade. Begin with two H753 boards with H753-N and the S, A or M module required by the allocated variant and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record sensor-node measurements/quality/age, actuator command/applied mode, physical response, sequence, heartbeat and link latency. Treat one end-to-end distributed process trial reconstructed from both nodes as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Best-profile/angle classification. First implement the parent baseline—local threshold/rule using the latest valid sensor message—and then compare two algorithms from the faculty-issued ML whitelist. Report correct/feasible selection rate, constraint violations and improvement over the fixed policy. A choice is wrong if it violates a declared current, timing, thermal or control-quality bound even when it is fast. Produce a candidate-outcome/constraint table showing why the selected option is feasible.
5 · Embedded integration and safe response
The host may return only approved MODE_ID, REQUEST_RECHECK or LOCAL_SAFE, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a stale or misaligned sensor value that is plausible by itself but wrong for the actuator response. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 15.02 — Remote Light-Positioning Cell”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P15 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Remote Light-Positioning Cell is a syllabus-scaled physical analogue of the need evidenced by IR03 · F Prime (F´): Sensor node measures light; actuator node positions a servo shade. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needProvide a component-driven, flight-proven embedded framework with well-defined interfaces, reusable components and unit/integration testing tools.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Reference
Expected engineering evidence
Course and implementation boundary
IR03 R · Distributed embedded reference architecture
Define node roles, typed interfaces, command/telemetry responsibilities, health behaviour and integration tests before implementation.
Students do not install F´ or implement RTOS-style architecture; they transfer its interface and verification discipline.
Evaluate the complete sense–decide–act system, its interfaces and failure behaviour—not a disconnected model or dashboard.
It is used as architectural guidance; certification or conformance is neither asserted nor required.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationSupply a common clock/sequence convention and require each actuator node to prove local safety with every other component disconnected.
Decideapproved MODE_ID, REQUEST_RECHECK or LOCAL_SAFE
Provetask-specific ML metric plus stale-command rejection,…
Variant equipment · EQ-15-03
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception2 H753 boards1 laptop
Controller2 H753 boards + 1 laptop
Senseencoder; 0–3.3 V current channel; LM35 temperature channel; 10 kΩ context pot…
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser message-sequence/failure matrix for sensor-node, actuator-node, bus and host loss
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: The actuator node must remain safe after loss of the sensor node, physical bus or host. Verify the complete EQ-15-03 manifest before data collection.
1 · Scenario and student challenge
Actuator node reports current/speed while sensor node supplies environment/load proxy. In plain language, adapt TwinNode Cell — Distributed Sensing and Actuation Supervisor so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Combines distributed context.
2 · What to build or modify
Allocated hardware: 2 × H753 + H753-N + H753-M motion/current fixture. Begin with two H753 boards with H753-N and the S, A or M module required by the allocated variant and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record sensor-node measurements/quality/age, actuator command/applied mode, physical response, sequence, heartbeat and link latency. Treat one end-to-end distributed process trial reconstructed from both nodes as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Fault or load classification. First implement the parent baseline—local threshold/rule using the latest valid sensor message—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only approved MODE_ID, REQUEST_RECHECK or LOCAL_SAFE, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a stale or misaligned sensor value that is plausible by itself but wrong for the actuator response. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 15.03 — Remote Motor-Load Supervisor”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P15 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Remote Motor-Load Supervisor is a syllabus-scaled physical analogue of the need evidenced by IR03 · F Prime (F´): Actuator node reports current/speed while sensor node supplies environment/load proxy. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needProvide a component-driven, flight-proven embedded framework with well-defined interfaces, reusable components and unit/integration testing tools.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Reference
Expected engineering evidence
Course and implementation boundary
IR03 R · Distributed embedded reference architecture
Define node roles, typed interfaces, command/telemetry responsibilities, health behaviour and integration tests before implementation.
Students do not install F´ or implement RTOS-style architecture; they transfer its interface and verification discipline.
Evaluate the complete sense–decide–act system, its interfaces and failure behaviour—not a disconnected model or dashboard.
It is used as architectural guidance; certification or conformance is neither asserted nor required.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationSupply a common clock/sequence convention and require each actuator node to prove local safety with every other component disconnected.
Variant 15.04
Two-Zone Environment Balancer
Engineering purpose: Adds multi-point sensing with limited hardware.
Decideapproved MODE_ID, REQUEST_RECHECK or LOCAL_SAFE
Provetask-specific ML metric plus stale-command rejection,…
Variant equipment · EQ-15-04
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception2 H753 boards1 laptop
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser message-sequence/failure matrix for sensor-node, actuator-node, bus and host loss
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: The actuator node must remain safe after loss of the sensor node, physical bus or host. Verify the complete EQ-15-04 manifest before data collection.
1 · Scenario and student challenge
Each node samples a zone; one actuator redistributes airflow/light. In plain language, adapt TwinNode Cell — Distributed Sensing and Actuation Supervisor so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Adds multi-point sensing with limited hardware.
2 · What to build or modify
Allocated hardware: 2 × H753 + H753-N + two H753-S zone sensors + one protected fan/light actuator. Begin with two H753 boards with H753-N and the S, A or M module required by the allocated variant and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record sensor-node measurements/quality/age, actuator command/applied mode, physical response, sequence, heartbeat and link latency. Treat one end-to-end distributed process trial reconstructed from both nodes as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Zone-imbalance classification. First implement the parent baseline—local threshold/rule using the latest valid sensor message—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only approved MODE_ID, REQUEST_RECHECK or LOCAL_SAFE, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a stale or misaligned sensor value that is plausible by itself but wrong for the actuator response. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 15.04 — Two-Zone Environment Balancer”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
2 × H753 + H753-N + two H753-S zone sensors + one protected fan/light actuatorclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P15 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Two-Zone Environment Balancer is a syllabus-scaled physical analogue of the need evidenced by IR03 · F Prime (F´): Each node samples a zone; one actuator redistributes airflow/light. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needProvide a component-driven, flight-proven embedded framework with well-defined interfaces, reusable components and unit/integration testing tools.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Reference
Expected engineering evidence
Course and implementation boundary
IR03 R · Distributed embedded reference architecture
Define node roles, typed interfaces, command/telemetry responsibilities, health behaviour and integration tests before implementation.
Students do not install F´ or implement RTOS-style architecture; they transfer its interface and verification discipline.
Evaluate the complete sense–decide–act system, its interfaces and failure behaviour—not a disconnected model or dashboard.
It is used as architectural guidance; certification or conformance is neither asserted nor required.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationSupply a common clock/sequence convention and require each actuator node to prove local safety with every other component disconnected.
Variant 15.05
Distributed Sorting Cell
Engineering purpose: Clear manufacturing workflow over CAN.
Decideapproved MODE_ID, REQUEST_RECHECK or LOCAL_SAFE
Provetask-specific ML metric plus stale-command rejection,…
Variant equipment · EQ-15-05
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception2 H753 boards1 laptop
Controller2 H753 boards + 1 laptop
SenseLDR 0–3.3 V channel; ambient-reference channel
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser message-sequence/failure matrix for sensor-node, actuator-node, bus and host loss
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: The actuator node must remain safe after loss of the sensor node, physical bus or host. Verify the complete EQ-15-05 manifest before data collection.
1 · Scenario and student challenge
Sensor node performs LDR inspection; actuator node drives diverter. In plain language, adapt TwinNode Cell — Distributed Sensing and Actuation Supervisor so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Clear manufacturing workflow over CAN.
2 · What to build or modify
Allocated hardware: 2 × H753 + H753-N + H753-S optical path + servo diverter. Begin with two H753 boards with H753-N and the S, A or M module required by the allocated variant and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record sensor-node measurements/quality/age, actuator command/applied mode, physical response, sequence, heartbeat and link latency. Treat one end-to-end distributed process trial reconstructed from both nodes as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Specimen classification and bin command. First implement the parent baseline—local threshold/rule using the latest valid sensor message—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only approved MODE_ID, REQUEST_RECHECK or LOCAL_SAFE, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a stale or misaligned sensor value that is plausible by itself but wrong for the actuator response. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 15.05 — Distributed Sorting Cell”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P15 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Distributed Sorting Cell is a syllabus-scaled physical analogue of the need evidenced by IR03 · F Prime (F´): Sensor node performs LDR inspection; actuator node drives diverter. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needProvide a component-driven, flight-proven embedded framework with well-defined interfaces, reusable components and unit/integration testing tools.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Reference
Expected engineering evidence
Course and implementation boundary
IR03 R · Distributed embedded reference architecture
Define node roles, typed interfaces, command/telemetry responsibilities, health behaviour and integration tests before implementation.
Students do not install F´ or implement RTOS-style architecture; they transfer its interface and verification discipline.
Evaluate the complete sense–decide–act system, its interfaces and failure behaviour—not a disconnected model or dashboard.
It is used as architectural guidance; certification or conformance is neither asserted nor required.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationSupply a common clock/sequence convention and require each actuator node to prove local safety with every other component disconnected.
Variant 15.06
Redundant Sensor Voting Cell
Engineering purpose: Introduces resilience and data provenance.
Decideapproved MODE_ID, REQUEST_RECHECK or LOCAL_SAFE
Provetask-specific ML metric plus stale-command rejection,…
Variant equipment · EQ-15-06
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception2 H753 boards1 laptop
Controller2 H753 boards + 1 laptop
Sensematched LM35-class 0–3.3 V temperature channels, one on each node; sealed sha…
ActuateNo powered actuator is required.
Fixtureredundant-sensor comparison panel; matched LM35 sensors mounted to the same s…
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser message-sequence/failure matrix for sensor-node, actuator-node, bus and host loss
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: The actuator node must remain safe after loss of the sensor node, physical bus or host. Verify the complete EQ-15-06 manifest before data collection.
1 · Scenario and student challenge
Two nodes measure related channels and host assesses disagreement. In plain language, adapt TwinNode Cell — Distributed Sensing and Actuation Supervisor so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Introduces resilience and data provenance.
2 · What to build or modify
Allocated hardware: 2 × H753 + H753-N + two related 0–3.3 V sensor channels. Begin with two H753 boards with H753-N and the S, A or M module required by the allocated variant and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record sensor-node measurements/quality/age, actuator command/applied mode, physical response, sequence, heartbeat and link latency. Treat one end-to-end distributed process trial reconstructed from both nodes as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Trust/fault classification. First implement the parent baseline—local threshold/rule using the latest valid sensor message—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only approved MODE_ID, REQUEST_RECHECK or LOCAL_SAFE, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a stale or misaligned sensor value that is plausible by itself but wrong for the actuator response. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 15.06 — Redundant Sensor Voting Cell”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
2 × H753 + H753-N + two related 0–3.3 V sensor channelsclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P15 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Redundant Sensor Voting Cell is a syllabus-scaled physical analogue of the need evidenced by IR03 · F Prime (F´): Two nodes measure related channels and host assesses disagreement. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needProvide a component-driven, flight-proven embedded framework with well-defined interfaces, reusable components and unit/integration testing tools.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Reference
Expected engineering evidence
Course and implementation boundary
IR03 R · Distributed embedded reference architecture
Define node roles, typed interfaces, command/telemetry responsibilities, health behaviour and integration tests before implementation.
Students do not install F´ or implement RTOS-style architecture; they transfer its interface and verification discipline.
Evaluate the complete sense–decide–act system, its interfaces and failure behaviour—not a disconnected model or dashboard.
It is used as architectural guidance; certification or conformance is neither asserted nor required.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationSupply a common clock/sequence convention and require each actuator node to prove local safety with every other component disconnected.
Variant 15.07
Remote Gate Safety Cell
Engineering purpose: Emphasises local safety despite remote intelligence.
Decideapproved MODE_ID, REQUEST_RECHECK or LOCAL_SAFE
Provetask-specific ML metric plus stale-command rejection,…
Variant equipment · EQ-15-07
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception2 H753 boards1 laptop
Controller2 H753 boards + 1 laptop
Senseencoder/position channel; 0–3.3 V current channel; end switches; command/envi…
Actuategeared DC motor and 3.3-V H-bridge
Fixturetwo-node low-force gate cell; geared actuator/encoder/current channel, end sw…
ProtectUSB board-power paths; fused motor supply; physical E-stop
System block
Complete quantity and equipment per team
Why it is required
Controller & host
2 × NUCLEO-H753ZI / MB1364E boards with onboard STLINK-V3E
2 × data-capable USB-A/USB-C-to-Micro-B cables
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
1 × powered USB data hub with at least three downstream ports
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
2 × full-size solderless breadboards, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser message-sequence/failure matrix for sensor-node, actuator-node, bus and host loss
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: The actuator node must remain safe after loss of the sensor node, physical bus or host. Verify the complete EQ-15-07 manifest before data collection.
1 · Scenario and student challenge
One node senses command/environment; actuator node controls low-force gate and current/position. In plain language, adapt TwinNode Cell — Distributed Sensing and Actuation Supervisor so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Emphasises local safety despite remote intelligence.
2 · What to build or modify
Allocated hardware: 2 × H753 + H753-N + H753-M motion/current fixture. Begin with two H753 boards with H753-N and the S, A or M module required by the allocated variant and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record sensor-node measurements/quality/age, actuator command/applied mode, physical response, sequence, heartbeat and link latency. Treat one end-to-end distributed process trial reconstructed from both nodes as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Obstruction/state classification. First implement the parent baseline—local threshold/rule using the latest valid sensor message—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only approved MODE_ID, REQUEST_RECHECK or LOCAL_SAFE, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a stale or misaligned sensor value that is plausible by itself but wrong for the actuator response. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 15.07 — Remote Gate Safety Cell”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P15 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Remote Gate Safety Cell is a syllabus-scaled physical analogue of the need evidenced by IR03 · F Prime (F´): One node senses command/environment; actuator node controls low-force gate and current/position. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needProvide a component-driven, flight-proven embedded framework with well-defined interfaces, reusable components and unit/integration testing tools.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Reference
Expected engineering evidence
Course and implementation boundary
IR03 R · Distributed embedded reference architecture
Define node roles, typed interfaces, command/telemetry responsibilities, health behaviour and integration tests before implementation.
Students do not install F´ or implement RTOS-style architecture; they transfer its interface and verification discipline.
Evaluate the complete sense–decide–act system, its interfaces and failure behaviour—not a disconnected model or dashboard.
It is used as architectural guidance; certification or conformance is neither asserted nor required.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationSupply a common clock/sequence convention and require each actuator node to prove local safety with every other component disconnected.
Decideapproved MODE_ID, REQUEST_RECHECK or LOCAL_SAFE
Provetask-specific ML metric plus stale-command rejection,…
Variant equipment · EQ-15-08
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception2 H753 boards1 laptop
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser message-sequence/failure matrix for sensor-node, actuator-node, bus and host loss
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: The actuator node must remain safe after loss of the sensor node, physical bus or host. Verify the complete EQ-15-08 manifest before data collection.
1 · Scenario and student challenge
Sensor node supplies demand proxy; actuator node switches a low-voltage load. In plain language, adapt TwinNode Cell — Distributed Sensing and Actuation Supervisor so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Maps to energy management.
2 · What to build or modify
Allocated hardware: 2 × H753 + H753-N + H753-S demand proxy + H753-A low-voltage load. Begin with two H753 boards with H753-N and the S, A or M module required by the allocated variant and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record sensor-node measurements/quality/age, actuator command/applied mode, physical response, sequence, heartbeat and link latency. Treat one end-to-end distributed process trial reconstructed from both nodes as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Demand class/next-state prediction. First implement the parent baseline—local threshold/rule using the latest valid sensor message—and then compare two algorithms from the faculty-issued ML whitelist. Report MAE and RMSE on whole held-out runs, show predicted-versus-measured values, and inspect error by operating condition. If the target is converted to a safe/unsafe decision, also report missed-unsafe and unnecessary-conservative actions. Produce a predicted-versus-measured plot with residuals by operating condition.
5 · Embedded integration and safe response
The host may return only approved MODE_ID, REQUEST_RECHECK or LOCAL_SAFE, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a stale or misaligned sensor value that is plausible by itself but wrong for the actuator response. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 15.08 — Demand–Response Load Cell”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P15 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Demand–Response Load Cell is a syllabus-scaled physical analogue of the need evidenced by IR03 · F Prime (F´): Sensor node supplies demand proxy; actuator node switches a low-voltage load. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needProvide a component-driven, flight-proven embedded framework with well-defined interfaces, reusable components and unit/integration testing tools.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Reference
Expected engineering evidence
Course and implementation boundary
IR03 R · Distributed embedded reference architecture
Define node roles, typed interfaces, command/telemetry responsibilities, health behaviour and integration tests before implementation.
Students do not install F´ or implement RTOS-style architecture; they transfer its interface and verification discipline.
Evaluate the complete sense–decide–act system, its interfaces and failure behaviour—not a disconnected model or dashboard.
It is used as architectural guidance; certification or conformance is neither asserted nor required.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationSupply a common clock/sequence convention and require each actuator node to prove local safety with every other component disconnected.
Variant 15.09
Two-Node Test Bench
Engineering purpose: Creates a distributed validation instrument.
Decideapproved MODE_ID, REQUEST_RECHECK or LOCAL_SAFE
Provetask-specific ML metric plus stale-command rejection,…
Variant equipment · EQ-15-09
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception2 H753 boards1 laptop
Controller2 H753 boards + 1 laptop
Sense10 kΩ setpoint potentiometer; encoder; 0–3.3 V current channel; LM35 channel
Actuategeared DC motor and 3.3-V H-bridge
Fixturetwo-node test bench; command potentiometer on test node and guarded motor res…
ProtectUSB board-power paths; fused motor supply; physical E-stop
System block
Complete quantity and equipment per team
Why it is required
Controller & host
2 × NUCLEO-H753ZI / MB1364E boards with onboard STLINK-V3E
2 × data-capable USB-A/USB-C-to-Micro-B cables
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
1 × powered USB data hub with at least three downstream ports
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
2 × full-size solderless breadboards, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser message-sequence/failure matrix for sensor-node, actuator-node, bus and host loss
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: The actuator node must remain safe after loss of the sensor node, physical bus or host. Verify the complete EQ-15-09 manifest before data collection.
1 · Scenario and student challenge
One node generates safe test setpoints; the other executes and reports response. In plain language, adapt TwinNode Cell — Distributed Sensing and Actuation Supervisor so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Creates a distributed validation instrument.
2 · What to build or modify
Allocated hardware: 2 × H753 + H753-N + H753-M motion/current fixture. Begin with two H753 boards with H753-N and the S, A or M module required by the allocated variant and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record sensor-node measurements/quality/age, actuator command/applied mode, physical response, sequence, heartbeat and link latency. Treat one end-to-end distributed process trial reconstructed from both nodes as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Response-quality prediction. First implement the parent baseline—local threshold/rule using the latest valid sensor message—and then compare two algorithms from the faculty-issued ML whitelist. Report MAE and RMSE on whole held-out runs, show predicted-versus-measured values, and inspect error by operating condition. If the target is converted to a safe/unsafe decision, also report missed-unsafe and unnecessary-conservative actions. Produce a predicted-versus-measured plot with residuals by operating condition.
5 · Embedded integration and safe response
The host may return only approved MODE_ID, REQUEST_RECHECK or LOCAL_SAFE, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a stale or misaligned sensor value that is plausible by itself but wrong for the actuator response. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 15.09 — Two-Node Test Bench”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P15 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Two-Node Test Bench is a syllabus-scaled physical analogue of the need evidenced by IR03 · F Prime (F´): One node generates safe test setpoints; the other executes and reports response. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needProvide a component-driven, flight-proven embedded framework with well-defined interfaces, reusable components and unit/integration testing tools.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Reference
Expected engineering evidence
Course and implementation boundary
IR03 R · Distributed embedded reference architecture
Define node roles, typed interfaces, command/telemetry responsibilities, health behaviour and integration tests before implementation.
Students do not install F´ or implement RTOS-style architecture; they transfer its interface and verification discipline.
Evaluate the complete sense–decide–act system, its interfaces and failure behaviour—not a disconnected model or dashboard.
It is used as architectural guidance; certification or conformance is neither asserted nor required.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationSupply a common clock/sequence convention and require each actuator node to prove local safety with every other component disconnected.
Variant 15.10
Node-Role Swap Auditor
Engineering purpose: Tests whether the pipeline generalises across roles and physical H753 specimens without introducing another MCU platform.
LearnModel robustness and board-pair domain-shift analysis.
Decideapproved MODE_ID, REQUEST_RECHECK or LOCAL_SAFE
Provetask-specific ML metric plus stale-command rejection,…
Variant equipment · EQ-15-10
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception2 H753 boards1 laptop
Controller2 H753 boards + 1 laptop
SenseLM35-class temperature channels and demand potentiometer
Actuateshrouded fan through protected MOSFET driver
Fixturerole-swap thermal/fan cell used unchanged in both trials; identical sensor ha…
Protectcurrent-limited actuator supply with fuse; hardware actuator-isolation switch…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
2 × NUCLEO-H753ZI / MB1364E boards with onboard STLINK-V3E
2 × data-capable USB-A/USB-C-to-Micro-B cables
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
1 × powered USB data hub with at least three downstream ports
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
2 × full-size solderless breadboards, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser message-sequence/failure matrix for sensor-node, actuator-node, bus and host loss
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: The actuator node must remain safe after loss of the sensor node, physical bus or host. Verify the complete EQ-15-10 manifest before data collection.
1 · Scenario and student challenge
Run equivalent trials after swapping sensing and actuation roles between the two identical NUCLEO-H753ZI boards, then repeat on a second H753 board pair if available. In plain language, adapt TwinNode Cell — Distributed Sensing and Actuation Supervisor so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Tests whether the pipeline generalises across roles and physical H753 specimens without introducing another MCU platform.
2 · What to build or modify
Allocated hardware: 2 × H753 + H753-N + the same selected process module on both board-role trials. Begin with two H753 boards with H753-N and the S, A or M module required by the allocated variant and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record sensor-node measurements/quality/age, actuator command/applied mode, physical response, sequence, heartbeat and link latency. Treat one end-to-end distributed process trial reconstructed from both nodes as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Model robustness and board-pair domain-shift analysis. First implement the parent baseline—local threshold/rule using the latest valid sensor message—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a two-lane synchronized node timeline linked by command and acknowledgement.
5 · Embedded integration and safe response
The host may return only approved MODE_ID, REQUEST_RECHECK or LOCAL_SAFE, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a stale or misaligned sensor value that is plausible by itself but wrong for the actuator response. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 15.10 — Node-Role Swap Auditor”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
2 × H753 + H753-N + the same selected process module on both board-role trialsclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P15 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Node-Role Swap Auditor is a syllabus-scaled physical analogue of the need evidenced by IR03 · F Prime (F´): Run equivalent trials after swapping sensing and actuation roles between the two identical NUCLEO-H753ZI boards, then repeat on a second H753 board pair if available. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needProvide a component-driven, flight-proven embedded framework with well-defined interfaces, reusable components and unit/integration testing tools.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Reference
Expected engineering evidence
Course and implementation boundary
IR03 R · Distributed embedded reference architecture
Define node roles, typed interfaces, command/telemetry responsibilities, health behaviour and integration tests before implementation.
Students do not install F´ or implement RTOS-style architecture; they transfer its interface and verification discipline.
Evaluate the complete sense–decide–act system, its interfaces and failure behaviour—not a disconnected model or dashboard.
It is used as architectural guidance; certification or conformance is neither asserted nor required.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationSupply a common clock/sequence convention and require each actuator node to prove local safety with every other component disconnected.
Problem 16 · 10 variants · CAN, telemetry and distributed embedded intelligence
Assigned Faculty Master pair for P16: one nominated ESD Faculty Master and one nominated ML Faculty Master shall jointly master this parent problem and variants V1-V10. The ESD Master owns hardware, firmware, control, communication and safety verification; the ML Master owns data, baselines, models, validation and bounded decision-policy verification. Together they teach and guide ten teams (one for each variant and up to 40 students), supervise five teams in Wave A and five in Wave B, witness integration and sign every final evaluation.
The problem
Periodic telemetry is easy when only one message exists. With several sensor, diagnostic and status frames, fixed rates can waste bandwidth during steady operation yet still fail to capture short anomalies. The challenge is to adapt only noncritical telemetry rates according to predicted signal activity and bus load while preserving fixed heartbeat, command and safety priorities.
Smart embedded product to build
Build a two-node NUCLEO-H753ZI FDCAN telemetry-policy demonstrator. Heartbeat, fault and command/acknowledgement frames retain immutable IDs and periods; only noncritical sensor/diagnostic traffic can select QUIET, NORMAL, BURST or DIAGNOSTIC profiles. The nodes measure per-ID counts, inter-arrival, response delay and missing sequence. The host predicts the upcoming signal/traffic regime or latency risk, recommends a profile, and verifies the effective rate through acknowledgement.
NUCLEO-H753ZI realization and issued pack
two NUCLEO-H753ZI / MB1364E boards with H753-N and H753-S signals
physical FDCAN network with heartbeat/safety traffic held at immutable IDs and periods
separate timer-driven sensor/logging periods and noncritical rate-profile table
per-ID transmit count, inter-arrival, command-response and missing-sequence instrumentation
host receives synchronized trace through USART3 VCP/gateway and recommends only a rate-profile ID
nodes acknowledge effective rate; host loss returns to NORMAL_RATE
no RTOS scheduler or electrical bus-fault injection is required
Intelligence to incorporate
Use signal slope/variance, recent event count, frame rates, ID mix, command-response latency and missing sequences. Compare fixed-fast, fixed-slow and rule-triggered baselines with classification/regression. Evaluate data freshness, captured-event recall, bus-load/latency proxy and message-count reduction.
Permitted output/action set
QUIET · NORMAL · BURST · DIAGNOSTIC · PROFILE_ID
Canonical family command contract: every parent brief, variant, host message and MCU acknowledgement for P16 shall use these exact identifiers. A variant may use only the applicable subset; it shall not introduce a synonym.
Core problem equipment · EQ-16-CORE
Complete equipment required for one core-problem team
Standalone family BOM. This list supports the parent problem itself. An allocated variant uses its own complete table later in this card. A component mentioned again in the fixture description is the same mounted unit, not another copy.
4 students; 3 by approved exception2 H753 boards1 team laptopquantities per team
Controller2 H753 boards + 1 laptop
SenseLM35-class temperature channel; LDR divider; 10 kΩ potentiometer for controll…
ActuateNo powered actuator is required for the core QoS problem; motion variants exp…
Fixturetwo-node network fixture with labelled SAFETY, COMMAND and NONCRITICAL teleme…
ProtectUSB board-power paths through the laptop/powered hub; protected transceiver s…
System block
Complete quantity and equipment per team
Purpose / acceptance condition
Controller & host
2 × NUCLEO-H753ZI / MB1364E boards with onboard STLINK-V3E
2 × data-capable USB-A/USB-C-to-Micro-B cables
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
1 × powered USB data hub with at least three downstream ports
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
2 × full-size solderless breadboards, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser message-budget/latency scoring sheet and golden network trace
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Release-to-team condition: Safety heartbeat and command traffic retain immutable periods; ML changes only whitelisted noncritical telemetry rates. The organiser signs the electrical, mechanical and communication acceptance checklist before H0:00.
Not duplicated inside the kit: supervised rework tools and the oscilloscope/logic-analyser station are shared at the ratio stated above. Everything else in this table is issued to, reserved for, or digitally assigned to this team.
Controlled self-learning extension
Recommended Add an explicit per-second frame budget and verify monotonic safety: reducing noncritical traffic must never worsen heartbeat/fault latency. Plot observability gained per transmitted byte/frame.
System safety and non-negotiable boundary
Heartbeat, hard-fault and command/ack frames have immutable priorities/rates. ML can modify only a whitelist of noncritical telemetry profiles. On host loss the nodes return to NORMAL_RATE, not silence.
Student interpretation — what this challenge really asks
Telemetry should be rich when events matter and economical when the process is quiet. Students select among approved message-rate profiles without altering the fixed control loop or starving safety traffic.
Independent data unitone fixed-duration traffic epoch with a declared process and message profile.
Closest misleading casea harmless short burst that should not permanently promote the network to a costly high-rate profile.
Definition of successStudents must save bandwidth while preserving every declared safety/command deadline and important event on a hidden traffic scenario.
Visual system blueprint
Physical processFDCAN telemetry under a frame budgetGenerate labelled, safe and repeatable conditions.
Observeprocess regime, frame ID/rate, inter-arrival/jitterPreserve units, timestamps, run identity and signal quality.
H753 responsibilityControl and protectpreserve fixed heartbeat/control traffic and apply only whitelisted noncritical telemetry schedules.
Host intelligenceLearn the distinctionclassify regime or predict latency/event-capture risk for a telemetry profile.
Bounded outcomeQUIET · NORMAL · BURST · DIAGNOSTIC · PROFILE_IDMCU validates, acknowledges and may refuse the request.
Recommended build journey
Make the process repeatableAssemble two H753 boards with H753-N and H753-S process signals; define reference and target conditions before collecting data.
Prove deterministic firmwarePreserve fixed heartbeat/control traffic and apply only whitelisted noncritical telemetry schedules. Demonstrate every hard limit before connecting ML.
Build trustworthy trialsTreat one fixed-duration traffic epoch with a declared process and message profile as independent; calibrate, label and split by run/session.
Beat a real baselineCompare fixed-fast, fixed-slow or threshold-triggered schedule with two syllabus-approved classical models.
Close and challenge the loopReturn only the applicable subset of QUIET · NORMAL · BURST · DIAGNOSTIC · PROFILE_ID; test the target, nearest confuser, stale command and host loss.
Definition of done
Firmware controls safely before, during and after host connection.
Demonstrate fixed traffic, timing counters, profile switching and preservation of critical frames.
R3 · Data
Submit traces under quiet/change/burst regimes and three baseline policies.
R4 · ML
Show regime/risk model and quantify message reduction versus event capture/freshness.
R5 · Integration
Integrate rate selection and pass burst, congestion, host-loss and fault-priority tests.
Final
Handle an unseen signal pattern while preserving critical traffic and improving telemetry efficiency.
Portfolio/Kaggle outcome
Kaggle asset: CAN traces and signal streams with rate-profile labels, event windows, freshness metrics and notebook showing bandwidth-versus-observability trade-offs.
Industry alignment and validation basis
CANFlow: external references and required evidence
The listed sources establish relevance, test discipline and implementation precedent. They do not modify the common syllabus boundary, safety rules or 100-mark assessment rubric.
Family implementation profile
Variant availability: 10 standard assignment(s); 0 organiser-supported assignment(s).
Public evidence: reproducible firmware, protocol, dataset, notebook/model, test report and demonstration video.
What the external benchmark confirms
The problem has a recognisable industrial or challenge analogue, a measurable data task, a defensible embedded implementation and a safe operational decision. Every one of its ten variants is mapped separately below.
Condition before team allocation
Publish an exact frame budget, traffic generator and protected safety-message class; otherwise QoS claims will not be comparable.
Monitor telemetry points against predefined limits, emit events and initiate a predefined response when a limit is violated.
Keep deterministic limits independent of ML, emit a reason-coded event and invoke only a pre-approved response.
Open the 10 fully elaborated student variant briefs
Choose only the variant allocated to your team. Read it together with the parent problem above: the card expands the experimental delta, while every hardware, safety, integration and review requirement of the family remains active.
Variant 16.01
Quiet/Active Sensor Scheduler
Engineering purpose: Simple physical validation of adaptive rates.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception2 H753 boards1 laptop
Controller2 H753 boards + 1 laptop
SenseLM35-class temperature channel; LDR divider; 10 kΩ potentiometer for controll…
ActuateNo powered actuator is required for the core QoS problem; motion variants exp…
Fixturetwo-node sensor scheduler panel; LDR, LM35 and repeatable quiet/active stimul…
ProtectUSB board-power paths through the laptop/powered hub; protected transceiver s…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
2 × NUCLEO-H753ZI / MB1364E boards with onboard STLINK-V3E
2 × data-capable USB-A/USB-C-to-Micro-B cables
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
1 × powered USB data hub with at least three downstream ports
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
2 × full-size solderless breadboards, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser message-budget/latency scoring sheet and golden network trace
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Safety heartbeat and command traffic retain immutable periods; ML changes only whitelisted noncritical telemetry rates. Verify the complete EQ-16-01 manifest before data collection.
1 · Scenario and student challenge
Switch LDR/LM35 telemetry between quiet and active rates. In plain language, adapt CANFlow — Adaptive Telemetry Quality-of-Service Scheduler so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Simple physical validation of adaptive rates.
2 · What to build or modify
Allocated hardware: 2 × H753 + H753-N + H753-S. Begin with two H753 boards with H753-N and H753-S process signals and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record process regime, frame ID/rate, inter-arrival/jitter, queue/drop counters, latency, event coverage and priority class. Treat one fixed-duration traffic epoch with a declared process and message profile as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Regime classification. First implement the parent baseline—fixed-fast, fixed-slow or threshold-triggered schedule—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only QUIET, NORMAL, BURST or DIAGNOSTIC telemetry PROFILE_ID, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a harmless short burst that should not permanently promote the network to a costly high-rate profile. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 16.01 — Quiet/Active Sensor Scheduler”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P16 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Quiet/Active Sensor Scheduler is a syllabus-scaled physical analogue of the need evidenced by ST01 · AUTOSAR End-to-End Protocol Specification: Switch LDR/LM35 telemetry between quiet and active rates. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needSpecify end-to-end mechanisms for detecting loss, repetition, incorrect sequence, delay and corruption of communicated data.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Use counters, age/timeout, sequence and plausibility checks; demonstrate stale, duplicate and missing-data handling.
AUTOSAR compliance is not required; only the observable fault categories and validation discipline are adopted.
IR03 R · Distributed embedded reference architecture
Define node roles, typed interfaces, command/telemetry responsibilities, health behaviour and integration tests before implementation.
Students do not install F´ or implement RTOS-style architecture; they transfer its interface and verification discipline.
IR04 R · Telemetry/command reference implementation
Version message dictionaries, log command and acknowledgement histories and make telemetry replayable for diagnosis.
The hackathon uses a lightweight supplied Python gateway, not the F´ ground system itself.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationPublish an exact frame budget, traffic generator and protected safety-message class; otherwise QoS claims will not be comparable.
Variant 16.02
Anomaly-Triggered Burst Capture
Engineering purpose: Improves diagnostic detail when it matters.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception2 H753 boards1 laptop
Controller2 H753 boards + 1 laptop
Senseencoder; 0–3.3 V current channel; LM35 channel
Actuategeared DC motor and 3.3-V H-bridge
Fixturetwo-node motor telemetry rig; guarded motor/encoder/H-bridge/current channel…
ProtectUSB board-power paths; fused motor supply; physical E-stop
System block
Complete quantity and equipment per team
Why it is required
Controller & host
2 × NUCLEO-H753ZI / MB1364E boards with onboard STLINK-V3E
2 × data-capable USB-A/USB-C-to-Micro-B cables
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
1 × powered USB data hub with at least three downstream ports
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
2 × full-size solderless breadboards, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser message-budget/latency scoring sheet and golden network trace
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Safety heartbeat and command traffic retain immutable periods; ML changes only whitelisted noncritical telemetry rates. Verify the complete EQ-16-02 manifest before data collection.
1 · Scenario and student challenge
Increase noncritical telemetry before/during abnormal motor behaviour. In plain language, adapt CANFlow — Adaptive Telemetry Quality-of-Service Scheduler so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Improves diagnostic detail when it matters.
2 · What to build or modify
Allocated hardware: 2 × H753 + H753-N + H753-S + H753-M process telemetry. Begin with two H753 boards with H753-N and H753-S process signals and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record process regime, frame ID/rate, inter-arrival/jitter, queue/drop counters, latency, event coverage and priority class. Treat one fixed-duration traffic epoch with a declared process and message profile as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Anomaly-risk classification. First implement the parent baseline—fixed-fast, fixed-slow or threshold-triggered schedule—and then compare two algorithms from the faculty-issued ML whitelist. Train or set the threshold using healthy/training data only. Report event recall, false alarms per normal run and detection delay; show where the method treats a new but valid regime as abnormal. Produce a event timeline with anomaly score, threshold and false-alarm examples.
5 · Embedded integration and safe response
The host may return only QUIET, NORMAL, BURST or DIAGNOSTIC telemetry PROFILE_ID, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a harmless short burst that should not permanently promote the network to a costly high-rate profile. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 16.02 — Anomaly-Triggered Burst Capture”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P16 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Anomaly-Triggered Burst Capture is a syllabus-scaled physical analogue of the need evidenced by ST01 · AUTOSAR End-to-End Protocol Specification: Increase noncritical telemetry before/during abnormal motor behaviour. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needSpecify end-to-end mechanisms for detecting loss, repetition, incorrect sequence, delay and corruption of communicated data.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Use counters, age/timeout, sequence and plausibility checks; demonstrate stale, duplicate and missing-data handling.
AUTOSAR compliance is not required; only the observable fault categories and validation discipline are adopted.
IR03 R · Distributed embedded reference architecture
Define node roles, typed interfaces, command/telemetry responsibilities, health behaviour and integration tests before implementation.
Students do not install F´ or implement RTOS-style architecture; they transfer its interface and verification discipline.
IR04 R · Telemetry/command reference implementation
Version message dictionaries, log command and acknowledgement histories and make telemetry replayable for diagnosis.
The hackathon uses a lightweight supplied Python gateway, not the F´ ground system itself.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationPublish an exact frame budget, traffic generator and protected safety-message class; otherwise QoS claims will not be comparable.
Variant 16.03
Bus-Load Risk Predictor
Engineering purpose: Connects network load to service quality.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception2 H753 boards1 laptop
Controller2 H753 boards + 1 laptop
SenseLM35-class temperature channel; LDR divider; 10 kΩ potentiometer for controll…
ActuateNo powered actuator is required for the core QoS problem; motion variants exp…
Fixturestandard two-node network fixture with sealed traffic-mix profiles
ProtectUSB board-power paths through the laptop/powered hub; protected transceiver s…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
2 × NUCLEO-H753ZI / MB1364E boards with onboard STLINK-V3E
2 × data-capable USB-A/USB-C-to-Micro-B cables
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
1 × powered USB data hub with at least three downstream ports
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
2 × full-size solderless breadboards, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser message-budget/latency scoring sheet and golden network trace
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Safety heartbeat and command traffic retain immutable periods; ML changes only whitelisted noncritical telemetry rates. Verify the complete EQ-16-03 manifest before data collection.
1 · Scenario and student challenge
Predict command-response latency from recent frame mix. In plain language, adapt CANFlow — Adaptive Telemetry Quality-of-Service Scheduler so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Connects network load to service quality.
2 · What to build or modify
Allocated hardware: 2 × H753 + H753-N + H753-S. Begin with two H753 boards with H753-N and H753-S process signals and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record process regime, frame ID/rate, inter-arrival/jitter, queue/drop counters, latency, event coverage and priority class. Treat one fixed-duration traffic epoch with a declared process and message profile as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Latency regression/risk classification. First implement the parent baseline—fixed-fast, fixed-slow or threshold-triggered schedule—and then compare two algorithms from the faculty-issued ML whitelist. Report MAE and RMSE on whole held-out runs, show predicted-versus-measured values, and inspect error by operating condition. If the target is converted to a safe/unsafe decision, also report missed-unsafe and unnecessary-conservative actions. Produce a predicted-versus-measured plot with residuals by operating condition.
5 · Embedded integration and safe response
The host may return only QUIET, NORMAL, BURST or DIAGNOSTIC telemetry PROFILE_ID, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a harmless short burst that should not permanently promote the network to a costly high-rate profile. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 16.03 — Bus-Load Risk Predictor”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P16 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Bus-Load Risk Predictor is a syllabus-scaled physical analogue of the need evidenced by ST01 · AUTOSAR End-to-End Protocol Specification: Predict command-response latency from recent frame mix. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needSpecify end-to-end mechanisms for detecting loss, repetition, incorrect sequence, delay and corruption of communicated data.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Use counters, age/timeout, sequence and plausibility checks; demonstrate stale, duplicate and missing-data handling.
AUTOSAR compliance is not required; only the observable fault categories and validation discipline are adopted.
IR03 R · Distributed embedded reference architecture
Define node roles, typed interfaces, command/telemetry responsibilities, health behaviour and integration tests before implementation.
Students do not install F´ or implement RTOS-style architecture; they transfer its interface and verification discipline.
IR04 R · Telemetry/command reference implementation
Version message dictionaries, log command and acknowledgement histories and make telemetry replayable for diagnosis.
The hackathon uses a lightweight supplied Python gateway, not the F´ ground system itself.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationPublish an exact frame budget, traffic generator and protected safety-message class; otherwise QoS claims will not be comparable.
Variant 16.04
Multi-Node Fairness Scheduler
Engineering purpose: Avoids one signal monopolising traffic.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception2 H753 boards1 laptop
Controller2 H753 boards + 1 laptop
SenseLM35-class temperature channel; LDR divider; 10 kΩ potentiometer for controll…
ActuateNo powered actuator is required for the core QoS problem; motion variants exp…
Fixturetwo-stream sensor panel; LM35 on Node A, LDR on Node B and separate stimulus…
ProtectUSB board-power paths through the laptop/powered hub; protected transceiver s…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
2 × NUCLEO-H753ZI / MB1364E boards with onboard STLINK-V3E
2 × data-capable USB-A/USB-C-to-Micro-B cables
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
1 × powered USB data hub with at least three downstream ports
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
2 × full-size solderless breadboards, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser message-budget/latency scoring sheet and golden network trace
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Safety heartbeat and command traffic retain immutable periods; ML changes only whitelisted noncritical telemetry rates. Verify the complete EQ-16-04 manifest before data collection.
1 · Scenario and student challenge
Allocate approved rate profiles across two sensor streams. In plain language, adapt CANFlow — Adaptive Telemetry Quality-of-Service Scheduler so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Avoids one signal monopolising traffic.
2 · What to build or modify
Allocated hardware: 2 × H753 + H753-N + H753-S. Begin with two H753 boards with H753-N and H753-S process signals and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record process regime, frame ID/rate, inter-arrival/jitter, queue/drop counters, latency, event coverage and priority class. Treat one fixed-duration traffic epoch with a declared process and message profile as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Regime classification plus rule-based fair assignment. First implement the parent baseline—fixed-fast, fixed-slow or threshold-triggered schedule—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only QUIET, NORMAL, BURST or DIAGNOSTIC telemetry PROFILE_ID, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a harmless short burst that should not permanently promote the network to a costly high-rate profile. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 16.04 — Multi-Node Fairness Scheduler”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P16 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Multi-Node Fairness Scheduler is a syllabus-scaled physical analogue of the need evidenced by ST01 · AUTOSAR End-to-End Protocol Specification: Allocate approved rate profiles across two sensor streams. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needSpecify end-to-end mechanisms for detecting loss, repetition, incorrect sequence, delay and corruption of communicated data.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Use counters, age/timeout, sequence and plausibility checks; demonstrate stale, duplicate and missing-data handling.
AUTOSAR compliance is not required; only the observable fault categories and validation discipline are adopted.
IR03 R · Distributed embedded reference architecture
Define node roles, typed interfaces, command/telemetry responsibilities, health behaviour and integration tests before implementation.
Students do not install F´ or implement RTOS-style architecture; they transfer its interface and verification discipline.
IR04 R · Telemetry/command reference implementation
Version message dictionaries, log command and acknowledgement histories and make telemetry replayable for diagnosis.
The hackathon uses a lightweight supplied Python gateway, not the F´ ground system itself.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationPublish an exact frame budget, traffic generator and protected safety-message class; otherwise QoS claims will not be comparable.
Variant 16.05
Priority-Preservation Auditor
Engineering purpose: Exercises CAN arbitration explicitly.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception2 H753 boards1 laptop
Controller2 H753 boards + 1 laptop
SenseLM35-class temperature channel; LDR divider; 10 kΩ potentiometer for controll…
ActuateNo powered actuator is required for the core QoS problem; motion variants exp…
Fixturestandard two-node network fixture with immutable high-priority heartbeat and…
ProtectUSB board-power paths through the laptop/powered hub; protected transceiver s…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
2 × NUCLEO-H753ZI / MB1364E boards with onboard STLINK-V3E
2 × data-capable USB-A/USB-C-to-Micro-B cables
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
1 × powered USB data hub with at least three downstream ports
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
2 × full-size solderless breadboards, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser message-budget/latency scoring sheet and golden network trace
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Safety heartbeat and command traffic retain immutable periods; ML changes only whitelisted noncritical telemetry rates. Verify the complete EQ-16-05 manifest before data collection.
1 · Scenario and student challenge
Stress low-priority traffic while verifying high-priority timing. In plain language, adapt CANFlow — Adaptive Telemetry Quality-of-Service Scheduler so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Exercises CAN arbitration explicitly.
2 · What to build or modify
Allocated hardware: 2 × H753 + H753-N + H753-S. Begin with two H753 boards with H753-N and H753-S process signals and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record process regime, frame ID/rate, inter-arrival/jitter, queue/drop counters, latency, event coverage and priority class. Treat one fixed-duration traffic epoch with a declared process and message profile as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Violation-risk prediction. First implement the parent baseline—fixed-fast, fixed-slow or threshold-triggered schedule—and then compare two algorithms from the faculty-issued ML whitelist. Report MAE and RMSE on whole held-out runs, show predicted-versus-measured values, and inspect error by operating condition. If the target is converted to a safe/unsafe decision, also report missed-unsafe and unnecessary-conservative actions. Produce a predicted-versus-measured plot with residuals by operating condition.
5 · Embedded integration and safe response
The host may return only QUIET, NORMAL, BURST or DIAGNOSTIC telemetry PROFILE_ID, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a harmless short burst that should not permanently promote the network to a costly high-rate profile. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 16.05 — Priority-Preservation Auditor”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P16 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Priority-Preservation Auditor is a syllabus-scaled physical analogue of the need evidenced by ST01 · AUTOSAR End-to-End Protocol Specification: Stress low-priority traffic while verifying high-priority timing. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needSpecify end-to-end mechanisms for detecting loss, repetition, incorrect sequence, delay and corruption of communicated data.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Use counters, age/timeout, sequence and plausibility checks; demonstrate stale, duplicate and missing-data handling.
AUTOSAR compliance is not required; only the observable fault categories and validation discipline are adopted.
IR03 R · Distributed embedded reference architecture
Define node roles, typed interfaces, command/telemetry responsibilities, health behaviour and integration tests before implementation.
Students do not install F´ or implement RTOS-style architecture; they transfer its interface and verification discipline.
IR04 R · Telemetry/command reference implementation
Version message dictionaries, log command and acknowledgement histories and make telemetry replayable for diagnosis.
The hackathon uses a lightweight supplied Python gateway, not the F´ ground system itself.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationPublish an exact frame budget, traffic generator and protected safety-message class; otherwise QoS claims will not be comparable.
Variant 16.06
Remote-Request Data Scheduler
Engineering purpose: Builds on request-driven telemetry while remaining correct for both Classical CAN and CAN-FD frame rules.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception2 H753 boards1 laptop
Controller2 H753 boards + 1 laptop
SenseLM35-class temperature channel; LDR divider; 10 kΩ potentiometer for controll…
ActuateNo powered actuator is required for the core QoS problem; motion variants exp…
Fixturestandard two-node network fixture; request/response test card; use CAN RTR on…
ProtectUSB board-power paths through the laptop/powered hub; protected transceiver s…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
2 × NUCLEO-H753ZI / MB1364E boards with onboard STLINK-V3E
2 × data-capable USB-A/USB-C-to-Micro-B cables
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
1 × powered USB data hub with at least three downstream ports
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
2 × full-size solderless breadboards, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser message-budget/latency scoring sheet and golden network trace
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Safety heartbeat and command traffic retain immutable periods; ML changes only whitelisted noncritical telemetry rates. Verify the complete EQ-16-06 manifest before data collection.
1 · Scenario and student challenge
Use Classical CAN RTR only if it was taught and enabled; otherwise use an explicit application-level FDCAN request/response frame to obtain occasional detailed data. In plain language, adapt CANFlow — Adaptive Telemetry Quality-of-Service Scheduler so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Builds on request-driven telemetry while remaining correct for both Classical CAN and CAN-FD frame rules.
2 · What to build or modify
Allocated hardware: 2 × H753 + H753-N + H753-S. Begin with two H753 boards with H753-N and H753-S process signals and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record process regime, frame ID/rate, inter-arrival/jitter, queue/drop counters, latency, event coverage and priority class. Treat one fixed-duration traffic epoch with a declared process and message profile as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Predict when a detailed-data request is beneficial. First implement the parent baseline—fixed-fast, fixed-slow or threshold-triggered schedule—and then compare two algorithms from the faculty-issued ML whitelist. Report MAE and RMSE on whole held-out runs, show predicted-versus-measured values, and inspect error by operating condition. If the target is converted to a safe/unsafe decision, also report missed-unsafe and unnecessary-conservative actions. Produce a predicted-versus-measured plot with residuals by operating condition.
5 · Embedded integration and safe response
The host may return only QUIET, NORMAL, BURST or DIAGNOSTIC telemetry PROFILE_ID, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a harmless short burst that should not permanently promote the network to a costly high-rate profile. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 16.06 — Remote-Request Data Scheduler”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P16 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Remote-Request Data Scheduler is a syllabus-scaled physical analogue of the need evidenced by ST01 · AUTOSAR End-to-End Protocol Specification: Use Classical CAN RTR only if it was taught and enabled; otherwise use an explicit application-level FDCAN request/response frame to obtain occasional detailed data. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needSpecify end-to-end mechanisms for detecting loss, repetition, incorrect sequence, delay and corruption of communicated data.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Use counters, age/timeout, sequence and plausibility checks; demonstrate stale, duplicate and missing-data handling.
AUTOSAR compliance is not required; only the observable fault categories and validation discipline are adopted.
IR03 R · Distributed embedded reference architecture
Define node roles, typed interfaces, command/telemetry responsibilities, health behaviour and integration tests before implementation.
Students do not install F´ or implement RTOS-style architecture; they transfer its interface and verification discipline.
IR04 R · Telemetry/command reference implementation
Version message dictionaries, log command and acknowledgement histories and make telemetry replayable for diagnosis.
The hackathon uses a lightweight supplied Python gateway, not the F´ ground system itself.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationPublish an exact frame budget, traffic generator and protected safety-message class; otherwise QoS claims will not be comparable.
Variant 16.07
Thermal Trend Scheduler
Engineering purpose: Produces early-warning evidence with fewer normal messages.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception2 H753 boards1 laptop
Controller2 H753 boards + 1 laptop
SenseLM35-class temperature channel; LDR divider; 10 kΩ potentiometer for controll…
ActuateNo powered actuator is required for the core QoS problem; motion variants exp…
Fixturetwo-node thermal trend panel; LM35 sensor, safe warm/cool mass and fixed slop…
ProtectUSB board-power paths through the laptop/powered hub; protected transceiver s…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
2 × NUCLEO-H753ZI / MB1364E boards with onboard STLINK-V3E
2 × data-capable USB-A/USB-C-to-Micro-B cables
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
1 × powered USB data hub with at least three downstream ports
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
2 × full-size solderless breadboards, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser message-budget/latency scoring sheet and golden network trace
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Safety heartbeat and command traffic retain immutable periods; ML changes only whitelisted noncritical telemetry rates. Verify the complete EQ-16-07 manifest before data collection.
1 · Scenario and student challenge
Increase temperature telemetry when slope/risk rises. In plain language, adapt CANFlow — Adaptive Telemetry Quality-of-Service Scheduler so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Produces early-warning evidence with fewer normal messages.
2 · What to build or modify
Allocated hardware: 2 × H753 + H753-N + H753-S. Begin with two H753 boards with H753-N and H753-S process signals and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record process regime, frame ID/rate, inter-arrival/jitter, queue/drop counters, latency, event coverage and priority class. Treat one fixed-duration traffic epoch with a declared process and message profile as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Risk classification. First implement the parent baseline—fixed-fast, fixed-slow or threshold-triggered schedule—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only QUIET, NORMAL, BURST or DIAGNOSTIC telemetry PROFILE_ID, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a harmless short burst that should not permanently promote the network to a costly high-rate profile. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 16.07 — Thermal Trend Scheduler”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P16 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Thermal Trend Scheduler is a syllabus-scaled physical analogue of the need evidenced by ST01 · AUTOSAR End-to-End Protocol Specification: Increase temperature telemetry when slope/risk rises. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needSpecify end-to-end mechanisms for detecting loss, repetition, incorrect sequence, delay and corruption of communicated data.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Use counters, age/timeout, sequence and plausibility checks; demonstrate stale, duplicate and missing-data handling.
AUTOSAR compliance is not required; only the observable fault categories and validation discipline are adopted.
IR03 R · Distributed embedded reference architecture
Define node roles, typed interfaces, command/telemetry responsibilities, health behaviour and integration tests before implementation.
Students do not install F´ or implement RTOS-style architecture; they transfer its interface and verification discipline.
IR04 R · Telemetry/command reference implementation
Version message dictionaries, log command and acknowledgement histories and make telemetry replayable for diagnosis.
The hackathon uses a lightweight supplied Python gateway, not the F´ ground system itself.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationPublish an exact frame budget, traffic generator and protected safety-message class; otherwise QoS claims will not be comparable.
Variant 16.08
Motion-Phase Scheduler
Engineering purpose: Creates a data-efficient servo trace.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception2 H753 boards1 laptop
Controller2 H753 boards + 1 laptop
Senseencoder; 0–3.3 V current channel; LM35 channel
Actuategeared DC motor and 3.3-V H-bridge
Fixturetwo-node motor phase rig; guarded motor/encoder/current fixture and labelled…
ProtectUSB board-power paths; fused motor supply; physical E-stop
System block
Complete quantity and equipment per team
Why it is required
Controller & host
2 × NUCLEO-H753ZI / MB1364E boards with onboard STLINK-V3E
2 × data-capable USB-A/USB-C-to-Micro-B cables
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
1 × powered USB data hub with at least three downstream ports
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
2 × full-size solderless breadboards, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser message-budget/latency scoring sheet and golden network trace
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Safety heartbeat and command traffic retain immutable periods; ML changes only whitelisted noncritical telemetry rates. Verify the complete EQ-16-08 manifest before data collection.
1 · Scenario and student challenge
Use high rate during startup/transient and low rate at steady state. In plain language, adapt CANFlow — Adaptive Telemetry Quality-of-Service Scheduler so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Creates a data-efficient servo trace.
2 · What to build or modify
Allocated hardware: 2 × H753 + H753-N + H753-S + H753-M process telemetry. Begin with two H753 boards with H753-N and H753-S process signals and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record process regime, frame ID/rate, inter-arrival/jitter, queue/drop counters, latency, event coverage and priority class. Treat one fixed-duration traffic epoch with a declared process and message profile as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Motion-phase classification. First implement the parent baseline—fixed-fast, fixed-slow or threshold-triggered schedule—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only QUIET, NORMAL, BURST or DIAGNOSTIC telemetry PROFILE_ID, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a harmless short burst that should not permanently promote the network to a costly high-rate profile. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 16.08 — Motion-Phase Scheduler”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P16 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Motion-Phase Scheduler is a syllabus-scaled physical analogue of the need evidenced by ST01 · AUTOSAR End-to-End Protocol Specification: Use high rate during startup/transient and low rate at steady state. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needSpecify end-to-end mechanisms for detecting loss, repetition, incorrect sequence, delay and corruption of communicated data.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Use counters, age/timeout, sequence and plausibility checks; demonstrate stale, duplicate and missing-data handling.
AUTOSAR compliance is not required; only the observable fault categories and validation discipline are adopted.
IR03 R · Distributed embedded reference architecture
Define node roles, typed interfaces, command/telemetry responsibilities, health behaviour and integration tests before implementation.
Students do not install F´ or implement RTOS-style architecture; they transfer its interface and verification discipline.
IR04 R · Telemetry/command reference implementation
Version message dictionaries, log command and acknowledgement histories and make telemetry replayable for diagnosis.
The hackathon uses a lightweight supplied Python gateway, not the F´ ground system itself.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationPublish an exact frame budget, traffic generator and protected safety-message class; otherwise QoS claims will not be comparable.
Variant 16.09
Fault-Diagnostic Profile Switcher
Engineering purpose: Links diagnosis and observability.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception2 H753 boards1 laptop
Controller2 H753 boards + 1 laptop
Senseencoder; 0–3.3 V current channel; LM35 channel
Actuategeared DC motor and 3.3-V H-bridge
Fixturetwo-node motor diagnostic rig; guarded motor fixture and sealed richer-diagno…
ProtectUSB board-power paths; fused motor supply; physical E-stop
System block
Complete quantity and equipment per team
Why it is required
Controller & host
2 × NUCLEO-H753ZI / MB1364E boards with onboard STLINK-V3E
2 × data-capable USB-A/USB-C-to-Micro-B cables
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
1 × powered USB data hub with at least three downstream ports
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
2 × full-size solderless breadboards, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser message-budget/latency scoring sheet and golden network trace
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Safety heartbeat and command traffic retain immutable periods; ML changes only whitelisted noncritical telemetry rates. Verify the complete EQ-16-09 manifest before data collection.
1 · Scenario and student challenge
On a detected fault, transmit a richer approved diagnostic frame set. In plain language, adapt CANFlow — Adaptive Telemetry Quality-of-Service Scheduler so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Links diagnosis and observability.
2 · What to build or modify
Allocated hardware: 2 × H753 + H753-N + H753-S + H753-M process telemetry. Begin with two H753 boards with H753-N and H753-S process signals and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record process regime, frame ID/rate, inter-arrival/jitter, queue/drop counters, latency, event coverage and priority class. Treat one fixed-duration traffic epoch with a declared process and message profile as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Fault class to profile mapping. First implement the parent baseline—fixed-fast, fixed-slow or threshold-triggered schedule—and then compare two algorithms from the faculty-issued ML whitelist. Report correct/feasible selection rate, constraint violations and improvement over the fixed policy. A choice is wrong if it violates a declared current, timing, thermal or control-quality bound even when it is fast. Produce a candidate-outcome/constraint table showing why the selected option is feasible.
5 · Embedded integration and safe response
The host may return only QUIET, NORMAL, BURST or DIAGNOSTIC telemetry PROFILE_ID, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a harmless short burst that should not permanently promote the network to a costly high-rate profile. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 16.09 — Fault-Diagnostic Profile Switcher”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P16 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Fault-Diagnostic Profile Switcher is a syllabus-scaled physical analogue of the need evidenced by ST01 · AUTOSAR End-to-End Protocol Specification: On a detected fault, transmit a richer approved diagnostic frame set. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needSpecify end-to-end mechanisms for detecting loss, repetition, incorrect sequence, delay and corruption of communicated data.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Use counters, age/timeout, sequence and plausibility checks; demonstrate stale, duplicate and missing-data handling.
AUTOSAR compliance is not required; only the observable fault categories and validation discipline are adopted.
IR03 R · Distributed embedded reference architecture
Define node roles, typed interfaces, command/telemetry responsibilities, health behaviour and integration tests before implementation.
Students do not install F´ or implement RTOS-style architecture; they transfer its interface and verification discipline.
IR04 R · Telemetry/command reference implementation
Version message dictionaries, log command and acknowledgement histories and make telemetry replayable for diagnosis.
The hackathon uses a lightweight supplied Python gateway, not the F´ ground system itself.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationPublish an exact frame budget, traffic generator and protected safety-message class; otherwise QoS claims will not be comparable.
Variant 16.10
Dataset-Capture Optimiser
Engineering purpose: Makes telemetry policy part of dataset engineering.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception2 H753 boards1 laptop
Controller2 H753 boards + 1 laptop
SenseLM35-class temperature channel; LDR divider; 10 kΩ potentiometer for controll…
ActuateNo powered actuator is required for the core QoS problem; motion variants exp…
Fixturetwo-node multi-regime sensor panel; LDR, LM35, potentiometer and an organiser…
ProtectUSB board-power paths through the laptop/powered hub; protected transceiver s…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
2 × NUCLEO-H753ZI / MB1364E boards with onboard STLINK-V3E
2 × data-capable USB-A/USB-C-to-Micro-B cables
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
1 × powered USB data hub with at least three downstream ports
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
2 × full-size solderless breadboards, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser message-budget/latency scoring sheet and golden network trace
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Safety heartbeat and command traffic retain immutable periods; ML changes only whitelisted noncritical telemetry rates. Verify the complete EQ-16-10 manifest before data collection.
1 · Scenario and student challenge
Optimise rates to capture representative ML data within a message budget. In plain language, adapt CANFlow — Adaptive Telemetry Quality-of-Service Scheduler so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Makes telemetry policy part of dataset engineering.
2 · What to build or modify
Allocated hardware: 2 × H753 + H753-N + H753-S. Begin with two H753 boards with H753-N and H753-S process signals and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record process regime, frame ID/rate, inter-arrival/jitter, queue/drop counters, latency, event coverage and priority class. Treat one fixed-duration traffic epoch with a declared process and message profile as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Regime classification and coverage analysis. First implement the parent baseline—fixed-fast, fixed-slow or threshold-triggered schedule—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only QUIET, NORMAL, BURST or DIAGNOSTIC telemetry PROFILE_ID, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a harmless short burst that should not permanently promote the network to a costly high-rate profile. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 16.10 — Dataset-Capture Optimiser”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P16 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Dataset-Capture Optimiser is a syllabus-scaled physical analogue of the need evidenced by ST01 · AUTOSAR End-to-End Protocol Specification: Optimise rates to capture representative ML data within a message budget. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needSpecify end-to-end mechanisms for detecting loss, repetition, incorrect sequence, delay and corruption of communicated data.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Use counters, age/timeout, sequence and plausibility checks; demonstrate stale, duplicate and missing-data handling.
AUTOSAR compliance is not required; only the observable fault categories and validation discipline are adopted.
IR03 R · Distributed embedded reference architecture
Define node roles, typed interfaces, command/telemetry responsibilities, health behaviour and integration tests before implementation.
Students do not install F´ or implement RTOS-style architecture; they transfer its interface and verification discipline.
IR04 R · Telemetry/command reference implementation
Version message dictionaries, log command and acknowledgement histories and make telemetry replayable for diagnosis.
The hackathon uses a lightweight supplied Python gateway, not the F´ ground system itself.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationPublish an exact frame budget, traffic generator and protected safety-message class; otherwise QoS claims will not be comparable.
Problem 17 · 10 variants · CAN, telemetry and distributed embedded intelligence
FaultMap — End-to-End Fault Attribution Across Sensor, Actuator, Process and Network
Assigned Faculty Master pair for P17: one nominated ESD Faculty Master and one nominated ML Faculty Master shall jointly master this parent problem and variants V1-V10. The ESD Master owns hardware, firmware, control, communication and safety verification; the ML Master owns data, baselines, models, validation and bounded decision-policy verification. Together they teach and guide ten teams (one for each variant and up to 40 students), supervise five teams in Wave A and five in Wave B, witness integration and sign every final evaluation.
The problem
A failed product outcome can originate in four layers: the sensor, the actuator, the physical process, or the communication path. Individual thresholds rarely identify the source. The goal is to build a small but complete distributed system and an evidence-based diagnostic engine that attributes the fault layer, not just flags that something is wrong.
Smart embedded product to build
Build a two-node NUCLEO-H753ZI sensing-to-actuation chain over physical FDCAN. Node S reports raw signal plus local quality evidence; Node A reports requested/applied mode, physical response and local protection; the bus trace provides command age, acknowledgement and heartbeat evidence. The host attributes a failed outcome to ROOT_SENSOR, ROOT_ACTUATOR, ROOT_PROCESS, ROOT_NETWORK or UNRESOLVED and explains the evidence variables, then recommends a fixed safe diagnostic step rather than a control value.
NUCLEO-H753ZI realization and issued pack
two NUCLEO-H753ZI / MB1364E boards with H753-N plus the S/A/M module required by the variant
sensor node emits raw measurement, local range/plausibility flag and sequence/age
actuator node emits requested/applied profile, current/position response and local interlock flags
physical FDCAN command/acknowledgement/heartbeat trace identifies the communication layer
safe software/fixture injections isolate sensor, actuator, process and network causes
host returns root-cause class, confidence and fixed diagnostic action; unknown maps to UNRESOLVED_SAFE
USART3 VCP/gateway records an end-to-end evidence timeline
Intelligence to incorporate
Use command-response residuals, missing/stale frames, physical plausibility, current-versus-motion, sensor variability and local flags. Train multiclass logistic/tree models or a hierarchical classifier. Compare with a hand-built diagnostic decision tree. Evaluate root-cause accuracy, critical-fault recall, time-to-attribution and confusion between layers.
Canonical family command contract: every parent brief, variant, host message and MCU acknowledgement for P17 shall use these exact identifiers. A variant may use only the applicable subset; it shall not introduce a synonym.
Core problem equipment · EQ-17-CORE
Complete equipment required for one core-problem team
Standalone family BOM. This list supports the parent problem itself. An allocated variant uses its own complete table later in this card. A component mentioned again in the fixture description is the same mounted unit, not another copy.
4 students; 3 by approved exception2 H753 boards1 team laptopquantities per team
Controller2 H753 boards + 1 laptop
SenseLM35-class temperature channels for the default diagnostic cell; conditioned…
Actuatelow-voltage fan through a protected 3.3-V-compatible MOSFET/relay channel for…
Fixturedefault thermal/fan diagnostic cell with independently injectable SENSOR, ACT…
Protectcurrent-limited actuator supply with fuse and physical isolation switch; USB…
System block
Complete quantity and equipment per team
Purpose / acceptance condition
Controller & host
2 × NUCLEO-H753ZI / MB1364E boards with onboard STLINK-V3E
2 × data-capable USB-A/USB-C-to-Micro-B cables
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
1 × powered USB data hub with at least three downstream ports
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
2 × full-size solderless breadboards, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser root-cause truth table and at least one held-out UNKNOWN fault mechanism
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Release-to-team condition: For variants 17.07–17.10 the default process is frozen to this thermal/fan cell unless an official BOM addendum replaces it. The organiser signs the electrical, mechanical and communication acceptance checklist before H0:00.
Not duplicated inside the kit: supervised rework tools and the oscilloscope/logic-analyser station are shared at the ratio stated above. Everything else in this table is issued to, reserved for, or digitally assigned to this team.
Controlled self-learning extension
Recommended Implement a two-stage diagnostic model—fault layer, then subtype—and an UNRESOLVED abstention threshold. Compare it with one flat classifier on the identical held-out injections.
System safety and non-negotiable boundary
Firmware interlocks act immediately; the diagnostic result only guides bounded next steps. Fault injection is safe and documented. Unknown/low-confidence cases must return UNRESOLVED_SAFE rather than fabricate certainty.
Student interpretation — what this challenge really asks
When a product fails, the symptom may originate in the sensor, actuator, physical process or network. Students build an evidence chain that attributes the layer and admits ‘unresolved’ when the traces do not justify a confident cause.
Independent data unitone end-to-end event window containing one controlled root cause.
Closest misleading casetwo different root causes that create the same high-level process symptom.
Definition of successStudents must attribute a hidden single-root fault from synchronized evidence or safely declare it unresolved.
Visual system blueprint
Physical processEnd-to-end distributed fault chainGenerate labelled, safe and repeatable conditions.
Observeraw measurement and quality, command/requested/applied mode, physical responsePreserve units, timestamps, run identity and signal quality.
H753 responsibilityControl and protectpreserve local sensor/actuator checks, event chronology and safe software/fixture fault injection.
Host intelligenceLearn the distinctionclassify root cause as SENSOR, ACTUATOR, PROCESS, NETWORK or UNRESOLVED.
Bounded outcomeROOT_SENSOR · ROOT_ACTUATOR · ROOT_PROCESS · ROOT_NETWORK · UNRESOLVED_SAFEMCU validates, acknowledges and may refuse the request.
Recommended build journey
Make the process repeatableAssemble two H753 boards with H753-N plus the variant’s sensing or actuation module; define reference and target conditions before collecting data.
Prove deterministic firmwarePreserve local sensor/actuator checks, event chronology and safe software/fixture fault injection. Demonstrate every hard limit before connecting ML.
Build trustworthy trialsTreat one end-to-end event window containing one controlled root cause as independent; calibrate, label and split by run/session.
Beat a real baselineCompare hand-built hierarchical diagnostic decision tree with two syllabus-approved classical models.
Close and challenge the loopReturn only the applicable subset of ROOT_SENSOR · ROOT_ACTUATOR · ROOT_PROCESS · ROOT_NETWORK · UNRESOLVED_SAFE; test the target, nearest confuser, stale command and host loss.
Definition of done
Firmware controls safely before, during and after host connection.
Portfolio shows causal event timeline and root-cause confusion matrix and one honest failure case.
Problem-specific evidence at the common reviews
R1 · Design
Define four root layers, injection mechanism, expected evidence, safe diagnostic actions and unknown policy.
R2 · Embedded
Demonstrate complete command-response trace with local flags and at least one fault per layer.
R3 · Data
Submit event-labelled traces, rule diagnostic tree and group split by injection run.
R4 · ML
Show root-cause classifier, confusion matrix, evidence explanation and low-confidence handling.
R5 · Integration
Integrate diagnostic actions and pass hidden cross-layer faults plus host/node loss.
Final
Attribute blind faults and defend the diagnosis from trace evidence, including one unresolved case.
Portfolio/Kaggle outcome
Portfolio: fault-injection matrix, end-to-end trace schema, rule tree, ML root-cause model, confidence/unknown policy, event timeline and demonstration video. Kaggle data can become a strong multi-layer fault-diagnosis dataset.
Industry alignment and validation basis
FaultMap: external references and required evidence
The listed sources establish relevance, test discipline and implementation precedent. They do not modify the common syllabus boundary, safety rules or 100-mark assessment rubric.
Family implementation profile
Variant availability: 10 standard assignment(s); 0 organiser-supported assignment(s).
Public evidence: reproducible firmware, protocol, dataset, notebook/model, test report and demonstration video.
What the external benchmark confirms
The problem has a recognisable industrial or challenge analogue, a measurable data task, a defensible embedded implementation and a safe operational decision. Every one of its ten variants is mapped separately below.
Condition before team allocation
Issue a fault-switch matrix and provenance log so sensor, actuator, process and network faults are reproducible and mutually distinguishable.
Combine process state, velocity, torque, current, voltage and timing context for conveyor anomaly detection, diagnosis and productivity analysis.
Condition inference on process phase; preserve physical context; test root-cause discrimination and subtask timing rather than a context-free threshold.
Frame cyber-physical systems as integrations of logical, physical and human components with concerns including trustworthiness and interoperability.
Evaluate the complete sense–decide–act system, its interfaces and failure behaviour—not a disconnected model or dashboard.
Open the 10 fully elaborated student variant briefs
Choose only the variant allocated to your team. Read it together with the parent problem above: the card expands the experimental delta, while every hardware, safety, integration and review requirement of the family remains active.
Variant 17.01
Thermal Cell Fault Mapper
Engineering purpose: Creates a highly observable, low-voltage example spanning sensor, actuator, process and two distinct communication paths.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception2 H753 boards1 laptop
Controller2 H753 boards + 1 laptop
SenseLM35-class temperature channels for the default diagnostic cell; conditioned…
Actuatelow-voltage fan through a protected 3.3-V-compatible MOSFET/relay channel for…
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser root-cause truth table and at least one held-out UNKNOWN fault mechanism
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: For variants 17.07–17.10 the default process is frozen to this thermal/fan cell unless an official BOM addendum replaces it. Verify the complete EQ-17-01 manifest before data collection.
1 · Scenario and student challenge
Separate LM35 fault, fan/relay fault, heat disturbance, physical FDCAN loss and host-gateway loss. In plain language, adapt FaultMap — End-to-End Fault Attribution Across Sensor, Actuator, Process and Network so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Creates a highly observable, low-voltage example spanning sensor, actuator, process and two distinct communication paths.
2 · What to build or modify
Allocated hardware: 2 × H753 + H753-N + H753-S + H753-A thermal/relay cell. Begin with two H753 boards with H753-N plus the variant’s sensing or actuation module and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record raw measurement and quality, command/requested/applied mode, physical response, current/position, timestamps, sequence, heartbeat and local fault bits. Treat one end-to-end event window containing one controlled root cause as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Five-class or hierarchical root-cause classification. First implement the parent baseline—hand-built hierarchical diagnostic decision tree—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only fixed diagnostic action, RECHECK or UNRESOLVED_SAFE, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with two different root causes that create the same high-level process symptom. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 17.01 — Thermal Cell Fault Mapper”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P17 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Thermal Cell Fault Mapper is a syllabus-scaled physical analogue of the need evidenced by BM03 · Diagnostic Approach for Electro-Mechanical Actuators in Aerospace Systems: Separate LM35 fault, fan/relay fault, heat disturbance, physical FDCAN loss and host-gateway loss. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needUse condition indicators to detect, identify and isolate actuator fault modes while distinguishing sensor faults from component failures.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Condition inference on process phase; preserve physical context; test root-cause discrimination and subtask timing rather than a context-free threshold.
The H753 cell uses a smaller signal set and safe injected resistance while retaining the context-sensitive evaluation idea.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationIssue a fault-switch matrix and provenance log so sensor, actuator, process and network faults are reproducible and mutually distinguishable.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception2 H753 boards1 laptop
Controller2 H753 boards + 1 laptop
Senseencoder; 0–3.3 V current channel; LM35 channel; command/load proxy
Actuategeared DC motor and 3.3-V H-bridge
Fixturetwo-node motor fault-attribution cell; motor/encoder/H-bridge/current channel…
ProtectUSB board-power paths; fused current-limited motor supply; physical E-stop
System block
Complete quantity and equipment per team
Why it is required
Controller & host
2 × NUCLEO-H753ZI / MB1364E boards with onboard STLINK-V3E
2 × data-capable USB-A/USB-C-to-Micro-B cables
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
1 × powered USB data hub with at least three downstream ports
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
2 × full-size solderless breadboards, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser root-cause truth table and at least one held-out UNKNOWN fault mechanism
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: For variants 17.07–17.10 the default process is frozen to this thermal/fan cell unless an official BOM addendum replaces it. Verify the complete EQ-17-02 manifest before data collection.
1 · Scenario and student challenge
Separate encoder/current sensor, driver/motor, mechanical load and network faults. In plain language, adapt FaultMap — End-to-End Fault Attribution Across Sensor, Actuator, Process and Network so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Strong embedded diagnostic portfolio.
2 · What to build or modify
Allocated hardware: 2 × H753 + H753-N + H753-M motor/gate cell. Begin with two H753 boards with H753-N plus the variant’s sensing or actuation module and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record raw measurement and quality, command/requested/applied mode, physical response, current/position, timestamps, sequence, heartbeat and local fault bits. Treat one end-to-end event window containing one controlled root cause as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Hierarchical classification. First implement the parent baseline—hand-built hierarchical diagnostic decision tree—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only fixed diagnostic action, RECHECK or UNRESOLVED_SAFE, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with two different root causes that create the same high-level process symptom. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 17.02 — Motor Cell Fault Mapper”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P17 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Motor Cell Fault Mapper is a syllabus-scaled physical analogue of the need evidenced by BM03 · Diagnostic Approach for Electro-Mechanical Actuators in Aerospace Systems: Separate encoder/current sensor, driver/motor, mechanical load and network faults. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needUse condition indicators to detect, identify and isolate actuator fault modes while distinguishing sensor faults from component failures.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Condition inference on process phase; preserve physical context; test root-cause discrimination and subtask timing rather than a context-free threshold.
The H753 cell uses a smaller signal set and safe injected resistance while retaining the context-sensitive evaluation idea.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationIssue a fault-switch matrix and provenance log so sensor, actuator, process and network faults are reproducible and mutually distinguishable.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception2 H753 boards1 laptop
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser root-cause truth table and at least one held-out UNKNOWN fault mechanism
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: For variants 17.07–17.10 the default process is frozen to this thermal/fan cell unless an official BOM addendum replaces it. Verify the complete EQ-17-03 manifest before data collection.
1 · Scenario and student challenge
Separate LDR fault, servo fault, moving light obstruction and command-link fault. In plain language, adapt FaultMap — End-to-End Fault Attribution Across Sensor, Actuator, Process and Network so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Uses causal command-response evidence.
2 · What to build or modify
Allocated hardware: 2 × H753 + H753-N + H753-S optical path + servo actuator. Begin with two H753 boards with H753-N plus the variant’s sensing or actuation module and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record raw measurement and quality, command/requested/applied mode, physical response, current/position, timestamps, sequence, heartbeat and local fault bits. Treat one end-to-end event window containing one controlled root cause as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Multiclass classification. First implement the parent baseline—hand-built hierarchical diagnostic decision tree—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only fixed diagnostic action, RECHECK or UNRESOLVED_SAFE, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with two different root causes that create the same high-level process symptom. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 17.03 — Light-Positioning Fault Mapper”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P17 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Light-Positioning Fault Mapper is a syllabus-scaled physical analogue of the need evidenced by BM03 · Diagnostic Approach for Electro-Mechanical Actuators in Aerospace Systems: Separate LDR fault, servo fault, moving light obstruction and command-link fault. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needUse condition indicators to detect, identify and isolate actuator fault modes while distinguishing sensor faults from component failures.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Condition inference on process phase; preserve physical context; test root-cause discrimination and subtask timing rather than a context-free threshold.
The H753 cell uses a smaller signal set and safe injected resistance while retaining the context-sensitive evaluation idea.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationIssue a fault-switch matrix and provenance log so sensor, actuator, process and network faults are reproducible and mutually distinguishable.
Variant 17.04
Sorting Cell Fault Mapper
Engineering purpose: Connects quality and equipment diagnosis.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception2 H753 boards1 laptop
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser root-cause truth table and at least one held-out UNKNOWN fault mechanism
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: For variants 17.07–17.10 the default process is frozen to this thermal/fan cell unless an official BOM addendum replaces it. Verify the complete EQ-17-04 manifest before data collection.
1 · Scenario and student challenge
Separate optical sensor, diverter actuator, unknown specimen and network faults. In plain language, adapt FaultMap — End-to-End Fault Attribution Across Sensor, Actuator, Process and Network so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Connects quality and equipment diagnosis.
2 · What to build or modify
Allocated hardware: 2 × H753 + H753-N + H753-S optical path + servo actuator. Begin with two H753 boards with H753-N plus the variant’s sensing or actuation module and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record raw measurement and quality, command/requested/applied mode, physical response, current/position, timestamps, sequence, heartbeat and local fault bits. Treat one end-to-end event window containing one controlled root cause as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Root-cause plus reject policy. First implement the parent baseline—hand-built hierarchical diagnostic decision tree—and then compare two algorithms from the faculty-issued ML whitelist. Report correct/feasible selection rate, constraint violations and improvement over the fixed policy. A choice is wrong if it violates a declared current, timing, thermal or control-quality bound even when it is fast. Produce a candidate-outcome/constraint table showing why the selected option is feasible.
5 · Embedded integration and safe response
The host may return only fixed diagnostic action, RECHECK or UNRESOLVED_SAFE, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with two different root causes that create the same high-level process symptom. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 17.04 — Sorting Cell Fault Mapper”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P17 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Sorting Cell Fault Mapper is a syllabus-scaled physical analogue of the need evidenced by BM03 · Diagnostic Approach for Electro-Mechanical Actuators in Aerospace Systems: Separate optical sensor, diverter actuator, unknown specimen and network faults. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needUse condition indicators to detect, identify and isolate actuator fault modes while distinguishing sensor faults from component failures.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Condition inference on process phase; preserve physical context; test root-cause discrimination and subtask timing rather than a context-free threshold.
The H753 cell uses a smaller signal set and safe injected resistance while retaining the context-sensitive evaluation idea.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationIssue a fault-switch matrix and provenance log so sensor, actuator, process and network faults are reproducible and mutually distinguishable.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception2 H753 boards1 laptop
Controller2 H753 boards + 1 laptop
Senseencoder/position channel; current channel; end switches
Actuategeared DC motor and 3.3-V H-bridge
Fixturetwo-node low-force gate fault cell; motor/encoder/current gate, end switches,…
ProtectUSB board-power paths; fused motor supply; physical E-stop
System block
Complete quantity and equipment per team
Why it is required
Controller & host
2 × NUCLEO-H753ZI / MB1364E boards with onboard STLINK-V3E
2 × data-capable USB-A/USB-C-to-Micro-B cables
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
1 × powered USB data hub with at least three downstream ports
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
2 × full-size solderless breadboards, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser root-cause truth table and at least one held-out UNKNOWN fault mechanism
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: For variants 17.07–17.10 the default process is frozen to this thermal/fan cell unless an official BOM addendum replaces it. Verify the complete EQ-17-05 manifest before data collection.
1 · Scenario and student challenge
Separate position/current sensor, gate actuator, obstruction and stale command. In plain language, adapt FaultMap — End-to-End Fault Attribution Across Sensor, Actuator, Process and Network so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Safety-critical context.
2 · What to build or modify
Allocated hardware: 2 × H753 + H753-N + H753-M motor/gate cell. Begin with two H753 boards with H753-N plus the variant’s sensing or actuation module and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record raw measurement and quality, command/requested/applied mode, physical response, current/position, timestamps, sequence, heartbeat and local fault bits. Treat one end-to-end event window containing one controlled root cause as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Cost-sensitive multiclass model. First implement the parent baseline—hand-built hierarchical diagnostic decision tree—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only fixed diagnostic action, RECHECK or UNRESOLVED_SAFE, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with two different root causes that create the same high-level process symptom. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 17.05 — Gate Cell Fault Mapper”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P17 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Gate Cell Fault Mapper is a syllabus-scaled physical analogue of the need evidenced by BM03 · Diagnostic Approach for Electro-Mechanical Actuators in Aerospace Systems: Separate position/current sensor, gate actuator, obstruction and stale command. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needUse condition indicators to detect, identify and isolate actuator fault modes while distinguishing sensor faults from component failures.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Condition inference on process phase; preserve physical context; test root-cause discrimination and subtask timing rather than a context-free threshold.
The H753 cell uses a smaller signal set and safe injected resistance while retaining the context-sensitive evaluation idea.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationIssue a fault-switch matrix and provenance log so sensor, actuator, process and network faults are reproducible and mutually distinguishable.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception2 H753 boards1 laptop
Controller2 H753 boards + 1 laptop
SenseLM35-class temperature channels for the default diagnostic cell; conditioned…
Actuatelow-voltage fan through a protected 3.3-V-compatible MOSFET/relay channel for…
Fixturetwo-node relay-load fault cell; protected driver, fan/lamp, current plus phys…
Protectcurrent-limited actuator supply with fuse and physical isolation switch; USB…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
2 × NUCLEO-H753ZI / MB1364E boards with onboard STLINK-V3E
2 × data-capable USB-A/USB-C-to-Micro-B cables
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
1 × powered USB data hub with at least three downstream ports
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
2 × full-size solderless breadboards, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser root-cause truth table and at least one held-out UNKNOWN fault mechanism
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: For variants 17.07–17.10 the default process is frozen to this thermal/fan cell unless an official BOM addendum replaces it. Verify the complete EQ-17-06 manifest before data collection.
1 · Scenario and student challenge
Separate response sensor, relay/load, external load condition and communication. In plain language, adapt FaultMap — End-to-End Fault Attribution Across Sensor, Actuator, Process and Network so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Clear command-versus-outcome chain.
2 · What to build or modify
Allocated hardware: 2 × H753 + H753-N + H753-S + H753-A thermal/relay cell. Begin with two H753 boards with H753-N plus the variant’s sensing or actuation module and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record raw measurement and quality, command/requested/applied mode, physical response, current/position, timestamps, sequence, heartbeat and local fault bits. Treat one end-to-end event window containing one controlled root cause as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Diagnostic classification. First implement the parent baseline—hand-built hierarchical diagnostic decision tree—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only fixed diagnostic action, RECHECK or UNRESOLVED_SAFE, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with two different root causes that create the same high-level process symptom. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 17.06 — Relay Load Fault Mapper”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P17 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Relay Load Fault Mapper is a syllabus-scaled physical analogue of the need evidenced by BM03 · Diagnostic Approach for Electro-Mechanical Actuators in Aerospace Systems: Separate response sensor, relay/load, external load condition and communication. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needUse condition indicators to detect, identify and isolate actuator fault modes while distinguishing sensor faults from component failures.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Condition inference on process phase; preserve physical context; test root-cause discrimination and subtask timing rather than a context-free threshold.
The H753 cell uses a smaller signal set and safe injected resistance while retaining the context-sensitive evaluation idea.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationIssue a fault-switch matrix and provenance log so sensor, actuator, process and network faults are reproducible and mutually distinguishable.
Variant 17.07
Two-Node Timing Fault Mapper
Engineering purpose: Adds timing diagnosis without RTOS.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception2 H753 boards1 laptop
Controller2 H753 boards + 1 laptop
SenseLM35-class temperature channels for the default diagnostic cell; conditioned…
Actuatelow-voltage fan through a protected 3.3-V-compatible MOSFET/relay channel for…
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser root-cause truth table and at least one held-out UNKNOWN fault mechanism
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: For variants 17.07–17.10 the default process is frozen to this thermal/fan cell unless an official BOM addendum replaces it. Verify the complete EQ-17-07 manifest before data collection.
1 · Scenario and student challenge
Focus on whether delay originates at sensing, bus or actuator processing. In plain language, adapt FaultMap — End-to-End Fault Attribution Across Sensor, Actuator, Process and Network so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Adds timing diagnosis without RTOS.
2 · What to build or modify
Allocated hardware: 2 × H753 + H753-N + one organiser-selected S/A/M cell used consistently across all fault classes. Begin with two H753 boards with H753-N plus the variant’s sensing or actuation module and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record raw measurement and quality, command/requested/applied mode, physical response, current/position, timestamps, sequence, heartbeat and local fault bits. Treat one end-to-end event window containing one controlled root cause as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Latency-pattern classification. First implement the parent baseline—hand-built hierarchical diagnostic decision tree—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only fixed diagnostic action, RECHECK or UNRESOLVED_SAFE, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with two different root causes that create the same high-level process symptom. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 17.07 — Two-Node Timing Fault Mapper”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
2 × H753 + H753-N + one organiser-selected S/A/M cell used consistently across all fault classesclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P17 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Two-Node Timing Fault Mapper is a syllabus-scaled physical analogue of the need evidenced by BM03 · Diagnostic Approach for Electro-Mechanical Actuators in Aerospace Systems: Focus on whether delay originates at sensing, bus or actuator processing. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needUse condition indicators to detect, identify and isolate actuator fault modes while distinguishing sensor faults from component failures.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Condition inference on process phase; preserve physical context; test root-cause discrimination and subtask timing rather than a context-free threshold.
The H753 cell uses a smaller signal set and safe injected resistance while retaining the context-sensitive evaluation idea.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationIssue a fault-switch matrix and provenance log so sensor, actuator, process and network faults are reproducible and mutually distinguishable.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception2 H753 boards1 laptop
Controller2 H753 boards + 1 laptop
SenseLM35-class temperature channels for the default diagnostic cell; conditioned…
Actuatelow-voltage fan through a protected 3.3-V-compatible MOSFET/relay channel for…
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser root-cause truth table and at least one held-out UNKNOWN fault mechanism
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: For variants 17.07–17.10 the default process is frozen to this thermal/fan cell unless an official BOM addendum replaces it. Verify the complete EQ-17-08 manifest before data collection.
1 · Scenario and student challenge
Inject wrong scaling, wrong CAN ID, wrong profile and reversed direction setting. In plain language, adapt FaultMap — End-to-End Fault Attribution Across Sensor, Actuator, Process and Network so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Targets human/configuration errors.
2 · What to build or modify
Allocated hardware: 2 × H753 + H753-N + one organiser-selected S/A/M cell used consistently across all fault classes. Begin with two H753 boards with H753-N plus the variant’s sensing or actuation module and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record raw measurement and quality, command/requested/applied mode, physical response, current/position, timestamps, sequence, heartbeat and local fault bits. Treat one end-to-end event window containing one controlled root cause as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Commissioning-fault classification. First implement the parent baseline—hand-built hierarchical diagnostic decision tree—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only fixed diagnostic action, RECHECK or UNRESOLVED_SAFE, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with two different root causes that create the same high-level process symptom. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 17.08 — Configuration Fault Mapper”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
2 × H753 + H753-N + one organiser-selected S/A/M cell used consistently across all fault classesclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P17 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Configuration Fault Mapper is a syllabus-scaled physical analogue of the need evidenced by BM03 · Diagnostic Approach for Electro-Mechanical Actuators in Aerospace Systems: Inject wrong scaling, wrong CAN ID, wrong profile and reversed direction setting. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needUse condition indicators to detect, identify and isolate actuator fault modes while distinguishing sensor faults from component failures.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Condition inference on process phase; preserve physical context; test root-cause discrimination and subtask timing rather than a context-free threshold.
The H753 cell uses a smaller signal set and safe injected resistance while retaining the context-sensitive evaluation idea.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationIssue a fault-switch matrix and provenance log so sensor, actuator, process and network faults are reproducible and mutually distinguishable.
Variant 17.09
Intermittent Fault Mapper
Engineering purpose: Demonstrates value of timestamped logs.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception2 H753 boards1 laptop
Controller2 H753 boards + 1 laptop
SenseLM35-class temperature channels for the default diagnostic cell; conditioned…
Actuatelow-voltage fan through a protected 3.3-V-compatible MOSFET/relay channel for…
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser root-cause truth table and at least one held-out UNKNOWN fault mechanism
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: For variants 17.07–17.10 the default process is frozen to this thermal/fan cell unless an official BOM addendum replaces it. Verify the complete EQ-17-09 manifest before data collection.
1 · Scenario and student challenge
Use brief faults that may disappear before inspection. In plain language, adapt FaultMap — End-to-End Fault Attribution Across Sensor, Actuator, Process and Network so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Demonstrates value of timestamped logs.
2 · What to build or modify
Allocated hardware: 2 × H753 + H753-N + one organiser-selected S/A/M cell used consistently across all fault classes. Begin with two H753 boards with H753-N plus the variant’s sensing or actuation module and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record raw measurement and quality, command/requested/applied mode, physical response, current/position, timestamps, sequence, heartbeat and local fault bits. Treat one end-to-end event window containing one controlled root cause as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Event-window classification. First implement the parent baseline—hand-built hierarchical diagnostic decision tree—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only fixed diagnostic action, RECHECK or UNRESOLVED_SAFE, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with two different root causes that create the same high-level process symptom. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 17.09 — Intermittent Fault Mapper”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
2 × H753 + H753-N + one organiser-selected S/A/M cell used consistently across all fault classesclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P17 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Intermittent Fault Mapper is a syllabus-scaled physical analogue of the need evidenced by BM03 · Diagnostic Approach for Electro-Mechanical Actuators in Aerospace Systems: Use brief faults that may disappear before inspection. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needUse condition indicators to detect, identify and isolate actuator fault modes while distinguishing sensor faults from component failures.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Condition inference on process phase; preserve physical context; test root-cause discrimination and subtask timing rather than a context-free threshold.
The H753 cell uses a smaller signal set and safe injected resistance while retaining the context-sensitive evaluation idea.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationIssue a fault-switch matrix and provenance log so sensor, actuator, process and network faults are reproducible and mutually distinguishable.
Variant 17.10
Unknown-Fault Abstention Mapper
Engineering purpose: Rewards honesty and robustness over forced labels.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception2 H753 boards1 laptop
Controller2 H753 boards + 1 laptop
SenseLM35-class temperature channels for the default diagnostic cell; conditioned…
Actuatelow-voltage fan through a protected 3.3-V-compatible MOSFET/relay channel for…
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × known-fault training set plus a deliberately held-out fault mechanism
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: For variants 17.07–17.10 the default process is frozen to this thermal/fan cell unless an official BOM addendum replaces it. Verify the complete EQ-17-10 manifest before data collection.
1 · Scenario and student challenge
Hold out one fault mechanism and require safe UNRESOLVED classification. In plain language, adapt FaultMap — End-to-End Fault Attribution Across Sensor, Actuator, Process and Network so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Rewards honesty and robustness over forced labels.
2 · What to build or modify
Allocated hardware: 2 × H753 + H753-N + one organiser-selected S/A/M cell used consistently across all fault classes. Begin with two H753 boards with H753-N plus the variant’s sensing or actuation module and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record raw measurement and quality, command/requested/applied mode, physical response, current/position, timestamps, sequence, heartbeat and local fault bits. Treat one end-to-end event window containing one controlled root cause as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Confidence-based abstention. First implement the parent baseline—hand-built hierarchical diagnostic decision tree—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a causal event timeline and root-cause confusion matrix.
5 · Embedded integration and safe response
The host may return only fixed diagnostic action, RECHECK or UNRESOLVED_SAFE, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with two different root causes that create the same high-level process symptom. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 17.10 — Unknown-Fault Abstention Mapper”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
2 × H753 + H753-N + one organiser-selected S/A/M cell used consistently across all fault classesclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P17 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Unknown-Fault Abstention Mapper is a syllabus-scaled physical analogue of the need evidenced by BM03 · Diagnostic Approach for Electro-Mechanical Actuators in Aerospace Systems: Hold out one fault mechanism and require safe UNRESOLVED classification. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needUse condition indicators to detect, identify and isolate actuator fault modes while distinguishing sensor faults from component failures.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Condition inference on process phase; preserve physical context; test root-cause discrimination and subtask timing rather than a context-free threshold.
The H753 cell uses a smaller signal set and safe injected resistance while retaining the context-sensitive evaluation idea.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationIssue a fault-switch matrix and provenance log so sensor, actuator, process and network faults are reproducible and mutually distinguishable.
Problem 18 · 10 variants · Control engineering and data-quality intelligence
Assigned Faculty Master pair for P18: one nominated ESD Faculty Master and one nominated ML Faculty Master shall jointly master this parent problem and variants V1-V10. The ESD Master owns hardware, firmware, control, communication and safety verification; the ML Master owns data, baselines, models, validation and bounded decision-policy verification. Together they teach and guide ten teams (one for each variant and up to 40 students), supervise five teams in Wave A and five in Wave B, witness integration and sign every final evaluation.
The problem
Students can tune PID by trial and step response, but the best gains change with load, direction, temperature and performance objective. Allowing an ML model to invent gains would exceed the course and create safety risk. The bounded alternative is to evaluate several faculty-approved gain sets and train a host-side model to recommend which set is most likely to meet the declared constraints.
Smart embedded product to build
Build a NUCLEO-H753ZI PID evidence bench with three to six faculty-approved gain sets stored in firmware. The fixed-rate loop performs standardised step/disturbance tests and exports setpoint, feedback, error, output, current, sample time, saturation and anti-windup evidence plus measured control metrics. The host predicts which stored set will satisfy the declared objective under the current context and returns only its ID; the board validates it and can revert to a conservative default.
NUCLEO-H753ZI realization and issued pack
NUCLEO-H753ZI / MB1364E with H753-M PID test fixture
fixed-period PID ISR, PWM output and timer encoder feedback
three to six faculty-approved gain-set/profile IDs stored in firmware
conditioned current and optional temperature ADC; saturation/anti-windup telemetry
USART3 VCP exports context×gain-set trials and accepts only an approved ID
MCU rejects illegal/stale IDs and reverts to conservative default
LED/display exposes selected, applied, rejected and safe-abort states
Intelligence to incorporate
Use classification of best feasible gain set or predict each set’s outcome using regression. Features include setpoint magnitude, direction, initial position, load estimate, temperature and prior test metrics. Compare against fixed default and manual rule selection. Evaluate constraint pass rate, selection accuracy, overshoot/settling improvement and unsafe recommendation rejection.
Permitted output/action set
GAIN_SET_ID · RETEST · CONSERVATIVE_DEFAULT
Canonical family command contract: every parent brief, variant, host message and MCU acknowledgement for P18 shall use these exact identifiers. A variant may use only the applicable subset; it shall not introduce a synonym.
Core problem equipment · EQ-18-CORE
Complete equipment required for one core-problem team
Standalone family BOM. This list supports the parent problem itself. An allocated variant uses its own complete table later in this card. A component mentioned again in the fixture description is the same mounted unit, not another copy.
4 students; 3 by approved exception1 H753 board1 team laptopquantities per team
Controller1 H753 board + 1 laptop
Sensequadrature encoder/position feedback; conditioned 0–3.3 V current-sense chann…
Actuatelow-torque 6–12 V geared DC motor with encoder; 3.3-V-logic H-bridge rated ab…
Fixtureguarded PID speed/position test rig with marked start/target points; sealed c…
Protectcurrent-limited 6–12 V DC supply; inline fuse plus spare fuses; latching E-st…
System block
Complete quantity and equipment per team
Purpose / acceptance condition
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser context×gain-set seed matrix and metric-check notebook
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Release-to-team condition: The host recommends an approved gain-set ID only; firmware retains current, travel, timing and stability bounds. The organiser signs the electrical, mechanical and communication acceptance checklist before H0:00.
Not duplicated inside the kit: supervised rework tools and the oscilloscope/logic-analyser station are shared at the ratio stated above. Everything else in this table is issued to, reserved for, or digitally assigned to this team.
Controlled self-learning extension
Recommended Train a separate simple outcome model for each stored gain set and create a counterfactual table of predicted versus subsequently measured outcomes. It may rank only existing sets.
System safety and non-negotiable boundary
Only pre-approved gain sets exist on the MCU. All saturation, anti-windup, current/travel/time limits remain active. Low confidence selects the safe default or requests another test.
Student interpretation — what this challenge really asks
The model is not allowed to invent PID gains. It studies outcomes from several faculty-approved gain sets and recommends the set most likely to satisfy the current performance and safety constraints.
Independent data unitone step-response trial for one gain set and operating context.
Closest misleading casea fast-looking set that fails a current, overshoot or steady-state constraint.
Definition of successStudents must choose a feasible gain set for a hidden context and show why the default or fastest set is inferior.
Visual system blueprint
Physical processPID test matrix across contextsGenerate labelled, safe and repeatable conditions.
Observegain-set ID, setpoint, start statePreserve units, timestamps, run identity and signal quality.
H753 responsibilityControl and protectstore approved gain sets, execute safe step tests and reject any unknown or stale selection.
Host intelligenceLearn the distinctionpredict each set’s outcome or classify the best feasible approved set.
Bounded outcomeGAIN_SET_ID · RETEST · CONSERVATIVE_DEFAULTMCU validates, acknowledges and may refuse the request.
Recommended build journey
Make the process repeatableAssemble the H753-M PID motion test bench with three to six locked gain sets; define reference and target conditions before collecting data.
Prove deterministic firmwareStore approved gain sets, execute safe step tests and reject any unknown or stale selection. Demonstrate every hard limit before connecting ML.
Build trustworthy trialsTreat one step-response trial for one gain set and operating context as independent; calibrate, label and split by run/session.
Beat a real baselineCompare one fixed default set or a simple context-to-set lookup with two syllabus-approved classical models.
Close and challenge the loopReturn only the applicable subset of GAIN_SET_ID · RETEST · CONSERVATIVE_DEFAULT; test the target, nearest confuser, stale command and host loss.
Definition of done
Firmware controls safely before, during and after host connection.
Portfolio shows gain-set outcome matrix and counterfactual comparison for the chosen context and one honest failure case.
Problem-specific evidence at the common reviews
R1 · Design
Freeze gain sets, performance constraints, safe test matrix, best-set labelling rule and fallback.
R2 · Embedded
Demonstrate stable PID execution for every gain set, accurate step metrics and MCU validation of IDs.
R3 · Data
Submit context×gain-set trials, fixed-default baseline and run-wise split.
R4 · ML
Show recommendation/outcome model and held-out-context pass rate.
R5 · Integration
Integrate selection, reject illegal sets and pass hidden load/direction/host-loss tests.
Final
Select a gain set for a blind condition, run it and compare predicted versus measured response.
Portfolio/Kaggle outcome
Kaggle notebook: step-response trial matrix by gain set/context, best-set label definition, multiclass selection model, counterfactual outcome comparison and model limitations.
Industry alignment and validation basis
PIDCoach: external references and required evidence
The listed sources establish relevance, test discipline and implementation precedent. They do not modify the common syllabus boundary, safety rules or 100-mark assessment rubric.
Family implementation profile
Variant availability: 8 standard assignment(s); 2 organiser-supported assignment(s).
Public evidence: reproducible firmware, protocol, dataset, notebook/model, test report and demonstration video.
What the external benchmark confirms
The problem has a recognisable industrial or challenge analogue, a measurable data task, a defensible embedded implementation and a safe operational decision. Every one of its ten variants is mapped separately below.
Condition before team allocation
Faculty must pre-approve every gain set and disturbance envelope; the ML service may recommend an ID but never invent gains.
Combine process state, velocity, torque, current, voltage and timing context for conveyor anomaly detection, diagnosis and productivity analysis.
Condition inference on process phase; preserve physical context; test root-cause discrimination and subtask timing rather than a context-free threshold.
Standardise HVAC control sequences to improve energy efficiency, performance and control stability while enabling real-time fault detection and diagnostics.
Keep hard sequences deterministic, compare energy and control quality, and test sensor/actuator faults against functional behaviour.
Open the 10 fully elaborated student variant briefs
Choose only the variant allocated to your team. Read it together with the parent problem above: the card expands the experimental delta, while every hardware, safety, integration and review requirement of the family remains active.
Variant 18.01
Speed-Loop Gain Coach
Engineering purpose: Directly aligns with velocity PID.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensequadrature encoder/position feedback; conditioned 0–3.3 V current-sense chann…
Actuatelow-torque 6–12 V geared DC motor with encoder; 3.3-V-logic H-bridge rated ab…
Fixtureguarded speed-loop motor rig; target-speed card with at least four approved s…
Protectcurrent-limited 6–12 V DC supply; inline fuse plus spare fuses; latching E-st…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser context×gain-set seed matrix and metric-check notebook
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: The host recommends an approved gain-set ID only; firmware retains current, travel, timing and stability bounds. Verify the complete EQ-18-01 manifest before data collection.
1 · Scenario and student challenge
Choose gain set for multiple target speeds. In plain language, adapt PIDCoach — Evidence-Based Gain-Set Selection Assistant so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Directly aligns with velocity PID.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M PID rig + the named safe mechanical/condition fixture. Begin with the H753-M PID motion test bench with three to six locked gain sets and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record gain-set ID, setpoint, start state, direction, load/temperature context, feedback, error, PWM, current and response metrics. Treat one step-response trial for one gain set and operating context as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Multiclass best-set selection. First implement the parent baseline—one fixed default set or a simple context-to-set lookup—and then compare two algorithms from the faculty-issued ML whitelist. Report correct/feasible selection rate, constraint violations and improvement over the fixed policy. A choice is wrong if it violates a declared current, timing, thermal or control-quality bound even when it is fast. Produce a candidate-outcome/constraint table showing why the selected option is feasible.
5 · Embedded integration and safe response
The host may return only approved GAIN_SET_ID, RETEST or CONSERVATIVE_DEFAULT, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a fast-looking set that fails a current, overshoot or steady-state constraint. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 18.01 — Speed-Loop Gain Coach”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M PID rig + the named safe mechanical/condition fixtureclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P18 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Speed-Loop Gain Coach is a syllabus-scaled physical analogue of the need evidenced by BM07 · RP-1587 Control Loop Performance Assessment: Choose gain set for multiple target speeds. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needDevelop a metric for assessing control-loop performance and report field-testing work on control quality.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Condition inference on process phase; preserve physical context; test root-cause discrimination and subtask timing rather than a context-free threshold.
The H753 cell uses a smaller signal set and safe injected resistance while retaining the context-sensitive evaluation idea.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationFaculty must pre-approve every gain set and disturbance envelope; the ML service may recommend an ID but never invent gains.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensequadrature encoder/position feedback; conditioned 0–3.3 V current-sense chann…
Actuatelow-torque 6–12 V geared DC motor with encoder; 3.3-V-logic H-bridge rated ab…
Fixturebounded position-loop arm/carriage; limit switches and at least four start/ta…
Protectcurrent-limited 6–12 V DC supply; inline fuse plus spare fuses; latching E-st…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser context×gain-set seed matrix and metric-check notebook
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: The host recommends an approved gain-set ID only; firmware retains current, travel, timing and stability bounds. Verify the complete EQ-18-02 manifest before data collection.
1 · Scenario and student challenge
Choose gains by movement distance and initial position. In plain language, adapt PIDCoach — Evidence-Based Gain-Set Selection Assistant so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Highlights nonlinear operating context.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M PID rig + the named safe mechanical/condition fixture. Begin with the H753-M PID motion test bench with three to six locked gain sets and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record gain-set ID, setpoint, start state, direction, load/temperature context, feedback, error, PWM, current and response metrics. Treat one step-response trial for one gain set and operating context as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Selection classification. First implement the parent baseline—one fixed default set or a simple context-to-set lookup—and then compare two algorithms from the faculty-issued ML whitelist. Report correct/feasible selection rate, constraint violations and improvement over the fixed policy. A choice is wrong if it violates a declared current, timing, thermal or control-quality bound even when it is fast. Produce a candidate-outcome/constraint table showing why the selected option is feasible.
5 · Embedded integration and safe response
The host may return only approved GAIN_SET_ID, RETEST or CONSERVATIVE_DEFAULT, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a fast-looking set that fails a current, overshoot or steady-state constraint. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 18.02 — Position-Loop Gain Coach”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M PID rig + the named safe mechanical/condition fixtureclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P18 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Position-Loop Gain Coach is a syllabus-scaled physical analogue of the need evidenced by BM07 · RP-1587 Control Loop Performance Assessment: Choose gains by movement distance and initial position. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needDevelop a metric for assessing control-loop performance and report field-testing work on control quality.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Condition inference on process phase; preserve physical context; test root-cause discrimination and subtask timing rather than a context-free threshold.
The H753 cell uses a smaller signal set and safe injected resistance while retaining the context-sensitive evaluation idea.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationFaculty must pre-approve every gain set and disturbance envelope; the ML service may recommend an ID but never invent gains.
Variant 18.03
Load-Conditioned Gain Coach
Engineering purpose: Demonstrates adaptive supervision without adaptive control.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensequadrature encoder/position feedback; conditioned 0–3.3 V current-sense chann…
Actuatelow-torque 6–12 V geared DC motor with encoder; 3.3-V-logic H-bridge rated ab…
Fixtureguarded motor rig with repeatable load attachment; calibrated load/friction c…
Protectcurrent-limited 6–12 V DC supply; inline fuse plus spare fuses; latching E-st…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser context×gain-set seed matrix and metric-check notebook
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: The host recommends an approved gain-set ID only; firmware retains current, travel, timing and stability bounds. Verify the complete EQ-18-03 manifest before data collection.
1 · Scenario and student challenge
Use load class/estimate as context. In plain language, adapt PIDCoach — Evidence-Based Gain-Set Selection Assistant so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Demonstrates adaptive supervision without adaptive control.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M PID rig + the named safe mechanical/condition fixture. Begin with the H753-M PID motion test bench with three to six locked gain sets and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record gain-set ID, setpoint, start state, direction, load/temperature context, feedback, error, PWM, current and response metrics. Treat one step-response trial for one gain set and operating context as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Best-set model across loads. First implement the parent baseline—one fixed default set or a simple context-to-set lookup—and then compare two algorithms from the faculty-issued ML whitelist. Report correct/feasible selection rate, constraint violations and improvement over the fixed policy. A choice is wrong if it violates a declared current, timing, thermal or control-quality bound even when it is fast. Produce a gain-set outcome matrix and counterfactual comparison for the chosen context.
5 · Embedded integration and safe response
The host may return only approved GAIN_SET_ID, RETEST or CONSERVATIVE_DEFAULT, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a fast-looking set that fails a current, overshoot or steady-state constraint. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 18.03 — Load-Conditioned Gain Coach”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M PID rig + the named safe mechanical/condition fixtureclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P18 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Load-Conditioned Gain Coach is a syllabus-scaled physical analogue of the need evidenced by BM07 · RP-1587 Control Loop Performance Assessment: Use load class/estimate as context. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needDevelop a metric for assessing control-loop performance and report field-testing work on control quality.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Condition inference on process phase; preserve physical context; test root-cause discrimination and subtask timing rather than a context-free threshold.
The H753 cell uses a smaller signal set and safe injected resistance while retaining the context-sensitive evaluation idea.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationFaculty must pre-approve every gain set and disturbance envelope; the ML service may recommend an ID but never invent gains.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensequadrature encoder/position feedback; conditioned 0–3.3 V current-sense chann…
Actuatelow-torque 6–12 V geared DC motor with encoder; 3.3-V-logic H-bridge rated ab…
Fixturesymmetric bidirectional motor rig; centre/home marker and separate forward/re…
Protectcurrent-limited 6–12 V DC supply; inline fuse plus spare fuses; latching E-st…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser context×gain-set seed matrix and metric-check notebook
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: The host recommends an approved gain-set ID only; firmware retains current, travel, timing and stability bounds. Verify the complete EQ-18-04 manifest before data collection.
1 · Scenario and student challenge
Allow different approved sets for forward/reverse. In plain language, adapt PIDCoach — Evidence-Based Gain-Set Selection Assistant so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Addresses asymmetric mechanics.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M PID rig + the named safe mechanical/condition fixture. Begin with the H753-M PID motion test bench with three to six locked gain sets and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record gain-set ID, setpoint, start state, direction, load/temperature context, feedback, error, PWM, current and response metrics. Treat one step-response trial for one gain set and operating context as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Direction-aware selection. First implement the parent baseline—one fixed default set or a simple context-to-set lookup—and then compare two algorithms from the faculty-issued ML whitelist. Report correct/feasible selection rate, constraint violations and improvement over the fixed policy. A choice is wrong if it violates a declared current, timing, thermal or control-quality bound even when it is fast. Produce a candidate-outcome/constraint table showing why the selected option is feasible.
5 · Embedded integration and safe response
The host may return only approved GAIN_SET_ID, RETEST or CONSERVATIVE_DEFAULT, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a fast-looking set that fails a current, overshoot or steady-state constraint. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 18.04 — Direction-Conditioned Gain Coach”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M PID rig + the named safe mechanical/condition fixtureclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P18 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Direction-Conditioned Gain Coach is a syllabus-scaled physical analogue of the need evidenced by BM07 · RP-1587 Control Loop Performance Assessment: Allow different approved sets for forward/reverse. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needDevelop a metric for assessing control-loop performance and report field-testing work on control quality.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Condition inference on process phase; preserve physical context; test root-cause discrimination and subtask timing rather than a context-free threshold.
The H753 cell uses a smaller signal set and safe injected resistance while retaining the context-sensitive evaluation idea.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationFaculty must pre-approve every gain set and disturbance envelope; the ML service may recommend an ID but never invent gains.
Variant 18.05
Low-Overshoot Coach
Engineering purpose: Suitable for precision motion.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensequadrature encoder/position feedback; conditioned 0–3.3 V current-sense chann…
Actuatelow-torque 6–12 V geared DC motor with encoder; 3.3-V-logic H-bridge rated ab…
Fixturestandard PID rig with a printed maximum-overshoot boundary
Protectcurrent-limited 6–12 V DC supply; inline fuse plus spare fuses; latching E-st…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser context×gain-set seed matrix and metric-check notebook
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: The host recommends an approved gain-set ID only; firmware retains current, travel, timing and stability bounds. Verify the complete EQ-18-05 manifest before data collection.
1 · Scenario and student challenge
Optimise primarily for overshoot constraint. In plain language, adapt PIDCoach — Evidence-Based Gain-Set Selection Assistant so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Suitable for precision motion.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M PID rig + the named safe mechanical/condition fixture. Begin with the H753-M PID motion test bench with three to six locked gain sets and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record gain-set ID, setpoint, start state, direction, load/temperature context, feedback, error, PWM, current and response metrics. Treat one step-response trial for one gain set and operating context as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Feasibility classification. First implement the parent baseline—one fixed default set or a simple context-to-set lookup—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only approved GAIN_SET_ID, RETEST or CONSERVATIVE_DEFAULT, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a fast-looking set that fails a current, overshoot or steady-state constraint. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 18.05 — Low-Overshoot Coach”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M PID rig + the named safe mechanical/condition fixtureclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P18 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Low-Overshoot Coach is a syllabus-scaled physical analogue of the need evidenced by BM07 · RP-1587 Control Loop Performance Assessment: Optimise primarily for overshoot constraint. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needDevelop a metric for assessing control-loop performance and report field-testing work on control quality.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Condition inference on process phase; preserve physical context; test root-cause discrimination and subtask timing rather than a context-free threshold.
The H753 cell uses a smaller signal set and safe injected resistance while retaining the context-sensitive evaluation idea.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationFaculty must pre-approve every gain set and disturbance envelope; the ML service may recommend an ID but never invent gains.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensequadrature encoder/position feedback; conditioned 0–3.3 V current-sense chann…
Actuatelow-torque 6–12 V geared DC motor with encoder; 3.3-V-logic H-bridge rated ab…
Fixturestandard PID rig with a printed settling band and sealed maximum settling time
Protectcurrent-limited 6–12 V DC supply; inline fuse plus spare fuses; latching E-st…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser context×gain-set seed matrix and metric-check notebook
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: The host recommends an approved gain-set ID only; firmware retains current, travel, timing and stability bounds. Verify the complete EQ-18-06 manifest before data collection.
1 · Scenario and student challenge
Minimise settling among sets that meet safety/error limits. In plain language, adapt PIDCoach — Evidence-Based Gain-Set Selection Assistant so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Connects to throughput.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M PID rig + the named safe mechanical/condition fixture. Begin with the H753-M PID motion test bench with three to six locked gain sets and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record gain-set ID, setpoint, start state, direction, load/temperature context, feedback, error, PWM, current and response metrics. Treat one step-response trial for one gain set and operating context as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Outcome regression plus ranking. First implement the parent baseline—one fixed default set or a simple context-to-set lookup—and then compare two algorithms from the faculty-issued ML whitelist. Report MAE and RMSE on whole held-out runs, show predicted-versus-measured values, and inspect error by operating condition. If the target is converted to a safe/unsafe decision, also report missed-unsafe and unnecessary-conservative actions. Produce a predicted-versus-measured plot with residuals by operating condition.
5 · Embedded integration and safe response
The host may return only approved GAIN_SET_ID, RETEST or CONSERVATIVE_DEFAULT, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a fast-looking set that fails a current, overshoot or steady-state constraint. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 18.06 — Fast-Settling Coach”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M PID rig + the named safe mechanical/condition fixtureregression/outcomerun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P18 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Fast-Settling Coach is a syllabus-scaled physical analogue of the need evidenced by BM07 · RP-1587 Control Loop Performance Assessment: Minimise settling among sets that meet safety/error limits. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needDevelop a metric for assessing control-loop performance and report field-testing work on control quality.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Condition inference on process phase; preserve physical context; test root-cause discrimination and subtask timing rather than a context-free threshold.
The H753 cell uses a smaller signal set and safe injected resistance while retaining the context-sensitive evaluation idea.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationFaculty must pre-approve every gain set and disturbance envelope; the ML service may recommend an ID but never invent gains.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensequadrature encoder/position feedback; conditioned 0–3.3 V current-sense chann…
Actuatelow-torque 6–12 V geared DC motor with encoder; 3.3-V-logic H-bridge rated ab…
Fixturestandard PID rig with calibrated current channel; declared current-integral/e…
Protectcurrent-limited 6–12 V DC supply; inline fuse plus spare fuses; latching E-st…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser context×gain-set seed matrix and metric-check notebook
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: The host recommends an approved gain-set ID only; firmware retains current, travel, timing and stability bounds. Verify the complete EQ-18-07 manifest before data collection.
1 · Scenario and student challenge
Add current-integral constraint. In plain language, adapt PIDCoach — Evidence-Based Gain-Set Selection Assistant so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Avoids performance-only tuning.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M PID rig + the named safe mechanical/condition fixture. Begin with the H753-M PID motion test bench with three to six locked gain sets and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record gain-set ID, setpoint, start state, direction, load/temperature context, feedback, error, PWM, current and response metrics. Treat one step-response trial for one gain set and operating context as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Multi-criteria feasibility model. First implement the parent baseline—one fixed default set or a simple context-to-set lookup—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a gain-set outcome matrix and counterfactual comparison for the chosen context.
5 · Embedded integration and safe response
The host may return only approved GAIN_SET_ID, RETEST or CONSERVATIVE_DEFAULT, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a fast-looking set that fails a current, overshoot or steady-state constraint. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 18.07 — Energy-Aware Gain Coach”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M PID rig + the named safe mechanical/condition fixtureclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P18 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Energy-Aware Gain Coach is a syllabus-scaled physical analogue of the need evidenced by BM07 · RP-1587 Control Loop Performance Assessment: Add current-integral constraint. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needDevelop a metric for assessing control-loop performance and report field-testing work on control quality.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Condition inference on process phase; preserve physical context; test root-cause discrimination and subtask timing rather than a context-free threshold.
The H753 cell uses a smaller signal set and safe injected resistance while retaining the context-sensitive evaluation idea.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationFaculty must pre-approve every gain set and disturbance envelope; the ML service may recommend an ID but never invent gains.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Senseencoder; 0–3.3 V current channel; LM35-class channels: motor/driver and ambie…
Actuatelow-torque 6–12 V geared DC motor with encoder; 3.3-V-logic H-bridge rated ab…
Fixturestandard PID rig with motor/driver and ambient temperature probe positions
Protectcurrent-limited 6–12 V DC supply; inline fuse plus spare fuses; latching E-st…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser context×gain-set seed matrix and metric-check notebook
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: The host recommends an approved gain-set ID only; firmware retains current, travel, timing and stability bounds. Verify the complete EQ-18-08 manifest before data collection.
1 · Scenario and student challenge
Select conservative set when temperature/current risk is elevated. In plain language, adapt PIDCoach — Evidence-Based Gain-Set Selection Assistant so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Integrates drive health.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M PID rig + the named safe mechanical/condition fixture. Begin with the H753-M PID motion test bench with three to six locked gain sets and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record gain-set ID, setpoint, start state, direction, load/temperature context, feedback, error, PWM, current and response metrics. Treat one step-response trial for one gain set and operating context as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Contextual selection. First implement the parent baseline—one fixed default set or a simple context-to-set lookup—and then compare two algorithms from the faculty-issued ML whitelist. Report correct/feasible selection rate, constraint violations and improvement over the fixed policy. A choice is wrong if it violates a declared current, timing, thermal or control-quality bound even when it is fast. Produce a candidate-outcome/constraint table showing why the selected option is feasible.
5 · Embedded integration and safe response
The host may return only approved GAIN_SET_ID, RETEST or CONSERVATIVE_DEFAULT, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a fast-looking set that fails a current, overshoot or steady-state constraint. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 18.08 — Thermal-State Gain Coach”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M PID rig + the named safe mechanical/condition fixtureclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P18 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Thermal-State Gain Coach is a syllabus-scaled physical analogue of the need evidenced by BM07 · RP-1587 Control Loop Performance Assessment: Select conservative set when temperature/current risk is elevated. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needDevelop a metric for assessing control-loop performance and report field-testing work on control quality.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Condition inference on process phase; preserve physical context; test root-cause discrimination and subtask timing rather than a context-free threshold.
The H753 cell uses a smaller signal set and safe injected resistance while retaining the context-sensitive evaluation idea.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationFaculty must pre-approve every gain set and disturbance envelope; the ML service may recommend an ID but never invent gains.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensequadrature encoder/position feedback; conditioned 0–3.3 V current-sense chann…
Actuatelow-torque 6–12 V geared DC motor with encoder; 3.3-V-logic H-bridge rated ab…
FixturePID rig with controlled disturbance lever/felt pad; repeatable spring/weight…
Protectcurrent-limited 6–12 V DC supply; inline fuse plus spare fuses; latching E-st…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser context×gain-set seed matrix and metric-check notebook
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: The host recommends an approved gain-set ID only; firmware retains current, travel, timing and stability bounds. Verify the complete EQ-18-09 manifest before data collection.
1 · Scenario and student challenge
Choose the set that recovers fastest from controlled disturbance. In plain language, adapt PIDCoach — Evidence-Based Gain-Set Selection Assistant so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Tests robustness.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M PID rig + the named safe mechanical/condition fixture. Begin with the H753-M PID motion test bench with three to six locked gain sets and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record gain-set ID, setpoint, start state, direction, load/temperature context, feedback, error, PWM, current and response metrics. Treat one step-response trial for one gain set and operating context as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Recovery-outcome prediction. First implement the parent baseline—one fixed default set or a simple context-to-set lookup—and then compare two algorithms from the faculty-issued ML whitelist. Report MAE and RMSE on whole held-out runs, show predicted-versus-measured values, and inspect error by operating condition. If the target is converted to a safe/unsafe decision, also report missed-unsafe and unnecessary-conservative actions. Produce a predicted-versus-measured plot with residuals by operating condition.
5 · Embedded integration and safe response
The host may return only approved GAIN_SET_ID, RETEST or CONSERVATIVE_DEFAULT, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a fast-looking set that fails a current, overshoot or steady-state constraint. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 18.09 — Disturbance-Rejection Coach”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M PID rig + the named safe mechanical/condition fixtureregression/outcomerun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P18 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Disturbance-Rejection Coach is a syllabus-scaled physical analogue of the need evidenced by BM07 · RP-1587 Control Loop Performance Assessment: Choose the set that recovers fastest from controlled disturbance. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needDevelop a metric for assessing control-loop performance and report field-testing work on control quality.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Condition inference on process phase; preserve physical context; test root-cause discrimination and subtask timing rather than a context-free threshold.
The H753 cell uses a smaller signal set and safe injected resistance while retaining the context-sensitive evaluation idea.
Implementation modeOrganiser-supported assignmentMay be issued only after the named seed history, reference specimens, calibration set or controlled fixture is prepared.
Required organiser provisionComplete before team allocationFaculty must pre-approve every gain set and disturbance envelope; the ML service may recommend an ID but never invent gains.
Variant 18.10
Ageing-Aware Gain Coach
Engineering purpose: Combines maintenance and control responsibly.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensequadrature encoder/position feedback; conditioned 0–3.3 V current-sense chann…
Actuatelow-torque 6–12 V geared DC motor with encoder; 3.3-V-logic H-bridge rated ab…
FixturePID rig with reversible ageing insert; healthy insert, friction/drift inserts…
Protectcurrent-limited 6–12 V DC supply; inline fuse plus spare fuses; latching E-st…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser context×gain-set seed matrix and metric-check notebook
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: The host recommends an approved gain-set ID only; firmware retains current, travel, timing and stability bounds. Verify the complete EQ-18-10 manifest before data collection.
1 · Scenario and student challenge
Use health-passport drift features in selection. In plain language, adapt PIDCoach — Evidence-Based Gain-Set Selection Assistant so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Combines maintenance and control responsibly.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M PID rig + the named safe mechanical/condition fixture. Begin with the H753-M PID motion test bench with three to six locked gain sets and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record gain-set ID, setpoint, start state, direction, load/temperature context, feedback, error, PWM, current and response metrics. Treat one step-response trial for one gain set and operating context as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Selection conditioned on degradation indicator. First implement the parent baseline—one fixed default set or a simple context-to-set lookup—and then compare two algorithms from the faculty-issued ML whitelist. Report correct/feasible selection rate, constraint violations and improvement over the fixed policy. A choice is wrong if it violates a declared current, timing, thermal or control-quality bound even when it is fast. Produce a candidate-outcome/constraint table showing why the selected option is feasible.
5 · Embedded integration and safe response
The host may return only approved GAIN_SET_ID, RETEST or CONSERVATIVE_DEFAULT, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with a fast-looking set that fails a current, overshoot or steady-state constraint. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 18.10 — Ageing-Aware Gain Coach”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M PID rig + the named safe mechanical/condition fixtureclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P18 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Ageing-Aware Gain Coach is a syllabus-scaled physical analogue of the need evidenced by BM07 · RP-1587 Control Loop Performance Assessment: Use health-passport drift features in selection. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needDevelop a metric for assessing control-loop performance and report field-testing work on control quality.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Condition inference on process phase; preserve physical context; test root-cause discrimination and subtask timing rather than a context-free threshold.
The H753 cell uses a smaller signal set and safe injected resistance while retaining the context-sensitive evaluation idea.
Implementation modeOrganiser-supported assignmentMay be issued only after the named seed history, reference specimens, calibration set or controlled fixture is prepared.
Required organiser provisionComplete before team allocationFaculty must pre-approve every gain set and disturbance envelope; the ML service may recommend an ID but never invent gains.
Problem 19 · 10 variants · Control engineering and data-quality intelligence
Assigned Faculty Master pair for P19: one nominated ESD Faculty Master and one nominated ML Faculty Master shall jointly master this parent problem and variants V1-V10. The ESD Master owns hardware, firmware, control, communication and safety verification; the ML Master owns data, baselines, models, validation and bounded decision-policy verification. Together they teach and guide ten teams (one for each variant and up to 40 students), supervise five teams in Wave A and five in Wave B, witness integration and sign every final evaluation.
The problem
A controller may appear ‘bad’ for several reasons: oscillation, sluggish tuning, saturation, integral wind-up, feedback noise, steady-state bias, timing jitter or stale setpoint. These pathologies require different remedies. The challenge is to create a control-loop diagnostic instrument that classifies the behaviour from STM32 telemetry and suggests a bounded engineering diagnosis.
Smart embedded product to build
Build a NUCLEO-H753ZI control-loop diagnostic instrument with safe repeatable scenarios: approved gain sets/output limits, bounded sensor noise/dropout, setpoint patterns and communication/timing disturbances. Firmware logs actual sample interval, setpoint, feedback, error, controller terms/output, PWM, conditioned current, saturation and fault flags. The host classifies the pathology and recommends one named inspection/tuning action; it never rewrites gains or bypasses the board’s protection.
NUCLEO-H753ZI realization and issued pack
NUCLEO-H753ZI / MB1364E with H753-M diagnostic test fixture
fixed timer PID, encoder feedback and PWM driver
logged setpoint, measurement, error, controller terms/output, saturation, sample interval and command age
safe firmware-selectable scenarios: approved gains, limits, bounded sensor dropout/noise and stale setpoint
USART3 VCP episode export and advisory diagnosis/action code
MCU never accepts raw gains from the host and retains all interlocks
LED/display reports TEST, DIAGNOSIS, ADVISORY and SAFE_ABORT
Intelligence to incorporate
Engineer features such as error zero-crossings, peak decay, rise/settling, percentage time saturated, integral-growth proxy, feedback variance, sample-period jitter and command age. Compare a hand-coded diagnostic rule tree with logistic/tree models. Evaluate macro-F1, per-pathology recall and diagnosis time.
Canonical family command contract: every parent brief, variant, host message and MCU acknowledgement for P19 shall use these exact identifiers. A variant may use only the applicable subset; it shall not introduce a synonym.
Core problem equipment · EQ-19-CORE
Complete equipment required for one core-problem team
Standalone family BOM. This list supports the parent problem itself. An allocated variant uses its own complete table later in this card. A component mentioned again in the fixture description is the same mounted unit, not another copy.
4 students; 3 by approved exception1 H753 board1 team laptopquantities per team
Controller1 H753 board + 1 laptop
Sensequadrature encoder/position feedback; conditioned 0–3.3 V current-sense chann…
Actuatelow-torque 6–12 V geared DC motor with encoder; 3.3-V-logic H-bridge rated ab…
Fixtureguarded PID diagnostic rig with repeatable setpoint/disturbance mechanism; se…
Protectcurrent-limited 6–12 V DC supply; inline fuse plus spare fuses; latching E-st…
System block
Complete quantity and equipment per team
Purpose / acceptance condition
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser labelled control-pathology episode set and metric-check traces
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Release-to-team condition: Only bounded firmware test modes may inject faults; the host cannot write arbitrary gains or timing values. The organiser signs the electrical, mechanical and communication acceptance checklist before H0:00.
Not duplicated inside the kit: supervised rework tools and the oscilloscope/logic-analyser station are shared at the ratio stated above. Everything else in this table is issued to, reserved for, or digitally assigned to this team.
Controlled self-learning extension
Recommended Automatically segment a continuous trace into command, rise, settling, disturbance and recovery episodes, then show how segmentation errors affect the diagnostic features and model.
System safety and non-negotiable boundary
All injected scenarios remain within safe limits. Recommendations are advisory and mapped to a fixed menu. The MCU remains responsible for shutdown, saturation and anti-windup protections.
Student interpretation — what this challenge really asks
Oscillation, sluggishness, saturation, wind-up, sensor noise and timing faults require different remedies. Students build a loop-diagnostic instrument that labels the pathology and recommends inspection—not autonomous retuning.
Independent data unitone segmented response episode with one declared injected pathology.
Closest misleading casedifferent pathologies that produce similar tracking error but different internal/timing evidence.
Definition of successStudents must identify the dominant hidden pathology and recommend the correct bounded engineering check without changing gains automatically.
Visual system blueprint
Physical processControlled-loop pathology episodeGenerate labelled, safe and repeatable conditions.
Observesetpoint, feedback, errorPreserve units, timestamps, run identity and signal quality.
H753 responsibilityControl and protectexecute safe pre-approved scenarios, retain fixed loop timing and log the controller’s internal evidence.
Host intelligenceLearn the distinctionclassify the dominant control pathology from the response episode.
Bounded outcomeDIAGNOSIS · INSPECTION_ACTION · RETEST · SAFE_DEFAULTMCU validates, acknowledges and may refuse the request.
Recommended build journey
Make the process repeatableAssemble the H753-M PID bench with safe software-selectable test scenarios; define reference and target conditions before collecting data.
Prove deterministic firmwareExecute safe pre-approved scenarios, retain fixed loop timing and log the controller’s internal evidence. Demonstrate every hard limit before connecting ML.
Build trustworthy trialsTreat one segmented response episode with one declared injected pathology as independent; calibrate, label and split by run/session.
Beat a real baselineCompare hand-coded diagnostic rule tree with two syllabus-approved classical models.
Close and challenge the loopReturn only the applicable subset of DIAGNOSIS · INSPECTION_ACTION · RETEST · SAFE_DEFAULT; test the target, nearest confuser, stale command and host loss.
Definition of done
Firmware controls safely before, during and after host connection.
Held-out results report macro-F1, per-pathology recall, diagnosis latency and confusion between similar behaviours.
Portfolio shows response episode with peaks, saturation, timing and predicted pathology annotated and one honest failure case.
Demonstrate reproducible episodes, timing/error/output logs and safety limits.
R3 · Data
Submit labelled episodes, automatic features and rule-tree baseline.
R4 · ML
Show classifier, confusion among similar pathologies and feature evidence.
R5 · Integration
Integrate live diagnosis and pass hidden gain/sensor/timing cases without changing raw gains.
Final
Diagnose blind response episodes and defend the recommended engineering action.
Portfolio/Kaggle outcome
Kaggle dataset: labelled control-response episodes with pathology injection metadata, feature notebook, rule diagnostic tree, model comparison and explainable event plots.
Industry alignment and validation basis
LoopDoctor: external references and required evidence
The listed sources establish relevance, test discipline and implementation precedent. They do not modify the common syllabus boundary, safety rules or 100-mark assessment rubric.
Family implementation profile
Variant availability: 10 standard assignment(s); 0 organiser-supported assignment(s).
Public evidence: reproducible firmware, protocol, dataset, notebook/model, test report and demonstration video.
What the external benchmark confirms
The problem has a recognisable industrial or challenge analogue, a measurable data task, a defensible embedded implementation and a safe operational decision. Every one of its ten variants is mapped separately below.
Condition before team allocation
Provide safe pathology profiles and one matched benign response for every fault so diagnosis is not reduced to extreme-case recognition.
Standardise HVAC control sequences to improve energy efficiency, performance and control stability while enabling real-time fault detection and diagnostics.
Keep hard sequences deterministic, compare energy and control quality, and test sensor/actuator faults against functional behaviour.
Combine process state, velocity, torque, current, voltage and timing context for conveyor anomaly detection, diagnosis and productivity analysis.
Condition inference on process phase; preserve physical context; test root-cause discrimination and subtask timing rather than a context-free threshold.
Open the 10 fully elaborated student variant briefs
Choose only the variant allocated to your team. Read it together with the parent problem above: the card expands the experimental delta, while every hardware, safety, integration and review requirement of the family remains active.
Variant 19.01
Oscillation Detector
Engineering purpose: Directly interpretable from response peaks.
Decidenamed DIAGNOSIS, INSPECTION_ACTION, RETEST or SAFE_DEFAULT
Provemacro-F1, per-pathology recall, diagnosis latency and confusion…
Variant equipment · EQ-19-01
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensequadrature encoder/position feedback; conditioned 0–3.3 V current-sense chann…
Actuatelow-torque 6–12 V geared DC motor with encoder; 3.3-V-logic H-bridge rated ab…
Fixturestandard PID diagnostic rig using only approved well-damped/decaying-oscillat…
Protectcurrent-limited 6–12 V DC supply; inline fuse plus spare fuses; latching E-st…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser labelled control-pathology episode set and metric-check traces
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Only bounded firmware test modes may inject faults; the host cannot write arbitrary gains or timing values. Verify the complete EQ-19-01 manifest before data collection.
1 · Scenario and student challenge
Classify well-damped versus sustained/decaying oscillation. In plain language, adapt LoopDoctor — Automatic Control-Pathology Classifier so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Directly interpretable from response peaks.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M PID rig + the named safe mechanical/condition fixture. Begin with the H753-M PID bench with safe software-selectable test scenarios and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record setpoint, feedback, error, controller output/integral proxy, PWM, current, saturation, sample-period jitter and command age. Treat one segmented response episode with one declared injected pathology as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Binary/multiclass classification. First implement the parent baseline—hand-coded diagnostic rule tree—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only named DIAGNOSIS, INSPECTION_ACTION, RETEST or SAFE_DEFAULT, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with different pathologies that produce similar tracking error but different internal/timing evidence. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 19.01 — Oscillation Detector”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M PID rig + the named safe mechanical/condition fixtureclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P19 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Oscillation Detector is a syllabus-scaled physical analogue of the need evidenced by BM07 · RP-1587 Control Loop Performance Assessment: Classify well-damped versus sustained/decaying oscillation. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needDevelop a metric for assessing control-loop performance and report field-testing work on control quality.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Use approved gain/profile IDs, test every operating region and reject a selection when its evidence is outside the validated envelope.
Students do not auto-tune arbitrary gains; ML only selects from faculty-approved sets.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationProvide safe pathology profiles and one matched benign response for every fault so diagnosis is not reduced to extreme-case recognition.
Variant 19.02
Sluggish-Loop Detector
Engineering purpose: Separates safe but poor performance.
Decidenamed DIAGNOSIS, INSPECTION_ACTION, RETEST or SAFE_DEFAULT
Provemacro-F1, per-pathology recall, diagnosis latency and confusion…
Variant equipment · EQ-19-02
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensequadrature encoder/position feedback; conditioned 0–3.3 V current-sense chann…
Actuatelow-torque 6–12 V geared DC motor with encoder; 3.3-V-logic H-bridge rated ab…
Fixturestandard PID diagnostic rig with sealed sluggish-response profiles
Protectcurrent-limited 6–12 V DC supply; inline fuse plus spare fuses; latching E-st…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser labelled control-pathology episode set and metric-check traces
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Only bounded firmware test modes may inject faults; the host cannot write arbitrary gains or timing values. Verify the complete EQ-19-02 manifest before data collection.
1 · Scenario and student challenge
Identify excessively slow rise/settling. In plain language, adapt LoopDoctor — Automatic Control-Pathology Classifier so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Separates safe but poor performance.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M PID rig + the named safe mechanical/condition fixture. Begin with the H753-M PID bench with safe software-selectable test scenarios and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record setpoint, feedback, error, controller output/integral proxy, PWM, current, saturation, sample-period jitter and command age. Treat one segmented response episode with one declared injected pathology as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Pathology classification. First implement the parent baseline—hand-coded diagnostic rule tree—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only named DIAGNOSIS, INSPECTION_ACTION, RETEST or SAFE_DEFAULT, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with different pathologies that produce similar tracking error but different internal/timing evidence. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 19.02 — Sluggish-Loop Detector”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M PID rig + the named safe mechanical/condition fixtureclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P19 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Sluggish-Loop Detector is a syllabus-scaled physical analogue of the need evidenced by BM07 · RP-1587 Control Loop Performance Assessment: Identify excessively slow rise/settling. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needDevelop a metric for assessing control-loop performance and report field-testing work on control quality.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Use approved gain/profile IDs, test every operating region and reject a selection when its evidence is outside the validated envelope.
Students do not auto-tune arbitrary gains; ML only selects from faculty-approved sets.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationProvide safe pathology profiles and one matched benign response for every fault so diagnosis is not reduced to extreme-case recognition.
Variant 19.03
Output-Saturation Detector
Engineering purpose: Connects constraints to performance.
Decidenamed DIAGNOSIS, INSPECTION_ACTION, RETEST or SAFE_DEFAULT
Provemacro-F1, per-pathology recall, diagnosis latency and confusion…
Variant equipment · EQ-19-03
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensequadrature encoder/position feedback; conditioned 0–3.3 V current-sense chann…
Actuatelow-torque 6–12 V geared DC motor with encoder; 3.3-V-logic H-bridge rated ab…
Fixturestandard PID diagnostic rig with a firmware-bounded saturation target
Protectcurrent-limited 6–12 V DC supply; inline fuse plus spare fuses; latching E-st…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser labelled control-pathology episode set and metric-check traces
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Only bounded firmware test modes may inject faults; the host cannot write arbitrary gains or timing values. Verify the complete EQ-19-03 manifest before data collection.
1 · Scenario and student challenge
Detect long periods at PWM limit. In plain language, adapt LoopDoctor — Automatic Control-Pathology Classifier so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Connects constraints to performance.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M PID rig + the named safe mechanical/condition fixture. Begin with the H753-M PID bench with safe software-selectable test scenarios and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record setpoint, feedback, error, controller output/integral proxy, PWM, current, saturation, sample-period jitter and command age. Treat one segmented response episode with one declared injected pathology as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Classification using saturation features. First implement the parent baseline—hand-coded diagnostic rule tree—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only named DIAGNOSIS, INSPECTION_ACTION, RETEST or SAFE_DEFAULT, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with different pathologies that produce similar tracking error but different internal/timing evidence. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 19.03 — Output-Saturation Detector”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M PID rig + the named safe mechanical/condition fixtureclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P19 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Output-Saturation Detector is a syllabus-scaled physical analogue of the need evidenced by BM07 · RP-1587 Control Loop Performance Assessment: Detect long periods at PWM limit. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needDevelop a metric for assessing control-loop performance and report field-testing work on control quality.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Use approved gain/profile IDs, test every operating region and reject a selection when its evidence is outside the validated envelope.
Students do not auto-tune arbitrary gains; ML only selects from faculty-approved sets.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationProvide safe pathology profiles and one matched benign response for every fault so diagnosis is not reduced to extreme-case recognition.
LearnClassification from integral/output/error history.
Decidenamed DIAGNOSIS, INSPECTION_ACTION, RETEST or SAFE_DEFAULT
Provemacro-F1, per-pathology recall, diagnosis latency and confusion…
Variant equipment · EQ-19-04
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensequadrature encoder/position feedback; conditioned 0–3.3 V current-sense chann…
Actuatelow-torque 6–12 V geared DC motor with encoder; 3.3-V-logic H-bridge rated ab…
Fixturestandard PID diagnostic rig with safe saturation/recovery profile and anti-wi…
Protectcurrent-limited 6–12 V DC supply; inline fuse plus spare fuses; latching E-st…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser labelled control-pathology episode set and metric-check traces
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Only bounded firmware test modes may inject faults; the host cannot write arbitrary gains or timing values. Verify the complete EQ-19-04 manifest before data collection.
1 · Scenario and student challenge
Use safe setpoint/limit scenarios to expose slow recovery after saturation. In plain language, adapt LoopDoctor — Automatic Control-Pathology Classifier so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Directly reinforces syllabus anti-windup.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M PID rig + the named safe mechanical/condition fixture. Begin with the H753-M PID bench with safe software-selectable test scenarios and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record setpoint, feedback, error, controller output/integral proxy, PWM, current, saturation, sample-period jitter and command age. Treat one segmented response episode with one declared injected pathology as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Classification from integral/output/error history. First implement the parent baseline—hand-coded diagnostic rule tree—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only named DIAGNOSIS, INSPECTION_ACTION, RETEST or SAFE_DEFAULT, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with different pathologies that produce similar tracking error but different internal/timing evidence. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 19.04 — Integral-Windup Detector”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M PID rig + the named safe mechanical/condition fixtureclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P19 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Integral-Windup Detector is a syllabus-scaled physical analogue of the need evidenced by BM07 · RP-1587 Control Loop Performance Assessment: Use safe setpoint/limit scenarios to expose slow recovery after saturation. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needDevelop a metric for assessing control-loop performance and report field-testing work on control quality.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Use approved gain/profile IDs, test every operating region and reject a selection when its evidence is outside the validated envelope.
Students do not auto-tune arbitrary gains; ML only selects from faculty-approved sets.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationProvide safe pathology profiles and one matched benign response for every fault so diagnosis is not reduced to extreme-case recognition.
Variant 19.05
Feedback-Noise Detector
Engineering purpose: Differentiates noisy measurement from aggressive gains.
Decidenamed DIAGNOSIS, INSPECTION_ACTION, RETEST or SAFE_DEFAULT
Provemacro-F1, per-pathology recall, diagnosis latency and confusion…
Variant equipment · EQ-19-05
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensequadrature encoder/position feedback; conditioned 0–3.3 V current-sense chann…
Actuatelow-torque 6–12 V geared DC motor with encoder; 3.3-V-logic H-bridge rated ab…
Fixturestandard PID rig; firmware-selectable bounded feedback-noise profile; no anal…
Protectcurrent-limited 6–12 V DC supply; inline fuse plus spare fuses; latching E-st…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser labelled control-pathology episode set and metric-check traces
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Only bounded firmware test modes may inject faults; the host cannot write arbitrary gains or timing values. Verify the complete EQ-19-05 manifest before data collection.
1 · Scenario and student challenge
Inject bounded noise into feedback path. In plain language, adapt LoopDoctor — Automatic Control-Pathology Classifier so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Differentiates noisy measurement from aggressive gains.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M PID rig + the named safe mechanical/condition fixture. Begin with the H753-M PID bench with safe software-selectable test scenarios and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record setpoint, feedback, error, controller output/integral proxy, PWM, current, saturation, sample-period jitter and command age. Treat one segmented response episode with one declared injected pathology as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Sensor-noise classification. First implement the parent baseline—hand-coded diagnostic rule tree—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only named DIAGNOSIS, INSPECTION_ACTION, RETEST or SAFE_DEFAULT, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with different pathologies that produce similar tracking error but different internal/timing evidence. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 19.05 — Feedback-Noise Detector”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M PID rig + the named safe mechanical/condition fixtureclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P19 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Feedback-Noise Detector is a syllabus-scaled physical analogue of the need evidenced by BM07 · RP-1587 Control Loop Performance Assessment: Inject bounded noise into feedback path. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needDevelop a metric for assessing control-loop performance and report field-testing work on control quality.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Use approved gain/profile IDs, test every operating region and reject a selection when its evidence is outside the validated envelope.
Students do not auto-tune arbitrary gains; ML only selects from faculty-approved sets.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationProvide safe pathology profiles and one matched benign response for every fault so diagnosis is not reduced to extreme-case recognition.
Decidenamed DIAGNOSIS, INSPECTION_ACTION, RETEST or SAFE_DEFAULT
Provemacro-F1, per-pathology recall, diagnosis latency and confusion…
Variant equipment · EQ-19-06
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensequadrature encoder/position feedback; conditioned 0–3.3 V current-sense chann…
Actuatelow-torque 6–12 V geared DC motor with encoder; 3.3-V-logic H-bridge rated ab…
FixturePID rig with encoder-path fault switch; PASS/INTERMITTENT/DROPOUT switch bank
Protectcurrent-limited 6–12 V DC supply; inline fuse plus spare fuses; latching E-st…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser labelled control-pathology episode set and metric-check traces
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Only bounded firmware test modes may inject faults; the host cannot write arbitrary gains or timing values. Verify the complete EQ-19-06 manifest before data collection.
1 · Scenario and student challenge
Inject missing transitions. In plain language, adapt LoopDoctor — Automatic Control-Pathology Classifier so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Bridges sensors and control.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M PID rig + the named safe mechanical/condition fixture. Begin with the H753-M PID bench with safe software-selectable test scenarios and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record setpoint, feedback, error, controller output/integral proxy, PWM, current, saturation, sample-period jitter and command age. Treat one segmented response episode with one declared injected pathology as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Feedback-fault pathology classification. First implement the parent baseline—hand-coded diagnostic rule tree—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only named DIAGNOSIS, INSPECTION_ACTION, RETEST or SAFE_DEFAULT, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with different pathologies that produce similar tracking error but different internal/timing evidence. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 19.06 — Encoder-Dropout Detector”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M PID rig + the named safe mechanical/condition fixtureclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P19 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Encoder-Dropout Detector is a syllabus-scaled physical analogue of the need evidenced by BM07 · RP-1587 Control Loop Performance Assessment: Inject missing transitions. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needDevelop a metric for assessing control-loop performance and report field-testing work on control quality.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Use approved gain/profile IDs, test every operating region and reject a selection when its evidence is outside the validated envelope.
Students do not auto-tune arbitrary gains; ML only selects from faculty-approved sets.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationProvide safe pathology profiles and one matched benign response for every fault so diagnosis is not reduced to extreme-case recognition.
Variant 19.07
Steady-State-Bias Detector
Engineering purpose: Highlights integral action and calibration.
Decidenamed DIAGNOSIS, INSPECTION_ACTION, RETEST or SAFE_DEFAULT
Provemacro-F1, per-pathology recall, diagnosis latency and confusion…
Variant equipment · EQ-19-07
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensequadrature encoder/position feedback; conditioned 0–3.3 V current-sense chann…
Actuatelow-torque 6–12 V geared DC motor with encoder; 3.3-V-logic H-bridge rated ab…
FixturePID rig with bounded feedback-bias control; 10 kΩ bias potentiometer or fixed…
Protectcurrent-limited 6–12 V DC supply; inline fuse plus spare fuses; latching E-st…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser labelled control-pathology episode set and metric-check traces
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Only bounded firmware test modes may inject faults; the host cannot write arbitrary gains or timing values. Verify the complete EQ-19-07 manifest before data collection.
1 · Scenario and student challenge
Introduce safe measurement/plant bias. In plain language, adapt LoopDoctor — Automatic Control-Pathology Classifier so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Highlights integral action and calibration.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M PID rig + the named safe mechanical/condition fixture. Begin with the H753-M PID bench with safe software-selectable test scenarios and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record setpoint, feedback, error, controller output/integral proxy, PWM, current, saturation, sample-period jitter and command age. Treat one segmented response episode with one declared injected pathology as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Bias pathology classification. First implement the parent baseline—hand-coded diagnostic rule tree—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only named DIAGNOSIS, INSPECTION_ACTION, RETEST or SAFE_DEFAULT, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with different pathologies that produce similar tracking error but different internal/timing evidence. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 19.07 — Steady-State-Bias Detector”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M PID rig + the named safe mechanical/condition fixtureclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P19 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Steady-State-Bias Detector is a syllabus-scaled physical analogue of the need evidenced by BM07 · RP-1587 Control Loop Performance Assessment: Introduce safe measurement/plant bias. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needDevelop a metric for assessing control-loop performance and report field-testing work on control quality.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Use approved gain/profile IDs, test every operating region and reject a selection when its evidence is outside the validated envelope.
Students do not auto-tune arbitrary gains; ML only selects from faculty-approved sets.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationProvide safe pathology profiles and one matched benign response for every fault so diagnosis is not reduced to extreme-case recognition.
Decidenamed DIAGNOSIS, INSPECTION_ACTION, RETEST or SAFE_DEFAULT
Provemacro-F1, per-pathology recall, diagnosis latency and confusion…
Variant equipment · EQ-19-08
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensequadrature encoder/position feedback; conditioned 0–3.3 V current-sense chann…
Actuatelow-torque 6–12 V geared DC motor with encoder; 3.3-V-logic H-bridge rated ab…
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser labelled control-pathology episode set and metric-check traces
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Only bounded firmware test modes may inject faults; the host cannot write arbitrary gains or timing values. Verify the complete EQ-19-08 manifest before data collection.
1 · Scenario and student challenge
Inject bounded timing variation in noncritical test mode. In plain language, adapt LoopDoctor — Automatic Control-Pathology Classifier so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Uses timer/jitter syllabus explicitly.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M PID rig + the named safe mechanical/condition fixture. Begin with the H753-M PID bench with safe software-selectable test scenarios and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record setpoint, feedback, error, controller output/integral proxy, PWM, current, saturation, sample-period jitter and command age. Treat one segmented response episode with one declared injected pathology as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Timing-pathology classification. First implement the parent baseline—hand-coded diagnostic rule tree—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only named DIAGNOSIS, INSPECTION_ACTION, RETEST or SAFE_DEFAULT, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with different pathologies that produce similar tracking error but different internal/timing evidence. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 19.08 — Sampling-Jitter Detector”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M PID rig + the named safe mechanical/condition fixtureclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P19 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Sampling-Jitter Detector is a syllabus-scaled physical analogue of the need evidenced by BM07 · RP-1587 Control Loop Performance Assessment: Inject bounded timing variation in noncritical test mode. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needDevelop a metric for assessing control-loop performance and report field-testing work on control quality.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Use approved gain/profile IDs, test every operating region and reject a selection when its evidence is outside the validated envelope.
Students do not auto-tune arbitrary gains; ML only selects from faculty-approved sets.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationProvide safe pathology profiles and one matched benign response for every fault so diagnosis is not reduced to extreme-case recognition.
Variant 19.09
Stale-Setpoint Detector
Engineering purpose: Separates command-path issues from plant faults.
Decidenamed DIAGNOSIS, INSPECTION_ACTION, RETEST or SAFE_DEFAULT
Provemacro-F1, per-pathology recall, diagnosis latency and confusion…
Variant equipment · EQ-19-09
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensequadrature encoder/position feedback; conditioned 0–3.3 V current-sense chann…
Actuatelow-torque 6–12 V geared DC motor with encoder; 3.3-V-logic H-bridge rated ab…
Fixturestandard PID rig with host-command replay tool; stale/duplicate setpoint test…
Protectcurrent-limited 6–12 V DC supply; inline fuse plus spare fuses; latching E-st…
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser labelled control-pathology episode set and metric-check traces
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Only bounded firmware test modes may inject faults; the host cannot write arbitrary gains or timing values. Verify the complete EQ-19-09 manifest before data collection.
1 · Scenario and student challenge
Delay or repeat command frames while local loop continues. In plain language, adapt LoopDoctor — Automatic Control-Pathology Classifier so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Separates command-path issues from plant faults.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M PID rig + the named safe mechanical/condition fixture. Begin with the H753-M PID bench with safe software-selectable test scenarios and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record setpoint, feedback, error, controller output/integral proxy, PWM, current, saturation, sample-period jitter and command age. Treat one segmented response episode with one declared injected pathology as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Network/control diagnosis. First implement the parent baseline—hand-coded diagnostic rule tree—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only named DIAGNOSIS, INSPECTION_ACTION, RETEST or SAFE_DEFAULT, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with different pathologies that produce similar tracking error but different internal/timing evidence. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 19.09 — Stale-Setpoint Detector”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M PID rig + the named safe mechanical/condition fixtureclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P19 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Stale-Setpoint Detector is a syllabus-scaled physical analogue of the need evidenced by BM07 · RP-1587 Control Loop Performance Assessment: Delay or repeat command frames while local loop continues. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needDevelop a metric for assessing control-loop performance and report field-testing work on control quality.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Use approved gain/profile IDs, test every operating region and reject a selection when its evidence is outside the validated envelope.
Students do not auto-tune arbitrary gains; ML only selects from faculty-approved sets.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationProvide safe pathology profiles and one matched benign response for every fault so diagnosis is not reduced to extreme-case recognition.
Variant 19.10
Bumpless-Transfer Auditor
Engineering purpose: Uses the syllabus’s bumpless-transfer concept.
Decidenamed DIAGNOSIS, INSPECTION_ACTION, RETEST or SAFE_DEFAULT
Provemacro-F1, per-pathology recall, diagnosis latency and confusion…
Variant equipment · EQ-19-10
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Sensequadrature encoder/position feedback; conditioned 0–3.3 V current-sense chann…
Actuatelow-torque 6–12 V geared DC motor with encoder; 3.3-V-logic H-bridge rated ab…
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser labelled control-pathology episode set and metric-check traces
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Only bounded firmware test modes may inject faults; the host cannot write arbitrary gains or timing values. Verify the complete EQ-19-10 manifest before data collection.
1 · Scenario and student challenge
Compare approved manual-to-auto transitions and classify acceptable versus bump-prone episodes. In plain language, adapt LoopDoctor — Automatic Control-Pathology Classifier so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Uses the syllabus’s bumpless-transfer concept.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-M PID rig + the named safe mechanical/condition fixture. Begin with the H753-M PID bench with safe software-selectable test scenarios and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record setpoint, feedback, error, controller output/integral proxy, PWM, current, saturation, sample-period jitter and command age. Treat one segmented response episode with one declared injected pathology as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Pass/fail classification. First implement the parent baseline—hand-coded diagnostic rule tree—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only named DIAGNOSIS, INSPECTION_ACTION, RETEST or SAFE_DEFAULT, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with different pathologies that produce similar tracking error but different internal/timing evidence. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 19.10 — Bumpless-Transfer Auditor”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-M PID rig + the named safe mechanical/condition fixtureclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P19 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Bumpless-Transfer Auditor is a syllabus-scaled physical analogue of the need evidenced by BM07 · RP-1587 Control Loop Performance Assessment: Compare approved manual-to-auto transitions and classify acceptable versus bump-prone episodes. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needDevelop a metric for assessing control-loop performance and report field-testing work on control quality.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Use approved gain/profile IDs, test every operating region and reject a selection when its evidence is outside the validated envelope.
Students do not auto-tune arbitrary gains; ML only selects from faculty-approved sets.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationProvide safe pathology profiles and one matched benign response for every fault so diagnosis is not reduced to extreme-case recognition.
Problem 20 · 10 variants · Control engineering and data-quality intelligence
TelemetrySense — Regime-Aware Sampling, Logging and Dataset-Quality Manager
Team size: 4; approved 3-member exception1 × NUCLEO-H753ZIH753-S; M optionalClassificationAdvanced
Assigned Faculty Master pair for P20: one nominated ESD Faculty Master and one nominated ML Faculty Master shall jointly master this parent problem and variants V1-V10. The ESD Master owns hardware, firmware, control, communication and safety verification; the ML Master owns data, baselines, models, validation and bounded decision-policy verification. Together they teach and guide ten teams (one for each variant and up to 40 students), supervise five teams in Wave A and five in Wave B, witness integration and sign every final evaluation.
The problem
Embedded data is often either oversampled wastefully or collected too slowly to capture transients. Poor timestamps, dropped samples, mixed trials and uncontrolled rate changes also make the resulting ML dataset unreliable. The challenge is to build a system that recognises operating regimes and adjusts only the noncritical logging/telemetry profile while preserving the fixed control loop and producing portfolio-quality data.
Smart embedded product to build
Build a NUCLEO-H753ZI dataset-quality and adaptive-logging appliance around H753-S signals, adding H753-M telemetry only for motion variants. The control/safety loop remains fixed. A separate timer-driven acquisition/logging path uses only LOW, NORMAL, BURST or FAULT profiles and records actual timestamps, overrun, run and sequence counters. The host classifies steady, transition, anomaly or fault and recommends only a profile ID; the board reports the effective rate and returns to NORMAL on host loss.
NUCLEO-H753ZI realization and issued pack
NUCLEO-H753ZI / MB1364E with H753-S; add H753-M only for motor variants
timer-triggered ADC sensing and a separate immutable control/safety timer where actuation exists
whitelisted LOW, NORMAL, BURST and FAULT logging profiles
microsecond timestamp, sample/run sequence, overrun and missing-sample counters
USART3 VCP by default; FDCAN only when paired; optional local Ethernet mirror as stretch
host returns logging-profile ID, not a control-loop frequency or arbitrary timer value
LED/display reports effective profile and dataset-integrity state
Intelligence to incorporate
Features include recent slope, variance, range, event count, control error, saturation and missing-data indicators. Compare fixed-fast, fixed-slow and threshold-triggered baselines with a course-approved classifier. Evaluate event-capture recall, timestamp/data completeness, message/storage reduction and whether downstream model quality is preserved.
Permitted output/action set
LOW · NORMAL · BURST · FAULT · PROFILE_ID
Canonical family command contract: every parent brief, variant, host message and MCU acknowledgement for P20 shall use these exact identifiers. A variant may use only the applicable subset; it shall not introduce a synonym.
Core problem equipment · EQ-20-CORE
Complete equipment required for one core-problem team
Standalone family BOM. This list supports the parent problem itself. An allocated variant uses its own complete table later in this card. A component mentioned again in the fixture description is the same mounted unit, not another copy.
4 students; 3 by approved exception1 H753 board1 team laptopquantities per team
Controller1 H753 board + 1 laptop
SenseLM35-class temperature channel; LDR divider; 10 kΩ potentiometer; guarded eve…
ActuateNo powered actuator is required for the core data-quality problem; motion/lig…
Fixturesensor-stimulus board with repeatable light, temperature and potentiometer re…
ProtectUSB board-power path only for the core sensor/data-quality problem.
System block
Complete quantity and equipment per team
Purpose / acceptance condition
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser clean/corrupted telemetry set with missing, duplicate and out-of-order samples
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Release-to-team condition: Logging profiles may change only data capture/telemetry; the control/safety timer remains fixed. The organiser signs the electrical, mechanical and communication acceptance checklist before H0:00.
Not duplicated inside the kit: supervised rework tools and the oscilloscope/logic-analyser station are shared at the ratio stated above. Everything else in this table is issued to, reserved for, or digitally assigned to this team.
Controlled self-learning extension
Recommended Implement timer-triggered ADC plus a circular DMA pre-trigger buffer from the organiser-provided starter code. Quantify overrun, timestamp jitter and event retention against the polling/interrupt baseline.
System safety and non-negotiable boundary
The control sampling rate, watchdog and safety messages never change. On model/host loss, logging returns to NORMAL. Any rate profile is hard-coded and bounded; the project is not an RTOS scheduler.
Student interpretation — what this challenge really asks
High row count does not guarantee a useful dataset. Students separate the immutable control/safety rate from changeable logging rates and make missing, duplicate and mistimed samples observable.
Independent data unitone fixed-duration acquisition epoch or one labelled physical event.
Closest misleading casebrief benign noise that should not create a sustained burst or corrupt trial segmentation.
Definition of successStudents must reduce data volume on a hidden run without missing the declared event or altering the control loop.
Visual system blueprint
Physical processRegime-aware data acquisitionGenerate labelled, safe and repeatable conditions.
Observesensor/process values, slope/variance, control errorPreserve units, timestamps, run identity and signal quality.
H753 responsibilityControl and protectkeep control timing fixed, apply only approved logging profiles and report actual data integrity.
Host intelligenceLearn the distinctionclassify steady, transition, anomaly or fault regimes and choose a logging profile.
Bounded outcomeLOW · NORMAL · BURST · FAULT · PROFILE_IDMCU validates, acknowledges and may refuse the request.
Recommended build journey
Make the process repeatableAssemble the H753-S acquisition rig, adding H753-M only for motion variants; define reference and target conditions before collecting data.
Prove deterministic firmwareKeep control timing fixed, apply only approved logging profiles and report actual data integrity. Demonstrate every hard limit before connecting ML.
Build trustworthy trialsTreat one fixed-duration acquisition epoch or one labelled physical event as independent; calibrate, label and split by run/session.
Beat a real baselineCompare fixed-fast, fixed-slow and simple threshold-triggered logging with two syllabus-approved classical models.
Close and challenge the loopReturn only the applicable subset of LOW · NORMAL · BURST · FAULT · PROFILE_ID; test the target, nearest confuser, stale command and host loss.
Definition of done
Firmware controls safely before, during and after host connection.
Portfolio shows raw-versus-adaptive sampling timeline with captured/missed events and data-volume comparison and one honest failure case.
Problem-specific evidence at the common reviews
R1 · Design
Separate control and logging timing, define rate profiles/regimes, event-capture metric and immutable safety traffic.
R2 · Embedded
Demonstrate timer-separated acquisition/control/logging, sequence counters and profile switching.
R3 · Data
Submit fixed-rate traces, regime labels and data-quality baseline.
R4 · ML
Show regime classifier and quantify data reduction versus event capture/downstream model performance.
R5 · Integration
Integrate adaptive logging and pass transient, anomaly, missing-sample and host-loss tests.
Final
Capture a blind mixed-regime run with fewer messages while preserving all declared events and dataset integrity.
Portfolio/Kaggle outcome
Kaggle asset: paired raw and adaptively sampled datasets, regime labels, completeness report and downstream model experiment showing the effect of telemetry policy on ML quality.
Industry alignment and validation basis
TelemetrySense: external references and required evidence
The listed sources establish relevance, test discipline and implementation precedent. They do not modify the common syllabus boundary, safety rules or 100-mark assessment rubric.
Family implementation profile
Variant availability: 8 standard assignment(s); 2 organiser-supported assignment(s).
Public evidence: reproducible firmware, protocol, dataset, notebook/model, test report and demonstration video.
What the external benchmark confirms
The problem has a recognisable industrial or challenge analogue, a measurable data task, a defensible embedded implementation and a safe operational decision. Every one of its ten variants is mapped separately below.
Condition before team allocation
Standardise timestamp, sequence, drop/overrun and profile fields, then score both data utility and message/storage cost.
Specify end-to-end mechanisms for detecting loss, repetition, incorrect sequence, delay and corruption of communicated data.
Use counters, age/timeout, sequence and plausibility checks; demonstrate stale, duplicate and missing-data handling.
Open the 10 fully elaborated student variant briefs
Choose only the variant allocated to your team. Read it together with the parent problem above: the card expands the experimental delta, while every hardware, safety, integration and review requirement of the family remains active.
Variant 20.01
Steady-versus-Transient Logger
Engineering purpose: Simple, measurable and sensor-only.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
SenseLM35-class temperature channel; LDR divider; 10 kΩ potentiometer; guarded eve…
ActuateNo powered actuator is required for the core data-quality problem; motion/lig…
Fixturesensor-regime board; LDR, LM35, steady light source and repeatable transition…
ProtectUSB board-power path only for the core sensor/data-quality problem.
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser clean/corrupted telemetry set with missing, duplicate and out-of-order samples
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Logging profiles may change only data capture/telemetry; the control/safety timer remains fixed. Verify the complete EQ-20-01 manifest before data collection.
1 · Scenario and student challenge
Use low rate at steady state and burst during temperature/light transitions. In plain language, adapt TelemetrySense — Regime-Aware Sampling, Logging and Dataset-Quality Manager so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Simple, measurable and sensor-only.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-S; H753-M only for motion variants. Begin with the H753-S acquisition rig, adding H753-M only for motion variants and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record sensor/process values, slope/variance, control error, event flags, actual timestamp, sample sequence, overrun/drop count and active logging profile. Treat one fixed-duration acquisition epoch or one labelled physical event as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Regime classification. First implement the parent baseline—fixed-fast, fixed-slow and simple threshold-triggered logging—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only LOW, NORMAL, BURST or FAULT logging PROFILE_ID, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with brief benign noise that should not create a sustained burst or corrupt trial segmentation. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 20.01 — Steady-versus-Transient Logger”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-S; H753-M only for motion variantsclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P20 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Steady-versus-Transient Logger is a syllabus-scaled physical analogue of the need evidenced by IR02 · FP-IND-DATALOGMC Smart-Actuator Function Pack: Use low rate at steady state and burst during temperature/light transitions. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needCollect heterogeneous sensor and motor-control telemetry for real-time monitoring, performance assessment, labelling and Python-side data workflows.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Represent hidden tests as replayable scripts, record expected versus observed results and preserve evidence for every injected failure.
Students may use a simple Python replay/test runner; they do not need cFS or its framework.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationStandardise timestamp, sequence, drop/overrun and profile fields, then score both data utility and message/storage cost.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Senseencoder; 0–3.3 V current channel; LM35 channel
Actuategeared DC motor and 3.3-V H-bridge
Fixtureguarded motor startup logger rig; motor/encoder/H-bridge/current channel and…
Protectfused current-limited motor supply; physical E-stop
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser clean/corrupted telemetry set with missing, duplicate and out-of-order samples
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Logging profiles may change only data capture/telemetry; the control/safety timer remains fixed. Verify the complete EQ-20-02 manifest before data collection.
1 · Scenario and student challenge
Capture high rate only around start/stop transients. In plain language, adapt TelemetrySense — Regime-Aware Sampling, Logging and Dataset-Quality Manager so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Preserves startup signatures efficiently.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-S + H753-M motion telemetry. Begin with the H753-S acquisition rig, adding H753-M only for motion variants and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record sensor/process values, slope/variance, control error, event flags, actual timestamp, sample sequence, overrun/drop count and active logging profile. Treat one fixed-duration acquisition epoch or one labelled physical event as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Motion-phase classifier. First implement the parent baseline—fixed-fast, fixed-slow and simple threshold-triggered logging—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only LOW, NORMAL, BURST or FAULT logging PROFILE_ID, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with brief benign noise that should not create a sustained burst or corrupt trial segmentation. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 20.02 — Motor Startup Burst Logger”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P20 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Motor Startup Burst Logger is a syllabus-scaled physical analogue of the need evidenced by IR02 · FP-IND-DATALOGMC Smart-Actuator Function Pack: Capture high rate only around start/stop transients. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needCollect heterogeneous sensor and motor-control telemetry for real-time monitoring, performance assessment, labelling and Python-side data workflows.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Represent hidden tests as replayable scripts, record expected versus observed results and preserve evidence for every injected failure.
Students may use a simple Python replay/test runner; they do not need cFS or its framework.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationStandardise timestamp, sequence, drop/overrun and profile fields, then score both data utility and message/storage cost.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Senseencoder; 0–3.3 V current channel; LM35 channel
Actuategeared DC motor and 3.3-V H-bridge
Fixtureguarded motor fault-trigger logger rig; reversible load/jam insert and event…
Protectfused current-limited motor supply; physical E-stop
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser clean/corrupted telemetry set with missing, duplicate and out-of-order samples
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Logging profiles may change only data capture/telemetry; the control/safety timer remains fixed. Verify the complete EQ-20-03 manifest before data collection.
1 · Scenario and student challenge
Switch to rich logging when fault probability rises. In plain language, adapt TelemetrySense — Regime-Aware Sampling, Logging and Dataset-Quality Manager so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Improves failure evidence.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-S + H753-M motion telemetry. Begin with the H753-S acquisition rig, adding H753-M only for motion variants and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record sensor/process values, slope/variance, control error, event flags, actual timestamp, sample sequence, overrun/drop count and active logging profile. Treat one fixed-duration acquisition epoch or one labelled physical event as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Fault-risk classification. First implement the parent baseline—fixed-fast, fixed-slow and simple threshold-triggered logging—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only LOW, NORMAL, BURST or FAULT logging PROFILE_ID, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with brief benign noise that should not create a sustained burst or corrupt trial segmentation. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 20.03 — Fault-Triggered Diagnostic Logger”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P20 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Fault-Triggered Diagnostic Logger is a syllabus-scaled physical analogue of the need evidenced by IR02 · FP-IND-DATALOGMC Smart-Actuator Function Pack: Switch to rich logging when fault probability rises. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needCollect heterogeneous sensor and motor-control telemetry for real-time monitoring, performance assessment, labelling and Python-side data workflows.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Represent hidden tests as replayable scripts, record expected versus observed results and preserve evidence for every injected failure.
Students may use a simple Python replay/test runner; they do not need cFS or its framework.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationStandardise timestamp, sequence, drop/overrun and profile fields, then score both data utility and message/storage cost.
Variant 20.04
Control-Error-Aware Logger
Engineering purpose: Links data rate to control quality.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
Senseencoder; 0–3.3 V current channel; LM35 channel
Actuategeared DC motor and 3.3-V H-bridge
Fixtureguarded closed-loop motor logger rig; target/load profile card and saturation…
Protectfused current-limited motor supply; physical E-stop
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser clean/corrupted telemetry set with missing, duplicate and out-of-order samples
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Logging profiles may change only data capture/telemetry; the control/safety timer remains fixed. Verify the complete EQ-20-04 manifest before data collection.
1 · Scenario and student challenge
Increase logging when tracking error or saturation pattern changes. In plain language, adapt TelemetrySense — Regime-Aware Sampling, Logging and Dataset-Quality Manager so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Links data rate to control quality.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-S + H753-M motion telemetry. Begin with the H753-S acquisition rig, adding H753-M only for motion variants and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record sensor/process values, slope/variance, control error, event flags, actual timestamp, sample sequence, overrun/drop count and active logging profile. Treat one fixed-duration acquisition epoch or one labelled physical event as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Control-regime classification. First implement the parent baseline—fixed-fast, fixed-slow and simple threshold-triggered logging—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only LOW, NORMAL, BURST or FAULT logging PROFILE_ID, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with brief benign noise that should not create a sustained burst or corrupt trial segmentation. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 20.04 — Control-Error-Aware Logger”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P20 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Control-Error-Aware Logger is a syllabus-scaled physical analogue of the need evidenced by IR02 · FP-IND-DATALOGMC Smart-Actuator Function Pack: Increase logging when tracking error or saturation pattern changes. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needCollect heterogeneous sensor and motor-control telemetry for real-time monitoring, performance assessment, labelling and Python-side data workflows.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Represent hidden tests as replayable scripts, record expected versus observed results and preserve evidence for every injected failure.
Students may use a simple Python replay/test runner; they do not need cFS or its framework.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationStandardise timestamp, sequence, drop/overrun and profile fields, then score both data utility and message/storage cost.
Variant 20.05
Thermal-Slope Logger
Engineering purpose: Supports long low-activity thermal runs.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
SenseLM35-class channels: process and ambient; event push-button; display/LED indi…
ActuateNo powered actuator is required for the core data-quality problem; motion/lig…
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser clean/corrupted telemetry set with missing, duplicate and out-of-order samples
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Logging profiles may change only data capture/telemetry; the control/safety timer remains fixed. Verify the complete EQ-20-05 manifest before data collection.
1 · Scenario and student challenge
Use forecast-risk class to select temperature logging rate. In plain language, adapt TelemetrySense — Regime-Aware Sampling, Logging and Dataset-Quality Manager so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Supports long low-activity thermal runs.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-S; H753-M only for motion variants. Begin with the H753-S acquisition rig, adding H753-M only for motion variants and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record sensor/process values, slope/variance, control error, event flags, actual timestamp, sample sequence, overrun/drop count and active logging profile. Treat one fixed-duration acquisition epoch or one labelled physical event as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Risk classification. First implement the parent baseline—fixed-fast, fixed-slow and simple threshold-triggered logging—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only LOW, NORMAL, BURST or FAULT logging PROFILE_ID, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with brief benign noise that should not create a sustained burst or corrupt trial segmentation. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 20.05 — Thermal-Slope Logger”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-S; H753-M only for motion variantsclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P20 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Thermal-Slope Logger is a syllabus-scaled physical analogue of the need evidenced by IR02 · FP-IND-DATALOGMC Smart-Actuator Function Pack: Use forecast-risk class to select temperature logging rate. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needCollect heterogeneous sensor and motor-control telemetry for real-time monitoring, performance assessment, labelling and Python-side data workflows.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Represent hidden tests as replayable scripts, record expected versus observed results and preserve evidence for every injected failure.
Students may use a simple Python replay/test runner; they do not need cFS or its framework.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationStandardise timestamp, sequence, drop/overrun and profile fields, then score both data utility and message/storage cost.
Variant 20.06
Light-Scan Smart Logger
Engineering purpose: Reduces scan data while retaining useful resolution.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
SenseLDR 0–3.3 V channel; servo-angle reference/feedback
Actuateexternally powered low-torque servo
Fixturebounded-angle light-scan logger; LDR, diffused LED source, externally powered…
Protectfused regulated 5 V servo/light supply; hardware servo switch and travel stops
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser clean/corrupted telemetry set with missing, duplicate and out-of-order samples
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Logging profiles may change only data capture/telemetry; the control/safety timer remains fixed. Verify the complete EQ-20-06 manifest before data collection.
1 · Scenario and student challenge
Allocate samples densely near predicted light peak and sparsely elsewhere from approved angle grid. In plain language, adapt TelemetrySense — Regime-Aware Sampling, Logging and Dataset-Quality Manager so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Reduces scan data while retaining useful resolution.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-S + externally powered low-force servo scan fixture. Begin with the H753-S acquisition rig, adding H753-M only for motion variants and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record sensor/process values, slope/variance, control error, event flags, actual timestamp, sample sequence, overrun/drop count and active logging profile. Treat one fixed-duration acquisition epoch or one labelled physical event as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Peak-region classification. First implement the parent baseline—fixed-fast, fixed-slow and simple threshold-triggered logging—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only LOW, NORMAL, BURST or FAULT logging PROFILE_ID, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with brief benign noise that should not create a sustained burst or corrupt trial segmentation. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 20.06 — Light-Scan Smart Logger”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P20 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Light-Scan Smart Logger is a syllabus-scaled physical analogue of the need evidenced by IR02 · FP-IND-DATALOGMC Smart-Actuator Function Pack: Allocate samples densely near predicted light peak and sparsely elsewhere from approved angle grid. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needCollect heterogeneous sensor and motor-control telemetry for real-time monitoring, performance assessment, labelling and Python-side data workflows.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Represent hidden tests as replayable scripts, record expected versus observed results and preserve evidence for every injected failure.
Students may use a simple Python replay/test runner; they do not need cFS or its framework.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationStandardise timestamp, sequence, drop/overrun and profile fields, then score both data utility and message/storage cost.
Variant 20.07
Dataset-Completeness Guardian
Engineering purpose: Turns instrumentation integrity into the product.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
SenseLM35-class temperature channel; LDR divider; 10 kΩ potentiometer; guarded eve…
ActuateNo powered actuator is required for the core data-quality problem; motion/lig…
Fixturesensor data-integrity panel; LDR, LM35, potentiometer and a guarded packet dr…
ProtectUSB board-power path only for the core sensor/data-quality problem.
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser clean/corrupted telemetry set with missing, duplicate and out-of-order samples
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Logging profiles may change only data capture/telemetry; the control/safety timer remains fixed. Verify the complete EQ-20-07 manifest before data collection.
1 · Scenario and student challenge
Detect missing/duplicate/out-of-order samples and classify dataset health. In plain language, adapt TelemetrySense — Regime-Aware Sampling, Logging and Dataset-Quality Manager so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Turns instrumentation integrity into the product.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-S; H753-M only for motion variants. Begin with the H753-S acquisition rig, adding H753-M only for motion variants and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record sensor/process values, slope/variance, control error, event flags, actual timestamp, sample sequence, overrun/drop count and active logging profile. Treat one fixed-duration acquisition epoch or one labelled physical event as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Data-quality classification. First implement the parent baseline—fixed-fast, fixed-slow and simple threshold-triggered logging—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only LOW, NORMAL, BURST or FAULT logging PROFILE_ID, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with brief benign noise that should not create a sustained burst or corrupt trial segmentation. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 20.07 — Dataset-Completeness Guardian”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-S; H753-M only for motion variantsclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P20 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Dataset-Completeness Guardian is a syllabus-scaled physical analogue of the need evidenced by IR02 · FP-IND-DATALOGMC Smart-Actuator Function Pack: Detect missing/duplicate/out-of-order samples and classify dataset health. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needCollect heterogeneous sensor and motor-control telemetry for real-time monitoring, performance assessment, labelling and Python-side data workflows.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Represent hidden tests as replayable scripts, record expected versus observed results and preserve evidence for every injected failure.
Students may use a simple Python replay/test runner; they do not need cFS or its framework.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationStandardise timestamp, sequence, drop/overrun and profile fields, then score both data utility and message/storage cost.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
SenseLM35-class temperature channel; LDR divider; 10 kΩ potentiometer; guarded eve…
ActuateNo powered actuator is required for the core data-quality problem; motion/lig…
Fixtureevent-segmentation sensor panel; LDR/LM35 stimulus, run-start button and labe…
ProtectUSB board-power path only for the core sensor/data-quality problem.
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser clean/corrupted telemetry set with missing, duplicate and out-of-order samples
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Logging profiles may change only data capture/telemetry; the control/safety timer remains fixed. Verify the complete EQ-20-08 manifest before data collection.
1 · Scenario and student challenge
Classify start, steady, disturbance and stop segments before dataset export. In plain language, adapt TelemetrySense — Regime-Aware Sampling, Logging and Dataset-Quality Manager so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Produces cleaner Kaggle datasets.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-S; H753-M only for motion variants. Begin with the H753-S acquisition rig, adding H753-M only for motion variants and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record sensor/process values, slope/variance, control error, event flags, actual timestamp, sample sequence, overrun/drop count and active logging profile. Treat one fixed-duration acquisition epoch or one labelled physical event as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Multiclass regime classification. First implement the parent baseline—fixed-fast, fixed-slow and simple threshold-triggered logging—and then compare two algorithms from the faculty-issued ML whitelist. Report a confusion matrix, macro-F1 and the recall/false-alarm rate for the operationally dangerous or costly class. Inspect errors by load, direction, temperature, device or other relevant context rather than reporting accuracy alone. Produce a confusion matrix plus one synchronized physical-signal decision timeline.
5 · Embedded integration and safe response
The host may return only LOW, NORMAL, BURST or FAULT logging PROFILE_ID, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with brief benign noise that should not create a sustained burst or corrupt trial segmentation. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 20.08 — Run-Segmentation Assistant”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-S; H753-M only for motion variantsclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P20 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Run-Segmentation Assistant is a syllabus-scaled physical analogue of the need evidenced by IR02 · FP-IND-DATALOGMC Smart-Actuator Function Pack: Classify start, steady, disturbance and stop segments before dataset export. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needCollect heterogeneous sensor and motor-control telemetry for real-time monitoring, performance assessment, labelling and Python-side data workflows.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Represent hidden tests as replayable scripts, record expected versus observed results and preserve evidence for every injected failure.
Students may use a simple Python replay/test runner; they do not need cFS or its framework.
Implementation modeStandard assignmentMay be issued when the listed equipment, common starter package and hidden-test protocol are available.
Required organiser provisionComplete before team allocationStandardise timestamp, sequence, drop/overrun and profile fields, then score both data utility and message/storage cost.
Variant 20.09
Downstream-Accuracy Preserving Logger
Engineering purpose: Connects acquisition policy to ML utility.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
SenseLM35-class temperature channels; event button; display/LED indication
ActuateNo powered actuator is required for the core data-quality problem; motion/lig…
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × organiser reference model and tolerance-scoring dataset
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Logging profiles may change only data capture/telemetry; the control/safety timer remains fixed. Verify the complete EQ-20-09 manifest before data collection.
1 · Scenario and student challenge
Choose a rate profile that keeps a chosen baseline model within an accuracy tolerance. In plain language, adapt TelemetrySense — Regime-Aware Sampling, Logging and Dataset-Quality Manager so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Connects acquisition policy to ML utility.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-S; H753-M only for motion variants. Begin with the H753-S acquisition rig, adding H753-M only for motion variants and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record sensor/process values, slope/variance, control error, event flags, actual timestamp, sample sequence, overrun/drop count and active logging profile. Treat one fixed-duration acquisition epoch or one labelled physical event as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Rate-policy classification plus downstream evaluation. First implement the parent baseline—fixed-fast, fixed-slow and simple threshold-triggered logging—and then compare two algorithms from the faculty-issued ML whitelist. Report correct/feasible selection rate, constraint violations and improvement over the fixed policy. A choice is wrong if it violates a declared current, timing, thermal or control-quality bound even when it is fast. Produce a candidate-outcome/constraint table showing why the selected option is feasible.
5 · Embedded integration and safe response
The host may return only LOW, NORMAL, BURST or FAULT logging PROFILE_ID, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with brief benign noise that should not create a sustained burst or corrupt trial segmentation. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 20.09 — Downstream-Accuracy Preserving Logger”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-S; H753-M only for motion variantsclassification/decisionrun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P20 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Downstream-Accuracy Preserving Logger is a syllabus-scaled physical analogue of the need evidenced by IR02 · FP-IND-DATALOGMC Smart-Actuator Function Pack: Choose a rate profile that keeps a chosen baseline model within an accuracy tolerance. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needCollect heterogeneous sensor and motor-control telemetry for real-time monitoring, performance assessment, labelling and Python-side data workflows.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Represent hidden tests as replayable scripts, record expected versus observed results and preserve evidence for every injected failure.
Students may use a simple Python replay/test runner; they do not need cFS or its framework.
Implementation modeOrganiser-supported assignmentMay be issued only after the named seed history, reference specimens, calibration set or controlled fixture is prepared.
Required organiser provisionComplete before team allocationStandardise timestamp, sequence, drop/overrun and profile fields, then score both data utility and message/storage cost.
Variant 20.10
Active-Test Recommendation Logger
Engineering purpose: Improves dataset diversity without autonomous experimentation.
Complete equipment required for this variant: one team
This is a full standalone packing list, not a delta. Do not add a second parent fixture when the variant names a replacement. A sensor/actuator named again as part of the fixture is the same mounted unit, not another copy.
4 students planned; 3 by approved exception1 H753 board1 laptop
Controller1 H753 board + 1 laptop
SenseLM35-class temperature channel; LDR divider; 10 kΩ potentiometer; guarded eve…
ActuateNo powered actuator is required for the core data-quality problem; motion/lig…
Fixturecoverage-driven sensor test panel; LDR, LM35, potentiometer and a card of saf…
ProtectUSB board-power path only for the core sensor/data-quality problem.
System block
Complete quantity and equipment per team
Why it is required
Controller & host
1 × NUCLEO-H753ZI / MB1364E board with onboard STLINK-V3E
1 × data-capable USB-A/USB-C-to-Micro-B cable
1 × 64-bit team laptop, minimum 8 GB RAM, 10 GB free storage and charger
1 × offline software image containing STM32CubeIDE/CubeMX, ST-LINK driver, Git, Python 3, Jupyter, pandas, NumPy, scikit-learn, matplotlib and the organiser serial logger
1 × smartphone/camera capable of 1080p video plus 1 × tabletop stand and charging cable for mandatory review video logs
Firmware build/debug, telemetry capture, classical-ML training/inference and evidence packaging.
Interface & wiring
1 × full-size solderless breadboard, used for logic/sensor signals only
1 × labelled seed-data bundle with data dictionary and run-level split guidance
1 × reviewer-held hidden-test script/condition list; teams receive only the public acceptance contract
1 × coverage matrix showing allowed but initially underrepresented test cells
Required non-hardware resources; these prevent 24-hour teams from fabricating rare history or unsafe faults.
Kit acceptance: Logging profiles may change only data capture/telemetry; the control/safety timer remains fixed. Verify the complete EQ-20-10 manifest before data collection.
1 · Scenario and student challenge
Recommend the next safe pre-approved test condition that fills a coverage gap. In plain language, adapt TelemetrySense — Regime-Aware Sampling, Logging and Dataset-Quality Manager so it can recognise or predict this specific condition rather than treating it as an ordinary parent-family run. The engineering reason is: Improves dataset diversity without autonomous experimentation.
2 · What to build or modify
Allocated hardware: 1 × H753 + H753-S; H753-M only for motion variants. Begin with the H753-S acquisition rig, adding H753-M only for motion variants and implement the physical delta stated in the scenario. Change only the approved condition, proxy, test sequence or fixture element named above. Preserve the 0–3.3 V signal contract and deterministic safety path. Create a repeatable reference setup and at least one repeatable target setup; photograph and document both.
3 · Signals and experiment design
Record sensor/process values, slope/variance, control error, event flags, actual timestamp, sample sequence, overrun/drop count and active logging profile. Treat one fixed-duration acquisition epoch or one labelled physical event as one independent example. Add variant_id, condition_id, run_id, operator-set severity/target and calibration version. Normally collect 6–10 short independent safe runs per state plus organiser seed data; reviewers may approve fewer long thermal/health runs. Split by run/device/session, never adjacent rows.
4 · Intelligence, baseline and metrics
Required ML task: Coverage-class prediction/rule hybrid. First implement the parent baseline—fixed-fast, fixed-slow and simple threshold-triggered logging—and then compare two algorithms from the faculty-issued ML whitelist. Report MAE and RMSE on whole held-out runs, show predicted-versus-measured values, and inspect error by operating condition. If the target is converted to a safe/unsafe decision, also report missed-unsafe and unnecessary-conservative actions. Produce a predicted-versus-measured plot with residuals by operating condition.
5 · Embedded integration and safe response
The host may return only LOW, NORMAL, BURST or FAULT logging PROFILE_ID, with model version, confidence band, command sequence and expiry. The H753 checks the request against its local state and hard limits, records accepted/rejected plus reason code, and continues safely if the model, logger or communication link disappears. Raw model-to-PWM or model-written PID gains remain prohibited.
6 · Common confusion to test
Do not train and demonstrate only the easiest extremes. Select the two nearest states, severities or outcomes named or implied by this variant and show that the system separates them. Also challenge it with brief benign noise that should not create a sustained burst or corrupt trial segmentation. These are the cases that reveal whether the model learned the engineering distinction or merely memorised an obvious threshold.
7 · Live acceptance test and portfolio evidence
Without retraining or editing thresholds, demonstrate one reference run, one target run implementing the scenario above and one nearest-confuser run. Show raw H753 telemetry, feature window, prediction/confidence, recommendation, MCU acknowledgement/reason and physical outcome; then disconnect the host and show the inherited safe state. Publish a README subsection titled “Variant 20.10 — Active-Test Recommendation Logger”, the labelled run manifest, the required plot, baseline-versus-model table, one misclassification/residual case and a short statement of where the solution should abstain.
1 × H753 + H753-S; H753-M only for motion variantsregression/outcomerun-wise splitbaseline requiredbounded action
Common requirements: the parent family’s NUCLEO-H753ZI realization, add-on pack, electrical/mechanical limits, common 24-hour reviews, video logs, deliverables and 100-mark rubric. Faculty supervision: this variant remains under the same P20 ESD/ML Faculty Master pair, completes the 24-hour Learnathon gates L1-L4, preserves the learnathon-close archive, follows provenance controls and receives joint technical evaluation during competition.
Active-Test Recommendation Logger is a syllabus-scaled physical analogue of the need evidenced by IR02 · FP-IND-DATALOGMC Smart-Actuator Function Pack: Recommend the next safe pre-approved test condition that fills a coverage gap. The cited source informs the engineering context and validation method; the assigned implementation remains governed by this handbook.
Industry needCollect heterogeneous sensor and motor-control telemetry for real-time monitoring, performance assessment, labelling and Python-side data workflows.
Course implementationBuild and test the safe, low-voltage experiment already specified in this card.
Required proofBeat the stated baseline on a held-out target and its nearest confuser, then prove MCU-safe action.
Represent hidden tests as replayable scripts, record expected versus observed results and preserve evidence for every injected failure.
Students may use a simple Python replay/test runner; they do not need cFS or its framework.
Implementation modeOrganiser-supported assignmentMay be issued only after the named seed history, reference specimens, calibration set or controlled fixture is prepared.
Required organiser provisionComplete before team allocationStandardise timestamp, sequence, drop/overrun and profile fields, then score both data utility and message/storage cost.
Appendix A · Hardware, curriculum and implementation references
Authoritative technical references
Board identity and facilities
ST NUCLEO-H753ZI product page — official order code, STM32H753 target MCU, STLINK-V3E, expansion connectors, Ethernet and USB facilities.
KL Y25 B.Tech programme structures — official course identity and curricular context. The final ML algorithm whitelist must still match the modules actually taught before the event.
FDCAN implementation requirement: the STM32H753 provides FDCAN controller peripherals; the NUCLEO-H753ZI board does not provide the complete external physical layer. Every physical FDCAN assignment therefore includes one compatible transceiver per node, bus wiring and termination through the H753-N pack.
Appendix B · Industry alignment and validation references
Industry relevance and external reference framework
Each problem family and variant is connected to an external challenge, industrial use case, benchmark dataset, official reference implementation, standard or white paper. These sources establish professional relevance and validation discipline; the student scope, hardware implementation and assessment requirements are defined by this handbook.
200 / 200variants with named external references
20 / 20families with industry or benchmark alignment
35authoritative reference sources
5families with a direct challenge analogue
161standard assignments
39organiser-supported assignments
Purpose of the mapping: references are provided so faculty and students can connect each prototype to a recognisable engineering need, adopt defensible test methods and position the resulting firmware, dataset and model as credible portfolio evidence.
Organiser-supported assignments: 39 variants depend on long-horizon history, unseen specimens, repeatable thermal episodes, calibration-transfer data or controlled fault fixtures that cannot be produced fairly within 24 hours. These assignments shall not be issued until the named resource is available.
How external evidence informs each assignment
DChallengeWhat competitors were asked to predict or diagnose
A/BUse case + dataWhy industry cares and how evaluation is structured
R/S/WImplementation + assuranceInterfaces, telemetry, limits, tests and failure semantics
H753Syllabus translationLow-voltage hardware, classical host ML and bounded MCU action
ProofHidden acceptanceBaseline, held-out confuser, link loss and portfolio evidence
Coverage across reference types
Counts indicate how many of the 20 problem families use at least one source of each type. A source may appropriately support more than one type of evidence.
Challenge / prize
7/20
Industry use case
16/20
Benchmark data
15/20
Official repository
12/20
Standard / guidance
14/20
White paper
16/20
Reference classification and permitted use
Relationship codes
D direct challenge/task analogue · A strong industry analogue · B benchmark dataset/case · R official reference implementation · S standard/guidance · W white paper. An A/B/R/S/W link supports quality but is not claimed as identical wording.
Evidence required from each family
Every family must retain a clear engineering purpose, meaningful embedded implementation, syllabus-aligned ML task, baseline, held-out validation, bounded MCU action, 24-hour feasibility and portfolio evidence.
Requirements applicable to every variant
The variant must provide a substantive experimental change, measurable target, real embedded work, baseline/model comparison, nearest-confuser test, safe bounded response and a complete equipment manifest.
Excluded technical scope
Deep learning, TinyML, RTOS, cloud infrastructure, FFT/DSP, arbitrary gain generation, offensive CAN activity and direct ML-to-PWM control are not mandatory and shall not replace the specified course outcomes.
Problem-family industry reference matrix
Evidence-tier meaning: Tier 1 indicates a direct task/challenge or benchmark alignment; Tier 2 indicates a strong industry-use-case or benchmark analogue; Tier 3 indicates reference-architecture, standard or guidance support. A higher tier means closer task similarity, not higher student difficulty or guaranteed quality.
Seed data or controlled fixture required before allocation
Authoritative source registry
The following sources provide the industrial context, datasets, implementation precedents and assurance practices used in the challenge bank. External links support faculty follow-up. Technologies not stated in a problem or variant do not become hackathon requirements.
Standardise HVAC control sequences to improve energy efficiency, performance and control stability while enabling real-time fault detection and diagnostics.
The handbook uses a safe miniature thermal/fan process rather than claiming building-code or Guideline 36 compliance.
Identify model portability, sensor calibration drift, context change and maintenance events as central challenges for data-derived virtual measurements.
Semiconductor-process complexity is reduced to a transparent low-voltage virtual-sensor experiment.
3, 11
Appendix C · Academic adoption and attainment mapping
Course alignment, approval fields and attainment evidence
The event integrates Embedded System Design and IoT (25EC2206E) with Machine Learning (25SC2107E). The domains below are operational event outcomes. Official CO wording, CO numbers, PO/PSO mapping, credit ownership and conversion of competition marks must be entered only from approved university documents.
Hackathon outcome
Observable attainment evidence
Primary course-aligned domain
Rubric evidence
HAO1 Engineer a safe STM32 sensing/control system
Pin/peripheral plan, timed acquisition, driver interface, interlocks and safe state
ESD
Reviews 1–2 and 5
HAO2 Produce trustworthy experimental data
Calibration, run manifest, labels, units, provenance and leakage-safe split
ESD + ML
Review 3
HAO3 Build and evaluate classical ML
Engineering baseline, two permitted models, suitable metrics and error analysis
ML
Review 4
HAO4 Integrate bounded intelligence safely
Canonical command, expiry/range checks, acknowledgement, latency and fallback
ESD + ML
Review 5
HAO5 Demonstrate originality and reproducibility
Repository history, individual viva, raw evidence, checksums and repeatable build
Both courses
All gates + final
HAO6 Communicate engineering decisions and limitations
Review briefs, video logs, model card, test report, presentation and portfolio
Both courses
Final presentation
Departmental approval register
Approved ESD CO identifiers and verbatim statements
Assessment status: the 100-mark rubric is the competition assessment unless the department formally approves its use within either course. For an approved attainment calculation, report criterion-level achievement as the number of eligible students meeting the department-approved threshold divided by the number of eligible assessed students; preserve the underlying team and individual-viva evidence.