It’s not often that I actually update the site in a way that’s not a build report. It does happen occasionally, and in small increments. I’m trying to clean up and update the dark, neglected corners of the site.

Reference Section

I’ve made a page specifically for links and posts  that contain technical info or methods of execution – “Useful Stuff“. For instance, my exploration of the IR21844 would be such a post. Since I’ve found that it’s a pain digging through my own build reports to find the small amount of “oh, so that‘s how I did it” within, I figure others would have even more trouble. The topics are also things which I’ve been asked about frequently – then had to go mine out of the archival depths.

Donations Box

Yup.

I’ve sold out.

Or not – but I have decided that it wouldn’t really hurt to keep open the option of accepting pittances. You may find the Paypal link on the Tips Jar page.

Nobody is morally obligated to donate. But keep it in mind if you find the site enjoyable or useful! You’re not paying for my living expenses, MIT, bar crawls, drug habit, services of ill repute, or things of that nature – it’s for showing your support of a little Turbo button on the next epic build project because you want to see it happen.

It’s May 1st.

Besides marking the two week countdown until spring semester ends, it’s also when I get serious in thinking about what the goals for the summer build season are. Historically, the summer season has been spent preparing the robots for Dragon*Con in September. Now, robots are fun and all, but I think they have become routine. If nothing else, taking on a more in-depth project is just a means of self-improvement. Last summer, I also completed and refined LOLrioKart, which gave me a taste for larger-scale, more involved projects. Overcoming its inherent Course VI difficulties taught me a great deal of power electronics and controls knowledge. Before that, RazEr and its predecessors were built to explore electric motor theory and construction. Segfault was built is being built (It’s under about 50 pounds of other stuff, but it’s coming, I PROMISE) to explore digital feedback controllers. So, with every project, I try to do something new or out of the ordinary that I haven’t done before. In the past, this has been limited to trying out new robot designs, but with my increased resource access, I’ve been able to wander outside that domain.

With increased scope and complexity comes the tallest mountain of cruft to sort through – increased cost. As much as LOLrioKart was scrounged, cursory appraisal of all its materials and parts, not counting those that have been scrapped or replaced, approaches the $1000 mark. This isn’t even including the $600+ Briggs and Stratton ETEK motor, which you can’t even get any more, and which I loaned from a friend. Nor does it factor in the price of the batteries if they were purchased new, or really any of the support equipment.

I can’t exactly fund this kind of stuff with a part-time UROP, and scrounging only goes so far before I start rejecting the compromises I have to make in order to get something resembling the original plan through and realized.

Super LOLrioKart

So with this in mind, I applied to MIT’s Eloranta Summer Research Fellowship in the name of great justice being able to realize my latest and greatest bad idea. I have always been a vocal supporter of a student project  fund that undergraduates can apply to in order to get resources for the scientific or engineering initiatives of their own. The Eloranta grant seemed the closest fit to this ideal. And it was $6,000. That’s like, a 6 with 3 zeroes after it, or about how much money the Federal Government spends every 42 microseconds.

But wait, how the hell can I possibly make LOLrioKart any better? Isn’t it already on the cover of Engineers Gone Wild?

No, it isn’t. It’s an electric gokart that has bonus points for absurdity. But LK doesn’t really do anything new that anyone else with a DC motor can’t pull off. It was a great mental exercise for me when I built the differential, or 5 different iterations of the motor controller, but that’s about it. It doesn’t even have supercapacitor boost.

The original plan for Super LOLrioKart dates back as far as the LK build itself. The idea was to have four 16kW custom hub motors, for a total of 64kW of peak motor power and the ability to drag race Tesla Roadsters. The project was then known as LOLrioKart 64. If you think about it, the power to weigh ratio of a < 300 pound kart with 64kW of motor power is not exactly trivial. But 64,000 watts is almost 90 electric horsepower, and the controls for such power levels are not exactly trivial either. Knowing my luck with LK’s DC motor controller, I wasn’t about to test it on high powered 3 phase ones; and so LK64 was shelved before I had even modeled up a hub motor.

