Sensorless BLDC controller
I've been working for a few weeks now on the idea of a homebrew (and open-source) BLDC (brushless motor) controller for sensorless motors (no hall sensors, as used in RC planes/copters). Partly motivated by wanting to be able to tune the response of the controller for multi-copter use, partly for the challenge.
The ultimate aim is to use one Prop to control 4 motors, though the current scheme uses 9 pins to control one motor (and doesn't have over-current detect yet)...
Anyway here's a video before I get to the boring details: http://www.youtube.com/watch?v=iC4W5s7clCQ
I started with a 3-phase bridge made from 6 IRLR3717's (n-channel, 20V, 0.004ohm) and experimented with a RC motor driven at about 1V (so all the MOSFETs could be driven from logic levels). So I got open-loop control working - but of course without closed-loop control the motor would stall at the slightest provocation.
Next step was to add a FAN7388 3-phase MOSFET driver chip - very straightforward device, capable of driving up to 600V inverter apparently, 12V didn't seem to stress it... With 12V and 0.15 ohm motor windings current-limiting is essential, which meant adding PWM to the controller - in order to keep the back-EMF feedback voltages centred about mid-supply I PWM'd high and low MOSFETs simultaneously - means that the built-in MOSFET diodes are conducting during the PWM off periods, which might become an issue.
Much experimentation with different ways to close the loop. Basic idea is use a LM339 quad-comparator to detect when each phase crosses mid-supply and have the Prop chip look at the idle phase's comparator output and detect the change - this avoids any need for ADCs. One comparator is left over to use for over-current detection in the future (an ACS711 will do the measurement). I also experimented with making the PWM pulses synchronous to the commutation but in the end simple was best so long as PWM frequency significantly higher than commutation frequency.
Remaining to do is lock-detection - currently if the controller loses lock with the motor it goes into a semi-chaotic state not aware that anything is wrong - this needs detection and a lock-recapture mechanism needs developing.
Also remaining to do is reducing the pin-count from the Prop to allow 4 controllers on one Prop. A shift register can reduce the 6 output pins to 3 (clk, data, pwm) and using wired-and on the open-collector comparator outputs could be used so that over-current means all phase feedback lines are pulled low (this isn't a normal state) so no extra pin is needed beyond the 3 for the phases. Thus 6 pins per motor, I hope.
I note there's a past thread on this: http://forums.parallax.com/showthread.php?133499-Sensorless-Brushless-Motor-Control-using-a-propeller-Anyone-done-it
The ultimate aim is to use one Prop to control 4 motors, though the current scheme uses 9 pins to control one motor (and doesn't have over-current detect yet)...
Anyway here's a video before I get to the boring details: http://www.youtube.com/watch?v=iC4W5s7clCQ
I started with a 3-phase bridge made from 6 IRLR3717's (n-channel, 20V, 0.004ohm) and experimented with a RC motor driven at about 1V (so all the MOSFETs could be driven from logic levels). So I got open-loop control working - but of course without closed-loop control the motor would stall at the slightest provocation.
Next step was to add a FAN7388 3-phase MOSFET driver chip - very straightforward device, capable of driving up to 600V inverter apparently, 12V didn't seem to stress it... With 12V and 0.15 ohm motor windings current-limiting is essential, which meant adding PWM to the controller - in order to keep the back-EMF feedback voltages centred about mid-supply I PWM'd high and low MOSFETs simultaneously - means that the built-in MOSFET diodes are conducting during the PWM off periods, which might become an issue.
Much experimentation with different ways to close the loop. Basic idea is use a LM339 quad-comparator to detect when each phase crosses mid-supply and have the Prop chip look at the idle phase's comparator output and detect the change - this avoids any need for ADCs. One comparator is left over to use for over-current detection in the future (an ACS711 will do the measurement). I also experimented with making the PWM pulses synchronous to the commutation but in the end simple was best so long as PWM frequency significantly higher than commutation frequency.
Remaining to do is lock-detection - currently if the controller loses lock with the motor it goes into a semi-chaotic state not aware that anything is wrong - this needs detection and a lock-recapture mechanism needs developing.
Also remaining to do is reducing the pin-count from the Prop to allow 4 controllers on one Prop. A shift register can reduce the 6 output pins to 3 (clk, data, pwm) and using wired-and on the open-collector comparator outputs could be used so that over-current means all phase feedback lines are pulled low (this isn't a normal state) so no extra pin is needed beyond the 3 for the phases. Thus 6 pins per motor, I hope.
I note there's a past thread on this: http://forums.parallax.com/showthread.php?133499-Sensorless-Brushless-Motor-Control-using-a-propeller-Anyone-done-it
Comments
Absolutely - get tighter integration with the balance control loop that way since you have a separate estimate of actual motor trust rather than waiting for the copter's frame to rotate in response.
I am also thinking of experimenting with various motor control feedback loops (constant power, constant RPM, constant current) to see how they behave. I'm not sure how much variability in thrust you get from a propeller (the mechanical kind!) due to air turbulence, for instance - without actually measuing thrust directly that might be a limiting factor. If part of the feedback is maintaining constant thrust, then a lot of the noise from the IMU control loop could be eliminated (but you would have to crank up the IMU feedback for rapid changes, and ramp it down again for stationary hover). But maybe a well tuned IMU control loop is enough if the rpm data is available?
Thinking of the modularity I'm thinking the way to go is to have separate boards for each motor controller and one for the Prop chip in the middle - since there is always a risk of blowing up a set of MOSFETs you don't want to junk the whole board - and there is probably already a nice Prop board with 8 pins out at each corner that could be linked via headers or ribbon cable to each motor section. And of course you aren't then restricted to the Prop as the brain.
I also wondered about sticking an ATmega168 on each motor to do the bulk of the work so that it can be a standlone ESC too. Then fewer cogs need be taken up in the central Prop and it can be the main brains of the 'copter.
Thrust is directly proportional to rotation speed, as is torque. And that's all you really care about for motor control. So a BLDC motor controller would be very useful if it could take motor speed as it's input. I don't think constant current or power would be as useful as constant RPM. From the equations that control the quadrotor, we have thrust and torque:
(Open in new tab if they look funny)
You wouldn't be able to do all of the hovering code on the single Propeller, at least for autonomous. From a design perspective I like the idea of a discrete BLDC controller that can be used straight in a circuit without having to worry about programming it.
As for board design, I think it would depend whether there's a way to easily pass high current between boards. What I would like to see is something a bit like an Arduino daughterboard where the processor is mounted on it's own board, then the motor controller hardware is mounted on four daughter boards. I'd imagine that it would have the four motor controllers laid out in a row, and you'd solder the pin headers in. If a board does burn up then all you have to do is desolder it and replace it. With this design, if you decide to go to a hex- or octo- design all you have to do is make a bigger carrier board (with the Propeller on it).
Inputs to the board would be a four wire connector with RX/TX/3.3/GND, and this would power and communicate with the onboard Propeller. A possible input would be four PWM channels so it could be a drop in replacement for off the shelf BLDC motors. Also input would be the motor battery. Outputs would include the three wires for each motor, and possibly a 5v/3.3v/GND connection (if you want to power electronics with the same battery as the motor). What do you think?
How interested are you in pursuing this and making it open source? If there's any way that I can support you, let me know (parts, math help, code help, testing, etc.). I'm one of the many people here working on quadrotor code, so it would be nice to have a good BLDC controller to go along with it.
Do you have data to back up the claim that the wires are noisy? I assume that you're saying that the three wire portion of the motor control is the noisy bit. I've heard this all over the internet, but I'm skeptical that it's an issue. Anecdotal evidence, but:
--- I've been running a single motor (on a test stand) with a three wire section approximately 6 feet long (it uses a re-purposed 3 wire AC cord). I haven't seen any problems.
--- Most of the Elev-8s from Parallax seem to have the three wires running through the arm booms, and they can still fly.
My guess is that those three wires are not as noisy as assumed, but I don't know how to reliably test such a hypothesis. Any suggestions?
I guess what would be ideal IMHO is a carrier board that has the four daugter boards arranged so that the three wire section comes out from the corners of the board. It needn't be a star, but could instead be a 2x2 grid.
But again, this all boil down to how much of the "noisy wires" is a myth, and how much is true, and how to test such a thing.
If you've using 6 channels of 12bit ADC interfacing to an IMU, they are noisy! Also its simply good practice not to make unintended radio transmitters (if you ever want to turn a prototype into a product then EMI cleanliness matters). Besides you may increase the RC control range a lot by reducing the overload on the receiver input stage. Remember we're switching high current inductive loads so the dV/dt is substantial as well as the magnetic interference from the high currents.
If you've ever used a sensitive radio receiver (not a broadcast receiver, they are pretty deaf) you'll know how strong the EMI output of digital electronics and power electronics can be. Remember the noise floor is well below 0.1uV over most of the electromagnetic spectrum - GPS receivers are sensitive to 40nV for instance.
Depending how you switch and PWM the voltages are jumping all over the place - you want to sense the open winding voltage against the centre, but you can't directly get to the centre, so you synthesize it by averaging the three phases.
If you do PWM on both high and low side switches simultaneously then in theory you can reference to mid-rail. Many schemes only switch one side.
You can't have a 4th terminal because motors are would as both star and delta windings - there is no common point in a delta winding and ESCs have to work with both.
Also p-channel and n-channel MOSFETs have different series resistance so there is an offset due to this that increases at higher currents.
My initial plan is to PWM high side and low side simultaneously and I will use BJT's since I know how to bias them. I expect both failure and progress.
Suppose you have a motor with 12 Poles and you want it to go 6000 rpm which is not out of the question for this type of application.
6000 rpm = 100rps
100rps X 12 poles = 1200kHz for the base frequency when energizing the coils, meaning that the coils can only be energized or sequenced for a maximum of 833 micro seconds... actually about half of that to allow freewheeling and minimize heat buildup in the motor due to braking effects if the coil is energized the entire cycle.
Ok, so that said, any Op-Amp/comparator solution is going to need to be quick to respond and have a minimal slew rate. An Op-Amp might not be the best approach here for the higher speeds. In my later attempts, I just used the B-E junction of a transistor across coils to form a comparator. In my most recent tests I was using that signal off of the transistor to energize the NEXT coil.... however, I'm not sure why I couldn't use that signal to energize the SAME sense coil itself. In other words, the initial state of the coil works as a sensor, when enough voltage is generated by kinetic momentum from previous coils to create a signal in the input coil, then energize the input coil. The beginning signal/power to the coil gets chopped, but only by about 600mV before it's fully engaged. Don't know it was just an idea I thought might be worth trying. This way you still get a tachometer from the motor to detect stalls and current speed, but your not completely sacrificing a coil as a sensor that's not energized. The Tach information could then be used to determine the width of the pulse necessary to ramp up to the desired/commanded speed.
@Beau Schwabe, I'm one of those that sees you as the guru in your knowledge of coils. Thanks for the math. I'm not clear on your use of the B-E junction as opposed to a diode but that usually means I have to look a little deeper before the light goes on in my head.
"I'm not clear on your use of the B-E junction as opposed to a diode" ... The B-E junction of the transistor starts to conduct between about 400mV and 600mV which acts like a comparator taking the place of an Op-Amp... the output of the transistor (The C-E junction) could be monitored to determine this event and when to fully engage the coil. In the initial state the coil acts like a generator as the motor turns, when the transistor threshold is met, the processor could control when to engage the same coil to provide drive strength since the Processor doesn't need to read it as an input anymore, or at least until the next cycle occurs.
Video:
http://www.youtube.com/watch?v=ffTyTN4bvUo&feature=youtu.be
Do i need a BLDC driver/controller to drive this?
http://www.leafmotor.com/hub-motors/18f-electric-hub-motor.html
This should go into a new thread.
Electrically you don't need to know anything about the details of windings and poles. You do need to know how fast the rotor can be accelerated for a given torque - depends on the motor rpm constant and moment of inertia of the load - if you try to accelerate too fast you'll lose lock, if too slow you increase the chance of vibratory stalling. You also have to limit the torque at start up since cogging increases with torque and cogging is the main issue at low speeds. Probably want to ramp up
torque and acceleration together for best spin-up behaviour. Once the loop is closed you can check for loss of lock.
A quick word about nomenclature - "poles" is ambiguous in this context - most descriptions of BLDC motors reserve it for the number of magnet poles (this is not the same as the number of magnets, note, since sometimes magnets are placed NNPPNNPP... in order to fit round a circle and keep gap size small).
Poles in other types of motor is often the number of stator winding slots - so in BLDC articles I've seen "slot" or "tooth" used for that. Due to the many winding schemes used there isn't a meaningful number of stator magnetic poles
In most (all?) windings schemes the number of electrical revolutions per shaft revolution is poles/2 (where poles = magnet poles). Beau earlier forgot to divide by 2 I note. http://forumrc.alexba.eu/nutpol_e.htm