Lecture 06: Course Synthesis

Obuda University -- Embedded Systems

Week 11 | Final lecture before Demo Day

Your Learning Arc

Foundation (Weeks 1--2): What is Embedded?, GPIO, Sensors ✓
Sensing & Signals (Weeks 3--4): ADC, I2C, PWM basics, Ultrasonic ✓
Movement & Control (Weeks 5--6): Motor physics, P-control, IMU ✓
Software (Weeks 7--8): State Machines, Abstraction ✓
Engineering (Weeks 9--10): Software Engineering, Integration ✓
Synthesis (Weeks 11--12): Course Synthesis, Demo ← you are here

The Patterns You Used

Since Week 1, every session mapped to the same two processes:

5-Step Integration: UNDERSTAND → COMMUNICATE → CONNECT → IMPLEMENT → VERIFY

Engineering Design Cycle: MEASURE → MODEL → DESIGN → VALIDATE → ITERATE

The processes did not change -- you changed. In Week 1 you needed the steps spelled out. By Week 10 you applied them without thinking.

That is what learning looks like: conscious steps become intuition.

The Past Two Weeks -- Project Work

You built your robot -- not the course's robot, but yours.

Chose features to integrate and how they work together
Built custom behavior reflecting your own design choices
Validated with data: test results, measurements, statistical evidence
Prepared to present and defend your design decisions

What you discovered: - Integration is harder than individual pieces - Data matters at every level -- not just for tuning PID - Trade-offs are everywhere: speed vs reliability, complexity vs maintainability

The Big Question

You have spent 11 weeks building a robot from scratch. You went from blinking an LED to a multi-sensor autonomous system with data-driven validation.

But what did you actually learn?

Not about robots -- about engineering?

Today we step back and see the full picture.

What You Already Know (Everything!)

From...	You learned...	You applied it in...
Electronics	Circuits, voltage, current, digital logic	Sensor wiring, ADC range, pull-ups, motor drivers
Programming	Code structure, debugging, data types	Every lab — from `Pin.value()` to state machines
Control Theory	Feedback, PID, stability, tuning	P-control for line following, heading control, velocity
Physics	Mechanics, sound, light, magnetism	Motor torque, ultrasonic distance, IR reflectance
This course	Integration of all the above on real hardware	Your robot — the vehicle for learning engineering

Today: step back and see the connections. The robot was the vehicle, engineering process is the destination.

Today's Map

Two Repeating Processes
The 9 Implementations
Connecting the Dots
Data-Driven Calibration
Python vs C: The Full Comparison
The Embedded Landscape
Industry Best Practices
What Makes an Engineer
Exercise: Retrospective -- Map Your Robot Journey
Demo Day Prep

Block 1

What You Actually Learned

Two Processes, Not Six Lectures

Looking back, every lecture and every lab followed the same two processes. You applied them repeatedly, to different hardware and different problems.

Recognizing these patterns is the real takeaway.

Process 1: The 5-Step Integration Process Process 2: The Engineering Design Cycle

The 5-Step Integration Process

Every time you added new hardware, you followed this sequence:

UNDERSTAND  -->  COMMUNICATE  -->  CONNECT  -->  IMPLEMENT  -->  VERIFY

Step	What It Means
Understand	What does the device do? How does it work physically?
Communicate	Which protocol? GPIO, PWM, I2C, ADC?
Connect	Correct pins, pull-ups, wiring
Implement	Library calls, register reads, driver code
Verify	Test with known inputs, compare expected vs actual

Integration Process: Lab by Lab

Week	Feature	Understand	Communicate	Connect	Implement	Verify
1-2	LEDs, Buzzer	RGB, PWM freq	GPIO, PIO	Pins	Library calls	Visual/Audio
3-4	Motors, Line sensors	DC motor, H-bridge, reflective opto	PWM, ADC/GPIO	Driver board, pull-ups	set_speeds(), read pins	Movement, known surface
5-6	IMU, Ultrasonic	6-axis accel+gyro, echo timing	I2C, pulse width	SDA/SCL, trigger/echo	Register reads, time_pulse_us	Known orientation, known distance
7-8	Data logging, Control	Experimental method, P-control	File I/O, math	SD/flash	Logger, PID	Statistical proof
9-10	Architecture, Integration	Modularity, system design	Interfaces, APIs	Module boundaries	Clean layers	10 consecutive runs

