The Long Overdue Go-kart Post: The Birth of SmartKart

So, I'm probably going to have to give a little bit of background on this one. 2.007 is one of the primary design/build courses for MIT mechanical engineering undergrads, and also served to inspire tons of other robotic competitions across the globe (eg FIRST). Incidentally, the class is also one of the reasons that high-school me was so enraptured by the idea of attending MIT. And now, like so many funny twists that life often brings, I can safely say that I will never take 2.007. I probably wouldn't have believed you if you'd told me that, even just a year ago. But when I found myself in a position to actually sign up for the class, I realized that there was no longer much reason for me to do so. Through clever (not really, this was actually totally accidental) selection of my requirements for my 2-A degree, I'd inadvertently rendered 2.007 no longer necessary for me to graduate. Additionally, by the time I got to the point where I'd be taking 2.007, I felt I'd gathered enough design experience to render the class largely redundant for me. Sorry to disappoint you, high-school me, but it turns out the alternative is even more fun.

And what is this magical alternative, you ask? Well, to be honest, it's not really even a real thing. More just a chain of serendipity leading to me racing around in a go-kart and teaching other MechE's how to build their own. It all pretty much started when I decided that I really wanted to build a hub motor-powered scooter, and solicited advice from MIT's resident silly-hub-motor-powered-things, Charles. Basically, this initiated a new major interest in electric vehicles for me, and after going to the 2012 Maker Faire last October and witnessing all the crazy go-kart racing, I knew what I had to build next. Fortunately, Charles had run an electric vehicles special section of 2.007 last year, and had plans to bring it back as a more specific go-kart section this spring. I didn't want to wait and take the section for a number of reasons; such as not wanting to wait for a whole semester before starting, as well as not wanting one of my projects to be given all the additional constraints that come along with being part of an academic class. This was about when a rather clever idea came to mind: Charles was a grad student at the time, and an interesting property of grad students is that they're able to acquire UROPs. So, naturally, I decided that I wanted to UROP for Charles and build a go-kart. Conveniently, this actually lined up exactly with what he was looking for at the time: someone to run a sample, 'pilot' of the 2.007 go-kart section (affectionately dubbed '2.00gokart') in order to iron out kinks in the intended curriculum, and give a better idea of what was expected for the course.

Administrative details handled, I pretty much dove right in and started designing. Initially the proposed budget for the course was $300 for the kart (not including batteries, three sticks of 80/20 aluminum extrusion, and 24" x 24" plates of both 1/4" and 1/8" aluminum), so I went with just about the cheapest option for motors I could find: two CIMs. If you did FIRST, you almost certainly remember these. Since the rated 337W max output of the motors sounded a bit low to me, I opted to run them on 24V batteries instead of their rated 12. For reasons that I'm going to try not to go into too much detail about, this effectively bumps their maximum power by a factor of 4, up to 1348W. I whipped up a couple of MATLAB plots to show both conditions:

 As you can see, the motor's power output is the product of its speed*torque, which has a maximum at the halfway point of each. However, owing to the stall current of each motor (133A each at 12V), I'll never actually be able to hit anywhere near their max power output. At 24V, each motor would draw 266A at stall, or 133A at max power output, for a total of 266A for both motors operating at max power. What's the problem with that? Well, that's 1348W*2 = 2696W of power output at the motors, but unfortunately both the batteries I was given and the controller I selected are limited to 100A. 100A*24V = 2400W maximum going into the controller, so I'll never be able to hit 2696W output (not to mention the ~15-20% loss due to resistance in the motor).

Why am I okay with this? Well, the controller is able to limit its output to 100A so nothing in it will explode, meaning I'll be capped at 2400W when I'm getting going. However, as soon as my motors are spinning faster than 556 rad/sec (5310 rpm), I'll be to the right of the max power point, meaning my motors will be outputting less power but operating in a more efficient region (less torque generally means more efficiency, because torque is related to current, power loss is I²*R, so minimizing torque/current means less power loss). How fast do I need to be going to make this happen? Well, I chose a relatively high (fast) gear ratio of 13:70 coming off of my motor, and I'm using 8" diameter wheels. At 556 rad/sec, I'll be going 556 rad/sec * 13/70 * 4 in = 23.5 mph, so any faster than that and my efficiency starts improving.

