This is a submission for the Hacktoberfest Open-Source AI Challenge Week 4: Ghost in the Machine.
What I Built
An embedded system can detect a fault and still lose the most important thing: what happened immediately before it failed.
A sensor freezes. A device experiences an impact. A controller resets. The terminal shows an error, but the sequence leading to it may already be gone.
I wanted to explore a different possibility: what if an embedded device could remember its last few seconds?
That idea became GHOST.OS — The Machine Remembers.
GHOST.OS is a local-first embedded instrumentation and post-mortem forensic platform built around an ESP32-WROOM-32 and an MPU6050 six-axis IMU.
It collects inertial telemetry, detects anomalies using deterministic rules, preserves recent measurements in a circular evidence buffer called Ghost Trace, and provides tools to investigate what happened.
Its guiding idea is simple:
Every machine leaves a last transmission. GHOST.OS remembers.
The word ghost has two meanings here. It represents the machine's remaining telemetry evidence, and the visual experience: when an anomaly is detected, a dormant holographic skull awakens and introduces the forensic investigation.
It isn't a chatbot pretending to be a ghost. It is a visual representation of the machine's recovered memory.
Demo
GHOST.OS runs locally because it needs access to hardware connected to the developer's laptop.
GitHub repository:
https://github.com/debashis-sharingan-21/ghost-os
Working prototype video:
The physical demonstration shows the ESP32 and MPU6050 transmitting real sensor measurements to the GHOST.OS dashboard. The software investigation features can also be demonstrated using repeatable simulator-generated scenarios.
The hosted showcase is read-only. Live hardware communication and local model execution require running the application locally.
Code
GHOST.OS is open source.
debashis-sharingan-21
/
ghost-os
Offline-first AI for embedded diagnostics. Investigate ESP32/STM32 telemetry, reconstruct hardware faults, and explain the machine's last transmission using local open-weight models.
GHOST.OS — The Machine Remembers
Real-Time ESP32 Telemetry, Deterministic Anomaly Detection & Forensic AI
"Every machine leaves a last transmission. GHOST.OS reconstructs what happened."
-black.svg){kind=icon}
1. Cinematic Introduction & Hero View
When an autonomous rover tumbles down an embankment, a drone drops from the sky, or a robotic joint freezes on a factory floor, ordinary loggers crash or write corrupt partial buffers. The physical state leading up to the impact is permanently lost.
GHOST.OS is a specialized real-time embedded instrumentation and post-mortem forensic platform. Built around the ESP32-WROOM-32 dual-core microcontroller and the MPU6050 6-DOF IMU, GHOST.OS captures high-rate inertial kinematics, detects physical anomalies using deterministic sliding-window rules, locks a 200-frame circular pre-fault evidence ring buffer (Ghost Trace), and synthesizes evidence-grounded hypotheses using local open-weight AI — entirely offline and air-gapped.
2. The Problem: Why the Machine's Last Transmission Matters
In edge computing and embedded robotics:
- The Black Box Fallacy…
Documentation:
How I Built It
The central engineering decision was to separate sensor acquisition, deterministic fault detection, evidence preservation and AI-assisted interpretation.
The architecture has three main execution environments.
1. ESP32 — Hardware and firmware
The ESP32 communicates with the MPU6050 over I²C and transmits structured ghost.v1 JSON Lines over USB serial.
The firmware is written in Arduino C++ and compiled using PlatformIO.
| Parameter | Configuration |
|---|---|
| SDA / SCL | GPIO 21 / GPIO 22 |
| MPU6050 address | 0x68 |
| Serial baud rate | 115200 |
| Target telemetry | 10 Hz |
| Status LED | GPIO 4 |
The firmware was successfully compiled and flashed to the ESP32-WROOM-32 through COM9.
The MPU6050 initialized successfully, completed stationary calibration and started transmitting physical sensor measurements.
With the board stationary, the measured acceleration magnitude was approximately 9.85 m/s², consistent with the expected gravity baseline.
The laptop's FastAPI backend received actual serial frames with simulated: false and switched into HARDWARE_SERIAL mode.
2. Laptop — Telemetry and forensic processing
The Python FastAPI backend uses pySerial to receive and validate telemetry.
It handles deterministic anomaly detection, maintains the 200-frame Ghost Trace buffer, preserves pre-fault measurements, and manages recording and replay.
GHOST.OS supports scenarios including free fall, high-G impact, tumble/spin, sensor freeze, thermal spike and brownout.
A separate deterministic simulator provides repeatable scenarios for software testing. Physical sensor events and simulator-injected events remain distinguishable.
3. Browser — Visualization and investigation
The browser receives telemetry through WebSockets and displays live waveforms, hardware status, forensic events, reports and recorded sessions.
When an anomaly arrives, the 3D Ghost HUD reacts with a scenario-specific animation.
Its forensic narrative follows three messages:
THE MACHINE HAS LEFT A TRACE.
RECOVERING LAST TRANSMISSION...
I REMEMBER WHAT HAPPENED.
4. AI Interrogation
GHOST.OS has two distinct reasoning paths.
Deterministic forensic provider: An offline fallback that evaluates measurements and produces observations, numerical evidence, ranked hypotheses and suggested engineering checks.
Ollama provider: An optional integration for local open-weight model inference, intended to interpret preserved evidence.
The distinction matters: the deterministic fallback is not a language model.
The Ollama integration is implemented, but successful real model inference has not yet been independently demonstrated. I do not present deterministic fallback output as an open-weight model response.
5. Digital Afterlife
A fault investigation should not disappear when the dashboard closes.
Digital Afterlife records telemetry sessions as JSON Lines files and supports playback, pause, step-by-step inspection and speeds from 0.5× to 4×.
Why Does Open Innovation Matter?
Embedded systems can produce sensitive information about their operating environment and connected equipment.
I wanted an architecture where telemetry acquisition and forensic investigation could happen locally, without requiring a remote proprietary AI service for every operation.
The Ollama provider is designed to support local open-weight inference. This gives developers control over model selection and the ability to experiment without making a hosted inference service mandatory.
The deterministic forensic engine remains available independently when model inference is unavailable.
Sensor measurements and fault detection stay grounded in application logic, while a language model can assist with interpretation.
Open innovation matters because developers should be able to inspect, run, replace and adapt the intelligence behind their tools instead of depending entirely on a closed service.
The goal is not to make AI responsible for every decision. It is to make forensic analysis more accessible while preserving the underlying evidence.
My Agent Session
GHOST.OS was developed using AI-assisted coding and iterative implementation, code inspection and testing.
The Spirit of It
There is something unsettling about a machine failing without leaving enough evidence to explain why.
The system was working. Measurements were flowing. Then something happened, and the last few seconds disappeared.
I wanted to build something that gives those moments a second life.
The 3D skull is the visual symbol. Ghost Trace is the actual memory.
The most satisfying part of this project has been taking it from a simulated telemetry pipeline to a physical ESP32 and MPU6050 transmission appearing in the GHOST.OS dashboard.
A machine may stop responding. Its last transmission should not have to disappear.
Let's Discuss
What would you want an embedded system to remember when something goes wrong: the last few seconds of telemetry, a detailed fault explanation, or a replayable record of the entire session?
I'd love to hear how other embedded and robotics developers approach failures that are difficult to reproduce.
GHOST.OS — THE MACHINE REMEMBERS.
Every machine leaves a last transmission.
Top comments (0)