Face Vector Modulation, Part I: Motivation

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

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.

WOOOHOOO I AM SO SWITCHING MAJORS TO COURSE 6

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,

Shazam.

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.