December 15, 2014

Turning An Outrunner Stator Into A Really Bad Induction Motor

Because why not.  A few months ago, Jamison brought a pile of small brushless motor stators down to MITERS.  I decided last night I should turn one of them into a tiny induction outrunner.  Basically, I replaced the permanent magnet rotor with an aluminum can shoved inside a steel can.  It's as simple as an induction motor can get;  it doesn't even have a squirrel cage rotor.  Although a rudimentary squirrel cage could be easily made by milling slots in the aluminum can.

Here's the stator.  Nice and densely wound, and it even has string holding the windings in!  Slightly above a hobbyking-grade stator.

I turned an aluminum can for the rotor, leaving as small an airgap as I could.  Something around .25mm

I turned a steel can, which the aluminum can is press fit into.  An aluminum end cap was attached to a steel shaft with a set screw, and was then also pressed into the steel can.  The rotor's shaft is made from fairly soft steel, and the motor has no can bearings, so any real load on the can will make the rotor rub the stator.  Definitely not made for anything other than testing purposes.  

I secured the rotor in place with  a bushing and too-big shaft collar:

Instead of commutating based on some input (hall sensors, back EMF, etc) like you would with a permanent magnet motor, you can just blindly shove three-phase into the windings of an induction motor to get it to spin (although to get decent performance more clever controls are required).

To drive the motor, Bayley and I hooked it up to this monstrosity, with some of his own sine-wave drive code.  I think the motor controller to motor ratio is a little off here:

It actually turns!

Unsurprisingly, it's a pretty terrible motor.  It took about 10 amps to get it spinning, and it produced so little torque it could easily be stopped with a finger.  I think bumping up the frequency would help, but the the motor controller brick used can't switch that fast, so the sine waves would have become much less sine-wave shaped.  It would be interesting to see how powerful and torque dense an induction motor this size could be made with some actual thought put into the design.  Time to learn more about induction motors...

November 30, 2014

Robot Arm Z-Axis and Custom Servo Drive

Finally back to the robot arm!  I've been taking a break from rideable things recently to arm more robots.  Most significantly, the robot arm got much bigger and gained a degree of freedom.

Part 1: More Billet

I started out with a huge linear rail which I think was scavenged from a large format plotter.  I found it in a corner of MITERS while replacing a table earlier this year.  I conveniently was also able to scavenge four recirculating linear ball bearings for the same shaft diameter.  I made a pair of bearing blocks to hold the bearings and robot arm to the rail:

The robot clamps to the bearing blocks using the same mounting clamps I used on the temporary 80/20 frame.

The bearing blocks have set screws which allow me to adjust the preload on the bearings:

The actuator for the z-axis is another DC motor (not servodisc pancake-style, this time) coupled to a four start leadscrew.  This was found in the same corner of MITERS as the linear rail.  It also has a really neat steel membrane shaft coupling, unlike the helical shaft couplings I'm used to seeing:

The frame for the robot is yet another piece of cruft.  This absurdly massive aluminum frame, fashioned from 1" thick aluminum plates, was found by Nick and Bayley outside a lab:

The whole assembly clamped together:

To actually fix the z-axis to the frame, I drilled and counterbored a bunch of holes in the 1" thick aluminum:

The z-axis actuated with a drill:

To stiffen up the axis, I bolted it through two of the 1" thick plates.  This was by far the largest piece of metal I've ever put on the bridgeport:

I took care to get the plate square on the mill.  It was fairly easy to get it within about 1/2 a thousandth per foot, which will be much smaller than the slop in the clearance bolt holes anyway:

Part 2: Diving into Power Electronics

This term I'm taking 6.131: Power Electronics Lab.  The class has been a very different experience from most of my other classes here.  It's very focused on learning how to actually design and build power converters of all sorts, rather than analyzing them to death.  Everyone in the class does a final project, which can be pretty much anything within reason (where reason means it can't be dangerous, for the professors' definition of dangerous).  

For my final project, I'm building a servo drive for the robot arm.  Basically its two H-bridges on a board with current sensors, encoder inputs, and an interconnect to a separate microcontroller board.  What makes it interesting is the motors I'm trying to drive.  The shiny Kollmorgen ServoDisc motors, due to their corelessness, have practically zero inductance.  When PWM'ed at standard motor controller frequencies (~20-ish KHz) the current through the motor is basically a square wave, since their electrical time constant is much smaller than the PWM period.  This means that RMS current, which determines resistive heating in the windings, is greater than average current, which determines motor torque.  Some motor makers (maxon, for example) fix this by actually putting series inductors on the outputs of their motor controllers.  I'm trying to fix this by switching really fast.

I designed the servo drive to switch at 200 Khz, using these neat CSD19531KCS logic-level FETs (7 mΩ, 37 nC gate charge, 100 V), IR2184 half-bridge gate drivers, and Allegro current sensors.  I put together a schematic and board layout in eagle:

And some time later a pile of PCBs appeared:

Here's a little mbed daughter board.  When I get sick of using mbeds and want to learn how to microcontroller for real, I can just switch out this board for another microcontroller breakout:

The board assembled, minus FETS:

And with FETs installed below the board:

This revision of the servo drive has a few problems, namely that it doesn't work properly with the originally spec'ed logic-level MOSFETS. The fast turn-on transient causes crazy ringing on the gates but it works well enough for the class with slower fets.  Further details on the controller and its problems will be documented in the future.

November 2, 2014

Roller Coaster Mechanical Design: How to Make Solidworks Really Sad

While I wrote about designing the shape of the track a while back, the shape design and detailed mechanical design actually happened somewhat simultaneously.  The roller coaster went through many revisions, as we got feedback from MIT and later some professional structural engineers about what we were allowed to build.

