5
\$\begingroup\$

Hi and thanks for looking!

Background

As a hobby, I enjoy tinkering with basic circuit building (often using Arduino) and lately I have mixed this hobby with another hobby of mine: building RC multicopters.

In the multicopter world, you need to eliminate as much weight as possible so lately I have been wondering if the need for traditional electronic speed controllers (ESC), which account for about 10-15% of total aircraft weight, could be eliminated.

I realize that the ESC is taking a PWM signal from the RC receiver and then converting that to something that tells the motor to change speed.

QUESTION

What is actually changing the motor's speed? Is it delta in voltage or is it a delta in frequency of the polarity change?

I may be completely off track, but it seems to me that if it is simply a matter of changing the frequency at which the polarity of the electromagnets change, then some of this could be handled in code via the Arduino thus eliminating some of the needed hardware. You would--of course--still at least need a transistor as the Arduino can't directly handle the 11-12 volts needed to drive the motor.

\$\endgroup\$
  • 1
    \$\begingroup\$ Not related to the question itself, but do note that you can get pretty big savings if you get rid of the Arduino. There are board available on the internet which already have Arduino-compatible AVR microcontrollers on them with the bootloader which would have much lower mass than the Arduino itself. \$\endgroup\$ – AndrejaKo Jun 3 '12 at 16:41
  • \$\begingroup\$ Agreed and good point! I actually don't have an Arduino on board any of my quads, I am just using it for circuit design. Good point though! \$\endgroup\$ – Matt Cashatt Jun 3 '12 at 16:43
  • \$\begingroup\$ One way to save weight would be to replace the ESCs and MCU with a PSoC. One PSoC + FETs can control 4 sensorless brushless motors \$\endgroup\$ – Rocketmagnet Jun 3 '12 at 17:53
2
\$\begingroup\$

Answer about voltage:

Voltage is the only way to let the motor reach particular velocity. Frequency of commutation is not the cause, but just a byproduct.

Is it feasible to exclude BLDC speed control as a function ? No, essentially any solution will end with building exactly same device.

Think of frequency of commutation as just the increase of phase value over time. There are 2 phase values: one reported back by hall sensors telling about momentary mechanical position of rotor. Another phase is applied field orientation.

After motor is built, since the moment when hall sensor were soldered and bolted, there is one fixed relashionship between this phases. Controller or something like controller must maintain the relationship as accurate as possible.

Parts we can not throw away (vital organs):

  • Path for phase information from hall sensors
  • Translation from sensor information into Sin
  • Multiplication of result by velocity of choice to get voltage value
  • Execution of voltage value by PWM
  • Amplification of PWM
  • Filtering of PWM on way back to motor

What was thrown away is only software parts (some parts of brain):

  • Logic and algorithms relevant to control loop: measuring velocity, goal velocity, PID algorithm etc.
\$\endgroup\$
4
\$\begingroup\$

Properly driving BLDC motors is a bit of fun with advanced mathematics.

That said, most of the cheap controllers, do some of the work, but rarely all of it. So the real question is, which tradeoffs do you want to make.

Theoretical / Optimal version

From the theoretical standpoint, you are driving each of the three windings (arranged in a triangle, which means each lead connects to two windings), with an out-of-phase sine waveform (which can be generated via PWM and some power MOSFETs/IGBTs), perhaps coupled with a balancing/filtering cap.

You are also supposed to be looking at the current draw of each winding (remember, it's inductive, so it's not just I=U/R), and using that to determine the actual (time-dependent, when the motor is rotating) impedance - this can be used to compute where exactly is the rotor, and what is it's current rotational speed.

Then, you compare this with control signal, and make necessary adjustments.

Take a look at OpenBLDC project, for more information on how to make a really nice BLDC controller. Yup, it's complicated, yup, it requires hardware FPU to work quickly enough for practical applications.

Practical Version:

From the practical standpoint, controllers take either of the four options:

  1. Dedicated BLDC chip Not exactly the cheapest option out there, but often enough actually implements all the above goals in hardware (either analog or digital, but basically optimized for this particual application). If you want to go that way, you can get going pretty quickly, but don't expect too much in terms of mass savings compared to a commercial product based on the same chip, at least if you want to keep this stuff hand-solderable - the PCB mass will add up, even if you can potentially shave off some useless electronics. The exception - some commercial BLDC controllers will have additional digital chip that interprets that weird proportional delay control RC models use. You can probably talk directly to the dedicated driver.

  2. El-Cheapo solution. If really in a pinch for space, you can actually drive a BLDC with a square wave of correct frequency. You still have to use back-EMF for speed estimation, since if you drive it too fast, it will actually stall and do nothing - basically driving frequency needs to be just a bit above current rotational frequency for maximum torque. You can PWM it too, but I doubt Arduino would have enough CPU to do sine calculations (or RAM to do lookups)

  3. Really El-Cheapo solution If really, really in a pinch for space, you can also skip the back-EMF calculation. You can do it in quadrocopters because you will have a nice feedback loop from accelerometers and the propellers acting as a turbine if it starts falling (thereby decreasing the work needed from the engine). With a lot of finetuning the open loop control software, you can actually do that.

  4. Recommended solution Get a real Cortex M3/M4/M4F CPU. It will make everything software-related seem like a breeze :)