It took a little bit more work at the Media Lab before I latched onto my next idea. Let’s say that it’s the common solution point of a CityCar, a swerve drive, and a LOLrioKart. I had an agenda to pursue with this one – I had become tired of the fussy wireless joystick derived controller for the test car. Seriously, it’s a car. You’re supposed to drive it like a car, not like a flight simulator. I set out to design a better interface for the test cars, wireless or otherwise, which were based on real car controls – steering wheel, pedals, shifters, some buttons.

The idea still involved 4 hub motors, but they would be more vestigial and just provide a level of reasonable maneuverability for the vehicle. No, see, the real focus of Super LOLrioKart would have been the four independently steered wheel pods.

Inside each pod is a ~1.5kW hub motor driving the 10″ tires (same size that LK has now) and a stock 700-size motor gearbox that handles the steering. The whole assembly would pivot around the large center gear, which is fixed to the vehicle through the upper half of each wheel arm, only partially modeled here. Each pod was designed to be independent, having internal computation and motor drivers running both drive and steering in closed-loop mode, and would only need a power connection and a point of reference. The control topology itself would be fully a wireless star network based on XBEE radios, which are extremely popular in the DIY electronics world and well-documented. Because of the full 360 degree turning ability of each wheel, there was no way you could convince me to run signal cables to each controller. It was the next stage after drive-by-wire – drive-by-wireless.

And so I wrote a 15 page proposal exposing the control agenda and some of the engineering details of this vehicle, including a rough cost breakdown based on glances at parts prices, and “timeline mitigation factors” i.e. answers to the question “Why the hell would we believe that you can build a CAR in 3 months?”

I mean, I built this in like…. a day and a half. Does that count?

…

They didn’t.

Well, I guess I can find solace in the thought that maybe it was so awesome and over the top that it wrapped back around to the other end, and thus was denied. But actually not – I probably shouldn’t have mentioned the whole ‘shopping cart’ dealie, because that would have passively thrown it from the realm of research and development work – legit stuff to ask a few thousand dollars for – to me punting a summer away by building something epic.

Which, while I consider a fully legitimate reason, obviously a group of people I have never met could not be persuaded to believe. There is something to be said about my proposal-writing and persuasion abilities if that was the case. At any rate, design of SLK stopped on the same day. It was simply going to cost too much for me to think about pursuing without free money, at least at the time of last ponderance.

But would it actually? And what are the tradeoffs I would have to make? I went back and looked at the “first order bill of materials” I had put together in accordance with the recommended format.

Many lines out of that BOM were assumed “commercial purchases”. Stock parts, things I could make or find a friend to make, but would purchase just because I had the funds, in order to save time. The first thing to get cut was the 40Ah LiFePO4 battery. MIT EVT still has their stock of small format cells that I could tap or beg. SLK would a minimum of 48 volts and 20AH, an arrangement easily supplied by a 15S10P A123 array. Many other things were gross overestimates or rough SWAGs. I can’t even think of a way to spend $400 on driver controls. Even a Logitech Driving Force wheel only costs $150 and would be ideal with a little Arduino fiddling.

The $1,400 of motor controllers was estimated from looking at what options Kelly Controller has to offer. As far as I know, nobody even makes a 48 volt DC motor controller small enough to fit inside the wheel pod. So at least some of the controls would have to be custom – and it was a problem that I seeked an answer from someone who knows alot more about motor controllers than I care to think about.  Hopefully, it would be solvable for far less than $1,400 (but likely not that much less) and some programming. Oh god the programming.

I figured there was no way I was going to escape from the raw material cost since I’d need serious metal to build the wheel modules. Also, the sheer volume of NdFeB in the motors would not cause the cost to wander too far from $400 even if I used stock flat magnets. Practically all the big power electrical components I either already have or have access to, so the “Power bus” is negligible.

With adequate scrounging and borrowing, I could probably bring the out of pocket cost under $3,000, with strong tradeoffs in commercially made parts towards DIY and fabrication. This would probably then break the project out of its summer-only timeline, too. On top of that, summer housing and living expenses take #1 priority, since exercising shopping cart absurdism is a little too close to being a hobo than I feel comfortable with.  It’s still financially unreasonable.

It’s a project that I think has the right about of Incremental Epicness given last summer’s work, which is why I haven’t dropped the idea completely. And the agenda – of course, the agenda.You don’t need joysticks to control an omnidirectional car, and I’m want to prove it.

