IoT

SmartXCar

Realtime web control for a physically built Raspberry Pi vehicle.

Completed PrototypeRealtime IoT Vehicle ControlFull-Stack & IoT Engineer

The friction

Authenticated DashboardFlask-SocketIO ServerCommand WhitelistAuthenticated Vehicle ClientPhysical VehicleTelemetry Feedback

Judgement, made visible.

Problem

Why this needed to exist.

The project required a browser-based control layer that could safely communicate with a physical vehicle, display live sensor information and prevent invalid or stale movement commands from being forwarded to the hardware client.

Context: School Project
Platform: Web · Raspberry Pi Vehicle Client

System

Complexity, given a direction.

Authenticated Dashboard
Flask-SocketIO Server
Command Whitelist
Authenticated Vehicle Client
Physical Vehicle
Telemetry Feedback

Decisions

The work behind the interface.

Role-based socket authentication

Dashboard connections are validated through the admin session while the vehicle connects with a dedicated device token and car identifier.

Unauthorised clients cannot register themselves as the active vehicle.

Safe stop behaviour

Stop and accessory-reset commands are sent when the dashboard disconnects, logs out or when a new vehicle connection replaces the previous client.

Loss of browser control does not intentionally leave the previous drive state active.

Single-worker production model

Active socket and vehicle state is stored in process memory, so Gunicorn runs with one worker rather than creating inconsistent state across processes.

The deployed architecture matches the current state-management limitation.Horizontal scaling would require shared state through a service such as Redis.

Evidence, not theatre.

Completed and tested as a working physical vehicle prototype, including deployment to a remote server, realtime browser control and live telemetry.

Physically built and operational vehicle

Remote server deployment

Realtime bidirectional Socket.IO control

Live distance and rain telemetry