the nyc marathon wearable

July 31, 2014 · 0 comments

i won't bother addressing my long absence from this blog (despite two posts, two years ago saying i will do more with it - perhaps in an upcoming post). rather, i'll just get right into what i do want to share here. that specifically is a new area of interest i've decided to pursue and an immediate application of it.


the preamble first. for reasons i can not honestly recall, i decided to get into electronics and circuitry, specifically the arduino platform (read more here). skipping ahead through a number of weeks of exploration and a course at OCAD on the subject (tl;dr it's been great - perhaps another post on the whole pursuit), i'm tackling my first real project, one that will actually be seen by lots of people. that's exciting.

a friend of mine, Mike Bodsworth, is running in the NYC Marathon this year. when he told me i immediately said "how about i make you a wearable for the race?" the response that followed was "sure, what does it do?" i offered the comprehensive response "stuff. for the race. you know, something to track you and give you some feedback. and some flair. that kind of thing." and so it was ordained.

here is the real response to that question and what i'll be building, testing, tweaking, issuing on race day and creating a memento of the day.

my approach
going in i wanted to keep some core principles (ie. restraints) in mind so this wouldn't get out of hand and be a functional system.
  1. the technology can't get in the way of running. this takes a lot of different forms from size, weight, movement restriction and just general comfort. primarily he's there to race and the technology is a complement to that so it need not be a constant annoyance. this would limit some of the devices to be employed, where they are placed (no wires running down limbs) and how (if in any way) they need to be interacted with.
  2. durability. it's a 4+ hour time period, jostling about, potentially poor weather and being attached to a sweaty dude (weatherproof).
  3. collect lots of data for later use. there is the device part and the data part as two separate parts of this project. the device for the race and good data to create a keepsake of the race itself (more on this later).
  4. provide some real time feedback. while much of the device will be passively collecting the data, some will be used in real time to provide simple feedback to the runner (more on this later). Simplicity is essential and what and how it's provided can't conflict with the other principles.
  5. add a bit of flair. mostly to support the charity he is running for; to visually represent the organization and be noticed. and again, can't conflict with other principles.

why create something?
the other question implied in this is "why not just use what already exists (namely a smartphone or some other existing wearable like a fitbit or fuelband)? the simple answer is: to make something. making things is a goal unto itself. but there's more to it than that.

first, to eliminate the existing devices, from the available options. primarily, these two gadgets use a basic accelerometer. that's great and they've taken that simple sensor really far. so what you are are really paying for is the software and nice industrial design. those wristbands are essentially a fancy algorithm to provide approximates for all the stats it gives you based on manipulating and interpreting the data points from the accelerometer. the apps they come with are handy and all but that's their secret sauce. for this project, i didn't need the fancy software stuff. i'd be writing simple code to collect essential data points that i would then do stuff with after-the-fact. while we're on data, that's the second big problem. getting the usable data out of these would be a pain in the ass to use how it want to. that's reason enough. especially when you consider my final point, cost. the cheapest fitbit or fuelband costs $99 which is pricey for an accelerometer that i can't get raw data out of. the accelerometer for this project to give me actually usable data costs $15. easy decision.

using a smartphone would be nice, but i'm not an app developer. i'm not an electronics maker either but simple devices are far easier to build than learning an entirely new programming language and user interface design. and again, the data. it would be tricky to get the data out and that's fundamental to this project.

what's all the data talk?
as much as this is an exercise in making a functional device, it's also about making use of data (as another interest of mine). because the NYC Marathon is kind of a big deal, i wanted to make a memento of the day for Mike. essentially a snapshot of the race and his 4+ hours of torment that he can be reminded of on his condo wall daily. using the data collected (the device description below will outline what i'm gathering), i aim to create a really interesting data visualization as art along with parts of the device and other pieces from the race weekend (namely pictures). more to come on this once we get into the next phase. in all honesty, this will be the most difficult part of the project for me. i'll do a few future posts on that phase of this.

race assist
capturing data for after-the-fact is pretty easy, but processing it real-time and providing some visual prompts to help with the race is another thing altogether. i talked to Mike about what he wanted out of the race and what was valuable for him to know. as he isn't a serious runner, the only thing that really mattered to him was a time goal and beating his personal best. that made it easy in not having to add in a lot of extraneous biometric sensors, displays for real-time updates or anything overly complicated.

what i arrived at (that you can see below) was a simple display mechanism that gave him only the essential information he would need to alter his run while in the race. it also delivered on the flair. using a basic lighting system, in an easily visible area, it would track his progress of distance run and remaining with a simple visual cue if he was on-pace or off-pace. a binary approach to the only things he cares about.

and now the device
let's start with a sketch that should explain the main components (click image to enlarge).


i aimed for minimalism and simplicity in the visible elements and hopefully delivered on my principles. the heart of it all is in the water bottle though. the one asterisk on there is the camera. the belt was the best place to mount it for steadiness and unobtrusiveness even though the images might look a bit weird. it also might not even make it in the final design. no point in having it if the images are going to be crap.

what now?
as of the date of this post, i have about 3 months to build the final device, write all the necessary code and actually make it work on race day like it should. what's in between is a lot of trial and testing of each component and some sewing (weird). who knows what will change from this initial design over 3 months.

first up for testing - the accelerometer.

Labels

subscribe/follow

 subscribe to rss feed Add to Technorati Favorites

tracking

 
Clicky Web Analytics