Not all ideas are good, and this one got scrapped pretty much immediatelyDuring my senior fall at MIT, I got the exciting opportunity to take 2.009, a semester-long mock start-up class about product design. With about a dozen other engineers in my group, we were tasked with ideating, designing, and manufacturing a complete product in just two short months. And at the end of it all, we presented it on stage, live, in front of a couple thousand people (see above)!
The very first thing that we did － and spent a critical amount of time on － was coming up with a bunch of ideas around the class' theme of "Balance." Most concepts only ever saw the light of day through sketches or mere words, and some had extensive research and feasibility analysis before ultimately landing on one idea. From this arduous process of brainstorming emerged our product, which we called Contact.
One of the ideas I presented that got scrapped
Not all ideas are good, and this one got scrapped pretty much immediately
The presentation video (above) does a much better job of explaining this, but the problem we addressed was children's safety while biking/skateboarding/scooter-ing. Essentially, while kids these days are essentially born with an iPad in their hands, a surprising amount don't own a mobile cellphone that would save them in a pinch. There's no worst feeling than walking your bike home with a bruised knee and dried up tears. For parents, that lack of contact (heh. see what I did there?) is stressful, and only amplified when their child is biking around the neighborhood or to/from school.
So we sought to fix that by designing a product that does the following:
We wanted to give parents peace of mind without impeding on their child's freedom to explore the world.
So what did we build?
Contact is essentially a phone in the form factor of a helmet attachment; it connects to the LTE network, has GPS built-in, makes calls (ish), and, like Apple's crash detection will call for help in case of accidents. Of course, parents could just buy their kid a phone, but our product is specifically tailored towards children who ride their bike without supervision. This has numerous advantages:
Since this class is a mechanical engineering capstone, it was a tad ambitious to pursue such an electronics-heavy project. Thankfully, I'm actually an EECS major and my team is super smart and learned quickly. I contributed to Contact's circuit board and firmware.
Like I said, Contact is essentially a smartphone minus the screen. And it has to be ultra compact since kids don't want to wear a clunky box on their head. And it has to be considerably cheaper than a smartphone, otherwise the incentives to purchase this product would be slim. As it turns out, this is a really hard problem because all of these modules need to be packed in a small form factor without exploding the budget:
Early systems diagram, before building anything. Amazingly we were able to fit everything mentioned here in the final prototype
I think I ended up designing ~6 different boards in these two months. About half of those are revisions, and the rest are completely new designs. Yes, we dropped multiple $100s more than once on express shipping. And yes, they were all assembled by hand, in EDS, because assembly in PCB houses takes another 3-4 days (Anthony & Alec, you'll probably never read this but you're the best, thanks for keeping lab open so long!!).
First version of the board. Massive, and expensive, but worked well enough for a proof of concept.
Same circuit as above, but this time on a PCB! The IMU didn't work though, so we fixed a breakout board on top...
First revision. IMU still didn't work! Damnit!
Second revision. I must be cursed, these I2C lines to the IMU just don't want to work
These boards are a completely different design, we were considering a "sandwich" approach to slim down a tad
At last, the final version (I skipped a few because you get the point)
Underside. Ignore the slightly overcooked SIM tray
I hope you can appreciate just how small this thing is. There is zero wasted space!
Once again, that small board really does integrate every demand listed above. And it's dirt cheap, about $20 even at low-volume prices. These incremental improvements in size are most appreciable through the enclosure, which started at something ridiculous.
First PCB would've resulted in this bulky form factor
I designed all these on KiCAD, and ordered through JLCPCB, PCBWay, and OSHPark. If you must know, JLCPCB was by far the best option.
We used Micro-Python and Arduino over the course of development. These are easy to pick-up and work well enough, and different people implemented different functionalities separately. When it came to integration, however, everything sucked. Although I'd planned for us to use FreeRTOS (which Arduino uses under the hood) to "run separate programs concurrently", assuming everything would "magically click" was a mistake. Then I just re-wrote the entire firmware in Rust using Embassy and everything magically clicked.
Wireless connectivity was one of the hardest parts of this project. Technically the final product has both WiFi and Bluetooth, but of course these don't work outside in the streets. So we looked towards 2G/3G/4G/LTE and vetted a few dozen chips. Now, this isn't that hard of a problem if you're willing to dish out ~$100 on a well documented chip. But we needed to go much, much cheaper which landed us on the SIM7080G.
All things considered, it's a great chip. For under $10, it provides GNSS, LTE (Cat-M1 and NB-IoT) and miraculously supports the US bands. The issue was documentation --- very hard to find and all existing firmware was either buggy or incomplete. You interface with it using AT commands, a 1981 standard for interfacing with modems. Ridiculous, right?
Over the course of 2-3 weeks, I struggled getting this thing to work. Most of that time was spent cross-referencing library implementations (they sucked on their own, but maybe together?) and looking for any semblance of documentation. I'd get some things working, but very inconsistently as if it were up to luck.
Things really picked up when I asked for some help, though. I made an AT command REPL to easily talk to the chip (the hard part is what commands to send and in what order), and with a few people on the team we cracked it. The last part was packaging all our findings into something reliable, because at some point the REPL itself (implemented in Micro-Python) started being the failure point. So I wrote a custom AT command parser that works with the SIM7080G's quirks, and async drivers for the chip with failure recovery (again, in Rust and using Embassy).
Since I led the EE and firmware teams for Contact, I got a bit of leadership experience. Of course, everyone on the team is cracked so my job wasn't super difficult, but I learned a lot about planning things out and delegating work. The most fun part though is showing off what we've been working on to the rest of the team; here is one of those update slide-decks.
This subsystem was led by another sub-team, but I helped a bit as they needed some electronics stuff early on (i.e. couldn't wait for the PCB and firmware to be complete first).
I threw together an accelerometer + gyroscope thingimabob wrapped in a lot of bubble wrap. It communicated to a host laptop using ESP-NOW, and streamed sensor data in realtime and a very high throughput. Then, the host laptop would process this data using a Python sandbox. The idea was to abuse the sensor thingimabob and gather valuable data, while also prototyping algorithms for crash detection.
This is something I threw together in an evening and was helpful until the end. Strictly speaking, it's a "complex" program (maybe not so much these days with vibe coding getting so much better) with UI, serial communication, graphing and a Python interpreter. It's really a testament to how nice the Rust ecosystem is that this velocity is possible at all.
I can only speak of the work that I did, since I remember it best. But this little entry doesn't even begin to cover the incredible amount of work that went into Contact. The enclosure, antenna considerations, mounting, logistics, financials, crash detection, marketing, user surveying, and so many other things were handled by the rest of the team. I'm so glad I got to take 2.009 and work with a team of incredibly talented engineers, and to have had the honor to present it on stage in the end.