Roller Coaster Track Design

The East Campus Roller Coaster happened, and was a great success.  Here's some proof.  I didn't get too many pictures of the construction process, since I was busy with the construction itself, so as I wait for other people's photos to trickle in, here are the details on how the shape of the roller coaster's track was designed.

To start off though, a brief back story about the roller coaster tradition and how I ended up being one of the people in charge of this year's 'coaster.

As far as I can tell, the first EC roller coaster, dubbed "8.01: The Ride" was built in 2004 (making this the 10th anniversary coaster).  The last roller coaster, "The Reverse Cowgirl" was in 2010, and had to be taken down prematurely since they weren't permitted.  So since then, EC has avoided roller coasters.

I've been thinking about the roller coaster since rush last year.  Pretty early on I was joined by Jaguar and then Wesley, hall-mates and fellow Mech E. 16's.  During the fall and winter, we started thinking about general track shape and construction method, and as soon as EC's Rush Chairs were elected near the beginning of spring semester 2014, we started talking with them about getting a roller coaster approved.

This post will cover track design.  A construction post will come later.

Let's get started.

Track designing started out like this:

Slightly fleshed out:

Yeah.

So we wanted a loop.

Loops are hard for lots of reason.  First, designing a loop that doesn't exert excessive g-forces at any point is non-trivial.  From a structure design construction standpoint, it's challenging as well, especially given the materials and labor limitations of Rush.   And convincing MIT administration, the city of Cambridge, and some professional structural engineers that our loop would be safe is an even harder problem.

The first of those problems was the easiest to deal with.

Fun Fact:  going into this project, I had never ridden a roller coaster, and didn't have the faintest idea how roller coaster loops were designed, other than that they weren't just circular.  I did a lot of reading about roller coaster loops, and some of the math behind them.

Before looking at any specific loop shapes though, I needed a way to look at the acceleration experienced by a person riding the roller coaster.  More specifically, I cared about the normal force between the roller coaster track and cart at any given point.  This number is important for both the riding sensation as well as design and analysis of the roller coaster structure.

Here's a simple mechanics view of the roller coaster with the cart at three different locations on the track.  I only cared about the forces normal to the track, and didn't particularly care about forces and accelerations in the direction of the track at this point.

The negative sign if inverted above comes from the fact that my code calculated theta using the arctangent of the slope.  Arctangent has a range from -π/2 to π/2, and therefore can't output an angle with a negative cosine.  Yes, atan2 could have fixed this.

I cranked out some MATLAB code which, given a set of points parametricly defining the shape of the track, could calculate the normal force (and G-forces) experienced at all points along the track.

Without going into the code line-by-line, here's how that works.  

First, I define the track as a set of points that looks something like [(x₁,y₁), (x₂,y₂), (x₃,y₃), ... (x_n, y_n)], where each x and y is a point along the track in meters with the origin on the ground at the start of the roller coaster.

To calculate the normal force, at any point you need the velocity, the radius of curvature of the track, and the angle of the track relative to horizontal.

Velocity at a given point is calculated using energy conservation with change in height from the starting point.  A friction factor is included in the velocity calculation to account for drag and track friction.

Angle at point is approximated by first calculating the slope from point n to point n+1 by (y_n+1 - y_n)/(x_n+1 - x_n).  Angle is just tan^-1(slope).

Finally, the radius of curvature at any given point n is calculated by finding the circle circumscribing the triangle formed by points n-1, n, and n+1.

This is roughly illustrated in the image below, where the black dots represent the points along the track, the blue dotted line is the approximate slope at a point, and the red circle is the curvature at a point.

So, now that I had a way to analyze different track shapes,  I needed to come up with an exact shape for the roller coaster track.  I chose to use a clothoid loop (generated from part of an euler spiral).  The curvature of a clothoid loop gradually increases until the top of the loop, at which point it decreases again and transitions to flat.  Gradually increasing curvature means no huge spikes in G's experienced by the rider.  

Here's a simulation of a 45 degree slope followed by a loop:

Loop Shaping in MATLAB.  How 'bout that phase margin?  Oh, wait....

And a 60 degree slope, with friction included this time:

At the bottom of the slope, G's actually go to infinity because of the instantaneous change in slope. 

 As shown, I was able to create reasonably sized loops with reasonable G-forces.

That's pretty cool.  Unfortunately, we had to scrap the loop.  One of the steps to getting the 'coaster approved by MIT and Cambridge was going through MIT's Environment, Health and Safety department (EHS).  Basically, EHS said No Upside-Down People.  Period.

We had very little time to come up with a new track design, so we threw around some ideas including things liked banked curves, but decided on a (relatively) simple straight, multi-humped track design.  More specifically, it's an exponentially decaying cosine function plus an additional exponential decay, with a turn up at the end.  Even more explicitly, the track is the function 2.124e^-.055xcos(.7x - .3) + 4.676e^-.055x

Here's what that looks like in the G-force simulation:

Not too bad.  ~4.5 G's is pretty high though.  I traced the track curve into a Solidworks sketch as a spline, and then rounded out the curve at the bottom of the first hill to reduce the acceleration there.  I then exported the sketch as a DXF.  I found a MATLAB script that could convert DXF files into a matrix of coordinates.  I used this to pass the modified track shape into my same simulation.  Unfortunately, the process of converting things into splines and DXFs made the curve much less smooth, so the resulting acceleration plot is a bit jagged.  But the peaks were indeed reduced:

If you look carefully, you'll see that, with the friction estimate I used, G-forces actually go just barely negative at the top of the second hill.  Negative G's mean the cart would actually lift off the track at this point.  This turned out to not be the case on the actual ride, unless we gave the cart a really big push at the top.

I planned on taking some measurements to see how accurate the simulation was, but I didn't get around to securing good test equipment in time.  I tried out using a smartphone accelerometer strapped to the cart, but the resulting measurements were an incomprehensible pile of noise.

There's the abridged version of how we came up with the shape of the roller coaster.  Next in the series:  Roller coaster mechanical design, and maybe a glimpse into the whole approval process for this project.

Carbon Fiber Scooter

You may be wondering what's been happening with that extremely shiny hub motor I built ages ago.  Well, the vehicle being built for it is nearly complete, but I've been bad at documenting things this summer, so I haven't gotten around to making a post about it.  Until now.  Get ready for a long one.

Since the motor was intended to serve as the drive for some sort of reasonable and practical vehicle, it will be stuck on a kick-scooter shaped object.

Aluminum U channel and rectangular tubing are great ways to make scooter frames with integrated batteries.  Unfortunately, MITERS, did not have any of either of these types of stock in appropriate dimensions for efficiently packing batteries.  However there was some carbon fiber cloth, epoxy, and foam from the same stash I used in my bicycle building adventures.

I quickly laid up a rectangular carbon fiber tube:



I tried out something new for layup.  Instead of vacuum bagging the foam mold, I bent an aluminum sheet metal form, and clamped the carbon-wrapped foam mold into it.

The surface finish on the bottom and sides was excellent directly out of the mold, but not great on top.  It'll all get covered in more carbon anyways though.  The pink foam was melted out with solvents.

To hold the hub motor, I machined some aluminum forks that extend from the carbon fiber tube.  They were thoroughly machined away for weight reduction.

The side in contact with the carbon fiber was wrapped in fiberglass to prevent galvanic corrosion, and they were epoxied in place.  They were additionally screwed in place, using small aluminum plates to distribute the pressure across the carbon fiber, like a big washer.

I also added a rear fender using a segment of a conveniently sized carbon fiber tube I found at a lab cleanout over a year ago.

I machined my own fork from some thick walled aluminum tubing.

The fork is two parts.  The bottom half was thick walled tubing with 1/4" walls and 1" I.D, while the actual steerer tube is 1" O.D tubing.  The two halves of the fork were crammed together with a very tight press fit.  Maybe I'll bother with adding a fastener to prevent the press fit from slipping, but probably I won't.

The head tube assembly for this scooter is by far the most strangely shaped object I've ever tried carbon-fibering.  I started out by cutting a section of carbon fiber tubing from a broken bicycle frame.  I bored out the ends, and epoxied in bearing races for a bicycle headset.  I then cut up a carbon fiber hockey stick handle, and tacked the pieces to the head tube.

The form was vacuum bagged over with move carbon fiber, and then epoxied to the rectangular tube of the scooter frame.  A new and more powerful vacuum pump at MITERS has greatly improved the quality of my vacuum bagging.

Hey, that kind of looks like a scooter

The entire assembly was vacuum bagged with even more carbon fiber over everything, with a few extra layers around the joint holding the head tube.

This was probably the best layup I've done, and took only minimal sanding to get smooth, despite the awkward geometry of the head tube joint.

I made a long split collar to attach the steering column to the steerer tube, and used some bicycle seatpost clamps to hold it all together.  The quick release at the top allows the entire handlebar assembly to be removed for compact storage.

Mike TIGed me some sweet aluminum handlebars:

As far as scooter internals go, the chassis was designed to just barely fit a 12S 2P pack of A123 26650 cells.  For motor controller, I am using one of Shane's FF1.1 controllers.  For the fancy field oriented control algorithm to properly commutate a motor, it needs to know some of the motor's characteristics.

Phase resistance of .6 ohms was measured with a four-wire measurement.  That's kind of high, and it may be worth rewinding to pack in a bit more copper.

Measuring the back EMF took a couple tries to get right, because either I was using the MITERS scope wrong, or the scope was being weird.  I switched to a fancier scope and got it sorted out though.  This was done by scoping two leads, and spinning up the motor by friction driving it with a drill:

Kind of funny looking back EMF.  Fairly trapezoidal but with something 5x the electrical frequency added in.

Looking at the amplitude and frequency of the back EMF gave me a torque constant of .31 N-m/A, or 30.6 RPM/V.  I was shooting for 30 RPM/V when I wound the motor, so this worked out surprisingly well.  This gives a no-load top speed of  ~18 mph with a 12S battery pack.

There's not too much left to make this thing rideable.  I built a battery pack for it, but I did not assemble it quite flat enough and it had to be forced into the carbon fiber tube.  I'd like the battery and electronics to be easily removeable, so I need to reassemble the pack to make it a millimeter or so thinner.

Finally, the motor controller needs to be reprogrammed again with the correct motor parameters.  When I did this the first time around, my torque constant was off by a factor of 3 somehow, so the motor didn't commutate particularly well.

In other news, we built a roller coaster, and it was great.  Documentation to follow.

Also, there is now a virtual python-scripted version of the robot arm that draws virtual squares.  The virtual robot arm also can do some virtual gradient descent tuning on its virtual controller, which is pretty cool.  Once I improve that a bit, the real robot arm will have a real controller that doesn't suck.