This process is not robot-specific. Every embedded engineer follows the same steps.

The Engineering Design Cycle

Every time you solved a problem, you followed this cycle:

MEASURE  -->  MODEL  -->  DESIGN  -->  VALIDATE  -->  iterate

Step	What It Means
Measure	Observe and quantify the problem
Model	Build a mental model of the cause
Design	Create a solution based on the model
Validate	Test the solution with data
Iterate	Refine based on results

Design Cycle: Lab by Lab

Week	Measure	Model	Design	Validate
3-4	Motors drift	"Motors differ"	Open-loop correction	Drift measured
5	Oscillation	"Bang-bang overcorrects"	P-control	Smooth tracking
5-6	Heading error	"Gyro drifts over time"	Calibration + integration	Precise turns
7	Blocking	"Ultrasonic freezes loop"	Non-blocking pattern	Steady timing
8	"Kind of works"	"Need data to decide"	Experimental method	Statistical proof
9-10	Spaghetti code	"No separation of concerns"	Modular architecture	Maintainable system

The Key Insight

You did not learn "how to build a line-following robot."

You learned the engineering process for integrating hardware and solving problems systematically.

The robot was just the vehicle.

These two processes -- integration and design -- apply to every embedded system, every sensor, every actuator, in every industry.

Same Problem, 9 Implementations

bg right:30%

Stage	Version of "Follow the Line"	What's New
1	Bang-bang control, oscillates	First attempt
2	Reduced oscillation with timing	Non-blocking code
3	Consistent behavior	Calibrated sensors
4	Visible debugging	OLED display
5	Smooth following	Proportional control
6	Optimized Kp	Data-driven tuning
7	Handles complex tracks	State machine for modes
8	Clean architecture	Abstraction layers
9	Competition-ready	Validated with data

Same line. Same robot. Nine different implementations.

What Changed Was You

Each version reveals why the previous one was insufficient.

Week 1:   "It kind of works"
Week 3:   "It works, but only sometimes"
Week 5:   "It works consistently"
Week 7:   "I can see why it works"
Week 9:   "I can prove it works"
Week 11:  "I can prove it works under all conditions"

The robot did not get better by accident. You got better at engineering.

Connecting the Dots

Every concept built on the previous one:

GPIO (Week 1)
 +-- PWM (Week 2)
      +-- Feedback control (Week 3)
           +-- Sensor fusion (Week 4)
                +-- Timing patterns (Week 5)
                     +-- Data-driven methods (Week 6)
                          +-- State machines (Week 7)
                               +-- Abstraction layers (Week 8)
                                    +-- Architecture (Week 9)
                                         +-- Integration (Week 10-11)

Remove any one layer and the layers above it collapse. This is why the course was sequential -- each concept requires the previous ones as foundation.

Data-Driven Calibration

When Data Beats Guesswork

You didn't use machine learning this semester -- and that was deliberate. ML is powerful but it's a sledgehammer. Most embedded problems are solved better with a calibration table, a linear fit, or a well-tuned PID.

When should you reach for data-driven methods vs traditional control?

Factor	Traditional Control	Machine Learning
Data available	Little or none	Abundant labeled data
Problem complexity	Well-understood physics	Hard to model mathematically
Interpretability	Fully explainable	Often a "black box"
Compute requirements	Minimal (runs on MCU)	May need more RAM/CPU
Development time	Quick if physics is known	Needs data collection + training
Adaptability	Fixed behavior	Can adapt to new conditions

Always ask first: "Can I solve this with an if-statement and a threshold?" If yes, do that. It is simpler, faster, and fully debuggable.

ML on Embedded: The Constraint