Okay, enough math, on to CAD:

I started with a frame mock-up, which consisted of spending somewhat inordinate amounts of time slicing up 80/20 into chunks and then mashing it together into a shape I more or less liked (funnily enough, that's a decent summary of the physical build process as well). I knew I wanted to keep the frame fairly short and compact, because I wanted it to be (relatively) portable and lightweight.

Next I threw in motor mounts and brackets:

I used 1/4" plate for all the primary structural frame brackets, because I was worried about 1/8" plates bending. At this point I started building whenever I had parts in and then CADding in parallel. This was probably a poor methodology for design, but I had a fairly complete structure in my head of how the cart would turn out, and certain elements like brake calipers and the seat were impossible to CAD until they were physically in front of me to measure for mounts.

Here's how the final CAD turned out. This assembly doesn't contain a few things, so I'll just go ahead and describe them/mention why they aren't present:

• Battery/electronics mounts, because I quickly whipped them up in 2D and didn't update the CAD with them (mostly laziness here)
• Steering wheel, same as above
• Seat mounts, because the seat was rather organically shaped which forced me to produce a mount by hand, as such it was more something that I just threw together rather than something meticulously planned.

So, on to building! I started out by cutting some of the 80/20 frame elements on the MITER saw.

I then got my CIM motors in, which ship with a keyed shaft:

In order to interface this with the small, smooth-bore drive sprocket I bought from McMaster, I had to mill a flat on the shaft to convert it into a D-shaft.

Afterwards, it looked like this:

Next was similar treatment for the sprockets themselves - I drilled out the 1/4" bore to 8mm to match the 8mm shaft of the CIM motors, and I drilled and tapped a set screw hole.

And here it is fixed on the motor shaft:

Next, I waterjet out the preliminary mounting brackets, cut some more 80/20 lengths, and just started throwing screws into things.

Because I had designed (and actually cut out, which was a mistake) the aluminum sprockets prior to getting my Harbor Freight wheels shipped in, I estimated the hole pattern as a 2.5" diameter when in fact it's actually 2.6". Accordingly, there was a bit of this involved:

As the waterjet can only cut parts in 2D, I also had to chamfer the edges of the sprocket to allow the chain edges to slide over it. I just eyeballed this one on the MITERS lathe.

Next, I had to part and tap a bunch of little spacer doohickeys to attach the sprockets to the wheels.

I also made some delrin spacers to axially support my wheel on one side, they have a chunk milled out of them so they can slide under the bar of 80/20 that the axle mounts are attached to.

And a shot of the part in action:

The chain was pretty sticky on my waterjet sprockets, so I went ahead and tensioned them and ran them in for 15-20 minutes each, just to get the chain to grind down the interfering aluminum on the sprocket.

Somewhere along the line, boredom and lack of a front half of the vehicle led to a rather monstrous contraption, with the combat robot Null Hypothesis serving solely as a temporary motor controller:

Then I waited a couple weeks and focused on Blizcopter while I waited for parts to ship in. I also made another giant waterjetting run, resulting in a pretty massive pile of parts.

I had to make some real tiny Delrin bore adapters for my steering knuckles, which honestly scared me a bit to turn because of how thin/fragile they were.

Yikes.

My waterjet holes on the front of the steering knuckles also didn't quite fit the 5/8" shaft I was using because it was about .005" over diameter, coupled with the fact that waterjet holes end up a little smaller than designed. So, naturally, the solution is to find a pointy 5/8" thing and just beast the hole wider (the shop I was in at the time definitely doesn't carry 5/8" drill bits).

And here's what the steering knuckles look like when mounted on the frame:

I then hack-sawed some threaded rod to put in the tie rods driving the steering linkage, and mounted front wheels.

Unfortunately the rest of my 5/8" stock didn't quite fit inside the bearings I'd bought for my steering linkage, so I had to move to the GIANT lathe downstairs and turn down the whole thing by just a few thousandths.

Seriously, this thing is massive. That shaft is easily 2.5' long.

Now the basic frame was close to complete! Obligatory celebration dance:

As you can see, the wheelbase is pretty miniscule.

Next, I needed a lot of T-plates to set up the attachment for the seat to the frame, and I didn't have enough patience to go waterjet these. So, I enlisted the help of a friend, and we started beasting out mount plates by hand. I started by cutting out some squares, clamping them together, tracing out the outline of the part, marking holes, and then drilling them out:

Next I bandsawed off the excess.

I went ahead and drilled some holes through the bottom of the seat and attached them to the tops of some 80/20 mounted to the brackets I'd just made. I also threw the steering 'wheel' (lol) on top of the steering rod, but it wasn't fully mounted at this point.

The seat was super wobbly in left/right bending, so I just attached a giant plate of 1/4" polycarbonate (yeah, that bullet-proof glass stuff) to the back to support it better. I also lasercut some quick acrylic battery mounts, and got started on wiring up the electronics.

Shh, don't tell the shop guys I did this...

I fit a laser-cut acrylic electronics mount into the center of the kart, where it holds the motor controller and ignition key.

I went ahead and installed some requisite glow-lighting, finished up the wiring, and was left with a reasonably functional go-kart:

Done? Not quite, there are still brakes to worry about. I cut out a cute little brake-pedal-mount-box, accidentally failed the clearance on the sides a little bit, and milled them out a touch.

I turned some little spacers to go between the brake discs and my sprockets, drilled more holes in the sprockets (same process as last time) and attached them together:

I still had some slight clearance problems with the brake calipers, so I had to dremel the face down just a little bit.

And a close-up showing the brake caliper mounted, as well as exactly where it was hitting the chain:

I also finished the brake pedal and added that to the front.

So, the state the kart is currently in:

And of course, obligatory underglow picture.

As you can see, the original front bumper I designed hasn't been fabricated yet because it's not essential to the function of the kart, and I haven't gotten a chance to go waterjet the mounts for it yet.

I decided to dub this kart the SmartKart, owing to its short wheelbase and passing resemblance to the similarly named car. The top speed is a calculated ~33mph, unfortunately the range is rather lacking as it only has two batteries, so it's only able to run for a continuous 5-10 minutes before running out of battery. Overall I'm pretty happy with how the project came out, and I'm looking forward to 'back-modding' it a bit now that my original design constraints (pretending to be in 2.00gokart) have been alleviated. It's not the most practical project, but it's a lot of fun to joyride in, and the tight turning radius makes drifting pretty easy. Now that the weather's picking up, I'll try to take it garaging sometime soon and update this post with a bit of video.

I've been pretty busy with classes this semester, which is why SmartKart took me so long to write up (it was effectively done a couple of months ago), but hopefully I'll be able to write another post soon (BE3P is way overdue for an update).

With SmartKart finished, the real 2.00gokart section started this semester, and I'm tagging along as a TA for the section and helping other students go through this process on their own. I'm hoping for some pretty crazy ideas/execution from them, and if I can manage to talk any of them into writing up their kart builds on blogs, I'll be sure to put up links here.

Introducing the BE3P

In a bit of a departure from my typical posts, I'm going to write one about something that doesn't actually physically exist yet: a brushless 3-phase motor controller I've spent the last week working on with my friend Erik; the BE3P (Banks Erik 3-Phase). Traditional brushed motor control effectively provides the motor with an average DC voltage and then brush contacts in the motor shift as it rotates, causing the magnetic field generated by the coils to always attract the next set of magnet poles, producing torque. Brushless control is a bit trickier, because this switching of the field needs to be handled in software, i.e. the controller needs to determine where the motor coils are in relation to the magnets in order to switch current through them accordingly. We got a bit of a crash-course in brushless motor control from our friend Shane as well as a few online resources, then we immediately started browsing for the major components. We decided to make the controller optimized for the hub motor I built, which probably isn't able to handle more than about 1200 Watts peak. My battery runs around 40V, meaning we're aiming for ~30A peak. Since exploding your components is kind of bad, we over-specced everything a bit (especially the MOSFETs) in order to (hopefully) be able to handle 30A at 40V peak without substantial heatsinking. We centered our design around an Atmega328 microcontroller, an HCPL3120 optocoupled gate drive, and surface-mount MOSFETs rated to 120A at 60V.

Just to warn you, I'm going to try to start basic but this post is necessarily going to get progressively more difficult to understand if you don't already have some idea of motor control theory.

Okay, quick intro: the easiest way to control the average voltage (voltage relates to speed) given to a motor is by taking your battery voltage and pulsing it (relatively quickly, on the order of 10's of kHz) across the motor. You can vary the exact average by controlling the duty cycle (percentage of time that you're applying battery voltage) of the pulses. This type of voltage control is called PWM. So, how do you quickly switch between battery voltage and ground? Transistors! A MOSFET (metal-oxide-semiconductor field-effect transistor) is a type of transistor that can turn on quickly and takes relatively little power to do so. Effectively, the MOSFET has a capacitor ("gate") inside it that turns the "switch" on when you give it a voltage on the order of ~5-15V. "Okay, sweet, my Arduino can do that!", you say? No, not exactly. The problem is that the MOSFET doesn't behave nearly as nicely while the gate capacitance lies between 0V and the "turn-on" voltage of ~5-15V. While your Arduino would (actually it wouldn't, Arduinos have fairly fragile output current limits) be able to drive an "ideal" MOSFET (zero resistance between your output pin and the gate capacitor), in reality there's some amount of resistance along that path, which means that there'll some nonzero amount of time required to charge the gate up. Why? Physics. It ends up being much more efficient to drive the gate with higher voltages (~12-15V) in order to throw higher currents (remember that current is rate of charge flow) into your gate, charging it faster.