But at the same time, I thought that perhaps I should just start on a different path completely, something that doesn’t require expensive power electronics and wireless embedded networks and lithium batteries.

(more…)

For the past z years, MIT has been trying to build another Media Lab. They finally succeeded in 2007, and construction started coincidentally about when I first got here, which really means I’ve put up with daily construction noise for essentially forever.

As well as cranes looming ominously overhead.

Anyways, the new building opened on December 2nd. Moving day was uneventful besides metric asstons of grunt work, and everybody is now happily set up in their new spaces. Let’s take a peek around…

About now is when I wish I had a wide-angle lens. I can’t fit the entire building into one frame without occupying the same physical space as either a sign or a parked van.

The new building is an impressive exercise in the “metallic gray, glass, and Faraday cage” school of design. The metal curtains make for excellent cell phone filter – you can’t get any reception up until the 5th floor or so.

That’s right.

I can only describe the interior of the building as an heterogenous mix of mental health facility, kindergarten, and research laboratory.

…which I guess sums up the Media Lab pretty well.

The entryway is a lounge and reception type area that opens up to a 4 storey lobby.

Said lobby is surrounded by walkways and 50 foot wide windows into adjacent spaces. The theme here is “transparency”. Remember that. MIT is good at transparency.

So those elevators are still under construction and just sort of hanging out there, right? Nope. They have all their mechanisms in plain view! Mechie buffs (like yours truly) will spend (have spent) inordinate amounts of time staring at the elevator hardware.

Seven or eight major lab spaces & offices peer out into the cavernous lobby.

Labs and buildings tend to be named after major donors to the construction effort. So I thank Mr. G. Hayek Swatch for… uhhh… having a pretty badass name. Among other things, I’m sure.

This is it. Major lab spaces in the building are built around two-floor conjoined spaces, referred to as cubes. They are patterned after the original Media Lab “cube”, a colloquial name for the large two-floor office-lined common space in the basement. There was only one cube in the old building and everybody wanted it.

Adjacent spaces have walkways and… observation decks? Zoo windows? Surveillance cells? Something. Windows between the labs allow you to peer at what’s going on in the next salt mine over.

So here’s how shit goes down™.

Smart Cities (my associated group) moved from the aforementioned Original Cube to the… 3rd floor? They put the guys who build cars on the 3rd floor?

Whatever. There’s more space, which is exactly what we need, besides an overhaul of parts organization systems, but hey. There’s also a walk-through, 5 ton freight elevator. I suppose that works too.

Here’s the full-size Citycar prototype and the half-scale minicar. In the left background is Roboscooter, my custodial project for the past k semesters.

This thing is so fly it’s on autopilot.

(It actually COULD be, I suppose…)

I’ve also been involved pretty deeply with the mini-bubblecar. This half scale, almost Powerwheels sized model features a body shell mockup, functioning quasi-omnidirectional drivetrain, and shows off the folding frame design. That is, it does everything which is too damned expensive to do on the real one.

It’s piloted by remote control, but…. Powerwheels sized. Come on.

Finishing details get added even as the tenants hack away.

Another cube area.

Old connects to new on all floors except the basement (and the 5th and 6th floors of the new building, because there isn’t a 5th and 6th floor of the old).

I obtained a physical plant from my cruft heap in the form of an old 5.25″ hard drive.

Okay, so it’s just the thorax and abdomen of a 5.25″ hard drive. Nonetheless, it contained a brushless DC motor. One way to tell a sensored BLDC motor is to count the wires – inevitably it will have 8 or 9. Three for the 3 phases, one for each sensor output, and a power & ground for the sensors. The “star point” of the 3 phases may or may not be accessible.

Pretty much immediately after getting the handout, I started scribbling all over it trying to adapt the 3 sensor outputs of an average BLDC motor to run the state machine. The 74LS163 would have to go, replaced with sensor interface circuitry and/or buffers.

But wait, is my HDD motor even “average”? What if it was 11 phase? Let’s take some scope readings to find out.  Here’s a picture of the back-EMF (voltage generated) by the motor when I gave the disks a twirl. Every motor has a BEMF signature because every motor can also work as a generator.

Hey! It’s a trapezoidal waveform, telltale of a permanent magnet rotor. Notice the relative positions of the waveforms. They are identical, but phase shifted. Taking wave 2 as the reference, wave 1 is 1/3 wavelength ahead in time and wave 3 is 1/3 behind in time. In electrical terms, they exhibit 120 degree phase lead/lag.