Your MCU has 520 KB RAM. A neural network that needs 50 MB of weights will not fit.

For embedded ML, you need:

Small models -- decision trees, linear regression, tiny neural nets
Quantized weights -- int8 instead of float32 (4x smaller)
Or: run ML on a host computer, send commands to the MCU

The question is not "can I use ML?" but "should I use ML?"

Most robot problems in this course are solved better with a well-tuned PID and a state machine than with a neural network.

Motor Calibration: A Practical Regression Example

Problem: PWM duty cycle does not equal actual wheel speed. Friction, battery voltage, and motor characteristics make it nonlinear.

Solution: Measure actual speed at various PWM values, fit a linear model.

# Data collected: PWM vs actual speed (cm/s)
pwm_values     = [30, 40, 50, 60, 70, 80, 90, 100]
actual_speeds  = [ 0, 12, 28, 45, 61, 76, 88,  95]

# Linear fit (done on host): speed = 1.16 * pwm - 27.5

# On the robot:
def pwm_for_speed(target_speed):
    """Convert desired speed to PWM value."""
    pwm = (target_speed + 27.5) / 1.16
    return max(0, min(100, int(pwm)))

"Machine learning" at its simplest -- learning a function from data. The model is two floating-point numbers. It fits in 8 bytes. It runs in microseconds.

What This Example Teaches

The motor calibration is worth studying because it captures the full engineering cycle in miniature:

MEASURE:   Collect PWM vs speed data points
MODEL:     Assume linear relationship (hypothesis)
DESIGN:    Compute slope and intercept (two numbers)
VALIDATE:  Compare predicted vs actual speed
ITERATE:   Add more data points if fit is poor

You did not need TensorFlow. You needed a ruler, a stopwatch, and the numpy.polyfit function.

Know when the simple tool is enough. Most embedded problems live here.

Python vs C: The Full Comparison

LED Blink -- Both Versions

MicroPython -- 5 lines, ~256 KB firmware, ~1-2 us per toggle:

from machine import Pin
import time

led = Pin("LED", Pin.OUT)
while True:
    led.toggle()
    time.sleep(1)

C SDK -- ~10 lines, ~10 KB binary, ~30 ns per toggle:

#include "pico/stdlib.h"
int main() {
    gpio_init(25);
    gpio_set_dir(25, GPIO_OUT);
    while (true) {
        gpio_put(25, !gpio_get(25));
        sleep_ms(1000);
    }
}

For an LED, speed is irrelevant. For a 1 kHz control loop with sensor fusion, the 50x factor determines whether you meet timing.

The Full Comparison Table

Criterion	Python	C	C++
Prototyping speed	Fast	Slow	Slow
Execution speed	Limited	Native	Native
Memory efficiency	High overhead	Minimal	Moderate
Timing precision	Limited	Full control	Full control
Learning curve	Easy	Steep	Steeper
Production systems	Rare	Most common	Growing
Debugging	print() + REPL	printf + JTAG	printf + JTAG
Safety certification	Not available	ISO 26262, DO-178C	ISO 26262, DO-178C

When to Use Which

Python -- Prototyping, learning, rapid iteration, proof-of-concept, lab experiments
C -- Production firmware, timing-critical code, resource-constrained MCUs, safety-critical
C++ -- Complex systems with OOP needs (automotive, robotics, large codebases)
Rust -- Emerging for safety-critical embedded (memory safety without GC)

These are not competing religions. They are tools with different strengths. Knowing when to use each is engineering judgment.

What Stays the Same

Regardless of language, the fundamentals do not change:

Concept	Python	C
GPIO read/write	`Pin(n, Pin.IN)`	`gpio_get(n)`
PWM control	`PWM(pin)`	`pwm_set_wrap()`
I2C communication	`I2C(0, sda, scl)`	`i2c_read_blocking()`
Timer/interrupt	`Timer(callback=fn)`	`add_repeating_timer_ms()`
Main loop	`while True:`	`while (true) {}`
State machine	`if state == X:`	`switch (state)`

