I was tired of SOS apps failing in dead zones, so I built a pure Dart, 100% offline TFLite crash detection engine.

Hey All,

I’ve been working on a safety application named SafePulse recently and ran into a massive architectural flaw with most existing SOS systems: they rely entirely on cloud servers to analyze telemetry and detect crashes. If an accident happens in a rural area with no network, the app is completely useless.

I wanted a deterministic, zero-latency solution, so I ended up decoupling my crash logic into a standalone, open-source package: offline_sos_system.

How it works: It is a completely headless "Edge AI" engine. It orchestrates raw hardware telemetry (accelerometer _+ _gyroscope), down-samples the vectors, and feeds them directly into an on-device TensorFlow Lite (tflite_flutter) neural network.

Key features:
100% Offline Inference: No network requests, zero latency, maximum privacy.

Strictly Headless: It doesn't handle UI, GPS, or SMS. It just does the complex math and emits a clean Stream, leaving the application layer in full control.

BYOB(Bring Your Own Brain): It bundles a default crash_model.tflite but exposes an injection port if you want to initialize it with your own custom-trained model.

I just pushed version 0.0.5 which hits a 160/160 points on pub.dev. I would love for the community to tear into the architecture, check out the telemetry pipeline, and let me know if there are any optimizations you'd suggest for handling high-frequency sensor streams in Dart!

Pub.dev: https://pub.dev/packages/offline_sos_system

GitHub: https://github.com/bhagyaprasad92/offline_sos_system

Thanks for checking it out!

Comments

[Techsteve990]

This resonates a lot with what I ran into building ArchFic, a Flutter offline-first fanfic reader. Same core idea — if the content matters, it should work with zero network. Your headless engine + Stream approach is clean. I ended up decoupling the sync layer from UI in a similar way. One thing that surprised me: SQLite and Isar both get weird with large offline datasets (AO3 fics can be 500k+ words). Curious how you handle high-frequency sensor buffering without memory spikes — that's a different beast from text caching, but the storage tradeoffs rhyme.

[Bhagya Prasad Dannina]

Hey Techsteve990, thanks for checking out the package!
As you noted, text caching and sensor telemetry are completely different problems. Text caching relies on persistent disk storage, while high-frequency sensor telemetry must be handled entirely in temporary memory (RAM). Writing 50Hz or 100Hz sensor data directly to a database like SQLite or Isar chokes your I/O thread and forces the garbage collector into overdrive, which is exactly what causes your memory spikes.
In offline_sos_system, zero raw telemetry touches the disk. It is managed strictly in RAM using two specific approaches:

• Fixed-size circular buffers: We pre-allocate an array once and simply overwrite the oldest data as new data comes in. This guarantees zero new memory allocations during runtime.
• Reactive stream batching: We group the sensor data in memory, pass it to the TFLite model for evaluation, and let it drop out of scope the exact second the evaluation is done. The takeaway: Stop writing raw sensor streams to disk. Keep the raw telemetry in RAM, and only write the actual detected events to your local database.

I will be releasing version 0.0.6 soon, which adds a new feature: crash detection via rapid deceleration (e.g., detecting a sudden speed drop from 100 to 0). I'd love to hear your thoughts on the new telemetry pipeline when it drops!

[Suseela Koduri]

Great work on this! Decoupling the telemetry logic from the app layer into a pure, headless Dart package is a really clean architecture choice. Edge AI is definitely the right call for safety-critical apps where connectivity is never guaranteed. Achieving a 160/160 pub points score on top of that is super impressive. Excited to see how version 0.0.6 turns out!

[Bhagya Prasad Dannina]

Hey Suseela, I appreciate the feedback!
You hit the exact reasoning behind the architecture.
Relying on cloud connectivity for a safety-critical system is a fundamentally broken model. And that resolved with offline_sos_system.

I am finalizing the logic for version 0.0.6 right now. It introduces the new rapid deceleration pipeline (e.g., detecting a sudden 100-to-0 speed drop). I will post an update once it is live on pub.dev.