That’s a good thing. That means my motor works.

Now let’s look at the Hall sensor outputs. I didn’t pay attention to exactly which wire corresponded with which phase yet, so orange, purple, and blue don’t necessarily correspond to eachother across the scope images.

It’s a 120 degree sensor arrangement, just like it’s supposed to be. The square waves lead/lag eachother by 1/3rd of an electrical cycle.

There are such things as 60 degree sensor placements, in which the “cascade” is much steeper because the waves are separated in time by half the amount. 120 degree makes for a fully symmetrical motor, so I’m lucky to have hit upon the correct type. The two can be transformed into eachother by inverting the signal from the “middle” channel – B, 2, beta, Y, V, whatever.

This is where  I can plug the state machine in. Focusing in on one full cycle of the channel 1 signal,

Whoa, that’s MAD TYTE DAWG. If we take the hall sensors to be binary digits, Sensor 1 as the LSB, we obtain a numeric “firing order” of states!

Which meant that all I had to do to convert the SVM kernel to use Hall sensors was rewire the logic gates.

So what’s going on here now?

The connections coming from each NOR output gate has not changed. They all still go two gates each. All that has changed is the output order of the 74LS138.

• Output Y0 moves to Y3. The new Y0 is an invalid state.
• Output Y1 remains unchanged
• Output Y2 moves to Y5
• Output Y3 moves to Y4
• Output Y4 moves to Y6
• Output Y5 moves to Y2.
• Output Y7 is an invalid state.

I obtained these connections by examining Microchip Appnote 857, which showes a 120 degree sensored motor’s BEMF and Hall sensor readings, along with their respective states. I didn’t have 6 channels of measurement available to find out.

Well that was easy. But does it work?

This is what I call a “leap of faith”. In the class, you are provided materials to make a 3 phase leg PCB using a power MOSFET and independent gate drive circuitry for each channel. So the power stage was taken care of already. FVM is constructed on the breadboard.

Does it work?!!?

HEEEEEEEEEEEYOOOOOOOOO

It actually took three tries to get the sensor-to-phase relationship correct. The normal way you’d do this is to scope one phase midpoint and one sensor at a time and find which ones line up when the motor is turning. So the peak of phase A should occur at the same time that the square wave of sensor A is high.

If it doesn’t work – well, you leverage the fact that motors are round and 120 degree phase spacing is symmetrical, and swap two leads at a time until it does work. “Does” is a bit subjective, because there are two connections out of six possible combinations that result in a motor that kind of runs but has very little torque. These states were interpreted in the HDD motor as the motor trying to run, but failing because the disks’ inertia. A proper connection means the motor speeds up very quickly.

Here’s a video of Face Vector Modulation running for the first time! In the background, Channel A and Channel B of the sensors can be seen. The MITERS public scope only has 2 channels and is old and analog, so no pretty screencaps.

How fast is the motor going? The frequency counter says that state 1 rolls around 266 times every second.

When the 74LS138 selects an output, it briefly dips that pin to logical low. So I counted how many times the pin drops for every motor revolution. Most motors have more poles than the basic 3/2 model. A 3/2 motor will cycle through the six states for every 1 mechanical revolution.

Motors with more poles multiply the number of electrical revolutions per mechanical one. A 4 pole motor needs to cycle through the SVM states twice to accomplish 1 mechanical revolution. My HDD turned out to be a 4  pole motor, because by manually rotating the platter, state 1 was selected twice in one revolution.

That means the motor is actually turning half of 266Hz, or 133. This is around 8000 RPM, which is reasonable for a hard drive motor normally running in the 5400-7200 range but is speed regulated and carefully watched…. versus me flooring the PWM knob.

Back to the 6.131 lab where they have nice scopes to take a picture of the motor phase voltages…

HOLY CRAP IT’S REAL

I thought they put those trapezoidal commutation pictures in textbooks just to fuck around with me! It’s real! Motors are real! Soylent Green IS PEOPLE!!!!

The PWM rate in this image is about 30,000Hz. This is generated independently of motor state – the motor is most definitely not turning 15,000 times a second.