The concepts transfer directly. The syntax changes. The thinking does not.

The Real Lesson About Languages

You learned MicroPython this semester. If you pick up C tomorrow, here is what transfers:

Transfers Directly	Needs New Syntax
GPIO as input or output	Pin configuration API
PWM for motor speed	Register-level PWM setup
I2C protocol (address, read, write)	Blocking vs DMA reads
Control loops and PID	Same math, same logic
State machines	switch/case instead of if/elif
Non-blocking patterns	Timer interrupts instead of ticks
Data-driven calibration	Same math, same approach
Debugging methodology	Different tools, same thinking

80% of what you learned is language-independent. The engineering thinking is the portable skill.

The Embedded Landscape

Where Embedded Systems Live

The skills you practiced exist across a massive industry:

Domain	Scale	Examples	Key Skill
Consumer	Billions of units	Smartwatch, earbuds, toys	Cost optimization, power
Automotive	100+ ECUs per car	Engine, brakes, infotainment	Safety (ISO 26262)
Medical	Life-critical	Pacemaker, insulin pump	Reliability, certification
Industrial	24/7 operation	PLCs, robots, SCADA	Determinism, uptime
Aerospace	Extreme environments	Satellites, drones	Radiation tolerance
IoT	Connected devices	Smart home, agriculture	Connectivity, security

Industry by the Numbers

bg right:40%

~30 billion MCUs shipped per year -- about 4 per person on Earth, every year
The laptop and phone market is tiny by comparison
C dominates embedded (~45% of firmware), C++ growing (~30%)
Python used for prototyping and scripting, rarely in production firmware
Rust is emerging for memory-safe embedded -- no garbage collector, no runtime
Embedded systems in every industry: consumer, automotive, medical, industrial, aerospace, IoT

Every object with a battery or a plug likely has an MCU inside it.

Career Paths

Embedded systems is not one job. It is an ecosystem:

Role	What You Do	Key Skills	Products
Firmware Engineer	Write code for MCUs	C, Rust, RTOS	Wearables, IoT, automotive ECUs
Embedded Linux Engineer	Build systems on MPUs	Kernel, device tree, Buildroot	Routers, cameras, infotainment
Hardware Engineer	Design PCBs, select components	Schematics, signal integrity	Physical boards and modules
Systems Engineer	Architecture, integration	Cross-domain thinking	The whole system
Test/Validation Engineer	Prove it works under all conditions	Automation, statistics	Every product that ships

Every one of these roles uses the processes you practiced.

Your Next Steps

If embedded systems interests you, here are concrete next steps:

Learn C for embedded -- The Pico C SDK uses the same hardware you already know. The concepts transfer directly.
Try an RTOS -- FreeRTOS on the Pico gives you real multitasking instead of cooperative main-loop patterns.
Build something for yourself -- A weather station, a motor controller, a data logger. Personal projects teach integration at a deeper level.
Read datasheets -- Practice reading one datasheet per week. This is the single most important skill employers look for.

Industry Best Practices

12 Practices for Embedded Systems

Define requirements before coding -- know what "working" means
Version control everything -- code, configs, calibration data
Test at boundaries -- low battery, extreme temps, edge cases
Log data, don't just observe -- measurements beat impressions
Use watchdog timers -- your system WILL crash; plan for recovery
Separate configuration from logic -- config files, not magic numbers
Build incrementally -- add one feature at a time, test after each
Document your calibration -- date, conditions, parameters, results
Design for failure -- what happens when a sensor disconnects?
Profile before optimizing -- measure where time is spent, don't guess
Review your own code after 24 hours -- fresh eyes catch bugs
Ship the simplest solution that works -- complexity is the enemy of reliability

Which Practices Did You Use?

Look at the list again. Check every practice you applied this semester:

#	Practice	When You Used It
1	Define requirements	Before every lab: success criteria
2	Version control	Saving code to flash, Git
3	Test at boundaries	Edge case testing (Week 9-10)
4	Log data	Data logging lab (Week 8)
5	Watchdog timers	Integration week (Week 10)
6	Config vs logic	config.py (Week 9)
7	Build incrementally	Every lab: one component at a time
8	Document calibration	Motor calibration, sensor calibration
9	Design for failure	Failure mode analysis (Week 10)
10	Profile before optimizing	Timing budget analysis
11	Code review	Debugging your own code
12	Simplest solution	Choosing PID over ML

You practiced all 12 -- you just did not call them by these names.

What Makes an Engineer

Hobbyist vs Engineer

Here's what I want you to take away more than any technical concept: the habit of proving your work. Every lab from the data logging week onward asked you to show data. That's not busywork -- that's the professional standard.

Hobbyist Says	Engineer Says
"It works"	"Here's the data showing it works"
"I tried different values"	"I measured and calculated the values"
"It usually works"	"It meets spec X% of the time"
"It's good enough"	"It meets requirements -- here's validation"
"I fixed it"	"I found root cause and verified the fix"

The difference is not knowledge or skill -- it is rigor. Engineers prove their work.

The Rigor Progression

You experienced this progression across the semester:

Weeks 1-2:   "Make it work"          → Get the LED blinking, motors spinning
Weeks 3-4:   "Make it work right"    → Calibrate, tune, control
Weeks 5-6:   "Make it work reliably" → Non-blocking, timing, data
Weeks 7-8:   "Make it maintainable"  → State machines, architecture
Weeks 9-10:  "Prove it works"        → Testing, validation, evidence
Week 11:     "Explain why it works"  → Defend your design decisions

Each level required the previous one. You cannot prove something works if it does not work reliably. You cannot make something reliable if you cannot measure it.

Engineering Judgment

The most valuable thing you developed is judgment -- knowing which tool, which approach, which trade-off is right for the situation.

Situation	Wrong Instinct	Engineering Judgment
Robot oscillates	"Try random Kp values"	"Measure, calculate, validate"
Code is messy	"Rewrite everything"	"Refactor incrementally"
Feature does not work	"Add more code"	"Simplify, isolate, measure"
Time pressure	"Skip testing"	"Test the critical path"
Two solutions exist	"Pick the cooler one"	"Pick the simpler one"

Judgment is not taught. It is developed through practice -- which is what 11 weeks of labs gave you.

Block 1 Summary

Seven Things to Remember

Two processes, not six lectures -- the 5-step integration process and the engineering design cycle repeat across all embedded work
Same problem, nine implementations -- each week you solved the same challenge at a deeper level
Concepts transfer across languages -- GPIO, PWM, I2C, control, state machines work in Python, C, C++, Rust
Data beats guesswork -- calibration with two numbers outperforms ad hoc tuning every time
Engineers prove their work -- data, not opinion, separates engineering from tinkering
Embedded is massive -- 30 billion MCUs per year, diverse career paths, every industry
Judgment is the real skill -- knowing which tool, which approach, which trade-off fits the situation

Block 2

Retrospective Exercise

Exercise: Map Your Robot Journey

Goal: Connect what you built each week to the engineering principle it taught you.

This is not about memorizing -- it is about recognizing the patterns now that you have experienced them.

Instructions: 1. Work individually (5 min) 2. Compare with a partner (3 min) 3. Class discussion (5 min)

Journey Map -- Fill in the Right Column

Week	What We Built	Engineering Principle Learned
1-2	LED blink, buzzer, unboxing
3-4	Motors, line sensors
5-6	IMU, ultrasonic
7-8	Data logging, control
9	Software architecture
10-11	System integration

5 minutes -- go.

Journey Map -- Example Answers

Week	What We Built	Engineering Principle
1-2	LED blink, buzzer, unboxing	GPIO, digital output, timing, first integration
3-4	Motors, line sensors	PWM, H-bridge, feedback control, sensor reading
5-6	IMU, ultrasonic	I2C protocol, sensor fusion, non-blocking patterns
7-8	Data logging, control	Data-driven decisions, P-control, experimental method
9	Software architecture	Modularity, interface design, config separation
10-11	System integration	Trade-offs, validation, testing, system thinking

