Archive for November, 2009


SEGFAULT Update 5: Electric something-or-other

Nov 29, 2009 in Project Build Reports, SEGFAULT

sup dawg we heard u like segways so we put a segway on your segway so you can balance while you balance

Would two segways, one stacked on the other, demonstrate dynamics of double inverted pendula? Maybe I’ll find out soon.  Segfault is edging ever closer to completion. The end of term is quickly approaching, and I’ll be effectively out of commission (read: back in Georgia) from December 16th until the end of the year. I’m not sure if I can get the whole thing done by then, but plan for the Inaugural Faceplant to occur in the first half of January.

Course 2

I wasted more aluminum cut out the last structural frame members.

The motor mounts (trapezoidal pieces) form the bottom structure of the vehicle. Since all the force from me standing on the thing will end up being supported by the motor and wheels, the motor is extremely well secured – screwed in from both sides, then structurally reinforced by the cross pieces.

I didn’t pop the cutout scrap off the front and back rails before taking the picture. They were left tabbed (as were most cutouts, just zoom in on the picture) in order to prevent nozzle and workpiece from attempting to occupy the same volume in 3-space.

Civil engineers would note that the trussing on the frame is completely bogus. They would be right, because the number one goal was to reduce weight, not be overtly structural.

I also cut the single shiniest piece of metal that I have ever handled:

Check it out! The top plate is a single piece of 1/8″ aluminum diamond tread plate. Too bad this is going to get banged up and scratched, because it’s so incredibly shiny.

To promote tight tolerances and to avoid sand damage to the incredibly shinyness, the piece was cut diamond-side-down.  The SEGFAULT cutout will eventually be covered on the underside by something high-contrast, or perhaps glowy.

Time to start putting things together!

Here are the “risers” being attached. Along with the front and rear, they form most of the loadbearing upper structure. I was planning to have two more rails in the middle, but elected to keep the aluminum for something more productive later on. The holes left will probably be filled by standoffs.

As usual, everything is t-nutted, so it went together quickly.

Uh oh. The new 3/8″ parts required alot of sanding and fitting. It turned out that my 3/8″ aluminum (0.375″) was actually 10mm aluminum (0.390″).

Wow, that’s a  hell of a press fit. Even worse, the waterjet nozzle offset distance was incorrect, from Previous User Syndrome or otherwise. This was a machine setting I did not mess with because it’s usually set by the shop head. Unfortunately, all the slots finished nearly 0.01 undersize on each linear dimension. That means my .375″ slot was actually closer to .360 than anything else.

I gave in, and instead of riding the belt sander all night, I threw the 3/8″ pieces on the mill and shaved off some of the tab thickness.

To make sure I can maintain a dead straight cut across something almost 20 inches long, I used a Neato Machining Trick that I picked up off the intergoogles.  An accurate steel rod of greater diameter than the width of the machine table T-slots is dropped into one of said slots, where it acts as a really long parallel. Tables are generally ground and finished dead square to the machine axis, so it creates a reference surface to back your long part against.

After abrading the tabs more, I dropped a motor into the mounts to see if everything actually fits.

Answer: Yes.

T-nuts get installed with a quick mallet whack. #10 square nuts are 3/8″ wide, which makes them a perfect flush fit for 3/8″ aluminum. The same works for #6 square nuts and 5/16″ aluminum.

Repeat once again, and the bottom half of the frame is done! I didn’t have the correct screws to put everything together, so had to scrounge a bit to find some temporary hardware. This is fortunate, because i forgot to lay out the holes in the bottom plate for the front and back.

Way to go me. That’s some drill press work to come.

That’s enough for now. The frame achieved enough freestanding structural integrity such that I was able to hop on it and jump up and down with no ill effect – just the requisite bowing of the top plate from over two square feet of unsupported sheet metal.

Check out the degree-o-meter and nascent gain knobs installed in the control box!

