Final (Week 1a - Principles & Practices)
- Sketched your final project idea/s
- Described briefly what it will do and who will use it
Hi-tech multi-tools are no stranger to sci-fi nerds from every universe imaginable.
- There’s the Tricorder, a multimeter-like device that measures everything from diseases to radiation to oxygen content (and probably voltages and currents)
- The Sonic screwdriver, a magical plotdevice most famously wielded by Time Lords that does whatever the plot requires
- These tools also come in wrist-mounted, gauntlet formfactors, like the Pip-boy or the Omni-tool
- and so on and so forth…
I started out thinking I wanted a wrist-mounted device that could listen to and process my thoughts, but I’ve realized my full vision is a wrist-mounted multitool (that serves as a jumping off point for other wearable projects).
I get asked why I have two “watches” a lot, so might as well lean into the idea even more…
overview of the wristLogger.
|vinyl cutter||solder stencil|
|3d scanning||wrist/body model|
|molding and casting||overmold|
|input||pushbuttons, mic, xl|
|app interface||dataviz webapp for transcriptions|
- the wristLogger body itself will have a laser-cut acrylic display cover and use a cast process to overmold and encapsulate the electronic assembly.
- I plan to use cnc-milled 1-sided PCBs for prototyping, but the final product will require higher circuit density. I may use the vinyl cutter for both flex circuits and solder stencil.
- 3d scanning will be used to take a scan of my forearm, so I can design the gauntlet body ergonomically. I will use flexure principles to create a gauntlet from sheet material.
- For HMI, I will use an ePaper display for output, pushbuttons for basic input, and a mic and accelerometer (xl) for sensor input.
- I will use either wifi or bluetooth for communicating with my phone.
- I plan to use vis.js for interacting with my data.
basic flowchart for how data will flow from user to storage/analysis
- user presses button on wristLogger to start recording
- user talks
- user presses button to stop recording
- wristLogger sends audio file to phone for transcription
- phone transcribes using online or onboard service
- phone syncs to homelab or cloud storage
- service combs memos for tags and creates relationships
- webapp frontend used to access, edit, play with database of ideas
expanded flowchart showing alternative sensor logging applications
finger strain sensor >
I injured my finger awhile back (06/21), and although its effectively healed, I still put strain on that finger cautiously. While undergoing physical therapy, I discovered that a strain gauge is instrumental in tracking recovery.
However, my physical therapist (a climber himself) only collected data during patient visits, which made me wonder whether it was possible to collect data on the fly, at the gym itself.
This sort of information could enable him to make better recommendations and accelerate recovery.
my makeshift splint immediately after the injury (yes, I used a house key. No, it didn’t work very well)
a much better splint
the idea here would be to use a minimalist strain sensor to record finger strain. However, considering its application, the challenge would be to measure strain w/o interferring with climbing itself.
motion mapper, rope health logger >
There are many forms of climbing, but can generally be divided into rope and no-rope. One form of roped climbing, lead climbing, has the climber periodically clip the rope in as they’re climbing; they start completely free from the wall.
Falls are pretty common in lead climbing, and in fact encouraged.
However, rope has a limited lifetime, and although there are other mechanisms to check the health of rope, falls are a major contributor for rope wear. Some suggest keeping a rope usage log, but when you’re in the moment, who’s keeping track?
You learn to have a lot more fun when you don’t count your nerf darts.
In this list, the wristLogger is probably the most mature/useful/complex design (I was on the cusp of sending it out to a board house, but ran into some issues with via manufacturability).
Fantastically capable little chip that I haven’t quite played with yet in real life.
the attached pdf cites credits for sources referenced during design. smartPDF file:
what I have done:
- design schematic
- design pcb
- ordered components
what I haven’t done:
- order pcb
- mcad prototype
As you can see, not completely realized yet.
One of my biggest hurdles I’ve discovered in this class is frequently and robustly documenting my projects, so it’s only fitting that my first spiral of the class is to finish a device that will aid with documentation!
I see the following sequence:
- eval boards for blocks in the system: mic, xl, eink display, mcu
- power is its own beast
- redesign based on new knowledge about best practices, etc.
- redesign for supply chain
- terminal application interface
- connecting all of the eval boards together
- if done properly, it’s possible to make this the final assembly (casting)
- final pcb
- gui application interface