Every pair of weeks had a principle. The robot was just the context.

Top 3 Lessons -- Your Turn

Write down your personal answers. Be honest -- there are no wrong answers here.

1. Most surprising thing I learned:

2. Skill I use most (from this course):

3. Biggest mistake that taught me something:

2 minutes -- write, do not think too hard.

Let us hear from 3-4 people.

Common patterns from previous semesters:

"I did not expect debugging to be 80% of the work"
"Data logging changed how I think about problems"
"I learned more from things that broke than things that worked"
"The state machine was the hardest concept but the most useful"
"I finally understand why engineers use version control"

Notice: the most memorable lessons usually came from failures, not successes.

What Would You Do Differently?

If you could start the semester over with what you know now:

What would you do first? Think about what foundation would have saved you the most time.
What would you skip? Was there something that felt like wasted effort in hindsight?
What would you spend more time on? What skill or concept deserved deeper practice?

Discuss with your neighbor for 2 minutes.

Common "Do Differently" Answers

From previous semesters:

"I would start data logging from Day 1 -- I wasted weeks guessing"
"I would read the datasheet before wiring, not after frying the component"
"I would write cleaner code from the start -- refactoring later was painful"
"I would test each subsystem alone before integrating"
"I would not skip calibration -- it seemed boring but it fixed everything"

The fact that you can answer this question means you have developed engineering judgment. Week 1 you could not have answered it.

The Semester in One Diagram

Week 1-2:  GPIO, Blink, Unboxing
               |
Week 3-4:  Motors + Line Sensors → Feedback Control
               |
Week 5-6:  IMU + Ultrasonic → Sensor Fusion + Timing
               |
Week 7-8:  Data Logging + P-Control → Evidence-Based Engineering
               |
Week 9:    Architecture → Clean, Modular Code
               |
Week 10-11: Integration → Your Complete Robot
               |
Week 12:   DEMO DAY → Prove It Works

Every row required the rows above it. The progression was not arbitrary -- it was a dependency chain.

Your Growth as an Engineer

Rate yourself honestly on these dimensions -- Week 1 vs now:

Dimension	Week 1	Week 11
Read a datasheet and extract what I need	☐	☐
Debug systematically (isolate, measure, fix)	☐	☐
Use data to make engineering decisions	☐	☐
Design a system with multiple interacting parts	☐	☐
Explain WHY my design works, not just THAT it works	☐	☐
Recognize when "good enough" is actually good enough	☐	☐

If you improved on even 3 of these, the course achieved its purpose.

Demo Day Prep

What Happens Next Week

Week 12: Demo Day

You demonstrate your robot live
You explain your design decisions
You show data that supports your choices
You answer questions about your engineering process

This is not a competition. It is a demonstration of engineering thinking.

What Success Looks Like

Success is NOT "my robot is the fastest."

Success IS demonstrating engineering thinking:

Element	What You Show
Working system	Your robot performs its designed behavior
Design rationale	You explain WHY you made each choice
Data evidence	Measurements, logs, calibration results
Failure awareness	What failed, what you tried, what you learned
Honest reflection	What you would do differently

A robot that follows a line slowly but has excellent data and clear engineering reasoning scores higher than a fast robot with no explanation.

Demo Day Structure

Prepare for this format:

1. DEMONSTRATE (2 min)
   - Show your robot in action
   - Highlight its key features and behaviors

2. EXPLAIN (3 min)
   - Walk through your architecture
   - Show your data: calibration, test results, timing budget
   - Explain one engineering decision in detail

3. REFLECT (2 min)
   - What was the hardest problem you solved?
   - What would you do differently?
   - What did you learn about engineering process?

Preparing Your Demo

Before Demo Day, make sure you have:

