Ollo turns a camera's observation into a caregiver's response: it notices a possible fall, gets the right person's attention, and tracks who is going to help.
Inspiration
A person having a seizure or choking may not be able to ask for help. Someone who cares for them might be in the next room, or miles away, and has no idea anything has happened.
The scale is real. WHO estimates that 50 million people worldwide have epilepsy, and identifies many epilepsy-related deaths from falls, drowning, burns, and prolonged seizures as potentially preventable. Severe choking can leave someone unable to cough, speak, or cry.
Many homes and care settings already have cameras. But a camera only records. Nobody watches it every second, and even when software spots something, a notification buzzing on a phone isn't the same as a person responding. That gap, between something was seen and someone is on their way, is what we set out to close.
We started from those moments. For this project we focused on the one we could build and test honestly: falls.
What it does
Ollo connects compatible cameras to a caregiver response workflow:
- Notice. Pose estimation tracks movement over time and flags a possible fall.
- Check. looks at 4 face-blurred crops from the moment of the fall and writes a plain-language description for the alert: what it sees, where, and what to check.
- Tell. The caregiver gets a Telegram message with a frame from the camera, answering three questions: what was observed, where, and what to do next.
- Reach. If they haven't responded, a Cartesia-powered voice call explains what was seen and asks whether they can check. It reaches someone who isn't looking at a screen.
- Own. SpacetimeDB tracks who has taken responsibility. If the caregiver acknowledges in time, the pending call is canceled. If nobody does, the alert escalates.
- Record. The dashboard keeps a timeline of each incident: detection, alerts, acknowledgment, resolution.
What Ollo is not. It doesn't diagnose seizures, choking, or any medical condition. It isn't a medical device or a substitute for emergency services. Detection from camera footage can be wrong and only works where the camera can see. We have not shown that it prevents injury or death. This is a prototype of the response layer.
How we're different
Wearables, medical alert devices, and smart cameras already cover parts of this problem. Ollo focuses on what happens after detection: getting the observation to a responsible person, in a form they can act on, and recording who responded.
It works with existing compatible cameras, so the person being observed doesn't have to wear a device or press a button. Its usefulness still depends on camera visibility and detection reliability.
How we built it
- Ultralytics YOLO + OpenCV extract pose and evaluate movement across frames. We look at movement over time because a single frame can't separate a fall from someone sitting down.
- SpacetimeDB holds alert state, ownership, and escalation in one place, so the dashboard, Telegram, and the voice call always agree on who is responding.
- A background worker turns alerts into Telegram messages (visual context) and Cartesia calls (spoken explanation).
- A React dashboard shows footage and incident history.
Note on the demo: our screenshots use a playroom scene as sample footage. The detection we built targets people falling in general.
Challenges we ran into
Falls look like other things. Lowering yourself to the floor on purpose is not a fall, and visible movement alone can't establish a medical emergency. We had to treat every detection as "possible" and say so in the alert.
Delivered is not the same as answered. A message arriving, a phone ringing, a call being picked up, and someone saying "I'll check" are four different states. Treating the first as success would hide the failure that matters most. So we built around acknowledgment, not delivery.
Optimized the cost. Running Claude on every frame set every 3 seconds would cost about \$18 per camera-hour (Opus 5.5). We used math to avoid this. Local YOLO-pose and our rules (keypoint geometry, change detection) run on-device for free and decide when something is wrong. Claude is called only after a local alert, on 4 face-blurred crops, for about \$0.01 per alert (\$0.0003 on Haiku 5.5) and \$0 while nothing happens. At 5 alerts per hour that is about \$0.05 per camera-hour instead of \$18, a reduction of roughly 360×.
How can math handle our problem
Our system uses AI to track body movements in each video frame. We measure movement relative to the person's standing height, h\(_0\) (the median bounding-box height while upright), so it works at different camera distances without calibration.
A fall is detected using three conditions:
- Sudden drop: The top of the body moves down by at least 0.45h\(_0\) within 1.5 seconds.
- Low position: The body height is less than 0.65h\(_0\), the bounding box is wider than tall, or the torso tilts more than 60\(^\circ\) from vertical.
- Fall confirmed: The person stays low for at least 0.8 seconds, following a drop within the previous 3 seconds.
This helps distinguish falls from sitting or slowly lying down. We also allow tracking gaps of up to 0.5 seconds, since the AI may temporarily lose track of someone on the floor.
Accuracy
We tested on 100 videos, none used for tuning.
| Measurement | Result | 95% Interval |
|---|---|---|
| Falls detected | 37/50 (74%) | 60–84% |
| False alarms | 12/50 (24%) | 14–37% |
| Median detection delay | 1.8 s | — |
Our original detector caught only 15/50 falls (30%).
Since the dataset is small, we report 95% Wilson score confidence intervals rather than relying on percentages alone:
$$ \frac{\hat p+\frac{z^2}{2n}\pm z\sqrt{\frac{\hat p(1-\hat p)}{n}+\frac{z^2}{4n^2}}}{1+\frac{z^2}{n}} $$
where \(\hat p=k/n\), \(k\) is the number of successes, \(n\) is the sample size, and \(z=1.96\).
In addition, we use a Kalman filter in combination with the Hungarian algorithm. Feel free to refer to this paper for more details: https://ieeexplore.ieee.org/document/7849633
Accomplishments that we're proud of
We built a working handoff, not just a detector. In our demo, a caregiver is alerted, acknowledges from the dashboard, and the pending voice call is canceled because a human has taken ownership. The record shows each step.
Telegram gives the caregiver the picture. Cartesia makes the observation audible to someone who isn't looking at a screen. Together they make the alert hard to miss without making it noisy.
What we learned
A useful safety alert answers three questions: What was observed? Where? What should I do next?
Clear language, visible uncertainty, and a single owner for each alert matter as much as the detection itself. A technically perfect alert nobody takes responsibility for is still a failure.
What's next for Ollo
- Evaluate detection on representative, consented footage and measure missed events and false alarms.
- Test the response flow with real caregivers.
- Strengthen privacy: what leaves the camera, who sees the frames sent in messages, and how long anything is kept.
- Make alerts reliable across channels, and turn each incident into a shared thread for the whole care team.
- Make it compatible with digital watches, such as the Apple Watch and Garmin watches.
- Connect with hospitals, so the patient's record and fall clip go straight into the ER's system before the ambulance arrives, with the patient's consent.
- We currently only use the model to detect falls involving people. However, we plan to expand its applications to other everyday accidents and natural disasters, while maintaining low costs and high accuracy.
We would need all of that before considering real-world use.
Built With
- cartesia
- claude
- figma
- mana
- ngrok
- notability
- python
- react
- spacetime
- twilio
- typescript
Log in or sign up for Devpost to join the conversation.