Seeing something that I’ve only read and theorized about up until t his point made me all giddy and happy and bouncy like a  7 year old schoolgirl. A 3 phase one, mind you. I’m not sure what that means, but let’s move on.

I wasn’t satisfied yet. I wanted reverse on the motor. Since the phases are symmetrical, you could just swap two wires and two sensor connections and the motor will happily run backwards. But BLDC motors are easily reversible by stepping backwards through the state machine. To do this in the most naive fashion possible, all 3 sensor inputs can be inverted. 101 becomes 010, 001 becomes 100.

What happens then is the controller tries to apply the opposite polarity field to the rotor. The rotor moves backwards. This moves the motor one state back, and the cycle continues.

For instance, if the motor is in state 101, the inverted pattern is 010. The controller moves the motor back into state 001, which is inverted to become 110. Conveniently, this is one state back from 010, so the commutation can continue backwards.

So how do I controllably invert all 3 signals on command without suppressing any?

The XOR (exclusive OR) function can be used as a “controlled inversion“. One input to the gate is the hall sensor, and another is a logical HIGH or LOW. When the second input is HIGH, the output is the opposite value of the first input.

In comes the 74LS136, the quad XOR chip. I stuck this in the signal path from sensor to state machine, and added a sconnection common to 3 of the gates that could be toggled high or low (read: loose wire plugged into 5v or GND).

Here’s an overview of FVM 1.0, now with the LS136 controlling motor direction.

Check out the video! The HDD motor takes a while to change speed because the disks weigh so much. All I did was suddenly toggle the “reverse switch”, which means the motor is being active forced to change directions by the controller. It’s probably not healthy for either one.

I scoped the motor BEMF on an unpowered spindown to see if the trapezoidal profile was still there. Imagine my surprise when I got this:

What the hell? It looks like it’s TRYING HARD to be trapezoidal, but is getting cut off at the ends abruptly. But the PWM is at 0% – nothing should be switching. Right?

…right?

Nope, turns out that even if the PWM is at 0%, meaning the high side switches are always suppressed, the state machine is still “running” the motor. The state machine was periodically switching on the bottom side, letting the motor current build up and circulate, then cutting it off. It was making a passive attempt at braking that only happened every half cycle because MOSFETs cannot block conduction in one direction.

When I disabled the state machine by yanking its power connection, the BEMF returned to the familiar trapezoid.

Interesting.

But wait. If that is a coast-down in the correct direction, what happens if I coast down the motor (no PWM applied) but have the reverse activated? I was curious. Would the weird untrapezoid flip across the horizontal axis?

Well, the first thing that happened was the power supply crowbarring. The lab power supply has an overcurrent and overvoltage shutdown feature. Maybe I shouldn’t do this from top speed. I spun the motor to a relatively modest RPM and tried it again.

COOOOOOL

The power supply’s voltage reading jumped up to 21 volts and drifted slowly back down to 12 volts as the motor slowed down.

Have I accidentally found the “regenerative braking” mode?

3 phase regen braking is still a topic that I’m fuzzy on.  I’ve become comfortable enough with DC motor regeneration to try and apply it to LOLrioKart in the future, and I figure that 3ph isn’t that different, just more things to keep track of.

I repeated the experiment a few times. The power supply voltage always spiked above its setting of 12 volts whenever I did the “zero power reverse”, and fell with the motor speed. This is definitely a regen mode of some sort, which makes the win even more epic.

Conclusion

FVM demonstrated that it can commutate a 120 degree sensored brushless DC motor in both directions, at variable speed, and with a possible brake mode that can feed the stored energy in the motor back into the power source.It accomplishes this with no proprietary or dedicated motor control ICs, nor with programmable logic such as FLASH microcontrollers or FPGAs. It uses only universally manufactured 7400 series ICs, op amps, and comparators.

Future directions for FVM include packaging the whole breadboarded mess onto a more permanent (maybe protoboard?) substrate and creating a basic motor controller for one of the vehicles in my flock. I intend to investigate the braking mode more to learn about 3 phase bidirectional drives.

Additionally, anyone else is welcome to build one and verify the work. Since much of this is done as an exploration by me, with limited EE intuition and knowledge, having others sanity check and confirm my observations is beneficial.

Here’s the current schematic for FVM.

Works Cited

