Coaster Metrics Project

A Detour

2006-07-14T23:34:00.000-07:00

I figured it would come to this. Minor setback -- the Zaurus's serial connector doesn't provide power (more specifically, it doesn't provide enough power), which makes the accelerometer useless out-of-the-box. It works fine and dandy on my PC, but the Zaurus can't drive it just yet.

There are two options:

create my own serial cable, splicing the power wires to run to a separate power sourcepower
power the accelerometer directly

Either way I'm in the land of soldering. Now, I've constructed some pretty basic circuits in the past, and done a good deal of cable splicing for theatre stuff, but I don't feel comfortable doing work that's potentially dangerous (at least, dangerous for the equipment) without some training. Or at least some practice.

Since I don't have the time/energy/money to actually take a class, I'm thinking of giving Electronic Circuits for the Evil Genius a try. It seems like a fairly thorough introduction, but doesn't assume you need to be told what electricity is. I took AP Physics -- I know what a resistor and capacitor are, and once upon a time could decipher a circuit diagram. I see this as a combination refresher course / hands-on training opportunity. I'm all about the hands-on. (If anyone knows a better resource, please feel free to interject. That book is recommended by MIT OpenCourseWare, so I'll take that as a fairly respectable endorsement.)

So that will probably take a little while before I'm comfortable enough to actually tackle this part of the project head-on. That's ok. It's not like I'm working towards a deadline or anything. Hobbies rock.

It seems that someone (Matt? The same Matt I know?) from the Center for Applied Biomechanics (where I worked during the summer of 2004, programming databases) found this blog recently. How he found it, I don't know, but he provided some useful feedback on the data analysis and capture. Pretty neat! Maybe some more useful people will drop by and give me hints.

Adventures with the Zaurus

2006-07-03T18:51:00.000-07:00

Fourth of July weekend, and I'm spending some time getting used to the Zaurus, so it can be more amenable to my means when I later use it as the brains of my little operation.

First a picture:

You can see here the Death Star orbiting the forest Moon of Endor. Er. I mean.

You see the Zaurus, sitting on the ironing board that also serves as my workbench. To the left, out of frame, is a Leatherman and a rotary tool currently being put to work on a wayward Furby. It asked too many questions.

I've been fairly impressed with the Zaurus (henceforth, "Z") from a hardware perspective. It's a nice little machine, fairly zippy, and looks like it could be a pretty decent PDA if I went in for that sort of thing.

The Z's interface

It even has a tiny keyboard!

I had been told that the Z ran Linux, but was initially a little confused by what that meant. I had read about OpenZaurus, and figured that replacing the stock operating system from Sharp would give me features above and beyond my wildest dreams. I played around with it for a bit. While it certainly offered more flexibility, its configuration proved to be a bit esoteric. No stranger to Linux, I could have muscled through this, but when I found out that the easiest way to get Python running on the Z wouldn't work with OpenZaurus, that kind of sealed the deal, and I'm currently running a stock Sharp operating system again.

The biggest feature I would have wanted from OpenZaurus would have been USB networking, so I could access the internet from the Z, but it proved very tricky to get working with my Ubuntu install, and I've given up for the moment.

The next step is seeing how well the accelerometer works with the Z. It looks like there's some hooey involved in getting the serial port to act like a proper serial port, but any research into it is purely academic until I actually have the accelerometer on hand and can test it out.

The Z that I bought actually came with the Sharp serial cable, a rarity, apparently. It's even been modified to allow the keyboard to open while it's attached, which the stock serial cables don't do. But it still blocks the power port when it's plugged in, which may be something I can't live with -- it's hard to say how long this thing will have to operate in the field, but I was planning on having a battery wired to it just in case. If the power is blocked, that's no good. I might end up having to fashion my own serial cable... which means soldering. Yay.

Now let's just hope I don't brick the thing.

Additional notes on constraints

2006-06-30T22:14:00.000-07:00

I love learning new technologies, especially in the context of a personal project, because under no other circumstance does a technology present itself so openly. At least, that's been my experience. For instance, I'm going to try and do a lot of the coding here in Python because:
1. NodeBox, which I already mentioned
2. I've been wanting an excuse to learn it
3. this project feels like the right mix of light coding and quick development that I've heard lends itself to Python. It's also not doing anything super-fancy from a software perspective, so I won't be hitting my head on the language quirks right away.

I like to use open source software whenever I can. In addition to the financial benefits (yay free stuff), I like the philosophy of community driven software, especially for oddball projects like this one. :-)

Constraints

2006-06-30T21:14:00.000-07:00

As I mentioned briefly in the first post, this task is not as trivial as it might at first seem. There are a number of constraints on the project:

Cost: Doing this in my spare time and not having a desire to shell out for hardware that would have little use in other projects, I'm looking to use off-the shelf general purpose hardware as much as possible, while keeping the costs down.
Current thoughts: This constraint comes into play on all subsequent constraints.

Stabilizing: Our first thought when designing the coasterometer in our heads was to mount all the sensing equipment (camera and accelerometers) in a helmet and perhaps run cables down to a fanny pack or pocket to record the data. This base design was inspired largely by the easy availability of camera helmet-mounts for skydivers. However, on a typical roller coaster ride, the head is apt to move around quite a bit, which would skew the accelerometer data and the imagery.
Current thoughts: Mount the accelerometers near the chest, since most coaster restraints cross either the hips or the shoulders, leaving the area around the sternum clear.

Size: Most amusement parks don't look kindly on folks trying to bring unattached items on the ride. A large sensor-bearing helmet would likely be frowned upon by the ride operator. So all of the equipment has to be small enough that it can fit underneath a person's clothing without making them so bulky that a ride restraint would fail to operate.
Current thoughts: Essentially make this a wearable-computing application, and distribute as much as possible through the body so as to keep overall profile slim.

Data Recording: There are two sets of data being recorded on any one ride: the three-dimensional readout of the accelerometer, and the video feed from the camera. I had initially considered using a Phidgets accelerometer, having used Phidgets sensors on a previous project and thus being familiar with their programming interface. Unfortunately, Phidgets hardware requires a USB host port on its attached computer -- a USB host port is what is probably on your computer, a USB plug that allows your computer to communicate with other devices. Unfortunately, most computers small enough to conceal under clothing only have a USB device port -- they can only communicate with a real computer, not other devices. Tiny portables with USB host ports exist, but as of 2006 they are prohibitively expensive for the purposes of this project.
Current thoughts: I ultimately discovered Spark Fun Electronics, who make a wide variety of sensors that can communicate over good ole serial connection. This discovery of serial sensors with an easy software interface allowed me to pursue a much more affordable recording device.

Computing Device: It has to be small enough to conceal, powerful enough to be easily programmable, and affordable enough for me to get one. I've currently settled on using a Sharp Zaurus 5500; it's an older device, which is why I was able to buy one for ~$50 off a friend. It runs Linux, which means a decently sized community has grown up around it to support development. The MIThril project at MIT uses a Zaurus for their applications, so I figure it should do the trick.
Current thoughts: The Zaurus is currently the only component I currently have in my possession; hopefully it will work out. Otherwise it's back to the drawing board.
Note: It has been suggested that I could reduce costs and complexity by creating a custom circuit with an accelerometer chip, a microcontroller, and an EEPROM to record the data. Unfortunately, I know little-to-nothing of electronics and circuits, and need a software interface. I'm always interested in learning something new, though, and am considering a custom circuit if I ever make a second version of the coasterometer.

Video Recording: There are two problems here.
1. The first is camera placement -- I can't very well strap a camcorder to my head and keep it concealed.
  Current thoughts: Use a tiny camera along the lines of a micro board cam and conceal it behind a shirt button. This allows it to be mounted in the sternum, right near the accelerometer, so clutter and cables can be reduced in the final design.
2. The second issue is the camera itself. I want to use a MiniDV camera so I can easily edit the footage later on a computer, but I need to be sure the camera has analog input capability so it can interface with the tiny camera. Sadly, not all cameras have this ability any more, and trying to figure out which ones do is a tricky proposition.
  Current thoughts: More research is required in this area. I would like to have a camcorder anyway, so the cost of this purchase is not considered a "project expense" per se. At the same time, I want to exercise the same careful, researched buying habits I have with all my electronics.
Wearables: Ultimately all of these devices will need to be mounted on my body, and the camera and computer both need to be accessible so I can turn them on at the start of the ride. Where exactly they should go is one question, but the other is how to keep them there?
Current thoughts: Need to find some kind of tight-fitting, stiff vest for the tiny camera and accelerometer; either that or some good way of securely strapping something to my chest that doesn't involve duct tape and pain. I'm thinking of putting the Zaurus on my thigh, with a flap cut in a cargo pocket to allow access. How it stays there is still a question. And then where the heck should the camera go?

Data Processing: At the end of a run through a roller coaster, all I'll have from the accelerometer is a whole bunch of numbers. To work them into something meaningful, I'll need to do some post-processing and generate a visualization of the forces experienced on the ride.
Current thoughts: I recently discovered NodeBox, a Python-scriptable image generation toolkit for Mac OS X. It looks like it has great-looking output. Unfortunately, my knowledge of Python is minimal at best, but what better time to learn? I'm a little concerned about limiting the portability of the data processing code, but if NodeBox proves to be too big a hammer for the task, I can always just make a generic ImageMagick script anyway.

Video Editing: After I have the beautiful output detailed above, I would like to overlay it on the first-person video from the ride, so someone watching can get a sense of the forces they would experience while seeing the coaster move around the track. I could do this with custom software, but it seems like more trouble than it's worth, and I want to edit the video anyway. I know there are simple video editors out there, but after working with real editors like Final Cut and Avid while I was getting my master's degree, I can't go back to simple editing. Unfortunately, I'm no longer a student and can't afford to shell out for Final Cut Pro at this point, nor do I own a Mac capable of running it well.
Current thoughts: I do, however, have a pretty powerful PC (have to keep up with the industry for my day job), and have heard decent things about Cinelerra, an open source high-end video editing system. I'm still having some trouble getting it running on my Ubuntu install, but that phase of the project is a ways off yet.

Whew! I think that pretty much covers the set of constraints for this project. It's not an easy nut to crack, and I would certainly appreciate advice on any of the points. In particular, at the moment, I'm most worried about how to secure the devices to my body, but all of these constraints are difficult problems on their own.

How it all began

2006-06-28T21:27:00.000-07:00

At my alma mater, the end of finals and graduation are separated by a week. A large portion of the population (though I hesitate to say a majority) spends this week at one of several beaches along the Atlantic coast in a tradition called, imaginatively enough, "Beach Week."

I went to Beach Week after my first year, but found it to be not quite my cup of tea. Having spent my formative years at another beach, I wasn't quite as gung-ho for the sandy brine as my classmates. The next year I joined a few of my friends on their long-standing tradition of "Alternative Beach Week." These wise folks spent the intervening time period riding roller coasters and (the year I joined, and most years since) seeing the movie premieres that typically abound during that early portion of the summer. Now this was something I could get excited about.

One year, while waiting in line, we got into the age-old (among coaster enthusiasts at least) debate as to whether the front, back, or middle of the train provided the so-called "best ride." While the quality of a ride is purely subjective (some people not enjoying bumps, others relishing them), we could not even come to an agreement as to where the forces of a ride would be the greatest. This was most bothersome, especially since our group is composed heavily of engineers.

So we created, in our minds, an apparatus that could measure the experience of riding on a roller coaster. It would contain accelerometers to measure the forces and a video camera to record the visuals. It sounded fairly simple.

It actually is not.

While it seems most of my group has since lost interest in such a project, I find myself now both gainfully employed and with a modicum of free time. And I still love roller coasters. Thus you have the Coaster Metrics Project. In this blog, I will be recording my efforts to build the measuring device (coasterometer?) and the results of my visits to roller coasters with the equipment.

Hopefully it will be interesting to someone.