[ ] Robot fully assembled and tested
[ ] At least 3 consecutive successful runs
[ ] Data logs or measurements to show
[ ] A clear explanation of your architecture (diagram helps)
[ ] One specific engineering decision you can explain in depth
[ ] Knowledge of what failed and how you responded

Do NOT: - Make last-minute changes the night before - Rely on "it worked yesterday" - Skip testing in the actual demo environment

The "It Worked Yesterday" Problem

Every engineer has experienced this. Why it happens:

Last night:                    Demo day:
+-- Fully charged battery      +-- Battery at 80%
+-- Your desk (known surface)  +-- Demo table (unknown surface)
+-- Quiet room (no IR noise)   +-- Room full of people + lights
+-- Fresh code upload          +-- Code from last night
+-- Relaxed testing            +-- Nervous hands, rushed setup

Mitigation: Test in conditions as close to the demo as possible. Bring a charged battery. Arrive early. Run your robot before your turn.

Common Demo Day Mistakes

Learn from previous semesters:

Mistake	Why It Happens	Prevention
Robot does not start	Forgot to upload latest code	Test morning of demo
Battery dies mid-demo	Not charged overnight	Bring a spare or charge fully
"Let me just fix this..."	Last-minute code change	Freeze code 24 hours before
Cannot explain design	Built it without thinking about why	Prepare 3-sentence explanation
No data to show	Removed logging to "speed up"	Keep data logging enabled

What the Demo Evaluates

Not your robot's performance. Your engineering process:

Did you follow a systematic approach? Integration process, design cycle, incremental testing
Did you use data to make decisions? Calibration, measurements, test results -- not guesswork
Can you explain your design? Architecture, trade-offs, why you chose this approach
Did you handle failures professionally? Root cause analysis, mitigations, honest reflection
Can you identify what you learned? Process improvements, skills gained, judgment developed

Final Preparation Checklist

Technical: - [ ] Code is clean, commented, and uploaded - [ ] Battery is fully charged (bring charger) - [ ] All sensors tested and calibrated - [ ] Timing budget measured and within limits - [ ] Watchdog timer enabled

Presentation: - [ ] Architecture diagram ready (paper or digital) - [ ] Data logs or measurements available - [ ] One engineering decision explained in 3 sentences - [ ] One failure and its resolution described

Mindset: - [ ] Success = demonstrating process, not perfection - [ ] If something fails during demo, explain the failure mode -- that IS engineering

Quick Checks

Quick Check 1

Name the two repeating processes that every lab followed.

Process 1: The 5-Step Integration Process (Understand, Communicate, Connect, Implement, Verify)

Process 2: The Engineering Design Cycle (Measure, Model, Design, Validate, Iterate)

Quick Check 2

What is the difference between a hobbyist and an engineer?

(Hint: data)

A hobbyist says "it works" based on observation. An engineer says "here is the data showing it meets requirements."

The difference is rigor -- engineers prove their work with measurement, not opinion.

Quick Check 3

If you had to build a new embedded project tomorrow, what would you do FIRST?

Understand the problem and the hardware. Read the datasheet. Identify the communication protocol. Plan the integration steps BEFORE writing code.

Not: "start coding and see what happens."

Quick Check 4

Why was the robot "just the vehicle" -- what was the real destination?

The real destination was the engineering process: systematic integration, data-driven design, measurement-based validation.

The robot gave you a physical context to practice these processes. The processes themselves transfer to any embedded system, any industry, any platform.

Quick Check 5

Name three things that transfer directly when you switch from Python to C.

GPIO concepts (input/output, pull-ups, pin configuration)

Communication protocols (I2C address + read/write, PWM duty cycle)

Engineering patterns (control loops, state machines, non-blocking design)

The syntax changes. The thinking does not.

Quick Check 6

What does Demo Day success look like?

Success is NOT "my robot is the fastest."

Success IS demonstrating engineering thinking: you can explain WHY your design works, show DATA that supports your choices, describe what FAILED, and identify what you would do DIFFERENTLY.

A slow robot with excellent engineering reasoning beats a fast robot with no explanation.

Hands-On Next