- Write a concrete contract for an integrated system.
- Separate sensor validity, model output and device policy.
- Record enough evidence to reproduce a decision.
- Evaluate success and failure paths independently.
Before you begin
Complete the temperature monitor, object detector and bounded LED bridge before this integration.
Choose a capstone you can finish and explain
The capstone is a desk monitor. A computer reads a temperature from an Arduino, analyzes one fresh camera frame and briefly lights an indicator when a person is detected and the measured temperature exceeds a chosen classroom threshold. It also logs the inputs and decision. This is a complete small system, not a claim of intelligent climate control.
The temperature threshold is ordinary logic. The pedestrian detector is the learned component. The Uno performs electrical input and output, while Python coordinates measurement and inference. No cloud processing is required, and no image is retained by the program. This explicit division makes the project's AI contribution honest.
Define success before assembly: valid inputs produce the documented indicator decision; absent detections leave it off; unavailable input ends the run; every completed decision has a timestamped log entry; stopping the host leaves the output off. These statements are testable. ‘Works intelligently’ is not.
TMP36 → Uno → temperature ───────────┐
USB camera → trained detector ────────┤
↓
checked policy
↓ ↓
Uno LED event CSV
↓
observed feedbackPrepare the computer and the LED bridge
The reference board is an Arduino Uno R3 connected by USB. Start with its built-in LED, so this output needs no external circuit. A laptop performs inference; the Arduino accepts a tiny set of commands. A Raspberry Pi can replace the laptop after its Python setup works. No cloud service is required.
Download bridge.py beside your Python script and the LED sketch. Save the sketch in a folder named led_bridge, open it in Arduino IDE, select Uno and your port, then upload. Close Serial Monitor before opening the port from Python. The kit guide supplies Windows and Raspberry Pi setup alternatives.
On macOS or Linux, create an environment with python3 -m venv .venv, activate it with source .venv/bin/activate, and install the serial library using python -m pip install pyserial. Find your port with python -m serial.tools.list_ports; replace the sample port in the code. Never install a package called bridge: that module is the downloaded file.
Commands are newline-terminated text at 115200 baud. LED_ON means illuminate the indicator; LED_OFF and STOP turn it off. The firmware acknowledges valid messages and turns the LED off after 600 milliseconds without a refreshed light command. Bridge.hold refreshes a requested action for a bounded interval and then sends STOP. An acknowledgement proves a message was parsed; looking at the board checks the physical output.
| Part | Purpose |
|---|---|
| Uno R3 and data-capable USB cable | Low-voltage output and communication |
| Computer with Python 3 | Inference and command validation |
| Built-in LED | Safe visible actuator substitute |
Assemble only the required subsystems
Use the AARD03 temperature circuit: TMP36 output onA1, its documented supply and ground leads on5V andGND, and a100nF bypass capacitor. Add a supported USB camera to the computer. The complete parts set is the LED bridge, sensor circuit, camera and suitable cables; there are no motors in this capstone.
Download vision.py beside bridge.py. Test its detector on your saved images, then verify a live frame can be captured. Test the sensor conversion separately against a room thermometer. Only after both paths work should you combine them. Integration cannot reveal which broken subsystem is responsible if you skip these isolated checks.
Keep a short configuration record: actual serial port, board revision, Python and package versions, camera model, sensor reference voltage, test room and detector threshold. Preserve that record with the CSV. A result without its conditions is difficult to reproduce, especially when a later package or board revision behaves differently.
Implement one inspectable decision cycle
The demonstration intentionally performs one cycle per run. Set the serial port and choose a threshold appropriate to your classroom experiment.24°C below is an arbitrary demonstration setting, not a health or equipment limit. Install OpenCV as in AARD05; the remaining logging modules are part of Python.
import csv
from datetime import datetime, timezone
import cv2
from bridge import Bridge
from vision import people
camera = cv2.VideoCapture(0)
try:
with Bridge('/dev/ttyACM0') as board:
_, raw, _ = board.read()
temperature = (raw * 5.0 / 1023 - 0.5) * 100
if not -20 <= temperature <= 60:
raise ValueError('Outside this demo measurement range')
ok, frame = camera.read()
if not ok:
raise RuntimeError('No camera observation')
count = len(people(frame))
command = 'LED_ON' if count > 0 and temperature > 24 else 'LED_OFF'
board.hold(command, 1.0)
with open('events.csv', 'a', newline='') as output:
csv.writer(output).writerow([datetime.now(timezone.utc).isoformat(),
round(temperature, 1), count, command])
print(temperature, count, command)
finally:
camera.release()Input validation happens before a device decision. The temperature range catches some implausible values but does not prove sensor health. A missing camera frame raises an error. The Boolean policy combines an ordinary threshold with a learned detection result. The appended CSV row records timestamp, Celsius, box count and requested command; it does not claim physical output verification.
Expected result: A valid run prints the three decision values and appends one CSV row. The LED lights for one second only when both conditions hold. Failed runs should stop with an error and leave the LED off.
Review evidence before calling the project complete
Make a four-row truth table for person present/absent and temperature above/below threshold. Test the policy with synthetic inputs first, then run physical examples without unsafe heating. Use a copied sensor reading or a temporarily changed demo threshold to exercise the logic; label those as simulated cases in your log.
Next test a missing image, wrong serial port and invalid sensor conversion. Confirm that a failure remains visible rather than becoming a default plausible reading. Unplugging USB tests whether the firmware timeout works independently of Python cleanup. A finally block helps software exit cleanly but cannot execute after every crash or cable failure.
Have another learner reproduce one run using only your article notes, configuration and source files. Ask them to explain which stage is AI and which stage is ordinary logic. If they cannot identify an output's origin, improve the logging or explanation before adding another feature.
The natural next step is to move the computer's responsibilities onto Raspberry Pi, then evaluate latency and resource use. Do not simultaneously change the board, camera, model and protocol. A successful capstone gives you a stable reference against which one new choice can be tested.
Important terms
- System contract
- A written agreement about inputs, outputs and failure behavior.
- Acceptance criterion
- An observable condition a finished project must satisfy.
- Integration test
- A test of components operating together.
- Truth table
- A listing of output decisions for combinations of Boolean inputs.
- Reproducibility
- The ability to repeat a result using recorded conditions and steps.
Mini project: Build an acceptance report
- Draw the architecture and name the processor for each stage.
- Test the four policy combinations in software and label simulated evidence.
- Run the missing-input and lost-communication checks.
- Have a second learner reproduce one valid run and record unresolved limitations.
Common mistakes and debugging
- Changing several components at once: preserve a working reference and change one variable.
- Logging a command as if it proves an observed LED state: record physical verification separately.
- Declaring completion after one successful demo: include the failure paths in acceptance.
Independent challenge
Design a second output that conveys sensor fault separately from an ordinary no-alert condition. Specify its meaning, wiring, firmware command and tests before adding it.
Check your understanding: 10 questions
Which stage uses a learned model?
Why test subsystems separately?
Is24°C a safety limit?
What does the event CSV establish?
Why keep a known working reference?
In your own words, what does “System contract” mean?
In your own words, what does “Acceptance criterion” mean?
In your own words, what does “Integration test” mean?
In your own words, what does “Truth table” mean?
In your own words, what does “Reproducibility” mean?
Quiz answers
Reveal all 10 answers after your attempt
- The computer's pedestrian detector; the temperature threshold and output policy are ordinary logic.
- It narrows the cause of failures before several components interact.
- No. It is an arbitrary setting for this demonstration.
- The recorded input values and requested decision, not guaranteed physical actuation.
- It lets you compare one later change against a reproducible baseline.
- A written agreement about inputs, outputs and failure behavior.
- An observable condition a finished project must satisfy.
- A test of components operating together.
- A listing of output decisions for combinations of Boolean inputs.
- The ability to repeat a result using recorded conditions and steps.
Summary
A complete AI + Arduino project has a defined purpose, clear component responsibilities, bounded outputs and evidence for both success and failure. That discipline matters more than adding a larger model or more sensors.
Continue learning
Continue with AI + Raspberry Pi to move perception and coordination onto a compact computer, then use the robotics project ladder for controlled movement.
- Build a Raspberry Pi AI Assistant
- Use Raspberry Pi as an AI Robot Brain
- Design Your Own AI Robot From Scratch
Sources and further reading
Prepared 2026-09-18. Editorial draft. Primary documentation checked; hardware, camera and audio behavior still require a physical test.