Fellow MITERers noted that this should be a permanent installation for SEGFAULT; that is, I shouldn’t have handle bars, but rather have to sit on the platform (which is actually expansive enough to allow comfortable sitting).

This will probably mung around with the dynamics, but isn’t unreasonable.

More to come! Hubs! Wheels! Motors! Actual machining because I haven’t made a real part at MITERS in a month!

Course 6

While waiting to hog the waterjet, I continued investigation of the analog balancing circuit. So here’s where things stand:

Version 2, however, did suffer from severe electrical noise issues from the switching converter. I also had trouble keeping the gyro integrator from pegging and having poor transient response. Despite building “drift correction” circuits, the integrating capacitor would either hover at some DC level or very slowly float towards the plus or mins rails. Attempts to zero the integrator by controlling the gyro reference voltage only worked for 1 power cycle – at the next turn-on, it would fly away again.

This only occured at near DC inputs – that is, when it was standing still. In the Version 2 video, I essentially kept things moving the whole time, so there wasn’t enough time for the integrator to wander. While in operation SEGFAULT would be considered a dynamic system and thus won’t ever see DC inputs, just staying still (no input? zero DC input?) would be troublesome because there would always be an “angle” being reported.

So, how to fix that? First, a picture of version 3, and its associated schematic.

First off, yes, I know, that’s a crapton of op-amps and half of them COULD probably go, but I opted to buffer what I could in order to not have mysterious loading issues crop up.

First-and-a-half, the switching noise has been greatly attenuated by adding lots of bulk capacitance, while keeping the switching frequency at something like 200kHz.

Secondly, the gyro now has two different stages of AC coupling such that the integrator only sees AC. It may find its own happy DC offset without affecting the rest of the circuit!

The epiphany that led to this circuit design was my realization that the gyro’s only purpose is to respond to high frequency inputs that would cause false readings in the accelerometer. It should never be working at DC, because unchanging angular velocity in this case means the vehicle is rotating out of control or standing still. In one case, I’m boned, and the other is taken care of by the acclerometer.

This meant that the gyro could be safely high pass filtered. High pass filtering implicitly decouples the output of the circuit from the DC level of the input. In the schematic, IC1D buffers a passive RC HPF with a corner frequency of about 0.6hz (REAL SLOW).

IC1C and IC1D form kind of a poor arrangement of components from an EE perspective, because they could be replaced by 1 active filter, but it’s okay for now. IC1C was originally there because I found the gyro incapable of driving the RC circuit. IC2C is the integrator, which is also a form of low pass filter. It is followed by one more stage of HPF with the same time constant as the first, in order to remove whatever DC offset the integrator might introduce.

Unfortunately, none of this actually worked. The actual behavior demonstrated by Version 3 was closer to an angular accelerometer. What the flick?

So I mentioned that integrators are actually low pass filters. The relationship goes the other way also – under certain circumstances, high pass filters are … uhh, derivators. Derivativizers. Derivatificators. What happens is that integrators only “integrate” at frequencies significantly higher than that which is associated with their time constant. Such a circuit with a time constant RC = 1 will only act like an integrator for circular frequencies much higher than 1 radian per second – 10 times the break frequency seems to be the rule of thumb.

I threw everything onto MATLAB to run the numbers. Above is the Bode Plot of the integrator comprising IC2C, C3, and R7. The break frequency of this system is 1 / R7 C3, or 10 radians per second. So, for frequencies substantially greater, it acts as an integrator. This is shown above. The phase is a flat +90 degrees, which is indicative of ideal integration.

This is the HPF that links the stages of the gyro circuit together. There are two in total, which just makes the slops steeper. High pass filters act as differentiators for frequencies substantially less than their 1/RC break frequency. For both filters, said frequency is 1 / (560,000 * 470E-9) = 3.79 radians per second.

So, for a band between about 1 and 3.79 radians per second, my math functions are fighting eachother.