The first thing that vaguely resembled a cad model was this:

It was really just a 3D concept drawing, to get the idea across to all the people at MIT that would need to approve the structure.

Another quick pass at a variant of the looped design, missing most of the structure:

Having two towers would have been great, because it would have solved the problem of needing to get the cart back around the loop after each run.  In retrospect, there's probably no way we would have actually been able to build this design in a week.

After talking with MIT's Environment, Health and Safety office, we had to change things up a bit.  The basic points from the meeting were:

  • It's too tall.  No more than three levels in total.  This was actually a surprise, since the fort built last year had a fourth floor.  When asked why, the representative from EHS said he was worried about how fast people would be going at the bottom.  However, when asked, he did not have a specific limit for ride speed he could give us.  It was unclear whether the structure could not be more than three floors tall, or whether the ride itself was constrained to this height.
  • No upside down people.  We said a sad goodbye to our hopes for a loop.  Getting a loop approved was always a long shot, but it would have been glorious.  They did not seem to care that the cart would be fully constrained to the track (as in there is no way it could fall off the track at the top of the loop) or that the person would be harnessed into the cart.  
 They needed some sort of updated pictures by the next day, so I quickly came up with a rough version of the new (and final) track shape, and threw it into a Solidworks model with the same rough tower design as the previous designs.

Once we had a vague "We will probably let you build this if a professional engineer approves it" from MIT, we started designing for real, down to the 2x4.

Behind general structural integrity, the strongest force directing the design was Design for Assembly.  We would have a week to build the entire structure, and the labor skill of the students and incoming freshmen who would be doing much of the construction would range from extremely competent to which direction does the drill point?.  So the entire giant assembly would have to be fairly tolerant of sub-optimal construction quality, and possible to build rapidly, with only two people (Wesley and myself) overseeing most of the construction.

Everywhere possible, the frame of the roller coaster uses stock lumber lengths (mostly 8')  As I found out from building the climbing wall (which had almost no uncut pieces of lumber), processing all the lumber with chop saws is a big time sink.  

The frame supporting the track is made up of about 20 frames of varying height, but similar construction.  These frames could all be built on the ground independently of each other, and then assembled one-by-one once they were finished.

The track would be supported by about 100 2" long segments that interpolated the curve of the track.  These track sections could be fabricated in an assembly line-type system using chop saw jigs and assembly jigs.

As you can see from the above rendering, the roller coaster's frame also had built-in work platforms, so the track could be assembled without ladders or scaffolding.  In the final construction these platforms had railings which were not shown in the rendering.

The actual track surface was designed to be bent from three overlapping layers of 3/8" thick plywood.  The layers of plywood are easy to bend one at a time, but when three layers are sandwiched together the resulting surface is very stiff.  The plywood overhangs the frame supporting it by 6" on each side.  The cart that rolls down the roller coaster had wheels underneath the overhang, to make it impossible for the cart to fly off the track.

With the design as pictured below, I went to the Cambridge building commissioner to let him look at the plans.  He was pretty un-phased by the roller coaster, and gave feedback like make sure your railings are at least 42" tall and your stairs need to have 7" of rise and 11" of run per step.  

With those changes made, we had to find a structural engineering firm to sign of on our designs, in order for both MIT and Cambridge to okay the plans for construction.  Before sending the plans to a professional engineer, we did some 2.001-level analysis on the critical parts of the structure - the joists and spandrels supporting the floors, the tower posts, the track structure beneath the high-load areas, and the track surface itself.  

Eventually a local structural engineering firm (started by some MIT alums) willing to look at our plans for free was found.  They gave us a bunch of feedback about our design and structural calculations.  Most of our design choices checked out with them, although there were a few features they asked us to add, like diagonal bracing on some parts of the frame.  They went through our calculations thoroughly as well, and pointed out some spots where we could have made different or better assumptions about the loading of the structure.

They also asked us to make some kind of absurd changes to the roller coaster's tower.  In the original design, we spec'ed 5/8" bolts to hold the spandrels supporting each floor to the posts of the tower.  Citing some wood-loading vs bolt size chart, they asked us to make all our spandrel-supporting bolts 1" in diameter.  Early East Campus wooden structures used 1/2" threaded rod as bolts.  My freshman year, they used 5/8" bolts.  The year after that, the (different) structural engineering firm that review their design asked them to use 3/4" bolts on the fort.  This year: 1".  At this rate, there won't be any wood left in the structures in a few years.  

Here's a look at the structure supporting a floor f the roller coaster tower:

The diagonal braces on the tower also had to be significantly beefed-up.  In the past, these have consisted of sketchily screwed in chunks of 2x4.  Now, they had to have 2 1" bolts at the post, and 4(!) 3/4" bolts at the spandrel. Seriously, why don't we just build this out of solid steel next year?

Despite my personal opinion that these changes were unnecessary and frankly absurd (in addition to costly: 1" bolts cost around $10 apiece), we didn't really have any choice but to make the changes.  After all, for the Cambridge and MIT to let us build this thing and have people ride it, we absolutely needed our plans to be signed off by a professional engineer.

It was worth it though when we got a letter to the Cambridge building commissioner, approving our structure:

Here's a pile of renderings because I felt like playing with PhotoView360 in SolidWorks:

Also some sneak-peaks of the actual roller coaster, as compared to renderings:

Photo credit: Rachel Davis
And finally, a shot of the roller coaster plus fort (designed by Lauran '16 and Amanda 15').  I was doubtful that we would be able to build all of this given our time and labor constraints, but somehow we did:

September 30, 2014

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:


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 [(x1,y1), (x2,y2), (x3,y3), ... (xn, yn)], 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 (yn+1 - yn)/(xn+1 - xn).  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:

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.