So now we need something that can quickly switch between 0 and 15V to drive our MOSFET which can quickly switch between 0 and ~40V. What, you thought this was going to be simple? (I'm not even going to go into other problems like the necessity of bootstrapping your high-side nFETs to enforce gate drive voltage between the gate and the source by leaving the source voltage floating). Well, this is where gate drivers come into play. Gate drivers are devices that can throw quick bursts of charge onto your MOSFET gates. Perfect! The gate drivers we picked out are opto-coupled, which basically means they have a tiny LED inside them and they dump charge onto your FET gates whenever the LED is turned on. This is great, because it means that all your little 5V microcontroller has to do is turn on an LED in order to drive the motor. Additionally, it means that your 5V systems and your 15V systems are only connected by light, which protects your low-voltage electronics and prevents high noise levels on your signal wires.

All of the above basically needs to be copy/pasted 3 times for brushless 3-phase control, which I'm not going to try to explain too heavily so as to avoid turning this blog post into a dissertation. The main important thing is that for "sensorless" control, meaning the controller doesn't directly know where the motor coils are relative to its magnets, it needs to have voltage sensors on each of the phases such that it can turn one off at a time and sense the voltage coming back out of it, from which you can determine the "electrical position" (basically the position of the coils relative to the magnet poles) of the motor, which in turn lets you drive it to the next desired position.

Okay, now that we've gotten physics/theory out of the way, let's move on to the interesting part: actually designing. Not only is this my first foray into brushless motor control, it's also my first time using Eagle CAD for a major board as well as using surface mount parts at all. This was basically a "learn everything as you go" style project for me, so I just kind of jumped into Eagle and started designing.

Here's an early schematic which shows the absolute basics. I'll explain starting from the far left, because that's sort of the direction of flow for this design. First there's a 15V switching regulator, which converts the 40 volts off of the battery down to something more manageable. Next, a feedback and filtering circuit which allows the 15V regulator to operate and cleans up its output a bit. I then have a 5V linear regulator which converts the 15V down to 5V in order to power the microcontroller. The giant box with lots of pins is the microcontroller itself (Atmega328), which then connects to a couple of status LEDs, as well as the three giant boxes you see in the middle of the schematic. The boxes are inverters and they along with the little resistor and capacitor to the right of them form a little circuit that takes the PWM signal from the microcontroller, splits it into two opposite signals and adds a little delay between turning each side off and turning the next on. This delay is a form of shoot-through protection, which means it avoids allowing the high-side and the low-side to turn on at the same time, which would directly short your battery through both FETs and explode everything. To the right of this inverting circuit you can see all 6 gate drivers, and finally the 6 FETs that they're driving.

Next, I moved on to adding the voltage and current sensing circuits. The current sensing consists of a very small (.001ohm), high current resistor in series with the motor phase, connected to a sensitive differential amplifier, which determines the voltage drop across the resistor and thus allows you to calculate current passing through the whole phase. Current sensing is extremely useful for a variety of reasons: (warning: physics) it allows you to calculate the phase-lag between your drive voltage and the current response of your phase (because your motor is an RL circuit), and since current is what you really care about in terms the position of the motor (because current creates flux which in combination with the field of the magnets applies torque), you need to offset the voltage by that detected phase-lag in order to time the torque with your phases switching electrical positions. Current sensing also allows you to do some nice things like over-current protection, constant-torque control, and the ability to detect shorts between the outputs and (hopefully) save your FETs from detonation.

As for voltage sensing, it's absolutely essential for DC sensorless control because, as I said above, it's the only way you can determine the electrical position of the motor.

Here you can see the current sensors (small boxes to the right of the FETs, and only on 2 phases) followed by the voltage sensors to the far right. The voltage reading is passed through a 2-stage RC low-pass filter, because there are lots of high-frequency voltage transients across the undriven phase due to the PWM on the other two and you want a smooth signal to determine the electical position.

With the absolute basics out of the way, I moved on to adding various extra stuff, including bus capacitors to smooth the voltage across the FETs/provide them with clean-ish power, a battery voltage sensor, a 20MHz oscillator for the microcontroller, an ISP header so I can actually program the microcontroller, throttle/extra input (or output) pins, and finally an XBee header so that the controller will be able to support wireless data transmission.

Yay! With the schematic finished (after like 4 days of staring at datasheets), I moved on to actually laying out the board. I definitely wanted it to be able to fit in my scooter, so I decided to make the outline 2.75" by 3.75".

I'd never laid out a board before, so this was my chance to learn Eagle's board layout features. I experimented with a couple of different general layouts before I settled on one I actually liked, the picture above is one of those early layouts.

This is the general layout I ended up settling on, you can see the massive power and ground traces on the left side of the board, and away from everything but the FETs and bus capacitors.

Here's a snapshot from the end of the first day of laying out, I got a little panicked about how much space things were taking and started trying to cram everything together towards the bottom, which in retrospect was a little bit of a mistake. It turns out I had more space than I thought, so cramming made my layout look pretty disorganized. On the plus side, however, this meant that the last third or so of routing went extremely quickly because there was an abundance of space available.

Here's the finished board design with everything routed, and I also added a logo on the back as well as name/date/credits on the front middle.

Erik and I each independently created our own boards and schematics because we wanted the additional practice, and for our PCB order we just put 2 of each of our boards on a panel. We also ordered enough components for 4 boards, so if all goes well we'll end up with 2 controllers each.

For now, it's time to wait for parts to arrive, which we can fill by starting on the code for the microcontroller. Basically, I'm going to enjoy spending a few days staring at massive spreadsheets which tell me which registers do what.

Hopefully that was at least somewhat intelligible for people of varying levels of experience, let me know if you have questions about the design/components/whatever.