Semester Project Ideas

These are alternative semester project ideas for the Linux in Embedded Systems course. Each project builds on the skills developed in the semester lab track -- Linux fundamentals, kernel drivers, device tree, systemd, Buildroot, real-time systems, and graphics -- and is scoped for roughly 12 weeks of lab time (~3 hours per week).

The default course project is the IMU Level Display. Students who want to pursue a different topic may choose one of the alternatives below, subject to instructor approval. All projects share the same final deliverable format: a live demo, a short presentation, and a measurement report.

Default Project: IMU Level Display

The standard course capstone. Build a tilt-responsive bubble level displayed on HDMI using SDL2 and DRM/KMS, running on a custom Buildroot image with a PREEMPT_RT kernel. Write I2C and SPI kernel drivers for the MCP9808 and BMI160, measure jitter across standard and RT kernels, and optimize SPI transfers with DMA.

This project is fully guided by the semester lab track tutorials (Labs 6--12). Choose an alternative only if you want to explore a different application domain -- the alternative projects require more independent work.

Choosing an Alternative Project

Alternative projects replace Labs 10--12 of the semester track. You still complete Labs 1--9 (including both kernel drivers and the Buildroot image), then branch off into your chosen project for the final three weeks. Some projects may require starting preparatory work earlier -- check the notes on each project.

Intermediate Projects

These projects use skills from the first 9 labs and add a focused application layer. They do not require writing additional kernel drivers beyond what the course already covers, but they do require integrating multiple subsystems (sensors, networking, display, systemd services) into a working appliance.

1. Weather Station with Web Dashboard

Build a self-contained weather station that logs sensor data and serves a live dashboard over the local network. The Pi reads temperature (MCP9808) and orientation (BMI160) via the kernel drivers written in Labs 7--8, logs to CSV with proper flushing, and runs a lightweight web server that displays current readings and historical charts.

Key technologies: Python (Flask or FastAPI), MQTT or HTTP, systemd service, HTML/JS charting (Chart.js or similar), overlayfs for reliability

Hardware: MCP9808, BMI160, Raspberry Pi (from course kit). Optional: add a BMP280 (pressure, ~2 EUR) or DHT22 (humidity, ~3 EUR) over I2C.

Deliverables:

Custom Buildroot image with Python, web server, and sensor drivers
systemd service that starts logging and serving on boot
Web dashboard accessible from a laptop browser on the same network
24-hour uptime test with power-cycle recovery proof
Measurement report: request latency (p50, p99), data loss after power cut

2. Network-Attached Data Logger Appliance

Extend the data logger from Lab 4 into a headless, network-accessible appliance. The device boots into a read-only root, logs sensor data to a dedicated partition, and exposes the logs over the network via a REST API with CSV export. Add a systemd watchdog so the service restarts on failure, and an OLED status display showing uptime, record count, and IP address.

Key technologies: overlayfs, systemd (watchdog, journald), Python REST API, I2C (OLED + MCP9808), shell scripting

Hardware: MCP9808, SSD1306 OLED, Raspberry Pi (all from course kit)

Deliverables:

Buildroot image with read-only root, writable data partition, REST API, OLED status
systemd watchdog integration (demonstrate recovery from killed process)
CSV export via HTTP (curl http://pi:8080/export.csv)
Power-cycle and watchdog test results
Measurement report: log write throughput, API response time, recovery time after watchdog trigger

3. Industrial Alarm Panel

Build a monitoring panel that watches multiple GPIO inputs (simulating door contacts, limit switches, or sensor thresholds), displays alarm state on the OLED and on HDMI via a simple SDL2 or framebuffer UI, sounds a buzzer on alarm, and logs all events to journald with timestamps. A systemd watchdog ensures the monitor never silently dies.

Key technologies: GPIO (sysfs or libgpiod), systemd (watchdog, journald), SDL2 or framebuffer, I2C (OLED), PWM (buzzer)

Hardware: Raspberry Pi, SSD1306 OLED (from course kit). Add: 3--4 push buttons or switches (~1 EUR), passive buzzer (~1 EUR).

Deliverables:

Buildroot image with alarm monitor service, OLED driver, HDMI display
Live demo: trigger alarms, observe display + buzzer + journal log
systemd watchdog test (kill the process, verify restart and alarm)
Measurement report: GPIO-to-display latency, GPIO-to-buzzer latency, journal entry timestamps

4. Audio Spectrum Analyzer

Capture audio from a USB microphone, compute the frequency spectrum in real time, and render a live bar-graph visualization on HDMI using SDL2 and DRM/KMS. This project focuses on the graphics pipeline and real-time data processing rather than kernel driver development.

Key technologies: ALSA or PulseAudio, FFT (numpy or a C library), SDL2 + DRM/KMS, Buildroot image, PREEMPT_RT for consistent frame timing

Hardware: Raspberry Pi, HDMI monitor (from course kit). Add: USB microphone or USB sound card (~5 EUR).

Deliverables:

Custom Buildroot image with ALSA, SDL2, Python (numpy) or C FFT library
Live visualization responding to audio input (music, speech, clapping)
Standard vs RT kernel comparison: frame jitter histogram under CPU load
Measurement report: FFT latency, frame rate stability, dropped frames under load

Tip

Start with a Python prototype using pyaudio + numpy on stock Raspberry Pi OS before porting to the Buildroot image. The Buildroot image needs ALSA libraries and either numpy or a C FFT implementation -- configure these in menuconfig during Lab 9.

5. GPS Tracker with Map Display

Read position data from a USB GPS receiver, parse NMEA sentences, and display the current position on a simple SDL2 map rendered on HDMI. Log the track to a GPX or CSV file. Optionally overlay speed and heading from the BMI160 IMU.

Key technologies: serial port (UART/USB), NMEA parsing, SDL2 + DRM/KMS, file logging, Buildroot image

Hardware: Raspberry Pi, HDMI monitor (from course kit). Add: USB GPS module (u-blox NEO-6M or similar, ~8 EUR).

Deliverables:

Custom Buildroot image with GPS support, SDL2, serial libraries
Live position display on HDMI (even a simple crosshair on a grid is sufficient -- no need for real map tiles)
Logged track file (GPX or CSV with timestamps, lat, lon)
Measurement report: GPS fix time, position update rate, display refresh jitter

Note

GPS modules need a clear sky view to get a fix. Test near a window or outdoors. Indoor testing with no fix is still useful for verifying the parsing and display pipeline -- you can feed recorded NMEA data through a virtual serial port.

6. Robot Remote Control via WebSocket

Build a web-based remote control interface for a simple robot (two DC motors + camera). The Pi runs a WebSocket server that receives joystick commands from a browser, drives PWM outputs for motor control, and streams camera frames back to the browser. This project exercises networking, real-time control, and the camera pipeline.

Key technologies: WebSocket (Python websockets or C library), PWM, camera (v4l2, MJPEG), HTML/JS, systemd service

Hardware: Raspberry Pi, Pi Camera Module v2 (from course kit). Add: L298N motor driver (~3 EUR), two DC motors (~4 EUR), chassis (~10 EUR). Or simulate motors with LEDs for a lower-cost version.

Deliverables:

Buildroot image with WebSocket server, camera support, PWM control
Browser UI with virtual joystick and live camera feed
Demonstrate control over WiFi with visible motor response (or LED brightness)
Measurement report: command-to-actuation latency, video stream frame rate, latency under network load

Warning

This project has more hardware than most alternatives. Confirm motor driver availability with the instructor before committing. The LED-only version (PWM brightness control instead of motors) is a valid fallback.

Advanced Projects

These projects require either writing additional kernel-level code beyond the course tutorials, integrating complex external protocols, or solving harder real-time problems. They are appropriate for students with prior Linux or C programming experience.

7. Digital Oscilloscope / Signal Visualizer

Build a single-channel digital oscilloscope that samples an analog signal via an external ADC (e.g., ADS1115 over I2C or MCP3008 over SPI), renders the waveform on HDMI using SDL2, and implements basic trigger logic (rising edge, level threshold). Compare sampling consistency on standard vs RT kernel.

Key technologies: ADC (I2C or SPI), kernel driver or IIO subsystem, SDL2 + DRM/KMS, trigger logic, PREEMPT_RT, Buildroot

Hardware: Raspberry Pi, HDMI monitor (from course kit). Add: ADS1115 I2C ADC (~4 EUR) or MCP3008 SPI ADC (~3 EUR), signal source (function generator or another Pi generating PWM).

Deliverables:

Kernel driver or IIO integration for the ADC (extend the patterns from MCP9808/BMI160 tutorials)
SDL2 waveform display with configurable time base and trigger level
Triggered single-shot and continuous sweep modes
Measurement report: maximum sample rate, sample jitter (standard vs RT), trigger accuracy

Tip

The MCP3008 is SPI-based and maps closely to the BMI160 driver from Lab 8. If you choose the ADS1115, it is I2C-based and maps to the MCP9808 driver from Lab 7. Either way, you already have a template.

8. CAN Bus Dashboard

Interface with a CAN bus using a MCP2515 CAN controller (SPI-attached), decode CAN frames, and display live gauges on HDMI using SDL2. This project introduces the SocketCAN Linux subsystem and is directly relevant to automotive and industrial applications.

Key technologies: SPI, CAN (MCP2515), SocketCAN, device tree overlay, SDL2 + DRM/KMS, Buildroot

Hardware: Raspberry Pi, HDMI monitor (from course kit). Add: MCP2515 CAN module (~5 EUR). A second CAN node (another Pi + MCP2515, or an Arduino) is needed to generate traffic.

Deliverables:

Device tree overlay for MCP2515 on SPI bus
SocketCAN configuration and candump/cansend verification
SDL2 dashboard displaying at least 3 decoded CAN signals (e.g., RPM, temperature, voltage)
Measurement report: CAN frame receive latency, display update rate, frame loss rate under bus load

Note

The MCP2515 driver is already in the mainline Linux kernel (can-mcp251x). Your job is to configure the device tree overlay, enable SocketCAN in Buildroot, and build the application layer. You do not need to write the CAN driver from scratch, but you should understand how it works.

9. Motor Control with PID Tuning UI

Drive a DC motor with PWM, read rotational speed from a rotary encoder, implement a PID speed controller, and display a real-time plot of setpoint vs actual speed on HDMI using SDL2. Provide a simple UI (keyboard or rotary encoder) to adjust PID gains live and observe the effect.

Key technologies: PWM, GPIO (encoder), PID control loop, real-time scheduling (PREEMPT_RT), SDL2 + DRM/KMS, Buildroot

Hardware: Raspberry Pi, HDMI monitor (from course kit). Add: DC motor with encoder (~8 EUR), L298N motor driver (~3 EUR), power supply for motor.

Deliverables:

PWM motor driver configuration via device tree or sysfs
Encoder reading (GPIO interrupt or hardware counter)
PID controller running at a fixed rate (100+ Hz) with RT scheduling
SDL2 real-time plot: setpoint, actual speed, control effort
Measurement report: control loop jitter (standard vs RT), step response time, steady-state error

Warning

This project requires careful wiring and a separate power supply for the motor. The encoder generates fast interrupts that stress the real-time guarantees -- this is the point, but it also means debugging is harder. Start with a software-simulated motor model before connecting real hardware.

10. Smart Home Gateway

Build a gateway that collects data from multiple sensors (I2C, SPI, and optionally BLE), runs an MQTT broker locally, stores readings in a lightweight database (SQLite), and serves a Grafana dashboard for visualization. This project focuses on system integration and networking rather than graphics.

Key technologies: MQTT (Mosquitto), SQLite, Grafana, systemd, I2C/SPI sensors, Buildroot, optionally BLE

Hardware: MCP9808, BMI160, Raspberry Pi (from course kit). Optional: BLE USB dongle (~5 EUR) + BLE sensor tags.

Deliverables:

Buildroot image with Mosquitto, SQLite, Grafana (or a lighter alternative like uPlot served via HTTP)
Sensor reader service publishing to MQTT topics
Persistent database surviving power cycles
Dashboard accessible from a laptop browser
Measurement report: MQTT message latency, database write throughput, 48-hour uptime log

Tip

Grafana is heavy for a minimal Buildroot image. Consider a simpler approach: a Python HTTP server serving a static HTML page with Chart.js that queries a JSON API backed by SQLite. This achieves the same result with a fraction of the image size.

11. Security Camera with Motion Detection

Capture video from the Pi Camera, run frame-difference motion detection, trigger recording and an MQTT alert on motion, and display the live feed with detection overlay on HDMI. This project combines the camera pipeline, real-time image processing, and networking.

Key technologies: v4l2, OpenCV (or raw frame differencing), MQTT, SDL2 or framebuffer, systemd, Buildroot

Hardware: Raspberry Pi, Pi Camera Module v2, HDMI monitor (from course kit)

Deliverables:

Buildroot image with camera support, OpenCV or custom motion detection, MQTT client
Live camera feed on HDMI with motion bounding box overlay
MQTT alert on motion detection (subscribe from a laptop to verify)
Recorded clips saved to persistent storage on motion trigger
Measurement report: detection latency (motion to alert), frame rate with and without detection, false positive rate over a 1-hour test

Warning

OpenCV is large and slow to cross-compile in Buildroot. Two alternatives: (1) use raw frame differencing in Python with numpy -- sufficient for simple motion detection; (2) use OpenCV on stock Raspberry Pi OS instead of Buildroot, and focus the Buildroot effort on a separate minimal image for comparison.

12. Environmental Monitoring Node with Custom Wireless

Build a standalone environmental monitoring node that reads multiple I2C and SPI sensors, transmits data wirelessly (via LoRa, WiFi, or USB-attached radio), and runs as a battery-aware appliance. The focus is on low-power design, robust data transmission, and building a truly self-contained Buildroot image.

Key technologies: I2C, SPI, wireless (LoRa SX1276 via SPI, or WiFi), power management, Buildroot, systemd, device tree

Hardware: MCP9808, BMI160, Raspberry Pi (from course kit). Add: LoRa module SX1276 (~8 EUR) or use built-in WiFi. Optional: add BMP280 (pressure) or light sensor.

Deliverables:

Custom Buildroot image with all sensor drivers and wireless stack
Device tree overlay for LoRa module (if using SPI-attached radio)
Data transmission to a receiving node or server (verified with packet capture)
Power consumption measurement: idle vs active vs transmitting
Measurement report: packet delivery rate, transmission latency, sensor polling jitter

Note

If using LoRa, you need a second LoRa module as a receiver (another Pi, or an Arduino). WiFi is simpler but less interesting from a driver perspective. Discuss the trade-off with your instructor.

Project Evaluation Criteria

All projects, including the default IMU Level Display, are evaluated using the same criteria:

Criterion	Weight	What We Look For
Working demo	30%	The system works live, not just in a video
System architecture	20%	Clear separation of concerns, proper use of systemd, device tree, and Linux subsystems
Measurement report	25%	Quantitative data: latency, jitter, throughput, reliability -- not just "it works"
Code quality	15%	Readable, documented, version-controlled
Presentation	10%	Clear explanation of design decisions and trade-offs

Scope Management

A working system with 3 features and solid measurements beats a half-working system with 10 features. Start with the minimum viable version, get it running end-to-end, measure it, and then add features if time allows. Every project above can be simplified by dropping optional features and focusing on the core data path.

Semester Lab Track | Course Overview