\$\endgroup\$
  • 1
    \$\begingroup\$ 5. Use a PSoC. This can control 4 BLDCs. \$\endgroup\$ – Rocketmagnet Jun 3 '12 at 18:31
  • \$\begingroup\$ I've read a bunch of PSoC marketing blurb, having some experience from the FPGA world.. They seem really cool.. Have you used them yourself and what are your experiences? Any particular devkit/entry way you'd recommend? \$\endgroup\$ – qdot Jun 3 '12 at 21:37
  • \$\begingroup\$ I have used them in a couple of small projects, and have been pretty happy with the overall experience, especially the ease with which you can choose and configure the peripherals. At [work](www.shadowrobot.com), we will now be using them exclusively, and have designed them into my first proper equipment. The fact that you have so much freedom to re-configure parts of the circuit after your PCBs have come back from the fab is amazing. \$\endgroup\$ – Rocketmagnet Jun 3 '12 at 21:52
  • \$\begingroup\$ That's really cool! Any neat way (say, under EUR 200 for a devkit) to quikl start playing? Or are those the kind of chips you just buy and play with? \$\endgroup\$ – qdot Jun 3 '12 at 21:57
  • \$\begingroup\$ The standard developement kit is a little pricey, but contains the programmer (which you'll need anyway), a PSoC3 and 5, and has loads of features like cap sense, various I/O voltages, USB, etc. \$\endgroup\$ – Rocketmagnet Jun 3 '12 at 22:00
3
\$\begingroup\$

There are several ways to control the speed of a brushless DC motor.

The most common for which there are off the shelf chips available to implement, is to PWM the windings to effectively adjust the applied voltage. Hall effect sensors (usually) are used to determine the rotor's position within a phase, and that information is used to decide which coils to turn on or off and with what polarity. This is the same as brushes would do in a brushed motor. The processes of commutating the motor runs independently from the speed control. This type of speed control is effectively the same as straight PWM to a brushed DC motor. This is probably how your motor controller works.

Another method is proceed thru the phases at the speed you want the motor to run at, except that you watch the Hall sensors to make sure you don't drive more than 90° from where the rotor actually is. When the motor has sufficient torque to spin at the speed you want, this gives you very accurate speed control because it's basically phase locked. When the motor can't go the speed you want, you still get maximum torque since the drive vector will be 90° off from the actual position. This method gets you more accurate speed control, but is trickier to do as efficiently as the "dumb" Hall sensor commutation method. Since effeciency matters a lot in your application and you don't need super precise speed, this method is probably not the best in your case.

\$\endgroup\$
1
\$\begingroup\$

The rotational speed of a running brushless permanent-magnet motor will be equal to some fixed fraction of the commutation speed of the windings. If drives the windings with properly-phased waveforms at some particular frequency, the motor will turn at that speed. That having been said, merely controlling the frequency at which the windings are driven is not, in and of itself, a good way to control the speed of a such a motor. There are two problems with that approach:

(1) If one drives the motor with simple switched on/off waveforms, and the voltage is more than necessary to overcome the torque load, the motor will not turn smoothly but will instead move in somewhat jerky fashion. One could solve this particular problem by driving the motor phases with more sinusoidal-ish waveforms (for most motors, the ideal waveform would be a somewhat-distorted sine wave).

(2) All of the electrical energy which goes into a motor must be either be fed from the motor into its mechanical load, or must be dissipated by the motor as heat. To make a frictionless motor spin at a particular speed without a mechanical load will require a voltage proportional to the desired speed. Driving a torque load will require additional voltage proportional to the torque load. Efficient operation requires knowing how much voltage will be needed to drive the mechanical load. Unless the torque load is very predictable, some form of feedback will be required. Note that unlike stepper motors, which are designed to dissipate a lot of heat safely, many brushless motors are not. Driving a motor harder than would be required to operate at a particular speed may cause it to overheat.

(3) Attempting to drive a motor with a frequency which is significantly above or below its actual speed of rotation will cause will cause it to generate about as much backward torque as forward torque, and turn nearly all of the input power into heat. This is, of course, very bad.

Because of these factors, the normal way to drive a brushless DC motor is to have the polarity of current to the windings controlled by position sensors (so the commutation frequency will always equal the rotation speed, and the commutation phase will always lead the motor position by a fixed amount), and control the motor speed by varying the voltage. Some other sensing mechanism may then by used to provide the control with motor-speed feedback. This approach will not offer quite the degree of responsiveness that could be obtained by having a controlled which modulated the windings directly (using position sensors to determine the phase lag between what the motor is doing and what it is supposed to be doing, and using that in turn to determine whether the motor is being driven with more or less than the ideal amount of voltage for its mechanical load), but it is simple and it is adequate for situations where one is more interested in controlling speed than position.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.