Blue Team!
Assembly!
Presentation Video
Drowning Alert
Drowning Alert is a wearable device that helps parents keep children safe at waterfronts (e.g., lakes and oceans) by alerting those nearby when the child is potentially drowning.
Product Contract
View Product Contract in New Window
Storyboard
CAD Images
View Fusion Preview in New Window
View CAD Files in New Window
Contributors
Danielle Allison: (SI) Coordinating between subteams, deliverable submissions, design input, product testing plan
Joseph Ntaimo: (SI) Coordinating between subteams, design input, research, parts sourcing, final assembly CAD
Pablo Alejo-Aguirre: (sensing subteam) Subteam leader, PCB sketches/dimensions, parts sourcing
Josh Sohn: (sensing subteam) PCB CAD, inflation design input, final assembly CAD
Eddie Barrios: (alerts subteam) Subteam leader, final assembly CAD, parts sourcing, alerts and latching research, GrabCAD coordination
Daniel Amaya: (alerts subteam) Code of ethics, alerts research
Luis Ibarra: (alerts subteam) Alerts research, sketching, LED/PCB CAD, CAD imports
Mulan Jiang: (product vision subteam) Subteam leader, product testing plan, product specs, storyboard
Zoe Wu: (product vision subteam) Product specs, storyboard
Jonhenry Poss: (wristband subteam) Subteam leader, GrabCAD coordination, bed, buoy, and wristband CAD
Carly Long: (wristband subteam) Product contract, product testing plan, drowning block diagram, deliverable submissions
Andrea Moncada: (wristband subteam) System schematic, wristband CAD, product specs, final assembly CAD
Kaira Samuel: (latching subteam) Subteam leader, final assembly CAD, latching research and design input
Christina Patterson: (latching subteam) Inflation brainstorm, final assembly CAD
Sophie Longawa: (latching subteam) Code of ethics, inflation research, latching design input
Reviewer Feedback
Georgia Van de Zande
Feedback
- How does the lifeguard know to be looking for the light? - Cool idea to have the one piece float to the top so you don’t have to produce sound/light below water. How do you make the release button easy to press when a kid is panicking, but hard enough that they wont accidently hit it - How are you planning to make something waterproof and have loud speakers? Look into how smartphones do this. It has something to do with the speaker mesh size and coatings
Tom Dillon
Feedback
I really liked the idea of deploying a separate system that floats to the water surface. Overall I think the team could look into defining specs a little more. For the alerting system, I know you haven't decided yet whether to use light/sound/a combo of these to communicate with the lifeguard. Using back of the envelope calculations to determine power requirements might be a good place to start in investigating feasibility of these options. For example, you mentioned you need to inform a lifeguard that might be as far as 61m away. On a busy beach, you could try to quantify the decibel level that the lifeguard can reliably discern. dB can be converted to power intensity (google "inverse square law"), which could inform the power requirements of your speaker at the 61m distance. Maybe from these simple calculations, you find that you need a JBL size speaker to create the required sound, which straight away tells you the design is infeasible and you should explore alternative options (look at the power density (W/kg) of common speakers). This will save you the hassle of trial and error prototyping. Just an example, and there's probably a similar analysis you could do for light based system. On a more conceptual level, maybe you could leverage the fact that you need to communicate with one person (the lifeguard) rather than everyone in the beach vicinity. Just one idea - I'm imaging a system where many kids "sign in" with a lifeguard by scanning their watch at the lifeguard tower, which maintains direct communication with the lifeguard on duty while they're out swimming (using e.g. RF, long-range bluetooth). P.S. might also be good to consider the trade-offs between bouyancy of your device vs. weight of the alerting system.
Keith Clavin
Feedback
The drowning alert is a promising device with an important function. I think the topics raised within the Q@A echo a lot of my impressions. When I first saw this device, I imagined it was linked to a lifeguard in a way that allowed them to help a drowning person before they were actually drowning. I realize this is a difficult task for a number of reasons. However, I do think a linked component that is triggered manually may be enough for this project. I appreciate the desire to have an automated model, and maybe that is something for a future iteration, but it seems especially tricky to develop an alert system that will cut thru the water sonically and/or visually with glare from the water, noise, etc. Would it be possible for the watch to either trigger a response on a lifeguard's station or some external buzzer or something near to the pool? They could be paired in a fairly straightforward way and your testing would revolve around the dependability of that system.
Braunstein
Feedback
Hi. It is good that you recognized that sound and light, when submerged, will probably not provide enough of an alert signal. I also perceived that you punted on the O2 measurement, presumably because of technical difficulties in obtaining a reliable measurement. If so, I commend the team for receiving input and acting on it. The idea of an ejected floating pod is interesting. I really wonder about the viability of this in a small package though. Look at any number of human factors books (Salvendy & Karwowski) to understand the size of a child's wrist. Then make reasonable models. There's your size constraint. I have a hard time believing you fit an ejection system, pressure sensor, IMU, batteries, LED, peizos, horns, the associated supporting electronics, and mechanical packaging into something that can comfortably fit on a childs wrist. That's a lot of stuff. What was in the CAD model? was it accurate and complete? and how big was it? For me, it didn't compute. If it was real, then hats off to you - make it immediately and start testing! You're not going to know what to fix until you have the first system. Are there opportunities for a receiver somewhere (pool installed) that would alleviate the signaling requirements. Is there anything that could be installed underwater to detect a wearable alarm? If not, is there something that could detect a lower power signal from an electronic beacon at the surface? I haven't seen much exploration in splitting the system up this way. Sure, such an architecture may not work at the beach (maybe it would), but a pool installed receiver/alarm system seems doable. In doing so, the alarm can be as powerful as one wants, and it only need be triggered by a low power signal. Since the alert is now off board, you may have regained valuable real estate to make the device less cumbersome and more reliable. On the communication side, you talked about the pool, but your storyboard showed the beach. There were a few other inconsistencies, so be sure to clean things up like that in upcoming presentations, lest you confuse your audience.
Sam Ihns
Feedback
Hello blueberries, the move toward a floating signal indicator is a push in the right direction given the difficulties of projecting your light/sound underwater. However it also highlights some new challenges, namely size/form-factor and (most critically in my opinion) battery life. An apple watch has a 300mAh battery, which is probably around the max you could cram in there. Doing some max power draw calculations to run your alarm system will indicate whether a small LiPo is even viable (Steve Banzaert will be super helpful for this). I like this pivot to the floating, however, because more broadly you are rethinking how the device can interact with the pool environment in ways you can take advantage of. I think pools may be a better environment for this product than open-water: I can't see a situation where a parent lets their young child swim freely in the ocean in any case, especially if there is a risk of drowning. Also, in the oceans many drownings are paired with Rip Tides which can pull people down/away in ways that would limit the effect of the device. In a pool, however, there are likely people closer by (easier to alert) and perhaps more infrastructure you can take advantage of. An easy pivot to make with this product could be to sell it as a larger product infrastructure to pools/water parks themselves - kiddos can put on a provided sensor strap when they enter, and the pools themselves can have the sensory infrastructure built in to collect a wireless signal from the sensor and alert the relevant parties. Don't be afraid to have subteams iterate for a few days at this point, as long as they are agile. So far in the class, your team has spent ~364 student-days working on this concept (student-day = one student working on this concept for one day). Your team has ~750 student-days remaining before final presentation. Good use of subteams for the first 200 of these days will be really valuable towards the end. One final thought I wrote down but couldn't fit in anywhere: this product may always struggle with false-positive drownings even with a good algorithm. Maybe if the device is detecting a drowning, it could give some indication to the wearer of a "check-in" and they can either confirm they are okay (avoiding a false-positive) or that they need help (allowing the device to deploy a few seconds faster, which could be critical in a drowning). I also agree with some of the other reviewers that perhaps a manual trigger is all you need, especially if autonomous drowning detection is such a difficult nut to crack.
Jordan Tappa
Feedback
I enjoy the direction you're moving with this newest iteration. I think your team realized how difficult/impossible transmitting sound out of water is. You have a few challenges up ahead, waterproofing with two detachable components is tricky, as well as recharging the launch able side if you continue with an electronic system. Consider encasing the detachable module in a silicon shell, this would help with the solenoid at least (definitely consider other actuation methods) however the solenoid could be internally pushing on the silicon skin and release without going through a clearance hole. I worry that sensing proper drowning conditions is going to be quite difficult. Anecdotally I can imagine a drowning case where someone is flailing and about to drown as well as one where they end up facedown floating on the surface. Also it would be nice for your future milestones and the final presentation. Additionally I think alerting the lifeguard is more non trivial than simple lights and sound can do. If it were a small pool with under 20 people at night I would say no sweat, however during the day at a loud pool with music in the background, I have doubts that your floatation device will be seen. Also is there concern that the device - if noticed - will have floated too far away from the child to be meaningful. The lifeguard will know someone is drowning, but will scramble to identify who and where. Consider a tether or similar so the device does not get lost.
Liz Stevens
Feedback
Keep conducting user interviews to ensure the product usability gets prioritized. I know when I take my daughter to the pool or beach, there are a million things to pack - floatie, water toys, sand toys, umbrella, sunblock, water shirt, bathing suit, towels, etc., etc., etc. and we always forget something. For busy parents, will this product be easy to use? How easy is it to take on and off? Will it stay on during vigorous play? If kids can manually sound the alert, will that cause lots of accidental deployments? Do parents think that light and sound are the best way to keep the child safe? Would a GPS tracker be of any use, say in a rip tide situation? If the child is submerged in water, will the alert sound be audible through deep water?
Juhan Sonin
Feedback
Death. Your kid dying. Talking about death ain't easy, and has to be part of your behind-the-scenes product development... since that's what you're tackling. In manufacturing, in product engineering and design, we have to think about error rates, product malfunction rates, and up times. 99% of the time, a fitbit works as expected after unwrapping it from the package. Nobody dies when a fitbit doesn't work or the piezo pickup isn't calibrated correctly for counting steps. What's the acceptable human death rate of a product? Wholy moly!@#! Start grappling with this now. Don't sugar coat it. And expect false alarm city. False negatives, false positives in droves. That is The Design problem.