Phone-Based Crash Detection and SOS for Motorcycle Riders
A final year project that builds an Android app that detects a likely motorcycle crash from phone sensors, starts a countdown the rider can cancel, and sends location to emergency contacts by data or plain SMS. For delivery riders and commuters on cheap phones, with a measured false alarm rate as the core result.
Advanced
Needs a team, real planning, and a supervisor who knows the area.2 semesters · 3 students
7 to ship
3 optional extrasSuggested stack
What you should ship
- Foreground service that samples accelerometer, gyroscope and speed during a ride with a measured battery cost
- Crash detector combining a hard-impact rule with a post-impact check (sudden stop, phone orientation change, no movement)
- Cancelable countdown with loud alarm and vibration, then an alert with location sent over data or SMS if there is no data
- Ride-labelled dataset: hours of normal riding, potholes, speed breakers, phone drops and simulated falls using a dummy or safe rig
- Offline analysis notebook reporting false alarms per riding hour and detection rate on simulated crashes
- Emergency contact setup, a test mode, and a ride history screen
- Battery and memory measurements over a 2-hour ride on a low-end phone
If you have time left
- Learned classifier on sensor windows compared against the rule-based detector
- Fleet mode where a delivery company dispatcher also receives alerts
- Automatic ride start and stop using activity recognition
The problem for motorcycle riders
Motorcycles carry a large share of commuters and nearly all delivery riders in South and Southeast Asia, and riders are among the most vulnerable road users. After a crash, especially at night or on a quiet road, the time until someone calls for help matters. A rider who is unconscious cannot call. Families often find out hours later.
Many phones now include crash detection, but it is tied to specific recent devices, and it is tuned for car crashes rather than motorbike falls.
What already exists and the gap
- Apple Crash Detection and Google Pixel Car Crash Detection: built into recent iPhones and Pixel phones; car-focused and not available on the budget Android phones most riders carry.
- REVER, Detecht and EatSleepRIDE: motorcycle apps with crash detection and emergency alerts, aimed at leisure riders with route planning, social features and paid tiers.
- Generic SOS apps: a panic button, which a person in a crash cannot press.
The gap is a focused, free or fleet-funded app for everyday and delivery riders, that works on low-end Android, sends an SMS when mobile data is off, and publishes its false alarm rate.
What you build
- Rider app: start ride (or automatic), background detection, countdown and cancel, alert sending, contacts, ride history, test mode.
- Contact side: receives an SMS or a push with a map link, time and last known speed.
- Optional fleet dashboard as a stretch goal.
The technically interesting part
The whole project is a detection problem with a painful trade-off. A detector that fires on every pothole will be uninstalled in a week; one that misses real crashes is useless.
- Data collection is hard and must be safe. Record hours of normal riding on real roads, including speed breakers and broken surfaces. Simulate crashes safely: a phone in a padded holder dropped from a moving trolley, a dummy on a bicycle, or controlled falls on a mat. Never crash real riders.
- Detector design: an impact spike alone is not enough. Look for impact followed by a sudden speed drop to near zero and a period of stillness. Compare a rule-based approach against a small classifier on sensor windows.
- Android background limits: a foreground service with a persistent notification, careful sampling rates, and surviving battery optimisation on different phone brands.
Show evaluators a curve of false alarms per riding hour against detection rate for different thresholds, and justify your chosen point.
How to evaluate it
- False alarms per hour over at least 20 hours of normal riding by several riders.
- Detection rate on simulated crash events.
- Time from impact to alert delivered, over data and over SMS.
- Battery drain per hour and behaviour on at least two phone brands with aggressive battery managers.
Suggested plan
- Weeks 1 to 3: literature and product review, safety plan for data collection, sensor logging app.
- Weeks 4 to 9: collect normal riding data and simulated events; label them.
- Weeks 10 to 14: rule-based detector, offline evaluation.
- Semester 2, weeks 1 to 5: on-phone detector, countdown and alert pipeline, SMS fallback.
- Weeks 6 to 10: learned classifier comparison, battery work, field test.
- Weeks 11 to 14: final evaluation and report.
Path to a product
The first paying customer is a delivery or courier company that owes its riders a duty of care and wants to know when one is hurt; charge per rider per month for the dispatcher alerts. Individual riders get the basic app free. Insurers are a later partner.
Scope warning
Do not stage real crashes with people. Do not promise emergency service integration you cannot test. Do not build navigation or social ride features. Be clear in the app that it may miss a crash.
Learn what you need on Sefism
- Mobile roadmap : background services and sensors on Android.
- Machine learning roadmap : classification, thresholds and evaluation.
- Data analytics cheat sheet : handling and plotting the sensor logs.
- Android developers documentation : foreground services, sensors and SMS.
- Google Play Console help : policies on SMS and background location permissions before you publish.
Get help with this idea
The safety plan for data collection and the choice of operating threshold deserve a second opinion. A mentor can help you cut the scope to what your team can finish, choose between the stack options above, and design an evaluation your examiners will respect. You still build it; the help is on decisions, not code.
New here? Create a free account first.
Ideas and guidance, not finished projects
These are project ideas and scoping guidance, published free for students to use as a starting point. I do not build, write, or sell final-year projects, and I do not complete coursework for anyone. Take an idea, make it yours, and build it.
Not sure this one fits you?
I help students pick an idea that matches their skills and their deadline, then scope it down until it is finishable. Guidance only, never done for you.
Stuck on something specific?
Writing only gets you so far. If you want an answer to your situation rather than the general case, book a session and we will work through it together. Sessions are free for approved Sefism members, and a few slots open each week.
Follow along
New writing, resources and project ideas land here first.