For any frequency less than 1 radian per second, I have an angular accelerometer (because d/dt of velocity is acceleration.

Only for frequencies substantially higher than 3.79 rad/s do I have something meaninfgul. Here’s the bode plot of the entire bottom half of the schematic, demonstrating these characteristics!

Sweet! I have THREE SENSORS IN ONE! An angular accelerometer for very low frequencies (< 1 radian per second, or 1/6Hz-ish), a gyro for medium ones, and an inclinometer for higher ones.

That’s WRONG.


To fix this, I made version 4:

It doesn’t look that different. In fact, it’s essentially the same circuit. It’s just that the filter values have been substantially modified to yield proper behavior. I made the following changes:

  • Moved the HPF break frequency to about 10Hz
  • Moved the integrator break frequency to 1Hz
  • Added “pre-gain” to the gyro output to compensate for the severe magnitude attenuation
  • Modified the accelerometer zero set circuitry so that it… uhh, works.

I can say that I’m approaching satisfaction.  For movements that contain frequency components above 10Hz (actually more like 3 or 4, but x10 is the rule of thumb for effective attenuation of unwanted freqs), the gyro contributes much of the resulting output. The accelerometer’s bandwidth-limiting LPF is also set for 10Hz, so they form rough complements.

Here’s a video of version 4 shaking and baking! It seems that the gyro stage needs more amplification, but otherwise the response is decently quick and clean. I should never be shaking that fast while on the vehicle anyway. Notice that all the time constants are absurdly low by signal processing standards because SEGFAULT is a very massive mechanical system, and the same differential equations that govern mechanical systems dictate that big things move slower.

oh man oh man it’s almost there

Face Vector Modulation Part III: Implementation

Nov 25, 2009 in MIT & Boston, Project Build Reports, Reference Posts

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?!!?


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…


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?


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.


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.


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.


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.

Face Vector Modulation Part II: Background and Theory

Nov 25, 2009 in MIT & Boston, Project Build Reports, Reference Posts

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.

Face Vector Modulation, Part I: Motivation

Nov 24, 2009 in MIT & Boston, Project Build Reports, Reference Posts

Everybody knows that I love brushless motors. They have essentially taken over DC brushed motors in just about every high performance application by virtue of being much more power dense and efficient. They have a fundamentally stronger physical construction (no spinning bundle of wire), less friction (no brushes), are simpler (no commutator), and can spin at speeds in the six digit range.  And are just… awesome.

And adorable.

And adorable.

What’s not awesome about them is control. A DC motor can be controlled by touching wires to battery terminals. A brushless motor opts to replace the mechanical segmented commutator with power semiconductors, control logic, and embedded software.

Wait a second. I hate software, semiconductors, and control logic. Those are electronics. They are my archnemesis. I want my DC motors back.

Historically speaking, control has been one of the roadblocks to widespread BLDC adoption by hobbyists. The issues of motor control are inevitably tied into motor application. There are a few characteristic traits represenative of the majority of BLDC motor controllers that are for sale to the general public:

  • They tend to be very optimized. R/C airplane motor controllers are cheap and power-dense, but being built for use with R/C equipment, they are completely run by (and calibrated by) the industry standard 1 to 2ms pulse duration modulation signal. They are designed for low torque (and shock), high speed loads, like a plane propellor, and have very poor torque characteristics otherwise.
  • “Industrial” controllers tend to be massively built and extensively featured. Field oriented control, precision tachometry, programmable curves for every variable motor parameter, feedback and servo amplification – you name it. The net result is “EXPENSIVE”, and usually low powered, for reasons including the fact that industrial motors tend to do the same thing all the time.

You have too many wires.

I approach this from the perspective of small electric vehicle hacking. Using BLDC motors in drivetrains presents issues which are (usually) not present in either a model aircraft or industrial setting:

  • Widely varying torque and speed requirements, especially high torques at low speeds
  • Shock loading and sudden disturbances
  • Commandable reversibility

Many small EVs such as scooters and bikes have been built with model aircraft controllers, including mine, and suffer from  the problem of launching from standstill. These controllers are what’s known as back-EMF commutated or sensorless controllers. They require the motor to be moving a bit so they can sense the phase voltages in order to know where the rotor is. A slight chicken-and-egg issue if I may say so myself. So unlike DC brush motors, you can’t usually stand on one of these and just take off. Motors with rotor sensors, usually Hall-effect type, and the controllers that can read them, can much more closely emulate the torque curve of a DC brush motor.

The other problem is one of signal interfacing. Because they are designed as black boxes, they are compatible with the industry standard, 50 hertz refresh rate 1 to 2 millisecond duration command pulse used by servo motors and receivers. The vast majority of EV throttle interfaces just use a potentiometer to output a varying voltage. To bridge the two requires some degree of electronic trickery or software hackery, or a product such as a servo tester.

The third problem with model aircraft controllers is their annoying startup and calibration routines. In the field, pilots tend to have exactly one tool to communicate with the model – the transmitter. Consequently, elaborate systems of changing controller settings involving varying the stick position (i.e. pulse duration) exist. So if your signal interface is even marginally wrong, the controller may become confused and not run at all. The majority of these settings only product noticeable effects at high RPMs.

What the fuck is this shit?

Recently, companies such as Kelly Controls have introduced low-cost, EV specialized controllers that address both the sensor and interface shortcomings. Besides being of questionable quality, however, the controllers tack on all sorts of frills that are useful only to legitimate EVs, such as contactor drivers, reverse beepers, light controllers, programmable throttle and brake curves, current limiting, etc. While nice to have, they are overkill for most small one-offs like scooters and e-bikes, and are enormous for the power they handle.

At the end of the day, I just want something that will run my Robot Jesus damned motor. It doesn’t have to do it with maximum efficiency, nor with minimal torque ripple, nor with phase current control. The best thing in the world would be a model aircraft ESC, with its extremely high power density, crossed with an EV controller that uses sensored motors and an analog throttle.

The goal of Face Vector Modulation is to produce a hardware kernel that will commutate a brushless DC motor with Hall-effect rotor sensors. It should not require specialized parts, proprietary ICs, or programming microcontrollers. This kernel can be extended and built upon, like an operating system kernel, to produce an EV (or robot, or bizarre kinetic sculpture) controller of the builders’ choosing, to arbitrary power limits.

The goal of a controller that I will make using the FVM kernel will be a small EV traction drive that can operate from 0 speed to the maximum speed of a not-yet determined motor, have high torque at low speeds, and interfaces to the user through a standard 5 kilohm throttle potentiometer.

Segfault Update 4: Fancy Ass-Inclinometer Lives

Nov 16, 2009 in Project Build Reports, Reference Posts, SEGFAULT

As promised, I went back to revise the sensor logic for Segfault. I am proud to annouce that I now have a stupidly overcomplicated inclinometer.


Just kidding.

The first order of business in the new construction is creating negative 5 volts. As I mentioned before, having balanced power supply rails is tantamount to approaching more theoretical performance from op-amps.And when you’re used to crashing through EE projects like very small silicon-based china shops, textbook debugging is invaluable.

So here’s the negative-5-voltificalator.

It’s a 555-based switched-capacitor dealie found all over the blagotubes in myriad configurations. I ran the 555 at 30kHz. Maybe it should be faster, maybe not – I didn’t run any numbers, like a bad engineer. The converter takes +12 volts and yields -11 volts or so. Both are regulated using the appropriate 5 volt regulators to yield stable, double-sided rails.

Who knew it was such a pain in the ass to get a negative voltage? Why can’t I just plug it in backwards?!

So much smaller. My goal with this board was to put everything pertaining to sensor signal processing on it so I can make a simple robot-on-a-stick to test the concept. It took a while to cram the componenets that tightly. The circuit up to this point produces a voltage out that corresponds to tilt angle.

No, I didn’t calculate how many volts per radian. Bear with me as I machine-gun into the darkness with exploding electrolytic capacitors.

The hardware configuration of the sensors means that I’d actually have to run the breadboard edgewise on a robot (sensors at the bottom, edges facing front and rear). Segfault itself will have the sensors mounted more appropriately.

Hey, let’s take a look at the outpuHOLY SHIT WHAT IS THAT I DONT EVEN

Well, that’s certainly disappointing. It looks like at least some part of the -5voltificator’s 30,000hz switching frequency is making it through to the output. Strange, because it doesn’t happen anywhere else. What the heck is this? Shoot-through? That’s 3 volts plateau-to-abyss!

Piling bypass caps by the gross onto the circuit didn’t help one bit, so I tried pumping up the volume on the switching converter…

…to around 220kHz. I figure I could knock it out of the range of the op-amp’s break frequency. But no, the LMC6484 is unity gain up to 1.5Mhz.

What did the ripple look like now? Maybe I knocked it instead out of the range of whatever is resonating.

Uhh, no. In fact, I think it got closer to resonating, because the wave is now significantly more sine-like. The ripple has been reduced to around 1 volt p/p.

That’s still pretty intense, though. This can probably be lowpass filtered out without affecting the circuit operation because it occurs at hundreds of kHz, and I will hopefully not be moving fast enough to warrant conveying angle information that fast. Since the motor driver PWM frequency will probably be around 20kHz, this ripple might not even matter because the motor drivers will “sample” much slower. I use “sample” loosely here, as techically a PWM comparator would be running all the time.

Oh well. I’ll just crank the horizontal sweep way up to 1ms and pretend it isn’t there. Here’s a video demonstrating quite a few improvements over the last sensor rig:

  • No nonlinearity or weirdness around the zero crossing! Probably because zero is zero, and I properly buffered the sensor outputs.
  • Symmetrical about zero!
  • No drift! If the gyro integrator is too far off base, the DC offset of the signal increases slightly and that’s it. Same for the accelerometer. The last version would slowly drift – not significantly, ultimately settling at a small DC value, but still visibly drift.
  • Real zeroing, not “leak rate control”. The accelerometer zeroing potentiometer will be available on the user panel to adjust the rest angle. The gyro zero will be glued shut in the position of least drift. I already mined every 10-turn miniature precision pot at MITERS for this.

It’s almost time to put together the bot-on-a-stick. Since this is comparatively easy, mechanical work on the Segfault chassis is continuing. In Course 2 news,


After round 1 of Segfault JetMachining™, the baseplate and some minor frame structral components are done. The parts on the left are spacers for the motor mounts, and the little things on the right are vertical standoffs for the eventual upper deck, for which aluminum plate has yet to arrive.

Yes, I did cut that whole piece out from a single large sheet of aluminum.

Something is just not right when your scrap weighs more than the part. I’m sorry, Kaiser and Alcoa. I bet you’re mad at me for wasting good metal like that.

Actually, who the hell am I kidding – you probably want me to keep making large, flat unibodies so I’ll buy more aluminum.

The bigger squares will be reused for little widgets.

Hey, it’s the upper control box! This is looking pretty crazy. After a few knocks with a belt sander, the tabs and slots just sort of fell into eachother.

They will be assembled by t-nutting, but this is the sort of thing I could seam weld and get great results from.

Check THIS out! The 7-LED battery bar graph slides into its final mounting location. There are two red LEDs, a yellow, and three greens. LED bar graphs on anything just makes it look epic.

The midpoint shown here is about 34 volts or so. All the LEDs are lit at 40 volts, and all go out at about 27. Since the Koooooooolmorgen motors are actually rated for 33 volts, the midpoint is an excellent “time-to-go-find-a-charger” reference.

The chase is on. The most difficult part of the project as I envisioned it, the analog inclinometer, has been conquered. More aluminum is on the way, and the end of the semester draws close.

Bot the fuck on.