I can’t take credit for all of it. In fact, I can take barely any credit, since the foundation of FVM is built upon material presented in MIT’s course 6.131, Power Electronics Laboratory, instructed by Professors Steven B. Leeb and James Kirtley. 6.131 is one of the most productive classes I’ve been in yet. I hope to gain the ability to unleash myself permanently from commercial controllers in the future.

It all started in 6.131.

What caught my eye in the description was “go-kart controller”. I registered for the class back when I blew up a new LOLrioKart controller about once every month or so. I wanted to learn how to do it right. Lingering in the back of my mind was the little mention of 3 phase AC inverters, but I was reassured by classmates that it was just V/Hz control for an induction motor, i.e. not really that exciting. A legitimate control method it may be, but it wasn’t BLDC .

It all changed, though, when I received the assignment handout for the AC motor control. Here’s a link to a paper jointly written by the course professor along with associates, which details the apparati and methods used in the class. Pay particularly close attention to Figure 15.

So what does it do?

Space Vector Modulation

SVM is a control algorithm for generating 3 phase waveforms to drive motors. It is based off the simplest possible 3 phase AC motor, that which has 1 winding per phase and 1 pole pair (that is, 1 N and 1 S on the rotor). Such a motor has six states it can be in which are represented by 6 voltage vectors.

There are actually 8 total states, because if the three phase legs are taken to be either on (connected to V+) or off (grounded) and treated as binary digits, there exists all combinations of 0 and 1 from 000 to 111. Both 000 and 111 themselves produce no voltage across the motor, thus no movement, and are invalid states – observing the diagram on Wikipedoia, this corresponds to all the top switches or all the bottom switches being closed.

It is interesting to note that at no time are the top and bottom switches in a leg closed together. This would result in everything blowing up because the power supply is being shorted.

What this distills down to is that simple motor commutation can be achieved using a finite state machine model. A device with six (or 8, counting the zero vectors) states that steps through them in order will commutate an AC motor.

The class circuit provides this FSM functionality in the 74LS138 3-to-8 Multiplexer chip. In its legitimate life, it helped select peripherals for microcontrollers. Here, it takes the conveniently three-bit input and translates that to one output.

So that means if you put in a binary number valued 0 to 7 (000 to 111), you get one output Y0 to Y7 selected.

Now all that’s left to do is associate each output with the top and bottom switches. Observe in Figure 15 above how the OR (actually NOR, because the 74138 is an active-low chip) gates are each tied to two 74138 outputs. That means each output NOR gate is on for two sequential states, which follows the SVM rule of at least two switches, one top and one bottom, always being on.

/

So how does that correspond to the 3 phase bridge circuit? Let’s start at “state 1″. Motors are round objects, and to a degree you can fiddle with what’s called state 1. In state 1, Q1 is on. That means Q2 cannot be on, or things would smoke. So state 1 is Q1 and Q4 on, and the motor current goes in-1-out-4.

State 2 advances the motor to in-1-out-6, state 3 now toggles q1 off and turns q3 on, and so on.

1. in-1-out-4
2. in-1-out-6
3. in-3-out-6
4. in-3-out-2
5. in-5-out-2
6. in-5-out-4
7. And the beat goes on.

The top and bottom switches are complementary and offset. The result in a motor is something trippy like this.

In the class circuit, the state switching is provided by the 74LS163, a 4-bit counter. In the lab assignment, we input a variable frequency square wave into the 74163, which sequentially stepped through its outputs from 000 to 101, 6 total states, then automatically resetting itself to 000 on state 5.

It is important to note that 000 and 111 here do not correspond to SVM states 000 through 111. The SVM 3 bit code is a Gray Code (of sorts), while the 74163 counts in raw binary. What the count from 000 to 101 does is select outputs 0 through 5 sequentially on the 74138. These output pins, in turn, go to the NOR gates and become commutation commands.

This was used as a crude VFD to turn an AC induction motor. The state machine sets up a rotating magnetic field in the motor, and it turns.

Oooh, shiny.

Face Vector Modulation

I wanted more.

I immediately saw how the simple SVM kernel could be used to run a brushless DC motor. Your average brushless DC motor has 3 Hall Effect magnetic sensors that pop high and low depending on the position of the magnetic rotor.

Wait, 3 bits?

This could get exciting.